Monday, February 22, 2010

Codec's for LTE

Sometime back I mentioned about Orange launching AMR-WB codec which would result in 'hi-fi quality' voice (even though its being referred to as HD voice by some). Since then, there has been not much progress on this HD-voice issue.

CODEC stands for “COder-DECoder,” but is also known as an enCOder-DECoder and COmpression-DECompression system when used in video systems. Codec's are important as they compress the voice/video data/packets so less bandwidth is required for the data to be transmitted. At the same time it has to be borne in mind that the capacity to withstand errors decrease with higher compression ratio and as a result it may be necessary to change the codecs during the voice/video call. This calls for flexibility as in case of AMR (Adaptive Multi Rate) Codecs.

The following is from Martin Sauter's book "Beyond 3G – Bringing Networks, Terminals and the Web Together":

Voice codecs on higher layers have been designed to cope with packet loss to a certain extent since there is not usually time to wait for a repetition of the data. This is why data from circuit-switched connections is not repeated when it is not received correctly but simply ignored. For IP sessions, doing the same is difficult, since a single session usually carries both real-time services such as voice calls and best-effort services such as Web browsing simultaneously. In UMTS evolution networks, mechanisms such as ‘Secondary PDP contexts’ can be used to separate the real-time data traffic from background or signaling traffic into different streams on the air interface while keeping a single IP address on the mobile device.

UMTS uses the same codecs as GSM. On the air interface users are separated by spreading codes and the resulting data rate is 30–60 kbit/s depending on the spreading factor. Unlike GSM, where timeslots are used for voice calls, voice capacity in UMTS depends less on the raw data rate but more on the amount of transmit power required for each voice call. Users close to the base station require less transmission power in downlink compared with more distant users. To calculate the number of voice calls per UMTS base station, an assumption has to be made about the distribution of users in the area covered by a cell and their reception conditions. In practice, a UMTS base station can carry 60–80 voice calls per sector. A typical three-sector UMTS base station can thus carry around 240 voice calls. As in the GSM example, a UMTS cell also carries data traffic, which reduces the number of simultaneous voice calls.

The following is an extract from 3G Americas white paper, "3GPP Mobile Broadband Innovation Path to 4G: Release 9, Release 10 and Beyond: HSPA+, SAE/LTE and LTE-Advanced,":

Real-time flows (voice/video) based on rate adaptive codecs can dynamically switch between different codec rates. Codec rate adaptation allows an operator to trade off voice/video quality on one side and network capacity (e.g. in terms of the number of accepted VoIP calls), and/or radio coverage on the other side. Operators have requested a standardized solution to control the codec rate adaptation for VoIP over LTE, and a solution has been agreed upon and specified in the 3GPP Rel-9 specifications, which is provided in this paper.

CODEC RATE ADAPTATION BASED ON ECN

Given previous discussion in 3GPP (3GPP S4-070314) it was clear that dropping IP packets was not an acceptable means for the network to trigger a codec rate reduction. Instead an explicit feedback mechanism had to be agreed on by which the network (e.g. the eNodeB) could trigger a codec rate reduction. The mechanism agreed on for 3GPP Rel-9 is the IP-based Explicit Congestion Notification (ECN) specified in an IETF RFC. ECN is a 2 bit field in the end-to-end IP header. It is used as a “congestion pre-warning scheme” by which the network can warn the end points of incipient congestion so that the sending endpoint can decrease its sending rate before the network is forced to drop packets or excessive delay of media occurs. Any ECN-based scheme requires two parts: network behavior and endpoint behavior. The first part had already been fully specified in an IETF RFC106 and merely had to be adopted into the corresponding specifications (3GPP TS 23.401 and 3GPP TS 36.300). The network behavior is completely service and codec agnostic. That is, it works for both IMS and non-IMS based services and for any voice/video codec with rate-adaptation capabilities. The main work in 3GPP focused on the second part: the endpoint behavior. For 3GPP Rel-9, the endpoint behavior has been specified for the Multimedia Telephony Service for IMS (MTSI - 3GPP TS 26.114). It is based on a generic (i.e. non-service specific) behavior for RTP/UDP based endpoints, which is being standardized in the IETF.

Furthermore, it was agreed that no explicit feedback was needed from the network to trigger a codec rate increase. Instead, the Rel-9 solution is based on probing from the endpoints – more precisely the Initial Codec Mode (ICM) scheme that had already been specified in 3GPP Rel-7 (3GPP S4-070314). After the SIP session has been established, the sending side always starts out with a low codec rate. After an initial measurement period and RTCP receiver reports indicating a “good channel,” the sending side will attempt to increase the codec rate. The same procedure is executed after a codec rate reduction.


Figure 6.8 depicts how codec rate reduction works in Rel-9:
  • Step 0. The SIP session is negotiated with the full set of codec rates and independent of network level congestion. The use of ECN has to be negotiated separately for each media stream (e.g. VoIP).
  • Steps 1 and 2. After ECN has been successfully negotiated for a media stream the sender must mark each IP packet as ECN-Capable Transport (ECT). Two different values, 10 and 01, have been defined in an IETF RFC106 to indicate ECT. However, for MTSI only 10 shall be used.
  • Step 3. To free up capacity and allow more VoIP calls and/or to improve VoIP coverage, the eNodeB sets the ECN field to Congestion Experienced (CE) in an IP packet that belongs to an IP flow marked as ECT. Note that the ECN-CE codepoint in an IP packet indicates congestion in the direction in which the IP packets are being sent.
  • Steps 4 and 5. In response to an ECN-CE the receiving MTSI client issues an RTCP message to trigger a codec rate reduction.
Note that ECN operates in both directions (uplink and downlink) entirely independent and without any interactions. It is very well possible to trigger codec rate adaptation in one direction without triggering it in the other direction.

ONGOING WORK IN 3GPP

A new work item called, Enabling Encoder Selection and Rate Adaptation for UTRAN and E-UTRAN, has been created for 3GPP Rel-10. Part of this work item is to extend the scope of the codec rate adaptation solution agreed in Rel-9 to also apply to HSPA and non-voice RTP-based media streams.

Further Reading:
Posted by at
Labels: , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)