Cellular Backhauling Optimization

Yaakov (J) Stein Chief Scientist RAD Data Communications, Ltd.

Cellular communications

cell site air interface

Base Transmitter Station Mobile Station

To most people cellular communications means only the air interface This is the Radio Frequency link between MS and BTS

Cellular networks
But there is a lot more to the cellular network than that ! Using GSM (2G) terminology : All the Base Transmitter Stations are to Base Station Controllers The BSCs are connected to Mobile Switching Centers MSCs are interconnected, and also connected to the Public Switched Telephony Network
BTS
BTS BTS BTS BTS BTS BTS BTS

BSC

PSTN
BSC MSC

BSC HLR VLR

MSC

BTS

Cellular backhauling
We (informally) call all of the network except the air interface the cellular backhaul network Backhauling of 2G cellular traffic uses TDM (E1/T1) links over : Copper Fiber Microwave Due to rapid worldwide increase in cellular penetration backhauling is one of the hottest topics in the telecommunications industry To reduce operational expenses, cellular operators want to : reduce bandwidth consumption migrate to (less expensive) Packet Switched Networks (IP/MPLS/Ethernet) employ less expensive transport types, for example Metro Ethernet Networks DSL links Reduction of bandwidth (optimization) for 2G GSM is the main topic of this talk

Cellular backhaul optimization

Voice traffic is already compressed by the mobile station So why can cellular traffic be optimized at all ? TDM transport mechanisms can not reduce bandwidth standard user traffic (TRAU) formats are extremely inefficient nonactive user channels are sent silence/idle frames in active channels are sent signaling channels (HDLC-based) are inefficient data can be compressed by lossless data compression additional mechanisms (e.g. stronger compression) may sometimes be used

ACE-3xxx

Cellular backhaul transport

When TDM transport (e.g. E1 links) is used optimization enables use of fewer E1s to carry the same amount of user traffic reduced operational expense at dense portions of network however, compressed traffic formats are not standardized When TDM transport is replaced with Packet Switched Networks service less expensive to begin with service often charged by bandwidth used optimization enables using only the minimum BW needed operational expense reduced

GSM 2G architecture
Um interface RF Abis interface TDM A / Ater interface TDM BF interfaces

BTS
Base Station Subsystem

BSC

MSC

Network and Switching Subsystem

servers and other networks

GSM formally separates the Public Land Mobile Network into subsystems and defines the interfaces / protocols between each two pieces of equipment A-type interfaces carry the voice traffic in the backhaul portion of the network A interface is a standard TDM link divided into 64 kbps timeslots Abis interface connects the BTS to the BSC and carries FR or HR channels Ater interface connects the BSC to the MSC and carries FR or HR channels A-type interfaces also carry control information

Carrying A-type interfaces over PSN

Abis interface TDM

pseudowire (PW)
cellopt GW cellopt GW

Abis interface TDM

BTS

PSN

BSC

Cellular operators can transport Abis/Ater over PSNs instead of TDM To do this without forklift upgrade of their equipment to 3G they can use pseudowire (PW) technology A PW emulates a native service by building a tunnel through the PSN Bandwidth reduced as compared to TDM with optimization, bandwidth can be further reduced

Voice channels
Although over time new services were added Fax Short Message Service Multimedia Message Service Wireless Application Protocol Internet and WWW access Video streaming the cellular network was originally designed for voice traffic A GSM transmitter segments voice into 20 millisecond frames And applies compression to place voice traffic into one of two channel types Full Rate channel - 16 kbps = 2 bits every 1/8000 sec. = 320 bits per 20 ms. Half Rate channel - 8 kbps = 1 bit every 1/8000 sec. = 160 bits per 20 ms. There are various compression algorithms Full Rate codec - 13 kbps (FR channel) Enhanced Full Rate codec - 12.2 kbps (FR channel) Half Rate codec - 5.6 kbps (HR channel) Adaptive MultiRate - 4.75, 5.15, 5.9, 6.7, 7.4, 7.95 (HR or FR channels) - 10.2, 12.2 kbps (FR channel)

TRAU frames
The compressions and format conversions in the network are performed by the Transcoder and Rate Adaptation Unit Information on the A bis and A ter interfaces is encoded in TRAU frames TRAU voice frames represent 20 ms. of audio FR channels - TRAU frames are 320 bits = 40 bytes HR channels - TRAU frames are 160 bits = 20 bytes The TRAU frames are transported over FR and HR channels

TDM (E1) frame (256 bits)

. . .
2 bit FR timeslots 1 bit HR timeslots

idle = 01 alarm = 00

Note that a full E1 (2 Mbps) must be used even when there are very few channels

8 bit TDM timeslots

TRAU framing
The TRAU frames have a specific frame structure that must be detected For example, this is the framing of the generic FR (40 byte) TRAU frame :
00000000 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 00000000 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxTTTT

And this is the generic HR (20 byte) TRAU frame :

00000000 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 01xxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxTT

x bits are data / control and are not part of the framing bits are for time alignment (justification)
T

Note: there are other frame formats as well

Abis signaling channels

It is very important not to delay or corrupt special signaling channels Ater signaling channels are based on SS7 Abis signaling channels are not completely standardized each equipment vendor has its own signaling format Abis Signaling channels can be 16 kbps (2 bits per TDM frame) 32 kbps (4 bits per TDM frame) 64 kbps (a full 8 bit TDM timeslot) Signaling is usually HDLC based, with a frame format :
flag address ctrl DATA CRC flag

The frame between flags (7E hex) is bit-stuffed Between frames there may be flags or other filling

Backhauling data
User data can be transported over the Abis interface in various ways Low rate data (up to 9.6 or 14.4 kbps) is transported in TRAU frames Intermediate rates (up to 114 kbps) are available via GPRS (2.5G) Higher rates (theoretically up to 384 kbps) via EDGE (2.75G) GPRS / EDGE are carried over G-type interfaces which may share the same TDM link as A-type interfaces GPRS/EDGE bandwidth allocation may be dynamic it takes over bits not used by the A-type interfaces In 3G networks data can be much higher rate (over 2 Mbps, e.g. 10 Mbps) carried over I-type interfaces that use separate transport media

GSM 2.5G architecture

A bis Um

(GPRS/EDGE)
A / A ter

BSC BTS
BSS Gb

NSS-CS Gn

MSC

SGSN

NSS-PS

GGSN

The first high-speed GSM data (WAP, PTT, MMS, WWW) service was the Generalized Packet Radio Service It provides 56 kbps - 114 kbps packet data for IP communications The air interface is enhanced, but won't be discussed here To the GSM backhaul architecture is adds Serving GPRS Support Node Gateway GPRS Support Node G interfaces The next stage is Enhanced Data for Global Evolution (AKA Enhanced GPRS)

3+G architectures
Uu RF User Equipment Iu - CS Iub

PSTN 3G-MSC PDN

Node B
UTRAN

RNC

Iu - PS

Core 3G-SGSN

In initial 3G releases Iu interfaces are based on ATM (Iu-CS:AAL2, Iu-PS:AAL5) In the final phases, the network becomes IP and the protocols become VoIP At that point the window of opportunity for optimization closes

1st challenge - channel detection

Voice/data/signaling information appears at various places in the frame Were we to understand the proprietary signaling we would know where to look for the various channels but this signaling is vendor-dependent and the formats are not always known So we need to employ an intelligent detector/classifier/deframer detect channel framing and return field positions classify channel as voice/data/signaling/idle/unknown maintain relative synchronization Matching framer at egress needs to recreate the original frames

TDM sync 64K data FR voice FR voice HR voice signaling 32K data

Channel detector/classifier
This detector/classifier needs to continually scan all 1-bit positions for HR TRAU frames even aligned 2-bit fields for FR TRAU frames even aligned 2-bit fields for HDLC nibble-aligned nibbles for HDLC byte-aligned octets for HDLC fields of idle bits anything else and then return the identifications and positions found Unidentified non-idle information must be reliably transported The processing involves searching for specific bit combinations performing bit correlations and is extremely computationally intensive Can be performed by a DSP with good bit-oriented operations

2nd challenge - optimization

Once the various components have been found the information needs to be reduced in size and reliably transported Idle fields need not be sent, often accounting for a large BW reduction TRAU framing overhead may be removed Voice frames marked as silent (DTX) may be suppressed Voice Activity Detection may be employed to suppress silence HDLC flags are removed and the contents destuffed Data may be compressed

We will deal with each of these in turn

3rd challenge - data compression

Data is typically transported over cellular networks in uncompressed form Lossless data compression algorithms, e.g. Ziv-Lempel variants Huffman codes / arithmetic codes Shannon-Fano coding Burrows-Wheeler Transform Prediction by Partial Match can be an effective optimization method when there is a significant amount of data traffic Text data, such as HTML or WML, can be significantly compressed Compressed video, binary files, encrypted data, etc. can not be compressed

Using data compression

Many algorithms perform well when there is a lot of data The problem is that the impact of packet loss must be taken into account If we compress each packet separately there is not enough data for efficient compression If we keep history from previous packets we need to separate flows we need to store state loss of single compressed packet causes multiple packets to be discarded DSPs can be exploited to handle data compression main limitation - large amount of memory needed Need a DSP with efficient bit/byte-oriented operations

4th challenge - trans-rating

Audio / video streams are already compressed Further compression may not be possible However, sometimes there are hard bandwidth limits (caps) and we must be able to survive short bandwidth peaks In certain instances trans-rating may be useful at the expense of reduced perceived quality especially when exceeding the cap is expected to be extremely rare For example change compression rate for AMR family on a frame-by-frame basis transcode EFR codec down to a lower AMR rates and transcode back up at network egress

Smart trans-rating
The simplest (but most computationally intensive) way to trans-rate is to cascade a decoder and an encoder For a particular pair of codecs there may be better ways, with lower computational complexity lower delay less perceptual degradation For AMR, there are commonalities that may be exploited However, reserving DSP computational resources is usually not economically justifiable for a process that will only be used for short bandwidth peaks Other mechanisms may be more affordable, such as smart frame drop

5th challenge - smart frame drop

Sometimes transport traffic bandwidth has a hard cap If this cap is exceeded, voice frames will be discarded The TRAU will employ Packet Loss Concealment techniques that cover up much of the effect generally there will still be noticeable impact on the user experience A smarter technique is smart selective frame drop (extended VAD)

Smart frame drop

Instead of dropping randomly chosen voice frames we can carefully select the frames to drop using a criterion of least perceptual quality degradation The selection can be based on voice parameters in the TRAU frame without full decoding of the voice coding The resulting DSP code is codec-dependent requires saving of state information per channel but does not require large amounts of memory The smart frame drop mechanism should be tightly coupled controlled to the main control function so that only the minimal percentage of frames are dropped

6th challenge - timing recovery

TDM's physical layer transfers accurate frequency (sync) information GSM BTSs use the accurate frequency recovered from the TDM link to generate accurate radio frequencies generate symbol timing send time offset information to mobile stations ensure short handover when moving from cell to cell CDMA and 3G cellular systems also need accurate Time Of Day Requirements are stringent : absolute frequency accuracy must be better than 50 ppb jitter and wander need to conform to ITU TDM standards 3G stations need time accuracy of better than s3 Qs 3G TDD mode requires time accuracy of better than s1.25 Qs from UTC When replacing TDM links with PWs over PSNs we lose timing information

Frequency measures
Frequency needs to be stable and accurate
f stable not accurate not stable not accurate f accurate but not stable f f stable and accurate time

time

time

time

and there may be both frequency jitter and wander

Jitter = short term timing variation (i.e. fast jumps - frequency > 10 Hz) Wander = long term timing variation (i.e. slow moving - frequency < 10 Hz)

jitter is easy to filter out - the real problem is wander

PSN - Delay and PDV

PSN

transmission times may be uniform

but arrival times are not uniform

TDM frequency distribution is based on constant bit rate Packets in PSNs may be sent at a constant rate but PSNs introduce Packet Delay Variation PDV makes frequency recovery difficult

Jitter Buffer
Jitter Buffer

PSN

transmission times may be uniform

but arrival times are not uniform

Data from arriving packets are written into a jitter buffer Once buffer is 1/2 filled, we read from buffer and output to Abis interface Data is read from jitter buffer at a constant rate - so no jitter But how do we know the correct rate ? How do we guard against buffer overflow/underflow ? We need a frequency recovery algorithm

Frequency recovery
Packets are injected into network ingress at times Tn The source packet rate R is constant Tn = n / R The PSN delay Dn can be considered to be the sum of typical delay d and random delay variation Vn The packets are received at network egress at times tn tn = Tn + Dn = Tn + d + Vn By proper averaging/filtering tn " = Tn + d = n / R + d and the original packet rate R has been recovered Unfortunately, simple averaging would be much too slow By the time the accuracy would be sufficient, the rate would have wandered In such cases control loops (PLL, FLL) are commonly used but the noise is much higher here than in usual cases where PLLs are used and changing frequency to compensate for inaccuracy causes wander

Frequency recovery algorithms

Early solutions relied on : linear regression augmented PLLs FLL - PLL hybrids More sophisticated implementations exploit : parameter estimation and tracking oscillator modeling network modeling system separation Although the algorithms may be complex they run at a relatively low rate (tens of times per second) and can thus be run on a DSP

Summary
Cellular backhaul optimization enables more efficient use of overloaded transport infrastructures lowering of OPEX Cellular optimization is applicable to 2G and 2.5G networks There are many challenges to building an operational system channel detection, classification, and deframing packet-loss-tolerant data compression smart trans-rating smart selective frame drop timing recovery DSPs provide a good platform for meeting these challenges

For more information, visit www.RAD.com