11_02_cn3410ben33gln0_bicc

8/11/2019 11_02_CN3410BEN33GLN0_BICC

1/57CN3410BEN33GLN0

BICC

1

1 Nokia Siemens Networks CN3410BEN33GLN0

Bearer Independent Call Control - BICCSwitching Core Network Signalling

M14/U4

8/11/2019 11_02_CN3410BEN33GLN0_BICC

2/57

CN3410BEN33GLN0

BICC

2


Nokia Siemens Networks Academy

Legal notice

Intellectual Property RightsAll copyrights and intellectual property rights for Nokia Siemens Networks trainingdocumentation, product documentation and slide presentation material, all of which are forthwithknown as Nokia Siemens Networks training material, are the exclusive property of NokiaSiemens Networks. Nokia Siemens Networks owns the rights to copying, modification,translation, adaptation or derivatives including any improvements or developments. NokiaSiemens Networks has the sole right to copy, distribute, amend, modify, develop, license,sublicense, sell, transfer and assign the Nokia Siemens Networks training material. Individualscan use the Nokia Siemens Networks training material for their own personal self-developmentonly, those same individuals cannot subsequently pass on that same Intellectual Property toothers without the prior written agreement of Nokia Siemens Networks. The Nokia SiemensNetworks training material cannot be used outside of an agreed Nokia Siemens Networkstraining session for development of groups without the prior written agreement of NokiaSiemens Networks.

8/11/2019 11_02_CN3410BEN33GLN0_BICC

3/57

CN3410BEN33GLN0

BICC

3


Document change history

Customization for Orange (UK)Guido Schneiders3March 09

Small layout adaptationsGuido Schneiders2Sept 08

Revised and update from M13 to M14/U4Pubate Satienpoch1March 3, 08

Change commentNameVersionDate

8/11/2019 11_02_CN3410BEN33GLN0_BICC

4/57

CN3410BEN33GLN0

BICC

4


BICC in 3GPP R4

MSC Server

H.2

48

IP

MSC Server/GCS

Mc

MGW

Nc

AAL2/AAL5ATM

Nb

Mc

BICC CS-2IP

MGW

RTPIP

H.2

48

IP

Controlplane

Userplane

or

8/11/2019 11_02_CN3410BEN33GLN0_BICC

5/57

CN3410BEN33GLN0

BICC

5


Bearer Independent Call Control - BICC

- call control protocol

- based on ISUP- Separate set of procedures for call control signalling and transport of

bearer control signalling

- independent of

- bearer technology (e.g. IP, ATM)

- signalling message transport (e.g. MTP, MTP3b, SIGTRAN)

IP

BICC

ATMMTP1

SCTPSAALMTP2

M3UAMTP3bMTP3

BICC overTDM BICC overATM BICC over IP

8/11/2019 11_02_CN3410BEN33GLN0_BICC

6/57

8/11/2019 11_02_CN3410BEN33GLN0_BICC

7/57

CN3410BEN33GLN0

BICC

7


BICC Functional Blocks

CSF

BCF

Call Control

Signalling

Bearer Control

Signalling

BIWF

Bearer

SN

CallBearerControl

Signalling(CBC)

CSF

BCF

Call Control

Signalling

BIWF

SN

CallBearerControl

Signalling(CBC)

CSF

CMN

Bearer

SN : Serving Node Call Service Function (CSF) with associated Bearer Control Function (BCF)

CMN : Call Mediation Node CSF without associated BCF

BIWF : Bearer Inter-working Function, provides BCF and media mapping/switching function

Controlplane

Userplane

8/11/2019 11_02_CN3410BEN33GLN0_BICC

8/57

CN3410BEN33GLN0

BICC

8


Bearer Establishment Modes

MSS MSS

Forward

Backward

MSS

MGW

MSS

MGW

Bearer establishment direction

Bearer establishment direction

BICC:IAM

BICC:IAM

8/11/2019 11_02_CN3410BEN33GLN0_BICC

9/57

CN3410BEN33GLN0

BICC

9


Two ways to establish a bearer

1) ATM: separate bearer control signalling: AAL-Type-2 Signalling

2) IP: bearer information tunneled in call- and call bearer control

messages: IPBCP

Bearer Control Signalling

MSS MSSCall Control Signalling

BICC or SIP

e.g: AAL2 signalling

IP backbone:the IPBCP protocol is tunneledinside H.248 and BICC (or SIP)

via the MSC Servers.

H.248

ATM backbone:separate bearer controlsignalling: AAL-Type-2

signalling

H.248

MGW MGW

8/11/2019 11_02_CN3410BEN33GLN0_BICC

10/57

CN3410BEN33GLN0

BICC

10


BICC call control related messages -1-

Q1902.3

Pre-Release Information0100 0010PRI

Initial Address Message0000 0001IAM

Information Request0000 0011INR

Information0000 0100INF

Identification Response0011 0111IRS

Identification Request0011 0110IDR

Connect0000 0111CON

Call Progress0010 1100CPG

Continuity0000 0101COT

Application Transport Message0100 0001APM

Answer Message0000 1001ANM

Address Complete Message0000 0110ACM

DescriptionCodeMessage

8/11/2019 11_02_CN3410BEN33GLN0_BICC

11/57

CN3410BEN33GLN0

BICC

11


BICC call control related messages -2-

Q1902.3

User-to-User Information0010 1101USR

Suspend0000 1101SUS

Segmentation0011 1000SGM

Subsequent Address Message0000 0010SAM

Release Complete0001 0000RLC

Resume0000 1110RES

Release0000 1100REL


8/11/2019 11_02_CN3410BEN33GLN0_BICC

12/57

CN3410BEN33GLN0

BICC

12


BICC Maintenance related messages -1-

Q1902.3

Circuit / CIC Group Query Response0010 1011CQR

Circuit / CIC Group Query Message0010 1010CQM

Circuit / CIC Group UnblockingAcknowledgement

0001 1011CGUA

Circuit / CIC Group Unblocking0001 1001CGU

Circuit / CIC Group Reset Acknowledgement0010 1001GRA

Circuit / CIC Group Reset0001 0111GRS

Circuit / CIC Group Blocking Acknowledgement0001 1010CGBA

Circuit / CIC Group Blocking0001 1000CGB


8/11/2019 11_02_CN3410BEN33GLN0_BICC

13/57

CN3410BEN33GLN0

BICC

13


BICC Maintenance related messages -2-

Q1902.3

Unequipped Circuit Identification Code0010 1110UCIC

Reset Circuit / CIC message0001 0010RSC

Facility Request0001 1111FAR

Facility Reject0010 0001FRJ

Facility0011 0011FAC

Facility Accepted0010 0000FAA

Confusion0010 1111CFN


8/11/2019 11_02_CN3410BEN33GLN0_BICC

14/57

CN3410BEN33GLN0

BICC

14


Format of BICC messages

Formats and codes for BICC protocols are specified in ITU-T Q.1902.3

They are very similar to ISUP messages.

Optional part

Mandatory variable part

Mandatory fixed part

Message type code

CIC

8/11/2019 11_02_CN3410BEN33GLN0_BICC

15/57

CN3410BEN33GLN0

BICC

15


Example: Initial Address Message (IAM)incomplete

5-?

3-?

4-?

1

1

2

1

1

Lengthoctets

Information sent in either direction to allow the peer-to-peercommunication of application transport users (BAT-ASE)

OApplication transport

Information generated on the access side of a call andtransfered transparently in either direction between

originating and terminating local nodes.

OAccess transport

Received digits to identify the called party.VCalled party number

Speech, 3.1kHz audio, 64kbit/s, Nx64kbit/s, 1920 kbit/s, 1536kbit/s, etc.

FTransmission mediumrequirement

Ordinary, payphone, prioroty, operator language.FCalling party's category

National/international call, end-to-end method indicator,CCS7 interworking indicator, end-to-end informationavailability, ISUP use indicator, ISUP preference indicator,ISDN access indicator, SCCP method indicator.

FForward call indicators

Satellite connection included, Continuity check required/notrequired, echo control device included/not included

FNature of connectionindicators

IAMFMessage type

DescriptionTypeParameter

F: mandatoryfixed parameter;V: mandatory variable parameter; O: optional parameter

8/11/2019 11_02_CN3410BEN33GLN0_BICC

16/57

CN3410BEN33GLN0

BICC

16


CIC (Call Instance Code)

CIC in the BICC protocol is used to identify a signalling relation between peer BICCentities and to associate all the PDUs to that relation.

CIC allocates a signalling message to the (virtual) channel, carrying the call.

Bilateral agreement is required with regard to the CIC values provisioned.

4CIC

3CIC

2CIC

1CIC

12345678

LSB

MSB

8/11/2019 11_02_CN3410BEN33GLN0_BICC

17/57

CN3410BEN33GLN0

BICC

17


Application Transport Mechanism APM -1-

APM (ITU-T Q.765.5) is used to transmit bearer related information in BICCmessages

The application, using APM for bearer control, is called Bearer AssociationTransport Application Service Element (BAT- ASE)

The application is running in parallel to call control instance in the node

Application specific data may be sent in CC messages or as a separate APMmessage.

appl

CC

appl

CC

CC message + application data

application data

CC message + application data

(e.g. BICC:IAM)

(e.g. BICC:APM)

(e.g. BICC:CPG)

8/11/2019 11_02_CN3410BEN33GLN0_BICC

18/57

CN3410BEN33GLN0

BICC

18


APM for BICC carries among others

Action indicator (forward/backward) BNC ID (reference used to associate the bearer with a call)

BIWF address (MGW address)

Codec(s)

Tunneling related information (used/not used, bearer control payload)

Carried in APP parameterof various BICC call control messages:ACM, ANM, APM, CPG, CON, IAM, PRI

MSS

IAMAPPparamparam

e.g. IAM or APMmessage

BAT-ASE

MSS

BAT-ASE

Application Transport Mechanism APM -2-

8/11/2019 11_02_CN3410BEN33GLN0_BICC

19/57

CN3410BEN33GLN0

BICC

19


Application Transport Parameter (APP)

Q.765.5ch11

Q.1902.3ch 6.4

n

4

3a

3

2

1a

1

APM user information

Segmentation local referenceext.

APM Segmentation IndicatorSIext.

RCISNIspareext.

MSBext.

LSBApplication Context Identifier (05=BAT-ASE)ext.

12345678

mIdentifier 2

Length indicator 2

Compatibility Information 2

Content 2

n

4

3

2

1

:

Content 1

Compatibility information 1

Length indicator 1

Identifier 1

12345678

Application context identifier 0000101 = BAT ASE

If ext=0 then octet 1a is present

RCI=Release Call Indicator (1=Release call)SNI=Send Notification Indicator (=1 send notification)

APM segment indicator (000000=Final segment) otherwise represents segmentnumber.(000001 to 001001)

SI= Sequence Indicator (1=New sequence)

8/11/2019 11_02_CN3410BEN33GLN0_BICC

20/57

CN3410BEN33GLN0

BICC

20


Contents of APM identifiers -1-

Identifies the bearer used e.g. IP/RTP, AAL1, AAL2,TDM etc.

Bearer NetworkConnectionCharacteristics

0000 0111

Has a field called Organization identifier and codecinformation subfield. Subfield has information aboutthe codec type and codec configuration.

Single codec0000 0101

In the codec list, single codec information elementsare listed in decreasing order of preference level.

Codec list0000 0100

Interworking function address is in NSAP formataccording to X.213 (BIWF Address).

Interworking functionaddress

0000 0011

The content is bearer specific with maximum length of4 octets (BNC_ID).

Backbone networkconnection identifier

0000 0010

Can have codes like connect forward, connectbackward etc. see separate slide

Action Indicator0000 0001

InformationIE nameValue

8/11/2019 11_02_CN3410BEN33GLN0_BICC

21/57

CN3410BEN33GLN0

BICC

21


Contents of APM identifiers -2-

Indicates whether bearer redirection capability issupported at sending node and also indicates optionswithin the capability.

Bearer redirectioncapability

0000 1100

Duration of a signal in milliseconds.Duration0000 1000

Indicates the signal type e.g. DTMF tones, dial tone,ringing tone, busy tone etc.

Signal type0000 1110

Signal to be appliedSignal0000 1011

Contains information about the BCU. It includesNetwork ID and Local BCU-ID.

Bearer control unitidentifier

0000 1010

Indicates whether tunnelling is used or notBearer controltunnelling

0000 1001

Contains PDU (Protocol Data Unit) of BCTP( see separate section)

Bearer controlinformation

0000 1000

Instructions on received, unrecognized informationBAT compatibilityreport

0000 0110

InformationIE nameValue

8/11/2019 11_02_CN3410BEN33GLN0_BICC

22/57

CN3410BEN33GLN0

BICC

22


Action Indicator: used for a lot of indications

Bearer Setup Control, for example no indication

connect backward connect forward connect forward, no notification connect forward plus notification required

Bearer Setup Indication, for example connected

Codec Selection and Modification, for example selected codec modify codec successful codec modification codec modification failure mid-call codec negotiation

DTMF Interaction, for example start signal, notify start signal, no notify stop signal, notify stop signal, no notify

8/11/2019 11_02_CN3410BEN33GLN0_BICC

23/57

8/11/2019 11_02_CN3410BEN33GLN0_BICC

24/57

8/11/2019 11_02_CN3410BEN33GLN0_BICC

25/57

CN3410BEN33GLN0

BICC

25


BCTP Bearer Control Tunnelling Protocol

tunnelling bearer control protocols (BCP) through Nc and Mc interface

ITU-T Q.1990

In Rel.4 networks, IPBCP is tunnelled by means of BCTP through BICC BCTP adds 2 octets - BCTP version indicator

- Tunnelled Protocol Indicator

8/11/2019 11_02_CN3410BEN33GLN0_BICC

26/57

CN3410BEN33GLN0

BICC

26


Tunneling bearer information

IPBCP(Q.1970)

SDP(RFC2327)

BCTP(Q.1990)

APM(Q.765.5)

BICC(Q.1902.2)

IPBCP(Q.1970)

SDP(RFC2327)

BCTP(Q.1990)

MEGACO(H.248)

MGW MGW

MSSMSS

M3UA

SCTP

IP

SCTP

IP

Nc

Mc

IP_BB

Mc

8/11/2019 11_02_CN3410BEN33GLN0_BICC

27/57

8/11/2019 11_02_CN3410BEN33GLN0_BICC

28/57

CN3410BEN33GLN0

BICC

28


IPBCP in SDP format acc. RFC2327

v= 0

o= - 0 0 IN IP4 10.33.16.136s= IP Tunnelingc= IN IP4 10.33.16.136t= 0 0a= ipbcp:1 Requestm= audio 1026 RTP/AVP 96a= rtpmap: 96 VND.3GPP.IUFP/16000

SDPSDP version (v) : 0

Owner/Creator, Session ID (o) :Owner Username : -

Session ID : 0

Session Version : 0

Owner Network Type : IN

Owner Address Type : IPv4

Owner Address : 10.33.16.136

Session name (s): IP Tunneling

Connection Information (c):

Connection Network Type : IN

Connection Address Type : IPv4

Connection Address : 10.33.16.136

Time Description, active time (t) :

Session Start Time : 0

Session Stop Time : 0

Session Attribute (a) :

Session Attribute Fieldname : ipbcp

IPBCP protocol version : 1

IPBCP command type : Request

Media Description, name and address (m):

Media Type : audio

Media Port : 1026

Media Proto: RTP/AVP

Media Format : 96

Media Attribute (a) :

Media Attribute Fieldname : rtpmap

Media Format : 96

MIME Type : VND.3GPP.IUFP

8/11/2019 11_02_CN3410BEN33GLN0_BICC

29/57

CN3410BEN33GLN0

BICC

29


Codecs represented in SDP

m=audio 1234 RTP/AVP 96

a=rtpmap:96AMR/8000a=fmtp:96 mode-set=1,2,3,4,5,6,7

AMR


a=rtpmap:4 G723/8000

G.723.1


a=rtpmap:0 PCMU/8000

G.711 u-law


a=rtpmap:8 PCMA/8000

G.711 A-law


a=rtpmap:3 GSM/8000

FR


a=rtpmap:103 GSM-EFR/8000

EFR

SDP representationCodec


a=rtpmap:4 G723/8000

a=fmtp:4 annexa=yes

G.723.1Annex A


a=rtpmap:100 CLEARMODE/8000

Clearmode


a=rtpmap:97 iLBC/8000

iLBC


a=rtpmap:18 G729A/8000

a=fmtp:18 annexb=yes

G.729aAnnex B


a=rtpmap:18 G729A/8000

G.729a

SDP representationCodec

8/11/2019 11_02_CN3410BEN33GLN0_BICC

30/57

CN3410BEN33GLN0

BICC

30


Terms, describing call setup scenarios (1)

Forward call setup: The bearer connection at Nb is established in the same

direction as the initial call setup message at Nc (from A-sideMGW towards B-side MGW; SAI=FORW).

Backward call setup: The bearer connection at Nb is established in the opposite

direction as the initial call setup message at Nc (from B-side

MGW towards A-side MGW; SAI=BACK).

Delayed MGW selection: MGW selection method in the originating MSC Server when

the originating MGW is selected after the succeeding MSC

Server has selected the MGW (originating MGW selection is

based on the MGW of the succeeding MSS).

Forward bearer establishment.

SAI=DFORW, supported only with ATM bearer currently

8/11/2019 11_02_CN3410BEN33GLN0_BICC

31/57

CN3410BEN33GLN0

BICC

31


Terms, describing call setup scenarios (2)

Forward tunnelling: The initial bearer control protocol message (IPBCP:Request)

is tunneled in the same direction as the initial call setup

message at Nc (from A-side MGW towards B-side MGW).

Backward tunnelling: The initial bearer control protocol message (IPBCP:Request)

is tunneled in the opposite direction to the initial call setup

message at Nc (from B-side MGW towards A-side MGW).

Fast tunnelling: The initial bearer control protocol message (IPBCP:Request)

is exchanged in the first IAM APM message pair.

Delayed tunnelling: The initial bearer control protocol message (IPBCP:Request)

is exchanged in the second and third APM messages (i.e.

after the first IAM APM message pair).

8/11/2019 11_02_CN3410BEN33GLN0_BICC

32/57

CN3410BEN33GLN0

BICC

32


Note: The AddReply

and NotifyReqcommands are

conveyed in the sameH.248 message.

Note: The AddReplyand NotifyReq

commands areconveyed in the sameH.248 message.

Forward IP bearer establishment with fast forwardtunneling, no codec negotiation

1.AddReq(T1,

Event=TunnelInd.

TunOpt=1)

2.AddReply

5. IAM(APP ( "connect forward", BCU-ID1, BNC Char:IP/RTP BCI = IPBCP1, BCT = Tunneling to be used))

10. APM(APP ( "connect forward, no notifification",BCU-ID2, BCI = IPBCP2))

11.ModdReq(IPBCP2)

12.ModReply

19. ANM

14. NbUP Init

15. NbUP Init Ack

Fast forward tunneling is initiated only without codec negotiation and only with

forward bearer establishment.

3.NotifyReq(IPBCP1)

4.NotifyReply

8.NotifyReq(IPBCP2)

9.NotifyReply

18. ACM

ACM depends onthe terminating

side call setup inMSS2.

15.NotifyReq(BNCEst.)

16.NotifyReply


17.NotifyReply

6.AddReq(T2,

Event=TunnelInd,

TunOpt=1,IPBCP1)

7.AddReply

SAI = FORW

UPD.STOM = DCUPD.STOM = DC

13. User Plane established.

The purple parts are the IPtunneling specific items.

The most efficient tunneled bearer establishment method in the terms of the networkresource usage. The Nc and Mc interface resource usage is optimised bytransporting the IPBCP PDUs inside the same protocol messages with the other call

control and bearer establishment related information.

Practical notes about the BIWF, BCU-ID, IPBCP information elements:

-T1 termination is reserved with AddReq message.

-The Event = TunnelInd parameter indicates that IP tunneling will be used.

-The TunOpt (Tunneling Option) = 1 (Same Message) indicates that fastestablishment will be done. Therefore the IPBCP routing info is requested inthe same message as the response to this AddReq.

-In Fast Forward tunneling case the TunOpt = 1 (Same Message) tunneling optionvalue is used in the AddReq H,248 message. That means that the IPBCP data is

requested in the same message as the AddReply, the IPBCP is transferred in theNotifyReq. In this special case the AddReply and the NotifyReq are transferred inone H.248 message. (See the H.248 protocol training for details.)

-BCU-ID1 (BCU-ID of MGW1) and the IPBCP are included in BICC: IAM message

-It is beneficial for influencing the MGW selection in MSS2 via the PBCUattribute (equals to BCU-ID1) in the Preceding UPD determination analysis.

-The IPBCP1 is transferred to MSS2 in BICC: IAM message in the BCIparameter.

-The BCT flag indicates that tunneling is used in this call setup.

-The IPBCP1 is transferred to MGW2 during the T2 termination creation in AddReq

sent by MSS2. The same TunOpt = 1 value is used here.-The IPBCP2 is received from MGW2 by MSS2 in the NotifyReq message.

-Then the IPBCP2 is packed to the BCI parameter of the APM message towardsMSS1.

-Then the ModReq transfers the IPBCP2 to MGW1 from MSS1. The user plane isestablished in this time.

8/11/2019 11_02_CN3410BEN33GLN0_BICC

33/57

CN3410BEN33GLN0

BICC

33


Forward IP bearer establishment with delayed forwardtunneling and codec negotiation

1.AddReq(T1,nocodec,

TunOpt=2)

2.AddReply

3. IAM(APP ( "connect forward", BCU-ID1, BNC Char: IP/RTP,BCT = Tunneling to be used, supported codec list))

4.AddReq(T2,codec,

TunOpt=2)

5.AddReply

6. APM(APP ( "connect forw, no notif+sel cdc", BCU-ID2,selected codec, available codec list))

17.ModReq(IPBCP2)

18.ModReply

25. ANM

20. NbUP Init

21. NbUP Init Ack

Delayed forward tunneling is initiated only with codec negotiation.

9.NotifyReq(IPBCP1)

10.NotifyReply

14.NotifyReq(IPBCP2)

15.NotifyReply

24. ACM

ACM depends on

the terminating


7.ModdReq(EstablishBNC,

selected

codec,

Event=TunnelInd.)

8.ModReply

12.ModReq(IPBCP1,

Event=TunnelInd,)

13.ModReply

11. APM(APP (BCI = IPBCP1))



23.NotifyReply


23.NotifyReply

SAI = FORW

UPD.STOM = CNUPD.STOM = CN



The delayed forward tunneling establishment method offers a separate negotiation phase about thebearer control tunneling usage before the actual bearer control protocol PDU exchange between theMGWs takes place. In practice the negotiation is not considered to bring benefit in the current networkswhere the bearer control tunneling is used exclusively for establishing IP bearer connections and the onlymeans for IP bearer connection establishment is by using IPBCP tunneling. See ITU-T Q.1902.4,

chapters 7.4.4 and 7.5.4 for more details about the different options.The negotiation phase can also be utilised with the codec negotiation to negotiate the selected speechcodec before the bearer establishment. The IPBCP is based on the Session Description Protocol (SDP)and includes Media Announcement and Media Attributes that can in some environments be dependenton the used speech codec; therefore the speech codec should be known before the tunneled bearerestablishment. In the pure 3GPP environment this is not necessarily significant because the Media

Announcement and Media Attributes always follow the same encoding that is defined in the 3GPP TS29.414. See ITU-T Q.1970 and 3GPP TS 29.414 for more information about the IPBCP and its usage inthe 3GPP environment. However, depending on the MGW implementation, it may be a requirement thatthe selected codec is known before the bearer establishment.

The delayed forward tunneling establishment method also offers a possibility for the originating MSS todelay the selection of the MGW and the reservation of the Nc interface resource until the tunneling usagehas been verified with the succeeding MSS, possibly the identity of the succeeding MSS selected MGWis known and the selected codec is known. The information about the identify of the succeeding MSSselected MGW and the selected codec can be used for optimising the MGW selection by the originatingMSS.

The possibility to negotiate the selected speech codec before bearer establishment and to delay theMGW selection by originating MSS are considered the main benefits of this bearer establishment

method.Because of these benefits NSN recommends using the delayed forward tunneling establishment withcalls that include codec negotiation. The delayed MGW selection is currently left for further development.

The most efficient tunneled bearer establishment method in the terms of the network resource usage.The Nc and Mc interface resource usage is optimised by transporting the IPBCP PDUs inside the sameprotocol messages with the other call control and bearer establishment related information.

Because of the efficient network resource usage NSN recommends using the fast forward tunnelingestablishment with calls that do no include codec negotiation.

Practical notes about the BIWF, BCU-ID, IPBCP information elements (in addition to the descriptionwritten to the fast forward tunneling):

-In Delayed Forward tunneling case the TunOpt = 2 (Any Time) tunneling option value is used in theAddReq H,248 message. That means that the IPBCP data is requested in later phase of the call setup.

-Later, the EstablishBNC signal instructs the MGW that the IPBCP information is needed in the MSS.

-EstablishBNC is set in the ModReq message.-Therefore, the IPBCP is transferred to the MSS in a NotifyReq after ModReply.

-The IPBCP exchange is performed in the second half of the bearer establishment period.

8/11/2019 11_02_CN3410BEN33GLN0_BICC

34/57

CN3410BEN33GLN0

BICC

34


Note: The AddReply

and NotifyReqcommands are

conveyed in the sameH.248 message.

Forward IP bearer establishment with fast forwardtunneling and codec negotiation

1. IAM(APP ( "connect forward", BCU-ID1, BNC char:IP/RTP BCI = IPBCP1, BCT = Tunneling to be used,supported codec list))

2.AddReq(T2,

Event=TunnelInd,

TunOpt=1,IPBCP1)

3.AddReply

6. APM(APP ( "connect forw, no notif.+sel codec", BCU-ID2, BCI = IPBCP2, selected codec, available codec list))

13. ANM

8. NbUP Init

9. NbUP Init Ack

4.NotifyReq(IPBCP2)

5.NotifyReply

12. ACM

ACM depends onthe terminating

side call setup inMSS2.Fast forward tunneling with codec

negotiation is never initiated by NSN MSC

Server.

It is supported only on the terminating

side (MSS2).

Differences in red

compared to the

previous slide.

Other vendors

MSC Server


11.NotifyReply

UPD.STOM = CN



The codec negotiation related differences are highlighted on this slide. It is quitesimilar to the ATM BB related slide.

8/11/2019 11_02_CN3410BEN33GLN0_BICC

35/57

CN3410BEN33GLN0

BICC

35


Forward IP bearer establishment with delayed forwardtunneling, no codec negotiation

1. IAM(APP ( "connect forward", BCU-ID1, BNC Char:IP/RTP, BCT = Tunneling to be used))

4. APM(APP ( "connect forw, no notif", BCU-ID2))

17. ANM

12. NbUP Init

13. NbUP Init Ack

16. ACM

ACM depends on

the terminating




Delayed forward tunneling without codec


Server.

It is supported only on the terminating

side (MSS2).

Differences in redcompared to the

previous slide.

Other vendors

MSC Server

UPD.STOM = DC

2.AddReq(T2,codec,

TunOpt=2)

3.AddReply

8.NotifyReq(IPBCP2)

9.NotifyReply

6.ModReq(IPBCP1,

Event=TunnelInd,)


15.NotifyReply

7.ModReply



8/11/2019 11_02_CN3410BEN33GLN0_BICC

36/57

8/11/2019 11_02_CN3410BEN33GLN0_BICC

37/57

CN3410BEN33GLN0

BICC

37


Backward IP bearer establishment with fast forwardtunneling and codec negotiation

1. IAM(APP ( "connect backward", BCU-ID1, BNC Char:IP/RTP, BCT = Tunneling to be used, BCI = IPBCP1,supported codec list))

2.AddReq(T2,codec,

IPBCP1,TunOpt=1)

3.AddReply


13. ANM

9. NbUP Init

10. NbUP Init Ack

4.NotifyReq(IPBCP2)

5.NotifyReply

12. ACM

ACM depends on

the terminatingside call setup in

MSS2.

11. APM(APP (connected))

Fast forward tunneling with backward

bearer establishment is never initiated by

NSN MSC.

Codecs and IPBCP can be sent back in 1

APM message (instead of 2 APM

messages) according to the standards.

NSN MSC Server prefers the version with 2

APM messages.

Differences in red compared

to the previous slide.

Other vendors

MSC Server

6. APM(APP (selected codec,selected codec, available codec list))

UPD.STOM = CN



8/11/2019 11_02_CN3410BEN33GLN0_BICC

38/57

CN3410BEN33GLN0

BICC

38


Backward IP bearer establishment with delayed backwardtunneling, no codec negotiation

1. IAM(APP ( "connect backward", BCU-ID1,BNC Char: IP/RTP, BCT = Tunneling to be used))

2.AddReq(T2,codec,

Event=TunnelInd

TunOpt=1,Estab.Bearer)

3.AddReply

16. ANM

4.NotifyReq(IPBCP2)

5.NotifyReply

15. ACM

ACM depends on

the terminating


8.ModReq(IPBCP1)

9.ModReply



Delayed backward tunneling without

codec negotiation is never initiated by

NSN MSC Server. It is supported only on

the terminating side (MSS2).

Other vendors

MSC Server


14.NotifyReply

UPD.STOM = DC


11. NbUP Init

12. NbUP Init AckNbUP (IuUP also)initialisation is executed

end-to-end and it is always

done in forward direction

regardless of the bearer

establishment direction.


The delayed backward tunneling establishment method does not offer similarnegotiation about the bearer control tunneling usage as the delayed forwardtunneling establishment method does. Nor does it offer the possibility for delayed

MGW selection by the originating MSS or the efficiency of the fast forwardestablishment method. See ITU-T Q.1902.4, chapters 7.4.5 and 7.5.5 for moredetails about the different options.

Similarly to the delayed forward tunneling establishment method the codecnegotiation can be completed before the bearer establishment.

It may be possible that the establishment method has interworking problems with theNb interface user plane protocol; since the bearer establishment is made in anopposite direction compared to the Nb interface user plane protocol initialisation, it ispossible that the originating side MGW will start the initialisation attempts before thebearer connection has been end-to-end established. This is due to the fact that theoriginating side MGW will consider the establishment complete from its point of viewafter sending the IPBCP Accepted message, however the bearer establishment isnot completed until the succeeding MGW has received and processed the message.

8/11/2019 11_02_CN3410BEN33GLN0_BICC

39/57

CN3410BEN33GLN0

BICC

39


Backward IP bearer establishment with delayed backwardtunneling and codec negotiation

1. IAM(APP ( "connect backward", BCU-ID1, BNC Char: IP/RTP,BCT = Tunneling to be used, supported codec list))

17. ANM

16. ACM

ACM depends on

the terminating





Delayed backward tunneling with codec


Server. It is supported only on the

terminating side (MSS2).

Codecs and IPBCP can be sent back in 1

APM message (instead of 2 APM

messages) according to the standards.

NSN MSC Server prefers the version with 2

APM messages.

Differences in red compared

to the previous slide.

Other vendors

MSC Server

6. APM(APP (selected codec,selected codec, available codec list))

UPD.STOM = CN

2.AddReq(T2,codec,

Event=TunnelInd

TunOpt=1,Estab.Bearer)

3.AddReply

4.NotifyReq(IPBCP2)

5.NotifyReply

9.ModReq(IPBCP1)

10.ModReply


15.NotifyReply


12. NbUP Init

13. NbUP Init Ack

8/11/2019 11_02_CN3410BEN33GLN0_BICC

40/57

CN3410BEN33GLN0

BICC

40


1.AddReq(T1,codec,

RequestingBIWF1)

2.AddReply(BIWF1)

3. IAM(APP ( "connect forward", BCU-ID1, BIWF1,BNC Char: ATM AAL2))

4.AddReq(T2,

RequestingBIWF2,BNC-ID2)

5.AddReply(BIWF2,

BNC-ID2)

6. APM(APP ( "connect forward, no notification",BCU-ID2, BNC-ID2, BIWF2))

7.ModdReq(BIWF2,

BNC-ID2,Est.Bearersignal)

9.ModReply

16. ANM

8. AAL2 ERQ

10. AAL2 ECF

15. ACM

ACM depends on


MSS2.

11. NbUP Init

12. NbUP Init Ack


14.NotifyReply


14.NotifyReply

SAI = FORW


Forward ATM bearer establishment, no codec negotiation

Practical notes about the BIWF, BCU-ID, BNC-ID information elements:

-T1 termination reservation is requested from MGW1 with codec information. TheBIWF1 address is requested from the MGW1.

-BIWF1 is received from the MGW1 in AddReply in MSS1 as a result of the T1termination reservation.

-BNC-ID1 is not requested from MGW1 as MSS1 doesnt need BNC-ID information.MSS2/MGW2 dont need BNC-ID as well as the forward establishment is used in thiscase.

-BIWF1 and BCU-ID1 is transferred in BICC: IAM to MSS2 from MSS1 only forsupporting the optimal MGW selection:

-If a physical MGW is shared between the MSS1 and MSS2 then the MSS2can realize that MSS1 selected the common physical MGW based on theBIWF1 information.

See User Plane Routing Functional Description (dn01163601) chapter 7.2MGW selection optimisation based on BIWF address for details.

-BCU-ID1 (MGW ID of MGW1) can influence the MGW selection in MSS2 inthe Preceding UPD determination analysis. The PBCU attribute of the PUPDdetermination analysis has the value of BCU-ID1.

-The T2 termination reservation is requested from MGW2 by MSS2. The BIWF2 andBNC-ID2 information is requested from MGW2 in the AddReq message.

-After the T2 termination is reserved in MGW2 the BNC-ID2 and BIWF2 parametersare received in AddReply from MGW2.

-Then these parameters are transferred to MSS1 in the APM message (IAMresponse).

-Next MSS1 sends these information to MGW1 in ModReq message in order to beable to establish the bearer in forward direction. The bearer establishment isrequested by the Establish Bearer signal in the ModReq message.

-Then the connection between the MGWs are setup with the AAL2 ERQ and AAL2ECF messages between MGW1 and MGW2.

-After the bearer is established end to end (NbUP framing protocol initialisation issuccessfully finished.) a NotifyReq message is sent to MSS1 and MSS2 from MGW1

8/11/2019 11_02_CN3410BEN33GLN0_BICC

41/57

CN3410BEN33GLN0

BICC

41


Forward ATM bearer establishment, with codec negotiation

1.AddReq(T1,no

codec,

RequestingBIWF1)

2.AddReply(BIWF1)

3. IAM(APP ( "connect forward", BCU-ID1, BIWF1,BNC Char: ATM AAL2, supported codecs list))

4.AddReq(T2,


5.AddReply(BIWF2,

BNC-ID2)

6. APM(APP ("connect forw, no notif+ selected codec",

BCU-ID2, BNC-ID2, BIWF2, sel codec, avail. codecs list))

7.ModdReq(BIWF2,BNC-ID2,

codec,Est.Bearersignal)

9.ModReply

16. ANM

8. AAL2 ERQ

10. AAL2 ECF

Differences in red compared to the previous slide.

15. ACM

ACM depends on


MSS2.

11. NbUP Init

12. NbUP Init Ack


14.NotifyReply


14.NotifyReply

SAI = FORW

UPD.STOM = CN

UPD.STOM = CN

Only the codec negotiation related information differs compared to the previous slide.

-The STOM parameter of the used UPDs shall be modified to CN value in bothMSSs configuration. See JF MML command group for more details.

-No codec is sent to the MGW1 in the first AddReq message.

-The Supported Codec List is filled in the BICC: IAM message.

-Different action indicator (* + selected codec) is used in the response: APMmessage. Additionally, the Available Codec List and the Selected Codec istransferred to MSS1 in the APM message.

-The selected codec is transferred to the MGW1 in the ModReq message.

8/11/2019 11_02_CN3410BEN33GLN0_BICC

42/57

CN3410BEN33GLN0

BICC

42


5.AddReq(T1,BIWF2,

BNC-ID2,EstablishBearersignal)

Forward ATM bearer establishment with delayed MGWselection, no codec negotiation

7.AddReply

1. IAM(APP ( "connect forward, BNC Char: ATM AAL2"))

2.AddReq(T2,


3.AddReply(BIWF2,

BNC-ID2)

4. APM(APP ( "connect forward, no notif.", BCU-ID2,BNC-ID2, BIWF2))

14. ANM

6. ERQ

8. ECF

13. ACM

ACM depends on


MSS2.


12.NotifyReply


12.NotifyReply

9. NbUP Init10. NbUP Init Ack

The SUPD

determination

analysis is

executed again.

This is the main

benefit of this

method: the

preceding side

MGW selection

can be based on

the SBCU.

There is no

change in the

succeeding

MSS in case of

delayed MGW

selection. The

forward

establishment

works in the

same way with

delayed and

non-delayed

MGW selection.

SAI = DFORW


The bearer related information exchange is similar to the forward establishment withnon-delayed MGW selection as both cases are about forward bearer establishment.

The differences are the following:

-As there is no MGW selected in the MSS1 no BIWF1 and BCU-ID1 is transferred toMSS2 in the BICC: IAM message.

-BNC-ID2 and BIWF2 parameters are transferred to MGW1 in the same way asdescribed at the non-delayed MGW selection.

-MSS2 requests BIWF and BNC-ID from MGW2 in AddReq

-MGW2 send BIWF2 and BNC-ID2 to MSS2 in AddReqply

-BIWF2 and BNC-ID2 are included in BICC: APM

-MSS1 reserves T1 termination and send the BIWF2 and BNC-ID2parameters in AddReq.

-The Succeeding UPD determination analysis is executed again when the APMmessage (IAM response) is received.

-This is the main benefit of the delayed MGW selection procedure.

-The Succeeding UPD determination analysis can be influenced with theSucceeding BCU-ID (SBCU). Therefore more optimal MGW selection can besupported in MSS1 as the MGW selection procedure depends on theselected MGW under MSS2.

-Please refer to User Plane Routing Functional Description (dn01163601) chapter7.3 MGW selection optimisation based on BCU-ID for details.

8/11/2019 11_02_CN3410BEN33GLN0_BICC

43/57

CN3410BEN33GLN0

BICC

43


1.AddReq(T1,codec,


Backward ATM bearer establishment, no codec negotiation

2.AddReply(BNC-ID1,

BIWF1)

3. IAM(APP ( "connect backward", BCU-ID1,

BIWF1, BNC-ID1, BNC Char: ATM AAL2))

4.AddReq(T2,BIWF1,BNC-ID1,

EstablishBearersignal)

6.AddReply

13. ANM

5. ERQ

7. ECF

12. ACM

ACM depends on theterminating side call

setup in MSS2.

8. NbUP Init

9. NbUP Init Ack


11.NotifyReply

SAI = BACK



11.NotifyReply

NbUP (IuUP also)

initialisation is

executed end-to-

end and it is always

done in forward

direction regardless

of the bearer

establishment

direction.

Practical notes about the BIWF, BCU-ID, BNC-ID information elements in case ofbackward establishment method:

-T1 termination reservation is requested from MGW1 with codec information. TheBIWF1 and BNC-ID1 are requested from the MGW1.

-MSS1 receives the BNC-ID1 and BIWF1 from MGW1 in AddReply when the T1termination is reserved.

-MSS1 packs the BCU-ID1, BNC-ID1, BIWF1 into the BICC: IAM message. All theuser plane routing information is needed at the terminating side in case of backwardestablishment.

-The MGW selection optimisation based on BIWF address functionality canbe used here also.See User Plane Routing Functional Description (dn01163601) chapter 7.2MGW selection optimisation based on BIWF address for details.

-BCU-ID1 (MGW ID of MGW1) can influence the MGW selection in MSS2 inthe Preceding UPD determination analysis. The PBCU attribute of the PUPDdetermination analysis has the value of BCU-ID1.

-MSS2 sends the BNC-ID1 and BIWF1 to MGW2 in the AddReq during T2termination creation. Therefore the backward establishment can be done in thisphase.

The later phases are similar to the forward establishment case:

-NbUP framing protocol initialisation is done.

-NbUP (IuUP also) initialisation is executed end-to-end and it is always donein forward direction regardless of the bearer establishment direction.

-Then notifications about Bearer Establishment is sent by the MGWs.

-Call setup is finished on control plane.

8/11/2019 11_02_CN3410BEN33GLN0_BICC

44/57

CN3410BEN33GLN0

BICC

44


Backward ATM bearer establishment with codecnegotiation

1.AddReq(T1,no

codec,


2.AddReply(BNC-ID1,

BIWF1)

4.AddReq(T2,BIWF1,

BNC-ID1,

EstablishBearersignal)

6.AddReply

16. ANM

5. ERQ

7. ECF

15. ACM

ACM depends on theterminating side call

setup in MSS2.

11. NbUP Init

12. NbUP Init Ack


14.NotifyReply

SAI = BACK

UPD.STOM = CN

UPD.STOM = CN


14.NotifyReply

Differences in red compared to the previous slide.

3. IAM(APP ( "connect backward", BCU-ID1, BNC-ID1,BIWF1, BNC Char: ATM AAL2, supported codec list))

8. APM(APP ( selected codec",selected codec, available codec list))

9.ModdReq(

selectedcodec)

10.ModReply

Only the codec negotiation related information differs compared to the previous slide.

-The STOM parameter of the used UPDs shall be modified to CN value in bothMSSs configuration. See JF MML command group for more details.

-No codec is sent to the MGW1 in the first AddReq message.

-The Supported Codec List is filled in the BICC: IAM message.

-An additional APM message is used from MSS2 to MSS1 to transfer the codecinformation. The selected codec action indicator is used in the APM message andthe Available Codec List and the Selected Codec are included.

-The selected codec is transferred to the MGW1 in the ModReq message.

-Note: T1 termination modification in MGW1 (e.g. with codec) is possible after ATMAAL2 connection establishment if the NbUP protocol layer is not yet built up.

-The NbUP framing protocol initialisation is done later.

-The other steps are similar to the backward establishment without codecnegotiation.

8/11/2019 11_02_CN3410BEN33GLN0_BICC

45/57

CN3410BEN33GLN0

BICC

45


BICC usage in MSS : BICC supports

Call and bearer establishment over AAL2 and IP

Codec negotiation procedure

Codec modify procedure

Out of band transport of DTMFs

APM/BAT ASE functionality

Bearer Redirection Enable rerouting of user plane after some sort of optimization is needed

Automatic Rerouting (Crankback mechanism) Allows the call set-up to return to the preceding Serving Network (SN) so that the call can

automatically be rerouted from there

New functionality defined for BICC

8/11/2019 11_02_CN3410BEN33GLN0_BICC

46/57

CN3410BEN33GLN0

BICC

46


Action Indicator supported in MSS (M14)

Not SupportedSupportedConnect backwardDelayed backward est. (IP)

Not SupportedSupportedConnect backwardFast backward est. (IP)

Supported 2SupportedConnect forwardDelayed forward est. (IP)

Supported 1SupportedConnect forwardFast forward est. (IP)

SupportedSupportedConnect forwardForward est. with delayed MGWselection (ATM)

SupportedSupportedConnect backwardBackward est (ATM)

SupportedSupportedConnect forwardForward est. (ATM)

Support in outgoingcall from MSS

Support in incomingcall to MSS

Action Indicator valueBICC bearer establishmentmethod

1. Establishment with codec negotiation is not supported.2. Only establishment with codec negotiation is supported.

8/11/2019 11_02_CN3410BEN33GLN0_BICC

47/57

CN3410BEN33GLN0

BICC

47


BICC parameter and their sources in incoming andoutgoing call in MSS

BCU identifier from the selected MGW'sdata or Succeeding Bearer Control Unitidentifier (SBCU) in user plane analysis.

Preceding Bearer Control Unitidentifier (PBCU) in user plane analysisor BCU identifier from the selectedMGW's data.

Bearer Control Unit Identifier

None. Parameter is present whenbearer control tunnelling is used forestablishing bearer connections.

None. Parameter is present whenbearer control tunnelling is used forestablishing bearer connections.

Bearer Control Tunneling

None. Parameter is conveyed as suchto the MGW.


Bearer Control Information

Succeeding Bearer NetworkCharacteristics (SBNC) is the result ofuser plane analysis.

Preceding Bearer NetworkCharacteristics (PBNC) attribute can beanalysed in user plane analysis

Bearer Network ConnectionCharacteristics



Interworking Function Address



Backbone Network ConnectionIdentifier

Succeeding Action Indicator (SAI) isthe result of user plane analysis.

Preceding Action Indicator (PAI)attribute can be analysed in user planeanalysis.

Action Indicator

Configurable parameter in MSS,If any

Configurable parameter in MSS,If any

BICC parameter

Outgoing CallIncoming Call

8/11/2019 11_02_CN3410BEN33GLN0_BICC

48/57

CN3410BEN33GLN0

BICC

48


BICC parameter generated internally in MSS inincoming and outgoing call

Succeeding Signaling type (SSIGT)Route data (OUTR)

Succeeding User Plane Destination reference(SUPDR)

Route data (UPDR)Outgoing call from MSS

Preceding Emergency call indicator (EMCI)Dialing pre-analysis

Preceding Signaling type (PSIGT)Circuit groups data (UPART)

Preceding User Plane Destination reference(PUPDR)

Circuit groups data (UPDR)Incoming call to MSS

Configurable parameter in MSS,

If any

Location of dataCall direction

8/11/2019 11_02_CN3410BEN33GLN0_BICC

49/57

CN3410BEN33GLN0

BICC

49


Codec Selection : Tandem Free Operation (TFO) vsTranscoder Free Operation (TrFO)

- TFO

8/11/2019 11_02_CN3410BEN33GLN0_BICC

50/57

CN3410BEN33GLN0

BICC

50


Codec Selection : Tandem Free Operation (TFO) vsTranscoder Free Operation (TrFO)

- TrFO : Codec negotiation using BICC APP parameter

8/11/2019 11_02_CN3410BEN33GLN0_BICC

51/57

CN3410BEN33GLN0

BICC

51


Successful BICC codec negotiation

8/11/2019 11_02_CN3410BEN33GLN0_BICC

52/57

CN3410BEN33GLN0

BICC

52


Transcoder at the edge

8/11/2019 11_02_CN3410BEN33GLN0_BICC

53/57

CN3410BEN33GLN0

BICC

53


Transcoder at the edge : UE originated call

8/11/2019 11_02_CN3410BEN33GLN0_BICC

54/57

CN3410BEN33GLN0

BICC

54


Transcoder at the edge : PSTN originated call

8/11/2019 11_02_CN3410BEN33GLN0_BICC

55/57

8/11/2019 11_02_CN3410BEN33GLN0_BICC

56/57

CN3410BEN33GLN0

BICC

56


Payload optimization with TFO

8/11/2019 11_02_CN3410BEN33GLN0_BICC

57/57

BICC


Basic codec modification with BICC signaling

11_02_cn3410ben33gln0_bicc

Documents