---

3G Video Telephony is powered by a protocol called 3G-324M. 3G-324M is circuit-switched based, so everything you send is sent as a single bitstream at a fixed bitrate of 64 kilobits per second. On that single connection, you can send voice, video, data and signaling. Since there’s not a lot of room 3G-324M uses a very efficient multiplexer protocol called H.223. The only problem is that implementing it properly isn’t that easy.

For that purpose, RADVISION has developed an efficient mechanism. This invention was just recently granted a patent, so I can explain it in some details. I apologise in advance for being a little bit technical in this post.

How H.223 works

The figure below shows most of the story behind H.223 multiplexing:

Media streams in an H.223 Multiplexer

Multiple data streams - in this example, a microphone and a video camera generate data, which is encoded (AMR for audio, MPEG-4 for video), wrapped with an adaptation layer framing mechanism (generating AL-PDUs), and then multiplexed into a bitstream.

In a multiplexed bitstream there are usually at the very least 3 different streams - control, audio and video, with an optional additional data channel and secondary video channel. All these go into the H.223 multiplexer which has the task of selecting what streams to use to build the next MUX-PDU (multiplexer payload data units - the data unit it sends out).

To use as little bandwidth as possible H.223 uses a short header for MUX-PDUs, which holds the type of data sent in that PDU. It usually selects to send data from a single data stream or from multiple streams.

Possible selection options tend to be sending audio only, video only or audio in a specific size with additional video concatenated to it. The type of data sent is defined by a 4-bit value which indicates an entry to the multiplexer table (which is 16 entries long). Selecting the best entry to use at each given moment is not an easy task.

Hurdles of selecting a multiplexer entry

To select the best entry, several different things need to be taken into consideration:

1. What do we have available for sending in the internal queues from each data stream?
2. What priority would we like to “enforce” on these pending data streams?
3. Which entries do we have that can follow this “enforcement” in the best possible way?

Most multiplexer implementations will a have linear loop implementation to implement this selection mechanism. The loop goes over the entries available, for each one checking the following:

• Do we have data pending for the streams supported by this entry?
• If we do, then it checks if it is better than what we found so far

A rough flow chart for the above described loop would be:

H.223 entry selection - the “naive” way

The problem with this approach is that it’s both time and memory consuming. For each MUX-PDU (at a rate of about 50 per second), you loop through entries, each time checking all data queues for pending buffers and trying to make logical decisions to maximize output.

Apparently there’s a better way of doing that.

The patent

Into the development of our own 3G-324M stack, we decided that the above is unacceptable. We wanted an o(1) algorithm with no loops. For that purpose we came up with a set of 2 small lookup tables, that - with less than 200 bytes of memory - are capable of providing the best entry number to use for multiplexing simply by knowing what types of data it has pending for sending.

The way it is done is by aligning the size of the next pending audio frame with the other data types we have pending, as the first priority is ensuring speech quality.

The concept behind the two stage approach

This allows making the decision in o(1) by looking into two small static tables in memory and getting to the best results. We have this algorithm available and running in our 3G-324M stack.

There is an additional side effect which this technique brings - the overhead of the multiplexing headers is reduced, giving the application a bit more bandwidth for media.

The result: More battery life

Once you take this road, you use less CPU for this decision making process. As this technology is used for 3G video telephony on mobile handsets, battery life - which is a sore spot for using VoIP over cellular networks - is of first priority. Reducing the CPU used by the H.223 multiplexer and the video codec means more battery life for the user.

Further reading

If you are interested in 3G-324M, I suggest the following whitepapers from RADVISION:

• Reducing call setup time with WNSRP
• The Unified WNSRP-ACN Solution - this one explains how MONA ACP works
• Overcoming the 3G-324M call setup time challenge - an overview of all call setup time reduction techniques available in the 3G-324M standard