Content for  TR 22.804  Word version:  16.3.0

Top   Top   Up   Prev   Next
0…   4…   4.3.3…   4.3.4…   5…   5.2   5.3   5.4   5.5   5.6   5.7   5.8   5.9   6…   8…   A…   B…   H…


4.3.4  Dependable communication servicep. 34  Introductionp. 34

Clause 4.3.4 discusses important criteria that are used for evaluating dependable 5G communication services from an end-to-end perspective. Dependability and its attributes are addressed in Clause 4.3.3.  Network dependabilityp. 34

Network dependability can be classified as follows [2]:
  • needed dependability: the end-users' network dependability requirements;
  • offered dependability: the service provider's offerings of network dependability (or planned/targeted network dependability);
  • achieved dependability: the dependability achieved or delivered by the service provider;
  • perceived dependability: the dependability perceived/experienced by the end-users.
The end-users' "dependability needs are the primary source of information for establishing dependability requirements." [2]. Note that in this framework one differentiates between needed, offered, achieved, and perceived/experienced dependability. This is in line with concepts developed by the ITU-T for quality in of service [22]. The ITU-T differentiates between the customer's QoS requirements and the offered, achieved and perceived QoS.
Up  Network serviceabilityp. 34

When communication functionalities are offered as services, dependability is contingent on what is referred to as serviceability. "Serviceability reflects the delivery of network dependability of service to the end-users. Higher serviceability improves availability, provides integrity of service without excessive impairments, and reduces service costs.
Serviceability can be described using the following performance criteria.
  1. Service accessibility
    Service accessibility is the ability of a network service to be accessed by the user, under given conditions, for a given period of time. For connection-oriented services, it refers to the ability to establish connection. Accessibility can be measured in terms of service access delay, network access capability, and service access control capability. (...)
  2. Service retainability
    Service retainability is the ability of a network service, once obtained, to continue to be provided under given conditions for a requested duration. It reflects the reliability of [the] network. (...) Retainability requires network dependability support to maintain stable operation. (...)
  3. Service integrity
    Service integrity is the delivery of information and data by the network without excessive impairment. Service integrity relates to the transfer of information and data known as throughput. (...)
  4. Disengagement
    Disengagement concerns the network devices and links involved in the end-to-end communication of a user as well as network resources (including bandwidth, channel or resources related to upper-layer protocols) to be released when the communication connection or session is closed. (...) Disengagement is a characteristic affecting service accessibility and service retainability in network serviceability." [2].
Serviceability has an additional flavour, which is operability. "From the user's perspective, operability refers to the ability of a service to be successfully and easily operated by a user." [2]. This flavour is especially important in dynamic communication scenarios and for machine-to-machine communication.
Table provides a mapping between serviceability criteria and dependability attributes. For the latter see Clause
Serviceability criterion Corresponding dependability attribute
AccessibilityAvailability, reliability
RetainabilityAvailability, reliability, maintainability, safety
IntegrityIntegrity, safety
DisengagementAvailability, reliability
A comparison of serviceability criteria stipulated by IEC 61907 (see Table and those stipulated by 3GPP (see the definition of QoS in [1]) is provided in Table
Serviceability criterion IEC 61907 3GPP
Up  Describing dependable communication servicesp. 35

In order to deliver a dependable communication service, one needs to assure the "continuity of service against failures and denial of service access and disengagement, and the transfer of user information against loss or interruption." [2]. The dependability of the service from an end-user perspective is ensured at the service access point (interfaces in Figure The end-user dependability requirements determine the required network performance, which in turn determine the required network parameters. As outlined in Clause, dependability requirements can be sorted under four serviceability criteria. However, as discussed in Clause, the dependability mind set also necessitates the differentiation of requested, offered, achieved and experienced dependability. The implied assurance is another paramount facet of a communication service. Assurance is a praxis that produces assurance judgments, i.e. statements that inspire confidence of, for instance, the user of the communication service. Ideally, assurance judgments are based on evidence. The evidence on which an assurance judgement is based can be obtained by the means of service monitoring. More on assurance, assurance methodology, and assurance frameworks can be found in appendix A.3 of [23]. More details on communication assurance and monitoring for assurance can be found elsewhere in the literature [24]. Such monitoring could, for instance, include the communication service availability. If the service monitoring shows that the service has been available for more than 99,92% over a year, the following assurance statement can be made: "The continuous monitoring of communication service availability over a year shows that the unavailability of the communication service is less than 0,08%. This implies that the communication service availability requested by the user, i.e. 99,9%, is met." Assurance takes place at the service interface, which is the single point of interaction between the communication network and the users, i.e. the automation functions. The set of facets of a dependable communication service is summarised in Figure
Copy of original 3GPP image for 3GPP TS 22.804, Fig. Facets of a dependable communication service
So far only automation functions have been addressed, but other types of applications requiring dependable communication services, e.g. PMSE (see Clause 7.8) can be served by the same conceptual framework.
So what about the related service description, in particular the service interface? Table, Table and Table summarise candidate interface parameters. The lists are grouped according to whether the parameter stands for automation function requirements (Table, influence quantities (Table, or management/control parameters (Table The meaning of the columns is explained after each table.
Parameter name Typical metric (unit) Traffic class (note 6)
Deterministic periodic communication Deterministic a-periodic communication Non-deterministic communication
Communication service availabilityMinimum availability (dimensionless)XXX
End-to-end latencyTarget value and jitter (s)XXX
Time between failuresMean time between failures (s)XXX
Time-triggered transmissionTime schedule {time, window size} (s)XX-
Service bit rateTarget value (bit/s); user experienced data rate (bit/s); time window (s)-XX
Update timeTarget value and jitter (s)X--
Parameter description
Communication service availability
This parameter indicates if the communication system works as contracted ("available"/"unavailable" state). The communication system is in the "available" state as long as the availability criteria for transmitted packets are met. The service is unavailable if the packets received at the target are impaired and/or untimely (e.g. update time > stipulated maximum). If the survival time is larger than zero, consecutive impairments and/or delays are ignored until the respective time has expired (see Figure A.2-1).
End-to-end latency
This parameter indicates the time allotted to the communication system for transmitting a message (see Clause 3.1) and the permitted jitter.
Time between failures
This parameter is an indicator for communication service reliability (see Clause This parameters states how long the communication service has to be available before it becomes unavailable. For instance, a mean time between failures of one day indicates that a communication service on average has to run error-free for one day before an error / errors make the communication service unavailable (see above). The default value is zero.
Time-triggered transmission
With time triggered transmission, the messages are forwarded according to a configurable time schedule, which is based on a reference time. The time schedule defines the time windows when the message shall be transmitted. Time-triggered transmission is contingent on a global network time and suits periodic communication of very low update time. This type of service is suitable when the target application does not keep the time.
Service bit rate
  1. deterministic communication
    The target value indicates committed data rate in bit/s sought from the communication service. This is the minimum data rate the communication system guarantees to provide at any time, i.e. in this case target value = user experienced data rate.
  2. non-deterministic communication
    The target value indicates the target data rate in bit/s. This is the information rate the communication system aims at providing on average during a given (moving) time window (unit: s). The user experienced data rate the lower data rate threshold for any of the time windows.
Update time
Applicable only to periodic communication, the update time indicates the time interval between any two consecutive messages delivered from the egress (of the communication system) to the application (see Clause A.4).
Traffic classes
In practice, vertical communication networks serve a large number of applications exhibiting a wide range of communication requirements. In order to facilitate efficient modelling of the communication network during engineering and for reducing the complexity of network optimisation, disjoint QoS sets have been identified. These sets are referred to as traffic classes [28]. Typically only three traffic classes are needed in industrial environments [28], i.e.
  • deterministic periodic communication;
  • deterministic aperiodic communication; and
  • non-deterministic communication.
For a discussion of determinism and periodicity see Clause
Deterministic periodic communication stands for periodic communication with stringent requirements on timeliness of the transmission.
Deterministic aperiodic communication stands for communication without a preset sending time. Typical activity patterns for which this kind of communication is suitable are event-driven actions.
Non-deterministic communication subsumes all other types of traffic. Periodic non-real time and aperiodic non-real time traffic are subsumed by the non-deterministic traffic class, since periodicity is irrelevant in case the communication is not time-critical.
Usage of the parameters in Table
Control service request and response; monitoring service response and indication.
Parameter name Typical metric (unit) Traffic class (note 7) Usage of this parameter
Deterministic periodic communication Deterministic a-periodic communication Non-deterministic communication
BurstMaximum user data length (byte) and minimum transfer interval (s)-X-Control service request and response; monitoring service response and indication
message length (byte) and line rate of the service interface (Mbit/s)--X
Survival timeMaximum (s)XX-Control service request and response
Message sizeMaximum or current value (byte)X(X)(X)Control service request and response; non-deterministic data transmission; deterministic aperiodic data transmission
Transfer intervalTarget value and jitter (s)X--Control service request and response
Parameter description
The transmission of, for instance, program code and configuration data may be handed to the 3GPP system as data burst. In this case, the ingress data rate exceeds the capacity of the network, which implies that some of the data has to be stored within the ingress node of the communication system before it can be transmitted to the egress interface(s). However, the data of a burst needs to be transmitted completely. This is in contrast to periodic data transmission, where new messages overwrite old ones.
Typical metrices for bursts:
  • aperiodic data transmission: maximum user data length and minimum transfer interval;
  • non-deterministic transmission: message length and line rate of the service interface.
Survival time
The maximum survival time indicates the time period the communication service may not meet the application's requirement before it is deemed to be in an unavailable state.
Transfer interval
Applicable only to periodic communication, the transfer interval indicates the time elapsed between any two consecutive message delivered by the automation application to the ingress of the communication system (see Clause A.4).
Message size
The user data length indicates the (maximum) size of the user data packet delivered from the application to the ingress of the communication system and from the egress of the communication system to the application. For periodic communication this parameter can be used for calculating the requested user-experienced data rate (see Clause A.4). If this parameter is not provided, the default is the maximum value supported by the PDU type (e.g. Ethernet PDU: maximum frame length is 1522 octets, IP PDU: maximum packet length is 65535 octets).
Parameter name Parameter description Service using this parameter
Application identifierIndicates the user's (application's) service interface and service instance, which is to be notified of communication related events (e.g. contracted forwarding behaviour can no longer be met)All service primitives
Communication service identifier / traffic flow identifierIndicates the data flow which shall be forwarded according to the mutually agreed (contracted) parameters. The traffic flow identifier is associated with a set of traffic filters, which filter traffic according to protocol data understood by the automation and the communication function.All service primitives
Quality class identifierIndicates the traffic class of the service flow.Control service requests and responses
Up  Other servicesp. 39  Monitoringp. 39
As pointed out in Clause and as becomes apparent when consulting the merged requirements in Clause 8, communication service monitoring is an important enabler of communication for automation.
Parameter name Typical metric (unit)
MonitoringParameter to be monitored {field; includes parameter identifiers (string), measurement rate (s-1), output filter {e.g., a moving average}, time stamping (Y/N), etc.}
Up  Clock synchronisationp. 39
As outlined in Clause 7.5, clock synchronisation is needed in many "vertical" use cases. The table below proposes related service parameters, i.e. the requirements the user expresses in a service call.
Parameter name Typical metric (unit)
ClockUpdate rate (s-1); time zone (string); combined type-A and -B uncertainty (s) [53]
Up  Localisationp. 39
As outlined in in clause 7.3 in [3], "vertical" automation functions might request knowledge about the position of UEs from the 5G system. The table below proposes related service parameters, i.e. the requirements the user expresses in a service call.
Parameter name Typical metric (unit)
PositionAbsolute position (Y/N); position relative to base station (Y/N); update rate (s-1); time to first fix (s); combined type-A and -B uncertainty [53]; encryption protocol for position

Up   Top   ToC