(5) Assuming a QSTA i having n i active TSs is selected for polling, the scheduler calculates the TXOP duration TD i , in three steps: (a) First, for every TS ij of QSTA i ðj ¼ 1 n i Þ, the scheduler calculates TD ij , as the maximum of (i) the time required to accommodate the pending traffic, as indicated by the queue size of that TS ðQS ij Þ, plus any overheads and, (ii) mTD ij , to ensure that the assigned TXOP will have at least the minimum duration: TD ij ¼ max QS ij R ij þ O; mTD ij  : ð7:11Þ In the special case where QS ij is equal to zero, TD ij is set equal to the time for the transmission of a Null-Data MSDU, to allow QSTA i to update the queue size information for TS ij . (b) TD i for QSTA i is calculated as the sum of all TD ij : TD i ¼ X n i j¼1 TD ij : ð7:12Þ (c) Finally TD i obtained from (7.12) is compared with the current TXOP Timer value T i , to ensure conforming traffic: TD i ¼ minðTD i ; T i Þ: ð7:13Þ (6) After the scheduler assigns the TXOP, it reduces the respective TXOP timer value accordingly and returns to step 1: T i ¼ T i À TD i : ð7:14Þ Although the above calculations are considered simple enough to be executed at the beginning of an idle slot, it is possible in most cases to execute steps 2–5 in parallel with step 1, while waiting for the channel to become idle, provided that the QSTA currently transmitting is not eligible for the next poll (e.g., it does not satisfy (7.10)). The exploitation of queue size information for calculating accurate TXOP durations is particularly effective for both Constant Bit Rate (CBR) and Variable Bit Rate (VBR) traffic, but introduces some extra delay and increases the transmission overhead percentage. For VBR traffic this seems to be unavoidable, since its behaviour cannot be accurately predicted. On the other hand, due to its periodic nature, CBR traffic has a much more predictable behaviour. An enhanced version of ARROW scheduler can take advantage of this characteristic to reduce overhead and delays. To differentiate the two versions of the algorithm, we refer to ‘ basic ARROW’ and ‘enhanced ARROW’. The idea behind the enhancement is that, instead of waiting for the QS information or use Null-Data TXOPs to get the current queue size, the scheduler can estimate the current queue size of a CBR TS. Every time a TXOP is assigned to a QSTA with CBR TSs, the scheduler calculates the TXOP duration for each of these TSs by adding the queue size value, indicated by the previous MSDU transmission of the same TS, and the estimated (using Mean Data Rate) generated traffic in the time interval between the previous and the current transmission. Accordingly, for CBR TSs Equation (7.11) can be replaced by: TD ij ¼ max QS ij þ  ij t Àt 0  R ij þ O; mTD ij 0 @ 1 A : ð7:15Þ In a fully synchronized system, the use of QS ij in Equation (7.15) would not be required, as it should always be equal to zero (the queue would be emptied in every transmission). Nevertheless, it is used at 210 QoS Provision in Wireless Multimedia Networks no expense to cover cases when, for example, a MSDU generation is delayed for some reason (e.g., high computing load), and misses the scheduled TXOP. Assuming a CBR TS in Figure 7.6, the duration of TXOP i ðx þ 1Þ is calculated based on the QS i ðxÞ and the estimation for the generated MSDUs within the interval ½tðxÞ; tðx þ1Þ. This estimation is very accurate for CBR TSs, leading to considerably lower transmission delays, since the MSDUs generated in the interval ½tðxÞ; tðx þ1Þ are transmitted at tðx þ1Þ, instead of tðx þ 2Þ with basic ARROW. This strategy also reduces transmission overheads and leads to lower average channel occupancy (i.e., better channel utilization) since, by picking a suitable value for mSI i , adequate for the generation of at least one MSDU, no Null-Data TXOPs for CBR TSs are required. To show how traffic scheduling can affect the performance of 802.11e, simulation results from the comparison of Simple, SETT-EDD, basic ARROW and enhanced ARROW are presented below. The simulation scenarios considered an increasing number of QSTAs attached to an AP. All QSTAs and the AP were supporting the extended MAC layer specified in IEEE 802.11e [17] and the PHY layer specified in IEEE 802.11g [18], with a transmission rate of 12 Mbps. An ideal, error-free wireless channel was assumed, as the focus was on the scheduling procedure. In order to investigate the limits and the maximum scheduling capability of each algorithm under heavy traffic conditions, no admission control was applied. Additionally, no minimum fraction of time for the operation of EDCA was reserved (i.e., the whole Beacon Interval could be utilized by HCCA) to focus solely on the performance of the HCCA mechanism. Each QSTA had two active sessions: (1) a bi-directional G.711 voice session (CBR traffic), mapped into two TSs (one per direction), and (2) an uplink (from QSTA to AP) H.261 video session at 256 Kbps (VBR traffic), mapped into one uplink TS. Figure 7.7 depicts throughput of non-delayed MSDUs for voice and video traffic. For voice traffic (Figure 7.7(a)), basic ARROW accommodates up to 18 QSTAs, while SETT-EDD can manage up to 14 QSTAs and Simple up to only 7 QSTAs. Using the enhancement, the number of QSTAs can be increased to 19 with enhanced ARROW. For video traffic (Figure 7.7(b)), basic and enhanced ARROW outperform both SETT-EDD and Simple, accommodating up to 19 QSTAs, as opposed to 13 with SETT-EDD and 6 with Simple. The main reason for the considerably improved performance of basic ARROW is the accurate TXOP assignment it performs, as a result of the accurate queue size information. This is also shown in more detail later in this section. As for the enhanced ARROW, it appears that the admission capacity limit of the Scheduler compared with the Standard ARROW for Voice traffic is somewhat increased since, with Enhanced ARROW up to 19 G.711 TSs can be accommodated comfortably. It is interesting to observe that throughput of SETT-EDD and ARROW (both basic and enhanced) reduces rapidly immediately after reaching its maximum value. The reason is that, due to the dynamic TXOP assignment performed by these algorithms, new TSs entering the system can participate equally in the channel assignment. Thus, when the scheduler exceeds its maximum scheduling capability, service for all TSs is degraded abruptly. The Simple Scheduler on the other hand, manages to provide a stable throughput regardless of the offered load, because static allocations for existing TSs are not affected as the traffic load increases. This effect highlights the need for an effective admission control scheme for SETT-EDD and ARROW, which would prevent the offered load from exceeding the maximum scheduling capability. In Figure 7.8, the mean delay for non-delayed voice and video MSDUs is shown. For voice traffic (Figure 7.8(a)), both Simple and SETT-EDD perform better than basic ARROW, since they are able to perform a fairly accurate estimation of expected CBR traffic. But enhanced ARROW achieves considerable improved delays, comparable to both Simple and SETT-EDD, as a direct effect of the incorporation of the traffic load prediction for CBR traffic. For video traffic (Figure 7.8(b)), Simple achieves a low and almost stable mean delay, but suffers from the considerable low number of accommodated QSTAs, as shown earlier in Figure 7.7(b). The improved delay of basic ARROW QoS in WLANs 211 compared with SETT-EDD shows that the extra scheduling delay introduced by ARROW is balanced by the accurate TXOP assignment. With the enhanced version of ARROW, the mean delay for video traffic is the same as with basic ARROW for low traffic loads (up to seven QSTAs), but for higher traffic loads the delay is somewhat increased. This occurs because of the use of the estimation mechanism that eliminates the need for Null-Data TXOPs for CBR traffic and results in the allocation of larger TXOPs for voice traffic, compared with basic ARROW. This delays the TXOP allocation for video MSDUs and increases their mean delay in heavy traffic conditions. But, in any case, the transmissions are within the delay bounds of video traffic. G.711 Non-Delayed MSDU Throughput 0 500 1000 1500 2000 2500 3000 3500 1 3 5 7 9 1113151719 QSTAs Throughput (Kbps) Simple SETT-EDD ARROW ARROW Enhanced Offered Load (a) G.711 Vo ice H.261 Non-Delayed MSDU Throughput 0 1000 2000 3000 4000 5000 6000 1234567891011121314151617181920 QSTAs Throughput (Kbps) Simple SETT-EDD ARROW ARROW Enhanced Offered Load (b) H.261 video Figure 7.7 Throughput of non-delayed MSDUs. 212 QoS Provision in Wireless Multimedia Networks 7.3 RSVP over Wireless Networks QoS provision is considered today as one of the basic requirements for next generation networks. These networks are expected to integrate a large number of access systems, both wired and wireless, in one common core, and rely on the Internet Protocol (IP) for data exchange. The IP protocol, up to its current version 4, was designed for applications with low network requirements, such as e-mail and ftp, and accordingly offers an unreliable service that is subject to packet loss, reordering, packet duplication and unbounded delays. The expected new version 6 of IP provides some means for QoS support, but it still G.711 Mean Delay of ND MSDUs 0 5 10 15 20 25 30 35 40 45 1 3 5 7 9 11 13 15 17 19 QSTAs Mean Delay (ms) Simple SETT-EDD ARROW ARROW Enhanced (a) G.711 voice H. 261 Mean Delay of Non-Delayed MSDUs 0 5 10 15 20 25 30 35 1234567891011121314151617181920 QSTA s Mean Delay (ms) Simple SETT-EDD ARROW ARROW Enhanced (b) H.261 video Figure 7.8 Mean delay of non-delayed MSDUs. RSVP over Wireless Networks 213 needs supporting mechanisms to provide guaranteed service. To treat the problem of QoS in IP networks, the Internet Engineering Task Force (IETF) has introduced two main frameworks, namely the Integrated Services (IntServ) [1] and the Differentiated Services (DiffServ) [18]. DiffServ classifies and possibly conditions the traffic, in order to ensure similar behaviour throughout the network. It performs well in core networks, due to its scalability to support large numbers of flows. IntServ on the other hand, is targeted mainly for the access systems, by providing means to request and obtain end-to-end QoS per flow. As already mentioned, the Resource Reservation Protocol (RSVP) [2] is considered the most popular signaling protocol in IntServ for requesting QoS per flow, and setting up reservations end-to-end upon admission. A static resource reservation based approach (such as RSVP) performs well in fixed networks where links are stable, but exhibits low performance in a variable bandwidth environment. RSVP assumes a stable given overall bandwidth per link, that can be distributed to different active flows, based on their requirements. When a new flow requests admission, RSVP is used to check if the overall bandwidth per link is sufficient for all (active and new) flows. If the result of this check is positive, the new flow can be accepted. But if the available bandwidth is reduced after admission control (as can be the case in wireless links), the network may not be able to meet commitments for flows that have been successfully admitted. In this case, none of the flows operates according to its requirements, while the QoS observed by the user can be poor. A number of solutions can be found in the literature, addressing this problem. For example, dynamic RSVP (dRSVP) [19] uses ranges of traffic flows specifications, instead of absolute values. The benefit is that intermediate nodes can adjust allocations, as long as these are within the specified ranges, depending on changes of the available bandwidth in the output links. As expected, dRSVP introduces a number of extensions/modifications of dRSVP, compared with the standard RSVP as listed below.  An additional flow specification object (FLOWSPEC) in RESV messages and an additional traffic specification object (SENDER TSPEC) in PATH messages have been introduced, so as to describe ranges of traffic flows.  A measurement specification object (MSPEC) has been added in the RESV messages, used to allow nodes to learn about downstream resource bottlenecks.  A measurement specification object (SENDER MSPEC) has been introduced in the PATH messages, used to allow nodes to learn about upstream resource bottlenecks.  An admission control process has been added, able to handle ranges of required bandwidth.  A bandwidth allocation algorithm has been introduced that divides the available bandwidth among admitted flows, taking into account the desired range for each flow, as well as any upstream or downstream bottlenecks. Measurements presented in [19] have shown that dRSVP can significantly improve the performance of RSVP over wireless. Nevertheless, as listed above, it introduces a number of enhancements to the standard protocol. Another solution that does not introduce changes to the protocol operation is to detect the instances where the overall bandwidth is reduced below the required limit and reject a number of flows in order to allow the rest to operate as required. The question is how many and which in particular should be rejected, to cause as little inconvenience to the users and the network as possible. Below, we present such a mechanism for fair and efficient flow rejection. More information on this mechanism can be found in [20]. The presented flow rejection mechanism can operate at a central point of the wireless link (e.g., the Access Point of a cell), where it can observe the overall provided bandwidth. When the provided bandwidth falls to a level that is insufficient for maintaining the reserved bandwidth values for all flows, one or more flows must be rejected, in order to maintain committed values for the rest. This can occur in two cases. 214 QoS Provision in Wireless Multimedia Networks (1) When a new flow requests admission. If bandwidth is insufficient, the admission control will not allow the new flow to be accepted. (2) When the overall available bandwidth is decreased to a point that the requested bandwidth per flow cannot be maintained for all flows. In this case, one or more of the flows have to be rejected, in order to maintain the reserved bandwidth for the rest of the flows within limits. Flow rejection can be performed through standard RSVP signaling (RESV_Tear, PATH_Tear). A simple mechanism can be used that rejects flows randomly until the total requested bandwidth is reduced below the available capacity. This can lead to low efficiency, in terms of flow rejection probability and bandwidth utilization, as it might tear down:  more flows than necessary (this can happen when a large number of flows with low bandwidth requirements is randomly selected for rejection, instead of a smaller number of high bandwidth flows),  high priority flows (if the mechanism does not differentiate the flows, based on their importance, it can reject high priority instead of low priority flows), or  flows that utilize a large portion of the available bandwidth (this could lead to low bandwidth utilization). Below, a more efficient flow rejection mechanism is presented, which attains a considerably improved flow rejection probability. In this, three criteria are considered for providing fair and efficient rejection. (1) Reject the lower priority flows first. In order to achieve this, a scheme is needed that classifies flows into a number of priority classes. The priority classes may be defined according to a number of criteria, such as the flow type, traffic characteristics, QoS requirements, etc. In its simplest form, the classification scheme can use the transport-layer protocol type included in every session identifica- tion triplet to classify flows. For example, UDP flows can be considered as high priority, as they usually carry real time data, while TCP flows can be considered as low priority. (2) Minimize the number of rejected flows. If there are more that one set of flows that can be rejected, then the set with the fewer members (i.e., flows) should be selected for rejection. This criterion prevents one from rejecting a large number of low bandwidth flows. (3) Prevent underutilization. This could happen if the mechanism chose to reject flows with large bandwidth requirements. Accordingly, the mechanism should reject a set of flows that leaves a total required bandwidth lower than but as close to the available capacity as possible. More specifically, the mechanism takes effect when the available bandwidth of the wireless link falls below the total required bandwidth of all flows. Assuming an ascending list of flows ff i;1 ; f i;2 ; ; f i;n g in each priority class C i , according to their bandwidth requirements, the mechanism starts with the first flow f 1;1 of the lowest priority list C 1 , and checks if, by rejecting it, the total required bandwidth falls below the available. It continues traversing the list until: (1) either such a flow is found, or, (2) the end of the list is reached. In case (1), it rejects the flow and stops, since the total required bandwidth is below the available. In case (2), it rejects the last flow of the list f 1;n (the one with the maximum bandwidth reservations in the list) and starts over from the beginning of the list. If all of the flows in the list are rejected (i.e., all the flows of the particular priority class), it continues with the flows of the next higher priority class C 2 , and so on, until the total required bandwidth falls below the available, or until all flows have been rejected. RSVP over Wireless Networks 215 Below, the results of a comparison between the previously presented mechanism and a random rejection mechanism are presented, based on a simulation model with the following characteristics. (1) Flows belong to two different priority classes, C 1 ¼ Low and C 2 ¼ High, although the mechanism can work with any number. The mechanism starts dropping flows belonging to priority class Low, as previously described in detail. (2) Each priority class includes a mix of flow types with different bandwidth requirements, assuming that the type of a flow is an independent discrete random variable. (3) The number of active flows is not constant. In each class, flows arrive according to an independent Poisson process. Flow durations are assumed to be exponential independent random variables. (4) The channel can be found in two states, ‘good’ or ‘bad’, offering two levels of finite bandwidth. The time the channel stays in each state is an exponential random variable, thus the channel can be modeled as a two state Markov chain. (5) New flows are not allowed to enter the system when bandwidth is insufficient to satisfy the requirements of all (existing and new) flows. Two simulation scenarios were considered, where flows in each class were generated as in Table 7.1. As can be observed, the flow mix included a large number of ‘light’ flows and a smaller number of ‘heavy’ flows. To experiment with different conditions, we used different channel capacities and flow interarrival times per class. In both scenarios, the rejection probability per class was measured, defined as the average number of flows dropped divided by the total number of flows in the class. Scenario 1 Here, a low capacity channel was considered, with bandwidth equal to 600 and 400 while in the ‘good’ and ‘bad’ state, respectively. The mean dwell times in each state were 8 and 1, respectively. The mean flow duration was equal to 4 for all flows, while six experiments were performed with different interarrival times per class in the range [0.012, 0.040]. As can be seen in Figure 7.9, the proposed mechanism attains lower overall rejection probability in all experiments, while for the high priority class the performance is significantly improved. The increased rejection probability for the low priority class is considered acceptable, since this class is destined mostly for best-effort flows. Scenario 2 In this scenario, the channel capacity was increased by a factor of 4 (Good ¼2400, Bad ¼ 1600), while the range of interarrival times was decreased by the same factor ([0,003, 0,009]), resulting in a considerably larger number of active flows. The mean time per channel state and the mean flow duration were as in Scenario 1. Six experiments were performed with different interarrival times per class, and the results are presented in Figure 7.10. Again, the overall rejection probability is improved significantly, especially for large values of the interarrival time. The rejection probability for the high priority class is much lower than the corresponding mean value of the randomly rejection mechanism. Table 7.1 Different bandwidth requirements per class Flow types Bandwidth requirements Probability 1 0.5 0.6 2 2 0.25 3 5 0.1 4 10 0.05 216 QoS Provision in Wireless Multimedia Networks In both scenarios, the channel utilization of the proposed mechanism was equal or slightly improved than that for the random rejection mechanism, indicating that the proposed mechanism manages to reduce the flow rejection probability without decreasing the bandwidth utilization. 7.4 QoS in Hybrid 3G/WLAN Networks b The interworking between 3G cellular and Wireless Local Area Networks (WLANs) has been considered as a suitable and viable evolution path towards the next generation of wireless networks. 3 4 5 6 7 8 9 10 x 10 -3 10 -3 10 -2 10 -1 10 0 Mean Interarrival Time Dropping Probability High Offered Traffic Scenario o - Class 2 x - Class 1 Original - (Square) Proposed - (Diamond) Figure 7.10 Rejection probability vs. mean interarrival time (high offered traffic scenario). b Parts of the following sections have been published in [34]. 0.01 0.015 0.02 0.025 0.03 0.035 0.04 10 -4 10 -3 10 -2 10 -1 10 0 Mean Interarrival Time Dropping Probability Low Offered Traffic Scenario o-Class2 x-Class1 Original - (Square) Proposed - (Diamond) Figure 7.9 Rejection probability vs. mean interarrival time (low offered traffic scenario). QoS in Hybrid 3G/WLAN Networks 217 Yet this interworking raises considerable challenges, especially when we demand seamless continuity of multimedia sessions across the two networks. To deal with these challenges several 3G/WLAN interworking requirements need to be identified and fulfilled. Typically, the 3G/WLAN interworking requirements are specified and categorized in terms of several usage scenarios [22, 23]. For example, a common usage scenario is when a 3G subscriber is admitted to a WLAN environment by re-using his regular 3G credentials, and then obtains an IP connectivity service (e.g., access to the Internet). In this case, the interworking requirements include support of 3G- based access control, signaling between the WLAN and the 3G network for Authentication, Authoriza- tion and Accounting (AAA) purposes, etc. Other scenarios can call for more demanding interworking requirements. We may envisage, for instance, a scenario in which a 3G subscriber initiates a video session in his home 3G network and subsequently transits to a WLAN environment, wherein the video session is continued seamlessly, i.e., without any noticeable change to the quality of service (QoS). In this case, not only 3G-based access control is required, but also access to 3G-based services is needed over the WLAN network, which in turn calls for appropriate routing enforcement mechanisms. More importantly, however, there is need for QoS consistency across 3G and WLAN, which does not appear to be very straightforward given the different QoS features offered by these networks. Indeed, WLANs have initially been specified without much attention being paid to QoS aspects and aimed primarily to satisfy simple and cost-effective designs. Even with the recent IEEE 802.11e [17] developments, WLAN QoS still exhibits several deficiencies with respect to the 3G QoS (this is further discussed later). On the contrary, 3G cellular networks were built with the multimedia applications in mind and trade simplicity and cost for inherently providing enhanced QoS in wide-area environments. Our main interest in the following sections of this chapter is to examine the challenges of seamless session continuity across UMTS and WLAN, and to evaluate the conditions and restrictions under which seamless continuity is feasible. To this purpose, we formulate a number of practical interworking scenarios, where UMTS subscribers with ongoing real-time video sessions handover to WLAN, and we consider the capability of WLAN to provide seamless session continuity under several policy rules and WLAN traffic loads. One measure that we are particularly interested to quantify is the maximum number of UMTS subscribers c that can be admitted to the WLAN, subject to maintaining the level of UMTS QoS and respecting the WLAN policies. Although our study focuses primarily on QoS consistency, we do address several other issues that are equally important for enabling seamless session continuity, such as routing enforcement, access control and differentiation between the traffic of regular WLAN data users and UMTS roamers. The framework for discussing these issues is created by considering a practical UMTS/WLAN interworking architecture that conforms to the 3GPP specifica- tions [23, 24] and other interworking proposals found in the technical literature (e.g., [22]). 7.5 UMTS/WLAN Interworking Architecture The end-to-end interworking architecture we are considering is illustrated in Figure 7.11 and is compliant with the proposals in [22] and [23]. Below we briefly discuss the main characteristics of this architecture. Although we do not provide a comprehensive description, we set the ground for the next sections and define the real-life environment to which the subsequent study applies. This creates the right context for the following discussion and makes it easy to assess the importance of the provided results. For more detailed information on the considered architecture the interested reader is referred to [22–26]. As shown in Figure 7.11, the 3G network supports access to a variety of IP multimedia services via two radio access technologies: UMTS Terrestrial Radio Access (UTRA) and WLAN access. Access c The UMTS subscribers admitted to the WLAN are also referred to as UMTS roamers. 218 QoS Provision in Wireless Multimedia Networks control and traffic routing for 3G subscribers in UTRA is handled entirely by the UMTS Packet- Switched (PS) network elements, which encompass the Serving GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN) (see [25] for more details). On the other hand, access control and traffic routing for 3G subscribers in WLAN (UMTS roamers) is shared among the WLAN and the UMTS network elements as discussed below. The important assumption we make, as shown in Figure 7.11, is that 3G subscribers can change radio access technology and keep using their ongoing multimedia sessions in a seamless fashion. Thus, we assume that seamless service continuity is provided. This assumption raises considerable challenges and, as noted above, we are interested in investigating the capability of WLAN to support this seamless service continuity under specific scenarios. Note that by the term seamless service continuity we to refer to the continuation of a session (that has been initiated in the UMTS environment) in the WLAN environment without any noticeable QoS degradation or any other discrepancies whatsoever. We do not take into account however, the handover latency. In other words, we focus on ‘how well’ a session is continued in the WLAN and not ‘how fast’ the session is handed over from UMTS. The WLAN access network may be owned either by the UMTS operator or by any other party (e.g., a public WLAN operator, or an airport authority), in which case the interworking is enabled and governed by appropriate business and roaming agreements. As shown in Figure 7.11, in a typical deployment scenario the WLAN network supports various user classes, e.g., UMTS roamers and regular WLAN data users (i.e., no 3G subscribers). Differentiation between these user classes and enforcement of corresponding policies is typically enabled by employing several Service Set Identifiers (SSIDs). For example, the regular WLAN data users may associate with the SSID that is periodically broadcast by the Access Point (AP), whereas the UMTS roamers may associate with another SSID that is also configured in the AP, but not broadcast (see [26] about the usage of SSIDs). In this case, the WLAN can apply Figure 7.11 The considered end-to-end interworking architecture for seamless multimedia session continuity. UMTS/WLAN Interworking Architecture 219 [...]... the WLAN, this policy cannot be satisfied as the bandwidth utilized by WLAN data users is quickly diminished 8.0E-02 L = 7 Mbps 7.0E-02 MSDU loss rate for data traffic L = 8 Mbps L = 5 Mbps 6. 0E-02 5.0E-02 4.0E-02 3.0E-02 2.0E-02 1.0E-02 0.0E+00 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80 84 88 92 96 10 Number of UMTS roamers Figure 7. 16 The MSDU loss rate for data traffic vs the number... first time in large scale technologies such as IP version 6 (IPv6) and policy based IP QoS, spearheading the introduction of such technologies into the Internet The two most important aspects of 3G networks with respect to IP based multimedia services are the IP Multimedia Subsystem (IMS) and the Multimedia Broadcast / Multicast Service (MBMS) The IMS enables complex IP based multimedia sessions to be... Dimitriadis, D Skyrianoglou, N Passas and N Pavlidou, seamless continuity of real-time video across UMTS and WLAN networks: Challenges and performance evaluation, IEEE Wireless Communications, June 2005 8 Wireless Multimedia in 3G Networks George Xylomenos and Vasilis Vogkas 8.1 Introduction This chapter describes the support for IP based multimedia services on Third Generation (3G) wireless cellular networks... Klein and Bernhard Walke, Analysis of IEEE 802.11e for QoS support in Wireless LANs, IEEE Wireless Communications, 6, 40–50, December 2003 [29] 3GPP TS 26. 071 v5.0.0, AMR speech Codec; General description (Release 5), December 2002 234 QoS Provision in Wireless Multimedia Networks [30] 3GPP TS 23.107 v5.12.0, Quality of Service (QoS) concept and architecture (Release 5), March 2004 [31] 3GPP TS 26. 2 36. .. include voice telephony and video conferencing The IMS interoperates with both traditional telephony services and external IP based multimedia services The MBMS provides native IP broadcast and multicast support in 3G networks, allowing high bandwidth services to be economically offered to multiple users Example applications include video streaming via multicast and location based services via broadcast... issues for IP based multimedia services, describing the overall QoS concept, the policy based QoS control scheme and its Emerging Wireless Multimedia: Services and Technologies Edited by A Salkintzis and N Passas # 2005 John Wiley & Sons, Ltd Wireless Multimedia in 3G networks 2 36 application to IMS sessions At the end of the chapter, a glossary lists the acronyms used An extensive UMTS vocabulary... features and services provided by the IMS and the MBMS In Section 8.5 we provide the details of the IMS, including service architecture, session setup and control and interworking issues Section 8 .6 describes the MBMS in the same manner as for the IMS Finally, Section 8.7 discusses the QoS issues for IP based multimedia services, describing the overall QoS concept, the policy based QoS control scheme and. .. Rubens and W Simpson, Remote Authentication Dial In User Service (RADIUS), RFC 2 865 , June 2000 [15] Grilo, M Macedo and M Nunes, A scheduling algorithm for QoS support in IEEE 802.11e networks, IEEE Wireless Communications, 36 43, June 2003 [ 16] D Skyrianoglou, N Passas and A Salkintzis, Traffic scheduling for multimedia QoS over WLANs, Proc IEEE ICC, Seoul, Korea, May 2005 [17] IEEE draft standard... telephone numbers and Internet names; media description capabilities, including coding formats and data rates; person-to-person real-time multimedia services, including voice telephony; machine-to-person streaming multimedia services, including TV channels; generic group management, enabling chat rooms and messaging; generic group communication, enabling voice and video conferencing These basic services can... 2475, December 1998 [20] M Mirhakkak, N Schult and D Thomson, Dynamic bandwidth management and adaptive applications for a variable bandwidth wireless environment, IEEE Journal on Selected Areas in Communications, 19(10), October 2001 [21] N Passas, E Zervas, G Hortopan and L Merakos, A Flow Rejection Algorithm for QoS Maintenance in a Variable Bandwidth Wireless IP Environment, IEEE Journal on Selected . to 0.0E+00 1.0E-02 2.0E-02 3.0E-02 4.0E-02 5.0E-02 6. 0E-02 7.0E-02 8.0E-02 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80 84 88 92 96 10 Number of UMTS roamers MSDU loss rate for data. reaches the UMTS 0.0E+00 5.0E-04 1.0E-03 1.5E-03 2.0E-03 2.5E-03 3.0E-03 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 Number of UMTS roamers MSDU loss rate for video traffic L = 7 Mbps L = 8 Mbps L. the randomly rejection mechanism. Table 7.1 Different bandwidth requirements per class Flow types Bandwidth requirements Probability 1 0.5 0 .6 2 2 0.25 3 5 0.1 4 10 0.05 2 16 QoS Provision in Wireless