Understanding the 3G-324M Spec: Part 1

Eli Orr, Radvision 1/21/2003 5:15 AM EST

When discussing wireless multimedia services, there is quite a bit of space between what people talk about and what's reality. For the past few years, many members of the sector have painted a picture of an all IP wireless network that will seamlessl Understanding the 3G-324M Spec: Part 1 When discussing wireless multimedia services, there is quite a bit of space between what people talk about and what's reality. For the past few years, many members of the sector have painted a picture of an all IP wireless network that will seamlessly stream audio and video over IP links. In reality, however, the all IP network is far from a reality. Today's IPv4 networks are not optimized to handle the delay sensitive applications required on wireless links and do not provide sufficient address space to handle tons of IP-enabled mobiles. At the same time, the high bit-error rates associated with today's wireless links, make the delivery of IP packets difficult, to say the least. While the vision of an all IP wireless network has been pushed out, the promise of a feature-rich, multimedia wireless experience has not. This is due to the emergence the 3G-324M standard, which supports the real-time streaming of wireless multimedia services over existing circuit-switched wireless networks. In this two-part series article, we'll provide a tutorial of the 3G-324M specification. In Part 1, we'll provide an overview of the specification, look at the error resilience and concealment techniques, discuss H.223 multiplexing/demultiplexing, and describe the 3G-324M adaptation layers. In Part 2, we'll examine H.245 support, voice coding/decoding, and the video channel. We'll also provide insight into some real-life implementation issues. Let's kick off our discussion with a look at the problem with delivering multimedia over 3G links. 3G's Inability to Deliver Multimedia Over IP The two main 3G standards bodies, 3GPP & 3GPP2, envision 3G as running entirely over an IP-based communications network (the Internet). However, as stated above, reality has pushed this vision quite a few years out and, with the current telecom downturn, the length of time until 3G is entirely IP-based might be further substantially extended. Granted, there are many current IP-based applications that run well over mobile devices today. However these are all non-delay sensitive services such as multimedia messaging (MMS), MP-3 streaming (with buffering), wireless imaging (JPEG), and other common Internet services such as e-mail, web surfing, and online chatting. Unfortunately, today's IP network has severe limitations in its ability to support, in addition to voice, those delay-sensitive applications, such as PDA-based

videoconferencing and video on demand, which service providers are today looking to roll out to customers. The crux of the problem is that today's IP network (the Internet) is not sufficiently robust for delay sensitive applications and, in fact, will not be so until service providers move to IPv6 and SIP-based IP communications. IP, with its variable transmission delays (many hops of routing processing and congestion delays) and IP packet overheads to carry the codecs data can't deliver conversational multimedia session. Unfortunately IPv6, which will remedy the situation, and is at the crux of a total migration to IP for 3G networks, will take years to be fully deployed and operate at 99.999% reliability. A network that includes a hybrid of IPv6 and IPv4 is not enough, and fully IPv6 deployment is required. There are many hurdles in the process including: IPv6 interoperability issues, protocol maturity, necessary OSS upgrades throughout the Internet, and the development, acceptance and deployment of an IPv6 addressing scheme worldwide. Enter 3G-324M To solve the problems created by an all-IP wireless network, the wireless industry has adopted the 3G-324M spec (Figure 1). 3G-324M supports the real-time streaming of multimedia broadband wireless communications by routing traffic over the circuit switched network, instead of the IP network. Being circuit-switched based, the standard has all the hallmarks of a protocol ideal for streaming real-time multimedia, including a fixed delay, low overhead of codecs, and no IP/UDP/RTP header overheads.

Figure 1: Diagram illustrating the key elements of the 3G-324M spec. The 3GPP standards body, which is responsible for developing the UMTS/WCDMA specifications, defines very specifically the structure and implementation requirements of the 3G-324M standard in two technical specs (TS): TS 26.112 for CS call setup and TS 26.111 for 3G-324M initiation and operational procedures. The 3GPP2 standard body, which developed the cdma200 specs, has also approved a technical spec for 3G-324M operation requirements over CDMA2000 networks called "3GPP2 C.S0042 for Circuit-Switched Video Conferencing Services." The 3G-324M standard is a derivative of ITU's H.324, which was developed for the PSTN and the V.34 modem protocol. H.324 is a tedious protocol for the setup and tear down of videoconferencing sessions over analog phone lines and has been modified for 3G wireless by leveraging the circuit switched network to support the delivery of delay-sensitive applications (video streaming, videoconferencing) to 3G end points today. The protocol does not use addressing but operates only after a mature E.164 addressing method is used by the underlying protocol such as WCDMA to locate party and the call is being setup between the two call peers. The standard uses several sub protocols and technologies to enable call control and multimedia channels operation over a bit stream channel between two communication parties:

Error Resilience Services and Concealment H.223 Multiplexing/Demultiplexing

H.245 Call Control Channel 3G-324M Adaptation Layers H.245 Call Control Channel Voice Channeladaptive multi-rate (AMR) and G.723.1 Codecs Video ChannelH.263 and MPEG-4 Simple Profile Codecs

In this part, we'll examine error resilience and concealment, the adaptation layers, and H.223 multiplexing/demultiplexing. The remaining topics will be covered in Part 2. Error Resilience Services and Concealment The 3G-324M operates in a wireless environment where high bit error rates (BER) occur often during the call session. The base line H.223 defines the multiplexing between the underlying bit stream, the call control, audio, video and data channels. The problems with baseline H.223 can be summarized as follows: 1. 2. 3. 4. 5. Bit errors that break high-level data link controller (HDLC) bit stuffing Flag emulations in the payload Corrupted framing flags Errors in mux-packet header Errors in payload bits

To solve these problems, the mobile group in ITU-T introduced a hierarchical structure into H.223 that features multiple levelslevels 0, 1, and 2that deliver higher levels of error resilience. In the baseline H.223, the HDLC protocol performs the framing of the multiplexed packets. HDLC is commonly used in many fixed data networks. However, variablelength HDLC is not considered robust to transmission errors. The main reason is the transparency procedure, which is needed to provide uniqueness of the framing flags. HDLC encoder provides the uniqueness by adding a stuffing "0"-bit after each five contiguous "1"-bits in the payload. Due to this procedure, HDLC-decoder may lose synchronization with data if transmission errors corrupt the structure of the transparency procedure (problem 1). Another problem with HDLC is that after some bit errors, flag emulations in the payload are very probable, due to the shortness of the framing flag (problem 2). Flag emulations destroy the multiplexed-packet structure and may split the multiplexedpackets in incorrect positions. Bit errors can also corrupt the framing flags hence causing concatenated or lost multiplexed-packets (problem 3). The baseline H.223 from the original H.324 is called level 0, actually this level does not provide any error resilience services. Level 1, defined in H.223 Annex A, replaces HDLC by a more robust framing. In this level, the stuffing bits are removed and the length of the flag is increased. The mobile ad-hoc group selected a 16-bit pseudorandom noise (PN) sequence for the framing flag. As a result, the framing flag is no longer a unique bit pattern, but the problem of flag emulations in the payload is negligible if the probability of it is low enough. The drawback of the longer flag is that it has a higher probability of being corrupted.

Level 2, which is defined by H.223 Annex B, adds a multiplexed-packet header. The framing is the same as in level 1. The role of the header is very important, since it describes the contents of the multiplex packet. Errors in the header may cause misdelivery of layer may be unnecessary overhead most of the time in typical channel conditions. The 3G-324M specification defines Annex A for low BER handling and B for moderate BER handling as mandatory error levels resilience to be support. In addition the mandatory AMR and recommended MPEG-4 codecs provide tools for error resilience to minimize the quality degradation caused by bit errors. The most challenging component in mobile videophone is the video codec. It is generally known that compressed video is very sensitive to transmission errors. Error resilience is essential for the mobile conversational multimedia communication for error detection and concealment on the fly. These solutions do not reduce errors like forward error correction (FEC) and automatic repeat request (ARQ), but can reduce the quality damage on decoded video quality. (Note: We'll discuss more on AMR and MPEG-4 error resilience in Part 2). H.223 Multiplexing/De-Multiplexing Protocol When a 3G-324M protocol is initialized, after a circuit-switched channel is opened between the two communicating parties, the H.223 multiplexing protocol is initiated between parties in the network. Once the multiplexing protocol is initiated, the 3G324M spec calls for the synchronization of the multiplexing process between the communicating parties in order to establish the call control (H.245) as the first logical channel to be openedchannel 0. The basic function of multiplexing protocol is to interleave multiple media streams such as video, speech, user data, and control signals (H.245) into single stream so that it can be sent over a transmission channel. 3G-324M uses ITU-T H.223 mobile extensions of level 2 as its multiplex protocol. H.223 has a flexible mapping scheme suitable for a variety of media and for a variable frame length. In its mobile extension, it obtains synchronization and control stronger against channel errors without losing its flexibility. There are 3 operation modeslevel 0, level 1, and level 2which are chosen according to the degree of error resiliency required in a 3G-324M system. Multiplexing level 0 is identical with H.223 specification, which provides multiplexing, and quality of service (QoS) function appropriate for each media data. Level 0 is made up of an adaptation and a mux layer. The mux layer assembles multiple media packets into single bitstream according to the selected multiplex pattern out of up to 16 multiplex patterns. The mux pattern can be defined arbitrarily through the session negotiation procedure. Header Information is attached to control such a flexible multiplexing mechanism. It consists of 4-bit multiplex code (MC), 1-bit packet marker (PM), and 3-bit parity header error control (HEC). The 3-bit HEC field provides error detection capabilities over the MC field using a 3-bit CRC. Eight-bit high-level data link controller (HDLC) synchronization flags ('01111110') are inserted as a delimiter of mux-packet data units (PDUs).

Stuffing '0' bit insertion after every 5 succeeding 1's is defined to prevent the flag emulation inside the payload. Multiplexing level 1 employs a 16-bit pseudorandom noise (PN) sequence instead of 8-bit HDLC synchronization flag to improve the mux-PDU synchronization over error-prone channels. Stuffing is prohibited to enable octet-oriented flag searches. This modification improves the flag detection performance over error-prone channels remarkably with a slight probability danger of flag emulation conditions in cases of conflict. Multiplexing level 2 adds mux-PDU payload length information and FEC in the header to improve synchronization and error resilience. Furthermore, the multiplexing level can add an optional header field, which includes MC/PM/HEC for the previous frame, to improve error resilience against burst errors through time diversity effects. 3G-324M Adaptation Layers Under the 3G-324M specification, three types of adaptation layers are defined according to the media type (video, speech or data): adaptation layers 1 (AL1), 2 (AL2), and 3 (AL3). Let's look at each in detail. AL1 is designed primarily for the transfer of data or control information. AL1 does not provide any error detection or correction capability. Therefore, the higher layer should provide any necessary error control, possibly including a retransmission procedure. Used for the mandatory H.245 call control that initiated immediately after the bit stream Multiplexing is synchronized between communicating parties and used for optional data channels. This AL assumes that the upper layer provides error control. AL2 is designed primarily for the transfer of digital audio. AL2 provides an 8-bit cyclic redundancy check (CRC) for error-detection. AL2 also supports optional sequence numbering, which may be used to detect missing and misdelivered ALPDUs. AL2 transfers variable-length AL SDUs of integral number of octets. Speech error detection and sequence numbering mechanism are provided. The optional 8-bit sequence numbering (SN) provides a capability for sequencing AL-PDUs. The sequence number may be used by the AL2 receiving entity to detect missing and misdelivered AL-PDUs. AL3 is designed primarily for the transfer of digital video. AL3 includes a 16-bit CRC for error-detection. AL3 also supports optional sequence numbering, which may be used to detect missing and misdelivered AL-PDUs. AL3 transfers variable-length AL SDUs and provides an optional retransmission procedure, designed primarily for video. Video error detection, sequence numbering, and ARQ are provided. On to Part 2 That wraps up the first part of our discussion on the 3G-324M protocol. In Part 2, we'll further the discussion by looking at the audio code, the video codec, and H.245 terminal control. To view Part 2 of the article, click here. About the Author Eli Orr is a product manager in Radvision's Technology Business Unit. He has more

than 18 years in computing systems, the last 10 years focused in the development of IP-based communications systems and technologies. Eli can be reached at eliorr@radvision.com.

Understanding the 3G-324M Spec: Part 2

Eli Orr, Radvision 1/28/2003 3:32 AM EST
The age of an all-IP wireless network could be years away. However, the need for delivering multimedia services over wireless links is at an all-time high. To bridge this gap, the 3GPP and 3GPP2 standards bodies are converging on the 3G324M specific Understanding the 3G-324M Spec: Part 2 The age of an all-IP wireless network could be years away. However, the need for delivering multimedia services over wireless links is at an all-time high. To bridge this gap, the 3GPP and 3GPP2 standards bodies are converging on the 3G324M specification for supporting video transmissions over wireless lines. 3G-324M supports the real-time streaming of multimedia broadband wireless communications by routing traffic over the circuit switched network, instead of the IP network. Being circuit-switched based, the standard has all the hallmarks of a protocol ideal for streaming real-time multimedia, including a fixed delay, low overhead of codecs, and no IP/UDP/RTP header overheads. This is the second installment in our tutorial on the 3G-324M. In Part 1, we explored error resilience and concealment techniques, H.223 multiplexing/demultiplexing, and the 3G-324M adaptation layers. In Part 2, we'll examine H.245 support, voice coding/decoding, and the video channel. We'll also provide insight into some real-life implementation issues. Let's kick off our discussion with a look at the problem with delivering multimedia over 3G links. H.245 Terminal Control Protocol 3G-324M uses H.245 as a terminal control protocol. H.245 is used by H.323 as well as by H.324 for PSTN and by H.310 for ATM. Currently (Q4/2002) ITU H.245 version 9 is ratified by the SG16 of ITU. The oldest version of H.245 that can be supported in a 3G-324M implementation is version 3. However it is highly recommended to support higher version such as 6 or 7 which support by most implantations today or even upper for richer set of call control services of commands and indications. H.245 is fully backward compatible so that higher version can operates with lower version of H.245 and vise versa. Since 3G-324M rides on a channel opened between two communicating parties it does not need any addressing such as in H.323. With this fact, it is expected that the

gateway (e.g. between 3G-324M, H.320, H.323 and SIP) will provide the interoperability between different networks can be realized rather easily. Since H.323 is not needed, H.245 requires the numbered simple retransmission protocol (NSRP) and control channel segmentation and reassembly layer (CCSRL) sublayer support to ensure reliable operation. H.245 requires mobile terminals to support NSRP and SRP modes. If both terminals start the session in level 0, H/245enabled systems must operate in the SRP. If the terminals start a session at level 2, NSRP mode is employed. CCSRL, on the other hand, is used for carrying H.245 large packets required for operation. In addition to providing NSRP and CCSRL support, the H.245 control protocol provides following functionalities and services:

Master-slave determination is provided to determine which terminal is the master at the beginning of the session. Due to the fact that H.245 is symmetric control protocol, it is necessary to decide the master terminal, which has the right to decide the conditions in case of the conflict. Capability exchange is provided to exchange the capabilities both terminal supports, such as optional modes of multiplexing, type of audio/video codecs, data sharing mode and its related parameters, and/or other additional optional features. Logical channel signaling is provided to open/close the logical channels for media transmission. This procedure also includes parameter exchange for the use of this logical channel. Multiplex table initialization/modification is provided to add/delete the multiplex table entries. Mode request is provided to request the mode of operation from the receiver side to the transmitter side. In H.245, the choice of codecs and its parameters are decided at the transmitter side considering decoder's capability, so if the receiver side has a preference within its capability, this procedure is used. Round-trip delay measurement is provided to enable accurate quality characteristic measurement. Loopback testing is provided for use during development or in the field to assure proper operation. Miscellaneous call control commands and indications are provided to request the modes of communication, flow control such as conference commands, jitter indication and skew, or to indicate the conditions of the terminal, to the other side.

H.245 uses the abstract syntax notation 1 (ASN.1) to define each message parameters that provides readability and extensibility effectively. To encode these ASN.1 messages into binary, the packed encoding rule (PER) is used to realize the very bandwidth effective message transmission. As mentioned before after the multiplexing level synchronization between communicating parties is completed the first logical channel opened (channel 0) is H.245 call control with the CCRL and NSRP to assure that the H.245 channel will be highly reliable and can use large packets during operation.

Voice ChannelThe AMR Codec The 3G-324M specifications define the AMR codec as mandatory. 3G-324M also recommends the use of G.723.1, which is used by many H.323 terminals today. The AMR codec was originally developed and standardized by the ETSI for GSM cellular systems. The AMR codec, rolling out in networks and terminals, dynamically adjusts the amount of bits allocated to voice coding and error control, providing the best possible voice quality at each instance based on radio conditions. AMR significantly enhances the effectiveness of frequency hopping and tighter reuse patterns by allowing a greater percentage of radio channels to be in use simultaneously, resulting in an additional capacity gain of about 150%. AMR was chosen by 3GPP as the mandatory codec for 3G cellular systems. The AMR codec includes eight narrowband codec modes: 12.2, 10.2, 7.95, 7.4, 6.7, 5.9, 5.5 and 4.75 kbit/s. It also supports comfort noise (CN) for a discontinuous transmission (DTX) operational mode. Besides the adaptation of rate, the AMR codec also supports unequal bit-error detection and protection (UED/UEP). The UEP/UED mechanisms allow more speech over a lossy network by sorting the bits into perceptually more and less sensitive classes. A frame is only declared damaged and not delivered if there are bit errors found in the most sensitive bits. On the other hand, acceptable speech quality results if the speech frame is delivered with bit errors in the less sensitive bits, based on human aural perception. An important characteristic for high BER environment such as wireless network is AMR's robustness for packet loss, through redundancy and bit errors, sensitivity sorting. Another benefit of AMR is the adaptive rate adaptation for switching smoothly between codec modes on the fly. The Video Channel The 3G-324M standard calls out the H.263 codec as mandatory and MPEG-4 as recommended codec for video processing. However, MPEG-4 is the 3G-324M standard de-facto used by all major supporting vendors. Resiliency and high efficiency make MPEG-4 codec particularly well suited for 3G-324M. H.263 is a legacy codec that is used by many existing H.323 wire lined devices. MPEG-4 is much more flexible and offers advanced error detection and correction services, which are a big value add when delivering video over a wireless network. Let's look at the error detection and correction services in more detail. When supported, 3G-324M says that MPEG-4 visual codecs shall support simple profile 1 level 0. MPEG-4 visual (ISO/IEC 14496-2) is a generic video codec. One of its target areas is mobile communications. Error resiliency and high efficiency make the MPEG-4 visual codec particularly well suited for 3G-324M. MPEG-4 visual is organized into profiles. Within a profile, various levels are defined. Profiles define subsets of tool sets. Levels are related to computational complexity. Among these profiles, the simple visual profile provides error resilience (through data partitioning, RVLC, resynchronisation marker, and header extension code) and low complexity. MPEG-4 allows various input formats,

including general formats such as QCIF and CIF. It is also baseline compatible with H.263. As stated above, error resilience is achieved through resynchronization, byte alignment, data partitioning the reversible variable length code (RVLC), adaptive intra refresh (AIR), and error detection and concealment. Let's look at each of these in more detail. 1. Resyncrhonization: Under the MPEG-4 spec, a resynchronization marker can reduce the error propagation caused by the nature of variable length code (VLC) into single frame. In MPEG-4, the resynchronization marker is inserted at the top of a new group of blocks GOB with the header information (multiplexed block number [MBN], quantization parameters) and optional HEC, so that decoding can be done independently. It is a good idea to place the resynchronization marker prior to important objects like people to improve error resilience with minimum increase of overhead. 2. Byte alignment: Bit-stuffing for the byte alignment gives additional error detection capability through its violation check. 3. Data partitioning: A new synchronization code named motion marker separates the motion vector (MV) and discrete cosine transform (DCT) field to prevent from interfield error propagation, thus allowing effective error concealment to be performed. When errors are detected solely in the DCT field, that multiplexed block (MB) will be reconstructed using correct MV. This results in natural motion better than simple MB replacement of the previous frame. 4. RVLC: The RVLC enables forward and backward decoding without significant impact on coding efficiency. This feature localizes error propagation ideally into single MB. 5. AIR: Different from the conventional cyclic intra refresh, AIR employs motionweighted intra refresh, which results in better perceptual quality with quick recovery in corrupted objects. 6. Error detection and concealment: Errors can be detected through exception or violation in the decoding process, and then concealment will be applied. The functionality is included for mobile application. The endpoint of H.324 can support for MPEG-4 audio, so that MPEG-4 audio could be used for H.324 mobile phone terminal. Integrating 3G-324M With Other Multimedia While 3G-324M is a straightforward protocol to implement in end devices and media servers, designers will face challenges making 3G-324M with other protocols such as H.323 and SIP. Let's look at this issue in more detail. H.323 is based on Q.931 for call setup and H.245 for call control. 3GPP defines TS.26.112 for call setup procedure in UMTS. The interworking device shall map theTS-26.112 call setup into Q.931 H.323 calls and vise versa. For call control mapping, since both protocols uses H.245 the mapping is trivial, however the H.245

in 3G-324M is addressless. Thus a transcoding function may also be required to ensure that 3G-324M works with various H.323 devices supporting codecs such as H.261 and H.263. SIP is based of session description protocol (SDP) for both call setup and call control. Hence both TS 26.112 and 3G-324M H.245 call control should be mapped into SDP messages and vise versa. Again a transcoding functions may be required to ensure that 3G-324M systems work with SIP-based systems. Editor's Note: To view Part 1 of this article, click here. About the Author Eli Orr is a product manager in Radvision's Technology Business Unit. He has more than 18 years in computing systems, the last 10 years focused in the development of IP-based communications systems and technologies. Eli can be reached at eliorr@radvision.com.