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 the
core technology. This paper discusses the need for PSTN replacement with IP, and compares some of the signalling and call
control options currently being progressed in standards bodies. The bearer-independent call control (BICC) under
development in the ITU is explained in greater depth, covering the requirements, functional modelling, information flows
and protocol aspects. The paper concludes with the current open issues and time-scales for the standardisation of BICC.

1.

Introduction

he patterns of telephony traffic in the networks run by

public network operators (PNOs) have changed
drastically over the last five years. Communications
methods have changed and the demand for access to the
Internet seemingly grows daily. Throughout the year 2000
many PNOs have reported that the Internet and related IP
traffic has surpassed, in simple bandwidth, the demand for
traditional telephony traffic.
It is easy to forget, however, that the volume of nonInternet telephony traffic also continues to grow. Better
marketing information enables personalised direct telesales,
and the enormous growth in mobile telephone sales both
contribute to the demand for telephony-type services. The
telephony growth, however, is small (about 35% per
annum, depending on statistics and network operator)
compared to the phenomenal growth in Internet and IPrelated traffic (anything from 100% to wildly imaginative
figures exceeding the worlds production capabilities).
The Internet Engineering Task Force (IETF) is the
standardisation body charged with developing protocols for
the Internet, and they have made considerable progress in
specifying protocols to enable the packetisation of speech.
Voice over IP is a much abused term, but in this paper is
understood to be the ability to support on demand real-time
conversational speech communication. A major factor in the
development of the protocols is the commercial
opportunities offered by new services integrating real-time
media (including voice) and data.
Recently, PNO have faced a choice in the development
of networks to leave the existing, regulated switched
circuit network (SCN), also known as the time-division
multiplex network (TDM), frozen in its current state, and
start to deploy a new network, better suited to IP-based
terminals, outside the constraints of regulation and offering
the potential of new services with faster deployment, and at

lower costs. If the demand for telephony was not also

growing, this strategy might have been adopted; however,
many TDM networks are running out of switching and
transmission capacity.
First conceived in the early 1970s, integrating voice and
data to provide a single, comprehensive, multi-purpose
communications network [1] offered a solution for PNOs.
Reduced operating costs from simpler network and service
management still provide the rationale for integration today.
The IETF began work on voice over IP (VoIP) as a
means of supporting just another media type to be
transferred using the Internet. Adding the emulation of
existing public switched telephone networks (PSTNs) or
integrated services digital networks (ISDNs) was a later
enhancement. The use of the session intiation protocol (SIP)
in this context is covered elsewhere [2]. The IETF approach
has been to specify enhancements to SIP for the basic call
(and a few selected supplementary services). Additional
services and intelligent network (IN) support are currently
being worked on and can be expected in the future.
2.

Overview and scope of bearer-independent call

control

hile the IETF are the prime standardisation body for

the Internet and general IP-related protocols, the
international standards organisation with the greatest
expertise and experience in telephony is the International
Telecommunications Union Telecommunications
Standardisation Sector (ITU-T). It was the ITU-T (formerly
the CCITT) that standardised the main signalling protocol
for telephony networks integrated services user part
(ISUP) as part of Signalling System No 7 (SS7). ITU-T
looked at the work that the IETF were undertaking on VoIP
and the strategy for PSTN/ISDN replacement.
BT Technol J Vol 19 No 2 April 2001

77

BEARER-INDEPENDENT CALL CONTROL

The ITU-T took a very simplistic view on PSTN/ISDN
replacement if you try to emulate existing services using
a new protocol the result will not be an identical service.
Even more drastic was their opinion that nothing less than
100% of the existing services should be supported in any
new technology that intends to replace the TDM network
and support existing customers. This strategy has considerable merit, since it does not seem a wise strategy to take
services away from customers, only to re-instate them again
at some point in the future. Telecommunications customers
purchase service, not technology, from their network
operator. The service that they purchase is very much richer
than simple voice communication it is an intricate set of
complex services available for a very simple terminal that
operates to provide access to global communications. Even
within the existing TDM network, there are instances of
service interactions that fail due to incompatibilities
between implementations of ISUP, and the success of
emulating all of the services, at day one, in a different
technology and using a different signalling system was seen
as doubtful by many network operators active in the ITU-T.
This simple view of replacing the technology
underlying the existing telecommunications networks was
given further impetus as TDM networks began to reach
their design capacity, and network operators were unwilling
to add further investment in TDM-based technology. As the
demand for new TDM switches (exchanges), and the need
for new services to be added to existing TDM networks,
fell, the cost of TDM switches grew. The immediate issue
of relieving the capacity problem needed a solution that
would be compatible with the longer term aims of the
network 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 ITUT began work on defining an ISUP derivative that would be
100% compatible with the existing networks, but could
operate in any environment that could transport voice with
reasonable quality. The term that they coined for this
protocol was bearer-independent call control BICC.
The scope of this new work was severely limited it
had to:

78

be based on ISUP, to be fully compatible with existing

services,
be independent of the underlying technology,
reuse existing signalling protocols to establish the
communications within networks.

These restrictions positioned the standardisation work

independent from other standards organisations and with
the single simple goal of PSTN/ISDN replacement. Many
standards bodies have begun work with a very simple goal
only to be distracted along the way with new ideas and
aspirations. The success of BICC has been a dogged
determination to remain within the existing scope and not to
BT Technol J Vol 19 No 2 April 2001

extend it to cover such exciting features as multimedia

support. One single enhancement, beyond existing ISUP
capabilities, was added better support for mobile calls.
Many of the worlds fixed networks provide the
interconnect for mobile calls, and one of the main causes of
loss of speech quality for mobile-to-mobile calls is the
conversion to the fixed network voice coding schemes and
back again (transcoding). The ability to signal codec usage,
and to negotiate the best codec to use for a particular call
could easily be added without compromising the
interworking with ISUP, and therefore the backwards
compatibility.
The goal of BICC was simple, and the starting point was
to take ISUP and determine which parts were not applicable
to alternative technologies, and to add to ISUP only features
to enable connections to be established by the new
technology. Three technology types were identified for
voice transport: ATM AAL1, ATM AAL2 and IP. Since
many network operators had already deployed networks
with these technologies, the signalling systems that could
establish connections across these technologies were
identified as being:

the ATM Forum UNI4.0 and ITU-T DSS2 for access

signalling in ATM,
ITU-T B-ISUP, ATM Forum PNNI and AINI for core
network signalling in ATM,
AAL Type 2 signalling [3] as a true bearer control
protocol in ATM,
SDP [4] for IP networks.

This was felt to be a considerable task to achieve in one

go, and with the pressure from network operators for a
short-term solution to the capacity shortage problem, the
standardisation work was split into two capabilities
ATM for the short-term problem and the addition of IP for
the longer term. It should be noted that IP was always seen
as the target, and that the ATM work would merely be a step
along the way.
3.

BICC architecture

he starting point for the BICC architecture was to

assume that calls would enter (ingress) and exit (egress)
the new network technology through interface serving
nodes (ISN). More generally, a serving node (SN) is a point
in the network that provides the functionality for existing
PSTN/ISDN services. Networks tend to grow from the
centre outwards, since it is pointless to provide functionality
at one access gateway that cannot be supported elsewhere.
The ISN initially had to provide a signalling interface
between the narrowband ISUP and a peer ISN, as shown in
Fig 1.

BEARER-INDEPENDENT CALL CONTROL

N/B exchange

ISN
ISUP

ISN
BICC

ISUP - BICC
I/W

ISUP - BICC
I/W

ISUP

connection signalling
IWU

IWU

new network
(user plane connection)

TDM
connection
Fig 1

TDM
connection

Initial BICC architecture.

This simple architecture, although realistic, does not

provide any flexibility. In a large network the
interconnections are much more flexible, with core network
nodes to spread traffic evenly across the network. This
initial scenario also would not prove that a robust and
generic standard was being produced, since BICC would
only interface between ISUP and itself. A more realistic
scenario allows the interconnection with other licensed
operators (OLOs), which is conceptually performed at a
PSTN gateway. Retaining the PSTN naming conventions,
this new node was named a gateway serving node (GSN). It
provides connectivity between two BICC networks and
interconnection consists of a pair of GSNs communicating
via a simple transmission link. Although this is not
necessarily exactly how network operators perform network
interconnection, it is a simple model that is sufficient for
standardisation.
If two network operators can interact, then it should also
be possible for a single network operator to provide PSTN/
ISDN services at a node within a network, as a point of
flexibility. This node is similar in function to a transit
exchange, and was named the transit serving node (TSN).
Fig 2 shows the ISN, TSN and GSN in a simple
configuration.

Figure 2 also shows that account must be taken of all

types of network technology. ATM, recognised as the shortterm solution for relieving capacity, uses intermediate
switches set up by signalling. These nodes are termed bearer
relay nodes (BRN), and not all network technologies need
these nodes.
One of the key requirements of BICC was to fully
support 100% of the narrowband services on first
deployment, and this clearly includes the services derived
from intelligent networks. Intelligent network services are
often provided by a transit exchange, on behalf of a local
exchange. In some smaller networks (not BT), it even
makes sense to provide a single node that offers access to
IN. Additionally, in IP networks, it is not necessarily very
efficient to provide, at a TSN offering IN access, conversion
of the user plane packets through the TSN. This type of
scenario occurs (for example) where charge card services
are provided by IN. The initial number dialled takes the call
as far as an IN special resource (located at a TSN), which
then collects further digits providing charge card
authorisation and destination number. The call is then
routed from the TSN but optimisation could occur if the
TSN was allowed to migrate to a node that supported the
BICC signalling, but no longer had the user plane present.

ISN

TSN

GSN

GSN

ISN

ISUP - BICC
I/W

BICC

BICC

BICC

ISUP - BICC
I/W

new
network
IWU

BRN
(Sw)

IWU

IWU

IWU
BRN
(Sw)

BRN
(Sw)

IWU

new network

Fig 2

79

BICC serving nodes.

BT Technol J Vol 19 No 2 April 2001

BEARER-INDEPENDENT CALL CONTROL

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

Requirements

he requirements for the signalling protocols are derived

from the services to be supported and the functional
modelling. Functional modelling decomposes network
functionality to logical entities and the information to be
exchanged by the entities to achieve the services. The
functional modelling in BICC builds upon the network
architecture to produce a conceptual model and the
interactions between the functions in the model.
4.1

Service requirements

Since BICC must support all existing narrowband calls,

the service requirements are based upon the services that
Table 1
ITU-T ISUP 2000 Function/service
Basic call
Speech/3.1 kHz audio
64 kbit/s unrestricted
Multi-rate connection types
N 64 kbit/s connection types
en bloc address signalling
Overlap address signalling
Transit network selection
Continuity check
Forward transfer
Simple segmentation
Tones and announcements
Access delivery information
Transportation of user teleservice information
Suspend and resume
Signalling procedures for connection type allowing
fallback capability
Propagation delay determination procedure
Enhanced echo control signalling procedures
Simplified echo control signalling procedures
Automatic repeat attempt
Blocking 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 interexchange circuits
Reset of circuits and circuit groups (in Q.BICC, circuits = CIC which is equal to the
CCA-ID)
Receipt of unreasonable signalling information
Compatibility procedure
Temporary trunk blocking
ISDN user part signalling congestion control
Automatic congestion control
Interaction between N-ISDN and INAP
Unequipped circuit identification code (in Q.BICC,
CIC = CCA-ID)
ISDN user part availability control
MTP pause and resume
Over length messages
Temporary alternative routeing (TAR)
Hop counter procedure
Hard-to-reach
Calling geodetic location procedure

80

Generic signalling procedures

End-to-end signalling pass along method

BT Technol J Vol 19 No 2 April 2001

ISUP supports. These are defined in Q.761 in tabular form.

The BICC service requirements were derived by taking this
table and determining which ISUP services were not
applicable in non-narrowband technology networks. This
removes those services that relate more to the
establishment, control, maintenance and release of the
circuit within TDM switches, and the TDM transmission
path between the switches (see Table 1).
4.2

Functional model

The architecture for managed IP networks supporting

real-time services is built around the concept of media
gateways (MGs) that provide conversion of user plane
communications from one format (e.g. TDM) to another
(e.g. IP). The control of these MGs is then performed by
media gateway controllers, providing a split of
responsibilities between two separate physical units. Since
it is highly desirable that BICC can co-exist in the same
environment, the functional model first separates the

ISUP services supported by BICC.

Applicability to BICC

Required
Required
Required
Required
Required
Required
National Option
Not Required
Required
Required
Required
Required
Required
Required
Required
Required
Not Required
Required
Required
Required

National Option
Required

Not Required
Required

Required
Required
Not Required
Required
Required
Required
National Option
Not Required
Required
Required
Required
Required
Required
Required

Required

ITU-T ISUP 2000 Function/service

End-to-end signalling SCCP connection
orientated
End-to-end signalling SCCP connectionless
Generic number transfer
Generic digit transfer
Generic notification procedure
Service activation
Remote operations service (ROSE) capability
Network specific facilities
Pre-release information transport
Application transport mechanism (APM)
Redirection
Pivot Routeing

Supplementary services
Direct-dialling-in (DDI)
Multiple subscriber number (MSN)
Calling line identification presentation (CLIP)
Calling line identification restriction (CLIR)
Connected line identification
presentation (COLP)
Connected line identification
restriction (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 supported]
Global virtual network service (GVNS)
International telecommunication charge
card (ITCC)
Reverse charging (REV)
User-to-user signalling (UUS)
Additional functions/services
Support of VPN applications with PSS1
information flows
Support of number portability (NP)

Applicability to BICC

Required
Required
Required
Required
Required
Required
Required
Required
Required
Required
Required
Required

Required
Required
Required
Required
Required
Required
Required
Required
Required
Required
Required
Required
Required
Required
Required
Required
Required
Required
Required
Required
Required
See Note

Required
Required
Required
Required

Required
Required

BEARER-INDEPENDENT CALL CONTROL

generalised serving node into portions that can be mapped
on to an MG/MGC architecture. Requirements for VoIP
networks have been derived in the ETSI Project TIPHON
[5], and other work has been performed in the Multiservice
Switching Forum. The work of both of these groups was
taken into account in deriving the functional model, which
allows a physical split between the call and bearer control,
as well as the more general split between control
functionality and the media gateway. Figure 3 shows the
basic split of functionality. The call serving function (CSF)
provides the BICC procedures on a per-call basis. The
bearer control function (BCF) provides a point of flexibility,
and could be considered to be drawing upon functionality in
more general-purpose media gateway controllers. The
simple media gateway functions (without any control
functionality) is provided by the media mapping and
switching function (MMSF).
Since the BICC standardisation concentrates on the
requirements to support existing narrowband services
utilising broadband technology, the BCF and MMSF are
logically grouped together to form a bearer interworking
function (BIWF). The BICC architecture allows for the
interface between the BCF and MCF to be open (the BMC
interface), but the split of functionality between the BCF
and MMSF is not considered to be the responsibility of the
BICC standardisation group.

CSF
CBC
interface
B-IWF
1
Fig 4

B-IWF
2
Control of multiple B-IWFs.

The requirements for supporting mobile applications

have also been incorporated, and this requires multiple
CSFs to control a single B-IWF as shown in Fig 5. The
reasoning for this is to enable a call and bearer to be
progressed to the mobile network, and the call only to be
progressed within the mobile network to the terminal. At
this point, tones may need to be applied, under the control
of the call server in the mobile network, but implemented by
the existing B-IWF.

BICC CS2

CSF

CBC
interface

CSF
1

CSF
2

CBC
interface

CBC
interface

Fig 5

B-IWF

Control of B-IWF by multiple CSFs.

CCU
CBC

bearer control
protocol

BCF
BCU
BMC

5.

MCF
bearer
(user plane)

MMSF
BIWF
MGU

physical unit

Fig 3

Figure 6 shows a simplified functional model. It should

be noted that BICC CS2 also supports all of the
functionality of CS1, and therefore a TSN is also supported,
but this is not shown. Also not shown is the support for
access networks, which is an integral part of the ISUPDSS1 interworking, and the IN functionality.

function

Decomposed CS2 serving node.

A more general architecture allows a single call server

to control multiple media gateways (MGs), and this is
reflected in the BICC functional model as shown in Fig 4.

BICC CS1

uring 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 it
has always been recognised by the designers of BICC that it
should be both signalling transport and bearer transport
independent, in order to provide a meaningful and useful
CS1 package in the time-scales allowed, the initial
capability set work focused on a subset of BICC
requirements. This subset was selected by reference to the
immediate requirements of certain network operators and
equipment implementors, but care was taken to prevent
short-term expediency limiting the scope of future BICC
capabilities. In February 2000, BICC CS1 work was
completed and formal ITU-T approval was given in June
2000.
BT Technol J Vol 19 No 2 April 2001

81

BEARER-INDEPENDENT CALL CONTROL

call and bearer
signalling
e.g. DSSI

call and bearer

signalling
e.g. ISUP
BICC
CSF-C

CSF-N

CSF-N

CSF-G

CSF-G

BCF-G

BCF-G

BCF-J

bearer
signalling

BCF-N

B-IWF

B-IWF

B-IWF

router

B-IWF

GSN

GSN

CMN

bearer
signalling

BCF-N
B-IWF

router

ISN

ISN

bearer
(user
communication)

bearer
(user
communication)
Fig 6

5.1

BICC CS2 simplified functional model.

What does BICC CS1 offer?

BICC CS1 is designed to allow a large incumbent ISUPbased network operator to migrate from using MTP3
signalling networks and TDM bearer networks towards
alternative packet-based technologies. The BICC CS1
model allows an ATM segment to be inserted into an
existing ISUP narrowband network without loss of ISUP or
IN features and services (see Fig 7).

for example, mobile services. Transcoder-free operation

improves speech quality by avoiding unnecessary
transcoding 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 for

BICC CS1 is shown in Fig 8. It can be seen that this is a
subset of the comprehensive model used for BICC CS2, see
Fig 6.

PSTN/ISDN
ISUP call + bearer

PSTN/ISDN
ISUP call + bearer

PSTN/ISDN
ISUP
call/bearer
signalling

BICC signalling
ISN

ISN
separated bearer

ISN

formal primitive
interface

BICC
CSF

ISUP service transparency

STC
Fig 7

BICC segment inserted into an existing PSTN/ISDN.

The BICC protocol is very closely based on the ISUP

protocol. It has been designed to interwork naturally with
narrowband ISUP taking full benefit from its strong forward
and backward compatibility features. This means that it has
inherited all the narrowband ISUP features and services that
are applicable in a separated bearer environment.
Furthermore, non-BICC relevant ISUP signals can be
transferred transparently between two PSTN/ISDN
connected by a BICC segment without loss of services
offered.

82

BICC CS1 has also introduced new optional codec

negotiation and codec modification capabilities not
defined in narrowband ISUP. These will allow BICC to
offer transcoder-free operation in core networks supporting,
BT Technol J Vol 19 No 2 April 2001

informal primitive
interface

BICC
signalling
bearer control
signalling

BCF
bearer

bearer
BIWF

Fig 8

Functional components of the ISN as used for BICC CS1.

The call service function (CSF) performs three

functions:

interfaces to the traditional ISUP signalling in the

TDM domain,
provides a generic interface to the signalling transport
specific converter (STC),

BEARER-INDEPENDENT CALL CONTROL

provides a generic (but loosely defined) interface to the

bearer interworking function/bearer control function
(BIWF/BCF).

The signalling transport converter (STC) maps the

generic BICC on to a specific signalling transport. For
BICC CS1, STCs are defined by ITU-T for the following
signalling transports:

MTP3/3B,

SSCOP,

SSCOPMCE.

AAL1 using DSS2 signalling,

AAL1 using B-ISUP signalling,

AAL2 using AAL2 (CS1) signalling.

Furthermore, the ATM Forum (ATM-F) has defined

mapping of BICC on to:

AAL1 using ATM-F UNI signalling,

AAL1 using ATM-F PNNI signalling,

AAL1 using ATM-F AINI signalling.

How and where is BICC CS1 specified?

BICC CS1 is specified as a delta to ISUP2000. The

ISUP2000 base text is defined by:

Descriptions of BICC operating with ITU-T bearer

control signalling systems are in ITU-T supplements.

TRQ.3000 (operation of BICC with DSS2),

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

The BIWF provides interworking of different bearer

technologies (e.g. TDM to ATM). The BCF provides bearer
specific signalling to establish new bearers for use by BICC
calls. A BICC CS1 CSF controls the BIWF/BCF through a
generic, but loosely defined, primitive interface. To allow
for adequate interoperability between the ISN implementations of different manufacturers, it is necessary to describe
BICC mapping to/from specific bearer network
technologies. For BICC CS1, mappings on to the following
bearer network interfaces has been defined by ITU-T:

5.3

The specific application of the BICC/ISUP application

transport mechanism (APM) used in BICC to support the
separated bearer procedures is defined in ITU-T
Recommendation Q.765.5 (2000).

ITU-T Recommendations Q.761 to 764 (including an

Addendum to Q.762 and Q.763),
ITU-T Recommendation Q.765.

The BICC delta is defined in ITU-T Recommendation

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

TRQ.3020 (operation of BICC with B-ISUP for

AAL1).

The description of BICC operating with ATM-F bearer

control signalling systems is in AF-CS-VMOA-0146.000
(operation of BICC with SIG4.0/PNNI1.0/AINI).
6.

Call flows

igure 9 shows a simplified version of the call flows and

the interactions between the vertical and horizontal
interfaces. They also show how the BICC environment
interacts with the PSTN/ISDN environment.
The incoming IAM message is received at the
originating ISN and the outgoing IAM is generated and sent
out 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 bearer
addressing information, the CSF will then notify the BIWF
of the request for a bearer and the bearer addressing
information. The BIWF will then send back an indication
once the bearer has been established, and the CSF will
forward this information in an APM message to the
succeeding node.
The actions at the destination CSF are to notify the
preceding node, in an APM message, of the addressing
information required to set up a bearer. If this node is a TSN
it will then generate and send out an IAM with a COT on
previous indication plus its BNC characteristics
encapsulated in an APP parameter and await an APM with
the bearer addressing information. If this node is the
destination ISN, the same action to send back an APM
message applies, but the outgoing IAM with COT on
previous indication is sent to the ISUP call control in the
TDM network.
Further APM message exchanges are optional
depending on whether codec negotiation or tunnelled bearer
information is deployed.
BT Technol J Vol 19 No 2 April 2001

83

BEARER-INDEPENDENT CALL CONTROL

ISN-A

TSN

ISUP
CSF-N
SWN-1
BCF-N
(x)

ISUP

CSF-T
SWN-2

BCF-R

ISN-B
BICC

BICC

BCF-R

BCF-N
(y)

CSF-N
SWN-1

SWN-2

BCF-R

BCF-R

BCF-N
(z)

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

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

(BNC characteristics)
APM (Action=Connect Forward, no notification)
(BNC-ID=z1), (BIWF Addr=z)

AAA

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.

Bearer-Setup-Connect
BBB

Bearer-Setup-Connect
Bearer-Setup-Connect

Bearer-Setup-Connect

Bearer-Setup-Connect
Bearer-Setup-Connect
ACM
ACM
ACM
ACM
ANM
ANM
ANM
ANM

Fig 9

Call flow for forward bearer establishment of the backbone network.

The COT message is then sent by the TSN once the

bearer requirements have been met, and a bearer path has
been established between the SNs. The destination ISN
sending out an ISUP COT message completes the call.
The message flows for ACM and answer are the same as
for ISUP.
The release signalling sequences, which are not shown,
are also unchanged from ISUP, although an instruction from
CSF to BIWF is also required to release the bearer.
The backward bearer set up uses the same message
flows except that the bearer characteristics and tunnelling
information are generated at the destination BIWF and
passed back between CSF in the first backward APM.
7.

BICC protocols

7.1

84

BICC protocol in IP networks (CS2)

ICC CS2 call control protocol builds on the work in

CS1 in that the protocol is based upon ISUP, it
includes most of the services supported by ISUP as the
BT Technol J Vol 19 No 2 April 2001

architecture now includes local exchange functionality. The

impact of this has required that the basic call
recommendation, developed in the ITU-T SG11, is now
complete text instead of a delta on the ISUP
recommendation as published in CS1. The recommendations in the basic call series are shown in Table 2.
Any future developments of ISUP will now include new
versions of Q.761 and Q.764 with the definition and layout
of any new parameters and messages documented in
Q.1902.2 and Q.1902.3.
As BICC CS2 includes the local exchange functionality,
it has to support the ISUP supplementary services as well as
the originating and destination exchange functions, e.g.
building the IAM and supporting call diversion. This is
done by interworking the BICC functionality with the ISUP
functionality as illustrated in Fig 10.
Some of the ISUP protocol is not required for the BICC
protocol either because it is a pure ISUP TDM circuit-

BEARER-INDEPENDENT CALL CONTROL

Table 2
BICC
recommendation

BICC basic call recommendation series.

Equivalent ISUP
recommendation

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

control functionality or the service is not supported. So, for

example, the circuit identification code (CIC) has changed
its meaning in a BICC environment to call instance code
and is larger than the ISUP CIC, thereby increasing the
number of simultaneous calls that can be supported by the
protocol (although exchange performance is more likely to
be the limit on the number of calls supported).

A new generic service, bearer redirection, has been

developed in which the bearer is redirected to a new
destination SN but the call is not. This could be deployed in
the BICC network for interworking to an IN service such as
a charge card service where the IN needs to be involved in
the call but the bearer does not, and the call diversion
services could also use this functionality.

The ISUP local exchanges are the nodes which support

the majority of the supplementary services functionality and
as such the BICC local SN will have to emulate this to
support the full PSTN/ISDN services. This has had an
impact on some of the supplementary services, e.g. the call
diversion supplementary service which could take account
of the global call reference and therefore change the service.
Other supplementary services such as conference and three
party calls need to take into account that more than one
bearer could be involved as this has not been resolved
yet, future work may be required.

The other important aspect of BICC CS2 is that it is

supported on an IP bearer and that the bearer control and
call control are separated. The model also allows for one
CSF to control more than one BIWF and for a BIWF to be
controlled by more than one CSF. This means that the
amount of information that has to be carried from the
originating SN to the next SN in the call path has increased.
This is for call/bearer correlation and identification
purposes.

half call

half call

CSF-N
PSTN
access

DSS1
access

based on
Q.699

Q.699

Q.1912.1

Q.1912.1

BICC

C5

Q.686 and
Q.690

R1

Q.675 and
Q.694

R2

Q.686 and
Q.695

TUP

Q.667 and
Q.692

Fig 10

Q.1601/2

BICC signalling interworking architecture.

INAP

A number of bearer set-up procedures for a call have

been included in the BICC signalling procedures to take
into account the differing bearer set-up methods, i.e.
forward, backward and idle bearer. This has increased the
complexity of the signalling procedures, but they are still
based upon the ISUP signalling.
As some of the bearer set-up procedures require a
confirmation that each SN in the bearer path has enabled the
user plane communication, this could result in the
destination 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 procedure
has been included in the BICC environment. The continuity
test of the connection as defined for ISUP is not included
in BICC, but the COT signal has been reused to indicate that
a bearer path has been set up and that the IAM is allowed to
go forward from the BICC environment.
To allow for network optimisation and the support of
mobile telephony a codec negotiation and modification
procedures have been added to the BICC protocol. This
could have an impact upon the conference and three-party
supplementary services where a different codec may have
been negotiated for each call leg.
7.2

IP bearer control protocol

IP networks are fundamentally different from

connection-oriented networks, such as those based on TDM
BT Technol J Vol 19 No 2 April 2001

85

BEARER-INDEPENDENT CALL CONTROL

and ATM, in that signalling messages do not need to be
acted upon by all network elements in order for a user plane
communication to take place. If the gateways or
interworking points can exchange IP addresses (including
port numbers), then the IP network can route the user plane
packets between the two gateways. This is sufficient for a
best-effort service; however, an IP network that provides a
level of guaranteed service must act upon any request for a
connection. Since BICC is only concerned with reusing
existing protocols within a network based on IP
technologies, an assumption has been made concerning the
provision of quality of service. A request for a connection
simply allocates the bandwidth at the gateway that receives
the request. Also, IP networks do not automatically set up
bi-directional communications and to provide this (vital for
conversational speech) a flow of information in each
direction is required. Fortunately, this exchange of
information can be very simple the exchange of the IP
addresses and port numbers, plus some information on the
type of media required, is all that is needed.
In IP networks utilising SIP [6], the information
concerning the media is defined separately in the session
description protocol (SDP) [4]. Although this is referred to
as a protocol, it is really only the definition of the format of
the data (and its meaning) that can be exchanged. SDP
specifies no messages and is therefore carried by SIP. In
order to make BICC as compatible as possible with SIPbased networks, this approach was also adopted. The BICC
call control messages have been extended to (optionally)
carry the SDP media information. This information is
derived at the MMSF (see section 4.2) and must be carried
by the CBC (H.248) interface vertically to the BICC call
control and then is passed horizontally as information
tunnelled within BICC. This feature allows SDP
information to be exchanged to open up the user plane
communication, without the BICC recommendation
needing to redefine all the information specified in SDP. It
is referred to as a tunnel, because the BICC protocol does
not inspect, check or understand the information it passes.
To allow the tunnelling mechanism to be generic, ITU-T
has produced a separate recommendation defining a header
at the start of the tunnelled information to identify the
protocol and a version number. The version number allows
future generic capabilities to be included (such as
segmentation and re-assembly).
7.3

86

BICC use of H.248 and the Megaco protocol

The original intention of the BICC CS2 work was to reuse existing signalling protocols. When considering the
CBC, the vertical interface, the obvious candidates were
H.248 and the Megaco protocol. Since there was no desire
to restrict the work to a single protocol, either was allowed.
There was, however, a fundamental problem the need for
BICC information to be exchanged between the CSF and
BT Technol J Vol 19 No 2 April 2001

BCF. This information included the tunnelling information

as well as some BICC-specific information. The solution
was to use the generic procedures of H.248 or Megaco as far
as possible and then to extend the functionality by defining
a new package. One of the more interesting aspects of this
work has been to define a package that is initiated solely by
the BCF. Further information on H.248 or Megaco can be
found in Rosen [7].
7.4

Signalling transport

An important aspect of any architecture is the ability to

transport signalling messages between peer entities. The
goal of BICC was to use whatever already exists, allowing
an adapted ISUP to be grafted on to new network
technology. The signalling transport therefore had to
provide BICC with exactly the same services that ISUP
receives from the lower layer signalling transport, i.e. SS7
message transfer part level 3 (MTP3) primitives. On the
other hand, it must be deployed in networks that do not
implement SS7 (or only adaptations and emulation of SS7).
Reconciling these two apparently disparate requirements,
without specifying new signalling transport mechanisms for
each network technology to be supported, was achieved
using signalling transport converters as shown in Fig 11.
The signalling transport converters document the
procedures and mapping to adapt the generic primitives
defined between ISUP and MTP3 on to specific primitives
for the particular signalling transport.
call control
signalling
messages

call
control
signalling
generic
primitives

generic
primitives
signalling
transport
converter

signalling
transport
converter
specific
primitives
signalling
transport

specific
primitives
signalling
transport

primitives

Fig 11

call
control
signalling

primitives

Signalling transport architecture.

A number of converters were documented (rather than

specified), showing how the ISUP to MTP3 primitives were
to be adapted to provide the same service over alternative
transports. Since all of the interfaces were internal, the
specification was largely an informative documentation
trick. The supported signalling transports are: MTP3,
MTP3B, SSCOP (including multi-link), SCTP and M3UA.

BEARER-INDEPENDENT CALL CONTROL

8.

BICC time-scales

procedure that is specified as part of the BC layer in IP

networks (H.245/SDP),

earer-independent call control was first brought into

ITU-T as a concept for supporting narrowband
services over ATM AAL1 in November 1998. The work
was properly started in March 1999 and the first approval
step completed in December 1999, with final approval for
publication in June 2000. This is something of a record for
the ITU, especially in the area of signalling (Study Group
11). The CS2 activity started in February 2000 and the first
approval step was completed in December 2000, with final
approval expected by the end of June 2001. The pace of the
work has surprised many people outside of the ITU-T, and
demonstrates a willingness to move into a new pattern of
working that is more responsive to the needs of industry.
9.

Relationship between BICC and ETSI TIPHON

the BCF entity performs functions similar to the BC

layer (except codec negotiation) and part of the MC
layer in the TIPHON architecture this refers to the
MC actions for transport signalling like address
allocation, codec selection and QoS control (delay,
bandwidth, etc),

the MMSF entity performs the media mapping and

switching actions as part of the MC layer.

The physical grouping of functions in a VoIP network

and a BICC network mainly differs with regard to the
positioning of the bearer control functionality, as shown in
Fig 12.

ICC provides an architecture designed for providing

narrowband services utilising an IP network, but there
has also been other more general work on voice over IP. In
particular, ETSI TIPHON has produced a generalised
architecture for the support of voice over IP. The following
differences are summarised from the ETSI TIPHON and
BICC documents:

the CSF entity in BICC performs call control functions

similar to the CC layer in the TIPHON architecture
(H.225/SIP) and in addition the codec negotiation

TIPHON
services

10. Open issues

he following list provides an overview of topics that

may be addressed in future capability sets of BICC:
BICC makes a major assumption about the quality of
service that the underlying network can really deliver,
interoperability between H.248 with the BICC
packages (CBC interface) and the BICC call control
protocol is not defined in sufficient detail,

BICC

SE
IN

service
control

MGC

MG

SC

CSF

call
control

CC

bearer
control

BC

BCF

MCF
media
control
MC

MMSF

RM

RM

call serving
function

CCU

bearer control
function

media control
function and
media mapping/
switching
function

BIWF

packet transport/core network

Fig 12

Mapping between the ETSI TIPHON architecture and the BICC architecture.

BT Technol J Vol 19 No 2 April 2001

87

BEARER-INDEPENDENT CALL CONTROL

BICC interworking with DSS1 has not been fully

defined the interworking is achieved by interworking BICC with ISUP and ISUP with DSS1,

supplementary service support that results in multiple

bearers is not adequately covered,

interworking with intelligent networks INAP CS3 is

supported by BICC and to remain backwards
compatible, this functionality will need to be added to
ISUP,

interworking BICC with SIP, as an access signalling

protocol is not defined,

network planning and dimensioning rules for IP

signalling networks are not defined,

enhanced bearer management, e.g. using RTCP

reports, have not been defined.

11. Conclusions

his paper has provided a comprehensive introduction to

the bearer-independent call control. It provides a
complete network solution to fully provide all of the
existing PSTN/ISDN services into networks utilising
technologies other than circuit switched. While there has
been considerable work on SIP to try to emulate PSTN/
ISDN services, BICC offers an immediate solution to public
network operators with a large customer base.
A further advantage of BICC could be that it will enable
SIP to develop independently of the current circuit-switched
services, and therefore more efficiently provide exciting
new communications possibilities without being restricted
by legacy technology and services.

References

88

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

Wisely D R: SIP and conversational Internet applications, BT

Technol J, 19, 2, pp 107118 (April 2001).

ITU-T Recommendation Q.2630.1: AAL Type 2 Signalling Protocol

(Capability Set 1), (December 1999).

IETF: RFC 2327 SDP Session description protocol, (April 1998).

Travers G and Swale R P: International standards for VoIP, BT

Technol J, 19, No 2, pp 5665 (April 2001).

BT Technol J Vol 19 No 2 April 2001

IETF: RFC 2543 SIP: Session initiation protocol, (March 1999).

Rosen B: VoIP gateways and the Megaco architecture, BT Technol J,

19, 2, pp 6676 (April 2001).

Dick Knight joined BTs Circuit Labs as an

apprentice in 1971 and moved to the
Research Centre in 1979. He worked on
System X development until 1986, when he
was made responsible for the software to
implement a programmable ISDN signalling
design acceptance tester. From 1990 to 1993,
he worked on a variety of development
projects, including the implementation of a
protocol to collect network management
information for the Jetphone Network. From
1993 to 1994 he moved on to broadband
signalling design by managing the
collaborative RACE MAGIC project on
behalf of twelve European companies. Following this he supported a variety
of broadband initiatives, and in 1996 designed and patented an application
protocol to collect information such as burglar alarms over the ISDN D
channel packet access. He has continued to work on various aspects of
signalling, and represented BT at ETSI and occasionally ITU-T until 1998.
He then moved to the BT Standards Co-ordination unit, to co-ordinate all
aspects of ATM signalling. In 1999 he accepted the challenge of the BICC
work and was appointed ITU-T Study Group 11 Co-Issue Manager for
BICC. Earlier this year his role was changed to joint special rapporteur for
BICC. He now undertakes the role of standards co-ordination for all aspects
of voice over IP and represents BT at IETF, as well as ITU-T Study Group
11, where he is now vice-chairman of the requirements working party, and
tasked to co-ordinate BICC requirements and protocols.

Steve Norreys joined BT in 1989 after

graduating from Middlesex Polytechnic with
a BEng degree in Electronic Engineering
Design and Production. His early work in BT
was in project management in the repair and
provision divisions which included the set-up
of the field office managers, and the
production of the London engineering
procedures handbook. He joined the
signalling standards team in 1994 where he
was responsible for the development, and
influencing, of the national and international
standards for N-ISUP. He was the editor of
the formats and codes section for the PNOISC Spec007 UK interconnection specification, and is the editor of the ETSI
ISUPv4 set of specifications. Recently he was appointed as the rapporteur
for the BICC protocols and the associate rapporteur for all narrowband
signalling protocols in ITU-T Study Group 11.

Juan Harrison joined BT in 1975 after

graduating from the University of Cambridge.
His early experience was gained in the
London telephone networks. Since 1985 he
has worked in BT core PSTN/ISDN
signalling, initially concentrating on ISDN
access protocols and then later on internodal
protocols. This work has included some
ITU-T and ETSI international standards
participation, but has principally been concerned with implementing internationally
standardised signalling interfaces (DSS1 and
ISUP) in the BT core network. Currently he is
studying the signalling aspects of introducing
into the BT core PSTN/ISDN a network architecture based on ATM bearer
technology.