-
7/30/2019 01347020
1/4
IEEE MELECON 2 004, May 12-15,2004, Dubrovnik, Croat ia
Comparison between ToATM and ToIP usingBICC as Call Control
Protocol
Lo vr e Hr ibar , Ericsson Nikola Tesla d.d., Split, Croatia, D
am ir Bu ric, Ericsson Nikola Tesla d.d., Split, Croatia,Denis
Duka, Ericsson Nikola Tesla d.d., Split, CroatiaE-mail:
Lovre.Hribar@,ericsson.com,Dainir.D.B.Buric@,ericsson.com,Denis.Duka@,ericsson.com
Abstract: Core Network is based on the separation
offunctionality into a con trol layer, a connectivity layer and
anapplication layer. The BICC signaling is carried on top ofeither
ATM or IP based signaling transport using aSignaling Transport
Converter, which makes the callcontrol signaling independent on the
underlying layers.BICC CS2 protocol versions are enhanced with new
set ofcapabilities in compare with earlier BICC CS1 version.
Thisarticle has shown that new version of BICC protocol shouldnot
exclude the earlier BICC protocol. Operators have beengiven the
possibility for smooth migration from theTelephony Over ATM (ToATM)
towards ToIP using BICCas a Call Control Protocol.
1. INTRODUCTIONBearer Independent Call C ontrol Capability Set
(BICCCS) protocol hav e it own place in the Core Network as aCall
Control Protocol. BICC CS1 is the first version usedin the ATM
based core network. The second version ofBICC, BICC CS2 is enhanced
version of BICC C Sl andis used in the Internet Protocol (IP) based
core network.This paper gives an overview of the capabilities for
eachversion, tries to explain the conceptual and
architecturaldifferences and finally tries to compare different
types ofset-up modes.11 BICC OVERVIEW
A. Core Network Architecture using BICCThe BICC protocol
provides the signaling functionsrequired supporting narrowband
Integrated ServicesDigital Network (ISDN) services independent of
th ebearer technology and signaling transport technologyused. It is
an extension of ISDN User Part (ISUP)protocol and therefore
provides a full transparency of theexisting telephony functionality
[11. The firststandardized version of BICC protocol was CSl but
onlyBICC CS2 version gives a true separation of control andbearer
layer and introduction of 1P bearer. The physicalseparation of the
Call Control and Bearer Control allowsphysically separate Call
Service Function (CSF) andBearer Control Function (BCF). Inherent
in thisseparation is the possibility for BIC C CS2 to support
theBearer Interworking Function (BIWF) selection, allowinga
many-to-many relationship between control servers andBIWFs.
-......,ign.dlingTransport llJetwrk......_,.
Figure I . Network Functional ModelBICC is used as a protocol
between C SFs within differentnodes as originating/destination
Serving Nodes (SN s)(ISNs interworking with an access signaling
system),intermediate national/international SN s
(TSNs),incoming/outgoing national/international gateway SNs(GSNs)
and Call Mediation Nodes (CMNs), Figure 1.CMNs are introduced for
call routing purposes. They donot have bearer control function.To
support IP as a bearer the BICC along with CallBearer Control (CBC)
protocol provides a mechanism forthe transport of Bearer Control
Protocol (BCP)information between BIWFs. The mechanism provides
areliable, sequenced transport on a per backbone networkconnection
basis when there is no requirement forintermediate BCF-Rs between
the BCF-Ns to process thetunnelled information [2].Bearer Control
Tunnelling (BCT) shall be used for a callif the BICC-data primitive
associated with the InitialAddress Message (IAM) or the first
backwardApplication Transport Message (APM) includes the
BCTinformation element set to tunneling to be used. Theabsence of
the BCT information element in the IAM or inthe first backward APM
(if tunnelling to be used wasnot indicated in the IAM) spe cifies
that the BC T shall notbe used. The CSF should not process the
BCPinformation transported by tunnelling mechanism. Theunmodified
BCP information is tunnelled through theCBC protocol toward the
terminating BIWF, Figure 2.The APM message is used for transmission
of tunnelledinformation in call control layer. The BIWF at
theoriginating SN makes the decision on use of the BCTmechanism on
a per call basis. The CSF shall inform theBIWF of the possibility
of using the BCT mech anism and
0-7803-827 1 4/04/$20.00 02 00 4 IEEE 67 7
mailto:Lovre.Hribar@,ericsson.commailto:Dainir.D.B.Buric@,ericsson.commailto:Dainir.D.B.Buric@,ericsson.commailto:Denis.Duka@,ericsson.commailto:Denis.Duka@,ericsson.commailto:Denis.Duka@,ericsson.commailto:Dainir.D.B.Buric@,ericsson.commailto:Lovre.Hribar@,ericsson.com
-
7/30/2019 01347020
2/4
the BIWF shall respond with an indication of whether theTunnel
should be set up or not.
BIWFBearer Control =Q.IPBC/-$-qI+ - -- - - -- - - -- -- --
-*ignaling transport
Figure 2. IP Bearer Control Tunelling ConceptDepending whether
BIWF has been selected prior tooutgoing BICC set-up or after there
are two differentways of bearer connection set-up: Forward
andBackward. It depends as well on outgoing CSF
routecharacteristics and originating BIWF. The choice betweenFast
(Forward or Backward) and DelayedFonvadBackward set-up,
respectively, is made by theoriginating BCF and is indicated in the
initial responsefrom the originating BCF [3].Following the Third
Generation Partnership Project(3GPP) standard and its model of core
network BICCCS2 defines its own procedures for supporting the
codecnegotiation, mid-call negotiation and tone information.The CS2
version also supports the bearer redirectioncapability as well as
proce dures for reuse of idle bearersas a network option.
B. BICC DevelopmentBICC CS3 standard work is not finished yet
and thefollowing items and contributions are some that areproposed
to be in the scope [4]:- The BICC CS3 protocol should support as an
optionalprocedure the transfer of text-based (URLRJRI)
naming,complementary to the existing digit-based (E. 164)naming.
The transfer of text-based nam ing is restricted tothe called party
for identification purposes only, not forrouting purposes. Service
platform including ENUMfunctionality is supposed to map the E.164
telephonenumber into a Session Initiation Protocol
(SIP)-URL.Reverse ENUM functionality supposes the reversemapping.-
It is supposed for BICC to fully support the advancedCMN call
control procedures. The call control proceduresshall support:
A mechanism of relaying CMN exchange dataand/or IN data between
the CMN (CSF-G) andthe Originating SN using functionality
alreadyprovided in SS 7A mechanism for relaying recording,
exchange,and/or IN data between an Originating SN and aCMN with the
same network; call routingScreening fimctionality at the CMN (by
theC SF-G).
- Support for efficient Uni-cast and Multi-cast
Servicestransported on various transport technologies (e.g.
ATM,AAL2, IP, MPL S.. etc.) via communicationsconfiguration 6 (i.e.
conference services supported byusing a server). In addition to
already supported bearertechnology it is proposed to take MPLS
bearer transporttechnology in a label and a non-label
switchingconfiguration as a candidate for BICC CS3, and provideda
set of high-level requirements.- Support of multi-party call
configurations allowing aparty to add another party to the call and
itscommu nication capability type 6 or any other, and releasethe
party that it has added, from the call and itsattachment to the
bearer(s). It is proposed for bearer re-direction to support
establishment of a multi-party serviceconfiguration.- According to
proposals following information should
be used at CSF selection of BIWF:The services required by the
call,The list of BIWF's which can be used tointerface the peer SN
,
0 Inter-working with Switched CircuitNetworks,Network
Interconnect ScenariosMinimising the number of BIWF's in
theconnectionAt the succeeding SN, the Bearer ControlUnit
Identifier (BCU-ID) of the BCUselected at the preceding SN .
- Support of multi-media and related services.
Furtherdevelopment of BICC is proposed to be undertaken, andnot to
be limited to the existing narrow-band ISDNservice set. This
proposal is particularly related to SIP,i.e. BICC should not
compete against SIP, which isregarded as an emerging technology.
Intenvorking wouldbe included as far as existing BICC end terminals
couldsupport a particular service.- Routing methods for E.164,
AESA, INRA & IPaddresses (GOL-08 1). This contribution
identifiedsignalling requirements to support routing methodsrecomm
ended in E.35 1 for application across networktypes, for E.164,
AESA, INRA, and/or IP routingaddresses. It proposed to develop the
required signallingrequirements needed to support these routing
methods.- International Emergency Preference Scheme
(IEPS)support.
111. OUTGOING BEARER SET-UP PROCEDURESWhen the relevant Outgoing
signalling procedure
determines that the IAM can be sent the procedure forbearer
set-up in forward or backward direction is started.Five variations
of procedure are defined. The BCP usedto set up the bearer may be
either tunnelled in BICCmessages, or sent between the BCFs via
alternativesignalling means. In the former case, there are
threevariations:"Fast set-up'' - in which bearer controlinformation
is carried in the IAM and subsequent
67 8
-
7/30/2019 01347020
3/4
APM(s). This variation is supported for both the forwardand
backward bearer set-up cases."Delayed Forward set-up" - in which
bearercontrol information is carried in APM messagesfollowing the
first backward A PM."Delayed Backward set-up" - in which
bearercontrol information is carried in the first backward APMand a
subsequent APM (s).In the non-tunnelled case, two possibilities are
defined."Per-call bearer set-up in forward direction" - inwhich
bearer control is achieved using a separate bearercontrol protocol,
initiated in the forward direction(relative to the call set-u p
direction)."Per-call bearer set-up in backward direction" -in which
bearer control is achieved using a separatebearer control protocol,
initiated in the backwarddirection (relative to the call set-up
direction).The choice of variation to use for a calf is done
asfollows:If a BIWF has been selected when outgoing set-up
isinitiated:. The choice between forward and backwardbearer set-up
is provisioned at the CSF, as an originatingBIWF or outgoing call
route characteristic.The choice of tunnelled or
non-tunnelledoperation is made by the originating BCF and is
indicatedin the initial response from the BCF. (The CSF mayindicate
in the initial request to the BCF what tunnellingoption(s) it may
choose.)and Delayed Forward/Backward set-up, respectively, ismade
by the originating BCF and is indicated in the initialresponse from
this BCF. (The CSF may indicate in theinitial request to the BCF
what option(s) it may choose.)
. The choice between Fa st (Forward or Backward)
A. Per-call bearer set-up in Forw ard directionIn this procedure
the bearer is set up in the forwarddirection from the originating
SN forward to the SN thatreceives the IAM. Information to enable
addressing andbearer identification is awaited from the succeeding
SNbefore the bearer set-up can be initiated. Initial actionsdepend
on whether a BIWF has been selected at theinitiation of outgoing
bearer set-up.If a BIWF has been selected: in the response to
theBackbone Network Connections (BNC) Informationrequest primitive
the BCF returns the BNCcharacteristics, and may include the BIWF
Address. Theresponse also indicates that B CT is not being used.If
no BIWF has been selected BNC Characteristics is setto a value
determined by the C SF application logic.An IAM is sent including
in the BICC-Data request
primitive: Action indicator set to "Connect forward",BNC
characteristics, BI WF A ddress, if received from theBCF, BCT set
to "no indication", if the BIWF has notbeen selected, providing
that bearer control tunnelling isallowed.Subsequently BICC-Data
indication primitive(corresponding to an AP M message), should be
received:
If the received Action indicator is "Connect forward,
plusnotification" the Connect Type is set to
"notificationrequired", else it is set to "notification n ot
required".A BIWF is selected, if one was not se lected earlier.A
Bearer Set-up request is sent to the selected BCF. Thisrequest
includes: BNC-ID, BIWF Address, BearerCharacteristics, i.e.
Transmission Medium Requirements(as received in the'IAM ) and User
Service Information (ifreceived in the IAM).When a Bearer Set-up
Connect indication is received thisindicates successful completion
of the outgoing set-upprocedure. If the Connect Type is
"notiJication equired"a BICC-Data request primitive (corresponding
to anAPM message), is sent containing: Action indicator set
to"Connected".B. Per-call bearer set-up in Backward directionIn
this procedure the bearer is set up in the backwarddirection from
the succeeding SN back to the SN thatsends the IAM. The IAM sent
includes information toenable the bearer to be addressed back to
the SN thatsends the IAM, and to allow the bearer set-up
indicationto be correlated with the call. In the response to the BN
CInformation request primitive the BCF returns the
BNCcharacteristics, BNC-ID and BIWF Address. Theresponse also
indicates that bearer control tunnelling isnot being used. An IAM
is sent together with aBICC-Data request primitive containin g:
Actio n indicatorset to "Connect backward'', BNC-ID, BIWF
Address,BNC characteristics.When the bearer connection arrives at
the SN a BearerSet-up indication is received from the BCF. The
BearerSet-up indication is correlated with the call instance and
aBearer Set-up response is sent to the BCF.The outgoing set-up
procedure is now successfullycompletedC. Delay bearer set-up in
Forward directionIn this procedure the bearer is set up from the SN
thatsends the IAM. Initial bearer set-up information isunavailable
when the IAM is sent - if a BIWF has beenselected at this point the
unavailability is indicated by theBCF. Alternatively, bearer set-up
information isunavailable if the BIWF has not yet been selected,
but inthis case the fact that bearer control tunnelling will
beapplicable for the call is not initially known. Initialactions
depend on whether a BIWF has been selected atthe initiation of
outgoing bearer set-up.If a BIW F has been selected, in the
response to the BNCInformation request primitive the BCF returns
the BNCcharacteristics. The response primitive also may includethe
BIWF-Address. The response also indicates thatbearer control
tunnelling is being used and that thedelayed forward set-up
procedure are to be used.An IA M is sent including in the BICC-Data
requestprimitive: Action indicator set to 'Connect forward",Bearer
Control Tunnelling, set to "tunnelling to be used'',BNC
characteristics, BIWF A ddress, if received from theBCF.
679
-
7/30/2019 01347020
4/4
Subsequently a BICC-Data indication primitive(corresponding to
an APM message) should be received.If the received A ction
indicator is "Connect orward, plusnotification" the Connect Type is
set to "notficationrequired", else it is set to "no tfica tion not
required".A BIWF is selected, if one was not selected earlier.
ABearer Set-up request primitive is then.sent to the selectedBCF
containing: BNC-ID (if received in the BICC-Dataindication
primitive), BIWF Address (if received in theBICC-Data indication
primitive), Bearer Characteristics,i.e. Transmission Medium
Requirements (as received inthe IAM ) and User Service Inform ation
(if received in theIAM), an indication that bearer control
tunnelling shall beused (if this request was received in the
BICC-Dataindication primitive).Bearer control tunnelling is then
used to exc hange bearerset-up information betw een BC Fs.Receipt
of a primitive from the BCF, indicating "BNCset-up successrr
indicates successful completion of theoutgoing set-up proce dure.If
the Connect Type is "notification required" aBICC-Data request
primitive (corresponding to an APMmessage), is sent containing:
Action indicator set to'%onnected".D. Delay bearer set-up in Backw
ard directionThis procedure is invoked if the received
Actionindicator is set to Tonnect backward" and the BearerControl
Tunnelling information element is presentindicating, "tunnelling to
be used". In this procedure thebearer is set up in the backward
direction from thesucceeding SN back to the SN that sends the IAM.
ABearer Set-up request primitive is se nt to a selected BCF.This
request includes: BNC Characteristics (as receivedvia BICC-Data
indication primitiv e associated with theIAM), BIWF-Address (if
received in the BICC-Dataindication primitive), BNC-ID (if received
in theBICC-Data indication primitive), Beare r Characteristics,i.e.
Transmission Medium Requirements (as received inthe IAM ) and User
Se rvice Information (if received in theIAM), an indication that be
arer control tunnelling shall beused.Bearer control tunnelling may
then be used to exchangebearer set-up information be tween B
CFs.Receipt of a primitive from the BCF, indicating "BNCset-up
success", indicates successful completion of th eincoming set-up
procedure.
IV. MEASUREMENT FOR CALLS OVER ATM&IPThe purpose of this
chapter is to describe andcompare results of the time me asurement
forestablishment of BICC calls over IP and ATM bearerbackbone.The
major point of interest is BICC as a Cal ControlProtocol and the
time taken fo r basic call set-up.To obtain these m easurement
results sim ple calls overBICC are made for tw o types o f
subscribers access:PSTN and ISDN.
For each type of subscribers access mea surement is takenfor ATM
and I P as a bearer backbone and for differenttypes of call set-up.
TAR1.E 1._- .
TABLE 2.
Call set-up times are presented (Table 1 and Table 2 ) onlyfor
BICC protocol com plex.Set-up time represent amount of job s
executed in BIC Cprotocol complex until B-phone is ringing.Answer
time represent amount of jobs executed in BICCprotocol com plex
when B subscriber answers the call.Release time represent amount of
jobs executed in BICCprotocol complex when a subscriber hooks on th
ehandset.
V. CONCLUSIONIP type of bearer always requires longer call
set-uptimes no matter which typ e of call set-up scenario is
used.This is expected result as a consequence of moresignaling and
processing more jobs in BICC complex. Onthe other hand, answer and
release times are not affectedby types of bearer used (ATM or
IP).
REFERENCES[l ] Lovre Hribar, Damir Buric, "Usage of BICC and SIP
protocol in IPcore network", 11 . International Conference on
Software,Telecommunications & Computer Networks, SoftCOM
2003[2] ITU-T, Q.1902.1 Bearer Independent Call Control
protocol(Capability Set 2) : Functional Description.[3] ITU-T,
Q.1902.4 Bearer Independent Call Control protocol, basiccall
procedures[4] ITU-T, Technical Report TRQ.BICC.CS3 General
signalingrequirements for the support of narrowband services over
broadbandtransport technologies, BICC Capab ility Set 3
680
