A Over IP User Description

User Description, A-interface over IP

USER DESCRIPTION

292/1553-HSC 103 12/18 Uen D

Copyright

© Ericsson AB 2008-2012. All rights reserved. No part of this document may bereproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due tocontinued progress in methodology, design, and manufacturing. Ericsson shallhave no liability for any error or damage of any kind resulting from the useof this document.

Trademark List

Ericsson is the trademark or registered trademark ofTelefonaktiebolaget LM Ericsson.

All other trademarks mentioned herein are the property of their respectiveowners.

292/1553-HSC 103 12/18 Uen D | 2012-02-24

Contents

Contents

1 Introduction 1

1.1 Readers Guide 1

1.2 Main Changes in Ericsson GSM System BSS G11B 2

2 Capabilities 3

3 Technical Description 5

3.1 General 5

3.2 Transmission alternatives 5

3.3 Principles 8

3.4 Payload Formats 10

3.5 Codec Negotiation 12

3.6 Handover Procedure, User Plane 15

3.7 Overload Handling 16

3.8 AGW Failover 16

3.9 PCM Encoding Type 16

3.10 Codec Mode Adaptation for AMR and AMR-WB 16

3.11 Negotiation of Userplane Multiplexing and RTP Headercompression 17

3.12 UDP ports for RTP/RTCP 17

3.13 Related Statistics 18

3.14 Migration to A-interface over IP 18

4 Engineering Guidelines 21

4.1 General 21

4.2 Requirements on IP Network Characteristics 21

4.3 AGW Jitter Buffer Setting 21

4.4 RTP Multiplexing 21

4.5 AGW HW and Redundancy 21

5 Parameters 23

5.1 Main Controlling Parameters 23

5.2 Value Ranges and Defaults Values 24

5.3 IP Connectivity Parameters 24

5.4 Parameters Needing Special Attention 25

292/1553-HSC 103 12/18 Uen D | 2012-02-24


6 Concepts 27

Glossary 29

Reference List 31

292/1553-HSC 103 12/18 Uen D | 2012-02-24

Introduction

1 Introduction

The BSS feature A-Interface over IP uses IP networks, instead of Time DivisionMultiplexing (TDM) networks, for transport of A-interface user plane data(speech and circuit switched data) between the BSS and the Core Network(CN).

A-interface over IP enables transmission bandwidth savings and improvedspeech quality in MS-MS calls. As transcoders can be placed in the CN,compressed speech can be transmitted over the A-interface instead of sendingspeech with 64-kbps Pulse Code Modulation (PCM) over a TDM link. Thefeature also enables Transcoder Free Operation (TrFO) when codec types usedin both ends of a call are compatible and no transcoders are involved in the call.

1.1 Readers Guide

This document describes the feature A-interface over IP to operators, productmanagers, designers and others interested.

Documents needed for the overall picture of A-interface over IP:

• BSS IP RAN System Description (Reference [3]) briefly describes IPnetwork functionality inside the BSS nodes, and integration between thenodes.

Documents supplementing this document in important areas:

• BSS Security Guidelines (Reference [4]) describes security aspects ofusing IP transport in BSS.

Guides for dimensioning and planning:

• BSC/TRC and BSC Hardware Dimensioning Handbook (Reference [1])describes how to equip BSC/TRC with hardware to achieve desirableperformance.

• BSC IP Addressing (Reference [13]) provides recommendations for the IPaddress plan used by A-interface over IP.

Related functions and features:

• BSS Circuit Switched System Description (Reference [2]) briefly describeshow BSS handles speech and circuit switched data.

• Adaptive Multi Rate (Reference [6]) describes how the Adaptive Multi Rate(AMR) codec types are used in BSS.

1292/1553-HSC 103 12/18 Uen D | 2012-02-24


• Adaptive Multi Rate Wideband (Reference [7]) describes how the AdaptiveMulti Rate Wideband (AMR-WB) codec type is used in BSS.

• Self Configuring Transcoder Pools (Reference [11]) describes how thetranscoder pool size can be adjusted automatically.

• SIGTRAN Support in BSC (Reference [12]) describes how A-interfacesignalling is carried over IP.

• MSC in Pool (Reference [9]) describes how MSCs can be placed in a Pool.

• BSC IP Application Set Up (Reference [14]) describes how an IP applicationis configured in the BSC.

• Packet Abis over TDM (Reference [15] describes this feature)

• Packet Abis over IP (Reference [16] describes this feature)

1.2 Main Changes in Ericsson GSM System BSS G11B

This document is based on 292/1553-HSC103 12/16 Uen Rev. B.

Other than editorial changes, this document has been revised as follows:

• Rate adaptation of Circuit Switched Data calls is moved from theTranscoder and Rate Adaptation Unit (TRAU) to the A-interface Gateway(AGW) in Section 2 on page 3

• New counters for monitoring the performance of the A-interface is added inSection 3.13.2 on page 18

• The feature names for Abis Optimization and Abis over IP are changed toPacket Abis over TDM and Packet Abis over IP respectively.

• The PACKALG parameter is available in both Packet Abis over IP andPacket Abis over TDM features, see Section 5.4.3 on page 26

• The UDP port range for RTP/RTCP is extended, see Section 3.12 onpage 17.

• A section describing migration to A-interface over IP is added, Section3.14 on page 18.

• The section Engineering Guidelines is updated, Section 4 on page 21.

• When A-interface over IP is used together with packet Abis the AGW jitterbuffer is not used, see Section 5.2 on page 24.

2 292/1553-HSC 103 12/18 Uen D | 2012-02-24

Capabilities

2 Capabilities

A-interface over IP uses IP based transport of A-interface user plane data. ABSS supporting A-interface over IP connects to a CN through a Mobile ServicesSwitching Center Server (MSC-S) and a Media Gateway (MGW) in a layeredarchitecture. See Figure 1.

A/IP

Mc/IP

MSC-S MSC-S

Mc/IP

Nb

Nc

A/IP A/IP

A/IP

PCM/Compressed

IP based protocol

stack

= Signalling = User plane

MGW MGW

= Possible location for a transcoder

BSS

TRAU

BSS

TRAU

PCM/Compressed

IP based protocol

stack

Figure 1 A-interface over IP general view

A-interface over IP is an optional feature that configures the BSC/TRC for IPtransport of A-interface substituting traditional TDM transport. The featurerequires specific Regional Processor (RP) hardware; the A-Interface Gateway(AGW). One BSC/TRC supports up to 64 AGW RPs of which at least 1 shouldbe redundant. The node type for a BSC with AGW RPs is a BSC/TRC.

One AGW RP can handle up to 900 simultaneous PCM over IP or Full IP calls.

A-interface over IP is supported on BSC/TRC nodes based on AXE810hardware.

A-interface over IP user plane transports either PCM coded speech orcompressed speech over IP. Circuit switched data and fax services can also betransported with A-interface over IP. BSC/TRC supports multiplexing and RTPheader compression of userplane payload.

Transcoding of speech calls in BSC/TRC requires a Transcoder and RateAdaptation Unit (TRAU). The operator configures the BSC/TRC per codec type;with regard to which codec types that have transcoder support in BSC/TRC.

3292/1553-HSC 103 12/18 Uen D | 2012-02-24


Transcoders in BSC/TRC, when available, are only used for calls that needtranscoding. Data and fax calls are transcoded in the AGW RP.

This feature, together with the features SIGTRAN support in BSC/TRC, Gb overIP, and Packet Abis over IP makes it possible to set up an all-IP BSS, whereall payload and all signalling uses IP transmission.

Voice Group Call Services (VGCS) and High Speed Circuit Switched Data(HSCSD) are not supported in Ericsson BSS with A-interface over IP. Alsoinstead of running Tandem Free Operation (TFO) with IP transmission of PCMsamples, A-interface over IP introduces TrFO.

When a BSS network with BSCs connected over Ater interface to TRC isupgraded with A-interface over IP, the Ater interface is removed and all BSCsare converted to BSC/TRCs with AGW RP and IP network connection.

4 292/1553-HSC 103 12/18 Uen D | 2012-02-24

Technical Description

3 Technical Description

3.1 General

With the feature A-interface over IP user plane data are sent as IP packets overan IP bearer instead of bit streams on dedicated 64 kbps channel over a TDMnetwork. This saves transmission bandwidth and improves speech quality forMS-MS calls compared to normal handling with two transcoders in the call. Incase both ends in an MS-MS call uses the same or compatible codec types, notranscoders are needed in the call.

One benefit with the feature is that deployment of MSC in Pool is easier,because the BSC/TRCs does not need to have CS connections with all MGWsbelonging to the pool.

Another benefit is that the IP hardware in the nodes, and IP site and backboneinfrastructure, can be shared by the A-interface signalling and userplane.

An IP based A-interface cannot be used as a synchronization source fora BSC/TRC with TDM connected base stations. Other solutions, such asseparate synchronization networks, AXE Central Building Clock (CBC) orsimilar is needed.

3.2 Transmission alternatives

3.2.1 General

With IP transmission there are two alternatives in placing transcoders; in theBSC/TRC or in the CN. The case with transcoders in BSC/TRC is called PCMover IP while the case with transcoders in CN is called Full-IP.

All three alternatives, PCM over TDM, PCM over IP and Full IP can be usedat the same time in a BSC/TRC. Which one to use is decided by the codecnegotiation at call set up see Section 3.5.2 on page 12.

3.2.2 PCM over TDM

The classic architecture for A-interface user plane is shown in Figure 2.Transcoders are always located in the BSC/TRC in BSS. The only encodingdefined for the A-interface is PCM (G.711). In addition TFO may exist, whichtunnels compressed speech through this PCM link between the TRAU andthe MGW.

5292/1553-HSC 103 12/18 Uen D | 2012-02-24


MGW

BSS

A (IP or TDM)

Mc/IP

MGW

Mc/IP

Nb

Nc

A/TDM A/TDM


A (IP or TDM)

TRAU

BSS

TRAU

= Transcoder

MSC-S MSC-S

Figure 2 Reference architecture for PCM over TDM

3.2.3 PCM over IP

With PCM over IP the transcoding is done within the BSS, and the functionaldivision between BSS and CN is the same as with PCM over TDM. 64 kbpsA-interface channels between the BSC/TRC and the MGW, carry voice servicesover an underlying IP based transport protocol. See Figure 3.

A/IP

Mc/IP

MSC-S MSC-S

Mc/IP

Nb

Nc

A/IP A/IP

A/IP

IP based protocol

stack

IP based protocol

stack


MGW MGW

= Transcoder

BSS

TRAU

BSS

TRAU

64 kbps payload64 kbps payload

Figure 3 Architecture for PCM over IP, 64 kbps PCM coded speech overIP network

6 292/1553-HSC 103 12/18 Uen D | 2012-02-24


Since PCM over IP requires high bandwidth per call, it is recommended thatthe IP network has high bandwidth, low delay, low delay variation and lowpacket loss.

With PCM over IP, the local radio interface uses a codec type for which theBSC/TRC has a transcoder. The remote radio interface uses a codec typeindependent of which codec type that is used on the local radio interface.

3.2.4 Full IP

With Full IP the compressed speech is transported over IP using theRTP/UDP/IP protocol stack, and the same codec type is used both on theA-interface and over the local radio interface.

Full-IP on the A interface relies on transcoders in the CN and allow removalof transcoders from the BSS, thus impacting the functional division betweenthe BSS and the CN. In addition to improving the end-to-end speech qualityfor MS-MS calls, and reducing the bit rate on the A interface, this approachalso reduces the overall need for transcoder resources in the BSS and theCN, as transcoders now can be shared among a larger network population,see Figure 4.

There must still be transcoders for all codec types used on the air interfaceeither in BSS or in the Core Network, so that MS to PSTN calls can be handled.

A/IP

Mc/IP

MSC-S MSC-S

Mc/IP

Nb

Nc

A/IP A/IP

A/IP

IP based protocol

stack

IP based protocol

stack


MGW MGW

= Transcoder in CN, typically only used in MS-PSTN calls

BSS BSS

e.g. AMR codede.g. AMR coded

Figure 4 Architecture for Full IP, compressed speech in this example AMRover IP network

7292/1553-HSC 103 12/18 Uen D | 2012-02-24


In this way the BSS network architecture is aligned with the 3G CS CNarchitecture. Transcoders can now be concentrated to the CN. They are part ofthe MGW and are controlled by the MSC servers.

The codec type to be used on the radio interface and the A-interface type isnegotiated between the BSC/TRC and the MSC with the goal to achieve TrFOoperation. In the successful case when TrFO is achieved no transcoders areneeded, neither in the BSS nor in the CN.

There are cases where the codec type usage on the radio interface mustbe changed, such as at handover to a halfrate radio channel in high loadsituations, or handover to a cell lacking support for the used codec type. Inthese cases, depending on the new codec type, either a transcoder in the MGWor a transcoder in BSC/TRC will be used (the call might change from Full-IP toPCM over IP). The codec negotiation at call set up is described in Section 3.5.2on page 12 and at handover in Section 3.5.3 on page 13.

In contrast to TFO the compressed speech is used directly and there is noPCM stream in parallel.

3.2.5 Circuit Switched Data and Fax with A-interface over IP

64 kbps A-interface channels between the BSC/TRC and the MGW, carry circuitswitched data and fax services over an underlying IP based transport protocol.

Circuit Switched data and Fax services use the AGW RP in the BSC/TRC forrate adaptation. The rate adapted data is sent with RTP, UDP and IP to the CN.

3.3 Principles

3.3.1 Transport Network User Plane

The user plane connection is set up dynamically for each call.

The payload is packed into Real-Time Transport Protocol (RTP) packets andtransported by the UDP/IP protocol stack. The IP layer uses IPv4. IPv4 isspecified in RFC 791 and RFC 792, and UDP is specified in RFC 768. TheRTP header is defined in RFC 3550.

The protocol stack for A-interface over IP is shown in Figure 5.

8 292/1553-HSC 103 12/18 Uen D | 2012-02-24


L1+ L2

A

BSC/TRC MGW

IPIP

UDPUDP

RTPRTP

L1+ L2

Payload Payload

Figure 5 A-interface over IP Payload Protocol Stack

Each user plane connection is identified by an IP address and a UDP portnumber in the MGW, and another IP address and UDP port number in BSS.These addresses are exchanged between the BSS and the MSC prior touser plane establishment. The port numbers that are exchanged are the portnumbers associated with the RTP data stream. Port numbers for RTP arealways even numbers.

There is also an RTCP connection associated with each call. The RTCP portis the next odd UDP port. RTCP is defined in RFC 3550. RTCP is used tonegotiate the use of multiplexing and header compression for the user plane,see Section 3.11 on page 17. After the negotiation the BSC continues to sendRTCP Sender and Receiver Reports every 5th second.

See 3GPP TS 48.103 Reference [20] for further information on the transportmechanism.

3.3.2 Multiplexing of User Plane

Use of multiplexing is negotiated between the BSS and the MGW, see Section3.11 on page 17.

The multiplexing algorithm collects payload frames and gives them a commonUDP/IP header. An IP packet is sent either when it is filled with complete framesup to the maximum packet size, or when the multiplexing time (maximumcollection time) has elapsed. The multiplexing time is measured from puttingthe first frame into the IP packet.

The larger UDP/IP packet size, the more time it takes to fill one packet. LargeUDP/ IP packets also increase the probability that a packet is discarded dueto transmission related bit errors. Small IP packets decrease the delay, inproportion to the time needed to collect frames, but increase the UDP/IPoverhead. Similarly, a long multiplexing time decreases the UDP/IP overhead,depending on the amount of traffic, but increases the delay, while a shortmultiplexing time increases the overhead and decreases the delay.

9292/1553-HSC 103 12/18 Uen D | 2012-02-24


3.3.3 Transport Network Control Plane

For Speech calls, the BSC/TRC and the MSC negotiate the Codec Type andCodec Configuration for the radio interface and transmission alternative (PCMover TDM, PCM over IP or Full-IP) via the Base Station System Application Part(BSSAP) of the Signaling Connection Control Part (SCCP). Both BSSAP andSCCP are parts of the signalling protocols on the A-interface.

The exchange of IP addresses and UDP Port numbers between the corenetwork and the BSS is also done via BSSAP for each call.

For Data and Fax calls the BSC/TRC and the MSC negotiate RTP-packetizationand Redundancy level via BSSAP.

3.3.4 Supervision of User Plane

If neither an RTP packet nor an RTCP packet has been received during 15seconds, the AGW consider the call as lost and informs the MSC.

The timeout cannot be changed by the operator.

Note: Regular transmission of RTCP SR/RR packets is required of all MGWsin the network.

3.4 Payload Formats

3.4.1 RTP Profiles for PCM Encoded Speech

When PCM (G.711) encoded speech is transmitted on the A-Interface over IP,the packetization is done according to RFC 3551. The packetization time is 20ms and redundancy is not applied.

3.4.2 RTP Profiles for Compressed Speech

The Codec Types that are currently used in GSM and the available RTP profilesare listed below:

GSM FR RFC 3551

GSM HR RFC 5993

GSM EFR RFC 3551

AMR-FR RFC 4867

AMR-HR RFC 4867

AMR-WB RFC 4867

10 292/1553-HSC 103 12/18 Uen D | 2012-02-24


Packetization time is 20 ms. Fixed, predefined Payload Type numbers are usedfor A-interface over IP, see 3GPP TS 48.103 Reference [20].

3.4.3 RTP profiles for Data and Fax Calls

The rate adaptation for data and fax calls is kept in BSC/TRC, and is done inthe AGW RP. In uplink direction, the BTS extracts the payload of the CS dataor fax service from the radio interface, rate-adapts it to 16 kbps and sends thisin TRAU frames over Abis.

The AGW RP in BSC/TRC extracts the data from these TRAU frames andadapts them to a 64 kbps bit stream for transmission on the A-interface. For4.8 kbps and lower data rates the first 8 kbps subchannel carries 80-bit longV.110 frames while for 9.6 kbps the first 16 kbps sub-channel carries 80-bit longV.110 frames. For 14.4 kbps data rate the first 16 kbps sub-channel carriesA-TRAU frames with 288 data bits.

The RTP profile defined in RFC 4040 is used. The Packetization Time is fixed to20ms. RTP redundancy is not supported, see 3GPP TS 48.103 Reference [20].

3.4.4 Transport format without Multiplexing

User Plane transport without RTP multiplexing is default. It is applied whena new RTP connection is established, until a User Plane transport withRTP-multiplexing is negotiated via RTCP, see Section 3.11 on page 17.

Each payload packet is transported in an RTP/IP/UDP packet.

3.4.5 Transport format for Multiplexing without RTP Header Compression

Several RTP payload packets sent to the same IP address are multiplexedwithin one single UDP/IP packet over the A interface. Use of multiplexing isnegotiated between the BSS and the MGW, see Section 3.11 on page 17. Afive octet long "Multiplex Header", which identifies the multiplexed packet, isinserted before each multiplexed RTP/codec payload packet.

3.4.6 Transport format for Multiplexing with RTP Header Compression

The RTP header includes static fields that remain unchanged during an RTPsession. When RTP Header compression is applied the RTP Header iscompressed from 12 octets to 4 octets.

Use of RTP header compression is negotiated between the BSS and the MGW,see Section 3.11 on page 17.

At least the first two RTP packets of each RTP session are sent with theirfull RTP header to allow the receiver to store the full header and use it indecompression. RTP packets are also sent with their full RTP header until

11292/1553-HSC 103 12/18 Uen D | 2012-02-24


reception of a RTCP packet from the MGW indicating support of RTP headercompression. Subsequent packets may be sent with a compressed RTPheader. A five octet long "Multiplex Header", which identifies the multiplexedpacket, is inserted before each multiplexed RTP/codec payload packet.

3.5 Codec Negotiation

3.5.1 General

The codec negotiation at Call Setup and Handover is described in TS 48.008Reference [19].

3.5.2 Codec Negotiation at Call Setup

An end-to-end Codec Negotiation is performed for each individual call toachieve best quality of service, considering the Codec capabilities of the MS,the BSC/TRC, as well as the CN and the distant end. Figure 6 shows the BSSparts of Codec negotiation at call setup.

OriginatingBSC/TRC

Assignment Request(Originating MSC-PCL: Pref. RAN Codec,+)

Assignment Complete(OriginatingSpeech Codec (chosen))

Originating.MSC

Complete Layer 3 (Originating BSS-SCL)

Complete Layer 3 (Terminating BSS-SCL)

Assignment Complete(TerminatingSpeech Codec (chosen))

DTAP, Setup(Originating MS-SCL)

DTAP, Call Confirm (Terminating MS-SCL)

TerminatingMSC

Terminating BSC/TRC

Assignment Request(Terminating MSC-PCL: Pref. RAN Codec,+)

Paging Paging

CM ServRequest

PagingResponse

MSCapab.

Figure 6 End to end codec negotiation at call set up of MS to MS call

The BSC/TRC sends its actual Supported Codec List (SCL) (in short: BSS-SCL)to MSC in the first COMPLETE LAYER 3 Message that encapsulates the DTAP

12 292/1553-HSC 103 12/18 Uen D | 2012-02-24


CM SERVICE REQUEST message from MS. The BSC/TRC shall predict to itsbest possible knowledge at this point in time and for this specific call, whichcodec Types, configuration and transmission alternatives that can be used inthe specific cell area. The BSC/TRC does not include Codec Types in theBSS-SCL that are currently not available. BSS-SCL always indicates that circuitswitched data is supported.

The Codec capabilities of the MS, the SCL (in short MS-SCL) are received bythe MSC in the DTAP SETUP message, which also includes other call set updetails. With input from MS-SCL, BSS-SCL and CN capabilities, the MSC theninitiates codec negotiation towards the terminating side.

After the terminating MS has sent CALL CONFIRMED, the terminating MSCselects a pair of codecs to be used for the call, one for the CN and onepreferred Codec for the terminating RAN. At best these codecs are identicalor at least compatible.

The originating MSC now selects the preferred RAN codec for the originatingside, taking the selected codec from terminating side, originating side BSS-SCLand CN capabilities into account. In the optimal case, selected codec forthe terminating side and Preferred RAN Codec for the originating side areidentical, or at least compatible. The originating MSC also considers possibletransmission alternatives. Of course also the codec configurations arepre-decided by originating MSC.

Both MSCs now start in parallel to construct their offers to the respective BSCs.The MSC Preferred Codec List (PCL) (in short MSC-PCL) for originating sidecontains the preferred RAN codec as first codec. The MSC-PCL may containmore codecs than were included in the BSS-SCL, but not more than the MSsupports in MS-SCL. These additional codecs may be used by the BSS insubsequent handover procedures.

The MSC-PCL for the terminating side contains the Preferred RAN Codecas first Codec Type. Both MSCs send their respective MSC-PCLs to theirBSC/TRCs in an Assignment Request. If resources in BSC/TRCs still areavailable, the BSC/TRCs will choose the preferred RAN codecs for theirrespective radio interface. When the Codec Type is negotiated on theA-Interface, the transmission alternative (PCM over TDM, PCM over IP orFull-IP) is also included in the negotiation.

3.5.3 Codec Negotiation at Handover

There are several reasons for Handover, such as radio coverage and radionetwork resource utilization. The effect of Handover on a call can be change ofcell, change of codec, change between full rate and half rate traffic channels orchange between PCM over IP and Full-IP. In these situations the BSC/TRCalways tries to avoid changing the configuration to create the least impact onthe Core Network and the distant termination. Sometimes this is not possibleand a new codec negotiation must be performed.

The different handover cases are:

13292/1553-HSC 103 12/18 Uen D | 2012-02-24


� Intra-BSC Handover without Configuration Change

For an intra-BSC handover where no configuration change is needed, theBSS handles the handover internally. One important intra-Cell handoverwithout configuration change is channel repacking (HR to HR, FR to FR) forhigher radio efficiency under high load conditions, see Reference [8]. TheMSC is merely informed about the handover by the Handover Performedmessage. A new Codec List (BSS Supported), containing the up-to-dateCodec capability of the BSC/TRC may be included in the HandoverPerformed message.

Intra-BSC handovers changing from a full rate to a half rate traffic channelfor AMR-NB are also handovers without configuration change.

� Intra-BSC Handover with Configuration Change

If the BSC/TRC has to change codec or transmission alternative, atintra-BSC handover, the BSC/TRC must involve the MSC and MGW.Examples are changes between Full-IP and PCM over IP, changing IPaddress in BSC and changes between fullrate and halfrate traffic channelson the air interface for other codecs than AMR-NB.

Important Intra-Cell handover cases are handovers triggered by thefeatures Dynamic Half Rate Allocation (DHA) and Dynamic FR/HRAdapatation (DYMA) in high cell load situations see Reference [8]. It isimportant to notice that such handovers may only affect some of the calls inthe cell, not all. The BSS-SCL is therefore often only relevant for a specificcall, not for the whole cell.

The Internal Handover Procedure is used for this case, see TS 48.008Reference [19]. The BSC/TRC sends an INTERNAL HANDOVERREQUIRED message, containing the up-to-date BSS-SCL, to the MSC.In this case the BSS-SCL includes a configuration specifically required bythe BSC/TRC, not a complete list of supported configurations.The MSCchecks the request from the BSC/TRC and if it can be fulfilled then theMSC sends an INTERNAL HANDOVER COMMAND back to the BSC/TRC.The BSC/TRC answers with HANDOVER DETECT message and finallyHANDOVER COMPLETE message.

The MSC may trigger the Internal Handover procedure to ensure that thebest fit of dedicated resources are used for the ongoing call. The InternalHandover procedure is triggered by the MSC with the transmission of anINTERNAL HANDOVER ENQUIRY message to the BSS. The INTERNALHANDOVER ENQUIRY message shall contain in the "Speech Codec (MSCChosen)" Information Element the details of the resources (codec andtransmission alternative) preferred by the MSC.

If the BSS finds an appropriate target cell that meets the needed radiorequirements and is compatible with the preferences in the "Speech Codec(MSC Chosen)" Information Element, the BSS shall initiate the InternalHandover procedure by sending the INTERNAL HANDOVER REQUIREDmessage.

14 292/1553-HSC 103 12/18 Uen D | 2012-02-24


� Inter-BSC Handover

Inter-BSC handovers must involve the MSC and the MGW, regardlesswhether the Codec Type or configuration has to be changed or not.

The source BSC/TRC sends a HANDOVER REQUIRED message to theMSC.

The MSC constructs the MSC-PCL, taking into consideration for examplethe currently Selected Codec in the CN and the Speech Codec (used) so farby the old BSC/TRC. The first Codec in the MSC-PCL should be compatibleto the currently selected codec in the CN. The other codec types in theMSC-PCL are determined by the known MS-SCL and the MGW capabilities.

In general the MSC does not know the configuration of the target BSC/TRC.Therefore the MSC may offer all possibilities (PCM over TDM, PCM over IPor Full-IP ) in parallel in the MSC-PCL, which is included in the HANDOVERREQUEST MESSAGE. The HANDOVER REQUEST MESSAGE alsocontains the A-interface over IP Transport Layer Address for the MGW, ifA-interface over IP is offered.

The target BSC/TRC makes the final selection out of the MSC-PCL. Thetarget BSC/TRC reports back to the MSC with Speech Codec (chosen),included in HANDOVER REQUEST ACKNOWLEDGE message. ThisHANDOVER REQUEST ACKNOWLEDGE message also contains theA-interface over IP Transport Layer Address (BSS) and the new, up-to-date,BSS-SCL of the target cell.

� Inter-MSC and Inter-System Handover

These procedures work as without A-interface over IP, if the target systemis capable of TrFO a new codec negotiation is performed in that system.

3.6 Handover Procedure, User Plane

3.6.1 Intra-BSC Handover without Configuration Change

Neither IP-address nor UDP-port are changed at Intra-BSC handover withoutconfiguration change. The MGW only sees some irregularities in the uplinkRTP stream.

3.6.2 Intra-BSC Handover with Configuration Change

At Intra-BSC handover or Intra-cell handover, if the BSC/TRC cannot keep thecodec type, codec configuration or transmission alternative, then the MGWadds a new termination towards the BSC/TRC and handles the handover like inInter-BSC handover, see Section 3.6.3 on page 16.

15292/1553-HSC 103 12/18 Uen D | 2012-02-24


3.6.3 Inter-BSC Handover

At Inter-BSC handover, the MGW will see for a transient time two terminationstowards the radio interface, one to the old, serving BSC/TRC and one to thenew, target BSC/TRC. The termination to the old BSC/TRC is removed whenHandover Detect is received in the MSC. The Codec Types and transmissionalternative (PCM over IP or Full-IP) may be compatible or different on bothMGW terminations. It is up to the MGW to insert necessary transcodingequipment, and to perform proper handover handling.

3.7 Overload Handling

3.7.1 AGW RP

There is a fixed upper limit on how many calls that an AGW RP can handle.When the limit is reached for an AGW RP, no more calls are placed on that RP.

3.7.2 A-interface transmission overload

The IP transmission can be overloaded if not enough bandwidth is availablefor A-interface over IP. This can be seen in the BSC/TRC statistics in objecttype AGWTRAF. For calls using packet Abis this is observed as an increase ofcounter LOSTRTPPKTS. While for calls connected via the group switch thiscan be seen as AGW Jitterbuffer underruns, when counter REPLF increases.

3.8 AGW Failover

If an AGW RP fails during operation and stops working, for example due tohardware failure, all calls handled by that RP will be moved to a spare AGWRP. The BSC/TRC may have one or more standby AGW RP installed withoutIP-adress configured.

3.9 PCM Encoding Type

In case PCM over IP is used, the TRAU in the BSC/TRC operates in A-lawmode and conversion to µ-law, when needed, is done in the AGW.

3.10 Codec Mode Adaptation for AMR and AMR-WB

In a non-TrFO configuration both radio channels are totally independent fromeach other. This means that codec mode adaptation is done separately inrespective radio channel, see Reference [6].

16 292/1553-HSC 103 12/18 Uen D | 2012-02-24


In TrFO the optimal codec mode must be suitable to both radio channels, thatis the local uplink and the distant downlink radio channel and vice versa. Thechannel with the highest error rate (or smallest capacity) determines the highestpossible codec mode. The codec mode used in one direction may however bedifferent from the one used in the other direction.

The principle for codec mode adaptation in TrFO is as follows: The radioreceivers (for example the local uplink BTS receiver and the distant downlinkmobile receiver) estimate the observed radio quality and determine the optimalcodec mode. The final codec mode to be used is achieved by taking theminimum of both. The distant mobile therefore sends its codec mode requestuplink, and this is transferred all the way back to the local BTS. The local BTStakes the minimum of the distant codec mode request and its local codec modedecision, and sends the result downlink to the local mobile to be used on thelocal uplink. The result is also sent to the distant BTS. The selected codecmode will now also be used on the distant downlink radio channel.

This mechanism works symmetrically, independent of each other in bothdirections of the speech conversation. So, the codec modes in each direction ofa call are in general different, but always one out of the allowed codec modes.

3.11 Negotiation of Userplane Multiplexing and RTP Headercompression

Real-Time Transport Control Protocol (RTCP), see Reference [20], is usedfor each userplane connection to negotiate multiplexing and RTP headercompression. A 3GPP specific RTCP Multiplexing packet, defined in Reference[20], is used for this negotiation. The Multiplexing RTCP packet indicates ifmultiplexing with or without RTP header compression is supported, local UDPport where to receive multiplexed userplane data streams, and if multiplexingis selected.

When setting up a new userplane connection both the BSC/TRC and theMGW starts to send data without applying multiplexing. The BSC/TRC willindicate that it is ready to receive multiplexed data streams with and withoutRTP header compression by sending RTCP Multiplexing packets indicatingthese capabilities.

If the MGW is ready to receive multiplexed data stream for this call it startssending RTCP Multiplexing packets to the BSC/TRC showing its capabilities.The BSC/TRC will then start to apply multiplexing with or without RTP headercompression following the capabilities of the MGW. The BSC/TRC will alsoindicate in an RTCP Multiplexing packet how the BSC/TRC will transmituserplane data for this call.

3.12 UDP ports for RTP/RTCP

The BSC assigns local UDP ports for RTP in the range 10000 - 26384, whereeven ports are used for RTP and the next odd port is used for RTCP.

17292/1553-HSC 103 12/18 Uen D | 2012-02-24


Even ports in the range 30000-32048 are used for multiplexed RTP streams.

3.13 Related Statistics

3.13.1 Impact on Existing STS Counters

In general, introducing A-interface over IP does not affect existing STScounters, but due to the Core Network's aim to achieve Transcoder FreeOperation, the codec usage may change. This in turn may affect STS counters.

3.13.2 Statistics for Performance Management

There are a number of STS counters defined for A-interface over IP:

• AGW CPU load counters that belong to object type AGW.

• Traffic level and throughput counters that belong to object type AGWTRAF.

• Counters for Internal Handover with configuration change procedure inobject type AOIP.

• Counters monitoring the capacity lock for A-interface over IP in objecttype AOIPCAP.

• Counter for interarrival jitter that belong to object type AGWTRAF.

• Counter for number of lost RTP packets that belong to object typeAGWTRAF.

More information on counters can be found in Reference [10].

3.14 Migration to A-interface over IP

This section describes the migration to A-interface over IP for an existing BSCusing TDM transport on the A-interface.

3.14.1 Migration of a BSC/TRC

Migration, without negative impact on existing traffic, is possible if the BSCis configured as a BSC/TRC. To achieve this the configuration of the CoreNetwork and BSS must first be changed to support IP transport over theA-interface. The feature A-Interface over IP should be activated in the BSC,while the BSC data in the MSC is still set to TDM transport. At this point theBSC is ready to set up new calls using IP transport, but the MSC continues torequest new calls to be set up using TDM transport over the A-interface.

18 292/1553-HSC 103 12/18 Uen D | 2012-02-24


When the MSC changes its BSC data to IP transport, new calls can be set upusing IP transport over the A-interface (from a BSC point of view new calls canbe set up using either IP or TDM transport). Assuming that the MSC requestsnew calls to be set up using IP transport, there will be a period of time whenTDM and IP transport are used in parallel. That is, an active call set up usingTDM transport before the change of BSC data in the MSC, will continue usingTDM transport until the call is released. Eventually all calls will use IP transportover the A-interface.

3.14.2 Migration of a Remote BSC

A migration of a remote BSC is not as straight forward as for a BSC/TRC. For aremote BSC the A-ter interface must first be removed, which will affect traffic.The remote BSC must then be configured as a BSC/TRC. After these initialsteps, a migration can be performed as described in Section 3.14.1 on page 18.

19292/1553-HSC 103 12/18 Uen D | 2012-02-24


20 292/1553-HSC 103 12/18 Uen D | 2012-02-24

Engineering Guidelines

4 Engineering Guidelines

4.1 General

For information about how to dimension A-interface over IP see BSC/TRC andBSC Hardware Dimensioning Handbook, Reference [1].

4.2 Requirements on IP Network Characteristics

The characteristics of the IP network have a direct impact on speech quality.For best performance the IP network is recommended to have low delay, lowdelay variation and a low drop rate.

4.3 AGW Jitter Buffer Setting

The AGW jitter buffer size is recommended to be large enough to handle themajority of the delay variation caused by the IP network. Setting the jitter buffersize larger then necessary results in longer speech path delay than needed.With a high performance IP network, the jitter buffer size can be set to a lowvalue, for example, to the recommended value in Section 5.2 on page 24.

Note: The AGW jitter buffer setting is not relevant for a call using packet Abis. Inthis case the delay variation deriving from the A-interface is handled by the BTS.

4.4 RTP Multiplexing

The use of RTP multiplexing will significantly reduce the needed bandwidth.Another effect of RTP multiplexing is that the number of sent IP packets issignificantly reduced, which results in less strain on both the LAN switch andthe IP network. Note that for the BSC, RTP multiplexing is supported by default,but to achieve RTP multiplexing Core Network support is also needed.

4.5 AGW HW and Redundancy

For the number of needed AGW boards, see Reference [1]. At least one spareAGW board is recommended for redundancy purposes due to, for example,hardware failure.

21292/1553-HSC 103 12/18 Uen D | 2012-02-24


22 292/1553-HSC 103 12/18 Uen D | 2012-02-24

Parameters

5 Parameters

5.1 Main Controlling Parameters

A-interface over IP is activated by issuing command RRAII and deactivatedby command RRAIE.

Command RRAGC changes Downlink Jitter buffer size with parameter JBS,DiffServ CodePoint for RTP/UDP with parameter DSCP and DiffServ CodePointfor RTCP/UDP with parameter DSCP1. See Table 1.

Two other parameters in command RRAGC controls multiplexing, parameterMBT sets the maximum time speech frames are collected, parameter MPSdefines the maximum size of an multiplexing packet.

All parameters in command RRAGC are on BSC/TRC level.

Decreasing size of transcoder pools in BSC/TRC is done with commandRRTPC and parameter RNOTRA.

5.1.1 Quality of Service

For an IP network with limited bandwidth, where there is a risk of overload,Quality of Service may improve performance. In this case, it is recommendedto give the A-interface userplane a higher priority than other transmission. Notethat Quality of Service also requires that the IP network supports DiffServ.

DSCP values for RTP and RTCP are set by command RRAGC, see Section5.1 on page 23.

What DSCP value to use depends on the IP service used for each BSC/TRCsite, and should be same as used by the CN.

5.1.2 PCMLAW

When PCM over IP is used the correct PCM law type must be used on theA-interface. This is controlled by the BSC Exchange Property PCMLAW andset to 0 for A-law or set to 1 for µ-law.

23292/1553-HSC 103 12/18 Uen D | 2012-02-24


5.2 Value Ranges and Defaults Values

Table 1 Main Controlling Parameters for A-interface over IP

Parameter Name DefaultValue

Recommended Value Value Range Unit

DSCP 0 46 0 to 63 -

DSCP1 0 46 0 to 63 -

JBS(1) 20 5 0 to 255 ms

MBT 2 2 1 to 5 ms

MPS 1500 1500 400 to 1500 octets

PCMLAW 0 - 0,1

(1) The AGW jitter buffer setting is not relevant for a call using packet Abis.

5.3 IP Connectivity Parameters

To use IP connectivity, the operator configures the parameters in Table 2.The steps are listed in Reference [5].

Configure an IP address to all active AGW RPs with the command RRIPI. Donot configure any IP address on standby AGW RPs.

• To configure the IP address of a AGW RP, give IPADDR as parameter.

• To create an reconfigurable IP address, leave out the parameter IPDEVNO.Add APPLSEL to specify that it is the application that selects which IPdevice the IP address will be defined on.

• Define the IP device as an AGW with the parameter IPDEVTYPE (usethe value in Table 2).

• Define the IPADDR sub-net mask with the parameter MASK.

Associate the A-interface over IP application to all active IP devices with thecommand RRAPI. This order is valid only for registered applications andremains after BSC restart.

TYPE and DEVNO are printout parameters. TYPE is a header that showswhether the IPADDR is of type FIXED, RECONF or APPLSEL. DEVNO is aheader for IPDEVNO values. DEVNO is empty for reconfigurable IP addresses.

IP Supervision requires parameter configurations in accordance with Reference[14].

24 292/1553-HSC 103 12/18 Uen D | 2012-02-24

Parameters

Table 2 Main Controlling Parameters for A-interface over IP

Parameter Name Default Value Recommended Value Value Range Comment

APL — AIP String 1–3 “AIP”: A-interfaceover IP

DEVNO(1) — — 0–127 Expressed as AGWdevices, where

n = Device number

IPADDR — — a.b.c.da: 1-126, 128-223

b,c,d: 0-255

—

IPDEVNO — — 0–63Expressed as AGW

devices, wheren = Device number

IPDEVTYPE — RTIPAGW String 1–7

“RTIPAGW”: the onlyapplicable value forA-interface over IPand means AGW

MASK — —

a.b.c.d

a: 255

b,c,d: 0-255

—

TYPE(1) — — APPLSEL

APPLSEL: The IPaddress movesbetween RPs at

hardware failures,controlled by the

application.

(1) Read-only parameter

5.4 Parameters Needing Special Attention

5.4.1 AMR and AMR-WB Codec Set

AMR Codec set

The BSC/TRC shall be configured with AMR Full Rate Codec Set 5 and AMRHalf rate Codec set 2 to enable Full-IP AMR calls (prerequisite for AMR TrFO),see parameters AMRFRSUPPORT and AMRHRSUPPORT in Reference [6].These codec sets are denoted Preferred Configuration 1 in 3GPP TS 28.062see Reference [18].

If non-standard settings for thresholds or hysteresis are needed, User Definedcodec sets can be defined (Reference [6]) but the codec modes includedin the User Defined codec sets must be {12.2,7.4,5.9,4.75} for FR-AMR and{7.4,5.9,4.75} for HR-AMR.

AMR-WB Codec set

The Ericsson BSS supports one codec set for AMR-WB, denoted Configurationset 0 according to TS 26.103, see Reference [7] and Reference [17].

25292/1553-HSC 103 12/18 Uen D | 2012-02-24


5.4.2 Signalling Network

All Signalling Points used for A interface signalling must be capable of sendingand receiving Extended Unitdata (XUDT) messages.

The signalling handling subsystem in BSC needs more and larger buffers forreception and re-assembly of signalling messages.

5.4.3 Packing Algorithm Parameter

The PACKALG parameter is available with the Packet Abis features, and setsthe packing algorithm used on the Abis traffic generated by the TG. The packingalgorithm is described in Reference [15]. If A-interface over IP is used togetherwith Packet Abis, packing algorithm 1 must be used.

Table 3 Packing Algorithm Parameter

Parameter Name Default Value RecommendedValue Value Range Comment

PACKALG 0 1 0–1

1 = packingalgorithm No.10 = switch offpacking. Notethat 0 isn'tvalid if usingPacket Abis.

5.4.4 Downlink Discontinuous Transmission

For calls in Full IP mode, the transmitter in the BTS may, regardless of theDTXD setting, be switched of during speech pauses. Since compressedspeech using Discontinuous Transmission at any time can be received bythe BSC/TRC in downlink, the BSC/TRC and BTS must be ready to handlethis. That is, the setting of parameter DTXD is overridden by A-interface overIP when a call is in Full IP mode. If Discontinuous Transmission is found indownlink on the air interface (and Abis) this is due to the use of DiscontinuousTransmission on the distant side, for example by the MGW, or by the MS incase of TrFO. The use of Discontinuous Transmission on the distant side cannot be influenced by the BSC/TRC.

26 292/1553-HSC 103 12/18 Uen D | 2012-02-24

Concepts

6 Concepts

A-TRAU Frame format used on A-interface for Circuit switcheddata transported over TCH/F14.4.

Codec ConfigurationMainly used in context of AMR and AMR-WB to specifythe mode set to be used during the call, for exampleNB-Set1 = {(12.2) – 7.4 – 5.9 – 4.75} and WB-Set0 ={12.65 – 8.85 – 6.60}.

Codec Mode A codec rate used within a codec set is called a codecmode.

Codec Set A set of up to 4 different codec modes using the samechannel rate.

Codec Type Any of the existing GSM Codec Types, like GSM FR,GSM HR, EFR, FR-AMR, HR-AMR, FR-AMR-WB, seeTS 26.103 Reference [17].

Compatible Codec ConfigurationsCodec Configurations that do not require transcoding,although the Codec Types and Configurations may bedifferent, FR-AMR(set 1) to HR-AMR (set 1), that isFR-AMR {12.2,7.4,5.9,4.75} to HR-AMR {7.4,5.9,4.75}.

Compressed SpeechSpeech coded with one of the following codecs FR, HR,EFR, AMR and AMR-WB.

Packet Abis Packet Abis is the collection name for the featuresPacket Abis over TDM and Packet Abis over IP.

PCM Pulse-code modulation is a digital representation ofan analog signal where the magnitude of the signal issampled regularly at uniform intervals, then quantized toa series of symbols in a numeric (usually binary) code.

TFO Tandem Free Operation, avoids the transcodingfunction within the transcoders in the networks (forexample: within the TRAU in BSS or the MGW) butneeds the transcoder hardware in the path.

TrFO Transcoder Free Operation, avoids the transcodingfunction within the networks. Does typically not needthe transcoder hardware in the path.

27292/1553-HSC 103 12/18 Uen D | 2012-02-24


Transcoder A transcoder handles encoding/decoding of speech andrate adaptation of data information between the formatused on the A-interface and the Abis interface.

28 292/1553-HSC 103 12/18 Uen D | 2012-02-24

Glossary

Glossary

AGWA-Interface Gateway

AMRAdaptive Multi Rate

AMR-WBAdaptive Multi Rate Wideband

BSSAPBase Station System Application Part

CBCCentral Building Clock

CNCore Network

DHADynamic Half Rate Allocation

DYMADynamic FR/HR Adapatation

HSCSDHigh Speed Circuit Switched Data

MGWMedia Gateway

MSC-SMobile Services Switching Center Server

PCLPreferred Codec List

PCMPulse Code Modulation

RPRegional Processor

RTCPReal-Time Transport Control Protocol

RTPReal-Time Transport Protocol

SCCPSignaling Connection Control Part

SCLSupported Codec List

TCHTraffic CHannel

TDMTime Division Multiplexing

TFOTandem Free Operation

TRAUTranscoder and Rate Adaptation Unit

TrFOTranscoder Free Operation

VGCSVoice Group Call Services

XUDTExtended Unitdata

29292/1553-HSC 103 12/18 Uen D | 2012-02-24


30 292/1553-HSC 103 12/18 Uen D | 2012-02-24

Reference List

Reference List

Ericsson Documents

[1] BSC/TRC and BSC Hardware Dimensioning Handbook, 1555-AXE 10507

[2] BSS Circuit Switched System Description

[3] BSS IP RAN System Description

[4] BSS Security Guidelines

[5] Operational Instruction, BSC, A over IP, Activate, 3/154 31-ANT242 05

[6] User Description, Adaptive Multi Rate

[7] User Description, Adaptive Multi Rate Wideband

[8] User Description, Channel Allocation Optimization

[9] User Description, MSC in Pool

[10] User Description, Radio Network Statistics

[11] User Description, Self Configuring Transcoder Pools

[12] User Description, SIGTRAN Support in BSC

[13] User Guide, BSC IP Adressing,, 9/19817-APT 210 09

[14] User Guide, BSC IP Application Set Up, 7/198 17-APT 210 09

[15] User Description, Packet Abis over TDM

[16] User Description, Packet Abis over IP

Standards

[17] 3GPP TS 26.103, Speech codec list for GSM and UMTS

[18] 3GPP TS 28.062, Inband Tandem Free Operation (TFO) of speechcodecs; Service description; Stage 3

[19] 3GPP TS 48.008, Mobile Switching Centre - Base Station system(MSC-BSS) interface; Layer 3 specification

[20] 3GPP TS 48.103, Base Station System - Media GateWay (BSS-MGW)interface; User plane transport mechanism

31292/1553-HSC 103 12/18 Uen D | 2012-02-24

A Over IP User Description

Documents

Transcript of A Over IP User Description