Volte Q n4g4b

[email protected]

:<port>) or a tel URI (RFC 3966) tel: <subscriber_number>. The needs to the public identity before the identity can be used to originating and terminating IMS communication.

© 2016 Qualcomm Technologies, Inc.

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION

3-41

VoLTE and IMS – Overview, Protocols, and Performance

80-W3085-1 Rev A

Section 3: IMS Signaling Protocols

Wildcard Public ID For details, refer to: • 3GPP TS 23.003, Numbering, addressing and identification, clause 13.4A and clause 13.4B • 3GPP TS 23.228, IP Multimedia Subsystem (IMS); Stage 2. clause 4.3.3 Wildcard Public ID Public Identities may be stored in the HSS as Wildcarded Public Identities. A Wildcarded Public Identity represents a collection of Public Identities that share the same service profile and are included in the same implicit registration set. Wildcarded Public Identities enable optimization of the operation and maintenance of the nodes for the case in which a large amount of s are ed together and handled in the same way by the network. Temp Public ID For 3GPP systems, if there is no ISIM application to host the Public Identity, a Temporary Public Identity shall be derived, based on the IMSI. The Temporary Public Identity shall be of the form as described in subclause 13.4 and shall consist of the string "sip:" appended with a name and domain portion equal to the IMSI derived Private Identity, as described in subclause 13.2.



3-42


80-W3085-1 Rev A


Public and Private Service Identity

For details, refer to • 3GPP TS 23.003, Numbering, addressing and identification, clause 13.5 and clause 13.5A • 3GPP TS 23.228, IP Multimedia Subsystem (IMS); Stage 2. clause 4.3.3



3-43


80-W3085-1 Rev A


Anonymous/Unavailable Identity

For details, refer to • 3GPP TS 23.003, Numbering, addressing and identification, clause 13.6 and clause 13.7 • 3GPP TS 29.163, Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks



3-44


80-W3085-1 Rev A


Globally Routable Agent For details, refer to 3GPP TS 23.228, IP Multimedia Subsystem (IMS); Stage 2. clause 4.3.3.2 Globally Routable Agent URI (GRUU) is an identity that identifies a unique combination of Public Identity and UE instance that allows a UE to address a SIP request to a specific Public Identity UE combination instance, as opposed to a Public Identity, in order to ensure that the SIP request is not forked to another ed UE of the same Public Identity. There are two types of GRUUs: Public GRUUs (P-GRUUs) and Temporary GRUUs (TGRUUs). P-GRUUs are GRUUs that reveal the Public Identity of the and are very long-lived. T-GRUUs are GRUUs that contain a URI that do not reveal the Public Identity of the and are valid until the is explicitly deed or the current registration expires. Each Public Identity may have one or more GRUUs . There are two types of GRUU, P-GRUUs and T-GRUUs, which are associated with Public Identities and are generated and assigned to the UE together during registrations and re-registration in a pair of one P-GRUU and one T-GRUU. Each pair of a P-GRUU and a T-GRUU is associated with one Public Identity and one UE. During subsequent re-registrations, the same P-GRUU will be assigned to the UE but a new and different T-GRUU will be generated and assigned. After a re-registration, all the previous T-GRUUs generated during the period of this registration are all still valid. A UE may retain some or all of the previous T-GRUUs obtained during the initial registration or previous re-registrations along with the new TGRUU or the UE may replace some or all of the previous T-GRUUs with the new T-GRUU. The current set of the PGRUU and all T-GRUUs which are currently valid during this registration period is referred to here as the GRUU set. This relationship is depicted in figure 4.6a. If a UE s (explicitly or implicitly) with multiple Public Identities, a separate GRUU set is associated with each. If different UEs with the same Public Identity, a different GRUU set is associated with each. Note: If the UICC is replaced the UE is still considered to be same UE instance and if that UE instance with a different UICC s the same Public Identity as was ed with the previous UICC the same P-GRUU will be assigned for that Public Identity UE instance combination. © 2016 Qualcomm Technologies, Inc.


3-45


80-W3085-1 Rev A


Specifications References

3GPP specifications are available at www.3gpp.org . IETF RFCs are available at www.ietf.org. GSMA documents are available at www.gsma.com.



3-46


80-W3085-1 Rev A

Section 4: Call Flows for VoLTE



4-1


80-W3085-1 Rev A


Notes



4-2


80-W3085-1 Rev A


Objectives

• Typical domain preferences for voice-centric VoLTE devices: – Voice domain: IMS PS voice preferred, CS voice secondary – SMS domain: PS SMS preferred

• VoLTE capabilities are exchanged in an LTE network during initial ATTACH process. – UE indicates VoLTE through FGI bits and ed PD parameters using UE Capability Information message. – Network indicates IMS VoPS in ATTACH Accept.

• P-CSCF discovery must be accomplished prior to IMS registration. • SIP messaging used by VoLTE devices for IMS registration, deregistration, call setup, and call release.

• MSC server enhanced to provide SRVCC functionality and SCC AS facilitates seamless transfer of VoLTE call to legacy 3GPP networks.



4-3


80-W3085-1 Rev A


VoLTE Protocol Stack This diagram highlights the protocols covered in this section. SIP signaling can flow over either T or UDP, as explained later.

LTE NAS allows configuration of the IP stack (IPv4 and or IPv6) and IMS (P-CSCF address discovery).



4-4


80-W3085-1 Rev A


Notes



4-5


80-W3085-1 Rev A


Domain Selection Multimode UEs can provide voice and SMS services in a variety of ways. For example, voice services could be provided in PS mode on LTE networks (Voice over IMS) and by using CS mode on legacy networks. Alternatively, voice services can be provided using PS mode in both LTE and legacy networks, for example, VoIP over EV-DO or VoIP over HSPA. Independently, SMS services can be provided either by IMS or by using the SGs interface (MME to MSC Server interface) with a legacy network through NAS messages to UEs camped on LTE networks. The domain selection process determines the manner in which these services are accessed by the based on operator and preferences in addition to UE and network capability. Further, the usage setting on the UE could be voice-centric or data-centric. All these factors influence domain selection. Domain selection also determines the network on which the UE camps. Currently, voice and SMS are the only services that are considered for domain selection. 3GPP TS 23.221 provides details on the domain selection process.



4-6


80-W3085-1 Rev A


Domain Selection and ATTACH Type If, based on the domain selection process, the UE decides to camp on an LTE network, the UE would use one of the ATTACH procedures shown in the above table for different voice and SMS options. SMS and voice domain preferences shown in the table above are:

• PS_SMS_PREF – SMS service is preferred to be delivered over the IP network (possibly using • • • • •

IMS) PS_SMS_NOT_ALLOWED – SMS service is not delivered over the IP network (e.g., it could be delivered over the SGs interface and through NAS messages) CS_ONLY – UE s CS voice only CS_PREF, PS_SECOND – UE prefers CS voice, IMS PS voice is secondary PS_PREF, CS_SECOND – UE prefers IMS PS voice, CS voice is secondary PS_ONLY – UE s PS voice only

Based on the determination made during the domain selection process, the UE:

• May elect to itself in more than one RAT network. The ATTACH type is referred to as Combined ATTACH.

• Elects to on the LTE network only. The ATTACH type is referred to as EPS ATTACH. Under certain circumstances, when the UE initiates Combined ATTACH, the network may indicate a preference for EPS ATTACH only. This is accomplished in the ATTACH Accept message through the “EPS Attach Result” IE. Refer to 3GPP 24.301 for more details.



4-7


80-W3085-1 Rev A


Typical Domain Preferences for VoLTE Devices Typical domain preferences for VoLTE device are detailed on the above slide. As explained in the previous slide, voice and SMS domain preference determine the ATTACH type a UE would perform. A VoLTE device would IMS PS voice. In addition, it may be capable of providing CS voice services. Further, the device usage setting plays a role in domain selection. For example, if an LTE network does not PS voice or CSFB, the device would choose a different RAT to camp on during the domain selection process if it were a voice centric device. Under similar conditions, a data-centric device would elect to camp on an LTE network.



4-8


80-W3085-1 Rev A


Attach Type Based on the determination made during the domain selection process, the UE:

• May elect to itself in more than one RAT network. This ATTACH type is referred to as

Combined ATTACH. • Elects to on the LTE network only. This ATTACH type is referred to as EPS ATTACH. Under certain circumstances, when the UE initiates Combined ATTACH, the network may indicate a preference for EPS ATTACH only. This is accomplished in the ATTACH Accept message through the “EPS Attach Result” IE. Refer to 3GPP TS 24.301 for more details. For details of Domain Selection and UE Usage Setting, refer to 3GPP TS 23.221, Clause 7.2. Voice Domain Preference • IMS PS Voice preferred, CS Voice as secondary: UE attempts VoLTE (PS) first and will only attempt CS (CSFB or SVRCC) if directed by the network. • CS Voice preferred, IMS PS Voice as secondary: UE attempts CS (CSFB or SVRCC) first. UE Usage Setting • Data Centric: UE does not CS voice. An LTE USB modem is an example of such a datacentric device. • Voice Centric: UE s CS voice and will camp on a RAT where voice services can be ed.



4-9


80-W3085-1 Rev A


Notes



4-10


80-W3085-1 Rev A


VoLTE Signaling Overview Key phases in a VoLTE call are highlighted in the diagram above. Various aspects addressed in this section for each of the phases are detailed below. A. Initial LTE attach, includes RRC connection setup, authentication and security procedures, PDN connection setup (includes default and an optional dedicated bearer set up). With respect to VoLTE, PDN connection setup can be broadly classified into either single initial IMS PDN setup or an initial PDN setup, followed by subsequent IMS PDN setup. In addition, VoLTE related UE capability is exchanged in the initial ATTACH process. B. IMS client registration. The IMS registration procedure allows the UE to create, maintain, and remove a binding between its public identity and its address. Mutual authentication of UE and IMS CN is accomplished through the registration process. Key steps include P-CSCF discovery and registration of the UE in the IMS. C. After initial LTE attach and subsequent IMS registration, VoLTE call setup involves IMS core interaction with LTE core setting up VoLTE media (codec selection), dedicated EPS bearer establishment (if necessary), QoS negotiations, and alerting UE on both ends. Key functionality covered in this section includes various VoLTE call scenarios, MO/MT call setup, and VoLTE call QoS. D. VoLTE Call Release. The call release mechanism when a UE experiences radio link failure during a VoLTE call is discussed as well as the signaling when either party hangs up the call. E. IMS Client Deregistration. Triggers for deregistration are discussed.



4-11


80-W3085-1 Rev A


Initial Attach An operator can configure IMS signaling to be carried either on the default or the dedicated bearer. For example, if an operator has some GBR requirements or a UL/DL Traffic Flow Template (TFT) is defined for IMS signaling traffic, a dedicated bearer may be used to carry IMS signaling.

Alternatively, if a single PDN carries all traffic and various filters are defined for different data traffic types and there is no filter for IMS signaling, then the latter is carried only on the default bearer since it does not match any of the TFTs.



4-12


80-W3085-1 Rev A


IMS PDN Connectivity and Signaling Bearer Setup Various ATTACH scenarios are likely for VoLTE devices based on:

• The number of PDN connections to be activated during the ATTACH process, • PDN functionality (dedicated to IMS or shared between IMS and other services), and • Which bearer (dedicated or default) carries IMS signaling. Networks can be designed in a variety of ways and may contain several PDNs. For example, there could be a IMS PDN, an Internet PDN, and another PDN for all other services. As per IR.92, the UE is not supposed to provide the IMS APN name in the Initial ATTACH. Also if the PDN connection during Initial ATTACH is established to an APN other than the IMS APN, the UE must establish another connection to the IMS APN.



4-13


80-W3085-1 Rev A


Initial LTE Attach for a VoLTE Device The initial LTE attach process is covered in depth in the LTE Call Processing class offered by Qualcomm Wireless Academy. Some high level procedures accomplished during LTE initial attach are:

• • • • • • • •

LTE system acquisition Random network access + RRC connection setup Attach request NAS authentication and security procedures Location update AS security mode procedures and UE capability exchange PDN connection establishment Establishment, activation of default EPS bearer, optional dedicated EPS bearer setup

In the diagram above, VoLTE related information exchange is highlighted in blue boxes. These exchanges take place during Attach request, UE Capability Information, Attach Accept, and Activate Default Bearer Context request. Note that the UE is informed of IMS Voice over PS by the network through the “EPS Network Feature ” IE in the Attach Accept message.



4-14

80-W3085-1 Rev A

VoLTE and IMS – Overview, Protocols, and Performance Section 4: Call Flows for VoLTE

UE Capability – VoLTE Related Features UE EUTRA Capability Information is included within UE-CapabilityRAT Container List sent as part of UE Capability Information message sent in response to UE Capability Enquiry message received from eNB. Refer to 3GPP 36.331 for more details. UE

EUTRAN

UECapabilityEnquiry

UECapabilityInformation

UE-EUTRA-Capability ::= accessStratumRelease ue-Category pd-Parameters phyLayerParameters rf-Parameters measParameters featureGroupIndicators interRAT-Parameters utraFDD


SEQUENCE { AccessStratumRelease, INTEGER (1..5), PD-Parameters, PhyLayerParameters, RF-Parameters, MeasParameters, BIT STRING (SIZE (32)) SEQUENCE { IRAT-ParametersUTRA-FDD

OPTIONAL, OPTIONAL,


4-15

80-W3085-1 Rev A

VoLTE and IMS – Overview, Protocols, and Performance Section 4: Call Flows for VoLTE

UE Capability – Feature Group Indicators (FGIs) Feature Group Indicators (FGIs) consist of 32 binary bits, each corresponding to a specific feature as defined in TS36.331 Annex B.1. The FGIs are included in the IE UE-EUTRA-Capability typically sent in the UE Capability Information Message as a response to the UE Capability Enquiry triggered by the network. The VoLTE related FGI bits shown above are addressed in this section and detailed below. IRAT measurements with B1 and B2:(Bit 15, 22-24, 26) Measurement reporting event: Event B1 – Neighbor > threshold (Bit15) – Can be set to 1 only if any of bits 22, 23, 24, or 26 are set to 1.

•

UTRAN, GERAN, 1xRTT, HRPD measurements, reporting and measurement reporting event B2 in E-UTRA connected mode (Bit 22, 23, 24, and 26 respectively) – Should be respectively set to 1 if UE s appropriate RAT.

Single Radio Voice Call Continuity (SR-VCC) related IRAT active handover

•

EUTRA RRC_CONNECTED to GERAN GSM Dedicated handover, CDMA2000 1xRTT CS Active handover, UTRA CELL_DCH CS handover (Bit 9, 11, and 27 respectively) – Can be set to 1 only if bit 23, 26 or 8 and 22 are respectively set to 1.

SON/ANR (Bit 16-19) UE EUTRA capability Information

•

Bit 16 takes on different meanings depending on how some of the other bits are set. The table below provides details. S.No Bit 16 interpretation 1 non-ANR related inter-frequency periodical measurement reporting 2 non-ANR related inter-RAT periodical measurement reporting for UTRAN, GERAN, 1xRTT or HRPD 3 non-ANR related intra-frequency periodical measurement reporting;

•

Dependent on If bit 25 is set to 1 If bits number 22, 23, 24 or 26 are set to 1, respectively. None of the above conditions are fulfilled

Periodic measurement reporting for SON/ANR – ANR-related intra-frequency, inter-frequency, and inter-RAT measurement reporting events (Bit 17, 18, and 19 respectively) – Can be set to 1 only if bit 5 (which indicates for Long DRX and DRX MAC CE) is set to 1.

PS Handover

•

EUTRA RRC_CONNECTED to UTRA FDD or UTRA TDD CELL_DCH PS handover, if the UE s either only UTRAN FDD and/or only UTRAN TDD. Can only be set to 1 if the UE has set bit number 22 to 1.



4-16


80-W3085-1 Rev A


Review – Dedicated EPS Bearers for VoLTE To ensure voice quality, PS voice traffic needs to be carried over GBR (guaranteed bit rate) bearers with QCI=1. Default bearers are non-GBR bearers (refer to 3GPP TS 23.401 sec 4.7.2.1). As such, these bearers enable Best Effort transport of data and QoS cannot be guaranteed for data carried over these bearers. In EPS, a dedicated EPS bearer can be used to transport application data requiring a specific QoS. The establishment of these bearers in the UE and the EPS guarantees requested or negotiated QoS. There are multiple ways the Dedicated EPS bearer(s) can be established. In UE initiated Dedicated EPS bearer setup (also known as Bearer Resource Allocation procedure), the UE requests a specific QoS (QCI) and optionally sends a GBR requirement for a new traffic flow aggregate. If the network accepts the request, it invokes a dedicated EPS bearer context activation procedure. The network-initiated Dedicated EPS bearer setup is triggered by:

• UE ing with IMS core for IMS services and establishing an IMS VoIP call • IMS node triggering PCRF to establish corresponding dedicated bearers The default EPS bearer with the PDN must be established before the dedicated EPS bearer can be established.



4-17


80-W3085-1 Rev A


Notes



4-18


80-W3085-1 Rev A


P-CSCF Discovery P-CSCF is the gateway to the IMS domain. It serves as the outbound proxy server for the UE. The UE must discover a P-CSCF before it can perform IMS registration. It needs to determine the IP address of the P-CSCF, the server port of the P-CSCF, and a transport protocol to exchange signaling with the P-CSCF. The process to determine this triplet is referred to as P-CSCF discovery. Signaling related to P-CSCF discovery can be performed over any bearer and there are no related QoS requirements. P-CSCF discovery can be accomplished in the ways outlined above. This course discusses the P-CSCF discovery process using PCO during bearer activation.



4-19


80-W3085-1 Rev A


P-CSCF Discovery Using PCO Determination of “valid” P-CSCF addresses is accomplished as follows:

• If an IPv6 bearer is established as part of ATTACH Accept, the UE shall ignore IPv4 P-CSCF addresses.

• If an IPv4 bearer is established as part of ATTACH Accept, the UE shall ignore IPv6 P-CSCF addresses.

• UE does not reorder the list when determining the “valid” P-CSCF addresses. UE initiates IMS registration using the first address in the “valid” list. If the list is empty, UE may proceed to other methods of P-CSCF discovery.



4-20


80-W3085-1 Rev A


IMS Registration Process 1) IMS registration starts with UE establishing a bearer for SIP signaling. The UE begins initial registration with IMS by sending a SIP request to P-CSCF. This message is not protected by any security association but includes security parameters required for IMS registration. 2) P-CSCF temporarily stores security parameters received in SIP signaling message. P-CSCF then forwards message to the selected S-CSCF via I-CSCF. S-CSCF obtains an authentication vector from HSS. The authentication method typically used is AKAv1. It challenges the UE with a 401 unauthorized response. This response is sent back to P-CSCF via I-CSCF. 3) P-CSCF, upon receiving 401 unauthorized response, extracts from the message, integrity, and cipher keys. It then adds its own security parameters on 401 unauthorized response and sends it to the UE. 4) The UE, on receiving 401 unauthorized message, decodes, constructs, and sends a request with same header value as the initial request. 5) P-CSCF checks the security field of the received request and removes the security and security-client headers. It then forwards the message to S-CSCF via I-CSCF indicating that the message is integrity-protected.

6) S-CSCF checks the challenge response from the UE and matches the response locally. In the event of successful registration, S-CSCF generates a 200 OK response including a list of ed public identities. 7) This response is forwarded to the UE via I-CSCF and P-CSCF. The UE upon receiving 200 OK response indicating successful authentication, stores a list of ed public identities in its P-associated URI (which is a SIP private URI provided by the operator).



4-21


80-W3085-1 Rev A


Notes



4-22


80-W3085-1 Rev A


VoLTE Call Scenarios This course details only Mobile-to-Mobile MO/MT VoLTE calls and the network-initiated QoS procedures. The processes are similar for MO and MT calls. Call forking, also known as call splitting, is a function that enables an incoming call to ring several UEs at the same time. The call is completed with the first UE that answers the call. Refer to TS 24.229 for more details.



4-23


80-W3085-1 Rev A


MO and MT VoLTE Call Initiation This scenario assumes both UEs have successfully completed IMS registration and network-initiated bearers would be used to set up dedicated bearers needed to carry voice traffic. Both UEs are also assumed to be in RRC Idle state. When a makes a VoLTE call, the indication reaches the UE’s IMS client, which forms a SIP:INVITE message to the destination . When the LTE stack receives this message, it initiates a service request procedure. The RRC layer then performs a RACH procedure to enter RRC Connected state. After RRC connection is complete, the LTE stack transmits an IPSec packet containing a SIP:INVITE message on EPS/Radio bearer allocated for SIP signaling. The IPSec packet reaches P-CSCF and is routed to S-CSCF via I-CSCF. P-CSCF sends a 100:Trying message to IMS client in MO UE to indicate that the SIP:INVITE has been forwarded. The S-CSCF forwards the message to the corresponding I-CSCF which forwards the same to the PGW of UE2 through its P-CSCF. UE2 is paged and performs a RACH procedure to enter RRC Connected state. The SIP:INVITE message is now delivered to the destination UE. The IMS client in the destination UE generates a 100: Trying message and sends it to the source UE to indicate that it has received SIP:INVITE message. When the UE receives an SDP offer, it selects exactly one codec per media line and indicates only the selected codec for the related media stream. More details can be found in Section 6.1.3 of 3GPP TS 24.229 and 3GPP 24.930. The selected codec is carried on the reverse path to the source over SIP:183 session progress message. The media description in 183: session progress is used to trigger network initiated dedicated bearer establishment. See 3GPP TS 23.401 section 5.4.1 for more details.



4-24


80-W3085-1 Rev A


MO-MT VoLTE Call Proceeding As soon as the P-CSCF SIP:183 session progress reaches the IMS core (P-CSCF), it triggers networkinitiated push of dedicated bearers in its network. The network-initiated dedicated bearer setup process is not detailed here. Details for the same can be found in 3GPP 23.401 Section 5.4.1. Dedicated EPS bearer establishment occurs in parallel to SIP:PRACK and SIP:OK messages exchanged between source and destination UEs. A precondition is a set of constraints about the session which are introduced in the offer. The recipient of the offer generates an answer, but does not alert the or otherwise proceed with session establishment. Session establishment only occurs when the preconditions are met. The IMS client in the source UE sends a SIP:PRACK message. This PRACK message reaches the IMS client on the destination UE, which responds with SIP:200 OK. This acknowledges the PRACK and accepts the SDP-offer. QoS negotiations between the source and destination UEs can take place over SIP:Invite, SIP:PRACK, and SIP:Update messages.



4-25


80-W3085-1 Rev A


MO-MT VoLTE Call Alerting and Answer After receiving SIP:200 OK for PRACK, the IMS client in the source UE sends a SIP:UPDATE message to the IMS client at the destination UE. The receipt of this message completes resource reservation. Now the IMS client at the destination UE responds with a SIP:200 OK to specify acceptance of SIP:UPDATE. All these messages are exchanged in parallel to dedicated EPS bearer establishment. The update procedure discussed above alerts the destination of the incoming voice call with a ringing tone and sends across a ringback tone to the source IMS client via SIP:180 Ringing message. When the destination answers the call, the IMS client at the destination also sends a SIP:200 OK message to the IMS client at the source. This serves a SIP:200 OK to the initial SIP:INVITE message. The IMS client at the source acknowledges the SIP:200 OK with an ACK and the media streams are established between source and the destination. The above call flow assumes that preconditions are enabled. In case preconditions are disabled the SIP:UPDATE/200 OK messages will not be present. The call/session establishment will progress irrespective of the network being able to arrange dedicated resources which may result the call being established with Best Effort services.



4-26


80-W3085-1 Rev A


UE-Originated – Detailed Messaging 1. 2. 3. 4. 5. 6.

7.

8.

9.

VoLTE UE originates a voice call from LTE and initiates a SIP INVITE request containing the SDP offer. The request is sent over the Gm interface to the P-CSCF that then forwards the SIP INVITE to the S-CSCF over Mw interface. The S-CSCF receives the SIP INVITE and checks for authorization by validating against the subscribed services that were retrieved in the service profile during IMS Registration. If validated, the S-CSCF then adds the ICSI into the erted-Service header and removes the P-Preferred-Service header. The S-CSCF routes the SIP INVITE to the I-CSCF over Mw interface to determine the terminating S-CSCF of the CalledParty. The called party's VoLTE UE will send SIP 183 Progress message. S-CSCF receives the message and forwards to the P-CSCF over Mw interface. P-CSCF sends the Authorize/AuthenticateRequest message to the PCRF over Rx interface. The PCRF authorizes the request and identifies the affected IP-CAN session (e.g., default bearer) established during the LTE Attach procedure and initiates a Re-Auth-Request to the PGW over Gx interface to initiate creation of a dedicated bearer. The PGW ACKS the Re-Auth-Request to the PCRF over Gx interface, which then acks the Authorize/AuthenticateRequest message sent from the P-CSCF. The PGW sends the Create Bearer Request to the SGW over S5 interface to create the dedicated bearer for VoLTE media. The SGW sends the request to the MME over S11 interface. The MME sends a Bearer Setup Request message to the eNB to activate the dedicated bearer for voice. The eNB maps the QoS parameters and sends a RRC Connection Reconfiguration to the UE. The UE acks the request to the eNB, which then acks the Bearer Request Setup to the MME. The MME sends the Create Bearer Response message to the SGW over S11 interface to acknowledge the bearer activation. This is then forwarded to the PGW. The P-CSCF forwards the SIP 183 Progress response to the VoLTE UE over Gm interface. The originating UE generates a PRACK, which is transited to the terminating side of the call with an associated 200 OK (PRACK) being received. The VoLTE UE sends a SIP UPDATE message with a new SDP offer confirming the selected codec, The UPDATE message is forwarded via the P-CSCF and S-CSCF to the terminating leg of the call. The 200 OK (UPDATE) response is received from the terminating UE and this message is ed onto the originating UE via the S-CSCF and P-CSCF. Terminating UE is now alerted and shall send a SIP 180 (Ringing) response that is received by the S-CSCF and onto the P-CSCF and originating UE. When the called party's VoLTE UE answers the call, it sends a 200 OK to the calling party VoLTE UE. This is received by the S-CSCF and forwarded to the P-CSCF over the Mw interface. The P-CSCF invokes the PCRF over Rx interface with an AAA message to enable both the uplink and downlink of the dedicated bearer. In turn, the PCRF invokes the P-GW with a RAR message to enable the media flows at the P-GW. The P-CSCF forwards the SIP 200 OK (INVITE) to the VoLTE UE over Gm interface. The VoLTE UE receives the 200 OK, and sends a SIP ACK message to acknowledge that the call has been established.



4-27


80-W3085-1 Rev A


Dedicated Bearer Establishment Failure during VoLTE Call Setup The P-CSCF initiates the cleanup by sending a SIP:503 (service unavailable) to the source IMS client and a SIP:CANCEL to the destination IMS client.



4-28


80-W3085-1 Rev A


Possible VoLTE Call Setup Failures Here are a few example of VoLTE call setup failures, broadly categorized as LTE Failures and IMS failures. LTE failures: 1. RF problems: If the underlying LTE coverage is poor, this may lead to VoLTE call setup failures. For example, the UE tries to send a SIP invite message but fails to establish LTE connection due to RACH or UL grant issues. 2. Paging failures: If the eNB paging scheme is not designed properly, this may lead to LTE Page failures and to VoLTE call setup failures. For example, if an operator has not designed the paging areas sufficiently large enough or paging intervals are long, this may cause the MO UE to give up on the VoLTE call and move to 3G. IMS failures: 1. Preconditions not met: Operators use preconditions to provide QOS for VoLTE calls. Usually preconditions are exchanged during call setup, so if one of the parties ( MO, MT, or IMS) does not met the preconditions then VoLTE call setup fails. 2. IMS server failures: IMS server failures may lead to VoLTE call setup failures. 3. ission Control: ission related issues also causes VoLTE call setup failure list.



4-29


80-W3085-1 Rev A


MT VoLTE Call QoS Negotiation UE IMS stack must preconditions for QoS negotiation. QoS negotiation determine the resources (e.g., determination of audio codec to be used in a VoLTE call) needed for an IMS session. In MT VoLTE call scenarios, IMS CN determines the QoS desired for the call and triggers a networkinitiated QoS establishment procedure. The calling party can indicate QoS availability via SIP:UPDATE, SIP:INVITE, or SIP:PRACK messages.

• SIP:UPDATE – This is the most typical use case. The calling party indicates availability of the required QoS for the call in an UPDATE message.

• SIP:INVITE – In this alternative use case scenario, the calling party indicates availability of the required QoS for the call in an INVITE message.

• SIP:PRACK – In this alternative use case scenario, the calling party indicates availability of the required QoS for the call in a PRACK message. More details on QoS negotiation can be found in 3GPP TS 24.930.



4-30


80-W3085-1 Rev A


VoLTE to UMTS Call Flow • In the case of VoLTE calling UMTS , the S-CSCF determines that the Called-Party is within the operator’s CS network and forwards the SIP INVITE to the BGCF. • The BGCF is responsible for selecting an appropriate MGCF for breaking out to the CS network. The BGCF may query DNS to determine the optimum MGCF to select. The BGCF forwards the INVITE to the selected MGCF. • The MGCF is responsible for interworking to the CS network both in the control plane (IMS SIP to SIP-I/BICC/ISUP) and media plane via the IMS-MGW and follows the procedures of 3GPP TS 29.163 (for ISUP/BICC) or 3GPP TS 29.235 (for SIP-I). • The IMS-MGW may be required to perform transcoding between AMR-NB/AMR/WB codecs and other codecs ed within the CS network (e.g., GSM-HR, GSM-FR, GSM-EFR, etc.). • The MGCF selects the outgoing route to the CS network (e.g., (G)MSC-S). The outgoing route to the CS network may be TDM or IP based and utilizes ISUP or SIP-I/BICC respectively. The MGCF invokes an IMS-MGW to allocate and configure media resources for the call (see 3GPP TS 29.332 ). • The MGCF sends an ISUP IAM/BICC IAM/SIP-I INVITE (IAM) to the GMSC-S, which in turn interrogates the HLR to discover location of the MSC-S that the is currently ed on. Note that the MGCF may be co-located with a (G)MSC-S. The (G)MSC-S forwards the request to the MSC-S that the is ed on and call establishment is progressed as defined within the 3GPP specifications.



4-31


80-W3085-1 Rev A


VoLTE to UMTS Call Flow (continued) • Since the SDP offer from the originating leg indicates that QOS preconditions are desired but not yet met at the originating side, the MGCF sets (for BICC / ISUP) the continuity indicator to “continuity check performed on previous circuit”/“COT to be expected” in the IAM message for ISUP/BICC respectively. • For ISUP/BICC, the MGCF sends a 183 Progress message containing the SDP answer. For SIP-I, the MGCF receives a 183 Progress message from the peer MSC containing the SDP answer. In both cases, the SDP answer contains a single voice codec, utilizes 100rel, and indicates that QOS preconditions are also desired but not yet met at the terminating side. In addition, the SDP answer requests confirmation of QOS preconditions being met at the originating side. • The 183 Progress (SDP) is sent to the originating leg via the BGCF/S-CSCF. • The MGCF receives a PRACK from the originating side of the call and responds with a 200 OK (PRACK) for BICC/ISUP routes. In the case of SIP-I routes, the MGFCF transits PRACK and 200 OK (PRACK). • The originating UE now sends an UPDATE message with a new SDP offer confirming the selected voice codec and indicating that QOS preconditions have been met at the originating leg. The MGCF receives the UPDATE message and responds with a 200 OK (UPDATE) for BICC/ISUP routes and transits the UPDATE/200 OK (UPDATE) for SIP-I routes. The 200 OK (UPDATE) contains the SDP answer which indicates that QOS preconditions are also met at the terminating side. Since QOS preconditions are now met at both ends, the MGCF (for ISUP/BICC) sends a COT message indicating “continuity check successful.” • The terminating in the CS network is now alerted and the MGCF receives an ACM (alerting) message from ISUP/BICC or a SIP 180 Ringing (ACM) message from SIP-I. The MGCF sends a SIP 180 Ringing message to the originating leg. This message does not utilize 100rel. It is strongly recommended that the MGCF includes the P-Early-Media header in the SIP 180 (Ringing) message as described in 3GPP TS 29.163. At this point, the MGCF also ensures that backward media (e.g., ring tone, progress indications) are conveyed via the IMS-MGW. • The SIP 180 Ringing is forwarded to the VoLTE UE to indicate a ringing tone to the subscriber. • When the CS network indicates that the call has been answered, the MGCF sends a 200 OK (INVITE) message to the IMS network. This message is forwarded to the originating leg of the call and onto the VoLTE UE. The MGCF ensures that duplex media can be conveyed via the IMS-MGW at this point. • The VoLTE UE receives the 200 OK, and sends a SIP ACK message to acknowledge that the call has been established. The ACK is propagated through the IMS network to the MGCF. The ACK message is forwarded to the CS network for SIP-I routes. • At this stage, the call is established with voice traffic sent over the dedicated bearer between the VoLTE UE and the CS network via the IMS-MGW.



4-32


80-W3085-1 Rev A


VoLTE to PSTN Call Flow The S-CSCF determines that the Called-Party is outside operator network and forwards the SIP INVITE to the BGCF. The BGCF is responsible for selecting an appropriate MGCF for breaking out to the PSTN. The BGCF forwards the INVITE to the selected MGCF. The MGCF is responsible for interworking to the PSTN network both in the control plane and media plane via the IMS-MGW. The IMS-MGW may be required to perform transcoding between AMRNB/AMR/WB codecs and other codecs ed within the PSTN.



4-33


80-W3085-1 Rev A


Intra-LTE Mobility during VoLTE Call LTE handover failure does not necessarily cause a VoLTE call drop • If handover execution delay is within an acceptable range: – VoLTE call continuity with no voice quality degradation is expected • If handover procedure incurs longer than expected delay: – For example, bad RF conditions may cause handover to take longer than expected (multiple retransmissions are required) – PD discard timer at the transmitting entity may drop some audio PD PDU, causing degradation in voice quality – VoLTE call will suffer degradation in quality • If handover delay was substantially large: – For example, recovering from RLF by executing re-established procedure – If UE manages to recover from RLF before the RTP timer expiry, the call will not be dropped; however, voice interruption will be noticeable by the end s – The VoLTE call will be dropped if the delay exceeds the RTP timer Handover in LTE is a hard handover (break before make). It is important to minimize the delay incurred during handover as much as possible. • Contention-free RACH preferred over contention-based to minimize interruption time and failures • X2 HO preferred over S1 HO to reduce the time required for handover • Suboptimum core network configuration can incur extra delay to process HO request – Core network response for the HO request should be optimized to reduce the delay incurred • Optimized RF planning is required to reduce the failures and potential delay during HO • Larger delay can impact the performance of the application layer • e.g., higher interruption RTP Loss and RTP Jitter  lower MOS score for VoLTE (poor experience) .



4-34


80-W3085-1 Rev A


Mobility to Non-VoLTE TA • During a VoLTE call, if the moves to a tacking area with no VOPS , VoLTE call continuity is dependent on vendor and operator specific choice. All new voice calls Originated or terminated form the UE in new tracking area ( VOPS=0) are going to be on CS domain.

• There are couple of options discussed on this slide for VoLTE call continuity:

• Option1: Operator/vendor may choose to continue the VoLTE call in the non-VOPS region. In this case there is no dedicated bearer establishment in the new TA. The VoLTE call continues on the default bearer with best effort service. Voice quality may suffer due to infrequent grants and best effort service.

• Option 2: Operator/vendor may choose to drop the ongoing VoLTE call. in such scenarios IMS Core is informed upon TA update from the UE. IMS core drops the ongoing VoLTE session.



4-35


80-W3085-1 Rev A


VoLTE Call Concurrent with Internet Data The above diagram illustrates how voice calls and data sessions can be concurrently ed in an LTE network. The key steps shown in the diagram are:

1. The two UEs are LTE attached, IMS ed, and in Idle state. During the Attach process, the UEs have connected to different PDNs, including the ones for Internet and IMS services.

2. UE1 initiates a VoLTE call to UE2. UE1 transitions from Idle mode to Connected mode and all DRBs are re-established. UE2 is paged. UE2 transitions to Connected mode and all its DRBs are re-established.

3. A VoLTE call is set up between UE1 and UE2. RTP audio packets are exchanged between the UEs every 20 ms. The DRB assigned to carry VoLTE traffic should have QCI of 1.

4. During the call, 1 decides to browse the Internet. UE1 uses the default Internet EPS bearer to transact the data. Typically this bearer has a QCI of 6, 8, or 9. Resources are shared between the VoLTE call and Internet browsing on the UE1 side. Note that this is accomplished without any impact to the VoLTE call due to respective bearer QCI.

5. The VoLTE call is terminated. On the UE1 side, all DRBs remain active because the Internet session is ongoing. On the UE2 side, the RRC is connection is released and the UE enters Idle mode.

6. The Internet browsing session continues on the UE1 side.



4-36


80-W3085-1 Rev A


VoLTE Call Concurrent with MO/MT SMS A UE can send short messages over an IMS network when it has SM over IP functionality. IP-Short-Message-Gateway (IP-SMGW), located in the IMS core, provides the interface between the UE and the short message service center. It facilitates transfer of short messages from/to the UE to/from the service center and handles related status reports. The above diagram illustrates how voice calls and SMS transfer can be concurrently ed in an LTE network. The key steps shown above are:

1. The two UEs are LTE attached, IMS ed for voice and SMS, and in Idle state. During the Attach process the UEs have connected to different PDNs, including the ones for Internet and IMS services.

2. UE1 initiates a VoLTE call to UE2. UE1 transitions from Idle mode to Connected mode and all DRBs are re-established. UE2 is paged. UE2 transitions to Connected mode and all its DRBs are re-established.

3. A VoLTE call is set up between UE1 and UE2. RTP audio packets are exchanged between the UEs every 20 ms. 4. During the call, 1 decides to send an SMS. SMS is transferred from the UE to its EPC using the dedicated IMS

bearer in this example. It may be also transferred on the default (non-GBR) bearer depending on operator configuration. SIP:MESSAGE request from UE1 includes the short message, and routing information for the IP-SM-GW (which may also be integrated with service center-SC) to forward the short message. Otherwise, the IP-SM-GW forwards the short message to the service center, which returns a submission report.

5. UE2 receives the SMS via a SIP:MESSAGE request and acknowledges the same with a status report, 200 OK. 6. In the meantime, UE1 receives an acknowledgement for submission of the SMS in a SIP:MESSAGE with 202 OK. 7. IP-SM-GW acknowledges the SIP MESSAGE with 202 OK. SIP 202 is used to indicate that the SMS is submitted to the IPSM-GW. When the IP-SM-GW receives a 200 OK acknowledgement from the MT UE (UE2) for the actual short message delivery, it can optionally initiate a delivery report procedure (if enabled) toward the MO UE (UE1).

8. UE2 terminates the call and sends UE1 a SIP:BYE message. RRC connection for the UEs is released and both the UEs return to Idle mode.

The above call flow illustrates key messages used to transfer short messages. For details on signaling related to short message transfer, refer to standards documents 23.204 and 24.341.



4-37


80-W3085-1 Rev A


Notes



4-38


80-W3085-1 Rev A


VoLTE Call Termination – Normal Release VoLTE call termination by remote or local follows these steps:

1. The UE is involved in a VoLTE session. The media stream is established and carrying VoLTE frames.

2. The ongoing media session can be terminated by the remote (Option A) or by the local (Option B). –

In Option A, the remote ends the session, hence the UE receives a SIP:BYE from the IMS CN and in response sends a SIP:200 OK.

–

In Option B, the local ’s IMS stack sends a SIP:BYE to the IMS CN, which responds with a SIP:200 OK.

–

In either option, the UE IMS stack deletes the QoS it had originally installed during call setup.

3. At the end of the call, the IMS CN triggers network initiated deactivation of the Dedicated Radio Bearer to carry VoLTE voice traffic assigned to the source and target UEs.

4. Subsequently, the network may transition the UE to RRC Idle (using an inactivity timer) and release bearers for IMS signaling until the UE is paged and requests to set up RRC Connection again.



4-39


80-W3085-1 Rev A


Dedicated Bearer Deactivation The VoLTE UE sends a SIP BYE message to the P-CSCF. P-CSCF initiates a Session Termination Request to the PCRF to initiate the process of removing the dedicated bearer that was established for the voice traffic. The PCRF removes the binding between the stored subscription information and the IMS service information, and initiates a Re-Auth-Request to the PGW to remove the dedicated bearer for voice with the related QoS parameters (QCI=1, ARP) and the related traffic flow template. The Delete Bearer Request, Bearer Release Request, and RRC Reconfiguration Request are utilized to remove the dedicated bearer utilized for voice traffic. The P-CSCF forwards the SIP BYE message to the S-CSCF, which may invoke any VoLTE service logic as triggered by the initial filter criteria within the subscriber profile that was received during the IMS Registration. The S-CSCF routes the SIP BYE to the S-CSCF of the other party. The other party acknowledges the SIP BYE with a 200 OK.

At this stage, the VoLTE UE has cleared the call and the dedicated bearer for voice traffic has been removed.



4-40


80-W3085-1 Rev A


VoLTE Call Termination – Loss of Radio Link If an RLF is encountered, the UE attempts RLF recovery as it would for a PS call. The IMS client in the UE does not react to an RLF. The UE performs a radio link recovery procedure. If this fails, the call may be released by either party (due to lack of activity). Alternatively, the IMS core or client may detect the lack of RTP flow and release the call or EPC may detect the loss of bearer. If a Guaranteed Bit Rate (GBR) bearer used for VolTE is lost, then the network must terminate the associated session according to the procedures in TS 24.229 section 5.2.8 (P-CSCF must be informed about loss of bearer by the PCRF). Further, the UE must have internal logic to react to the detection of loss of bearer/radio connection to handle its internal state. The call will be released if the UE receives a SIP:BYE or SIP:CANCEL from the network. Note the SIP:BYE message is generated if the other terminates the call. SIP:CANCEL message is generated by the IMS core network to terminate the call. If the UE, having lost radio connectivity, then regains radio connectivity, the UE must perform a new initial registration to IMS in case the IMS registration expired during the absence of radio connectivity.



4-41


80-W3085-1 Rev A


Notes



4-42


80-W3085-1 Rev A


Triggers for IMS Deregistration The various triggers leading to a UE being deed from the IMS core network are listed above. The UE will explicitly de only for some of the cases (for example, when the UE is powered off). In other cases, the UE is implicitly detached (for example, the network detaches UE from EPC).

Refer to 3GPP document 24.229, sections 5.1.1.6, 5.1.1.7, and 5.2.5 for more details.



4-43


80-W3085-1 Rev A


IMS Deregistration Process IMS deregistration steps are detailed below. The numbers correspond to the steps in the diagram above. 1. The UE releases all dialogs associated with the URI(s) being deed. A SIP dialog is the signaling relation between the two UEs in a call. It is established at call setup and maintained until the call is released. It is used to establish, modify, and release the IMS multimedia session. 2. The UE constructs a request as follows: a) The UE includes the headers specified in Section 5.1.1.6 of 3GPP 24.229. The Expires header set to zero indicates the UE wishes to de. b) The UE also inserts a Require and Proxy-Require header field with the option tag “sec-agree” (which permits negotiation of common security mechanism between the UE and P-CSCF). c) If a URI belongs to an implicit registration set, all URIs in that set shall be deed along with this URI. The temporary public URI may be used in deregistration. d) The is sent to P-CSCF protected by the UEs outbound SA (Security Association – Between the client port at the UE and the server port at the P-CSCF). 3. The P-CSCF processes the request and forwards the to the S-CSCF indicating that it is integrity protected. 4. The S-CSCF notices that the P-CSCF had marked the as being integrity protected. Hence, the S-CSCF performs deregistration procedures, including removing the bindings of the UE’s addresses of the public identities being deed. The S-CSCF sends a 200 OK response to the P-CSCF via the I-CSCF. 5. The P-CSCF updates its state information about the UE’s registration and state of SA accordingly on receiving the 200 OK response and forwards it to the UE on the UE’s inbound SA. The UE performs the steps listed in Section 5.1.1.6 of 3GPP 24.229. These include: a) Clearing all registration states associated with deed public identities. b) If no more public identities are ed, the UE shall delete the security associations and related keys it may have towards the IM CN subsystem. c) If all public identities are deed and the security associations are removed, then the UE considers the subscription to the registration event package canceled. The UE is no longer able to receive signaling from the P-CSCF. © 2016 Qualcomm Technologies, Inc.


4-44


80-W3085-1 Rev A


SIP Bearer Deactivation Triggered by IMS Deregistration When the UE is no longer IMS ed, the bearer carrying SIP signaling is not required. Therefore the UE can perform procedures to disconnect the bearer. Alternatively the network can deactivate the SIP signaling bearer, disconnect the IMS PDN, and detach the UE from the EPC.

UE initiated detachment – The UE performs the IMS deregistration procedure or the EPC detach procedure. As a result, the UE is EMM-Deed and considers itself IMS deed. Network initiated detachment – The UE performs the network-initiated EPC detach procedure. As a result, the UE is EMM-Deed and considers itself IMS deed. If any VoIP session exists at the time of deregistration, it may be locally cleaned up. SIP bearer deactivation triggered by IMS deregistration – The P-CSCF shall attempt to release the UE’s SIP signaling bearer. Option 1 – IMS signaling on Default Bearer

•

If multiple PDNs are connected and IMS PDN carries only IMS traffic, P-GW will disconnect the UE from IMS PDN.

•

If IMS PDN was the only PDN connected and only carried IMS traffic, UE shall perform EPC detach procedure. As a result, UE is disconnected from IMS PDN, UE is EMM-Deed.

Option 2 – IMS Signaling on Dedicated Bearer If IMS signaling shared PDN connection with non-IMS traffic, the P-GW shall perform dedicated bearer deactivation for SIP signaling bearer. As a result, the UE’s SIP bearer is deactivated but it remains connected to the IMS PDN. IMS PDN continues to carry non-IMS traffic.



4-45


80-W3085-1 Rev A


SMS over IMS Both 3GPP and 3GPP2 format SMS are sent over IMS as the payload of a SIP message. For a 3GPP format SMS, there is an additional step where RP-ACK is sent after RP-DATA is received. However, there is no fundamental difference between the 3GPP and 3GPP2 format SMS from the IMS perspective, since IMS does not process the SIP message payload. The IMS Client sender builds and populates RP-DATA (Relay Protocol Data Unit) message, containing all the information that a mobile station submitting an SMS message according to 3GPP TS 24.011. The sender shall parse and interpret RP- DATA, RP-ACK, and RP-ERROR messages, containing all the information that a mobile station receiving an SM according to 3GPP TS 24.011 would see, in a SM submission or status report. More info: http://betelco.blogspot.com/2009/10/sms-over-3gpp-ims-network.html



4-46


80-W3085-1 Rev A


SIP Timers Per RFC 4028, Session Timer From the Session-Expires header field in the response, both UAs know that a session timer is active, when it will expire, and who is refreshing. At some point before the expiration, the currently active refresher generates a session refresh request, which is a re-INVITE or UPDATE request. If the refresher never gets a response to that session refresh request, it sends a BYE to terminate the session. Similarly, if the other side never gets the session refresh request before the session expires, it sends a BYE.



4-47


80-W3085-1 Rev A


Other SIP Timers Per RFC 4028, Session Timer From the Session-Expires header field in the response, both UAs know that a session timer is active, when it will expire, and who is refreshing. At some point before the expiration, the currently active refresher generates a session refresh request, which is a re-INVITE or UPDATE request. If the refresher never gets a response to that session refresh request, it sends a BYE to terminate the session. Similarly, if the other side never gets the session refresh request before the session expires, it sends a BYE.



4-48


80-W3085-1 Rev A


Notes



4-49


80-W3085-1 Rev A


Notes



4-50


80-W3085-1 Rev A


Notes



4-51


80-W3085-1 Rev A


Notes



4-52


80-W3085-1 Rev A


Notes



4-53


80-W3085-1 Rev A


Notes



4-54


80-W3085-1 Rev A


Notes



4-55


80-W3085-1 Rev A


Notes



4-56


80-W3085-1 Rev A


E-UTRAN and 3GPP2 1xCS (Rel 9) Architecture 1x CS IWS is enhanced for SRVCC to 3GPP2 1x CS interworking which emulates a 1xRTT BSS towards the 1x RTT MSC. See the following specifications for more information: 1. TS 23. 402: Architecture enhancements for non-3GPP accesses 2. X.S0042 V1.0: Voice call continuity between IMS and circuit switched systems



4-57


80-W3085-1 Rev A


SRVCC Call Flow in 3GPP2 1xCS (Rel 9) The call flow is similar to 3GPP UTRAN/GERAN except in here, 1x CS IWS is involved between the MME and the 1x RTT MSC server.



4-58


80-W3085-1 Rev A


Notes



4-59


80-W3085-1 Rev A


IMS Emergency SRVCC (Rel 9) Call Flow Details The above figure illustrates a scenario where IMS emergency calls goes through SRVCC.

1. IMS Voice media path (PS) between the UE and PSAP is shown as a solid blue line with SIP signaling as a light blue dotted line.

When the eNodeB in the network decides to switch the radio path (PS-to CS handover) from LTE to UMTS, the eNodeB commands SRVCC process through MME. eNodeB sends a radio switching request to MME, following which the MME requests the MSC to allocate CS resources.

2. MSC proceeds with securing bearer path resource reservation between itself and RNC/NodeB on UMTS side shown as a black dashed line.

3. MSC then sends an access path switching request to EATF via CSCF in IMS of the Home Network shown as a dotted blue line. EATF functionally takes the role of SRVCC AS of a normal SRVCC architecture.

4. EATF, having received the request, instructs the PSAP to change route or switch the destination of voice media from PGW to MSC MGW in the Home Network shown as a black dashed line.

5. In parallel MSC sends MME a response to its request for allocating resources on the UMTS side and the MME commands UE via eNodeB to switch to UMTS radio (CS) shown as a black dashed line.

6. After the UE is switched to UMTS (CS), the transmission path for SIP signaling and Voice (PS) data path are switched between MSC and PSAP. Voice call is continued via CS by the MSC MGW doing a CS-to-PS bearer conversion shown as red dotted and thick lines.

There are two interruptions, one at the UE1 originating end (visited network in this case) due to HO and session transfer and other at the UE2 terminating end (Home network) due to session transfer and media switch. Usually the HO interruption is the longer of the two, between HO and session transfer.



4-60


80-W3085-1 Rev A


IMS Emergency Calls in SRVCC to 3GPP2 WLAN/1x UEs are capable of being in simultaneous full-duplex communication with both a WLAN access network and a 1x radio access network unlike HRPD/1x UEs. Refer to 3GPP TS 23.216 and 3GPP2 X P0042 v1.0 for details.



4-61


80-W3085-1 Rev A


SRVCC Reference Architecture to 3GPP2 1xCS The above architecture is the same as presented in SRVCC having an additional functional entity to those defined in the E-UTRAN architecture TS 23.402, called 1x CS SRVCC interworking solution function (3GPP2 1xCS IWS), not shown in the figure because the figure only shows only the necessary components related to 3GPP2 1xCS IWS. 3GPP2 1xCS IWS uses the S102 reference point to communicate with the MME and to transport 3GPP2 1xCS signaling messages to the SRVCC UE. The role of the 3GPP2 1xCS IWS is to be a signalling tunneling end point towards the MME for receiving/sending encapsulated 3GPP2 1xCS signaling messages to/from the UE; and to emulate a 1xRTT BSS towards the 1xRTT MSC (reference point A1, as defined in 3GPP2 A.S0014 between 1xBSS and MSC). If the MME s interworking to 3GPP2 1xCS, the MME follows the rules and procedures described in TS 23.402 with the following additions and clarifications:

•

To be a signaling tunneling end point towards the 3GPP2 1xCS IWS for sending/receiving encapsulated 3GPP2 1xCS signaling messages to/from the UE, which are encapsulated in S1-MME S1 Information Transfer messages (TR 36.938).

•

Release of the E-UTRAN resources after SRVCC to the 3GPP2 1xCS is completed.

•

Include information to enable 3GPP2 network to determine emergency session.

•

Insert the equipment identifier during the handover procedure for the case UE operating in limited service mode.

UE needs to 3GPP2 1xCS access, which means that it is capable to perform SRVCC to the 3GPP2 1xCS system. The interaction between UE and E-UTRAN is described in TR 36.938. The interaction with the 3GPP2 1xCS system is described in TS 23.216. If the E-UTRAN (operator) s interworking to 3GPP2 1xCS, the E-UTRAN performs the HO trigger, tunneling of the 3GPP2 1xCS signaling messages toward the MME, and interacting with the SRVCC UE as described in TR 36.938. E-UTRAN may be capable of determining the neighbour cell list based on the "SRVCC operation possible" indication and/or presence of an established QCI=1 bearer for a specific UE. For details, refer to TS 23.216. © 2016 Qualcomm Technologies, Inc.


4-62


80-W3085-1 Rev A


IMS Emergency Call Flow in SRVCC to 3GPP2 1xCS The above simplified call flow refers to IMS Emergency calls to 3GPP2 SRVCC 1x CS in limited service mode. UE initiates emergency session over E-UTRAN as specified in 3GPP TS 23.167, and TS 23.401, and upon detecting handover is required from E-UTRAN to CDMA 1x, the SRVCC emergency procedures apply. To handover of Emergency session the network is aware that the UE and core network SRVCC and has information to identify Emergency session. When handover of the emergency session has been completed, the MME or the 1xRTT side may initiate location continuity procedures for the UE as defined in TS 23.271. The only difference between a normal SRVCC IMS to CS HO and IMS emergency HO to CS PSAP is as follows: For an emergency services session after HO is complete (step 8.0, in yellow above), if the control plane location solution is used on the source side, the source MME sends a Subscriber Location Report carrying an indication of the 1xRTT MSC (e.g., reference cell ID) to the GMLC associated with the source side to location continuity. This enables location continuity for the 1xRTT side. Alternatively, if a C Plane solution is not used on the source side, location continuity procedures shall be instigated on the 1xRTT side. (There is also a U plane solution available for legacy networks based on OMA Secure Plane (SUPL) standards to transfer Location Information between the UE (called secure End Terminal-SET) to eNB and to Secure Location Plane (SLP) server. However a SUPL client is required on the UE.



4-63


80-W3085-1 Rev A


VCC Reference Architecture 3GPP2 The above diagram illustrates the Voice Call Continuity (VCC) between Multi Media Domain (MMD)(equivalent to IMS). VCC allows s to move voice calls between CS domain and MMD, connected through different Internet Protocol-Connectivity Access Networks (IPCANs) (e.g., WLAN, HRPD). This architecture refers to an inter-technology Domain Transfer (DT) call model which s procedures that allow a use to DT from an HRPD or WLAN multimedia session with a voice component to a 1x CS voice session and from a 1x CS voice session to a WLAN VoIP session. The goal is to allow the core network to know precisely the current accessibility of the UE and to deliver services efficiently across the appropriate access network while minimizing the impact on the legacy systems. The VCC AS comprises two main functions: Assists in terminating services to a terminal that is 1x CS ed and/or IMS ed is involved in voice call setup signaling to facilitate HRPD/WLAN VoIP-to-1x CS voice call DTs and 1x CS voice call to WLAN VoIP DTs. The VCC AS is anchored in the call signaling path of all voice calls originated from, or terminated to, a VCC UE that is IMS ed and tuned to HRPD/WLAN, or 1x CS ed and tuned to 1x. It has the following signaling interfaces: VCC AS/S-CSCF (ISC): The VCC AS serves as a SIP Back-to-Back Agent (B2BUA) that interfaces to the S-CSCF via an ISC SIP signaling interface. VCC AS/I-CSCF (Ma): The VCC AS interfaces to an I-CSCF via an Ma SIP signaling interface. This interface is used to anchor the VCC AS in the call path by sending SIP request from I-CSCF directly to the VCC AS. VCC AS/HLR (MAP): The VCC AS interfaces to the 1x CS HLR using MAP in order to obtain routing information for terminating voice calls to a UE via the 1x CS network. VCC AS/HSS (Sh): The VCC AS also interfaces to the HSS via an Sh interface [MMD Part-10] using the diameter protocol to transfer data between the VCC AS and HSS. VCC AS/WIN S (MAP): The VCC AS interfaces to the WIN S using the MAP protocol in order to provide routing information for 1x voice call originations and terminations and to anchor the VCC AS in these calls. The WIN S may be integrated with the VCC AS or may be a standalone network element. Refer to X P0042 B V1.0 for details.



4-64


80-W3085-1 Rev A


LCS Measurements and Reporting Several implementation options for UE position estimation using control plane are in 3GPP: two main steps: signal measurements and position estimate based on the measurements using the eNodeB (network) or UE (assisted). These are network-assisted GNSS (Global Navigation Satellites Systems) methods: • Downlink positioning • Enhanced cell ID method – This is not very accurate and hence may not be suitable for emergency position location. • Hybrid positioning using multiple methods from the list of positioning methods above is also ed, as shown in the slide. A.1 MME receives a request for some location service associated with a particular target UE from another entity ESMLC or the MME itself decides to initiate some location service on behalf of a particular target UE as in the case of IMS emergency call from the UE. A.2 The SMLC sends the Location Request to the concerned eNodeB where the UE is in connected mode as an S1 AP on DL NAS transport. A.3 eNodeB after measurements sends a Location Report including CGI and the measurement result. A.4 The MME returns the location service results to E SMLC. Based on this implementation this is called NW assisted. B: The steps in in UE assisted measurements are also shown for positioning procedures in B call flow, which follows similar steps. Currently the implementations are based on network for LCS. Refer to TS 29.171 for more details (hybrid approach and SUPL implementations are not discussed here). C.1 The last part in the above call flow shows Location Update procedure as follows. The Location Request comes from GMLC (with QoS and UE ID, etc.) to the MME. If the requested location information and the location accuracy within the QoS can be satisfied based on parameters received from the MME and the parameters obtained by the RAN (eNodeB) e.g., cell coverage and timing information (i.e., RTT), the RAN may send a Location Report immediately. If the position method returns position measurements, the RAN uses them to compute a location estimate. If there has been a failure to obtain position measurements, the RAN may use the current cell information and, if available, RTT value to derive an approximate location estimate. If an already computed location estimate is returned for an UE based position method, the RAN may consistency with the current cell and, if available, RTT. If the location estimate so obtained does not satisfy the requested accuracy and sufficient response time still remains, the RAN may instigate a further location attempt using the same or a different position method. If a vertical location coordinate is requested but the RAN can only obtain horizontal coordinates, these may be returned. C.2 The MME makes a Location Request to the E SMLC. C.3 The ESMLC returns the location estimate/update to the MME. C.4 Having got the response from E SMLC, the MME returns the Location Response to the GMLC. © 2016 Qualcomm Technologies, Inc.


4-65


80-W3085-1 Rev A


Comments/Notes



4-66


80-W3085-1 Rev A

Section 5: VoLTE Supplementary Services and Emergency Calls



5-1


80-W3085-1 Rev A


Notes



5-2


80-W3085-1 Rev A


Notes



5-3


80-W3085-1 Rev A


Notes



5-4


80-W3085-1 Rev A


Notes



5-5


80-W3085-1 Rev A


Notes



5-6


80-W3085-1 Rev A


Notes



5-7


80-W3085-1 Rev A


Call Forwarding Unconditional (CFU) The call forwarding features CFNR, CFNRc, and CFB operate differently depending on whether the destination number is the Default Call Forwarding number provisioned by Switch Control in the Default Call Forwarding profile field or whether the destination number is a provided number provisioned using the Ut interface. 3GPP TS 24.604 The CFU service may operate on all communications, or just those associated with specified services. The served 's ability to originate communications is unaffected by the CFU supplementary service. After the CFU service has been activated, communications are forwarded independent of the status of the served . As a service provider option, a subscription option can be provided to enable the served to receive a reminder indication that the CFU service has been activated. This indication is provided when the served originates a communication and if the CFU service has been activated for the served 's address and for the service requested for the communication.



5-8


80-W3085-1 Rev A


Call Forwarding Unconditional 3GPP TS 24.604 Communication Forwarding Unconditional 1. Initial INVITE request towards B. 2. The URI-B is subscribed to the CFU service. 3-4. Using the IFC ( Initial Filter Criteria) the initial INVITE request is forwarded to the AS. 5. CFU Procedures are executed. 6-8. Depending on subscription option value “Originating is notified that his communication has been diverted (forwarded or deflected)”, a 181 response is sent towards the A indicating that the communication is diverted. 9. An initial INVITE request including URI-C as destination is sent back to the S-CSCF. 10. S-CSCF checks HSS to identify the location of -C. 11-12. Communication is routed towards -C. 13-18. 200 (OK) response is sent to the -A. 19-24. ACK request is send back to -C. 25. RTP media is established.



5-9


80-W3085-1 Rev A


Call Forwarding No Reply CFNR is invoked when the called party UE rings and is unanswered until the configured ring cycle timer expires (default 20 sec). In this flow, UE-A calls UE-B who does not respond within 20 sec and the call is forwarded as per UE-B’s CFNR setting to Carol, who is another VoLTE on VoLTE RAN. The CFNR service enables a served to have the network redirect to another communications that are addressed to the served 's address, and for which the connection is not established within a defined period of time. The CFNR service may operate on all communications, or just those associated with specified services. The served 's ability to originate communications is unaffected by the CFNR supplementary service. The CFNR service can only be invoked by the network after the communication has been offered to the served and an indication that the called is being informed of the communication has been received. As a service provider option, a subscription option can be provided to enable the served to receive a reminder indication that the CFNR service has been activated. This indication is provided when the served originates a communication and if the CFNR service has been activated for both the served 's address and the service requested for the communication.



5-10


80-W3085-1 Rev A


Call Forwarding on No Reply 3GPP TS 24.604 and 24.082 B has activated the CFNR service. A is sending a communication request towards B: 1-2. Initial INVITE request towards B. The URI-B is subscribed to the CFU service. 3. Using the IFC the initial INVITE request is forwarded to the AS. 4. The initial INVITE request is forwarded to B due to normal communication procedures. 5-6. The initial INVITE request is forwarded to B due to normal communication procedures. 7-9. A 180 (Ringing) response is sent back to the AS indicating that the terminating UE is ringing. 10. The no-reply timer in the AS is started.

11-13. The previous 180 (Ringing) response is sent towards the originating indicating that the terminating UE is ringing. 14. The timer expires. 15-17. In this case, the option to not continue ringing the forwarding applies, therefore to release the communication to B the AS sends a CANCEL request 18-20. The 200 (OK) response for the CANCEL request is sent back to the AS. © 2016 Qualcomm Technologies, Inc.


5-11


80-W3085-1 Rev A


Call Forwarding on No Reply (continued) 3GPP TS 24.604 and 24.082 21-23. Depending on the value of subscription option "Originating receives notification that his communication has been diverted (forwarded or deflected)", a 181 (Call Is Being Forwarded) response is sent towards the A indicating that the communication is diverted. 24-26. A 487 (Request Terminated) response with a ACK request finalize the termination of the dialog between AS and UE:B. 27-29. The ACK for the 487 (Request Terminated) response is sent back to -B. 30. An initial INVITE request including URI-C as destination is sent back to the S-CSCF. Additionally, the History-Info header is included. 34-39. A 180 (Ringing) response is sent back to the originating including a History-Info header, as shown above. If no restriction is given the diverted-to will be presented at the UE of A.

40-45. The 200 (OK) response from -C is sent back to the -A. 46-51. The ACK request is sent back to -C. 52. RTP media is established.



5-12


80-W3085-1 Rev A


Call Forwarding Busy (CFB) 3GPP TS 24.604 and 24.082 The CFB service enables a served to have the network redirect to other communications, which are addressed to the served 's address and meet busy. The CFB service may operate on all communications, or just those associated with specified services. The served 's ability to originate communications is unaffected by the CFB supplementary service. As a service provider option, a subscription option can be provided to enable the served to receive a reminder indication that the CFB service has been activated. This indication is provided when the served originates a communication and if the CFB service has been activated for the served 's address and for the service requested for the communication.



5-13


80-W3085-1 Rev A


Call Forwarding Busy Refer to TS 3GPP 24.604 Appendix A.1.4 for details B has activated the CFB service. A is sending a communication request towards B: 1-2. Initial INVITE request towards B. The URI-B is subscribed to the CFU service. 3. Using the IFC the initial INVITE request is forwarded to the AS. 4. The initial INVITE request is forwarded to B due to normal communication procedures. 5-6. The initial INVITE request is forwarded to B due to normal communication procedures. 8-9. A 486 response is sent back to the P-CSCF and forwarded to S-CSCF indicating that the terminating UE is busy. 10. S-CSCF informs the AS of the Busy status of UE-B. 12-14. AS informs the UE-A that call is now being forwarded since UE-B is busy. 15. AS sends invite to S-CSCF with URI of URI C. 17-18. SIP URI for UE C is sent by P-CSCF to S-CSCF to UE-C. 19-24. 180 Ringing is sent to UE-A.



5-14


80-W3085-1 Rev A


Call Forwarding Busy (continued) 25-36. OK and ACK messages are exchanged. 37. RTP Media is established between UE-A and UE-C.



5-15


80-W3085-1 Rev A


Call Forwarding Not Reachable Since the precise reason why a ed UE is not responding to INVITE messages does not matter and may involve any number of network elements and error conditions, all SIP error responses (4xx except 486, 5xx, and 6xx) received by the TAS trigger the CFNRc response. In addition, select internal TAS errors, namely the timeout waiting for the 100 TRYING response, will also trigger CFNRc. Contrary to the TS 24.604 CFNRc standard, CFNRc will be triggered regardless of whether a provisional response (180 or 183) precedes the final error response.



5-16


80-W3085-1 Rev A


Communication Forwarding Not Reachable (CFNRc) – ed 1. The call proceeds as a normal MT call. 2. At message 5/6, the SCC‐AS sends the call to the P‐CSCF. 3. At message 7, after a timer expires in the SCC‐AS waiting for a response other than 100 TRYING, the SCC‐AS sends a CANCEL, which is ed to the P‐CSCF in message 9. 4. A potential race condition is documented in messages 11a – 11d where the P‐CSCF may respond with a SIP 5xx code that gets returned to the SCC‐AS. This is ignored if the SCC‐AS has already canceled the attempt. 5. Normal circuit switch terminating processing continues with the call being forwarded to the MSRN retrieved from the HLR. This is all as normal for a terminating call attempt until message 25 where due to a paging timeout in the circuit switch network, the MGCF will respond with a SIP error code. 6. The IMS core returns this error code transparently to the TAS in message 29 where it triggers CFNRc. 7. From this point forward, if the call is being sent to the default voicemail destination or a PSTN number, the flow will be Call Forwarding to default VM on no answer/busy part . If the call is being sent to an LTE attached VoLTE number, then the flow follows as is the case with Call Forwarding No Reply for Manually Provisioned to VoLTE Target.



5-17


80-W3085-1 Rev A


Notes



5-18


80-W3085-1 Rev A


Call Forwarding Not Reachable (CFNRc) – Uned Scenario 1. UE-A calls UE-B. Following normal MO/MT processing for a pair of LTE RAN attached UEs. 2. UE-B’s S‐CSCF sends INVITE to TAS‐UE-B. 3. TAS‐UE-B sends INVITE to S‐CSCF. 4. S‐CSCF sends INVITE to SCC‐AS UE-B. 5. SCC‐AS UE-B knows from the registration status in the INVITE that there is no HSS IMS registration for UE-B so the Terminating Access Domain Selection (TADS) function queries the HLR for a circuit switch location. 6. The HLR responds with the “Absent Subscriber” message since there is no circuit switch registration. 7. SCC‐AS UE-B internally generates and returns 480 to S‐CSCF. 8. S‐CSCF returns 480 to TAS‐UE-B. 9. TAS returns ACK to S‐CSCF. 10. S‐CSCF returns ACK to SCC‐AS UE-B At this point, if UE-B has configured CFNRc to forward to a VoLTE attached third party, the flow continues exactly like the CFU flow in slide 9 “Call Forwarding Unconditional,” starting at message 3, except the cause code value will be “480.” If UE-B has the default CFNRc configuration where the call goes to voicemail. © 2016 Qualcomm Technologies, Inc.


5-19


80-W3085-1 Rev A


Notes



5-20


80-W3085-1 Rev A


Call Barring 3GPP Ts 24.611 and 24.088 The Incoming Communication Barring (ICB) service makes it possible for a to have barring of certain categories of incoming communications according to a provisioned or configured barring program and is valid for all incoming communications. A barring program is expressed as a set of rules in which the rules have a conditional part and an action part. Examples of conditions are whether the asserted originating public identity matches a specific public identity or whether the originating public identity is restricted (anonymous). The action part could specify for a rule that contains a matching condition that the specific incoming communication is barred. The complete set of conditions and actions that apply to this service and their semantics is described in subclause 4.9. The Inhibition of Incoming Forwarded Calls is a special case of the ICB and allows the served to reject incoming communications from s or subscribers who have diverted the communication towards the served . The communication history information will be used to trigger the service as described in subclause 4.9. The Anonymous Communication Rejection (ACR) service allows the served to reject incoming communications on which the asserted public identity of the originating is restricted. In case the asserted public identity of the originating is not provided then the communication is allowed by the ACR service. An example where the originating restricts presentation of the asserted public identity is when he activated the OIR service 3GPP TS 24.607 [3]. The originating is given an appropriate indication that the communication has been rejected due to the application of the ACR service. The ACR service is a special case of the ICB service, which is highlighted here because it is a regulatory service in many countries. The ACR service can be activated for a specific subscriber by configuring an ICB service barring rule where the conditional part contains the "Condition=anonymous" and the action part "allow=false." The Outgoing Communication Barring (OCB) service makes it possible for a to have barring of certain categories of outgoing communications according to a provisioned or configured barring program and is valid for all outgoing communications. A barring program is expressed as a set of rules in which the rules have a conditional part and an action part. An example condition is whether the request uri matches a specific public identity. The action part can specify for a rule that contains a matching condition that the specific outgoing communication it to be barred. The complete set of conditions and actions that apply to this service and their semantics is described in subclause 4.9.



5-21


80-W3085-1 Rev A


Anonymous Call Rejection (ACR) 3GPP TS 24.611 1-2. INVITE request (UE to S-CSCF) – The incoming INVITE request is sent to the S-CSCF serving UE-B. The INVITE request includes a Privacy header field set to one of the following values: "id" or "header" or "." 3. Evaluation of initial filter criteria. The initial Filter criteria indicates that the called is subscribed to the ACR service. Therefore the S-CSCF forwards the INVITE request to the ACR AS. 4-5. INVITE request (S-CSCF to AS) - INVITE is sent to the AS. 6-8. 433 (Anonymity Disallowed) response. (AS to UE) AS has identified that the call is anonymous and answers with a 433 (Anonymity Disallowed) response. 9-10. The originating party acknowledges the final response with ACK.



5-22


80-W3085-1 Rev A


Notes



5-23


80-W3085-1 Rev A


3-Way Conference Call 3GPP 24.605 This slide depictures a flow where two UEs, UE-1 and UE-2, are engaged in a call. At some point in time, UE-1 decides to involve UE-3 into the communication and activate the 3PTY CONF service. UE-1 puts UE-2 on hold, initiates a session toward UE-3 to get the 's permission to start 3PTY call, creates the conference, and moves the original communication with both UE-2 and UE-3 to the conference server. 1. UE-1 and UE-2 are in an active call. 2. UE-1 puts UE-2 on hold before invoking the 3-Way Calling with UE-3. 3-8. UE-1 establishes a call with UE-3 following normal call setup procedure and gets UE-3’s permission to start the 3-Way Calling. 9. UE-1 sends an INVITE request to the conference server to establish a conference session. 10. The Conference Server (CS) coordinates with MRFP to allocate conference resources. 11~12. The CS sends a 200 (OK) response and receives an ACK request from UE-1. 13. UE-1 sends a REFER request to UE-2 with the Refer-To header set to the address of the CS; UE-2 accepts the REFER request. 14. UE-2 sends an INVITE request to the CS to the conference. 15-16. The CS sends a 200 (OK) response to UE-2 and receives an ACK request. © 2016 Qualcomm Technologies, Inc.


5-24


80-W3085-1 Rev A


3-Way Conference Call (continued) 17-18. UE-2 sends a NOTIFY request to UE-1 to indicate that it has finished action required by the REFER request.

19-20. UE-1 sends a BYE request to terminate the call between itself and UE-2. 21. In parallel to step 13, UE-1 sends a REFER request to UE-3 with the Refer-To header set to the address of the CS; UE-3 accepts the REFER request. 22. UE-3 sends a NOTIFY request to UE-1 to indicate that UE-3 is acting on the REFER request. 23. UE-3 sends an INVITE request to the CS to the conference. 24-25. The CS sends a 200 (OK) response to UE-3 and receives an ACK request. 26. UE-3 sends a NOTIFY request to UE-1 to indicate that it has finished action required by the REFER request.

27-29. UE-1 sends a BYE request to terminate the call between itself and UE-3.



5-25


80-W3085-1 Rev A


Notes



5-26


80-W3085-1 Rev A


Call Hold Reference For details of Call Hold, refer to 3GPP TS 24.610.



5-27


80-W3085-1 Rev A


Notes



5-28


80-W3085-1 Rev A


Notes



5-29


80-W3085-1 Rev A


Call Waiting For details on Call Waiting, refer to 3GPP TS 24.615. The next slides discuss the Accepted Waiting call case. Signaling for Ignored and Declined scenarios is operator-specific.



5-30


80-W3085-1 Rev A


Notes



5-31


80-W3085-1 Rev A


Notes



5-32


80-W3085-1 Rev A


Notes



5-33


80-W3085-1 Rev A


IMS Emergency Services 3GPP TS 23.167 Rel 8/9 specifies many options for providing IMS emergency sessions. These options allow operators to tailor emergency services to meet their own requirements as well as those of local regulatory agencies. Therefore, the delivery methods of IMS based emergency services and related signaling will likely to vary significantly across different regions and operators worldwide. Standards allow UEs that are attached or camped on a cell in limited mode (with out a USIM or USIM with Access Class barred) to access emergency services. Limited service state is used to describe specific situation when UE cannot obtain normal services

• UE enters in limited service state when it is without SIM. • UE enters in limited service when there is no cell available from the HPLMN/EHPLMN (i.e., subscribed network) as in roaming situations or in Forbidden PLMN.

• Limited service state can also be defined as a state in which only emergency services can be provided to UE.

• Access class barring is enabled for certain cells that are reserved for operator testing. UEs in limited service state determine that a cell s emergency services over E-UTRAN from a broadcast indicator in SIB1 (if absent, IMS emergency call is not ed by the network in the cell for UEs in limited service mode). The UEs that camp normally on a cell are informed that the PLMN s emergency services over E-UTRAN from the Emergency Bearer Service (EMC BS) indicator in the Attach and TAU procedures. Further, parameters in SIB2 determine if emergency services are allowed and/or if it is restricted for UEs with certain Access Class. Details on this can be found in 3GPP 36.331.



5-34


80-W3085-1 Rev A


IMS Emergency Services: Requirements For a UE to make an Emergency call without a valid subscription (in HSS), the LTE network needs to define an Emergency APN. When a UE wants to perform emergency attach, it will send an attach request with attach type as Emergency Attach. Upon receiving this attach, MME may or may not HSS for Authentication and the call may proceed without Authentication. When Emergency Attach is received, Authentication/Security procedures are optional. MME Emergency Configuration data is needed in MME, where Emergency APN is stored. Optionally, QoS parameters and the static PDN GW address can be stored. Upon receiving an Emergency attach, MME knows where to send the Create Session Request. When the UE initiates an Emergency session establishment without prior IMS registration, it shall include both the "anonymous " and "emergency service" indications in the emergency session establishment request to the P-CSCF. Based on local regulation and an operator’s policy, the P-CSCF may reject "anonymous " Emergency session establishment with an appropriate error code. A UE shall not reattempt the "anonymous " emergency session again via the same network. When P-CSCF accepts the "anonymous " Emergency session establishment, it forwards this request to an appropriate E-CSCF, although no security association between UE and P-CSCF is established. The E-CSCF shall follow the same rules and procedure as defined for the Emergency Session Establishment in the Serving IMS network to route the anonymous emergency session.



5-35


80-W3085-1 Rev A


Reference Architecture for IMS Emergency Services 3GPP IMS Emergency Architecture This slide illustrates a reference architecture specified in 3GPP(TS 36.167). The blue and yellow boxes shown are the usual LTE NW entities and the new IMS entities (are in green E CSCF and EATF), while the new entities related to LCS (are in green are LCS Control Plane entities) and finally PSAP in pink. 3GPP-defined positioning methods for LTE using LTE Positioning Protocol (LPP) is designed also to accommodate other positioning technologies in the future. The location service architecture specified for LTE consists of the evolved SMLC connected to the MME over the new SLs interface. With this architecture LS continuity is possible during intra-eNB and inter-eNB handovers without MME relocation. The E-SMLC communicates with the UE for location services and assistance data delivery using the new LPP protocol. It communicates with the eNB for eNB almanac and other assistance data using the LPPa. External or network initiated location service requests are forwarded through the GMLC to the MME via the SLg, which performs the LCS subscription authorization function. While 3GPP standards provide for a control plane based LCS information transport as shown above, a hybrid approach using Secure Plane (SUPL) transport for LCS (OMA) could be used as well.



5-36


80-W3085-1 Rev A


Establishing UE Detected IMS Emergency Calls 3GPP These are the essential steps for an IMS emergency session or service. 1. The UE can make an initial attachment for an emergency session or the UE may request a PDN connection for an emergency session. 2. UE can detect a request for an emergency call/session needs to allocate a special public identifier for the service such as [email protected]. 3. UE conducts RRC Connection establishment with an emergency indication. 4. UE requests PDN connectivity with an emergency indication. MME selects an emergency APN based on emergency configuration data and requests PDN GW to establish a default bearer. This is done in parallel to an existing PDN connectivity to IMS APN. 5. The PCRF creates and delivers a policy rule to the P-GW. 6. UE executes and IMS emergency registration using the received IP address and P-CSCF address. This registration is done in parallel to an existing regular registration. 7. P-CSCF detects an emergency service request from UE, differentiates it from normal registration by prioritizing. P-CSCF determines which E CSCF for handling the call/session and routes the message to that E CSCF. 8. The E-CSCF routes the call to the PSAP. 9. The remainder of the emergency call establishment occurs.



5-37


80-W3085-1 Rev A


Establishing UE Position and Tracking IMS Emergency Calls 3GPP These are the essential steps after an IMS emergency session is established for obtaining UE position information.

1.

MME sends a location report to a GMLC in the network that is designated to location of emergency calls. The location report carries the UE identity (e.g., IMSI) and the MME IP address (how MME gets the LR is explained in the appendix).

2.

The GMLC acknowledges the location report.

3.

UE executes and IMS emergency registration using the received IP address and P-CSCF address. This registration is done in parallel to an existing regular registration.

4.

P-CSCF detects an emergency service request from UE, differentiates it from normal registration by prioritizing. P-CSCF determines which E CSCF for handling the call/session and routes the message to that E-CSCF.

5.

The E-CSCF sends a location and/or routing request to an LRF, which forwards this to an associated GMLC.

6.

The GMLC obtains location information for the UE using a procedure applicable to the architecture.

7.

The GMLC returns the location information to the LRF, which may use this to obtain PSAP routing information. The LRF then returns the location and/or PSAP routing information to the E-CSCF. Correlation information (e.g., an Emergency Service Query Key (ESQK)) can also be included. ESQK is a mechanism to retrieve additional information after the call is initially delivered to the PSAP. It allowed the PSAP operator to 're-bid' on the ESQK and get back current location information.

8.

The E-CSCF routes the call to the PSAP indicated by the LRF. Any ESQK can also be sent to the PSAP.

9.

The remainder of the emergency call establishment occurs.

10. The PSAP sends a request to the LRF (e.g., determined using the ESQK) for the location of the UE. The LRF forwards the request to the associated GMLC.

11. The GMLC obtains location information for the UE using the same procedure and returns to the LRF. © 2016 Qualcomm Technologies, Inc.


5-38


80-W3085-1 Rev A


Specifications References 3GPP specifications are available at www.3gpp.org. IETF RFCs are available at www.ietf.org. GSMA documents are available at www.gsma.com.



5-39


80-W3085-1 Rev A


Notes



5-40


80-W3085-1 Rev A


Notes



5-41


80-W3085-1 Rev A


Notes



5-42


80-W3085-1 Rev A


Notes



5-43


80-W3085-1 Rev A


Comments/Notes



5-44

80-W3085-1 Rev A

VoLTE and IMS – Overview, Protocols, and Performance Section 6: Voice Mobility from LTE to 2G/3G (SRVCC)



6-1

80-W3085-1 Rev A


Notes



6-2

80-W3085-1 Rev A


Objectives

• Typical domain preferences for voice-centric VoLTE devices: – Voice domain: IMS PS voice preferred, CS voice secondary – SMS domain: PS SMS preferred

• VoLTE capabilities are exchanged in an LTE network during initial ATTACH process. – UE indicates VoLTE through FGI bits and ed PD parameters using UE Capability Information message. – Network indicates IMS VoPS in ATTACH Accept.

• P-CSCF discovery must be accomplished prior to IMS registration. • SIP messaging used by VoLTE devices for IMS registration, deregistration, call setup, and call release.

• MSC server enhanced to provide SRVCC functionality and SCC AS facilitates seamless transfer of VoLTE call to legacy 3GPP networks.



6-3

80-W3085-1 Rev A


Notes



6-4

80-W3085-1 Rev A


Notes



6-5

80-W3085-1 Rev A


SRVCC Standard Evolution in 3GPP eSRVCC eSRVCC is an enhanced version of the SRVCC. The SRVCC follows the basic policy of IMS call, which causes a processing delay during the communication path switching from VoLTE to CS domain, especially during roaming scenarios. as an enhancement the eSRVCC was developed to reduce the duration required for the switch to occur. Voice call traffic (signaling and media) is now confined in the visited network (ATGW/ATCF), forcing the call to be anchored in the visited network instead of the mobile terminal. This facilitates the path switching during SRVCC. aSRVCC The SRVCC in alerting phase feature adds the ability to perform access transfer of media of an instant message session in packet-switched to circuit-switched direction in alerting phase for access transfers. bSRVCC Ability to perform SRVCC before the alerting phase of the VoLTE call. Mid-call feature This feature was introduced in Rel 9 for dual radio UE, where session transfer of held session, active session, and conference session can be transferred from one domain to another. However enhancement for the MSC was introduced in Rel 10 to allow a single radio UE to the mid-call feature. MSC server-assisted mid-call feature enables packet-switched/circuit-switched access transfer for the UEs not using IMS centralized service capabilities, while preserving the provision of mid-call services (inactive sessions or sessions using the conference service).



6-6

80-W3085-1 Rev A


E-UTRAN to UTRAN/GERAN SRVCC (Rel 9) The above figure illustrates a scenario where UE1 is assumed to be in an LTE Visited network with an IMS VoLTE call to UE2 in the Home Network. The call control (SCC-AS ) and IMS voice media anchor is assumed to be in Home Network as shown in the blue circle. 1.

Voice media path (PS) between the two UEs is shown as a solid blue line with SIP signaling as a light blue dotted PS path over LTE before HO(1). When the eNodeB in the visited network decides to switch the radio path (PS-to-CS handover) from LTE to UMTS, the eNodeB commands SRVCC AS process through MME and MSC (shown as black dashed line). eNodeB sends a radio switching request to MME following which MME requests the MSC to allocate CS resources. MSC proceeds with securing bearer path resource reservation between itself and RNC/NodeB on UMTS side, shown as a black dashed line CS Bearer reservation in UTRAN(2).

2.

MSC then sends an access path switching request to SCC AS via CSCF in IMS of the Home Network, shown as a black dashed line all the way to the Home network, Access Switching request (3).

3.

SCC AS, having received the request, instructs the UE2 to change route or switch the destination of voice media from PGW of the Home network to MSC MGW in the Home Network, shown as a black dashed line, path switching command (4).

4.

In parallel, MSC sends MME a response to its request for allocating resources on the UMTS side and the MME commands UE1 via eNodeB to switch to UMTS radio (CS), shown as a black dashed line, radio switching command (5).

5.

After UE1 is switched to UMTS (CS) the transmission path for SIP signaling and Voice (PS) data path are switched between MSC and UE2. Voice call is continued via CS by the MSC-MGW doing a CS to PS bearer conversion, shown as red dotted (signaling) and thick (media) lines, CS path after HO(6).

6.

There are two interruptions, one at the UE1 originating end (visited network in this case) due to HO and session transfer and media switch at the UE2 terminating end (Home network). Usually the HO interruption is the longer of the two, between HO and session transfer interruptions.

7.

The UE2 remains in PS domain all the time. There is no SRVCC on this side. Only UE 1 goes through PS-CS HO.



6-7

80-W3085-1 Rev A


E-UTRAN to UTRAN SRVCC Call Flow – Rel 9 For a VoLTE call, the UE initiates an IMS multimedia session and uses only PS media flow. The request is forwarded to S-CSCF and the session is anchored at SCC AS to enable Session Transfer. The call flow steps are: 1.

SRVCC capability negotiation during aThe SRVCC STN (Session Transfer Number) along with other information is ed to MME from HSS during the E-UTRAN attach procedure, and these are used by MSC for enabling PSCS service continuity of IMS multimedia sessions.

2.

Attach, UE capability Inquiry, and UE establishes PS VoIP call. UE measures the Serving Cell and reports an A2 event as the Serving Cell falls below a certain threshold.

3.

Network configures UE with UTRAN channel measurements and measurement gap information. UE reports B2 event to eNB as E-UTRAN Serving Cell falls below a certain threshold and UTRAN Cell becomes better than another threshold.

4.

E-UTRAN indicates to MME that this is an SRVCC handover. •

MME sends a PS-CS request to UTRAN MSC enhanced with SRVCC capabilities along with IMSI, SRVCC STN, and other information.

•

The MSC initiates the SRVCC handover preparations and also initiates the SRVCC session transfer with IMS domain to maintain Voice call continuity. MSC then sends a PS-CS response to MME once preparations are complete on CS side.

5.

eNB sends E-UTRAN to UTRAN IRAT HO command to UE.

6.

UE acquires UTRAN and completes handover.

7.

CS Voice call is established over UTRAN.



6-8

80-W3085-1 Rev A


E-UTRAN to UTRAN/GERAN SRVCC – Rel 10 In SRVCC Rel 9, since the IMS call control with media anchor is in Home Network, in a visited network for roaming situation, as illustrated in the previous slide, there will be processing delays in communications for control and path switching for UE2, which is in Home Network even though HO (RAN part) for UE1 takes place in the Visited Network. SRVCC Rel 10 is also called as eSRVCC, which provided enhancements with new functional entities Access Transfer Control Function (ATCF) and Access Transfer GW, which could be part of CSCF or MSC server. Application of ATGW would avoid path switching between PGW (LTE) and MGW(s) (UMTS) for the terminating UE when the IMS originating UE handed over the IMS VoLTE call from PS to CS. Because access path switching request in Rel 9 goes all the way from Visited to Home Network, this delay and also interruption for media switching is avoided in Rel 10. The deviations in call control from Rel 9 are explained in the following steps.

1.

Voice media and SIP control signal path over LTE are indicated in thick and dotted blue lines.

2.

When eNodeB decides to do SRVCC HO, it sends a request to MME, which in turn reaches RNC. A bearer path resource reservation is shown with dashed black line.

3.

Access path switching request, shown as a dashed black line, would now go ATCF locally in the Visited network instead to SCC-AS (and CSCF) all the way to Home network, which saves transport delays.

4.

Path switching command, shown as a dashed black line from ATCF, goes to ATGW locally. ATCF and ATGW shown as separate entities, in reality could be the same physical box.

5.

RAN switching command, shown as a dashed black line, goes to eNodeB from MME, as shown earlier.

6.

Voice media and SIP control signaling are shown now as a red line and dotted black line after voice HO.

While the originating UE has changed from PS to CS, there is no media path switching as such in the Visited network as the UE2 is always in connection with ATGW, since the MGW and the PGW have transport links to ATGW. As shown, eSRVCC reduces the media interruption time and brings it down to meet the 3GPP TS 25.913 requirement of maximum media interruption time of 300 ms.



6-9

80-W3085-1 Rev A


Notes



6-10

80-W3085-1 Rev A


SRVCC – UE Requirements SRVC to UTRAN FGI bits: The UE shall also during capability negotiation that it can monitor UTRAN and GERAN networks while in the RRC Connected state by:

• Including GERAN MS Class Mark 3 if GERAN access is ed • Including MS Class Mark 2 if GERAN or UTRAN access or both are ed



6-11

80-W3085-1 Rev A


SRVCC – Network Requirements To the SRVCC at system level, new functionalities are required in network architecture:

• SRVCC-enhanced MSC server – Prepares the radio access resources for domain transfer – Provides an interface towards EPC – Updates the source side of session after domain transfer – Acts as an anchor towards the target MSC in case inter-MSC handover is required • SCC AS – Anchors the VoLTE session during establishment phase to facilitate the session transfer when needed at a later stage – Responsible for the access transfer from one domain to another – Routes terminating calls to a VoLTE subscriber after domain transfer • MME – Indicates to eNB if SRVCC is possible for a current session – Invokes enhanced MSC to provide resources for UE for session transfer – Moves EPC PS bearers (data and voice) to the target access domain (UMTS/GSM) • eNB – Provides SRVCC relevant measurement report configuration to UE – Determines if SRVCC needs to be performed – Invokes MME to initiate SRVCC © 2016 Qualcomm Technologies, Inc.


6-12

80-W3085-1 Rev A


SRVCC Enhancement in Rel 10 As an enhancement to SRVCC, enhanced SRVCC (eSRVCC) optimizes the SRVCC networking scheme. The media is anchored on the ATGW for a call during which a handover is likely to occur. During the handover of a UE, the ATCF anchors the media information of the UE on the ATGW so the remote media information does not need to be updated. The i2 interface between the enhanced MSC and the SCC AS facilitates the exchange of the session state information directly between these two nodes.



6-13

80-W3085-1 Rev A


Notes



6-14

80-W3085-1 Rev A


SRVCC Enhancement in Rel 10 – eSRVCC IMS sessions from and to a UE are anchored at the SCC AS in the home IMS and may also be anchored at the ATCF in the serving (visited if roaming) network to provide Service Continuity for the during transition between two Access Networks. Release 8/9

• SRVCC call is anchored at the SCC AS, causing a total delay of 200 to 250 ms for regular SRVCC in the home network.

• For a roaming scenario, an additional delay of 400 tp 500 ms is incurred because the SCC AS in the home network has to be ed for SRVCC session transfer.

• Delay includes voice interruption on SRVCC UE during handover and the additional delay for media/signaling path switch for remote UE during SRVCC handover.



6-15

80-W3085-1 Rev A


SRVCC Enhancement in Rel 10 – aSRVCC Alerting Phase Refers to a SIP session for which all possibly existing dialogs created by the SIP INVITE request initiating the session are early dialogs, for which no final SIP response has been received yet and for which SIP 180 (Ringing) response has already been received in an existing early dialogues.



6-16

80-W3085-1 Rev A


aSRVCC Call Flow Session transfer for originating call is in alerting phase using SRVCC procedure – PS to CS To fulfill the requirements for PS-CS access transfer in SRVCC for calls in alerting state, the UE needs to be engaged in a session with speech media component in early dialog state according to the following conditions before SRVCC access transfer is performed: • A SIP 180 (Ringing) response for the initial SIP INVITE request to establish this session has been sent or received; and • A SIP final response for the initial SIP INVITE request to establish this session has not been sent or received. In the example flow, UE A has invited for an originating session with speech media component which is anchored at SCC AS. The session is in alerting phase. Based upon measurement reports sent from the UE to E-UTRAN, the source E-UTRAN decides to trigger SRVCC handover to CS access The UE that s single radio PS to CS access transfer for calls in alerting state shall include the g.3gpp.srvccalerting media feature tag in the header field of the SIP INVITE request. This media feature-tag when used in a header field of a SIP request or a SIP response indicates that the functional entity sending the SIP message s SRVCC access transfer for calls in alerting phase, i.e. for calls with early dialog. This media feature-tag when used in a Record-Route header field of a SIP request or a SIP response indicates: •

That the functional entity sending the SIP message s access transfer for calls in alerting phase; and

•

All entities of which the sender of the message is aware of being requested to the feature do access transfer for calls in alerting phase.

Values appropriate for use with this feature-tag: None



6-17

80-W3085-1 Rev A


Notes



6-18

80-W3085-1 Rev A


rSRVCC Rel 11 Call flow can be found in TS 23.216 V11 Clause 6.4.



6-19

80-W3085-1 Rev A


Reverse SRVCC Rel 11 3GPP Reference: TS 23.216v11



6-20

80-W3085-1 Rev A


Notes



6-21

80-W3085-1 Rev A


Notes



6-22

80-W3085-1 Rev A


Notes



6-23

80-W3085-1 Rev A


Notes



6-24

80-W3085-1 Rev A


Notes



6-25

80-W3085-1 Rev A


Notes



6-26

80-W3085-1 Rev A


Notes



6-27

80-W3085-1 Rev A


Notes



6-28

80-W3085-1 Rev A


E-UTRAN and 3GPP2 1xCS (Rel 9) Architecture 1x CS IWS is enhanced for SRVCC to 3GPP2 1x CS interworking, which emulates a 1xRTT BSS towards the 1x RTT MSC. See the following specifications for more information:

1. TS 23. 402: Architecture enhancements for non-3GPP accesses 2. X P0042 V1.0: Voice Call Continuity between IMS and Circuit-Switched Systems



6-29

80-W3085-1 Rev A


SRVCC Call Flow in 3GPP2 1xCS (Rel 9) The call flow is similar to 3GPP UTRAN/GERAN except in here, 1x CS IWS is involved between the MME and the 1x RTT MSC server.



6-30

80-W3085-1 Rev A


Notes



6-31

80-W3085-1 Rev A


IMS Emergency SRVCC (Rel 9) Call Flow Details The above figure illustrates a scenario where IMS emergency calls goes through SRVCC.

1. IMS Voice media path (PS) between the UE and PSAP is shown as a solid blue line with SIP signaling as a light blue dotted line.

When the eNodeB in the network decides to switch the radio path (PS-to CS handover) from LTE to UMTS, the eNodeB commands SRVCC process through MME. eNodeB sends a radio switching request to MME, following which the MME requests the MSC to allocate CS resources.

2. MSC proceeds with securing bearer path resource reservation between itself and RNC/NodeB on UMTS side shown as a black dashed line.

3. MSC then sends an access path switching request to EATF via CSCF in IMS of the Home Network shown as a dotted blue line. EATF functionally takes the role of SRVCC AS of a normal SRVCC architecture.

4. EATF, having received the request, instructs the PSAP to change route or switch the destination of voice media from PGW to MSC MGW in the Home Network shown as a black dashed line.

5. In parallel MSC sends MME a response to its request for allocating resources on the UMTS side and the MME commands UE via eNodeB to switch to UMTS radio (CS) shown as a black dashed line.

6. After the UE is switched to UMTS (CS), the transmission path for SIP signaling and Voice (PS) data path are switched between MSC and PSAP. Voice call is continued via CS by the MSC MGW doing a CS to PS bearer conversion shown as red dotted and thick lines.

There are two interruptions, one at the UE1 originating end (visited network in this case) due to HO and session transfer and other at the UE2 terminating end (Home network) due to session transfer and media switch. Usually the HO interruption is the longer of the two, between HO and session transfer.



6-32

80-W3085-1 Rev A


IMS Emergency Calls in SRVCC to 3GPP2 WLAN/1x UEs are capable of being in simultaneous full-duplex communication with both a WLAN access network and a 1x radio access network unlike HRPD/1x UEs. Refer to 3GPP TS 23.216 and 3GPP2 X P0042 v1.0 for details.



6-33

80-W3085-1 Rev A


SRVCC Reference Architecture to 3GPP2 1xCS The above architecture is the same as presented in SRVCC having an additional functional entity to those defined in the E-UTRAN architecture TS 23.402, called 1x CS SRVCC interworking solution function (3GPP2 1xCS IWS), not shown in the figure because the figure only shows only the necessary components related to 3GPP2 1xCS IWS. 3GPP2 1xCS IWS uses the S102 reference point to communicate with the MME and to transport 3GPP2 1xCS signaling messages to the SRVCC UE. The role of the 3GPP2 1xCS IWS is to be a signalling tunnelling end point towards the MME for receiving/sending encapsulated 3GPP2 1xCS signaling messages to/from the UE; and to emulate a 1xRTT BSS towards the 1xRTT MSC (reference point A1 as defined in 3GPP2 A.S0014 between 1xBSS and MSC). If the MME s interworking to 3GPP2 1xCS, the MME shall follow the rules and procedures described in TS 23.402 with the following additions and clarifications:

•

To be a signaling tunneling end point towards the 3GPP2 1xCS IWS for sending/receiving encapsulated 3GPP2 1xCS signalling messages to/from the UE, which are encapsulated in S1-MME S1 Information Transfer messages (TR 36.938).

•

Release of the E-UTRAN resources after SRVCC to the 3GPP2 1xCS is completed.

•

Include information to enable 3GPP2 network to determine emergency session.

•

Insert the equipment identifier during the handover procedure for the case UE operating in limited service mode.

UE needs to 3GPP2 1xCS access, which means that it is capable of performing SRVCC to the 3GPP2 1xCS system. The interaction between UE and E-UTRAN is described in TR 36.938. The interaction with the 3GPP2 1xCS system is described in TS 23.216. If the E-UTRAN (operator) s interworking to 3GPP2 1xCS, the E-UTRAN performs the HO trigger, tunneling of the 3GPP2 1xCS signalling messages toward the MME, and interacting with the SRVCC UE as described in TR 36.938. E-UTRAN may be capable of determining the neighbor cell list based on the "SRVCC operation possible" indication and/or presence of an established QCI=1 bearer for a specific UE. For details refer to TS 23.216.



6-34

80-W3085-1 Rev A


IMS Emergency Call Flow in SRVCC to 3GPP2 1xCS The above simplified call flow refers to IMS Emergency calls to 3GPP2 SRVCC 1x CS in limited service mode. UE initiates emergency session over E-UTRAN as specified in 3GPP TS 23.167, and TS 23.401, and upon detecting handover is required from E-UTRAN to CDMA 1x, the SRVCC emergency procedures apply. To handover of emergency session the network is aware that the UE and core network SRVCC and has information to identify Emergency session. When handover of the emergency session has been completed, the MME or the 1xRTT side may initiate location continuity procedures for the UE as defined in TS 23.271. The only difference between a normal SRVCC IMS to CS HO and IMS emergency HO to CS PSAP is as follows: For an emergency services session after HO is complete (step 8.0 shown in yellow above), if the control plane location solution is used on the source side, the source MME shall send a Subscriber Location Report carrying an indication of the 1xRTT MSC (e.g., reference cell ID) to the GMLC associated with the source side to location continuity. This enables location continuity for the 1xRTT side. Alternatively, if a C Plane solution is not used on the source side, location continuity procedures shall be instigated on the 1xRTT side. (There is also a U plane solution available for legacy networks based on OMA Secure Plane (SUPL) standards to transfer Location Information between the UE (called secure End Terminal-SET) to eNB and to Secure Location Plane (SLP) server. However a SUPL client is required on the UE.



6-35

80-W3085-1 Rev A


VCC Reference Architecture 3GPP2 The above diagram illustrates the Voice Call Continuity (VCC) between Multi-Media Domain(MMD) (equivalent to IMS). VCC allows s to move voice calls between CS domain and MMD, connected through different Internet Protocol-Connectivity Access Networks (IPCANs) (e.g., WLAN, HRPD). This architecture refers to an inter-technology Domain Transfer (DT) call model which s procedures that allow a use to DT from an HRPD or WLAN multimedia session with a voice component to a 1x CS voice session and from a 1x CS voice session to a WLAN VoIP session. The goal is to allow the core network to know precisely the current accessibility of the UE and to deliver services efficiently across the appropriate access network while minimizing the impact on the legacy systems. The VCC AS comprises two main functions: Assists in terminating services to a terminal that is 1x CS ed and/or IMS ed is involved in voice call setup signaling to facilitate HRPD/WLAN VoIP-to-1x CS voice call DTs and 1x CS voice call to WLAN VoIP DTs. The VCC AS is anchored in the call signaling path of all voice calls originated from, or terminated to, a VCC UE that is IMS ed and tuned to HRPD/WLAN, or 1x CS ed and tuned to 1x. It has the following signaling interfaces: VCC AS/S-CSCF (ISC): The VCC AS serves as a SIP Back-to-Back Agent (B2BUA) that interfaces to the S-CSCF via an ISC SIP signaling interface. VCC AS/I-CSCF (Ma): The VCC AS interfaces to an I-CSCF via an Ma SIP signaling interface. This interface is used to anchor the VCC AS in the call path by sending SIP request from I-CSCF directly to the VCC AS. VCC AS/HLR (MAP): The VCC AS interfaces to the 1x CS HLR using MAP in order to obtain routing information for terminating voice calls to a UE via the 1x CS network. VCC AS/HSS (Sh): The VCC AS also interfaces to the HSS via an Sh interface [MMD Part-10] using the Diameter protocol to transfer data between the VCC AS and HSS. VCC AS/WIN S (MAP): The VCC AS interfaces to the WIN S using the MAP protocol in order to provide routing information for 1x voice call originations and terminations and to anchor the VCC AS in these calls. The WIN S may be integrated with the VCC AS or may be a standalone network element. Refer to X P0042 B V1.0 for details.



6-36


80-W3085-1 Rev A

Section 7: VoLTE Codecs and Transport Protocols

Notes



7-1


80-W3085-1 Rev A


Notes



7-2


80-W3085-1 Rev A


Notes



7-3


80-W3085-1 Rev A


Notes



7-4


80-W3085-1 Rev A


Audio Codec Evolution in Cellular Domain An audio codec (coder/decoder) is a signal processing mechanism that converts analog audio to digital data for transmission/storage and back to analog audio for playback.

Encoding lower frequencies improves naturalness and listening comfort. Encoding mid-range frequencies improves voice clarity and intelligibility. Encoding higher frequencies improves the sense of presence and contributes to better music quality. Although it is not standardized by the 3GPP, Adaptive Multi-Rate (AMR) has been the ubiquitous vocoder in 3GPP cellular systems thus far and has two main variants: Narrowband and wideband. VoLTE-capable UEs are required to AMR NB as well as AMR WB. Specific audio bit rates ed by AMR NB and WB variants are provided on the next two pages.



7-5

80-W3085-1 Rev A

VoLTE and IMS – Overview, Protocols, and Performance Section 7: VoLTE Codecs and Transport Protocols

Adaptive Multi-Rate Frame Structure: Header AMR NB bit rates and header fields The following table displays the mapping of various Frame Type values onto frame content and bit rates for AMR NB. The same table is reused for the Mode Indication and Mode Request fields which are 3-bit fields each and are defined only in the 0 to 7 range to specify one of the eight AMR NB codec modes. Frame Type

Mode Indication

Mode Request

0 1 2 3 4 5 6 7 8 9 10 11 12-14 15

0 1 2 3 4 5 6 7 -

0 1 2 3 4 5 6 7 -


Frame content (AMR mode, comfort noise, or other)

AMR 4,75 kbit/s AMR 5,15 kbit/s AMR 5,90 kbit/s AMR 6,70 kbit/s (PDC-EFR) AMR 7,40 kbit/s (TDMA-EFR) AMR 7,95 kbit/s AMR 10,2 kbit/s AMR 12,2 kbit/s (GSM-EFR) AMR SID GSM-EFR SID TDMA-EFR SID PDC-EFR SID For future use No Data (No transmission/No reception)


7-6

80-W3085-1 Rev A


Adaptive Multi-Rate Frame Structure: Core Frame The comfort noise bits in the SID frames are all mapped to the Class A of the AMR Core Frame and Classes B and C are not used. This is only a notation convention and the class division has no meaning for comfort noise bits. Error concealment reduces the subjective (perceived) effect of residual bit errors that have not been eliminated by channel coding. In practice, IF2 is more popular than IF1. AMR-WB bit rates and header fields Frame Type Index

Mode Indication

Mode Request

0 1 2 3 4 5 6 7 8 9 10-13 14 15

0 1 2 3 4 5 6 7 8 -

0 1 2 3 4 5 6 7 8 -


Frame content (AMR-WB mode, comfort noise, or other) AMR-WB 6.60 kbit/s AMR-WB 8.85 kbit/s AMR-WB 12.65 kbit/s AMR-WB 14.25 kbit/s AMR-WB 15.85 kbit/s AMR-WB 18.25 kbit/s AMR-WB 19.85 kbit/s AMR-WB 23.05 kbit/s AMR-WB 23.85 kbit/s AMR-WB SID (Comfort Noise Frame) For future use speech lost No Data (No transmission/No reception)


7-7


80-W3085-1 Rev A


Notes



7-8


80-W3085-1 Rev A


Enhanced Voice Services (EVS) Voice/Sound Activity Detection EVS enables the detection of the presence of the human voice or other sounds of interest. The encoder can generate high bit-rate data for time periods containing voice/sounds and fall back to generating low-rate data in the absence of voice/sound. Time-domain VAD/SAD is performed based mostly on the energy content of the signal. Comfort Noise Generation and Silence Insertion Descriptor frames A CNG algorithm sufficiently represents ambient noise while minimizing data rate during periods of sound inactivity, as identified by the VAD algorithm. The payload containing a description of the ambient noise is known as a SID frame. A Discontinuous Transmission (DTX) algorithm determines when a SID frame should be transmitted. The typical periodicity of SID frames in modern vocoders is 160 ms during periods of silence. While a SID frame can be as long as a regular voice frame in of time (typically 20 ms), its size (in of bits) is considerably lower. The CNG algorithm at the receiver uses the information contained in SID frames to its noise generation mechanism and then produce an appropriate comfort noise that gives the listener a sense of presence when the speaker is silent.



7-9

80-W3085-1 Rev A


EVS Operation The following figure depicts audio frequency layout of the four bands discussed above.

0

4k

Fullband (FB)

Super Wideband (SWB)

Wideband (WB)

Narrowband (NB)

8k

16k

20k

Audio Content Frequency (Hz)



7-10


80-W3085-1 Rev A


Advantages of EVS Cell Coverage For a given audio quality target, an EVS-encoded audio stream can endure more errors than an AMR-encoded stream. It implies that a wireless signal carrying an EVS stream can travel farther than a signal carrying an AMR stream and still provide equivalent audio quality, thus expanding the effective cell radius. Alternatively, for a given cell radius EVS can enhance deep indoor coverage as compared with AMR. Network Capacity The combination of Voice Activity Detection (VAD), Comfort Noise Generation (CNG), and Discontinuous Transmission (DTX) enables an EVS encoder to reduce the amount of data it sends during periods of audio inactivity, thus reducing unnecessary network traffic. A WB stream in EVS also can be encoded at as little as 5.9 kbps and a super wideband stream at 13.2 kbps, thus requiring fewer network resources to achieve a given audio quality.



7-11


80-W3085-1 Rev A


Channel-Aware Mode (1 of 2) Jitter is a measure of variation in periodicity of packet arrival. In an ideal network where packets arrive at the receiver in the same order and separated by the same interval as those generated by the sender, jitter is absent. In a practical VoIP system, however, packets arrive at the decoder with random jitters in their arrival time. Packets may also arrive out of order at the decoder. Since the decoder expects to be fed a speech packet every 20 ms to output speech samples in periodic blocks, a de-jitter buffer is required to absorb the jitter in the packet arrival time. The larger the size of the dejitter buffer, the better its ability to absorb the jitter in the arrival time and consequently fewer late arriving packets are discarded. On the other hand, voice communication systems are also delay-critical and therefore it is essential to keep the end-to-end delay as low as possible so a real-time two-way conversation can be sustained. The dejitter buffer size involves a trade-off between minimizing audio choppiness and end-to-end delay. While attempting to minimize packet losses, the jitter buffer management algorithm in the decoder also keeps track of the delay in packet delivery as a result of the buffering. The jitter buffer management algorithm may suitably adjust the depth of the de-jitter buffer to achieve the trade-off between the delay and audio quality.

Source control is used to determine which frames can best be coded at a reduced frame rate (called primary frames) to accommodate the attachment of redundancy without altering the total packet size, thus maintaining a constant bit rate. Additionally, the encoder can use properties of the input signal to determine which frames are the most critical for high quality reconstruction at the decoder and selectively transmit redundancy for those frames. A frame is critical to protect when its loss would significantly impact the audio quality at the receiver. The size of the PRC copy is variable and depends on the characteristics of the input signal.



7-12


80-W3085-1 Rev A


Channel-Aware Mode (2 of 2) The criticality of a frame also depends on if the previous frames were lost or not. For example, a frame may go from being non-critical to critical if the previous frames were also lost. Parameters computed from the primary copy coding such as coder type classification information, subframe pitch lag, factor M, etc. are used to measure the criticality of a frame. The threshold, to determine whether a particular frame is critical or not is a configurable parameter at the encoder that can be dynamically adjusted depending on the network conditions. For example, under high FER conditions it may be desirable to adjust the threshold to classify more frames as critical. The difference in time the units between the transmit time of the primary copy of a frame and the transmit time of the redundant copy of the frame (piggy backed onto a future frame) is called the FEC offset. If the depth of the jitter buffer, at any given time, is at least equal to the FEC offset, then it is likely that the future frame is available in the de-jitter buffer at the current time instance. The FEC offset is a configurable parameter at the encoder which can be dynamically adjusted depending on the network conditions.



7-13


80-W3085-1 Rev A


EVS Modes and Bit Rates Source-controlled VBR Coding VBR coding describes a method that assigns a different number of bits to a speech frame in the coded domain depending on the characteristics of the input speech signal. This method is often called source-controlled coding as well. Typically, a source-controlled coder encodes speech at different bit rates depending on how the current frame is classified, e.g., voiced, unvoiced, transient, or silence. Note: DTX operations can be combined with VBR coders in the same way Fixed Rate (FR) coders can; the VBR operation is related to active speech segments. The VBR solution provides narrowband and wideband coding using the bit rates 2.8, 7.2, and 8.0 kbps and produces an average bit-rate of 5.9 kbps. In comparison to the Fixed Rate (FR) coding, the VBR offers the advantage of better speech quality at the same average active bit-rate due to the finer bit allocation. The benefits of VBR can be exploited if the underlying network s the transmission of speech frames (packets) of variable sizes, such as LTE and UMTS networks. Primary Mode Fixed-rate speech operation at 7.2, 8.0, 9.6, 13.2, 16.4, 24.4, 32.0, 48.0, 64.0, 96.0, or 128.0 kbps; SID frames at 2.4 kbps and a variable bit rate of 5.9 kbps. EVS AMR-WB Interoperable Mode Includes nine bit rates for audio (6.6, 8.85, 12.65, 14.25, 15.85, 18.25, 19.85, 23.05, or 23.85 kbps) and one for SID.



7-14


80-W3085-1 Rev A


EVS Packet Formats The EVS RTP payload format includes a compact format and a header-full format which are used depending on the required functionalities within a session and whether only a single frame is transmitted. These two formats can be switched during a session. The complete RTP payload of header-full EVS format consists of an optional CMR byte, followed by one or several ToC bytes, followed by speech data bits, and possible zero-padding bits. More details about the modes and formats as well as CMR and ToC headers can be found in the Appendix.



7-15


80-W3085-1 Rev A


Notes



7-16


80-W3085-1 Rev A


Notes



7-17


80-W3085-1 Rev A


VoLTE Traffic Types and QoS Requirements Apart from LTE signaling, VoLTE requires the transport of IMS data and associated IMS signaling messages. These different traffic types require special treatments due to the different QoS requirements. • IMS Media (Voice) – Guaranteed bandwidth – Constant bandwidth requirement (e.g., AMR 12.2 kbps, AMR-WB 12.65 kbps)  QCI 1 => Guaranteed Bit Rate (GBR) bearer – Payload importance – High priority  QCI 1 => Priority 2  Real-time voice traffic should be prioritized over other delay-tolerant service traffic – Delay-sensitive to keep up with the vocoder rate – Not much room for retransmissions  Limited (HARQ) retransmissions – Error tolerant – 1% packet error rate acceptable for voice quality  QCI 1 => 10-2 Packet error loss rate  Error concealment function available in vocoders • IMS Signaling – No guaranteed bandwidth – Variable bandwidth requirement  QCI 5 => Non-Guaranteed Bit Rate (N-GBR) bearer – Payload importance – highest priority  QCI 5 => Priority 1  Critical for call setup and other important SIP signaling – Less delay sensitive – More room for retransmissions  Retransmissions via T, RLC-AM, and HARQ – Error intolerant – Very low packet error rate required  QCI 5 => 10-6 Packet error loss rate



7-18


80-W3085-1 Rev A


Notes



7-19


80-W3085-1 Rev A


VoLTE Upper Layer Protocols This diagram specifies the upper layer protocols pertaining to VoLTE and IMS.



7-20


80-W3085-1 Rev A


Transmission Control Protocol/ Datagram Protocol IMS data is transported using Real-Time Transport Protocol (RTP) over UDP, because of better efficiency (UDP incurs less overhead) and there is no need for transport layer retransmission (lower layer HARQ retransmissions are OK.

IMS signaling (SIP) can be carried over UDP or T:

• UDP provides better performance and scalability for small packets – Too many T sessions increase traffic overhead for an operator deploying VoIP/VoLTE because each T session requires a formal connection setup and acknowledgements are required for data to be sent – UDP does not require connection setup and there is no acknowledgement mechanism, making it faster and simpler – If a SIP message is too big to fit into one UDP packet, fragmentation will divide the message into segments; the whole message is lost even if one of the segments is lost

• T provides better transport for large packets, has congestion control, and offers security and authentication – Lost segments can be retransmitted to avoid retransmitting the whole message – T provides congestion control to handle the overload situation – Transport Layer Security (TLS) uses T as the base transport According to IETF RFC3261 for SIP, if a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as T. For example, if the path MTU is 1500 bytes in size and the SIP request message exceeds 1300 bytes (extending into the last 200 bytes of the path MTU), then T should be used instead of UDP. © 2016 Qualcomm Technologies, Inc.


7-21


80-W3085-1 Rev A


Real-Time Transport Protocol (RTP) RTP is used to transport a one-way data stream (voice) at a constant data rate that plays in near real time:

• GSMA IR.92 mandates that the RTP profile, Audio Video Profile (AVP) IETF RFC 3551 be used. RTP over UDP as described in IETF RFC 3550 and IETF RFC 768 to transport voice and use symmetric RTP, per IETF RFC 4961. The UE must use the same UDP port number for sending and receiving RTP packets.

• An important consideration for incorporating voice frames into RTP packets is the bundling factor: the number of audio frames bundled together to form one RTP packet. A lower bundling factor reduces mouth-to-ear delay (since frames are sent out soon after they’re generated) but results in more overheads in of bandwidth consumption (since the entire RTP header, ~12 bytes, is amortized over fewer frames). In practice, the delay consideration outweighs bandwidth concerns and a bundling factor of 1 is employed by many VoLTE networks to offer real-time communications.

• Server may change packet size based on RTP Control Protocol (RT) The 7-bit payload type indicates the format of the payload as described in the SDP information. The 16-bit sequence number is incremented with each successive RTP packet and can be used to detect packet loss. For time synchronization, the 32-bit timestamp enables real time playback of the media based on the sampling rate defined in the RTP profile. The Synchronization Source Identifier (SSRC) is used to identify the source stream, which is unique within a session. Additional contributing sources are possible, as defined by the Contributing Source Stream (CSRC) (shown above as Miscellaneous Fields). This source should be used if multiple sources are generating the media. Each audio source is identified by a unique Synchronization Source Identifier (SSRC); a separate RTP flow is necessary for each direction of audio traffic.



7-22


80-W3085-1 Rev A


RTP Packet Structure Note the difference between AMR frames and RTP packets: AMR frames carry the actual audio payload (along with the applicable AMR headers), whereas an RTP packet simply encapsulates one or more AMR frames along with the applicable RTP headers. In the Octet-aligned mode, all the fields in a payload, including payload header, table of contents entries, and speech frames themselves, are individually aligned to octet boundaries. Octet alignment of a field or payload means that the last octet is padded with zeroes in the least significant bits to fill the octet. In Octet-aligned mode the Payload Header consists of a 4-bit CMR, 4 reserved bits, and an 8-bit interleaving header, which is included only if interleaving is enabled. With interleaving, consecutive blocks of individual audio frames (frame blocks) are placed in subsequent RTP packets, rather than one after another in the same packet. The first half of the interleaving header for a given RTP packet (ILL) indicates to the receiver the interleaving length in number of frame-blocks. The second half of the interleaving header (ILP) indicates the offset of the first frame-block in that packet from the very first frame-block in the entire interleaving group. For more details and examples, refer to section 4.4.1 of the reference source below. ToC entries in octet-aligned mode are similar to those in bandwidth-efficient mode, except for two padding bits in the end and optional CRC. Further details can be found in IETF RFC 4867, RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs.



7-23


80-W3085-1 Rev A


RTP Control Protocol (RT) GSMA requires that the RT accompany the RTP based on IETF RFC 3550. The UE and plane terminating the IMS network elements should symmetric RT as defined in the IETF RFC 4961 and the RT transmission must be turned on by the UE and IMS network.

Key RT functions are as follows:

• Providing on the data distribution quality to facilitate the control of adaptive encoding, among other things

• Carrying a transport-level identifier for the RTP source • Providing limited session control functionality In VoLTE, the RT-APP packet may be used for codec rate control requests via the Codec Mode Request (CMR) field in the RT-APP packet. Note: The RT based CMR field can be used only when multiple codec modes for the codec are considered to be ed during the SDP negotiation phase. The IMS client in the device may trigger RT-APP CMRs in response to the link quality assessment such as packet loss rate estimates or in response to Explicit Congestion Notification (ECN) bits received in the IP payload header. If a MGW that is interworking with CS receives RT-APP CMR requests it must be able to translate them into the CMR fields in the AMR header. If an IMS client receives CMR requests in both the AMR header and in the RT-APP CMR it should take the lower of the two rates. If the IMS client determines that RT APP cannot be used or does not work then the IMS client may use CMR in the AMR RTP payload in-band CMR or other RT mechanisms for adaptation. More details about codec rate adaptation using RT can be found in TS26.114. It is recommended that the RTP and the RT are paired in port assignments: RTP should be assigned an evennumbered port, and the next (odd-numbered) port should be the associated to the RT port; the RTP and RT port numbers SHOULD NOT be the same.



7-24

80-W3085-1 Rev A


RTPC Packet and Transmission As the number of participants in a session changes, the RT message transmission rate can be varied dynamically to keep the total bandwidth utilization by RT messages under the recommended level of 5%. Reception statistics (in SR or RR) should be sent as often as bandwidth constraints will allow to maximize the resolution of the statistics, therefore each periodically transmitted compound RT packet must include a report packet. Compound RT Packets All RT packets are sent in a compound packet of at least two individual packets. Each RT packet begins with a fixed part similar to that of RTP data packets, followed by structured elements that may be of variable lengths according to the packet type, but must end on a 32-bit boundary. The alignment requirement and a length field in the fixed part of each packet are included to make RT packets “stackable." Multiple RT packets can be concatenated without any intervening separators to form a compound RT packet that is sent in a single packet of the lower layer protocol, for example UDP. The only difference between the sender report (SR) and receiver report (RR) packets, besides the packet type code, is the sender report includes a 20-byte sender information section for use by active senders. The SR is issued if a site has sent any data packets during the interval since issuing the last report or the previous one, otherwise the RR is issued. Jitter is computed as the difference in the traversal delay of two consecutive media packets; the traversal delay of a given packet being the difference between its arrival timestamp at the receiver and the generation timestamp at the source. If encrypted: random 32-bit integer

Packet

Packet

Site 2

SDES

SSRC

Site 1

SSRC

SSRC

SR

SSRC

receiver reports Sender report

Chunk

item

item

CNAME

PHONE

SSRC

Chunk

item

item

CNAME

LOC

BYE

SSRC SSRC

Packet

reason

Compound Packet UDP Packet © 2016 Qualcomm Technologies, Inc.


7-25


80-W3085-1 Rev A


Notes



7-26


80-W3085-1 Rev A


Dual IP Stack (IPv4/v6) Motivation The Internet Protocol (IP) is primarily based on IPv4. However, the existing IPv4 addressing cannot meet the demand from the exploding growth in the use of the Internet Protocol. IPv6 extends the IP address space from 32 bits to 128 bits, which vastly expands the address space (theoretically 2128 IPv6 addresses).



7-27


80-W3085-1 Rev A


Dual IP Stack (IPv4/v6) for VoLTE VoLTE-capable UE and network should both IPv4 and IPv6 for all protocols in VoIP including SIP, SDP, RTP, RT, and XCAP/HTTP. • The same IP address shall be used for both the Default and Dedicated bearers within the same PDN connection. – P-GW assigns an IP address to each . – The same can have multiple IP addresses assigned by different P-GWs. • IP address allocation is activated by the UE requested PDN connectivity procedure.



7-28


80-W3085-1 Rev A


Notes



7-29


80-W3085-1 Rev A


Notes



7-30


80-W3085-1 Rev A


Notes



7-31


80-W3085-1 Rev A


Notes



7-32


80-W3085-1 Rev A


Notes



7-33


80-W3085-1 Rev A


Notes



7-34

80-W3085-1 Rev A


ANR Codec Payloads and Headers Note the difference between AMR frames and RTP packets: AMR frames carry the actual audio payload (along with the applicable AMR headers), whereas an RTP packet simply encapsulates one or more AMR frames along with the applicable RTP headers. The following tables show the AMR/AMR-WB codec payload and additional bits for different codec modes used in formation of AMR frames (active speech frames, IF2 only). See RFC 4867, TS 26.101 and TS 26.201 for more details. AMR Mode (Kbps)

AMR Speech Frame Payload + AMR Header + Padding (bits)

Total AMR Speech Frame Size (bits)

AMR-WB Mode (Kbps)

AMR-WB Speech Frame Payload + AMR Header + Padding (bits)

Total AMR Speech Frame Size (bits)

4.75

95 + 4 + 5

104

6.60

132 + 5 + 7

144

112

8.85

177 + 5 + 2

184

128

12.65

253 + 5 + 6

264

14.25

285 + 5 + 6

296

15.85

317 + 5 + 6

328

5.15 5.9

103 + 4 + 5 118 + 4 + 6

6.7

134 + 4 + 6

144

7.4

148 + 4 + 0

152

18.25

365 + 5 + 6

7.95

159 + 4 + 5

168

376

19.85

397 + 5 + 6

408

10.2

204 + 4 + 0

208

23.05

461 + 5 + 6

472

12.2

244 + 4 + 0

248

23.85

477 + 5 + 6

488



7-35

80-W3085-1 Rev A


AMR Source Controlled Rate Adaptation For the AMR codec, the following table shows the different frame types used for Source Controlled Rate Adaptation. A slightly different table is used for AMR-WB.

See TS 26.093 and TS 26.193 respectively for more details Frame Type Legend

Information Bits

SPEECH_GOOD

Speech frame, size 95..244 bits depending on codec mode; no errors known.

SPEECH_DEGRADED (only in downlink in TFO)

Speech frame, size 95..244 bits, depending on codec mode; there might be errors in class 2 bits.

SPEECH_BAD (only in downlink in TFO)

Speech frame, size 95..244 bits, depending on codec mode; there are errors in class 1 bits.

SID_FIRST

Marks the end of a talkspurt, respectively the beginning of a speech pause; does not contain information bits.

SID_BAD (only in downlink in TFO) ONSET (only in downlink in TFO)

Comfort noise, 35 bits; no errors known Comfort noise, 35 bits; errors detected, parameters unusable Announces the beginning of a speech burst; does not contain information bits

NO_DATA

No useful information

SID_UPDATE



7-36


80-W3085-1 Rev A


EVS Formats: Compact EVS Compact format Primary mode The Compact format for EVS Primary 2.8 kbps frames (56 bits) has the same payload size (56 bits) as the headerfull format (discussed next) for EVS AMR-WB IO SID frames with CMR byte. Hence, a 56 bit payload can be interpreted by the decoder in two ways. This resulting ambiguity is resolved through the most significant bit (MSB) of the first byte of the payload. By definition, the first data bit d(0) of the EVS Primary 2.8 kbps rate payload is always set to 0. Therefore, if the MSB of the first byte of a 56-bit payload is set to 0, then the payload is an EVS Primary 2.8 kbps frame in Compact format; otherwise it is an EVS AMR-WB IO SID frame in header-full format with one CMR byte. EVS Compact format AMR-WB IO mode The table blow shows 3-bit CMR mapping for EVS AMR-WB IO/AMR-WB Due to the 3-bit limitation on CMR field, CMRs in Compact format for EVS AMR-WB IO mode are limited to include the most frequently used set of EVS AMR-WB IO/AMR-WB bit rates, shown in the table. CMRs for 14.25 and 19.85 kbps are not ed in Compact format for EVS AMR-WB IO. If a request needs to be transmitted for either of these modes it should be remapped to the next lower rate mode (12.65 and 18.25, respectively). Alternatively the header-full format may be used to transmit CMRs to 14.25 and 19.85 modes. If the total of three CMR bits and coded frame bits is not a multiple of 8, zero-padding bits are added so that the total becomes a multiple of 8. One zero-padding bit is required for EVS AMR-WB IO mode rate 6.6 and four zeropadding bits are required for EVS AMR-WB IO mode rate 8.85. Note: In other modes no padding bits are inserted.



7-37


80-W3085-1 Rev A


EVS Formats: Header-Full The complete payload of header-full EVS frames comprises an optional CMR byte, followed by one or several ToC bytes, followed by speech data bits and possible zero-padding bits. Padding bits are discarded by the receiver. The purpose of padding is twofold:

• In the case of EVS AMR-WB IO frames, payload data may need to be octet-aligned, using zero-padding bits at the end of the payload. Note: that EVS Primary frames are by definition octet-aligned.

• When required, zero-padding bits are also used to increase the total payload size by byte increments so that conflicts with any of the protected sizes reserved for the Compact format are avoided. The following figure shows some possible payload structures of header-full format with one or more audio frames, corresponding ToC fields and with or without CMR field.



7-38

80-W3085-1 Rev A


Obtaining an IPv6 Address In the EPS network, Stateless Address auto-configuration is mandatory. The UE only receives IPv6 Interface Identifier when the UE requests IPv4v6 or IPv6 address in the Attach Accept message. The P-GW then sends the Router ment message with the IPv6 prefix to the UE. If the UE does not receive the Router ment message, it can send a Router Solicitation message to request it. The IPv6 prefix is globally unique (/64). IPv6 addresses are 128 bits long, which typically can be divided into two parts: a 64-bit network prefix and a 64-bit interface identifier. (/64) refers to the standard subnet size being 64 bits. The P-GW maintains the mapping between the IMSI and the allocated IPv6 prefix. The IPv6 interface identifier (RFC 4862) is provided to the UE so that the link local address generated by the UE does not collide with the link local address of P-GW. Once the UE has received the IPv6 prefix, it constructs a full IPv6 address via the IPv6 Stateless Address auto-configuration (RFC 4862). During stateless address autoconfiguration, the UE can choose any interface identifier to generate IPv6 addresses, other than link-local based on the interface identifier. For privacy (RFC 3041) the UE may change the interface identifier used to generate full IPv6 addresses, without involving the network (as long as it does not collide with the P-GW).

Global Routing Prefix

Subnet ID

Interface Identifier

n bits

m bits

128-n-m bits

IPv6 Address Structure (Global Unicast)



7-39


80-W3085-1 Rev A


Comments/Notes



7-40


80-W3085-1 Rev A

Section 8: PD and RLC Protocols for VoLTE



8-1


80-W3085-1 Rev A


Notes



8-2


80-W3085-1 Rev A


Notes



8-3


80-W3085-1 Rev A


VoLTE Upper Layer Protocols

This diagram specifies the upper layer protocols covered in this section.



8-4


80-W3085-1 Rev A


Notes



8-5


80-W3085-1 Rev A


Radio Bearer Configuration for VoLTE

According to the 3GPP TS36.331 Annex B, any LTE UE must at least SRB1 + SRB2 + 4x AM DRB. Per IR.92, a VoLTE capable UE must : SRB1 + SRB2 + 4x AM DRB + 1x UM DRB. Two additional AM DRBs can be used to transport other multimedia contents in of the “Rich” call feature. For example, additional video sharing, image sharing, location services, and file transfer can be ed through dedicated radio bearers with specified QoS in the same call. In the configuration with the default EPS bearer set up with QCI = 5 (IMS-only PDN), SIP, and XCAP, signaling can be transported using the default EPS bearer. In the case of mixed internet and IMS traffic configuration, the internet traffic uses the default EPS bearer with QCI = 8 or 9, while IMS Signaling has its own default EPS bearer with QCI = 5. Voice traffic shall be carried on a QCI = 1 dedicated bearer that is network initiated. It should also be noted that only a single QCI = 1 EPS bearer is used to multiplex concurrent voice sessions as required in case of voice conferencing. After the completion of the voice call, the QCI = 1 dedicated bearer should be deleted; this process must be triggered by the network.



8-6


80-W3085-1 Rev A


Notes



8-7


80-W3085-1 Rev A


PD Configuration Enhancements for VoLTE PD specifications (3GPP TS36.323) include optimization to enable more efficient VoLTE operations. A special PD format with a short PD sequence number is only introduced for DRBs mapped onto RLC-UM. This reduces the header overheads by 50% (from 2 bytes to 1 byte). This process increases the risk of SN/HFN (sequence number/hyper frame number) wrap-around, but it should not be an issue at this low data rate. Short Discard Timer can be configured to move data out of the transmit buffer (UE or eNodeB) consistently with the vocoder frame rate to avoid transmission delay for subsequent voice packets. The minimum discard timer is 50 ms.

3GPP TS36.331 Section 6.3.2 Radio resource control information elements PD-Configuration information element © 2016 Qualcomm Technologies, Inc.


8-8


80-W3085-1 Rev A


PD Discard Timer Operation

After handover, unsent voice packets can be transmitted in sequence provided that the Discard Timer at the UE has not expired. Note that the Discard Timer is not restarted after handover (no additional time is allowed). Stale packets are flushed out of the UE buffer continuously to keep up with the vocoder timing. The Uplink Transmission Sequence Number and the Hyper Frame Number are reset to 0 to avoid ambiguity after re-establishment. This specifically applies to PD SDUs mapped to RLC-U, which also minimizes complexity and delay because the target eNodeB does not need to retrieve the PD SN from the source eNodeB. The maximum PD SN is 127 for 7-bit SNs, and the corresponding maximum HFN is 33554431 (in bits, the size of the HFN is equal to 32-7 = 25 bits), such that the COUNT bit length stays constant at 32 bits (HFN + PD SN).



8-9


80-W3085-1 Rev A


Notes



8-10


80-W3085-1 Rev A


Motivation for RoHC

RoHC is a highly robust and efficient IP header compression scheme for RTP/UDP/IP, UDP/IP, and ESP/IP headers that works well when used over links with significant error rates and long roundtrip times (bandwidth limited links). RoHC is the only ed compression protocol in LTE (3GPP TS36.323), and works well with both IPv4 and IPv6 packets (IPv4 header size = 20 bytes and IPv6 header size = 40 bytes). Each RTP header takes 12 bytes and each UDP header takes 8 bytes. In addition, the L1/L2/PD combined headers (1 byte PD, 1 byte RLC, 1 byte MAC and 3 bytes CRC) are approximately 6 bytes. The total header size per voice packet is 66 bytes (IPv6). In comparison, speech payload with very small AMR header can be as low as ~32 bytes for AMR 12.2 kbps or ~33 bytes for AMR-WB 12.65 kbps, assuming bandwidth efficient mode. Therefore, the need for IP+RTP+UDP header compression is required to achieve high bandwidth efficiency. An efficient header compression scheme can potentially reduce the headers from 60 bytes (RTP/UDP/IPv6) to 3 to 4 bytes. Adding L1/L2/PD headers, the compressed header size is ~9-10 bytes and AMR-WB 12.65Kbps payload size ~33 bytes. The overall capacity gain due to RoHC is approximately (66+33)/(9+33) = 2.36 times. The table on this page shows the RoHC compression efficiency estimates based on lab tests.



8-11


80-W3085-1 Rev A


Compressing Specific Header Fields with RoHC This diagram shows the different header fields in a combined RTP/UDP/IPv6 header. These header fields can be categorized into 5 classes, which are outlined below: 1. STATIC fields are expected to be constant throughout the lifetime of the packet stream and only need to be communicated once. For example, the IP version (IPv6 encoded as 6 in this case) and the Next header, which typically conveys the transport protocol, does not change in the packet stream. 2. STATIC-DEF field values define the packet stream (these fields can be used to identify packets belonging to a specific packet stream). For example, the STATIC-DEF fields such as IP Flow Label, Source/Destination IP Addresses and Source/Destination Port are always fixed during an RTP session and only need to be communicated once. In addition, the randomly chosen RTP SSRC identifier does not normally change during the RTP session (SSRC may change when there is a conflict or if the program is restarted, but this does not happen often—SSRC conflict probability is very low according to RFC 3550). 3. STATIC-KNOWN fields are expected to have well-known values and therefore do not need to be communicated at all. 4. INFERRED fields values can be determined from other values, such as the size of the frame carrying the packet (Length), and thus do not have to be handled at all by the compression scheme. 5. CHANGING fields are expected to vary in some way: randomly, within a limited value set or range, or in some other manner. For example, the Traffic class includes DS marking (packet classification) and ECN bits (congestion notification) that could change. Similarly, the UDP checksum and certain RTP header fields like PT, sequence number, timestamp can be time varying. More information can be found in RFC 3095 for RoHC, RFC 3550 for RTP, RFC 768 for UDP, and RFC 2460 for IPv6.



8-12

80-W3085-1 Rev A

VoLTE and IMS – Overview, Protocols, and Performance Section 8: PD and RLC Protocols for VoLTE

RoHC Profiles A set of RoHC profiles is defined in 3GPP TS36.323. Per, GSMA IR.92, the UE and the network must Robust Header Compression (RoHC ) as specified in 3GPP TS 36.323, IETF RFC 3095, and IETF RFC 4815. The UE and the network must be able to apply the compression to packets that are carried over the radio bearer dedicated for the voice media. At a minimum, the UE and the network must “RTP/UDP/IP” profile (0x0001) to compress RTP packets and the “UDP/IP” profile (0x0002), to compress the RT packets. The UE and the network must these profiles for both IPv4 and IPv6. 3GPP TS36.331 Section 6.3.6: UE-EUTRA3GPP TS36.323 Table 5.5.1.1 Capability information element Profile Usage Reference Identifier 0x0000

No compression

RFC 4995

0x0001

RTP/UDP/IP

RFC 3095, RFC 4815

0x0002

UDP/IP

RFC 3095, RFC 4815

0x0003

ESP/IP

RFC 3095, RFC 4815

0x0004

IP

RFC 3843, RFC 4815

0x0006

T/IP

RFC 4996

0x0101

RTP/UDP/IP

RFC 5225

0x0102

UDP/IP

RFC 5225

0x0103

ESP/IP

RFC 5225

0x0104

IP

RFC 5225


In the case of SIP messages, the header is small compared to the typical message sizes and hence the compression gain is smaller and the processing overhead is larger. It should be noted however that Signaling Compression (SigComp) may be used for SIP Signaling compression as defined in IETF RFC 3320, 4896.


8-13


80-W3085-1 Rev A


RoHC Operation Modes RoHC has three modes of operation, which are as follows:

• Unidirectional mode (U-mode) – One direction only. No ; state changes are based on periodic refreshes. – Less efficient and slightly higher loss probability compared to bidirectional modes. – RoHC always starts in U-mode and transitions to bidirectional mode(s).

• Bidirectional Optimistic mode (O-mode) – Two directions. channel is available to send error recovery requests and ACKs of significant context updates despite sparse usage. – No periodic refreshes. – More efficient compared to the unidirectional mode.

• Bidirectional Reliable mode (R-mode) – More intensive usage of the channel.  Acknowledge all context updates including updates of the sequence number field. – More robust, with stricter logic to prevent loss of context synchronization except for very high residual bit error rate, and lower probability of context invalidation than O-mode. The compressor and de-compressor establish a context for the packet flow and identify the context with a Context Identifier (CID) included in each RoHC compressed header when a logical channel s RoHC transport with multiple header-compressed flows. RoHC uses a distinct CID space per logical channel, and the CID can only be omitted for one of the flows over the RoHC channel when it is configured to use a small CID space; refer to RFC 3095 for details. © 2016 Qualcomm Technologies, Inc.


8-14


80-W3085-1 Rev A


RoHC States RoHC Compressor has three states:

• Initialization and Refresh (IR) – Full (uncompressed) packets are sent in order to establish a context at the decompressor. – RoHC enters this state during initialization or when repeated errors are detected.

• First Order (FO) – Only dynamic fields are sent. – Compressor is confident the decompressor is able to form the full header given the dynamic fields.

• Second Order (SO) – This is the state where compression is optimal. – The compressor enters the SO state when the header that needs to be compressed is completely predictable, given the RTP Sequence Number (SN). In addition, the compressor must be confident that the decompressor has acquired all parameters of the functions from SN to other fields. Corresponding RoHC Decompressor states are:

• No Context (NC) • Static Context (SC) • Full Context (FC) © 2016 Qualcomm Technologies, Inc.


8-15


80-W3085-1 Rev A


Why the Need for RoHC Context Continuation?

In Rel.11, RoHC functionality was enhanced to maintain the context after HO. Smaller VoLTE packet sizes maintained around handover enables eNB to schedule more VoLTE packets, which improves overall eNB capacity. Also under heavily loaded conditions, scheduling larger VoLTE packets immediately after handover might not be possible which results in additional VoLTE delay. Continuing RoHC context within a same eNB means VoLTE packet sizes are smaller after handover. This process enables the eNB to schedule smaller VoLTE packets better, which leads to an overall reduced VoLTE latency.



8-16


80-W3085-1 Rev A


UE & Network RoHC Context Continuation Setup

Inside the UE-EUTRA-Capability information element within the UE-CapabilityInformation message is RohcContextContinue, which indicates whether the UE s RoHC context continuation operation where the UE does not reset the current RoHC context upon intra eNB handover. Inside the RRC Reconfiguration message within mobilityControlInfo is drb-ContinueRoHC, which indicates whether to continue or reset, for this handover, the header compression protocol context for the RLC UM bearers configured with the header compression protocol. The presence of the field indicates that the header compression protocol context continues as is while its absence indicates that the header compression protocol context is reset. The E-UTRAN includes the field only in the case of a handover within the same eNB (intra eNB). The UE handover execution procedure remains unchanged. The onus is on the eNB to check for source and target to figure out if the handover procedure is indeed an intra-eNB handover, in which case the eNB could explicitly set drb-ContinueRoHC. Thereafter, the UE will continue its RoHC session, i.e., continue to use compressed header immediately after handover. 3GPP TS 36.331 Evolved Universal Terrestrial Radio Access (E-UTRA);Radio Resource Control (RRC);Protocol specification (Release 11) Clause 6.3



8-17


80-W3085-1 Rev A


Notes



8-18


80-W3085-1 Rev A


RLC Configuration for VoLTE: RLC-UM

For VoLTE, RLC-UM is used to transport voice data payloads to enable fast and efficient delivery.

• Mapped from the dedicated EPS bearer carrying the vocoder packets with QCI = 1. • Segmentation/concatenation depends on the radio environment, i.e., matching to the transport block size that can be ed by the physical layer. – Probably not used to avoid additional overheads and to allow simpler processing – SPS grant is expected to match the RLC PDU size exactly

• RLC PDUs may arrive out-of-sequence (i.e., HARQ retransmissions), which needs to be reordered according to the sequence number. – Choice of smaller RLC headers (5-bit sequence number) for UMD PDU to lower the overheads

• RLC receive entity performs duplicate discard and loss detection with an UM window (=16), which is half of the sequence number space (32). In addition, a t-Reordering timer is aligned to the maximum tolerable delay given the vocoder information rate.



8-19


80-W3085-1 Rev A


RLC Configuration for VoLTE: RLC-AM

RLC-AM is typically used for the IMS signaling and the default EPS bearer. RLC retransmissions can help recover important signaling messages in the case of transmission errors (especially if the UDP is used to transport SIP signaling messages because there is no retransmission mechanism like T). RLC-AM:

• • • • •

s concatenation and re-assembly of RLC SDUs to fit within a PDU Detects duplicates and discards already received PDUs Performs reordering and operates over a larger window due to larger SN space Detects losses of PDUs and request retransmission Retransmitted PDUs may be further segmented if the radio conditions change and the same PDU size cannot be ed over wireless link



8-20


80-W3085-1 Rev A


RLC Segmentation and Sequence Number (SN) Size

In some cases, where UE is UL power challenged, e.g. at the edge of the cell, the RTP packet might be segmented into 8 PDU or more.



8-21


80-W3085-1 Rev A


Feature Group Indicators

Feature Group Indicators (FGIs) consist of 32 binary bits, each corresponding to a specific feature as defined in TS36.331 Annex B.1. The FGIs are included in the IE UE-EUTRA-Capability, they are typically sent in the UE Capability Information Message in response to the UE Capability Enquiry that is triggered by the network.

• Bit 7 should be set to 1 for a VoLTE capable device (RLC-UM needed) • Bit 3 can be set to 1 only if Bit 7 is set to 1; Bit 3 should be set to 1 for a VoLTE-capable device



8-22

80-W3085-1 Rev A


QoS for VoLTE

QoS for VoLTE is specified through a set of EPS QoS parameters.

There are nine QoS Class Identifiers (QCIs) defined for different service/traffic types:

3GPP TS23.203 Table 6.1.7 Standardized QCI characteristics



8-23


80-W3085-1 Rev A


Notes



8-24


80-W3085-1 Rev A


Notes



8-25


80-W3085-1 Rev A


Notes



8-26


80-W3085-1 Rev A


Notes



8-27


80-W3085-1 Rev A


Notes



8-28


80-W3085-1 Rev A


Notes



8-29


80-W3085-1 Rev A


Notes



8-30


80-W3085-1 Rev A


Notes



8-31

80-W3085-1 Rev A


Interspersed RoHC Packets Packet header compression is optional at the PD layer (configured by upper layers). Each PD entity is carrying data of one radio bearer (SRB or DRB), and every PD entity uses at most one RoHC instance and thus one profile. Compression and ciphering are applied to the data before fitting into PD PDU. Different PD PDU types are defined separately for Control Plane, Plane PD data PDUs, and PD control PDUs (PD status reports and interspersed RoHC packets). All PD control PDUs are not compressed nor ciphered/integrity-protected. Data associated with SRBs is integrity-protected before ciphering; ciphering applies to both DRBs and SRBs. The PDU formats for the two PD control PDU are different, as illustrated in this slide. The “D/C” field specifies whether it is “data” or “control” PDU type. The PD control PDU status report has the PDU type set to “000” while the interspersed RoHC packet is set to “001”. The “FMS” field specifies the First Missing PD SDU SN, and the “Bitmap” field indicates the subsequent missing PD SDUs. The “Interspersed RoHC packet” contains RoHC information from decompressor to compressor. The RoHC payloads shall contain the size of the data field (Code = 1 to 7 indicates the size of the data in octets, or specific size indicated using the Size Field if Code = 0), and profile-specific information including the Context Index (CID) information, and ACK/NACK s with the following AckType:

• •

ACK: Acknowledges successful decompression of a packet, which means the context is up-to-date with a high probability

•

STATIC-NACK: Indicates that the static context of the decompressor is not valid or has not been established (more severe problem)

NACK: Indicates the dynamic context of the decompressor is out of sync (several successive packets have failed to be decompressed correctly)

of types ACK, NACK, and STATIC-NACK carry sequence numbers, and packets can also carry a mode parameter indicating the desired compression mode: U, O, or R. Success No Dynamic

No Static

No Context

Failures

Static Context

Success

Success Failures

Full Context

RoHC Decompressor States for All Modes © 2016 Qualcomm Technologies, Inc.


8-32


80-W3085-1 Rev A

Section 9: MAC and PHY Protocols for VoLTE



9-1


80-W3085-1 Rev A


Notes



9-2


80-W3085-1 Rev A


Notes



9-3


80-W3085-1 Rev A


Lower Layer Protocols This diagram specifies the lower layer protocols and features in the MAC and Physical layers of the LTE stack relevant to VoLTE; these are covered in this section.



9-4


80-W3085-1 Rev A


VoLTE Payload



9-5


80-W3085-1 Rev A


Notes



9-6


80-W3085-1 Rev A


Notes



9-7


80-W3085-1 Rev A


Semi-Persistent Scheduling Efficient VoIP is a fundamental requirement for Evolved UTRA because there is no circuit switched domain voice service ed in the packet switched domain. Therefore, it is necessary for E-UTRA to a large portion of voice capacity that is currently being handled by traditional circuit switched networks. To achieve this goal, packet scheduling algorithms and related resource allocation methods are destined to play a pivotal role among all the elements of system. One of the challenges for efficient VOIP is control signaling overhead for VoIP transmissions. The traditional full dynamic scheduling scheme could become a bottleneck and limit the system capacity. Hence the need for a different type of scheduling that requires less control signaling overhead without losing some of the flexibility of resource allocation in time and frequency domain of the dynamic scheduling.



9-8


80-W3085-1 Rev A


Persistent Scheduling Persistent scheduling means the scheduling of packets does not depend on the channel condition. A CS-like allocation of resources is made for each call and the allocation remains constant for the duration of the call. The allocation also includes resources required for Hybrid Automatic Repeat Request (HARQ) retransmission. The allocation can be so persistent that there will be no HARQ ACK/NACK but there will be a fixed number of retransmissions for each packet, which results in a fixed Forward Error Correction (FEC) scheme instead of an adaptive HARQ scheme. The main problem of persistent scheduling is the waste of resources. In a dynamic wireless environment, it is difficult to determine the exact resources and number of retransmissions for a voice packet for the entire call duration. This depends on channel quality, interference, etc. Therefore, it is very hard to allocate a fixed resource to each , which may cause serious issues including very lowutilization of capacity. Persistent scheduling was replaced in the LTE specification by Semi-Persistent Scheduling at a later stage.



9-9


80-W3085-1 Rev A


Dynamic Scheduling Because LTE is a packet radio system, the packets are usually scheduled using L1/L2 scheduling. VoIP packets can also be scheduled using the same procedure. From the resource usage point of view, this scheme is the most flexible because it enables packets to be scheduled exactly when they are needed. The downside of this approach is the large amount of signaling that is required. When fully dynamic scheduling in the DL is carried out, the eNodeB can assign PDSCH resources via the PDCCH whenever VoIP packets need to be sent to the UE. In the UL, the UE sends a specific PUSCH resource request via a Scheduling Request for each VoIP packet since the eNodeB may not provide continuous PDCCH based on UL grants. In addition, the eNodeB allocates PUSCH and PDSCH resources for every retransmission separately via the PDCCH. With dynamic scheduling, the VoIP packet scheduling enjoys the full diversity of channel in both the time and frequency domain at the expense of large control (PDCCH) signaling. A smarter dynamic scheduler can allocate resources ahead of time to avoid a large number of Scheduling Requests from UEs.



9-10


80-W3085-1 Rev A


Notes



9-11


80-W3085-1 Rev A


Semi-Persistent Scheduling The basic principle is to periodically allocate certain transmission resources for a particular . For semi-persistent resource scheduling, the time pattern is initially configured via the RRC protocol. The Node B can always override semi-persistent scheduling in the TTI by dynamically scheduling the same via the PDCCH. Persistently allocated resources are periodic in time with a fixed bandwidth as well as a constant modulation and coding scheme, they represent regular scheduling of a fixed data amount. The semi-persistent scheduling method is therefore primarily intended for deterministic data flows (e.g., for Voice over Internet Protocol [VoIP] service). For example, a with constant size VoIP packets arriving every 20 ms could be persistently scheduled with this time interval on a bandwidth (number of PRBs), a modulation and coding scheme corresponding to the expected packet size and the estimated link quality. The main advantage of semi-persistent scheduling is that no explicit physical layer signaling on the PDCCH is required for every transmission, which reduces the Downlink control signaling overhead. However, if the reception of a persistently scheduled packet fails, any hybrid ARQ retransmissions will need dynamic scheduling.



9-12


80-W3085-1 Rev A


UL Dynamic vs. SPS Scheduling When Dynamic Scheduling is used for UL transmission of voice frames, the UE sends a Scheduling Request to the eNodeB on the PUCCH to request a grant. In response, the eNodeB assigns the UL resources via the PDCCH, which is used after 4 TTI (4 ms). The same signaling messages is exchanged between the UE and the eNodeB upon the arrival of each voice frame (every 20 ms). When semi-persistent scheduling is used, the UL resources are only requested by the UE for the first voice frame. The UL resources are granted in advance at regular intervals for the remaining voice frames for the duration of the talk spurt and there is no need for the UE to continuously request UL resources within that time period.



9-13


80-W3085-1 Rev A


DL Dynamic vs. SPS Scheduling One role of the PDCCH is to inform the UE about the incoming data on the DL, which occurs at each DL transmission when Dynamic Scheduling is used. When SPS is used, the eNodeB informs the UE about the first incoming voice frame via an initial DL SPS grant assignment. The remaining voice frames during the talk spurt are sent at pre-determined intervals without explicit DL grant assignments.



9-14


80-W3085-1 Rev A


SPS Configuration for a VoLTE Call SPS configuration will take place during the Dedicated Bearer establishment for the VoLTE call. Once the Dedicated Radio Bearer is established, the eNodeB will allocate UL/DL resources for SPS via the PDCCH.

Once the eNodeB has detected VoIP traffic for the in the DL (as an example), the eNodeB will send the DL allocation with PDCCH scrambled with the SPS C-RNTI. If the eNodeB decides to remove the SPS resource allocation (could be at the end of the talk spurt, based on VoIP traffic frequency), the eNodeB will explicitly release the SPS assignment by configuring the PDCCH DCI fields accordingly (indicating SPS release). Upon VoLTE call termination, the eNodeB will release the Dedicated Radio Bearer including all the SPS configuration and other VoLTE specific C-DRX, RoHC, logical channel priority configuration used for the call. Note: Talk spurt is a continuous segment of speech between silence intervals.



9-15


80-W3085-1 Rev A


SPS Configuration Parameters After a Semi-Persistent DL assignment is configured, the UE shall consider the assignment recurs in each subframe for which: (10 * SFN + subframe) = [(10 * SFNstart time + subframestart time) + N * semiPersistSchedIntervalDL] modulo 10240, for all N>0 Where SFNstart time and subframestart time are the SFN and subframe, at the time the configured Downlink assignment were (re)initialized. Other optional parameters can be sent by the eNodeB for UL power control adjustment during SPS UL transmissions:

•

p0-NominalPUSCH-Persistent: unit dBm step 1. This field is only applicable for SPS. If choice ‘setup’ is used and p0Persistent is absent, apply the value of p0-NominalPUSCH for p0-NominalPUSCH-Persistent (see TS 36.213 section 5.1.1.1).

•

p0-UE-PUSCH-Persistent: unit choice ‘setup’ is used and p0-Persistent is absent, apply the value of p0-UE-PUSCH for p0-UE-PUSCH-Persistent (see TS 36.213 section 5.1.1.1).

For the FDD scenario, when a UE is about to send a HARQ on PUCCH in response dB. This field is only applicable for SPS. If to a PDSCH transmission without a corresponding PDCCH detected in subframe n-4 (since DL SPS is activated), the value of the PUCCH resources used to transmit the HARQ-ACK is determined according to n1-PUCCH-AN-PersistentList. The following list from Table 9.2-2 in TS 36.213 provides a set of n(1) PUCCH indexes to be used.



9-16


80-W3085-1 Rev A


HARQ Operation with SPS In DL HARQ, HARQ ID will be deduced from the equation below: HARQ Process ID = [floor(CURRENT_TTI/semiPersistSchedIntervalDL)] modulo numberOfConfSPSProcesses

• Current TTI: the TTI at which the UE is receiving the SPS DL assignment • semiPersistSchedIntervalDl: DL SPS interval • numberOfConfSPS-Processes: number of configured HARQ processes for SPS See TS36.321 for more details.



9-17


80-W3085-1 Rev A


SPS Scenarios The scenarios discussed in the following slides are for DL SPS transmission. The UL SPS transmission will differ from the DL in a couple of ways:

1. The DL allocation sent on the PDCCH to the UE will be decoded in the same TTI (PDSCH part),

in other words, the DL data carried by the PDSCH will be transmitted in the same TTI that has the PDCCH scrambled with the SPS C-RNTI. On the other hand, for the UL SPS, the UL allocation sent on the PDCCH, where the PDCCH is scrambled with SPS C-RNTI, will be used by the UE after 4 TTI.

2. In the DL SPS there is one mechanism used by the eNodeB to indicate the release of the SPS transmission, the “explicit SPS Release” where eNodeB configures DCI fields with specific values, indicating to the UE that SPS has been released. For the UL SPS, there are two mechanisms to release the SPS: a) The explicit SPS release, where the eNodeB configures DCI-0 fields with specific values, indicating to the UE that the SPS has been released. b) The implicit SPS release where the UE sends x SPS UL transmissions of empty PDUs (padded PDUs). The x number is the “implicitReleaseAfter” parameter configured by the eNodeB.



9-18


80-W3085-1 Rev A


Review of PDCCH and PDSCH Allocation Both the DL-SCH and UL-SCH allocation are performed by the eNodeB. In the Downlink, the allocation information is carried on the PDCCH for PDSCH (DL-SCH) transmissions within the same subframe. The UE may be addressed using different Radio Network Temporary Identities (RNTI).

During normal (DTCH/DCCH) operation either the Cell Radio Network Temporary Identifier (C-RNTI) or Semi-Persistent Scheduling (SPS) C-RNTI may be used, depending on whether the transmission is dynamically scheduled or periodic following a predefined pattern. During the RACH procedure, DL-SCH transmissions may also be scheduled using the Random Access (RA) RNTI or the Temporary C-RNTI. Additionally, if system information is being transmitted using the DL-SCH, the System Information (SI)-RNTI is utilized.



9-19


80-W3085-1 Rev A


SPS Initialization and Transmission The eNodeB initiates the DL SPS by sending a voice frame (on the PDSCH), where the PDCCH of this PDSCH is scrambled with the SPS C-RNTI of the designated UE and the NDI is set to 0 in the DCI. The HARQ Process ID, MCS, and the RV is configured according to the table below. The remaining DL assignments for the same talk spurt will not have a PDCCH associated with the PDSCH and the UE will attempt to decode PDSCH periodically every 20 ms, based on the SPS configuration. Note: The PDSCH corresponding to the PDCCH scrambled by SPS C-RNTI as well as PDSCH without a corresponding PDCCH (using pre-allocated SPS grant) are also scrambled with the SPS C-RNTI. A PDCCH scrambled with SPS C-RNTI and an NDI=0 will be validated by checking for values of specific fields. For SPS initialization, specific values of fields are defined in TS36.213 Table 9.2-1. The MCS for SPS is limited to 4 bits (only QPSK, 16-QAM can be used) since MSB of the MCS field is set to 0. For SPS C-RNTI the absolute value of NDI (0, 1) is relevant and the NDI toggling concept is not used.



9-20


80-W3085-1 Rev A


DL SPS HARQ Retransmission HARQ retransmission is ed for the SPS transmission on the DL as well as on the UL. If the eNodeB decides to do a HARQ retransmission of an SPS TB, it will scramble the PDCCH with the UE SPS-CRNTI and set the NDI to “1”. HARQ ID will be conveyed to the UE via the DCI (similar to the case for the Dynamic Scheduling); however, for SPS transmission, the UE will deduce the HARQ ID from the equation below to determine the designated first transmission: (Reference: TS36.321) HARQ Process ID = [floor(CURRENT_TTI/semiPersistSchedIntervalDL)] modulo numberOfConfSPSProcesses

• Current TTI: the TTI at which the UE is receiving the SPS DL assignment • semiPersistSchedIntervalDl: DL SPS interval • numberOfConfSPS-Processes: number of configured HARQ processes for SPS



9-21


80-W3085-1 Rev A


DL SPS with Explicit Release If the UE receives a PDCCH scrambled with SPS C-RNTI of the UE and the DCI format 1A with the value combination below, this indicates a DL SPS release. The eNodeB might choose to release the DL SPS explicitly any time after the last voice frame of the talk spurt by sending the above indicated PDCCH. Reference: Table 9.2-1A TS 36.213 V9.3 Physical layer procedures.



9-22


80-W3085-1 Rev A


Notes



9-23


80-W3085-1 Rev A


TTI Bundling Concept and Tradeoffs When comparing the TTI bundling mechanism with the conventional TTI transmission:

• Uplink resources over multiple TTIs can be assigned with a single grant, which decreases the signaling overhead. To trigger a transmission of a TTI bundle, the same grant format can be used for ordinary HARQ transmissions. Whether the UE should transmit using a single TTI or TTI bundling is configured by the Radio Resource Control (RRC) protocol.

• There is a single HARQ on the PHICH after each TTI bundle transmission. This decreases control signaling and vulnerability to NACK-to-ACK errors, which can lead to data loss.

• For power limited UE where retransmission is inevitable, TTI bundling provides the UE with the four redundant versions of the PDU in one shot, saving time and resources.



9-24


80-W3085-1 Rev A


Notes



9-25


80-W3085-1 Rev A


Review: Conventional UL Transmission The diagram shows Non-adaptive UL HARQ retransmissions (using PHICH ). Considering a 50 ms UL delay budget, for conventional UL HARQ transmissions, energy from up to seven TTIs can be accumulated by the eNodeB.



9-26


80-W3085-1 Rev A


UL TTI Bundling for 4 TTIs The diagram shows Non-adaptive UL HARQ retransmissions for each TTI bundle (using PHICH ). Considering a 50 ms UL delay budget, for TTI bundled UL HARQ transmissions, energy from up to 12 TTIs (3 bundles) can be accumulated by the eNodeB.



9-27


80-W3085-1 Rev A


Notes



9-28


80-W3085-1 Rev A


Notes



9-29


80-W3085-1 Rev A


Notes



9-30


80-W3085-1 Rev A


Notes



9-31


80-W3085-1 Rev A


What is Logical Channel Prioritization (L)? Prioritization in the Downlink (eNodeB) • Finite Radio Resources need to be allocated to UEs and the respective Radio Bearers. • The eNodeB MAC scheduler is responsible for delivering data from different logical channels to the UE and it is left up to the eNodeB implementation.

Prioritization in the Uplink (UE) • UE makes a decision based on the data in its Buffers and the allocated Radio Resources through Grants from eNodeB.

• This process at the UE is standardized to ensure consistent UE implementation to construct an UL MAC PDU based on the specific amount of data from each logical channel and type of MAC control element that will be included.

• Specific L parameters are provided by the eNodeB to UE to ensure that QoS of each Radio Bearer is satisfied in the best and most predictable way, given the UL grant provided.



9-32


80-W3085-1 Rev A


Key L Parameters Priority: Takes values from 1-16. Higher Priority value indicates a lower priority level. PBR: The range of values for PBR (KB/sec) per radio bearer are 0/8/16/32/64/128/256/512/1024. If set to infinity for a specific LC, the UE will allocate all data in the buffer for this LC (from highest to lowest priority LC) to the UL grant. BSD: The range of values for BSD (ms) are 50/100/150/300/500/1000. The UE increments a variable Bj= PBR*1 TTI duration every TTI until Bj becomes = Bucket Size (upper limit for Bj). When some data for a LC is accommodated in the UL MAC PDU, the LC Bucket Size is decremented by that amount. Bj can take a negative value. For L, the UE takes into the following relative priority in decreasing order:

Priority Highest

1.MAC CE for C RNTI or data for UL CCCH 2.MAC CE for BSR with exception of BSR included for padding 3.MAC CE for PHR 4.Data from any LC except data from UL CCCH

Lowest

5.MAC CE for padding BSR

A Logical channel Group is specified for a LC to reduce Buffer Status Reporting overhead. For additional details on L in LTE, see TS 36.321 section 5.4.3.1. © 2016 Qualcomm Technologies, Inc.


9-33


80-W3085-1 Rev A


Logical Channel Prioritization Process The L process is based on the Token Bucket model. In this model, if a logical channel has not fully utilized its right to transmit in any subframe, it can be used in subsequent subframes. The right to accumulate data is limited to the Bucket Size = PBR*BSD. Each time data is allocated to the UL MAC PDU, that amount is decremented, which prevents it from accumulating the right to transmit too much data.



9-34


80-W3085-1 Rev A


UL MAC PDU Construction using Token Bucket Model A token bucket algorithm is used in the L process where each bucket corresponds to a Radio Bearer (RB) with a LCID from a Logical Channel Group (LCG). The PBR defines the rate of the inflow of tokens for each RB; the size of the bucket is the product of PBR and BSD which dictates the burst of the flow. When the tokens in the bucket exceed the bucket capacity, no more tokens will be added. The UL data bytes in the UE MAC buffer to be transmitted via MAC PDU using UL grant for each RB (LCIDs) are selected from the respective bucket based on their relative priority starting with the highest priority bucket with a positive bucket depth (with most tokens) to the lowest priority bucket with positive bucket depth. For each data byte selected for the UL MAC PDU for a specific RB, a token is removed from the corresponding bucket. In the figure above, 2 LCs are illustrated — Voice with higher priority and best effort data with lower priority. In Step 1: The5 data bytes are present, but only 3 tokens exist in the high priority voice token bucket and therefore only 3 voice bytes are selected for UL MAC PDU based on the available grant. In this step, moving to the lower priority best effort data bucket, 15 data bytes are present but only 2 tokens are available and therefore only 2 data bytes are selected for the UL MAC PDU. In Step 2: The UL grant is still available, the higher priority voice RB is now served even though 0 tokens exist, but the remaining two voice bytes are selected for the UL MAC PDU to empty MAC buffer for this LC. Thereafter, since there is still some UL grant available, the lower priority best effort data RB is served and three data bytes are selected for transmission in the UL MAC PDU to fully utilize the UL grant even though no tokens were available for this data bucket.



9-35


80-W3085-1 Rev A


Token Bucket Model In Action In the diagram above displays the token bucket model in action for L. Only two Logical Channels are assumed in this example. The UL MAC PDUs is constructed based on UL grant in subframes 4 and 5 respectively. The orange and brown balls represent the LCI1 token and data respectively while the grey and green balls represent the LC2 token and data respectively. SF1, SF2, and SF3: Three data bytes are present in the UE LC1 buffer and two data bytes are always present in the UE LC2 buffer. In each subframe 1, 2, and 3 a single token is added to the LC1 and LC2 token buckets based on the PBR of 1 kB/sec resulting in 3 tokens each thereafter. SF4: A 2 byte UL grant is now provided by the eNodeB to the UE. In this subframe one additional token enters LC1 and LC2 token buckets for a total of 4 tokens each. Given that LC2 has higher priority and has a positive bucket level, which is greater than the amount of data bytes, both data bytes from the UE LC2 buffer are selected for the UL MAC PDU and 2 tokens are removed from the LC2 bucket. Therefore, the UE LC2 MAC buffer is empty. SF5: An additional token enters each LC1 and LC2 bucket. Simultaneously, the eNodeB has provided a 3 byte UL grant to the UE. The higher priority LC2 now has an empty buffer and lower priority, LC1 has a positive bucket level that is greater than the data bytes present, so LC1 is served. The 3 data bytes from UE LC1 buffer are selected for the UL MAC PDU and 3 tokens are removed from the LC1 bucket. SF6: An additional token enters each LC1 and LC2 token bucket but there is no data in the UE buffer for either LC and no UL grant is available.



9-36


80-W3085-1 Rev A


Setting L Parameters for VoLTE The configuration above is an example that describes the minimum resources needed to maintain a VoLTE call. In addition to the example cited above, the network operator may also configure these L parameters to avoid any interruption in the VoLTE call (prioritize voice at any cost) compared to other traffic, though this is not optimal. In this case, the parameters can be configured as follows:

• PBR  infinity • BSD  obsolete since PBR is set to infinity • Priority still needs to follow the recommendation shown on this slide As a result, the UE will always allocate a speech frame data in the MAC buffer to the UL MAC PDU when an UL grant becomes available.



9-37


80-W3085-1 Rev A


Notes



9-38


80-W3085-1 Rev A


DL and UL Packet Bundling Since VoIP is strictly a delay-restricted service, the Packet Scheduler needs to consider the buffering delay of the UEs. Dynamic packet scheduling provides good frequency domain and multi- gain for the best type of traffic. However, the nature of the Semi-Persistent Scheduling mechanisms used for VoIP traffic limits (or negates entirely) the gain from multi- and frequency domain scheduling. With packet bundling, the eNodeB may decide to bundle one or more VoIP packets into one MAC PDU, thus improving the spectral efficiency because of better resource utilization.



9-39


80-W3085-1 Rev A


Notes



9-40


80-W3085-1 Rev A


Connected DRX (C-DRX) – Introduction New mobile communication systems, such as Long Term Evolution (LTE), aim to improve perceived experience by providing higher data rates and lower latencies. This makes wireless devices a great platform to run a whole new set of services and applications. However, the improvement of data transmission and computation technologies in mobile devices has not been matched with a corresponding improvement in battery performance. Therefore, power consumption is one of the critical issues to solve when developing new mobile systems. For this reason, one of the key objectives in ing the LTE system is more efficient utilization of battery power. This is especially important for devices that VoLTE, because a VoIP call can run for a long period of time with the UE in Connected mode while a simultaneous frequent burst data session is taking place. LTE exploits Discontinuous Reception (DRX) as a practical solution to this issue.



9-41


80-W3085-1 Rev A


Review: C-DRX Operation DRX command is a MAC Control Element sent on the Downlink to force the UE to start the DRX.



9-42


80-W3085-1 Rev A


Long and Short DRX Cycles For VoLTE, depending on the C-DRX parameters configured, the Short DRX cycle could help conserve power during the talk spurt, while the Long DRX cycle could help conserve power during silence periods or outside talk spurts.

The following examples illustrate the behavior of the UE when C-DRX is enabled. Example 1: UE monitors the PDCCH for the duration of the inactivity timer. Expiration of the timer indicates that the UE should enter the DRX cycle. If the C-DRX is configured, begin with the (optional) short cycle. The UE starts the On-Duration period (monitoring the PDCCH during this period). After this, the Off-Duration starts (UE shuts down the receiver to reduce power consumption). After a few Short DRX cycles (number of cycles is configurable), the UE transitions to the Long DRX cycle, where the same On-Duration period is used, but the UE is off for a longer time period. Example 2: Is similar to the first example with one exception. The Short DRX cycle does not start immediately after the inactivity timer expires; it will start after 2 TTI. During the 2 TTI the UE receiver is Off. The UE determines the start of a DRX cycle from the TTI number, which must be a multiple of the DRX Cycle (with some offset, if it exists).



9-43


80-W3085-1 Rev A


Notes



9-44


80-W3085-1 Rev A


C-DRX Timers Multiple timers are running at the UE during Connected DRX to ensure that the UE will not go “off” during the “On-duration” period when UL or DL (re)transmission or HARQ is expected to be transmitted or received.

DRX-Inactivity timer: Specifies the number of consecutive PDCCH-subframe(s) after successfully decoding a PDCCH indicating an initial UL grant or DL data transmission for this UE. If this timer is running, the UE will be “On”. If a UL grant is received at TTI = n, then the timer will start at TTI = n+2 (processing time). RTT timer: The amount of time (fixed to 8 ms for FDD) before the DL HARQ retransmission is expected by the UE. It is defined per DL HARQ process. This timer will start once a DL PDU is received. If this PDU is not successfully decoded (UE sends a HARQ-NACK after 4 TTI) upon expiration of this timer (after 8 TTI from the reception of the PDU), the UE should start the (DL) DRX-ReTx timer. (DL) DRX-ReTx timer: Specifies the maximum number of consecutive PDCCH-subframe(s) by which a DL HARQ retransmission is expected by the UE. This timer will start upon the expiration of the RTT timer. If the timer is running, the UE will stay “On”. Upon reception of a DL transmission (or a configured SPS DL assignment) this timer will stop. Upon the expiration of this timer, the UE should fall back to the corresponding state (on/off). UL DRX-ReTx timer: This timer starts at the TTI when the UE sends any UL data. If this timer is running, the UE will stay “on” waiting for HARQ . The duration of this timer is calculated from the (MAX_HARQ_tx - 1) x 8. If the UE receives an ACK that is not enough to stop the timer, the UE should receive a new UL allocation (NDI toggled) to stop the timer and move to the next transmission.



9-45


80-W3085-1 Rev A


Notes



9-46


80-W3085-1 Rev A


Notes



9-47


80-W3085-1 Rev A


Notes



9-48


80-W3085-1 Rev A


Additional/Enhanced Lower Layer Parameters for VoLTE •

Logical Channel SR Mask: Used to specify the LCID (transporting the voice traffic) for which SR transmission is prohibited since an UL SPS grant is already configured.

•

SR-Prohibit Timer: Prevents unnecessary SR transmissions when a UE is in a VoLTE call. During a VoLTE call the data stream is not continuous; it is intermittently periodic, which generates a significant number of SRs. Upon the arrival of each voice frame, the UE transmits one or more SRs periodically to indicate the arrival of new data. For this reason, the SR-Prohibit Timer was introduced to prohibit the transmission of an SR for one or more SR periods.

•

Short SR period: To meet the 10 ms boundary, additional SR periods were added (1 and 2 ms), to accelerate the reception of the UL grant when necessary, during a VoLTE call.

•

CQI-Mask: Limits the transmission of CQI, RI, and PMI reports to the on-duration period during the Connected-DRX cycles when this feature is enabled. If the CQI-Mask is not configured, the UE could send CQI/RI at any time as long as the UE is not in the off-duration period. The UE can send CQI/RI reports while the inactivity timer is running and it is “not” in the on-duration period.

•

ECN: A mechanism that allows the network (eNBs and intermediate CN nodes) to signal explicitly the onset of congestion to UEs (and any other media end point) to adjust the codec sending rate instead of relying on implicit triggers like packet loss. The ECN framework uses two reserved bits in the IP header to provide the explicit indication to the receiver that the path between the sender and receiver will likely be experiencing congestion issues and packet losses. The end-to-end negotiation of ECN is done during the offer/answer phase of the SIP call flow through the use of the Session Description Protocol. Note: The sender/receiver or any media end point such as UE, MGW, ALG, TrGW, or ECN can result in codec rate changes by the IMS client sending RT-APP messages with Codec Mode Request (CMR) fields to the other end and resulting in the rate switch. This requires for RT as well as multiple codec rate as part of the specific codec selected during the SDP negotiation phase. The ECN profile used to trigger the codec rate adaptation for Multimedia Telephony is defined in TS 26.114.



9-49


80-W3085-1 Rev A


Notes



9-50


80-W3085-1 Rev A


Notes



9-51


80-W3085-1 Rev A


Notes



9-52


80-W3085-1 Rev A


Notes



9-53


80-W3085-1 Rev A


Notes



9-54


80-W3085-1 Rev A


Notes



9-55


80-W3085-1 Rev A


Notes



9-56


80-W3085-1 Rev A


Notes



9-57


80-W3085-1 Rev A


Re-Initiate DL SPS with Different Resources The eNodeB might choose to change the resources used during the SPS; e.g., the MCS and the number of RBs during a talk spurt or for the next talk spurt. The eNodeB will inform the UE about these changes via the PDCCH (scrambled with the UE SPS C-RNTI and NDI = 0).

PDCCH validation for specific fields is performed for this case when PDCCH is scrambled with SPSCRNTI and NDI = 0 is detected, per TS36.213 Table 9.2-1.



9-58


80-W3085-1 Rev A


DL SPS Activation When a new talk spurt starts at the DL, the eNodeB might restart the SPS with the same resources by scrambling the PDCCH with the UE SPS C-RNTI and setting the DCI fields, per TS36.213 Table 9.2-1. PDCCH validation for specific fields is performed for this case when PDCCH is scrambled with SPSCRNTI and NDI = 0 is detected, per TS36.213 Table 9.2-1.



9-59


80-W3085-1 Rev A


DL SPS HARQ ReTx Overrides SPS First Tx During HARQ retransmission, if the eNodeB schedules an SPS DL HARQ retransmission at the same TTI the UE expects the pre-configured DL SPS PDSCH transmission (no PDCCH), the UE will detect the PDCCH with SPS C-RNTI and decode the SPS HARQ retransmission on PDSCH only. Thus, the SPS HARQ retransmission overrides any pre-configured SPS DL grant. Note: The eNodeB will only send the PDCCH + PDSCH corresponding to the SPS DL HARQ retransmission in this case. PDCCH validation for specific fields is performed for this case when PDCCH scrambled with SPSCRNTI and NDI = 0 is detected, per TS36.213 Table 9.2-1. The corresponding UE would only be expected to decode one PDSCH TB for data that corresponds to the SPS HARQ Tx and not attempt to decode a pre-assigned PDSCH SPS grant (which eNodeB will not transmit anyway).



9-60


80-W3085-1 Rev A


DL Dynamic Transmission Overrides SPS Tx The UE will be monitoring the PDCCH at each TTI; this is because Dynamic Scheduling can occur in parallel with the SPS transmission. In the above scenario, consider the UE has two Radio Bearers, each defined for different types of traffic, e.g., one Radio Bearer is for VoIP with SPS enabled and the other Radio Bearers is for the best effort traffic where Dynamic scheduling is used only. The eNodeB scheduler might transmit the best effort data to the UE in between the SPS transmissions. If a Dynamic transmission occurs at the same TTI as a pre-determined SPS transmission, the Dynamic transmission will override the SPS transmission and the UE should not expect an SPS transmission at this TTI from the eNodeB.



9-61


80-W3085-1 Rev A


Comments/Notes



9-62


80-W3085-1 Rev A

Section 10: VoLTE Performance and Capacity



10-1


80-W3085-1 Rev A


Notes



10-2


80-W3085-1 Rev A


Notes



10-3


80-W3085-1 Rev A


Notes



10-4


80-W3085-1 Rev A


Notes



10-5


80-W3085-1 Rev A


Notes



10-6


80-W3085-1 Rev A


Notes



10-7


80-W3085-1 Rev A


Plane Severe RTP Packet delay leads to the arrival of RTP packets in a group and possibly discard by the dejitter buffer



10-8


80-W3085-1 Rev A


LTE Metrics Impacting RTP Packet Loss

Impact of Radio Link Failure (RLF) • During a VoLTE call when the UE can declare RLF for many reasons: RACH Issues, PDCCH BLER, Handover Failure, etc.

• RLF can lead to the re-establishment of RRC connection as the UE as to perform cell reselection, connection re-establishment and setting up the bearers again

• The scenarios above lead to loss of RTP packets therefore impacting voice quality Impact due to poor RF conditions • When a UE enters a poor RF condition, RTP inter-arrival time can be adversely impacted because of high HARQ retransmissions

Core Network Issues • Even when both MO and MT UE are in very good RF condition, packet losses can be observed if there are RTP packet drops at the core network – Between the IMS network elements and the LTE leading to RTP packet drops at core network

Use of SPS • It is critical for a VoLTE to be scheduled at the right time. Failure in which can lead to increased packet latency

• Scarce resource of PDCCH because of system load is very much possible in dense network deployments Use of TTI-B •

Allows UE to operate at a lower spectrum efficiency which is needed under power limited conditions



10-9


80-W3085-1 Rev A


Notes



10-10


80-W3085-1 Rev A


Delay Definitions ( Plane KPI – Delay) As the RTP packet flows on the UL from the speaker to the DL at the listener, Air Interface delays become important. Any delays in scheduling on either the UL (from speaker) or the DL (as a listener) may increase jitter.

• Jitter increase can therefore increase the adaptive de-jitter buffer level, therefore increasing the end to end delay The next slide discusses the components contributing to e2e delay.



10-11


80-W3085-1 Rev A


Recommendation for Mouth-to-Ear Delay See the International Telecommunication Union ITU-T G.114, “One-way Transmission Time”, May 2003. http://www.itu.int/rec/do_pub.asp?lang=e&id=T-REC-G.114-200305-I!!PDF-E&type=items For satisfaction, the maximum acceptable end-to-end delay is 285 ms.

• •

Commercial CDMA2000 1X/WCDMA/GSM networks have 260-270 ms delay. Packet switched networks allow for capacity/delay trade-off optimization.

For VoIP capacity analysis, mouth-to-ear delay is analyzed in comparison to ITU recommendations. Note: The ITU-T G.114 recommendations are for circuit switched networks. However, it does include (in the Appendix) some discussion on packetization delay in IP networks, the impact of de-jitter buffers, as well as some guidance on one-way delays for VoIP network planning to ensure acceptable mouth-to-ear delays. MOS Score E-Model Rating R is a measure of the MOS – a measure of voice quality. The transmission rating factor R can be in the range of 0 to 100, where R = 0 represents extremely bad quality and R = 100 represents very high quality. The E-model provides a statistical estimation of quality measures. An estimated Mean Opinion Score for the conversational situation on the scale of 1 to 5 can be obtained from the R-factor, using specific formulae. Additional details can be found in ITU-T G.107, “The E-model - A computational model for use in transmission planning”. Note: In 2011, the ITU-T published P.863 : Perceptual objective listening quality assessment (POLQA). POLQA represents the next-generation of voice quality testing technology for fixed, mobile and IP-based networks and can be applied to HD Voice, 3G and 4G/LTE and is considered a successor to PESQ. The ITU-T document describes an objective method for predicting overall listening speech quality from narrowband (300 to 3400 Hz) to super-wideband (50 to 14'000 Hz) telecommunication scenarios as perceived by the in a P.800 or P.830 ACR listening only test. P.863 s two operational modes, one for narrowband and one for super-wideband. The document presents a high-level description of the method, advice on how to use it, and part of the results from a Study Group 12 benchmark carried out in the period 2006-2010. For more information, please refer http://www.itu.int/rec/T-REC-P.863/en © 2016 Qualcomm Technologies, Inc.


10-12


80-W3085-1 Rev A


RTP Jitter in VoLTE Jitter is caused by one or more of the following things:

• • • • •

UL/DL scheduling delays Radio retransmissions Core network jitter Device processing jitter Handover (small percentage)

A jitter buffer is used at the receiving equipment to store incoming RTP packets, re-align them in of timing and check they are in the correct order. If some arrive slightly out-of-sequence then, provided it is large enough, the jitter buffer can put them back into the right sequence. However, for this to work the receiving device must delay the audio very slightly while it checks and reassembles the packet stream. If a packet was dropped (or simply does not arrive in time) then the receiving device has to somehow “fill in” the gap using a process known as Packet Loss Concealment or PLC. Packet loss needs to be less than 1% to avoid a big impact on the call audio quality. Greater than 3% would certainly be noticeable as a degradation of quality. If the RTP packets remain in the correct sequence and there is zero packet loss, large variations in the end-to-end transmission time for the packets may cause degradation of audio quality that can only really be fixed through the use of a jitter buffer. Additional information on Analysis of RTP Packet Delay and Loss can be found at: http://www.ece.rutgers.edu/~marsic/books/CN/projects/wireshark/ws-project-4.html © 2016 Qualcomm Technologies, Inc.


10-13


80-W3085-1 Rev A


Plane KPI - Jitter LTE RAN or LTE core may cause different latencies on different RTP packets resulting in the variation of the inter-arrival time of the RTP packets.

• RTP packets with jitters larger than the de-jitter buffer length will be discarded the by de-jitter buffer, resulting in poor voice quality.



10-14

80-W3085-1 Rev A

VoLTE and IMS – Overview, Protocols, and Performance Section 10: VoLTE Performance and Capacity

Jitter Example The formula for estimating jitter is as follows (https://www.ietf.org/rfc/rfc3550.txt): J(i) = J(i-1) + ( |D(i-1,i)| - J(i-1) )/16 where,

i: i-th packet J: Jitter D (i-1,i): The difference of relative transit times for the two consecutive packets. The difference is computed as: D(i-1,i) = Ri – Si – (Ri-1 – Si-1)


i 1 2 3 4 5 6 7 8 9 10

Si 0 20 40 60 80 100 120 140 160 180

Ri 8 28 46 74 91 112 133 149 171 192

|Di-1,i| 0 0 2 8 3 1 1 4 2 1


Ji 0.00 0.00 0.13 0.62 0.77 0.78 0.79 0.99 1.06 1.05 10-15


80-W3085-1 Rev A


De-Jitter Buffer – Concept & Functionality Timing jitters can be controlled by de-jitter buffers, which receive a stream of packets and effectively render these packets by controlling the rate at which packets are output from the buffer. De-jitter buffers may be used in the terminal equipment/device itself (for example, VoIP devices). Larger de-jitter buffers enable the system to be more tolerant to jitter. However, a buffer will increase end-to-end latency (or delay), a major transmission impairment. The goal of a de-jitter buffer is to provide a smooth supply of audio/video frames to the decoder. This smooth supply is accomplished by buffering a number of audio/video frames (buffer length) before resuming playback. Some de-jitter buffers are static, with a fixed processing window. Others are dynamic and can alter the size of the window to adapt to network conditions. There is a balance between the size of the de-jitter buffer and overall delay. Even with a dejitter buffer, some packets may arrive outside the window of the buffer. These packets cannot be processed and will be lost or discarded; interpolation may be used to maintain signal integrity. Dynamic (or adaptive) de-jitter buffers can change the buffer length in response to the characteristics of the communication channel. Buffer length selection must consider the trade-off between additional end-to-end delay and frame erasure rate. Proprietary dynamic de-jitter buffer algorithms can be implemented. In the diagram above, the voice frames are generated at the source every 20 ms. After traversing the wireless channel, some frames (RTP packets) at the receiver may be delayed and received out of order (such as 2) and some may be lost due to errors (such as 5). These frames at the receiver are stored in the de-jitter buffer, which may drop frames that are delayed significantly (such as 2) causing erasure and while delivering all other frames received successfully (except 5) per the required 20 ms timing to the vocoder at the receiver.

Adaptive De-jitter buffer: Dynamically changes the de-jitter buffer depth according to the channel/network conditions to reduce the end-to-end delay, when possible.

Time-warping: Dynamically compresses or expands the packets being played out from the de-jitter buffer, without changing their pitch.



10-16


80-W3085-1 Rev A


Notes



10-17


80-W3085-1 Rev A


Perceptual Objective Listening Quality Assessment (POLQA) Official POLQA website: http://www.polqa.info/ PESQ: Perceptual Evaluation of Speech Quality. A perceptual quality measurement for voice quality; commonly used in CS networks. http://www.pesq.org/



10-18


80-W3085-1 Rev A


POLQA Measurement For a list of Harvard sentences, please refer to: http://www.cs.columbia.edu/~hgs/audio/harvard.html



10-19


80-W3085-1 Rev A


POLQA Score MOS score E-Model Rating R is a measure of the MOS – a measure of voice quality. The transmission rating factor R can be in the range of 0 to 100, where R = 0 represents extremely bad quality and R = 100 represents very high quality. The E-model provides a statistical estimation of quality measures. An estimated Mean Opinion Score (MOS) for the conversational situation on the scale of 1 to 5 can be obtained from the R-factor, using specific formula. Additional details can be found in ITU-T G.107, “The E-model - A computational model for use in transmission planning.” Note: In 2011, the ITU-T published P.863: Perceptual objective listening quality assessment (POLQA). POLQA represents the next-generation of voice quality testing technology for fixed, mobile and IPbased networks and can be applied to HD Voice, 3G, and 4G/LTE and is considered a successor to PESQ. The ITU-T document describes an objective method for predicting overall listening speech quality from narrowband (300 to 3400 Hz) to super-wideband (50 to 14'000 Hz) telecommunication scenarios as perceived by the in a P.800 or P.830 ACR listening only test. P.863 s two operational modes, one for narrowband and one for super-wideband. The document presents a highlevel description of the method, advice on how to use it, and part of the results from a Study Group 12 benchmark carried out in the period 2006-2010. For more information, refer to: http://www.itu.int/rec/T-REC-P.863/en



10-20


80-W3085-1 Rev A


Notes



10-21

80-W3085-1 Rev A

VoLTE and IMS – Overview, Protocols, and Performance Section 10: VoLTE Performance and Capacity

Notes

Codec Mode

6.6

8.85

12.65

14.25

15.85

18.25

19.85

23.05

23.85

Speech Payload

132

177

253

285

317

365

397

461

477

AMR Header IPv4 Header IPv4 Packet Size IPv4 BW (kbps) IPv6 Header IPv6 Packet Size IPv6 BW (kbps)

12 320 464

15 320 512

11 320 584

11 320 616

11 320 648

11 320 696

11 320 728

11 320 792

11 320 808


24

26

30

32

33

36

37

40

41

480 624

480 672

480 744

480 776

480 808

480 856

480 888

480 952

480 968

32

34

38

40

41

43

45

48

49


10-22


80-W3085-1 Rev A


Example: RF Impact on MOS Score RF Impact on MOS Score This slide compares the MOS score with the RF condition (RSRP/RSRQ) for different voice chunks; each chunk contains two talk spurts with the duration of 8s.



10-23


80-W3085-1 Rev A


Notes



10-24


80-W3085-1 Rev A


Handover and Mobility KPIs Handover in LTE can be either intra-frequent or inter-frequent handover. Inter-RAT handovers (SRVCC) can also happen between two technologies namely LTE and 3G. The UE performs handover a number of times during a VoLTE call which can increase the change of RTP Packet drops, delays, and in severe cases impact retainability.



10-25


80-W3085-1 Rev A


Notes



10-26


80-W3085-1 Rev A


Mobility Factors Impacting VoLTE Performance Handover Delay

• Signaling Interruption Delay: The delay caused in setting up the bearers at the destination eNB will have a significant impact to the VoLTE audio quality.

• Interruption times of 45 ms vs 90 ms is possible when the handover is X2 based vs S1 based. • Data Interruption Delay: After the UE reconfigures the bearer, delay at the network side in forwarding the packets to the destination when eNB is significant can introduce delay in receiving the audio packets.

• Inter-Frequency Handover: Handover involves configuration of measurement gaps for measurements of target frequency and right handover thresholds are required by target band propagation characteristics. Handover Success Ratio

• Failure in completing the handover within the T304 timer can lead to the UE trying to reestablish with a new RRC connection setup can lead to significant RTP delay as well as RTP loss. ROHC State Mismatch after Handover

• In-complete handover procedure caused by RLF can lead to UE and eNB ROHC state mismatch. This could lead to packets being discarded at both the eNB and UE side.



10-27


80-W3085-1 Rev A


Notes



10-28


80-W3085-1 Rev A


VoLTE Coverage Dependencies Link Budget Dependencies: The typical channels that are analyzed are RS, PBCH, PDCCH, PDSCH, PRACH, PUCCH (SR, CQI, ACK/NACK), and PUSCH. For macro deployments, PUSCH is typically the limiting link due to limited UL UE transmit power. The key components that will dictate the VoLTE link budget and eventually the cell radius are listed below: • Receiver Sensitivity: Depends on UE/eNB noise figure, allocated bandwidth, and lowest SINR that require data rate can be achieved for a target BLER. • Codec Type: NB-AMR codecs require lower data rates, therefore could have larger coverage, but they have inferior voice quality compared to WB-AMR codec which needs higher data rates and has less coverage. Next generation EVS codecs (LTE Rel 12) requires low data and hence provides better coverage without compromising voice quality. • Frequency band of operation: Lower frequency bands have better radio propagation and lower building penetration loss thereby providing larger VoLTE cell radius. • Co-channel interference/Network Optimization: Sub-optimal network optimization can result in higher cell overlap and hence higher co-channel interference, thereby reducing SINR and receiver sensitivity/cell radius. Since the VoLTE for the macro is UL limited, a higher number of eNB receive antennas (4Rx or 8Rx) and can provide higher UL diversity gain and hence improve receiver sensitivity and cell-radius. Good network optimization, advanced eNB interference cancellation features, and more number of Rx antennas at eNB will improve VoLTE cell-radius. • VoLTE features: Features like RoHC, TTI-B & RLC segmentation help improve VoLTE cell radius. Note: The only LTE FDD & LTE TDD UL/DL Config 0, 1 & 6 can TTI-B (4 or more UL sub-frames per 10ms) Delay Budget Dependencies: The link budget can improve the additional HARQ re-Tx and RLC segmentation (repetition gain), but at the cost of increasing packet delay. If packet delay increases beyond a certain point, the PD discard timer for VoLTE will engage and the delayed packets will be dropped. Therefore, the final VoLTE link budget and coverage should consider the optimum number of RLC segments and HARQ re-Tx to stay within the delay budget. © 2016 Qualcomm Technologies, Inc.


10-29


80-W3085-1 Rev A


Example: Impact of Band & Features on VoLTE Coverage Cell ranges based on Okumura-Hata/COST-Hata Model for the cell-radius calculation.



10-30


80-W3085-1 Rev A


VoLTE Capacity Dependencies Air Interface Resources: •

Channel Bandwidth: The higher the channel BW, the higher the control and data channel resources which leads to higher VoLTE capacity.

•

LTE Duplexing: Since VoLTE is a symmetric demand application (same demand on DL and UL), for the same channel BW, LTE FDD will provide higher VoLTE capacity than LTE TDD.

•

Per Channel Resources: VoLTE capacity will depend on the smallest of the per channel available capacity (PDCCH, PDSCH, PRACH, PUCCH, PUSCH). This needs to be shared with BE data s, however, since VoLTE typically gets configured with higher priority. In the case of congestion, the BE s will get blocked to make room for VoLTE s.

RF Conditions: •

PDSCH/PUSCH Spectral Efficiency: Improves the network optimization, the higher the cell’s average PDSCH and PUSCH spectral efficiencies, the higher the VoLTE carrying capacity for the corresponding channels. Features like higher order MIMO and increased UL diversity receive antennas at the eNB. In addition, better interference cancellation features improve spectral efficiency and the realizable VoLTE capacity.

•

PDCCH aggregation level: Good RF conditions  lower PDCCH aggregation level  higher PDCCH capacity and converse is true (PDCCH aggregation is related to the RF conditions).

Codecs and Features: •

Lower rate codec & RoHC provide higher VoLTE capacity if the capacity is limited by PDSCH or PUSCH only.

•

Features like SPS and Packet bundling provide higher VoLTE capacity if it is limited by PDCCH only.

•

Coverage extension features like RLC segmentation reduces VoLTE capacity for all channels.

•

Coverage extension features like TTI-B reduces VoLTE capacity for PUSCH only.



10-31


80-W3085-1 Rev A


Notes



10-32


80-W3085-1 Rev A


Notes



10-33


80-W3085-1 Rev A


Notes



10-34


80-W3085-1 Rev A


Notes



10-35


80-W3085-1 Rev A


Notes



10-36


80-W3085-1 Rev A


Notes



10-37


80-W3085-1 Rev A


Notes



10-38


80-W3085-1 Rev A


POLQA Coalition and Licensing Perceptual Objective Listening Quality Assessment

• Measurement Scope – Predict speech quality by means of signal analysis – Close to subjective quality scores – Uses real speech samples

• Technology Capabilities – Successor of PESQ – Covers also higher bandwidth audio signals (wideband and ultra wideband 50-14000 Hz)

• Standards and Website – ITU-T P.863 (PESQ ITU-T P.862) – www.polqa.info

• Description – Full Reference (FR) algorithm rating degraded/processed speech in relation to original sample – Calculates perceptual differences between listener side and talker side (based on signal samples) – Perceptual psycho-acoustic modeling as used in MP3 or AAC – Analysis in the frequency domain with help of masking functions – Results in MOS scores with rating between 1 and 5 © 2016 Qualcomm Technologies, Inc.


10-39


80-W3085-1 Rev A


VoLTE vs UMTS CS Voice: Theoretical Expectations It is assumed that same voice codec is used for both UMTS and VoLTE, therefore the same bit energy (Eb) at the codec level is required to decode at the target BER. This bit energy is independent of the underlying technology (UMTS or VoLTE).



10-40


80- W3085-1 Rev A

Section 11: Rich Communications Services (RCS)



11-1


80- W3085-1 Rev A


Notes



11-2


80- W3085-1 Rev A


Notes



11-3


80- W3085-1 Rev A


Notes



11-4


80- W3085-1 Rev A


RCS over IMS The IP Multimedia Subsystem (IMS) is a framework of the core network components that enables subscriber access to a range of multimedia services without reliance on a specific access technology. Per the example above, a range of diverse Access Networks share a common IMS platform that enables a converged and seamless offering of different services. Central control of a specific session and its associated service enables provisioning appropriate Quality of Service (QoS) as well as potential continuity across different access platforms. The QoS provisioning will be limited by the different capabilities and mechanisms of the respective Access Network. Another important aspect of IMS is charging and the ability to differentiate between different services and how they are billed. The motivation for RCS over IMS by GSMA is to be able to compete with Over The Top (OTT) Services like Skype, WhatsApp, FaceTime, etc., which have fragmented the value added services using cross platforms and technologies. This also reduced the mobile wireless operators only providing access and transport (bit pipes) while OTT services are being indirectly subsidized.

RCS Rel1 started with defining mobile multimedia services, based on CS voice. RCS Rel2 defines mobile services (based on CS voice) and broadband/PC-based services (potentially using PS voice). RCS Rel3 defines additional service features (e.g., location part of the Rich Address Book). RCS Rel4 includes reuse of LTE network to enhance RCS services. This section deals with RCS 5.1 (RCC.07 of GSMA), which is the most recent release. Global interoperability (which means being able to work across various operators and with cross platforms) is a key aspect of these specifications. © 2016 Qualcomm Technologies, Inc.


11-5


80- W3085-1 Rev A


RCS 5.1

RCS 5.0 with V1.2.2 specifications introduced new features such as best effort IP video calls, Geolocation exchange based Social Presence, Standalone Messaging, and a network based blacklist. RCS 5.1 has advanced capabilities, but completely backward compatible with the V1.2.2 and RCS 5.0 specifications. RCS 5.1 introduces additional new features such as Group Chat Store & Forward, File Transfer in Group Chat, and RCS enabled IP voice and video calls as shown in the diagram above based on GSMA RCC.07. RCS uses the OPTIONS (meant for using SIP in 3GPP) and PRESENCE (meant using presence server of Open Mobile Alliance (OMA)) which are network based. RCS5.1 allows both mechanisms for capability discovery. RCS-e is RCS enhanced (Release5+), which is described on the next slide, uses SIP OPTIONS for all features including first time capability discovery and on demand subsequent features/capabilities. The use of the Presence server of OMA is optional. Enhanced Address Book (EAB), which is at the center of the services, could use either SIP options or Presence based on Network to Network Interface (NNI).



11-6


80- W3085-1 Rev A


RCS enhanced (RCS-e) RCS-e defines the initial IM/Chat functionality, File Transfer, Image Share, and Video Share functionality over mobile PS SMS/MMS and voice/video, trusted and untrusted broadband networks. RCS-E has gained wide acceptance as an initial deployment will be followed by future deployment phases. RCS-e protocols include SIP, MSRP, and RTP/RT over T/IP, and UDP. Current RCS/RCS-e handsets have full interoperability for network-to-network level internetworking between operators. •

Joyn is the global consumer facing brand for RCS-e services that will be used by operators and it is GSMA licensed for RCS using SIP options that include the following functionality:

– s presence, a way of showing s how they can reach and share content with their s, including those in their social networks;

– Enhanced chat, which includes threaded conversations showing who said what and which people or groups are available to chat or share content;

– Content sharing, enabling s to share video, images, and files while on a call or within an instant message or chat; and

– Image and video share connecting s with voice including over Wi-Fi. •

The key benefits of Joyn for the end s are as follows:

– Service discovery displays the services available to be used for any particular in the 's Address Book.

– Interoperable between mobile operators, which enables the end to communicate and be connected with anyone.

– Joyn is either available natively on the handset or can be ed as an application without the need for s or creating a special (cross platform technology).

A web-based interface is provided for Joyn to send messages via servers and across different platforms. © 2016 Qualcomm Technologies, Inc.


11-7


80- W3085-1 Rev A


Capability Discovery in RCS Presence Server (PS) is an entity that accepts, stores, and distributes SIP Presence Information. The PS performs the following functions: 1) Managing publications from one or multiple presence source(s). This includes refreshing presence information, replacing existing presence information with newly-published information, or removing presence information. 2) PS also manages subscriptions from watchers to presence information and generates notifications about presence information state changes, retrieving the presence authorization rules from the XDM Server. XML Document Management (XDM) server stores all the s. Remote storage allows the to get the list everywhere. A is stored with some mandatory information (id and display-name) and extended with social information. To keep XML documents compliant and interoperable, all specific information is stored in separate documents. Presence is based on OMA SIMPLE Presence 1.1 which partially uses IETF presence data model (RFC 4479). It requires you to publish your status (online, offline, favorite link, notes, availability, willingness, mood or per service/device) capabilities at any time. OMA Presence Content is an important element of Enhanced Address Book (EAB) to have the look and feel of some well-known VoIP software (Skype or Windows Live Messenger). It is possible to retrieve presence information for each in the phonebook using subscription mechanisms; presence could be retrieved one by one or per list. The SIP method of OPTIONS allows a UA to query another UA or a server as to its capabilities. This allows a client to discover information about the ed methods, content types, extensions, codecs, etc. without "ringing" the other party. For example, before a client inserts a required header field into an INVITE listing, an option that it is not certain the destination UAS s: The client can query the destination UAS with OPTIONS to see if this option is returned in a ed header field. All UAs MUST the OPTIONS method. SIP options for capability discovery is the default method or the fallback mechanism and the Service Providers that use SIP OPTIONS as the default discovery mechanism requires an Interworking Function (IWF); the IWF architecture is negotiated and agreed between interconnecting operators. The architecture must ensure that all messages that require interworking treatment are routed to the appropriate IWF. An IWF performs one or both of the following functions: 1) respond to SIP OPTIONS RCS capability exchange requests based on the information obtained from a Presence Server ([RCS5.0] 2) respond to SIP SUBSCRIBE requests based on the information obtained using SIP OPTIONS requests ([RCS5.0]. The IWF architecture may be required to bidirectional or unidirectional.



11-8


80- W3085-1 Rev A


Social Profile Information and Voice

Social Profile implementations are based on IMS core entities like presence, IM servers, and the ability for end devices to share the information across the networks. For details, refer to ETSI TS 102 901-IMS Interoperability and NNI. Pull mode in Presence OMA uses Representational State Transfer (REST), an architectural style that outlines how resources are created, accessed, and modified over the internet using a stateless communication protocol such as HTTP.



11-9


80- W3085-1 Rev A


Instant Messaging (IM)

Standard messaging or standalone messaging was part of pre RCS 5 release. Standard messaging using SIP uses a message sending method where the content of an IM is carried as the payload in a SIP message. Message content is carried as part of the signaling path, much like SMS. Also like SMS, the MESSAGE method provides a “pager” like experience, where there is no inherent connection between one message and another. Like SMS, the MESSAGE method also has limitations on the size of the content (< 1300 bytes) in a single message. One-one chat and Group-chat may use SIP options for messaging as long as the message size is < 1300 bytes; for larger message sizes, OMA Simple must be used. MSRP (RFC 4975) is a fundamentally richer approach, and differs from the MESSAGE method in several ways. The biggest difference is that MSRP uses a media session that is separate from the SIP/ OMA presence based signaling, similar to how RTP is used for audio, video, or other real time media sessions.



11-10


80- W3085-1 Rev A


Notes



11-11


80- W3085-1 Rev A


Notes



11-12


80- W3085-1 Rev A


Notes



11-13


80- W3085-1 Rev A


Notes



11-14


80- W3085-1 Rev A


Notes



11-15


80- W3085-1 Rev A


Notes



11-16


80- W3085-1 Rev A


RCS – One-One and Group Chat Enhancements As explained in the previous slide in OMA SIMPLE IM the SIP INVITE carries the first message, where as in OMA Converged IP Messaging (M) it does not. RCS v5.0. Management Object for the RCS configuration, there is a setting "imMsgTech" which defines if the client is using OMA SIMPLE IM (0) or OMA M (1). GSMA defines OMA M interoperability with SIMPLE IM. M specifies inter-working function between standalone messaging enabler and legacy messaging (SMS&MMS) and M includes file transfers. In summary SIMPLE IM is an instant chat only enabler where as M chat: 1) Is different from SIMPLE, 2) Includes store and forward standalone messaging functions; 3) Specifies IWF between standalone messaging enabler and legacy messaging (SMS & MMS) 4) Includes file transfers; 5) Includes network message store; and

6) Can leverage presence information. can use willingness as part of publish message to accept (open) or deny (close) availability or his basic status. Willingness means that even though you are available, you are/are not willing to communicate with anyone at the present time. Willingness is related and is only available with OMA Presence. Mood or feeling is used for conveying an emotion of a through an icon (avatar) and is a defined string in http; refer to OMA v2.0 and RFC 5438 for more details. SIP options do not have capabilities to convey willingness/mood, etc., as these are related and not devicecentric.



11-17


80- W3085-1 Rev A


RCS – Content Sharing Image/Video/File Transfer

In the illustration above, Converged IP Messaging (M’s) Control Function (CF) could be part of IPSM-GW (TS 23.204 architecture) for providing generic SMS over IP-CAN. OMA SIMPLE IM v2.0 could be used or Message Session Relay Protocol (MSRP). It is a protocol for transmitting a series of related instant messages in the context of a communications session. The MSRP protocol that is defined in RFC 4975 and MSRP messages can also be transmitted by using intermediaries peers, by using the relay extensions. MSRP is used in the RCS context, especially for IM, file transfer, image, and video share features. In contrast, MSRP is a transport protocol to individual messages, each sent independently. Messaging schemes that track only individual messages are described as "page-mode" messaging; refer to MSRP in RFC 4975 for more information.

When using the CSCF, Page-mode messaging is enabled in SIP via the SIP MESSAGE method.



11-18


80- W3085-1 Rev A


RCS – Video Sharing During a CS Call

CSI Feature Tag: Combinational Services – CSI feature is introduced in TS 24.279 Rel9 which simultaneously defines a set of combined CS and IMS services. The CSI feature tag also allows the mobile device to send in SIP INVITE for an enriched voice call to add an image or video with a feature tag (+g.3GPP.c-voice), shown in the call flow above.



11-19


80- W3085-1 Rev A


Comments/Notes



11-20


80-W3085-1 Rev A

Section 12: Voice over Wi-Fi (VoWiFi)



12-1


80-W3085-1 Rev A


Notes



12-2


80-W3085-1 Rev A


Notes



12-3


80-W3085-1 Rev A


Notes



12-4


80-W3085-1 Rev A


What is Voice over Wi-Fi (VoWiFi)? Wi-Fi offload has recently become one of the hot topics in the mobile industry. Exponential growth in the mobile network traffic has made the operators look for all the possible solutions to increase the capacity of their networks.

The abundance of unlicensed spectrum available for Wi-Fi has caught the operators’ attention for further expansion of their network capacity. The existence of Wi-Fi capability in most of the current wireless devices is an added advantage and is viewed as a cost-effective means of offloading large amounts of mobile data traffic. The universal presence and the demand for capacity has made Wi-Fi offload an easy and effective solution. One of the services that can be offloaded to Wi-Fi is voice. With voice over Wi-Fi (VoWiFi) , it is possible to move an active VoLTE voice call over an LTE network over to Wi-Fi and thus continue the call as a VoWiFi call. To VoWiFi, the handset needs to IMS over Wi-Fi. The VoWiFi device connects and s to the same IMS core as a VoLTE-enabled device. Services to which the device may over Wi-Fi include voice, video, SMS, etc.



12-5


80-W3085-1 Rev A


Notes



12-6


80-W3085-1 Rev A


Notes



12-7


80-W3085-1 Rev A


VoWiFi Offload Options Offload to Wi-Fi can be achieved using two approaches: 1. Solution with no IP address continuity: Application connectivity on the cellular access is terminated and has to be reinitiated after switching to the WLAN access; this approach is also referred to as the WLAN Direct IP Access or the WLAN Local Breakout. 2. Solution with IP address continuity: IP address being used on cellular access is preserved when switching to the WLAN access to keep the applications transparent to the switch; such an approach is commonly referred to as the Interworking Wireless LAN (IWLAN). Typically, VoWiFi uses this approach. The IWLAN feature allows the device to access services provided by the 3GPP network via the WLAN connectivity. When the WLAN connectivity is available, some or all of the cellular traffic is routed via the WLAN. One aspect about VoWiFi that makes it easy to deploy and use is that the Wi-Fi access does not have to be provided by the cellular operator.



12-8


80-W3085-1 Rev A


Trusted Access vs. Untrusted Access There are two types of access: trust and untrusted. Device behavior is different depending on the Trusted or Untrusted status of the WLAN access network when traffic is routed via the EPC core.

• Untrusted WLAN access: refers to the scenario where the WLAN access is not provided or authorized by the 3GPP operator or cannot be trusted by the operator for the 3GPP access without any security. Usually Wi-Fi access found at homes or enterprises is untrusted access type. The WLAN offload and VoWiFi works with both trusted and untrusted 3GPP access. To access an untrusted WLAN network, a device has to establish an IPSec tunnel toward the evolved Packet Data Gateway (ePDG) network element in the EPC core for secure data flow. The device has to authenticate with the 3GPP AAA (Proxy) server where the ePDG acts as an authenticator and gets the relevant parameters from the AAA server. It requires an EAP client in the device with IPSec . There are no changes to the Wi-Fi core, legacy Wi-Fi hotspot networks can work as well. ePDG maps the IPSec tunnels into GTP or PMIP tunnels that are terminated in the Packet Gateway (P-GW).

• Trusted WLAN Access: refers to Wi-Fi access provided by cellular operators, such as hotspots at coffee shops is an example of a trusted network. When accessing a trusted WLAN network, there is no need for the additional IPSec tunnel establishment. The device (UE) is connected through a TWAG (Trusted Wireless Access Gateway) in the Wi-Fi core. The TWAG is, in turn, connected directly with the P-GW (Packet Gateway) in the Evolved Packet Core (EPC) through a secure tunnel (GTP, MIP, or PMIP).



12-9

80-W3085-1 Rev A

VoLTE and IMS – Overview, Protocols, and Performance Section 12: Voice over Wi-Fi (VoWiFi)

Voice Codecs AMR and AMR-WB The Adaptive Multi-Rate – Narrowband/Wideband (AMR-NB/AMR-WB) codecs, adopted by VoLTE, are ed on IWLAN. The details of the AMR-NB and AMR-WB codecs are found in specifications 14 and 15. 14 (General description) includes a comprehensive list of all AMR and AMR-WB 3GPP specifications. The bit rates of both codecs are given in Table 1 (below). Table 1 AMR and AMR-WB Codecs Bit Rates (All values in kbps) AMR

4.75

5.15

5.90

6.70

7.40

7.95

10.20

12.20

AMR-WB

6.60

8.85

12.65

14.25

15.85

18.25

19.85

23.05

23.85

EVS codecs are standardized in 3GPP Release 12 The details of the EVS codecs can be found in specifications 16 and 17. 16 (General Overview) includes a comprehensive list of all AMR and AMR-WB 3GPP specifications. Key Features

• • • • • •

Super-wideband speech for improved speech quality Source-controlled variable bit-rate operation – improved capacity Designed for VoIP – improved robustness Improved music performance Wide bit-rate range and all bandwidths for maximum flexibility Backward interoperable mode to AMR-WB



12-10


80-W3085-1 Rev A


Notes



12-11


80-W3085-1 Rev A


VoWiFi Architectures S2a/ePDG-based: This architecture was introduced in 3GPP Release 11 and is discussed in the Appendix. It provides the plane with related control and mobility between trusted non-3GPP IP access and Gateway. S2b/ePDG-based: This is the most commonly used architecture. An operator can VoWiFi over any access point (AP) whether used in residences, enterprises, or in commercial establishments by adding an ePDG into its network with no need to roll out a large number of operator-provided access points. More details are discussed in the following slides. It provides the plane with related control and mobility between ePDG and Gateway. S2c/eDPG-based: This architecture is the least commonly used and is covered in the Appendix. It provides the plane with related control and mobility between UE and Gateway.



12-12


80-W3085-1 Rev A


S2b/ePDG-based WLAN Offload This slide illustrates the high-level 3GPP architecture for the S2b/ePDG-based WLAN offload. There are other architectures specified in the IWLAN specification, however S2b-based architecture is the most commonly used one. An operator can VoWiFi over any access point (AP) whether used in residences, enterprises, or in commercial establishments by adding an ePDG into its network with no need to roll out a large number of operator-provided access points. The UE associates with a WLAN AP. IP packets are forwarded to the 3GPP access network via the WLAN. The ePDG is the entry point into the 3GPP access network for the WLAN + ePDG-enabled UE. The UE establishes an IPSec-IKEv2 tunnel per PDN with the ePDG. The ePDG then proceeds to establish a PMIP tunnel over the S2b reference point with the PDN Gateway (retrieving a remote IP address) for each connection. The UE consequently has two IP addresses, one being the local IP address obtained by association with the WLAN, and the other being the remote IP address assigned to the UE per tunnel establishment by the ePDG. The UE exchanges application data and IKEv2 control packets with the ePDG over the Wu interface. The application data packets are further forwarded to the Internet via the ePDG through the PDN Gateway using the PMIP tunnel over the S2b reference point. The reverse path assumed is symmetrically opposite. Application data packets arriving from the Internet get forwarded from the 3GPP core network to the ePDG via the PMIP tunnel over the S2b reference point and ultimately to the UE through the WLAN access network. The ePDG node that provides the 3GPP connectivity for untrusted non-3GPP access, e.g., untrusted WLAN access, serves as an entry point to the 3GPP network for all data traffic. Some of the functions of ePDG are listed below: • Serves as an endpoint for IKEv2 signaling for tunnel authentication and authorization, and acts as a relay for AAA messages. • Allocates the IP addresses for PDN connectivity via IKEv2 signaling. • Allocates other auxiliary information required for data connectivity like the DNS and P-CSCF server addresses via IKEv2 signaling. • Performs decapsulation and encapsulation of tunneled IPSec and PMIPv6 packets. • Routes the data packets between the device and the PDN Gateway. • Acts as a Mobility Access Gateway (MAG) for PMIPv6-based IP mobility. • Enforces QoS policies and does transport-level packet marking in the Uplink.



12-13


80-W3085-1 Rev A


S2b/ePDG Protocol Stack The control and plane data protocol stacks that need to be ed by the device for VoWiFi calls using the S2b/ePDG are shown in the Figure above. For the control plane, the UE and the ePDG communicate using IKEv2. The ePDG and the PDN Gateway communicate using Proxy MIPv6. For the data plane, packets between the UE and the ePDG are encapsulated with IPSec/ESP tunnel. The tunneling layer between the ePDG and the PDN Gateway over the S2b reference point is the GRE encapsulation for Proxy MIPv6. Since the PMIPv6 is used over an S2b reference point between the ePDG and the PDN Gateway, the ePDG is also referred to as MAG, and the PDN Gateway is also referred to as Local Mobility Anchor (LMA), per the PMIPv6 architecture.



12-14


80-W3085-1 Rev A


Notes



12-15


80-W3085-1 Rev A


Notes



12-16


80-W3085-1 Rev A


IMS Registration via S2b - Initial Attach over S2b 1. The first step for the UE is to establish connectivity with a local untrusted network. For example, it may attach to a hotspot wireless LAN (untrusted network). 2. The hotspot provider assigns a local IP address to the UE. 3. The UE initiates IKEv2 with the ePDG. The address of the ePDG may be pre-configured in the UE or it may be sent dynamically by another means. 4. The UE starts an IKEv2 procedure to establish a secure tunnel. The UE sends an APN in the IKEv2 message. As part of this process, the UE must be authenticated as well; AKA is used to authenticate the UE. The AKA parameters are carried in IKEv2 messages. The ePDG sends AKA parameters in EAP to the AAA server, which interacts with the HSS. Once the UE is authenticated, the HSS s the subscriber profile to the ePDG. 5. The ePDG sends a Create Session Request (IMSI, APN, RAT type, ePDG TEID for control plane. PDN Type, PDN Address, EPS Bearer Identity, Default EPS Bearer QoS, ePDG Address for the plane) message to the P-GW. The RAT type indicates the non-3GPP IP access technology type. More information in TS 23.401 [4]. The ePDG shall set the Dual Address Bearer Flag when the PDN type is set to IPv4v6 and all SGSNs, which the UE may be handed over to are Release 8 or above ing dual addressing. The Additional Parameters include the authentication credentials for an additional authentication and authorization with an external AAA server if it was provided by the UE before this step. The ePDG shall provide the IMEI(SV) if available. The PDN GW performs the authentication and authorization with the external AAA server if it is required to get access for the given APN. The Location Information shall include UE local IP address and optionally the UDP source port number (if NAT is detected). It may also include WLAN Location Information (and its Age). The ePDG may have received from the 3GPP AAA server about the UE. NOTE 1: The UE local IP address is the source address on the outer header of the IPSec tunnel to the ePDG. The P-GW creates a new entry in its bearer context table and generates a Charging Id. The new entry allows the P-GW to route plane PDUs between the ePDG and the packet data network and to start charging. NOTE 2: The EPS Bearer Identity and Default EPS Bearer QoS parameters convey the S2b bearer identity and the default S2b bearer QoS. 6. The PDN GW initiates the IP CAN Session Establishment Procedure with the PCRF, as specified in TS 23.203 [19]. If available, the PCRF provides the APN-AMBR and Default Bearer QoS to the PDN GW in the response message. © 2016 Qualcomm Technologies, Inc.


12-17


80-W3085-1 Rev A


Initial Attach over S2b (continued) 7. The selected PDN GW informs the 3GPP AAA Server of the PDN GW identity. The 3GPP AAA Server then informs the HSS of the PDN GW identity and APN associated with the UE's PDN Connection. The message includes information that identifies the PLMN in which the PDN GW is located. The PDN GW shall only use the APN-AMBR and Default Bearer QoS received from the 3GPP AAA server in this step if these parameters have not been received in step 6. When the 3GPP AAA Server is informed of the PDN GW identity, the selected PDN GW indicates the selected S2b protocol variant (here GTP); this allows the option for the 3GPP AAA Server or 3GPP AAA Proxy not to return to the PDN GW PMIP specific parameters (e.g., static QoS Profile, Trace Information, APN-AMBR) if GTP is used over S2b; the PDN GW shall ignore those parameters if received from the 3GPP AAA Server or 3GPP AAA Proxy.

8.

The PDN GW forwards to the PCRF in the IP-CAN Session Establishment procedure following information extracted from the Location Information it may have received from the ePDG: • The UE local IP address • WLAN location information in conjunction with the Age of this information The PDN GW returns a Create Session Response (PDN GW Address for the plane, PDN GW TEID of the plane, PDN GW TEID of the control plane, PDN Type, PDN Address, EPS Bearer Identity, EPS Bearer QoS, APN-AMBR, Charging ID, Cause) message to the ePDG, including the IP address(es) allocated for the UE. The PDN GW selects the PDN type to be used in the same way as done during the E-UTRAN Initial Attach in TS 23.401 [4]. The P-GW may initiate the creation of dedicated bearers on GTP based S2b (this may occur on a GTP based S5/S8 for an attachment to 3GPP access). NOTE 3: If the UE requests for both IPv4 address and IPv6 prefix, both are allocated. If the PDN GW operator dictates the use of IPv4 address only or IPv6 prefix only for this APN, the PDN GW shall allocate the IPv4 address or the IPv6 prefix to the UE accordingly. If the UE requests for only IPv4 address or IPv6 prefix only one address/prefix is allocated accordingly.

9.

The ePDG sends the final IKEv2 message with the IP address in IKEv2 Configuration payloads. The ePDG also includes the identity of the associated PDN (APN) in the IDr payload of IKEv2. If the UE provided the APN to the ePDG in the earlier steps, the ePDG shall not change the provided APN. The IP connectivity from the UE to the PDN GW is now set up. Any packet in the Uplink direction is tunnelled to the ePDG by the UE using the IPSec tunnel; The ePDG then tunnels the packet to the PDN GW. From the PDN, GW normal IP-based routing takes place. In the Downlink direction, the packet for UE arrives at the PDN GW. The PDN GW tunnels the packet based on the binding cache entry to the ePDG. The ePDG then tunnels the packet to the UE via proper IPSec tunnel.



12-18


80-W3085-1 Rev A


Notes



12-19


80-W3085-1 Rev A


Notes



12-20


80-W3085-1 Rev A


Notes



12-21


80-W3085-1 Rev A


Notes



12-22


80-W3085-1 Rev A


Handover Decision Process The handover process involves two RATs. The source RAT is the radio access technology the UE already has service with. The target RAT is the radio access technology that the UE intends to acquire service with and camp on at the end of the handover process. The source system criteria for under performance are only used when the source system is considered to be more preferred than the target system. If the target system is preferred, only the target system criteria is used for transitioning into that system. The criteria for Handover is based on proprietary implementation.



12-23


80-W3085-1 Rev A


Notes



12-24


80-W3085-1 Rev A


VoWiFi to VoLTE Handover Call Flow The handover may take place when the Wi-Fi network is no longer able to provide the required quality of service if the RSSI of Wi-Fi is weak or based on other UE configured policies. The UE sends a PDN connectivity request with cause handover and APN set to the same APN it is ed for IMS over Wi-Fi. In response, the UE receives a configuration for QCI-1 and QCI-5 bearers. The UE uses the QCI-5 bearer for SIP re-registration over LTE and starts to use QCI-1 bearer for sending and receiving RTP packets.



12-25


80-W3085-1 Rev A


Notes



12-26


80-W3085-1 Rev A


VoLTE to VoWiFi Handover Call Flow The UE is on a VoLTE call and there is a GTP tunnel between the P-GW and the S-GW. The UE may evaluate the need to handover based on a number of reasons including weak LTE RF or bad call quality during the VoLTE call. The UE then performs IWLAN attachment and IPSec tunnel setup tunnel establishment. If the PDN policy allows for the WLAN offload, the UE initiates the PDN connection over the WLAN by triggering the IKEv2 protocol with the ePDG to set up the IPSec tunnel parameters and security associations. IKEv2 negotiation involves the authentication and authorization of the UE for 3GPP access using EAP-AKA with the AAA server. The IKEv2 procedures also include the discovery of the presence of a NAT between the UE and the ePDG to allow for subsequent NAT traversal. The UE may include the IP addresses of the PDN if it is handing off the PDN from a previous WWAN connectivity. The UE may also include an APN in IKEv2 to identify the PDN it wishes to connect. If no APN is provided, the ePDG assumes default APN. The ePDG sends a Proxy Binding Update to the PDN Gateway to set up the PDN connection. The ePDG identifies the UE to the PDN-GW and provides the configuration information requested via IKEv2 from the UE in the binding update message. The PDN Gateway sets up an IP-CAN session with the PCRF. The PDN Gateway identifies itself to the HSS/AAA and s its information in the HSS for this PDN connection. The PDN Gateway creates a binding for the UE and allocates IP addresses for the UE via a Proxy Binding Ack to the ePDG. This completes the IKEv2 negotiation and sets up an IPSec tunnel for data transfer between the UE and the ePDG. The UE also discovers the PDN IP addresses, DNS, and P-CSCF server addresses via IKEv2 signalling. Thus, an IPSec tunnel is now successfully established between the UE and the ePDG, and a corresponding PMIP tunnel is established between the ePDG and the PDN Gateway. The UE uses this IPSec tunnel for secure 3GPP access for the corresponding PDN via the ePDG, which helps in encapsulation/decapsulation of the IPSec tunnel to send packets to/from the UE. The ePDG tunnels packets to/from the UE to the PDN Gateway via the PMIP tunnel. The UE can then send a SIP Re-registration to the IMS core network over Wi-Fi. After IMS registration is completed over WiFi, IMS core will message the E-UTRAN to tear down the resources allocated to the UE during the VoLTE call. As a result UE will receive a Deactivate EPS Bearer message to release QCI and QCI5 bearers. © 2016 Qualcomm Technologies, Inc.


12-27


80-W3085-1 Rev A


Notes



12-28


80-W3085-1 Rev A


DRVCC The Dual Radio Voice Call Continuity feature refers to the capability of the IMS network and ICS enhanced CS network or a MSC with SIP interface to the IMS network, which is used to provide voice continuity. This applies when using a PS access network and the network is unable to the full duplex speech/video component of an IMS-based service and so the CS core network is utilized to establish a circuit bearer for use as media for IMS sessions. DRVCC uses single IMS registration on the source network where the UE was ed before access transfer using the DRVCC procedure was triggered. PS-CS Access Transfer is provided according to the requirements specified in IETF RFC 6809. DRVCC features can be summarized at a high level as follows: • While the UE is in a IMS call on PS domain, the UE sets up a “silent” call to a special e.164 number on the CS domain (called session transfer number or STN). • The MSC determines, based on the STN, that the call is expected to be transferred from IMS domain to the CS domain and initiates access transfer with the IMS Network. • When the CS call is successful to this STN, the UE locally releases the call on the IMS domain and the call continues on the CS domain. • To ensure good experience during this process (“make-before-break”), the audio interruption delay is required to be bounded by 300 ms. • Unlike SRVCC, which is a network initiated procedure, the trigger for DRVCC is based on “proprietary” schemes defined at the UE. © 2016 Qualcomm Technologies, Inc.


12-29


80-W3085-1 Rev A


Notes



12-30


80-W3085-1 Rev A


Notes



12-31


80-W3085-1 Rev A


Notes



12-32


80-W3085-1 Rev A


Notes



12-33


80-W3085-1 Rev A


Notes



12-34


80-W3085-1 Rev A


Notes



12-35


80-W3085-1 Rev A


Notes



12-36


80-W3085-1 Rev A


Notes



12-37


80-W3085-1 Rev A


Notes



12-38


80-W3085-1 Rev A


Notes



12-39


80-W3085-1 Rev A


Notes



12-40


80-W3085-1 Rev A


Notes



12-41


80-W3085-1 Rev A


Notes



12-42


80-W3085-1 Rev A


Notes



12-43


80-W3085-1 Rev A


Notes



12-44


80-W3085-1 Rev A


S2a/ePDG Interface The S2a based approach, illustrated above, was introduced in 3GPP Release 11 specification. The key change in this case was to eliminate the need to set up an IPSec/IKEv2 tunnel. Security and authentication is done by means of the EAP protocol that is ed by both UEs and the access point. EAP-SIM or EAP AKA methods are typically used to authenticate the UE. The S2a interface provides the plane with related control and mobility between trusted non-3GPP IP access and the PDN Gateway. S2a-based WLAN offload is used when the WLAN access is provided and authorized by the 3GPP operator itself, and hence it is trusted by the operator for direct 3GPP core network access from the device via the WLAN.



12-45


80-W3085-1 Rev A


S2c/ePDG Interface When a trusted non-3GPP access network is used one or more IP addresses are allocated to the UE by the trusted non-3gpp access network. One of these IP addresses is used by the UE as care-of address within DSMIPv6. When an untrusted Non-3GPP access network is used one or more IP addresses are allocated to the UE by the untrusted non-3gpp access network. One of these IP addresses is used by the UE as the IP address towards the ePDG when IPSec SAs are established. During the IPSec SA establishment the ePDG allocates and delivers an IP address to the UE, the IP address is used by the UE as a care-of address within DSMIPv6. This IP address is allocated by the ePDG either by using an internal address pool or using an external server, such as DH. The allocation of this IP address is implementation specific. When a UE is connecting to a PDN via S2c, address allocation for that PDN takes place as follows. During the IKEv2 exchange for bootstrapping the DSMIPv6 security association the following parameters can be negotiated between the UE and the PDN GW/HA:

• The IPv6 prefix that the IPv6 Home Address belongs to, also called the "Home Network Prefix" and the PDN associated with the IPv6 prefix (PDN is indicated with APN); • The UE's IPv6 Home Address; • The DNS server address for that PDN.

The UE may request additional configuration parameters by running stateless DH as defined in RFC 4039 and RFC 3736 over the DSMIPv6 tunnel. The UE may also request an IPv4 home address using DSMIPv6 signaling, as defined in RFC 5555. The PDN GW/HA may receive a static IP address (i.e., a static IPv4 address and/or a static IPv6 prefix) from HSS/AAA during the authentication and authorization procedure. Then the PDN GW/HA shall assign the static IP address to the UE, as indicated above. © 2016 Qualcomm Technologies, Inc.


12-46


80-W3085-1 Rev A


Notes



12-47


80-W3085-1 Rev A


DRVCC Architecture on 3GPP This slide illustrates the bearer states before and after DRVCC procedure is complete. The diagram is directly sourced from 3GPP specification (for reference only). DRVCC enables session transfer of a VoIWLAN call to the CS domain. This process involves the EUTRAN redirecting the UE to execute handover to UMTS/GSM. Following the handover, the voice call continues on the CS domain with the MSC bridging the session with the IMS system anchored via the SCC AS. The list below shows the main functions of each of the components that are impacted to UMTS/GSM DRVCC capability. 3GPP system impacts to UMTS/GSM DRVCC Entity: UMTS/GSMDRVCC roles (high-level). UE: If the UE s 3GPP2 UMTS/GSMCS access, the UMTS/GSMCS DRVCC UE is capable to perform DRVCC to the 3GPP2 UMTS/GSMCS system. The UE is provisioned with the static STN, which it uses as the called party number when attempting to transfer the voice call from the PS to CS domain. MSC server ed detection of dynamic or static STN and initiating the voice call continuity with the IMS system. IMS system CSCF, CS-MGW, SCC AS: s interworking with UMTS/GSM MSC for transferring an active non-emergency calls from PS to CS domain. I2 Reference point: The I2 reference point is used to route service control signaling between the MSC Server enhanced for ICS and the home IMS. Mc Reference point: The Mc reference point, established between the MSC Server enhanced for ICS and the CS-MGW used to Voice frame interworking. © 2016 Qualcomm Technologies, Inc.


12-48


80-W3085-1 Rev A


DRVCC Call Flow from IWLAN to UMTS/GSM Trigger: The UE decides to switch the call from IWLAN to UMTS based on the configured handoff criteria. 1. The UE is operating in dual radio mode where one radio interface is monitoring UMTS/GSM service on which the UE has attached for CS service and the other radio interface is monitoring WLAN that has an active IMS registration. The UE has processed the dynamic STN feature tag and the dynamic STN is available at the UE. 2. An ongoing VoIP session over the IMS access leg is established via the IWLAN access. 3. The UE determines that the PS voice session must be transferred to the CS domain using PS-CS access transfer based on operator policy. The Wi-Fi stack notifies the UMTS/GSM stack to initiate the CS session and es the dynamic STN. 4. The UE needs a radio resource to deliver the call control signaling to the CS access domain and initiates the CS access transfer. • For GSM operation, the UE performs the RR Channel Request procedure. • For UMTS operation, the UE performs the RRC Connection Setup procedure. 5. Following a successful CS access for radio resource allocation, the UE performs the Service Request procedure for RAB assignment including checks to Authentication and Ciphering. 6. The UE sends the CC SETUP message to the MSC. The message contains BCD number IE with dynamic STN, if available, or static STN, if dynamic STN is not available 7. The MSC Server enhanced for ICS or with a SIP interface identifies the use of Dynamic or Static STN and applies Call Continuity procedures. The MSC sends the SIP INVITE request (Interworking entities to Intermediate IM CN subsystem entities) per 3GPP TS 24.237. 8. The MSC Server enhanced for ICS or with a SIP interface sends the selected codec to the CS UE in NAS synchronization indicator bit in the RAB assignment message. 9. The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request. Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE 2. © 2016 Qualcomm Technologies, Inc.


12-49


80-W3085-1 Rev A


DRVCC Call Flow from IWLAN to UMTS/GSM (continued) Trigger: The UE decides to switch the call from IWLAN to UMTS based on the configured handoff criteria 10. SIP 200 (ok): Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, it immediately sends the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The SDP answer indicates that the resources are available. 11. The MSC delivers CC CONNECT message (interworking entities to UE A) indicating a successful CS bearer resource allocation. 12. The UE responds with the CC CONNECT ACKNOWLEDGE message (UE A to interworking entities (MSC)). 13. Media paths between UE 1 and UE 2: The CS bearer is set up while the PS bearer still exists. 14. SIP BYE request (SCC AS to UE A via intermediate IM CN subsystem entities). The SCC AS terminates the replaced call leg, which was using the old IP-CAN, by sending a SIP BYE request to the UE A. UE A then sends a SIP 200 (OK) response over the old IP-CAN to the SCC AS ands subsequently relinquishes all resources pertaining to the old IP-CAN. 15. The PS to CS access transfer is complete and voice packets flow end-to-end between UE1↔UMTS/GSM BSC↔UMTS/GSM MSC↔MGCF/MGW↔UE2.



12-50


80-W3085-1 Rev A


Notes



12-51


80-W3085-1 Rev A


DRVCC Call Flow from IWLAN to 1X Trigger: The UE decides to switch the VoIWLAN call from IWLAN to 1X CS. 1.

An ongoing VoIP session over the IMS access leg is established via IWLAN access.

2. The UE is operating in Dual Radio mode where one radio interface is monitoring CDMA 1X service, on which the UE has ed with the CDMA 1X network, and the other radio interface is monitoring WLAN, which has an active IMS registration. 3. The UE determines that the PS voice session must be transferred to the CS domain using PS-CS access transfer based on operator policy. The PS stack notifies the CS (CDMA 1X) stack to initiate the CS session and es the VDN. 4. The UE needs a radio resource to deliver the call control signaling to the CS access domain and initiates the CS access transfer. For a CDMA 1X operation, the UE performs the call origination procedure by sending the origination message to the MSC. 5. The VCC AS determines that this is a domain transfer scenario based on the VDN in the called party number (and the calling party number) and performs the MAP procedures per 3GPP2 X.S0042-B v1.0. 6. Any time after step 4 and before step 7, the visited MSC sends a 1X traffic assignment. 7-11. These steps are similar to steps 12-25 from Section 4.5.1 of HRPD VoIP-to-1X CS Voice DT in 3GPP2 X.S0042-B v1.0.



12-52


80-W3085-1 Rev A


DRVCC Call Flow from IWLAN to 1X (continued) Trigger: The UE decides to switch the VoIWLAN call from IWLAN to 1X CS. 7-11. These steps are similar to steps 12-25 from Section 4.5.1 of HRPD VoIP-to-1X CS Voice DT in 3GPP2 X.S0042-B v1.0.

12. The MSC delivers a Service Connect Complete message indicating a successful CS bearer resource allocation. The UE also transitions the codec from the PS call to the CS call depending on the assigned codec. 13. The UE responds with the Service Connect Complete message. The UE locally terminates the PS voice session. 14. Media paths between UE 1 and UE 2 are established.



12-53


80-W3085-1 Rev A


Comments/Notes



12-54


80-W3085-1 Rev A

Section 13: Video over LTE (ViLTE)



13-1


80-W3085-1 Rev A


Notes



13-2


80-W3085-1 Rev A


Notes



13-3


80-W3085-1 Rev A


Notes



13-4


80-W3085-1 Rev A


Overview

As IMS services are deployed in Mobile Networks, and with more capacity and speeds available on LTE networks, operators can offer more services via IMS such as Video Telephony. This can improve experience, as opposed to Over The Top services, because operators can provide a guaranteed bit rate for each audio and video bearer, which can ensure a more reliable and differentiated service to their customers. These services need minimum requirements from the UE side and no extra applications on the OS, making Video Telephony a service that is ready to use when the UE is turned on.



13-5


80-W3085-1 Rev A


Requirements For detailed requirements, refer to:

• GSMA PRD IR.92 IMS Profile for Voice and SMS • GSMA PRD IR.94 IMS Profile for Conversational Video Service • RFC 3840 Indicating Agent Capabilities in the Session Initiation Protocol (SIP) • RFC 3841 Caller Preferences for the Session Initiation Protocol (SIP)



13-6


80-W3085-1 Rev A


Notes



13-7


80-W3085-1 Rev A


Video Codecs

Per GSMA IR.94 - IMS Profile for Conversational Video Service of ITU-T Recommendation H.264 Constrained Baseline Profile (CBP) Level 1.2, as specified in 3GPP release 10 TS 26.114 section 5.2.2, is mandatory in the UE and the entities in the IMS core network that terminate the plane. for H.265 (HEVC) Main Profile, Main Tier, Level 3.1, as specified in 3GPP release 12 TS 26.114 section 5.2.2, is recommended in the UE and the entities in the IMS core network that terminate the plane. The in the UE of ITU-T Recommendation H.263 Profile 0 Level 45, as specified in 3GPP release 8 TS 26.114 section 5.2.2, is not required.

When sending the currently active H.264 parameter set (SPS and PPS) in the RTP media stream, the UE and the entities in the network terminating the media plane must repeat the parameter set at multiple occasions and with appropriate spacing with regard to the channel loss characteristics.



13-8


80-W3085-1 Rev A


Notes



13-9


80-W3085-1 Rev A


VT Call Initiated Call Flow Bearer Considerations for Video E-UTRAN For an IMS session request for a video call (originating or terminating) in E-UTRAN, one dedicated bearer resource for voice, as specified in IR.92, and another dedicated bearer resource for video must be created by authorizing the flows utilizing dynamic PCC (Policy and Charging Control). The network must initiate the creation of dedicated bearer resources to transport voice and video media. The dedicated bearer for a Conversational Video stream may be a GBR or a non-GBR bearer. A GBR bearer must utilize the standardized QCI value of two (2) and have the associated characteristics specified in 3GPP TS 23.203. For IMS session termination of a session using conversational media, the dedicated bearer resources must be deleted by withdrawing the authorization of the flows. The network must initiate the deletion of the bearer resources. Call Flow Steps VT session procedures These procedures are used to establish and terminate a VT session with a remote party. In general, the remote party may be a on a wireless network, the Internet, or the S-GW. [1] represents a sequence of messages for either an MT or MO VT call. [2a] and [2b] involve establishing dedicated bearers for VT voice and video media respectively; these message exchanges are discussed in 3GPP: TS 24.301. [3] shows the bidirectional VT voice data and unidirectional/bidirectional VT video data between the UE and the EUTRAN. This data is routed from the E-UTRAN to the other remote party involved in the call (not shown in Call Flow). Each video frame is generated by the video encoder and carried as the payload in an RTP packet. The RTP packets are encapsulated in Datagram Protocol (UDP) packets and carried over the IP. The audio and video frames are synchronized using RT. The RTP/UDP/IP header is compressed using RoHC. [4] VT session termination. [5] Dedicated bearers are release following call termination. Procedures are described in 3GPP TS 24.301. © 2016 Qualcomm Technologies, Inc.


13-10


80-W3085-1 Rev A


Session Modification (Upgrade) Call Flow VoLTE and VT Session Procedures These procedures are used to establish and terminate a VT session with a remote party. In general, the remote party may be a on a wireless network, the Internet, or the S-GW. [1] represents a sequence of messages for either an MT or MO VoLTE call. [2] involve establishing a dedicated bearer for voice media; these message exchanges are discussed in 3GPP: TS 24.301. [3] shows the bidirectional VoLTE voice data between the UE and the E-UTRAN. This data is routed from the E-UTRAN to the other remote party involved in the call (not shown in Call Flow). The RTP packets are encapsulated in Datagram Protocol (UDP) packets and carried over the IP. The audio packets are synchronized using RT. The RTP/UDP/IP header is compressed using RoHC. [4] with the Voice Call active, UE requests to UPGRADE the Voice Call to VT Call bidirectional. This is shown as a sequence of messages for either an MT or MO VoLTE call, with a video tag on the SDP section from the SIP UPGRADE message. [5] involve establishing a dedicated bearer for video media; these message exchanges are discussed in 3GPP: TS 24.301. [6] shows the bidirectional VT voice data and unidirectional/bidirectional VT video data between the UE and the E-UTRAN. This data is routed from the E-UTRAN to the other remote party involved in the call (not shown in Call Flow). Each video frame is generated by the video encoder and carried as the payload in an RTP packet. The RTP packets are encapsulated in Datagram Protocol (UDP) packets and carried over the IP. The audio and video frames are synchronized using RT. The RTP/UDP/IP header is compressed using RoHC. [7] shows VT session termination signaling and illustrates the dedicated bearers release procedures described in 3GPP: TS 24.301. © 2016 Qualcomm Technologies, Inc.


13-11


80-W3085-1 Rev A


Notes



13-12


80-W3085-1 Rev A


Notes



13-13


80-W3085-1 Rev A


Notes



13-14


80-W3085-1 Rev A


Notes



13-15


80-W3085-1 Rev A


Notes



13-16


80-W3085-1 Rev A


Notes



13-17


80-W3085-1 Rev A


Notes



13-18


80-W3085-1 Rev A


Notes



13-19


80-W3085-1 Rev A


Notes



13-20


80-W3085-1 Rev A


Notes



13-21


80-W3085-1 Rev A


Comments/Notes



13-22

Volte Q n4g4b

Overview 3e4r5l

More details w3441

Related Documents 3m3m1z

Volte Q n4g4b

Volte 206l1p

10mila Volte 606n43

Volte-qci 5i5r63

Volte Troubleshooting 4cm6s

Volte Optimisation 3b5q5

More Documents from "julio_mora" 3v123y

Ensayo Gerencia Talento Humano Siglo Xxi 2o116j

Ensayo Gerencia Talento Humano Siglo Xxi 2o116j