Switching Core Network

Signalling Delta

BICC
Training Document M14/U4

© Nokia Siemens Networks 1 (63)

Contents

Legal notice
Intellectual Property Rights
All copyrights and intellectual property rights for Nokia Siemens Networks training
documentation, product documentation and slide presentation material, all of which are
forthwith known as Nokia Siemens Networks training material, are the exclusive property of
Nokia Siemens Networks. Nokia Siemens Networks owns the rights to copying, modification,
translation, adaptation or derivatives including any improvements or developments. Nokia
Siemens Networks has the sole right to copy, distribute, amend, modify, develop, license,
sublicense, sell, transfer and assign the Nokia Siemens Networks training material. Individuals
can use the Nokia Siemens Networks training material for their own personal self-
development only, those same individuals cannot subsequently pass on that same Intellectual
Property to others without the prior written agreement of Nokia Siemens Networks. The Nokia
Siemens Networks training material cannot be used outside of an agreed Nokia Siemens
Networks training session for development of groups without the prior written agreement of
Nokia Siemens Networks.
Indemnity
The information in this document is subject to change without notice and describes only the
product defined in the introduction of this documentation. This document is intended for the
use of Nokia Siemens Networks customers only for the purposes of the agreement under
which the document is submitted, and no part of it may be used, reproduced, modified or
transmitted in any form or means without the prior written permission of Nokia Siemens
Networks. The document has been prepared to be used by professional and properly trained
personnel, and the customer assumes full responsibility when using it. Nokia Siemens
Networks welcomes customer comments as part of the process of continuous development
and improvement of the documentation.
The information or statements given in this document concerning the suitability, capacity, or
performance of the mentioned hardware or software products are given “as is” and all liability
arising in connection with such hardware or software products shall be defined conclusively in
a separate agreement between Nokia Siemens Networks and the customer. However, Nokia
Siemens Networks has made all reasonable efforts to ensure that the instructions contained in
the document are adequate and free of material errors and omissions. Nokia Siemens
Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may
not be covered by the document.
Nokia Siemens Networks will correct errors in the document as soon as possible. IN NO
EVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THIS
DOCUMENT OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL,
DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY MONETARY
LOSSES,SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS
INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE
USE OF THIS DOCUMENT OR THE INFORMATION IN IT
This document and the product it describes are considered protected by copyrights and other
intellectual property rights according to the applicable laws.
Wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of
Nokia Corporation. Siemens is a registered trademark of Siemens AG.
Other product names mentioned in this document may be trademarks of their respective
owners, and they are mentioned for identification purposes only.
Copyright © Nokia Siemens Networks 2009. All rights reserved.

© Nokia Siemens Networks 2 (63)

Contents

Contents

1 Introduction ............................................................................................6

2 ATM- or IP Bearer ...................................................................................9

2.1 Call Setup Direction..................................................................................9
2.2 Bearer Control Signalling .......................................................................10

3 BICC Messages ....................................................................................12

4 BICC Message Format .........................................................................16

4.1 BICC Message Format and Codes (Q.1902.3) ......................................16
4.2 Application Transport Mechanism – APM (ITU-T Q.765.3)...................20
4.2.1 Format of Application Transport Parameter (APP).................................21
4.2.2 Encapsulated Application Information ....................................................22
4.3 Action Indicator (AI)................................................................................25
4.4 Codec List ..............................................................................................27
4.5 Bearer Control Information .....................................................................29
4.5.1 Bearer Control Tunnelling Protocol (BCTP) ...........................................29
4.5.2 IP Bearer Control Protocol (IPBCP) ......................................................30

5 Bearer Establishment Methods...........................................................38

5.1 Establishment of IP bearers ...................................................................38
5.1.1 Forward IP bearer establishment with fast forward tunnelling
without codec negotiation.......................................................................40
5.1.2 Forward IP bearer establishment with delayed forward
tunnelling and codec negotiation............................................................42
5.1.3 Forward IP bearer establishment with fast forward tunnelling
and codec negotiation ............................................................................43
5.1.4 Forward IP bearer establishment with delayed forward
tunnelling and no codec negotiation.......................................................44
5.1.5 Backward IP bearer establishment with fast forward tunnelling
and no codec negotiation .......................................................................45
5.1.6 Backward IP bearer establishment with fast forward tunnelling
and codec negotiation ............................................................................46
5.1.7 Backward IP bearer establishment with delayed backward
tunnelling and no codec negotiation.......................................................47
5.1.8 Backward IP bearer establishment with delayed backward
tunnelling and codec negotiation............................................................48
5.2 Establishment of ATM bearers ...............................................................49
5.2.1 Forward ATM bearer establishment without codec negotiation .............50
5.2.2 Forward ATM bearer establishment with codec negotiation ..................51
5.2.3 Forward ATM bearer establishment with delayed MGW
selection and no codec negotiation ........................................................52
5.2.4 Backward ATM bearer selection without codec negotiation...................53
5.2.5 Backward ATM bearer establishment with codec negotiation................54

© Nokia Siemens Networks 3 (63)

Contents

6 BICC Usage in MSS ............................................................................. 56

6.1 General.................................................................................................. 56
6.2 Establishment Direction of User Plane Connection............................... 57
6.3 Codec Selection and Modification ......................................................... 60

© Nokia Siemens Networks 4 (63)

38BSummary of changes

Summary of changes

© Nokia Siemens Networks 5 (63)

Error! No text of specified style in document.

1 Introduction
The Bearer Independent Call Control Protocol (BICC, ITU-T Q.1902) is a
call control protocol designed to transport call control signalling
information, independent of the used bearer technology and
signalling message transport technology.
Signalling message transport independence means that BICC signalling
can be transported over several different signalling transports such as
MTP3, MTP3b or SIGTRAN. Between two Nokia Siemens Networks
MSS, BICC will be transported over IP (=SIGTRAN).
Bearer independence means that the bearer for a call, controlled by
BICC signalling, can be ATM, IP/Ethernet or something else.

A second function beside call control is the transport of bearer related

information (e.g. available codecs or IP addresses) between the
serving nodes, involved in a call. This bearer information is usually
provided by the MGWs who utilize the BICC protocol just as
transmission medium for communication.
BICC accomplishes this by defining a set of procedures separately for
call control signalling and transport of bearer control information.

According to the 3GPP Rel.4 core network concept, the BICC protocol is
used at the Nc interface, between MSS and other MSS – GMSS.
Since BICC is based on ISUP it provides natural interworking with ISUP
and BICC networks and allows the existing supplementary services to
be used without modifications.

© Nokia Siemens Networks 6 (63)

Error! No text of specified style in document.

BICC CS-2
IP
Control MSC Server MSC Server/
plane Nc GCS

H.248
H.248

Mc
IP

IP
Mc
User
Nb
plane AAL2/AAL5 RTP
MGW ATM or IP MGW

Figure 1. BICC protocol in a Rel.4 network

.
Bearer information .
carried inside call IP address: 192.168.3.2
control messages Port: 5964
Codec: AMR mode 7
.
MSC Server MSC Server .

IAM

BICC
M3UA
IP: 192.168.3.2 Sigtran
port: 5964 SCTP
MGW MGW
IP

Figure 2. Bearer information transport and call control

© Nokia Siemens Networks 7 (63)

Error! No text of specified style in document.

According to the 3GPP Rel. 4 network layout, several arrangements are

possible for nodes that support BICC signalling.
Serving Nodes (SN) have an associated Bearer Control Function (BCF).
A node without an associated BCF is referred to as Call Mediation Node
(CMN).
If these functionalities are realized with network elements from Nokia
Siemens Networks, the MSS represents a SN and the MGW represents
BCF and BIWF. An MSS is a CMN if it is involved in call control
signalling, but does not control the bearer for that call.
In any case, a separate Bearer Control Protocol is required for
establishing calls through an IP- or ATM based backbone. In case of IP,
this will be the IP Bearer Control Protocol (IPBCP) and in case of ATM,
the bearer control protocol will be AAL-Type-2 signalling.

SN CMN SN

Control Call Control Call Control

CSF CSF CSF
plane Signalling Signalling

Call Bearer Control

Call Bearer Control

Signalling (CBC)
Signalling (CBC)

BIWF BIWF
User Bearer Control
plane BCF BCF
Signalling

Bearer
Bearer

Figure 3. Rel 4 functional blocks

© Nokia Siemens Networks 8 (63)

Error! No text of specified style in document.

2 ATM- or IP Bearer

Depending on the bearer technology at the Nb interface, BICC supports

different bearer establishment methods between MGWs.
Here, just an overview is given. A detailed explanation of all possible
combinations can be found in section 6 of this chapter.

2.1 Call Setup Direction

Unlike ISUP, BICC supports forward and backward call setup, whereas
the originating node selects the bearer establishment method (user
plane analysis)
Forward call setup:
The bearer connection at Nb is established in the same direction as the
initial call setup message at Nc (from A-side MGW towards B-side
MGW).
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).
For an IP bearer, Nokia Siemens Networks' network elements support
forward call setup on originating and terminating side. Backward call
setup with IP bearer is just supported at the terminating side, if another
vendor's MSS has initiated it.
For ATM bearers, both methods are supported.

© Nokia Siemens Networks 9 (63)

Error! No text of specified style in document.

MSS MSS
BICC:IAM

Forward
Bearer establishment direction

MSS MSS
BICC:IAM

Backward

Bearer establishment direction

MGW MGW

Figure 4. Bearer establishment direction

2.2 Bearer Control Signalling

IP backbone
Prior to establishing a bearer connection through IP backbones, the IP
Bearer Control Protocol (IPBCP) is exchanged between the involved
MGWs. Amongst other information, IP addresses and port numbers of
either side are exchanged. The messages of this protocol are not
transmitted directly from MGW to MGW but via the MSS, controlling the
MGWs. IPBCP messages are encapsulated inside H.248 between MGW
and MSS and inside BICC messages between adjacent MSSs.
Details of the IPBCP protocol and the tunneling mechanism are
explained further below in this chapter.

© Nokia Siemens Networks 10 (63)

Error! No text of specified style in document.

ATM backbone
In case of ATM backbones, AAL-Type-2 signalling messages are
exchanged directly between adjacent MGWs for establishing the AAL
bearer. AAL-Type-2 messages are not tunneled inside other protocols.
This is the same AAL2 signalling protocol as between MGW and RNC.

Call Control Signalling

MSS BICC or SIP MSS

I P backbone:
the IPBCP prot ocol is tunneled
inside H.248 and BICC(or SIP)
via the MSCServers.

H.248 H.248

ATM backbone:
separate bearer control
signalling: AAL-Type-2
signalling
Bearer Control Signalling
e.g: AAL2 signalling

MGW MGW

Figure 5. Bearer control signalling transport

© Nokia Siemens Networks 11 (63)

Error! No text of specified style in document.

3 BICC Messages
The BICC messages are used by the peer-to-peer protocol very much
like ISUP messages. Most messages have the same meaning as their
ISUP cóunterparts.
As with ISUP, also the BICC messages may be divided into two groups,
presented in the following two tables.

Table 1 BICC call control related messages (Q.1902.3)

Message Code Description

ACM 0000 0110 Address Complete Message: A message sent in the
backward direction indicating that all the address signals
required for routeing the call to the called party have been
received.
ANM 0000 1001 Answer message: A message sent in the backward direction
indicating that the call has been answered. In semi-automatic
working, this message has a supervisory function. In
automatic working, this message is used in conjunction with
charging information in order to start metering the charge to
the calling subscriber (see Recommendation Q.28 [2]); and
start measurement of call duration for international accounting
purposes (see Recommendation E.260.
APM 0100 0001 Application Transport message: A message sent in either
direction to convey application information using the
Application Transport mechanism.
COT 0000 0101 Continuity message: A message sent in the forward
direction indicating that the establishment of the bearer is
complete up to and including the SN sending the COT
message.
CON 0000 0111 Connect message: A message sent in the backward
direction indicating that all the address signals required for
routeing the call to the called party have been received and
that the call has been answered.

© Nokia Siemens Networks 12 (63)

Error! No text of specified style in document.

CPG 0010 1100 Call Progress message: A message, sent in either direction
during the setup or active phase of the call, indicating that an
event, which is of significance, and should be relayed to the
originating or terminating access, has occurred.
IAM 0000 0001 Initial Address message: A message sent in the forward
direction to initiate seizure of an outgoing circuit and to
transmit number and other information relating to the routeing
and handling of a call.
IDR 0011 0110 Identification Request message: A message sent in the
backward direction to request action regarding the malicious
call identification supplementary service.
INF 0000 0100 Information message: A message sent to convey
information in association with a call, which may have been
requested in an information request message. (National use)
INR 0000 0011 Information Request message: A message sent by an
exchange to request information in association with a call.
(National use)
IRS 0011 0111 Identification Response message: A message sent in
response to the identification request message.
PRI 0100 0010 Pre-release Information message: A message to be used
with the Release message for the transport of information
where sending of that information in the Release message
itself would cause compatibility problems with ISUP Q.764
and BICC CS1 Q1902.4.
REL 0000 1100 Release message: A message sent in either direction to
indicate that the circuit /CICis being released due to the
reason (cause) supplied and is ready to be put into the idle
state on receipt of the release complete message. Where the
call is to be redirected the message will also carry the
redirection number.
RES 0000 1110 Resume message: A message sent in either direction
indicating that the calling or called party, after having been
suspended, is reconnected.
RLC 0001 0000 Release Complete message: A message sent in either
direction in response to the receipt of a release message, or if
appropriate to a reset circuit message, when the circuit/CIC
concerned has been brought into the idle condition.
SAM 0000 0010 Subsequent Address Message: A message that may be
sent in the forward direction following an initial address
message, to convey additional called party number
information.
SGM 0011 1000 Segmentation Message: A message sent in either direction
to convey an additional segment of the message.
SUS 0000 1101 Suspend message: A message sent in either direction
indicating that the calling or called party has been temporarily
disconnected.
USR 0010 1101 User-to-user information message: A message to be used
for the transport of user-to-user signalling independent of call
control messages.

© Nokia Siemens Networks 13 (63)

Error! No text of specified style in document.

The use of the BICC messages depends on the BICC procedure and will
be discussed in the following chapters.

Table 2 BICC maintenance related messages (Q.1902.3)

Message Code Description

CGB 0001 1000 Circuit/CIC Group Blocking message: A message sent to
the node to permit the switching equipment or maintenance
system to remove from (and return to) traffic a group of
circuits/CICs. A node receiving a Circuit/CIC group blocking
message must be able to accept incoming calls on the group
of blocked circuits/CICs unless it has also sent a Circuit/CIC
group blocking message.
CGBA 0001 1010 Circuit/CIC Group Blocking Acknowledgement message:
A message sent in response to a circuit/CIC group blocking
message to indicate that the requested group of circuits/CIC
has been blocked.
GRS 0001 0111 Circuit/CIC Group Reset message: A message sent to
release an identified group of circuits/CIC when, due to
memory mutilation or other causes, it is unknown whether for
example, a REL or RLC message is appropriate for each of
the circuits/CICs in the group. If at the receiving end a circuit
is remotely blocked, reception of this message should cause
that condition to be removed.
GRA 0010 1001 Circuit/CIC Group Reset Acknowledgement message: A
message sent in response to a circuit/CIC group reset
message and indicating that the requested group of
circuits/CIC has been reset. The message also indicates the
maintenance blocking state of each circuit/CIC.
CGU 0001 1001 Circuit/CIC Group Unblocking message: A message sent
to the exchange at the other end of an identified group of
circuits/CIC to cause cancellation in that group of circuits of
an engaged condition invoked earlier by a blocking or
circuit/CIC group blocking message.
CGUA 0001 1011 Circuit/CIC Group Unblocking Acknowledgement
message: A message sent in response to a circuit/CIC group
unblocking message to indicate that the requested group of
circuits/CICs has been unblocked.
CQM 0010 1010 Circuit/CIC group Query Message: A message sent on a
routine or demand basis to request the far-end exchange to
give the state of all circuits/CICs in a particular range.
CQR 0010 1011 Circuit/CIC group Query Response message: A message
sent in response to a circuit group query message to indicate
the state of all circuits in a particular range.
CFN 0010 1111 Confusion message: A message sent in response to any
message (other than a confusion message) if the exchange
does not recognize the message or detects a part of the
message as being unrecognised. (Partly supported)

© Nokia Siemens Networks 14 (63)

Error! No text of specified style in document.

FAA 0010 0000 Facility Accepted message: A message sent in response to

a facility request message indicating that the requested facility
has been invoked.
FAC 0011 0011 Facility message: A message sent in either direction at any
phase of the call to request an action at another exchange.
The message is also used to carry the results, error or
rejection of a previously requested action.
FRJ 0010 0001 Facility Reject message: A message sent in response to a
facility request message to indicate that the facility request
has been rejected.
FAR 0001 1111 Facility Request message: A message sent from an
exchange to another exchange to request activation of a
facility.
RSC 0001 0010 Reset Circuit/CIC message: A message sent to release a
circuit/CIC when, due to memory mutilation or other causes, it
is unknown whether for example, a release or a release
complete message is appropriate. If, at the receiving end, the
circuit/CIC is remotely blocked, reception of this message
should cause that condition to be removed.
UCIC 0010 1110 Unequipped Circuit Identification Code message: A
message sent from one exchange to another when it receives
an unequipped circuit/CIC identification code. (National use).

The use of the BICC messages depends on the BICC procedure and will
be discussed in the following chapters.

© Nokia Siemens Networks 15 (63)

Error! No text of specified style in document.

4 BICC Message Format

4.1 BICC Message Format and Codes (Q.1902.3)

The ASN1 format
BICC messages use the ASN1 format. Any message in this format,
depending on the type of message, can contain different parameters.
Each parameter has this structure: parameter code, parameter length
and parameter contents. Since parameters may have variable lengths,
pointers are used to indicate the beginning of each parameter of variable
length.
To this aspect, BICC is not different than any other, ASN.1 coded
protocol.

This structure results in a logical division of the BICC messages into

these parts:
• call instance code (CIC)
• message type code
• mandatory fixed part
• mandatory variable part
• optional part, which can contain fixed length and variable length
fields.

© Nokia Siemens Networks 16 (63)

Error! No text of specified style in document.

CIC
Message type code
Mandatory fixed part
Mandatory variable part
Optional part

Figure 6. BICC message format

The parameters of a mandatory fixed part are required; they occur in a

fixed order and have fixed lengths. Therefore, they do not identify the
parameter name or the parameter length. They have only the parameter
contents called the parameter variable.
To point to the parameters in the mandatory variable part, there are
pointers to each mandatory variable parameter. The pointers contain the
count of octets between themself and the beginning of the variable
parameter.
The parameters of a mandatory variable part also occur in a fixed order;
this means that they do not need a parameter code. However, they have
a variable length and thus a parameter length field inside.
The optional part has optional parameters. The parameters have to
identify themselves with a parameter code, specify their length, and
specify their variables. To mark the beginning of the optional part, the
end of the mandatory fixed part has a pointer.
The end of optional parameters is marked with the code, "End of
optional parameters", coded as "00h". If no optional parameter is present
the “End of optional parameters” is not transmitted.

© Nokia Siemens Networks 17 (63)

Error! No text of specified style in document.

To proof this structure, an example of an Initial Address Message is

shown in the following picture.

Parameter Type Length Description

octets
Message type F 1 IAM

Nature of connection F 1 Satellite connection included, Continuity check required/not

indicators required, echo control device included/not included
Forward call indicators F 2 National/international call, end-to-end method indicator,
CCS7 interworking indicator, end-to-end information
availability, ISUP use indicator, ISUP preference indicator,
ISDN access indicator, SCCP method indicator.
Calling party's category F 1 Ordinary, payphone, prioroty, operator language.

Transmission medium F 1 Speech, 3.1kHz audio, 64kbit/s, Nx64kbit/s, 1920 kbit/s, 1536
requirement kbit/s, etc.
Called party number V 4-? Received digits to identify the called party.

Access transport O 3-? Information generated on the access side of a call and
transfered transparently in either direction between
originating and terminating local nodes.
Application transport O 5-? Information sent in either direction to allow the peer-to-peer
communication of application transport users (BAT-ASE)

Figure 7. Message example (IAM)

© Nokia Siemens Networks 18 (63)

Error! No text of specified style in document.

The Call Instance Code (CIC) in every BICC message is used to

identify a signalling relation between peer BICC entities and to associate
all the PDUs to that relation. In other words, it's a reference value that
assigns a signalling message to the (virtual) channel in an MSS which
carries the respective call.

8 7 6 5 4 3 2 1
CIC LSB
CIC
CIC
MSB CIC

Figure 8. CIC format

A bilateral agreement is required with regard to the provisioned CIC

values. The total number of provisioned CIC values for any particular
signalling association indicates the maximum number of peer-call
signalling relations between the peer BICC entities, i.e. the maximum
number of simultaneous calls.

© Nokia Siemens Networks 19 (63)

Error! No text of specified style in document.

4.2 Application Transport Mechanism – APM

(ITU-T Q.765.3)
The ITU-T recommendation Q.765.3 describes the extensions required for the
transport of bearer-related information associated with BICC (as defined in
ITU-T Rec. Q.1902.1).

BICC is used to manage the call control instance that has been separated
from the bearer control instance. Thus, BICC needs to transport bearer-
related information between call control instances. The Application Transport
Mechanism (APM) is used for this purpose.

APM allows applications to send application specific data between nodes

using call control messages e.g. in the IAM message. An application running
in the nodes besides the call control instance utilizes the optional parameter
APP (Application Transport Parameter) to carry application specific data. If no
suitable call control message is available then application specific data can be
send in separate message called APM.
The application using APM for bearer control is called Bearer Association
Transport – Application Service Element (BAT- ASE).

Figure 9. Application Transport Mechanism

© Nokia Siemens Networks 20 (63)

Error! No text of specified style in document.

Figure 10. BAT-ASE as application for BICC APM

4.2.1 Format of Application Transport Parameter (APP)

8 7 6 5 4 3 2 1
ext. Application Context Identifier (05=BAT-ASE) LSB 1
ext. MSB 1a
ext. spare SNI RCI 2
ext. SI APM Segmentation Indicator 3
ext. Segmentation local reference 3a
4
APM user information
n

Figure 11. Application Transport Parameter Field

The following codes are used in APP

• Extension indicator (ext)
− If the extension bit is set to “0”, next octet e.g. 1a is present.
• Application Context Identifier (ACI)
− Value “0000101” here represents BAT ASE application is
used.
• Send Notification Indicator (SNI)

© Nokia Siemens Networks 21 (63)

Error! No text of specified style in document.

− 0 Do not send notification

− 1 Send notification
• Release Call Indicator (RCI)
− 0 Do not release call
− 1 Release call
• APM segment indicator
− 0000000 Final segment
− 0000001 to 001001 Indicates number of following segments
• Sequence Indicator (SI)
− 0 Subsequent segment to first segment
− 1 New sequence
• APM user field information
- Encapsulated application information is included here.
It is defined in Q.765.3.

4.2.2 Encapsulated Application Information

8 7 6 5 4 3 2 1
Identifier 1 1
Length indicator 1 2
Compatibility information 1 3
4
Content 1

Identifier 2 m
Length indicator 2
Compatibility Information 2

Content 2

n
:

Figure 12. Encapsulated Application Information Field

© Nokia Siemens Networks 22 (63)

Error! No text of specified style in document.

Each information element within the Encapsulated Application

Information field has same structure. It consists of four fields in given
order:
• Identifier
− Identifier governs interpretation of the contents
• Length indicator
− Length in octets of compatibility information and content.
• Compatibility information
− It contains instructions for the case that the received
information is unrecognised. E.g. to release call, send
notification, pass on, discard information element etc.
• Content
• This field is the substance of the element. It contains the
information to be conveyed.

Table 3 List of Identifiers

Value Information element Information

name
00000001 Action Indicator It can have codes like “Connect Forward”,
“Connect Backward” etc. See 4.3
00000010 Backbone Network Identifies the logical connection between a local
Connection Identifier and a remote termination and is bearer specific.
(BNC_ID).
00000011 Bearer Interworking This is and ATM AAL2 level address (BIWF
Function Address address) which is needed for the ATM AAL2
connection setup. It is in NSAP format.
00000100 Codec List Single codec information elements are listed in
decreasing order of preference level. See 4.4
00000101 Single Codec It has information about single codec information
element e.g. Organisation identifier, codec type,
codec configuration.
00000110 BAT compatibility Instructions on information received that is
report unrecognised.
00000111 Bearer Network Information to identify the type of bearer used
Connection e.g. AAL2, IP/RTP, TDM etc.
Characteristics

© Nokia Siemens Networks 23 (63)

Error! No text of specified style in document.

00001000 Bearer Control It contains the bearer control tunnelling protocol

Information IPBCP in case of IP backbone.
00001001 Bearer Control It indicates whether tunnelling of a bearer control
Tunnelling protocol is used or not.
00001010 Bearer Control Unit A logical MGW identifier which can be used for
Identifier optimal MGW selection purposes and is set by
the operator. BCU is represented with Network
ID and local BCU-ID.
00001011 Signal Indicates whether a signal (tone) shall be
applied or was detected on the bearer.
00001110 Signal Type It indicates signal type e.g. DTMF tones, dial
tone, ringing tone, busy tone etc.
00001100 Bearer Redirection This information element indicates whether
Capability bearer redirection capability is supported at
sending node and also indicates options within
the capability.
00001111 Duration Duration of a signal in milliseconds.

© Nokia Siemens Networks 24 (63)

Error! No text of specified style in document.

4.3 Action Indicator (AI)

In many situations BICC requires the indication of special actions or
events. Therefore the action indicator is defined. This identifier can occur
in BICC:IAM or BICC:APM messages.
It is used for a lot of indications:

Bearer Setup Control in BICC:IAM 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

See message flows in section six of this chapter for application

examples.

© Nokia Siemens Networks 25 (63)

Error! No text of specified style in document.

The following general rules apply for the action indicators in BICC:IAM
and BICC:APM:

IAM contains one of the following action indicator values:

▪ “connect forward” or “connect backward”
APM (as IAM response) without codec negotiation:
▪ “connect forward, no notification”
APM (as IAM response) with codec negotiation:
▪ “connect forward, no notification + selected codec”,
▪ “selected codec”
APM, if the out of band bearer establishment notification is requested
from the peer MSS without codec negotiation (i.e. BICC:APM notifies the
peer MSS about an established bearer):
▪ “connect forward, plus notification”
APM, if the out of band bearer establishment notification is requested
from the peer MSS with codec negotiation:
▪ “connect forward, plus notification + selected codec”
APM – as out of band bearer establishment notification to the peer MSS:
▪ “connected”
APM – transferring only Bearer Control Information (IPBCP) in case of
IP tunneling mechanism:
▪ no action indicator.

The originating MSS determines the bearer establishment method used

during bearer setup. In the outgoing BICC signalling towards the
succeeding MSS, the AI becomes the "Succeeding Action Indicator
(SAI)" which is determined in the originating MSS during the Succeeding
Action Indicator determination analysis (User Plane Analysis phase 5).
The SAI parameter can have 3 values:
▪ FORW: forward establishment (with non-delayed MGW
selection. I.e. the termination in the A-side MGW is created
before the termination in the B-side MGW).
▪ BACK: backward establishment
▪ DFORW: forward establishment with delayed MGW selection.
I.e. the termination in the B-side MGW is created before the
termination in the A-side MGW.

© Nokia Siemens Networks 26 (63)

Error! No text of specified style in document.

4.4 Codec List

Codecs are transferred in IAM and APM messages only if codec
negotiation is used. The codec negotiation is activated/deactivated by
the UPD parameter STOM (Speech Transmission Optimization Method;
see JF MML command group: CN=codec negotiation, DC=default
codecs).
If codec negotiation is not used (STOM=DC), no codec information is
transferred in BICC messages.
In case of STOM=CN, the following applies:
The Supported Codecs List is included in the IAM message, in the
Codec List APP parameter.
▪ This list is used on NNI (BICC/SIP) Out-of-Band Transcoder
Control (OoBTC) signalling. At call setup it is sent forward by
the node originating the OoBTC signalling and contains the
default PCM codec (G.711) and a set of codecs in decreasing
priority that is common to the nodes and the equipment
involved in setting up the call. For a mobile originating call,
these are the UE and the MGWs involved in the connection
and also the originating radio access. At inter-MSC relocation
and inter-MSC handover, the Supported Codecs List is sent
forward by the anchor MSC towards the target MSC and
contains the default PCM codec and a set of codecs that is
common to the anchor MSC and the nodes involved in setting
up the new call leg towards the target MSC.
The Available Codecs List is included in the APM message (as IAM
response), in the Codec List APP parameter.
▪ This is the list of all codecs available for the NNI connection
and is a subset of the Supported Codecs List that was sent
forward. It is returned in the backward signalling to the node
that originated the OoBTC. At call setup the Available Codecs
List contains the default PCM codec and a common set of
codecs in decreasing priority that can be supported by all
nodes and, if Transcoder Free Operation has been achieved
end-to-end, also by the UEs and the radio access networks that
are involved in the call. At inter-MSC relocation and inter-MSC
handover to UMTS, the Available Codecs List (BICC) contains
the default PCM codec and a set of codecs that can be
supported by all nodes involved in setting up the new call leg
towards the target MSC and, if Transcoder Free Operation can
be maintained end-to-end after the handover or relocation, also
by the UE and the target radio access network.

© Nokia Siemens Networks 27 (63)

Error! No text of specified style in document.

The Selected Codec is included in the APM message (as IAM

response), in the Single Codec APP parameter.
▪ This is the codec selected to be used on the NNI connection. It
is one of the codecs contained in the Available Codecs List
(BICC/SIP) and may be different from the codec that is used on
the radio interface, but if end-to-end Transcoder Free
Operation has been achieved, this will be the common codec
for all nodes, the UEs, and the radio accesses.
See the message flows in section six of this chapter for applications of
codec negotiation and codec lists.

The codec list parameter itself is a sequence of zero, one or more codec
information elements (single codec IE). The single codec IE uniquely
identifies the codec and can contain additional configuration parameters.
In detail the codec is described by:
- organization ID : It uniquely identifies the group, organization or
company that defined the codec. The ID values are assigned by
ITU-T. The organization ID is a 1 byte value.
- codec type : Every organization defining codecs has to label their
codecs uniquely with a 1 byte codec ID that is unique within the
organization.
- codec configuration : For several codecs there may be additional
parameters to influence the codec behaviour. Because these
parameters are specific to the codec, there is no general
specification for them.

Figure 13. Organization ID and Codec ID

© Nokia Siemens Networks 28 (63)

Error! No text of specified style in document.

4.5 Bearer Control Information

4.5.1 Bearer Control Tunnelling Protocol (BCTP)

Figure 14. Operation of BCTP tunnelling mechanism

In case of an IP backbone, bearer control signalling (IPBCP) does not

pass horizontally between the peer BIWFs/MGWs. Instead it is passed
on the vertical interface (in case of Rel. 4 this is the Mc interface) and
then it is tunnelled inside BICC messages.
Recommendation Q.1990 defines the BICC Bearer Control Tunnelling
Protocol (BCTP) which transports the tunnelled Protocol Data Units
(PDU) of the IP bearer control protocol IPBCP between adjacent MSSs.
BCTP puts two octets in front of every tunnelled IPBCP PDU. These two
octets contain information on BCTP version indicator and Tunnelled
Protocol Indicator. For IPBCP, the tunnelled protocol indicator has the
value 100000.

© Nokia Siemens Networks 29 (63)

Error! No text of specified style in document.

The next figure shows how the IPBCP is tunnelled through Mc- and Nc
interfaces.

IPBCP
(Q.1970)
SDP
(RFC2327)
MSS MSS
BCTP Nc
(Q.1990)
APM IPBCP
(Q.765.5) (Q.1970)
BICC Mc
Mc SDP
(Q.1902.2) (RFC2327)
M3UA BCTP
SCTP (Q.1990)
IP_BB
IP MEGACO
(H.248)
SCTP
MGW MGW
IP

Figure 15. Tunnelling Bearer Information (IPBCP)

4.5.2 IP Bearer Control Protocol (IPBCP)

The IP Bearer Control Protocol is used in an IP network environment

where the BICC protocol is deployed.
The purpose of IP bearer control protocol (IPBCP) is to exchange
information between two BIWFs for establishing or modifying IP bearers.
IPBCP makes use of the Session Description Protocol (SDP) defined in
RFC 2327 [10] to encode the information that is exchanged. SDP
descriptors used for IPBCP also contain IPBCP-specific SDP attributes.
IPBCP uses four messages to convey information between peer BIWFs.
These messages are
• Request – is sent by a BIWF to initiate an IP bearer establishment
or modification request.
• Accepted – is sent by a BIWF that receives an IP bearer
establishment or modification message if it accepts the request.

© Nokia Siemens Networks 30 (63)

Error! No text of specified style in document.

• Confused – is sent by a BIWF in response to an IP bearer

establishment or modification message if it cannot process the
received message.
• Rejected - is sent by a BIWF in response to an IP bearer
establishment or modification message if it rejects the request.

IPBCP message contents.

IPBCP messages consist of the following SDP fields.
Session and time description fields
1. Protocol version (v)
2. Origin (o)
3. Session name (s)
4. Connection data (c)
5. Session attribute (a)
6. Time (t)
Media description fields
1. Media Announcement (m)
2. Media Attributes (a)
Some of the fields and subfields are included because they are
mandatory and required by SDP but not relevant to IPBCP environment.
SDP messages are in text format.

Figure22 IPBCP in SDP format

© Nokia Siemens Networks 31 (63)

Error! No text of specified style in document.

The meaning of the SDP parameters is as follows:

v - protocol version
- v= set always to '0' by MSS. Ignored when received.
o - owner/creator and session identifier
- o=<username> <session id=" "> <version> <network type=" ">
<address type> <address>
- username: Username is always set to '-' in all interfaces and ignored
when received.
- session id: Session id is set to '0' in all SDP offers and answers
generated by MSS and ignored when received. However, the session
id sent to MSS must be representable with a 64-bit signed integer.
- version: Version is set to '0' in initial SDP offer or answer generated
by the MSS. New SDP offers generated by the MSS increment this
field by one (SDP answers generated by the MSS use also the
incremented field). The <version> field sent to MSS must be
representable with a 64 bit signed integer. MSS stores and checks the
version received in SDP offers. The SDP offer is regarded as a
session refreshment if the version is the same as the version received
in the previous offer or answer. New SDP offers (that change any
aspect of the session) sent to MSS must contain a version tag that is
one time bigger than the previous one. If this is not the case, the MSS
rejects the SDP offer through SIP, but the call is not released if it has
been established.
- network type: The network type is always 'IN' (=internet) in all SDPs
generated by MSS. The network type sent to MSS has to be 'IN'.
However, since the fields are not used by MSS, any network type is
tolerated.
- address type: MSS sets the address type to 'IP4' or 'IP6' depending
on the type of the IP address in <address> field. When SDP (offer or
answer) is received by the MSS, the address type must match the
address found in the <address> field if the network type is 'IN'.
Otherwise the address type is ignored by MSS.
- address: MSS sets the IP address of the unit handling SDP
information to this field. The address received in this field is ignored by
the MSS.
s – session name
s=<session name>
The <session name> field is set by MSS to 'MSS call' in case of an
ISUP tunnelling trunk interfaces (SIP-T/SIP-I) and set to '-' in MGCF
interfaces (3GPP and IETF variant). The field is ignored when received
by MSS.

© Nokia Siemens Networks 32 (63)

Error! No text of specified style in document.

c – connection information
c=<network type> <address type> <connection address>
The connection data field is used on session and media level. The
media-level connection data overrides the connection data for the
media where it is given. The connection data field in SDP
offers/answers generated by MSS defines the address where the
remote end must send the Real-Time Transport Protocol (RTP) media.
The connection data field received by MSS determines where the
MGW controlled by MSS sends the media.
- network type: MSS sets the network type to 'IN' in all MSS generated
SDPs. SDPs sent to MSS must also contain 'IN' as network type. If
other than 'IN' network type is received in SDP offer, the offer is
rejected, but if the call is already established, the call is not released. If
a non 'IN' network type is received in SDP answer, the call is released.
- address type: MSS sets the address type to 'IP4' or 'IP6' dependent
of the type of the IP address in <connection address> field. When SDP
(offer or answer) is received by the MSS, the address type must match
the address found in the <address> field. If not, the SDP offer is
rejected through SIP. If the call has been established, the call is not
released. If the address type does not match the connection address in
SDP answer, the call is released.
- connection address: MSS sets the IP address in all SDPs (offers or
answers) where it expects RTP media. The actual type and value of
the IP address is dependent on MGW and MSS configuration. MSS
uses the connection address received in SDP to instruct the MGW
where to send RTP media. The Zero IPv4 address (0.0.0.0) is
accepted as call hold indication, however, MSS does not use zero IPv4
to indicate call hold.
t – time the session is active
t=<start time> < stop time>
MSS sets both <start time> and <stop time> fields to '0'.
The whole attribute line is ignored by the MSS when received.
m – media name and transport address
m=<media> <port>[/number of ports] <transport> <fmt list>
- media: SDP offers, generated by the MSS, currently contain only one
media section of the type 'audio'. In CMN mode, video media line is
forwarded as well. If CMN mode is used (for example, in case of video
call), a not strict checking of the SDP is done.
- port[/number of ports]: SDP offers generated by MSS do not use the
optional 'number of ports' field. When received, only one port number is
allowed. If some other value is received, the SDP is rejected, and the

© Nokia Siemens Networks 33 (63)

Error! No text of specified style in document.

call is released. MSS sets the port to zero in SDP answers for those
media that it cannot handle. However, all media-level attributes are
preserved in the answer currently.
- transport: Media descriptions generated by MSS contain only
'RTP/AVP' transport. Unsupported and rejected streams can indicate
any transport type.
- fmt list: The payload types in the <fmt list> are used in accordance to
IETF RFC 3551 RTP Profile for Audio and Video Conferences with
Minimal Control.
This parameter also contains codec information, represented by an
IANA assigned number. The following codec representations are used:
▪ AMR:
m=audio 1234 RTP/AVP 96
a=rtpmap:96 AMR/8000
a=fmtp:96 mode-set=1,2,3,4,5,6,7
▪ EFR:
m=audio 1234 RTP/AVP 103
a=rtpmap:103 GSM-EFR/8000
▪ FR:
m=audio 1234 RTP/AVP 3
a=rtpmap:3 GSM/8000
▪ G.711 A-law:
m=audio 1234 RTP/AVP 8
a=rtpmap:8 PCMA/8000
▪ G.711 u-law:
m=audio 1234 RTP/AVP 0
a=rtpmap:0 PCMU/8000
▪ G.723.1:
m=audio 1234 RTP/AVP 4
a=rtpmap:4 G723/8000
▪ G.723.1 Annex A:
m=audio 1234 RTP/AVP 4
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=yes
▪ G.729a:
m=audio 1234 RTP/AVP 18
a=rtpmap:18 G729A/8000

© Nokia Siemens Networks 34 (63)

Error! No text of specified style in document.

▪ G.729a Annex B:
m=audio 1234 RTP/AVP 18
a=rtpmap:18 G729A/8000
a=fmtp:18 annexb=yes
▪ iLBC:
m=audio 1234 RTP/AVP 97
a=rtpmap:97 iLBC/8000
▪ Clearmode:
m=audio 1234 RTP/AVP 100
a=rtpmap:100 CLEARMODE/8000

a – zero or more media attribute lines

a= sendrecv|sendonly|recvonly|inactive
Set by MSS to reflect the session hold status. If an SDP offer is
received that indicates that media cannot be sent to the remote end, it
is handled as call hold. If an SDP offer is received that indicates that
media can be sent to the remote end and currently no media is sent, it
is regarded as call retrieval.
a=rtpmap: <payload type> <encoding name>/<clock rate>[/<encoding
parameters>]
payload type: MSS generates rtpmap with the static payload type
assigned to the codec or from dynamic range (96–127) Payload types
between '0' and '127' are accepted when received.
- encoding name: Only IETF registered codec names are supported.
For more information, see Section Coding of codex. If an unknown
codec name is received, it is ignored and it does not take part in the
codec selection. If known codec is not received, the SDP offer is
rejected.
- clock rate: MSS generates only default clock rates. This currently
means 8000 (8 KHz) only. If a clock rate is received that is not
supported with the given codec, the codec is handled as an unknown
codec, and it does not take part in codec selection.
- encoding parameters: MSS does not generate the optional encoding
parameters field. MSS supports only one audio channel and accepts if
/1 is indicated. If some other number is indicated, the codec is handled
as an unknown codec, and it does not take part in codec selection.
fmtp: <format> <format specific parameters>
MSS uses the fmtp attribute line only with AMR codec currently. The
parameters are used in line with IETF RFC 3267. MSS generates only
the mode-set, the mode-change-period, and the mode-
changeneighbor parameters.

© Nokia Siemens Networks 35 (63)

Error! No text of specified style in document.

curr|des|conf:qos <qos attributes>

MSS uses QoS precondition-related attributes defined by IETF RFC
3312 in IMS-CS interworking interfaces. MSS uses only 'local' and
'remote' status types and only 'sendrecv' direction tag. However, when
received, the 'send' direction tag is also accepted and handled.
ptime
The MSS generates ptime attribute with 20 ms or 30 ms depending on
the selected codec type in use.
maxptime
The MSS generates maxptime attribute with 20 ms or 30 ms
depending on the selected codec type is used. (For more information
on ptime and maxptime, see Feature 1335: Speech Transmission
Optimisation in MSC Server, Feature Description.)
<other media level attributes>
MSS generates only the attributes that are mentioned. To provide
enhancements, the MSS can generate additional attributes in the
future. Attributes that are not listed in this description are ignored when
received.
b – bandwidth information
b= AS/CT/RR/RS/TIAS
AS: Set by MSS to the value required by the highest bitrate codec.
CT: Ignored by MSS currently if received, not generated by MSS.
RR: Ignored by MSS currently if received, not generated by MSS.
RS: Ignored by MSS currently if received, not generated by MSS.
TIAS: Ignored by MSS currently if received, not generated by MSS.

<other bandwidth related SDP attribute>

Ignored by MSS if received.

© Nokia Siemens Networks 36 (63)

Error! No text of specified style in document.

© Nokia Siemens Networks 37 (63)

Error! No text of specified style in document.

5 Bearer Establishment Methods

With TDM as bearer (as in a Rel99 network), the bearer can only be
established from A-side to B-side. In a Rel4 network with ATM- or IP
bearer at the backbone (i.e. at the Nb interface between MGWs) and
BICC signalling, different bearer establishment methods are possible:

1. forward bearer establishment:

the bearer connection at Nb is established from A-side MGW
towards B-side MGW.
2. backward bearer establishment:
the bearer connection at Nb is established from B-side MGW
towards A-side MGW.
These two methods and their variations will be explained in the next
paragraphs.

Please note, that NbUP (IuUP also) initialization is executed end-to-end

and it is always done in forward direction regardless of the bearer
establishment direction.

5.1 Establishment of IP bearers

Several IP tunnelling methods can be distinguished (tunnelling=
transmitting the IPBCP inside H.248 and BICC messages).
Forward IP bearer establishment
− Fast Forward tunnelling (supported):
This is a forward bearer establishment with non-delayed
MGW selection. The word “fast" in the fast forward tunnelling
term refers to the fact that IPBCP (BCI) is exchanged in the
IAM and first APM message.

© Nokia Siemens Networks 38 (63)

Error! No text of specified style in document.

− Delayed Forward tunnelling (supported):

This is a forward bearer establishment with non-delayed
MGW selection. The word "delayed" in the delayed forward
tunnelling term refers to the fact that IPBCP (BCI) is
exchanged after (i.e. delayed) the IAM - first APM message
exchange. IPBCP is exchanged in the 2. and 3. APM
messages.
− Delayed Forward tunnelling with delayed MGW selection
(not supported)

Backward IP bearer establishment

− Fast Forward tunnelling (partially supported)
− Delayed Backward tunnelling (partially supported)

For IP bearers, an NSN MSC Server initiates only these forward bearer
establishment methods with tunnelling:
- Fast Forward tunnelling without codec negotiation
- Delayed Forward tunnelling with codec negotiation
For terminated calls (initiated by other vendor’s equipment) also the
following is supported by NSN MSC Servers:
- Forward bearer establishment:
− Fast Forward tunnelling with codec negotiation
− Delayed Forward tunnelling without codec negotiation
- Backward bearer establishment:
− Fast Forward tunnelling with and without codec negotiation
− Delayed Backward tunnelling with and without codec
negotiation

Note that the following two terms are different:

– Delayed MGW selection
▪ This is a MGW selection method in the originating MSC Server
when the MGW is selected after the succeeding MSC Server
has selected the MGW (termination in B-side MGW before
termination in A-side MGW).
▪ This is a forward bearer establishment with delayed MGW
selection (MGW selection is based on the MGW of the
succeeding MSS).
▪ SAI=DFORW, supported only with ATM bearer currently.

© Nokia Siemens Networks 39 (63)

Error! No text of specified style in document.

– Delayed forward tunneling

▪ This is a forward bearer establishment method for IP bearer
setup with the delayed forward tunneling method, i.e. the
IPBCP is not exchanged with the first IAM-APM messages.
▪ SAI=FORW with UPD.STOM=CN.
▪ The delayed forward bearer establishment method can be used
for delayed MGW selection with IP bearer. This is not
supported currently.
These terms are frequently confused due to their very similar names.
The SAI=DFORW naming is really misleading!

5.1.1 Forward IP bearer establishment with fast forward tunnelling

without codec negotiation

The most efficient bearer establishment method in terms of network

resource usage. The Nc and Mc interface resource usage is optimised
by transporting the IPBCP PDUs inside the same protocol messages
with the other call control and bearer establishment related information.
Because of the efficient network resource usage, NSN recommends
using the fast forward tunnelling establishment with calls that do not
include codec negotiation.

© Nokia Siemens Networks 40 (63)

Error! No text of specified style in document.

SAI = FORW UPD.STOM = DC

5. I AM(APP ( "connect forw ard", BCU-ID1, BNCChar:
UPD.STOM = DC IP/ RTP BCI = I PBCP1, BCT = Tunneling to be used))

10. APM(APP ( "connect forw ard, no notifification",

BCU-ID2, BCI = I PBCP2))

19. ANM
18. ACM

15. NotifyReq (BNCEst.)

16. NotifyReq (BNCEst.)

11.ModdReq (I PBCP2)
3. NotifyReq (IPBCP1)

8. NotifyReq (IPBCP2)
ACM depends on

TunOpt=1, I PBCP1)
Event=Tunnel I nd,
Event=Tunnel I nd.

6. AddReq (T2,
the terminating
1. AddReq (T1,

16. NotifyReply

17. NotifyReply
4. NotifyReply

9. NotifyReply
12. ModReply

7. AddReply
2. AddReply
TunOpt=1) side call setup in
MSS2.

13. User Plane “established”. Note: The AddReply

Note: The AddReply and NotifyReq
and NotifyReq 14. NbUP I nit commands are
commands are conveyed in the same
conveyed in the same 15. NbUP I nit Ack H.248 message.
H.248 message.

Fast forw ard tunneling is initiated only w ithout codec negotiation procedure and only
w ith forw ard bearer establishment.

In this special case the AddReply and the NotifyReq are transferred in
one H.248 message that contains two different H.248 commands.

© Nokia Siemens Networks 41 (63)

Error! No text of specified style in document.

5.1.2 Forward IP bearer establishment with delayed forward tunnelling

and codec negotiation

The delayed forward tunneling establishment method offers a separate

negotiation phase about the bearer control tunneling usage before the
actual bearer control protocol PDU exchange between the MGWs takes
place. In practice the negotiation is not considered to bring benefit in the
current networks where the bearer control tunneling is used exclusively
for establishing IP bearer connections and the only means for IP bearer
connection establishment is by using IPBCP tunneling.
The possibility to negotiate the selected speech codec before bearer
establishment and to delay the MGW selection by originating MSS are
considered the main benefits of this bearer establishment method.
Because of these benefits NSN recommends using the delayed forward
tunnelling establishment with calls that include codec negotiation.

3. I AM(APP ( "connect forw ard", BCU-ID1, BNCChar: IP/ RTP,

SAI = FORW BCT = Tunneling to be used, supported codec list)) UPD.STOM = CN
UPD.STOM = CN
6. APM(APP ( "connect forw , no notif+sel cdc", BCU-ID2,
selected codec, available codec list))

11. APM(APP (BCI = I PBCP1))

16. APM(APP (BCI = I PBCP2))

24. ACM
25. ANM

ACM depends on
7.ModdReq (Establish BNC,

the terminating
1. AddReq (T1, no codec,

22. NotifyReq (BNCEst.)

22. NotifyReq (BNCEst.)

4. AddReq (T2, codec,

14. NotifyReq (I PBCP2)

9. NotifyReq (I PBCP1)

12.ModReq (I PBCP1,
17.ModReq (I PBCP2)

side call setup in

Event=Tunnel I nd,)
Event=Tunnel I nd.)

MSS2.
10. NotifyReply
selected codec,

23. NotifyReply

15. NotifyReply

23. NotifyReply
13. ModReply
18. ModReply

5. AddReply
TunOpt=2 )
8. ModReply
TunOpt=2)

2. AddReply

19. User Plane “established”.

20. NbUP I nit

21. NbUP I nit Ack

Delayed forw ard tunneling is initiated only w ith codec negotiation procedure.

© Nokia Siemens Networks 42 (63)

Error! No text of specified style in document.

5.1.3 Forward IP bearer establishment with fast forward tunnelling and

codec negotiation

This call setup is never initiated by a NSN MSC Server but is supported
if the NSN MSC Server is on the terminating side.

1. I AM(APP ( "connect forw ard", BCU-ID1, BNCchar: UPD.STOM = CN

IP/RTP BCI = I PBCP1, BCT = Tunneling to be used,
supported codec list))

6. APM(APP ( " connect forw , no notif.+sel codec", BCU-

Other vendor’s ID2, BCI = I PBCP2, selected codec, available codec list))

MSCServer
13. ANM

12. ACM

10. NotifyReq (BNCEst.)

4. NotifyReq (I PBCP2)
ACM depends on

TunOpt=1, I PBCP1)
Event=Tunnel I nd,
2. AddReq (T2,
the terminating

11. NotifyReply
5. NotifyReply
3. AddReply
side call setup in
Fast forw ard tunneling w ith codec MSS2.
negotiation is never initiated by NSN MSC
Server.

Fast forw ard tunneling w ith codec

negotiation is supported only on the
term inating side (MSS2).
7. User Plane “established”. Note: The AddReply
and NotifyReq
8. NbUP I nit commands are
conveyed in the sam e
9. NbUP I nit Ack H.248 m essage.

The purple parts are the I

tunneling specific items.

© Nokia Siemens Networks 43 (63)

Error! No text of specified style in document.

5.1.4 Forward IP bearer establishment with delayed forward tunnelling

and no codec negotiation

This call setup is never initiated by a NSN MSC Server but is supported
if the NSN MSC Server is on the terminating side.

UPD.STOM = DC

1. I AM(APP ( "connect forw ard", BCU-ID1, BNCChar:

IP/RTP, BCT = Tunneling to be used))

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

Other vendor’s 5. APM(APP (BCI = I PBCP1))

MSC Server 10. APM(APP (BCI = I PBCP2))

16. ACM
17. ANM

14. NotifyReq (BNCEst.)

2. AddReq (T2, codec,

8. NotifyReq (I PBCP2)
6.ModReq (I PBCP1,
Event=Tunnel I nd,)

15. NotifyReply
ACM depends on

9. NotifyReply
3. AddReply
TunOpt=2)

7. ModReply
the term inating
Delayed forw ard tunneling w ithout codec side call setup in
negotiation is never initiated by NSN MSC MSS2.
Server.

Delayed forw ard tunneling w ithout codec

negotiation is supported only on the
terminating side (MSS2).
11. User Plane “established”.

12. NbUP I nit

13. NbUP I nit Ack

The purple parts are the I P

tunneling specific item s.

© Nokia Siemens Networks 44 (63)

Error! No text of specified style in document.

5.1.5 Backward IP bearer establishment with fast forward tunnelling and

no codec negotiation

This case is similar to the forward bearer establishment with fast forward
tunneling case. The only difference is the action indicator in the IAM.
This call setup is never initiated by a NSN MSC Server but is supported
if the NSN MSC Server is on the terminating side.

UPD.STOM = DC

1. I AM(APP ( "connect backw ard", BCU-ID1, BNCChar:

IP/RTP, BCT = Tunneling to be used, BCI = I PBCP1))

6. APM(APP (BCI = I PBCP2))

Other vendor’s
MSCServer 10. APM(APP (“ connected” ))

11. ACM

12. ANM

ACM depends on
the term inating

2. AddReq (T2, codec,

4. NotifyReq (I PBCP2)
I PBCP1, TunOpt=1,
Event=Tunnel I nd)
side call setup in
MSS2.

5. NotifyReply
3. AddReply
This case is similar to the Forw ard
bearer establishment w ith fast
forw ard tunneling case, the only
difference is the action indicator in
the IAM.

7. User Plane “established”.

8. NbUP I nit
9. NbUP I nit Ack

© Nokia Siemens Networks 45 (63)

Error! No text of specified style in document.

5.1.6 Backward IP bearer establishment with fast forward tunnelling and

codec negotiation

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.
This call setup is never initiated by a NSN MSC Server but is supported
if the NSN MSC Server is on the terminating side.

1. IAM(APP ( "connect backw ard", BCU-ID1, BNCChar:

IP/ RTP, BCT = Tunneling to be used, BCI = I PBCP1,
supported codec list))
UPD.STOM = CN
6. APM(APP (“selected codec”,
selected codec, available codec list))
Other vendor’s 7. APM(APP (BCI = I PBCP2))
MSCServer
11. APM(APP (“connected”))

12. ACM
13. ANM

ACM depends on

2. AddReq (T2, codec,

4. NotifyReq (IPBCP2)
IPBCP1, TunOpt=1)
the terminating
side call setup in

5. NotifyReply
3. AddReply
MSS2.

8. User Plane “established”.

9. NbUP Init
10. NbUP Init Ack

© Nokia Siemens Networks 46 (63)

Error! No text of specified style in document.

5.1.7 Backward IP bearer establishment with delayed backward

tunnelling and no codec negotiation

Delayed backward tunneling without codec negotiation is never initiated

by NSN MSC Server but can be supported on the terminating side
(MSS2).

UPD.STOM = DC
1. I AM(APP ( "connect backw ard", BCU-ID1,
BNCChar: IP/RTP, BCT = Tunneling to be used))

6. APM(APP (BCI = I PBCP2))

Other vendor’s
7. APM(APP (BCI = I PBCP1))
MSCServer
15. ACM
16. ANM

ACM depends on

TunOpt=1, Estab. Bearer)

the terminating

13. NotifyReq (BNCEst.)

4. NotifyReq (I PBCP2)
2. AddReq (T2, codec,

8.ModReq (I PBCP1)
Event=Tunnel I nd
side call setup in

14. NotifyReply
5. NotifyReply
MSS2.

3. AddReply

9. ModReply
10. User Plane “established”.

11. NbUP I nit

12. NbUP I nit Ack

© Nokia Siemens Networks 47 (63)

Error! No text of specified style in document.

5.1.8 Backward IP bearer establishment with delayed backward

tunnelling and codec negotiation

Delayed backward tunneling with codec negotiation is never initiated by

NSN MSC Server but is supported 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.

1. IAM(APP ( "connect backw ard", BCU-ID1, BNCChar: IP/ RTP,

BCT = Tunneling to be used, supported codec list))
UPD.STOM = CN
6. APM(APP (“selected codec”,
selected codec, available codec list))

7. APM(APP (BCI = I PBCP2))

Other vendor’s
8. APM(APP (BCI = I PBCP1))
MSCServer
16. ACM
17. ANM

ACM depends on
the terminating

TunOpt=1, Estab. Bearer)

14. NotifyReq (BNCEst .)

4. NotifyReq (I PBCP2)
2. AddReq (T2, codec,
side call set up in

9.ModReq (I PBCP1)
Event=Tunnel I nd
MSS2.

15. NotifyReply
5. NotifyReply

10. ModReply
3. AddReply
11. User Plane “established”.

12. NbUP I nit

13. NbUP Init Ack

© Nokia Siemens Networks 48 (63)

Error! No text of specified style in document.

5.2 Establishment of ATM bearers

For ATM bearers, a separate bearer control protocol is exchanged
between the involved MGWs: AAL Type 2 Signaling. Because AAL2-
Signaling is transmitted on the ATM bearer directly, and not via the
controlling MSSs, no tunnelling options are available here.

We can distinguish the following bearer establishment methods:

Forward bearer establishment

The AAL2:ERQ is sent from A-side MGW to B-side MGW. Can be
combined with codec negotiation.

Forward bearer establishment with delayed MGW selection:

The termination in the B-side MGW is selected before the termination in
the A-side MGW, but the AAL2:ERQ is sent from A-side MGW to B-side
MGW.

Backward bearer establishment:

The AAL2:ERQ is sent from B-side MGW to A-side MGW. Can be
combined with codec negotiation.

© Nokia Siemens Networks 49 (63)

Error! No text of specified style in document.

5.2.1 Forward ATM bearer establishment without codec negotiation

UPD.STOM = DC
SAI = FORW
UPD.STOM = DC 3. I AM(APP ( "connect forw ard", BCU-ID1, BIWF1,
BNCChar: ATM AAL2))
6. APM(APP ( "connect forw ard, no notification",
BCU-ID2, BNC-ID2, BIWF2))

16. ANM
15. ACM

Requesting BIWF2, BNC-ID2)

BNC-ID2, Est. Bearer signal)

13. NotifyReq (BNCEst.)

13. NotifyReq (BNCEst.)

1. AddReq (T1, codec,

2. AddReply(BIWF1)

ACM depends on

5. AddReply(BIWF2,
Requesting BIWF1)

7.ModdReq (BIWF2,

the terminating

14. NotifyReply
14. NotifyReply

4. AddReq (T2,
9. ModReply

side call set up in

BNC-ID2)
MSS2.

8. AAL2 ERQ
10. AAL2 ECF
11. NbUP I nit
12. NbUP I nit Ack

© Nokia Siemens Networks 50 (63)

Error! No text of specified style in document.

5.2.2 Forward ATM bearer establishment with codec negotiation

SAI = FORW
UPD.STOM = CN UPD.STOM = CN
3. IAM(APP ( "connect forw ard", BCU-ID1, BIWF1,
BNC Char: ATM AAL2, supported codecs list))
6. APM(APP ( "connect forw , no notif + selected codec",
BCU-ID2, BNC-ID2, BIWF2 , sel codec, avail. codecs list ))

15. ACM
16. ANM

ACM depends on
the terminating
7.ModdReq (BIWF2, BNC-ID2, side call setup in
1. AddReq (T1, no codec,

Requesting BIWF2, BNC-ID2)

13. NotifyReq (BNCEst.)

13. NotifyReq (BNCEst.)

codec, Est. Bearer signal) MSS2.
2. AddReply(BIWF1)

5. AddReply(BIWF2,
Requesting BIWF1)

14. NotifyReply

14. NotifyReply
4. AddReq (T2,
9. ModReply

BNC-ID2)
8. AAL2 ERQ
10. AAL2 ECF
11. NbUP Init
12. NbUP I nit Ack

Only the codec negotiation related information differs compared to the

previous slide.
The STOM parameter of the used UPDs shall be modified to 'CN' in both
MSSs’ configuration.
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:
APM message. Additionally, the Available Codec List and the Selected
Codec is transferred to MSS1 in the APM message.
The selected codec is transferred to the MGW1 in the ModReq
message.

© Nokia Siemens Networks 51 (63)

Error! No text of specified style in document.

5.2.3 Forward ATM bearer establishment with delayed MGW selection

and no codec negotiation

The Succeeding UPD determination analysis is executed again when

the APM message (IAM response) is received. This is the main benefit
of the delayed MGW selection procedure:
The Succeeding UPD determination analysis can be influenced with the
Succeeding BCU-ID (SBCU). Therefore more optimal MGW selection
can be supported in MSS1 as the MGW selection procedure depends on
the selected MGW under MSS2.

There are no changes 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.

UPD.STOM = DC
SAI = DFORW
UPD.STOM = DC

1. IAM(APP ( "connect forw ard, BNCChar: ATM AAL2"))

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

13. ACM
14. ANM
BNC-ID2, Establish Bearer signal)

Requesting BIWF2, BNC-ID2)

11. NotifyReq (BNCEst.)

11. NotifyReq (BNCEst.)

ACM depends on
5. AddReq (T1, BIWF2,

3. AddReply(BIWF2,

the terminating
12. NotifyReply

12. NotifyReply
2. AddReq (T2,
7. AddReply

side call setup in

BNC-ID2)

MSS2.

6. ERQ
8. ECF
9. NbUP Init
10. NbUP Init Ack

© Nokia Siemens Networks 52 (63)

Error! No text of specified style in document.

5.2.4 Backward ATM bearer selection without codec negotiation

Please note: NbUP (IuUP also) initialisation (INIT and INIT_ack) is

executed end-to-end and it is always done in forward direction
regardless of the bearer establishment direction.

UPD.STOM = DC
SAI = BACK
UPD.STOM = DC

3. IAM(APP ( "connect backw ard", BCU-ID1,

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

12. ACM
13. ANM

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

Requesting BIWF1, BNC-ID1)

10. NotifyReq (BNCEst.)

10. NotifyReq (BNCEst.)

ACM depends on the

2. AddReply (BNC-ID1,
1. AddReq (T1, codec,

Establish Bearer signal)

terminating side call

11. NotifyReply
11. NotifyReply

setup in MSS2.

6. AddReply
BIWF1)

5. ERQ
7. ECF
8. NbUP I nit
9. NbUP I nit Ack

© Nokia Siemens Networks 53 (63)

Error! No text of specified style in document.

5.2.5 Backward ATM bearer establishment with codec negotiation

Only the codec negotiation related information is different from the

previous case. No codec is sent to the A-side MGW in the first ADD_req
msg., thus only the supported codecs are filled in the BICC:IAM.

UPD.STOM = CN

SAI = BACK 3. IAM(APP ( "connect backw ard", BCU-ID1, BNC-ID1,

UPD.STOM = CN BIWF1, BNCChar: ATM AAL2, supported codec list))

8. APM(APP ( “selected codec",

selected codec, available codec list))

15. ACM
16. ANM
Requesting BIWF1, BNC-ID1)
1. AddReq (T1, no codec,

13. NotifyReq (BNCEst.)

13. NotifyReq (BNCEst.)

Establish Bearer signal)
4. AddReq (T2, BIWF1,
2. AddReply(BNC-ID1,

ACM depends on the

selected codec)

14. NotifyReply

14. NotifyReply
9.ModdReq (

10. ModReply

terminating side call

6. AddReply
BNC-ID1,
setup in MSS2.
BIWF1)

5. ERQ
7. ECF
11. NbUP Init
12. NbUP Init Ack

© Nokia Siemens Networks 54 (63)

Error! No text of specified style in document.

© Nokia Siemens Networks 55 (63)

Error! No text of specified style in document.

6 BICC Usage in MSS

6.1 General

NSN implements BICC with feature 1330. This feature implements the
BICC CS2 signalling through the IP network between the two MSSs
according to ITU-T Recommendations Q.1902.1; Q.1902.2; Q.1902.3;
Q.1902.4; Q.1902.6 specifications. For M14 Release, this includes the
following:

• 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
• Automatic Rerouting (Crankback mechanism)

There are two new functionalities defined to be used with BICC protocol,
Bearer Redirection and Crankback/Automatic Re-routing. The Bearer
Redirection procedure enables the re-routing of the user plane after
which some sort of optimization is needed (for example after CFNA).
Crankback mechanism (Automatic Re-routing) allows the call set-up to
return to the preceding Serving Network (SN) so that the call can
automatically be rerouted from there.

© Nokia Siemens Networks 56 (63)

Error! No text of specified style in document.

BICC signalling protocol is the result of evolution from ISDN User Part
(ISUP) protocol. If you use BICC signalling protocol for connections
between two MSSs, consider the following issues. BICC signalling
protocol can be used to establish circuit-switched calls using either ATM
or IP transport for user plane connections.

Required signalling network configuration

In NSN solution, BICC requires the presence of a C7 (MTP3 or M3UA)

signalling network. In small networks, it is not necessary to have an
individual transit layer for consolidating the signalling traffic from the
access layer MSSs. If the individual transit layer is required, it can be
built by using traditional STP nodes. It is also possible to use other
Nokia network elements such as Nokia SRRi to act as a Signalling
Transfer Point (STP), if so required.
The use of M3UA is recommended with BICC signalling. However, if an
existing MTP3 signalling network is used, the specific configuration is
required where the BICC signalling user parts in Nokia MSS are aware
of MTP3 use and explicitly use smaller message sizes and simple
segmentation. Otherwise, larger BICC messages do not fit into 272
octets available for MTP3 user part payload.

Call Identification Code

Call Instance Code (bCIC) in BICC compared to the Circuit Identification

Code (iCIC) in ISUP does not have similar relationship to the actual user
plane resource. Technically, the bCIC is only the limitation of how many
simultaneous calls can be established between two specific signalling
points.

6.2 Establishment Direction of User Plane Connection

BICC carries the information on establishment direction used in the user
plane level (between MGWs). This direction is encoded into the Action
Indicator (AI) parameter transported in the Initial Address Message
(IAM). Thus, always the originating side of the BICC connection is
responsible for choosing, for example, the establishment direction of the
user plane connection. The AI parameter can have several different
values. The AI parameter value depends on the used BICC bearer
establishment method.

© Nokia Siemens Networks 57 (63)

Error! No text of specified style in document.

Support for different BICC establishment methods and related AI values

in Nokia MSS in M14 release are listed in the table below.

Table 4 Action Indicator supported by BICC in MSS

In outgoing calls using BICC signalling, the value of the AI is the result of
the 'Determination of Succeeding Action Indicator' phase of the executed
user plane analysis.

BICC signalling has several user plane-related parameters the values of

which are received either from the user plane analysis or from other
network elements. The tables below list all relevant parameters and their
source in both incoming and outgoing call cases.

© Nokia Siemens Networks 58 (63)

Error! No text of specified style in document.

Table 5 BICC parameter and their sources in incoming and outgoing call

In addition to these parameters which are actually received from the

signalling message, the following parameters are generated internally.

Table 6 BICC parameter generated internally in MSS in incoming and outgoing

call

© Nokia Siemens Networks 59 (63)

Error! No text of specified style in document.

6.3 Codec Selection and Modification

Cellular networks typically use compressed codecs over the Air
interface, because of strict capacity requirements. However, traditionally
(that is, in GSM networks), the speech is converted (transcoded) into a
common format before connecting to the core network. This operation is
performed by a device called transcoder, which is logically located
between the BSC and the MSC. The transcoded G.711 format codec is
used by the MSC, and can be used in the whole core network. If the call
is going further to another Mobile Station (MS), an extra transcoding
takes place from G.711 to the compressed codec. This is called 'tandem
connection', that is, two transcoding stages in series. But whenever
transcoding takes place,speech quality is decreased. The reasons for
this are the imperfect conversion process and the increasing delay.

Figure 23 Tandem Free Operation (TFO)

To avoid tandem connection, it is useful not to transcode to the

intermediate format at all, but only relay the compressed codec all the
way from MS to MS. One solution for this is TFO (Tandem Free
Operation), which is based on the capability of peer transcoders to
inband negotiate with each other, and to transmit the compressed codec
by overriding a part of the normal G.711 coded channel. In TFO, the
peer transcoders can communicate with each other by using bit-robbing
signalling inside an established 64 kbit/s channel. If a common codec is
available, the transcoders override a part of the 64 kbit/s channel with a
compressed codec which is eventually used by both ends. TFO is an
inband solution, the call control level is not aware of it.

© Nokia Siemens Networks 60 (63)

Error! No text of specified style in document.

TrFO (Transcoder Free Operation) is a 3GPP bearer independent

circuit-switched core network concept to use an end-to-end common
compressed codec from UE to UE through the access network and the
core network avoiding the unnecessary transcoding stages. TrFO is
standardised only for 3G calls (calls through UTRAN). The Transcoder
Free Operation (TrFO) provide enhanced speech quality and
transmission capacity savings in the 3G core network. The operation is
based on codec negotiation and selection performed by the MSS and
the user plane operations of the MGW, including user plane protocol
handling and automatic transcoder removal and insertion, when
applicable.

Figure 24 Transcoder Free Operation (TrFO)

Codec negotiation is performed by the MSSs interacting with each other,

with the Radio Network Controllers (RNCs), and UEs. On mobile
originated side, the UE provides its supported codec list to the MSS in a
SETUP message. The MSS, RAN, and MGW capabilities are taken into
account during the codec negotiation and codec selection procedures.
After the MSS has preselected the MGW(s) through which the call is
routed, it further deletes the not supported codecs from the list.
Additionally, the MSS and MGW supported codecs are added to the list
as fallback codecs to guarantee that the user plane can be established.
The UPD-specific codec preference list is also taken into account (if
defined) when the UPD level codec support is checked, and when the

© Nokia Siemens Networks 61 (63)

Error! No text of specified style in document.

priority order of the given codecs is determined. The codec list is further
sent in a BICC message to the next MSS.
An intermediate node, if any, when receiving a BICC IAM message,
compares the received list of codecs with the codecs supported by the
MGW(s) that the node selects. The UPD-specific codec preference list is
also taken into account (if defined) when codec support is checked. The
codecs that are not supported are deleted from the list. The list is sent
further in the BICC IAM (SIP INVITE) message to the next node.
The terminating MSS receives the codecs supported by the terminating
UE in a CALL CONFIRMED message. The terminating MSS selects the
highest priority codec in the received list (in BICC) also supported by the
terminating UE. The UPD-specific codec preference list, if defined, is
also taken into account at this step.
TrFO-compatible codecs are necessary for establishing TrFO calls and
they are the codecs that are suitable for a TrFO connection.
The selected codec is sent back in a BICC APM message. When
receiving this message, each node knows the selected codec to be used
in the speech path and can control the MGW(s) accordingly. The MGW
is controlled through the H.248 interface by defining the used codec and
other user plane protocol-related parameters for each MGW termination
created for a call.
After the termination properties are provided, the bearer requirements
are known, and the bearer connections through the core network can be
set up by the MGWs involved. With TrFO the core network technology
can either be based on RTP/IP or AAL2/ATM, and there are different
methods (that is, forward and backward) for bearer establishment.
However, the method or technology used does not prevent TrFO.
Interaction towards the RAN and the UE is performed by requesting a
Radio Access Bearer (RAB) suitable for the selected codec and by
indicating the used codec to the UE when necessary.

© Nokia Siemens Networks 62 (63)

Error! No text of specified style in document.

Figure 25 Successful BICC Codec Negotiation

© Nokia Siemens Networks 63 (63)