VoLTE: Traffic Flow Templates

The service data flow template is a set of packet filters applied to IP packets to identify the service data flow belonging to a specific application. The packet filters typically consist of IP 5-tuples, i.e., source IP address, destination IP address, source port, destination port, protocol type. The service data flow template is delivered to the PGW contained in the PCC rules. The PGW identifies the service data flow based on the service data flow template applied in the order of filtering priorities. Once the service data flow is identified, the corresponding QoS parameters are applied to relate the service data flow to a certain EPS bearer.

I. TFT filter
Once the bearer binding is completed, that is, the PGW builds mapping relations between EPS bearers and the corresponding PCC rules, the PGW requests the creation of the EPS bearer (i.e., Create Bearer Request) towards the MME in which the set of IP 5-tuples are interpreted as a bearer level Traffic Flow Template (TFT). The TFT can be defined either separately for uplink and downlink or for both uplink and downlink. The TFT for the downlink is used by the network element whereas the TFT for the uplink is used by the UE. The following diagram shows the TFT structure when the TFT operation is add, create or replace [TS24.008].

• TFT operation code : the action to be taken to the TFT and/or packet filter list e.g., create, delete, add, replace, etc. 
• Number of packet filters : the number of packet filters. In case the operation code is "Delete existing TFT" or "no operation code", the number of filters will be 0. Otherwise, the maximum number of packet filters is 15.
• Packet filter direction: the direction of the traffic, i.e., uplink only, downlink only, bidirectional
• Packet filter identifier: the unique number to identify the packet filter
• Packet filter evaluation precedence: the precedence for the packet filter among all the packet filters in all TFTs associated with the PDP address.
• Packet filter contents: variable components with variable size such as remote/local IPv4/IPv6 address, protocol identifier, remote/local port, etc.

The following snapshot shows the TFT included in the Create Bearer Request (PGW/SGW->MME) captured over S11. The TFT operation code is to "Create a new TFT" and the direction of the IP flow to which this TFT is applied is an "uplink only" as this TFT is supposed to be used by the UE. The precedence value indicates the priority for this filter among other filters to be applied to the IP flow. Therefore this priority value must be locally unique in the UE. In this example, the IPv4 remote address indicates the P-CSCF address.

The following snapshot shows the TFT included in the Activate dedicated EPS bearer (MME ->eNB) captured over S1AP. As the TFT is included in the NAS message, it is delivered to the UE transparently so it can be used by the UE.

In a nutshell, the uplink-only TFT is created by the PGW based on the received PCC rules and sent to the UE so the UE can utilize it to filter and map the outgoing IP packets with the corresponding uplink EPS bearer.


II. TFT errors
The TFT is delivered from the MME to UE or vice versa contained in a NAS message over S1AP and the RRC interfaces. The TFT errors indicate operational inconsistencies from semantics or syntax perspectives between TFT operations, packet filters and NAS messages and once detected, it leads to the failure of EPS bearer level operations. The 3GPP TS24.301 has specified four types of TFT related errors as below:

(1) Semantic error in the TFT operation is more likely the case when there is a contextual inconsistency in the TFT operation. The following shows example cases:
   - The TFT operation of other than "Create a new TFT" in the Activate dedicated EPS bearer context request.
   - The TFT operation of "Delete packet filters from existing TFT" when the deletion will result in the empty TFT.
(2) Syntactical error in TFT operations is more likely the case when there is a logical inconsistency between TFT operation and the packet filters. The following shows example cases:
   - The TFT operation of "Create a new TFT" and the empty packet filter list in the TFT IE.
   - The TFT operation of "Add packet filters in existing TFT" and the empty packet filter list in the TFT IE.
   - The TFT operation of "Delete packet filters from existing TFT" when there is no corresponding packet filter in the existing TFT.
(3) Semantic error(s) in packet filter(s) is more likely the case when a packet filter consists of conflicting packet filter component which would render the packet filter ineffective.
(4) Syntactical error(s) in packet filters(s) is more likely the case when two or more packet filters in the resultant TFT would have component(s) with identical values such as the same packet filter identifiers, the same packet filter precedence values, etc.

Each of the above error cause can appear in the following NAS messages as an ESM cause:

(1) The Activate dedicated EPS bearer context reject (UE-->MME) as a failure to create the dedicated EPS bearer.
(2) The Modify EPS bearer context reject (UE-->MME) as a failure to modify the dedicated EPS bearer.
(3) The Bearer Resource Allocation reject (MME-->UE) as a failure to initiate the activation of the dedicated EPS bearer.
(4) The Bearer Resource Modification reject (MME-->UE) as a failure to initiate the update of the dedicated EPS bearer.


III. Case study
The following snapshot has been captured while testing the conference call scenario. Having been sorted out based on the MME-UE-S1AP-ID, it shows the lifetime of the EPS bearer from when it is created until it is released due to the "semantic error in the TFT operation". In the meantime, there are five times of EPS bearer modifications occurred.

NOTE The MME-UE-S1AP-ID is assigned by the MME to identify the UE over S1AP. In the same way, the eNB also identifies the UE by assigning the ENB-UE-S1AP-ID.

The following snapshot shows the TFT in the Activate dedicated EPS bearer context request. Please note that there are two packet filters, one for the RTP and the other one for the RTCP. The TFT operation has to be "Create a new TFT". The packet filter identifiers are 1 and 2 and the precedence values are 223 and 191, respectively.

NOTE the detail of the second packet filter is not shown in this snapshot.

The following snapshot shows the TFT in the first Modify EPS bearer context request. The TFT operation is "Add packet filters to existing TFT". The packet filter identifiers are 3 and 4 and the packet precedence values are 247 and 239, respectively.

NOTE the detail of the second packet filter is not shown in this snapshot.

All the history of packet filters for the rest of operations can also be analyzed following the same way. The following table shows the resulting analysis of the details for all the packet filters during the lifetime of the EPS bearer.

In this example, the last TFT "Add packet filters to existing TFT" operation which is sent in the Modify EPS bearer context request has the same packet precedence value with the existing packet filter #5. Therefore, the UE responds with the ESM cause = "semantic error in the TFT operation" in the Modify EPS bearer context reject.

NOTE The UE seems to have a glitch sending the wrong ESM cause in this test case. The duplicated packet precedence value will lead to the ESM cause of "Syntactical errors in packet filter(s)" according to the 3GPP TS24.301.

Red Mouse

VoLTE: Bearer binding and Session binding

The LTE supports the PCC(Policy and Charging Control) architecture for QoS control applied to service data flow. In the PCC architecture, the PCRF(Policy and Charging Rules Function) takes the role of a central network component interacting with P-CSCF, SPR(Subscription Profile Repository) and the EPC. The PCRF is always involved in the activities of EPS bearer creation by generating the PCC(Policy and Charging Control) rules and provisioning them to PDN GW(i.e., PCEF). In order to generate PCC rules, the PCRF needs to gather service data flow information from the P-CSCF and possibly the subscription information from the SPR. As the PCC rule shall be applied from the access network to the EPC core with consistency, the PCRF needs to be able to maintain the relations of different sessions over different interfaces across the IP-CAN, EPS bearer and applications, in which the binding mechanism becomes a basic concept.

NOTE In this article, it is assumed that the S5 between the SGW(Serving GW) and PGW(PDN GW) is using GTP, where the PGW becomes the end point of the GTP tunnel.


I. Session binding

The session binding is an association of the AF session information to one and only one IP-CAN session [TS23.203]. Th AF(Application Focus) session is defined as a service level session such as IMS service session that is established by the application level signaling protocol offered by the AF that requires a session-setup with explicit session description before the use of the service[TS29.214].

The IP-CAN session information is obtained by the PCRF during the UE initial attach procedure.
When the UE performs the initial attach to the LTE network, the PGW triggers the CCR-I towards the PCRF. The CCR-I contains the IP-CAN related AVPs such as Framed-IP-Address, IP-CAN-Type, RAT-Type, Called-Station-Id, AN-GW-Address. The following is an example of CCR-I captured over Gx.

• Framed-IP-Address: The valid routable IPv4 address that is applicable for the IP Flows towards the UE at the PCEF. The PCRF shall use this address to identify the correct IP-CAN session binding[TS29.214].
• Freamed-IPv6-Prefix: A valid full IPv6 address that is applicable to an IP flow or IP flows towards the UE at the PCEF. The PCRF shall use this address to identify the correct IP-CAN session binding[RFC4005,RFC3162].
• IP-CAN-Type: Type of Connectivity Access Network in which the user is connected[TS29.212]. 
• RAT-Type: The Radio Access Technology that is currently serving the UE[TS29.212].
• Called-Station-Id: APN [TS29.212].

The service data flow information is obtained while the service session is set up. Upon UE request for VoLTE call setup, the SIP INVITE is delivered to the P-CSCF(i.e., AF) with an SDP offer. The SDP offer includes media session information such as 5-tuples(source ip address, destination ip address, source port, destination port and protocol), codec information, etc. Upon receiving the SIP INVITE, the P-CSCF interprets the received SDP contents into diameter AVPs and triggers the AAR towards the PCRF. The following shows an example of SDP contents included in the SIP INVITE.

NOTE It would be possible for the P-CSCF to trigger AAR once when the 183 Session In Progress is received(SDP answer) in order to reduce diameter traffic.

The following is an example of diameter AAR over Rx which includes the service data flow information.

• Media-Sub-Component: contains the requested bitrate and filters for the set of IP flows identified by their common Flow-Identifier[TS29.212].
• Flow-Description: defines a packet filter for an IP flow with the following information[TS29.212].
• Flow-Status: describes whether the IP flow(s) are enabled or disabled[TS29.214].
• Max-Requested-Bandwidth-UL/DL: Indicates the maximum requested bandwidth in bits per second for an uplink/downlink IP flow[TS29.214].
• RS-Bandwidth: indicates the maximum required bandwidth in bits per second for RTCP sender reports within the session component[TS29.214].
• Codec-Data: contain codec related information known at the AF[TS29.214].

Upon receiving the AAR, the PCRF binds the service data flow information received from the P-CSCF to a specific IP-CAN session received from the PGW.


II. Bearer Binding

The bearer binding is the association of the PCC rule and the QoS rule (if applicable) to an IP-CAN bearer within that IP-CAN[TS23.203]. Upon user's request for voice call, the SIP signals will flow through the EPS bearer of QCI=5 and there will be additional EPS bearer newly established to transfer voice traffic. In the same way as described in the previous section, the PCC rules are generated and provisioned to the PGW by the PCRF. The PGW enforces PCC rules accordingly by performing gating control over service data flow.

The PCC rule contains various parameters that can be used to control service data flow such as Flow-Information, Flow-Status, QoS, etc. The following snapshot shows an example of PCC rule contained in the diameter RAR over Gx for voice traffic.

Upon receiving the RAR, the PGW triggers the EPS bearer creation procedure by sending the Create Bearer Request to the MME. The Create Bearer Request contains the TEID for GTP-U created by the PGW and QoS parameters(QCI, MBR, GMBR) as well. In return, the corresponding response from the MME, Create Bearer Response, contains the allocated EBI(EPS Bearer ID) and the TEID for GTP-U created by the eNB. As an end point of the GTP Tunnel, the PGW shall maintain the relations between EPS bearers and PCC rules. The following is an example of Create Bearer Response captured over GTPv2.

***

The session binding and the bearer binding are basic concepts to understand how different type of sessions are related with each other over different interfaces within the PCC architecture. The IP-CAN session to which the UE is attached is bound with the AF session by the PCRF and the service data flow for that AF session is used to generate the PCC rules. These PCC rules are used to map the specific service data flow to a certain EPS bearer which belongs to that IP-CAN session.

Thanks to this binding relations, one event at one place makes a ripple effect to the other, thereby the LTE core can maintain the consistent status for the same UE. If the UE releases an AF session, the corresponding PCC rules for the service data flow belonging to that AF session are removed and in turn, the EPS bearer for that PCC rules will also be released. If the UE detaches from the network, the IP-CAN session will be released and in turn, all the AF session and EPS bearers belonging to the same IP-CAN will also be released.

Red Mouse

VoLTE: QCI=1 setup failure when S1 handover is in progress

In a mobile environment, by its nature, the handover may occur while the user is engaged in a VoLTE call session. The UE periodically reports measurements of various parameters to the eNB and the eNB determines whether the handover is required. Once it is determined by the eNB to trigger the handover, the eNB will decide whether to perform X2 handover or the S1 handover. When there is an existing X2AP connection towards the target eNB, the source eNB performs X2 handover. If there is no X2AP connection or the X2 handover attempt has failed for some reasons, the source eNB may trigger the S1 handover.

As to the PGW initiated bearer related requests(e.g., Create/Update/Delete Bearer request) there is no cause-id defined in the 3GPP TS29.274(r8),  Therefore, in this case, the MME may reject the request with the cause-id of reason unspecified. This cause-id will lead to the ripple effect towards the upstream forcing each node on the path to release the corresponding resources. This is shown in the following flow diagram.

Even though the handover is successful in this flow, the error cause of RESOURCE ALLOCATION FAILURE in the CCR over Gx will lead to the PCRF to send RAR(Re-Authentication Request) or ASR(Abort-Session-Request) over Rx with a cause-id of RESOURCE NOT AVAILABLE, and the process will end up with sending the 503 Service Unavailable by the P-CSCF. Upon receiving the 503 Service Unavailable, the UE releases all the resources for the call.

In a circumstance where the eNB is not optimized, the handover might occur relatively often. If this racing condition is not handled properly, the result will lead to bad user experiences for VoLTE as the rejection of the bearer related request may often lead to the VoLTE setup failure for QCI=1 bearer for voice.

In the 3GPP TS29.274(r9), the 3GPP has specified the proper cause value of "Temporarily rejected due to handover in progress" and in the 3GPP TS29.274(r11), "Temporarily rejected due to handover/TAU/RAU procedure in progress". This cause-id value is used by the MME rejecting the bearer related request when the handover results in the relocation of the Serving GW and/or MME. The PDN GW which initiated the bearer related request will be able to consider this error cause value to handle the rejection. 

The following flow shows one example of how to handle the rejected bearer related request. In this flow, the Create Bearer Request is rejected by the MME. The PDN GW may retry the Create Bearer Request based on the operator's policy. 

If there is no need of relocation of MME and/or Serving GW, the MME does not need to respond with the cause-id, rather it can perform store-and-forward way of message handling. In this case, the MME will temporarily store the message and wait for the handover to be completed and if it's done soon enough, the Create Bearer Request can be sent to the UE via the target eNB. How 'soon' is the 'soon enough' time is usually up to the operator's policy.

Red Mouse

VoLTE: End to end QoS control

The end to end QoS control is an important factor to be considered to provide a qualified service to users. It would become more so when the service is required to be provided in real time such as voice call or multimedia streaming.  If the voice call service is provided through the best-effort network where the QoS is not guaranteed, the users will experience frequent call attempt failure, call setup delay, call drop, voice cracking, etc. 

In the following are introduced several different level of QoS control methodologies for VoLTE service.

I. Separated APN for VoLTE

The UE can attach multiple PDNs at the same time and each PDN connection can have multiple EPS bearers. Each PDN connectivity has one default EPS bearer and can have multiple dedicated EPS bearers up to 11 in total. The UE is assigned with a different IP address for each APN by the P-GW during PDN connectivity procedure for each APN.

In general, the operator uses an IMS APN separately from the Internet APN. This dedicated APN for VoLTE service may have the intention to provide the quality of VoLTE service not to be affected by other non-real time service such as the internet service. The default APN is provided by the network based on subscriber profile fetched from the HSS during the initial attach procedure. 

The following diagram shows a call flow of initial attach procedure. During the initial attach procedure, the MME obtains the APN list from the HSS in the Location Update Answer message as a part of subscriber's profile. The MME determines the default APN based on the received APN list and parameters, creates the GTP-C session with the corresponding S-GW/P-GW. Once the GTP-C session is created successfully, the default APN information is delivered to the UE in the Attach Accept message. If the default APN is pre-configured in the UE, the same should also be the part of the subscriber profile stored in HSS in order to avoid the conflict which leads to the attach failure. If the default APN is not an IMS APN, the UE has to trigger additional PDN Connectivity with its APN parameter set to "IMS".

NOTE the EPS bearer creation procedure is not shown in this diagram. 

The following shows an example of the Location Update Answer message from the HSS which contains the APN list for the subscriber. Each APN-Configuration AVP under the APN-Configuration-Profile AVP contains the APN information. The Context-Identifier AVP which is one of sub AVPs of the APN-Configuration-Profile AVP is used to determine the defalut APN. Whereas, the same AVP under the Configuration-Profile AVP indicates the context identifier for respective APNs. Given this, the APN whose own Context-Identifier is matched with the upper level Context-Identifier will become the defualt APN. 

In this example, there are three APNs in total and the "IMS" APN will be selected as a default APN of which Context-Identifier(=10) has the same value as upper level Context-Identifier.

II. PCC(Policy and Charging Control) rules

When the PDN connection is established with the IMS APN, the EPC and the PCRF creates the EPS bearer of QCI=5 for IMS signaling. Since then, all the SIP signaling in VoLTE goes through this EPS bearer of QCI=5. Subsequently, when the user requests a VoLTE call setup and the media information is exchanged end to end, the EPC and the UE creates dedicated EPS bearer(e.g., QCI=1 for Voice, QCI=2 for Video, etc) to transfer media traffic. 

The PCC architecture consists of P-CSCF(i.e., AF), PCRF, P-GW(i.e., PCEF) and S-GW(i.e., BBERRF). All of these components are involved in delivering the service data flow to the right EPS bearer with the right QoS conditions. The PCC rules generated or assigned by the PCRF define the mapping relations between the QoS paramemters and the service data flows. Upon receiving a VoLTE request(i.e., SIP INVITE with SDP offer), the P-CSCF extracts the 5-tuples of media information(i.e., source ip address, destination ip address, source port, destination port, protocol), codec profile, etc. The P-CSCF interworks these service data flow information to the PCRF and the PCRF either dynamically generates the corresponding PCC rules or assigns the predefined PCC rule. The PCC rules are provisioned to the P-GW. As its logical name suggests(i.e., PCEF), the P-GW performs gating control for the uplink/downlink traffic based on the given PCC rules. After successful PCC provisioning, the P-GW initiates the dedicated EPS bearer creation via the S-GW towards the eNB. 



The following example shows the PCC rule information in the RAR(Re-Authenticate Request) over Gx. In this case, there are two Charging-Rule-Definition AVPs defined each for RTP and RTCP respectively. The Charging-Rule-Definition AVP contains various information that is required for service data control such as PCC rule name(i.e., Charging-Rule-Name AVP), 5-tuple for each direction(i.e., Flow-Information AVP), QoS parameters(i.e., QoS-Information AVP), etc. The QOS parameters includes the QCI, GBR(UL/DL), AMBR(UL/DL), ARP, etc.

• QCI(CoS Class Index): A level of QoS classified based on the required quality per service usages.
• GBR(Guaranteed Bit Rate) : The minimum bit rate to be guaranteed for the given bearer. A certain amount of bandwidth will be reserved for this bearer. The GBR bearer always takes up resources over the radio link, even if no traffic is sent.
• AMBR(Aggregated Maximum Bit Rate) : The total bit rate that is allowed to be used for all non-GBR bearers associated with a specific APN/UE.
• ARP(Allocation and Retention Priority) : Being used to indicate a priority for the allocation and retention of bearers. It’s typically used to decide whether a bearer establishment or modification can be accepted or needs to be rejected due to resource limitations..

III. DSCP(Differentiated Services Code Point) marking

The DSCP marking is an IP level QoS control for each IP packet to flow through the backhaul with a certain priority and the appropriate latency. As the IP packets from different PDN with different QCI values will be mixed inside the backhaul(e.g., VoLTE, internet), the DSCP marking at IP layer would be an important factor to be considered by switches and routers to guarantee the quality service for VoLTE. Without DSCP marking, IP packets can be delayed or dropped significantly when there is a burst of IP traffic at the same time within the IP network.

The DSCP marking shall be done by both end points of the backhaul for both uplink and downlink IP packets based on the QCI of the service traffic. The following shows a recommended DSCP mapping relations between the QCI and the DSCP values as specified in GSMA IR.34 "Inter-Service Provider IP backbone guidelines". For instance, the IP packets with QCI=1 and 2 for voice and video respectively is marked with the 2E, whereas the IP packets with QCI=5 for IMS signaling will be marked as 1A.

NOTE the DSCP-QCI mapping relation is a part of operator's policy. All the switches and routers aware of DSCP values needs to adjust itself to the correct behavior according to the agreed DSCP values as to handling the IP packets.

The following shows an example of DSCP marking in the IP packet. In this example, the IP packet has been used to deliver the SIP INVITE and the IPv4 packet is wrapped by the IPv6 header at P-GW/S-GW. The 6-bit DS field in this IPv6 header is set to "2e"(i.e.,the Expedited Forwarding). This is a different value from the one specified in the above case 

Red Mouse