<<

. 123
( 132 .)



>>

183 SESSION
183 SESSION PROGRESS
PROGRESS
Authorise QoS
resources
183 SESSION
PROGRESS
PRACK
PRACK
PRACK
Resource
reservation
UPDATE
UPDATE
UPDATE
180 RINGING
180 RINGING
180 RINGING
PRACK
PRACK
PRACK
200 OK
200 OK (INVITE)
(INVITE)
Approval of QoS
commit
200 OK
(INVITE)
ACK
ACK
ACK


Figure 9.29 IMS Mobile originated call ¬‚ow example
9.7 UMTS IMS CALL SIGNALLING 605


this stage since the CODEC for the session has not yet been established. The S-CSCF
then checks the service pro¬le for the subscriber, determines if the call is permitted by
applying the user™s ¬lter criteria and then forwards the INVITE to the destination. The
destination will then decides which CODEC(s) it wants to support then sends its reply in
the SDP contained within a 183 session progress message.
When the P-CSCF receives the 183 message, it now knows the QoS requirements and
can determine if it has enough resources within the IMS to support the call. If not it
will send a 580 precondition failure to the UE and a CANCEL to the S-CSCF. For the
example shown the QoS request is authorized and the 183 is forwarded to the UE. The
UA then uses the PRACK message to acknowledge the 183 response and this in return
gets a 200 OK from the remote user. The UE then proceeds to establish QoS suitable
for the call over the GPRS network. This could involve the UE negotiating a bandwidth
increase in the PDP context that it is already using for the SIP signalling. If the existing
GPRS connection is suf¬cient for the call then nothing further needs to be done at this
stage. Assuming the UE is successful in achieving QoS it will then send the UPDATE
message con¬rming this to the far end. If it fails, it must cancel the call. Note that the
200 OK messages for the PRACK and UPDATE messages are omitted on the diagram
for simplicity.
When the terminating UE receives the UPDATE message (and assuming all its local
QoS requirements are established) it will apply ringing to the destination. It sends the
180 ringing provisional response, which is sent using the reliable mode in UMTS and is
acknowledged with a PRACK, and 200 OK is sent in response to this message.
Finally, when the user at the far end answers the call, the 200 OK is sent for the
INVITE. When the 200 OK is received at the P-CSCF this then con¬rms the QoS request
and lets the call through by sending the 200 OK to the UE. At this point media can ¬‚ow
between the two parties and the ACK is sent to ¬nally acknowledge the 200 OK.



9.7.5 IMS mobile terminated call
Figure 9.30 shows the call ¬‚ow for a mobile terminated call. The call starts with the
INVITE request entering the home network for the subscriber at the I-CSCF. The I-CSCF
acting as an incoming proxy then interrogates the HSS, by sending a Cx location query
to the HSS. This request contains the public ID, which is extracted from the URI in the
INVITE message. The HSS now responds with a location response, which contains the
address of the S-CSCF with which the destination user is registered. If the user does not
exist then a 401 not found response will be returned. The I-CSCF then forwards the call
to the S-CSCF.
The S-CSCF looks up the registration entry for the destination, which contains the
contact details, including the UE IP address and serving P-CSCF address. It then forwards
the INVITE to the P-CSCF, which in turn forwards it to the UE.
The called UE responds with a session progress message, which is acknowledged with
PRACK. The called UE then proceeds to establish QoS for the GPRS connection. As
soon as it receives the UPDATE from the far end con¬rming the remote QoS, it alerts the
user and sends 180 RINGING. The user then answers the phone, generating a 200 OK
606 RELEASE 5 AND BEYOND (ALL-IP)


Originating Terminating Network
Network

S-CSCF I-CSCF HSS S-CSCF P-CSCF UE


INVITE
Cx location request
100 TRYING public id
Cx location answer
S-CSCF
INVITE
100 TRYING

Evaluation filter criteria
INVITE
100 TRYING
INVITE
183 SESSION
PROGRESS
Authorise QoS resources
183 SESSION
183 SESSION PROGRESS PROGRESS
183 SESSION
PROGRESS
PRACK
PRACK
PRACK
PRACK
UPDATE Resource
UPDATE
UPDATE reservation
UPDATE
180 RINGING
180 RINGING
180 RINGING
180 RINGING
PRACK
PRACK
PRACK
PRACK
200 OK
(INVITE)
Approval of QoS commit
200 OK
200 OK (INVITE)
200 OK (INVITE)
(INVITE)
ACK
ACK
ACK
ACK



Figure 9.30 Mobile terminated call

message, which is also used to trigger the P-CSCF into enabling the QoS over the GPRS
network. Once again, the 200 OK messages for the PRACK and UPDATE messages are
omitted from the diagram for simplicity.



9.7.6 QoS reservation for IMS calls
The QoS reservation decisions for the network are based on two criteria, resources and
policy. The resource criterion is simply stated as whether the network has enough capacity
to accept this call. For the policy criterion the question is, does the network wish to allocate
this subscriber this much bandwidth at this point in time? Resource decisions must be
made locally at the point of control within the network, so the RNC controls resources
in the RAN, the SGSN resources in the GPRS core, etc. Policy decision can be more
9.7 UMTS IMS CALL SIGNALLING 607


centralized; in the case of the IMS it is carried out by an entity called the policy decision
function (PDF). The PDF may be co-located with the P-CSCF and this is a logical choice
since it will be the closest SIP point of contact for the UE within the IMS.
Three procedures for QoS control were shown in Figures 9.29 and 9.30; they are;

• authorize QoS resources at the P-CSCF
• resource reservation at the UE
• approval of QoS commit.

The ¬rst of these steps is always carried out near the beginning of a call as soon as
the ¬rst 183 session progress message has been received at the P-CSCF. At this point in
the call the CODEC and bandwidth requirements will have been agreed, and therefore
the PDF can make a decision as to whether there are suf¬cient resources within the IMS
network (not the GPRS or access network) to handle the call. As soon as the resources
are reserved the session progress message can be forwarded to the UE.
At this stage the resource reservation at the UE can proceed. This is shown in Fig-
ure 9.31. First the UE uses the bandwidth requirements given in the SDP portion of the
SIP response to generate an activate PDP context request. This is sent to the SGSN,
and assuming the SGSN is able to ful¬l this request, it then sends a create PDP context


P-CSCF
UE SGSN GGSN UE
PDF

INVITE
100 TRYING
INVITE
183 SESSION
PROGRESS
Authorise QoS resources
183 SESSION PROGRESS
PRACK
PRACK
GPRS Activate PDP
GPRS Create PDP
context request COPS REQ
context request
(PDP context)
COPS DEC
GPRS Create PDP (Policy info)
GPRS Activate PDP context response
context accept UPDATE
UPDATE
180 RINGING
180 RINGING
PRACK
PRACK
200 OK (INVITE)
COPS DEC
(Open gate)
COPS REP
(Outcome)
200 OK (INVITE)
ACK
ACK


Figure 9.31 QoS establishment for IMS calls
608 RELEASE 5 AND BEYOND (ALL-IP)


message to the GGSN. The GGSN now needs policy information to decide on whether
to allow the PDP context or not. It sends a request using the COPS REQ message to
ask the PDF for a policy decision as regards the creation of the PDP context. The PDF
knows which SIP call the QoS request relates to by the use of an authorization token.
This is a unique value which the P-CSCF generates for each new call. It adds this value
to the P-Media-Authorization header in the INVITE or 183 messages that are terminated
at the UE. The policy information returns a decision accepting or rejecting the creation
of the PDP context. Note at this stage, IP traf¬c for the given context may not be passed
over the GGSN between the IMS and the GPRS core network. The GGSN then con¬rms
the creation of the PDP context to the SGSN, which in turn con¬rms this to the UE. At
the same time the GGSN sends a COPS REP message to the PDF con¬rming the creation
of the PDP context. The call then proceeds in the standard manner until the 200 OK
for the INVITE is received at the P-CSCF. At this point the PDF sends a COPS DEC
message con¬rming the use of the resources at the GGSN. The GGSN will then proceed
to forward traf¬c between the two networks for the newly created context. This request
is called a gate open. The GGSN then reports back the status of the newly opened gate
to the PDF. Note that throughout all these exchanges the authorization token is used to
bind the SIP call to the PDP context.


9.7.7 IMS accounting
Accounting is an essential service within any commercial network operation. Network
usage must be monitored and accounting records produced so to be able to produce
the correct customer billing information. Accounting functions must be carried out at
two different points: the home and visited network. The collating of accounting infor-
mation within the IMS is performed by a network entity called the charging collection
function (CCF). This is essentially a DIAMETER server which responds to accounting
control messages.
The procedure is essentially as follows. Each P-CSCF and S-CSCF forwarding a 200
OK in response to an INVITE sends a request to the accounting server within their domain
to open a CDR. At the end of the call when the BYE is sent the P-CSCF and S-CSCF
send requests to update then close the CDR.


9.7.8 Common open policy service (COPS)
Whenever QoS is requested on a network two decisions have to be made. First, are
there enough network resources to satisfy the request? This decision is decided locally
by individual network elements, for example a GGSN providing GPRS connectivity into
the IMS. The GGSN will determine if enough network resources are available to satisfy
the request. The second is called the policy decision and this takes into account factors
such as the user™s service pro¬le, time of day or even if they have enough credit on their
account to decide whether to accept or reject the QoS request. In most networks it makes
sense to take the policy decision at a single central point since subscriber data will be
stored centrally in some database.
9.8 IP IN THE RADIO ACCESS NETWORK (RAN) 609


The COPS model for policy control (RFC 2748) uses this arrangement and requires
two main components, PEP and PDP. The policy enforcement point (PEP) is the network
element which receives the QoS request from the user and is responsible for enforcing

<<

. 123
( 132 .)



>>