<<

. 109
( 132 .)



>>

}
}
Add = $ {
Media {
Stream = 1 {
LocalControl {
Mode = SendOnly,
},
Local
{
v=0
c=ATM NSAP $
m=audio $ AAL2/ITU 96 AAL2
a=rtpmap: 96 VND.3GPP.IUFP/16000 termination
a=eecid: $
mode=sendonly
}
Events = 1111
{
GB/BNCChange
}
}
}
}
}




Figure 8.14 Local association creation transaction (step 6)


The eecid is the end-to-end call identi¬er. This is a unique value chosen by the MGW
and passed back to the MSC server. This value (referred to as the binding ID) is then sent
to the RNC along with the NSAP address and used in the AAL2 connection establishment
request. Now the MGW can use the eecid value to match up the incoming AAL2 request
from the RNC with its corresponding AAL2 termination. The BNCChange event occurs
whenever there is a change in the status of the bearer network connection. It will be
534 IP TELEPHONY FOR UMTS RELEASE 4


triggered when the RNC establishes the incoming connection to the MGW. This allows
the MSC server to be informed as soon as the AAL2 bearer has been established from
the RNC.
The reply to the local association creation transaction is shown in Figure 8.15. In this
most of the ¬elds marked $ (including the termination and context IDs) in the transaction
have been ¬lled in with values by the MGW. In particular, the values for the NSAP and
the eecid have been allocated by the MGW.




Reply = 4000 {
Context = C300 {
Add = Ephemeral_594 {
Media {
Stream = 1 {
LocalControl {
Mode = ReceiveOnly,
},
Local {
v=0
c=IN IP4 192.45.6.25
m=audio 2030 RTP/AVP 96
a=rtpmap: 96 VND.3GPP.IUFP/16000
},
Remote {
v=0
c=IN IP4 192.45.6.7
m=audio 3000 RTP/AVP 96
a=rtpmap: 96 VND.3GPP.IUFP/16000
}
}
}
Add = Ephemeral_595 {
Media {
Stream = 1 {
LocalControl {
Mode = SendOnly,
},
Local
{
v=0
c=ATM NSAP 47.0021.6732.0000.0060.3224.6701.9990.3e64.fd01.00
m=audio $ AAL2/ITU 96
a=atmmap: 96 VND.3GPP.IUFP/16000
a=eecid: BB 56 90 12
mode=sendonly
}
Events = 1111
{
GB/BNCChange
}
}
}
}
}



Figure 8.15 Local association creation reply (step 7)
8.7 MEGACO 535


When the call is answered, indicated by the ISUP answer messages ANM, the remote
and local MGWs are asked to modify their terminations to send/receive instead of just
receive-only. This allows the speech to ¬‚ow in both directions. The MEGACO transactions
for this are illustrated in Figure 8.16.


8.7.5 Deleting contexts and bearers
When the call is ¬nished the contexts and terminations have to be deleted at the MGWs
to free up the resources. This is done using the subtract command. This transaction must
be carried out at both the local and remote gateway to free up the resources there as well.



Transaction = 3001 {
Context = C500 {
Modify = Ephemeral_123 {
Media {
Stream = 1 {
LocalControl {
Mode = SendReceive
}
}
Step 10
Modify = TDM_1/20 {
Remote MSC server -> Remote MGW
Media {
Stream = 1 {
LocalControl {
Mode = SendReceive
}
}
}
}



Transaction = 4001 {
Context = C300 {
Modify = Ephemeral_594 {
Media {
Stream = 1 {
LocalControl {
Mode = SendReceive
}
} Step 12
Modify = Ephemeral_595 { Local MSC server -> Local MGW
Media {
Stream = 1 {
LocalControl {
Mode = SendReceive
}
}
}
}




Figure 8.16 Send/receive enable (steps 10 and 12)
536 IP TELEPHONY FOR UMTS RELEASE 4


8.7.6 Summary
MEGACO is the enabling protocol for the separation of switching and call control func-
tions within the network (softswitch architecture). It is recommended by 3GPP for UMTS
networks since it allows for greater scalability and reliability. Call control capacity and
switching capacity can be increased independently, allowing more ¬‚exibility of scaling.
Multiple media gateways and MSC servers can be used within a redundant architecture
to allow for carrier grade reliability.



8.8 BEARER-INDEPENDENT CALL CONTROL (BICC)
As mentioned previously, before a call can be transported across the IP core network,
some type of call/session control has to be initiated. This is to allow a call which was
initiated within the UTRAN to be terminated within the PSTN or vice versa. With current
PSTN networks this call control is largely done using ISUP (ISDN user part). One possible
approach to handle calls across the IP network is to use a new protocol such as SIP, and
emulate all PSTN services using SIP call control. The problem with this, however, is that
services are somewhat complex and emulation will not always produce the correct result.
The ITU-T view on this was that only a protocol that was 100% compatible with ISUP
would be suitable, and that all services would have to be emulated exactly. This would
mean that two PSTN customers having their calls connected via an IP network would be
unaware that their call had been handled any differently.
The protocol that was developed to achieve this is called bearer-independent call control
(BICC), and has the following features:

• compatible with and based on the ISUP protocols;
• voice/data call capability (but no special multimedia features);
• independent of the underlying network technology (hence bearer-independent);
• support for tandem-free coding of mobile calls.

Since BICC is bearer-independent, it also requires a mechanism to establish bearers
across the network it is using to transport its calls. The ITU-T has provided recom-
mendations for running BICC over both ATM and IP. It is envisioned, however, that
the long-term goal is to use BICC for IP networks with ATM being provided as an
interim solution.
BICC development started with capability set 1 (CS1). For CS1 the only transport option
available was ATM. In this case, a network operator can migrate their network from a
traditional TDM solution to use of ATM, allowing for transport of real-time over AAL1 or
AAL2. CS1 is essentially designed to allow packet-based networks to trunk ISDN calls.
With BICC CS1, all supplementary service information is tunnelled transparently in BICC
messages. BICC CS1 was released as an amendment to the original ISUP speci¬cations.
BICC capability set 2 (CS2) builds on CS1 but in this case, a totally new set of
speci¬cations were released (Q.1902.x), and nodes are expected to support local exchange
8.8 BEARER-INDEPENDENT CALL CONTROL (BICC) 537


functionality. A BICC CS2 node therefore has to provide all the ISUP supplementary
services (call forward on busy, etc.) as well as basic bearer establishment. CS2 allows the
bearer options to include IP. To allow for bearers to be established across the IP network
a new protocol, BICC IP bearer control protocol (Q.1970), was developed.
Figure 8.17 shows a simpli¬ed diagram of the BICC architecture. Notice that BICC,
like MEGACO, splits the control of the network into call control and switching or bearer
control. The call service function (CSF) sited at the MSC server performs the follow-
ing functions:


• call control;
• interfaces to the ISUP network;
• interface to the bearer network to forward requests using BICC;
• interfaces to the bearer control function (BCF) to request for bearers to be established.


The bearer interworking function (BIWF, corresponding to the UMTS MGW) performs
translation between the two different networks, for example between TDM and ATM or
ATM and IP. Functions provided at the BIWF will include:


• interfacing to the user plane;
• CODEC translation;
• bearer establishment and tear down.


The BCF provides the signalling required to establish new bearers. The CSF controls
the BCF, requesting the establishment of bearers and internetworking between them using
the BICC bearer control protocol.



ISUP BICC ISUP
CSF CSF
(MSC server) (MSC server)




BCF BCF
user bearer bearer signalling user bearer


bearer user plane
BIWF BIWF


Figure 8.17 BICC architecture
538 IP TELEPHONY FOR UMTS RELEASE 4


IAM
Forward bearer establishment
procedure used
MSC MSC
server A server B
IAM
Backward bearer establishment

<<

. 109
( 132 .)



>>