BICN

BT Technol J Vol 19 No 2 April 2001

77

Bearer-independent call control

R R Knight, S E Norreys and J R Harrison

One elusive aspect of voice over IP is the problem of providing a public switched telephone network (PSTN) using IP as thecore technology. This paper discusses the need for PSTN replacement with IP, and compares some of the signalling and callcontrol options currently being progressed in standards bodies. The bearer-independent call control (BICC) underdevelopment in the ITU is explained in greater depth, covering the requirements, functional modelling, information flowsand protocol aspects. The paper concludes with the current open issues and time-scales for the standardisation of BICC.

1. Introduction

It is easy to forget, however, that the volume of non-Internet telephony traffic also continues to grow. Bettermarketing information enables personalised direct telesales,and the enormous growth in mobile telephone sales bothcontribute to the demand for telephony-type services. Thetelephony growth, however, is small (about 3—5% perannum, depending on statistics and network operator)compared to the phenomenal growth in Internet and IP-related traffic (anything from 100% to wildly imaginativefigures exceeding the world’s production capabilities).

The Internet Engineering Task Force (IETF) is thestandardisation body charged with developing protocols forthe Internet, and they have made considerable progress inspecifying protocols to enable the packetisation of speech.Voice over IP is a much abused term, but in this paper isunderstood to be the ability to support on demand real-timeconversational speech communication. A major factor in thedevelopment of the protocols is the commercialopportunities offered by new services integrating real-timemedia (including voice) and data.

Recently, PNO have faced a choice in the developmentof networks — to leave the existing, regulated switchedcircuit network (SCN), also known as the time-divisionmultiplex network (TDM), frozen in its current state, andstart to deploy a new network, better suited to IP-basedterminals, outside the constraints of regulation and offeringthe potential of new services with faster deployment, and at

lower costs. If the demand for telephony was not alsogrowing, this strategy might have been adopted; however,many TDM networks are running out of switching andtransmission capacity.

First conceived in the early 1970s, integrating voice anddata to provide a single, comprehensive, multi-purposecommunications network [1] offered a solution for PNOs.Reduced operating costs from simpler network and servicemanagement still provide the rationale for integration today.

The IETF began work on voice over IP (VoIP) as ameans of supporting just another media type to betransferred using the Internet. Adding the emulation ofexisting public switched telephone networks (PSTNs) orintegrated services digital networks (ISDNs) was a laterenhancement. The use of the session intiation protocol (SIP)in this context is covered elsewhere [2]. The IETF approachhas been to specify enhancements to SIP for the basic call(and a few selected supplementary services). Additionalservices and intelligent network (IN) support are currentlybeing worked on and can be expected in the future.

2. Overview and scope of bearer-independent call control

While the IETF are the prime standardisation body for the Internet and general IP-related protocols, the

international standards organisation with the greatestexpertise and experience in telephony is the InternationalTelecommunications Union — TelecommunicationsStandardisation Sector (ITU-T). It was the ITU-T (formerlythe CCITT) that standardised the main signalling protocolfor telephony networks — integrated services user part(ISUP) as part of Signalling System No 7 (SS7). ITU-Tlooked at the work that the IETF were undertaking on VoIPand the strategy for PSTN/ISDN replacement.

The patterns of telephony traffic in the networks run bypublic network operators (PNOs) have changed

drastically over the last five years. Communicationsmethods have changed and the demand for access to theInternet seemingly grows daily. Throughout the year 2000many PNOs have reported that the Internet and related IPtraffic has surpassed, in simple bandwidth, the demand fortraditional telephony traffic.

BEARER-INDEPENDENT CALL CONTROL


78

The ITU-T took a very simplistic view on PSTN/ISDNreplacement — if you try to emulate existing services usinga new protocol the result will not be an identical service.Even more drastic was their opinion that nothing less than100% of the existing services should be supported in anynew technology that intends to replace the TDM networkand support existing customers. This strategy has consid-erable merit, since it does not seem a wise strategy to takeservices away from customers, only to re-instate them againat some point in the future. Telecommunications customerspurchase service, not technology, from their networkoperator. The service that they purchase is very much richerthan simple voice communication — it is an intricate set ofcomplex services available for a very simple terminal thatoperates to provide access to global communications. Evenwithin the existing TDM network, there are instances ofservice interactions that fail due to incompatibilitiesbetween implementations of ISUP, and the success ofemulating all of the services, at day one, in a differenttechnology and using a different signalling system was seenas doubtful by many network operators active in the ITU-T.

This simple view of replacing the technologyunderlying the existing telecommunications networks wasgiven further impetus as TDM networks began to reachtheir design capacity, and network operators were unwillingto add further investment in TDM-based technology. As thedemand for new TDM switches (exchanges), and the needfor new services to be added to existing TDM networks,fell, the cost of TDM switches grew. The immediate issueof relieving the capacity problem needed a solution thatwould be compatible with the longer term aims of thenetwork operators. Another simple solution was arrived at.Rather than develop an ISUP derivative for the IP world,and another as a stop gap for the capacity problem, the ITU-T began work on defining an ISUP derivative that would be100% compatible with the existing networks, but couldoperate in any environment that could transport voice withreasonable quality. The term that they coined for thisprotocol was bearer-independent call control — BICC.

The scope of this new work was severely limited — ithad to:

• be based on ISUP, to be fully compatible with existingservices,

• be independent of the underlying technology,

• reuse existing signalling protocols to establish thecommunications within networks.

These restrictions positioned the standardisation workindependent from other standards organisations and withthe single simple goal of PSTN/ISDN replacement. Manystandards bodies have begun work with a very simple goalonly to be distracted along the way with new ideas andaspirations. The success of BICC has been a doggeddetermination to remain within the existing scope and not to

extend it to cover such exciting features as multimediasupport. One single enhancement, beyond existing ISUPcapabilities, was added — better support for mobile calls.Many of the world’s fixed networks provide theinterconnect for mobile calls, and one of the main causes ofloss of speech quality for mobile-to-mobile calls is theconversion to the fixed network voice coding schemes andback again (transcoding). The ability to signal codec usage,and to negotiate the best codec to use for a particular callcould easily be added without compromising theinterworking with ISUP, and therefore the backwardscompatibility.

The goal of BICC was simple, and the starting point wasto take ISUP and determine which parts were not applicableto alternative technologies, and to add to ISUP only featuresto enable connections to be established by the newtechnology. Three technology types were identified forvoice transport: ATM AAL1, ATM AAL2 and IP. Sincemany network operators had already deployed networkswith these technologies, the signalling systems that couldestablish connections across these technologies wereidentified as being:

• the ATM Forum UNI4.0 and ITU-T DSS2 for accesssignalling in ATM,

• ITU-T B-ISUP, ATM Forum PNNI and AINI for corenetwork signalling in ATM,

• AAL Type 2 signalling [3] as a true bearer controlprotocol in ATM,

• SDP [4] for IP networks.

This was felt to be a considerable task to achieve in onego, and with the pressure from network operators for ashort-term solution to the capacity shortage problem, thestandardisation work was split into two capabilities —ATM for the short-term problem and the addition of IP forthe longer term. It should be noted that IP was always seenas the target, and that the ATM work would merely be a stepalong the way.

3. BICC architecture

The starting point for the BICC architecture was toassume that calls would enter (ingress) and exit (egress)

the new network technology through interface servingnodes (ISN). More generally, a serving node (SN) is a pointin the network that provides the functionality for existingPSTN/ISDN services. Networks tend to grow from thecentre outwards, since it is pointless to provide functionalityat one access gateway that cannot be supported elsewhere.The ISN initially had to provide a signalling interfacebetween the narrowband ISUP and a peer ISN, as shown inFig 1.



79

This simple architecture, although realistic, does notprovide any flexibility. In a large network theinterconnections are much more flexible, with core networknodes to spread traffic evenly across the network. Thisinitial scenario also would not prove that a robust andgeneric standard was being produced, since BICC wouldonly interface between ISUP and itself. A more realisticscenario allows the interconnection with other licensedoperators (OLOs), which is conceptually performed at aPSTN gateway. Retaining the PSTN naming conventions,this new node was named a gateway serving node (GSN). Itprovides connectivity between two BICC networks andinterconnection consists of a pair of GSNs communicatingvia a simple transmission link. Although this is notnecessarily exactly how network operators perform networkinterconnection, it is a simple model that is sufficient forstandardisation.

If two network operators can interact, then it should alsobe possible for a single network operator to provide PSTN/ISDN services at a node within a network, as a point offlexibility. This node is similar in function to a transitexchange, and was named the transit serving node (TSN).Fig 2 shows the ISN, TSN and GSN in a simpleconfiguration.

Figure 2 also shows that account must be taken of alltypes of network technology. ATM, recognised as the short-term solution for relieving capacity, uses intermediateswitches set up by signalling. These nodes are termed bearerrelay nodes (BRN), and not all network technologies needthese nodes.

One of the key requirements of BICC was to fullysupport 100% of the narrowband services on firstdeployment, and this clearly includes the services derivedfrom intelligent networks. Intelligent network services areoften provided by a transit exchange, on behalf of a localexchange. In some smaller networks (not BT), it evenmakes sense to provide a single node that offers access toIN. Additionally, in IP networks, it is not necessarily veryefficient to provide, at a TSN offering IN access, conversionof the user plane packets through the TSN. This type ofscenario occurs (for example) where charge card servicesare provided by IN. The initial number dialled takes the callas far as an IN special resource (located at a TSN), whichthen collects further digits providing charge cardauthorisation and destination number. The call is thenrouted from the TSN — but optimisation could occur if theTSN was allowed to migrate to a node that supported theBICC signalling, but no longer had the user plane present.

Fig 1 Initial BICC architecture.

connection signalling

TDMconnection

ISUP

new network

(user plane connection)

ISUP - BICCI/W

IWU

ISUP - BICCI/W

IWU

BICC ISUP

TDMconnection

N/B exchange ISN ISN

Fig 2 BICC serving nodes.

ISUP - BICCI/W

IWU

ISN

ISUP - BICCI/W

IWUBRN(Sw)

BRN(Sw)

BRN(Sw)

TSN GSN GSN ISN

new network

newnetwork

IWU IWU IWU

BICC BICC BICC



80

For these reasons, a special call mediation node (CMN) wasintroduced. This is really just a special case of a TSNwithout a user plane, and so does not serve the user plane(hence it was not called a call serving node). This is coveredin more detail in section 4.2.

4. Requirements

4.1 Service requirements

Since BICC must support all existing narrowband calls,the service requirements are based upon the services that

ISUP supports. These are defined in Q.761 in tabular form.The BICC service requirements were derived by taking thistable and determining which ISUP services were notapplicable in non-narrowband technology networks. Thisremoves those services that relate more to theestablishment, control, maintenance and release of thecircuit within TDM switches, and the TDM transmissionpath between the switches (see Table 1).

4.2 Functional model

The architecture for managed IP networks supportingreal-time services is built around the concept of mediagateways (MGs) that provide conversion of user planecommunications from one format (e.g. TDM) to another(e.g. IP). The control of these MGs is then performed bymedia gateway controllers, providing a split ofresponsibilities between two separate physical units. Sinceit is highly desirable that BICC can co-exist in the sameenvironment, the functional model first separates the

The requirements for the signalling protocols are derivedfrom the services to be supported and the functional

modelling. Functional modelling decomposes networkfunctionality to logical entities and the information to beexchanged by the entities to achieve the services. Thefunctional modelling in BICC builds upon the networkarchitecture to produce a conceptual model and theinteractions between the functions in the model.

Table 1 ISUP services supported by BICC.

ITU-T ISUP 2000 Function/service Applicability to BICC ITU-T ISUP 2000 Function/service Applicability to BICC

Basic callSpeech/3.1 kHz audio64 kbit/s unrestrictedMulti-rate connection typesN ✕ 64 kbit/s connection typesen bloc address signallingOverlap address signallingTransit network selectionContinuity checkForward transferSimple segmentationTones and announcementsAccess delivery informationTransportation of user teleservice informationSuspend and resumeSignalling procedures for connection type allowing fallback capabilityPropagation delay determination procedureEnhanced echo control signalling proceduresSimplified echo control signalling proceduresAutomatic repeat attemptBlocking and unblocking of circuits and circuit groups (in Q.BICC, circuits = CIC which is equal to the CCA-ID)CIC group query (in Q.BICC, CIC = CCA-ID)Dual seizure (in Q.BICC, dual seizure applies to CIC = CCA-ID and does not refer to circuits)Transmission alarm handling for digital inter-exchange circuitsReset of circuits and circuit groups (in Q.BICC, cir-cuits = CIC which is equal to theCCA-ID)Receipt of unreasonable signalling informationCompatibility procedureTemporary trunk blockingISDN user part signalling congestion controlAutomatic congestion controlInteraction between N-ISDN and INAPUnequipped circuit identification code (in Q.BICC, CIC = CCA-ID)ISDN user part availability controlMTP pause and resumeOver length messagesTemporary alternative routeing (TAR)Hop counter procedureHard-to-reachCalling geodetic location procedure

Generic signalling proceduresEnd-to-end signalling — pass along method

RequiredRequiredRequiredRequiredRequiredRequired

National OptionNot Required

RequiredRequiredRequiredRequiredRequiredRequiredRequired

RequiredNot Required

RequiredRequiredRequired

National OptionRequired

Not Required

Required

RequiredRequired

Not RequiredRequiredRequiredRequired

National Option

Not RequiredRequiredRequiredRequiredRequiredRequiredRequired

Required

End-to-end signalling — SCCP connectionorientatedEnd-to-end signalling — SCCP connectionlessGeneric number transferGeneric digit transferGeneric notification procedureService activationRemote operations service (ROSE) capabilityNetwork specific facilitiesPre-release information transportApplication transport mechanism (APM)RedirectionPivot Routeing

Supplementary servicesDirect-dialling-in (DDI)Multiple subscriber number (MSN)Calling line identification presentation (CLIP)Calling line identification restriction (CLIR)Connected line identificationpresentation (COLP)Connected line identificationrestriction (COLR)Malicious call identification (MCID)Sub-addressing (SUB)Call forwarding busy (CFB)Call forwarding no reply (CFNR)Call forwarding unconditional (CFU)Call deflection (CD)Explicit call transfer (ECT)Call waiting (CW)Call hold (HOLD)Completion of calls to busy subscriber (CCBS)Completion of calls on no reply (CCNR)Terminal portability (TP)Conference calling (CONF)Three-party service (3 PTY)Closed user group (CUG)Multi-level precedence and pre-emption (MLPP)[Note: only transiting of MLPP information is sup-ported]Global virtual network service (GVNS)International telecommunication chargecard (ITCC)Reverse charging (REV)User-to-user signalling (UUS)

Additional functions/servicesSupport of VPN applications with PSS1information flowsSupport of number portability (NP)

Required

RequiredRequiredRequiredRequiredRequiredRequiredRequiredRequiredRequiredRequiredRequired

RequiredRequiredRequiredRequiredRequired

Required

RequiredRequiredRequiredRequiredRequiredRequiredRequiredRequiredRequiredRequiredRequiredRequiredRequiredRequiredRequiredSee Note

RequiredRequired

RequiredRequired

Required

Required



81

generalised serving node into portions that can be mappedon to an MG/MGC architecture. Requirements for VoIPnetworks have been derived in the ETSI Project ‘TIPHON’[5], and other work has been performed in the MultiserviceSwitching Forum. The work of both of these groups wastaken into account in deriving the functional model, whichallows a physical split between the call and bearer control,as well as the more general split between controlfunctionality and the media gateway. Figure 3 shows thebasic split of functionality. The call serving function (CSF)provides the BICC procedures on a per-call basis. Thebearer control function (BCF) provides a point of flexibility,and could be considered to be drawing upon functionality inmore general-purpose media gateway controllers. Thesimple media gateway functions (without any controlfunctionality) is provided by the media mapping andswitching function (MMSF).

Since the BICC standardisation concentrates on therequirements to support existing narrowband servicesutilising broadband technology, the BCF and MMSF arelogically grouped together to form a bearer interworkingfunction (BIWF). The BICC architecture allows for theinterface between the BCF and MCF to be open (the ‘BMC’interface), but the split of functionality between the BCFand MMSF is not considered to be the responsibility of theBICC standardisation group.

Fig 3 Decomposed CS2 serving node.

A more general architecture allows a single call serverto control multiple media gateways (MGs), and this isreflected in the BICC functional model as shown in Fig 4.

The requirements for supporting mobile applicationshave also been incorporated, and this requires multipleCSFs to control a single B-IWF as shown in Fig 5. Thereasoning for this is to enable a call and bearer to beprogressed to the mobile network, and the call only to beprogressed within the mobile network to the terminal. Atthis point, tones may need to be applied, under the controlof the call server in the mobile network, but implemented bythe existing B-IWF.

Fig 5 Control of B-IWF by multiple CSFs.

Figure 6 shows a simplified functional model. It shouldbe noted that BICC CS2 also supports all of thefunctionality of CS1, and therefore a TSN is also supported,but this is not shown. Also not shown is the support foraccess networks, which is an integral part of the ISUP-DSS1 interworking, and the IN functionality.

5. BICC CS1

During the second half of 1999 and the early part of 2000, ITU-T Study Group 11 conducted intensive work on

the initial capability set of BICC (BICC CS1). Although ithas always been recognised by the designers of BICC that itshould be both signalling transport and bearer transportindependent, in order to provide a meaningful and usefulCS1 package in the time-scales allowed, the initialcapability set work focused on a subset of BICCrequirements. This subset was selected by reference to theimmediate requirements of certain network operators andequipment implementors, but care was taken to preventshort-term expediency limiting the scope of future BICCcapabilities. In February 2000, BICC CS1 work wascompleted and formal ITU-T approval was given in June2000.

CSF

BCF

MCF

MMSF

physical unit function

CBC

BMC

BIWFMGU

BCU

CCU

BICC CS2

bearer controlprotocol

bearer(user plane)

CSF

B-IWF2

B-IWF1

CBCinterface

CBCinterface

Fig 4 Control of multiple B-IWFs.

B-IWF

CSF2

CSF1

CBCinterface

CBCinterface



82

5.1 What does BICC CS1 offer?

BICC CS1 is designed to allow a large incumbent ISUP-based network operator to migrate from using MTP3signalling networks and TDM bearer networks towardsalternative packet-based technologies. The BICC CS1model allows an ATM segment to be inserted into anexisting ISUP narrowband network without loss of ISUP orIN features and services (see Fig 7).

The BICC protocol is very closely based on the ISUPprotocol. It has been designed to interwork ‘naturally’ withnarrowband ISUP taking full benefit from its strong forwardand backward compatibility features. This means that it hasinherited all the narrowband ISUP features and services thatare applicable in a separated bearer environment.Furthermore, non-BICC relevant ISUP signals can betransferred transparently between two PSTN/ISDNconnected by a BICC segment without loss of servicesoffered.

BICC CS1 has also introduced new optional ‘codecnegotiation’ and ‘codec modification’ capabilities notdefined in narrowband ISUP. These will allow BICC tooffer transcoder-free operation in core networks supporting,

for example, mobile services. Transcoder-free operationimproves speech quality by avoiding unnecessarytranscoding between different speech encoding/compression schemes within the network.

5.2 The BICC CS1 specification model

The model of the interface serving node (ISN) used forBICC CS1 is shown in Fig 8. It can be seen that this is asubset of the comprehensive model used for BICC CS2, seeFig 6.

The call service function (CSF) performs threefunctions:

• interfaces to the traditional ISUP signalling in theTDM domain,

• provides a generic interface to the signalling transportspecific converter (STC),

Fig 6 BICC CS2 simplified functional model.

CSF-N CSF-C CSF-G CSF-G

BCF-NBCF-J

router

CMN

BCF-N BCF-G BCF-G

B-IWF B-IWF B-IWF B-IWFrouter

bearersignalling

bearersignalling

ISN GSN GSN ISN

CSF-N

B-IWF

bearer(user

communication)

call and bearersignallinge.g. ISUP

call and bearersignallinge.g. DSSI

bearer(user

communication)

BICC

ISN ISN

separated bearer

BICC signalling

PSTN/ISDNISUP call + bearer

ISUP service transparency

PSTN/ISDNISUP call + bearer

Fig 7 BICC segment inserted into an existing PSTN/ISDN.

BICCCSF

STC

BCF

BIWF

formal primitiveinterface

informal primitiveinterface

ISN

bearer bearer

bearer controlsignalling

BICCsignalling

PSTN/ISDNISUP

call/bearersignalling

Fig 8 Functional components of the ISN as used for BICC CS1.



83

• provides a generic (but loosely defined) interface to thebearer interworking function/bearer control function(BIWF/BCF).

The signalling transport converter (STC) maps thegeneric BICC on to a specific signalling transport. ForBICC CS1, STCs are defined by ITU-T for the followingsignalling transports:

• MTP3/3B,

• SSCOP,

• SSCOPMCE.

The BIWF provides interworking of different bearertechnologies (e.g. TDM to ATM). The BCF provides bearerspecific signalling to establish new bearers for use by BICCcalls. A BICC CS1 CSF controls the BIWF/BCF through ageneric, but loosely defined, primitive interface. To allowfor adequate interoperability between the ISN implemen-tations of different manufacturers, it is necessary to describeBICC mapping to/from specific bearer networktechnologies. For BICC CS1, mappings on to the followingbearer network interfaces has been defined by ITU-T:

• AAL1 using DSS2 signalling,

• AAL1 using B-ISUP signalling,

• AAL2 using AAL2 (CS1) signalling.

Furthermore, the ATM Forum (ATM-F) has definedmapping of BICC on to:

• AAL1 using ATM-F UNI signalling,

• AAL1 using ATM-F PNNI signalling,

• AAL1 using ATM-F AINI signalling.

5.3 How and where is BICC CS1 specified?

BICC CS1 is specified as a ‘delta’ to ISUP2000. TheISUP2000 base text is defined by:

• ITU-T Recommendations Q.761 to 764 (including anAddendum to Q.762 and Q.763),

• ITU-T Recommendation Q.765.

The BICC ‘delta’ is defined in ITU-T RecommendationQ.1901.

Annexes to ITU-T Recommendation Q.1901 describeinterworking of ISUP with BICC at an ISN and therequirements for specific signalling transport converters(see section 7.4).

The specific application of the BICC/ISUP applicationtransport mechanism (APM) used in BICC to support theseparated bearer procedures is defined in ITU-TRecommendation Q.765.5 (2000).

Descriptions of BICC operating with ITU-T bearercontrol signalling systems are in ITU-T supplements.

• TRQ.3000 (operation of BICC with DSS2),

• TRQ.3010 (operation of BICC with AAL2 CS1),

• TRQ.3020 (operation of BICC with B-ISUP forAAL1).

The description of BICC operating with ATM-F bearercontrol signalling systems is in AF-CS-VMOA-0146.000(operation of BICC with SIG4.0/PNNI1.0/AINI).

6. Call flows

The incoming IAM message is received at theoriginating ISN and the outgoing IAM is generated and sentout to the succeeding node with the BNC characteristics(generated from the USI and TMR ISUP parameters)encapsulated in an APP parameter.

Upon receipt of an APM message with the beareraddressing information, the CSF will then notify the BIWFof the request for a bearer and the bearer addressinginformation. The BIWF will then send back an indicationonce the bearer has been established, and the CSF willforward this information in an APM message to thesucceeding node.

The actions at the destination CSF are to notify thepreceding node, in an APM message, of the addressinginformation required to set up a bearer. If this node is a TSNit will then generate and send out an IAM with a ‘COT onprevious’ indication plus its BNC characteristicsencapsulated in an APP parameter and await an APM withthe bearer addressing information. If this node is thedestination ISN, the same action to send back an APMmessage applies, but the outgoing IAM with ‘COT onprevious’ indication is sent to the ISUP call control in theTDM network.

Further APM message exchanges are optionaldepending on whether codec negotiation or tunnelled bearerinformation is deployed.

F igure 9 shows a simplified version of the call flows andthe interactions between the vertical and horizontal

interfaces. They also show how the BICC environmentinteracts with the PSTN/ISDN environment.



84

The COT message is then sent by the TSN once thebearer requirements have been met, and a bearer path hasbeen established between the SNs. The destination ISNsending out an ISUP COT message completes the call.

The message flows for ACM and answer are the same asfor ISUP.

The release signalling sequences, which are not shown,are also unchanged from ISUP, although an instruction fromCSF to BIWF is also required to release the bearer.

The backward bearer set up uses the same messageflows except that the bearer characteristics and tunnellinginformation are generated at the destination BIWF andpassed back between CSF in the first backward APM.

7. BICC protocols

7.1 BICC protocol in IP networks (CS2)

BICC CS2 call control protocol builds on the work inCS1 in that the protocol is based upon ISUP, it

includes most of the services supported by ISUP as the

architecture now includes local exchange functionality. Theimpact of this has required that the basic callrecommendation, developed in the ITU-T SG11, is nowcomplete text instead of a delta on the ISUPrecommendation as published in CS1. The recom-mendations in the basic call series are shown in Table 2.

Any future developments of ISUP will now include newversions of Q.761 and Q.764 with the definition and layoutof any new parameters and messages documented inQ.1902.2 and Q.1902.3.

As BICC CS2 includes the local exchange functionality,it has to support the ISUP supplementary services as well asthe originating and destination exchange functions, e.g.building the IAM and supporting call diversion. This isdone by interworking the BICC functionality with the ISUPfunctionality as illustrated in Fig 10.

Some of the ISUP protocol is not required for the BICCprotocol either because it is a pure ISUP TDM circuit-

Fig 9 Call flow for forward bearer establishment of the backbone network.

SWN-1

BICCBICC

SWN-2 SWN-1 SWN-2

ISUP

ISN-A

IAM (COT on previous), (Action=Connect Forward),(BNC characteristics)

IAM (Action=Connect Forward), (BNC characteristics)IAM

“AAA”APM (Action=Connect Forward, no notification)

(BNC-ID=z1), (BIWF Addr=z)

APM (Action=Connect Forward, no notification)(BNC-ID=y1), (BIWF Addr=y)

Bearer-Set-up req. (BNC-ID=y1), (BIWF-Addr=y)

Bearer-Set-up req.

Bearer-Set-up req.

Bearer-Set-up req.(BNC-ID=z),

(BIWF-Addr=z)

Bearer-Set-up req.

COT

Bearer-Set-up req.

“BBB”

Bearer-Setup-Connect






ACM

ANM

ACM

ANM

ACM

ANM

ACM

ANM

TSN ISN-B

ISUPCSF-N

BCF-N(x)

BCF-R BCF-RBCF-N

(y)BCF-R BCF-R

CSF-N

BCF-N(z)

CSF-T



85

control functionality or the service is not supported. So, forexample, the circuit identification code (CIC) has changedits meaning in a BICC environment to call instance codeand is larger than the ISUP CIC, thereby increasing thenumber of simultaneous calls that can be supported by theprotocol (although exchange performance is more likely tobe the limit on the number of calls supported).

The ISUP local exchanges are the nodes which supportthe majority of the supplementary services functionality andas such the BICC local SN will have to emulate this tosupport the full PSTN/ISDN services. This has had animpact on some of the supplementary services, e.g. the calldiversion supplementary service which could take accountof the global call reference and therefore change the service.Other supplementary services such as conference and threeparty calls need to take into account that more than onebearer could be involved — as this has not been resolvedyet, future work may be required.

Fig 10 BICC signalling interworking architecture.

A new generic service, bearer redirection, has beendeveloped in which the bearer is redirected to a newdestination SN but the call is not. This could be deployed inthe BICC network for interworking to an IN service such asa charge card service where the IN needs to be involved inthe call but the bearer does not, and the call diversionservices could also use this functionality.

The other important aspect of BICC CS2 is that it issupported on an IP bearer and that the bearer control andcall control are separated. The model also allows for oneCSF to control more than one BIWF and for a BIWF to becontrolled by more than one CSF. This means that theamount of information that has to be carried from theoriginating SN to the next SN in the call path has increased.This is for call/bearer correlation and identificationpurposes.

A number of bearer set-up procedures for a call havebeen included in the BICC signalling procedures to takeinto account the differing bearer set-up methods, i.e.forward, backward and idle bearer. This has increased thecomplexity of the signalling procedures, but they are stillbased upon the ISUP signalling.

As some of the bearer set-up procedures require aconfirmation that each SN in the bearer path has enabled theuser plane communication, this could result in thedestination SN holding up the sending of the outgoing IAM.This could lead to an unacceptable delay in setting up a call;to overcome this the ISUP continuity signalling procedurehas been included in the BICC environment. The continuity‘test’ of the connection as defined for ISUP is not includedin BICC, but the COT signal has been reused to indicate thata bearer path has been set up and that the IAM is allowed togo forward from the BICC environment.

To allow for network optimisation and the support ofmobile telephony a codec negotiation and modificationprocedures have been added to the BICC protocol. Thiscould have an impact upon the conference and three-partysupplementary services where a different codec may havebeen negotiated for each call leg.

7.2 IP bearer control protocol

IP networks are fundamentally different fromconnection-oriented networks, such as those based on TDM

Table 2 BICC basic call recommendation series.

BICC recommendation

Equivalent ISUPrecommendation

Describes Comments

Q.1902.1 Q.761 Scope A complete stand-alone text

Q.1902.2 Q.762 Definitions Shared with ISUP

Q.1902.3 Q.763 Formats and codes Shared with ISUP

Q.1902.4 Q.764 Procedures A complete stand-alone text

PSTNaccess

DSS1access

based onQ.699

Q.1601/2

Q.1912.1

BICC

Q.686 andQ.690

Q.675 andQ.694

Q.686 andQ.695

Q.667 andQ.692

C5

Q.699

Q.1912.1

R1

R2

TUP

INAP

CSF-N

half callhalf call



86

and ATM, in that signalling messages do not need to beacted upon by all network elements in order for a user planecommunication to take place. If the gateways orinterworking points can exchange IP addresses (includingport numbers), then the IP network can route the user planepackets between the two gateways. This is sufficient for abest-effort service; however, an IP network that provides alevel of guaranteed service must act upon any request for aconnection. Since BICC is only concerned with reusingexisting protocols within a network based on IPtechnologies, an assumption has been made concerning theprovision of quality of service. A request for a connectionsimply allocates the bandwidth at the gateway that receivesthe request. Also, IP networks do not automatically set upbi-directional communications and to provide this (vital forconversational speech) a flow of information in eachdirection is required. Fortunately, this exchange ofinformation can be very simple — the exchange of the IPaddresses and port numbers, plus some information on thetype of media required, is all that is needed.

In IP networks utilising SIP [6], the informationconcerning the media is defined separately in the sessiondescription protocol (SDP) [4]. Although this is referred toas a protocol, it is really only the definition of the format ofthe data (and its meaning) that can be exchanged. SDPspecifies no messages and is therefore carried by SIP. Inorder to make BICC as compatible as possible with SIP-based networks, this approach was also adopted. The BICCcall control messages have been extended to (optionally)carry the SDP media information. This information isderived at the MMSF (see section 4.2) and must be carriedby the CBC (H.248) interface vertically to the BICC callcontrol and then is passed horizontally as informationtunnelled within BICC. This feature allows SDPinformation to be exchanged to ‘open up’ the user planecommunication, without the BICC recommendationneeding to redefine all the information specified in SDP. Itis referred to as a tunnel, because the BICC protocol doesnot inspect, check or understand the information it passes.

To allow the tunnelling mechanism to be generic, ITU-Thas produced a separate recommendation defining a headerat the start of the tunnelled information to identify theprotocol and a version number. The version number allowsfuture generic capabilities to be included (such assegmentation and re-assembly).

7.3 BICC use of H.248 and the Megaco protocol

The original intention of the BICC CS2 work was to re-use existing signalling protocols. When considering theCBC, the vertical interface, the obvious candidates wereH.248 and the Megaco protocol. Since there was no desireto restrict the work to a single protocol, either was allowed.There was, however, a fundamental problem — the need forBICC information to be exchanged between the CSF and

BCF. This information included the tunnelling informationas well as some BICC-specific information. The solutionwas to use the generic procedures of H.248 or Megaco as faras possible and then to extend the functionality by defininga new package. One of the more interesting aspects of thiswork has been to define a package that is initiated solely bythe BCF. Further information on H.248 or Megaco can befound in Rosen [7].

7.4 Signalling transport

An important aspect of any architecture is the ability totransport signalling messages between peer entities. Thegoal of BICC was to use whatever already exists, allowingan adapted ISUP to be ‘grafted’ on to new networktechnology. The signalling transport therefore had toprovide BICC with exactly the same services that ISUPreceives from the lower layer signalling transport, i.e. SS7message transfer part level 3 (MTP3) primitives. On theother hand, it must be deployed in networks that do notimplement SS7 (or only adaptations and emulation of SS7).Reconciling these two apparently disparate requirements,without specifying new signalling transport mechanisms foreach network technology to be supported, was achievedusing signalling transport converters as shown in Fig 11.The signalling transport converters document theprocedures and mapping to adapt the generic primitivesdefined between ISUP and MTP3 on to specific primitivesfor the particular signalling transport.

A number of converters were documented (rather thanspecified), showing how the ISUP to MTP3 primitives wereto be adapted to provide the same service over alternativetransports. Since all of the interfaces were internal, thespecification was largely an informative documentationtrick. The supported signalling transports are: MTP3,MTP3B, SSCOP (including multi-link), SCTP and M3UA.

callcontrol

signalling

callcontrol

signalling

signallingtransportconverter

signallingtransportconverter

signallingtransport

signallingtransport

call controlsignallingmessages

genericprimitives

genericprimitives

specificprimitives

specificprimitives

primitives primitives

Fig 11 Signalling transport architecture.



87

8. BICC time-scales

Bearer-independent call control was first brought intoITU-T as a concept for supporting narrowband

services over ATM AAL1 in November 1998. The workwas properly started in March 1999 and the first approvalstep completed in December 1999, with final approval forpublication in June 2000. This is something of a record forthe ITU, especially in the area of signalling (Study Group11). The CS2 activity started in February 2000 and the firstapproval step was completed in December 2000, with finalapproval expected by the end of June 2001. The pace of thework has surprised many people outside of the ITU-T, anddemonstrates a willingness to move into a new pattern ofworking that is more responsive to the needs of industry.

9. Relationship between BICC and ETSI TIPHON

BICC provides an architecture designed for providingnarrowband services utilising an IP network, but there

has also been other more general work on voice over IP. Inparticular, ETSI TIPHON has produced a generalisedarchitecture for the support of voice over IP. The followingdifferences are summarised from the ETSI TIPHON andBICC documents:

• the CSF entity in BICC performs call control functionssimilar to the CC layer in the TIPHON architecture(H.225/SIP) and in addition the codec negotiation

procedure that is specified as part of the BC layer in IPnetworks (H.245/SDP),

• the BCF entity performs functions similar to the BClayer (except codec negotiation) and part of the MClayer in the TIPHON architecture — this refers to theMC actions for transport signalling like addressallocation, codec selection and QoS control (delay,bandwidth, etc),

• the MMSF entity performs the media mapping andswitching actions as part of the MC layer.

The physical grouping of functions in a VoIP networkand a BICC network mainly differs with regard to thepositioning of the bearer control functionality, as shown inFig 12.

10. Open issues

• BICC makes a major assumption about the quality ofservice that the underlying network can really deliver,

• interoperability between H.248 with the BICCpackages (CBC interface) and the BICC call controlprotocol is not defined in sufficient detail,

Fig 12 Mapping between the ETSI TIPHON architecture and the BICC architecture.

SE

SC

CSF

CC

BC BCF

MCF

MMSFMC

IN

RMRM

call servingfunction

bearer controlfunction

media controlfunction and

media mapping/switchingfunction

services

servicecontrol

callcontrol

bearercontrol

mediacontrol

TIPHON BICC

packet transport/core network

CCU

BIWF

MGC

MG

The following list provides an overview of topics thatmay be addressed in future capability sets of BICC:



88

• BICC interworking with DSS1 has not been fullydefined — the interworking is achieved by inter-working BICC with ISUP and ISUP with DSS1,

• supplementary service support that results in multiplebearers is not adequately covered,

• interworking with intelligent networks — INAP CS3 issupported by BICC and to remain backwardscompatible, this functionality will need to be added toISUP,

• interworking BICC with SIP, as an access signallingprotocol is not defined,

• network planning and dimensioning rules for IPsignalling networks are not defined,

• enhanced bearer management, e.g. using RTCPreports, have not been defined.

11. Conclusions

References

1 Griffiths J M: ‘ISDN explained’, John Wiley & Sons Ltd (1990).

2 Wisely D R: ‘SIP and conversational Internet applications’, BTTechnol J, 19, 2, pp 107—118 (April 2001).

3 ITU-T Recommendation Q.2630.1: ‘AAL Type 2 Signalling Protocol(Capability Set 1)’, (December 1999).

4 IETF: ‘RFC 2327 — SDP Session description protocol’, (April 1998).

5 Travers G and Swale R P: ‘International standards for VoIP’, BTTechnol J, 19, No 2, pp 56—65 (April 2001).

6 IETF: ‘RFC 2543 — SIP: Session initiation protocol’, (March 1999).

7 Rosen B: ‘VoIP gateways and the Megaco architecture’, BT Technol J,19, 2, pp 66—76 (April 2001).

This paper has provided a comprehensive introduction tothe bearer-independent call control. It provides a

complete network solution to fully provide all of theexisting PSTN/ISDN services into networks utilisingtechnologies other than circuit switched. While there hasbeen considerable work on SIP to try to emulate PSTN/ISDN services, BICC offers an immediate solution to publicnetwork operators with a large customer base.

A further advantage of BICC could be that it will enableSIP to develop independently of the current circuit-switchedservices, and therefore more efficiently provide excitingnew communications possibilities without being restrictedby legacy technology and services.

Dick Knight joined BT’s Circuit Labs as anapprentice in 1971 and moved to theResearch Centre in 1979. He worked onSystem X development until 1986, when hewas made responsible for the software toimplement a programmable ISDN signallingdesign acceptance tester. From 1990 to 1993,he worked on a variety of developmentprojects, including the implementation of aprotocol to collect network managementinformation for the Jetphone Network. From1993 to 1994 he moved on to broadbandsignalling design by managing thecollaborative RACE MAGIC project on

behalf of twelve European companies. Following this he supported a varietyof broadband initiatives, and in 1996 designed and patented an applicationprotocol to collect information such as burglar alarms over the ISDN Dchannel packet access. He has continued to work on various aspects ofsignalling, and represented BT at ETSI and occasionally ITU-T until 1998.He then moved to the BT Standards Co-ordination unit, to co-ordinate allaspects of ATM signalling. In 1999 he accepted the challenge of the BICCwork and was appointed ITU-T Study Group 11 Co-Issue Manager forBICC. Earlier this year his role was changed to joint ‘special rapporteur’ forBICC. He now undertakes the role of standards co-ordination for all aspectsof voice over IP and represents BT at IETF, as well as ITU-T Study Group11, where he is now vice-chairman of the requirements working party, andtasked to co-ordinate BICC requirements and protocols.

Steve Norreys joined BT in 1989 aftergraduating from Middlesex Polytechnic witha BEng degree in Electronic EngineeringDesign and Production. His early work in BTwas in project management in the repair andprovision divisions which included the set-upof the field office managers, and theproduction of the London engineeringprocedures handbook. He joined thesignalling standards team in 1994 where hewas responsible for the development, andinfluencing, of the national and internationalstandards for N-ISUP. He was the editor ofthe formats and codes section for the PNO-

ISC Spec007 UK interconnection specification, and is the editor of the ETSIISUPv4 set of specifications. Recently he was appointed as the rapporteurfor the BICC protocols and the associate rapporteur for all narrowbandsignalling protocols in ITU-T Study Group 11.

Juan Harrison joined BT in 1975 aftergraduating from the University of Cambridge.His early experience was gained in theLondon telephone networks. Since 1985 hehas worked in BT core PSTN/ISDNsignalling, initially concentrating on ISDNaccess protocols and then later on internodalprotocols. This work has included someITU-T and ETSI international standardsparticipation, but has principally been con-cerned with implementing internationallystandardised signalling interfaces (DSS1 andISUP) in the BT core network. Currently he isstudying the signalling aspects of introducing

into the BT core PSTN/ISDN a network architecture based on ATM bearertechnology.

BICN

Documents

Transcript of BICN