Content for TR 38.835 Word version: 18.0.1

1… 4… 5… 6 A B… B.1.2 B.1.3 B.1.4 B.1.5 B.1.6 B.1.7 B.1.8 B.1.9 B.1.10 B.2… B.2.2 B.2.3 B.2.4 B.2.5 B.2.6 B.2.7 B.2.8 B.2.9 B.2.10 B.2.11 B.2.12 B.2.13 B.2.14 B.2.15 B.2.16 B.2.17 B.2.18 C…

C.1 RAN2#119-e C.2 RAN2#119bis-e C.3 RAN2#120 C.4 RAN2#121

C RAN2 Study Item Agreements p. 119

C.1 RAN2#119-e p. 119

Agreements from RAN2#119-e meeting:

RAN2 does not intend to ask RAN1 to change their simulation assumptions.
RAN2 should take SA2/SA4 work into account.
RAN2 assumes that PDU Set based parameters and PDU Set related information may be used for better support of XR services. RAN2 can consider both UL and DL directions.
RAN2 will study PDU Set based parameters and PDU Set related information handling in Network and UE.
RAN2 to adopt the current SA2 definition of PDU Set as an application media unit as working assumption, subjected to further guidance from SA2 and SA4.
XR awareness discussion in RAN2 should consider PDU set characteristics and how to use the information available on those (for UL and/or DL). Can also consider how to handle data bursts.
RAN2 can study e.g. periodicity, arrival time, jitter and frame-size variations for XR awareness to enable power savings and capacity enhancements. Can study also how often such parameters change (i.e. how dynamic they are).
RAN2 can consider how PDU sets can be mapped to DRBs (FFS if SA2 discussion on PDU set mapping to QoS (sub-)flows impacts this).
RAN2 to focus on the following issues for power saving, as well necessary parameters XR-awareness to support such enhancements, i.e.:
- DRX enhancements to address the issues of DRX cycle mismatch and jitter;
- Identify necessary parameters from CN for XR-awareness for power saving.
Enhancements to Rel-17 PDCCH adaptation can be discussed based on RAN1 feedback, if they have any RAN2 impact.
RAN2-specific aspects can be studied based on contributions (e.g. multiple XR traffic flows with different periodicities, SFN wrap-around, RAN2-specific CDRX aspects, …).
As starting point, RAN2 can further discuss the solutions in TR 38.838 that can impact on L2 operation (e.g., BSR, LCP, assistance information for scheduling, packet discarding, prioritization) for XR-specific capacity improvement. RAN2-specific solutions are not precluded (even if RAN1 hasn't discussed them before).
Enhancement to SPS/CG should be justified for XR scheduling and should be evaluated against dynamic grant (DG) scheduling which should be considered as baseline. Should justify why enhancements are needed.
RAN2 considers SPS enhancements may not be needed in Rel-18 XR since PDCCH capacity is not assumed to be a problem for XR. FFS if SPS has some power consumption benefits.

C.2 RAN2#119bis-e p. 119

Agreements from RAN2#119bis-e meeting:

From RAN2 viewpoint, the following information would be useful for PDU set handling in UL and DL:
- Semi-static information (from CN to RAN): At least PSER and PSDB;
- Dynamic information: At least identifying which PDU belongs to which data burst/PDU set is also needed, including means to determine at least PDU set boundaries.
Capture the models 1a/b, 2a/b (from R2-2209777) in TR and indicate what is possible in current specifications and how. FFS how LCH options work in each case.
SDAP maps each data packet in a PDU set to a single PDCP SDU, as in legacy (i.e. each PDU is only mapped to a single SDU).
HARQ and RLC re-/transmissions for XR traffic are done as in legacy (i.e. they are not based on XR PDU sets).
For UE transmitter, the PDCP discard should be performed per PDU set basis.
For UE transmitter, the PDCP discard is managed per SDU for PDU set, the PDCP entity discards all PDCP SDUs associated with the PDU set.
At least RRC pre-configuration and switching of configurations of DRX could be considered for enhancements of XR power saving. Other solutions are not precluded and can be further discussed.
Introduce new BS table(s) to reduce the quantisation errors (e.g. for high bit rates). FFS how new BSR tables are created and how they impact BSR formats (can be discussed in WI phase).
Delay information consists of at least "remaining time".
RAN2 considers a delay information is useful for XR. FFS if dynamic reporting from UE to network (e.g. via BSR) is needed, or whether PSDB is sufficient. If we have delay information, it needs to distinguish how much data is buffered for which delay value. Stage-3 details (e.g. what's contained, how the triggering is done) can be discussed in the WI phase.
If we have delay information reporting, RAN2 aims to define how the UE determines the "remaining time" in the delay information.
Current CG configurations can be reused for UL XR traffic. FFS if enhancements are needed (RAN1 is already discussing something). RAN2 can discuss this in the next meeting.
RAN2 can discuss potential enhancement to provide some assistant information on UL XR traffic for CG configurations at the gNB. FFS whether TSCAI can already provide all necessary information.
RAN2 discuss whether additional traffic or QoS related information on downlink traffic beyond what has been agreed by SA2 needs to be provided to RAN for UE power savings.
RAN2 study what traffic and QoS related information on uplink traffic (e.g. counterpart of what has been agreed by SA2) should be provided to RAN for UE power savings and how the information may be provided to RAN.
Capture in TR that traffic parameters and Jitter are semi-static info.
Can capture also SA2 agreements related to how they impact RAN2.

C.3 RAN2#120 p. 120

Agreements from RAN2#120 meeting:

N1N excluded.
Splitting DRB into multiple LCH (DC like) FFS.
Should try to understand why we would need to treat PDU sets differently over the radio and why different PDU sets are muxed over same flows. Also need to understand need for reordering. LS to SA2/SA4 sent in R2-2213351.
Agree that UE identifies PDU Sets / Bursts.
In-band marking not needed. Further information considered if BSR is not enough.
Handling of discard FFS.
Regarding making LCP delay aware:
- If delay-aware LCP is introduced, need the ability to turn it off;
- SRBs not impacted.
- Not considered further unless fundamental issues are identified.
RAN2 to support timer-based discarding of UL transmit side of PDCP PDU/SDUs of a PDU set. FFS how this is modelled in PDCP specification, can be discussed in WI phase.
RAN2 aims to allow XR frame rates that correspond to non-integer periodicities in at least semi-static manner (e.g. RRC). Details can be left to WI phase.
RAN2 thinks we need one or more additional BSR table(s) for XR. FFS whether these are static (=specified) or dynamic (e.g. generated, differs according to some RRC parameter), can be discussed in WI phase.
RAN2 will introduce data volume information associated with delay information (e.g. remaining time) in a MAC CE. FFS if this is extension of BSR or new format. FFS how to do that (e.g. what exactly is reported) and how to ensure this information is up-to-date e.g. considering UL scheduling delay.
RAN2 needs to discuss additional BSR triggering conditions to allow timely availability of buffer status information at gNB. This can be discussed in WI phase.
RAN2 sees some benefit from CG to XR services. RAN2 will address enhancements triggered by RAN1 work.
RAN2 agrees some assistance information can be beneficial (e.g. periodicity, packet size). RAN2 assumes baseline could be TSCAI (pending SA2 conclusions), can discuss during WI phase whether something additional is needed on top of that. If any assistance information is needed, its definition should be standardized.
RAN2 thinks all information may not be always available at UE application.

C.4 RAN2#121 p. 121

Agreements from RAN2#121 meeting: