Bearer Independent call control –BICC

l  What is BICC ?

an architecture that provides a means of supporting narrowband (PSTN, ISDN) services across a Packet-based backbone network without impacting the existing network interfaces and end-to-end services.

BICC is used on NC interface between two MSS. It provides interoffice call control capability independent to bearer technology in user plane & signaling transmission technology in control plane. BICC inherit all features of ISUP.

l  BICC contains the logical CIC (Call instance code) used to identify sequence of message exchanged during a call

l  a call control protocol that is unaware of the actual bearer transport being employed. Binding information identifies the bearer used for each communication instance

l  a call control protocol that is based on SS7 ISUP signalling protocol commonly used in legacy networks for PSTN/ISDN intra- and inter-networking

l  bearer (connection) control signalling protocols depend on the underlying bearer technology used (e.g., DSS2/UNI for ATM AAL type 1 and  ATM AAL type 2, IP and/or MPLS related signalling protocols)

Bearer Independent call control –BICC

BICC is modified version of ISUP that overcomes ISUP limitation to make it truly transport (bearer) independent.BICC is only standardized for ATM and IP.

BICC versions

1.       BICC CS1

2.       BICC CS2

We are using BICC capability set 2 as it allows physically separation of control servers and MGWs and MGWs selections.

BICC Principle

Concepts new to BICC as compared with ISUP

l  Call Instance Code(CIC)

l  Bearer setup direction

l  Codec negotiation

l  BICC tunneling

l  Idle bearer reuse

l  Notification

Call Instance Code(CIC):-

l  CIC is not Circuit Identification Code. BICC has the ”Call Instance Code” (CIC).The role of the “Call Instance Code” (CIC) is the identification of the signaling relation between the peer BICC entities and association of all signaling messages to that relation.

BICC Message

IAM:-

l      The BICC IAM has the same structure and format as an ISUP IAM; only BICC allows extra network specific information to be transferred. For example it could contain the identity of an already selected M-MGw or indicate the bearer setup direction or the list of supported codecs.

APM (Application Transport) :-

l      If codec negotiation is implemented, an APM message indicates to the originating exchange that a codec has been selected from the list of supported codecs.

l  Other message are ACM,ANM etc

GATEWAY CONTROL PROTOCOL (GCP/H.248/MEGACO)

The introduction of Ericsson Mobile Softswitch Solution necessitates the use of a protocol for remote control of M-MGws by control servers. The Gateway Control Protocol (GCP) was developed for this purpose. GCP operates in a master-slave configuration. Control servers, or Media Gateway Controllers (MGCs) as they are called in GCP act as masters while M-MGws act as slaves.

     MGCs issue commands to initiate connections and associations in the underlying bearer network, and may request the introduction of devices such as announcement machines, echo cancellers, DTMF devices, etc into the bearer path. M-MGws enact MGC commands and usually respond with notifications.

GCP message

ADD

    The ADD command adds a Termination to a Context. The Termination is either created or, in the case of a physical Termination, taken out of the Null Context

SUBTRACT

     The SUBTRACT command disconnect the termination from context

MODIFY

    The MODIFY command modifies Termination properties. A Termination identifier is specified if a single Termination in a Context is to be modified.

NOTIFY

     The NOTIFY command allows the M-MGw to notify the MGC of an event that has occurred.

   A Termination is a logical representation of a resource within a GCP-controlled M-MGw like malt devices. A call is through connected within a switch by associating two (or more) Terminations. A Context is an association between two or more Terminations

IP BEARER CONTROL PROTOCOL (IPBCP) :-

By introducing support for IP bearers, CN3.0 had to introduce a new signaling protocol to establish and clear down these IP bearers.It has been designed to be a tunneling protocol utilizing both the ‘vertical’ (GCP) and ‘horizontal’ (BICC) signaling protocols used to establish transport bearers. It is important to note that this protocol is only used to establish IP bearers across the Core Network (Nb interface, MGW to MGW).

      An IP bearer is a bidirectional user plane association between 2 BIWFs for carrying media stream information across IP networks. The tunneling mechanism is used to exchange media stream characteristics, port numbers and IP addresses of the source and sink of a media stream to establish. The exchange of this information is done at call establishment and after it has been established

IPBCP message

Request: the Request message is used to initiate the establishment and/or modification of an IP bearer. The iniitator of the establishment request message is known as the I-BIWF.

Accept: the Accept message is used to reply to an establish/modification request message received, only in the circumstance that it is accepted. The initiator of the accept message is known as the R-BIWF.

Confused: the confused message is sent by the R-BIWF in response to an establish/modification request message, only in the circumstance that it cannot process the received message.

Reject: the reject message is used to reply to an establish/modification request message received, only in the circumstance that it is rejection the request message received.

APM Functionality

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

APM for BICC defines among others

Action indicator (forward/backward)

BNC ID (reference used to associate the bearer with a call)

BIWF address (MGW address)

Codec(s)

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

Carried in APP parameter

Tunneling bearer information with BICC:-

IP Bearer Control Protocol (IPBCP) defines the tunneling protocol

based on SDP with BICC-specific extensions

IPBCP is carried in Bearer Control Tunneling Protocol (BCTP)

adds two bytes to indicate the used BCP

currently only IPBCP Q.1970 supported

Forward bearer setup:-

l  1) IAM conveys Application Transport parameter which has encapsulated BICC signaling information that indicates:

 - Bearer set-up is in the forward direction.

l   2) IAM sent before completion of the bearer set-up with the Nature of Connection parameter is set to indicate:

    - Continuity check performed on previous CIC

l  In addition the Application Transport parameter is conveyed with encapsulated BICC signaling information to indicate:

     - Bearer set-up is in the forward direction.

l  3) APM conveys Application Transport parameter which has encapsulated BICC signaling information to indicate:

    - Notification of bearer set-up is required.

l  4) APM conveys Application Transport parameter which has encapsulated BICC signaling information to indicate:

    - Bearer is connected

l  5) Continuity Indicators in COT indicates:

 - Successful bearer set-up on the preceding BICC leg.

Backward bearer setup:-

l  1) IAM conveys Application Transport parameter which has encapsulated BICC signaling information that indicates:

    - Bearer set-up is in the backward direction

l  2) IAM sent before completion of the bearer set-up with the Nature of Connection parameter is set to indicate:

    - Continuity check performed on previous CIC

l  In addition the Application Transport parameter is conveyed with encapsulated BICC signaling information to indicate:

    - Bearer set-up is in the backward direction.

l   3) Continuity Indicators in COT indicates:

     - Successful bearer set-up on the preceding BICC leg.

IP Bearer Control Tunneling Principle:-

l  When two MGW-s need to set up an IP bearer, they need to exchange information, i.e. the port numbers, the IP addresses, etc. The information that needs to be exchanged is defined in the IPBCP protocol.

l  When IPBCP protocol information has to be passed from one MGW to another, it is tunnelled from the MGW via the BCTP protocol over GCP using CBC extensions to the call control server, then from the call control server to the target call control server via the BICC protocol and finally from the target call control server to the target MGW via the BCTP protocol over CBC. In all this process the call control servers involved do not read or change the content of the IPBCP information.

Codec negotiation or OoBTC:-

In some cases it will be necessary to determine the codec used at each edge of the connectivity layer before the bearer is established.

IAM message contains the list of codecs supported by ingress MGW in preferred order. At the egress MGW

The highest supported codec is chosen. The chosen codec is returned in BICC APM message.

Codec negotiation is often referred as OoBTC i.e Out of Band Transcoder Control.

OoBTC is prerequisite for compressed speech in core network,TrFO and TFO.

Comments are most Welcomed,

Telecom Champ Team

telecomchamp@gmail.com