Usage of BICC and SIP protocol in IP Core Network

Lovre Hribar

Damir Buric

Ericsson Nikola Tesla, d.d.

Croatia, Split

E-mail: ;

Abstract: Core Network is based on the separation of functionality into a control layer, a connectivity layer and an application layer. Call Control protocols like BICC and SIP have its own place in such IP Core Network but the continuous development offer the posibility for their convergence. New protocol versions are enhanced with new set of capabilities but every protocol has kept its own philosophy and protocol architecture. This article has shown that one protocol should not exclude the other one. The better solution is to keep the both protocols thus enabling the easer introduction of new services that could be a superset of existing services offered by each of the call control protocols.

1. INTRODUCTION

Bearer Independent Call Control (BICC) protocol and Session Initiation Protocol (SIP) have its own place in the Core Network and there is a possibility for their interwork in such network. BICC is the Call Control Protocol chosen for the 3rd Generation Partnership Project Circuit Switched domain (3GPP CS) Release 4. On the IP Multimedia side SIP is recommended in 3GPP Release 5. Today it exists the possibility for convergence between these two protocols copying their each capability. With such process of convergence each protocol can lose gradually its strong points. This paper gives an overview of the capabilities for each protocol and tries to explain the conceptual and architectural differences. The first version of BICC is used in the ATM based core network and the true comparison of BICC and SIP can be done only with introduction of IP bearer network.

2. BICC OVERVIEW

2.1 Core Network Architecture using BICC

The BICC protocol provides the signaling functions required supporting narrowband ISDN services independent of the bearer technology and signaling transport technology used. It is an extension of ISUP protocol and therefore provides a full transparency of the existing telephony functionality [1]. The first standardized version of BICC protocol was CS1 but only BICC CS2 version gives a true separation of control and bearer layer and introduction of IP bearer. The physical separation of the Call Control and Bearer Control allows physically separate Call Mediation Node (CMN) and Bearer Interworking Function (BIWF). Inherent in this separation is the possibility for BICC CS2 to support the BIWF selection, allowing a many-to-many relationship between control servers and BIWFs.

Figure 1 – Network Functional Model

BICC is used as a protocol between Call Service Functions (CSFs) within different nodes as originating/destination Service Nodes (SNs) (ISNs interworking with an access signaling system), intermediate national/international SNs (TSNs), incoming/outgoing national/international gateway SNs (GSNs) and Call Mediation Nodes (CMNs), Figure 1. CMNs are introduced for call routing purposes. They do not have bearer control function.

To support IP as a bearer the BICC along with Call Bearer Control (CBC) protocol provides a mechanism for the transport of Bearer Control Protocol information between BIWFs. The mechanism provides a reliable, sequenced transport on a per backbone network connection basis when there is no requirement for intermediate BCF-Rs between the BCF-Ns to process the tunnelled information [2].

Bearer Control tunnelling shall be used for a call if the BICC-data primitive associated with the IAM or the first backward APM message includes the Bearer Control Tunnelling information element set to “tunneling to be used”. The absence of the Bearer Control Tunneling information element in the IAM or in the first backward APM (if “tunnelling to be used” was not indicated in the IAM) specifies that the bearer control tunneling shall not be used. The Bearer Control Protocol information transported by tunnelling mechanism need not to be processed by the CSF. The unmodified BCP information is tunnelled through the CBC protocol toward the terminating BIWF, Figure 2. The APM message is used for transmission of tunnelled information in call control layer. The decision on use of the Bearer Control Tunnelling mechanism is made on a per call basis by the Bearer Interworking Function at the originating SN. The CSF shall inform the BIWF of the possibility of using the Bearer Control Tunnelling Mechanism and the BIWF shall respond with an indication of whether the Tunnel should be set up or not.

Figure 2 – IP Bearer Control Tunelling Concept

Depending whether BIWF has been selected prior to outgoing BICC set-up or after there are two different ways of bearer connection set-up: Forward and Backward. It depends as well on outgoing CSF route characteristics and originating BIWF. The choice between Fast (Forward or Backward) and Delayed Forward/Backward set-up, respectively, is made by the originating BCF and is indicated in the initial response from the originating BCF [3].

Following the 3GPP standard and its model of core network BICC CS2 defines its own procedures for supporting the codec negotiation, mid-call negotiation and out-of band transport of DTMF and tone information. The CS2 version also supports the bearer redirection capability as well as procedures for reuse of idle bearers as a network option.

2.2 BICC Development

BICC CS3 standard work is not finished yet and the following items and contributions are some that are proposed to be in the scope [4]:

- The BICC CS3 protocol should support as an optional procedure the transfer of text-based (URL/URI) naming, complementary to the existing digit-based (E.164) naming. The transfer of text-based naming is restricted to the called party for identification purposes only, not for routing purposes. Service platform including ENUM functionality is supposed to map the E.164 telephone number into a SIP-URL. Reverse ENUM functionality supposes the reverse mapping.

- It is supposed for BICC to fully support the advanced CMN call control procedures. The call control procedures shall support:

  • a mechanism of relaying CMN exchange data and/or IN data between the CMN (CSF-G) and the Originating SN using functionality already provided in SS7
  • a mechanism for relaying recording, exchange, and/or IN data between an Originating SN and a CMN with the same network; call routing
  • Screening functionality at the CMN (by the CSF-G).

- Support for efficient Uni-cast and Multi-cast Services transported on various transport technologies (e.g. ATM, AAL2, IP, MPLS…etc.) via communications configuration 6 (i.e. conference services supported by using a server). In addition to already supported bearer technology it is proposed to take MPLS bearer transport technology in a label and a non-label switching configuration as a candidate for BICC CS3, and provided a set of high-level requirements.

- Support of multi-party call configurations allowing a party to add another party to the call and its communication capability type 6 or any other, and release the party that it has added, from the call and its attachment to the bearer(s). It is proposed for bearer re-direction to support establishment of a multi-party service configuration.

-According to proposals following information should be used at CSF selection of BIWF:

  • the services required by the call,
  • the list of BIWF’s which can be used to interface the peer SN,
  • inter-working with Switched Circuit Networks,
  • Network Interconnect Scenarios
  • minimising the number of BIWF’s in the connection
  • At the succeeding SN, the BCU-ID of the BCU selected at the preceding SN.

- Support of multi-media and related services. Further development of BICC is proposed to be undertaken, and not to be limited to the existing narrow-band ISDN service set. This proposal is particularly related to SIP, i.e. BICC should not compete against SIP, which is regarded as an emerging technology. Interworking would be included as far as existing BICC end terminals could support a particular service.

- Routing methods for E.164, AESA, INRA & IP addresses (GOL-081). This contribution identified signalling requirements to support routing methods recommended in E.351 for application across network types, for E.164, AESA, INRA, and/or IP routing addresses. It proposed to develop the required signalling requirements needed to support these routing methods.

- International Emergency Preference Scheme (IEPS) support.

3. SIP OVERVIEW

3.1 SIP Architecture

SIP is an IETF application-layer control protocol that can establish, modify, and terminate multimedia sessions (conferences) such as Internet telephony calls [5]. SIP can also invite participants to already existing sessions, such as multicast conferences. Media can be added and changed to (and removed from) an existing session. SIP transparently supports name mapping and redirection services, which supports personal mobility - clients can maintain a single externally visible identifier regardless of their network location. SIP is not a vertically integrated communications system. It is structured as a layered protocol, which means that its behavior is described in terms of a set of fairly independent processing stages with only a loose coupling between each stage. SIP is a component that can be used with other IETF protocols to build complete multimedia architecture. SIP was designed to be a modular component of a larger IP telephony solution and thus functions well with a broad spectrum of existing and future IP telephony protocols.

SIP service technologies can be integrated into WWW technologies that are used widely today. Through the adoption of these technologies the 3G network will be able to provide rapid and inexpensive services and, probably most importantly, there will be a mass of people with the ability to provide the wealth of services desired. SIP is one of the key protocols used to implement VoIP, Figure 3. Although performing telephony call signaling and transporting the associated audio media over IP yields significant advantages over traditional telephony, a VoIP network cannot exist in isolation from traditional telephone networks. It is vital for a SIP telephony network to interwork with the Core Network. An IP network using SIP may serve as a transit network between gateways - a call may originate and terminate in the Core Network, but cross a SIP-based network somewhere in the middle.

SIP telephony network is transparently with respect to the Core Network. Traditional telecom services such as call waiting, freephone numbers, etc., implemented in protocols such as SS7 should be offered by a SIP network in a manner that precludes any debilitating difference in client experience while not limiting the flexibility of SIP.

SIP telephony network is routability of SIP requests - a SIP request that sets up a telephone call should contain sufficient information in its headers to enable it to be appropriately routed to its destination by proxy servers in the SIP network. SIP has possibility of querying for the capabilities of a SIP server or client using OPTIONS, or canceling a pending request using CANCEL. SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services. SIP does not transport media streams. SIP is used for signaling only and it is not a session description protocol. The details of the session, such as the type of media, codec, or sampling rate, are not described using SIP. SIP does not offer conference control services and does not prescribe how a conference is to be managed. Itdoes not have any baseline mechanism to carry any mid-call information (such as the BICC INF/INR query) along the SIP signaling path during the session. SIP is not an easy protocol to secure. Its use of intermediaries, its multi-faceted trust relationships, its expected usage between elements with no trust at all, and its user-to-user operation make security far from trivial. SIP is not extended to support ATM bearers additional to IP bearers.

Figure 3 – Voice over IP Network

3.2 SIP-T Architecture

SIP-T is not a new protocol - it is a set of mechanisms for interfacing traditional telephone signaling with SIP. The purpose of SIP-T is to provide protocol translation and feature transparency across points and for the purposes of interfaces with the Core Network-SIP interconnection.

SIP-T provides a framework for the integration of legacy telephony signaling into SIP messages. Encapsulation of the Core Network signaling is one of the major requirements of SIP-T [6].

There are three distinct sorts of elements (from a functional point of view) in a SIP VoIP network that interconnects with the Core Network. Originator (SIP phone) sends requests to a SIP proxy that is responsible for routing the request to an appropriate destination. The originator has no way to anticipate that call will terminate in any other network than SIP network. It is therefore not the responsibility of IP endpoints like a SIP phone to generate encapsulated BICC.
Terminator generates the BICC appropriate for signaling to the Core Network from the incoming SIP message. Values for certain BICC parameters may be gleaned from the SIP headers or extracted directly from an encapsulated BICC body.

Intermediaries like proxy servers are entrusted with the task of routing messages to one another, as well as gateways and SIP phones. Each proxy server makes a forwarding decision for a SIP request based on values of various headers, or 'routable elements'.

SIP-T uses the methods and procedures of SIP as defined in pure SIP. SIP-T activity (Tunnelling of BICC or ISUP over SIP) should produce mismatches between message sequences and compatibility problems. Moreover, a lot of complexity is introduced, for example that network points may choose to either discard the SIP or the BICC information. Another problem is that BICC, as successor of ISUP, has new capabilities for UMTS (e.g. codec negotiation), that are not supported by ISUP. Therefore, SIP-tunnelling- BICC will miss some essential BICC capabilities.

3.3 SIP and 3G technology

The 3GPP are producing globally applicable Technical Specifications and Technical Reports for a third generation mobile system. The group is using IP technology end-to-end to deliver multimedia content to mobile handsets so IETF protocols are a must. The call control and signalling function will be fulfilled by SIP [7]. SIP URLs and/or E.164 numbers, the numbering system of the telephone system, will identify clients. The bearer system (GPRS or mobile IP) will manage micro-mobility. This is the movement of the mobile client from one base station to another. Macro-mobility, the movement of the mobile client from one domain to another, will be handled by SIP. SIP will route signalling so that services are available from the originating or terminating network. 3GPP has identified the CSCF in the network. This is the equivalent of a SIP server, Figure 4.

There will be three different kinds of CSCF.
Proxy CSCF - this is the first point of contact in a visited network and will find the client's home network and provide some translation, security and authorization functions.
Serving CSCF - controls sessions, acts as registrar and triggers and executes services. The serving CSCF will access the client's profile. It can be located in the home network.
Interrogating CSCF - the first point of contact in the home network. It assigns the serving CSCF, contacts the HSS and forwards SIP request. Because of SIP's inherent presence capability, at any one time the network knows where a client is, by what means client is accessible and whether client is available to take a call. The network will divert any incoming calls to the correct device automatically. The same services will apply to mobile devices as to fixed telephones and PCs. Find-me/follow-me, call hold, call forward etc., can be used on mobile phones in a SIP-based architecture.

3GPP has decided to develop an architecture that is based on SIP to solve a number of architectural requirements. These requirements include a disturbed architecture, services architecture flexible enough to provide enhanced services (data combined with voice, characteristics of the communication can change based on the information that needs to be sent…) and the requirement of a Virtual Home Environment.

Figure 4 – SIP Usage in Basic IP Multimedia Subsystem Architecture

4. PROTOCOL INTERWORK

4.1 BICC-SIP Interwork

When a GSM user wishes to begin a session with a SIP user (Figure 5) the GSM network generates an IAM message towards the gateway. Upon receipt of the IAM message CCU routes call to the SIP protocol. SIP protocol performs BICC (ISUP) to SIP mapping and sends data (SIP-IAM) to the SIP proxy as an INVITE method. Proxy sends INVITE to the SIP client. On the other hand, proxy sends a 100 TRYING to the gateway as response. When an event signifying that the call has sufficient addressing information occurs the SIP client will generate a provisional response of 180 or greater and send to the SIP proxy. Upon receipt of a provisional response of 180 or greater SIP proxy forwards the message towards the gateway. SIP protocol in CCU performs SIP to BICC (ISUP) mapping and sends an ACM message to the GSM user. The SIP protocol may use further provisional messages to indicate call progress. After an ACM message has been sent towards GSM user, all provisional responses from the SIP client or proxy will be mapped into CPG message. When the SIP client answers the call it will send a 200 OK message towards proxy. Upon receipt information from SIP client, SIP proxy forwards the message towards the gateway. SIP protocol in CCU performs SIP to BICC (ISUP) mapping and sends ANM message to the GSM user. On the other hand, after sending of ANM message to the GSM user, SIP protocol sends an ACK to acknowledge receipt of the INVITE final response to the SIP proxy. Finally, proxy sends ACK message to the SIP client.

4.2 SIP- BICC Interwork

When a SIP client wishes to begin a session with a GSM user (Figure 5) the SIP network issues an INVITE request towards the gateway. Upon receipt of the INVITE message SIP protocol performs SIP to BICC (ISUP) mapping and CCU routing a call to the BICC (ISUP) protocol.