WP 5G 5G Traffic Model For Industrial Use Cases 22.10.19

White Paper
A 5G Traffic Model
for Industrial Use Cases
November 2019
5G Alliance for Connected Industries and Automation
5G Traffic Model for Industrial Use Cases
Contact:
Email: info@5g-acia.org
www.5g-acia.org
Published by:
ZVEI – German Electrical and
Electronic Manufacturers’ Association
5G Alliance for Connected Industries and Automation
(5G-ACIA), a Working Party of ZVEI
Lyoner Strasse 9
60528 Frankfurt am Main, Germany
www.zvei.org
November 2019
Graphics: ZVEI
The work, including all of its parts, is protected
by copyright. Any use outside the strict limits of
copyright law without the consent of the publisher is
prohibited. This applies in particular to reproduction,
translation, microfilming and storage and processing
in electronic systems.
Despite the utmost care, ZVEI accepts no
liability for the content.
Contents
1 Abstract 5
2 Terms and definitions 5

2.1 Local application function 5
2.2 Communication function 5
2.3 Service access point and logical endpoints 5
2.4 Logical link 6
2.5 Reference interface 6
3 Use cases and traffic types 7
3.1 Deterministic periodic traffic 7
3.2 Non-deterministic traffic and burst traffic 9
3.3 Traffic types and usage examples 10
4 Reference interface when applied to 5G networks 11
4.1 Multiple application functions 11
4.2 Communication methods 12
4.3 Radio communication direction 12
5 Traffic model attributes 13
5.1 Traffic-related attributes 13
5.1.1 Message size 13
5.1.2 Transfer interval 13
5.1.3 Data rate 13
5.2 Network-related attributes 13
5.2.1 Radio link direction 13
5.2.2 Communication paths 14
6 Mobility model 14
7 Conclusion and outlook 15
8 References and abbreviations 15
9 Annex A.1:
Traffic model applied to example use cases 16
9.1 Use case: motion control, mobile controller 18
9.2 Use case: closed loop control, mobile I/O gateway 18
9.3 Use case: Process monitoring 19
9.4 Use case: Mobile robot 20
9.5 Use case: human-machine interface (HMI) 20
9.6 Use case: Closed-loop control for process automation 21
9.7 Use case: Control-to-control 22
10 Annex A.2:
Distributed devices in an example factory 24
11 5G-ACIA members 26
3
4
1 Abstract
Applications in industrial automation systems have stringent requirements regarding
latency and reliability. These requirements are already met by current communication sys-
tems, mostly based on wired technologies. To determine whether a wired system can be
replaced by a wireless 5G system or not, it is necessary to analyze the actual data volumes
and traffic types of industrial use cases. To accurately predict network load, a realistic
trafﬁc model is required to enable performance evaluation and design of the correspond-
ing communications systems. The communication requirements of selected use cases must
therefore be analyzed, modelled and validated.
This white paper describes a 5G user data traffic model for industrial use cases employing
a 3GPP-compliant radio network. The traffic is modelled by a set of parameters relevant to
the design and dimensioning of 5G networks.
These traffic model parameters give both network service providers (SPs) and network ser-
vice users/operational technology (OT) companies to a common method of describing the
projected 5G traffic. Based on these mutually agreed parameters, SPs can assess and install
necessary spectrum and network resources for the 5G networks offered to OT companies.
The traffic model will focus on use case categories of high priority for industrial automa-
tion, process automation and inbound (production) logistics.
2 Terms and definitions

This is a list of the most important terms and definitions used in this white paper.
• Where not otherwise indicated, definitions are from 5G-ACIA
• Some are based on existing definitions but slightly amended by 5G-ACIA, i.e. for
greater clarity. This is indicated accordingly, and the source of the underlying definition
is given
• Direct citations are in italics and parentheses, and the source is given
• Where a term is defined in detail later in this white paper, reference is simply made to
the corresponding section
2.1 Local application function

Hardware and/or software of a device that is a local element of a distributed application.
2.2 Communication function

Hardware and software of a device that implements the communication stack and reference
interface.
2.3 Service access point and logical endpoints

The service access point (SAP) allows user data to be exchanged between a local application
function and a communication function.
The SAP uses logical endpoints within the communication function, namely a logical source
endpoint (LSEP), via which the local application function sends data to the communication
function, and a logical target endpoint (LTEP), via which the local application function
receives data from the communication function.
5
The LSEP and LTEP may have differing communication characteristics, e.g. with respect to
data volumes, latency, etc.
Within a radio network, the LSEP and LTEP can be mapped to radio up- and down-link data
transmission, respectively.
2.4 Logical link

According to IEC 62657, a logical link is an: “Application oriented communication rela-
tionship which enables the transmission of user data between one logical end point of the
reference interface in a source device and one logical end point of the reference interface
in a target device”. (Source: IEC 62657 4, 3.1.2)
A logical link comprises a pair of SAPs that communicate with each other, as depicted in
Figure 1.
2.5 Reference interface

The reference interface is the exposed interface between the local application function and
the communication function. In the case of a 5G network, the communication function
can be implemented in a UE or in a network node. The reference interface is the interface
between the UE or the wired network node on the one side and the application functions
on the other; its actual implementation is manufacturer-dependent (AT commands, PCIe,
USB, serial i/f, etc).
A reference interface can include more than one SAP, and/or more than one source and/or
target logical endpoint.
Fig. 1: Reference interface and logical link
Local application Local application

function function
SAP SAP
Reference interface Reference interface
LSEP LTEP LSEP LTEP
Communication Communication
function function
Logical link
Communication network
Source: 5G-ACIA / ZVEI
6
3 Use cases and traffic types
The most important use cases with their varying demands on the communications network
have been prioritized and described in [1] 3GPP TS 22.104 Annex 2. This traffic model
addresses the use cases encountered in factory and process automation, human-machine
interfaces and production IT, logistics and warehousing, and monitoring and maintenance.
However, due to the generic nature of the traffic model, it can also be employed to describe
and quantify traffic patterns of use cases applicable to other vertical domains such as rail-
bound mass traffic and electric power distribution and central power generation.
Use cases explicitly addressed by this white paper:
• Motion control
• Control-to-control communication
• Mobile control panels with functional safety applications
• Control-to-sensor/actuator communications
• Mobile robots and automated guided vehicles (AGVs)
• Remote access and maintenance
• Augmented reality
• Closed-loop process control
• Process monitoring
• Plant asset management
These use cases display diverse traffic behavior, ranging from periodically generated mes-
sages with small data volumes to aperiodic messages with, in some instances, very large
data volumes. This section describes the data traffic types characteristic of industrial use
cases. These traffic types are employed as the basis for defining parameters that describe a
traffic model applicable to all use cases given above.
The parameters that describe the traffic model are defined and detailed in section 5 below.
3.1 Deterministic periodic traffic

Messages for automation control loops and process control use cases are typically deter-
ministic periodic traffic.
Applications with this traffic type send messages at defined time intervals. These applica-
tions also expect to receive messages with predictable latency at the same defined transfer
intervals. Acceptable latency and tolerable latency jitter depend on the particular applica-
tion and use case, and are not described by the traffic model given in this white paper.
Deterministic periodic traffic can be specified using the parameters of message size and
transfer interval.
A subset of this traffic type is deterministic time-triggered traffic. This can occur when local
instances of a distributed application function do not have synchronized clocks. If the local
instances of the distributed applications share a global clock time, deterministic time-
triggered traffic of high precision is not required.
Deterministic time triggered traffic can also be specified using the parameters of message
sizeand transfer interval. Therefore, from a traffic model viewpoint these parameters do not
differ from those of the generic deterministic periodic traffic type. A graphical representa-
tion of this traffic type is given below.
7
Fig. 2: Periodic traffic
Average
user
data
length
Message
Message
Message
Message
Message
Message
time
Transfer
interval
Sizes of messages for a local application function may vary depending on the particular
use case. Moreover, the transfer interval may vary, especially for deterministic time trig-
gered traffic. For the sake of simplicity, these variations are not considered in the present
traffic model. However, for more detailed simulation of network behavior such variance
may be of importance. Deterministic aperiodic traffic is own section i.e. 3.2
Messages generated e.g. by process events are typically deterministic aperiodic. This traffic
type consists of messages that are sent regularly but aperiodically, i.e. there is no defined
transfer interval between messages.
Deterministic aperiodic traffic can be specified using the parameters of message size and
transfer interval, whereas the transfer interval is an average value and not a defined value
as for deterministic periodic traffic. Below is a graphical representation of this traffic type
with messages of average size sent by an application regularly but not with a constant
transfer interval.
Fig. 3: Aperiodic traffic
Average
user
data
length
Message
Message
Message
Message
time
Transfer Transfer
interval interval
Similar to deterministic periodic traffic, message size may vary.
More detailed modeling of the statistical variation of this attribute may be needed for e.g.
simulations and detailed evaluations.
8
3.2 Non-deterministic traffic and burst traffic
Non-deterministic traffic can be periodic or aperiodic. Messages of this traffic type are not
expected to be received at the target endpoint within a specified time frame (transmission
time) or within a specified time period between two consecutive messages (update time).
The minimum requirement is that messages are correctly received and in the correct order.
Burst traffic is characterized by a sequence of successive messages that are sent in a

“burst”, for example to transmit images. Bursts can be periodic or aperiodic. Burst mes-
sages are not expected to be received at the target endpoint within a specified time frame
(transmission time).
Non-deterministic and burst traffic can be specified using the parameters of average data
rate and peak data rate. A graphical representation of this traffic type is given below.
Fig. 4: Non-deterministic traffic
Peak
data range
Burst
Average
data range
time
9
3.3 Traffic types and usage examples
In the table below there are some example use cases extracted from TS 22.104 for each of
the above described traffic types.
Table 1: Traffic pattern types
Traffic type Example
Deterministic traffic
Periodic and time- Sensor-to-controller messages sent periodically between synchroni-

triggered periodic zed, time-sensitive applications.
For example a pressure sensor sending values to a machine PLC, or
emergency stop signals from hand-held controllers being sent to a
machine PLC.
Controller-to-actuator messages sent periodically, e.g. a PLC sends
commands to a motor drive.
Aperiodic Sensor-to-controller messages sent e.g. on detected status changes
or value changes between non-synchronized, time-sensitive, applica-
tions.
for example, an optical sensor sending positional information to a
conveyor belt PLC.
Controller-to-actuator messages sent aperiodically, e.g. a light cur-
tain PLC sending a stop command to a mobile robot
Non-deterministic and burst traffic

Periodic Client/server traffic between non-synchronized, non-latency-critical
applications, e.g. high-resolution cameras sending images to a pat-
tern recognition server.
Aperiodic Client/server traffic with non-latency-critical characteristics, e.g. soft-
ware updates, test report uploads, screwdriver torque documentation,
etc.
It should be noted that there are a range of other communication parameters, such as
service reliability, service availability, latency and latency jitter, that are of crucial impor-
tance to many use cases as outlined in [1]. However, these characteristics are not covered
by this traffic model. They are determined by the implemented network technology, by the
quantity of deployed (dedicated) resources and by the radio access network (RAN) design.
10
4 Reference interface when applied to 5G networks
4.1 Multiple application functions
The traffic model defined in this white paper defines and describes the traffic as observed
at the reference interface of each local application function. There may be multiple local
application functions interfacing with a single communication function; the local applica-
tion function may also have more than one SAP (depending on how the function is imple-
mented).
A communication function can act as an I/O gateway that aggregates traffic from multiple
local application functions; these local application functions operate independently of each
other and will, in most cases, have differing traffic types. Therefore, the traffic for each
local application function must be modelled separately. When the communication function
aggregates traffic from multiple applications, all logical links will be transmitted across the
5G network via one or several concurrent radio connections. Whether one or more radio
connections are used depends on the communication function’s (i.e. a UE or a network
node) capabilities and on configuration parameters.
Figure 5 below depicts a deployment scenario where (left-hand side) three local application
functions interface with a single communication function. Each local application function
communicates with a peer application function at the remote end (right-hand side) via
a logical link. At the remote end, two local application functions interface with a shared
communication function, while the third one interfaces with a communication function of
its own. The remote communication functions are in most cases wired network nodes that
reside outside of the 5G network.
As depicted in Figure 5, this traffic model only describes reference interfaces for commu-
nication functions that are UEs. Wired terminals do not contribute to radio traffic and are
therefore not relevant to this model.
Figure 5: Deployment of logical application functions
Traffic model shope

Local Local Local Local Local Local
application application application application application application
function function function function function function
SAP SAP SAP SAP SAP SAP
Reference interface
LSEP LTEP LSEP LTEP LSEP LTEP LSEP LTEP LSEP LTEP LSEP LTEP
Communication Communication Commu-

function function nication
function
Logical link
Logical link
Logical link
Communication network
11
Only those local application functions and reference interfaces are of relevance to this traf-
fic model that interface with a UE-type communication function. When a communication
function is not a UE (i.e. it has no radio interface) if will not contribute to radio traffic, and
therefore has no relevance to the traffic modeled and observed within a 5G network.
All messages sent from the LSEP and/or received from the LTEP are transmitted via the
reference interface to/from the communication function, which relays the traffic via the
communications network to its destination. The communication function will add some
overhead from the 5G network protocol stack (see 3GPP 23.501). For this reason message
sizes and the quantity of messages observed at lower layers in the 5G network may be sig-
nificantly larger than those seen at the reference interface.
Messages at the reference interface can have L2 Ethernet or L3 IP frame structures – in both
cases, message sizes referred to in this traffic model include the protocol overhead imposed
by Ethernet and/or IP headers.
4.2 Communication methods

Logical links between application functions can be implemented by means of various com-
munication paths and methods available within a 5G network:
• Point-to-point (P2P): a message has a unique destination/source address and is trans-
mitted over the communications network
• Device-to-device (D2D): a message has a unique destination/source address and is
transmitted directly from one device to another device, not via the communications
network; the communication functions have a direct radio connection.
• Point-to-multipoint (P2M): a message has a unique source address, while the destina-
tion is a multicast or broadcast address. Multipoint messages are broadcast by the radio
network and therefore applicable for LTEP, i.e. for DL direction only.
4.3 Radio communication direction

A further 5G network-related communication characteristic of paramount importance is
whether messages are sent or received, i.e. whether they are sent via uplink (UL), from the
UE to the network, or via downlink (DL), from the network to the UE (see Figure 6 below).
Messages sent by a LSEP are transmitted via the UE uplink, while messages received by a
LTEP are transmitted via the downlink.
Fig. 6: Mapping of LSEP/LTEP to UL and DL directions.
SAP Local application

function
Reference interface
LSEP LTEP
ul, k
upl lin
ink
down
dl, Communication
function
Communication
network
12
5 Traffic model parameters
The primary purpose of the traffic model is to provide a basis for assessing required net-
work resources, i.e. what resources are needed to sustain a certain number and density of
devices with a certain traffic pattern.
Due to the nature of the local application functions, it can be assumed that 5G signaling
traffic (e.g. traffic for UE authentication, hand-over, connection establishment, etc.) is neg-
ligible and does not have to be modeled with specific parameters.
5.1 Traffic-related parameters
5.1.1 Message size

The message size is the number of bytes that are transferred between the local application
function and the communication function at the reference interface. The message size is
primarily determined by the application. However, if, for example, Ethernet frames are
used by the local application function the minimum message size is 64 bytes. When IP
frames are used the IP (v4 or v6) frame structure will determine the minimum message size.
Message size is given for each logical link separately. Within a logical link the message size
may vary, depending on whether a message is being sent or received by the local applica-
tion function via LSEP and LTEP, respectively.
5.1.2 Transfer interval

The transfer interval is the time between two consecutive transfers of user data between
the local application function and the communication function via the reference interface.
Transfer intervals are given for each logical link and may vary, depending on whether mes-
sages are being sent or received.
5.1.3 Data rate

The data rate is the specific number of bytes transferred between the local application
function and the communication function via the logical endpoint within a specific time
interval, e.g. a second.
This parameter is typically given as follows:

• average data rate, measured over an extended time period (e.g. an hour); this value
indicates the average load a network will have to support, and
• peak data rate, measured over a short time period (e.g. 1 to 10 seconds);
• Average and peak data rates are given for each logical link and may vary depending
on whether data is being sent or received. Similar to the message size, the data rate
includes L2 and L3 header overhead.
5.2 Network-related parameters
5.2.1 Radio link direction

Data can be sent from the local application function or received by the local application
function, as outlined in the logical endpoint definition. Where the local application func-
tion sends data, it is transferred via the radio uplink, when data is received, it is transferred
via the downlink.
13
5.2.2 Communication paths
All parameters described in the sections above are applicable to P2Pand D2D communica-
tion paths.
P2P – messages are sent and received via the UL and DL using individual addresses. When
an application sends information to multiple receivers, each message must be sent indi-
vidually to each receiver.
D2D – messages are sent from one device to another device directly using the 3GPP side-
link mechanism without using the resources of the communications network. Setting-up the
D2D connection via the communications network imposes a traffic load that is negligible
since the D2D connection is expected to be of extensive duration (hours or even days).
P2M – messages are sent from a device to multiple other devices. The sending device uses
a P2P path to the network, while the network used P2M over the radio DL towards the
receivers.
6 Mobility model
Awareness of device mobility is important when modelling user data traffic, in particular
with regard to: 
• Handover probability 
• Load variation across cells  
• Receive power variation for both the uplink and the downlink 
In an advanced, flexible factory, many assets containing 5G devices, such as mobile robots
and many tools and machines, can change location. In addition, automated guided vehicles
(AGV) are commonly deployed to move items between machines. It is also highly likely
that workers are connected to the factory network. Some vehicles, in particular AGVs, may
be restricted to predefined corridors. However, some 5G devices may not be mobile at all.
These are excluded from the mobility model.
Also excluded are devices that only move within a very limited geographical area of a few
meters, such as e.g rotating devices with sensors/actuators in a motion control system of a
machine. Devices of this kind typically have little impact on the handover probability, load
variation across cells, or receive power variation.
The traffic model needs to define the following additional parameters:

Average distance between mobile devices: This parameter is employed to model the
number of devices present in a given geographical area. The distance between devices is
expressed as an exponential random variable with the average equal to this parameter.
Mobile device type: Mobile device types are characterized by their size, velocity and their
planned trajectory. It is also important that the traffic model includes the time when the
device is not moving (pause). For example, this occurs when an AGV is loading or unloading
items. In addition, some types may be restricted to certain areas of the factory. Examples
are given in Table 2.
Mobile device heterogeneity: This parameter describes the statistical distribution of

mobile device types within a factory or within a certain area of the factory.
14
Table 2: Example mobile device types
Velocity Restricted Predefined Pause time
Device type [km/h] area path [s]
Drones 15-50 no yes 0-50
Connected worker 5-10 yes no 5-3600
Connected workpieces 1-15 yes yes 5-3600
AGVs 1-50 yes yes 5-3600
Mobile robots 1-15 yes yes 5-3600
7 Conclusion and outlook

This white paper presents a traffic model that can be used by OT companies and by 5G ser-
vice providers as a mutually agreed method to describe expected radio traffic. The model
must be applied to each use case individually, taking into account the specific characteris-
tics of the use case and corresponding application functions.
While a more generic traffic model would comprise a large number of parameters, this traf-
fic model comprises only those parameters relevant to a wireless 5G network, i.e. relevant
to assessing required network resources.
A reference interface is described where all parameters of this traffic model can be unam-
biguously defined and, depending on the specific device implementation, measured.
In its present version, the majority of traffic model parameters are defined using average
values. In actual use case implementations, the values may vary significantly; such vari-
ations may have an impact on 5G network dimensioning and design. In a next release of
this white paper, the traffic model will be enhanced with a description of such variations.
Last but not least it should be noted that this traffic model is not, on its own, sufficient to
assess the required frequency bandwidth of a 5G network. This assessment would require
more in-depth analysis of e.g. the geographical topology, radio access network design,
frequency range, etc.
8 References and abbreviations

UL Uplink
DL Downlink
UE User equipment
HMI Human-machine interface
P2P Point to point
P2M Point to multipoint
D2D Device to device
LSEP Logical source endpoint
LTEP Logical target end point
SAP Service access point
[1] 3GPP TS 22.104
[2] 3GPP TS 23.501

15
9 Annex A.1: Traffic model applied to example use cases
As a guide to companies implementing real-world industrial use cases with 5G networks,
this appendix applies the traffic model described in this white paper to a number of exam-
ple use cases. To this end, the use cases defined in 3GPP 22.104 have been employed. It
should be noted that the examples represent just a few typical use cases and make no claim
to be comprehensive.
For real-world deployments, the applicability of the use cases described must be considered
from both a technical and economic viewpoint. Not all use cases will justify 5G radio access.
This white paper does not consider economic goals or constraints. It is assumed that all
devices for the respective use cases are operating in environments which require wireless
communications. This is most clearly the case for mobile robots and AGVs.
The generic template given below contains all traffic model parameters that must be popu-
lated with values in line with the specific use case. This template is used for each applica-
tion function that participates in data communication over the radio interface of a 5G
network. The generic template includes four logical links. However, in real-world scenarios,
the number of logical links is unlimited and must be tailored to the specific use case. A
device connected to a single sensor will only require a single logical link to be depicted,
while a device connected to 100 sensors will generally be modeled by means of 100 logical
links. However, in this latter case, if multiple sensors display identical behavior, they can
be modeled in aggregate by means of a single logical link.
16
Table 3: Generic traffic model template
Attributes Logical Link 1 Logical Link 2 Logical Link 3 Logical Link 4 Comments/
LSEP LTEP LSEP LTEP LSEP LTEP LSEP LTEP explanations
Transfer Interval A use case may need
Explanation: This is the more that one logical
average time interval links in case e.g. more
(in ms) when a user Sensors/Actuators
data message is sent (or controllers) are
(LSEP)from the local connected to a single
application function cellular IO/GW, i.e.
to the communication only the IO/GW has a
function (uplink), or radio i/f but not each
received (LTEP) from the S/A.
communication function
(LTEP, downlink).
Note 1: This is the
Periodic Traffic „Transfer Interval of
vertical application“ Ref
TS 22.104 Figure C5-2
Note 2: This is not the
latency!
Message Size Periodic and
Explanation: This is the aperiodic&Burst
value in bytes of the Traffic attributes are
average user data frame mutually exclusive for
including the Ethernet a single logical link.
and/or IP header. A use case may re-
Note 3: Message sizes quire both periodic
may differ for sending and aperiodic traffic,
and receiving directions in which case thos
traffic type will be
Data Rate modelled in different
average logical links.
peak
Explanation: This is
the value in bytes of
Aperiodic and the average user data
Burst frame including the
Ethernet and/or IP
Traffic header.
Note 3: Message sizes
may differ for sending
and receiving
directions
Radio Link Direction uplink downlink uplink downlink uplink downlink uplink downlink The attributes ‚Radio
Explanation: data can Link Direction‘ and
be sent from the mobile ‚Communication Path‘
device to the radio apply to both periodic
network and aperiodic traffic
(LSEP, uplink) or is types.
received from the radio
network (LTEP, down-
All Traffic link)
Communication Path P2P P2P P2P P2P P2P P2P P2P P2P
Explanation: data can
be transferred via the
network, or from one
device to another device
omitting the network
Traffic volume (kbit/s)

Sum uplink 00,00
Sum downlink 00,00
17
9.1 Use case: motion control, mobile controller
In this use case, a controller with radio network connectivity communicates with two remote
sensors (logical links 1 and 2) and with a remote actuator (logical link 3). The two sensors
send a message of small size every 1 ms to the controller. The controller sends a command
to the actuator every 10 ms and receives an acknowledgement in return.
Small-sized messages might potentially be just a few bytes in length. However it is assumed
that they are transmitted as L2 frames over the reference interface (Figure 1) with 64 bytes
as the minimum size.
With these assumed values for the traffic model parameters, the controller would be
expected to generate traffic over the radio interface of 50 kbit/s for the uplink and 1550
kbit/s for the downlink.
Table 4: Motion control

Transfer Interval 1,00 1,00 1,00 10,00 10,00
Periodic Traffic
Message Size 64 64 64 64 64
Data Rate
average
Aperiodic and
peak
Burst Traffic
Radio Link Direction uplink downlink uplink downlink uplink downlink uplink downlink
All Traffic

Sum uplink 50,00
Sum downlink 1.550,00
9.2 Use case: closed loop control, mobile I/O gateway

A mobile I/O gateway with radio network connectivity connects locally (wired) to two sen-
sors (logical link 1 and 2) and one actuator (logical link 3) and communicates with a remote
controller. The two sensors send a small-sized message every 1 ms via the I/O gateway to
the remote controller; these messages are not acknowledged by the remote controller. The
actuator receives a medium-size (256 byte) message from the remote controller every 1 ms,
and acknowledges that message with a small-sized message of its own.
With these assumed values for the traffic model parameters, the I/O device will generate
traffic over the radio interface of 1500 kbit/s on the uplink and 2000 kbit/s on the down-
link.
18
Table 5: Close Loop Control
Transfer Interval 1,00 1,00 1,00 1,00
Periodic Traffic
Message Size 64 64 64 256
Data Rate
average
Aperiodic and
peak
Burst Traffic
All Traffic

Sum uplink 1.500,00
9.3 Use case: Process monitoring

A mobile I/O gateway with radio network connectivity connects locally (wired) to two sensors
(logical link 1 and 2) and communicates with a remote compute entity such as a controller
or a SCADA system. The two sensors are polled by the remote compute entity and respond
to that poll with their captured values; polling is performed every 20 ms on average.
With these assumed values for the traffic model parameters that I/O device will generate
traffic over the radio interface of 50 kbit/s uplink and 50 kbit/s downlink.
Table 6: Process monitoring
Periodic Traffic
Data Rate
average
Aperiodic and
peak
Burst Traffic
All Traffic

Sum uplink 50,00
Sum downlink 50,00
19
9.4 Use case: Mobile robot
A mobile I/O gateway with radio network connectivity mounted on a mobile robot or an
AGV connects locally (wired) to two high-definition cameras (logical link 1 and 2) and to 2
actuators (logical link 3 and 4).
The camera on logical link 1 sends a continuous high-definition video stream to a remote
controller at a data rate of 8 Mbit/s and receives corresponding acknowledgements (10
kbit/s). The second camera (logical link 2) only sends a video stream when the mobile robot
(AGV) reaches a defined position where a second image is required by the remote control-
ler. This second camera has the same resolution and the same peak data rate as the first
camera but will have a lower average data rate as it only transmits images intermittently.
The actuator communicating via logical link 3 receives a command from the remote con-
troller every 10 ms, and sends a corresponding acknowledgement. The actuator using logi-
cal link 4 does the same every 1 ms. All actuator messages are small in size.
With these assumed values for the traffic model parameters, the I/O device will generate
traffic over the radio interface of 9 Mbit/s on the uplink and 560 kbit/s on the downlink.
Table 7: Mobile robot

Periodic Traffic
Data Rate
average 8.000,00 10,00 500,00 1,00
Aperiodic and
peak 8.000,00 10,00 4.000,00 10,00
Burst Traffic
All Traffic

Sum uplink 9.050,00
Sum downlink 561,00
9.5 Use case: human-machine interface (HMI)

A mobile HMI device with radio network connectivity possesses an emergency button sys-
tem (logical link 1) that communicates with a remote controller and sends a watchdog
supervision message every 5 ms which is acknowledged by the remote controller. The HMI
also occasionally receives a high-definition video data stream (logical link 2) at a peak data
rate of 8 Mbit/s.
With these assumed values for the traffic model parameters, the HMI device will generate
traffic over the radio interface of 200 kbit/s on the uplink and 4 Mbit/s on the downlink.
20
Table 8: HMI
Transfer Interval 5,00 5,00
Periodic Traffic
Message Size 128 64
Data Rate
average 10,00 4.000,00
Aperiodic and
peak 10,00 8.000,00
Burst Traffic
All Traffic

Sum uplink 210,00
9.6 Use case: Closed-loop control for process automation

A mobile I/O gateway with radio network connectivity connects locally (wired) to two groups
of sensors (logical link 1 and 2) and one group of actuators (logical link 3), and commu-
nicates with a remote controller. The I/O gateway captures a value from each sensor in the
first group and sends a message with the combined values of medium size (256 bytes)
every 200 ms, and sends a smaller-sized message with the values from the other group
(128 bytes) every 500 ms via the I/O gateway to the remote controller. These messages are
not acknowledged by the remote controller. The I/O gateway receives a message with the
values from the group of actuators (128 bytes) every 200 ms from the remote controller
and sends back an achnowledgement message of the same size (128 bytes).
With these assumed values for the traffic model parameters, the the I/O device will gener-
ate traffic over the radio interface of 17 kbit/s on the uplink and 5 kbit/s on the downlink.
21
Table 9: Closed-loop control for process automation
Periodic Traffic
Message Size 256 128 128 128
Data Rate
average
Aperiodic and
peak
Burst Traffic
All Traffic

Sum uplink 17,00
Sum downlink 5,00
9.7 Use case: Control-to-control

Two or more (typically four to five) machines collaborate in a flexible, modular produc-
tion environment. Each machine communicates with every other machine, with similar
traffic across all links. In traditional, non-flexible scenarios, 100 Mbit/s and 1 Gbit/s wired
links are used (e.g. 1 Gbit/s links for video streaming, 100 Mbit/s links for motion con-
trol). In order to enable flexible and modular scenarios, the wired connections between the
machines are replaced by wireless ones. For this purpose, each machine is equipped with
an I/O device (UE) connected to the controller.
The traffic is divided into periodic (on logical link 1) and aperiodic traffic (on logical link
2). The logical link 1 can be considered the aggregate of all links between the collaborating
machines, in both uplink and downlink directions. The traffic is distributed across all links
between the collaborating machines. Aperiodic traffic is also distributed across all links,
and can be considered the aggregate of all links between the collaborating machines and
any additional devices they are communicating with (e.g. various sensors).
Use case 1 – 100 Mbit/s link

For the 100 Mbit/s link, 50% periodic and 25% aperiodic traffic is assumed. Each machine
sends to and receives 6.25 kB of periodic data per 1 ms interval (50 Mbit/s) via logical
link 1 from the collaborating machines. Aperiodic data can vary between 0 and 3.125 kB
per 1 ms interval (25 Mbit/s) via logical link 2. With these assumed values for the traffic
model parameters, the traffic volume over the radio interface is on average 62 Mbit/s on
the uplink and 62 Mbit/s on the downlink.
Use case 2 – 1 Gbit/s link

For the 1 Gbit/s link, 25% periodic and 50% aperiodic traffic is assumed. Each machine
sends and receives 31.25 kB of periodic data per 1 ms interval (250 Mbit/s) via logical link
1. Aperiodic data can vary between 0 and 62.5 kB per 1 ms interval (500 Mbit/s) via logical
link 1. With these assumed values for the traffic model parameters, the traffic volume over
the radio interface is on average 500 Mbit/s on the uplink and 500 Mbit/s on the downlink.
22
Table 10: Control-to-control – 100 Mbit/s link
Periodic Traffic
Message Size 6.250 6.250
Data Rate
average 12.500,00 12.500,00
Aperiodic and
peak 25.000,00 25.000,00
Burst Traffic
All Traffic

Sum uplink 61.328,13
Table 11: Control-to-control – 1 Gbit/s link

Periodic Traffic
Message Size 31.250 31.250
Data Rate
average 250.000,00 250.000,00
Aperiodic and
peak 500.000,00 500.000,00
Burst Traffic
All Traffic

Sum uplink 494.140,63
23
10 Annex A.2: Distributed devices in an example factory
This Annex A.2 presents an example implementation of the use cases described in Annex
A.1 applied to the factory layout given in Figure 7. The layout represents a typical factory
for discrete production and assembly. It comprises a production area, assembly areas, a
warehouse, a commissioning space and office cubicles, spanning a total of approximately
15,000 square meters with a ceiling 30 m high.
Fig. 7: Indoor industrial facility

180 m
80 m
Aisle
15 m
Assembly line
Production area Production area
Aisle
5 m
Aisle
Aisle
Assembly line
80 m
Production area
Aisle Aisle
Office
Storage/Ware House Commissioning area
5 m
Office
3GPP TS 22.104 specifies the expected device density for the use cases given in Annex A.1.
The table below shows the expected number of devices and the expected data rates. Three
deployment scenarios are considered: small-scale, large-scale deployment and inbound
logistics. Small-scale in this context reflects an initial roll-out of half the number of devices
(half the density) defined in TS 22.104, typical to a brown-field factory. Large-scale cor-
responds to the wide deployment of 5G-based devices in a new or highly flexible factory
with modular production cells. The inbound logistics scenario reflects the deployment of
many more mobile robots and AGVs but on the other hand fewer motion-control use cases.
24
The example calculations in table 12 for these scenarios give values for the radio uplink
and downlink traffic.
Table 12: Device deployment scenarios and corresponding 5G traffic

(note 1: no values specified in TS 22.104)
Device density UL traffic DL traffic
Use case [#/sqm] # of devices [Mbit/s] [Mbit/s]
Small scale deployment scenario

Process Monitoring n/a 20
Close-Loop-Control 0.002 15
Motion Control 0.2 150
Mobile Robot 0.001 8
HMI (note 1) 7
Control-Control 100 0.003 0
105 300
Large scale deployment scenario

HMI n/a (note 1) 14
550 730
Inbound logistics deployment scenario

HMI (note 1) 14
410 190
It should be noted that the above traffic volumes depend to a very large extent on the use
case mix. The traffic volumes given include periodic, aperiodic and aperiodic and burst
traffic types that are subject to differing quality of service classes within a 5G network.
The composition of traffic types varies according to the use case, as indicated in tables
4 – 11 in Annex A.1.
In the inbound logistics scenario, for example, uplink traffic is higher than downlink traffic
while that relationship is reversed for the small-scale and large-scale scenarios.
25
11 5G-ACIA members As of November 2019
TM
TM
TM
26
27
5G Alliance for Connected Industries and
Automation (5G-ACIA),
a Working Party of ZVEI
Lyoner Strasse 9
60528 Frankfurt am Main, Germany
Phone: +49 69 6302-424
Fax: +49 69 6302-319
Email: info@5g-acia.org
www.5g-acia.org

WP 5G 5G Traffic Model For Industrial Use Cases 22.10.19

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

WP 5G 5G Traffic Model For Industrial Use Cases 22.10.19

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WP 5G 5G Traffic Model For Industrial Use Cases 22.10.19

Uploaded by

Copyright:

Available Formats

White Paper

2 Terms and definitions 5

7 Conclusion and outlook 15

8 References and abbreviations 15

2 Terms and definitions

2.1 Local application function

2.2 Communication function

2.3 Service access point and logical endpoints

2.4 Logical link

2.5 Reference interface

Fig. 1: Reference interface and logical link

Local application Local application

Reference interface Reference interface

LSEP LTEP LSEP LTEP

Source: 5G-ACIA / ZVEI

3.1 Deterministic periodic traffic

Fig. 3: Aperiodic traffic

Similar to deterministic periodic traffic, message size may vary.

Burst traffic is characterized by a sequence of successive messages that are sent in a

Fig. 4: Non-deterministic traffic

Table 1: Traffic pattern types

Traffic type Example

Periodic and time- Sensor-to-controller messages sent periodically between synchroni-

Non-deterministic and burst traffic

Figure 5: Deployment of logical application functions

Traffic model shope

Communication Communication Commu-

Source: 5G-ACIA / ZVEI

4.2 Communication methods

4.3 Radio communication direction

Fig. 6: Mapping of LSEP/LTEP to UL and DL directions.

SAP Local application

Source: 5G-ACIA / ZVEI

5.1 Traffic-related parameters

5.1.1 Message size

5.1.2 Transfer interval

5.1.3 Data rate

This parameter is typically given as follows:

5.2 Network-related parameters

5.2.1 Radio link direction

The traffic model needs to define the following additional parameters:

Mobile device heterogeneity: This parameter describes the statistical distribution of

7 Conclusion and outlook

8 References and abbreviations

Traffic volume (kbit/s)

Table 4: Motion control

Traffic volume (kbit/s)

Source: 5G-ACIA / ZVEI

9.2 Use case: closed loop control, mobile I/O gateway

Traffic volume (kbit/s)

Source: 5G-ACIA / ZVEI

9.3 Use case: Process monitoring

Table 6: Process monitoring

Traffic volume (kbit/s)

Table 7: Mobile robot

Traffic volume (kbit/s)

Source: 5G-ACIA / ZVEI