. 110
( 132 .)


procedure used


Bearer Establishment

Figure 8.18 Use of forward/backward bearer establishment

8.8.1 Forward and backward bearer establishment
In forward bearer establishment the bearer setup control is initiated in the same direction
as the IAM message which starts the call. It is possible, however, for the bearer to be
established in the opposite direction to the IAM. This is referred to as a backward bearer
establishment procedure. Allowing the transport bearer establishment to be performed in
either direction (forward or backward) allows one MSC server to be in control of network
resources, simplifying control. This is illustrated in Figure 8.18. MSC server A on the left
is responsible for controlling admission by only allowing calls to be established if there
is enough bandwidth available within the core network. For calls in which MSC server
A originates the IAM message, forward bearer establishment is used; for calls forwarded
from MSC server B, backward bearer establishment is used. In both case MSC server A
is in control of bearer establishment.
Another example of forward/backward bearer establishment is with the AAL2 connec-
tion made from the RNC towards the core network, since the RNC always establishes
the connection.

8.8.2 BICC messages and parameters
Table 8.9 shows some of the more commonly used BICC messages. The messages are
used in very much the same way as their ISUP equivalent. Basic call setup progression
for forward bearer establishment is shown in Figure 8.19. In this diagram CSF-N and
BSF-N refer to CSF and BSF node, respectively.
The IAM message is used to initiate the call setup. This message contains the called
party™s number, and is forwarded to the CSF node serving the called party, or the CSF
node connected to the PSTN which serves the called party. The APM message is a
general purpose message used to forward non-BICC information between BICC users.
In response to the IAM, an APM message is sent in the reverse direction. This message

Table 8.9 BICC messages
Message Acronym Meaning/purpose
Initial address IAM Initiates call setup
Application transport APM Carries non-BICC information
Address complete ACM Indicates all addressing information has been received
Answer ANM Called party has answered phone
Release REL Request release of bearer
Release con¬rm RLC Con¬rm release of bearer


bearer signalling
(a) (b)

IAM (1)

APM (2) (BIWF Address =b)

Bearer set-up (4)
bearer (3)

ACM (5)

ANM (6)

REL (7)

RLC (8)

Figure 8.19 BICC forward bearer establishment

contains bearer information, including the remote gateway™s local media options and its
interworking address (i.e. IP address and RTP port number or ATM address). On receipt
of the APM the local CSF-N requests its BSF-N to set up the bearer to the remote BSF-N
using the bearer information contained in the APM message (this request is carried in an
H.248/MEGACO transaction).

The bearer information is used to establish the bearer between the media gateways,
which is performed using a non-BICC protocol. Once the call has been routed all the
way to the destination, an ACM message is sent in the reverse direction. At this point,
the destination phone starts ringing and a ringing tone is played to the caller. When the
called party answers the phone, the ANM message is sent in the reverse direction, the
ringing signals are removed from the lines and the media is connected in both directions.
Finally, when one of the parties hangs up, release messages are used to clear the call.
Each BICC message can contain a number of parameters, a few of which are shown
in Table 8.10. The call instance code (CIC) is used to relate a number of BICC messages
which belong to a particular call. The called party number is used to help route the IAM
message to the correct destination. The calling party number is used to identify the caller
and can be included in the IAM message to allow for services such as caller ID.
The application transport parameter allows the standard BICC message to carry non-
BICC data for another application. This could be, for example, charging information. In
the examples given in this section this information is related to the bearer control.
The destination for the application transport message can be an application residing
at the CSF-N, or if tunnelling is used the parameter contents will be forwarded to the
BCF-N without being examined by the CSF. This mechanism is used by the IPBCP to
allow transport of bearer establishment requests between peer BCF-Ns.

8.8.3 Bearer control function
The BICC bearer control protocol operates on the interface between the CSF-N and
BCF-N. De¬ned in Q.1950 and based on H.248 with added packages, it de¬nes a set
of bearer control transactions and maps them onto H.248 transactions (i.e. add, modify,
subtract etc.).
The 3GPP de¬nes bearer control procedures for R4 in 29.232 (Media Gateway Con-
troller (MGC) “ Media Gateway (MGW) Interface). Most of these procedures map with-
out modi¬cation to the transactions de¬ned in Q.1950, and Table 8.11 lists some of the
more common procedures.
As well as describing procedures for bearer establishment, TS29.232 also de¬nes a
number of new UMTS-speci¬c packages. For example, the 3GPP 3gup/interface property
is set, depending on which interface the termination resides on (possible values are RAN
for the Iu interface and CN for the Nb interface).
The prepare bearer procedure is used to create terminations and contexts at the gateway
but without bearer establishment taking place at the same time. This is used in a case

Table 8.10 BICC parameters
Name Size (bits) Use
Call instance code (CIC) 32 Relates multiple
Called party number Variable Destination of call
Calling party number Variable Source of call
Application transport Variable Application information, e.g. bearer
control information

Table 8.11 Media gateway control procedures (29.232)
3GPP MGW control Q.1950 transaction Possible H.248
procedure commands
Prepare bearer Prepare BNC Notify Add, modify, move
Establish bearer Establish BNC Notify Add, modify, move
Change through-connection Cut Through Add, modify, move
Active interworking function N/A Modify
Activate voice processing function Echo canceller Add, modify, move

where the bearer establishment is done by the remote media gateway or by the RNC. An
example of the prepare bearer function is step 3 in the MEGACO call example shown
in Section 8.7.4. A local termination is created and the internetworking address of the
MGW is returned to the MSC server. This procedure is represented by H.248 add or
modify commands. The modify command is used when an MSC server wishes to reuse
a termination that already exists for a new call.
The establish bearer procedure requests that the media gateway creates the context
and termination as well as establishing a bearer to the remote MGW. The MSC server
provides the bearer address, binding reference and bearer characteristics requested for
this connection. In this case the H.248 command also contains the remote address of the
MGW to connect to. This procedure corresponds to step 6 in the MEGACO call example.
The change through-connection procedure alters the mode of a termination at the gate-
way to send/receive. It is commonly carried out at the same time as the prepare bearer
or establish bearer procedures but can be executed on its own using the H.248 mod-
ify command.
The activate interworking function is entirely new (not from Q.1950) and de¬ned
wholly within TS29.232. This procedure activates the negotiation of any layer 2 protocols
that may be required when making circuit switched data calls, for example when making
a data call to a modem in the PSTN (see Figure 8.20). In this case, on receipt of the

MSC server

Layer 2 negotiotion

IP core Modem
MGW pool PSTN Modem
network pool

Data call

Figure 8.20 CS domain data call

Table 8.12 Circuit switched data package
Name Type Parameters Description
Actprot Signal Local peer role Activates layer 2
Values orig or term negotiation
Protres Event Result Values Returns result of
success, failure negotiation

activate interworking request the media gateway is allowed to allocate a modem out of
its pool and start connection procedures to the remote modem. Once the connection is
successful (or has failed) the MGW will notify the MSC server of the result. The activate
interworking function is supported in H.248 by the addition of the circuit switched data
package (29.232), some of which is described in Table 8.12.
The activate interworking procedure is executed after the call has been set up between
the two end points. The procedure consists of an H.248 modify command being sent
to the MGW applying the actprot signal and requesting noti¬cation of the result of the
negotiation (notify on protres).
The activate voice processing function enables the echo cancellation function (and any
other relevant voice processing functions) for terminations that support it. This proce-
dure consists of an add, modify or move command which modi¬es the tdmc/ec (echo
cancellation property).

8.8.4 Bearer control protocols
Since the CS core network can be based on ATM (AAL1 or AAL2) or IP, bearer estab-
lishment procedures have to be de¬ned for both of these networks. The 3GPP speci¬es
the following options for bearer control across the core CS domain (29.414):

• AAL2 connection signalling (Q.2630.2)
• BICC IP bearer control protocol (Q.1970).

For more detail on AAL2 connection signalling see Chapter 7.

8.8.5 BICC IP bearer control protocol (IPBCP, Q.1970)
IPBCP allows a pair of IP peers to negotiate IP addresses, RTP port numbers and media
characteristics for a bearer connection between them. All media options for IPBCP are
described using SDP.
The protocol uses an offer response mode, and the following messages are supported:

• Request: requests establishment or modi¬cation of media bearer
• Accept: accepts establishment or modi¬cation of media bearer

• Confused: response when peer does not understand request format
• Rejected: rejects request to establish or modify bearer

In general, an initiator will send a request message and wait for an accept or reject. If
it does not receive a reply within a given time it will send the message again. IPBCP tunnelling

The IPBCP messages, instead of being sent on a dedicated connection directly between
MGWs (Nb interface), are tunnelled over the Nc and Mc interfaces. This is illustrated in
Figure 8.21. IPBCP messages are encapsulated in the BICC tunnelling protocol (Q.1990).
The BICC bearer control tunnelling messages are encapsulated in BICC APM messages
or optionally piggybacked on other BICC messages (e.g. IAM) for transport over the Nc
interface. The tunnelling information is passed over the Mc interface using events and
signals de¬ned in the tunnel package (Q.1950).


. 110
( 132 .)