IEEE MELECON 2004, May 12-15,2004, Dubrovnik, Croatia

Comparison between ToATM and ToIP using BICC as Call Control Protocol
Lovre Hribar, Ericsson Nikola Tesla d.d., Split, Croatia, Damir Buric, Ericsson Nikola Tesla d.d., Split, Croatia, Denis Duka, Ericsson Nikola Tesla d.d., Split, Croatia E-mail: Lovre.Hribar@,ericsson.com, Dainir.D.B.Buric@,ericsson.com,Denis.Duka@,ericsson.com
Abstract: Core Network is based on the separation of functionality into a control layer, a connectivity layer and an application layer. The BICC signaling is carried on top of either ATM or IP based signaling transport using a Signaling Transport Converter, which makes the call control signaling independent on the underlying layers. BICC CS2 protocol versions are enhanced with new set of capabilities in compare with earlier BICC CS1 version. This article has shown that new version of BICC protocol should not exclude the earlier BICC protocol. Operators have been given the possibility for smooth migration from the Telephony Over ATM (ToATM) towards ToIP using BICC as a Call Control Protocol.
1.

_. .....S,ign.dlingTransport llJetwrk......_, ....

-..

INTRODUCTION

Figure I . Network Functional Model

Bearer Independent Call Control Capability Set (BICC CS) protocol have it own place in the Core Network as a Call Control Protocol. BICC CS1 is the first version used in the ATM based core network. The second version of BICC, BICC CS2 is enhanced version of BICC CSl and is used in the Internet Protocol (IP) based core network. This paper gives an overview of the capabilities for each version, tries to explain the conceptual and architectural differences and finally tries to compare different types of set-up modes.
11.

BICC OVERVIEW

A. Core Network Architecture using BICC The BICC protocol provides the signaling functions required supporting narrowband Integrated Services Digital Network (ISDN) services independent of the bearer technology and signaling transport technology used. It is an extension of ISDN User Part (ISUP) protocol and therefore provides a full transparency of the existing telephony functionality [ 11. The first standardized version of BICC protocol was CSl but only BICC CS2 version gives a true separation of control and bearer layer and introduction of 1P bearer. The physical separation of the Call Control and Bearer Control allows physically separate Call Service Function (CSF) and Bearer Control Function (BCF). Inherent in this separation is the possibility for BICC CS2 to support the Bearer Interworking Function (BIWF) selection, allowing a many-to-many relationship between control servers and BIWFs.

BICC is used as a protocol between CSFs within different nodes as originating/destination Serving 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 (BCP) 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 (BCT) shall be used for a call if the BICC-data primitive associated with the Initial Address Message (IAM) or the first backward Application Transport Message (APM) includes the BCT information element set to tunneling to be used. The absence of the BCT 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 BCT shall not be used. The CSF should not process the BCP information transported by tunnelling mechanism. 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 BIWF at the originating SN makes the decision on use of the BCT mechanism on a per call basis. The CSF shall inform the BI WF of the possibility of using the BCT mechanism and

0-7803-827 1-4/04/$20.00 02004 IEEE

677

- 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 Bearer Control = Q.IPBC party to add another party to the call and its BIWF communication capability type 6 or any other, and release the party that it has added, from the call and its I + -Signaling - -- -- - --transport - - - - - -- attachment to the bearer(s). It is proposed for bearer redirection to support establishment of a multi-party service Figure 2. IP Bearer Control Tunelling Concept configuration. Depending whether BIWF has been selected prior to - According to proposals following information should be used at CSF selection of BIWF: outgoing BICC set-up or after there are two different The services required by the call, ways of bearer connection set-up: Forward and The list of BIWF's which can be used to Backward. It depends as well on outgoing CSF route characteristics and originating BIWF. The choice between interface the peer SN, Fast (Forward or Backward) and Delayed 0 Inter-working with Switched Circuit FonvadBackward set-up, respectively, is made by the Networks, originating BCF and is indicated in the initial response Network Interconnect Scenarios from the originating BCF [3]. Minimising the number of BIWF's in the Following the Third Generation Partnership Project connection (3GPP) standard and its model of core network BICC At the succeeding SN, the Bearer Control CS2 defines its own procedures for supporting the codec Unit Identifier (BCU-ID) of the BCU negotiation, mid-call negotiation and tone information. selected at the preceding SN. The CS2 version also supports the bearer redirection - Support of multi-media and related services. Further capability as well as procedures for reuse of idle bearers development of BICC is proposed to be undertaken, and as a network option. not to be limited to the existing narrow-band ISDN service set. This proposal is particularly related to SIP, B. BICC Development i.e. BICC should not compete against SIP, which is BICC CS3 standard work is not finished yet and the regarded as an emerging technology. Intenvorking would following items and contributions are some that are be included as far as existing BICC end terminals could proposed to be in the scope [4]: support a particular service. - The BICC CS3 protocol should support as an optional - Routing methods for E.164, AESA, INRA & IP procedure the transfer of text-based (URLRJRI) naming, addresses (GOL-08 1). This contribution identified complementary to the existing digit-based (E. 164) signalling requirements to support routing methods naming. The transfer of text-based naming is restricted to recommended in E.35 1 for application across network the called party for identification purposes only, not for types, for E.164, AESA, INRA, and/or IP routing routing purposes. Service platform including ENUM addresses. It proposed to develop the required signalling functionality is supposed to map the E.164 telephone requirements needed to support these routing methods. number into a Session Initiation Protocol (SIP)-URL. - International Emergency Preference Scheme (IEPS) Reverse ENUM functionality supposes the reverse support. mapping. - It is supposed for BICC to fully support the advanced 111. OUTGOING BEARER SET-UP PROCEDURES CMN call control procedures. The call control procedures shall support: When the relevant Outgoing signalling procedure A mechanism of relaying CMN exchange data determines that the IAM can be sent the procedure for and/or IN data between the CMN (CSF-G) and bearer set-up in forward or backward direction is started. the Originating SN using functionality already Five variations of procedure are defined. The BCP used to set up the bearer may be either tunnelled in BICC provided in SS7 A mechanism for relaying recording, exchange, messages, or sent between the BCFs via alternative and/or IN data between an Originating SN and a signalling means. In the former case, there are three variations: CMN with the same network; call routing "Fast set-up'' - in which bearer control Screening fimctionality at the CMN (by the information is carried in the IAM and subsequent C SF-G).
the BIWF shall respond with an indication of whether the Tunnel should be set up or not.

/-$-q *

678

APM(s). This variation is supported for both the forward and backward bearer set-up cases. "Delayed Forward set-up" - in which bearer control information is carried in APM messages following the first backward APM. "Delayed Backward set-up" - in which bearer control information is carried in the first backward APM and a subsequent APM(s). In the non-tunnelled case, two possibilities are defined. "Per-call bearer set-up in forward direction" - in which bearer control is achieved using a separate bearer control protocol, initiated in the forward direction (relative to the call set-up direction). "Per-call bearer set-up in backward direction" in which bearer control is achieved using a separate bearer control protocol, initiated in the backward direction (relative to the call set-up direction). The choice of variation to use for a calf is done as follows: If a BIWF has been selected when outgoing set-up is initiated: The choice between forward and backward bearer set-up is provisioned at the CSF, as an originating BIWF or outgoing call route characteristic. The choice of tunnelled or non-tunnelled operation is made by the originating BCF and is indicated in the initial response from the BCF. (The CSF may indicate in the initial request to the BCF what tunnelling option(s) it may choose.) 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 this BCF. (The CSF may indicate in the initial request to the BCF what option(s) it may choose.)

If the received Action indicator is "Connect forward, plus notification" the Connect Type is set to "notification required", else it is set to "notification not required". A BIWF is selected, if one was not selected earlier. A Bearer Set-up request is sent to the selected BCF. This request includes: BNC-ID, BIWF Address, Bearer Characteristics, i.e. Transmission Medium Requirements (as received in the'IAM) and User Service Information (if received in the IAM). When a Bearer Set-up Connect indication is received this indicates successful completion of the outgoing set-up procedure. If the Connect Type is "notiJicationrequired" a BICC-Data request primitive (corresponding to an APM message), is sent containing: Action indicator set to "Connected". B. Per-call bearer set-up in Backward direction In this procedure the bearer is set up in the backward direction from the succeeding SN back to the SN that sends the IAM. The IAM sent includes information to enable the bearer to be addressed back to the SN that sends the IAM, and to allow the bearer set-up indication to be correlated with the call. In the response to the BNC Information request primitive the BCF returns the BNC characteristics, BNC-ID and BIWF Address. The response also indicates that bearer control tunnelling is not being used. An IAM is sent together with a BICC-Data request primitive containing: Action indicator set to "Connect backward'', BNC-ID, BIWF Address, BNC characteristics. When the bearer connection arrives at the SN a Bearer Set-up indication is received from the BCF. The Bearer Set-up indication is correlated with the call instance and a Bearer Set-up response is sent to the BCF. The outgoing set-up procedure is now successfully completed
C. Delay bearer set-up in Forward direction In this procedure the bearer is set up from the SN that sends the IAM. Initial bearer set-up information is unavailable when the IAM is sent - if a BIWF has been selected at this point the unavailability is indicated by the BCF. Alternatively, bearer set-up information is unavailable if the BIWF has not yet been selected, but in this case the fact that bearer control tunnelling will be applicable for the call is not initially known. Initial actions depend on whether a BIWF has been selected at the initiation of outgoing bearer set-up. If a BIWF has been selected, in the response to the BNC Information request primitive the BCF returns the BNC characteristics. The response primitive also may include the BIWF-Address. The response also indicates that bearer control tunnelling is being used and that the delayed forward set-up procedure are to be used. An IAM is sent including in the BICC-Data request primitive: Action indicator set to 'Connect forward", Bearer Control Tunnelling, set to "tunnelling to be used'', BNC characteristics, BIWF Address, if received from the BCF.

A. Per-call bearer set-up in Forward direction In this procedure the bearer is set up in the forward direction from the originating SN forward to the SN that receives the IAM. Information to enable addressing and bearer identification is awaited from the succeeding SN before the bearer set-up can be initiated. Initial actions depend on whether a BIWF has been selected at the initiation of outgoing bearer set-up. If a BIWF has been selected: in the response to the Backbone Network Connections (BNC) Information request primitive the BCF returns the BNC characteristics, and may include the BIWF Address. The response also indicates that BCT is not being used. If no BIWF has been selected BNC Characteristics is set to a value determined by the CSF application logic. An IAM is sent including in the BICC-Data request primitive: Action indicator set to "Connect forward", BNC characteristics, BIWF Address, if received from the BCF, BCT set to "no indication", if the BIWF has not been selected, providing that bearer control tunnelling is allowed. Subsequently BICC-Data indication primitive (corresponding to an APM message), should be received:

679

Subsequently a BICC-Data indication primitive (corresponding to an APM message) should be received. If the received Action indicator is "Connectforward, plus notification" the Connect Type is set to "notfication required", else it is set to "notfication not required". A BIWF is selected, if one was not selected earlier. A Bearer Set-up request primitive is then.sent to the selected BCF containing: BNC-ID (if received in the BICC-Data indication primitive), BIWF Address (if received in the BICC-Data indication primitive), Bearer Characteristics, i.e. Transmission Medium Requirements (as received in the IAM) and User Service Information (if received in the IAM), an indication that bearer control tunnelling shall be used (if this request was received in the BICC-Data indication primitive). Bearer control tunnelling is then used to exchange bearer set-up information between BCFs. Receipt of a primitive from the BCF, indicating "BNC set-up successrr indicates successful completion of the outgoing set-up procedure. If the Connect Type is "notification required" a BICC-Data request primitive (corresponding to an APM message), is sent containing: Action indicator set to '%onnected". D. Delay bearer set-up in Backward direction This procedure is invoked if the received Action indicator is set to Tonnect backward" and the Bearer Control Tunnelling information element is present indicating, "tunnelling to be used". In this procedure the bearer is set up in the backward direction from the succeeding SN back to the SN that sends the IAM. A Bearer Set-up request primitive is sent to a selected BCF. This request includes: BNC Characteristics (as received via BICC-Data indication primitive associated with the IAM), BIWF-Address (if received in the BICC-Data indication primitive), BNC-ID (if received in the BICC-Data indication primitive), Bearer Characteristics, i.e. Transmission Medium Requirements (as received in the IAM) and User Service Information (if received in the IAM), an indication that bearer control tunnelling shall be used. Bearer control tunnelling may then be used to exchange bearer set-up information between BCFs. Receipt of a primitive from the BCF, indicating "BNC set-up success", indicates successful completion of the incoming set-up procedure.
IV. MEASUREMENT FOR CALLS OVER ATM&IP

For each type of subscribers access measurement is taken for ATM and IP as a bearer backbone and for different types of call set-up.
TAR1.E . .. _ -- 1 ..

TABLE 2.

Call set-up times are presented (Table 1 and Table 2) only for BICC protocol complex. Set-up time represent amount of jobs executed in BICC protocol complex until B-phone is ringing. Answer time represent amount of jobs executed in BICC protocol complex when B subscriber answers the call. Release time represent amount of jobs executed in BICC protocol complex when a subscriber hooks on the handset.
V. CONCLUSION

IP type of bearer always requires longer call set-up times no matter which type of call set-up scenario is used. This is expected result as a consequence of more signaling and processing more jobs in BICC complex. On the other hand, answer and release times are not affected by types of bearer used (ATM or IP).
REFERENCES

The purpose of this chapter is to describe and compare results of the time measurement for establishment of BICC calls over IP and ATM bearer backbone. The major point of interest is BICC as a Cal Control Protocol and the time taken for basic call set-up. To obtain these measurement results simple calls over BICC are made for two types of subscribers access: PSTN and ISDN.

[l] Lovre Hribar, Damir Buric, "Usage of BICC and SIP protocol in IP core network", 11. International Conference on Software, Telecommunications & Computer Networks, SoftCOM 2003 [2] ITU-T, Q. 1902.1 Bearer Independent Call Control protocol (Capability Set 2) : Functional Description. [3] ITU-T, Q.1902.4 Bearer Independent Call Control protocol, basic call procedures [4] ITU-T, Technical Report TRQ.BICC.CS3 General signaling requirements for the support of narrowband services over broadband transport technologies, BICC Capability Set 3

680