7 Performance requirements

22.2613GPPRelease 18Service requirements for the 5G systemTS

7.1 High data rates and traffic densities

Several scenarios require the support of very high data rates or traffic densities of the 5G system. The scenarios address different service areas: urban and rural areas, office and home, and special deployments (e.g. massive gatherings, broadcast, residential, and high-speed vehicles). The scenarios and their performance requirements can be found in table 7.1-1.

– Urban macro – The general wide-area scenario in urban area

– Rural macro – The general wide-area scenario in rural area

– Indoor hotspot – The scenario for offices and homes, and residential deployments.

– Broadband access in a crowd – The scenario for very dense crowds, for example, at stadiums or concerts. In addition to a very high connection density the users want to share what they see and hear, putting a higher requirement on the uplink than the downlink.

– Dense urban – The scenario for pedestrian users, and users in urban vehicles, for example, in offices, city centres, shopping centres, and residential areas. The users in vehicles can be connected either directly or via an onboard base station to the network.

– Broadcast-like services – The scenario for stationary users, pedestrian users, and users in vehicles, for example, in offices, city centres, shopping centres, residential areas, rural areas and in high speed trains. The passengers in vehicles can be connected either directly or via an onboard base station to the network.

– High-speed train – The scenario for users in trains. The users can be connected either directly or via an onboard base station to the network.

– High-speed vehicle – The scenario for users in road vehicles. The users can be connected either directly or via an onboard base station to the network.

– Airplanes connectivity – The scenario for users in airplanes. The users can be connected either directly or via an onboard base station to the network.

Table 7.1-1 Performance requirements for high data rate and traffic density scenarios.

	Scenario	Experienced data rate (DL)	Experienced data rate (UL)	Area traffic capacity (DL)	Area traffic capacity (UL)	Overall user density	Activity factor	UE speed	Coverage
1	Urban macro	50 Mbit/s	25 Mbit/s	100 Gbit/s/km2 (note 4)	50 Gbit/s/km2 (note 4)	10 000/km2	20 %	Pedestrians and users in vehicles (up to 120 km/h	Full network (note 1)
2	Rural macro	50 Mbit/s	25 Mbit/s	1 Gbit/s/km2 (note 4)	500 Mbit/s/km2 (note 4)	100/km2	20 %	Pedestrians and users in vehicles (up to 120 km/h	Full network (note 1)
3	Indoor hotspot	1 Gbit/s	500 Mbit/s	15 Tbit/s/km2	2 Tbit/s/km2	250 000/km2	note 2	Pedestrians	Office and residential (note 2) (note 3)
4	Broadband access in a crowd	25 Mbit/s	50 Mbit/s	[3,75] Tbit/s/km2	[7,5] Tbit/s/km2	[500 000]/km2	30 %	Pedestrians	Confined area
5	Dense urban	300 Mbit/s	50 Mbit/s	750 Gbit/s/km2 (note 4)	125 Gbit/s/km2 (note 4)	25 000/km2	10 %	Pedestrians and users in vehicles (up to 60 km/h)	Downtown (note 1)
6	Broadcast-like services	Maximum 200 Mbit/s (per TV channel)	N/A or modest (e.g. 500 kbit/s per user)	N/A	N/A	[15] TV channels of [20 Mbit/s] on one carrier	N/A	Stationary users, pedestrians and users in vehicles (up to 500 km/h)	Full network (note 1)
7	High-speed train	50 Mbit/s	25 Mbit/s	15 Gbit/s/train	7,5 Gbit/s/train	1 000/train	30 %	Users in trains (up to 500 km/h)	Along railways (note 1)
8	High-speed vehicle	50 Mbit/s	25 Mbit/s	[100] Gbit/s/km2	[50] Gbit/s/km2	4 000/km2	50 %	Users in vehicles (up to 250 km/h)	Along roads (note 1)
9	Airplanes connectivity	15 Mbit/s	7,5 Mbit/s	1,2 Gbit/s/plane	600 Mbit/s/plane	400/plane	20 %	Users in airplanes (up to 1 000 km/h)	(note 1)
NOTE 1: For users in vehicles, the UE can be connected to the network directly, or via an on-board moving base station. NOTE 2: A certain traffic mix is assumed; only some users use services that require the highest data rates [2]. NOTE 3: For interactive audio and video services, for example, virtual meetings, the required two-way end-to-end latency (UL and DL) is 2‑4 ms while the corresponding experienced data rate needs to be up to 8K 3D video [300 Mbit/s] in uplink and downlink. NOTE 4: These values are derived based on overall user density. Detailed information can be found in [10]. NOTE 5: All the values in this table are targeted values and not strict requirements.

7.2 Low latency and high reliability

7.2.1 Overview

Several scenarios require the support of very low latency and very high communications service availability. Note that this implies a very high reliability. The overall service latency depends on the delay on the radio interface, transmission within the 5G system, transmission to a server which can be outside the 5G system, and data processing. Some of these factors depend directly on the 5G system itself, whereas for others the impact can be reduced by suitable interconnections between the 5G system and services or servers outside of the 5G system, for example, to allow local hosting of the services.

7.2.2 Scenarios and KPIs

Different deployments of URLLC capabilities will depend on the 3GPP system being able to meet specific sets of KPIs with different values and ranges applicable for each attribute. A common, yet flexible, 5G approach to URLLC will enable the 5G system to meet the specific sets of KPIs needed in a given implementation. To provide clear and precise requirements for specific types of services, the corresponding KPI requirements are included in other specifications as follows:

– Cyber-physical control applications in vertical domains can be found in 22.104 [21].

– V2X can be found in 22.186 [9].

– Rail communications can be found in 22.289 [23].

Some scenarios requiring very low latency and very high communication service availability are described below:

– Motion control – Conventional motion control is characterised by high requirements on the communications system regarding latency, reliability, and availability. Systems supporting motion control are usually deployed in geographically limited areas but can also be deployed in wider areas (e.g. city- or country-wide networks), access to them can be limited to authorized users, and they can be isolated from networks or network resources used by other cellular customers.

– Discrete automation – Discrete automation is characterised by high requirements on the communications system regarding reliability and availability. Systems supporting discrete automation are usually deployed in geographically limited areas, access to them can be limited to authorized users, and they can be isolated from networks or network resources used by other cellular customers.

– Process automation – Automation for (reactive) flows, e.g. refineries and water distribution networks. Process automation is characterized by high requirements on the communications system regarding communication service availability. Systems supporting process automation are usually deployed in geographically limited areas, access to them is usually limited to authorized users, and it will usually be served by non-public networks.

– Automation for electricity distribution and smart grid (mainly medium and high voltage). Electricity distribution and smart grid are is characterized by high requirements on the communications service availability and security, as well as low latency in some cases. In contrast to the above use cases, electricity distribution and smart grid are deeply immersed into the public space. Since electricity distribution is an essential infrastructure, it is well served by network slices to provide service isolation and security, or by non-public networks.

– Wireless road-side infrastructure backhaul in intelligent transport systems – Automation solutions for the infrastructure supporting street-based traffic. This use case addresses the connection of the road-side infrastructure, e.g. roadside units, with other infrastructure, e.g. a traffic guidance system. As is the case for automation electricity, the nodes are deeply immersed into the public space.

– Remote control – Remote control is characterised by a UE being operated remotely by a human or a computer. For example, Remote Driving enables a remote driver or a V2X application to operate a remote vehicle with no driver or a remote vehicle located in a dangerous environment.

– Rail communications (e.g. railway, rail-bound mass transit) have been using 3GPP based mobile communication (e.g. GSM-R) already for some time, while there is still a driver on-board of the train. The next step of the evolution will be providing fully automated train operation that requires highly reliable communication with moderate latencies but at very high speeds of up to 500 km/h.

For specific requirements, refer to the specifications noted above [21], [9], [23].

7.2.3 Other requirements

7.2.3.1 (void)

7.2.3.2 Wireless road-side infrastructure backhaul

Intelligent Transport Systems embrace a wide variety of communications-related applications that are intended to increase travel safety, minimize environmental impact, improve traffic management, and maximize the benefits of transportation to both commercial users and the general public.

Road-side infrastructure such as traffic light controllers, roadside units, traffic monitoring in urban areas and along highways and streets is wirelessly connected to traffic control centres for management and control purposes. The backhaul communication between the road-side infrastructure and the traffic control centre requires low-latency, high communication service availability, and high-capacity connections for reliable distribution of data. Road-side infrastructure is deployed alongside streets in urban areas and alongside major roads and highways every 1-2 km.

For more information about infrastructure backhaul, see clause D.5.

To support wireless road-side infrastructure backhaul the 5G system shall support the performance requirements in table 7.2.3.2-1.

Table 7.2.3.2-1 Performance requirements for wireless ITS infrastructure backhaul scenario

Scenario	Max. allowed end-to-end latency (note 1)	Survival time	Communication service availability (note 2)	Reliability (note 2)	User experienced data rate	Payload size (note 3)	Traffic density (note 4)	Connection density (note 5)	Service area dimension (note 6)
wireless road-side infrastructure backhaul	30 ms	100 ms	99,9999%	99,999%	10 Mbit/s	Small to big	10 Gbit/s/km2	1 000/km2	2 km along a road
NOTE 1: This is the maximum end-to-end latency allowed for the 5G system to deliver the service in the case the end-to-end latency is completely allocated to the 5G system from the UE to the Interface to Data Network. NOTE 2: Communication service availability relates to the service interfaces, and reliability relates to a given system entity. One or more retransmissions of network layer packets can take place in order to satisfy the reliability requirement. NOTE 3: Small: payload typically ≤ 256 bytes NOTE 4: Based on the assumption that all connected applications within the service volume require the user experienced data rate. NOTE 5: Under the assumption of 100% 5G penetration. NOTE 6: Estimates of maximum dimensions; the last figure is the vertical dimension. NOTE 7: All the values in this table are example values and not strict requirements. Deployment configurations should be taken into account when considering service offerings that meet the targets.

7.3 High-accuracy positioning

7.3.1 Description

Adaptability and flexibility are among the key features of the 5G system to serve a wide diversity of verticals and services, in different environments (e.g. rural, urban, indoor). This applies to high-accuracy positioning and translates into the ability to satisfy different levels of services and requirements, for instance on performance (e.g. accuracy, positioning service availability, positioning service latency) and on functionality (e.g. security).

7.3.2 Requirements

7.3.2.1 General

The 5G System shall provide different 5G positioning services with configurable performances working points (e.g. accuracy, positioning service availability, positioning service latency, energy consumption, update rate, TTFF) according to the needs of users, operators and third parties.

The 5G system shall support the combination of 3GPP and non-3GPP positioning technologies to achieve performances of the 5G positioning services better than those achieved using only 3GPP positioning technologies.

NOTE 1: For instance, the combination of 3GPP positioning technologies with non-3GPP positioning technologies such as GNSS (e.g. Beidou, Galileo, GLONASS, and GPS), Terrestrial Beacon Systems (TBS), sensors (e.g. barometer, IMU), WLAN/Bluetooth-based positioning, can support the improvement of accuracy, positioning service availability, reliability and/or confidence level, the reduction of positioning service latency, the increase of the update rate of the position-related data, increase the coverage (service area).

NOTE 2: The combination can vary over time to optimise the performances, and can be the combination of multiple positioning technologies at the same epoch and/or the combination of multiple positioning technologies at different epochs.

The corresponding positioning information shall be acquired in a timely fashion, be reliable, and be available (e.g. it is possible to determine the position).

UEs shall be able to share positioning information between each other e.g. to a controller if the location information cannot be processed or used locally.

7.3.2.2 Requirements for horizontal and vertical positioning service levels

The 5G system shall be able to provide positioning services with the performances requirements reported in Table 7.3.2.2-1.

NOTE: The requirements do not preclude any type of UE, including specific UE such as for example V2X, MTC.

Table 7.3.2.2-1 Performance requirements for Horizontal and Vertical positioning service levels

Positioning service level	Absolute(A) or Relative(R) positioning	Accuracy (95 % confidence level)		Positioning service availability	Positioning service latency	Coverage, environment of use and UE velocity
		Horizontal Accuracy	Vertical Accuracy (note 1)			5G positioning service area	5G enhanced positioning service area (note 2)
							Outdoor and tunnels	Indoor
1	A	10 m	3 m	95 %	1 s	Indoor – up to 30 km/h Outdoor (rural and urban) up to 250 km/h	NA	Indoor – up to 30 km/h
2	A	3 m	3 m	99 %	1 s	Outdoor (rural and urban) up to 500 km/h for trains and up to 250 km/h for other vehicles	Outdoor (dense urban) up to 60 km/h Along roads up to 250 km/h and along railways up to 500 km/h	Indoor – up to 30 km/h
3	A	1 m	2 m	99 %	1 s	Outdoor (rural and urban) up to 500 km/h for trains and up to 250 km/h for other vehicles	Outdoor (dense urban) up to 60 km/h Along roads up to 250 km/h and along railways up to 500 km/h	Indoor – up to 30 km/h
4	A	1 m	2 m	99,9 %	15 ms	NA	NA	Indoor – up to 30 km/h
5	A	0,3 m	2 m	99 %	1 s	Outdoor (rural) up to 250 km/h	Outdoor (dense urban) up to 60 km/h Along roads and along railways up to 250 km/h	Indoor – up to 30 km/h
6	A	0,3 m	2 m	99,9 %	10 ms	NA	Outdoor (dense urban) up to 60 km/h	Indoor – up to 30 km/h
7	R	0,2 m	0,2 m	99 %	1 s	Indoor and outdoor (rural, urban, dense urban) up to 30 km/h Relative positioning is between two UEs within 10 m of each other or between one UE and 5G positioning nodes within 10 m of each other (note 3)
NOTE 1: The objective for the vertical positioning requirement is to determine the floor for indoor use cases and to distinguish between superposed tracks for road and rail use cases (e.g. bridges). NOTE 2: Indoor includes location inside buildings such as offices, hospital, industrial buildings. NOTE 3: 5G positioning nodes are infrastructure equipment deployed in the service area to enhance positioning capabilities (e.g. beacons deployed on the perimeter of a rendezvous area or on the side of a warehouse).

7.3.2.3 Other performance requirements

The 5G system shall be able to provide the 5G positioning services with a TTFF less than 30 s and, for some 5G positioning services, shall support mechanisms to provide a TTFF less than 10 s.

NOTE 1: In some services, a TTFF of less than 10s can only be achievable at the expense of a relaxation of some other performances (e.g. horizontal accuracy can be 1 m or 3 m after 10 s TTFF, and reach a steady state accuracy of 0,3 m after 30 s).

The 5G system shall support a mechanism to determine the UE’s velocity with a positioning service availability of 99%, an accuracy better than 0,5 m/s for the speed and an accuracy better than 5 degree for the 3-Dimension direction of travel.

The 5G system shall support a mechanism to determine the UE’s heading with an accuracy better than 30 degrees (0,54 rad) and a positioning service availability of 99,9 % for static users and with an accuracy better than 10 degrees (0,17 rad) and a positioning service availability of 99 % for users up to 10 km/h.

For power consumption aspects for various usage scenarios see TS 22.104 [21]

Low power high accuary positioning use cases and example scenarios for Industrial IoT devices can be found in 3GPP TS 22.104 [21].

7.4 KPIs for a 5G system with satellite access

7.4.1 Description

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
LEO	3	15	30
MEO	27	43	90
GEO	120	140	280
NOTE1: The serving satellite provides the satellite radio link to the UE NOTE2: delay between UE and ground station via satellite link; Inter satellite links are not considered

7.4.2 Requirements

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.

NOTE 1: 5 ms network latency is assumed and added to satellite one-way delay.

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.

NOTE 2: 5 ms network latency is assumed and added to satellite one-way delay.

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.

NOTE 3: 5 ms network latency is assumed and added to satellite one-way delay.

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/km2	150 kbit/s/km2	[100]/km2	[1,5] %	Pedestrian	Handheld
Public safety	[3,5] Mbit/ss	[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/km2	40 kbit/s/km2	[400]/km2	[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

7.5.1 Description

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

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

Profile	Characteristic parameter					Influence quantity
	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,9999	<1 year (>> 1 month)	< 100 ms	< 1 Mbit/s	Uplink	~ 1000	50 ms	Transfer Interval	< 500	10/km2 to 1000/km2	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

7.6.1 AR/VR

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 ms to 15ms 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].

NOTE: The motion-to-photon latency is defined as the latency between the physical movement of a user’s head and the updated picture in the VR headset. The motion-to-sound latency is the latency between the physical movement of a user’s head and updated sound waves from a head mounted speaker reaching their ears.

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 to 5 ms] for audio delayed and

– in the range of [45 ms to 5 ms] for audio advanced.

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
	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 to120 frames per second content.	99,99 % in uplink and 99,9 % in downlink (note 4)	–	Stationary or Pedestrian	Countrywide
Gaming or Interactive Data Exchanging (note 3)	10ms (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 to120 frames per second content.	99,99 % (note 4)	≤ [10]	Stationary or Pedestrian	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.

7.7 KPIs for UE to network relaying in 5G system

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	10 m 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	10000 devices /factory	100 m x 100 m	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	15000 x 100 bytes / 15 mins /ship	15000 x 100 bytes / 15 mins /ship	15000 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

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 km2	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 km2	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.

7.9 KPIs for ranging based services

In several scenarios, it can be beneficial to determine the distance between two UEs and/or the direction of one UE from the other one via direct communication connection. The functional requirements related to ranging based services can be found in clause 6.36. Performance requirements for ranging based services in different scenarios can be found in table 7.9-1.

Key performance indicators and key attributes for ranging are defined as follows:

– Ranging accuracy: describes the absolute value of the deviation of the measured distance and/or direction between two UEs to the true distance and/or direction value.

– Confidence level: describes the percentage of all the possible measured distance and/or direction that can be expected to include the true distance and/or direction considering the ranging accuracy.

– Effective ranging distance: the largest distance between the UE who initiates the ranging and target UEs in the ranging operation.

– Line-of-sight (LOS) Environment: the environment between the UE who initiates the ranging and target UEs, such as LOS and non-LOS (NLOS).

– Coverage: type of radio coverage conditions of the UEs who are involved in ranging, such as in coverage (IC), partial coverage (PC) and out of coverage (OOC). See also fig. 6.36.1-1.

NOTE: If using licensed spectrum, ranging is only permitted in network coverage under the full control of the operator who provides the coverage​, except for public safety networks with dedicated spectrum where ranging might be allowed out of coverage or in partial coverage as well.

– Relative UE velocity: the target UE can be either static or mobile relative to the UE who initiates the ranging. In the latter, the attribute shall also provide some elements about its motion, e.g. maximum speed, trajectory.

– Availability: percentage value of the amount of time when a ranging system is able to provide the required ranging-related data within the performance targets or requirements divided by the amount of time the system is expected to provide the ranging service in a targeted service area.

– Latency: time elapsed between the event that triggers the determination of the ranging-related data and the availability of the ranging-related data at the ranging system interface.

– Ranging interval: time difference between two consecutive ranging operations.

Table 7.9-1: Performance requirements for ranging based services

Ranging scenario	Ranging Accuracy (95 % confidence level)		Availability	Latency 10ms 50ms 50ms	Effective ranging distance	Coverage	NLOS/LOS	Relative UE velocity	Ranging interval	Number of concurrent ranging operation for a UE	Number of concurrent ranging operation in an area
	Distance Accuracy	Direction Accuracy
Smart TV Remoter	10cm up to 3 meter separation	±2° horizontal direction accuracy at 0.1 to 3 meter separation and AoA coverage of (-60°) to (+60°); ±2° Elevation direction accuracy at 0.1 to 3 meter separation and AoA coverage of (-45°) to (+45°)	99 %	50ms	10m	IC/PC/OOC	LOS	Static/ Moving (<1m/s)	50ms	–	–
Picture and video sharing based on Ranging results	10cm	2°	99 %	50ms	10m	IC/PC/OOC	LOS	Static/ Moving (<1m/s)	50ms	–	–
Distance based smart device control	10cm	–	99 %	100ms	20m	IC/PC/OOC	LOS	Static/ Moving (<1m/s)	50ms	20	–
Smart Vehicle Key	10 cm	–	99 %	50ms	30m	IC/PC/OOC	LOS	Static/ Moving (<2m/s)	25ms	–	50UEs/ (104m2)
Touchless Self-checkout Machine Control	10cm	–	99%	150ms	1m	IC/PC/OOC	LOS	Static/ Moving (<1m/s)	100ms	–	=
Hands Free Access	10cm	–	99 %	500ms	10 m	IC/PC/OOC	LOS	Static/ Moving (1 m/s)	50ms	–	20 UEs/3.14*100m2
Smart Transportation Metro/Bus Validation	10cm	–	99 %	–	2m	IC/PC/OOC	LOS	Static/ Moving (3km/h)	50ms	20	100 in the area of 8 m2
Ranging of UE’s in front of vending machine	20cm	10°	–	1s	5m	IC/PC/OOC	LOS	Static/ Moving (<1m/s)	50ms	–	10
Finding Items in a supermarket	50 cm	5 degree	95 %	–	100m	IC/PC/OOC	LOS	Static/ Moving (<1m/s)	250ms	–	100 UEs/ (3.14*104m2)
distance based intelligent perception for public safety	50cm	–	99 %	–	20m	IC/PC/OOC	LOS	Static/ Moving (<20km/h)	–	100	–
Long Distance Search	20m	5°	99 %	–	100m-1km	IC/PC/OOC	LOS	Static/ Moving (up to 10m/s)	5s	–	–
Long range approximate location	[10m]	±[12.5°]	99 %	–	500m	IC/PC/OOC	LOS	Static/ Moving (<10m/s)	–	1	[50]UEs/ (104m2)

7.10 KPIs for AI/ML model transfer in 5GS

The 5G system shall support split AI/ML inference between UE and Network Server/Application function with performance requirements as given in Table 7.10-1.

Table 7.10-1 KPI Table of split AI/ML inference between UE and Network Server/Application function

Uplink KPI					Downlink KPI				Remarks
Max allowed UL end-to-end latency	Experienced data rate	Payload size	Communication service availability	Reliability	Max allowed DL end-to-end latency	Experienced data rate	Payload size	Reliability
2 ms	1.08 Gbit/s	0.27 MByte	99.999 %	99.9 %				99.999 %	Split AI/ML image recognition
100 ms	1.5 Mbit/s				100 ms	150 Mbit/s	1.5 MByte/‌frame		Enhanced media recognition
	4.7 Mbit/s				12 ms	320 Mbit/s	40 kByte		Split control for robotics
NOTE 1: Communication service availability relates to the service interfaces, and reliability relates to a given system entity. One or more retransmissions of network layer packets can take place in order to satisfy the reliability requirement.

The 5G system shall support AI/ML model downloading with performance requirements as given in Table 7.10-2.

Table 7.10-2 KPI Table of AI/ML model downloading

Max allowed DL end-to-end latency	Experienced data rate (DL)	Model size	Communication service availability	Reliability	User density	# of downloaded AI/ML models	Remarks
1s	1.1Gbit/s	138MByte	99.999 %	99.9% for data transmission of model weight factors; 99.999% for data transmission of model topology			AI/ML model distribution for image recognition
1s	640Mbit/s	80MByte	99.999 %				AI/ML model distribution for speech recognition
1s	512Mbit/s(see note 1)	64MByte				Parallel download of up to 50 AI/ML models	Real time media editing with on-board AI inference
1s		536MByte			up to 5000~ 10000/km2 in an urban area		AI model management as a Service
1s	22Mbit/s	2.4MByte	99.999 %				AI/ML based Automotive Networked Systems
1s		500MByte					Shared AI/ML model monitoring
3s	450Mbit/s	170MByte					Media quality enhancement
NOTE 1: 512Mbit/s concerns AI/ML models having a payload size below 64 MB. TBD for larger payload sizes. NOTE 2: Communication service availability relates to the service interfaces, and reliability relates to a given system entity. One or more retransmissions of network layer packets can take place in order to satisfy the reliability requirement.

The 5G system shall support Federated Learning between UE and Network Server/Application function with performance requirements as given in Table 7.10-3.

Table 7.10-3: KPI Table of Federated Learning between UE and Network Server/Application function

Max allowed DL or UL end-to-end latency	DL experienced data rate	UL experienced data rate	DL packet size	UL packet size	Communication service availability	Remarks
1s	1.0Gbit/s	1.0Gbit/s	132MByte	132MByte		Uncompressed Federated Learning for image recognition
1s	80.88Mbit/s	80.88Mbit/s	10Mbyte	10Mbyte	TBD	Compressed Federated Learning for image/video processing
1s	TBD	TBD	10MByte	10MByte		Data Transfer Disturbance in Multi-agent multi-device ML Operations

7.11 KPIs for tactile and multi-modal communication service

The 5G system shall support tactile and multi-modal communication services with the following KPIs.

Table 7.11-1: Multi-modal communication service performance requirements

Use Cases	Characteristic parameter (KPI)			Influence quantity			Remarks
	Max allowed end-to-end latency	Service bit rate: user-experienced data rate	Reliability	Message size (byte)	UE Speed	Service Area
Immersive multi-modal VR (UL: device  application sever)	5 ms (note 2)	16 kbit/s -2 Mbit/s (without haptic compression encoding); 0.8 – 200 kbit/s (with haptic compression encoding)	99.9% (without haptic compression encoding) 99.999% (with haptic compression encoding) [40]	1 DoF: 2-8 3 DoFs: 6-24 6 DoFs: 12-48 More DoFs can be supported by the haptic device	Stationary or Pedestrian	typically < 100 km2 (note 5)	Haptic feedback
	5 ms	< 1Mbit/s	99.99% [40]	1500	Stationary or Pedestrian	typically < 100 km2 (note 5)	Sensing information e.g. position and view information generated by the VR glasses
Immersive multi-modal VR (DL: application sever  device)	10 ms (note1)	1-100 Mbit/s	99.9% [40]	1500	Stationary or Pedestrian	typically < 100 km2 (note 5)	Video
	10 ms	5-512 kbit/s	99.9% [40]	50	Stationary or Pedestrian	typically < 100 km2 (note 5)	Audio
	5 ms (note 2)	16 kbit/s -2 Mbit/s (without haptic compression encoding); 0.8 – 200 kbit/s (with haptic compression encoding)	99.9% (without haptic compression encoding) 99.999% (with haptic compression encoding) [40]	1 DoF: 2-8 3 DoFs: 6-24 6 DoFs: 12-48	Stationary or Pedestrian	typically < 100 km2 (note 5)	Haptic feedback
Remote control robot	1-20ms	16 kbit/s -2 Mbit/s (without haptic compression encoding); 0.8 – 200 kbit/s (with haptic compression encoding)	99.999% [40]	2-8 (1 DoF)	high-dynamic (≤ 50 km/h)	≤ 1 km2	Haptic feedback
	20-100ms	16 kbit/s -2 Mbit/s (without haptic compression encoding); 0.8 – 200 kbit/s (with haptic compression encoding)	99.999% [40]	2-8 (1 DoF)	Stationary or Pedestrian	≤ 1 km2	Haptic feedback
	5 ms	1-100 Mbit/s	99.999% [40]	1500	Stationary or Pedestrian	≤ 1 km2	Video
	5 ms	5-512 kbit/s	99.9% [40]	50-100	Stationary or Pedestrian	≤ 1 km2	Audio
	5 ms	< 1Mbit/s	99.999% [40]	–	Stationary or Pedestrian	≤ 1 km2	Sensor information
Skillset sharing low- dynamic robotics (including teleoperation) Controller to controlee	5-10ms	0.8 – 200 kbit/s (with compression)	99,999% [40][45]	1 DoF: 2-8 3 DoFs: 6-24 6 DoFs: 12-48	Stationary or Pedestrian	100 km2	Haptic (position, velocity)

Skillset sharing low- dynamic robotics (including teleoperation) Controlee to controller	5-10ms	0.8 – 200 kbit/s (with compression)	99,999% [40][45]	1 DoF: 2-8 10 DoFs: 20-80 100 DoFs: 200-800	Stationary or Pedestrian	100 km2	Haptic feedback
	10ms	1-100 Mbit/s	99,999% [40] [45]	1500	Stationary or Pedestrian	100 km2	Video
	10ms	5-512 kbit/s	99,9% [40] [45]	50	Stationary or Pedestrian	100 km2	Audio
Skillset sharing Highly dynamic/ mobile robotics Controller to controlee	1-5ms	16 kbit/s -2 Mbit/s (without haptic compression encoding); 0.8 – 200 kbit/s (with haptic compression encoding)	99,999% (with compression) 99,9% (w/o compression) [40] [45]	1 DoF: 2-8 3 DoFs: 6-24 6 DoFs: 12-48	high-dynamic	4 km2	Haptic (position, velocity)
Skillset sharing Highly dynamic/ mobile robotics Controlee to controller	1-5ms	0.8 – 200 kbit/s	99,999% (with compression) 99,9% (w/o compression) [40] [45]	1 DoF: 2-8 10 DoFs: 20-80 100 DoFs: 200-800	high-dynamic	4 km2	Haptic feedback
	1-10ms	1-10 Mbit/s	99,999% [40] [45]	2000-4000	high-dynamic	4 km2	Video
	1-10ms	100-500 kbit/s	99,9% [40] [45]	100	high-dynamic	4 km2	Audio
Immersive multi-modal navigation applications Remote Site  Local Site (DL)	50 ms [39]	16 kbit/s -2 Mbit/s (without haptic compression encoding); 0.8 – 200 kbit/s (with haptic compression encoding)	99.999 % [40]	1 DoF: 2 to 8 10 DoF: 20 to 80 100 DoF: 200 to 800	Stationary or Pedestrian	≤ 100 km2 ( note 5)	Haptic feedback
	<400 ms [39]	1-100 Mbit/s	99.999 % [40]	1500	Stationary/ or Pedestrian,	≤ 100 km2 (note 5)	Video
	<150 ms [39]	5-512 kbit/s	99.9 % [40]	50	Stationary or Pedestrian	≤ 100 km2 (note 5)	Audio
	<300 ms	600 Mbit/s	99.9 % [40]	1500	Stationary or Pedestrian	≤ 100 km2 (note 5)	VR
Immersive multi-modal navigation applications Local Site  Remote Site (UL)	<300 ms	12 kbit/s [26]	99.999 % [40]	1500	Stationary or Pedestrian	≤ 100 km2 (note 5)	Biometric / Affective
	<400 ms [39]	1-100 Mbit/s	99.999 % [40]	1500	Workers: Stationary/ or Pedestrian, UAV: [30-300mph]	≤ 100 km2 (note 5)	Video
	<150 ms [39]	5-512 kbit/s	99.9 % [40]	50	Stationary or Pedestrian	≤ 100 km2 (note 5)	Audio
	<300 ms	600 Mbit/s	99.9 % [40]	1500	Stationary or Pedestrian	≤ 100 km2 (note 5)	VR
NOTE 1: Motion-to-photon delay (the time difference between the user’s motion and corresponding change of the video image on display) is less than 20 ms, and the communication latency for transferring the packets of one audio-visual media is less than 10 ms, e.g. the packets corresponding to one video/audio frame are transferred to the devices within 10 ms. NOTE 2: According to IEEE 1918.1 [40] as for haptic feedback, the latency is less than 25 ms for accurately completing haptic operations. As rendering and hardware introduce some delay, the communication delay for haptic modality can be reasonably less than 5 ms, i.e. the packets related to one haptic feedback are transferred to the devices within 10 ms. NOTE 3: Haptic feedback is typically haptic signal, such as force level, torque level, vibration and texture. NOTE 4: The latency requirements are expected to be satisfied even when multimodal communication for skillset sharing is via indirect network connection (i.e., relayed by one UE to network relay). NOTE 5: In practice, the service area depends on the actual deployment. In some cases a local approach (e.g. the application servers are hosted at the network edge) is preferred in order to satisfy the requirements of low latency and high reliability.