Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 22.261  Word version:  18.6.1

Top   Top   Up   Prev   Next
0…   4…   6…   6.4…   6.8…   6.12…   6.22…   6.26…   6.30…   7…   7.4…   8…   D…   D.3…   F…

 

7.4  KPIs for a 5G system with satellite access |R17|Word‑p. 77

7.4.1  DescriptionWord‑p. 77

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:
UE to serving satellite propagation delay [ms] [NOTE 1] UE to ground max propagation delay [ms] [NOTE 2]
Min Max
LEO31530
MEO274390
GEO120140280
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
Up

7.4.2  RequirementsWord‑p. 77

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%.
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/s1.5 Mbit/s/km²150 kbit/s/km²[100]/km²[1.5] %PedestrianHandheld
Public safety[3,5] Mbit/ss[3.5] Mbit/sTBDTBDTBDN/A100 km/hHandheld
Vehicular connectivity (Note 3)50 Mbit/s25 Mbit/sTBDTBDTBD50 %Up to 250 km/hVehicle mounted
Airplanes connectivity (Note 4)360 Mbit/s/ plane180 Mbit/s/ planeTBDTBDTBDN/AUp to 1000 km/hAirplane mounted
Stationary50 Mbit/s25 Mbit/sTBDTBDTBDN/AStationaryBuilding mounted
Video surveillance (note 4a)[0,5] Mbit/s[3] Mbit/sTBDTBDTBDN/AUp to 120km/h or stationary (note 4b)Vehicle mounted or fixed installation
Narrowband IoT connectivity[2] kbit/s[10] kbit/s8 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.
Up

7.5  High-availability IoT traffic |R17|Word‑p. 78

7.5.1  DescriptionWord‑p. 78

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

7.5.2  RequirementsWord‑p. 79

Profile Characteristic parameter Influence quantity
Communi­cation service availabi­lity: target value in % Communi­cation service reliabi­lity (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 monito­ring (Note 2)> 99.999 9< 1 year (>> 1 month)< 100 ms< 1 Mbit/sUplink~1,00050 msTransfer Interval< 50010/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.
Up

7.6  High data rate and low latency |R17|Word‑p. 80

7.6.1  AR/VRWord‑p. 80

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.
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.
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 to120fps content.99.99 % in uplink and 99.9% in downlink (Note 4)Stationary or PedestrianCountry­wide
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 Pedestrian20 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.
Up

7.7  KPIs for UE to network relaying in 5G system |R17|Word‑p. 81

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.
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/s500 Mbit/s10 ms5 Gbit/s/ home2 Gbit/s /home50 devices /house10m x 10m - 3 floors10 m indoor2 to 3
Factory Sensors (Note 2)100 kbit/s5 Mbit/s50 ms to 1 s1 Gbit/s /factory50 Gbit/s /factory10,000 devices /factory100m x 100m30 m indoor / metallic2 to 3
Smart Metering (Note 3)100 bytes / 15 mins100 bytes / 15 mins10 s200 x 100 bytes / 15 mins /hectare200 x 100 bytes / 15 mins /hectare200 devices /hectare100 m x 100 m> 100 m indoor / deep indoor2 to 5
Containers (Note 4)100 bytes / 15 mins100 bytes / 15 mins10 s15,000 x 100 bytes / 15 mins /ship15,000 x 100 bytes / 15 mins /ship15,000 containers /ship400 m x 60 m x 40 m> 100 m indoor / outdoor / metallic3 to 9
Freight Wagons100 bytes / 15 mins100 bytes / 15 mins10 s200 x 100 bytes / 15 mins /train200 x 100 bytes / 15 mins /train120 wagons /train1 km> 100 m outdoor / tunnel10 to 15
Public Safety (Note 5)12 Mbit/s12 Mbit/s30 ms20 Mbit/s /building40 Mbit/s /building30 devices /building100 m x 100 m - 3 floors> 50 m indoor (floor or stairwell)2 to 4
Wearables (Note 6)10 Mbit/s10 Mbit/s10 ms20 Mbit/s per 100 m220 Mbit/s per 100 m210 wearables per 100 m210 m x 10 m10 m indoor / outdoor1 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.
Up

7.8  KPIs for 5G Timing Resiliency |R18|Word‑p. 82

The 5G system shall be able to support a holdover time capability with timing resiliency performance requirements defined in Table 7.8-1.
Use case Holdover time (note 3) Sync target Sync accuracy Service area Mobility Remarks
Power grid (5G network)Up to 24 hourUTC (note 1)<250 ns to1000 ns (note2)< 20 km²lowWhen 5G System provides direct PTP Grandmaster capability to sub-stations
Power grid (time synchronization device)>5 sUTC (note 1)<250 ns to1000 ns (note2)< 20 km²lowWhen 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.
 
Type of trading activity Maximum divergence from UTC Granularity of the timestamp (note 1)
Activity using high frequency algorithmic trading technique100 μs≤1 μs
Activity on voice trading systems1 s≤1 s
Activity on request for quote systems where the response requires human intervention or where the system does not allow algorithmic trading1 s≤1 s
Activity of concluding negotiated transactions1 s≤1 s
Any other trading activity1 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.
Up

7.9  KPIs for ranging based services |R18|Word‑p. 83

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 Figure 6.36.1-1.
  • 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.
Ranging scenario Ranging Accuracy
(95 % confidence level)
Availability Latency 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 Remoter10cm 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 %50ms10mIC/PC/OOCLOSStatic/ Moving
(<1m/s)
50ms--
Picture and video sharing based on Ranging results10cm99 %50ms10mIC/PC/OOCLOSStatic/ Moving
(<1m/s)
50ms--
Distance based smart device control10cm-99 %100ms20mIC/PC/OOCLOSStatic/ Moving
(<1m/s)
50ms20-
Smart Vehicle Key10 cm-99 %50ms30mIC/PC/OOCLOSStatic/ Moving
(<2m/s)
25ms-50UEs/ (104m²)
Touchless Self-checkout Machine Control10cm-99%150ms1mIC/PC/OOCLOSStatic/ Moving
(<1m/s)
100ms-=
Hands Free Access10cm-99 %500ms10 mIC/PC/OOCLOSStatic/ Moving
(1 m/s)
50ms-20 UEs/3.14*100m²
Smart Transportation Metro/Bus Validation10cm-99 %-2mIC/PC/OOCLOSStatic/ Moving
(3km/h)
50ms20100 in the area of 8 m²
Ranging of UE's in front of vending machine20cm10°-1s5mIC/PC/OOCLOSStatic/ Moving
(<1m/s)
50ms-10
Finding Items in a supermarket50 cm5 degree95 %-100mIC/PC/OOCLOSStatic/ Moving
(<1m/s)
250ms-100 UEs/ (3.14*104m²)
distance based intelligent perception for public safety50cm-99 %-20mIC/PC/OOCLOSStatic/ Moving
(<20km/h)
-100-
Long Distance Search20m99 %-100m-1kmIC/PC/OOCLOSStatic/ Moving
(up to 10m/s)
5s--
Long range approximate location[10m]±[12.5°]99 %-500mIC/PC/OOCLOSStatic/ Moving
(<10m/s)
-1[50]UEs/ (104m²)
 
Up

7.10  KPIs for AI/ML model transfer in 5GS |R18|Word‑p. 86

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.
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 ms1.08 Gbit/s0.27 MByte99.999 %99.9 %99.999 %Split AI/ML image recognition
100 ms1.5 Mbit/s100 ms150 Mbit/s1.5 MByte /frameEnhanced media recognition
4.7 Mbit/s12 ms320 Mbit/s40 kByteSplit 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.
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
1s1.1Gbit/s138MByte99.999 %99.9% for data transmission of model weight factors; 99.999% for data transmission of model topologyAI/ML model distribution for image recognition
1s640Mbit/s80MByte99.999 %AI/ML model distribution for speech recognition
1s512Mbit/s(see note 1)64MByteParallel download of up to 50 AI/ML modelsReal time media editing with on-board AI inference
1s536MByteup to 5000~ 10000/km2 in an urban areaAI model management as a Service
1s22Mbit/s2.4MByte99.999 %AI/ML based Automotive Networked Systems
1s 500MByteShared AI/ML model monitoring
3s450Mbit/s170MByteMedia 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.
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
1s1.0Gbit/s1.0Gbit/s132MByte132MByteUncompressed Federated Learning for image recognition
1s80.88Mbit/s80.88Mbit/s10Mbyte10Mbyte TBDCompressed Federated Learning for image/video processing
1sTBDTBD10MByte10MByteData Transfer Disturbance in Multi-agent multi-device ML Operations
Up

7.11  KPIs for tactile and multi-modal communication service |R18|Word‑p. 87

The 5G system shall support tactile and multi-modal communication services with the following KPIs.
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 server)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 Pedestriantypically
< 100 km²
(note 5)
Haptic feedback
5 ms< 1Mbit/s99.99%
[40]
1500Stationary or Pedestriantypically
< 100 km²
(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/s99.9%
[40]
1500Stationary or Pedestriantypically
< 100 km²
(note 5)
Video
10 ms5-512 kbit/s99.9%
[40]
50Stationary or Pedestriantypically
< 100 km²
(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 Pedestriantypically
< 100 km²
(note 5)
Haptic feedback
Remote control robot1-20ms16 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 km²Haptic feedback
20-100ms16 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 km²Haptic feedback
5 ms1-100 Mbit/s99.999%
[40]
1500Stationary or Pedestrian≤ 1 km²Video
5 ms5-512 kbit/s99.9%
[40]
50-100Stationary or Pedestrian≤ 1 km²Audio
5 ms< 1Mbit/s99.999%
[40]
-Stationary or Pedestrian≤ 1 km²Sensor information
Skillset sharing low- dynamic robotics (including teleoperation) Controller to controlee5-10ms0.8 - 200 kbit/s (with compression)99,999%
[40] [45]
1 DoF: 2-8
3 DoFs: 6-24
6 DoFs: 12-48
Stationary or Pedestrian100 km²Haptic
(position, velocity)
Skillset sharing low- dynamic robotics (including teleoperation) Controlee to controller5-10ms0.8 - 200 kbit/s (with compression)99,999%
[40] [45]
1 DoF: 2-8
10 DoFs: 20-80
100 DoFs: 200-800
Stationary or Pedestrian100 km²Haptic feedback
10ms1-100 Mbit/s99,999%
[40] [45]
1500Stationary or Pedestrian100 km²Video
10ms5-512 kbit/s99,9%
[40] [45]
50Stationary or Pedestrian100 km²Audio
Skillset sharing Highly dynamic/ mobile robotics Controller to controlee 1-5ms16 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-dynamic4 km²Haptic
(position, velocity)
Skillset sharing Highly dynamic/ mobile robotics Controlee to controller1-5ms0.8 - 200 kbit/s99,999% (with compression)
99,9% (w/o compression)
[40] [45]
1 DoF: 2-8
10 DoFs: 20-80
100 DoFs: 200-800
high-dynamic4 km²Haptic feedback
1-10ms1-10 Mbit/s99,999%
[40] [45]
2000-4000high-dynamic4 km²Video
1-10ms100-500 kbit/s99,9%
[40] [45]
100high-dynamic4 km²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 km²
(note 5)
Haptic feedback
<400 ms
[39]
1-100 Mbit/s99.999 %
[40]
1500Stationary or Pedestrian≤ 100 km²
(note 5)
Video
<150 ms
[39]
5-512 kbit/s99.9 %
[40]
50Stationary or Pedestrian≤ 100 km²
(note 5)
Audio
<300 ms600 Mbit/s99.9 %
[40]
1500Stationary or Pedestrian≤ 100 km²
(note 5)
VR
Immersive multi-modal navigation applications Local Site → Remote Site (UL)<300 ms12 kbit/s
[26]
99.999 %
[40]
1500Stationary or Pedestrian≤ 100 km²
(note 5)
Biometric / Affective
<400 ms
[39]
1-100 Mbit/s99.999 %
[40]
1500Workers: Stationary/ or Pedestrian, UAV: [30-300mph]≤ 100 km² (note 5)Video
<150 ms
[39]
5-512 kbit/s99.9 %
[40]
50Stationary or Pedestrian≤ 100 km²
(note 5)
Audio
<300 ms600 Mbit/s99.9 %
[40]
1500Stationary or Pedestrian≤ 100 km²
(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.
Up

Up   Top   ToC