Download Step 5 - Ning.com

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Piggybacking (Internet access) wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Zero-configuration networking wikipedia , lookup

I²C wikipedia , lookup

DomainKeys Identified Mail wikipedia , lookup

Real-Time Messaging Protocol wikipedia , lookup

Routing in delay-tolerant networking wikipedia , lookup

SIP extensions for the IP Multimedia Subsystem wikipedia , lookup

Transcript
限閱
IMS 架構與話務分析
網路管理維運資源中心
日期: 2013/07/25
IMS Function Layer
2
限閱
Access and border layer
3
限閱
限閱
4
Session control layer
5
限閱
限閱
6
Application layer
7
限閱
IMS Registration sequence
8
限閱
Registration sequence
9
限閱
限閱
Step 1:
The UE generates a REGISTER message and sends it to the entry point of the network: the P-CSCF.
In this message, the home network domain name is present and will be used to determine where to send the REGISTER message.
The REGISTER message contains:
Private user identity
Corresponds to an identity stored in the terminal
Public user identity
In URI format
Home network domain name
Request-URI
Terminal IP address
Step 2:
The P-CSCF uses a DNS request to translate the home network domain name into the IP address of the I-CSC.
10
限閱
Step 3:
The P-CSCF examines the home network domain name to discover the entry point (I-CSCF) in the home network (DNS look up).
The P-CSCF adds its own address into the REGISTER message and sends the message to the ICSCF with:
P-CSCF address/name
P-CSCF network identifier
Public user identity
Private user identity
Home network domain name
Terminal IP address
11
限閱
Step 4a:
The I-CSCF requests information related to the user registration status. It sends a User Authorization Request (UAR) diameter
message to the HSS.
The message contains the following data:
Public user identity
Private user identity
P-CSCF network identifier
The HSS checks the status of the subscriber, and if the subscription is not locked, the HSS checks the roaming
right, using the address of the P-CSCF from which the request is coming.
Step 4b:
The HSS sends a User Authorization Answer (UAA) diameter message to the I-CSCF and gives a list of S-CSCFs
available in the network with their capabilities
12
限閱
Step 5:
The I-CSCF selects one S-CSCF according to the capabilities of the UE and then forwards the REGISTER message to the S-CSCF.
The I-CSCF does a DNS lookup to find the selected S-CSCF address and sends the REGISTER message with:
P-CSCF address/name
P-CSCF network identifier
Public user identity
Private user identity
Home network domain name
Terminal IP address
The S-CSCF stores the P-CSCF address/name and the network ID.
13
限閱
Step 6a:
The S-CSCF sends a Server Assignment Request (SAR) diameter message in order to inform the HSS that it will be in charge of the subscriber
and to request the subscriber profile.
The S-CSCF sends:
Public user identity
Private user identity
S-CSCF name
Step 6b:
The HSS answers using the Server Assignment Answer (SAA) diameter message. This message contains the subscriber profile and especially
the initial filter Criteria (iFC) that define a set of triggers and ASs, in an ordered list, that the S-CSCF must contact.
These Filter Criteria are called initial because they are defined in the HSS subscriber profile.
Other Filter Criteria can be added to the S-CSCF by the AS: they are called subsequent Filter Criteria (sFC).
The HSS stores the S-CSCF name for that user and returns the user information. The S-CSCF stores this information.
14
限閱
Step 7:
The S-CSCF checks the iFC conditions. If any of them match, the S-CSCF contact by order the ASs.
Each AS returns a result in the body of the SIP 200 OK message.
Then the S-CSCF is able to generate the answer according to the result it receives from ASs.
Based on iFC, the S-CSCF sends the REGISTER message to the service control platform (AS).
Step 8:
The S-CSCF sends a 200 OK message to the UE and fills in the SIP message with a VIA parameter, to define
which item of equipment the message must pass through.
The response follows the same path as the REGISTER request, as described in the Via list
Steps 9 and 10:
The P-CSCF receives a 200 OK message. It stores the address of the S-CSCF in charge of the UE and forwards
the message to the UE.
15
IMS to IMS complete sequence
16
限閱
限閱
Steps 1 and 2
The originating User Equipment generates an INVITE message and inserts in the body of the message all the
codecs that the mobile supports.
It sends it to the P-CSCF registered during the registration phase.
A 100 Trying message is sent back to the mobile, to indicate that the network is processing the session.
The UE determines the complete set of codecs that it is capable of supporting for this session. It builds the
message body and sends an INVITE to the P-CSCF:
Public user identity (from)
Destination subscriber (to)
UE IP address (via)
17
限閱
Steps 3 and 4
The P-CSCF sends the Invite to the S-CSCF associated to the subscriber.
In the INVITE message, the P-CSCF adds its own address in the record-route header, in order to receive the
answers. It also adds charging parameters which will be discussed in chapter 5.
The P-CSCF adds itself to the via headers to make sure it receives the responses. The P-CSCF sends the
message to the next hop:
Charging parameters
P-CSCF address (record-route)
Public user identity (from)
Destination subscriber (to)
Step 5
The S-CSCF analyzes the message and evaluates the iFC. If a trigger to the AS is required, it forwards the
INVITE message to the AS.
The S-CSCF validates the service profile of this subscriber and invokes any applicable origination service logic.
18
限閱
19
限閱
Steps 6 and 7
The S-CSCF requests a DNS to determine the TISPAN network in charge of the subscriber and then sends the INVITE message to
the I-CSCF of this network.
In the INVITE message, the S-CSCF adds its own address in the via header, in order to receive the answers. It also adds charging
parameters.
The S-CSCF determines the network operator to whom the destination subscriber belongs. Using a DNS query, it determines the
address of the I-CSCF in charge of the destination network.
Charging parameters
P-CSCF address & S-CSCF address (record-route)
Public user identity (From)
Destination subscriber (to)
Step 8
The I-CSCF requests the address of the S-CSCF assigned to the destination subscriber, from the HSS.
The I-CSCF queries the HSS to find out the S-CSCF of the called user.
The HSS responds with the address of the current S-CSCF for the destination subscriber.
20
限閱
21
限閱
Steps 9 and 10
The I-CSCF transfers the message to the S-CSCF associated to the subscriber. In the INVITE message, the P-CSCF adds its own
address in the via header, in order to receive the answers. It also adds charging parameters which will be discussed in chapter 5.
The I-CSCF forwards the INVITE message to the S-CSCF that will handle the session termination and adds itsaddress in the via
header
Step 11 and 12
The S-CSCF transfers the message to the P-CSCF associated to the subscriber in its local database. The S-CSCF adds its own
address in the via header, in order to receive the answers.
The S-CSCF forwards the INVITE message to the next hop and adds its address in the via header.
Steps 13 and 14
The P-CSCF transfers the message to the subscriber for whom it has registered the address of his terminal in its local database.
The P-CSCF determines the address of the destination subscriber and forwards the INVITE message.
22
限閱
Step 15
The destination UE receives the INVITE message. This message contains the list of all supported codecs by the originating UE, in its
body. The destination UE compares this list with the list of codecs it supports and generates the SESSION PROGRESS message. It
puts the common codecs that both UE supports in the body of
this message.
The UE2 determines the complete set of codecs that it is capable of supporting for this session. It determines the intersection with those
appearing in the body of the INVITE message and sends back to the originator the resulting codecs in the message body
Step 16
The P-CSCF receives the SESSION PROGRESS message and requests to authorizes the QoS requested by the UE from the Service
Policy Decision Function (SPDF).
Then the P-CSCF transfers the message to the next hop defined in the via header and removes its address from the via header.
The P-CSCF authorizes the resources necessary for this session. It requests from the RACS to set the QoS needed for this session.
23
限閱
24
限閱
Steps 17 to 20
All the IMS/TISPAN items of equipment transfer the message to the next hop defined in the via header.
The response is forwarded up to the P-CSCF, passing through all the items of equipment defined in the via header.
Step 21
The P-CSCF receives the SESSION PROGRESS message and requests the Policy Decision Function (PDF) in order to authorize the
QoS requested by the UE. The PDF gives back an authorization token, in order to correlate the GPRS QoS with the IMS/TISPAN
QoS.
The P-CSCF authorizes the resources necessary for this session and requests a QoS authorization token from the PDF.
Step 22
The P-CSCF transfers the message to the UE in which the authorization token is placed.
The P-CSCF adds the authorisation-token and forwards the response to the UE.
25
限閱
26
限閱
Steps 23 to 28
The UE selects one codec and sets the QoS by doing a resource reservation. It includes the selected codec in the
PRACK message body.
The PRACK message is transferred to the destination UE using the session contexts present is each CSCF.
You can notice that the I-CSCF is not involved anymore in the session initiation.
Steps 29 to 34
The UE2 receives the PRACK message and acknowledges with a 200 OK message back to UE1.
In this message, the codec that must be used for the session is acknowledged and the resource reservation is done.
Steps 35 to 37
When the resource reservation is successfully completed, the UE1 sends an UPDATE request to the terminating
endpoint to acknowledge.
The UPDATE is forwarded, up to UE2.
27
限閱
28
限閱
Next step
The UE receives the UPDATE message and then it starts ringing. It sends a 200 OK message to the originating UE
in order to confirm that its resources reservation is completed.
The UE sends by the way a 180 Ringing message to notify the originating UE that it must generate a ring back
tone.
PRACK and 200 OK messages are exchanged in order to confirm that the 180 Ringing message has been received.
29
限閱
30
限閱
Steps 52 to 54
When the destination subscriber off hooks his phone, the UE generates a 200 OK message.
The P-CSCF applies the QoS negotiated previously and the UE starts the media flow.
The destination answers and sends a 200 OK to acknowledge the INVITE message.
The P-CSCF indicates that the resources reserved for this session should now be committed.
Steps 55 to 66
The 200 OK message is forwarded to the originating UE. The P-CSCF of this subscriber sets the QoS
negotiated.
The P-CSCF applies the QoS negotiated previously and the UE starts the media flow.
It sends an ACK message, in order to respond to the 200 OK message.
31
IMS to PSTN complete sequence
32
限閱
PSTN to IMS complete sequence
33
限閱