Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 22.261  Word version:   17.2.0

Top   Up   Prev   Next
0…   4…   6…   6.4…   6.8…   6.12…   6.22…   6.26…   7…   8…   A   B   C   D…   F…

 

7  Performance requirementsWord-p. 47
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.
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.

Up
7.2  Low latency and high reliabilityWord-p. 48
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 may 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.
Up
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 TS 22.104.
  • V2X can be found in TS 22.186.
  • Rail communications can be found in TS 22.289.
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 may also be deployed in wider areas (e.g. city- or country-wide networks), access to them may be limited to authorized users, and they may 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 may be limited to authorized users, and they may 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 (mainly medium and high voltage). Electricity distribution is characterized by high requirements on the communications service availability. In contrast to the above use cases, electricity distribution is deeply immersed into the public space. Since electricity distribution is an essential infrastructure, it will, as a rule, be served 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].
Up
7.2.3  Other requirementsWord-p. 49
7.2.3.1Void
7.2.3.2  Wireless road-side infrastructure backhaul [R16]
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.
To support wireless road-side infrastructure backhaul the 5G system shall support the performance requirements in Table 7.2.3.2-1.
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 may 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.

Up
7.3  High accuracy positioningWord-p. 52
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 [R16]
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.
Up
7.3.2.2  Requirements for Horizontal and Vertical positioning service levels [R16]
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.
Positioning service level
Absolute(A) or Relative(R) positioning
Accuracy (95 % confidence level)
Horizontal Accuracy
Vertical Accuracy (note 1)
Positioning service availability
Positioning service latency
Coverage, environment of use and UE velocity
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 others (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).

Up
7.3.2.3  Other performance requirements [R16]Word-p. 54
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 may only be achievable at the expense of a relaxation of some other performances (e.g. horizontal accuracy may 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.
The 5G system shall support positioning technologies that allow the UE to operate at Service Level 1 for at least 12 years using less than 1800 mWh of battery capacity, assuming multiple position updates per hour.
NOTE 2:
This requirement aims energy-efficient positioning technologies draining a minimal energy on the UE battery. It derives from use cases, such as asset tracking, with a small form-factor battery representative of an IoT device. This requirement may translate into an energy consumption for the UE's positioning functions in the order of 20 mJ per fix.
NOTE 3:
This requirement does not preclude the use of higher energy consumption to fulfil higher position update rates than the one above, or other KPIs than those of Service Level 1 (e.g. more accurate service levels).
Up
7.4  KPIs for a 5G system with satellite access [R16]
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 associated with these orbits ranges, for the UE to the satellite path, can be summarized in the following table:
UE to satellite Delay [ms]
Min
Max
One-Way Max propagation delay [ms]

LEO
3
15
30
MEO
27
43
90
GEO
120
140
280

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%.
Up
7.5  High availability IoT traffic [R17]Word-p. 55
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.
Up
7.5.2  RequirementsWord-p. 56
Profile
Characteristic parameter
Communication service availability: target value in %
Communication service reliability (Mean Time Between Failure)
End-to-end latency: maximum
Bit rate
Direction
Influence quantity
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 - 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.

Up
7.6  High data rate and low latency [R17]Word-p. 57
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-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 conversations 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-5 ms] for audio delayed and
  • in the range of [45 ms-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)
Max Allowed End-to-end latency
Service bit rate: user-experienced data rate
Reliability
Influence quantity
# of UEs
UE Speed
Service Area (note 2)

Cloud/Edge/Split Rendering (note 1)
5ms (i.e. UL+DL between UE and the interface to data network) (note 4)
0.1-[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
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 to120fps 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)
Consume VR content via tethered VR headset (note 6)
[5 -10] ms (note 5)
0.1-[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 may 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. 58
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/s
500 Mbit/s
10 ms
5 Gbit/s/ home
2 Gbit/s /home
50 devices /house
10 mx10m - 3 floors
10 m indoor
2 - 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
100m x 10 0m
30 m indoor / metallic
2 - 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 - 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 - 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 - 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 - 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 - 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 - 70 houses per hectare.
NOTE 4:
A large containership with a mix of 20 ft and 40 ft 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 may 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 may be concrete walls / floors between the devices.
NOTE 9:
All the values in this table are example values and not strict requirements.

Up

Up   Top   ToC