<<

. 111
( 132 .)



>>

Tunnelling has two main advantages. First it reduces the time for bearer negotiation,
since a new TCP connection setup is not required and the IPBCP messages can be
piggybacked on the BICC call control messages. It also allows the IPBCP to be carried
over the Nc signalling interface across the core, supporting the SCTP protocol, which is
more suited for signalling transport.




BICC BICC
BICC APM
MSC MSC
IPBCP tunnel IPBCP
tunnel
Q.765.5
Server Server
Q.1990 Q.1990



Nc
IPBCP




IPBCP




BICC BICC
Mc Mc
Tunnel Tunnel

Tunnel package Tunnel package
Q.1950 Q.1950




MGW MGW



Figure 8.21 IPBCP tunnelling
544 IP TELEPHONY FOR UMTS RELEASE 4


8.8.6 BICC call ¬‚ow examples for release 4
Figure 8.22 shows the call ¬‚ow for BICC in a UMTS R4 network. The example given is
for a mobile originated call with the bearer establishment in the forward direction.

1. The call starts with the mobile forwarding its call setup request to the MSC server.
The MSC server replies to the mobile with a call proceeding message.
2. It then proceeds to prepare a bearer for the call on its core network side by issuing
the add command to the local MGW. The local MGW responds with the identi¬ers
for the new context and termination created. The local MGW will also pass up the
description of its local media options in the IPBCP request message (in
SDP format).
3. The MSC server then creates an IAM message and examines the called party
number to determine the correct remote MSC server to which it should forward the
call. This IAM message also contains the tunnelled IPBCP request.
4. The remote MSC server will prepare a bearer on its own MGW using the add
command. This add command also contains the tunnelled IBCP message destined


MSC
UE RNC MGW
Server
SETUP
ADD.req ($)
1 CALL PROCEEDING
Prepare bearer CS
interface=CN
core network
2 ADD.rep (T2) Tunnel information up

IAM+tunnelled IPBCP request
3
APM+tunnelled IPBCP reply
4
Tunnel information
MOD.req (T2)
down, network bearer
5 MOD.rep (T2)
established
ADD.req ($)
interface=RAN
Prepare bearer
6 ADD.rep (T1) (access network)
RAB Assignment Request

UTRAN Radio Bearer
Establishment
RAB Assignment Response
ACM
7 ALERTING
ANM
8
Change through
MOD.req (T1)
connection
MOD.rep (T1) Activate interworking
function (if required)
9 MOD.req (T2)
Activate voice
MOD.rep (T2) processing function (if
CONNECT
required)
10


Figure 8.22 BICC Release 4 call ¬‚ow example (forward bearer establishment)
8.8 BEARER-INDEPENDENT CALL CONTROL (BICC) 545


for the remote MGW. Once the remote MGW has created the termination it will
reply; its reply contains the tunnelled IPBCP response. This IPBCP response is
tunnelled in an APM message which is sent back to the original MSC server.
5. The local MSC server passes the IPBCP response down to the local MGW using
the mod request. At this point the bearer will have been established across the core
network between the two MGWs.
6. The MSC server then prepares a bearer for the radio access side of the call. It uses
the ass command to create a termination on the Iu interface. The reply to the add
request at this point will return the IP address and RTP port number for the
termination. The MSC server will then proceed to establish a radio access bearer
over the RAN to the UE, by sending a RAB assignment request to the RNC. The
RNC will then reply with the RAB assignment response to indicate that radio bearer
has been established.
7. The ACM message being forwarded from the call destination initiates the MSC
server to send the altering message to the UE. At this point, the destination will be
ringing and the ringing tone will be being played to the caller.
8. The called party answers the phone and the ANM message is returned to the
MSC server.
9. On call answer, the MSC server instructs the MGW to patch the call through. This
will allow media to ¬‚ow between the two parties. The activate voice processing
function for voice calls and activate interworking function for data calls may also
be requested at this point.
10. The connect message is sent back to the user equipment to signal
connection success.



8.8.7 Tandem-free and transcoder-free operation

CODEC tandem operation is where media sent between two MGWs must be translated
before transmission. For example, if one MGW is receiving a call on its external interface
coded as G.723.1 and the other MGW is forwarded the media in GSM format, the speech
will have to be transcoded before being forwarded. The usual way to do this is to translate
the media into PCM before transmitting it between the two gateways. This process is
illustrated in Figure 8.23. The reason for the use of PCM as a common CODEC is that
every MGW must support it, therefore its use guarantees interoperability.
For the MGWs to operate tandem free, i.e. without transcoding to PCM, they would have
to use common CODECs on their external interfaces. This is illustrated in Figure 8.24.


GSM PCM G.723.1
MGW A MGW B


Figure 8.23 Tandem operation
546 IP TELEPHONY FOR UMTS RELEASE 4


GSM GSM GSM
MGW A MGW B


Figure 8.24 Tandem-free operation


GSM GSM GSM GSM GSM
MGW MGW MGW MGW
UE UE
A B C D


Figure 8.25 Transcoder-free operation


If the media for a call requires no transcoding between sender and receiver, this is
referred to as transcoder-free operation (Figure 8.25). This will involve every MGW pair
from source to destination to be operating tandem-free.
In general transcoding is undesirable since it can increase delay and distort the original
signal. Also, since PCM has the highest bit rate of any telephony CODEC, there is also
the issue of wasted bandwidth.
Figure 8.26 illustrates the transcoding issues for UMTS. For a call from the UTRAN
to the PSTN, the AMR code will require transcoding between AMR and G.711, either
at MGW-a or MGW-c. This is because the PSTN works on 64 kbps connections while
the cellular network with its limited capacity, compresses the voice and works on less
than 13 kbps.
To enable a transcoder-free operation from one UTRAN user to another UTRAN user,
both AMR users will have to use the same CODEC.
For a call from the UTRAN to the GERAN (which is GSM-based), transcoding may
or may not be required since the AMR CODEC supports GSM EFR as one of its
options, therefore it may be possible to send packets from source to destination with
no CODEC translation. It can be seen that within a single operator™s realm, implementing
transcoder-free operation should present a number of technical challenges. However, for
the mechanisms to work between operators is a much more complex problem to solve.



PSTN
G.711




MGW-c


Core
UE UTRAN RNC MGW-a MGW-b BSC GERAN
Network

AMR GSM (e.g. EFR)

Figure 8.26 UMTS transcoding
8.8 BEARER-INDEPENDENT CALL CONTROL (BICC) 547


To establish a common CODEC between end users, a process called CODEC nego-
tiation is used. When a call is made by the UE in the UTRAN it can provide a list of
CODECs it supports in the call setup messages (see 24.008). In the bearer setup, the
initiating MSC server uses the list from the UE to generate a prioritized list of supported
CODECs in the IAM message. For transit MSC servers each one can remove (puncture)
CODECs from the list that are not supported before forwarding the IAM message. The
MSC server terminating the IAM message then checks to see which CODECs are sup-
ported for the termination on its MGW, chooses a supported CODEC from the list and
returns this choice back to the initiating MSC server in the APM message. The procedures
for transcoder control are de¬ned in detail in TS 23.153.
At the originating MSC, the CODEC choice is passed back to the UE using a NAS
synchronization indicator information element. This is carried in RANAP messages to
the RNC and from there in the RRC messages sent to the UE. Since the CC ALERTING
message is sent via RANAP and RRC, it is convenient to piggyback the NAS synchro-
nization identi¬er IE onto this message. This process is illustrated in Figure 8.27. Note
that the NAS synchronization indicator is set to 2, i.e. the CODEC ID for GSM EFR.
The advantages of transcoder-free operation are:

• improved call quality (no distortion due to tandem coding);
• reduced end-to-end delay;
• freeing up of transcoding resources at the media gateways;
• possible saving of bandwidth use within the core network.


8.8.8 BICC summary
The use of BICC ¬ts in well with the evolutionary model for UMTS development. It
allows for easy internetworking between the TDM and packet switched technologies


MSC Core MSC
UE UTRAN RNC GERAN
server Network server


RRC/RANAP Direct Transfer
IAM
SETUP
CODEC List:
CODEC List:
AMR_6.70
AMR_6.70
AMR_7.40
AMR_7.40
AMR_10.2
AMR_10.2
AMR_12.2
AMR_12.2
AMR_SID

<<

. 111
( 132 .)



>>