A signaling architecture for multimedia MBS over WiMAX
© Femminella et al; licensee Springer. 2012
Received: 20 September 2011
Accepted: 11 April 2012
Published: 11 April 2012
In this article, we design and demonstrate a signaling architecture for multicast and broadcast services over a laboratory-emulated worldwide interoperability for microwave access (WiMAX) network. WiMAX is a broadband wireless access technology which includes different quality of service levels. Currently, a significant research effort focuses on data transmission optimization and mobility support for multicast and broadcast services. Our proposal is fully IP-based, and the relevant signaling architecture is modular in all its entities and extensible to other, non-WiMAX, IP access networks. We specifically address the non-trivial support of multicast services, which has been demonstrated through a prototype implementation of our proposal for an Internet protocol television (IPTV) service. This prototype has been implemented by using open source technologies and its signaling is orchestrated by a JAIN SLEE server. The results obtained show that the implemented system is scalable, can achieve both high signaling throughput and low service latency, and has a signaling overhead lower than similar IMS-based solutions.
KeywordsMBS JAIN SLEE WiMAX signaling SIP IPTV
The worldwide interoperability for microwave access (WiMAX) is a wireless broadband technology. Its architecture includes a set of flexible capabilities which enable the convergence of mobile and fixed broadband networks. By using suitable communication technologies, such as multiple input multiple output smart antennas and orthogonal frequency division multiple access, WiMAX can provide high throughput, efficient data multiplexing, and low transmission latency in both fixed and mobile communications. These features, together with the capability of covering large areas with relatively few base stations (BSs), are fundamental to deploy effective wireless broadband network services able to support many applications, such as data exchange, audio/video streaming, and VoIP services, with different levels of quality of service (QoS) . Leveraging on these network services, service providers can also implement the so-called Multicast Broadcast Service (MBS) over WiMAX, which consists of providing mechanisms for delivering the same contents to multiple users who share radio resources. In particular, a single-frequency operating mode is envisaged, through which a single radio channel is used to distribute information to all users subscribed to the same service . The MBS is typically used for delivering multimedia contents, such as mobile Internet protocol television (IPTV) and audio/video file casting, and for implementing massive software updates [1, 2]. Implementing MBS over WiMAX is not trivial for service providers, since customers may also need a return channel for interacting with a management system in order to dynamically subscribe/unsubscribe to any available service. Moreover, multicast services are more complex to be designed and maintained than broadcast services, due to additional signaling, content delivery authorization and management, and required support of multicast streams in WiMAX subscriber stations (SSs) and mobile stations (MSs). Finally, an MBS architecture must be scalable with the number of users, requires a central management system, should both include an easy to use management software application and be implemented through standard technologies so as to simplify MBS service development and maintenance.
In this paper, we illustrate an original design, and the relevant prototype implementation, of a simple and effective end-to-end service architecture that extends the MBS Network Reference Model (NRM)  and provides MBS over WiMAX.
Our aim was to create a flexible and efficient signaling system for MBS architecture, with a low architectural complexity, so as to reduce the initial investment for service providers. In fact, an MBS system has a quite complex set of requirements, such as the need of using a return channel and a central service orchestration point that needs a suitable design. This design has to guarantee scalability, manageability, efficiency and maintainability. Most the recent literature on MBS focuses mainly on data transport over WiMAX networks. Nevertheless, in order to achieve the MBS requirements mentioned above, a suitable signaling support is also essential.
Our proposal addresses these features by resorting to available standard and open interfaces that speed up implementation process and reduce time to market. In fact, the use of development frameworks providing high-level APIs may be extremely helpful to service creation, since suitable APIs can mask the complexity of underlying network and transport layers. In addition, the use of standard open interfaces, rather than proprietary ones, has the additional advantages of both supporting multiple access networks, devices, and protocols, and attracting a larger number of developers. For these reasons, some key implementation issues of our MBS architecture have been faced by resorting to the Service Logic Execution Environment (SLEE), which is a hosting environment for advanced telecom services. The SLEE logic is designed to fulfill the specifications of telecom services, which are typically asynchronous and require high throughput and low signaling latency. Thus, a SLEE server can be useful to effectively orchestrate the overall signaling architecture of MBS over WiMAX.
Our MBS solution is IP-based and adopts standard IP signaling protocols, such as SIP (Session Initiation Protocol)  and IGMP (Internet Group Multicast Protocol) . We have implemented the core signaling elements by using an open source JAIN SLEE application server (AS), named Mobicents . Being based on standard protocols and open interfaces, our architecture is not limited to WiMAX, but it may both include other existing networks, and be accessed by most existing terminal devices. As a proof of concept, we have implemented an IPTV multicast service on top of our MBS prototype, which is often indicated as the main application for MBS architectures . We show that this service is scalable with the number of users, flexible in the deliverable contents, modular in all its entities, and centrally manageable. Latency and throughput are evaluated experimentally, and an in-depth analysis of the signaling overhead and its impact on a WiMAX network is presented.
The paper is organized as follows. The next background section shows a brief overview of the SLEE container, including the open source SLEE package that we have used in our implementation; it also illustrates the MBS over WiMAX issues and some recently published results, including a related work about an alternative signaling architectures for IPTV. Section 3 describes the design of our service architecture and the end-to-end signaling flows between network entities. Section 4 illustrates the test-bed implementation. Section 5 shows the achieved performance, including a specific analysis of the signaling overhead. Some final remarks are reported in Section 6.
2. Background and related work
2.1 JAIN SLEE specifications
A SLEE is a service container made of several abstraction layers. Its multi-tier architecture simplifies the development of complex services by providing the non-functional features needed for their execution, such as object lifecycle management, persistence management, thread management, object pooling, and so on.
The Java APIs for Integrated Networks (JAIN) activity has delivered the JAIN SLEE (JSLEE) specifications, which delineate a Java-based, event-oriented, and protocol-agnostic container suitable for hosting carrier-grade telecom services . It includes different Java Enterprise Edition (J2EE) components, adapted to the needs of telecom applications.
In a JSLEE container, a service logic is organized and implemented in system components called Service Building Blocks (SBBs). In operation, a JSLEE server creates a pool of SBB objects and manages them according to a well-defined lifecycle. SBBs operate asynchronously by receiving, processing, and triggering events. They are attached to one or more data streams called Activities, by which they can exchange events and share state variables (Activity Context) regarding the Activity itself with other JSLEE system entities. SBBs may be hierarchically structured according to parent-child relations, in order to enhance service logic modularity. Events are internally managed and routed by a functional entity called Event Router, which delivers each event to the appropriate recipient SBB. With regard to the JSLEE performance, an Event Router plays a critical role, since it processes all system events.
External network events, such as a SIP message arrival, are translated into JSLEE events by means of specific entities called Resource Adaptors (RAs). Thus, the set of available RAs constitutes an abstract interface layer that allows a JSLEE to access external resources. If service interoperability with a particular protocol stack is needed, it can be achieved easily by including the relevant RA interface in service code (e.g. methods to access SIP header fields) and deploy the appropriate RA Java archive (JAR) file within the JSLEE container.
Our MBS signaling server has been developed by using the Mobicents Communication Platform  that is an open source project currently owned by Red Hat. Mobicents includes a JSLEE, a Media server, a Presence server, and a SIP Servlet server. At the time of writing, the Mobicents JSLEE (MSLEE) is under active development and it is the first and only open source implementation of the latest JSLEE v.1.1 specifications . The MSLEE includes several J2EE components, such as Container Managed Persistence (CMP) fields, which enable data persistence for SBB objects, Java Database Connector (JDBC) drivers, Java Management Extensions, SNMP interfaces, and Java Naming and Directory Interface (JNDI), which provides lookup functions for services and variables. In order to leverage the aforementioned J2EE technologies, the MSLEE is deployed and executed within the JBoss AS , which plays the role of container of containers, offering advanced capabilities such as JSLEE service deployment, thread pooling, logging, etc.
2.2 MBS over WiMAX
A broadcast service may be defined as a unidirectional point-to-multipoint (PMP) service in which data is transmitted from a single source to all terminals (Subscriber Units, SUs, including either MSs or SSs) included in its broadcast service area. Thus, broadcast services are often referred to as push-type services . Multicast services are unidirectional PMP services in which data is transmitted from a single source to a multicast group of SUs located in the multicast service area. Only SUs that have subscribed to a specific multicast service and joined the relevant multicast group can receive data relevant to that service. Whilst a broadcast service can be accessed without any explicit request from customers , multicast users need a return channel for interacting with a management system, in order to dynamically subscribe/unsubscribe available services. Thus, designing an end-to-end multicast service architecture is not trivial since it must fulfill all service requirements and be compliant with the underlying network architecture.
The IEEE 802.16-2009  standard specifies the MBS deployment over WiMAX networks. MBS provides an efficient transmission of multimedia streams from one or more BSs to multiple MSs through a shared radio resource . Multiple BSs compose an MBS zone, where BSs synchronously transmit over the air multicast data belonging to the same service flow, by using a common connection identifier (CID) and through the same security association. Since BSs located within the same MBS zone use a common Multicast CID (MCID) for the same MBS multimedia stream transmission, MSs do not require registration to any specific BS and the handover functions are transparent to a MS moving within the same MBS zone.
The MBS service can be provided over the WiMAX air interface , since:
high data rate and large coverage using a single frequency network;
flexible radio resource allocation that enables dynamic radio resource management in MBS areas;
low MS power consumption;
low channel switching time, in order to support multichannel services such as mobile IPTV.
MBS over WiMAX is suitable for applications that need to simultaneously provide large subscriber groups with the same data. Usage of broadcast/multicast bearers allows multiple receiving SUs to share downlink radio resources and receive the same data in parallel. Hence, this technology allows network operators reducing costs for delivering multimedia services, such as mobile IPTV, audio/video file-casting, mass software, and configuration updates. Further, multicast/broadcast transmission allows such services to scale well with the number of users, without modifying the network capacity even in case of extremely high service demand. Multicast services are more complex to be designed and maintained than broadcast services due to additional signaling exchange and content delivery authorization and management. For this reason, the implemented service, shown in what follows as a proof-of-concept of our architecture, focuses on multicast transmission of IPTV to WiMAX users.
2.3 Related studies on MBS over WiMAX
Some of the recent literature on the MBS-enabled WiMAX focuses on the extension of the baseline MBS architecture in order to improve the performance of video broadcasting over the air [2, 13]. Other articles are related to video QoS provisioning [14, 15] and handover management . Nevertheless, the end-to-end signaling support for IPTV provisioning over WiMAX is not investigated. In , the multicast service management is optimized in terms of channel switching time, uplink bandwidth, and power consumption. Nevertheless, this proposal requires SU modifications, which do not operate in a standard way, especially for what concerns IGMP message handling. We believe the need of modifying SUs to be a strong limitation.
Differently, we prefer the solution of using a dedicated service delivery entity [2, 13–15, 17] and enhance it by adding signaling and authorization capabilities. In addition, the solutions proposed in [2, 14, 15] can easily be integrated in our architecture, since we do not require any specific procedures for handling multicast data flows.
In regard to signaling for IPTV, the articles [18, 19] present an approach based on the IP Multimedia Subsystem (IMS) . In , the authors present a detailed SIP exchange for live TV and Video On Demand, both for content request and content switch, and analyze the relevant message delays. In , an IMS-based architecture for providing converged IPTV services, compliant with the ETSI TISPAN NGN release 2 specifications, is illustrated. Extensions to IMS session setup for supporting multicast-based many-to-many services are discussed in . Proposals in [22, 23] enhance the IMS-based service architecture illustrated in , by adding scenarios aiming to a future interactive TV experience, illustrated by a SIP signaling exchange.
The SIP-based IMS architecture is the most largely used in the IPTV signaling proposals [18, 19, 21–24]. Nevertheless, IMS is a very complex reference architecture, and its complexity often leads service providers to resort to simplified architectures, often proprietary, to provide users with advanced services. Due to its complexity, IMS typically exhibits worse performance than a pure SIP-based service architecture . Our aim is to create a simple and effective architecture that both require a very small initial investment and provides advanced MBS services without changing existing network entities and configurations.
3. System architecture
To facilitate end-to-end interoperability, the WiMAX forum has specified the WiMAX NRM , that is, a logical representation of the network architecture. The NRM is based on all-IP core and a packet-switched air interface. The main NRM advantage is that the network entities are agnostic of the IEEE 802.16 radio specifications. In , a new entity, called MBS Controller (MBSC), has been included within NRM. However, as mentioned above, the MBSC has been defined only for improving service data delivery, without specifying signaling entities and signaling flow management.
The MBS is used to offer data services, including real-time and non-real-time multimedia streaming, together with relevant service announcements. Since the NRM is IP-based, streams can be transmitted from either a dedicated multicast server (e.g., a content provider directly connected to the CSN) or an Internet streaming server.
As mentioned above, providing MBS over WiMAX is not trivial for many reasons, such as the need of using a return channel for interacting with the network entities and dynamically subscribe/unsubscribe services. Thus, in what follows we focus on the design and the evaluation of a suitable signaling architecture for multicast services. A simplified version of our architecture can also be used to provide broadcast or push-type services.
Our solution is IP-based and it includes standard IP signaling protocols only, such as SIP and IGMP. This way, the scope of the signaling architecture is not limited to WiMAX access networks, but it includes most of existing data networks and is accessible by most existing terminal devices.
SIP is the main signaling protocol of IP multimedia services  due to both its flexibility in supporting different signaling scenarios and its reliability, also when messages are transported by UDP segments. In addition, SIP is the de facto standard protocol for VoIP communications and it is central in the 3GPP IMS . However, it is worth noting that in this context the concept of MBS session is very different from the call session typically used in the Internet telephony field. In fact, in our case signaling is used to set up a unidirectional point-to-multipoint media flow, whereas in the Internet telephony it is typically used to set up a bidirectional, point-to-point media flow. Also the pricing scheme is different. In Internet telephony each call is typically charged on a per-second basis , and the use of SIP calls handled by SIP back-end servers on the signaling path is necessary to correctly apply charging policies. Instead, in the scenario proposed here, it is much more suitable a per-session charging. Thus, we have decided to use simple, session stateless, SIP MESSAGE requests to wrap data exchanged between MBS entities [4, 28], instead of the classic SIP INVITE used in IMS-based systems [18, 19, 21, 29]. This approach simplifies signaling management (e.g., see ) and maintains user state consistent by keeping its information updated in the database running in the MBSC-DB.
Finally, IGMP is used to manage multicast groups. Clients use IGMP to report their multicast group memberships to any immediately neighboring multicast router. There are essentially three IGMP message types: Report, Query, and Leave Group. A Report message is used in two situations. When a client wants to receive a specific multicast stream, it sends out an unsolicited Join Report message to the local router in order to join the group. Another situation is when the client passively generates a Membership Report for its interested groups in response to a Query message. A Leave message is sent by a client when it leaves a multicast group. It allows group membership termination to be quickly reported to the router in order to release resources.
When the first user access to the MBS system is gained, he is asked to subscribe to categories of interest. For example, in an IPTV service user can subscribe to a package containing his favorite TV channels, whereas in a software update service user can select the software type to be updated (e.g., anti-virus or system updates). Users can add or remove subscriptions at any time, after being authenticated by the MBS system through the login phase described above.
In the announcement phase, users are informed about the subscribed MBS sessions, such as list of TV channels and the relevant contents. An announcement can be distributed in either multicast or unicast fashion. We have implemented both approaches. In case of multicast distribution, we have provided a specific multicast channel, for each package or channel offered by the service provider, to send announcements from the MBS source to clients. In case of unicast distribution, a user periodically receives announcements relevant to its subscribed packages or channels from an announcement server, co-located with the MBS source. In both cases, either the multicast IP address of the announcement multicast group, or the IP address of the announcement server, is communicated to the client during his subscription to the relevant channel or package. After receiving an announcement, a user can join the multicast group (session join) relevant to the selected content and, after being authorized by the MBSC-SS, the multicast data transfer phase from the MBS source starts. Finally, if either a data stream ends or a user leaves the current session, the session leave signaling exchange closes the network bearers towards the specific subscriber and, if that user is the last one within an MBS zone, network resources are released.
To implement the aforementioned service phases, our proposal includes two main signaling flows: one for the login-subscription-announcement chain and one for the join/leave a multicast data session. In what follows, when we refer to user credentials, we assume that the considered user has already registered with the service provider prior to use the proposed MBS architecture.
In order to preserve generality, we keep client and WiMAX SU entities separated. For example, the SU could be the WiMAX interface of a vehicular gateway, and the client could run within a notebook/smartphone connected to the gateway through a WiFi connection). Clearly, in case of mobile WiMAX terminals, they are co-located. Note that being the MBSC-ETL entity part of the data plane it is not involved in the following signaling exchanges of the control plane.
3.1.1 Login, subscription, and announcement
In our solution, we have encapsulated signaling messages into the body of SIP Message requests. The reason of this approach is that SIP Message requests can be issued at any time and they do not require any SIP session to be established and managed by a signaling server, thus decreasing the overall MBSC-SS load. In addition, a SIP Message can contain different payload types, including contents encoded also in binary format and not only in the text-based format typical of SIP, even though the original design purpose of SIP messages was to carry instant messages in VoIP communications .
3.1.2 Session join/leave and session refresh
The signaling flow for a client joining or leaving an MBS session over WiMAX is shown in Figure 4. Before going into details, we point out that all the SIP protocol messages used in Figure 4 are SIP Message requests. For the sake of neatness, all SIP 200 OK responses are not shown in Figure 4.
In order to join a multicast group, the client becomes aware of the multicast address and port through the announcement phase and issues an unsolicited IGMP report. This report is forwarded by the SU to the BS, and from the BS to the closest multicast capable router which, in our scenario, is the ASN-GW. In order to optimize traffic delivery, the BS can "snoop" the IGMP report  and send it to the ASN-GW only. Once the latter receives the IGMP report, a new SIP Message request, called Join/Leave Request, is created and sent to the MBSC-SS. The message body of the Join/Leave request contains both user information and the IGMP report that has triggered it. The signaling server parses such an information and uses it to check whether the user is allowed to join the desired session. For example, the MBSC-SS can check on the MBSC-DB if the user has subscribed to that session. If the authorization check is successful, the MBSC-SS issues an MBS Context Request towards the ASN-GW in order to either trigger the creation of a new multicast context or reuse an already existing one for the new client. When the ASN-GW receives the MBS Context request, a message exchange between ASN-GW and BS is initiated through the R6 reference point. If this signaling exchange is successful, it triggers a BS-initiated three-way Dynamic Service Addition handshake, carried out at MAC layer, between the BS and the SU of the client. Once the multicast context is created, the BS notifies the ASN-GW by sending it another R6 message, called MBS Context Response. The ASN-GW, in turn, creates a SIP Message to notify the MBSC-SS that it can save the session information on the MBSC-DB.
The final step of the procedure consists of another SIP message, called Join/Leave Response, sent by the MBSC-SS to the client (see Figure 4), and used to notify it whether his request was successfully processed by the signaling entities. It is worth noting that this message is not mandatory, and could be avoided in order to save bandwidth, unless it is used to transport some information needed by the application to receive the content. For example, it could transport a cryptographic key needed by the client software to decode the streamed data, or custom data enabling more options for service providers, such as live advertisements or notifications. When the packets of the joined session are routed to the BS, they are delivered to the SU through the established multicast connection over the air.
When the client leaves the multicast group, the same signaling flow as shown in Figure 4 is triggered by sending an IGMP Leave message to the neighboring multicast router (ASN-GW). This signaling might cause the deletion of the over-the-air connection by means of BS-initiated Dynamic Service Deletion messages, transmitted on the Primary Management Connection of the MS/SS, if the leaving SU is the last multicast user for that multicast connection on the BS, and the consequent release of the unused wireless resources.
Another option consists of defining a timer inside the MBS client that sends unsolicited IGMP messages towards the ASN-GW. In this second case, the timer for the IGMP query sent by the ASN-GW could be relaxed or disabled at all, since clients autonomously refresh their status. It is easy to show that the second solution does not imply additional overhead with respect to the first one, which is analyzed in detail in the article. In this second option, when the ASN-GW receives the IGMP message, and encapsulates it inside the payload of a SIP message towards the MBSC-SS, it includes additional information such as the BS serving the MBS client, which, in turn, has an its own identifier. When this information is received by the MBSC-SS, it checks the data stored in the MBSC-DB to determine if the previous status of the MBS client is changed. This step allows the MBSC-SS to realize if the client has changed the serving BS, and thus to trigger, if necessary, a signaling procedure to update the system by using exactly the same messages already defined (i.e., MBS Context Req and MBS Context Res). Thus, this way of performing session refresh could allow an easy way to maintain active the multicast session in case of client mobility.
Differently from , where the BS infers its subordinate interest of SU in a multicast group from the MAC-layer management messages, in order to avoid periodic exchange of IGMP reports, we prefer to not include additional, mandatory functions in the BS. Thus, the IGMP exchange occurs on the wireless channel in a standard way, since the overhead of exchanging IGMP message is small (see Section 5.2).
If either a user leaves the session abnormally, thus without issuing an IGMP leave message, or the client software crashes, such a situation is handled at the MBSC-SS level. Within the signaling server, we have designed a further simple service, which periodically checks the MBSC-DB to make sure that there are no users with active sessions that have not been refreshed for more than a fixed amount of time. If it happens, the MBSC-SS issues an MBS Context Request that acts as an unsolicited, MBSC-SS-initiated leave procedure (see Figure 4). This periodical check is very useful to release resources on the wireless interface when the user that got stuck was the last one in his multicast session. A good choice for the value of this timer is an integer multiple of the IGMP refresh period (the default value is 125 s).
4. Prototype implementation
In this section, we illustrate the implementation of the testbed used for validating the proposed service architecture, in particular the end-to-end signaling architecture for MBS over WiMAX. Thus, we focus on the entities involved in the signaling process only and exclude those belonging to the data path, such as the MBSC-ETL, that has already been described in the literature [2, 14, 15].
The testbed has been designed to provide a multicast IPTV service as an instance of a typical MBS over WiMAX service. In what follows, "TV channel" and "multicast session" share the same meaning.
Five main entities are involved: MBSC-SS, which is the core of the proposed signaling service architecture, MBSC-DB, ASN-GW, client, and MBS Source.
The MBSC-SS is the key functional entity that orchestrates all the components used to enable, create, and manage the MBS IPTV streaming service. In order to fulfill the requirements illustrated in Section 2.3, the Mobicents JSLEE (MSLEE) has been selected to implement the central signaling server. It handles all the incoming SIP signaling messages from the MBS clients and the ASN-GW. In addition, it performs user authentication, service subscription, session join/leave, periodic check of active users, and their authorizations.
The MSLEE service, running in the same MBSC-SS where the signaling logic resides, has been implemented in a single SBB, called MessageSbb. As mentioned above, all the SIP sessions used in our architecture are stateless, differently from the typical INVITE-initiated VoIP call dialogs . Thus, the SBB has been configured to process all incoming SIP events fired by the SIP RA as a root SBB. Specifically, each incoming SIP request is processed by a different MessageSbb entity, which is identified by the Call-ID value of the originating SIP request. As a design choice, requests belonging to the same transaction (e.g., MBS Context REQ--RES) share the same Call-ID value and are processed by the same SBB entity, thus increasing the MSLEE efficiency.
The format of data encapsulated into the body part of the SIP Message requests is based on the Cisco® R6 interface , which consists of a set of control and bearer plane communication protocols between BS and ASN-GW . In short, in our implementation each data packet is encoded as a binary Type-Length-Value (TLV) data structure and located within the body field of a SIP Message request. After receiving such a request, the recipient replies with a final SIP response with an empty body (i.e., 200 OK) . The ASN-GW encapsulates the R6 message into the body of SIP Message requests. In this way, the modifications needed in the ASN-GW are marginal, since it only has to encapsulate the relevant R6 and IGMP protocol messages into a SIP message body. Thus, they affect the implementation effort and the complexity of the signaling architecture on the MBSC-SS only. If needed, given the SLEE flexibility and extendibility, the MBSC-SS can easily be modified, so as to support other R6 protocols, different from the Cisco® version.
The signaling management service runs on top of Mobicents JSLEE v.1.2.4.GA, which is executed in the JBoss AS v.4.2.2. The designed service makes an extensive use of the external database (MBSC-DB), hence the MySQL Connector/J v.5.1.6 JDBC, which is the official JDBC driver for MySQL, has been deployed onto JBoss and configured to access MBSC-DB from the MBSC-SS service class.
The MessageSbbclass has also been equipped with a management interface by means of a Management Bean (MBean) class called MessageSbbConfigurator (Figure 6). Through the management interface, an administrator can change configuration parameters of the MBS service at runtime without stopping or even pausing the JSLEE server. The MBean exploits the Java Management eXtension (JMX) interface provided by JBoss, thus the parameters are easily accessible through a simple JMX web interface.
All the service-related information, such as user subscription and registration data, channels, packages, and configuration variables, are stored and maintained in the MBSC-DB.
The MBSC-DB is implemented by a Linux box running the open source MySQL database server v.5.0.75 as our Data Base Management System (DBMS). This database stores user data, package composition, channel information, ongoing sessions, subscriptions, and scheduled streams by using different tables. Each table has been designed by optimizing the memory space occupied by each field. The database can be managed using, e.g., MySQL Administrator or the phpMyAdmin free software tool .
ASN-GW, which is placed at the edge of the ASN, is the entity that connects the ASN to the CSN. The ASN-GW assists mobility and security in the control plane and handles IP forwarding. In our architecture, the ASN-GW also connects the WiMAX entities with the MBS service entities. It translates the protocol messages from the R6 protocol to the SIP protocol.
The MSLEE server providing the MBSC-SS is then in charge of parsing and interpreting encapsulated data. Thus, the service running in the MSLEE is always aware of the protocol being used within the WiMAX network .
Given our focus on the IP part of the MBS signaling architecture, we treat the WiMAX network as a black box. Thus, mobility effects, modulation parameters, and wireless loss rates and retransmissions are not emulated by our WANE module and are not included in our performance evaluation results.
Finally, it is worth citing that we also executed functional tests of the overall system in the laboratories of a WiMAX manufacturer, running our software on a real ASN-GW, able to dialogite with real WiMAX BSs and our MBSC.
4.4 MBS software client
The MBS software client handles the signaling messages at the client side and provides a graphical user interface (GUI) of the implemented IPTV service. The system architecture that we have designed is modular and allows developers to implement an MBS client as both a standalone application and a Web 2.0 client.
The standalone version consists of a standard Java application using the open source JAIN SIP stack v.1.2  to enable SIP communication with the MBSC-SS. The same SIP stack is used also internally by the SIP RA in the MSLEE signaling server. The client is also equipped with a multimedia player compliant with the used multimedia flow formats and able to send the IGMP unsolicited report message to join a multicast group. The join message triggers all the signaling exchange described in Section 3.
In both standalone and web cases, the GUI displays user information about subscribed and available channels and packages, announcements, and multicast streaming contents.
4.5 MBS source
The MBS Source is one of the key entities for deploying an MBS over WiMAX architecture. Nonetheless, thanks to our modular architecture, the service administrator is allowed to select the technology that better fits his interests, without modifying the other service entities. In our IPTV experiment, this is achieved by isolating the actual streaming server technology from the service logic. The only requirement for the MBS Source is to support multicast streaming endpoints. We have used a simple VideoLAN client (VLC), running in server mode in a Linux machine, and configured some multicast endpoints to stream a sample video. Then, we have recorded the URLs of the created endpoints in the appropriate database table of the MBSC-DB. We have also created channel packages that the user can subscribe to, such as sport, movies, etc. Users can subscribe to packages and/or to a single channel. The MBS Source has also to create and send multicast announcement data on a dedicated multicast group when a standalone client is used. This is done by using the Session Announcement Protocol (SAP, ) functionality of the mini-SAP server bundled with the VLC software. On the other hand, if a Web 2.0 MBS client is used, then a Web server is also necessary. The Web server is used to provide users with the Web portal through which they can access the MBS Service. The Web server has been deployed by installing the open source LAMP (Linux Apache, MySQL, PHP) package on a Linux machine executing Ubuntu Server 9.1 x86. The Web portal also provides an administrative Web interface by which service providers can add, remove, and manage channels, users, and subscriptions. The Web server also dynamically creates and sends the unicast announcement data for the channels subscribed by a user. In this case, data are used to update the web page of the service with real-time information. In fact, each user, once subscribed and authorized by the MSLEE server, periodically polls the web server for announcements encoded as an RSS news file. The client GUI is then in charge of parsing XML files and visualizing data in a user-friendly way. Even if not implemented in our prototype yet, the web client could have the option of using multicast announcements distributed through the SAP protocol, as it happens in the standalone client approach.
5. Performance evaluation
In this section, we show the performance metrics used to evaluate the MBS signaling. A number of experiments have been realized by using the system testbed described in Section 4. For this purpose, we have deployed the Mobicents JAIN SIP RA v.1.2.4.GA in the MSLEE server that acts as MBSC-SS. We have optimized the SIP RA load by increasing the number of threads, in order to maximize the number of simultaneous processed events. During test execution, we have stopped recording logs in order to improve MSLEE and JBoss AS performance. For what concerns the operating system, we have used the 32-bit Ubuntu server 10.04, running in a virtual machine (VM) equipped by three CPU cores and 3 GB of RAM, and managed by the ESXi 4.1 VMWare hypervisor . The server running the hypervisor is equipped with a dual Intel Xeon E5410 with clock frequency equal to 2.33 GHz and 16 GB of RAM. The MSLEE has been configured with 2.5 GB Java heap, using the Parallel Garbage Collector scheme to periodically clean the memory allocated to the Java server. The choice of deploying the MBSC-SS in a VM allows using computing resources efficiently, implementing energy efficient policies, simplifying replication of ASs along with their failover management, and so on. An interesting reading about virtualization advantages can be found in . The DBMS has been deployed in a different VM having the same characteristics of the MBSC-SS VM and executed in the same server.
In our experiments, clients have been emulated by using the well-known SIPp traffic generator . This choice is due to the unavailability of high performance IGMP message generators. Thus, by using SIPp, the client generates SIP messages with the IGMP report information already encoded in the payload, thus emulating the output of the ASN-GW towards the MBSC-SS. In turn, the WANE has been modified with respect to its base version, in order to simply forward the SIPp-generated messages to the MBSC-SS, without modifying them. By using this configuration, we have collected significant statistics, such as the number of lost SIP messages and the signaling latency, by using the built-in logging capabilities of the SIPp. In particular, we have measured the throughput and latency of the core component of our architecture, the MBSC-SS. We have checked that the WANE was never the system performance bottleneck in our testbed implementation. In addition, we have measured the average signaling protocol overhead of each message exchanged between the MBS entities, and compared it with a typical IMS-based system. In all service lifecycle phases, per-user and per-BS frequency overhead have been evaluated. Finally, we have evaluated the maximum number of users that our testbed can support while keeping a good QoS level in terms of signaling latency and service availability. In particular, we consider a maximum tolerable channel switching time of 100 ms and service availability equal to, at least, 99%. As mentioned in Section 4.3, it is worth to remember that our focus is the performance of the IP part of the MBS signaling architecture, thus the WiMAX network may be simply regarded as a "black box" emulated by our WANE module.
5.1 Throughput and latency
We define a service transaction as the signaling exchange which starts with an IGMP message sent by the client, and ends when a SIP reply is sent by the MBSC-SS back to the client (see Figure 4). Therefore, this signaling exchange corresponds to a Join or a Leave operation. We use the service transaction as the basic message exchange to evaluate performance in terms of signaling throughput and latency. Since it is the most frequent and complex signaling exchange of our signaling architecture, it is a meaningful benchmark for evaluating the processing capability of the MBSC-SS. As for the service transaction latency, this is a significant parameter, since it represents the contribution of the core elements of the signaling architecture to the channel switching time. It is defined as the delay between the IGMP message generation (directly encapsulated within a SIP message) at the client side and the reception of the Join Response message.
The SIPp client, which emulates the MBS client, has been configured to generate SIP Messages according to a deterministic arrival process, at a fixed rate λ. Each test has been executed by using the same λ value for 60 min. Both TCP and UDP protocols have been used for transmitting SIP messages. In case of TCP usage, SIPp is configured to work in a mono socket mode.
In UDP, a packet lost in the internal queues of the JSLEE application server will always be retransmitted with increased timer value. Thus, overall throughput is much lower, but the decrease is smoother.
Consider also that the additional latency due to the over-the-air data transmission is not included in our tests, thus it is really important to keep the measured latency value as small as possible in order to have an acceptable service in operation.
By using the maximum throughput values, expressed in service transactions/s, obtained by using either TCP or UDP, we have calculated the maximum number of clients that our MBSC-SS can simultaneously support. We assume that all users are already logged in. This means that they need to issue one service transaction in order to be authorized to join the multicast data flow, an additional one to notify their intention to leave the multicast stream, and a number of service transactions are used to refresh the current multicast session, by answering the Query sent by the ASN-GW with an IGMP Join message (the relevant signaling exchange is shown in Figure 5). Clearly, in this case the only parameter that can influence the number of supported users is the IGMP query period value, since it determines the number of service transactions per user. Note that during a session refresh (see Figure 5), the number of SIP messages exchanged by the MBSC-SS is lower than those exchanged during a service transaction (see Figure 4). Thus, our evaluation is a lower bound of the real capacity of the proposed implementation of the signaling server.
Definition of symbols used in overhead formulas
Maximum number of service transactions per second supported by an MBSC-SS instance
Average multicast flow duration, expressed in seconds
IGMP timer value, in seconds, for queries refreshing membership to multicast groups transmitting data flows
IGMP timer value, expressed in seconds, for queries refreshing membership to multicast groups transmitting announcement data
SIP Registration expiration value, expressed in seconds
Number of service transactions per user needed to maintain the membership to a multicast data flow of duration FD
Number of available subscription packages (each one with likely more than one channel)
Maximum number of users receiving a multicast data flow supported by a MBSC-SS instance
Number of users served by a BS (or BS sector) on a single WiMAX channel
Overhead per user evaluated at the IP layer associated to a SIP registration
Overhead per user evaluated at the IP layer for maintaining the membership to Np multicast announcement groups (one for each subscribed package of TV channels)
Overhead per user evaluated at the IP layer for maintaining the membership to a multicast data flow
TCP connection setup/teardown overhead, expressed in bytes
In this evaluation, we have done the realistic assumption that each user joins only one multicast session. In addition, we have assumed that the ASN-GW sends Group-Specific multicast Queries, which are queries relevant to the membership to a single, specific multicast group . In this way, we avoid handling messages from users not involved in such a multicast group, i.e., in the specific case, from inactive users.
In the above evaluation, we have neglected the effect of the queries needed to maintain the membership to multicast groups used to transport announcement data. Clearly, this effect is present only when announcements are multi-casted. We suggest two possible approaches to take this effect into account and limit the performance penalty to a negligible level. The first one is to use an IGMPT2 timer value larger than IGMPT1 (e.g., 10 times larger), so as to have a lower rate, and thus a lower impact of the responses to queries on the signaling server. The other approach consists of both using IGMPT2 > > IGMPT1 and sending a General Query upon expiration of the IGMPT2 timer at ASN-GW. In this way, irrespective of the number of the multicast groups the client has joined, it will answer by means of a single Report message, listing all multicast groups . In both approaches, the additional resource consumption is negligible.
5.2 Signaling overhead
Message overhead by protocol layer (expressed in bytes)
8 (UDP), 20 (TCP)
348 (UDP), 360 (TCP)
8 (UDP), 20 (TCP)
478 (UDP), 490 (TCP)
Register w/auth data
8 (UDP), 20 (TCP)
528 (UDP), 540 (TCP)
8 (UDP), 20 (TCP)
278 (UDP), 290 (TCP)
8 (UDP), 20 (TCP)
378 (UDP), 390 (TCP)
8 (UDP), 20 (TCP)
378 (UDP), 390 (TCP)
8 (UDP), 20 (TCP)
378 (UDP), 290 (TCP)
8 (UDP), 20 (TCP)
378a (UDP), 390a (TCP)
8 (UDP), 20 (TCP)
388 (UDP), 400 (TCP)
MBS context req
MBS context res
Therefore, the total average amount of signaling overhead for a session setup is I r + Jreq + MCreq + MCres + Jres = 36 + 410 + 410 + 400 + 388 = 1644 bytes, plus any possible retransmissions when UDP is used to deliver SIP messages. If only TCP is used, there are no SIP retransmissions at the application layer, but the average overhead increases by 12 bytes per packet plus the TCP handshake overhead when the connection is not yet established. Note that only the first join and the final leave messages produce this amount of overhead, whereas the periodic join messages, triggered by the IGMP queries, used to refresh data or announcement multicast sessions, only use I q + I r + Jreq + Jres = 40 + 36 + 410 + 388 = 874 bytes (886 bytes in TCP) including the IGMP query sent by the ASN-GW.
Similarly, the registration process involves four different messages, even if their size depends on the type of security support implemented in the selected user authentication procedure. In fact, if public key encryption is used, then the size of the Register messages can increase significantly. Even though the registration could easily become the largest contribution to the signaling overhead, in an operational service scenario we believe that the session join and refresh exchanges are those to be kept under control in terms of size, latency, and rate. To this aim, we will refer to the quantities reported in Tables 1 and 2.
Since the wireless link is typically the bandwidth bottleneck, in what follows we analyze the overhead only in the radio interface.
The initial four quantities in Equation (3) are the size of the signaling messages used in the registration phase (see Table 2) and CTCP is the TCP connection setup and teardown contribution to the overhead (see Table 1).
where R t represents the expiration value of the SIP registration, which is typically equal to 3600 s, and ROH is the registration overhead calculated by Equation (3).
In fact, as shown in Figures 4 and 5, the announcement multicast session and the data multicast session are both joined and refreshed by similar procedures, which start with an IGMP message. Thus, each time they are performed, they produce the same amount of overhead on the wireless interface, even if membership refresh requires a lower number of signaling messages for the signaling server. Given the greater importance of data sessions queries than announcement ones,a two different IGMP query periods can be used in the ASN-GW, IGMPT1, and IGMPT2, which represent the refresh period of both the data and the announcement multicast sessions, respectively. Their values used in subsequent calculations are reported in Table 1. We have used a value for IGMPT2 10 times larger than the value of IGMPT1. These values can be adjusted for different multicast groups in the ASN-GW configuration, and the overhead rate can therefore be optimized.
By using the single user overhead rate, we can estimate the amount of aggregate overhead rate, consumed by a group of 200 users being served by a single MBS frequency under a single BS. We assume that each user is already registered and is watching a TV channel. In addition, all users are subscribed to N p = 20 different packages and receive the relevant announcement data.
where NBS is the number of users served by a single BS on an MBS frequency.
In Equations (9) and (10), we consider a single IGMP query triggering a number NBS of IGMP reports, as in the standard IGMP settings. This happens N p times in the case of announcements (we assume, as worst case, that all users subscribed all N p packages) and only once for the TV channel that the user is currently watching. Similar to Equations (6) and (7), also in Equations (9) and (10), we assume that the IGMP query periods of announcement multicast channels are longer than for those of normal data channels (IGMPT2 = 10 × IGMPT1).
The overall aggregate overhead rate for 200 users is then around 40 kbit/s for TCP and 28 kbit/s for UDP. If we consider that each announcement channel, using the SAP protocol, is limited to a maximum of 4 kbit/s , and that the streaming TV channel can easily use more than 1 Mbit/s, then the overall overhead percentage of our signaling architecture is very low. In more detail, assuming the worst case for the signaling overhead, in which 200 users subscribed to N p packages, all watching the same channel with a data rate equal to 500 kbit/s (e.g., low-quality video), the ratio between the maximum overhead (if TCP is used) and aggregate data rate is given by the ratio 40/500 = 0.08, without any compression. Clearly, this value is definitely affordable.
As already mentioned in Section 2, in the IMS-based architectures the use of the SIP INVITE message is mandatory to create a session state and to provide an IPTV service [18, 19, 22, 23]. Even other proposals  try to extend the IMS session setup for multipoint-to-multipoint service type, using again INVITE messages. Conversely, the signaling overhead of our architecture is significantly lower than that of an IMS-based one, due to the usage of simple Message requests. In , the overhead of the IMS architecture is analyzed together with the signaling latency, and in both cases our architecture proves to save bandwidth and provides lower latency values for initiating a service session.
5.3 A deployment scenario
The MBSC-SS is an AS and thus it is usually deployed on a cluster of servers in the CSN. It serves a number of ASN-GWs, each providing Internet connectivity to a set of BS. By using a cluster of servers in the MBSC-SS, critical situations, such as failures and overload, can easily be managed without compromising the user's perceived grade of service. Moreover, it is also possible to increase throughput and decrease latency by using different small servers in parallel rather than using a single powerful node processing all messages. In fact, recent studies (see  and references therein) show that Java-based ASs, especially SIP servers, perform better if they are executed in a VM with a limited number of CPU cores (e.g., two or three CPU cores), and scalability is efficiently obtained by deploying multiple VMs on the same physical server, each one hosting a replica of the AS. In this deployment, the entry point of all SIP signaling messages in the MBSC-SS is a SIP proxy load balancer, in charge of dispatching SIP messages among AS replicas. This task can easily be accomplished by using a SIP proxy such as SIP Express Router, which can provide high throughput also on low end hardware . In addition, it can also act as a SIP registrar during the registration phase of the service .
In a cluster scenario, like the one shown in Figure 13, the session-oriented nature of SIP has important implications for load balancing. In a typical VoIP scenario, all transactions relevant to the same call must be routed to the same server; otherwise, the server will not recognize the call. Session-aware request assignment is the process through which a system allocates requests to servers such that sessions are properly recognized by that server, and subsequent requests, corresponding to the same session, are allocated to the same server . In our case, in which no SIP INVITEs are used, there is no need of complex algorithms. On the contrary, a simple static approach to load balancing (such as a call-id hash algorithm ) is enough to ensure that messages with the same call-id, hence belonging to the same MBS service transaction (as defined in Section 5.1), are routed to the same server within the cluster. In addition, when the MBS service transaction (e.g., the Join procedure) is completed, in our architecture any future update of the user state can be processed by another replica of the MBSC-SS, since the session status of each user is stored in the DB. This allows managing computing resources very efficiently by employing simple load-balancing and failover techniques, since ASs do not have to maintain session states and can be powered off without any problem.
For what concerns the use of UDP or TCP for exchanging SIP messages, the best solution is to use UDP between the MBS clients and the SIP load balancer, so as to minimize the overhead on the wireless interface, and to use TCP for all other exchanges, that is between the ASN-GW and the SIP load balancer and between the SIP load balancer and the MSLEE instances (see Figure 13). In this way, it is possible to maximize the achievable throughput and to control the system latency.
Finally, we point out that the solution proposed, although based on Java, has not been tailored exclusively to the JAIN SLEE service framework. In fact, another very interesting approach to the deployment of our MBSC-SS entails the usage of the Java-based NSF NetServ in network container . By using NetServ, a dynamic approach, in which MBSC-SS replicas can be created and installed closer to the ASN-GW lowering signaling latencies and dynamically adapting the number of servers to the load, is made possible with no significant development effort.
In this article, we have illustrated the novel design and implementation of a modular, open source, and IP-based MBS over WiMAX service signaling architecture. The modularity of the proposed architecture allows service providers to select the best technology for each service entity without any need of modifying the other service entities or the signaling interfaces. The presented service architecture is service independent, and allows creating services such as file-casting, media streaming, mass software updates, and data push services without any need of modifying the signaling messages or network entities. Any change of the service type requires only the change of the user GUI of the MBS client and the MBS source content provider technology, both outside the core network elements.
Being full IP-based, our service architecture is independent from the access network technology, thus it is possible to extend it to other fixed or mobile access networks beyond WiMAX.
The signaling messages exchanged between system entities are based on encoded binary data encapsulated within the payload of SIP messages. In the proposed solution, we have chosen to shift implementation complexity from the ASN-GW towards the JSLEE server orchestrating all signaling. Thanks to the open nature of the JSLEE specifications and the Java capability to ease the development process of telecommunication services, our approach allows supporting a number of different vendors/protocols without major changes.
To test the performance of the service architecture, we have focused on the non-trivial case of a multicast IPTV service offered through an MBS over WiMAX architecture. The signaling server has been implemented by using a single service building block deployed over the open source Mobicents JSLEE server. Also the other signaling entities have been implemented by using open source technologies, thus reducing costs and leveraging the community of developers. Our results show that a simple virtual machine hosting the MBSC signaling server, which can be regarded as a common mid-level machine in terms of memory size and CPU processing power can provide up to 210 service transaction/s (and thus supporting tens of thousands of users) and a signaling latency as low as 100 ms when the TCP transport protocol is used by the MBSC-SS.
Although the experiments shown in this article and in some referenced articles are quite different, it could be interesting to compare session set-up times reported by Munir and Gordon-Ross  (well above 1 s in the best case) and our switching time (below 100 ms by using TCP as transport protocol). This should be enough to show an order of magnitude on the advantage of deploying our system with respect to IMS-based ones, which are much more complex. As for the comparison with other MBS systems, let us consider the one defined for the UMTS illustrated in . Comparing that proposal with our solution, two differences emerge. The first is that the solution proposed in  is tailored exclusively to the UMTS system, whereas our proposal is quite general and could be adapted to other systems with minimal software changes in the MBSC-SS service logic, maintaining the same protocols. The second is that, analyzing the complexity of the signaling exchange, our solution is definitely simpler.
A future work goal is the definition of a standard high level interface to be used between the ASN-GW and the MBSC-SS based on the emerging Open WiMAX standard . Using such a standard interface, the JSLEE service logic becomes independent from the specific protocol implementation used in the WiMAX network, and thus portable over different vendor devices.
aAs explained in last part of Section 3.1.2, missing replies to IGMP query refresh messages could cause service interruption, thus IGMP queries relevant to data sessions are much more important than those relevant to announcements.
- Mobile WiMAX--Part I: A Technical Overview and Performance Evaluation[http://www.wimaxforum.org/technology/downloads/Mobile_WiMAX_Part1_Overview_and_Performance.pdf]
- Jiang T, Xiang W: Multicast broadcast services support in OFDMA-based WiMAX system. IEEE Commun Mag 2007, 45(8):78-86.View ArticleGoogle Scholar
- WiMAX Forum, WiMAX end-to-end network systems architecture, Stage 2: architecture tenets, reference model and reference points2006. [http://www.wimaxforum.org/]
- Rosenberg J, Schulzrinne H, Camarillo G, Johnston A, Peterson J, Sparks R, Handley M, Schooler E: SIP: session initiation protocol. IETF RFC 3261 2002.Google Scholar
- Cain B, Deering S, Kouvelas I, Fenner B, Thyagarajan A: Internet group management protocol, Version 3. IETF RFC 3376 2002.Google Scholar
- Mobicents Web Site[http://www.mobicents.org]
- JSR 240, JAIN SLEE v1.1. Web Site[http://jcp.org/en/jsr/detail?id=240]
- Boss JWeb Site, available at: www.jboss.com
- Etemad K, Wang L: Multicast and broadcast multimedia services in mobile WiMAX networks. IEEE Commun Mag 2009, 47(10):84-91.View ArticleGoogle Scholar
- 3GPP TS 22.146. Multimedia Broadcast/Multicast Service (MBMS); Stage 1 (Release 9)Google Scholar
- IEEE 802.16-2009, IEEE Standard for Local and metropolitan area networks, Part 16: Air Interface for Broadband Wireless Access Systems 2009.Google Scholar
- WiMAX Forum, Mobile WiMAX--Part II: A Comparative Analysis2006. [http://www.wimaxforum.org/]
- Bhatnagar S: Multicast data delivery in WiMAX by reusing L2 handoff procedure. Annu Rev Commun 2008, 61: 277-283.Google Scholar
- Wang J, Venkatachalam M, Fang Y: System architecture and cross-layer optimization of video broadcast over WiMAX. IEEE J Sel Areas Commun 2007, 25(4):712-723.View ArticleGoogle Scholar
- Lee JM, Park H-J, Choi SG, Choi JK: Adaptive hybrid transmission mechanism for on-demand mobile IPTV over WiMAX. IEEE Trans Broadcast 2009, 55(2):468-477.View ArticleGoogle Scholar
- Lee JH, Kwon TT, Choi Y, Pack S: Location management area (LMA)-based MBS handover in mobile WiMAX systems. In IEEE International Conference on Communications System Software and Middleware (COMSWARE) 2008. Bangalore, India; 2008:341-348.Google Scholar
- Liao N, Shi Y, Chen J, Li J: Optimized multicast service management in a mobile WiMAX TV system. In 6th IEEE CCNC. Las Vegas, NV (USA); 2009:1-5. February 2009Google Scholar
- Riede C, Al-Hezmi A, Magedanz T: Session and media signaling for IPTV via IMS. In Mobilware '08. Innsbruck, Austria; 2008.Google Scholar
- Mikoczy E, Sivchenko D, Xu B, Rakocevic V: IMS based IPTV services--architecture and implementation. In ACM MobiMedia'07. Nafpaktos, Greece, August; 2007.Google Scholar
- ETSI ES 282 007. Telecommunications and Internet converged services and protocols for advanced networking (TISPAN); IP multimedia subsystem (IMS); functional architecture, V2.0.0, 2008-05 2008.Google Scholar
- Vidal I, Garcia-Reinoso J, Soto I, Valera F: Evaluating extensions to IMS session setup for multicast-based many-to-many services. Comput Netw 2011, 55(3):600-621. 10.1016/j.comnet.2010.09.011View ArticleGoogle Scholar
- Riede C, Friederich O, Seeliger R, Arbanowski S: Interactive IMS-based IPTV--plunge into the reality game show. In IEEE IMSAA 2008. Bangalore, India; 2008:1-6.Google Scholar
- Hung N, Thanh N: Intelligent features for IMS-based IPTV. In IEEE ATNAC 2010. Auckland, New Zealand; 2010:130-134.Google Scholar
- Xiao Y, Du X, Zhang J, Hu F, Guizani S: Internet protocol television (IPTV): the killer application for the next-generation Internet. IEEE Commun Mag 2007, 126-134.Google Scholar
- Kellokoski J, Tukia E, Wallenius E, Hamalainen T, Naarmala J: Registration performance comparison between IP multimedia subsystem and session initiation protocol networks. In International Congress on Ultra Modern Telecommunications and Control Systems and Workshops (ICUMT), 2010. Moscow, Russia; 2010:20-25. 18-20Google Scholar
- Lloret J, Garcia M, Atenas M, Canovas A: A QoE management system to improve the IPTV network. Int J Commun Syst 2011, 24(1):118-138. 10.1002/dac.1145View ArticleGoogle Scholar
- Di Sorte D, Femminella M, Reali G: A QoS index for IP services to effectively support usage-based charging. IEEE Commun Lett 2004, 8(11):686-688. 10.1109/LCOMM.2004.837661View ArticleGoogle Scholar
- Campbell B, Rosenberg J, Schulzrinne H, Huitema C, Gurle D: Session initiation protocol (SIP) extension for instant messaging. IETF RFC 3428 2002.Google Scholar
- Munir A, Gordon-Ross A: SIP-based IMS signaling analysis for WiMAX-3G interworking architectures. IEEE Trans Mob Comput 2010, 9(5):733-750.View ArticleGoogle Scholar
- Christensen M, Kimball K, Solensky F: Considerations for Internet group management protocol (IGMP) and multicast listener discovery (MLD) snooping switches. IETF RFC 4541 2006.Google Scholar
- Femminella M, Francescangeli R, Giacinti F, Maccherani E, Parisi A, Reali G: Scalability and performance evaluation of a JAIN SLEE-based platform for VoIP services. ITC-21 Paris, France; 2009.Google Scholar
- Cisco Broadband Wireless Gateway[http://www.cisco.com/en/US/prod/collateral/wireless/wirelssw/ps8738/product_data_sheet0900aecd806cdb72.html]
- Li B, Qin Y, Low CP, Gwee CL: A survey on Mobile WiMAX. IEEE Communications Magazine 2007, 45(12):70-75.View ArticleGoogle Scholar
- phpMyAdmin web page[http://www.phpmyadmin.net/home_page/index.php]
- JAIN SIP stack Web Site[http://jsip.java.net]
- Handley M, Perkins C, Whelan E: Session announcement protocol. IETF RFC 2974 2000.Google Scholar
- VMware ESXi Web Site[http://www.vmware.com/products/esxi/]
- Singh A: An introduction to virtualization.2004. [http://www.kernelthread.com/publications/virtualization/]Google Scholar
- SIPp Traffic Generator[http://sipp.sourceforge.net/]
- Pareit D, Deruyck M, Tangle E, Joseph W, Moerman I, Martens L, Demeester P: Detailed modeling of MAC throughput and ranges for mobile WiMAX. IEEE Commun Lett 2011, 158(8):839-841.View ArticleGoogle Scholar
- Femminella M, Maccherani E, Reali G: Performance management of java-based SIP application servers. In IEEE/IFIP IM'11. Dublin, Ireland; 2011:493-500. 23-27Google Scholar
- Nahum EM, Tracey J, Wright CP: Evaluating SIP proxy server performance. In NOSSDAV '07. Urbana, IL; 2007.Google Scholar
- Jiang H, Iyengar A, Nahum E, Segmuller W, Tantawi A, Wright CP: Load balancing for SIP server clusters. In IEEE INFOCOM 2009. Rio de Janeiro, Brazil; 2009:2286-2294. 19-25Google Scholar
- Femminella M, Francescangeli R, Reali G, Lee J, Schulzrinne H: An enabling platform for autonomic management of the future internet. IEEE Netw 2011, 25(6):24-32.View ArticleGoogle Scholar
- Xylomenos G, Vogkas V, Thanos G: The multimedia broadcast/multicast service. Wirel Commun Mob Comput 2008, 8(2):255-265. 10.1002/wcm.463View ArticleGoogle Scholar
- Open WiMAX whitepaper, The disruptive approach of open WiMAX[http://www.wimax-industry.com/sp/wcm/avr/dl/wp/Disruptive_Approach_wp.pdf]
This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.