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.
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 W-CDMA 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:
- 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, variable-length 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 multiplexed-packets 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 mis-delivery 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 3G-324M 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 AL-PDUs. 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 email@example.com.