Download II. bicc overview

Network Resource Reservation in the Next
Generation Networks using BICC as a Call
Control Protocol
Lovre Hribar, Damir Buric, Alen Bulic
Ericsson Nikola Tesla R&D Center, Split, Croatia
[email protected], [email protected], [email protected],
Abstract—Architecture
of
the
next
generation
telecommunication network is based on the separation of
functionality into independent layers: control layer, a
connectivity layer and an application layer. BICC and other
Call Control Protocols share the resources in the
connectivity layer. The connectivity layer handles the
transport and manipulation of user and control data and
comprises transport backbone elements and Media
Gateways. Media Gateways have been introduced to provide
bearer control function and media mapping/switching
functions. Resource reservation for Bearer Independent
Call Control protocol has most important role in the call setup. The paper gives a detailed overview of bearer set-up
procedures in ATM and IP networks based on BICC ITU-T
recommendations.
technology and signaling transport technology used. It is
an extension of Integrated Services Digital Network User
Part (ISUP) protocol and therefore provides a full
transparency of the existing telephony functionality. The
first standardized version of BICC protocol was
Capabilities Set 1 (CS1) but only BICC Capabilities Set 2
(CS2) version gives a true separation of control and bearer
layer and introduction of IP bearer [5]. The physical
separation of the Call Control and Bearer Control allows
physically separate Call Mediation Node (CMN) and
BIWF. Inherent in this separation is the possibility for
BICC CS2 to support the BIWF selection, allowing a
many-to-many relationship between call control servers
and BIWFs.
I.
INTRODUCTION
When two Media Gateways (MGW) need to set up an
communication path over backbone using Asynchronous
Transfer Mode (ATM) or Internet Protocol (IP) as a
technology Fig. 1, they need to obtain and exchange
information about the Bearer Interworking Function
Address (BIWF), Backbone Network Connection
Identifier (BNC-id), IP addresses, port numbers, codecs
that will be used for the speech compression, media
streams, etc. BICC using different mechanism for this
purpose depending on the transport technology used in the
call, but the problems obtaining necessary information and
establishing communication path between two MGWs are
the similar for the both transport technology.
BICC protocol has its own place in the next generation
network as a call control protocol and there is a possibility
for interwork with other call control protocols in such
network [4]. BICC is the call control protocol chosen for
the 3rd Generation Partnership Project Circuit Switched
domain (3GPP CS) Release 4. This paper gives an
overview of the capabilities for the resource network
reservation in the connectivity layer for the MGWs
terminations Fig. 1 in BICC protocol and tries to explain
the conceptual and architectural differences between
different transport technologies used in the call scenario.
Signalling Transport Network
II.
BICC OVERVIEW
A. Network Architecture using BICC
BICC protocol provides the signaling functions required
supporting narrowband Integrated Services Digital
Network (ISDN) services independent of the bearer
LE/TE
ISN-A
CCF
BIWF
BIWFBCF
BCF
CMN
CCF
ISN-B
Call Control Signalling
Bearer Control Signalling
LE/TE
CCF
BIWF
BIWFBCF
BCF
BNC-ID
Backbone Network Conection
Network Bearer Conection (end-to-end)
Figure 1. Network Functional Model
BICC is used as a protocol between Call Service
Functions (CSFs) within
different
nodes
as
originating/destination Service Nodes (SNs) (ISNs
interworking with an access signaling system),
intermediate
national/international
SNs
(TSNs),
incoming/outgoing national/international gateway SNs
(GSNs) and Call Mediation Nodes (CMN). CMNs are
introduced for call routing purposes [6]. They do not have
bearer control function.
B. BICC using ATM as a transport technology
The first version of BICC, BICC CS1 is used in the
ATM based network and it is standardized through ITU-T
Q.1901 specification [9]. The main body of Q.1901
specification defines the protocol at Transit Serving Nodes
and Gateway Serving Nodes. The scope is shown in
Figure 2.
Serving Node (SN)
Call Control Signalling
(BICC Protocol)
Call Service Function (CCF)
Call Control Signalling
(BICC Protocol)
depends as well on outgoing CSF route characteristics and
originating BIWF.
The choice between Forward or Backward set-up,
respectively, is made by the originating BCF and is
indicated in the initial response from the originating BCF.
Also in both scenarios there is a possibility for the
notification for successfully established bearer.
C. BICC using IP as a transport technology
Bearer Control
Signalling
Bearer Control Function
(BCF)
Bearer Control
Signalling
Bearer
Figure 2. Scope of BICC CS1
This specification describes the adaptation of the
narrow-band ISDN User Part (ISUP) for the support of
narrow-band ISDN services independent of the bearer
technology and signalling message transport technology
used. Between Serving Nodes the control of bearers is
provided by other protocols – not specified by the
specification. Three types of Serving Node (SN) are
defined:
•
Interface Serving Node (ISN) – this type of node
provides an interface to circuit switched networks.
•
Transit Serving Node (TSN) – this type of node
provides transit functionality, for call and bearer, within
one network using the BICC protocol.
•
Gateway Serving Node (GSN) – this type of
node provides inter-network gateway functionality, for
call and bearer, using the BICC protocol.
In defining the procedures for BICC at an Interface
Serving Node the specification also defines how BICC
interworks with other protocols.
But the true separation of the Call Control and Bearer
Control was introduction of IP as a transport technology,
BICC CS2 and it is standardized in ITU-T Q.1902
specification [11], [12], [13].
These specifications provide a functional description of
the BICC protocol. Describes the elements of signalling
information used by the BICC protocol and the ISDN user
part and their functions. Also, specifies the formats and
codes of the BICC protocol for the support of narrowband ISDN services independent of the bearer technology
and signalling message transport technology used. It also
specifies ISDN user part messages and parameters
required to support basic bearer services and
supplementary services according to ITU-T Q.761. Where
a message, a parameter, a parameter field or a parameter
field value is not supported by one of the two protocols or
they interpret a code point differently, it is also indicated.
Finally, describes Capability Set 2 (CS2) of BICC basic
call procedures for the support of narrow-band ISDN
services independent of the bearer technology and
signalling message transport technology used.
Depending whether BIWF has been selected prior to
outgoing BICC set-up or after there are two different ways
of bearer connection set-up: Forward and Backward. It
The second standardized version of BICC protocol
was BICC CS2 version that gives a true and fully
separation of control and bearer layer with introduction of
IP as a transport technology [7]. To support IP as a bearer
the BICC along with Call Bearer Control (CBC) protocol
[10] provides a mechanism for the transport of Bearer
Control Protocol information between BIWFs. The
mechanism provides a reliable, sequenced transport on a
per backbone network connection basis when there is no
requirement for intermediate BCF-Rs between the BCFNs to process the tunneled information.
The mechanism used in BICC is so called Tunneling
mechanism and is defined in the Internet Protocol Bearer
Control Protocol (IPBCP) protocol [8]. When IPBCP
protocol information has to be passed from one MGW to
another, it is tunneled from the MGW via the Bearer
Control Tunneling Protocol (BCTP) using Call and Bearer
Control extensions to the call control server, then from the
call control server to the target call control server via the
BICC protocol in the Application Transport Mechanism
(APM) message and finally from the target call control
server to the target MGW via the BCTP protocol over
CBC Fig. 3.
Call Control = BICC
CSF
Signaling transport
CBC
CSF
CBC
Bearer Control = Q.IPBC
BIWF
BIWF
Signaling transport
Figure 3. Tunneling mechanism
The Bearer Interworking Function at the originating SN
makes the decision on use of the Bearer Control
Tunneling mechanism on a per call basis. The CSF shall
inform the BIWF of the possibility of using the Bearer
Control Tunneling Mechanism and the BIWF shall
respond with an indication of whether the Tunnel should
be set up or not.
Bearer Control tunneling shall be used for a call if the
BICC-data primitive associated with the IAM or the first
backward APM message includes the Bearer Control
Tunneling information element set to “tunneling to be
used”. The absence of the Bearer Control Tunneling
information element in the IAM or in the first backward
APM (if “tunneling to be used” was not indicated in the
IAM) specifies that the bearer control tunneling shall not
be used.
The CSF does not process the Bearer Control Protocol
information transported by tunneling mechanism. The
unmodified BCP information is tunneled through the CBC
protocol toward the terminating BIWF. The APM
message is used for transmission of tunneled information
in call control layer.
Depending whether BIWF has been selected prior to
outgoing BICC set-up or after there are two different ways
of bearer connection set-up: Forward and Backward. It
depends as well on outgoing CSF route characteristics and
originating BIWF. The choice between Fast (Forward or
Backward) and Delayed Forward/Backward set-up,
respectively, is made by the originating BCF and is
indicated in the initial response from the originating BCF.
Following the 3GPP standard and its model of core
network BICC CS2 defines its own procedures for
supporting the codec negotiation, mid-call negotiation and
out-of band transport of Dual Tone Multiple Frequency
(DTMF) and tone information. The CS2 version also
supports the bearer redirection capability as well as
procedures for reuse of idle bearers as a network option.
(MPLS) bearer transport technology in a label and a nonlabel switching configuration as a candidate for BICC
CS3, and provided a set of high-level requirements. One
of the main requirement is support of multi-party call
configurations allowing a party to add another party to the
call and its communication capability type 6 or any other,
and release the party that it has added, from the call and its
attachment to the bearer(s).
It is proposed for bearer re-direction to support
establishment of a multi-party service configuration.
According to proposals following information should be
used at CSF selection of BIWF:
 The services required by the call,
 The list of BIWFs which can be used to interface the
peer SN, inter-working with Switched Circuit
Networks,
 Network Interconnect Scenarios minimizing the
number of BIWFs in the connection
 At the succeeding SN, the Bearer Control Unit
Identifier (BCU-ID) of the BCU selected at the
preceding SN.
 Support of multi-media and related services.
D. BICC Capabilities Set 3
Further development of BICC is proposed to be
undertaken, and not to be limited to the existing narrowband ISDN service set. BICC should not compete against
other Call Control Protocols, which is regarded as an
emerging technology. Interworking would be included as
far as existing BICC end terminals could support a
particular service.
BICC standard work is not finished yet and the
following items and contributions are some that are
proposed to be in the BICC CS3 scope [14]:
 The BICC CS3 protocol should support as an
optional procedure the transfer of text-based
Uniform Resource Locator/Uniform Resource
Identifier (URL/URI) naming, complementary to the
existing digit-based (E.164) naming. The transfer of
text-based naming is restricted to the called party for
identification purposes only, not for routing
purposes. Service platform including ENUM
functionality is supposed to map the E.164 telephone
number into a SIP-URL. Reverse ENUM
functionality supposes the reverse mapping.
 It is supposed for BICC to fully support the
advanced CMN call control procedures.
 International Emergency Preference Scheme (IEPS)
support [1].
The call control procedures shall support a mechanism
of relaying CMN exchange data and/or IN data between
the CMN (CSF-G) and the Originating SN using
functionality already provided in SS7:
 A mechanism for relaying recording, exchange,
and/or IN data between an Originating SN and a
CMN with the same network; call routing
 Screening functionality at the CMN (by the CSF-G).
 Support for efficient Uni-cast and Multi-cast
Services transported on various transport
technologies (e.g. ATM, AAL2, IP, etc.) via
communications configuration 6 (i.e. conference
services supported by using a server).
In addition to already supported bearer technology it is
proposed to take Multiple Protocol Label Switching
III.
NEXT GENERATION NETWORK ARCHITECTURE
The telecommunication community is migrating towards
a new network architecture based on horizontal layers [2].
The change in the network architecture introduces new
logical network nodes and also changes the role of
existing nodes in the network. This architecture changes
the current vertically specialized network into a horizontal
layered architecture Fig. 4.
APPLICATION
SERVER
(BICC)
APPLICATION LAYER
APPLICATION
SERVER
(BICC)
TELEPHONY
SERVER
CONTROL LAYER
TELEPHONY
SERVER
CONNECTIVITY
SERVER
CONNECTIVITY LAYER
CONNECTIVITY
SERVER
Figure 4. Horizontal layered architecture
In practice the layering means that different levels in
network hierarchy are separated and communicate over
well-specified interfaces; thus different applications share
resources in the lower level of the network. Ericsson’s
solution for the next generation networks adopts the
layering principles outlined above [3].
The layered Core Network architecture is derived from
the current standards reference model by separating the
control plane functions in the SN from their user plane
functions, thus turning these nodes into Servers and Media
Gateways (Connectivity Servers).
IV.
connection. IAM conveys Application Transport
parameter, which has encapsulated BICC signaling
information BIWF address, BNC-id, and to indicate that
bearer set-up is in the backward direction Fig. 7.
CCF
CCF
CCF
BCF (x)
BCF (Y)
BCF (Z)
IAM
BEARER SETUP PROCEDURES
IAM (Action = Connect forward)
IAM (Action = Connect forward)
IAM
APM (Action = Connect forward,
BNC-ID=z1, BIWF-Address=z)
APM (Action = Connect forward,
BNC-ID=y1, BIWF-Address=y)
A. Bearer Setup procedures in ATM network
In the ATM network bearer setup is propagated using
separate bearer protocol. BICC protocol is used only for
exchanging information about BIWF address and BNCID.
Bearer Setup request (BNC-ID=y1,
BIWF-Address=y)
Bearer Setup request (BNC-ID=z1,
BIWF-Address=z)
Bearer Setup Connect
Bearer Setup Connect
APM (Action = Connected)
CCF
CCF
CCF
BCF (x)
BCF (Y)
BCF (Z)
APM (Action = Connected)
COT
COT
ACM
ACM
ACM
ACM
IAM
IAM (Action = Connect forward)
ANM
ANM
ANM
ANM
IAM (Action = Connect forward)
IAM
APM (Action = Connect forward,
BNC-ID=y1, BIWF-Address=y)
Bearer Setup request (BNC-ID=y1,
BIWF-Address=y)
Bearer Setup Connect
APM (Action = Connect forward,
BNC-ID=z1, BIWF-Address=z)
Figure 6. Forward bearer setup, with notification
Bearer Setup request (BNC-ID=z1,
BIWF-Address=z)
Bearer Setup Connect
COT
ACM
ACM
ACM
ANM
ANM
CCF
CCF
CCF
BCF (x)
BCF (Y)
BCF (Z)
COT
ACM
ANM
ANM
IAM
IAM (Action = Connect backward,
BNC-ID=x1, BIWF-Address=x)
Bearer Setup request (BNC-ID=x1,
BIWF-Address=x)
Figure 5. Forward bearer setup, no notification
Bearer Setup Connect
IAM (Action = Connect backward,
BNC-ID=y1, BIWF-Address=y)
Bearer Setup Connect
COT
Two possibilities are defined:
"Per-call bearer set-up in forward direction" - in which
bearer control is achieved using a separate bearer control
protocol, initiated in the forward direction (relative to the
call set-up direction).
In the case of forward bearer set-up the service node
that sends an IAM also initiates the set-up of the bearer
connection. IAM conveys Application Transport
parameter (ATP), which has encapsulated BICC signaling
information that indicates bearer setup is in the forward
direction.
APM conveys Application Transport parameter, which
has encapsulated BICC signaling information, BIWF
address, BNC-id, and to indicate either notification of
bearer set-up is required Fig. 6 or not Fig. 5.
"Per-call bearer set-up in backward direction" - in
which bearer control is achieved using a separate bearer
control protocol, initiated in the backward direction
(relative to the call set-up direction).
In the case of backward bearer set-up the service node
that receives IAM initiates the set-up of the bearer
ACM
ANM
ACM
ANM
IAM
Bearer Setup request (BNC-ID=y1,
BIWF-Address=y)
ACM
ANM
COT
ACM
ANM
Figure 7. Backward bearer setup
B. Bearer Setup procedures in IP network
The IPBCP protocol is used to set up the bearer
tunneled in BICC messages, and sent between the BCFs
via BICC signaling means.
In this case, there are two variations of bearer setup:
"Fast set-up" - in which bearer control information is
carried in the IAM and subsequent APM(s) messages.
This variation is supported for both the forward and
backward bearer set-up cases.
In the case of fast forward set-up the service node that
sends the IAM also initiates the set-up of the bearer
connection.
Information concerning the bearer set-up is carried
transparently between the BCFs via bearer control
tunneling. Initial bearer set-up information is available
when the IAM is sent.
The following Fig.8 show the case when notification of
bearer connects is not required.
CCF
CCF
CCF
BCF (x)
BCF (Y)
BCF (Z)
IAM (Action = Connect backward,
Tunnel data)
IAM
IAM (Action = Connect backward,
Tunnel data)
APM (Tunnel data)
APM (Action = Connected)
APM (Action = Connected)
CCF
CCF
CCF
BCF (x)
BCF (Y)
BCF (Z)
COT
IAM
IAM (Action = Connect forward,
Tunnel data)
ANM
ANM
ANM
ANM
COT
ACM
ACM
ACM
ACM
IAM (Action = Connect forward,
Tunnel data)
IAM
APM (Tunnel data)
IAM
APM (Action = Connect forward
without notification, Tunnel data)
APM (Action = Connect forward
without notification, Tunnel data)
Figure 10. Fast backward bearer setup
COT
COT
ACM
ACM
ACM
ACM
ANM
ANM
ANM
ANM
Figure 8. Fast forward bearer setup, no notification
"Delayed set-up" - in which bearer control information
is carried in APM messages following the first backward
APM. This variation is supported for both the forward and
backward bearer set-up cases.
In the case of delayed backward set-up the service node
that receives the IAM initiates the set-up of the bearer
connection Fig.11.
Information concerning the bearer set-up is carried
transparently between the BCFs via bearer control
tunneling.
The following Fig.9 show the case when notification of
bearer connects is required.
CCF
CCF
CCF
BCF (x)
BCF (Y)
BCF (Z)
IAM
CCF
CCF
CCF
BCF (x)
BCF (Y)
BCF (Z)
IAM (Action = Connect backward)
IAM (Action = Connect backward)
IAM
IAM
IAM (Action = Connect forward,
Tunnel data)
APM (Action = Connect forward
with notification, Tunnel data)
IAM (Action = Connect forward,
Tunnel data)
APM (Tunnel data)
APM (Tunnel data)
IAM
APM (Action = Connect forward
with notification, Tunnel data)
APM (Tunnel data)
APM (Tunnel data)
COT
APM (Action = Connected)
APM (Action = Connected)
ACM
COT
ACM
ACM
ACM
ANM
ANM
COT
ANM
ACM
ANM
ACM
ANM
COT
ACM
ANM
ACM
ANM
ANM
Figure 11. Delayed backward bearer setup
Figure 9. Fast forward bearer setup with notification
In the case of fast backward set-up the service node that
sends the IAM also initiates the set-up of the bearer
connection Fig. 10.
Information concerning the bearer set-up is carried
transparently between the BCFs via bearer control
tunneling.
Initial bearer set-up information is available when the
IAM is sent. In the fast backward set-up case, notification
of bearer connect is required.
In the case of delayed forward set-up the service node
that sends the IAM also initiates the set-up of the bearer
connection.
Information concerning the bearer set-up is carried
transparently between the BCFs via bearer control
tunneling. Initial bearer set-up information is unavailable
when the IAM is sent.
Bearer control tunneling is applicable to the case when
notification of bearer connect is required Fig. 12 or not
required Fig. 13.
CCF
CCF
CCF
BCF (x)
BCF (Y)
BCF (Z)
IAM
IAM (Action = Connect forward)
IAM (Action = Connect forward)
IAM
APM (Action = Connect forward)
APM (Action = Connect forward)
APM (Tunnel data)
APM (Tunnel data)
APM (Tunnel data)
APM (Tunnel data)
COT
COT
ACM
ACM
ACM
ACM
ANM
ANM
ANM
ANM
or PLMN and good operational support for large-scale
use. Work on BICC protocol is still ongoing and new
capabilities are being added.
IP transport technology always requires longer call setup times in compare with ATM no matter which type of
call set-up scenario is used. This is a consequence of more
signaling between servers.
The layered architecture is being deployed in thirdgeneration networks. This enhanced architecture, provides
an inherent flexibility, which allows operators to build
scalable and cost effective multi-services solutions in the
new telecom world.
The modular nature of MGW means it is possible to
create nodes with different configuration, functionality,
capacity, cost, and reliability and performance level.
MGW represents the base for supporting the multimedia
services making the convergence of telecom and data in
communications possible.
Figure 12. Delayed forward bearer setup, no notification
REFERENCES
IAM
CCF
CCF
CCF
BCF (x)
BCF (Y)
BCF (Z)
[1]
[2]
IAM (Action = Connect forward)
IAM (Action = Connect forward)
IAM
APM (Action = Connect forward
with notification)
APM (Tunnel data)
APM (Action = Connect forward
with notification)
[3]
APM (Tunnel data)
[4]
APM (Tunnel data)
APM (Connected)
APM (Tunnel data)
COT
ACM
ACM
ACM
ANM
ANM
[5]
APM (Connected)
COT
ACM
[6]
ANM
ANM
[7]
Figure 13. Delayed forward bearer setup with notification
Measurement results (e.g. call set-up times for ATM
and IP bearer) for each bearer set-up procedures described
in this paper can be found in [5].
[8]
[9]
[10]
[11]
V.
CONCLUSION
[12]
This paper has shown the capabilities for the resource
reservation in the next generation networks using BICC as
a call control protocol using ATM and IP transport
technology. BICC supports the full range of ISDN and
supplementary services over packet networks. Its strong
points are complete compatibility with the existing PSTN
[13]
[14]
Alen Bulić, Damir Burić, Lovre Hribar, ''Implementation of IEPS
in Multi Service Networks and impacts on call control protocols'',
12. International Conference on Software, Telecommunications &
Computer Networks, SoftCOM 2004
Denis Duka, Lovre Hribar, Damir Burić, ''Horizontal Layering –
an Essential Aspect in Modern networking'', 27. International
Conference, MIPRO 2004
Denis Duka, Lovre Hribar, Damir Burić, ''Adopting the Horizontal
Layering in the GSM/UMTS Network'', 12. International
Conference on Software, Telecommunications & Computer
Networks, SoftCOM 2004
Lovre Hribar, Damir Buric, “Usage of BICC and SIP protocol in
IP core network”, 11. International Conference on Software,
Telecommunications & Computer Networks, SoftCOM 2003
Lovre Hribar, Damir Buric, Denis Duka, “ Comparison between
ToATM and ToIP using BICC as Call Control Protocol”, 12.
IEEE MELECON 2004
Lovre Hribar, Damir Buric, Denis Duka, “Usage of Call
Mediation Node in ATM/IP Core Network”, 27. International
Conference, MIPRO 2004
Lovre Hribar, Damir Burić, Denis Duka, ''Migration from ToATM
towards ToIP using BICC'', 12. International Conference on
Software, Telecommunications & Computer Networks, SoftCOM
2004
BICC IP bearer control protocol, ITU-T Recommendation Q.1970.
Bearer independent call control protocol, ITU-T Recommendation
Q.1901
Bearer independent call bearer control protocol, ITU-T
Recommendation Q.1950
Bearer independent call control protocol (Capability Set 2) and
Signaling System No. 7 ISDN User part: General functions of
messages and parameters, ITU-T Recommendation Q.1902.2.
ITU-T, Q.1902.1 Bearer Independent Call Control protocol
(Capability Set 2) Functional Description.
ITU-T, Q.1902.4 Bearer Independent Call Control protocol, basic
call procedures
ITU-T, Technical Report TRQ.BICC.CS3 General signaling
requirements for the support of narrowband services over
broadband transport technologies, BICC Capability Set 3