Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.203  Word version:  17.2.0

Top   Top   Up   Prev   Next
0…   4…   5…   6…   6.1.4…   6.1.7…   6.1.10…   6.1.17…   6.2…   6.2.2…   6.2.3…   6.3   6.4…   6.8…   7…   7.3…   7.4…   7.7…   7.7.3…   7.8…   A…   A.4…   D…   P…   P.4.2.4…   P.7…   P.7.5…   P.8   Q…   S…   S.7…   S.8.8   T…

 

6.1.7  Standardized QoS characteristicsp. 50

6.1.7.1  General |R8|p. 50

The service level (i.e., per SDF or per SDF aggregate) QoS parameters are QCI, ARP, GBR, and MBR.
Each Service Data Flow (SDF) is associated with one and only one QoS Class Identifier (QCI). For the same IP-CAN session multiple SDFs with the same QCI and ARP can be treated as a single traffic aggregate which is referred to as an SDF aggregate. An SDF is a special case of an SDF aggregate. The QCI is scalar that is used as a reference to node specific parameters that control packet forwarding treatment (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.) and that have been pre-configured by the operator owning the node (e.g. eNodeB). When required by operator policy, the eNodeB can be configured to also use the ARP priority level in addition to the QCI to control the packet forwarding treatment in the eNodeB for SDFs having high priority ARPs.
Up

6.1.7.2  Standardized QCI characteristics |R8|p. 50

This clause specifies standardized characteristics associated with standardized QCI values. The characteristics describe the packet forwarding treatment that an SDF aggregate receives edge-to-edge between the UE and the PCEF (see Figure 6.1.7-1) in terms of the following performance characteristics:
  1. Resource Type (GBR or Non-GBR);
  2. Priority;
  3. Packet Delay Budget;
  4. Packet Error Loss Rate;
  5. Maximum Data Burst Volume (for some GBR QCIs);
  6. Data Rate Averaging Window (for some GBR QCIs).
Copy of original 3GPP image for 3GPP TS 23.203, Fig. 6.1.7-1: Scope of the Standardized QCI characteristics for client/server (upper figure) and peer/peer (lower figure) communication
Up
The standardized characteristics are not signalled on any interface. They should be understood as guidelines for the pre-configuration of node specific parameters for each QCI. The goal of standardizing a QCI with corresponding characteristics is to ensure that applications / services mapped to that QCI receive the same minimum level of QoS in multi-vendor network deployments and in case of roaming. A standardized QCI and corresponding characteristics is independent of the UE's current access (3GPP or Non-3GPP).
The one-to-one mapping of standardized QCI values to standardized characteristics is captured in Table 6.1.7-A and Table 6.1.7-B. The main differences between the two parts are that, in contrast to Part A, Part B of Table 6.1.7 describes QCIs for which the Packet Error Loss Rate calculation includes those packets that are not delivered within the Packet Delay Budget; and, it provides additional information on the Data Rate Averaging Window as well as the Maximum Data Burst Volume that needs to be delivered within the Packet Delay Budget.
QCI Resource Type Priority Level Packet Delay Budget
(13)
Packet Error Loss Rate
(2)
Example Services
1
(3)
GBR2100 ms
(3,11)
10-2Conversational Voice
2
(3)
4150 ms
(1,11)
10-3Conversational Video (Live Streaming)
3
(3,14)
350 ms
(1,11)
10-3Real Time Gaming, V2X messages
Electricity distribution - medium voltage (e.g. TS 22.261, clause 7.2.2)
Process automation - monitoring (e.g. TS 22.261, clause 7.2.2)
4
(3)
5300 ms
(1,11)
10-6Non-Conversational Video (Buffered Streaming)
65
(3,9,12)
0.775 ms
(7,8)
10-2Mission Critical user plane Push To Talk voice (e.g., MCPTT)
66
(3,12)
2100 ms
(1,10)
10-2Non-Mission-Critical user plane Push To Talk voice
67
(3,12)
1.5100 ms
(1,10)
10-3Mission Critical Video user plane
75
(14)
2.550 ms
(1)
10-2V2X messages
715.6150ms
(1,16)
10-6 "Live" Uplink Streaming (e.g. TS 26.238)
725.6300ms
(1,16)
10-4 "Live" Uplink Streaming (e.g. TS 26.238)
735.6300ms
(1,16)
10-8 "Live" Uplink Streaming (e.g. TS 26.238)
745.6500ms
(1,16)
10-8 "Live" Uplink Streaming (e.g. TS 26.238)
765.6500ms
(1,16)
10-4 "Live" Uplink Streaming (e.g. TS 26.238)
5
(3)
Non-GBR1100 ms
(1,10)
10-6IMS Signalling
6
(4)
6300 ms
(1,10)
10-6Video (Buffered Streaming)
TCP-based (e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)
7
(3)
7100 ms
(1,10)
10-3Voice,
Video (Live Streaming)
Interactive Gaming
8
(5)
8300 ms
(1)
10-6Video (Buffered Streaming)
TCP-based (e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)
9
(6)
9
1091100 ms
(1,17)
10-6Video (Buffered Streaming)
TCP-based (e.g. www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.) and any service that can be used over satellite access with these characteristics
69
(3,9,12)
0.560 ms
(7,8)
10-6Mission Critical delay sensitive signalling (e.g., MC-PTT signalling, MC Video signalling)
70
(4,12)
5.5200 ms
(7,10)
10-6Mission Critical Data (e.g. example services are the same as QCI 6/8/9)
79
(14)
6.550 ms
(1,10)
10-2V2X messages
80
(3)
6.810 ms
(10,15)
10-6Low latency eMBB applications (TCP/UDP-based);
Augmented Reality
NOTE 1:
A delay of 20 ms for the delay between a PCEF and a radio base station should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface. This delay is the average between the case where the PCEF is located "close" to the radio base station (roughly 10 ms) and the case where the PCEF is located "far" from the radio base station, e.g. in case of roaming with home routed traffic (the one-way packet delay between Europe and the US west coast is roughly 50 ms). The average takes into account that roaming is a less typical scenario. It is expected that subtracting this average delay of 20 ms from a given PDB will lead to desired end-to-end performance in most typical cases. Also, note that the PDB defines an upper bound. Actual packet delays - in particular for GBR traffic - should typically be lower than the PDB specified for a QCI as long as the UE has sufficient radio channel quality.
NOTE 2:
The rate of non congestion related packet losses that may occur between a radio base station and a PCEF should be regarded to be negligible. A PELR value specified for a standardized QCI therefore applies completely to the radio interface between a UE and radio base station.
NOTE 3:
This QCI is typically associated with an operator controlled service, i.e., a service where the SDF aggregate's uplink / downlink packet filters are known at the point in time when the SDF aggregate is authorized. In case of E-UTRAN this is the point in time when a corresponding dedicated EPS bearer is established / modified.
NOTE 4:
If the network supports Multimedia Priority Services (MPS) then this QCI could be used for the prioritization of non real-time data (i.e. most typically TCP-based services/applications) of MPS subscribers.
NOTE 5:
This QCI could be used for a dedicated "premium bearer" (e.g. associated with premium content) for any subscriber / subscriber group. Also in this case, the SDF aggregate's uplink / downlink packet filters are known at the point in time when the SDF aggregate is authorized. Alternatively, this QCI could be used for the default bearer of a UE/PDN for "premium subscribers".
NOTE 6:
This QCI is typically used for the default bearer of a UE/PDN for non privileged subscribers. Note that AMBR can be used as a "tool" to provide subscriber differentiation between subscriber groups connected to the same PDN with the same QCI on the default bearer.
NOTE 7:
For Mission Critical services, it may be assumed that the PCEF is located "close" to the radio base station (roughly 10 ms) and is not normally used in a long distance, home routed roaming situation. Hence delay of 10 ms for the delay between a PCEF and a radio base station should be subtracted from this PDB to derive the packet delay budget that applies to the radio interface.
NOTE 8:
In both RRC Idle and RRC Connected mode, the PDB requirement for these QCIs can be relaxed (but not to a value greater than 320 ms) for the first packet(s) in a downlink data or signalling burst in order to permit reasonable battery saving (DRX) techniques.
NOTE 9:
It is expected that QCI-65 and QCI-69 are used together to provide Mission Critical Push to Talk service (e.g., QCI-5 is not used for signalling for the bearer that utilizes QCI-65 as user plane bearer). It is expected that the amount of traffic per UE will be similar or less compared to the IMS signalling.
NOTE 10:
In both RRC Idle and RRC Connected mode, the PDB requirement for these QCIs can be relaxed for the first packet(s) in a downlink data or signalling burst in order to permit battery saving (DRX) techniques.
NOTE 11:
In RRC Idle mode, the PDB requirement for these QCIs can be relaxed for the first packet(s) in a downlink data or signalling burst in order to permit battery saving (DRX) techniques.
NOTE 12:
This QCI value can only be assigned upon request from the network side. The UE and any application running on the UE is not allowed to request this QCI value.
NOTE 13:
Packet delay budget is not applicable on NB-IoT or when Enhanced Coverage is used for WB-E-UTRAN (see TS 36.300).
NOTE 14:
This QCI could be used for transmission of V2X messages as defined in TS 23.285.
NOTE 15:
A delay of 2 ms for the delay between a PCEF and a radio base station should be subtracted from the given PDB to derive the packet delay budget that applies to the radio interface.
NOTE 16:
For "live" uplink streaming (see TS 26.238), guidelines for PDB values of the different QCIs correspond to the latency configurations defined in TR 26.939. In order to support higher latency reliable streaming services (above 500ms PDB), if different PDB and PELR combinations are needed these configurations will have to use non-standardised QCIs.
NOTE 17:
The worst case one way propagation delay for GEO satellite is expected to be ~270 ms, ~ 21 ms for LEO at 1200 km, and ~13 ms for LEO at 600 km. The UL scheduling delay that needs to be added is also typically a two way propagation delay e.g. ~540 ms for GEO, ~42 ms for LEO at 1200 km, and ~26 ms for LEO at 600 km. Based on that, the access network Packet delay budget is not applicable for QCIs that require access network PDB lower than the sum of these values when the specific types of satellite access are used (see TS 36.300). QCI-10 can accommodate the worst case PDB for GEO satellite type.
QCI Resource Type Priority Level Packet Delay Budget
(B1)
Packet Error Loss Rate
(B2)
Maximum Data Burst Volume
(B1)
Data Rate Averaging Window Example Services
82
(B6)
GBR1.910 ms
(B4)
10-4
(B3)
255 bytes2000 ms Discrete Automation (bullet g in clause 8 of TS 22.278, and TS 22.261, Table 7.2.2-1, "small packets")
83
(B6)
2.210 ms
(B4)
10-4
(B3)
1354 bytes
(B5)
2000 ms Discrete Automation (bullet g in clause 8 of TS 22.278, and TS 22.261, Table 7.2.2-1, "big packets")
84
(B6)
2.430 ms
(B7)
10-5
(B3)
1354 bytes
(B5)
2000 ms Intelligent Transport Systems (bullet h in clause 8 of TS 22.278, and TS 22.261, Table 7.2.2).
85
(B6)
2.15 ms
(B8)
10-5
(B3)
255 bytes2000 ms Electricity Distribution- high voltage (bullet i in clause 8 of TS 22.278, and TS 22.261, Table 7.2.2 and Annex D.4.2).
NOTE B1:
The PDB applies to bursts that are not greater than Maximum Data Burst Volume.
NOTE B2:
This Packet Error Loss Rate includes packets that are not successfully delivered over the access network plus those packets that comply with the Maximum Data Burst Volume and GBR requirements but which are not delivered within the Packet Delay Budget.
NOTE B3:
Data rates above the GBR, or, bursts larger than the Maximum Data Burst Volume, are treated as best effort, and, in order to serve other packets and meet the PELR, this can lead to them being discarded.
NOTE B4:
A delay of 1 ms for the delay between a PCEF and a radio base station should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface.
NOTE B5:
This Maximum Data Burst Volume value is set to 1354 bytes to avoid IP fragmentation on an IPv6 based, IPSec protected GTP tunnel to the eNB (the value is calculated as in Annex C of TS 23.060 and further reduced by 4 bytes to allow for the usage of a GTP-U extension header).
NOTE B6:
This QCI is typically associated with a dedicated EPS bearer.
NOTE B7:
A delay of 5 ms for the delay between a PCEF and a radio base station should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface.
NOTE B8:
A delay of 2 ms for the delay between a PCEF and a radio base station should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface.
The Resource Type determines if dedicated network resources related to a service or bearer level Guaranteed Bit Rate (GBR) value are permanently allocated (e.g. by an admission control function in a radio base station). GBR SDF aggregates are therefore typically authorized "on demand" which requires dynamic policy and charging control. A Non GBR SDF aggregate may be pre-authorized through static policy and charging control.
The Maximum Data Burst Volume, if defined for the QCI (see Table 6.1.7-B), is the amount of data which the RAN is expected to deliver within the part of the Packet Delay Budget allocated to the link between the UE and the radio base station as long as the data is within the GBR requirements. If more data is transmitted from the application, delivery within the Packet Delay Budget cannot be guaranteed for packets exceeding the Maximum Data Burst Volume or GBR requirements.
The Data Rate Averaging Window, if defined for the QCI (see Table 6.1.7-B), is the 'sliding window' duration over which the GBR and MBR for a GBR SDF aggregate shall be calculated (e.g. in the RAN, PDN-GW, and UE).
The Packet Delay Budget (PDB) defines an upper bound for the time that a packet may be delayed between the UE and the PCEF. For a certain QCI the value of the PDB is the same in uplink and downlink. The purpose of the PDB is to support the configuration of scheduling and link layer functions (e.g. the setting of scheduling priority weights and HARQ target operating points). Except for QCIs 82 and 83, the PDB shall be interpreted as a maximum delay with a confidence level of 98 percent. For services using QCI 82 or 83, a packet delayed by more than the PDB is included in the calculation of the PELR if the packet is within the Maximum Data Burst Volume and GBR requirements.
The support for SRVCC requires QCI=1 only be used for IMS speech sessions in accordance to TS 23.216.
Services using a Non-GBR QCI should be prepared to experience congestion related packet drops, and, except for QCI 80, 98 percent of the packets that have not been dropped due to congestion should not experience a delay exceeding the QCI's PDB. This may for example occur during traffic load peaks or when the UE becomes coverage limited. See Annex J for details. Packets that have not been dropped due to congestion may still be subject to non congestion related packet losses (see PELR below). Owing to its low latency objective, services using QCI 80 should anticipate that more than 2 percent of packets might exceed the PDB of QCI 80.
Except for services using QCI 82 or 83 services using a GBR QCI and sending at a rate smaller than or equal to GBR can in general assume that congestion related packet drops will not occur, and 98 percent of the packets shall not experience a delay exceeding the QCI's PDB. Exceptions (e.g. transient link outages) can always occur in a radio access system which may then lead to congestion related packet drops even for services using a GBR QCI and sending at a rate smaller than or equal to GBR. Packets that have not been dropped due to congestion may still be subject to non congestion related packet losses (see PELR below). For services using QCI 82 or 83 a packet which is delayed by more than the PDB but is within the Maximum Data Burst Volume and GBR requirements, is counted as lost when calculating the PELR.
Every QCI (GBR and Non-GBR) is associated with a Priority level (see Table 6.1.7). The lowest Priority level value corresponds to the highest Priority. The Priority levels shall be used to differentiate between SDF aggregates of the same UE, and it shall also be used to differentiate between SDF aggregates from different UEs. Via its QCI an SDF aggregate is associated with a Priority level and a PDB. Scheduling between different SDF aggregates shall primarily be based on the PDB. If the target set by the PDB can no longer be met for one or more SDF aggregate(s) across all UEs that have sufficient radio channel quality then the QCI Priority level shall be used as follows: in this case a scheduler shall meet the PDB of an SDF aggregate on QCI Priority level N in preference to meeting the PDB of SDF aggregates on next QCI Priority level greater than N, until the priority N SDF aggregate's GBR (in case of a GBR SDF aggregate) has been satisfied.
Other aspects related to the treatment of traffic exceeding an SDF aggregate's GBR are out of scope of this specification.
When required by operator policy, the eNodeB can be configured to use the ARP priority level in addition to the QCI priority level to determine the relative priority of the SDFs in meeting the PDB of an SDF aggregate. This configuration applies only for high priority ARPs as defined in clause 6.1.7.3.
The Packet Error Loss Rate (PELR) defines an upper bound for the rate of SDUs (e.g. IP packets) that have been processed by the sender of a link layer protocol (e.g. RLC in E-UTRAN) but that are not successfully delivered by the corresponding receiver to the upper layer (e.g. PDCP in E-UTRAN). Thus, the PELR defines an upper bound for a rate of non congestion related packet losses. The purpose of the PELR is to allow for appropriate link layer protocol configurations (e.g. RLC and HARQ in E-UTRAN). For a certain QCI the value of the PELR is the same in uplink and downlink.
Up

6.1.7.3  Allocation and Retention Priority characteristics |R8|p. 58

The QoS parameter ARP contains information about the priority level, the pre-emption capability and the pre-emption vulnerability. The priority level defines the relative importance of a resource request. This allows deciding whether a bearer establishment or modification request can be accepted or needs to be rejected in case of resource limitations (typically used for admission control of GBR traffic). It can also be used to decide which existing bearers to pre-empt during resource limitations.
The range of the ARP priority level is 1 to 15 with 1 as the highest level of priority. The pre-emption capability information defines whether a service data flow can get resources that were already assigned to another service data flow with a lower priority level. The pre-emption vulnerability information defines whether a service data flow can lose the resources assigned to it in order to admit a service data flow with higher priority level. The pre-emption capability and the pre-emption vulnerability can be either set to 'yes' or 'no'.
The ARP priority levels 1-8 should only be assigned to resources for services that are authorized to receive prioritized treatment within an operator domain (i.e. that are authorized by the serving network). The ARP priority levels 9-15 may be assigned to resources that are authorized by the home network and thus applicable when a UE is roaming.
Up

6.1.8  Termination Action |R8|p. 58

The termination action applies only in case of online charging. The termination action indicates the action, which the PCEF/TDF should perform when no more credit is granted. A packet that matches a PCC rule/ADC rule, indicating a charging key for which no credit has been granted, is subject to a termination action.
The defined termination actions include:
  • Allowing the packets to pass through;
  • Dropping the packets;
  • The PCEF/TDF Default Termination Action;
  • The re-direction of packets to an application server (e.g. defined in the termination action).
The Default Termination Action for all charging keys, for which no more credit is granted and there is no specific termination action shall be pre-configured in the PCEF/TDF according to operator's policy. For instance, the default behaviour may consist of allowing packets of any terminated service to pass through the PCEF/TDF.
The OCS may provide a termination action for each charging key over the Gy interface. Any previously provided termination action may be overwritten by the OCS. A termination action remains valid and shall be applied by the PCEF/TDF until all the corresponding PCC/ADC rules of that charging key are removed or the corresponding IP-CAN bearer is removed (for GPRS the PDP context).
The OCS shall provide the termination action to the PCEF/TDF before denying credit; otherwise the PCEF/TDF default termination action will be performed.
Up

6.1.9  Handling of packet filters provided to the UE by PCEF/BBERF |R8|p. 59

The network shall ensure that the traffic mapping information negotiated with the UE reflects the bearer binding of PCC/QoS rules, except for those extending the inspection beyond what can be signalled to the UE. The PCC/QoS rules may restrict what traffic is allowed compared to what is explicitly negotiated with the UE. The PCRF may, per service data flow filter, indicate that the PCEF/BBERF is required to explicitly signal the corresponding traffic mapping information to the UE, e.g. for the purpose of IMS precondition handling at the UE. In absence of that indication, it is a PCEF/BBERF decision whether to signal the traffic mapping information that is redundant from a traffic mapping point of view.
The traffic mapping information (e.g. TFT filters for GPRS and EPS) that the network provides to the UE shall include the same content as the corresponding SDF filters in the SDF template received over the Gx/Gxx interface. The representation/format of the packet filters provided by the network to the UE is access-system dependent and may vary between accesses and may also be different from the representation/format of the SDF filters in the SDF template on the Gx/Gxx interface.
In case traffic mapping information is required for a dedicated bearer and in the PCC/QoS rules corresponding to the bearer there is no SDF filter for the uplink direction having an indication to signal corresponding traffic mapping information to the UE, the PCEF/BBERF derives traffic mapping information based on implementation specific logic (e.g. traffic mapping information that effectively disallows any useful packet flows in uplink direction as described in clause 15.3.3.4 of TS 23.060) and provides it to the UE.
Up

Up   Top   ToC