System Information Broadcast: the UE reads the system information broadcasted periodically in every LTE cell (only one is illustrated in the call flow). This provides the UE with the cell information. The UE passively listens to the broadcast information and determines the signal strength.
MAC Access: After the UE has selected an LTE cell for access, the UE initiates/performs the Random Access Channel (RACH) procedures as defined in TS 36.321.
RRC Connection Request: sent from the UE to the eNB. The purpose of this request is to establish an RRC connection. The RRC connection establishment involves an SRB1 setup. Details of the RRC Connection establishment procedure can be found in Section 5.3.3 of TS 36.331.
RRC Connection Setup: sent by the eNB to the UE. Upon receipt, the UE performs the radio resource configuration.
RRC Connection Setup Complete (Attach Request): sent by the UE to the eNB. The Attach Request is included in the NAS-dedicated information of the RRC Connection Setup Complete message. The request includes the IMSI such that a separate Identity Request / Response message exchange between the UE and the MME (in order to obtain the IMSI from the UE) is not required. The request furthermore includes the PCO indicating the PDN type.
Initial UE Message (Attach Request): sent by the eNB to the MME. The Attach Request is carried to the MME within the NAS-PDU part of an Initial UE Message. The NAS-PDU furthermore contains a PDN Connectivity Request. The information received is used later by the MME when initiating the establishment of the Default EPS bearer (see also the Create Session Request message below).
Authentication Information Request (AIR): sent by the MME to the HLR/HSS. This message initiates the user authentication by requesting an Authentication Vector from the HLR/HSS. The AIR request includes the IMSI received from the UE to identify the subscriber. It also includes the Visited PLMN Identifier. The details of the AIR are described in Section 7.2.5 of TS 29.272.
Authentication Information Answer (AIA): sent by the HLR/HSS to the MME. The AIR contains the Authentication Vector requested by the MME with the AIR. The Authentication Vector (RAND, XRES, AUTN, KASME) is used for the authentication of the UE. It can be found in the Authentication-Info part of the AIA. The details of the AIA are described in Section 7.2.6 of TS 29.272.
Downlink NAS Transport (Authentication Request): sent by the MME to the eNB to request the authentication of the UE. The NAS-PDU carries the authentication request including the EPS challenge (RAND, AUTN).
Downlink Information Transfer (Authentication Request): sent by the eNB to the UE. Upon receipt of the Authentication Request from the MME, the eNB forwards the request to the UE.
Uplink Information Transfer (Authentication Response): sent by the UE to the eNB. Upon receipt of the EPS challenge from the eNB/MME, the UE computes the response (RES) for the EPS challenge in order to authenticate the UE. The RES parameter is transferred via the eNB to the MME.
Uplink NAS Transport (Authentication Response): upon receipt of the Authentication Response by the eNB, the eNB forwards the response to the MME. The NAS-PDU of the message includes the authentication response (RES) of the UE. The MME then performs the actual authentication. The UE is successfully authenticated when RES matches XRES.
Downlink NAS Transport (NAS Security Mode Command): sent by the MME to the eNB. In order to request the NAS security support (integrity- and confidentiality protection (ciphering)), the MME sends the NAS Security Mode Command via the eNB to the UE. The request specifies the NAS integrity- and ciphering algorithms based on the UE capabilities received by the MME in the Attach request (step 6).
Downlink Information Transfer (NAS Security Mode Command): upon receipt of the NAS Security Mode Command by the eNB, the request is passed on to the UE.
Uplink Information Transfer (NAS Security Mode Complete): send by the UE via the eNB to the MME. This response messages acknowledges the NAS Security Mode Command request received (via the eNB) from the MME.
Uplink NAS Transport (NAS Security Mode Complete): upon receipt of the NAS Security Mode Complete by the eNB, the request is passed on to the MME. After the successful enabling of the NAS security support, the subsequent message exchange is protected (integrity and ciphering).
Update Location Request (ULR): sent by the MME to the HLR/HSS. The request includes the identity of the MME, the IMSI, the ME Identity, MME capabilities, etc. The MME identity is stored in the HLR/HSS and identifies the MME as the current registrar of the UE. The S6a interface between the MME and the HLR/HSS is described in 3GPP
TS 29.272.
Update Location Ack (ULA): sent by the HLR/HSS to the MME to acknowledge the ULR. The ULA message returns the subscription data of the user to the MME. The subscription data contains one (or more) PDN subscription context (one for each APN that the UE is allowed to connect to) including the QoS parameters for the default EPS bearer.
Create Session Request: sent by the MME to the Serving GW. This request initiates the establishment of a default EPS bearer. The message includes the following parameters: IMSI, MSISDN, ME Identity, User Location Info, RAT type, APN, PDN type, APN-AMBR, PDN GW address, default EPS Bearer QoS, PCO, etc. The message details can be found in 3GPP TS 29.274 (GTPv2-C description).
Create Session Request: sent by the Serving GW to the PDN GW. Upon receipt of the Create Session Request, the Serving GW creates a new context entry into the EPS bearer table. Afterwards, it sends a Create Session Request to the PDN GW whose address it received in the request.
CCR (IP CAN Session Establishment Request): if dynamic PCC is supported (in Test Phase 2), then the PDN GW sends a Credit Control Request (CCR) with the CC-Request type set to Initial-Request via the Gx interface to the PCRF. This is to request the PCC authorization. The request includes the IMSI, APN, the Bearer QoS, etc. See also Section 7.2 of 3GPP standard TS 23.203. The PCRF may download the user profile from the SPR/HSS by sending an Sh UDR and receiving an Sh UDA including the user’s policy profile. The Sh UDR/UDA are not shown in the above call flow.
CCA (IP CAN Session Establishment Acknowledgement): the Credit Control Answer (CCA) is sent by the PCRF to the PDN GW to acknowledge the CCR (IP CAN Session Establishment Request). The message returns the Default-EPS-Bearer-QoS, Bearer-Control-Mode, Event Triggers, etc. to the PDN GW (PCEF).
Create Session Response: sent by the PDN GW to the Serving GW. This acknowledges the Create Session Request.
Create Session Response: sent by the Serving GW to the MME. This acknowledges the Create Session Request.
Initial Context Setup Request (Attach Accept): sent by the MME to the eNB. The Attach Accept is transferred in the NAS-PDU of the Initial Context Setup message. It includes the parameters: MME-UE-S1AP-ID, eNB-UE-S1AP-ID, UE-AMBR, E-RAB-to-be-Setup-list, UE Security-Capabilities, Security-Key.
UE Capability Enquiry: sent by the eNB to the UE. This message is triggered by the Initial Context Setup Request received from the MME (see the trigger condition described in Section 5.11.2 of TS 23.401). As part of the UE Radio Capability Information Procedure, the eNB requests the UE Radio Capability from the UE and uploads it to the MME in the S1 interface UE Capability Info Indication message (see below). The actions related to the UE Capability Handling (Enquiry- / Information message) are described in Section 5.6.3 of TS 36.331.
UE Capability Information: sent by the UE to the eNB. This message is used by the UE to inform the network about the UE Radio Capability information. It contains information on the RATs that the UE supports (e.g., frequency bands, features). This information is passed by the eNB to the MME.
UE Capability Info Indication: sent by the eNB to the MME. The MME stores the UE Radio Capability Information received with this message. The reported UE radio Capabilities include pdcp-Parameters (e.g., ROHC support), phyLayerParameters, rf-Parameters, measParameters (e.g., Frequency Band Information), featureGroupIndicators (e.g., Radio Bearer support (SRB1, SRB2 for DCCH + 8xAM DRB)). See Section 5.11.2 of TS 23.401 for a description of the general behavior.
RRC Connection Reconfiguration (Attach Accept): sent by the eNB to the UE. This includes the EPS Radio Bearer Identity and the Attach Accept message. The APN is also provided to the UE to notify the UE of the APN for which the Default EPS Bearer has been established. The UE may change the radio resource configuration. See also Section 5.3.5 of TS 36.331.
RRC Connection Reconfiguration Complete: sent by the UE to the eNB to acknowledge the RRC Connection Reconfiguration request.
Initial Context Setup Response: sent by the eNB to the MME. It includes the MME-UE-S1AP-ID, eNB-UE-S1AP-ID, E-RAB-Setup-List, etc.
Uplink Direct Transfer (Attach Complete): the UE sends an Uplink Direct Transfer message to the eNB. This includes the Attach Complete message in the ESM message container. The Attach Complete message includes the EPS Bearer Identity, etc.
Uplink NAS Transport (Attach Complete): the eNB forwards the Attach Complete message received from the UE to the MME. It is carried in the NAS-PDU of the Uplink NAS Transport message. In total, the UL NAS Transport message includes the following content: MME-UE-S1AP-ID, eNB-UE-S1AP-ID, NAS-PDU, E-UTRAN CGI, and the TAI.
Modify Bearer Request: upon receipt of the Attach Complete indication from the eNB, the MME sends a Modify Bearer Request to the Serving GW. A prerequisite for this is that the MME has also received the Initial Context Response (step 31). The Modify Bearer Request includes for example the EPS Bearer ID, eNB F-TEID, etc. Note that the Serving GW does not forward the Modify Bearer Request to the PDN GW (this is only done in the case of a handover from a non-3GPP access).
Modify Bearer Response: upon receipt of the Modify Bearer Request message, the Serving GW sends a Modify Bearer Response message back to the MME. This acknowledges the Modify Bearer Request.
Note that the Notify Request / Response exchanged after the Modify Bearer Response in the LTE Attach procedure in Section 5.3.2 of TS 23.401 only applies in the case of non-3GPP access support.
CCR (IP CAN Session Establishment Request): if dynamic PCC is supported (in Test Phase 2), then the PDN GW sends a Credit Control Request (CCR) with the CC-Request type set to Initial-Request via the Gx interface to the PCRF. This is to request the PCC authorization. The request includes the IMSI, APN, the Bearer QoS, etc. See also Section 7.2 of 3GPP standard TS 23.203. The PCRF may download the user profile from the SPR/HSS by sending an Sh UDR and receiving an Sh UDA including the user’s policy profile. The Sh UDR/UDA are not shown in the above call flow.
CCA (IP CAN Session Establishment Acknowledgement): the Credit Control Answer (CCA) is sent by the PCRF to the PDN GW to acknowledge the CCR (IP CAN Session Establishment Request). The message returns the Default-EPS-Bearer-QoS, Bearer-Control-Mode, Event Triggers, etc. to the PDN GW (PCEF).
SIP Register: sent by the UE to the P-CSCF via the Gm-interface. This message initiates the registration of the UE in the IMS.
SIP Register: sent by the P-CSCF to the I-CSCF via the Mw-interface. The I-CSCF address is resolved by the P-CSCF via DNS SRV. For this, the P-CSCF uses the domain name found in the R-URI of the SIP Register message. Note that the I-CSCF and S-CSCF are co-located in the example call flow.
User Authorization Request (UAR): sent by the I-CSCF to the HSS via the Cx-interface. This is to query the IMS Registration Status of the user from the HSS, which is why the UAR/UAA is also denoted as IMS Registration Status Query. The Public-Identity-AVP carries the IMPU (IMS Public User ID) that identifies the user. The User-Name-AVP carries the IMPI (IMS Private User ID) which can be viewed as an identification of the specific device of the user. A description of the UAR/UAA parameters can be found in Section 6.1 of TS 29.228.
User Authorization Answer (UAA): sent by the HSS to the I-CSCF to answer the UAR. Since the user is not registered in the HSS (Initial Registration), the UAA message returns the Server Capabilities (in the Server-Capability-AVP) used afterwards by the I-CSCF to select an appropriate S-CSCF for the user being registered. Once the I-CSCF has selected the S-CSCF, it forwards the SIP Register message to the S-CSCF (this is not shown in the call flow because the I-CSCF and S-CSCF are co-located on the same system in the example deployment).
Multimedia Auth Request (MAR):sent by the S-CSCF to the HSS via the Cx-interface. This message is used to request authentication information from the HSS. The SIP-Authenticate-Scheme-AVP in the request indicates the user authentication scheme used, which is “SIP Digest” in this scenario (the HSSc supports the 3GGP R9 compliant HTTP Digest authentication from NSN IMS7.2 release onwards).
Multimedia Auth Answer (MAA): sent by the HSS to the S-CSCF to answer the MAR. The message returns the information needed by the S-CSCF for the authentication of the UE (for HTTP Digest, the relevant parameters are Digest-Realm-AVP, Digest-Algorithm-AVP, Digest-QoP-AVP, Digest-HA1-AVP). A description of these parameters can be found in Section 6.3 of TS 29.228. In short, HTTP Digest is a challenge/response authentication scheme, in which the S-CSCF sends a challenge to the UE that needs to be responded appropriately by the UE based on the pre-configured shared secret (password).
SIP 401 Unauthorized: sent by the S-CSCF to the I-CSCF and from there to the P-CSCF. The WW-Authenticate header included in the SIP 401 message contains the authentication challenge (nonce) to be answered by the UE.
SIP 401 Unauthorized: sent by the P-CSCF to the UE. When the UE receives the message, it computes the HTTP Digest response for the challenge (nonce) received in the SIP 401 message. This uses the MD5 algorithm.
SIP Register: sent by the UE to the P-CSCF. The Authorization header in the SIP Register message is used to transfer the HTTP Digest response (response) from the UE to the P-CSCF.
SIP Register: sent by the P-CSCF to the I-CSCF.
User Authorization Request (UAR): sent by the I-CSCF to the HSS via the Cx-interface. See also the description of the UAR in step 3 above.
User Authorization Answer (UAA): sent by the HSS to the I-CSCF to answer the UAR. To ensure that the received SIP Register message is forwarded to the same S-CSCF that was selected for the Initial SIP Register message, the HSS returns the S-CSCF address in the Server-Name-AVP to the I-CSCF. The I-CSCF then forwards the SIP Register message to the S-CSCF (this is not shown in the call flow because the I-CSCF and S-CSCF are co-located on the same system in the example deployment. Upon receipt of the SIP Register, the S-CSCF verifies the Digest response found in the SIP Authorization header. If correct, then the user is successfully authenticated. If not, then the registration request is rejected using an error message.
Server Assignment Request (SAR): sent by the S-CSCF to the HSS via the Cx-interface. The key tasks performed with the SAR/UAR procedure are: 1) to assign an S-CSCF to an IMPU after the user has been successfully authenticated and 2 to download the user profile from the HSS to the S-CSCF. The S-CSCF name assigned is carried in the Server-Name-AVP in the SAR. The description of the SAR/SAA parameters can be found in Section 6.1.2 of TS 29.228.
Server Assignment Answer (SAA): sent by the HSS to the S-CSCF to respond to the SAR from the S-CSCF. The User-Data-AVP in the SAA includes the user profile downloaded with this message from the HSS to the S-CSCF.
SIP 200OK: sent by the S-CSCF via the I-CSCF to the P-CSCF via the Mw-interface. This message answers the SIP Register message received earlier in step 9 from the UE.
SIP 200OK: the P-CSCF forwards the SIP 200 OK received from the I-CSCF/S-CSCF back to the UE via the Gm-interface. This completes the authentication of the UE.
AA-Request (AAR): sent by the P-CSCF to the PCRF via the Diameter based Rx-interface. This request is made by the P-CSCF to subscribe at the PCRF for Notifications of the Signaling Path Status as described in Section 4.4.5 of TS 29.214. The Specific-Action-AVP of the AA-Request indicates/requests the subscription (e.g., INDICATION_OF_LOSS_OF BEARER / INDICATION_OF_RELEASE_OF_BEARER). In the case that the LTE signaling bearer is lost (LOSS_OF BEARER) or released (RELEASE_OF BEARER), then the PCRF will indicate this event to the P-CSCF using an RAR message (Rx-interface). Note that this feature is not supported in Phase 1.
AA-Answer (AAA): sent by the PCRF to the P-CSCF to acknowledge subscription to the notification of the signaling path status made with the AAR (in step 17).
SIP Register: sent by the S-CSCF to the Voice Application Server (the NVS in the example above) via the ISC-interface. It can be sent any time after the SIP 200 OK (in step 15). This message is used to inform the Application Server about the IMS registration of the user. This procedure is called 3rd Party Registration. In the case that the user has several application servers in its user profile, the S-CSCF sends a separate SIP Register message to each of them (this requires an Initial Filter Criteria for each application server in the IMS User Profile of the user).
MAP Update Location Request: sent by the NVS Voice Application Server to the HLR via the D-interface. This procedure is used by the NVS to retrieve the Supplementary Service Data from the HLR. The Location Update procedure is described in Section 8.1.2 of TS 29.002.
MAP Insert Subscriber Data Request: sent by the HLR to the NVS Voice Application server via the D-interface. This request carries the Supplementary Service Data from the HLR to the NVS. The Insert Subscriber Data procedure is described in Section 8.8.1 of TS29.002.
MAP Insert Subscriber Data Ack: sent by the NVS to the HLR to acknowledge the MAP Insert Subscriber Data Request received from the HLR.
MAP Update Location Ack: sent by the HLR to the NVS to acknowledge the MAP Update Location Request received earlier (in step 20) from the NVS Voice Application Server.
SIP 200 OK: sent by the NVS Voice Application Server to the S-CSCF via the ISC-interface. This messages successfully acknowledges the SIP Register request received earlier (in step 19) from the S-CSCF.
SIP Subscribe (Reg-Event): sent by the P-CSCF to the S-CSCF via the Mw-interface. This request is used by the P-CSCF to subscribe at the S-CSCF (the Registrar) for the Registration Event Package defined in RFC3680. The SIP Subscribe includes the Event header indicating the name of the package “reg”. This procedure can be initiated at any time after the successful user authentication (SIP 200 OK in step 16). The Registration Event Package is useful because it enables the support of additional network procedures (e.g., the Network Initiated De-Registration). Note that the NCS Client (in the UE) used in the example deployment does not yet support the Registration Event Package.
SIP 200 OK: sent by the S-CSCF to the P-CSCF via the Mw-interface. This message successfully acknowledges the SIP Subscribe (Reg-Event) request.
SIP Notify (Reg-Event): sent by the S-CSCF to the P-CSCF via the Mw-interface. Upon receipt of the subscription request for the Registration Event Package, the S-CSCF generates a notification (SIP Notify with Event header indicating “reg”) that reports the current status to the P-CSCF. Since the UE has just been successfully registered, the SIP Notify message includes the event ”registered” in the application/reginfo+xml message body.
SIP 200 OK: sent by the P-CSCF to the S-CSCF via the Mw-interface. This message acknowledges the SIP Notify request received earlier (in step 27) at the P-CSCF.
UE-A initiates the call based on user input. The SIP INVITE contains the SDP offer. The B-party address is based on user input. The INVITE is sent to the same P-CSCF used at registration time.
The P-CSCF includes the identity of the A-party in the P-Asserted Identity header field based on registration information (SIP-URI). The P-CSCF also generates an ICID and adds it in a P-Charging-Vector header filed. In order to stay in the call path for subsequent requests, the P-CSCF inserts a Record-Route header field. The P-CSCF forwards the INVITE to the S-CSCF. Note: If the P-CSCF is a B2BUA (like the ACME SBC), it will not use the Record-Route header field defined for SIP proxies.
Note: If HTTP digest is used and the UE does not provide credentials right away, then the S-CSCF will challenge the UE (depending on configuration) with a “407 Proxy Authentication” required response. This and the related ACK message are not shown in the call flow. The S-CSCF performs originating service control and invokes the NVS. In order to stay in the call path for subsequent requests, the S-CSCF inserts a Record-Route header field. It usually also adds a P-Asserted Identity header field for the tel-URI. An example how this message could look like:
INVITE sip:+443399300017@ims20.fmc.so.noklab.net;user=phone SIP/2.0
Via: SIP/2.0/TCP 10.20.76.143:5090;branch=z9hG4bK_IMSCA0720354.000_ad9c60bfe120008a8e791751c2e206e401;lskpmc=S0J
Record-Route: P-Asserted-Identity: Via: SIP/2.0/TCP 10.20.76.143:5070;branch=z9hG4bK_IMSCA0720354.000_d93edb6d6c493cb2cd590c16f7556a0b;lskpmc=P0R Record-Route: Via: SIP/2.0/TCP 10.22..154;branch=z9hG4bKm461UmaB3rg7j Max-Forwards: 68 From: "+443399400046" To: Call-ID: 9084743e-878f-122e-2980-39a48cb53b8d CSeq: 6127520 INVITE Contact: Accept-Contact: *;+g.3gpp.icsi-ref=urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel User-Agent: Communication Suite 5.0.0.8519 sofia-sip/1.12.9 Allow: REFER,INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,MESSAGE,SUBSCRIBE,NOTIFY,UPDATE,INFO Supported: 100rel,precondition,timer Session-Expires: 3600 Min-SE: 90 Content-Type: application/sdp Content-Disposition: session Content-Length: 365 P-Asserted-Identity: P-Charging-Vector: icid-value=133d3298a1067b832c35fca6cc169b9a P-NokiaSiemens.Session-Info: corrID=9084743e-878f-122e-2980-39a48cb53b8d; originator= P-com.Siemens.Access-Information: GGSN P-com.Siemens.MSISDN-ID: 443399400046P-com.Siemens.IMSI-ID: 234999410000046 P-com.Siemens.Corr-ID: ad9c60bfe120008a8e791751c2e206e401,9084743e-878f-122e-2980-39a48cb53b8d P-Served-User: Route: Route: v=0 o=- 28100 1 IN IP4 10.22..154 s=- c=IN IP4 10.22..154 t=0 0 m=audio 31172 RTP/AVP 97 96 98 8 0 18 101 a=rtpmap:97 AMR-WB/16000 a=fmtp:97 mode-change-capability=2 a=rtpmap:96 AMR/8000 a=rtpmap:98 iLBC/8000 a=fmtp:98 mode=30 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 After executing potential originating services, the NVS returns the call to the S-CSCF based on the Route header information in message 3. If the B-party address in the request-URI is phone number based, but not in international format, the S-CSCF converts the telephone number to international format. As the B-party number is a telephone number, the S-CSCF performs an ENUM query for the B-party number. The ENUM server returns as SIP-URI the B-party address, which is the IMPU of B. Using the ENUM result as (potentially new) request-URI, the S-CSCF follows the procedures in RFC 3263 to identify the B-party I-CSCF. The S-CSCF forwards the INVITE – again with a record-route header field. The I-CSCF queries the HSS with the IMPU of B … ... and receives the S-CSCF name of the B-party S-CSCF in the LIA response. The I-CSCF forwards the INVITE to the S-CSCF. The S-CSCF performs terminating service control and invokes the NVS. In order to stay in the call path for subsequent requests, the S-CSCF inserts a Record-Route header field. - 16. The NVS interrogates the HLR. After executing potential terminating services, the NVS returns the call to the S-CSCF based on the Route header information in message 12. The S-CSCF replaces the request-URI by the contact of B from the registration. It adds a P-Called-Party header with the Request-URI it received in message 17. In order to stay in the call path for subsequent requests, the S-CSCF inserts a Record-Route header field. The message is forwarded to the P-CSCF of B, which is known from the service route discovery at registration. After removing information not sent to the UE, the P-CSCF forwards the INVITE to UE-B. - 30. The B-party user is alerted and a “180 ringing” response is returned along the same path as the INVITE (in opposite direction, obviously). - 41. The B-party user answers the call. A 200 OK response is sent along the same path as the 180. The 200 OK message contains the SDP response. - 50. The ACK message acknowledges the receipt of the 200 OK by the A-party. It is sent along the route established at session initiation. SIP proxies, who did not “record-route”, are not in the path of the ACK, i.e. the I-CSCF is not in the path of the ACK or any subsequent request.下载本文
