Content for TS 22.261 Word version: 20.0.0

0… 4… 6… 6.4… 6.8… 6.12… 6.15… 6.16… 6.22… 6.26… 6.30… 6.37… 6.41… 6.43… 6.46… 7… 7.4… 7.9 7.10… 7.11… 8… D… D.3… F… G… H I J…

7.4 KPIs for a 5G system with satellite access 7.4.1 Description 7.4.2 Requirements 7.5 High-availability IoT traffic 7.5.1 Description 7.5.2 Requirements 7.6 High data rate and low latency 7.6.1 AR/VR 7.7 KPIs for UE to network relaying in 5G system 7.8 KPIs for 5G Timing Resiliency
...

7.4 KPIs for a 5G system with satellite access |R17| p. 97

7.4.1 Description p. 97

Satellite access networks are based on infrastructures integrated on a minimum of satellites that can be placed in either GEO, MEO or LEO.

The propagation delay via satellite associated with these orbit ranges can be summarized in Table 7.4.1-1:

Table 7.4.1-1: Propagation delay via satellite

	UE to serving satellite propagation delay [ms] [NOTE 1]		UE to ground max propagation delay [ms] [NOTE 2]
	Min	Max	UE to ground max propagation delay [ms] [NOTE 2]
LEO	3	15	30
MEO	27	43	90
GEO	120	140	280
NOTE 1: The serving satellite provides the satellite radio link to the UE NOTE 2: delay between UE and ground station via satellite link; Inter satellite links are not considered

7.4.2 Requirements p. 97

A 5G system providing service with satellite access shall be able to support GEO based satellite access with up to 285 ms end-to-end latency.

A 5G system providing service with satellite access shall be able to support MEO based satellite access with up to 95 ms end-to-end latency.

A 5G system providing service with satellite access shall be able to support LEO based satellite access with up to 35 ms end-to-end latency.

A 5G system shall support negotiation on quality of service taking into account latency penalty to optimise the QoE for UE.

The 5G system with satellite access shall support high uplink data rates for 5G satellite UEs.

The 5G system with satellite access shall support high downlink data rates for 5G satellite UEs.

The 5G system with satellite access shall support communication service availabilities of at least 99,99%.

Table 7.4.2-1: Performance requirements for satellite access

Scenario	Experienced data rate (DL)	Experienced data rate (UL)	Area traffic capacity (DL) (Note 1)	Area traffic capacity (UL) (Note 1)	Overall user density	Activity factor	UE speed	UE type
Pedestrian (Note 2)	[1] Mbit/s	[100] kbit/s	1.5 Mbit/s/km²	150 kbit/s/km²	[100]/km²	[1.5] %	Pedestrian	Handheld
Public safety	[3,5] Mbit/s	[3.5] Mbit/s	TBD	TBD	TBD	N/A	100 km/h	Handheld
Vehicular connectivity (Note 3)	50 Mbit/s	25 Mbit/s	TBD	TBD	TBD	50 %	Up to 250 km/h	Vehicle mounted
Airplanes connectivity (Note 4)	360 Mbit/s/ plane	180 Mbit/s/ plane	TBD	TBD	TBD	N/A	Up to 1000 km/h	Airplane mounted
Stationary	50 Mbit/s	25 Mbit/s	TBD	TBD	TBD	N/A	Stationary	Building mounted
Video surveillance (note 4a)	[0,5] Mbit/s	[3] Mbit/s	TBD	TBD	TBD	N/A	Up to 120km/h or stationary (note 4b)	Vehicle mounted or fixed installation
Narrowband IoT connectivity	[2] kbit/s	[10] kbit/s	8 kbit/s/km²	40 kbit/s/km²	[400]/km²	[1] %	[Up to 100 km/h]	IoT
NOTE 1: Area capacity is averaged over a satellite beam. NOTE 2: Data rates based on Extreme long-range coverage target values in clause 6.17.2. User density based on rural area in Table 7.1-1. NOTE 3: Based on Table 7.1-1 NOTE 4: Based on an assumption of 120 users per plane 15/7.5 Mbit/s data rate and 20 % activity factor per user NOTE 4a: Refer to video surveillance data transmitted (in UL) from a UE on the ground (e.g. picture or video from a camera) using satellite NG-RAN to connect to 5GC, and video surveillance-related configuration or control data sent (in DL) to the UE/device. 0.5 Mbit/s for DL experienced data rate is based on MAVLINK protocol that is widely used for UAV control. 3 Mbit/s for UL experienced data rate is based on the assumed sum from 2.5 Mbit/s for video streaming and 0.5 Mbit/s for data transmission. NOTE 4b: Up to 120km/h applies to vehicle mounted while stationary applies to fixed installation. NOTE 5: All the values in this Table are targeted values and not strict requirements. NOTE 6: Performance requirements for all the values in this Table should be analyzed independently for each scenario.

7.5 High-availability IoT traffic |R17| p. 98

Several scenarios require the support of highly reliable machine type communication such as those, typically (but not restricted to) related to medical monitoring. They involve different deployment areas, different device speeds and densities and require a high-availability communication service to transfer a low data rate uplink data stream from one or several devices to an application.

Their related performance requirements can be found in Table 7.5.2-1.

7.5.2 Requirements p. 99

Table 7.5.2-1: Performance requirements for highly reliable machine type communication

Profile	Characteristic parameter					Influence quantity
Profile	Communication service availability: target value in %	Communication service reliability (Mean Time Between Failure)	End-to-end latency: maximum	Bit rate	Direction	Message Size [byte]	Transfer Interval	Survival Time	UE speed (km/h)	# of UEs connection	Service Area
Medical monitoring (Note 2)	> 99.999 9	< 1 year (>> 1 month)	< 100 ms	< 1 Mbit/s	Uplink	~1,000	50 ms	Transfer Interval	< 500	10/km² to 1,000/km²	Country wide including rural areas and deep indoor. (Note 1)
NOTE 1: "deep indoor" term is meant to be places like e.g. elevators, building's basement, underground parking lot… NOTE 2: These performance requirements aim energy-efficient transmissions performed using a device powered with a 3.3V battery of capacity < 1000 mAh that can last at least 1 month without recharging and whereby the peak current for transmit operations stays below 50 mA.

7.6 High data rate and low latency |R17| p. 100

7.6.1 AR/VR p. 100

Audio-visual interaction is characterised by a human being interacting with the environment or people, or controlling a UE, and relying on audio-visual feedback. In the use cases like VR and interactive conversation the latency requirements include the latencies at the application layer (e.g. codecs), which could be specified outside of 3GPP.

To support VR environments with low motion-to-photon capabilities, the 5G system shall support:

motion-to-photon latency in the range of 7 to 15 ms while maintaining the required resolution of up to 8k giving user data rate of up to [1Gbit/s] and
motion-to-sound delay of [< 20 ms].

To support interactive task completion during voice conversation the 5G system shall support low-delay speech coding for interactive conversational services (100 ms, one-way mouth-to-ear).

Due to the separate handling of the audio and video component, the 5G system will have to cater for the VR audio-video synchronisation in order to avoid having a negative impact on the user experience (i.e. viewers detecting lack of synchronization). To support VR environments the 5G system shall support audio-video synchronisation thresholds:

in the range of [125 ms yo 5 ms] for audio delayed and
in the range of [45 ms to 5 ms] for audio advanced.

The 5G system shall support service continuity for AR/VR to support immersive user experience under high UE mobility.

When it comes to implementation of applications containing AR/VR components, the requirements on the 5G network could depend on architectural choices implementing these services. Note 3 in Table 7.1-1 above gives an example on such dependences for a VR application in a 5G system. Table 7.6.1-1 below illustrates additional use cases and provides more corresponding requirements on the 5G system.

Cloud/Edge/Split Rendering - Cloud/Edge/Split Rendering is characterised by the transition and exchange of the rendering data between the rendering server and device.
Gaming or Training Data Exchanging - This use case is characterised by the exchange of the gaming or training service data between two 5G connected AR/VR devices.
Consume VR content via tethered VR headset - This use case involves a tethered VR headset receiving VR content via a connected UE; this approach alleviates some of the computation complexity required at the VR headset, by allowing some or all decoding functionality to run locally at the connected UE. The requirements in the Table below refer to the direct wireless link between the tethered VR headset and the corresponding connected UE.

Table 7.6.1-1: KPI Table for additional high data rate and low latency service

Use Cases	Characteristic parameter (KPI)			Influence quantity
Use Cases	Max allowed end-to-end latency	Service bit rate: user-experienced data rate	Reliability	# of UEs	UE Speed	Service Area (Note 2)
Cloud/Edge/Split Rendering (Note 1)	5 ms (i.e. UL+DL between UE and the interface to data network) (Note 4)	0.1 to [1] Gbit/s supporting visual content (e.g. VR based or high definition video) with 4K, 8K resolution and up to120fps content.	99.99 % in uplink and 99.9% in downlink (Note 4)	–	Stationary or Pedestrian (Note 7)	Countrywide
Gaming or Interactive Data Exchanging (Note 3)	10ms (Note 4)	0.1-[1] Gbit/s supporting visual content (e.g. VR based or high definition video) with 4K, 8K resolution and up to 120 frames per second content.	99.99 % (Note 4)	≤ [10]	Stationary or Pedestrian (Note 7)	20 m x 10 m; in one vehicle (up to 120 km/h) and in one train (up to 500 km/h)
Consumption of VR content via tethered VR headset (Note 6)	[5 to 10] ms (Note 5)	0,1 to [10] Gbit/s (Note 5)	[99.99 %]	–	Stationary or Pedestrian	–
NOTE 1: Unless otherwise specified, all communication via wireless link is between UEs and network node (UE to network node and/or network node to UE) rather than direct wireless links (UE to UE). NOTE 2: Length x width (x height). NOTE 3: Communication includes direct wireless links (UE to UE). NOTE 4: Latency and reliability KPIs can vary based on specific use case/architecture, e.g. for cloud/edge/split rendering, and can be represented by a range of values. NOTE 5: The decoding capability in the VR headset and the encoding/decoding complexity/time of the stream will set the required bit rate and latency over the direct wireless link between the tethered VR headset and its connected UE, bit rate from 100 Mbit/s to [10] Gbit/s and latency from 5 ms to 10 ms. NOTE 6: The performance requirement is valid for the direct wireless link between the tethered VR headset and its connected UE. NOTE 7: Similar user-experienced data rates may be achievable also at higher UE speeds. [50]

7.7 KPIs for UE to network relaying in 5G system |R17| p. 101

In several scenarios, it can be beneficial to relay communication between one UE and the network via one or more other UEs. The functional requirements related to relaying can be found in clause 6.9.2. Performance requirements for relaying in different scenarios can be found in Table 7.7-1.

Table 7.7-1: Key Performance for UE to network relaying

Scenario	Max. data rate (DL)	Max. data rate (UL)	End-to-end latency (Note 7)	Area traffic capacity (DL)	Area traffic capacity (UL)	Area user density	Area	Range of a single hop (Note 8)	Estimated number of hops
InHome Scenario (note 1)	1 Gbit/s	500 Mbit/s	10 ms	5 Gbit/s/ home	2 Gbit/s /home	50 devices /house	10m x 10m - 3 floors	10 m indoor	2 to 3
Factory Sensors (Note 2)	100 kbit/s	5 Mbit/s	50 ms to 1 s	1 Gbit/s /factory	50 Gbit/s /factory	10,000 devices /factory	100m x 100m	30 m indoor / metallic	2 to 3
Smart Metering (Note 3)	100 bytes / 15 mins	100 bytes / 15 mins	10 s	200 x 100 bytes / 15 mins /hectare	200 x 100 bytes / 15 mins /hectare	200 devices /hectare	100 m x 100 m	> 100 m indoor / deep indoor	2 to 5
Containers (Note 4)	100 bytes / 15 mins	100 bytes / 15 mins	10 s	15,000 x 100 bytes / 15 mins /ship	15,000 x 100 bytes / 15 mins /ship	15,000 containers /ship	400 m x 60 m x 40 m	> 100 m indoor / outdoor / metallic	3 to 9
Freight Wagons	100 bytes / 15 mins	100 bytes / 15 mins	10 s	200 x 100 bytes / 15 mins /train	200 x 100 bytes / 15 mins /train	120 wagons /train	1 km	> 100 m outdoor / tunnel	10 to 15
Public Safety (Note 5)	12 Mbit/s	12 Mbit/s	30 ms	20 Mbit/s /building	40 Mbit/s /building	30 devices /building	100 m x 100 m - 3 floors	> 50 m indoor (floor or stairwell)	2 to 4
Wearables (Note 6)	10 Mbit/s	10 Mbit/s	10 ms	20 Mbit/s per 100 m2	20 Mbit/s per 100 m2	10 wearables per 100 m2	10 m x 10 m	10 m indoor / outdoor	1 to 2
NOTE 1: Area traffic capacity is determined by high bandwidth consuming devices (e.g. ultra HD TVs, VR headsets), the number of devices has been calculated assuming a family of 4 members. NOTE 2: Highest data rate assumes audio sensors with sampling rate of 192 kHz and 24 bits sample size. NOTE 3: Three meters (gas, water, electricity) per house, medium density of 50 to 70 houses per hectare. NOTE 4: A large containership with a mix of 20 foot and 40 foot containers is assumed. NOTE 5: A mix of MCPTT, MCVideo, and MCData is assumed. Average 3 devices per firefighter / police officer, of which one video device. Area traffic based on 1080 p, 60 fps is 12 Mbit/s video, with an activity factor of 30% in uplink (30% of devices transmit simultaneously at high bitrate) and 15% in downlink. NOTE 6: Communication for wearables is relayed via a UE. This relay UE can use a further relay UE. NOTE 7: End-to-end latency implies that all hops are included. NOTE 8: 'Metallic' implies an environment with a lot of metal obstructions (e.g. machinery, containers). 'Deep indoor' implies that there can be concrete walls / floors between the devices. NOTE 9: All the values in this Table are example values and not strict requirements.

7.8 KPIs for 5G Timing Resiliency |R18| p. 102

The 5G system shall be able to support a holdover time capability with timing resiliency performance requirements defined in Table 7.8-1.

Table 7.8-1: Timing resiliency performance requirements for 5G System

Use case	Holdover time (note 3)	Sync target	Sync accuracy	Service area	Mobility	Remarks
Power grid (5G network)	Up to 24 hour	UTC (note 1)	<250 ns to1000 ns (note2)	< 20 km²	low	When 5G System provides direct PTP Grandmaster capability to sub-stations
Power grid (time synchronization device)	>5 s	UTC (note 1)	<250 ns to1000 ns (note2)	< 20 km²	low	When 5G sync modem is integrated into PTP grandmaster solution (with 24h holdover capability at sub-stations)
NOTE 1: A different synchronization target is acceptable as long as the offset is preconfigured when an alternatively sourced time differs from GNSS. In this case, a 5G end device will provide PPS output which can be used for measuring the difference. NOTE 2: Different accuracy measurements are based on different configurations needed to support the underlying requirements from IEC 61850-9-3 [32]. The range is between 250 ns and 1000 ns. The actual requirement depends on the specific deployment. NOTE 3: This requirement will vary based on deployment options.

Table 7.8-2: Timing resiliency accuracy KPIs for members or participants of a trading venue [35]

Type of trading activity	Maximum divergence from UTC	Granularity of the timestamp (note 1)
Activity using high frequency algorithmic trading technique	100 μs	≤1 μs
Activity on voice trading systems	1 s	≤1 s
Activity on request for quote systems where the response requires human intervention or where the system does not allow algorithmic trading	1 s	≤1 s
Activity of concluding negotiated transactions	1 s	≤1 s
Any other trading activity	1 ms	≤1 ms
NOTE 1: Only relevant for the case where the time synchronization assists in configuring the required granularity for the timestamp (for direct use), otherwise it will be configured separately as part of the financial transaction timestamp process.