4.3 The Challenges of Mobile Networks
4.3 The Challenges of Mobile Networks
This section analyzes the differences between fixed IP networks and mobile networks, from the streaming service perspective. Deploying a streaming service over mobile networks is a challenging task, because all the constraints and properties of a mobile network must be taken into account when developing a streaming application.
In a fixed IP environment such as the Internet, the main obstacles for achieving a good QoS are packet losses and delays. Losses are mainly caused by congestion in the routers along the end-to-end path between the streaming server and the streaming client. If a router is congested, it starts to drop packets. These packets are normally not retransmitted by the network protocols, unless ad hoc retransmission techniques are used at the application layer or reliable transport protocols as employed. Delays may depend on congestion issues, out-of-sequence packet reordering and on the physical capacity of the network trunks between streaming server and client. A variable delay over time is called jitter. Whenever the inter-arrival time of the media packets at the streaming client is variable, delay jitter occurs. Normally, a good buffer management at the streaming client would help in de-jittering the incoming data flow.
In a mobile network environment some new factors must be considered:
-
Radio link quality. In mobile networks the air interface is inherently affected by bit errors that can be up to 10-3 after channel coding. High bit error rates (BERs) can be caused, for example, by a weak radio signal in a determined area (such as under bridges, behind buildings or hills) or because of handover due to movement of the user. This factor may cause packet corruption or packet losses that can produce noticeable impairment of the streamed media.
-
Mobility. As users become truly mobile, handover is an important issue. Handover (i.e., switching the mobile client from a cell to another cell of the same or another operator's network) is an operation that may cause service interruption for a certain amount of time, and it might cause delay and packet losses at the streaming client. When moving to a new cell, the capacity that was available in the old cell might no longer be available to the streaming user. This factor means that the bandwidth may be subject to change all the time with user mobility. The management of network bandwidth variation is one of the key points for a successful mobile streaming service.
4.3.1 Mobile Networks for Streaming
In this section we will describe the suitable mobile channels for multimedia streaming. There are essentially two types of connections that allow streaming: circuit-switched and packet-switched connections.
4.3.1.1 Circuit-Switched Mobile Channels
4.3.1.1.1 High Speed Circuit-Switched Data (HSCSD)
HSCSD is a technology derived by the GSM (Global System for Mobile Communications) standard, and defined in the GSM Release '96 specifications. The limit of GSM networks in terms of capacity is 9.6 kbps. This speed is suitable for voice calls and nonreal-time data connections at very low bit rates, such as Web access. The minimum capacity requirement of a multimedia streaming application of acceptable quality is about 20 kbps (i.e., considering 5 kbps of audio and 15 kbps for video at four frames per second).
An HSCSD network is an enhancement of the GSM network. The basic idea is to allow one user to simultaneously allocate several TDMA (Time Division Multiple Access) time slots of a carrier. To achieve this, a new functionality is introduced in the network and mobile station (MS) for splitting and combining data into several data streams, which will then be transferred via n (n = 1,2,...,8) channels over the radio interface. Once split, the data streams are carried by the n full-rate traffic channels as if they were independent of each other, up to the point in the network where they are combined (see Figure 4.2). [2]
Figure 4.2: Network architecture for supporting HSCSD. (Source— ETSI, High speed circuit-switched data [HSCSD], Stage 2 [Release '96], GSM 03.34, v.5.2.0 [1999-05].)
The data rate of a single time slot can be increased up to 14.4 kbps by puncturing (i.e., by deleting) certain error correction bits of the existing 9.6 kbps. In theory, up to 8 time slots can be allocated at the same time; therefore, the available user bit rate could be as high as 115.2 kbps (8 14.4 kbps). In practice, however, the maximum bit rate per user is limited to 64 kbps, because only one ISDN B-channel is reserved per user in the A interface of GSM network infrastructure. [3] Table 4.1 summarizes the possible bit rates achievable in uplink and downlink with HSCSD networks.
| Number of Time Slots | Bit Rate per Time Slot (kbps) | Total User Bit Rate (kbps) |
|---|---|---|
| 1 | 9.6 | 9.6 |
| 2 | 9.6 | 19.2 |
| 3 | 9.6 | 28.8 |
| 4 | 9.6 | 38.4 |
| 1 | 14.4 | 14.4 |
| 2 | 14.4 | 28.8 |
| 3 | 14.4 | 43.2 |
| 4 | 14.4 | 57.6 |
HSCSD has both transparent and nontransparent types of services. Transparent mode offers error protection at the channel coding level only. In this mode retransmission of packets hit by errors is not used. As a result, the bit rate and network delay are constant, [4] but the BER is variable (up to 10-3), depending on the channel condition. Nontransparent mode offers retransmission of erroneous frames, using the GSM Radio Link Protocol (RLP) (see Figure 4.3), [5] in addition to error correction made by channel coding. Typical BER values in nontransparent mode are less than 10-6. The available throughput and transmission delay vary with the channel quality (the higher the BER, the lower the throughput and the higher the network delay). Typical delay values range from 400 milliseconds up to 1 second in case of mobile-to-mobile connections. [6]
Figure 4.3: The HSCSD concept in nontransparent mode. (Source— ETSI, High speed circuit-switched data [HSCSD], Stage 2 [Release '96], GSM 03.34, v.5.2.0 [1999-05].)
HSCSD services can be further classified in symmetrical and asymmetrical services. Symmetrical service allows allocating equal bit rates to both the uplink and downlink connections. Asymmetrical service can provide different data rates in the uplink and downlink direction. Asymmetrical services are only applicable in nontransparent mode, [7] and are most suitable for multimedia streaming. In fact, in this case most of the data flow goes from the network to the MS; only a fraction of the traffic goes in the opposite direction. An example of a streaming connection over asymmetrical HSCSD is a 3+1 time slot service (43.2 kbps for downlink direction and 14.4 kbps for uplink direction).
4.3.1.1.2 Enhanced Circuit-Switched Data (ECSD)
ECSD is a network technology defined within EDGE in Release '99 specifications, and it has the same principle as HSCSD. The fundamental enhancement consists of a new modulation technique used in the air interface. This modulation is called 8-PSK (octagonal Phase Shift Keying) and it triples the data rate per time slot. However, the limitation of the A interface to 64 kbps is always in place. Table 4.2 summarizes the bit rates achievable with ECSD (in addition to those available with HSCSD). [8]
| Number of Time Slots | Bit Rate per Time Slot (kbps) | Total User Bit Rate (kbps) |
|---|---|---|
| 1 | 28.8 | 28.8 |
| 2 | 28.8 | 57.6 |
| 2 | 32.0a | 64.0 |
| 1 | 43.2 | 43.2 |
| The 32 kbps configuration is available only for multiple slot transparent service. [a] | ||
|
[a]3GPP TSG-CN, High Speed Circuit Switched Data (HSCSD), Stage 2 (Release '99), TS 23.034, v.3.3.0 (2000–12). | ||
4.3.1.2 Packet-Switched Mobile Channels
4.3.1.2.1 General Packet Radio Service (GPRS)
GPRS networks introduce the concept of packet data in Release '97 specifications. Packet data is suitable for applications that exploit a bursty traffic, for which it is not needed to allocate a circuit-switched channel permanently, but resources are allocated from a common pool. The access time to GPRS networks is lower, and charging is done based on traffic volumes.
A great advantage of GPRS networks is that they are built to support packet-switched traffic based on IP and X.25 protocols. In this way, it is easy to connect GPRS networks to IP-based backbones, such as the public Internet. Figure 4.4 shows the GPRS protocol stack for the user plane. [9]
Figure 4.4: GPRS user plane protocol stack.
A GPRS MS can use up to eight channels or time slots (TS), that are dynamically allocated separately for downlink and uplink when there is traffic to be transferred. The allocation depends on the resource availability. In GPRS, different channel coding schemes are defined in the radio interface. They are named CS-1, CS-2, CS-3, and CS-4, and offer decreasing error protection. Depending on the number of time slots and the coding scheme used, the maximum bit rate achievable with GPRS networks can be as high as 171.2 kbps, as shown in Table 4.3.
| 1 TS | 2 TS | 3 TS | 4 TS | 5 TS | 6 TS | 7 TS | 8 TS | |
|---|---|---|---|---|---|---|---|---|
| CS-1 | 9.05 | 18.1 | 27.15 | 36.2 | 45.25 | 54.3 | 63.35 | 72.4 |
| CS-2 | 13.4 | 26.8 | 40.2 | 53.6 | 67.0 | 80.4 | 93.8 | 107.2 |
| CS-3 | 15.6 | 31.2 | 46.8 | 62.4 | 78.0 | 93.6 | 109.2 | 124.8 |
| CS-4 | 21.4 | 42.8 | 64.2 | 85.6 | 107.0 | 128.4 | 149.8 | 171.2 |
Between the MS and the BSS (Base Station Subsystem) transmission can occur in Unacknowledged or Acknowledged mode at the Radio Link Control (RLC) layer. [10] Unacknowledged mode is a transparent transmission mode. In acknowledged mode, the RLC layer provides the ability to retransmit the erroneous frames that have been corrupted by errors in the air interface. Acknowledged mode is appropriate for mobile multimedia streaming.
The SNDCP (SubNetwork Dependent Convergence Protocol) [11] layer provides TCP/IP header compression [12] and V.42 bis [13] data compression to enhance the capacity of the network. SNDCP allows a reduction of the packet header size from 40 to 3 bytes.
GPRS introduces the concept of QoS profile for a PDP context. A QoS profile defines a set of attributes that characterize the expected quality of the connection. These attributes are described in Table 4.4. [14], [15], [16], [17], [18], [19] For real-time traffic, such as multimedia streaming traffic, the QoS profile must be set with appropriate combination of values, in order to guarantee the best user QoS. It must be noted that the throughput values can be renegotiated by the network at any time.
| QoS Profile Attribute | Description |
|---|---|
| Precedence class | The precedence class indicates a priority in case of abnormal network behavior. For example, in case of congestion, the precedence class determines which packet to discard first. Values: [1...3] in decreasing order of precedence |
| Delay class | The delay class defines the maximum and 95-percentile of mean transfer delay within a GPRS network end-to-end (it does not include transfer delays in external networks). Examples for packet sizes of 128 and 1024 bytes are shown in Table 4.5. Values: [1...4]. A GPRS network must support at least the Class 4 (best effort) |
| Reliability class | Data reliability is defined in terms of residual probabilities of data loss, out-of-sequence delivery, duplicate data delivery and data corruption. These probabilities are defined for three classes in Table 4.6. The reliability class specifies the requirements of the various network protocol layers. The combinations of the GTP (GPRS Tunneling Protocol), LLC (Logical Link Control), and RLC transmission modes support the reliability class performance requirements. The combinations are shown in Table 4.7. Values: [1...5]. A GPRS network may support only a subset of the defined reliability classes |
| Mean throughput class | It specifies the average rate at which data is expected to be transferred across the GPRS network during the remaining lifetime of an activated PDP context. The rate is measured in bytes per hour. Values: [1...18, 31], where the value 31 means best effort, and the values from 1 to 18 define discrete rates in the range [100, 50 106] bytes per hour, i.e., in the range [0.22, 111 103] bits per second |
| Peak throughput class | It specifies the maximum rate at which data is expected to be transferred across the GPRS network for an activated PDP context. There is no guarantee that this peak rate can be achieved or sustained for any time period, and this depends on the MS capability and the available radio resources. The rate is measured in bytes per second. Values: [1...9], which define discrete rates in the range [1 103, 256 103] bytes per second, i.e., in the range [8, 2048] kbps |
| Delay (Maximum Values) | ||||
|---|---|---|---|---|
| Packet Size: 128 Bytes | Packet Size: 1024 Bytes | |||
| Delay Class | Mean Transfer Delay (sec) | 95th Percentile Transfer Delay (sec) | Mean Transfer Delay (sec) | 95th Percentile Transfer Delay (sec) |
| < 0.5 | < 1.5 | < 2 | < 7 |
| < 5 | < 25 | < 15 | < 75 |
| < 50 | < 250 | < 75 | < 375 |
| Unspecified | |||
| Probability | |||||
|---|---|---|---|---|---|
| Reliability Class | Packet Loss | Duplicate Packet | Out of Sequence Packet | Packet Corruption | Example of Application Characteristics |
| 1 | 10-9 | 10-9 | 10-9 | 10-9 | Error sensitive, no error-correction capability, limited error-tolerance capability |
| 2 | 10-4 | 10-5 | 10-5 | 10-6 | Error sensitive, limited error-correction capability, good error-tolerance capability |
| 3 | 10-2 | 10-5 | 10-5 | 10-2 | Not error sensitive, error-correction capability, very good error-tolerance capability |
| Reliability Class | GTP Mode | LLC Frame Mode | LLC Data Protection | RLC Block Mode | Traffic Type |
|---|---|---|---|---|---|
| 1 | Acknowledged | Acknowledged | Protected | Acknowledged | Nonreal-time traffic, error-sensitive application that cannot cope with data loss. |
| 2 | Unacknowledged | Acknowledged | Protected | Acknowledged | Nonreal-time traffic, error-sensitive application that can cope with infrequent data loss. |
| 3 | Unacknowledged | Unacknowledged | Protected | Acknowledged | Nonreal-time traffic, error-sensitive application that can cope with data loss, GMM/SM, and SMS. |
| 4 | Unacknowledged | Unacknowledged | Protected | Unacknowledged | Real-time traffic, error-sensitive application that can cope with data loss. |
| 5 | Unacknowledged | Unacknowledged | Unprotected | Unacknowledged | Real-time traffic, error nonsensitive application that can cope with data loss. |
4.3.1.2.2 Enhanced General Packet Radio Service (E-GPRS)
E-GPRS is defined in the EDGE framework of Release '99 specifications. [20] In E-GPRS, as in ECSD, the 8-PSK modulation is used to increase the network capacity. This modulation scheme is used in addition to the GMSK (Gaussian Minimum Shift Keying) already employed in GPRS. The major impacts of E-GPRS, compared to GPRS, are in layers 1 and 2 of the protocol stack. In layer 1 a new set of modulation and coding schemes (MCS) are defined. The GPRS GMSK coding schemes (CS-1 through CS-4) are replaced with four new GMSK modulation and coding schemes (MCS-1 through MCS-4) offering decreasing error protection. In addition, five 8-PSK coding schemes (MCS-5 through MCS-9) are defined, which yield decreasing error protection as well.
The E-GPRS coding schemes support incremental redundancy (IR), which is a physical layer performance enhancement for the RLC acknowledged mode of layer 2. Whenever a request for a retransmission is triggered by the RLC protocol, the IR mechanism dynamically adjusts the code rate to the actual channel conditions by incrementally redundant information, until the reception of the lost RLC block is successful. This effectively increases the probability of data reception at the RLC peer entity. [21] This feature is a great benefit in nonconversational real-time applications, such as mobile multimedia streaming.
In E-GPRS, bit rates can be increased up to 473.6 kbps, as illustrated in Table 4.8, which shows the bit rates for different combinations of time slots and coding schemes.
| 1 TS | 2 TS | 3 TS | 4 TS | 5 TS | 6 TS | 7 TS | 8 TS | |
| MCS-1 | 8.8 | 17.6 | 26.4 | 35.2 | 44.0 | 52.8 | 61.6 | 70.4 |
| MCS-2 | 11.2 | 22.4 | 33.6 | 44.8 | 56.0 | 67.2 | 78.4 | 89.6 |
| MCS-3 | 14.8 | 29.6 | 44.4 | 59.2 | 74.0 | 88.8 | 103.6 | 118.4 |
| MCS-4 | 17.6 | 35.2 | 52.8 | 70.4 | 88.0 | 105.6 | 123.2 | 140.8 |
| MCS-5 | 22.4 | 44.8 | 67.2 | 89.6 | 112.0 | 134.4 | 156.8 | 179.2 |
| MCS-6 | 29.6 | 59.2 | 88.8 | 118.4 | 148.0 | 177.6 | 207.2 | 236.8 |
| MCS-7 | 44.8 | 89.6 | 134.4 | 179.2 | 224.0 | 268.8 | 313.6 | 358.4 |
| MCS-8 | 54.4 | 108.8 | 163.2 | 217.6 | 272.0 | 326.4 | 380.8 | 435.2 |
| MCS-9 | 59.2 | 118.4 | 177.6 | 236.8 | 296.0 | 355.2 | 414.4 | 473.6 |
Another improvement offered by E-GPRS is the TCP and UDP (over IPv4 and IPv6) header compression capability in the SNDCP layer. This allows the packet headers to reduce from a maximum size of 60 to 4 bytes. [22]
The QoS profile for E-GPRS is essentially similar to that for UTRAN. Please refer to the information provided in Tables 4.9, 4.10, and in the next section.
| Traffic Class | Conversational Class | Streaming Class | Interactive Class | Background |
|---|---|---|---|---|
| Fundamental characteristics |
|
|
|
|
| Example application |
|
|
|
|
| QoS Profile Attribute | Description |
|---|---|
| Traffic class | Type of application for which the UMTS bearer service is optimized. UMTS can make assumptions about the traffic source and optimize the transport for that traffic type. Values: [Conversational, Streaming, Interactive, Background] |
| Maximum bit rate | Upper limit a user or application can accept or provide. All UMTS bearer service attributes may be fulfilled for traffic up to the maximum bit rate depending on the network conditions. Its purpose is (1) to limit the delivered bit rate to applications or external networks with such limitations, and (2) to allow a maximum user bit rate to be defined for applications that are able to operate with different rates (e.g., applications with adapting codecs). Values: up to 2048 kbps |
| Guaranteed bit rate | Describes the bit rate the UMTS bearer service shall guarantee to the user or application. Guaranteed bit rate may be used to facilitate admission control based on available resources, and for resource allocation within UMTS. Values: up to 2048 kbps |
| Delivery order | Indicates whether the UMTS bearer shall provide in-sequence packet delivery. Values: [Yes, No] |
| Maximum SDU size | The maximum allowed SDU (packet) size. It is used for admission control and policing. Values: up to 1502 bytes |
| SDU format information | List of possible exact sizes of SDUs (packets). UTRAN needs packet size information to operate in transparent RLC mode. Thus, if the application can specify packet sizes, the bearer is less expensive. Values: specific values in bits |
| SDU error ratio | Indicates the fraction of packets lost or detected as erroneous. Values: [10-1, 10-2, 7*10-3, 10-3, 10-4, 10-5] |
| Residual bit error ratio | Indicates the undetected bit error ratio in the delivered packets. If no error detection is requested, residual bit error ratio indicates the bit error ratio in the delivered packets. Values: [5*10-2, 10-2, 5*10-3, 10-3, 10-4, 10-5, 10-6] |
| Delivery of erroneous SDUs | Used to decide whether error detection is needed and whether frames with detected errors shall be forwarded to the upper layers. Values [Yes, No, —], where "Yes" means that error detection is employed and erroneous packets are delivered together with an error indication; "No" means that error detection is employed and that erroneous packets are discarded; "—" means that packets are delivered without considering error detection. |
| Transfer delay | Used to specify the delay tolerated by the application; in other words, it is the maximum delay for the 95th-percentile of the distribution of delay for all delivered packets during the lifetime of a bearer service, where delay for a packet is defined as the time from a request to transfer a packet at one SAP (service access point) to its delivery at the other SAP. A good maximum delay value would take into account delays produced by the RLC layer when the acknowledged mode is used. Values: [288, maximum value] milliseconds; the maximum value can be defined at bearer setup |
| Traffic handling priority | Specifies the relative importance for handling of all the packets belonging to the bearer compared to the packets of other bearers. This parameter is not used for the streaming traffic class. Values: [1, 2, 3] |
| Allocation/retention priority | Used for differentiating between bearers when performing allocation and retention of a bearer. In situations where resources are scarce, the network can use this attribute to prioritize bearers with a high priority over bearers with a low priority when performing admission control. This is a subscription attribute, which is not negotiated from the mobile terminal. Values: [1, 2, 3] |
| Source statistics descriptor | Specifies characteristics of the source traffic. Conversational speech has a well-known statistical behavior. By being informed that the packets are generated by a speech source, the network and the mobile station may, based on experience, calculate a statistical multiplex gain for use in admission control on the relevant interfaces. Values: [Speech, unknown]. |
4.3.1.2.3 UMTS Terrestrial Radio Access Network (UTRAN)
The IMT-2000 specifications for 3G networks are written by 3GPP, which has defined standards for UMTS networks. The air interface technology for UMTS is W-CDMA (Wideband Code Division Multiple Access). The main objectives and features for UMTS networks can be summarized as:
-
Full area coverage and mobility for 144 kbps (at vehicular speed), preferably 384 kbps (at pedestrian speed). Limited area coverage and mobility for 2 Mbps.
-
Multiplexing of services with different QoS requirements on a single bearer (e.g., a speech call, a multimedia streaming session, and a Web session). This is one of the key features of W-CDMA. Power is the common shared resource for users. As the bit rate changes, the power allocated to the channel is adjusted so that the continuity of service is guaranteed at any instant of the connection. The relative transmitted power during a 10-millisecond radio frame is a function of the bit rate: the higher the bit rate, the higher the transmitted power. In this way there is no waste of resources. For example, when a short voice segment has low information content, it can be encoded with few bits that will be transmitted using a relatively small amount of power, thus minimizing interference with other users.
-
Delay requirements that range from the most stringent values for real-time traffic to more relaxed ones for best-effort traffic.
-
Coexistence of 2G, 2.5G, and 3G networks through intersystem handover capability.
-
Fast transmit power control (TPC). Because W-CDMA networks are interference limited, fast TPC based on the measurement of signal-to-interference ratio (SIR) can always minimize the transmitted power according to the traffic load, and thus interference to other users can be reduced.
3GPP has gone through different releases of the UTRAN specifications, namely Release '99, Release 4, and Release 5. At the time of writing this chapter, the Release 6 specifications were in the process of being defined. UTRAN networks offer both circuit-switched and packet-switched services. Release 5 specifications define the IP Multimedia Subsystem (IMS) [23] in the Core Network (CN) that makes all-IP networks a reality. IMS is based on the Session Initiation Protocol (SIP) defined in the IETF (Internet Engineering Task Force). [24], [25], [26] IMS in the CN enables more Internet-based multimedia services that are not available in the Release 4 CN.
Figure 4.5 shows the user plane protocol stack for UTRAN networks. [27] Between the MS and the UTRAN, the RLC Protocol can operate in transparent, unacknowledged, and acknowledged modes. In transparent mode no protocol overhead is added to the higher layer data, while in unacknowledged and acknowledged modes a certain RLC layer overhead is added (sequence numbers, length indication, and other information). Acknowledged mode is suitable for a mobile multimedia streaming application, because it provides retransmissions of the lost blocks. Retransmission can be configured in the RLC protocol in different ways: [28]
Figure 4.5: User plane protocol stack for UTRAN networks (Iu mode)
-
Retransmissions for n times. The RLC layer tries to retransmit the lost block up to n times. If it does not reach the RLC peer entity within n retransmission attempts, the block is considered lost. This option tries to achieve a constant BLER (block error rate) at the cost of a variable delay at the RLC peer entity.
-
Retransmission with a timer. The RLC tries to retransmit the lost block an undefined number of times until a timer fires. Afterwards, the block is considered lost. This option defines implicitly an upper bound on the delay at the RLC peer entity; however, the BLER is variable.
-
Fully persistent retransmission. The RLC layer retransmits the lost block an undefined number of times until the block is received by the RLC peer entity. The RLC block is discarded only when the RLC layer buffer is full. This option defines an upper bound on the BLER, but it may produce the highest variations of delay at the receiver (jitter).
Other functions of the RLC layer include segmentation/reassembly, concatenation, padding, error correction, in-sequence delivery, duplicate detection, flow control, sequence number check, and ciphering.
The PDCP (Packet Data Convergence Protocol) layer [29] is located immediately below the IP layer, and it exists only for services from the packet-switched domain. Its main functionality is that of compressing higher-layer protocol headers for the purpose of reducing the bit rate toward the radio interface. For Release '99 networks the compression algorithm is the same as the one included in the E-GPRS specifications, [30] while from Release 4 onward the ROHC (Robust Header Compression) algorithm [31] is supported also to compress RTP/UDP/IP or UDP/IP (under IPv4 or IPv6 environment) headers from a maximum of 60 to 3 bytes. In the PDCP, differently than the SNDCP layer in GPRS, no data compression is supported. The reason for this choice is to achieve a higher protocol speed, and also because many types of data encapsulated using the Real-Time Transport Protocol (RTP) are already compressed (speech, audio, video, images), making a second compression step unnecessary.
To guarantee end-to-end quality of service, the UMTS specifications define a new, important parameter: the traffic class. This is considered as a fundamental way to distinguish services of different types and their respective quality. Table 4.9 summarizes the four traffic classes defined for UMTS networks. [32] The practical differences between the four classes is in terms of delay and error rates. While conversational and streaming classes guarantee low delays at the cost of higher error rates, interactive and background traffic classes guarantee lower error rates at the cost of higher delays.
The QoS profile for an UMTS PDP context is defined in a slightly different way compared to the GPRS QoS profile. Table 4.10 contains the QoS profile attributes and values for the streaming traffic class. [33]
The rules to map UMTS and GPRS Release '97 QoS profile attributes (and vice versa) are not described here, but they are available (see reference [34]).
4.3.1.2.4 GSM/EDGE Radio Access Network (GERAN)
GERAN networks in Release 5 specifications originate from the possibility of integrating UMTS and GSM/EDGE network technologies to provide more benefits to the end users. The two technologies have many things in common; for example, UMTS has adopted most of the functionalities of the GSM/EDGE networks. On the other hand, GERAN has adopted the Iu interface, which is the same interface between UTRAN and CN. The Iu interface enables the interfacing to UTRAN networks, allowing also the provisioning of the same IMS services as UTRAN. GERAN also makes use of the Gb and A interfaces to communicate with GSM/EDGE networks at the maximum speed of 473.6 kbps. GERAN implements a separation of radio-related and nonradio-related functionalities. For example, one operator could run a CN and deploy the same services using two different radio technologies seamlessly (e.g., W-CDMA, GSM/EDGE, WLAN).
One of the peculiarities of UTRAN and GERAN is the fact that their protocol stacks are aligned. Figure 4.6 shows the GERAN user plane protocol stack. [35]
Figure 4.6: User plane protocol stack for GERAN networks.
In this architecture, the SNDCP and LLC protocols of E-GPRS are replaced by the PDCP layer, when communicating through the Iu interface. One of the features standardized in GERAN is the capability to efficiently handle RTP/UDP/IP traffic by using header compression [36] or header removal in the PDCP layer.
The RLC layer is similar to the one defined for UTRAN, but also it can benefit from incremental redundancy of E-GPRS. All the other protocol details are similar to those for UTRAN. The same is valid for the QoS profile parameters.
In this section we have surveyed the standards for 2.5G and 3G mobile networks. These networks allow the deployment of mobile multimedia streaming. The next section is about standardized protocols, codecs, and issues related to multimedia streaming applications.
[2]ETSI, High speed circuit-switched data (HSCSD). Stage 2 (Release '96), GSM 03.34, v.5.2.0 (1999-05).
[3]ETSI, High speed circuit-switched data (HSCSD). Stage 2 (Release '96), GSM 03.34, v.5.2.0 (1999-05).
[4]ETSI, High speed circuit-switched data (HSCSD). Stage 1 (Release '98), GSM 02.34, v.7.0.0 (1999-08).
[5]ETSI, High speed circuit-switched data (HSCSD). Stage 2 (Release '96), GSM 03.34, v.5.2.0 (1999-05).
[6]Nieweglowski, J. and Leskinen, T., Video in mobile networks, European Conference on Multimedia Applications, Services and Techniques (ECMAST '96), 28–30 May 1996, Louvain-la-Neuve, Belgium, pp. 120–133.
[7]ETSI, High speed circuit-switched data (HSCSD). Stage 1 (Release '98), GSM 02.34, v.7.0.0 (1999-08).
[8]3GPP TSGS-SA, High speed circuit-switched data (HSCSD). Stage 1 (Release 4), TS 22.034, v.4.1.0 (2001–03).
[9]3GPP TSGS-SA, General packet radio service (GPRS), service description. Stage 2 (Release '97), TS 03.60, v.6.11.0 (2002–06).
[10]3GPP TSG-GERAN, General packet radio service (GPRS), mobile station (MS)-base station system (BSS) interface, radio link protocol/medium access control (RLC/MAC) protocol (Release '97), TS 04.60, v.6.14.0 (2001-07).
[11]3GPP TSG-CN, General packet radio service (GPRS), mobile station — serving GPRS support node (MS-SGSN), subnetwork dependent convergence protocol (SNDCP) (Release '97), TS 04.65, v.6.7.0 (2000–03).
[12]Jacobson, V., Compressing TCP/IP headers for low-speed serial links, IETF (Internet Engineering Task Force) RFC 1144, February 1990.
[13]ITU-T, Data compression procedures for data circuit-terminating equipment (DCE) using error correcting procedures, Recommendation V.42 bis, January 1990.
[14]3GPP TSGS-SA, General packet radio service (GPRS), service description. Stage 2 (Release '97), TS 03.60, v.6.11.0 (2002–06).
[15]3GPP TSG-GERAN, General packet radio service (GPRS), mobile station (MS)-base station system (BSS) interface, radio link protocol/medium access control (RLC/MAC) protocol (Release '97), TS 04.60, v.6.14.0 (2001-07).
[16]3GPP TSG-CN, General packet radio service (GPRS), mobile station — serving GPRS support node (MS-SGSN), subnetwork dependent convergence protocol (SNDCP) (Release '97), TS 04.65, v.6.7.0 (2000–03).
[17]Jacobson, V., Compressing TCP/IP headers for low-speed serial links, IETF (Internet Engineering Task Force) RFC 1144, February 1990.
[18]ITU-T, Data compression procedures for data circuit-terminating equipment (DCE) using error correcting procedures, Recommendation V.42 bis, January 1990.
[19]ETSI, General packet radio service (GPRS), service description (Stage 1) (Release '98), GSM 02.60, v.7.5.0 (2000–07).
[20]3GPP TSGS-SA, General Packet Radio Service (GPRS), Service Description, Stage 2 (Release '99), TS 23.060, v.3.14.0 (2002–12).
[21]Halonen, T., Romero, J., and Melero, J., Eds., GSM, GPRS and EDGE Performance, John Wiley & Sons, New York, 2002.
[22]Degermark, M., Nordgren, B., and Pink, S., IP header compression, IETF (Internet Engineering Task Force) RFC 2507, February 1999.
[23]3GPP TSG SSA, IP Multimedia subsystem (IMS). Stage 2 (Release 5), TS 23.228, v.5.7.0 (2002–12).
[24]3GPP TSG-CN, Signaling flows for the IP multimedia call control based on SIP and SDP. Stage 3 (Release 5), TS 24.228, v.5.3.0 (2002–12).
[25]3GPP TSG-CN, IP multimedia call control protocol based on SIP and SDP. Stage 3 (Release 5), TS 24.229, v.5.3.0 (2002–12).
[26]Rosenberg, J. et al., SIP: Session Initiation Protocol, IETF (Internet Engineering Task Force) RFC 3261, March 2002.
[27]3GPP TSGS-SA, General packet radio service (GPRS), service description. Stage 2 (Release 5), TS 23.060, v.5.4.0 (2002–12).
[28]3GPP TSG-RAN, Radio link control (RLC) protocol specification (Release 5), TS 25.322, v.5.3.0 (2002–12).
[29]3GPP TSG-RAN, Packet Data Convergence Protocol (PDCP) Specification (Release 4), TS 25.323, v.4.6.0 (2002–09).
[30]Degermark, M., Nordgren, B., and Pink, S., IP header compression, IETF (Internet Engineering Task Force) RFC 2507, February 1999.
[31]Bormann, C., Ed., Robust header compression (ROHC): framework and four profiles: RTP, UDP, ESP and uncompressed, IETF (Internet Engineering Task Force) RFC 3095, July 2001.
[32]3GPP TSGS-SA, QoS concept and architecture (Release 5), TS 23.107, v.5.7.0 (2002–11).
[33]3GPP TSGS-SA, QoS concept and architecture (Release 5), TS 23.107, v.5.7.0 (2002–11).
[34]3GPP TSGS-SA, QoS concept and architecture (Release 5), TS 23.107, v.5.7.0 (2002–11).
[35]3GPP TSG-GERAN, Overall description. Stage 2 (Release 5), TS 43.051, v.5.8.0 (2002–11).
[36]Bormann, C., Ed., Robust header compression (ROHC): framework and four profiles: RTP, UDP, ESP and uncompressed, IETF (Internet Engineering Task Force) RFC 3095, July 2001.
EAN: 2147483647
Pages: 239