XR Enhancements - Release 18 and 19

XR (eXtended Reality) covers VR, AR and cloud gaming. For the radio network it is a difficult kind of traffic. A headset sends and receives video frames at a fixed rate, each frame is large, and each frame has to arrive within a tight delay. A frame that arrives late is as useless as a frame that never arrives. Release 15 NR handles high data rate and low latency separately, but XR needs both at once, for many UEs, on a battery.

Release 18 added a set of XR enhancements across the stack, and Release 19 extended them. Most of them follow one idea: tell the RAN what the application data looks like, so it can schedule, sleep and discard in units the application cares about. This page goes through them in that order: XR awareness, DRX, uplink capacity, buffer and delay reporting, discard, and the Release 19 additions. The XR related QoS background is in the QoS page.

• Why is XR traffic difficult ?
• XR awareness - PDU Sets and data bursts
• DRX for XR traffic
• Configured grant with several PUSCHs
• Buffer and delay reporting - refined BSR and DSR
• PDU Set based discard
• Release 19 additions
• Reference

Why is XR traffic difficult ?

What makes XR traffic different from a video stream on a phone ? A phone can buffer several seconds of video, so late packets are hidden by the player. A headset cannot. The picture must follow the head movement, so each frame has a delay budget measured in milliseconds, not seconds. The traffic is also strongly periodic. A frame is generated every 1/fps seconds, and it arrives at the gNB as a burst of many packets.

Three properties cause most of the trouble. The first is the period. Common frame rates such as 60 or 90 fps give periods of 16.66 ms or 11.11 ms, which are not integers. Release 15 timers and periodicities are in integer milliseconds or slots, so a DRX cycle or a CG period drifts against the traffic. The second is jitter. The frame does not arrive exactly every period, because encoding and the core network add a variable delay. The third is the size. One frame can be tens of kilobytes or more, so it does not fit in one transmission, and its size varies from frame to frame.

• Periodic, but not integer: 38.300 lists 15, 30, 45, 60, 72, 90 and 120 fps, with periods 66.66, 33.33, 22.22, 16.66, 13.88, 11.11 and 8.33 ms.
• Jitter: the arrival time varies around the nominal period, so the gNB cannot plan the burst to the slot.
• Large, variable bursts: a frame is many IP packets, and losing one of them can make the whole frame useless.
• Power: a headset or glasses has a small battery, so the UE should sleep between frames.

XR awareness - PDU Sets and data bursts

Before Release 18, the RAN saw only a stream of independent packets in a QoS flow. It had no idea that 40 packets together form one video frame, or that the frame is useless if one of them is lost. Release 18 gives the RAN this knowledge with two concepts defined in TS 23.501: the PDU Set and the data burst. A PDU Set is one or more PDUs carrying one unit of application information, such as a frame or a video slice. A data burst is a set of PDUs generated and sent in a short period, which can contain one or more PDU Sets.

Figure 1 shows how they relate on the time axis. The 5GC gives the gNB information about both, through the QoS profile, through NGAP and in the GTP-U header of each packet.

Figure 1. PDU Sets inside data bursts. Each burst carries one or more PDU Sets, and a PDU Set is the unit the application needs complete. The bursts repeat with a periodicity that is often not an integer number of milliseconds.

The information comes in three groups. The PDU Set QoS parameters are part of the QoS profile of the flow. The PDU Set Information comes with every packet in the GTP-U header. The traffic assistance information comes with NGAP or GTP-U. 38.300 clause 16.15 lists them as follows.

In the uplink, the UE itself has to identify PDU Sets and data bursts, and how it does that is left to implementation. The UE can tell the gNB what it can identify and what its uplink traffic looks like. It sends this per QoS flow in UEAssistanceInformation, in the Release 18 field ul-TrafficInfo-r18.

Following is based on 38.331 v19.4.0 (Release 19)

UL-TrafficInfo-r18 ::=                SEQUENCE (SIZE (1..maxNrofPDU-Sessions-r17)) OF PDU-SessionUL-TrafficInfo-r18

PDU-SessionUL-TrafficInfo-r18 ::=     SEQUENCE {
    pdu-SessionID-r18                     PDU-SessionID,
    qos-FlowUL-TrafficInfoList-r18        SEQUENCE (SIZE (1..maxNrofQFIs)) OF QOS-FlowUL-TrafficInfo-r18
}

QOS-FlowUL-TrafficInfo-r18 ::=        SEQUENCE {
    qfi-r18                               QFI,
    jitterRange-r18                       SEQUENCE {
        lowerBound-r18                        JitterBound-r18,
        upperBound-r18                        JitterBound-r18
    }                                                                                    OPTIONAL,
    burstArrivalTime-r18                  CHOICE {
        referenceTime                         ReferenceTime-r16,
        referenceSFN-AndSlot                  ReferenceSFN-AndSlot-r18
    }                                                                                    OPTIONAL,
    trafficPeriodicity-r18                INTEGER (1..640000)                            OPTIONAL,
    pdu-SetIdentification-r18             BOOLEAN                                        OPTIONAL,
    psi-Identification-r18                BOOLEAN                                        OPTIONAL,
    ...
}

• jitterRange-r18: lower and upper bound of the arrival jitter, in 0.5 ms steps from 0 to 7 ms, plus beyondMs7.
• burstArrivalTime-r18: when a burst is expected, as an absolute time or as an SFN and slot. At handover, the target can reuse it by taking the SFN offset of the source into account.
• trafficPeriodicity-r18: the uplink burst period.
• pdu-SetIdentification-r18, psi-Identification-r18: whether the UE can identify PDU Sets and their importance for this flow. The uplink discard features later on this page depend on this.

DRX for XR traffic

Why can a normal DRX configuration not follow 60 fps traffic ? The DRX long cycle in Release 15 takes integer values in milliseconds, such as 16 ms or 20 ms. The video period at 60 fps is 16.66 ms. With a 16 ms cycle, the On Duration moves 0.66 ms earlier than the frame every cycle. After about 25 cycles, it has drifted a whole cycle away. The gNB either keeps the UE awake longer to cover the drift, which costs power, or reconfigures DRX regularly, which costs signalling.

Release 18 solves this directly. The DRX cycle can be a rational number of milliseconds. For 60 fps the gNB configures 50/3 ms, which is exactly 16.66... ms, so the On Duration stays aligned with the frames forever. The new cycles are in DRX-ConfigExt2-v1800, and when they are configured the UE ignores the integer drx-LongCycleStartOffset.

Following is based on 38.331 v19.4.0 (Release 19)

DRX-ConfigExt2-v1800 ::=                SEQUENCE {
    drx-NonIntegerLongCycleStartOffset-r18  CHOICE {
        ms1001over240                           INTEGER(0..3),
        ms25over6                               INTEGER(0..3),
        ms25over3                               INTEGER(0..7),
        ms1001over120                           INTEGER(0..7),
        ms100over9                              INTEGER(0..10),
        ms25over2                               INTEGER(0..11),
        ms40over3                               INTEGER(0..12),
        ms125over9                              INTEGER(0..12),
        ms50over3                               INTEGER(0..15),
        ms1001over60                            INTEGER(0..15),
        ms125over6                              INTEGER(0..19),
        ms200over9                              INTEGER(0..21),
        ms250over9                              INTEGER(0..26),
        ms100over3                              INTEGER(0..32),
        ms1001over30                            INTEGER(0..32),
        ms75over2                               INTEGER(0..36),
        ms125over3                              INTEGER(0..40),
        ms1001over24                            INTEGER(0..40),
        ms200over3                              INTEGER(0..65),
        ms1001over15                            INTEGER(0..65),
        ms250over3                              INTEGER(0..82),
        ms1001over12                            INTEGER(0..82),
        ms400over3                              INTEGER(0..132),
        ...
    },
    shortDRX-r18                            SEQUENCE {
        drx-NonIntegerShortCycle-r18            ENUMERATED {ms1001over240, ms25over6, ms25over3, ms1001over120, ms100over9, ms25over2,
                                                            ms40over3, ms125over9, ms50over3, ms1001over60, ms125over6, ms200over9,
                                                            ms100over3, ms1001over30, ms125over3, ms1001over24, ms200over3, spare15,
                                                            spare14, spare13, spare12, spare11, spare10, spare9, spare8, spare7, spare6,
                                                                   spare5, spare4, spare3, spare2, spare1},
        drx-ShortCycleTimer-r18                 INTEGER (1..16)
    }                                                                                                            OPTIONAL,   -- Need R
    drx-TimeReferenceSFN-r18                    ENUMERATED {sfn512}                                              OPTIONAL    -- Need N
}

• Values: the names give the cycle as a fraction in ms. For example, ms50over3 is 16.67 ms for 60 fps, and ms100over9 is 11.11 ms for 90 fps. The value ms1001over60 is 16.68 ms, which matches the 59.94 fps video rate. The integer after each value is the start offset in ms.
• Short DRX: drx-NonIntegerShortCycle-r18 offers a smaller set of the same fractions. The long cycle must be a multiple of it.
• drx-TimeReferenceSFN-r18: sets how the UE initialises DRX_SFN_COUNTER in 38.321 clause 5.7. This counter increments each time the SFN wraps to 0, so the MAC can place a fractional cycle over a longer time than one SFN period of 1024 frames.

One more DRX change targets the uplink. Normally, after a PUSCH on a configured grant, the UE starts drx-HARQ-RTT-TimerUL and then wakes up to monitor for a possible retransmission grant. For XR traffic the next frame often comes before a retransmission would help. With disableCG-RetransmissionMonitoring-r18 in ConfiguredGrantConfig, the UE does not start that timer for CG PUSCHs, and so it gets more sleep opportunities. The general power saving framework is in the Power Saving page.

Configured grant with several PUSCHs

Uplink XR traffic, such as the camera stream of AR glasses or pose and controller data, is also periodic. A configured grant fits periodic traffic well, because the UE needs no scheduling request and no grant. The problem is the size. In Release 15 and 16, one CG period gives one PUSCH occasion for a new transport block. A frame that needs more resources than one PUSCH has to wait for a dynamic grant, and a frame that arrives late because of jitter misses the occasion completely.

Release 18 allows several CG PUSCH occasions in one period. The field nrofSlotsInCG-Period-r18 gives 2 to 32 consecutive slots with a PUSCH occasion each, in every period of one CG configuration. The same start symbol, length and mapping type repeat in each slot. Since the UE might not need all of them, it also tells the gNB which upcoming occasions it will not use, with UTO-UCI (Unused Transmission Occasion UCI). Figure 2 shows the idea.

Figure 2. Several CG PUSCH occasions in one period, with UTO-UCI. The UE gets enough occasions for a large or late frame, and the gNB learns early which ones it can reuse.

Following is based on 38.331 v19.4.0 (Release 19)

disableCG-RetransmissionMonitoring-r18  ENUMERATED {true}                                           OPTIONAL,   -- Need R
    nrofSlotsInCG-Period-r18            INTEGER (2..32)                                                 OPTIONAL,   -- Need R
    uto-UCI-Config-r18                      SEQUENCE {
        nrofBitsInUTO-UCI-r18               INTEGER (3..8),
        betaOffsetUTO-UCI-r18               INTEGER (0..31),
         ...
    }                                                                                                   OPTIONAL    -- Need R

• nrofSlotsInCG-Period-r18: the number of consecutive slots with a CG PUSCH occasion in each period. With this field, the UE does not support repetition or TB processing over multiple slots for that CG, and it is not configured together with cg-nrofSlots and cg-nrofPUSCH-InSlot. It is not used on shared spectrum.
• nrofBitsInUTO-UCI-r18: 3 to 8 bits. Each bit maps to one of the following CG PUSCH occasions in time order. In TDD, occasions that collide with DL symbols or SSBs are skipped in this count (38.213 clause 9.3.1).
• UTO-UCI bit values: 0 means the UE may transmit in that occasion, and 1 means it will not. Once the UE has sent 1 for an occasion, it keeps sending 1 for it, so the gNB can rely on it.
• betaOffsetUTO-UCI-r18: the beta offset for multiplexing UTO-UCI on the CG PUSCH, like the beta offsets for HARQ-ACK and CSI.

Buffer and delay reporting - refined BSR and DSR

A gNB schedules the uplink from what the UE reports. The BSR tells how much data is waiting, but not how urgent it is. For XR this is not enough. Two buffers of 50 kB need very different treatment if one is a frame due in 2 ms and the other is a background upload. Release 18 improves the BSR itself and adds a new report for urgency, the DSR (Delay Status Report).

The BSR improvement is about precision. The 8-bit buffer size table in 38.321 is logarithmic, so at high values each step covers a wide range, and the gNB may grant much more or much less than needed. Release 18 adds a refined table, 38.321 Table 6.1.3.1-3. When additionalBS-TableAllowed-r18 enables it for an LCG, the UE uses the refined table whenever the buffered amount is within its range, and the regular table otherwise. A BT bit per LCG in the report tells the gNB which table was used. The BSR formats are on the MAC CE BSR page.

The DSR is the new part. It is based on the PDCP discard timer. When a PDCP SDU is buffered, its discard timer runs, and the remaining time before discard is exactly how urgent the data is. If the smallest remaining time among the buffered SDUs of a logical channel falls below remainingTimeThreshold-r18 of its LCG, the MAC triggers a DSR. The Single Entry DSR MAC CE then reports, per LCG, the shortest remaining time and the amount of delay-critical data.

Following is based on 38.331 v19.4.0 (Release 19)

    additionalBS-TableAllowed-r18       BIT STRING (SIZE (maxNrofLCGs-r18))                                     OPTIONAL,    -- Need R
    dsr-ConfigToAddModList-r18          SEQUENCE (SIZE (1..maxNrofLCGs-r18)) OF LCG-DSR-Config-r18              OPTIONAL,    -- Need N
    dsr-ConfigToReleaseList-r18         SEQUENCE (SIZE (1..maxNrofLCGs-r18)) OF LCG-Id-r18                      OPTIONAL,    -- Need N

LCG-DSR-Config-r18 ::= SEQUENCE {
    lcg-Id-r18                      LCG-Id-r18,
    remainingTimeThreshold-r18      INTEGER (1..64),
    ...,
    [[
    multiEntryDSR-r19                  SEQUENCE {
        dsr-ReportingThresList-r19          SEQUENCE (SIZE (1.. maxNrOfDSR-ReportingThres-r19)) OF DSR-ReportingThreshold-r19,
        dsr-ReportNonDelayCriticalData-r19  ENUMERATED {enabled}                                        OPTIONAL    -- Need R
    }                                                                                                   OPTIONAL    -- Need R
    ]]
}

• Where it sits: these fields are in the Release 18 extension of MAC-CellGroupConfig, so DSR is configured per cell group and per LCG.
• remainingTimeThreshold-r18: 1 to 64 ms. It triggers the DSR and also defines which data counts as delay-critical in the Single Entry DSR.
• Remaining Time field: the shortest remaining discard timer among the buffered, not yet transmitted SDUs of the LCG, measured at the first symbol of the PUSCH that carries the DSR.
• Refined table in DSR too: the DSR Buffer Size field also has a BT bit and can use the refined table.
• multiEntryDSR-r19: the Release 19 extension, explained in Release 19 additions.

PDU Set based discard

What should a transmitter do when one packet of a frame is already lost ? If the application needs every PDU of the PDU Set, as the PSIHI can say, the rest of that set is useless. Sending it wastes radio resources that the next frame needs. Release 18 therefore allows discarding at the PDU Set level, in both directions. It also lets the network drop less important PDU Sets earlier when the cell is congested.

In the downlink this is gNB implementation, using PSDB, PSI and PSIHI. In the uplink the UE needs configuration, and it comes in the PDCP-Config Release 18 extension. 38.300 adds a warning in a note. With FEC at the application layer, the remaining packets may still be useful, so discarding them is not always right.

Following is based on 38.331 v19.4.0 (Release 19)

pdu-SetDiscard-r18             ENUMERATED {true}                                            OPTIONAL,   -- Need R
    discardTimerForLowImportance-r18   SetupRelease { DiscardTimerForLowImportance-r18 }        OPTIONAL,   -- Cond DRB2
    primaryPathOnIndirectPath-r18  ENUMERATED {true}                                            OPTIONAL,   -- Cond SplitBearerMP
    sn-GapReport-r18               ENUMERATED {true}                                            OPTIONAL    -- Need R

DiscardTimerForLowImportance-r18 ::= ENUMERATED {ms0, ms2, ms4, ms6, ms8, ms10, ms12, ms14, ms18, ms22, ms26, ms30, ms40, ms50, ms75, ms100}

• pdu-SetDiscard-r18: when one PDCP SDU of a PDU Set is discarded because its discard timer expired, the UE discards all other SDUs of the same PDU Set (38.323).
• discardTimerForLowImportance-r18: a shorter discard timer for SDUs of low importance PDU Sets, always shorter than the normal discard timer. At most 8 DRBs can have it. Which PDU Sets are of low importance is up to the UE, and it can use the PSI where available.
• Activated by MAC CE: the short timer applies only after the gNB activates it with the PSI-Based SDU Discard Activation/Deactivation MAC CE (38.321 clause 6.1.3.73), one bit per configured DRB. So the gNB can turn it on during congestion and off again.
• sn-GapReport-r18: discards leave gaps in the PDCP SN. With this field, the UE sends a PDCP control PDU that reports the gap, so the receiver does not wait for SNs that will never arrive. It cannot be used with out-of-order delivery.
• primaryPathOnIndirectPath-r18: not an XR feature. It belongs to multi-path relaying and only shares the extension group.

RLC has a matching Release 18 change. When PDCP discards an SDU, an RLC AM transmitter stops any transmission or retransmission of it. On the receiver side, a missing PDU can be given up after a configured time and acknowledged in a status report, so the transmitter does not keep retransmitting it. The PDCP and RLC entities themselves are described in the PDCP and RLC pages.

Release 19 additions

Release 18 gave the RAN the information and the basic tools. Release 19 refined them, mostly in layer 2. The common theme is the remaining time before discard. Release 18 used it only to trigger a report, and Release 19 uses it to change priorities and retransmissions. The field suffixes in 38.331 v19.4.0 show which items are Release 19.

• Multiple Entry DSR: multiEntryDSR-r19 adds up to 4 remaining-time thresholds per LCG (maxNrOfDSR-ReportingThres-r19). The Multiple Entry DSR MAC CE reports a buffer size for each threshold, so the gNB sees how the buffered data spreads over urgency, not just the most urgent part.
• Logical channel priority adjustment: enhancedLCP-r19 in LogicalChannelConfig, with priorityAdjustmentThreshold-r19 (1 to 64) and additionalPriority-r19 (1 to 16). When the remaining time of a buffered SDU falls below the threshold, the logical channel gets the additional priority in LCP.
• Remaining-time based RLC retransmission and polling: remainingTimeThresholdRLC-ReTx-r19 and remainingTimeThresholdRLC-Polling-r19 in PDCP-Config. When the remaining time of an RLC SDU falls below them, the RLC AM transmitter may trigger a retransmission, or a poll, before it is too late.
• UL rate control: ul-RateControlConfigList-r19 and ul-RateQuery-r19 in MAC-CellGroupConfig. The gNB can recommend an uplink bit rate per QoS flow with the UL Rate Control MAC CE, and the UE can request a preferred one. The application can then adapt its encoder rate quickly during congestion.
• Measurement gap cancellation: a measurement gap occasion can be cancelled by DCI, so XR traffic is not blocked by a gap. The UE can also report a preferred cancellation ratio per gap configuration in UEAssistanceInformation (gapOccasionCancelRatio-r19). The ratio report is Release 19 by its suffix. 38.300 clause 16.15.6 gives no release for the DCI cancellation itself, and this page assumes it is part of the same work.

One more XR item has a different nature. It is about the device, not the traffic. A 2Rx XR UE is a head-worn XR device that has only two receive antenna ports in bands where four are mandatory. The UE capability identifies it, and a cell can bar such UEs or allow them with system information fields such as cellBarred2RxXR-r18. The field suffix says Release 18, while 38.300 clause 16.22 describes it separately from the XR traffic features.

• Release 18 summary: PDU Set awareness, non-integer DRX, CG with several PUSCHs and UTO-UCI, refined BSR table and Single Entry DSR. It also brought PDU Set and PSI based discard, RLC discard alignment and UE uplink traffic assistance.
• Release 19 summary: Multiple Entry DSR, LCP priority adjustment, remaining-time based RLC retransmission and polling, UL rate control, gap cancellation ratio reporting.
• Where to look in a log: DRX-ConfigExt2-v1800 and ConfiguredGrantConfig r18 fields in RRCReconfiguration; MAC-CellGroupConfig for DSR; PDCP-Config for discard; UEAssistanceInformation for ul-TrafficInfo-r18.

The release overviews are in the Release 18 and Release 19 pages, and the UE assistance message in the UE Assistance Information page.

Reference

• 3GPP TS 38.300 V19.4.0 : NR; NR and NG-RAN Overall description; Stage-2. Clause 16.15, eXtended Reality Services, and clause 16.22, 2Rx XR devices
• 3GPP TS 38.331 V19.4.0 : NR; Radio Resource Control (RRC) protocol specification. DRX-Config, ConfiguredGrantConfig, MAC-CellGroupConfig, PDCP-Config, LogicalChannelConfig, UEAssistanceInformation
• 3GPP TS 38.321 V19.4.0 : NR; Medium Access Control (MAC) protocol specification. Clause 5.4.5 (BSR), clause 5.4.9 (DSR), Table 6.1.3.1-3, clauses 6.1.3.72, 6.1.3.73 and 5.18.40
• 3GPP TS 38.213 V19.4.0 : NR; Physical layer procedures for control. Clause 9.3.1, UTO-UCI
• 3GPP TS 38.214 V19.4.0 : NR; Physical layer procedures for data. Clause 6.1.2.3, configured grant
• 3GPP TR 38.835 : NR; Study on XR enhancements for NR
• 3GPP TS 23.501 : System architecture for the 5G System. PDU Set and data burst definitions
• QoS, Power Saving, MAC CE BSR, PDCP, RLC, UE Assistance Information, Release 18, Release 19 (ShareTechnote)