E2E VoLTE call flow : detach (UE-initiated)

The UE initiated detach procedure may occur when the UE is turned off or the UE needs to fall back from EPS services to non-EPS services or vice versa. Along with the detach procedure all the allocated resources are released and connections for signaling and bearer are disconnected.

The above figure shows the overall sequence of how the UE and the network releases related resources when the UE detaches. Upon receiving the detach request from the UE(1), the MME releases the EPS bearer context towards the S/PGW(2) and in turn, the bearer binding and the session binding is released over Gx and Rx(3,4). Apart from this procedure, the MME also releases the UE context towards the eNB(5) and the eNB releases RRC connection with the UE(6). Meanwhile, the IMS network is informed of bearer release from the PCRF and proceeds the release procedure of the SIP session(7).

I. EPS bearer release

Fig 1. Detach procedure - EPS bearer release

[1] The UE triggers the detach procedure from the LTE network by sending Detach Request towards the MME.

• Detach Type IE indicates the reason of detach procedure and where the UE is being detached from (i.e., EPS services only, non-EPS services only, both). In this example, the UE is being detached from the LTE network due to switch-off.
• EPS mobile identity IE is set to be GUTI when the UE has a valid GUTI. If the UE does not have the valid GUTI, the EPS mobile identity will be the IMSI.

The GUTI is a globally unique identifier of the UE. It is composed of the M-TMSI, PLMN-ID (MCC+MNC) and MMEI (MMEGI+MMEC). The M-TMSI is assigned by the MME when the UE attaches to the network and remain unchanged until the UE detaches from the network. The following shows the GUTI format and the sample message of Detach Request.

If it is the detach for EPS only or combined EPS/IMSI detach, the MME deactivates the EPS bearer context(s) for this UE locally and enter the state EMM-DEREGISTERED for this UE.

[2-3] The MME requests the S/PGW to delete the corresponding session by sending Delete Session Request. If there are multiple APNs that the UE was attached to, there will be multiple Delete Session Request, one for each APN. The message contains the list of EBIs to be deleted for each APN. In case of detach, all the EBIs belong to that APN shall be included.

Upon receiving the Delete Session Request, the SGW/PGW deactivates the EPS bearer context corresponding to the received EBIs of this UE. The bearer binding relation between EPS bearer and PCC rule is also released. The SGW/PGW responds with the Delete Session Response.

[4] The MME sends Detach Accept only if the Switch off parameter is not "Switch off". Otherwise, this transaction will be spared.

[5] The MME performs MME-initiated UE context release by sending UE Context Release Command to the eNB, which is to release the UE-associated logical connection. In this case, the message contains the cause value of "Detach". Upon receiving the UE Context Release Command, the eNB releases all related signaling and user data transport resources for the indicated UE by the UE S1AP ID.

[6-7] The eNB sends the RRC Connection Release to the UE. In case the RRC connection has not been released already, the RRC Connection Release will be sent as an Acknowledge Mode(AM). After releasing the RRC connection, the UE responds with the RRC Connection Release Complete.

NOTE Whether to use Acknowledge Mode (AM) or UnAcknowledge Mode(UM) is dependent on the requirements for the radio bearer such as packet loss, packet delay, etc. The basic difference between the UM and AM is that the UM would be compared with the UDP where re-transmission control is not provided, whereas the AM is more likely TCP. The detail for this technology may need to be referred to the radio expert.

[8] The eNB responds with the UE Context Release Complete to the MME and releases the S1 signaling connection. This step would be performed without necessarily waiting for the RRC Connection Release Complete from the UE. Upon receiving the UE Context Release Complete, the MME deletes any eNB related information.


II. IMS de-Registration

Once the GTP-C, S1-MME connection and the corresponding S1 bearers have been released, the network starts to release remaining resources and connections towards upstream.

Fig 2. Detach procedure - application level release

[9-10]  The PGW reports the event to the PCRF by sending Credit-Control-Request(CCR). The CCR contains the cause value set to be "TERMINATION-REQ". The "TERMINATION-REQ" is sent only when the IP-CAN session is terminated, i.e., detach. If there are multiple APNs to which the UE attaches, there will be multiple CCRs sent to the PCRF, one for each APN. The PCRF acknowledges with the Credit-Control-Answer(CCA).

[11-12] Upon receiving the CCR from the PGW containing the IP-CAN session termination event, the PCRF releases session binding relation between IP-CAN session and the corresponding AF-session and requests to release the Rx session by sending Abort Session Termination (ASR) to the P-CSCF. The message contains the Abort-cause value of "BEARER_RELEASED". The PCRF acknowledges with the Abort Session Answer (ASA).

[13] Upon receiving the CCR containing the cause value of "BEARER RELEASED", the P-CSCF performs de-registration procedure by sending the SIP REGISTER to the I-CSCF in the UE's home network with its Expires header set to zero. The P-CSCF performs a name-address resolution mechanism for P-Visited-Network-ID header to determine the address of the home network.

[14] The I-CSCF requests the registration state of the received Public User Identity to the HSS by sending the User-Authentication-Request(UAR) with its User-Authorization-Type set to "DE_REGISTRATION". The UAR contains the Public User Identity, Private User Identity, Visited Network Id, etc.

[15] The HSS determines if the user is currently registered and responds with the User-Authentication-Answer(UAA) with the corresponding S-CSCF name (i.e., Server-Name AVP). 

[16] The I-CSCF determines the address of the S-CSCF through the name-address resolution mechanism and sends the SIP REGISTER to that S-CSCF.

[17-18] Upon receiving the SIP REGISTER, the S-CSCF may trigger the 3rd-party de-Registration procedure towards the application server based on the iFC mechanism. On the other hand, the S-CSCF sends the Server-Assignment-Request(SAR) towards the HSS. In this example, the Server-Assignment-Type AVP is set to "USER_DEREGISTRATION_STORE_SERVER_NAME", which indicates that the give Public User Identity is no longer considered as registered and the HSS needs to keep the S-CSCF name after this action. 

[19-20] The 200 OK for the SIP REGISTER is sent towards the P-CSCF.

[21] The S-CSCF may send the SIP NOTIFY towards the UE to inform that the subscription has terminated. The body of the SIP NOTIFY includes the fact that the registration state has also been terminated. This SIP NOTIFY transaction is correlated with the subscription procedure that was done when the UE registered to this IMS network.

***

When it comes to IMS de-registration, it is supposed to happen before LTE attach in a normal situation and it would be a quite natural sequence considering the protocol stack. The UE shall release all the resources relating to applications before it detaches from the network. However, in this example, the UE performs LTE detach first and then the IMS Core initiates the IMS de-registration based on the bearer loss event reported from the PGW. This type of exceptional situation happens more often than not in reality. It can come from incomplete implementation of the VoLTE client in a UE or the UE might not be able to perform IMS de-registration for some reasons.

Red Mouse

REFERENCES

[1] 3GPP TS24.301, "Non-Access Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3", v12.4.0, Mar 2014
[2] 3GPP TS29.274, "3GPP Evolved Packet System (EPS); General Radio Packet Service (GPRS) Tunneling Protocol for Control Plane (GTPv2-C); Stage 3", v9.3.0, Jun 2014
[3] 3GPP TS23.401, "General Radio Packet Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", v12.4.0, Mar 2014
[4] 3GPP TS23.228, "IP Multimedia System (IMS); stage2", v11.4.0, Mar 2012
[5] 3GPP TS29.229, "Cx and Dx interfaces based on the Diameter Protocol; Protocol details", v12.6.0, Jun 2015
[6] 3GPP TS36.413, "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)", v13.0.0, Jun 2015

[7] Netmanias, "EMM Procedure 2. Detach", Jan 2014

VoLTE : UE initiated voice call release

When the VoLTE call session does exist, either one of users engaged in the call can release the call session by sending SIP BYE towards the IMS network in a normal case. The user's request comes to the IMS network and it makes a chain reaction from the IMS network to EPC and to the UE. The P-CSCF informs the release of the AF session (i.e., SIP session) to the PGW via the PCRF and the PGW initiates the release of allocated resources for that application. The following scenario shows the case where the user requested to end the voice call session.

[1-2] Upon request from the user, the UE sends SIP BYE towards the IMS network to release the existing SIP session.

• Call-ID header is a globally unique identifier of this SIP session. In this context, it will identify the SIP session to be released.
• Route header is a list of IP addresses of intermediary nodes which stays in the signaling path.
• P-Preferred-Identity header indicates the originating user's identity that is preferred by the user to be used.
• P-Access-Network-Info header includes the radio access technologies and cell id.

[3] The P-CSCF sends Session-Terminating-Request (STR) to inform the PCRF that the established session shall be terminated over Rx, which combines the AF session and the IP-CAN session. As a result of this procedure, the session binding between the AF session and the IP-CAN session is terminated.

[4] The PCRF requests to remove the corresponding PCC rule by sending the Re-Auth-Request (RAR) containing the Charging-Rule-Remove AVP to the PGW. In this example, there are two charging rules to be removed for RTP and RTCP as the voice media session is to be released.

[5-6] The PGW unbinds the PCC rules from the corresponding EPS bearer and responds with the Re-Auth-Answer (RAA) to the PCRF. The PCRF unbinds the AF session from the corresponding IP-CAN and responds with the Session-Termination-Answer (STA) to the P-CSCF.

[7] The PGW sends the Delete Bearer Request containing the EPS Bearer Id (EBI) towards the MME.

[8] The MME requests the eNB to deactivate the EPS bearer context by sending Deactivate EPS bearer context request, which is wrapped by the E-RAB Release Command and RRC Downlink Direct Transfer over S1AP and RRC respectively.

Upon receiving the E-RAB Release Command, the eNB releases allocated resources on Uu and S1 for the corresponding E-RAB(s).

[9-10] The eNB sends the RRC Connection Reconfiguration request to release the radio bearer. The UE releases allocated resources on Uu.

[11-12] The UE responds with the Deactivate EPS bearer Context accept to the MME and the eNB responds with the E-RAB Release Response to the MME.

[13] Upon receiving the E-RAB Release Response, the MME updates the ECM and EMM state of the UE and sends Delete Bearer Response to the SGW/PGW. The SGW/PGW releases allocated resources on S1 and S5.

Red Mouse

E2E VoLTE call setup(3/4) - Voice call setup

Once the IMS registration is successfully done between the UE and the IMS network, the user can make a VoLTE call. Upon request for voice call from the user, the VoLTE UE starts SIP signaling with the IMS core. The SIP messages are routed based on initial Filter Criteria (iFC) in the IMS Core and delivers SDP offer and answer to establish media session along with various SIP headers. As a consequence of the SIP signaling, a new dedicated EPS bearer is established between the UE and the SGW/PGW which is used to transfer voice media. The QoS of this new dedicated EPS bearer is defined by the PCC rules generated by the PCRF.

Introduction

While the SIP messages go through the default EPS bearer (QCI=5) towards the IMS core, the voice media path is established at the front-end NEs taking the role of IMS Application Level Gateway (IMS-ALG) and IM Access Gateway based on SDP negotiation. The following diagram shows the conceptual diagram of IMS-ALG and IMS Access Gateway model specified in 3GPP TS23.228. The IMS-ALG controls media resources and gating functions of the IM Access Gateway over Iq interface. It acts as a B2BUA and can modify the SDP and SIP headers of SIP messages if necessary. The IM Access Gateway executes the allocation and release of transport addresses, IP versioning and the media gating function under the control of the IMS-ALG.

Fig 1. IMS-ALG and IMS Access Gateway model

The following diagram shows how the media path is established. Upon request from the user for voice call setup, the UE sends VoLTE call setup request (i.e., SIP INVITE) to the IMS core with an SDP offer, which contains the allocated media information of the originating UE [A]. The IMS-ALG allocates media resource in the IM Access Gateway to which the originating VoLTE UE can access. The allocated media information at IM Access Gateway is sent back to the UE in the response as an SDP answer [a]. The IMS-ALG allocates additional media resource for the upstream, includes it in the SDP offer and sends it towards the remote IMS-ALG [B]. The IMS-ALG in the remote IMS network responds with the SDP answer containing the media access point of IM Access Gateway in the same network [b]. The IMS-ALG in the remote network also allocates another media resources and sends it to the UE as an SDP offer [C]. In turn, the UE will also send back the response including SDP answer of its own [c].

NOTE the gray arrow indicates the signaling path and the rest indicate the media path and its direction.

Fig 2. Media path establishment

NOTE The IM Access Gateway functionality is typically provided by Service Border Controller (SBC).

II. VoLTE call setup procedure

Upon request from the user for VoLTE call setup, the UE initiates SIP signaling with the IMS core. The P-CSCF address is informed to the UE when the UE attaches to the network. The signaling path beyond the P-CSCF is determined based on a routing mechanism of IMS core. The SDP negotiation is performed along with the SIP signaling and determines the media path for voice call setup.

Upon receiving call setup request (i.e., SIP INVITE), the P-CSCF informs the PCRF of the service data flow information. The PCRF triggers the Evolved Packet Core (EPC) to create a dedicated EPS bearer of QCI=1 for voice media by generating and provisioning PCC rules to the SGW/PGW. The PCC rules include QoS parameters and rules to be applied to service data flows based on which the SGW/PGW establishes mapping relations between service data flows and the EPS bearers.

NOTE Based on GSMA IR.92, the UE is strongly recommended to support the precondition framework for VoLTE. Please note that, in the following practice, the precondition procedure has been disabled before testing. Please refer to FCM.01, IR.92 and 3GPP TS 24.229 for the detail.

NOTE While the following procedure shows the only originating side, the same procedure and principles can also be applied to the terminating side. The signaling procedure handled within the IMS core has not been described to avoid complexities as it can vary based on the deployment architecture as per IMS vendor.

Fig 3. VoLTE setup call flow

[48] Upon request from the user to make a voice call, the originating UE sends the SIP INVITE towards the P-CSCF.

• Supported header: a list of option tags indicating supporting features. In this example, the "timer" and "100rel" indicate support of session timer and a reliable delivery of the provisional response (i.e., 183 Session In Progress), respectively.
• P-Early-Media header: indicator of whether the UE supports the early media mode.
• Allow header: a list of SIP methods that is supported by the UE.
• P-Preferred-Identity header: the originating user's identity that is preferred by the originating user to be used. This header is replaced with the P-Asserted-Identity header by the P-CSCF in the IMS network. If the SIP message is sent towards untrusted IMS core, the P-Asserted-Identity header shall be removed.
• User-Agent header: VoLTE client information
• Privacy header: preference of sending UE indicating that any sensitive information shall be hidden from any parties that do not need to know it.
• Accept-Contact header: a list of features of target UE preferred by the sending UE
• P-Access-Network-Info header: the radio access technology and cell identity.
• Session-Expires header: a valid period of time of this SIP INVITE session. The parameter “uac” indicates that the sending UE will refresh the session before the timer is expired.
• P-Preferred-Service header: service identification user wishes to be used. This header is replaced with the P-Asserted-Service header by the P-CSCF.
• Content-Type: media type of the message-body sent to the recipient.
• Route header: a list of IP addresses of intermediary nodes which the SIP request will go through. This would a copy of Service-Route header returned in 200 OK response to SIP REGISTER, which is inserted by the S-CSCF. The Service-Route header indicates the intermediary node associated with that S-CSCF.
• From header: sending user’s SIP URI or TEL URI
• To header: recipient’s SIP URI or TEL URI
• Call-ID header: a globally unique identifier of the SIP session. All the SIP messages of the same session must have the same Call-ID value.
• CSeq header: sequence of the same SIP method. The sequence number is incremented as the same SIP method is being sent.
• Max-Forwards header: maximum number of hops that the message can go through.
• Contact header: the contact address, device capabilities, feature-tags, etc. of the sending UE.
• Via header: a list of SIP addresses of intermediary nodes. The entry is inserted by each node that wants to stay in the signaling path for the SIP response. The response message for this request (e.g., 183 session in progress, 100 Trying, 200 OK, etc) will be transferred to the originating UE following the reverse path listed in this header.
• Content-Length: body length in bytes.

Fig 4. headers in SIP INVITE

The SIP INVITE contains an SDP offer. The SDP defines media information of the sending node which contains the contact ip address, port number and a list of supporting codec information. The following shows descriptions of each parameters used in SDP.

• ‘o’ (originator and session identifier): <username><session-id><network type><address type><ip address>
• ‘s’ (session name): any textual session name
• ‘c’ (connection data): <network type><address type><connection address>
• ‘t’ (timing): <start time><stop time>
• ‘m’ (media description): <media type><port><protocol><fmt: media format description>
• ‘b’ (bandwidth): AS (application specific) – maximum RTP session bandwidth (kbytes), RS – sending RTCP bandwidth (bytes), RR – receiving RTCP bandwidth (bytes)
• ‘a=rtpmap’ (attributes): <payload type><encoding name><clock rate><encoding parameters>
• ‘a=fmtp’(attributes): format specific parameters related with the corresponding media
• ‘a=ptime’(attributes): length of time represented by the media in a packet (ms)
• ‘a=maxptime’(attributes): maximum amount of media that can be encapsulated in each packet(ms)

The following is an SDP example included in the SIP INVITE captured on the Gm interface. The UE’s IP address is “100.64.63.41” and port number for audio is “1234”, which is depicted as [A] in Fig2.

Fig 5. Attributes in Session Description Protocol (SDP) offer

NOTE Upon receiving the SIP INVITE with an SDP offer, the P-CSCF may send service data information to the PCRF of which flow-status AVP set to ‘DISABLED’. In this case, the P-CSCF will send additional service data information when it receives the 183 Session In Progress with SDP answer. In the following example, the service data information is sent only once when the P-CSCF obtains SDP offer and answer all together at step #48.

The P-CSCF responds with a 100 Trying provisional response. The provisional response is a one-way response sent back to the originating side used as informative. It is not necessarily guaranteed for its safe arrival.

Fig 6. Parameters in 100 Trying

[49] The terminating UE locally allocates resources, generates the 183 Session In Progress along with SDP answer and sends it back towards the originating UE. The 183 Session In Progress arrives the originating S-CSCF following the reverse path of the SIP messages. The S-CSCF forwards it to the P-CSCF.

• Record-Route header: a list of IP addresses that is copied from the Route header by the terminating UE in the received SIP INVITE. The value of this header will be reused by the originating UE when it composes Route header upon sending subsequent SIP request.
• Require header: a list of option tags indicating features that needs to be supported by the recipient (i.e., the originating UE) of this message. In this case, the "100rel" indicates the originating UE shall support the reliable delivery of provisional response. 

NOTE the provisional response, 1xx, is an informative response therefore it does not usually require the reliable delivery. However, 183 Session In Progress would be an exception as it contains the SDP answer.

• RSeq header: the sequence number of this response. The value of this header is copied to the CSeq header in the following SIP PRACK sent by the originating UE.
• P-Asserted-Identity header : the authorized user's identity of the sending user of this message (i.e., the terminating user)
• P-Charging-Vector header: a collection of charging information, which consists of IMS Charging Identity (ICID) value, the address of the SIP proxy that creates the ICID value and the Inter Operator Identifiers (IOI). The ICID indicates a globally unique charging value that identifies a dialog, the IOI identifies both the originating and terminating networks involved in a SIP dialog. In the following example, the full text for the header is as follow:

icid-value=0.274.195-1418282284.647;term-ioi=32345;term-ioi=22345;icid-generated-at=10.75.0.5;term-ioi=Type3Term;orig-ioi=32345

Fig 7. Headers in 183 Session In Progress

[50] Upon receiving the 183 Session In Progress, the P-CSCF triggers the Authentication and Authorization Request (AAR) towards the PCRF to inform the fact that there is a new Application Focus (AF) session being created. The PCRF performs session binding between the AF session and the corresponding IP-CAN session.

NOTE AF indicates an element offering applications that require the Policy and Charging control of the user plane resources. In this context, it indicates the P-CSCF.

• Session-Id AVP: identifier of Rx session for this application. It lasts until this application (i.e., VoLTE session) does exist.
• AF-Application-Identifier AVP: identifier of the VoLTE call session assigned by the P-CSCF.
• Media-Component-Description AVP: media information of the service data flow
• Service-Info-Status AVP: the status of the service information that the P-CSCF is providing to the PCRF.
• FINAL SERVICE INFORMATION (0): the service has been fully negotiated between the two nodes and the provided service information is the result of the negotiation.
• PRELIMINARY SERVICE INFORMATION (1): the provided service information is a preliminary and further negotiation is to be needed between two nodes.

NOTE In this example, the value is set to be “FINAL SERVICE INFORMATION” as the P-CSCF has both SDP offer and answer.

• AF-Charging-Identifier AVP: identifier for charging correlation with bearer layer.
• Specific-Action AVP: a list of events that P-CSCF wants to be informed from the PCRF. The PCRF shall report to the P-CSCF when any of these events occurs.
• Subscription-Id AVP: identifier of the end user’s subscription. It holds subscription type and data. Multiple instances of the subscription-id indicates multiple type of identifiers of the same subscriber such as E164, SIP URI, IMSI, etc.
• Framed-IP-Address AVP: UE’s IP address which is allocated by the PGW during initial attach procedure.
• Required-Access-Info AVP: indicator of query by the P-CSCF for access network information.

Fig 8. AVPs in AAR

The Media-Component-Description AVP reflects the SDP offer and answer which includes the media type, direction and codec information.

• Media-Sub-Component AVP: descriptions for media flows. There are two sub components appears in this snapshot, one for RTP and the other one for RTCP.
• Flow-Description AVP: description for IP flow in each direction, of which IP addresses and port numbers are copied from the SDP offer and answer by the P-CSCF.
• Uplink IP flow: UE (“100.64.63,41”, “1234”) à SBC (“10.75.23.197”, “10570”)
• Downlink IP flow: SBC (“10.75.23.197”, “10570”) à UE (“100.64.63,41”, “1234”)
• Flow-Status AVP: permission status of each media flow.
• ENABLED-UPLINK (0): enable associated uplink IP flow(s) only.
• ENABLED-DOWNLINK (1): enable associated downlink IP flow(s) only.
• ENABLED (2): enable all associated IP flow(s)
• DISABLED (3): disable all associated IP flow(s)
• REMOVED (4): remove all associated IP flow(s)
• Media-Type AVP: the type of media stream e.g., audio, video, data, text, message.
• Max-Requested-Bandwidth-UL/DL AVP: the Maximum Bit Rate (MBR) of the IP flow in each direction. The bandwidth contains all the overhead coming from IP layer and the layer above e.g., IP, UDP, RTP, RTP payload.
• RS-Bandwidth AVP: maximum required bandwidth for RTCP sender reports.
• RR-Bandwidth AVP: maximum required bandwidth for RTCP receive reports.
• Codec-Data AVP: codec related information known at the P-CSCF.

Fig 9. Sub-AVPs of Media-Component-Description AVP

[51] Upon receiving the AAR, the PCRF generates PCC rules. PCC rules includes IP flow description for uplink and downlink (i.e., 5-tuple), QoS information, the flow status, etc. The SGW/PGW performs bearer binding between the received PCC rules and the corresponding IP-CAN bearer. The IP flow shall be mapped to a specific IP-CAN bearer based on these PCC rules by the SGW/PGW

• Charging-Rule-Definition AVP: A PCC rule. There are two PCC rules showing up for voice call, one for RTP and the other one for RTCP.
• Charging-Rule-Name AVP: A PCC rule name. It is uniquely defined within the same IP-CAN. If the PCC rule is pre-defined in PGW as is the case for default EPS bearer, it is uniquely defined within the PGW.
• Flow-Information AVP: a single IP flow packet filter. It includes the ip address and port number and the direction of the IP flow.
• Flow-Status AVP: permission status of each media flow. Refer to step#49 for the detail.
• QoS-Information AVP: QoS information to be applied to the IP flow, which includes QoS Class Identifier (QCI), GBR (Guaranteed Bit Rate), MBR (Maximum Bit Rate) and ARP (Allocation Retention Precedence).
• QoS-Class-Identifier AVP: QoS Class Identifier
• Guaranteed-Bitrate-UL/DL AVP: guaranteed for service data flow. The bandwidth contains all the overhead coming from the IP-layer and the layers above e.g., IP, UDP, RTP and RTP payload.
• Max-Requested-Bandwidth-UL/DL AVP: the Maximum Bit Rate (MBR) of the IP flow in each direction. The bandwidth contains all the overhead coming from IP layer and the layer above e.g., IP, UDP, RTP, RTP payload.
• Allocation-Retention-Priority AVP: The priority of allocation and retention. When a new media resource is required to be allocated and all the resources are already occupied, the PGW can release the allocated media resource and re-allocate it for the new IP flow based on this value.
• Precedence AVP: the order of applying the service data flow template consisting of service data flow filters to the service data flow at PGW.
• Flows AVP: Indicator of the IP flow to which this PCC rule is to be applied.

Fig 10. AVPs of RAR

[52] The SGW/PGW initiates the EPS bearer creation procedure and responds with the Re-Auth-Answer (RAA) to the PCRF.

• Access-Network-Charging-Address AVP: IP address of the network entity within the access network performing charging.
• 3GPP-SGSN-MCC-MNC AVP: MCC and MNC of the access network.
• 3GPP-User-Location-Info AVP: UE’s current location. It is composed of Tracking Area Identity (TAI) and E-UTRAN Cell Global Identifier (ECGI).

Fig 11. AVPs of RAA

[53] The PCRF responds with the AAA to the P-CSCF.

Fig 12. AVPs of AAA

[54] Upon receiving the successful AAA from the PCRF, the P-CSCF continues the SIP signaling by forwarding the 183 Session In Progress towards the UE. The following snapshot shows headers of 183 Session In Progress captured on Gm interface.

• P-Early-Media header: indicator of whether the UE supports the early media mode. The early media option has been disabled in the practice.

Refer to step#47 and step#48 for the detailed description for SIP headers.

Fig 13. Headers of 183 Session In Progress

The following snapshot shows the SDP answer included in the 183 Session In Progress. The SBC is going to be a peer node from UE’s perspective. Given that, the IP address and port number represents the SBC to which the originating UE shall connect for media. The codec information represents the one supported by the SBC. Refer to step#47 for the detailed description for SDP attributes.

Fig 14. SDP answer in 183 Session In Progress

The SDP answer delivered to the originating UE shows the IP address is 10.75.23.197 and port number is 10570, which is depicted as [a] in Fig2.

[55] The UE confirms that the 183 Session In Progress with SDP answer has been received safely by sending SIP PRACK.

• RACK header: the sequence number the corresponding 183 Session In Progress and the SIP INVITE.

Refer to step#47 for the detailed description for other headers.

Fig 15. Headers in SIP PRACK

[56] The 200 OK response to the SIP PRACK is received by the UE.

Fig 16. Headers in 200 OK for PRACK

[57] The 180 Ringing provisional response is received by the UE. It indicates the voice call setup request is being notified to the recipient. Refer to step#47 and step#48 for the detailed description for headers.

NOTE If the option tag ‘100rel’ appears in the Require header, the UE shall acknowledge the provisional response by sending PRACK. If it appears in Supported header, it is just informative.

Fig 17. Headers in 180 Ringing

[58] The 200 OK response for the SIP INVITE is received by the UE. It indicates that the terminating user answered the phone. Upon receiving the response, the UE allocates the media resource. Refer to step#47 and step#48 for the detailed description for headers.

Fig 18. Headers in 200 OK for SIP INVITE

[59] The UE sends SIP ACK towards the terminating user. Refer to step#47 for the detailed description for headers.

Fig 19. Headers in SIP ACK

Red Mouse

REFERENCES

[1] 3GPP TS 23.228, "IP Multimedia System (IMS); Stage 2", v11.4.0, Mar 2012

[2] 3GPP TS 24.229, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); stage3", v11.3.0, Mar 2012

[3] 3GPP TS 24.628, "  ", v11.3.0, Mar 2012

[4] 3GPP TS 29.212, "Policy and Charging Control (PCC); Reference points", v12.6.0, Sep 2014

[5] 3GPP TS 29.214, "Policy and Charging Control over Rx reference point", v12.5.0, Sep 2014

[6] IETF RFC7315, "Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for 3GPP", July 2014

[7] IETF RFC4028, "Session Timer in the Session Initiation Protocol (SIP)", Apr 2005

[8] IETF RFC3264, "A offer and answer model with the Session Description Protocol (SDP)", Jun 2002

[9] IETF RFC3262, "Reliability of the Provisional Responses in Session Initiation Protocol (SIP)", Jun 2002

[10] IETF RFC3608, “Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration”, Oct, 2003

Last Updated: 26th Dec 2015