Guest

RAN Optimization

Cisco Offers IP RAN Optimization Congestion Management for GSM and UMTS

  • Viewing Options

  • PDF (528.5 KB)
  • Feedback
The Cisco ® IP RAN Optimization solution introduces IP to the RAN network that has traditionally been TDM. Cellular providers have been using TDM based networks to backhaul the traffic from the cell site to the Mobile Telephone Switching Office (MTSO) since deploying their networks for the first time. GSM Abis and UMTS Iub deal with the TDM backhaul in different ways so we have different congestion management solutions for each one. We must address them separately.
The first level of handling congestion in Cisco IP RAN is implementing Cisco IOS ® Software quality of service (QoS). The QoS configured for Cisco IP RAN is Low Latency Queuing (LLQ) with Class Based Weighted Fair Queuing (CBWFQ). The LLQ feature brings strict priority queuing (PQ) to CBWFQ. Strict PQ allows delay-sensitive data such as voice to be dequeued and sent before packets in other queues are dequeued. Without LLQ, CBWFQ provides weighted fair queuing based on defined classes with no strict priority queue available for real-time traffic. We configure a single LLQ to handle all the voice and circuit-switched data for both 2G and 3G networks. The remaining default queue is for the rest of the traffic, packet-switched data, and any other IP traffic. After defining the two queues, one as priority queuing and the other as a default queue, we assign bandwidth percentage values to each. The priority queue is given 99 percent of the available bandwidth and the default queue the remaining bandwidth that is not used by the priority queue. This configuration guarantees that voice and circuit switched data is given all the bandwidth required to transmit the voice as quickly and jitter-free as possible. Packet-switched data then uses the remaining bandwidth. If no bandwidth is available for the default queue, that traffic is dropped, thus not impacting the priority queued real-time traffic (voice).
By correctly configuring the QoS in the Cisco IP RAN solution, we can successfully avoid the need of the GSM and UMTS congestion management features in the majority of congestion scenarios. Please see the MWR 1941-DC-A Configuration Guide for examples on correctly configuring the QoS in the solution.
For more detailed information on these features discussed above, please refer to the chapter on Cisco IOS Quality of Service Solutions in the Configuration Guide.

GSM Congestion Management

By introducing IP into the RAN, we move from the traditional fixed resources of TDM architecture to one of shared RAN bandwidth resources. In the traditional TDM network, the operator managed backhaul resources using an Abis map. The Abis map allowed the operator to map fixed radio resources to fixed TDM DS-0s. If the operator added radio resources to the cell site, TDM resources also had to be added. This led to a very fixed 1 to 1 mapping of radio and TDM resources.
With the introduction of IP in the RAN, many operators that are comfortable with TDM resources now must understand how to manage the shared bandwidth IP provides. There is no longer the mapping of radio resources to TDM resources on the RAN. Now from the MWR at the cell site to the ONS 15454 at the MTSO, we have to share fixed bandwidth. The Cisco IP RAN Optimization solution gives the operator the ability to provision more radio resources to the same amount of bandwidth they already had in place.
If the MWR or ONS RAN Service module reaches utilization where more RAN bandwidth is required than available , a congested state could occur on the IP RAN. In the rare case that this happens , IP packets are dropped and affect some or all sub rates, including voice/data and signaling sub rates on the RAN. This is a new problem for cellular operators. If enough IP packet drops occur on the IP RAN, the signaling channels of the BTS could be affected ; the BTS may timeout and reset requiring operator intervention. Because of the remote possibility of this occurring in the field, the Cisco IP RAN Optimization solution implemented a GSM congestion management scheme that allows the operator to protect a small number of timeslots during a congested state.

How GSM Congestion Management Works

Detecting Congestion on the Backhaul

Both the MWR and ONS RAN Service module store GSM packets they receive from the backhaul in a buffer known as the transmit jitter buffer before converting them to TDM for transmittal on the shorthaul. Once GSM Congestion Management is enabled on the MWR and ONS RAN Service module, each device monitors the level of this buffer. If the transmit jitter buffer level shrinks, it means that backhaul packets are not arriving quickly enough to fill the transmit jitter buffer. This could indicate backhaul congestion.
If the transmit jitter buffer becomes less than 50 percent full, the router begins sending backhaul packets with a congestion indicator bit set to signal congestion may be present to the remote. When the remote receives this congestion indication, it stops transmitting all timeslots across the backhaul except those which the provisioner has configured as critical. When the jitter buffer returns to 50 percent or more filled, it indicates to the remote peer that the congestion event is over, and the remote peer begins to reintroduce the eliminated timeslots back into the backhaul packets.
Figure 1 is an example of detecting congestion with a default jitter buffer of 4 msec (2 buffers).

Figure 1.

In Figure 1, we see the transmit jitter buffer already contains two packets waiting to be sent to the BTS. At time t=0ms we receive a GSM interrupt from the serial link connected to the BTS (S0/0:0). After this interrupt, we check the transmit jitter buffer size and see if it is at 50 percent of the maximum. In this case it is not (txJitterBufSz = 2), so we send a backhaul IP packet to the remote peer with the Congestion Indicator set to 0 (congestionInd=0) signaling that no congestion has been detected. We now transmit GSM out S0/0:0, thus taking a packet out of the jitter buffer and reducing its size to 1 (txJitterBufSz = 1). After that we receive an IP backhaul packet and process it filling the jitter buffer back up to 2 (txJitterBufSz = 2).

Figure 2.

In Figure 2, we see the transmit jitter buffer contains two packets waiting to be sent to the BTS. At time t=2ms we receive a GSM interrupt from the serial link connected to the BTS (S0/0:0). After this interrupt, we check the transmit jitter buffer size and see if it is at 50 percent of the maximum. In this case it is not (txJitterBufSz = 2). Therefore we send a backhaul IP packet to the remote peer with the Congestion Indicator set to 0 (congestionInd=0). We now transmit GSM out S0/0:0, thus taking a packet out of the jitter buffer and reducing its size to 1 (txJitterBufSz = 1). At this point, one of the backhaul packets is delayed due to congestion, and the transmit jitter buffer still has only one packet in it (txJitterBufSz = 1).

Figure 3.

In Figure 3, we see the transmit jitter buffer has one packet in it waiting to be sent to the BTS. At time t=4ms we receive a GSM interrupt from the serial link connected to the BTS (S0/0:0). After this interrupt, we check the transmit jitter buffer size and see if it is at 50 percent of the maximum and in this case it is (txJitterBufSz = 1) ; therefore we send a backhaul IP packet to the remote peer with the Congestion Indicator set to 1 (congestionInd=1) indicating that congestion has been detected. This causes the remote peer to drop all but the critical timeslots. We now transmit GSM out S0/0:0, thus taking a packet out of the jitter buffer and reducing its size to 0 (txJitterBufSz = 0). After that we receive an IP backhaul packet and process it filling the jitter buffer back up to 1 (txJitterBufSz = 1).

Figure 4.

In Figure 4, we see the transmit jitter buffer has one packet in it waiting to be sent to the BTS. At time t=6ms we receive a GSM interrupt from the serial link connected to the BTS (S0/0:0). After this interrupt, we check the transmit jitter buffer size to see if it is at 50 percent of the maximum. In this case it is (txJitterBufSz = 1) . Therefore we send a backhaul IP packet to the remote peer with the Congestion Indicator set to 1 (congestionInd=1) indicating that congestion has been detected. We now transmit GSM out S0/0:0, thus taking a packet out of the jitter buffer and reducing its size to 0 (txJitterBufSz = 0). After that we receive a late IP backhaul packet and an on-time IP backhaul packet processing both packets, thus filling the jitter buffer back up to 2 (txJitterBufSz = 2).

Figure 5.

Figure 6.

Based on the default jitter buffer size of 4 msec (2 buffers), the IP RAN Optimization solution detects congestion at the last minute. With this default setting, by the time congestion is detected and the routers react , the congestion has already impacted the performance of the solution. Because of this, Cisco recommends that the transmit jitter buffer be increased to 8 ms (4 buffers) when deploying the solution with GSM congestion management. This allows the solution to detect and react to the congestion before it has time to impact the overall performance of the solution.
There are also two timers involved in GSM congestion management. The congestion onset and congestion abate timers. The onset timer is the time period the router waits while congestion is detected (congestionInd=1) before declaring a state of congestion on the backhaul link. The default value for the onset timer is 100 milliseconds. Once congestion is declared, the router transmits only those timeslots that are configured as protected timeslots. All other timeslots in the channel group will not be transmitted in the backhaul packets until congestion has cleared. The abate timer is the time period the router waits once congestion is no longer detected (congestionInd=0) before it declares congestion has cleared. The default time for the abate timer is 250 milliseconds. Once the abate period has passed, the router will begin transmitting the non-protected timeslots in the channel group again. These non-protected timeslots are slowly added back to the backhaul packets once congestion has cleared to prevent the backhaul going into congested state immediately because of the flooding of timeslot samples on the backhaul. Adding the non-protected timeslots slowly into the backhaul packets prevents the possibility of a cyclic congested/non-congested behavior.
Starting with 12.4(6)MR, the jitter Buffer is automatically adjusted to 8ms when congestion is enabled.

Configuring GSM Congestion Management

Note: The GSM congestion management feature was designed to handle brief peaks in GSM utilization. It is not designed to support call admission control types of applications.

Before configuring congestion management, the Abis map of the cell site must be examined to determine which timeslots on the T1/E1 are protected. All radio vendors can provide some form of an Abis map. A sample Abis map is shown below:

Nokia Abis Map Example

TSL

Bits

 

1            2

3            4

5            6

7            8

1

TCH0

TCH1

TCH2

TCH3

TRX1

Cell A

 

2

TCH4

TCH5

TCH6

TCH7

 

3

TCH0

TCH1

TCH2

TCH3

TRX2

 

4

TCH4

TCH5

TCH6

TCH7

 

5

TCH0

TCH1

TCH2

TCH3

TRX3

 

6

TCH4

TCH5

TCH6

TCH7

 

7

TCH0

TCH1

TCH2

TCH3

TRX4

Cell A

 

8

TCH4

TCH5

TCH6

TCH7

 

9

TCH0

TCH1

TCH2

TCH3

TRX5

 

10

TCH4

TCH5

TCH6

TCH7

 

11

TCH0

TCH1

TCH2

TCH3

TRX6

 

12

TCH4

TCH5

TCH6

TCH7

 

13

TCH0

TCH1

TCH2

TCH3

TRX7

Cell C

 

14

TCH4

TCH5

TCH6

TCH7

 

15

TSL

TSL

TSL

TSL

EDAP for TRX1 to 7

 

16

TSL

TSL

TSL

TSL

 

17

TSL

TSL

TSL

TSL

 

18

TSL

TSL

TSL

TSL

 

19

TRX SIG1

 

TRX SIG2

 

Signaling

 

20

TRX SIG3

 

TRX SIG4

   

21

E911

     

911 Signaling

 

22

TRX SIG5

 

TRX SIG6

 

Signaling

 

23

TRX SIG7

 

OMU

   

24

Q1

 

Free

Free

Q1 BSC

 

After examining this particular Abis map , the timeslots that have to be protected are 19, 20, and 22-24. They are the basic signaling timeslots for the BTS and TRXs. By protecting these timeslots, you help ensure that even during a peak utilization period the BTS does not reset. If the ability to place a limited number of calls during the congestion were desired, you would protect a few of the TCH timeslots. The configuration for this example would look like this:

Cell Site Configuration

interface Serial0/0:0
no ip address
encapsulation gsm-abis
gsm-abis local 10.10.10.2 4000
gsm-abis remote 10.10.10.1 4000
gsm-abis congestion enable
gsm-abis congestion critical 19-20
gsm-abis congestion critical 22-24
gsm-abis congestion onset 100
gsm-abis congestion abate 250
gsm-abis set dscp ef

MTSO Configuration

interface Serial0/0:0
no ip address
encapsulation gsm-abis
gsm-abis local 10.10.10.1 4000
gsm-abis remote 10.10.10.2 4000
gsm-abis congestion enable
gsm-abis congestion critical 19-20
gsm-abis congestion critical 22-24
gsm-abis congestion onset 100
gsm-abis congestion abate 250
gsm-abis set dscp ef
You can see from the configuration above that timeslots 19-20 and 22-24 have been protected. Those are the signaling timeslots for this Nokia BTS.

Note: "gsm-abis congestion onset/abate" are not displayed in the configuration if the values are left at 100 and 250 respectfully because those are the default values.

An important note here is the configuration is for this particular Abis map only. Each cell site will have a different Abis map and radio vendors map the signaling, voice, data and OAM differently. One vendor of note is Ericsson; they don't have dedicated signaling timeslots, but dynamically mix them into voice/data timeslots. Ericsson BTSs dynamically assign signaling channels within a range of timeslots on the Abis map. You can determine that range and protect the timeslots in that range. This will protect the signaling channels and some voice channels. Most other radio vendors reserve complete timeslots for signaling that makes protecting them easy.

UMTS Congestion Management

Like GSM RAN, UMTS is moving from a fixed resource ATM architecture with different classes of service (CoS) and cell rates for permanent virtual circuits (PVC) to shared RAN bandwidth. In the UTRAN, backhaul bandwidth resources are mapped as cell rates and CoS and managed across one or more T1/E1s. If more than one T1/E1 is used when connecting the Iub interface, ATM IMA is implemented.
Operators are learning that, with the introduction of IP backhaul and the converged 2G and 3G backhaul, there is a possibility of congestion on the backhaul. There is no longer a direct 1 to 1 mapping of the T1/E1 links in the UTRAN as before.
If the MWR or ONS RAN Service module reaches utilization where more RAN bandwidth is required than available, a congested state could occur on the IP RAN. In the rare case that this happens, IP packets would be dropped, affecting some or all the PVCs. This is a new problem for cellular operators. Because of the remote possibility of this occurring in the field and impacting voice quality/data throughput, Cisco IP RAN Optimization solution implemented a UMTS congestion management solution that allows the operator to protect certain PVCs during a congested state.

How UMTS Congestion Management Works

Figure 7.

Detecting Congestion on the Backhaul

Once UMTS Congestion Management is enabled on the MWR and the ONS RAN Service module, each device monitors its IP packet flows between the UMTS peers. The local device detects congestion on the RAN by monitoring the number of protected PVCs packet drops between the two peered devices. If the device(s) detects a certain number of protected PVC packet drops, this could be an indicator of backhaul congestion.
Once enough protected PVC packets have been dropped, the router will begin sending backhaul packets with a congestion indicator bit set.
Congestion is declared once the device detects three or more protected PVC packet drops in a 200 msec window. When three protected PVC packet drops are detected, the detecting device sets the congestion indicator bit in the IP backhaul packets it transmits to its peer.

Figure 8.

Monitoring Congestion on the Backhaul

While congestion is still detected on the backhaul, the detecting device(s) monitors the protected PVC packet loss on the backhaul. Congestion is cleared when no protected PVC packet loss is detected during a 200 msec window. If even a single drop occurs before 200 msec elapses, the 200 msec timer is restarted.

Figure 9.

Recovering from Congestion on the Backhaul

Once the congestion has cleared, the devices enter a recovery phase. During the congestion phase, all cells from non-protected PVCs are dropped. This is done to reduce the traffic on the IP backhaul and take the RAN out of congestion. After the congestion indicator has cleared, the recovery phase starts allowing 20 percent of the traffic from non protected PVCs to pass. Priority configured per PVC control how much of this 20 percent comes from which PVCs.

Figure 10.

The allowed pass percentage is increased by 1 percent every 100 msec until all cells are allowed to pass and operation of the backhaul is returned to normal.

Configuring UMTS Congestion Management

Note: The UMTS congestion management feature was designed to handle brief peaks in UMTS utilization. It is not designed to support call admission control types of applications.

Before configuring congestion management, the Iub PVC definitions of the NodeB must be examined to determine which PVCs to configure and which PVCs to protect. All radio vendors can provide the PVC definitions. The PVC definitions should look something like this:

VPI

VCI

Description

Type

PCR (cps)

RAN-O PVC Encapsulation

1

32

OAM

UBR

170

AAL0

1

33

OAM

UBR

170

AAL0

1

34

E// Sync

CBR

10

AAL0

1

35

E// Sync

CBR

10

AAL0

1

36

Radio Control

NRT-VBR

1000

QSAAL

1

37

Radio Control

NRT-VBR

1000

QSAAL

1

38

Q.2630 Signaling

NRT-VBR

1000

QSAAL

1

39

Voice Bearer

CBR

4000

AAL0

1

40

Data Bearer (HSDPA)

UBR

6000

AAL0

1

43

Radio Control

NRT-VBR

1000

QSAAL

1

44

Radio Control

NRT-VBR

1000

QSAAL

1

45

Q.2630 Signaling

NRT-VBR

1000

QSAAL

Sample Ericsson PVC Definitions

Based on these PVC definitions, the PVCs we need to protect are 1/34, 1/25,1/39. Protecting these PVCs ensure that the NodeB does not reset and voice bearer traffic is still passed through, even during a peak utilization period. The configuration for this example would look like this:

Cellsite Configuration

interface ATM0/4
no ip address
scrambling-payload
no atm ilmi-keepalive
atm umts-iub
umts-iub congestion-control
umts-iub set dscp ef
umts-iub set peering dscp ef
umts-iub local 10.10.10.1 6000
umts-iub remote 10.10.10.2 6000
pvc 1/32
encapsulation aal0
!
pvc 1/33
encapsulation aal0
!
pvc 1/34
encapsulation aal0
umts-iub congestion priority protected
!
pvc 1/35
encapsulation aal0
umts-iub congestion priority protected
!
pvc 1/36 qsaal
!
pvc 1/37 qsaal
!
pvc 1/38 qsaal
!
pvc 1/39
encapsulation aal0
umts-iub congestion priority protected
!
pvc 1/40
encapsulation aal0
umts-iub set dscp af43
!
pvc 1/43 qsaal
!
pvc 1/44 qsaal
!
pvc 1/45 qsaal
!

MTSO Configuration

! interface ATM0/4
no ip address
scrambling-payload
no atm ilmi-keepalive
atm umts-iub
umts-iub congestion-control
umts-iub set dscp ef
umts-iub set peering dscp ef
umts-iub local 10.10.10.2 6000
umts-iub remote 10.10.10.1 6000
pvc 1/32
encapsulation aal0
!
pvc 1/33
encapsulation aal0
!
pvc 1/34
encapsulation aal0
umts-iub congestion priority protected
!
pvc 1/35
encapsulation aal0
umts-iub congestion priority protected
!
pvc 1/36 qsaal
!
pvc 1/37 qsaal
!
pvc 1/38 qsaal
!
pvc 1/39
encapsulation aal0
umts-iub congestion priority protected
!
pvc 1/40
encapsulation aal0
umts-iub set dscp af43
!
pvc 1/43 qsaal
!
pvc 1/44 qsaal
!
pvc 1/45 qsaal
!
You can see from the configuration above that PVCs 1/34, 1/35, and 1/39 have been protected. Note that the configuration is for this particular example Ericsson PVC definition only. Each UMTS vendor will have different PVC definitions. Also note that the PVC 1/40 that is the HSDPA data PVC has a different DSCP value. It is configured this way because we use QoS to give the real-time traffic a priority queue and data traffic a best effort queue. This QoS configuration will handle the first line of congestion by transmitting the bandwidth-hungry HSDPA in the default queue while voice and circuit switch data are scheduled in the priority queue.
If you have any further questions about Cisco IP RAN Optimization, please send your questions to cs-rano@cisco.com.