2. 2
Outline
• Use cases and deployment scenarios
• Traffic model
• KPIs and some key aspects of evaluation methodology
• Challenges for NR to support XR: potential enhancements areas
3. 3
XR and Cloud Gaming Use Cases
Cloud Gaming VR Split Rendering AR Split Computation
HMD/Device
5G Smartphone
or Tablet
Head-mounted with 5G modem
attached
HMD with 5G modem attached
HMD with USB/Bluetooth/Wi-Fi/NR SL connection
to “Puck” or Smartphone with 5G modem
Low power (2W) AR glass
Location Indoor/Outdoor
Enterprise-Indoor, Residential-Indoor,
Outdoor
Enterprise-Indoor, Outdoor
Mobility Static, Hi-speed
Limited to head movements and
restricted body movements, Hi-speed
(VR in a train, back of a car)
Pedestrian, Hi-speed
4. 4
XR Split Architecture via 5G
Edge compute input
(camera/sensor and
controller data)
Edge compute output
(video stream)
On-device
computation loops
react to latest
sensor input
Cloud
Computation offload
with 5G’s high capacity and low latency quality of
service
Today’s latency is
unpredictable
Less latency sensitive content
(e.g. recorded streaming
video)
Deeper
in network
On-premise,
e.g. venue
Computation and
Storage
Edge
Uplink XR Traffic
Pose/control: e.g., 0.5-2 Mbps at 60 - 500 Hz
Scene update: e.g., ~10 Mbps at 10 Hz
Time
FileSize
...
Downlink XR Traffic
H.264/265 video: Quasi-Periodic (e.g., 45/60/120fps), High Rate
(e.g., 25-100Mbps), Tight Delay Budget (e.g., 10-25ms in DL/UL)
Time
FileSize
6-9 files per frame
Power-efficient, latency
sensitive on-device
computation
5. 5
2D Media for pre-
rendered viewport
XR Server
5GSDelivery
XR Device
3DOF/6DOF
Tracking and
XR Sensors
5GSDelivery
2D Media
Decoders
XR Viewport
Rendering
(ATW only)
XR Scene
Generation Display
2D Media
Encoding
XR Media
Content
Delivery
XR Media
Content
Delivery
Tracking and Sensor
InformationXR Viewport
Pre-Rendering
Rasterization
XR Split Rendering Architecture Example
6. 6
Topology of AR Glass / Smartphone / Edge
Internet
Internet
Edge/Cloud
Edge/Cloud
AP / gNB
gNBSmartphone
/ “puck”
AR glass
AR glass
5G NR
5G NR
Wifi-D
Internet
Edge/Cloud
AP / gNBSmartphone
/ “puck”
AR glass
5G NRUSB
5G sidelink
Case 1: Standalone HMD
Case 2: Wired Tethering
Case 3: Wireless Tethering
7. 7
3GPP Activities for XR/Edge
3GPP terms
DN: Data Network
AF: Application function
N5, N6, N33: 3GPP Interfaces
RAN
PCF/NEF Edge AF
XR public
cloud
N6
Edge DN
N5/N33
AMF
UPF
N6
App
Edge
Client
UE
SA6 study on Edge apps:
• Edge client to manage
Edge session on behalf
of App
SA2 study on Edge/MEC:
• IP addr discovery
• Service chaining
• Edge mobility
SA1 study/SA2 WI on Network
controlled Interactive Services (NCIS)
• Cloud gaming and XR
requirements
SA4 study on XR5G
• XR use cases and multimedia
architecture
• XR traffic model in R17
RAN: XR evaluations for NR
(R17 SI)
XR enh. SI/WI in R18 (TBD):
Power, Capacity, Mobility,
Coverage
8. 8
RAN R17 XR SI Objectives (RP-193241)
Key performance aspects: Capacity, Power, Mobility, Coverage
Objectives
1. Confirm XR and Cloud Gaming applications of interest
2. Identify the traffic model for each application of interest taking outcome of SA WG4 work as input,
including considering different upper layer assumptions, e.g. rendering latency, codec compression
capability etc.
3. Identify evaluation methodology to assess XR and CG performance along with identification of KPIs of
interest for relevant deployment scenarios
4. Once traffic model and evaluation methodologies are agreed, carry out performance evaluations
towards characterization of identified KPIs
9. 9
System Model and RAN Evaluation
Time
Render
+
Encode
Rendering epoch
(e.g., every 8.3/16.7
ms @ Server)
Downlink Transmission
Decode
+
Async Time Warp
Display epoch @ Client
DL Delay Budget, e.g., 10ms
Motion-To-Render-To-Photon Delay
D D S U D D S U D D S U D D S U D D S U D D S U D D S U D D S U D D S U. . . .
5G NR
Timeline
RAN evaluation: DL
• Exact Traffic model to be provided by SA4 that may be simplified by RAN1 for simultations
Files arrival at gNB
Pose 1
Sampled
Last successfully
received pose before
rendering
Pose 1
Sent
Pose 1
Received
Age of pose
✓
RAN evaluation: UL
+ “Scene upload”
10. 10
Rel-17 RAN1 Evaluation: KPIs & Performance Characterization
Capacity
▪ DL KPI per UE: % of files delivered within delay budget (e.g., 10ms)
▪ UL KPI for pose update per UE: Age of pose (AOP. See the previous slide)
▪ UL KPI for scene upload per UE: % of files delivered within delay budget
▪ DL system capacity: # UEs per cell w/ higher than X (e.g., 99%) percentage of files delivered within a delay budget
▪ UL system capacity: # UEs per cell w/ “Y-th (e.g., 95%) percentile AOP less than Z (e.g., 10) ms” and “higher than U percentage of
scene upload files delivered within a delay budget”
▪ Characterize the capacity performance in terms of different deployment scenarios/system configurations/design options such
as traffic model/config, Uma/Umi/InH, RAN & edge synchronization/cooperation, etc.
UE Power Consumption
▪ KPI: UE power consumption
✓System level evaluation to study various aspects, where Power model in TR 38.840 can be largely reused.
▪ Characterize the power perf. in terms of different deployment scenarios/system configurations/design options such as traffic
model/config, Uma/Umi/InH, C-DRX configurations/enhancements, other Power Saving techniques, etc.
Coverage
▪ Largely reuse evaluation methodology developed under R17 Coverage Enh SI. Contribution driven.
Mobility
▪ At least qualitative study
11. 11
Challenges of XR over NR
Traffic characteristics and requirements
▪ High rates (e.g., 30 – 250 Mbps)
▪ Frequent file arrivals (e.g., 45/60/120 fps)
▪ Variable file size
▪ Jitter (e.g., up to several msec)
▪ Tight file delivery time budget (e.g., 10ms in DL/UL)
▪ Burst interference
Form factor constraints
▪ Smaller form factor → smaller battery size
▪ Battery life requirements for full day use
▪ Thermal constraint
XR CoverageXR MobilityXR UE Power
Consumption
XR Network
Capacity
Z Z Z
→ Making it challenging to better support XR over NR in terms of:
12. 12
Examples of Challenges of XR over NR: Downlink Capacity
Network capacity, esp., for high rate XR, e.g., 100Mbps, suffering from burst inter-cell interference,
jitter, CDRX (i.e., cannot send packets during off-duration → capacity-power trade-off), etc.
(FR1. Simulation assumptions in Appendix)
13. 13
Examples of Challenges of XR over NR: UE Power Consumption
Significant room for UE power saving enhancement
• Minimize unnecessary PDCCH monitoring and jitter effect; enhance CDRX to maximize sleep
duration
~100%
System level assumptions
• UMi (indoor: 80%, outdoor: 20%)
• 3 XR UEs per cell
• System BW: 100 MHz
• 3.5GHz
• # UE Rx ant: 4
• Simultaneous DL & UL simulations
14. 14
XR over NR: Potential Enhancement Areas
Enhanced interference management
Enhanced link adaptation/HARQ feedback
Coordination between RAN and Edge
• RAN report
• Synchronous Edge
• XR rate adaptation
Frame-level QoS (instead of packet)
Enhanced scheduling/resource allocation
Enhanced packet prioritization
C-DRX enhancement
BWP configuration/operation enh.
Efficient jitter handling
DL/UL Tx/Rx alignment
PAPR/MPR reduction
XR capacity enh.
XR UE power
saving enh.
XR mobility enh.
XR coverage enh.
15. 15
Appendix: Simulation Configuration (UMi 200m ISD)
# UEs/cell Randomly chosen N UEs from each cell (results averaged over 5 runs)
BS Antennas
(M, N, Mg, Ng, P)
(8, 16, 1, 1, 2)
with 64 TXRU (4 V elems combined)
BS Antenna spacing dH = 0.5 λ, dV = 0.8 λ
Carrier Frequency 3.5 GHz
Bandwidth Sys BW = 100 MHz
Numerology 30 KHz SCS, 0.5 ms slot
PHY Processing delay
Cap-1 Timeline
N1 = 10 OS, K2 = 1 slot, K3 = 3 slots (CSI delay not modeled)
Sim Duration 1200 Frames
UE ant 4 RX, 2 TX (Co-pol)
Layout 21 cells w/wraparound
Channel model, ISD 3D UMi 200m
Outdoor UEs % 100% outdoor or 20% ourdoor/80% indoor
BS Antenna down tilt 6 degrees
Antenna Gain BS: 8 dBi ; UE: 0 dBi per element
Noise Figure BS: 5 dB, UE: 7 dB
Max Power UE : 23 dBm, BS : 44 dBm
Doppler 3 kmph
TDD Config DDSU
Scheduler MU-MIMO PF Metric Based
Guard Band Overhead 2.08% (Useful BW : 272 RBs over 100 MHz)
Channel Estimation Realistic
Traffic
DL: Statistical model with periodic pattern
UL Pose Update: Periodic {100, 500} Bytes, every 2 ms