Industrial automation with 5g and beyond

Abstract

This invention discloses techniques for improving performance in an Industrial Internet of Things (IIoT) context, including techniques for integrating Time-Side Networks (TSNs) with 5G wireless networks. An example method performed by a wireless device associated with a wireless communication network includes receiving a first timing signal from the wireless communication network and receiving a second timing signal from an external TSN data network to which the wireless device is connected. The method further includes establishing at least one TSN stream with the external TSN data network via a radio base station (RBS) in the wireless communication network.

Description

[Technical Field]

[0001] This invention relates to wireless communication networks and describes a network architecture, wireless device, and wireless network node suitable for industrial applications using a fifth-generation (5G) or other wireless communication network. [Previous Technology]

[0002] Fifth-generation mobile technology (5G) will be able to provide a wider range of services than existing 3G / 4G technologies. The three main use cases for 5G are: enhanced mobile broadband (eMBB), massive machine-type communications (mMTC), and ultra-reliable low-latency communications (URLLC). A key objective of 5G systems will be to support the stringent system requirements of vertical markets. These requirements include: simultaneously supporting multiple combinations of reliability, latency, throughput, location, and availability, as well as area deployment with area survivability, area data / routing, area management, security, data integrity, and privacy.

[0003] Figure 1 illustrates a perspective view of an industrial network within a 5G system. Service performance requirements arise from automation applications. 5G systems are providing communication services for automation applications. To support automation in vertical domains, 5G systems need to reliably and flexibly meet service performance requirements to serve specific applications and use cases. They need to possess system properties of reliability, availability, maintainability, security, and integrity.

[0004] Members of the 3rd Generation Partnership Project (3GPP) are developing 5G specifications. The document "Service Requirements for Network Entity Control Applications in Vertical Domains, Phase 1" (3GPP TS 22.104, Version 16.0.0 (January 2019)) specifies the requirements for providing a set of performance criteria that need to be met in order to satisfactorily support the different use cases of network entity control applications used in various vertical markets.

[0005] In industrial applications, support for hybrid services in factory and manufacturing environments is required, including support for different service levels (such as massive machine-type communications (mMTC), enhanced mobile broadband (eMBB), and ultra-reliable low-latency communications (URLLC)) within the same deployment. Support for industrial deterministic services is also required. Integration between 5G systems (5GS) and existing industrial networks is also required. Interoperability is needed, including support for interoperability with non-public networks and with public terrestrial mobile networks (PLMNs).

[0006] Regarding system availability and reliability, a 5G system, as a communication service provider, should comply with the 3GPP definitions of availability and reliability. Communication service availability is defined as the amount of time that an end-to-end communication service is delivered according to an agreed Quality of Service (QoS) divided by the expected amount of time the system will deliver end-to-end services according to specifications in a specific area. The required availability will be determined by business models that consider the trade-off between the monetary losses incurred when the system is unavailable and the complexity of increasing availability, for example, by adding redundancy. It will be understood that availability exceeding 99.95% typically requires an additional power source to prevent the public power grid (99.9% to 99.99% availability in Europe) from becoming the weakest component.

[0007] Communication service reliability is defined as the ability to perform communication services as required under given conditions within a given time interval. These conditions include factors that affect reliability, such as operating mode, stress level, and environmental conditions. Reliability can be quantified using appropriate measures (such as mean time between failures or the probability of no failures within a specified time period).

[0008] The use of 5G in industrial applications must meet security requirements, where security is defined as being protected from damage, danger, or injury, or as a condition in which damage, danger, or injury is impossible. Therefore, security systems should be designed to be functionally safe from the outset. To ensure system safety during operation, automatic protection functions can be built into the system. To ensure automatic protection, the security profiles to be considered in system design should include, for example, human error, hardware and software failures, and operational and environmental stress factors.

[0009] Today, many industries have complete control over their local area network (LAN) deployments. Therefore, LAN deployment patterns regarding survivability, data / routing, and management have become requirements for industrial networks. In short, the factory network should function normally even when connectivity to the outside world is lost. Furthermore, there may be requirements for data not to leave the workplace and for LAN IT staff to manage and modify network deployments as needed.

[0010] Security, data integrity, and privacy are also important requirements for industry. Business-critical information regarding manufacturing processes and data should not be disclosed. [Summary of the Invention]

[0011] This document details various technologies used to improve performance in the Industrial Internet of Things (IIoT) context, including technologies for integrating Time-Based Networking (TSN) and 5G wireless networks. Corresponding devices and nodes are also described in detail.

[0012] An example method performed by a wireless device includes: receiving system information (SI) from a radio base station (RBS) of a radio access network (RAN), the SI indicating support for TSN through the RBS; and establishing at least one TSN data stream with an external data network through the RBS. The example method further includes: receiving a first timing signal from the wireless communication network via the RBS; receiving a second timing signal from the external TSN data network to which the wireless device is connected; comparing the first timing signal and the second timing signal to determine an offset; and transmitting the offset to the wireless communication network.

[0013] Another example method performed by a wireless device includes: receiving a first timing signal from a wireless communication network; receiving a second timing signal from an external TSN data network to which the wireless device is connected; and establishing at least one TSN data stream with the external TSN data network through a radio base station (RBS) in the wireless communication network.

[0014] Another example method is executed in one or more nodes of a core network associated with a radio access network (RAN) and is used to process a time-sensitive data stream associated with a user equipment (UE) and an external network. This example method includes: receiving from the external network a transmission schedule associated with a time-sensitive data stream; and sending a request to the RAN to allocate radio resources for transmitting the data stream between the RAN and a first UE, wherein the request further includes information related to the transmission schedule. The method further includes receiving from the RAN a response indicating whether radio resources are available to satisfy the transmission schedule associated with the data stream. The method further includes: obtaining configuration information of the data stream, the configuration information indicating individual values ​​of one or more fields in a header of a data packet associated with the data stream that will remain static; initiating transmission of the configuration information to a first UE; receiving a data packet associated with the data stream from the external data network; removing the one or more fields from the data packet to generate a compressed data packet; and initiating transmission of the compressed data packet to the first UE.

[0015] Another example method is performed by a wireless device associated with a wireless communication network and is used to transmit data packets associated with a data stream in an external data network. This example method includes: receiving an SI from an RBS of a RAN, the SI indicating support for TSN through the RBS; and establishing at least one TSN data stream with the external data network through the RBS. This method further includes: obtaining configuration information of the TSN data stream, the configuration information indicating individual values ​​of one or more fields in a header of a data packet associated with the data stream that will remain static; receiving a data packet associated with the TSN data stream from the RBS; and adding the one or more fields to the data packet to generate a decompressed data packet.

[0016] Another example method is performed by a radio device configured to communicate with a RAN and is used to schedule resources in the RAN according to a transmission schedule associated with an external network. This example method includes: receiving an SI from an RBS of the RAN, the SI indicating support for TSN via the RBS; and establishing at least one TSN data stream with the external data network via the RBS. This example method further includes: receiving a transmission schedule associated with the TSN data stream from the external network; sending a request to allocate radio resources to transmit the TSN data stream between the radio device and the RBS to the network associated with the RBS, wherein the request further includes information related to the transmission schedule; and receiving a response from the network indicating whether radio resources can be allocated to satisfy the transmission schedule associated with the TSN data stream.

[0017] Another example method performed by a wireless device associated with a wireless communication network includes: receiving a first timing signal from the wireless communication network; and receiving a second timing signal from an external timeliness network (TSN) data network to which the wireless device is connected. The method further includes: establishing at least one TSN data stream with the external TSN data network via a radio base station (RBS) in the wireless communication network; and receiving a transmission schedule associated with the corresponding TSN data stream from the external network.

[0018] Another example method performed by a wireless device includes: receiving an SI from an RBS of a RAN, the SI indicating support for TSN through the RBS; and establishing at least one TSN data stream with an external data network through the RBS. The method further includes: obtaining configuration information of the TSN data stream, the configuration information indicating individual values ​​of one or more fields in a header of a data packet associated with the data stream that will remain static. The method further includes: receiving a data packet associated with the TSN data stream from the RBS, and adding the one or more fields to the data packet to generate a decompressed data packet.

[0019] Another method performed again by a wireless device associated with a wireless communication network includes: establishing at least one TSN data stream with the external TSN data network via a radio base station (RBS) in the wireless communication network; and obtaining configuration information of the TSN data stream, the configuration information indicating individual values ​​of one or more fields in a header of a data packet associated with the data stream that will remain static. The method further includes: receiving a data packet associated with the TSN data stream from the RBS; and adding the one or more fields to the data packet to generate a decompressed data packet.

[0020] Another method performed by a wireless device associated with a wireless communication network includes: establishing at least one TSN data stream with an external TSN data network via a radio base station (RBS) in the wireless communication network, and receiving a transmission schedule associated with the corresponding TSN data stream from the external network.

[0021] Another example method is performed by a first device and is used to assist in registering a second device to and using the second device in an Internet of Things (IoT) environment. This example method includes: obtaining a representation of a registration function associated with the second device, wherein the registration function is associated with at least one serialized registration application, the at least one serialized registration application including registration information associated with the first device and the second device; deserializing the registration application such that the registration information associated with the first device and the registration information associated with the second device are separated; and transmitting the registration information associated with the second device to the second device to initiate the second device's registration processing procedure by configuring the second device based on the registration information associated with the second device. The method further includes: receiving configuration information associated with the second device from the second device; and using a first runtime environment executed on the first device to transmit a code module to a second runtime environment executed on the second device, wherein the code module is configured to execute within the second runtime environment and expose to the first device a function of the second device supported by the second runtime environment. The method further includes executing an application within the first runtime environment, the application remotely invoking the function of the second device via the transmitted code module and the second runtime environment.

[0022] A corresponding method is executed by a second device and is used for registering a process with an IoT environment assisted by a first device and providing the first device with access to a function of the second device. This example method includes: receiving registration information associated with the second device from the first device; executing the registration process by configuring the second device based on the registration information; and transmitting configuration information associated with the second device to the first device. The method further includes: receiving a code module from a first runtime environment executing on the first device to a second runtime environment executing on the second device to expose a function of the second device supported by the second runtime environment to the first device; and using the second runtime environment to control the execution of the function in response to a remote call to the function of the second device received via the code module from an application executing within the first runtime environment.

[0023] These and other methods are disclosed and illustrated in detail below and in the accompanying drawings. Corresponding devices, network nodes and such, for example, network configurations and environments in which these technologies can be advantageously used, are also described in detail.

Implementation Method

[0024] The following is a detailed description of the concepts, system / network architectures, and detailed designs of various forms of wireless communication networks designed to address the requirements and use cases of 5G. The terms "requirement," "need," or similar language should be understood to describe a desired feature or function of the system in the sense of an advantageous design in some embodiments, and should not be understood to indicate a necessary or essential element in all embodiments. Thus, each of the following requirements and capabilities described as required, important, necessary, or in similar language should be understood as optional.

[0025] Operational technology communication system and 5G

[0026] Today, various technologies are used in industrial communication systems. For manufacturing systems in factories, a one-tiered communication structure (often called an automation pyramid) is used, as illustrated on the upper left of Figure 2. This design is based on the ISA95 / 99 model. Industrial equipment is connected to small subsystems covering, for example, a production unit. These subsystems are separated by gateways and can use different communication technologies; each subsystem is tightly managed to ensure critical communication performance. At a higher level, these subsystems are interconnected, for example for coordination between production units and monitoring and control of the production system. This part related to manufacturing operations is called the Operational Technology (OT) domain containing critical communications, where requirements typically become more stringent at lower levels. Today, critical communications are primarily based on wired communication technologies, such as fieldbuses or industrial Ethernet. The OT portion of the network is securely separated from the IT portion of the network containing enterprise applications and services.

[0027] It is anticipated that the broader digitization of one of the manufacturing systems will provide increased flexibility and efficiency by transforming manufacturing into a network-physical production system. This transition is also known as the Fourth Industrial Revolution or Industry 4.0. The entire production system is envisioned to be modeled, monitored, evaluated, and manipulated using a digital avatar. To this end, it is desirable for the entire factory to be fully connected, thereby avoiding connection silos at the shop floor level, as shown on the upper right of Figure 2. The separation of different domains of the network is thus shifted from physical separation (via gateways) to logical separation. In this transition, IEEE 802.1 Timeliness Networking (TSN) plays a central role because it allows for guaranteed high-performance connectivity services for certain traffic flows shared on a common Ethernet infrastructure between critical and non-critical communications. As a fully standardized solution, it also allows the convergence of multiple proprietary fieldbus technologies currently in use into a global standard.

[0028] Wireless connectivity can bring tremendous value to a manufacturing system. It can provide cost savings by avoiding extensive cabling, and it can support new use cases that cannot be achieved with wires (e.g., connecting mobile components). More specifically, it offers great flexibility in redesigning the workshop – a major trend toward Industry 4.0. Currently, the use of wireless technology in the workshop is very limited and focused on non-critical communications provided through various technologies. For critical communication services, there is currently no wireless technology that can provide reliable and deterministic low-latency connectivity.

[0029] 5G promises to provide reliable, deterministic, low-latency services while supporting eMBB and mMTC. (Note that 5G mMTC is based on LTE-M and NB-IoT, and can be embedded in an NR carrier. The ultimate goal is to achieve an NR-based mMTC mode.) To this end, it can play a role on the radio side similar to that of TSN for wired connections. It provides a universal, globally standardized technology that converges all service types and extends radio connectivity to a wider range of areas, including inter-vehicle communications.

[0030] TSN has an additional role to 5G. Industrial networks are long-established infrastructure, and most factories have already deployed them. Introducing new technologies into existing brownfield infrastructure is slow and cumbersome. TSN is expected to trigger a redesign of building practices, which is anticipated to extend even to industrial brownfield networks where feasible. By connecting 5G as a wireless equivalent to TSN, TSN provides an open market opportunity to help transform the brownfield market. This has spurred a need for 5G architecture solutions that are largely compatible with TSN.

[0031] The integration of 5G must address several requirements: • Area Content: For reasons such as security and trust, production-related data may not leave the industrial / factory premises; that is, all such data needs to be stored locally. • Complete Control of Critical Connections: Critical communications must be controlled by industrial end-users and connected to operating systems that manage uninterrupted operation. • Area Management: Management solutions need to be easily integrated with industrial business and operational procedures and include network observability. • Area Survivability: Connectivity solutions should not be dependent on any external failures; that is, they should be independent in terms of survivability. • Life Cycle Management (LCM): Several industries require LCMs to span decades. This means the long-term availability of industrial equipment and network infrastructure is required, including methods for equipment configuration, firmware updates, application software updates, authentication, installation, provisioning, and field maintenance. • Security: Connectivity networks should ensure that only authorized traffic is allowed and apply the required level of confidentiality protection (e.g., encryption and / or integrity protection). It should also support features such as preventing intrusions (hackers) from the Internet, preventing malware from reaching devices and servers, and preventing data tampering. Support for different security zones should be enabled. Furthermore, the network infrastructure itself needs to be securely protected against external attacks. • Integration with existing solutions: The connectivity solution needs to be integrated into existing wired OT systems and other wireless connectivity devices. One example is the transmission of industrial Ethernet frames.

[0032] System Architecture

[0033] As shown in Figure 3, a 5G network integrated into an industrial system requires the following functionalities: • A 5G radio access and core network for 5G connectivity, including radio connectivity, mobility support, service management, and QoS, encompassing all service types with deterministic performance: URLLC, eMBB, and mMTC. • High availability and redundancy. • Network identity enabling dedicated network services (i.e., restricting network access and network services to a defined group of devices). • Security solutions based on security authentication. • Support for location and time synchronization. • Network monitoring and QoS assurance mechanisms. • A lightweight network management solution. • A cloud computing infrastructure with deterministic performance and high availability for industrial applications. • The ability to integrate with existing industrial systems (i.e., connectivity, cloud computing infrastructure, and management systems). • The ability to interact with external public networks when service continuity is required to enter and exit the factory.

[0034] A 5G system can be deployed in different variations. In cases where an industrial user has territorial access to a dedicated spectrum, a standalone 5G system can be deployed, as illustrated in Figure 3. This standalone 5G network can allow interaction with a public network, for example, via roaming. Alternatively, federated network slicing can be applied by establishing a logical network slice based on one of the physical infrastructures of two (or more) networks.

[0035] A regional 5G system can also be implemented as a non-public network service provided by a public mobile network operator in an industrial location, as illustrated in Figure 4. Typically, at least a portion of the network infrastructure needs to be deployed on a site for regional use. Data offloading on the site ensures low latency and allows data privacy policies to prevent information from leaving the site. Core control functions may be provided from an external MNO site, or may be entirely or partially on the site, to support, for example, regional survivability. While critical communication services remain on the site via regional offloading, certain other functions may also utilize external termination of the data processing phase.

[0036] A combination of an independent local area network (LAN) and a public MNO network can also be used as the basis for providing a non-public network service across two network domains. An industrial user may deploy a LAN on a site, which, together with the public network infrastructure, provides non-public network services via federated network segmentation. For example, a regional deployment can be deployed to "enhance" the public network in terms of regional coverage, availability, capacity, and computing resources.

[0037] In addition to providing a regional independent network, a regional network can also provide neutral hosting capabilities by extending a public network on a site. For this purpose, network sharing solutions, such as Multi-Operator Core Network (MOCN) or Multi-Operator Radio Access Network (MORAN), can be applied. In the network sharing approach, a resource management solution is needed that can provide guaranteed resources and performance for different supported networks (or network slices). A network sharing solution can be well-developed for both regional and public network providers. The regional provider can provide a free regional site to the MNO, while the MNO can provide its spectrum resources to the network. Since the same base stations can support both public and private services, it should be possible to achieve some form of improved coexistence between the regional network and the public network. Furthermore, a sharing solution can be developed by different services. For example, a public MNO can provide conventional enterprise services, such as telephone, mobile broadband, and IT connectivity, on an industrial site, while a dedicated independent regional network is used for regional industrial OT connectivity.

[0038] Network Slicing for Industrial Internet of Things (IoT)

[0039] Network segmentation is considered one method for enabling or implementing industrial IoT network solutions. Network segmentation can provide separate and isolated logical networks on a shared infrastructure. It can be used, for example, to: • separate different security zones in a factory; • separate different service types, such as isolating critical communications from non-critical communications; • provide a non-public IIoT network on a public network infrastructure that is also used for public mobile communications.

[0040] Network segmentation is a conceptual approach to examining and implementing provider networks. Instead of the common concept of a single, monolithic network serving multiple purposes, technological advancements such as virtualization and SDN allow logical networks to be built on top of a common and shared infrastructure layer.

[0041] Such "logical networks," which may be referred to as "network slices," are established for a specific business purpose or even for a specific customer (the provider's customer). They are end-to-end and complete within the context of the given business purpose. They are and behave like a network of their own, containing all necessary capabilities and resources. This extends from the sharing of infrastructure resources to configuring network functions, network management, or even OSS / BSS capabilities. It encompasses both mobile and fixed network components. It is expected that even if different slices share common physical resources, they are independent and isolated, thus providing a separation of concerns. A network slice can be defined as spanning multiple physical network infrastructures, sometimes referred to as a federated network slice. This can provide, or even enable, alternative network implementations for roaming.

[0042] Just as an existing network is built to provide services, so too is a network slice. It is not a service in itself, but is constructed to provide one or more services. As a special case, a service (or its execution entity) is mapped one-to-one to a network slice, for example, to allow wholesale-type services. Resources (entities or logic) may be dedicated to all slices (i.e., individual execution entities), or they may be shared across multiple slices. These resources are not necessarily all generated within the provider; in fact, some resources may be services consumed by other providers, thereby facilitating, for example, convergence, roaming, etc.

[0043] A network slice can be defined as a set of resources, as shown in Figure 5. These resources can be physical resources (shared or configured across all slices), or even dedicated physical resources if activated. A slice can also be defined as including logical entities, such as configured network functions, management functions, VPNs, etc. Resources (physical or logical) can be dedicated to all slices (i.e., a single entity), or they can be shared across multiple slices. These resources are not necessarily all generated within the provider; in fact, some resources may be services consumed by other providers, thereby facilitating, for example, convergence, roaming, etc. Network slicing allows for the leasing of network capacity using, for example, associated Service Level Agreements (SLAs).

[0044] Because slices can be created to address new business requirements or customers and may need to adapt to changes, slices require a new lifecycle management function that can create, modify (e.g., upgrade), or remove slices. Network slicing allows the use of different network architectures that have been optimized for the specific use cases of using slices. This optimization for different network slices may include both optimization within functional domains and optimization within the geographical deployment of different functions in the network. This can be seen in Figure 6, which illustrates an example of one of four different slices in the network. It is also expected that service providers will support this in a cost-effective and timely manner through applications that include industry-specific services and / or from other third parties or service providers.

[0045] The definition of network slicing is twofold. For the general definition, the definition from the GSMA is used: "From a mobile operator's perspective, a network slice is an independent, end-to-end logical network operating on a shared physical infrastructure, capable of providing a negotiated quality of service." In addition to this general definition, several implementation schemes exist to achieve the above, and the use of "network slicing" usually refers to these implementation schemes. The most prominent implementation scheme comes from the 5G core specification ("System Architecture for 5G Systems (5GS), Phase 2", 3GPP TS 23.501, version 15.4.0 (December 2018)): "Network slice: A logical network that provides specific network capabilities and network characteristics [...]. A network slice is defined within a PLMN and should include: core network control plane and user plane network functions [...]." Methods that at least partially implement the above definition are not limited to 5G and can also be used in 4G networks.

[0046] Using these definitions, a basic network slice can be explained according to Figure 7: • There is a shared physical infrastructure (see (1) in Figure 7). • Define one or more independent end-to-end logical networks (see (2) in Figure 7), which include: a. a core network control plane, b. user plane network functions, • These logical networks can support negotiated quality of service or specified service capabilities, or in other words, support a service level agreement (SLA) for the network slice capabilities (see (3) in Figure 7).

[0047] Once a network slice is defined, a primary issue is how to assign or route a data traffic flow through the corresponding network slice. In many cases, a single device uses only a single slice, so allocation can be done by assigning each UE to a specific network slice. However, in some cases, a device can serve traffic from multiple slices.

[0048] In mobile networks, dedicated bearers are a benchmark used for service processing to provide specific service performance and QoS; they are typically a solution to meet the requirements of a specific use case or service. In radio access networks (RAN), dedicated bearers are mapped to radio bearers that can be used by the scheduler to deliver services carrying specific QoS. Specific resources can be reserved for certain dedicated bearers. At the network edge, bearers can be individually identified and processed based on filters in the packet header, such as the 5-tuple source IP address, destination IP address, source port number, destination port number, and protocol (UDP or TCP).

[0049] Figure 8 illustrates four available 4G methods for segmenting a network. For the first method, RAN sharing is applied, allowing the eNB to advertise multiple PLMN IDs. To utilize this method, the RAN and core need to support these characteristics to ensure the advertised PLMN IDs and proper routing of traffic to / from the correct core network. The UE selects the PLMN based on the usual network selection procedure that includes the better (home) network. A UE can be served by only one PLMN (except in the case of multi-SIM UEs). Currently, each UE and at least some network-side systems support this solution.

[0050] The second solution relies on Access Point Names (APNs) configured in the UE. In this scenario, the RAN advertises a PLMN ID, but user plane traffic is routed to the correct core network based on the APN. During PDN setup, a UE can even have multiple configured APNs, resulting in multiple IP addresses (multi-homed). It is crucial to ensure that uplink transmissions do not directly use the correct source IP address. Not every device may support configuring more than one APN for an Internet application within the same UE. This solution does not require changes to the RAN but must be supported in the core network.

[0051] 3GPP has a research project called DECOR, now described in the standard document as a Dedicated Core Network (DCN), which allows all slices to be selected based on the network configuration rather than on a better PLMN ID or APN setting as in previous solutions. This feature must be supported in both the RAN and the core, and information from the Home Subscriber Server (HSS) will be used to determine the "UE usage type" and thereby attach it to the correct slice. This solution does not affect the UE.

[0052] One concept known as eDECOR further enhances this by allowing the UE to submit a DCN-ID to select a slice. To utilize this method, the RAN, core, and UE need to support this feature.

[0053] Both DECOR and eDECOR only allow one slice per UE, but ensure that different types of UEs are served by different slices. Within each dedicated core, multiple dedicated bearers and APNs can be used.

[0054] For version 15 and later, 5G slicing extends this feature to a theoretically unlimited number of slices, but implementation schemes and resource dependencies in the UE, RAN, and core may be subject to constraints. For 4G, there are several sub-options for implementing slicing in 5G, but these will not be further distinguished in this document.

[0055] Once traffic has been assigned to the corresponding slice, the next question is how to provide service performance. In many industrial IoT use cases, guaranteed service performance for prioritized traffic is required. In a normal (i.e., unsegmented) 5G network or within a single network slice, different traffic flows can be separated based on traffic flow separation, as shown in Figure 9, which illustrates how QoS is applied in a 5G system. Dedicated resource allocation can be provided for critical traffic. Licensing controls are used to ensure that the number of licensed prioritized traffic flows with guaranteed transmission resources (i.e., guaranteed bit rates) does not exceed the available resources, with sufficient margin for resource changes.

[0056] For resource allocation between slices, resource reservation in the physical infrastructure is not based on individual traffic flows, but on the sum of all critical traffic flows within a slice. This overall requirement needs to be defined in the network slice SLA. Resource allocation does not have to be static. Better efficiency can be achieved if unused resources of one slice can be used by another slice. This can be seen in Figure 10, which illustrates the resource allocation between example slices A and B. The requirement is that each network slice can access guaranteed service flows (or at least the availability level defined in the SLA) at any given time.

[0057] Industrial Applications

[0058] The following is a discussion of several applications and activities related to industrial technology. This discussion includes a discussion of cloud robotics, which is a new technology that offers many additional benefits compared to previous technologies.

[0059] In Chapter 5.3.2 of 3GPP TR 22.804, version 16.2.0 (December 2018), "Study on Communication for Automation in Vertical Domains," motion control is introduced as one of the use cases for the factory of the future. Motion control is essential for any automation application and is fundamental, for example, for industrial robots. The movement of a robot or the function of a printing machine is essentially just one of many actuators coordinated by motion control.

[0060] Motion control refers to the task of driving an actuator (or a group of actuators) in a manner required by an application (and ensuring that this is being done). Electric motors are the most common actuators in industry. There are several ways to classify electric motors (e.g., AC-DC (brushed / brushless), stepper-servo-hybrid stepper). In any case, the motion control principles for each type of motor are similar. Communication technology is used to coordinate and synchronize multiple actuators and for higher-level control. Motion control applications that require accuracy or precision are always implemented as a closed-loop control.

[0061] A common logical split exists in motion control systems: • Physical actuators (also known as motors) and encoders (i.e., one or more sensors such as speed and position) • Drivers (also known as inverters) • Motion controllers • Programmable logic controllers (PLCs) This logical split of motion control functions is illustrated in Figure 11.

[0062] Typical communication patterns in motion control architecture (numbered in Figure 11): 1) A PLC transmits higher-order commands to the motion controller – this has less stringent communication requirements. 2) The motion controller generates a so-called setpoint (potentially speed, torque, etc.) for the drive using, for example, the following operations: a. Pulse width modulation (PWM), which is not a communication technology. b. Protocols such as EtherCat or Profinet IRT, or similar protocols, supporting very low cycle times, typically less than 1 ms. 3) Current fed from the drive to the motor – motor power supply based on the setpoint, no communication technology. 4) Encoder (sensor) feedback to the drive and / or motion controller; the feedback depends on the type of motor and encoder. The feedback can be analogous to or based on, for example, EtherCat or Profinet IRT (as described in 2) with similar requirements (e.g., cyclic closed-loop setpoint transmission and feedback).

[0063] If, for example, several motors are used in the same machine, a single motion controller can control multiple actuators. The requirements for motion control applications (solving the closed loop: motion controller-driver-encoder) are listed in the above technical report - these requirements are reproduced in Table 1 below. app Number of sensors / actuators Typical message size Cycle time T cycle Service Area Printing machines > 100 20-byte < 2 ms 100 m x 100 m x 30 m Machine tools ~ 20 50-bit tuple <0.5 ms 15 m x 15 m x 3 m Packaging machines ~ 50 40-bit tuple < 1 ms 10 m x 5 m x 3 m Table 1 – Motion Control Requirements

[0064] 3GPP TR 22.804 further states that the loss of two consecutive packets is unacceptable and requires extremely high synchronization (less than 1 usec time base error) between all involved devices. The latter is mandatory to enable sampling from distributed encoders and to apply new setpoints in the motion controller to the drivers at common sampling points. This is called isochronous communication, which means that the application (and therefore the motion control program, as well as all actuators and encoders) is synchronized with the communication cycle timing provided by communication technology (such as Profinet's communication technology). This also ensures minimal and deterministic latency for access using timing channels.

[0065] Several suppliers of motion control equipment (such as motion control manufacturer Lenze) also combine functions into a single physical entity. At a higher “control level”, a combined PLC + motion controller (logic and motion) is used next to the human-machine interface. This controller takes input from the IO device (3) and feeds its setpoint to, for example, a service inverter (2) via EtherCat (“field level”).

[0066] Another trend is to integrate encoders and / or drives and / or motion controllers into the motor. This is sometimes referred to as an integrated motor or a smart motor.

[0067] Furthermore, it is possible to use multiple motion controllers in the same application; each motion controller controls a subgroup of drivers. Coordinating motor movement requires communication between the separate motion controllers. In 3GPP TR 22.804, this is called "Controller-to-Controller" (C2C) communication. The cycle time is assumed to be between 4 ms and 10 ms. Synchronization requirements are equally stringent, with a time base error of less than 1 usec at the C2C level. The payload size can be as high as 1 kB.

[0068] For safety reasons, an additional functional safety control can be deployed in wireless motion control applications. Functional safety is implemented as an additional closed loop after the closed loop used for motion control itself. This is accomplished through additional hardware in the motion control components or by integrating safety functions. Communication protocols such as ProfiSafe are used. A safety constraint is, for example, Safe Torque Off (STO) (from IEC 61800). An STO is defined as the requirement to stop supplying power to the motor if the PLC or an additional safety PLC detects any error / safety problem. An STO can be triggered, for example, by pressing an emergency stop button. 3GPP TR 22.804 explains that a strict loop data communication service is required between the two ends for functional safety. If the connection is disrupted, an emergency stop will be triggered even if no actual safety event occurs. Different requirements exist for different use cases (cycle time from 4 ms to 12 ms, packet size from 40 byte to 250 byte, and tolerable time base error in transmission according to 3GPP TR 22.804). Security features can be implemented in different components of the motion control architecture.

[0069] In summary, motion control involves four different types of communication: 1) Lowest-order closed-loop motion control (motion controller-driver-encoder); 2) Controller-to-controller communication; 3) Functional safety communication; 4) PLC-to-motion controller communication. The latency requirements of communication systems decrease from 1 to 4. Whether establishing a connection via a wireless communication technology (1 to 4) is meaningful depends on the application. In most cases, establishing wireless connections for 2), 3), and 4) may be most relevant, but may be irrelevant for 1).

[0070] Cloud Robot

[0071] Cloud-based robotics are a major theme in industrial robotics research and robotics in general. It elaborates on how different cloud technologies can be used to provide additional benefits for various robotic tasks and thereby improve the flexibility and capabilities of the entire system. Several studies have demonstrated the benefits of connecting robots to one cloud: • Use of more powerful computing resources in the cloud (e.g., for artificial intelligence AI tasks). • Use virtually unlimited data for analysis, decision making and learning (contains digital shading and real-time simulation). • New types of usage scenarios are enabled (e.g., collaboration control in the cloud). • Lower cost per robot due to offloading functions to a central cloud. • A bot may perform a fault-tolerant migration if it is physically interrupted from one of the latest backups in the cloud. • By having multiple executing individuals as hot-pending fate rows in the cloud, the reliability of the function is improved and the primary function that can self-fail immediately takes over the operation without interruption. • Makes operation and maintenance easier (software updates, configuration changes, monitoring, etc.). • Save energy by offloading CPU energy consumption to the cloud, particularly for mobile battery-powered robots.

[0072] High flexibility is indeed one of the key requirements of Industry 4.0. Cost-effective and customized production needs to be achieved by supporting rapid reconfiguration of production lines as well as easy application development. Typical industrial applications are time sensitive and require end-to-end highly reliable communication. Therefore, 5G URLLC and edge cloud are essential technologies to address those requirements. Despite the fact that some cloud-based robotic applications do not require instant communication, there are still certain applications that require large amounts of communication, particularly where the processing of the cloud is related to the immediate movement of the robot. In the following, certain major challenges of industrial applications that can be solved using cloud robotics are listed: • Fast closed-loop control (1 ms to 10 ms) between controller and device. • Wireless link between controller and device. • Immediate industrial applications in cloud execution environments (e.g., service controllers). • Industrial-grade reliability (e.g., the same as the coil-based ProfiNet). • Flexible production lines (easy to reconfigure and reprogram, low-latency software updates, reconfiguration (i.e., FaaS capabilities)). • Collaborative control and module architecture. • Adaptive algorithms (e.g., for human-machine cooperation, controls must adapt to a constantly changing dynamic environment and require learning and cognitive abilities). • Used for shared data for different control applications.

[0073] In the following, certain cloud robotics scenarios that involve (real or simulated) 4G / 5G connectivity and cloud technologies for industrial robot applications are briefly described.

[0074] One application of cloud robotics involves replacing the hardware programmable logic controller (PLC) in a robot with a software version (soft-PLC), and running the PLC on a commercial HW component in a virtualized environment / cloud. This conceptual study involves a real robot unit with two large robotic arms, a conveyor belt, and certain other industrial devices. For communication, ProfiNet is used.

[0075] One question is what robot control levels can be moved to the cloud via LTE. This is illustrated in Figure 12. High-level control, typically performed by a PLC, is not very latency-critical; that is, depending on the configuration, it has a latency requirement of tens of milliseconds (e.g., about 30 ms). However, the entire communication is very sensitive to latency variations (time base error) and packet loss. For example, in the case of periodic traffic at a frequency of 8 ms, the loss of three consecutive packets or a time base error of 3 × 8 (24) ms can cause the entire robot unit to stop operating. These requirements are easily met when using dedicated hardware in a cable-based solution, but can be challenging when implemented virtually over wireless technology.

[0076] From the perspective of cloud platforms, one of the main challenges brought about by virtualized control is the execution of real-time applications. An application may use a software PLC, which uses Windows 7 as a base OS after the real-time OS responsible for executing the PLC code. Both run in parallel and communicate via inter-processor communication (IPC). The control logic implementation is always executed by the RTOS, and Windows is usually used as a user interface. RTOSs typically have certain specific requirements to ensure necessary performance, such as accurate timers and specific network interface cards. A virtualized environment can be established that can manage the software PLC platform and execute the same control logic as that running on the hardware PLC.

[0077] In a real factory environment, it is feasible to place PLC-level control logic from a dedicated hardware to an edge cloud platform, and it works fully even on LTE. However, if research is conducted on applications that can accurately control the speed, acceleration, or position of actuators, such as trajectory planning, inverse kinematics, and control loops, then a significant reduction in latency is required in the range of 1ms to 5ms. To support such applications, the ultra-reliable and low-latency service of 5G is crucial, as shown in Figure 12.

[0078] One motivation behind moving robot motion control to the cloud is again to increase flexibility. For example, in this environment, it is much easier to rearrange the production line using cloud-based control devices because only the moving device (no controller box required), management is easier, reprogramming is easier, and fault-tolerant transfers or software updates are possible. However, some functions should remain inside / near the robot (using cables) (e.g., certain safety mechanisms) in case of connectivity issues. If the robot can also perform its tasks without a connection, the network requirements are reduced. If a temporary loss of connectivity or reduced performance (e.g., due to extended mobility of the robot in the shop floor), the robot may reduce its operating speed or activate other mechanisms to ensure safety or process objectives, while remaining independent of the network. The robot controller should be removed from the shop floor as an additional entity alongside the robot itself. Figure 13 illustrates one architecture for this type of deployment.

[0079] Another approach is for motion control to be autonomously performed within the robot, with the connection only used to enable new use cases, such as collaborative robot control. For collaborative control, one control entity may still need to quickly access the actual state of other control processes. This option is effective in certain situations, for example, where motion control has a 5 ms control loop within the robot, but only needs to coordinate with another actuator approximately every 100 ms.

[0080] A robot controller that includes trajectory planning and execution has been implemented, and the performance of a robot arm control application via a modeled wireless channel from a regional cloud is being evaluated. The application being evaluated includes closed-loop control of an industrial robot arm, wherein the control is connected to the robot arm via a modeled 5G connection.

[0081] The impact of connection latency on the performance of a robotic arm’s movement quality can be measured using specific key performance indicators (KPIs). An industrial robotic arm has an externally accessible speed control interface that accepts speed commands for each joint (service) and publishes joint status information with an update time of 8 ms. The KPI can be the response time and the accuracy of trajectory execution, i.e., the spatial and temporal deviation from the planned trajectory. Measurements show that network latency below 4 ms has no significant performance impact on this application. This is because (1) due to the internal sampling used in the robot, the robot's internal operations end within a standard deviation of approximately 2 ms in the response time, and (2) the timing units of the robot and the controller are not synchronized. The impact of network latency below 4 ms is masked by background "noise" in the measurement setup.

[0082] Several other conclusions can be drawn: • Response to external events: Low network latency is required because network latency between the robot and the controller directly increases reaction time. • Real-time trajectory refinement (i.e., accurate positioning of the robot arm's end effector): The deadline for trajectory execution necessitates a requirement for maximum tolerable network latency. Typically, higher network latency extends refinement time, thereby increasing the total trajectory execution time. • Trajectory accuracy: Some tasks require accurate movement not only at the final position but also along the path, such as welding. Another example is the collaboration of multiple robot arms, where precise and synchronized movement is crucial. For such tasks, low network latency is desirable if external information is considered in trajectory planning.

[0083] The internal mechanisms of a robotic arm can also impose requirements on network latency. Generally, a system with a low update time requires lower network latency. For example, the control of a robotic arm with an update time of 20 ms tolerates higher network latency compared to a more precise and faster robotic arm with an update time of 1 ms. Furthermore, providing ultra-low latency connectivity for a system with a relatively high update time offers limited performance advantages.

[0084] The performance requirements for trajectory execution can also impose requirements on network latency. Faster robot movement requires lower network latency to achieve accurate movement. On the other hand, if only one high-latency connection is available, using a lower robot speed can compensate for the increased network latency to some extent. Performance optimization can also guide the required network latency. Choosing an appropriate required accuracy can shorten execution time. For example, if a lower accuracy is sufficient for movement, a more lenient accuracy can shorten refinement time.

[0085] New robot concepts and applications include the control of large-scale collaborative robots and the use of digital avatars in networked physical production systems. These topics are briefly discussed in the following sections.

[0086] Hexapod Robot

[0087] When introducing greater cooperation and adaptability into industrial applications such as robotic arms and robot cell control, the cooperation of numerous servers may be required, making the use cases more challenging. Hexapod robots are a useful application for evaluating various challenges arising in an Industry 4.0 robotic cell, such as service control and cooperation. Figure 14 illustrates a hexapod robot, which can be viewed as a cooperative robot-supplier-agnostic system coupled with a 5G slice for cloud-based control.

[0088] A hexapod robot can be viewed as six 3-DOF robotic arms connected by a basic link. To evaluate 5G requirements, servers at 18 joints can be controlled separately from a computer located at a wireless network hop point far from the hexapod robot. In this way, the hexapod robot has proven to be a suitable choice for visualizing the effects of synchronized cooperation. Good synchronized cooperation should result in a stable central position, while any failure in the system will cause platform jitter. Geza Szabo, Sandor Racz, Norbert Reider, and Jozsef Peto reported the results of an evaluation of wireless control of a hexapod robot, "QoC-aware Remote Control of a Hexapod Robot Platform," Budapest, ACM Sigcomm, 2018.

[0089] Digital Doppelganger

[0090] The concept of Digital Avatar (DT) can be used to analyze the impact of a network on the control of a real robot, where the DT runs within a complex robotic cell performing an agile robotic task. An implementable DT can be implemented in the Gazebo simulation environment and evaluated against a fully simulated scenario for solving an Industrial Automation Competitive Agile Robot (ARIAC). This evaluation addresses issues of varying command frequencies, control loops, and the handling of real and simulated robot dynamics. An evaluation of an architecture within a hardware-independent Gazebo add-in demonstrates that network simulation of robot control can be used in low-latency scenarios. In high-latency scenarios, the simulation latency provides approximately 10% margin regarding latency until a complete failure occurs within the robotic cell. These results are reported in Ben Kehoe, Sachin Patil, Pieter Abbeel, and Ken Goldberg, "Research Survey on Cloud Robotics and Automation," IEEE Transactions on Automation Science and Engineering (T-ASE): Special Issue on Cloud Robotics and Automation, Vol. 12, No. 2, April 2015.

[0091] Positioning

[0092] Positioning is considered an important function in industrial and manufacturing contexts, with applications such as personnel tracking (e.g., in mines), safety (e.g., when working near forklifts), tool positioning in manufacturing / assembly workshops, supply chain optimization, and operation of automated guided vehicles. Most use cases only require relative positioning, for example, defining all locations relative to a common reference point in a factory hall.

[0093] The required positioning accuracy and the environmental and radio conditions for performing positioning vary greatly between different use cases. However, most manufacturing uses are indoors, such as a factory hall or a mine tunnel. This means that Global Navigation Satellite System (GNSS) based solutions are difficult to use because the signal strength received from satellite transmissions indoors is very low, resulting in no coverage or very little coverage.

[0094] The limitations of indoor GNSS systems have opened the door to cellular-based positioning solutions. Today, commonly used positioning solutions in industrial and factory settings are based on Wi-Fi, Radio Frequency Identification (RFID), Low Energy Bluetooth (BLE), Ultra Wideband (UWB), and LTE. Narrowband (NB)-IoT and CAT-M are 3GPP LTE technologies designed for low-complexity, low-power, and low-cost devices; therefore, they are the only viable 3GPP positioning solutions for situations where the asset being located does not yet contain a 3GPP modem for communication purposes. Radio solutions (such as RADAR) and non-radio solutions (such as LIDAR and computer vision systems) are also important, especially when high-accuracy (sub-meter) positioning is required.

[0095] Multipath propagation is often a key source of error in positioning. In industrial settings, path delays are typically relatively short, but these paths remain crucial given the need for accurate positioning in such environments. Most positioning algorithms operate under the assumption that line-of-sight (LoS) measurements are available, and there is no direct way to distinguish between line-of-sight (LoS) and non-line-of-sight (nLoS). If an nLoS path is incorrectly used instead of a LoS path for positioning, time difference ranging and angle of arrival can be misleading. The time difference ranging of an nLoS path will be an upper limit of the time difference ranging of a LoS path, and the angle of arrival may be completely incorrect. Therefore, an nLoS path can significantly degrade the performance of positioning algorithms. Future industrial positioning solutions need to satisfactorily address this problem.

[0096] Another obstacle to accurate positioning is network synchronization error. Practical network synchronization algorithms may implicitly contain network synchronization errors of up to 360 ns, corresponding to a positioning error of ±110 m. Radio Interface Based Monitoring (RIBM) is a promising alternative for improving positioning accuracy. This solution uses base station timing measurements based on positioning reference signals from neighboring base stations and estimates the synchronization offset between base stations, thus providing a more accurate "virtual synchronization." Another option is to consider positioning techniques that do not require network synchronization, such as those based on round-trip time and / or angle of arrival measurements. Note that any estimations of positioning accuracy described herein assume good network synchronization has been achieved, for example, using RIBM.

[0097] By considering the trajectory of movement, positioning accuracy can be significantly improved, especially between the time intervals of measurement. Furthermore, inertial measurement units (IMUs) are increasingly being used in terminals as a means of updating position estimates. They use accelerometers and gyroscopes (and sometimes magnetometers) to track the movement of the terminal.

[0098] Deployment Status

[0099] To reduce costs and simplify deployment, a solution that combines both communication and positioning into one system is preferable. This is especially important in environments where deploying a separate positioning system is difficult and expensive (e.g., in mines where the installation cost per node is typically high). However, if a communication deployment, for example, including one or several micro base stations, cannot provide sufficiently good positioning accuracy, then adding a separate or complementary positioning system on top of the communication system may be the best solution, as high-precision positioning typically requires a denser deployment compared to communication.

[0100] The achievable positioning accuracy largely depends on the density of the deployment and the characteristics of the radio environment. Therefore, densification of the communication network can be one means of improving positioning accuracy. In environments with severe multipath propagation, especially where multipath propagation is dynamically changing, a dense deployment is particularly important because otherwise there may not be enough Loss of Sight (LoS) paths available for location estimation. A dense deployment may also be needed to ensure the location of hidden objects with high signal attenuation.

[0101] Network density is a key factor in providing sufficiently good positioning accuracy in manufacturing scenarios. Another deployment factor to consider is the ease of installing anchor nodes. Installation may involve manually providing the exact location of the anchors, which can be difficult, time-consuming, and error-prone. To avoid this, a Simultaneous Localization and Mapping (SLAM) algorithm can be used to estimate the position of each anchor during the initialization phase.

[0102] To make dense deployment cost-effective, the cost of each anchor must be kept low. However, the cost of each anchor / base station used to provide both communication and positioning is naturally higher than that of technologies that only provide positioning (e.g., RFID and UWB). One way to reduce the cost involved in densifying communication networks to achieve high-precision positioning might be to develop simple anchors with reduced positioning capabilities using the same technology as the more expensive base stations. For example, just one or a few high-capacity NR base stations installed on the ceiling of a factory hall might be sufficient to provide communication coverage. Then, densification can be achieved using lower-capacity NR positioning nodes / anchors to achieve high-accuracy positioning.

[0103] Another way to reduce the need for a very dense deployment is to combine NR's advanced beamforming capabilities with reflectors. In this way, each pair of transmission beams and reflectors can act as a virtual anchor, thereby achieving the benefit of a very dense deployment using only a few NR base stations. One challenge of this solution is stability, as the reflectors should be stationary or at least change only slowly to ensure stable positioning accuracy.

[0104] Spectral state

[0105] As is well known, positioning accuracy improves with increasing bandwidth. Furthermore, higher signal bandwidth allows for greater resolution of the Loss-leading edge and the nLoS-dominant received signal, thus making it easier to accurately detect LosS paths. On the other hand, using a higher carrier frequency reduces the detectability of LosS paths due to increased signal attenuation.

[0106] Currently defined frequency bands are for regional use, such as the 3.7 to 3.8 GHz band in Germany and Sweden. Nationwide spectrum and / or unlicensed spectrum may also be used for industrial purposes. A 100 MHz bandwidth should be sufficient to achieve sub-meter positioning accuracy. Different spectrum blocks can be combined to further improve performance.

[0107] Accuracy Requirements

[0108] Positioning accuracy requirements range from millimeters to a few tenths of a meter. For example, drilling and blasting in mines, as well as automated manufacturing (alignment, assembly), can benefit from millimeter- to centimeter accuracy. Other examples requiring centimeter- to decimeter accuracy include positioning tools in manufacturing / assembly shops and tracking automated guided vehicles. Decimeter- to meter accuracy is necessary for certain safety solutions, such as personnel tracking and immediate warnings to personnel working near a forklift, but it is also necessary when considering factors such as supply chain optimization and asset tracking (e.g., tools, machines).

[0109] 3GPP outlines the positioning requirements for 5G positioning services in Section 5.7, "Positioning Performance Requirements," of TS22.104. Table 2 summarizes some of these requirements. According to 3GPP, depending on the use case, 5G systems should support the use of both 3GPP and non-3GPP technologies to achieve higher positioning accuracy. context Horizontal accuracy Availability go ahead Latency of UE position estimation UE speed Mobile control panel with safety features (non-hazardous area) < 5 m 90% not applicable < 5 s not applicable Process Automation – Factory Asset Management < 1 m 90% not applicable < 2 s < 30 km / h Flexible modular assembly area in a smart factory (for tracking tools at workplace locations). (< 1m relative positioning) 99% not applicable 1 s < 30 km / h Augmented Reality in Smart Factories < 1 m 99% <0.17rad < 15 ms < 10 km / h A mobile control panel with safety features in a smart factory (located in hazardous areas of the factory). < 1 m 99.9% <0.54rad < 1 s not applicable Flexible modular assembly area in a smart factory (for autonomous vehicles, for monitoring purposes only). < 50 cm 99% not applicable 1 s < 30 km / h Inbound logistics of manufacturing (used for driving trajectories of autonomous driving systems (in cases supported by other sensors such as cameras, GNSS, and IMU)) < 30 cm (when supported by other sensors such as cameras, GNSS, IMU, etc.) 99.9% not applicable 10 ms < 30 km / h Inbound logistics from manufacturing (used for storing goods) < 20 cm 99% not applicable < 1 s < 30 km / h Table 2 – Summary of Positioning Requirements from 3GPP TS 22.104

[0110] Overview of Positioning Technology

[0111] The following question provides an overview of one of the positioning technologies that may be useful in manufacturing, with a focus on how such positioning technologies can be applied in a manufacturing context. The focus is on 3GPP technology, but several other technologies are also considered here. Positioning using RFID and BLE beacons is not included in this overview, but it will be understood that many of the same principles apply, and the various technologies described herein can be combined with these and other positioning technologies.

[0112] LTE OTDOA

[0113] Since version 9, LTE supports Observed Time Difference of Arrival (OTDOA) positioning, which is based on the Reference Signal Time Difference (RSTD) measurement described in 3GPP TS 36.305. The UE receives a Positioning Reference Signal (PRS) from neighboring cells, uses RSTD measurements to estimate the Time of Arrival (TOA) of each cell, and reports the TOA relative to a reference cell. Subsequently, the Evolved Serving Mobile Location Centre (E-SMLC) estimates the UE's location based on the known eNB location. The use of Time Difference of Arrival (TDOA) relative to a reference cell instead of TOA eliminates the requirement for UE time synchronization, although network synchronization is required. In principle, 2D positioning requires at least 3 cells, and 3D positioning requires at least 4 cells.

[0114] Figure 15 illustrates how the UE location can be estimated from three eNBs based on the principle of OTDOA, and is a conceptual diagram of 2D TDOA-based positioning assuming perfect TDOA measurement. When multiplied by the speed of light, each TDOA (the TOA of the reference eNB minus the TOA of the eNB) is converted into a distance difference (e.g., in meters). Each TDOA returns a hyperbola on the 2D plane of the possible UE locations. The intersection of these hyperbolas is the UE location. In practice, this location is estimated using Gauss-Newton search or similar numerical algorithms by E-SMLC.

[0115] In LTE, RSTD can be estimated based on cell-specific signals or based on a situationally defined PRS. However, TDOA estimation procedures typically use PRS because other cell-specific reference signals do not guarantee a sufficiently high probability of detecting neighboring cells with low (below -6 dB) signal-to-interference-noise ratio (SINR). PRS is defined by a Gothic sequence initialized by time variables (slot number within a frame and OFDM symbol number within a slot) and PRS ID, and allocated in a diagonal pattern shifted across subcarriers. Basically, three main factors contribute to high PRS detectability: • The Gothic sequence guarantees low cross-correlation properties. • Each resource block and OFDM symbol has 2 PRS resource elements, with a distance (reuse factor) of 6 subcarriers. The specific position of each PRS diagonal is determined by PRS ID mod 6. Subcarriers not used for PRS are empty to establish LIS (Low Interference Subframe). • When receiving PRS from a distant cell, the PRS can be muted in certain transmission scenarios to increase SINR.

[0116] The RSTD is obtained from the power delay variation curve (PDP) generated by cross-correlating the received downlink baseband signal with the PRS. The challenge here is to detect the earliest peak in the PDP (which is not a noise peak) and then obtain the peak delay according to a multiple of the sample. One of the main sources of TOA error is the nLoS condition, in which the LoS path is not detected due to obstruction or blockage.

[0117] In practical deployments, the positioning accuracy achievable using LTE OTDOA is approximately 50 m to 100 m for Release 9 series. In LTE Release 14, the reporting resolution of E-SMLC changed from Ts to Ts / 2, where Ts is the basic time unit in LTE (32.55 ns), to improve the relative distance resolution from 9.8 m to 4.9 m. However, it remains unclear what level of accuracy can be achieved in practice. Furthermore, OTDOA requires network synchronization, and any reduction in synchronization errors will affect the achievable positioning accuracy. For LTE, available Mobile Broadband (MBB) UE chipsets cover most positioning methods standardized up to Release 14.

[0118] Figure 16 illustrates the OTDOA positioning results in a 3GPP indoor open office (IOO) scenario using different bandwidths: 100 MHz (30 kHz SCS, 275 PRB), 50 MHz (15 kHz SCS, 275 PRB), 10 MHz (15 kHz SCS, 50 PRB), and 5 MHz (15 kHz, 25 PRB). The plot is based on the existing tracking reference signal (TRS) used for positioning as the baseline in the NR.

[0119] This scenario uses 6 gNBs spaced 20 meters apart (12 gNBs in total). ("gNB" is a 3GPP term used for an NR base station.) Results show that increasing the bandwidth from 5MHz to 10MHz and further increasing it to 50MHz significantly improves positioning accuracy. However, it is also evident that the results at 100MHz and 50MHz are similar, with an accuracy of approximately 8 meters at the 80th percentile. The 100MHz case can be further improved by using a more advanced peak search algorithm for Time of Arrival (TOA) estimation. In the current simulation, the earliest peak in the PDP, which is at least half of the highest peak, is considered the LOS peak. Increasing the signal-to-noise ratio (SNR) can improve the probability of detecting peaks above the noise floor. Furthermore, if OTDOA becomes unreasonable, errors in inter-site distance (ISD) greater than 20m can be practically compensated by combining it with a simple cell ID (CID) estimate, but this operation is not performed here.

[0120] Narrowband (NB)-IoT and CAT-M are 3GPP LTE technologies that address low complexity, low power consumption, and low cost devices. The availability of these low-cost devices makes them the only realistic 3GPP solution for situations where the asset to be located does not yet contain a 3GPP modem for communication purposes. However, when using IoT devices, positioning accuracy is significantly worse, primarily due to the narrow bandwidth used. A simulation study demonstrated that in an indoor deployment, the positioning error at the 70th percentile for NB-IoT was 100 m, while LTE using 50 PRBs for positioning gave ~23 m at the 70th percentile in the same scenario.

[0121] The narrow bandwidth of NB-IoT devices can be partially compensated by enabling longer PRS scenarios in a timely manner. However, this is undesirable because the PRS is repeated every frame (10 ms). NB-IoT devices also have a lower sampling rate to reduce power consumption, which reduces the accuracy of RSTD measurements.

[0122] Chipsets for LTE IoT devices are not as readily available as LTE MBBs. However, development is underway and availability is slowly improving.

[0123] As of December 2018, no IoT positioning for NR was defined, but one contributing factor to achieving better IoT positioning accuracy is, for example, improving the time-related properties of the PRS by increasing the PRS repetition interval. Carrier aggregation for NB-IoT, with increased bandwidth, has also been discussed as another contributing factor to improved IoT positioning in this case. Another alternative is to modify the phase of the eNB PRS, thereby ensuring that NB-IoT devices can sample at low rates while still detecting the phase of the PRS.

[0124] LTE Enhanced Cell ID Positioning

[0125] Enhanced Cell ID or E-CID is introduced in LTE Release 9. The UE reports the serving cell ID, timing advance and ID, and estimated timing and power of detected neighboring cells to the network. The eNB can report additional information to the positioning server, such as angle of arrival, cell portion, round-trip time, etc. The positioning server estimates the UE's location based on this information and its understanding of cell locations.

[0126] The accuracy of E-CID depends primarily on deployment density. For outdoor deployments, the accuracy of E-CID can be approximately 100 m in urban environments with an ISD of less than a few hundred meters, or approximately 3000 m in rural environments with an ISD of several thousand meters. The accuracy of E-CID in manufacturing environments has not been studied, but it is expected to be approximately ISD, as the environment contains many multipath paths and (for example) angle of arrival data can be misleading due to reflections. On the other hand, even in this challenging scenario, if radio propagation is stable and a calibration / training phase is feasible, RF fingerprint analysis should be able to provide an accuracy of a few meters.

[0127] NR Location Features

[0128] As of December 2018, there is no defined concept for NR positioning. It is conceivable that NR features will achieve improved positioning accuracy superior to LTE OTDOA. Some of these features also present new challenges: • Better ranging and angle of arrival / angle of departure (AoA / AoD) estimation in beam-based systems. • Support for higher carrier frequencies in NR, meaning signals are more susceptible to obstruction / blocking. This can be partially addressed by beamforming. Furthermore, higher carrier frequencies are typically accompanied by wider bandwidth, resulting in better RSTD resolution. • Denseer deployment for smaller inter-site distances and cell radii. This requires more complex golden sequence initialization to maintain code orthogonality across all possible beam / cell ID combinations, compared to beamforming combinations using specific beam IDs. • Better time alignment is expected in NR, thereby reducing time synchronization errors. • A reduction in the basic time unit compared to LTE. The maximum number of PRBs is 275 (compared to 110 in LTE), thus requiring an FFT length of 4096 (twice that of LTE). Furthermore, the subcarrier spacing ranges from 15kHz to 240kHz. Essentially, this implies a shorter sampling interval than in LTE, thereby improving TOA positioning resolution.

[0129] The solution for NR Release 16 standardization is expected to provide the tools needed to achieve sub-meter accuracy. Link-level simulations demonstrating the technical potential of NR indicate that sub-decimeter accuracy is theoretically possible. The Release 16 NR positioning 3GPP research project began in October 2018.

[0130] Positioning using a radio point system

[0131] Ericsson's Radio Point System (RDS) is well-suited for communications in indoor industrial and manufacturing environments. However, with RDS products available as of December 2018, location based solely on cell ID is possible because it is impossible to distinguish DOTs connected to the same IRU. Furthermore, an RDS is typically deployed with both large and small cells, as up to eight DOTs can connect to the same IRU. In the case of digital 5G DOTs, up to 16 DOTs can connect to the same IRU.

[0132] An improvement to the positioning accuracy has been proposed, making per-DOT positioning possible. A combined uplink time difference of arrival (UTDOA) algorithm and DOT-level power is used to calculate the UE's location. Simulations have shown that a positioning error of less than 1 meter can be achieved with good SNR and good DOT geometry. However, when considering various error sources (such as the accuracy of DOT location and DOT cable length delay), a positioning error of approximately 1 to 5 meters is possible.

[0133] For typical manufacturing scenarios with severe multipathing, due to the dense deployment of nodes and low cost, Radio Point Systems (RDS) seem to be the most suitable solution for providing combined communication and positioning.

[0134] Wi-Fi positioning

[0135] Wi-Fi is widely deployed in industry and is therefore commonly used for positioning. One widely deployed Wi-Fi solution is the ARUBA solution, which can achieve an accuracy of approximately 5m to 10m on its own using the Received Signal Strength Indicator (RSSI) of the access point, depending on obstruction and antenna pattern. For even better positioning accuracy, the ARUBA solution can be combined with a Bluetooth Low Energy (BLE) battery-powered ARUMBA beacon. With this dedicated positioning solution, very good accuracy of <3m can be achieved, and even accuracy of <1m is possible when the device to be located is close to a beacon.

[0136] A leading industrial Wi-Fi positioning solution achieves an average accuracy of 1m to 3m in office environments. This positioning solution includes an additional Wi-Fi wireless device with a dedicated antenna array, housed within the same unit as the Wi-Fi wireless device used for communication. Position is estimated using a combination of RSSI and angle of arrival (AoA) measurements.

[0137] One difference between Wi-Fi positioning and 3GPP-based OTDOA positioning is that Wi-Fi positioning (IEEE 802.11mc) can be based on round-trip time (RTT). Compared with the OTDOA algorithm described above, the advantage of using RTT is that it does not require network time synchronization.

[0138] UWB

[0139] Ultra-wideband (UWB) technology has become increasingly popular in positioning solutions due to the inherent high temporal resolution of UWB signals, enabling accurate positioning. Several UWB-based positioning products are available. Many of these UWB-based positioning products are based on DecaWave UWB technology, but proprietary solutions also exist (e.g., Zebra).

[0140] UWB can be used in multiple algorithms. It can support downlink or uplink TDOA, angle of arrival using multiple antennas, and direct range measurement, without requiring network time synchronization at all.

[0141] Due to the very short transmission pulses used in UWB technology, UWB can detect and eliminate problems caused by multipath propagation by individually detecting and filtering reflections. This is a significant advantage compared to narrowband systems, where such discrimination is impossible. The accuracy of time-difference ranging is in the range of 2 cm to 5 cm. When applied in a real-world environment, the positioning accuracy of UWB is 10 cm.

[0142] Compared to 3GPP modules, one advantage of UWB is the potential for cheaper devices. The price of a commercial UWB transceiver is approximately US$3 to US$4. This enables increased installation density, flexible selection of support for various use cases and cloud platforms to support algorithms in a global ecosystem (which can serve all aspects of the global ecosystem).

[0143] Guangda

[0144] Some positioning technologies estimate distance by measuring the round-trip time of an ultrasonic or electromagnetic wave to an object. Ultrasonic waves suffer significant losses in air and cannot reach distances beyond a few meters. Radar and LiDAR use electromagnetic waves in the radio and optical spectra, respectively. The shorter wavelength of light waves (compared to radio frequency waves) translates to better resolution, making LiDAR solutions an advantageous choice for high-accuracy positioning. As in radar solutions, a typical LiDAR system comprises a transmitter and a receiver, and measures distance based on the round-trip time of light to the target. This is achieved by modulating the intensity, phase, and / or frequency of the transmitted light waveform and measuring the time required for the modulated pattern to reappear at the receiver.

[0145] Popular LiDAR architectures include pulsed and frequency-modulated continuous wave (FMCW) schemes. Pulsed LiDARs rely on the particle nature of light and can provide moderate accuracy over a wide window, while FMCW LiDARs rely on the wave nature of light. In these LiDARs, the frequency of the light field is modulated, and a large frequency bandwidth in the optical domain becomes accessible and can be used to achieve very high-precision localization, with accuracy in the nanometer range.

[0146] Summary of Positioning Technology

[0147] Table 3 summarizes the key properties of the positioning technologies discussed in this chapter. It should be noted that the accuracy figures presented are for illustrative purposes only. Actual positioning accuracy depends on various factors, including but not limited to network deployment, cell planning, radio environment, etc. method Accuracy Device and anchor Integration with communication systems Required network synchronization Deployment status LTE OTDOA Version 9: Approximately 50 m to 100 m Version 14: Standard support of approximately 5 MB If a cheaper device is needed, expensive devices and anchors can be used with NB-IoT. yes yes The several eNBs in the ceiling usually provide sufficient communication coverage for a factory lobby. NR OTDOA AoA Expected accuracy of sub-meter Expensive equipment and anchors are expected at least in the near future. yes OTDOA: Yes AoA: No The several gNBs in the ceiling usually provide sufficient communication coverage for a factory lobby. radio point CID UTDOA Currently: Only the community ID is available, ranging from approximately 30 m to 200 m. H2 2020: Regional support per point, approximately 3 m to 5 m Mid-cost per anchor yes CID: No UTODA: Yes Typically deployed with 20m ISD NB-IoT OTDOA LTE OTDOA: 100 m below the 70th percentile indoors RDS: In the future, <5m may be possible. Cheap device Yes, for limited flux and relaxed latency requirements yes A single eNB may provide sufficient communication coverage, but a denser deployment is needed to perform location services. Wi-Fi RSSI AoA RTT Standard solution: 5 m to 10 m Specialized solutions: 1 m to 3 m Relatively expensive anchors when used specifically for positioning yes no Typical coverage is about 50m, but Aps are usually deployed more densely. UWB OTDOA UTDOA AoA RSSI Products on the market require an accuracy of 0.1m. Cheap equipment and anchors Complexity and power consumption in the anchor rather than in the device no OTDOA: Yes UTDOA: Yes AoA: No RSSI: No Typically deployed very densely (e.g., with 10m ISD) Simple configuration solutions are available. Table 3 – Summary of Positioning Technologies

[0148] Hybrid Positioning

[0149] Many devices on the market today are equipped with sensors, such as an inertial measurement unit (IMU). This IMU may contain a 3-axis gyroscope and a 3-axis accelerometer, for example. The data provided by the IMU allows the positioning server to estimate the UE trajectory between, after, or during an OTDOA / E-CID positioning operation phase, reducing the need for frequent OTDOA / E-CID measurements. A hybrid positioning solution using an IMU can also be beneficial in scenarios where the device can partially move out of the positioning coverage area to increase positioning reliability. Figure 17 illustrates an example use of IMU data and position estimation. The same method can be applied even when IMU measurements are unavailable, by estimating velocity and direction based on old position estimates and predicting the UE trajectory.

[0150] It should be noted that the positioning system based solely on the IMU is a relative positioning system, that is, it can estimate the position of a UE relative to a known coordinate. For example, a pressure difference within a cycle translates into a change in altitude, and an acceleration during a cycle indicates a change in velocity.

[0151] To integrate radio measurements and IMU data, the data reported by the UE equipped with an IMU needs to be aligned with a standardized Earth-defined coordinate system. Alternatively, the IMU measurements reported by the UE can enable the positioning server to convert the measurements into an Earth-defined coordinate system. To obtain the UE's position in Earth coordinates, device orientation is required. A common method for determining orientation is to use a gyroscope, magnetometer, and accelerometer. After estimating orientation, the orientation and accelerometer can be used to estimate the acceleration relative to the coordinate system (accelerometer reading minus gravity). With relative acceleration, the relative displacement of the device can be estimated, for example, by double integration.

[0152] LTE version 15 includes support for IMU positioning and communication specifications, as well as procedures for supporting IMU positioning via the Location Positioning Protocol (LPP) and supporting hybrid positioning that includes IMU-related estimates.

[0153] Network synchronization accuracy

[0154] For OTDOA and Uplink Time Difference of Arrival (UTDOA) (which is a positioning method supported in LTE), the network synchronization error that causes the TDOA estimation error dominates the overall positioning error. Therefore, understanding the achievable network synchronization accuracy is important. By considering the distance traveled by light during the timing error caused by the synchronization error, the synchronization error can in principle be directly converted into a positioning error; that is, a synchronization error of 1 ns corresponds to a positioning error of 0.3 m.

[0155] Synchronization error mainly consists of four additional components: 1) Error delivered to the external synchronization reference of the anchor (baseband unit of the giant base station and DOT). 2) Synchronization error between the anchor (baseband unit) and the external synchronization reference. 3) Synchronization error within the radio base station (RBS). 4) Synchronization error between the RBS antenna and the UE.

[0156] When considering the manufacturing scenario, the following situations apply to each of the four parts: 1) The external synchronization reference is typically from a GNSS receiver. A GNSS receiver can have an accuracy of <50 ns when it has a LoS over most of the sky, but the accuracy drops rapidly when multipath is present, and the assumed accuracy from an indoor GNSS receiver is <200 ns. External synchronization can be improved by using a more expensive GNSS receiver with better multipath filtering and better internal accuracy. 2) The baseband unit can be synchronized to a GNSS receiver with an accuracy of approximately 150 ns. This number can be improved simply by using better hardware (i.e., a new baseband unit). 3) The budget for internal allocation is 130 ns. In practice, this depends on a batch of RBS hardware configurations. The simplest is a single-hop direct connection to a single baseband unit of the antenna integrated radio (AIR) unit. 4) It is unclear how large the synchronization error is between the RBS antenna and the UE. However, this error does not affect the OTDOA positioning error because OTDOA is based on the phase of the PRS observed by the UE at its location and does not require synchronization between the network and the UE.

[0157] The above discussion assumes that the RBS time is locked to a reference. When the RBS is extended in time, the accuracy may decrease.

[0158] The above-mentioned number can be significantly improved by radio interface-based monitoring (RIBM), in which the phase difference between an RBS antenna and a reference is measured and reported. This reported phase difference can then be taken into account when calculating the position of an object. Synchronization errors still exist, but the portion of the error taken into account does not affect the accuracy of OTDOA positioning. This is a promising method because RIBM can achieve a virtual synchronization accuracy of approximately 20 ns between RBSs. Therefore, external synchronization reference errors 1) do not affect OTDOA positioning and can be ignored.

[0159] For RDS, assuming the IRU contains common DOT hardware, the synchronization time between DOTs connected to the same IRU is approximately 6 ns. This applies to both existing DOTs available today and digital 5G DOTs that will be available in 2019. RIBM can be one solution for achieving synchronization between DOTs connected to different IRUs, but it may require a special feature to operate because the standard RIBM algorithm requires nodes to be synchronized for reception when not transmitting, which is not the case for DOTs.

[0160] In summary, the practical network synchronization algorithm can imply a network synchronization error of up to 360 ns when locked to a GNSS reference, corresponding to a positioning error of up to ±110 m (3 Σ). If the RBS is over time, the accuracy can be even worse. In the future, RIBM can provide a virtual synchronization accuracy of approximately 20 ns, corresponding to a positioning error of 6 m. For RDS, positioning using DOTs connected to the same IRU is affected by a synchronization error of approximately 6 ns (corresponding to a positioning error of approximately 2 m). If DOTs connected to different IRUs are used to estimate the position, RIBM can be applied in the future to provide a virtual synchronization accuracy of approximately 20 ns.

[0161] Improving accuracy in severe multipath scenarios

[0162] If the multipath problem cannot be addressed, LTE OTDOA and other positioning algorithms suffer severe penalties in terms of positioning accuracy. Essentially, OTDOA assumes RSTD represents the Loss of Sight (LoS) path, but it is generally difficult to determine whether a LoS path is blocked or heavily damped. At least one could say that an nLoS path represents an upper limit to the distance between the transmitter and receiver. The multipath problem is significant in typical industrial environments, especially at high frequencies. Some methods for addressing the multipath problem include: • Designing the network to have good LoS conditions by placing nodes in advantageous locations (for example, by using a planning tool that can estimate the positioning accuracy of several reference locations). This can imply higher installation complexity and may not be feasible for industrial environments with many moving objects. • Using hypothesis testing (e.g., feasibility testing) to estimate nLoS using a subset of locations from the TOA / TDOA estimates. If the estimates are inconsistent, they are classified as nLoS. This method can have high computational complexity for dense networks. • Another alternative is to consider location updates based on IMU measurements and dead reckoning as a reference, classifying the path as nLoS if the measured TDOA does not match the reference position sufficiently well. • Use an environment model for ray tracing and correlate distance estimates with rays. In this way, nLoS estimation can contribute to positioning estimation in a better manner. Such environment models are typically unavailable but can be used in the development of a digital avatar. • Use polarization to estimate nLoS. Polarization changes during bounce events, so nLoS is detected if a reference polarization is incorrect. • Compare individual distance estimates with a communication-independent velocity / position measurement (gyroscope / accelerometer) to determine which estimates are feasiblely LoS. Of course, not all UEs are equipped with such position sensors. • Version 14 introduces a significant enhancement to LTE OTDOA called Multipath Reference Signal Time Difference (RSTD). The main idea is to include several possible peak candidates from the Power Delay Variation (PDP) curve and use the closest approximation to estimate the position. This significantly improves positioning accuracy because the algorithm does not make difficult decisions on the Loss of Sense (LoS) path.

[0163] In summary, the selection of the most suitable positioning system for manufacturing must consider several different parameters, including: • required accuracy • required latency • deployment parameters • device

[0164] When accuracy is involved, there exists industrial use situations where positioning requirements range from mm-level accuracy to a few tenths of a meter. In one environment with one high probability of LoS and few barriers to blocking, the position may be estimated within ten meters to a few tenths of a meter accuracy in a deployment with only one or a few micro base stations installed in the ceiling of (for example) a plant hall. However, in many manufacturing situations, reality is one with multiple paths, reflections and numerous blocking barriers. In such scenarios, it appears that the radio point system (RDS) is the most suitable solution for providing combined communication and positioning due to the intensive deployment and low cost of nodes.

[0165] The number of accuracies stated for different positioning techniques usually assumes that the network synchronization is sufficiently good. However, in many cases, it is very difficult to achieve a network synchronization error of approximately 10 ns to 20 ns corresponding to the positioning error of 3m to 6m. For positioning needs, virtual network synchronization achieved through RIBM is the most promising solution.

[0166] UWB solutions are becoming increasingly popular in industrial and manufacturing use scenarios due to their high accuracy and relatively cheap devices. However, one drawback is: UWB solutions are not integrated with a communication system, for example, this is the case for 3GPP-based solutions. In the future, NR can replace UWB, this is because NR will also use very wide bandwidth.

[0167] The positioning diving time requirements for manufacturing are relaxed for most use cases. For example, tracking tools and assets do not require very frequent positioning updates. Most demanding manufacturing use situations can be safety related in terms of positioning latent times. One instance alerted one of the workers to an instant alarm when a forklift approached. The trade-off between the high accuracy of this use case and the positioning latent time has not been adequately studied.

[0168] It is also important to consider the relationship between the device and the anchor. For LTE and NR, both devices and anchors are complex and costly, and solutions based on these technologies are therefore not suitable in which the use of numerous small objects should be tracked, this is because each object must have its own LTE or NR device. In this case, UWB or RFID can be more appropriate, this is because most of the complexity is located in the anchor node and the device / tag is therefore cheap. 3GPP-based technologies with cheap devices (such as NB-IoT or CAT-M) can also be considered for this type of usage, but the achievable positioning accuracy is low since these technologies are narrowband.

[0169] Spectrum

[0170] For industrial applications, certain spectrum-related issues include: • Spectrum suitable for regional use; • Regulatory means for achieving regional spectrum use, such as leasing and regional concessions; • Technical means for achieving regional spectrum use, such as Evolved Shared Licensed Access (eLSA) and Citizens Broadband Radio Service (CBRS). • 5G NR will be used as one of the access technologies in various frequency bands (including many currently used for LTE). Several frequency ranges may be more harmonized globally, such as 3400 MHz to 3800 MHz and the portion above 24 GHz to 29 GHz, although there may be changes in band planning. The research process of WRC-19 (World Radiocommunication Conference 2019), which led to the band identification of IMT2020, could generate additional millimeter-wave (mmW) spectrum bands with good harmonization potential, such as 37 GHz to 43 GHz.

[0171] Recent regulations have designated frequency bands for "regional or regional use" (e.g., 3700 MHz to 3800 MHz in Germany and Sweden, and 3300 MHz in China). These actions are not part of an all-encompassing radio solution for industrial IoT. However, the introduction of these frequency bands is a good first step towards the private use of spectrum. It is not expected that these regulatory actions will immediately spread to all markets. Therefore, it is clear that additional access to globally coordinated spectrum will require opportunities derived from spectrum licensed to mobile network operators (MNOs), which is essentially achieved through commercial configurations allowing the leasing of spectrum or capacity under well-defined service level agreements (SLAs).

[0172] The availability of mmW spectrum does pose a challenge to industrial IoT, primarily due to the time required to establish products in the market and the complexity of semiconductor manufacturing at such high frequencies. There is no established practice in device deployment, where cost-effective solutions for devices remain a significant challenge. Millimeter-wave devices also offer certain advantages: the propagation characteristics of narrow-beam transmitters can be better reused through transmission power control and beamforming, and coexistence can be equally easier. The bandwidth is also suitable for wider-bandwidth signals, although uncertainties remain regarding the amount of spectrum available for industrial wireless applications.

[0173] The Fourth Industrial Revolution (referred to as Industry 4.0 in the literature) presents an opportunity for 5G wireless technology in manufacturing, exploration, and process control within factories, mines, and processing industries. Utilizing these opportunities will require access to unlicensed, shared, or exclusively licensed spectrum. In fact, there is a clear indication in industry that the lack of access to high-quality licensed spectrum is a key obstacle that must be overcome. Access to licensed spectrum for industrial IoT can be provided in one of three ways: 1. Service Level Agreement (SLA): An agreement with an MNO can meet these requirements using services provided or deployed by the MNO; for example, • an internal MNO deployment on a keyed basis or an end-user deployment of approved devices that the MNO permits to connect to a public network, as appropriate. This scenario is not further discussed here. • An alternative is to establish a private virtual network that guarantees capacity on an MNO network through network segmentation. 2. Spectrum Leasing: The MNO acts as a lessor for a vertical industry. 3. Regional concessions: Regulators grant spectrum directly to vertical industries through a limited geographical deployment that is usually associated with property rights in the covered area.

[0174] The following summarizes the regulatory landscape of spectrum leasing. Spectrum leasing regulations are of interest for potential business models in 5G usage. • The US has the most mature regulations on spectrum leasing; these regulations date back to 2003-2004. Spectrum leasing is used commercially. The Universal License System (ULS) in the public database records all leasing agreements. • In South America, several countries allow leasing between MNOs. • In the EU, leasing of major operational / cellular bands has been permitted in regulations since 2012. This leasing may not be implemented in the regulations of member states. To date, no instances of commercial leasing of frequencies owned by MNOs to non-MNOs have been found. • In Asia, spectrum leasing is generally prohibited in several key countries and is therefore not part of the regulations. • In Africa, spectrum leasing is generally not permitted.

[0175] Regarding regional concessions, there are currently no such concessions available for private / public use. Certain 5G use cases will benefit from regional concessions, particularly in relation to industrial automation; the introduction of 5G offers an opportunity in this regard. The planned auction of Europe's first 5G spectrum band (3.4 GHz to 3.8 GHz) has already triggered regulatory activity in two countries (Germany and Sweden) by defining a specific implementation of regional concessions. In China, industry has shown interest in dedicated spectrum.

[0176] In order to provide a comprehensive view of one possible solution, unlicensed frequency bands suitable for industrial applications are also mentioned. These unlicensed frequency bands are generally unsuitable for URLLC due to the potential for interference (attributed to contention-based operations); variations in access performance result in uncertainties in throughput and latency performance.

[0177] The Evolved LSA (eLSA) is currently designated as a solution to support leasing and territorial concessions within regulations using a database / controller architecture. The eLSA should support any frequency band and be technology-neutral. Similarly, the US Citizens Broadband Radio Service (CBRS), which will initially operate in the 550 MHz to 3700 MHz band, will use a Spectrum Access System (SAS) to handle regulatory requirements for that band. This is also a database / controller architecture that provides leasing opportunities for territorial use while effectively granting concessions covering a larger area under FCC regulations. Given appropriate regulatory requirements, the SAS can also be used in other frequency bands. Depending on the required regulatory requirements in a country or region, eLSA and CBRS will accommodate coexistence between different deployments. However, the methods for ensuring coexistence differ between eLSA and CBRS.

[0178] Many different spectrum bands have been identified for 5G. Here, only bands that may use NR technology are discussed. For example, the 700 MHz band was identified as a 5G band at the European Conference on Postal and Telecommunications Administration (CEPT), but it will likely be used for 4G. The same applies to APAC regarding the 700 MHz band. Moreover, the 2.3 GHz band has been discussed (for example) in Sweden, but is currently mainly used for 4G.

[0179] Currently, there are no valid 5G 3GPP coordinated frequency bands allocated to all countries worldwide, but coordinated spectrum ranges do exist, such as 3400 MHz to 3800 MHz and 24.25 GHz to 29.5 GHz. Several 3GPP frequency bands will be defined within each range. The numerous mmW frequency bands to be allocated depend on the results of WRC-19.

[0180] Europe

[0181] The 3400 MHz to 3800 MHz band is identified as one of the "pioneer bands" for 5G on CEPT. Plans vary significantly between countries, depending on the legacy operators with very different license expiry dates. Some countries plan to auction the entire band and then typically offer 100 MHz blocks (as in Sweden). Other countries only have currently available higher or lower bands, such as 200 MHz, due to legacy operator usage. This results in narrower spectrum licenses, as in the UK. A new auction will occur when the remaining spectrum becomes available. If nothing is done (such as a reallocation of one of the bands), this will result in operators holding discontinuous spectrum. Reallocation may not occur due to "carrier aggregation."

[0182] Most countries promote national concessions, except for Germany and Sweden, which have proposed reserving 100 MHz (3700 MHz to 3800 MHz) for regional service under existing plans. This block will be available in Sweden in 2023.

[0183] The EC (European Commission)'s "5G Action Plan" specifies that all countries should: • Have a 5G network in service in at least one city in each country by 2020. • Achieve full coverage by 2025. This will likely mean that most countries will focus on mid-band frequencies (3 GHz to 8 GHz), as there will be various national coverage requirements in order to achieve the EC's goals.

[0184] Also applies to the 26 GHz band (24.25 GHz to 27.5 GHz) for 5G identification. The exact definition depends largely on the results of WRC-19. In most countries, the 26.5 GHz to 27.5 GHz range is available and can now be auctioned. In some countries, auctions have already begun.

[0185] United States

[0186] In the United States, there are several frequency bands (24 / 28 / 37 / 39 GHz) targeting 5G in mmW, and recently only the Federal Communications Commission (FCC) has begun to consider mid-band spectrum (e.g., the 3.7 to 4.2 band). Operators have identified portions of existing frequency bands for NR deployment, such as T-Mobile on 600 MHz and Sprint on 2600 MHz.

[0187] Existing users do not own the upcoming FCC auction of mmW spectrum at 28 / 39 GHz.

[0188] In the mid-band, 5G will be permitted in the CBRS band (3550 MHz to 3700 MHz). Based on 10 MHz blocks, this band has licensed (PAL) and generally licensed (GAA) blocks. In the 37 GHz to 37.6 GHz band, it is proposed to define the licensing of territorial use.

[0189] Asia Pacific Region

[0190] Several major countries in the Asia-Pacific region are planning auctions during the 2018 / 2019 period.

[0191] In June 2018, South Korea auctioned 3.5 GHz (3420 GHz to 3700 MHz) and 28 GHz (26.5 GHz to 28.9 GHz) to operators.

[0192] China plans to allocate additional frequencies in the 2.6 GHz band (totaling 160 MHz) and 4.9 GHz band (100 MHz) to the CMCC during 2018. An auction for 3.5 GHz (3300 MHz to 3600 MHz) is planned for 2019, with 3300 MHz to 3400 MHz specifically designated for indoor use. Currently, the 2300 MHz band is primarily used for indoor 4G, but so far there has been no indication of permission for 5G.

[0193] Japan is planning to compete for frequency bands from 3.6 GHz to 4.1 GHz, 4.5 GHz to 4.8 GHz (200 MHz for private use), and 27 GHz to 29.5 GHz (900 MHz for private use) during 2019. It should be noted that a portion of the 3400 MHz to 3600 MHz band has already been allocated to LTE and will eventually be converted to 5G, but in Japan, frequency band allocation is legally defined and can take a long time to change.

[0194] Australia is planning to conduct a 5G auction in the 3400 MHz to 3700 MHz range at the end of 2018.

[0195] Other countries involved in the planned 5G auction process include India, Indonesia, Pakistan, Thailand, and Vietnam.

[0196] Middle East

[0197] Countries such as the UAE, Saudi Arabia, and Qatar have specific auction plans for 3.5 GHz and 26 GHz between 2019 and 2021. Other countries have also indicated upcoming auctions, but details are not yet known.

[0198] Spectrum Summary

[0199] Table 4 shows a summary of one of the 4G / 5G spectrum bands in different countries. Items that are shaded are suitable for regional services and industrial automation. Spectrum band Region / Country Area use 600 MHz (FDD) US 2300 MHz (TDD) China Currently, 4G is mainly used indoors. 5G may also be allowed in the future. 2600 MHz (TDD) US, China 3300 to 3400 MHz (TDD) China, Africa In China, indoors. Possibly assigned in connection with 5G. 3400 to 3600 MHz (TDD) CEPT, China, South Korea 3550 to 3700 MHz (TDD) US (CBRS) PAL is based on regional licenses. GAA is not qualified to provide protection against regulatory interference. It can only protect deployed systems around the coverage area. 3600 to 3800 MHz (TDD) CEPT, South Korea In Germany and Sweden, at 3.7 GHz to 3.8 GHz 3600 to 4100 MHz (TDD) Japan 3700 to 4200 US The proposed rulemaking process includes frequency notification (NPRM). 4500 to 4800 MHz (TDD) Japan For private use, 200 MHz 4900 to 5000 MHz (TDD) China Recommendations for regional service centers 5925 to 6425 MHz US Not licensed, may be shared with FS 6425 to 7125 US Can be used with FS, whether unlicensed or licensed. 24.25 to 27.5 GHz (TDD) WRC-19 related (US plans to auction FDD in the 24 GHz band) 27 to 29.5 GHz (TDD) Japan For private use, 900 MHz 27.5 to 29.5 GHz (TDD) US, South Korea 37 to 38.6 GHz (TDD) US Regional use, with a possibility of one of the 37 GHz to 37.6 GHz range; the FCC has proposed a license in accordance with the rules. 37 to 43.5 GHz (TDD) WRC-19 related 37 to 40.5 GHz 40.5 to 42.5 GHz 42.5 to 43.5 GHz 38.6 to 40 GHz (TDD) US 42 to 42.5 GHz US Part of the Federal Notice on the Proposed Rulemaking (FNPRM) 47.2 to 48.2 GHz US Part of FNPRM Table 4 – 4G / 5G spectrum bands in several different countries

[0200] Control methods for controlling access to regional spectrum.

[0201] There are two other regulatory methods for obtaining access to regional spectrum: • spectrum leasing, • regional concessions. These methods are applicable if operators agree to customer control over the spectrum, or if regulators establish regional concessions as a viable strategy.

[0202] Under the spectrum leasing method, a user / lessor leases a portion of its licensed spectrum to a lessee, with or without a fee. The lessee may lease a portion of a frequency band, a portion of the spectrum, or both to a specific geographic area. A sublease occurs when the lessee leases the spectrum to a secondary lessee. A regulatory view of spectrum leasing is shown in Figure 18.

[0203] Regulations governing spectrum leasing vary from country to country. Numerous forms of regulation are possible: • Terminology • Differences or non-differences between statutory (legal) control and actual (in principle, radio network owner) control of the spectrum • Application procedures, for example, stipulated approval times • Which bands are available for leasing, taking into account (for example) competitive impact • Lease terms, but not exceeding the term of the license • The possibility of subleasing • Zones defined for leasing • etc… Moreover, regulators may choose to disclose more or less of the leasing agreements.

[0204] The following is an overview of one of the regulatory situations regarding spectrum leasing: • The US has the most mature regulations on spectrum leasing; regulations have existed since 2003-2004. Spectrum leasing is commercially implemented. Instances of spectrum leasing, spectrum aggregators, and spectrum brokers exist. A public searchable database (ULS) containing all leasing agreements exists. • In South America, several countries allow leasing between MNOs. • In the EU, leasing of major operational / cellular bands has been permitted in regulations since 2012. This leasing is not necessarily implemented in the regulations of member states. In Sweden, Finland, the UK, Ireland, Germany, France, or Italy, there appear to be no instances of commercial leasing of frequencies owned by MNOs. • In the UK, Ofcom does not allow leasing in major cellular bands due to competition implications. • In Ireland, leasing in major cellular bands is permitted following a ComReg review of competition implications. • In Sweden, spectrum leasing is permitted. Due to its auction scheme (lack of a stable long-term plan), regulators have so far only permitted short-term leasing. Due to the uncertainty of their network plans / expansions, operators have so far not allowed long-term leases with guaranteed protection. • In Finland, spectrum leasing is permitted, but no lease has ever been resolved under MNO licenses, and therefore regulators have never implemented this practice. • In Germany, spectrum leasing was first resolved in the fall of 2018 during a consultation on one of the 3.7 to 3.8 GHz bands. Regulators define the user as both the property owner and the user (tenant). • In Italy, spectrum leasing is permitted and used commercially. • In Asia, competition generally prevents spectrum leasing in several key countries, and therefore spectrum leasing is not part of the regulations; for example, it is not permitted in China, India, and Japan, but there is growing interest in spectrum trading. Spectrum leasing is permitted but not used in South Korea. • In Africa, spectrum leasing generally appears to be prohibited. However, Nigeria recently issued guidelines for spectrum trading that include spectrum leasing. • Commercial leasing of MNO spectrum in the US involves several scenarios. • Nationwide operators lease spectrum among themselves to address markets where capacity / coverage / growth is needed. • Nationwide operators leasing spectrum to non-nationwide operators, for example, Verizon's LTE (LRA) program in rural U.S. Verizon has signed agreements with 21 rural and smaller operators under this program, and 19 of them have already launched LTE networks through it. This program allows Verizon to rapidly expand its rural presence. • The MNO interest in leasing spectrum to 5G vertical industries (for example, in a factory automation scenario) remains to be validated.

[0205] has primarily engaged in spectrum leasing from mobile operators to other operators to meet coverage and other requirements from regulators. In terms of volume, this is almost entirely in the US.

[0206] In higher frequency bands (>10 GHz), fixed service refers to a usage scenario where the service provider leases the service to the operator. This has been established in both the US and Europe.

[0207] With the arrival of 5G, vertical industries are providing usage scenarios that require dedicated (mobile) spectrum. One question is which role will become the lessee.

[0208] The long-term reaction of operators to the possibility of leasing mobile spectrum to vertical industries is unknown. For both lessees and lessors, there are opportunities and issues surrounding such lease agreements, for example: • MNOs are interested in spectrum that is not fully utilized; • MNOs may be unwilling to lease spectrum in areas with high demand or where demand is expected within 5 to 10 years; • The required lease term of 30+ years (attributable to investments in procedures and buildings) is far longer than the MNO's concession period.

[0209] The introduction of 5G will lead to a significant change in operators' ability to provide SLAs through network slicing. While network slicing is supported to varying degrees by all 3GPP-based networks, 5G CN will provide operators with a framework that allows programmatic network slicing to influence usage scenarios, QoS categories, and separation between service providers. This will then likely result in deployment scenarios where slicing can achieve network capacity leasing. This will allow regional users to control end-to-end SLAs and even keep RAN behavior (including QoS, for example) within limits. The MNO will deploy the RAN according to the leased SLAs and integrate the RAN with the CN without losing overall control over planning and management.

[0210] Spectrum bands eligible for lease must meet specific requirements. In certain countries / regions, spectrum leasing must be permitted by law. The following table is generated by removing China, Africa, and Japan from Table 4 above: Spectrum band Region / Country Notes 600 MHz (FDD) US 2600 MHz (TDD) US 3400 to 3600 MHz (TDD) CEPT, except for the UK South Korea (unknown). 3550 to 3700 MHz (TDD) US (CBRS) 3600 to 3800 MHz (TDD) CEPT, except for the UK South Korea (unknown). 24.25 to 27.5 GHz (TDD) WRC-19 related (US plans to auction FDD in the 24 GHz band) 27.5 to 29.5 GHz (TDD) US South Korea (unknown). 37 to 38.6 GHz (TDD) US 38.6 to 40 GHz (TDD) US 42 to 42.5 GHz US Table 5 – 4G / 5G spectrum bands available for leasing

[0211] Regional Franchise

[0212] Most concessions use predefined administrative boundaries to define a concession area, such as: • National borders • Regional boundaries or other larger administrative structures • Communities / cities

[0213] The next level of granularity can be property. Using this method, property and land use rights can be used as management definitions for regional concessions. If a larger regional spectrum concession requires regional spectrum, one solution to increase granularity would be the lease of sub-regions. If necessary, this solution can define a region larger than property.

[0214] Currently, when a regulator defines a concession area smaller than a district / city, the definition has always consisted of a landmark and a radius, an event name, an address, the coordinates of the defined area, etc. This has become a problem because the number of such concessions has always been low. However, with the advent of 5G deployments, this will change. For regulators, this is an ongoing process.

[0215] If the number of regional concessions increases with the use of 5G, coordination also needs to increase: • A geographic database is needed to display the concession areas, for example, for new applicants. • Interference between implementation plans needs to be coordinated through regulatory requirements.

[0216] While national and regional licenses exist for commercial services, regional licenses exist for non-commercial purposes, such as testing labs and testing facilities. Certain program production and special events (PMSE) service licenses may be considered regional. 5G, with the advent of new types of use cases, will require regional licenses for facilities, for example, and will impose new regulatory requirements.

[0217] The main frequency bands for 5G services in Europe are 3.4 GHz to 3.8 GHz, and auctions of these bands have triggered regulatory activities regarding regional concessions. Higher frequency bands (for example, 24.25 GHz to 27.5 GHz (pioneer bands for early implementations in Europe)) are suitable for regional use in terms of their propagation characteristics, particularly in indoor use, where they are less likely to cause coexistence problems. Currently, regulatory discourse regarding regional concessions for these bands is largely overreaching or barely within the realm of possibility, but this situation is expected to change with industry interest.

[0218] Certain indoor environments are suitable for reusing spectrum across multiple uses, especially in situations where network routing is floor-to-ceiling in modern buildings. It is well known that even at mid-band frequencies such as 3.5 GHz, the loss across multiple floors of a building can be tens of dB.

[0219] Chinese industry has shown interest in regional licenses in the standards forum, thus indicating Germany’s proposal for 3.7 GHz to 3.8 GHz.

[0220] One example of a concession assigned to an industry is the allocation of 1800 MHz to 1830 MHz to the Canadian hydroelectric industry since the 1990s.

[0221] Europe: 3.7 GHz to 3.8 GHz (part of 3.4 GHz to 3.8 GHz, the main frequency band for 5G services)

[0222] Several countries have already auctioned spectrum, and more are following suit. Two countries have held negotiations involving regional concessions and are following up on each other's plans. • Germany issued auction rules in the third quarter of 2018, with auctions scheduled for the first and second quarters of 2019. These rules distinguish between indoor and outdoor uses of "uses related to regional property," implying that property is a definition of a region. It should be noted that there are properties that are not privately owned, such as streets, parks, etc. • Sweden's latest auction was in the first quarter of 2020. Recent negotiations defined "regional block allocation." A region is defined here as a "small geographical area," such as mines, indoor facilities, and hotspots. It should be noted that regional concessions, which typically correspond to municipalities, are also mentioned in the negotiations.

[0223] USA: 3.4 GHz to 3.55 GHz (potentially extended to CBRS)

[0224] In the US, the National Telecommunications and Information Administration (NTIA) is evaluating spectrum sharing between military radar and operational broadband in this band. Traditional carrier systems differ here compared to existing CBRS coverage. If CBRS rules apply, licensed operations will be inter-county, and general authorized access will include Tier 3. The large area size within the CBRS band makes it unsuitable for industrial use because vertical industries are unlikely to participate in the auction market.

[0225] Frequency band used for regional concessions

[0226] Specific requirements must be met for any frequency bands eligible for regional concessions. Regulators must permit regional concessions.

[0227] The new regional plan in Table 4 above will generate the following table: Spectrum band Region / Country Notes 3300 to 3400 MHz (TDD) China In China, indoors. Possibly assigned in connection with 5G. 3550 to 3700 MHz (TDD) US (CBRS) PAL is based on regional licenses. GAA is not qualified to provide protection against regulatory interference. It can only protect deployed systems around the coverage area. 3600 to 3800 MHz (TDD) In Germany and Sweden, at 3.7 GHz to 3.8 GHz Indoor and outdoor 4500 to 4800 MHz (TDD) Japan For private use, 200 MHz 27 to 29.5 GHz (TDD) Japan For private use, 900 MHz 37 to 38.6 GHz (TDD) 37 GHz to 37.6 GHz is one of the possibilities in the US. The FCC has instead recommended a license as suggested by the rules and shared it with federal use. Table 6 – 4G / 5G spectrum for regional licensing

[0228] Technical support for leasing and territorial licensing

[0229] In Europe, eLSA is a continuation of the ETSI-mandated system-granted shared access to spectrum in IMT bands, where traditional operators cannot be withdrawn within a reasonably foreseeable timeframe. Access can be managed by time and geographic region. The system creates geographic protection and restricted areas that traditional operators do not allow others to use. In eLSA, permitted zones are introduced to also achieve regional user disposal, which automates the process of granting and managing numerous regional access concessions. It will also include frequency leasing to regional users under concessions established under conditions such as MNOs. Figure 19 illustrates the hypothetical spectrum allocation possibilities for a band allocated to mobile services such as IMT.

[0230] Specification work on the eLSA system has commenced at ETSI (Europe) and is based on the ETSI technical report "Feasibility Study on Temporary Spectrum Access for Regional High-Quality Wireless Networks". Technical specifications regarding system requirements are assumed to be ready by the end of 2018, followed by specifications on architecture and procedural flows, and then an agreement specification. In the Asia-Pacific region, information related to "regional" services has been shared, and the commencement of work on a technical report has been approved.

[0231] The eLSA system is based on a database / controller concept. It supports licensed and leased operations by means of, for example, access granted by blank spaces or access granted by rules, rather than unlicensed / unlicensed operations, thus eliminating the need for necessary interference protection requirements.

[0232] The database is named the eLSA repository and is assumed to be within a regulatory domain. The controller is named the eLSA controller and ensures that the systems of eLSA users will have the necessary configuration to operate according to the permit conditions, thereby easily supporting high-quality requirements for URLLC use cases. The controller will obtain the necessary control sharing and coexistence requirements from the eLSA repository.

[0233] Figure 20 shows a possible architectural sketch of one of the regional concessions, while Figure 21 shows a possible architecture of leasing. In the latter case, the eLSA controller box also contains some eLSA library functions, because the MNO is the leased frequency MNO.

[0234] In the United States, the Federal Communications Commission (FCC) has defined Citizen Broadband Radio Service (CBRS) in the 3550 to 3700 MHz frequency band in the regulations compiled in the FCC Rules. Figure 22 illustrates the form of CBRS.

[0235] The Navy Radar and Fixed Satellite System (FSS) service (the two services constituting Tier 1 Traditional Operator Main Service) is using the CBRS band. It also protects grandfather-level wireless broadband service users (such as Wireless Internet Service Providers (WISPs)) operating under 47 CFR Part 90, Subpart Z from interference from CBRS until April 2020. The two remaining tiers respectively allow the issuance of Priority Access Licenses (PAL) and General Licensed Access (GAA) within the band for wireless broadband use. PAL users benefit from the licensed spectrum based on the granted area and bandwidth. GAA users are allowed to access any spectrum not utilized by higher tiers based on Licensed Access.

[0236] Radio devices are registered as Citizen Broadband Radio Service (CBSD) devices based on their location and operating parameters. Any qualified radio device may request access to Priority Access License (PAL) and GAA spectrum. Since the FCC does not provide any regulatory protection for GAA spectrum users, industry protocols create solutions for GAA coexistence. While the Wireless Innovation Forum (WInnForum) specifies technology-agnostic protocols primarily focused on regulatory compliance, the CBRS Alliance seeks to improve the performance of LTE networks operating within CBRS.

[0237] The CBRS Alliance is licensed as an industrial trade organization that aims to promote and improve LTE operation in various bands for various use cases, including small cell networks deployed by operators in connection with public services, last-mile replacement of fixed wireless services, and industrial wireless. The Alliance specifies network architecture changes to allow for both traditional operator-deployed operations and private network operations (including neutral hosts), and has provided a platform to establish contributions within 3GPP for defining bands 48 and 49 for LTE-TDD and LTE-eLAA operations in these bands. The CBRS Alliance will also introduce 5G NR into these bands in 2019. Focusing 5G on industrial wireless applications aligns with the CBRS Alliance's mission.

[0238] The Spectrum Access System (SAS), a geolocation database, and a policy manager authorize the CBSD to access the CBRS spectrum. According to FCC regulations, the SAS primarily protects higher-level users from lower-level operations. The logical relationships within the CBRS are illustrated by the SAS-CBSD and SAS-SAS interfaces, as shown in Figure 23. Figure 23 illustrates the high-level SAS architecture, including the GAA spectrum coexistence manager (CxM) function. The Federal Radar System is protected by implementing a sensor network that forms an Environmental Sensing Component (ESC) that notifies the SAS of coastal radar activity. Regional privileges are granted to PAL users within a 10 MHz block over a large geographic area.

[0239] Each PAL is 10 MHz and limited to the maximum of one of seven licenses confined to the CBRS band within 100 MHz (i.e., 3550 MHz to 3650 MHz). The new rules have made the license zones county-based, with 3142 counties in the United States. There are seven PALs in each license zone, with a license term of ten years with a renewal guarantee, and the licenses can be subdivided and split. The maximum for a single operator is the maximum of one of four PAL licenses. The ability to lease spectrum and split licenses under geographical constraints will support a secondary market for spectrum use by industry. In this way, PAL licenses may support URLLC without significant overhead.

[0240] WinnForum defines the technology neutrality mechanism and PAL used to manage frequency bands (including traditional operator protection). This creates additional requirements for coexistence among GAA users, with much of the debate revolving around whether coexistence should be engineered by the central authority of the SAS or by the regional actions of the CBSD (caused by an understanding of the radio environment).

[0241] Figure 24 is a diagrammatic illustration of PAL spectrum management. PAL users are protected only within a coverage area outlined around the actual deployment of one or more CBSDs. These coverage areas are called PAL Protection Areas (PPAs) and are defined by a signal level of -96 dBm from the transmission station. A PAL Protection Area (PPA) represents a cluster of CBSDs with overlapping coverage areas, which can be merged to show a polygonal area eligible for interference protection by other unrelated uses of PAL or GAA. The figure shows several concession areas, each corresponding to a county. PAL users spanning multiple concession areas (i.e., having concessions in more than one area) can combine their concessions to form a common channel assignment.

[0242] GAA users can use PAL spectrum, provided that the actual PAL deployment within the PPA is protected from total interference exceeding -80 dBm within the PPA. This is illustrated in the diagram for PPA C, where two GAA CBSDs are allowed to operate on the same channels as the PAL user, provided that the total interference from their transmissions does not exceed -80 dBm across most PPA boundaries. Overlapping or sufficiently close PPAs from different operators will obviously use exclusive spectrum allocation. Therefore, if the band is not obstructed by higher tiers, GAA users are guaranteed access to all 150 MHz of spectrum.

[0243] While not protecting GAA users from mutual interference or interference from higher layers, the WInnForum and CBRS Alliance have been involved in exploring methods to create a higher quality experience for GAA users. The CBRS Alliance process reallocates spectrum assigned by the SAS to the CBRS Alliance coexistence group, creates regional interference profiles based on environmental modeling, and optimizes spectrum allocation for one of the coexistence managers (CxMs) of the proposed CBSD network. Additionally, the CxM manages uplink-downlink coordination for TDD signals. It is anticipated that all LTE-TDD networks will be fully phase-synchronized by cell, and the CBRS Alliance coexistence specification details how this will be achieved independently of the SAS or CxM. The WInnForum and CBRS Alliance will attempt to guarantee at least 10 MHz of spectrum per CBSD. In congested areas, this may not consider eMBB service.

[0244] Both PAL and GAA spectrum can address URLLC requirements, but cannot guarantee URLLC quality in all GAA scenarios. As a result, an operator will not be able to meet the SLA that promises a customer that the capacity or potential performance will not degrade, unless the covered facilities are physically isolated from other interfering parties.

[0245] CBRS has several drawbacks: • The three-tiered nature of the concession system and, in particular, the rules that allow for GAA, introduce considerable uncertainty regarding the utility of the spectrum. Some of this uncertainty stems from a lack of understanding that GAA spectrum is the same as or similar to ungranted spectrum: it is not. In fact, a strict interpretation of one of the FCC rules surrounding the use of GAA can lead to the mistaken belief that it is similar to a blank. • The WINNF specification has created the impression among some operators that it can ensure interference protection by using GAA spectrum alone. This impression may require spectrum allocation among users to the extent that compromises bandwidth quality. This is not suitable for eMBB use. • The coexistence of the WINNF and CBRS alliance specifications tends to reduce the value of outdoor deployments. High-power base stations are factored into traditional operator protection to a greater extent than low-power base stations. Indoor deployments can be advantageous in spectrum allocation, and large indoor node networks can obtain more spectrum than their fair share unless SAS introduces fairness measures. A pragmatic approach based on commercial guarantees is expected. • An interesting use case for CBRS is coverage and offloading in small and micro-cells in urban areas. This is primarily due to large concession areas, where operators are more likely to bid for concessions in lucrative markets. For industrial automation use of CBRS, operators must obtain concessions if they intend to break down or lease their spectrum. • CBRS has been defined in one of the key focus bands for 5G. The terms underlying spectrum allocation (especially PAL) make the band problematic for eMBB services and have mixed utility for industrial purposes (including URLLC operating modes).

[0246] On the other hand, there are some positive aspects to CBRS: • The use-and-use approach of CBRS is a well-thought-out exercise in improving spectrum utility. The rules incentivize operators to use their licenses in practical deployments, and operators are motivated to deploy their own radios or lease out PPAs to realize revenues beyond their spectrum. • Success of the band is guaranteed if the majority of users in CBRS are small, indoor users. Many industrial use cases meet this requirement. • The FCC cannot bias the auction process in favor of industrial and corporate spectrum use. Furthermore, industrial users are not genuinely interested in a competitive licensing market. In fact, Ericsson's regional licensing concept, which relies on licenses being assigned to property owners according to the rules, may require a small registration fee. By allowing the splitting of licenses, the FCC has given industrial users options (leasing, purchasing, or operating under GAA rules). • CBRS should be commercially deployed and proven in the field. The establishment of industry organizations that form standards (including those used in LTE within the band) ensures, in some way, the practical deployment and success of the band. The same applies to LSAs in 2.3 GHz. In fact, CBRS is a significant concern among other regulators (e.g., Ofcom). The experience of deploying CBRS can encourage the telecommunications industry to accept CBRS as a tolerable way of implementing spectrum sharing.

[0247] Coexistence

[0248] Generally, coexistence issues arise when industrial networks using cellular or RLAN technologies share spectrum with other services (e.g., satellite). If there is sufficient geographical isolation or path loss between these services, industry may gain access to spectrum designated globally for radio navigation, satellite services, or fixed services. For example, indoor factory use of spectrum can easily occur in satellite bands. Ideally, these bands are close to those allocated for RLAN or IMT, incentivizing manufacturers to include them in their wireless equipment. The CBRS band is one such band closely associated with bands already designated for mobile use in most markets worldwide.

[0249] Another aspect of the industrial use of spectrum is the issue of spectrum utility. While cellular technology has the advantage of high spectrum efficiency, it is also necessary to regulate the extent to which spectrum can be reused. In many cases, this will involve understanding the extent to which spectrum can be reused in closely adjacent concession areas.

[0250] There are situations where coexistence is not actually a problem. Indoor spectrum used in industrial applications can benefit from other (e.g., satellite, FS, FFS, radar (not just indoor)) unavailable spectrum (excluding mobile allocation). However, outdoor spectrum used in industrial applications must also be considered.

[0251] While indoor industrial use may indeed benefit from secondary use of spectrum that can be designated for other services (e.g., satellite, FS, FSS, radar, etc.), it is equally important for industry to designate area spectrum for outdoor use.

[0252] Shared Spectrum – Market Considerations

[0253] The underlying philosophies behind shared spectrum regulations differ between the USA and Europe. The FCC is willing to define CBRS in a way that highly values ​​spectrum utility, while the EU has shifted its focus towards spectrum quality and stability.

[0254] In Europe, support for industrial IoT is focused on licensed frequency bands because a specific standard can contain interference standards from others. Numerous licenses and leases are expected to exist within a single country.

[0255] An evolved LSA system in ETSI is designed to handle deployment and coexistence issues efficiently. Depending on the country, coexistence scenarios with the possibility of co-channeling can be area-to-area indoor, area-to-area indoor and overlapping coverage areas, and area-to-area indoor to area-to-area outdoor. The regulated co-operation conditions required to handle this situation include, for example, frequency domain (and possible reuse mode requirements), guard distance (if required), wall loss assumptions, and a maximum permissible signal strength level that ensures predictability of interference to neighbors by setting a boundary. This will facilitate the deployment of networks with known expected interference levels to ensure the required network quality level.

[0256] Unlicensed and licensed exempted frequency bands with unpredictable interference behavior can be used for services that do not require high QoS and can be used simultaneously with licensed networks.

[0257] In the US, spectrum leasing and private use are most likely to occur within the CBRS. PAL regulations are geared towards protecting actual deployments. If an established PPA is interference-free, an area outside a user's radio coverage within a license definition is available to GAA users. However, users are free to monetize their licenses by allowing private PPA leasing. This may improve the utility of the spectrum.

[0258] GAA uses a mixed experience quality that is open to private deployment systems and will depend on various factors: urbanization, population density, business interests, indoor and outdoor deployment, and outdoor deployment in small and large communities (low power and high power).

[0259] The WinnForum and the CBRS Consortium participated in defining the coexistence principle of GAAs, which reduces the interference impact of co-channel use from allocated spectrum on GAA users. The formation of the coexistence procedure is controversial and generally involves orthogonalizing spectrum allocation between adjacent CBSDs that are considered to interfere with each other. This has the disadvantage of reducing individual spectrum allocation to CBSDs in some cases. This is particularly concerning for NR use in the band, especially where eMBB coverage is expected.

[0260] Unlicensed spectrum

[0261] Industrial applications of wireless technology can overlap with cellular or Radio Local Area Network (RLAN) technologies. In practice, it is unnecessary to categorize all industrial uses of spectrum as highly reliable or communication-critical derivatives. The specific characteristics of industrial automation environments are highly important for spectrum availability, ease of deployment, low regulation, and the opportunity to form trusted and secure networks. However, many, and perhaps most, industrial use cases can also utilize license-free spectrum. The development of Multefire and LAA as license-free operating technologies provides cellular industries with one pathway to the RLAN domain.

[0262] Key disadvantages of unlicensed spectrum include the necessity of operating in the presence of interference and the low reliability resulting from distributed intelligence due to the use of shared spectrum. This typically means that radio nodes use collision avoidance and listen-before-speak etiquette to access channels immediately. This does not apply to KPI assurance. Therefore, unlicensed spectrum is generally unsuitable for mission-critical applications.

[0263] Unlicensed spectrum bands for industrial applications span various spectrum bands. The US FCC has been the most proactive in expanding the availability of unlicensed spectrum in recent years.

[0264] Table 7 lists the unlicensed frequency bands for each country, where underlined text indicates the frequency bands under consideration. The frequency bands listed in the table are for broadband use and do not include several frequency bands designated as short-range device communication bands. Unlicensed frequency bands are generally unsuitable for URLLC due to the possibility of interference. Spectrum band Region / Country Notes 600 MHz USA The TVWS rules permit unlicensed blank devices to operate in the guard band between the radio service and the TV band, and in the duplex gap between the radio downlink and uplink bands. This includes unlicensed operation on UHF channel 37, which is also hosted by the Radio Astronomy Service (RAS). 902 to 928 MHz USA Some 15-frequency hopping or digital modulation 863 to 870 MHz Europe The short-range frequency band of the wireless microphone, LPWAN uses Viqa SigFox. 2400 to 2,483.5 MHz worldwide ISM band, part of Rule 15. 5.150 to 5.250 GHz USA, Europe, Japan US: U-NII-1 band, indoor use only, integrated antenna European RLAN band 1 5.250 to 5.350 GHz USA, Europe, Japan US: U-NII 2A, for indoor and outdoor use Europe: RLAN band 1 requires TPC 5.350 to 5.470 GHz Europe Europe: Available for RLAN use 5.470 to 5.725 GHz USA, the whole world U-NII 2C / 2E, DFS and radar detection, indoor and outdoor. Europe: RLAN Band 2 5.725 to 5.850 GHz USA, the whole world The U-NII 3 band overlaps with the ISM bands worldwide. 5.725 to 5.875 Europe BRAN 5.925 to 6.425 GHz USA The proposed U-NII 5 band and the required AFC (database) 6.425 to 6.525 GHz USA The proposed U-NII 6 is for indoor use only. 6.525 to 6.875 GHz USA The proposed U-NII 7 requires AFC 6.875 to 7.125 GHz USA The proposed U-NII 8 is for indoor use only. 57 to 64 GHz USA, Canada, South Korea Unlicensed mmW 59 to 66 GHz Japan Unlicensed mmW 59.4 to 62.9 Australia Unlicensed mmW 57 to 66 GHz Europe Unlicensed mmW 66 to 71 GHz USA Proposal made in response to the FCC's lack of authorization Table 7 – Unlicensed Frequency Bands

[0265] Spectrum leasing in Europe and the US is not a regulatory issue, but the interest and business of operators remain to be seen. In Asia and Africa, discussions on spectrum leasing have begun.

[0266] Indoor spectrum used in industrial applications can benefit from other unavailable spectrum (excluding mobile allocation) such as satellite, FS, FFS, and radar (not just indoors). However, outdoor spectrum used in industrial applications must also be considered.

[0267] While indoor industrial use may indeed benefit from secondary use of spectrum that can be designated for other services (e.g., satellite, FS, FSS, radar, etc.), it is equally important for industry to designate area spectrum for outdoor use.

[0268] eLSA is independent of the bands and technologies used for spectrum leasing and regional licensing. CBRS will represent the best opportunity for industrial use of spectrum in the United States. CBRS is defined within a spectrum range accessible globally by IMT, enabling economies of scale and allowing for leasing and decommissioning of licenses. Allowing decommissioning does not imply that CBRS will achieve regional licensing.

[0269] Global harmonization of IMT and MBB spectrum has been an expectation that has never been fully realized. The effects of differing regulatory actions on mobile service spectrum over the years have made it difficult to achieve harmonization for industrial use. However, the telecommunications industry is interested in allocating portions of the spectrum range from 3400 MHz to 4200 MHz and from 24.25 MHz to 29.5 GHz for industrial use.

[0270] Outside of China and the US, where 5G rollout will begin, the 3400 MHz to 4200 MHz frequency range is likely to be the primary frequency range. Limited regulatory support for regional concessions within this range will create delays in non-MNO-dependent spectrum use. For example, in Sweden, regional concessions for 5G use may be available as early as 2023, and in most other European countries, regulatory action is not yet under consideration. Therefore, during that period, leasing may be the only option for spectrum access, except for services provided by an MNO. mmW spectrum could be of interest to achieve regional concession availability in a more timely manner, but this will depend to some extent on the allocation of operational bands in WRC-19.

[0271] Safety

[0272] It is often said that the security of a system is only as strong as its weakest link. However, depending on which part of the system, breaching (or neglecting) it can have very different consequences. When discussing a system involving more than one entity, the secure identities used and their handling and protection are building blocks upon which a large portion of other security functions depend. These identities are used to authenticate entities, grant access and authorize actions, and establish secure working phases between entities. This means that a device needs to have a secure identity and provide protection and isolation of the device's identity and authentication through hardware (HW) and software (SW) mechanisms. Not only is identity protection necessary, but the device itself should also be secured, for example, through proper control over what SWs run on the device. All of the above is achieved by having an HW root of trust (RoT) in the device (essentially, a trust anchor that forms the basis of security).

[0273] Identity

[0274] A device's identity is used to identify the device to a communication party. This identity typically consists of an identifier and several authentication methods (such as a key, key pair, or password used for device authentication). Once the identity is authenticated, the communication party (such as a network, service, or peer device) can make sound security policy decisions regarding network / resource access control, service usage, billing, service quality settings, etc.

[0275] Identity based on a shared secret depends on the fact that all communication endpoints and only those endpoints know a secret value. The randomness of this shared secret is a key characteristic. It is usually quite weak for a username-password pair (the most basic form of identity based on a shared secret). In addition to randomness, the length of the secret and the secure handling of the secret (both at the device and server sides) are important.

[0276] In the case of asymmetric keys, an entity's identifier is an asymmetric key paired with its public key and a corresponding private key, which serves as authentication. A signature generated using the private key can be verified by anyone with access to the corresponding public key. This may be the main advantage of asymmetric keys compared to symmetric (shared secret) keys.

[0277] To add additional value to identities based on asymmetric keys, it is possible to obtain an identity certified by a Certificate Authority (CA). The CA verifies the identity of the entity possessing the key pair and issues a credential proving the link between the owner and the public key. Disadvantages of credentials include the size of the credential (or credential chain) (which can be an issue in a constrained environment) and the added costs of obtaining and maintaining (updating) the credential. To reduce costs, an enterprise may also set up its own CA.

[0278] The Original Public Key (RPK) mechanism strikes a trade-off between the simplicity of pre-shared keys and the benefits of asymmetric cryptographic solutions. An RPK is a simplified credential significantly smaller than a typical credential, containing only a public key in a specific format. An RPK is similar to a self-signed credential in that there is no guarantee of a trusted entity providing the identity; that is, peers receiving this identity need to use an out-of-band mechanism to trust that it is the entity they wish to communicate with.

[0279] For all Public Key Infrastructure (PKI), it is recommended to have a method to revoke a compromised key. This can be achieved by retrieving a Credential Revocation List (CRL) from a Credential Authority (CA) or by checking the credential status online using the Online Credential Status Protocol (OCSP).

[0280] 3GPP cellular systems are a primary example of where shared secret-based identities are used. A 3GPP identity consists of an IMSI, a 15-digit identifier and its associated authentication, and a 128-bit shared secret. This information is stored in a user database (e.g., HLR or HSS) in the 3GPP core network and on a UICC or SIM card installed in the user equipment (UE). The UICC serves as both a secure storage area for 3GPP authentication and a TEE for 3GPP authentication. For IoT devices, a permanently integrated embedded UICC (eUICC) can be used as an alternative. The eUICC has a smaller footprint and allows for remote updates of subscription data.

[0281] For 5G, 3GPP also considers alternatives to traditional SIM authentication, namely, the so-called "alternative authentication." TR 33.899 focuses on different identity solutions, including credentials. In the specifications, for example, support for credentials is described in 33.501, where EAP-TLS is defined as an alternative to AKA. EAP-TLS implies that credentials are used for authentication. To identify the network, the use of credentials can be partially obtained through the definition of the Hidden Identifier (SUCI) (which is the UE's Private Identifier (SUPI) encrypted with its home network's public key), that is, the network already has an asymmetric key pair, where the public key is part of the user profile. SUPI is defined in 3GPP TS 23.501; there, the Network Address Identifier (NAI) is given as a possible format for the identifier, which will also support the use of credentials.

[0282] End-to-End (E2E) Security

[0283] In most cases, protecting a device's communications is crucial. This involves preventing information from being leaked to an unauthorized third party and preventing third parties from modifying data along the path. This can be achieved by applying confidentiality (encryption) and integrity (data signing) protection. The exact security requirements of the data are highly dependent on the usage scenario and relate to the data, its use, sensitivity, value, and the associated risk of misuse. However, as a rule of thumb, integrity protection should always be applied, while the need for confidentiality protection should be assessed on a case-by-case basis. Generally, a single key should be used for only one purpose (encryption, authentication, etc.).

[0284] To protect data, numerous standardized protocols exist, including "conventional" internet security solutions such as TLS, IPsec, and SSH. IoT-optimized solutions include DTLS as a variant of TLS for IoT and ongoing work to outline an IoT-friendly IPsec. Furthermore, application-layer security solutions (such as OSCORE as defined in the IETF) are available and particularly useful for constrained devices. The advantages compared to TLS include: end-to-end security can be provided even through transport layer proxies, such as those used for store-and-forward type communications with hibernation devices. It also optimizes for the additional burdens of protocols.

[0285] 3GPP also provides tools for protecting end-to-end traffic of a service, even outside the 3GPP network. The Generic Boot Loading Architecture (GBA) (3GPP TS 33.220) uses SIM authentication to authenticate the UE / subscription to a network service, referred to as a Network Application Function (NAF) in GBA terminology. GBA requires a trust relationship between the service / NAF and the operator. Using this trust, the NAF can request a working phase key from the network, which is based on the UE's SIM authentication. This working phase authentication can be used for authentication between the UE and the service and for establishing a secure working phase.

[0286] Hardware Trust Root

[0287] The concept of a Hardware Root of Trust (HW RoT) includes the following features: • Secure storage • Secure / measurable boot • HW-enhanced Trusted Execution Environment (TEE) • HW-protected cryptography and key management (cryptographic acceleration, HW-based random number generator, secure generation / storage / access to keys)

[0288] HW security also extends to the environment of its manufacturing equipment, such as the protection of interfaces and mechanisms used during manufacturing and development, the use of security keys, key generation, security device configuration, code signing, etc.

[0289] The basis for guaranteeing that a device performs as expected will ensure that only authorized firmware / software runs on the device. This requirement originates from a secure boot mechanism of a hardware root of trust. This secure boot mechanism verifies that all loaded software is authorized to run during device startup. A hardware root of trust is an inherently trusted entity, meaning that its data, code, and execution cannot be altered outside its trust boundary. It consists of functions that must operate as intended (according to its design), regardless of what software is running on the device.

[0290] A device must also have a secure storage mechanism to protect sensitive device data, such as password keys, when stored in (on-chip) non-volatile memory. This mechanism also relies on an HW RoT, for example, an on-chip individual key stored in on-chip non-volatile memory or OTP memory.

[0291] In order to recover from malware infection and to minimize the risk of loss of sensitive data or altered behavior of the device, security-related parts of firmware and software should be separated from other software (and run in isolation). This is achieved using a Trusted Execution Environment (TEE) (formed using HW isolation mechanisms).

[0292] Equipment hardening

[0293] A device typically contains interfaces and mechanisms for debugging and hardware analysis, the aim of which is to identify problems in a given device discovered during ASIC production, device manufacturing, or in the field. The Joint Test Behavior Group (JTAG), IEEE Standard 1149.1, is a common interface used for debugging and various hardware analyses. These mechanisms and interfaces must be protected to prevent unauthorized access to retrieve or modify firmware / software / security features and / or device data. This can be achieved by permanently disabling the interface, allowing only authorized entities to use the interface, or restricting what can be accessed through the interface. Furthermore, for authorized access, it must be ensured that sensitive information belonging to the device owner / user (such as keys) cannot be accessed by those performing debugging / error analysis.

[0294] SW safety is one of the most important building blocks of device safety. HW safety and SW safety are complementary. While it is impossible to build a safety device without HW safety as a foundation, the same applies to SW safety.

[0295] While IoT gateways with application processors typically run Linux-based OSes, MCU-based IoT devices primarily run lightweight OSes such as mbed OS and Zephyr OS. Other highly secure, proven OSes also exist for devices requiring high availability and security. Choosing the right OS is crucial, as is hardening its security. Hardening entropy, user space components, and network functionality can also be considered part of the OS security hardening process. Other aspects to consider related to device hardening include: • Using security services (SWs) developed according to best security software development practices. • Sandboxing and isolation – running SWs in a sandboxed environment. • The concept of least privilege – programs only acquire the privileges they need. • Password hardening – using secure cryptographic libraries with traceable and reviewed code. • Use of cryptographic security PRNGs. • Authentication (where applicable). • Secure SW updates – signed updates applied in a timely manner.

[0296] Safety of Security

[0297] However, such security mechanisms / tools (excluding non-repudiation) should be implemented in any security system, regardless of whether the goal is to form a security system. Security requirements may be more of an indication of the required level of security and require review of security configurations, as any error can have greater consequences than in a system without security requirements. Security configuration also concerns the selection of the correct level of security / algorithm / key used in the system. In addition to security, at least one equally relevant aspect of security is (for example) the availability / reliability of the system, or the correct operation of components (the accuracy of reported values, time synchronization, etc.), relating to both the communication channels and services that constitute the system.

[0298] Interference

[0299] Like security, interference is also a topic that holds a place in the security field. Interference is a form of denial-of-service (DoS) attack. Some DoS countermeasures are also applicable to interference, such as load balancing and rerouting of traffic (which in the air interface would mean load balancing and rate limiting), backup base stations, and additional frequencies.

[0300] Industrial Equipment

[0301] Industrial devices range from small, simple monocular sensors to large, complex assemblies of devices, such as robotic units and paper machines. Therefore, a very relevant question we address here is: what constitutes a device? IoT devices are generally classified in two main ways: sensing devices and actuating devices. Sensing devices are equipped with sensors that measure a specific state (such as temperature, brightness level, humidity, on / off state, etc.). Actuating devices are those that receive a command and thus change their state; for example, a light bulb that can turn on or off or adjust the fan speed. More complex devices have a group of sensors and actuators combined, but still having only one communication interface. Even more complex machines may consist of several smaller devices (composed of several sensors and actuators). Typically, even for a small device, a microcontroller or minicomputer is in place to host the communication stack, processing power, memory, etc. In essence, a very complex device is actually a small network composed of several parts that may or may not interact with each other and may or may not communicate through the same communication module.

[0302] The scope of requirements imposed on communication itself varies depending on the purpose and critical state of the task for which the device in question is intended. These requirements may include throughput, latency, reliability, battery life, and extended coverage. For example, one might see a simple sensor reporting temperature changes with relaxed communication requirements, while wirelessly controlling a robot from the cloud requires a URLLC service. The network needs to be able to support a mix of devices and services in the same deployment. Suppose the device in question is actually a complex entity with different sets of sensors and actuators communicating through the same interface, the network may also need to support a mix of services, i.e., different types of traffic from the same device. For example, this could be a robot with a video camera and manipulator for surveillance purposes (mobile broadband traffic streaming) and a manipulator (URLLC traffic) or a port straddle crane with remote control capabilities.

[0303] To enter the vertical industrial market, it is necessary to address the different use cases described above and answer several key research questions regarding the device. How to combine devices with different URLLC requirements, how to combine different URLLC streams within a single device, and how to combine non-URLLC streams with URLLC streams within a single device? How to monitor QoS metrics within the device and send this information to the BS or network controller in a timely manner? How to ensure redundancy within the device (UE, carrier, etc.)?

[0304] Finally, the device is not an isolated part of the network, especially when it has high processing power. Rather, the device is part of the system and can host system functions, such as part of the edge cloud or the application of consortium machine learning algorithms, which can be beneficial from both a self-computing and privacy perspective.

[0305] Distributed Cloud

[0306] The following discussion introduces the concept of a distributed cloud, specifically designed to meet the requirements of industrial scenarios (industrial cloud). Furthermore, it describes an information management system capable of collecting, storing, and managing large amounts of data from manufacturing sites. Access to the stored information is handled through a well-defined API, allowing developers to focus entirely on how to process the data rather than trying to figure out how to obtain the specific data of interest.

[0307] Traditional (IT) centralized computing in the cloud offers numerous advantages over regional hosting. Technical advantages include ubiquitous on-demand access to computing resources (CPU, storage, network, applications, services), elasticity (scaling up and down resources), and metering (monitoring actual usage and paying for actual usage). Service provider resources are aggregated to serve multiple consumers simultaneously. By utilizing remote hardware deployed, managed, and maintained by a single service provider, much of the work can be offloaded from regional IT. For individual consumers, all these characteristics translate into a lower total cost.

[0308] A centralized cloud model has many advantages, but it does not address all industrial requirements. Two main issues need to be considered. First, long-distance communication adds to the overall latency. For (hard) real-time programs with strict timing constraints, round-trip latency to the cloud can negatively impact performance or even make certain use cases impossible. Latency time base errors can also be a significant problem, as communication to and from the cloud may involve numerous external links to the small control system on top of it. Second, computational tasks related to industrial production tend to place very stringent demands on availability, robustness, and security. Even if cloud-native applications and services can and should be designed and configured in a redundant and fail-safe manner, communication is not easily guaranteed. For example, fiber optic cables can be disconnected due to construction work, routing tables can be corrupted, and power outages can occur. Any interruption of network connectivity, for whatever reason, can be catastrophic for production. Specifically, anything that relies on a closed-loop control algorithm executed in a central cloud must be handled with extreme care regarding communication losses. Whether that means replicating on a site for control algorithms, a graceful degradation, or other things depends on the situation.

[0309] To mitigate the problems described above while retaining the benefits of cloud computing, a distributed approach is proposed. The principle is illustrated in Figure 25. Essentially, a central cloud (also known as a data center) is physically connected to several other computing entities at different locations. These peripheral entities can vary considerably in terms of processing power, memory, storage, and bandwidth available for communication. Typically, applications are also distributed to run different parts of these applications on separate hardware. When used in conjunction with manufacturing, this system is called an industrial cloud. Another concept commonly used synonymously with distributed cloud is edge cloud. However, the term "edge cloud" can also be used to specifically refer to cloud resources located in base stations. Clearly, as shown in Figure 25, an industrial cloud scenario is more common and also spans locations beyond base stations.

[0310] Functional requirements (i.e., specifying the behavior and what to do) and non-functional requirements (quality attributes related to system operation) determine where to deploy specific tasks. Placing data close to the location where it is used is advantageous for time-constrained tasks. In other use cases, bandwidth limitations may necessitate temporary storage areas for the generated data. Therefore, regional (site-level) computing and storage resources are required. However, there are also many time-less critical tasks that are better handled in a central cloud environment. For example, predictive maintenance and anomaly detection often rely on long and complete time series of log and sensor data. Storing this information in a data center simplifies the posterior analysis and training of one of the deep learning algorithms.

[0311] Real-time Manufacturing Software Platform

[0312] On-site edge cloud deployment is seen as a new and improved application enabler for reducing deployment and management costs, including the possibility of replacing equipment components with software-only solutions. A typical example is the robot controller, which in existing deployments is a hardware box installed right next to each manufacturing robot, essentially an industrial-grade PC. This device is responsible for real-time control of the robot, such as motion control, requiring millisecond-level control loops. The first step in the cloudification of these brownfield technologies is to move the software from the controller to the on-site cloud, thus simplifying installation by removing additional hardware components.

[0313] The next step toward a fully software-defined factory is to break down the functionality of current software controllers into more granular functions to leverage the benefits of running programs in the cloud, such as per-function reliability, scaling, externalization of state data, and manageability (e.g., updates and version control). Each function encompasses a specific part of a specific program within the overall domain that constitutes the actual business logic controlling each manufacturing process, and ideally, it can be reused across different such programs. In the context of 5G manufacturing, it is envisioned that programs are formed within and run on top of a Manufacturing Software Platform (MSP) that provides commonly used functions (such as object recognition, motion control, or real-time analytics) in a Function as a Service (FaaS) manner, thereby reusing concepts, toolsets, and experience from the network-scale IT industry. MSP providers achieve high flexibility and programmability of physical devices by stacking components on top of each other and providing an increased level of real-world abstraction. These abstractions are used both in detection / sensing / input and in command / actuation / output.

[0314] These higher-level concepts are (for example) observations synthesized from lower-level sensory inputs, typically combining information from several sources. For example, "Unit #32 has reached its destination" is a trigger that can be calculated based on indoor triangulation, a destination database, and possible camera verification. Each raw input may first be processed in a specific component of an input device (such as a localization system or an image recognition system). The results of using these higher-level components allow the AGV position to ultimately be correlated with more precise coordinates. Finally, even higher-level components can correlate it with a target database and the overall goal of the system. Thus, input is processed by stacking components, each raising the level of abstraction slightly and adding more contextual information.

[0315] Similarly, a high-level quasi-command is like an instruction given to a human worker, such as "transfer this object to that robot", "paint it white", or "drill two holes there". The exact procedure for executing these commands is then calculated by stacking components from task scheduling, trajectory planning, motor control down to the original commands going to the server.

[0316] This method ultimately allows for the use of high-level concepts that are easily understood by humans to program manufacturing processes, completely simplify or hide the complexity and distributed nature of cloud-based applications. It also supports reuse and saves formation time because low-level components may be application-agnostic and can be used in many contexts, while high-level components are easier to work with high-level concepts to form them.

[0317] Both the execution environment and the MSP platform can add value to components that are in and connected to 5G networks, especially when bundled with connectivity solutions (both wired and wireless) to provide a robust and streamlined vision of industrial control. Because of this, an ecosystem of robot suppliers and manufacturers must be onboard and utilize these components. Collaboration in the early stages is essential.

[0318] Data / Information Management

[0319] To manage all data generated within an industrial plant, an information management system is required. Key characteristics of this system are: it is distributed (for robustness and access to data when needed), scalable (this operation should have the same complexity for one or a hundred machines), reusable (adding data management to another manufacturing site to an existing entity should be simple), and secure (committing to confidentiality and privacy, ensuring data integrity, and providing means for data ownership and access control). The system's tasks are to collect, manage, store, filter, retrieve, and identify data of interest. Clearly, the system must accommodate different types of data with varying requirements regarding lifetime, latency, storage and availability, bandwidth, etc. (e.g., time series, streaming data, events of interest, alarms, log files, etc.). Furthermore, it must handle a mix of sensitive and open data. Data storage requirements vary, but a solution based on the concept of a distributed cloud with a "secure" storage area is needed to handle the anticipated wide range of different requirements. Security status includes privacy issues and access rights enforcement, both of which occur during flight (i.e., while the data is in transit) and in storage.

[0320] A rich set of production data forms the basis for all further processing and analysis. Collecting more data facilitates planning, flow control within production, efficient logistics, predictive maintenance, information sharing, control and actuation of individual machines, anomaly detection, rapid response to alarms, decentralized work orders, remote monitoring, daily operations, and many new use cases. The more data collected, the greater the challenge of managing that data. For a large industrial site, the total number of sensors and actuators that can be read, monitored, and controlled can easily exceed 10,000. Sampling rates vary greatly, but the aggregate amount of collected data becomes very large over time. Even finding data of interest can become problematic.

[0321] Production is rarely as static as it may seem. Clearly, variations in product shape, material, size, surface finish, drill placement, etc., may require changes to setups or a slightly different set of work stages. Furthermore, the same set of tools and machines can be used for completely different products in different production batches. When manufacturing a new product, it may even require setting up a completely new production line. Production changes will impact what data is viewed in operations and analysis. When utilizing new sensors and actuators, data management must be adaptable to changed conditions.

[0322] Typically, the same data can be used for multiple purposes (e.g., both for monitoring production and for quality assurance after product completion), and as discussed above, new parameters become relevant when production changes. When collecting sensor data, it is advantageous to annotate it with additional information (also known as meta-data) for future use. A simple example of this is adding a timestamp to each sensor reading, not always from something that has been present since the beginning. Other usable meta-data includes information about location, product ID, details of the tools used, and / or batch number. Generally, this type of meta-data simplifies searching and improves traceability. Specifically, it can be used to filter and extract specific information needed for analytical and machine learning purposes.

[0323] Some sensor data collected can be used for purposes other than industrial processes operating within a factory. For example, readings may relate to monitoring the condition or status of specific equipment used in production but owned by someone else. The owner may be interested in monitoring the equipment to plan maintenance and servicing, and to collecting statistics for future equipment improvements. This data may be sensitive and should not be visible to the factory owner. On the other hand, the factory owner may not want to disclose information related to the quality or quantity of products leaving the production line. Therefore, it is necessary to define data ownership and provide means to restrict data access to authorized parties. The information management system should accommodate this situation while still treating all data in the same way, regardless of its purpose or ownership.

[0324] Figure 26 illustrates a typical manufacturing scenario. On the left is the factory, and on the right is the data center (i.e., the central cloud). Data is generated, annotated, and forwarded for processing and storage via connected tools, machines, and sensors. A "global" device registry records all available producers (sensors) and consumers (actuators). Applications obtain information about where to find the required data by querying the device registry. Storage is considered both at the site and in the data center, just as it is at the source (more details later). This design allows for control applications based on both on-site (low latency) and off-site operations. Clearly, this setup can be replicated if multiple production sites are included.

[0325] This setup is an example of a distributed cloud architecture where data is processed both in the factory and in a central cloud. In situations where available resource capacity is significantly abnormal, the regional setup and its functionality can be made very similar to the corresponding setup and functionality of a data center. This greatly simplifies the deployment, operation, and lifecycle management of applications running in both locations.

[0326] In addition to annotation, storage, and processing of data, an information management system must also manage data sources. In short, this is a process of recording the origin of data, where it has moved over time, who used it, for what purpose, and when it was used. Recording these parameters facilitates auditing, forensic analysis, retrospective analysis, and recovery from the use of erroneous data series. Sources provide the administrator of the information management system with a way to obtain a detailed view of data dependencies and derived results. For example, if a faulty or uncalibrated sensor does not cause immediate production disruption, it may be overlooked for a period of time. Then, if its sensor data is used for training purposes in a machine learning algorithm, the resulting model may become flawed, negatively impacting its use. With proper attribution, it is possible to identify where and when a potentially flawed model has been used and to take appropriate action to mitigate the resulting problems.

[0327] To simplify things for developers, it is important that the information management platform provides a well-defined API for finding and accessing all data. This applies to both the "raw" sensor data collected in real time and the historical records of older data. Specifically, it is worth noting that the distributed cloud model implies that the data of interest can be stored in geographically different locations and that its placement can change over time. This fact arises from different needs (e.g., tolerance for latent changes), overall robustness (e.g., handling data center link failures), and requirements for long-term availability. Applications that use the data should not need to record the storage location itself; the underlying information management platform does this, allowing developers to focus on what is more important.

[0328] A prototype of an information management system is currently deployed at one of SKF's ball bearing factories in Gothenburg. This work is part of the 5GEM II research project, which ran from June 2018 to September 2019. The software is based on both open-source projects (e.g., Calvin for handling data flow from the factory to the data center, and Apache Pulsar and VerneMQ for publish-subscribe messaging) and proprietary internal code. The information management platform is used for data, and Kubernetes is used for containers. Clearly, not all functionality is in place, but we frequently iterate and update it. This work is done using a modern continuous integration / continuous deployment methodology. This means that changes to the code are automatically tested, and deployment to the distributed system can be done with a single command. Careful overall design allows most system updates to be performed without interrupting applications. Therefore, production does not need to be stopped to deploy software updates to the platform. This characteristic is particularly important at factory sites because updates can then be performed outside of scheduled maintenance windows at the production site. Typically, a production stoppage is very costly for manufacturers, which means that planned maintenance windows are very few and spread out as much as possible in time.

[0329] A distributed cloud retains all the characteristics of a central cloud, such as elasticity, on-demand computing, resource clustering, measurable services, and network access. In addition, the ability to place processing closer to the results of use promotes more robust solutions, decentralization, and implementation for low-latency use cases.

[0330] With a well-developed information management system in place, developers can build new applications that access data generated at the factory without physically accessing the manufacturing site or understanding in detail how the data is collected or stored. Different types of data are processed and stored both on-site and in a data center. A well-defined API exposes the service and allows for efficient searching and filtering based on any parameters and available post-processing data. Access rights to data can be defined based on the user and / or the user's role. Advanced logging features facilitate auditing and traceability of the use of collected data.

[0331] Operation and Management

[0332] The term Operation and Management (O&M) refers to the act of operating and managing a network and devices deployed in a factory. Operation Support System (OSS) refers to the software used to accomplish this task.

[0333] A factory floor consists of mechanical devices used to produce and manufacture goods. Machines are typically organized into an assembly line through which goods flow, with or without human intervention, depending on a level of automation. Various tools and machines used in production may or may not be connected. If connected, data is typically collected from the mechanical devices for predictive maintenance of the tools and machines themselves or to assist in quality assurance procedures for manufactured goods. This is called the operational technology (OT) component of the factory floor.

[0334] Most businesses, including their factories, also have communication infrastructure for their workforce, located in appropriate places, consisting of wired and wireless communications (typically Ethernet and Wi-Fi), computers, mobile phones, etc. This equipment is used to access intranets and the internet, email, and other typical office applications. This is called the information technology (IT) section of the factory floor.

[0335] The consolidation of OT and IT has been identified as an emerging trend. In practice, this means a single interface both operates and manages the devices, connections, data generated by these devices, and network infrastructure within a factory. Research questions related to the OT / IT consolidation in factories include: • What types of device management protocols are used for OT and those that can interface to IT systems? • What platform is needed to handle all the different scenarios?

[0336] The concept of digital avatars is very popular in industrial environments. Here, the idea is to bring collected data into a digital data model of a physical asset or the entire plant, and then apply analysis to the data to predict, describe, and define the past, present, and future behavior of the asset or process. Research questions regarding the concept of digital avatars include: • How to model physical assets? • What data is relevant to the acquisition and for how long? • What kind of latency is needed for real-time interaction and how can that latency be provided? • What kind of models are needed to predict possible characteristics? • Where and what kind of computing power is needed to perform meaningful predictions?

[0337] All of this should be achieved through an easy-to-use system that brings increased reliability and availability, reduced risk, lower maintenance costs, and improved production. It would be desirable for one operator to disclose / delegate only a small portion of its O&M to its customers as a solution. Customers should have a simple interface. The solution should be scaled down to only a few devices, making it usable even by a single family.

[0338] Finally, the combination of augmented reality and virtual reality with the concept of digital avatars can have a significant impact on future network management in the merged IT and OT spaces. Device management can be performed remotely while maintaining the feeling of being in the same space. Moreover, technical documents and instructions regarding device use or maintenance can be remotely provided to one person at the site via smart glasses, tablets, etc.

[0339] Timeliness Networking

[0340] Following the general principles and initial overview of Time-Based Networking (TSN), the materials presented here will help you get a good start in TSN. Specific details on 5G-TSN integration are also provided.

[0341] The concept of TSN is envisioned to improve wired IEEE 802.3 Ethernet communication to support high-demand applications in industrial sectors (and other applications). TSN supports time-sensitive networks (or networking). It is an ongoing IEEE standardization proposal among the TSN task groups. They define TSN as a set of individual features. Most TSN features are extensions to the IEEE 802.1Q standard. A TSN network includes Ethernet terminal stations (sometimes called endpoints), Ethernet cables, and bridges (also called switches). If an Ethernet bridge supports a specific (undefined) set of TSN features, then that Ethernet bridge becomes a TSN bridge.

[0342] The different features in the TSN standard generally aim to: • Zero packet loss due to buffer congestion (if the buffer is full, common Ethernet bridges will actually drop packets) • Extremely low packet loss due to faults (device, bit errors, control plane, etc.) • Guaranteed upper limit of peer-to-peer latency • Low packet latency variation (time base error)

[0343] Communication in TSN occurs in TSN streams (which may also be called TSN data streams). For example, a particular feature of TSN is that the stream undergoes a protocol that ensures low latency transmission in the absence of unforeseen contingencies, such as when configured between the transmitter (the terminal station called the communicator) and the network up to the receiver (the terminal station called the listener).

[0344] The following text introduces TSN from a high-level perspective. The following section details what the interaction between TSN and 5G will look like and how specific TSN features can be supported in 5G.

[0345] The TSN standardization originated from the discovery of a new standardized scheme for defining an Ethernet-based communication standard for audio and video communication known as Audio-Video Bridging (AVB). TSN is based on AVB and its features have been enhanced to make it suitable for industrial use. To date, the TSN community focuses on the following industrial use cases: • Industrial communication for factory automation (primary use case #1) o Shop floor TSN links (horizontal) o Shop floor to cloud TSN links (vertical) o In-machine communication o TSN for factory backbone networks • In-vehicle communication (primary use case #2) • Power generation and distribution (smart grid use case) • Building automation (no actual examples of this have been found to date) • Fronthaul (according to IEEE P802.1CM) This document addresses the use cases in industrial communication for factory automation, although some detailed techniques and concepts may be applicable to other use cases.

[0346] Figure 27 illustrates a hierarchical network architecture in a factory. Shop floor TSN links (horizontal) appear within production units, connecting devices, or machines and controllers. The production line area establishes connections between the Operations Technology (OT) and Information Technology (IT) domains and is used to connect production units on the shop floor (if necessary). In the TSN classifications described above, the first (OT-IT) is clearly based on shop floor to cloud TSN links (vertical), and the latter is again based on shop floor TSN links (horizontal). TSN for machine-to-machine communication differs from horizontal shop floor TSN links to date, as it may therefore be a TSN network deployed by a single machine vendor within (for example) a printing machine or any other machine tool – from a 5G perspective, it is unlikely that such horizontal links will need to be addressed. TSN for the factory backbone network is used in the factory / building / office network (light orange area). If deterministic communication from virtualized controllers is desired, for example, TSN is necessary end-to-end all the way to the shop floor.

[0347] TSN communication is an alternative packet service based on a best-effort Ethernet packet network but enhanced with TSN features. A protocol is used between the devices involved in the communication to achieve determinism. This protocol limits the transmitter of a TSN stream to a specific bandwidth, while the network reserves the required bandwidth, thereby preserving buffering mechanisms and scheduling resources. Resources can be exclusively used by a specific stream. Specific observations can be made compared to other packet services (such as CBR (Constant Bit Rate) and best-effort type packet services).

[0348] Best-effort packet service is perhaps the most well-known packet service, which forwards and delivers packets as quickly as possible. However, timely delivery of packets is not guaranteed. End-to-end latency and its variation are considerable, and therefore a statistical language is better suited to express overall performance (loss, end-to-end latency, and time base error). The top portion of Figure 28 illustrates the typical performance of a best-effort packet service network. The typical tail in end-to-end latency causes one of the problems in most industrial use cases.

[0349] Conversely, there are also CBR packet services that provide near-zero fixed latency and time base error (latency variation) (as seen in the application layer). CBR is typically provided by time-domain multiplexing, with typical examples being SDH (Synchronous Digital Hierarchy Network) or OTN (Optical Transport Network). Typical performance of CBR can be seen in the middle section of Figure 28. One drawback of CBR is its inflexibility in how network resources are shared. Therefore, for example, it is difficult to adapt to different application needs in terms of latency or bandwidth – but of course, in the industrial context, requirements are diverse and expected to extend to a single network of all servers.

[0350] The purpose of TSN is to support all types of traffic categories (Quality of Service (QoS) and non-QoS) via a single infrastructure. Therefore, a TSN network sits somewhere between a CBR and a best-effort type packet service, where latency is typically larger compared to a CBR network, but latency variations and time base errors are limited – no tail. In other words, TSN provides a guarantee that the network will not perform worse end-to-end latency and time base errors than a particular protocol (as seen in the bottom portion of Figure 28). These guarantees can be flexibly adapted. Most industrial applications require this behavior.

[0351] One of the core features of TSN is the "stream concept," where a stream includes dedicated resources and APIs. A TSN stream can be viewed as a unicast or multicast from one terminal station (talker) to another or multiple terminal stations (listeners) in a TSN-enabled network. Each stream has a unique stream ID. This stream ID is created from the talker's source MAC address and a unique stream identifier. The bridge will use the stream ID plus the Priority Code (PCP) field and the VLAN ID (VID) (which is contained inside one of the 802.1Q VLAN tags in the Ethernet header) for internal frame processing. In that sense, a TSN stream is a standard 802.1Q Ethernet frame that is given more privileges than a regular non-TSN Ethernet frame. Before a talker can start sending any packets in a TSN stream, the specific stream must be registered in the network and the specific TSN features must be configured. Adjacent to a TSN stream with guaranteed QoS, a peer can also send best-effort traffic within a TSN network – but of course, without QoS guarantees or only with limited QoS guarantees. TSN streams are sent within a TSN domain. A TSN domain can be considered a contiguous domain in which all devices are simultaneously and continuously connected through TSN-enabled ports. A TSN domain is defined as a number of commonly managed devices; packet processing is a management decision.

[0352] Stream management is defined in IEEE 802.1Qcc, Qat, Qcp, and CS. It defines network discovery and the management of network resources and TSN characteristics within a network as (for example) the creation of the required protected channels for TSN streams. Furthermore, stream management provides users and network administrators with functions to monitor, report, and configure network conditions. In TSN, there are three configuration models: a distributed configuration model, a centralized configuration model, and a fully centralized configuration model. In the latter two models, a central network controller (CNC) is used to manage TSN switches, similar to a software-defined networking (SDN) controller. In the fully centralized model, a central user controller (CUC) is used as a central interface for end stations and users. In the distributed model, there is no central control; therefore, bridges and end stations need to negotiate TSN requirements; in this model, certain TSN characteristics of a central entity that needs coordination are not applicable. Many TSN features are also intended to serve as a common protocol and language standard (i.e., YANG, Netconf, Restconf, LLDP, SNMP, etc.) for interaction between CNC / CUC, terminal stations, and bridges.

[0353] Time synchronization is used to establish a common time reference shared by all network entities enabled by TSN. This time synchronization is based on the exchange of packets containing time information, as defined in IEEE 802.1AS-rev; its definition is a modification of the Precision Time Protocol (PTP), which is widely used in the industry context (hereafter referred to as gPTP (Generalized PTP)). gPTP is an advanced version of PTP in that it also supports redundant grandmaster deployments, the establishment of multiple time domains in a single PTP network, and certain other enhancements, as well as support for wider PTP limitations. gPTP aims to achieve sub-microsecond accuracy in synchronization. Precision time synchronization is used for certain TSN features (for example, IEEE 802.1Qbv) and is provided for applications that rely on a common time concept (such as distributed motion control).

[0354] Provides restricted low-latency stream control rules on how frames belonging to a specified TSN stream are handled in TSN-enabled bridges. It enforces rules for effectively forwarding frames according to their associated traffic class and for scheduling frames appropriately. All existing stream controls follow similar principles, i.e., specific privileges are associated with TSN streams, allowing frames not originating from prioritized TSN streams to be scheduled and delayed. Relevant features of industrial networking include frame priority IEEE 802.1Qbv (which introduces "time-gated scheduling" of frames, i.e., time-coordinated handling) and IEEE 802.1Qbu plus IEEE 802.3br. 802.1Qbv relies on precise time synchronization and is only applicable when a CNC is used to schedule frame forwarding in a bridge in a manner similar to time-division multiplexing. Using Qbv, a CNC tells each bridge along one path in the network exactly when to forward a frame. One alternative to Qbv is credit-based shaping derived from AVB (802.1Qav), which may not be suitable for strictly industrial applications due to its non-deterministic nature. An additional feature known as asynchronous service shaping (802.1Qcr) was developed in an early stage of development. One argument against Qbv (which may be optimal for achieving guaranteed latency limits) is the complexity it requires in terms of scheduling and time synchronization. Qbv and frame preemption (Qbu and br) can be used individually or in combination.

[0355] Stream integrity is crucial for providing ultra-reliability. In addition to delivering packets with ultra-low latency and time base error, TSN streams also need to deliver their frames regardless of dynamic network conditions (including transmission errors, physical corruption, and link failures). Stream integrity provides path redundancy, multipath selection, and queue filtering and monitoring. Therefore, a key feature of IEEE 802.1CB includes frame replication and redundancy elimination (FRER).

[0356] Figure 29 provides a visual summary of one of the TSN features described above.

[0357] The interaction between 5G and TSN was discussed above. Because the two systems offer different approaches to pursuing QoS and network management, new solutions are needed. Based on some of the technologies described here, the basic idea is that 5G systems (5GS) are adapted to the network configuration of TSN networks. It should be noted that the ongoing TSN standard defines a set of features, and it is not necessary to support all features for every use case. The declaration regarding which set of TSN features pertains to which use cases has not yet been completed. One ongoing new solution to this problem is the joint project IEC / IEEE 60802: "TSN Configuration File for Industrial Automation." It is under development and frequently updated. It is scheduled for publication in 2021.

[0358] Real-time Ethernet is one of the wired communication technologies used for vertical applications. For wireless communication technologies, 3GPP TS 22.104 specifies the requirements for 5G systems to support real-time Ethernet. When using a 5G system to connect certain sensors, actuators, and motion controllers and using an industrial (i.e., real-time) Ethernet to connect other sensors, actuators, and motion controllers, a gateway UE connected to an Ethernet switch is used to achieve interconnection between real-time Ethernet and 5G, or an Ethernet adapter is used to directly connect a device to a data network.

[0359] Possible baseline system requirements are: • The 5G system should support basic Ethernet Layer-2 bridge functionality for bridge learning and broadcast handling. • The 5G system should support and be aware of VLANs (IEEE 802.1Q). • The 5G system should support clock synchronization defined by IEEE 802.1AS across 5G-based Ethernet links with PDU operational phase type Ethernet. • The 5G system should support TSNs as defined by IEEE 802.1Q (e.g., IEEE 802.1Qbv (Time-Aware Scheduling)). • The 5G system should support the coexistence of critical real-time traffic following a time-aware scheduling with lower priority non-TSN traffic.

[0360] A TSN network consists of four types of components: bridge, terminal, network controller, and cable (Secondary note: In industrial contexts, the terminal is often also a switch to achieve daisy-chaining and ring topologies, for example). If seamless integration within a TSN network is envisioned, a 5G network will in most cases need to behave as one or more TSN bridges. Therefore, in many cases, the 5G network will participate in TSN network configurations as a regular TSN bridge.

[0361] Figure 30 illustrates a baseline architecture in a factory network, where TSN components are used in the workshop and in the factory backbone TSN. 5G is used to replace the workshop-to-cloud (vertical) connection (5G is used for vertical TSN links). Generally, one of the workshop TSNs illustrated in Figure 30 can be at least a single TSN-capable terminal station without any TSN switches. Talkies and receivers can appear on both sides of the 5G network (UE and UPF). The 5G network is used to connect or merge two TSN domains. Radio access points or 5G base stations can be used to connect TSN domains. One of the CUCs and CNCs in Figure 30 is deployed on the factory backbone side, although it can be well implemented in the workshop as (for example) part of an in-machine TSN network.

[0362] Connecting two TSN domains in the same workshop (5G for horizontal TSN links) is a possible scenario. In this scenario, 5GS replaces one of the workshop's single-hop relays. Since NR currently does not support device-to-device (D2D) capability, this will be a dual-hop relay (UEA-gNB / core-UE B) connection in 5G.

[0363] For TSN (Inter-Machine Communication) used inside a machine, interaction with 5G is obviously less relevant, as described above. Two nodes inside a (possibly metal) machine may not rely on a central connection to a 5G base station to communicate wirelessly. A typical example is a printing machine, where different motors must be controlled very precisely to achieve an accurate result.

[0364] Another option is for an existing 5G device (i.e., a device that does not support TSN features, or may not even be an Ethernet device) to connect to a 5GS connected to a factory backbone TSN network. Since the 5G device is unaware of any TSN features or can support them, the 5GS can act as a virtual endpoint representing the 5G device's TSN configuration to communicate with a TSN endpoint end-to-end with seamless QoS. A virtual endpoint function can be part of a UPF in the 5GS. From a TSN network perspective, the virtual endpoint looks like the actual endpoint – the 5G endpoint is hidden. Figure 31 illustrates how the concept works, showing how a virtual endpoint can be used to connect a non-TSN device to a TSN network using 5G. In the figure, "UP" refers to the "User Plane," and "CP" refers to the "Control Plane." This concept can be called an "Application Gateway."

[0365] Certain TSN features pose challenges for 5GS. The following section highlights how 5GS can support certain key TSN features to achieve seamless 5G TSN interaction.

[0366] Network-wide reference time (IEEE 802.1AS-rev)

[0367] In a TSN, reference time is provided by the IEEE 802.1AS-rev synchronization protocol, which allows regional clocks in terminal stations and switches to synchronize with each other. More specifically, the so-called Generalized Precision Time Protocol (gPTP) described therein employs a hop-by-hop time transfer between different TSN-capable devices in the network. This protocol supports the establishment of multiple time domains in a TSN network and a redundant supermaster setup, among other features. A 5GS should be able to participate in the gPTP procedure, thereby allowing the same clock accuracy and synchronization capability as in the TSN. These gPTP procedures must always run periodically to compensate for clock drift. Clock information received by the 5GS from a supermaster in the TSN network via cable needs to be carried over the air from a base station (BS) to a UE, or it may be in other ways. The different options for how this can be performed are discussed below, and it is an ongoing topic of standardization. In the following text and generally speaking, a supermaster is a device that carries a source clock for gPTP.

[0368] Figure 32 illustrates a simple example of TSN time synchronization across a 5G network. A supermaster time signal is received in the 5GS at the UPF side and transmitted over the air by a BS. The UE forwards its received time signal from the BS to device 1 ("Device 1" in the figure). Device 1 may require the supermaster time signal to communicate with device 2 ("Device 2" in the figure).

[0369] Internally, the 5GS can carry a supermaster time signal using any communication unrelated to gPTP. In that case, the entry point in the 5GS (at the UE and User Plane Function (UPF)) needs to act as a gPTP slave. It synchronizes itself to the supermaster from the arrival of the gPTP signal and forwards that time concept on the RAN. Of course, this is application-defined and needs to meet the requirements for time synchronization accuracy. In LTE Release 15, a communication mechanism for accurate time synchronization with sub-microsecond accuracy has been introduced and can be reused in NR.

[0370] For industrial applications, support for multiple time domains can be related, as illustrated in Figures 33 and 34. One time domain can be a global time domain, such as Coordinated Universal Time (UTC). This time domain can be used by applications to record specific events on a global time basis. Additionally, an extra time domain can be used based on a regional clock (i.e., a clock based on an arbitrary time span and without a specific defined start date (e.g., a clock at a supermaster point starting at device startup, rather than a global clock span)). This regional clock can have a much higher accuracy than the global clock. It is distributed from a supermaster point to several other devices and used at the application layer to coordinate very accurate synchronized actions or (for example) for timing communications as defined in 802.1Qbv. To support multiple time domains in 5GS, one possible implementation is (for example) to establish a common reference time between all gNBs and UEs using UTC amplitude, and then, based on that, transmit individual time domain signals in 5GS only to the terminal stations that require that specific time domain. For the transmission of individual regional time signals, a timestamp from the common reference time may be used, or an offset referenced to the common reference time may be transmitted periodically. Alternatively, it may be possible to clearly forward one gPTP frame through the RAN using a similar timestamp mechanism.

[0371] Figure 33 provides a general illustration of the concept of using a common reference time to support multiple other time domains. In this figure, the clock in the 5G time domain represents the common reference time, while the clock in the TSN working domain is the regional clock that needs to be forwarded to some UEs via 5GS. Based on the timestamps completed at the UE and UPF using the common reference time, it is possible to correct the time inside the gPTP packet (belonging to a TSN working domain clock) to account for the changing transmission time in 5GS. It may be necessary to transmit only a subset of all gPTP frames reaching the entry point across 5GS, such as (for example) the announcement (configuration) frame and the follow-up (carrying timestamp) frame. Other frames may be consumed at the 5GS entry point without forwarding. At the exit point, 5GS needs to act as a gPTP master in any case. To detect and distinguish time domains, the domain number field in the gPTP header of each frame can be used. Some effort is required to identify which UE needs to synchronize to which time domain. A recent research activity has resolved this issue.

[0372] In Figure 33, the application function (AF) in the 5GS is used as an interface to the CNC in the TSN network – in one possible way, the CNC can provide information to the 5GS about how the time domain needs to be established (i.e., which UE needs which time domain signal).

[0373] Timed Transmission Gate (IEEE 802.1Qbv)

[0374] TSN Features: IEEE 802.1Qbv provides scheduled transmission of traffic controlled by a transmission gate. Each port in an Ethernet bridge is equipped with up to eight columns, and each column has a separate gate. This is illustrated in Figure 35.

[0375] At the egress port, incoming traffic is forwarded to its intended queue; the egress queue (for example) is identified by the Priority Code Point (PCP) in the VLAN header field of a frame. A normal cycle ("periodic window") is established for each port and at any given time within that window, only specific gates are open and therefore only specific traffic types can be transmitted. Queue coordination is performed by the CNC. The CNC collects information about the topology, streams, and individual latency from all switches and creates a Gate Control List (GCL). The GCL controls the timing of opening and closing queues at each switch, not the order in which frames are queued. If the order in which frames are queued (i.e., the queue state) is not deterministic, the timely behavior of the two streams can oscillate and cause overall end-to-end transmission time base errors. By opening and closing gates in a time-coordinated manner, deterministic latency can be achieved across a TSN network, even if non-deterministic best-effort type traffic exists on the same infrastructure. Best-effort traffic is suppressed simply by closing its queue and allowing priority traffic to be delivered from another queue. It is important to note that timely delivery not only means sending a frame from one bridge to the next at the latest, but also prohibits sending it too early, which can lead to buffer congestion in succession time.

[0376] Assuming the 5GS acts as one or more TSN switches from the perspective of a TSN network, the 5GS should be able to transmit frames in a manner expected by the 802.1Qbv standard (i.e., according to a GCL created by a CNC). This means maintaining specific time windows for ingress and egress TSN traffic at the UE and UPF respectively. Therefore, data transmission in the 5GS must occur within a specific time budget to ensure that packets are forwarded to the next TSN node at the configured time point (neither earlier nor later) in both the uplink and downlink. Since the largest portion of the latency in the 5GS may be added to the RAN, it seems reasonable to use timing information from a CNC at the gNB to improve radio resource scheduling. It is possible to use information about transmission timing according to Qbv scheduling to achieve efficient scheduling of radio resources at a BS using mechanisms such as configured granting and semi-persistent scheduling. Since a BS needs to be time-aware anyway to be able to forward time signals to the UE, it only needs to know the transmission schedule in advance. The Qbv mechanism ensures that frames reach 5GS from the TSN network with minimal time base error.

[0377] The Application Functions (AF) in the 5GS can be an option to interface with the CNC. There, a topology can be declared, and a latency map can be provided to the CNC, as if the 5GS were a normal TSN switch or any TSN switch topology. The AF can then also accept a time schedule from the CNC and translate it into meaningful parameters for the 5GS to support time-gateway scheduling occurring in the external TSN network. It is important to understand that, by the current method of specifying the CNC, it will only accept a fixed number of latency values ​​defined by a typical TSN switch. Therefore, some new methods are required regarding the number of latency values ​​that need to be reported to the CNC, which also allows the 5GS to be a more "flexible" TSN switch.

[0378] One method to achieve timely packet delivery may involve using play buffers at the egress point of the 5G network (i.e., at one of the UEs and UPFs used for downlink or uplink). These play buffers need to be time-aware and aware of the time schedule specified by the CNC of the TSN network for Qbv. The use of play buffers is a common way to reduce timing errors. In principle, for the downlink, for example, the UE or any function following the UE will suppress packets until a specific defined time point arrives to forward the packet ("play the packet"). As an additional function of TSN traffic, this will also be possible in the uplink (possibly in or after the UPF).

[0379] Frame Preemption (IEEE 802.1Qbu)

[0380] IEEE 802.1Qbu Amendment "Frame Preemption" and its Guidelines: IEEE 802.3br "Specifications and Management Parameters for Distributing High-Speed ​​Traffic" adds the ability to interrupt a frame transmission to transmit a higher-priority frame. Because it does not have to wait for the lower-priority transmission to complete, any high-speed frame has a shorter latency. The eight priority levels are divided into two groups: high-speed and preemption. The queue assigned to priority levels belonging to the high-speed group is called the high-speed queue. Transmission of a preemption frame continues after the high-speed traffic has completed, and the receiver can reassemble the preemption frame from fragments.

[0381] 5G networks already support frame preemption using existing mechanisms. It is unclear whether additional effort is needed to fully support frame preemption. It should be noted that there is a key difference between IEEE frame preemption and 5G frame preemption. IEEE frame preemption merely interrupts transmission and resumes frame preemption after forwarding the high-speed frame. There is no retransmission.

[0382] Frame replication and elimination for achieving reliability - FRER (IEEE 802.1CB)

[0383] The IEEE 802.1CB standard introduces procedures, management objects, and protocols for providing packet identification and replication to achieve redundant transmission for bridges and terminal systems. One of these procedures is Frame Replication and Elimination (FRER), which is provided to increase the probability of delivering a given packet – assuming that an Ethernet outlet is removed for any reason or a cable is accidentally cut, communication should continue.

[0384] Figure 36 illustrates some of the basic features of FRER. Some of the important features of FRER are: • Appending sequence numbers to packets originating from a source or a specific stream. • Copying packets based on specific needs / configurations. This results in two (or more) identical packet streams traversing the network. • Eliminating copied packets at specific points in the network (usually near or at the receiver). • Supporting complex configurations, thus the mechanism can support faults at multiple points in the network.

[0385] 5GS may require support for end-to-end redundancy, as also defined in the FRER for TSN, for example by using dual connectivity with a single UE or two PDU operating phases of two UEs (referred to as "paired UEs") deployed in the same industrial installation. However, redundancy in 5GS may not be based on the exact same principles as a TSN network (meaning full physical end-to-end redundancy derived from individual devices). The latter relies on fixed wired links, while 5G relies on a dynamic radio environment. In any case, as defined by the FRER, redundancy precisely indicates faults in the equipment (such as an error in a gNB that leads to a connection loss), but obviously also helps overcome the effects of changes in radio conditions and connection losses attributable to handover.

[0386] If “paired UEs” are used, they should be connected to two BSs at all times to support full redundancy, and in the event of a handover, the “paired UEs” do not execute at the same time and are not connected to the same BS.

[0387] Whether a physical redundancy needs to be implemented in 5GS or whether the service can be carried separately via (for example) a single user plane function (UPF) or server hardware is an open discussion. If (for example) certain 5GS functions are reliable enough that they do not need to be deployed in a redundant manner, then using physical redundancy only for certain parts of 5GS may be sufficient.

[0388] Some inventions have described how this FER type of redundancy can be supported in 5GS (both on the RAN and the core). Application Functions (AFs) are also recommended as a configuration point for redundancy. 5GS can declare different redundant paths to the TSN network, and internally, redundancy can be adequately supported in 5GS with or without physical redundancy of specific components. Therefore, this allows for the implicit redundancy of the actual 5G interpretation to be hidden in the redundancy CNC / TSN definition.

[0389] 5G and TSN – Network Configuration

[0390] In TSN, the IEEE 802.1Qcc extension supports runtime configuration and reconfiguration of TSN. First, it defines a User Network Interface (UNI). This interface allows users to specify streaming requirements without knowing the network, thereby making the network configuration transparent to the user. This is also related to achieving plug-and-play behavior, which is common in home and office networking systems, but especially uncommon in today's industrial Ethernet.

[0391] There are three models for achieving this transparency. Specifically, the fully distributed model, where streaming requirements are transmitted over the network, originating from the intercom and ending at the receiver. In this model, the UNI resides between a terminal station and its access switch. Figure 37 illustrates the fully distributed model, where solid arrows represent the UNI interface used to exchange user configuration information between the intercom, receiver, and bridge. Dashed arrows in the figure represent a protocol carrying TSN user / network configuration information and additional network configuration information.

[0392] The centralized network / distributed user model introduces an entity called the Centralized Network Configurator (CNC), which has complete knowledge of all streams in the network. All configuration messages originate in the CNC. The UNI still resides between the terminal station and the access switch, but in this architecture, the access switch communicates directly with the CNC. Figure 38 illustrates the centralized network / distributed user model.

[0393] Finally, the fully centralized model allows a central user configurator (CUC) entity to capture terminal station capabilities and configure the TSN characteristics within the terminal station. Here, the UNI is located between the CUC and the CNC. This configuration model is best suited for manufacturing use cases where the receiver and intercom require configuration of a significant number of parameters. The CUC interfaces with and configures the terminal station, while the CNC still interfaces with the bridge. The fully centralized model is illustrated in Figure 39. The following discussion provides more details regarding the fully centralized model, as it is likely best suited for manufacturing use cases.

[0394] CUC and CNC

[0395] In a fully centralized model, the CUC and CNC are part of one of two tasks performed by a configuration agent (e.g., a PLC in a factory automation context), as shown in Figure 40, which illustrates a configuration agent composed of a CUC and a CNC. (In the figure, "SW" refers to a switch, "ES" refers to a terminal station, and "UNI" refers to a user network interface.) The standard IEEE 802.1Qcc does not specify the protocol to be used between the CUC and CNC, as shown in Figure 40. OPC UA (Open Platform Unified Communication Architecture) may be one possible interface choice between the CUC and the terminal station, and the Netconf between the bridge and the CNC. For TSN stream establishment, a CUC will make a join request to the CNC, as illustrated in Figure 41, which shows the interaction between the CNC and the CUC.

[0396] Communication between the transceiver and the receiver occurs in a streaming as described above. A streaming has specific requirements in terms of the data rate and latency provided by an application implemented at the transceiver and receiver. TSN configuration and management features are used to set up the streaming and ensure the streaming requirements across the network. The CUC collects streaming requirements and terminal station capabilities from the device and communicates directly with the CNC. Figure 42 shows the sequence diagram for setting up a TSN streaming between different entities.

[0397] The steps for setting up one of the TSN streams in a fully centralized TSN network are as follows: 1) The CUC obtains input from, for example, an industrial application / engineering design tool (e.g., a PLC) that specifies, for example, that devices for switching time-sensitive streams should be used. 2) The CUC reads the capabilities of the terminal stations and applications in the TSN network, including the period / interval of user traffic and the payload size. 3) The CNC uses, for example, LLDP and any network management protocol to discover the physical network topology. 4) The CNC uses a network management protocol to read the TSN capabilities of the bridges (e.g., IEEE 802.1Q, 802.1AS, 802.1CB) in the TSN network. 5) The CUC initiates a join request to the CNC to configure the TSN stream. The CNC will configure network resources at the bridge for one of the TSN streams from one telephone to one or more receivers. 6) The CNC configures the TSN domain. 7) The CNC checks the physical topology and whether the required features are supported by the bridges in the network. 8) The CNC performs stream path and scheduling calculations (assuming Qbv is applied). 9) The CNC configures the TSN features in the bridges along the path in the TSN network. 10) The CNC transmits the stream status (success or failure) back to the CUC. 11) The CUC further configures the terminal station (the protocol used for this information exchange is not within the scope of the IEEE 802.1Qcc specification) to begin user plane traffic exchange as initially defined between the listener and the transceiver.

[0398] 5GS Application Functions (AF) are considered as possible interfaces for interacting with TSN control plane functions (i.e., CNC and CUC). According to 3GPP TS 33.501, AF can influence traffic routing, interact with the policy framework for policy control of 5G links, and further interact with 3GPP core functions to provide services that can be used to set up and configure TSN streams in 5G TSN interaction scenarios. Figure 43 illustrates the possible interfaces between AF and the TSN control plane.

[0399] Figure 44 shows a FRER configuration sequence stream in a TSN network. A CUC sets a parameter value (NumSeamlessTrees greater than 1) to request that a message be added from the CUC to the CNC. The CNC then calculates disjoint trees based on this input in the path calculation step. It uses the IEEE 802.1CB (FRER) management object to configure redundant paths in the bridge.

[0400] As described above in the FRER section, the AF can implement an interface that signals redundancy support to the CNC and receives redundant path calculations from it. This is illustrated in Figure 45, which illustrates the interaction between the AF, CNC, and CNC for setting up FRER. Furthermore, the AF can also be used to interact with the CNC to achieve other TSN features besides FRER.

[0401] TSN is currently in a research and development phase. Early products available on the market only support a subset of the TSN features listed herein. Furthermore, TSN standardization is ongoing and some features have not yet been finalized. In particular, it is unclear which features will be relevant to industrial applications and which will not. IEC / IEEE 60802 continues its efforts to define a TSN profile for industrial use. Nevertheless, it is generally believed that TSN will be the primary communication technology for wired industrial automation in the coming years.

[0402] In the preceding paragraphs, the concept of Time-Sensitive Networking (TSN) was introduced and the vision for improving Ethernet communications for industrial applications was explained. Then, the technical introduction provides certain performance objectives for TSNs that require handling not only best-effort type traffic but also critical priority streams. These critical streams require very low latency that TSNs must support. This allows TSNs to achieve new use cases in the field of industrial automation.

[0403] Then, further details regarding the operating principles of TSN are provided to illustrate how TSN can provide deterministic communication. The issue of integrating 5G with the core features of TSN is also discussed. This integration requires support from a specific set of TSN features from a 5G network. This set of features is described, and certain inventive techniques are also explained for achieving a smooth interaction between the two networks.

[0404] Core Network

[0405] The core network is part of a system residing between the Radio Access Network (RAN) and one or more Data Networks (DNs). A Data Network may be the Internet or a closed corporate network. It is assumed that the core network is fully virtualized and operates on top of a cloud platform. The core network's tasks include: user management; user authentication, authorization, and accounting; mobility management; work phase management, including policy control and traffic shaping; lawful interception; and network public functions. The 5G core network is described in the 3GPP document "System Architecture (5GS) for 5G Systems" (3GPP TS 23.501, v.15.4.0 (December 2018)). Figure 46 illustrates the components of the 5G core network and their relationship to the Radio Access Network (RAN) and UEs, as described in 3GPP TS 23.501.

[0406] In today's mobile broadband (MBB) deployments, core network functions are typically deployed on large nodes serving millions of users. These nodes are usually located in several centralized data centers, thus providing economies of scale.

[0407] In 5G, many other use cases will emerge besides MBB. These new use cases may require different deployments and functionalities. For example, in manufacturing, legal interception and numerous charging and billing functions may not be necessary. Mobility may be simplified or even eliminated in small factory sites. Instead, new functionalities are required, including support for native Ethernet or Time-of-Sight Networking (TSN). Ideally, new functionalities can be added quickly without going through a lengthy standardization process.

[0408] For reasons of latency, data localization, and survivability, a core network used in manufacturing should not necessarily operate in a large centralized data center. Instead, a small-scale core network should be deployed at factory sites. 5G and manufacturing require a core network that is flexible in both deployment and functionality.

[0409] This problem can be solved by decomposing the user plane of the core network into smaller functions called micro user plane functions (µUPFs). Depending on the use case, different sets of µUPFs are reassembled into a single user plane service for a single user. This service can change over time, and the µUPFs are hosted on the execution node, depending on the service requirements at any given time. The control plane of the core network requests a service by describing it at an abstract level. A chain controller translates this high-level service description into a set of µUPFs and instantiates those µUPFs on the correct execution node. Figure 47 illustrates the chain controller concept.

[0410] This approach offers flexibility in terms of deployment and functionality and can be used as a basis for applications such as manufacturing. As an important example of flexibility, this approach allows for implementation schemes that can be scaled down to a very small footprint.

[0411] One alternative to core network deployment in manufacturing is a separate deployment in one area of ​​the factory. Another alternative is to run a portion of the core network in a more centralized cloud. This cloud could be at a vendor site or a company site. This deployment offers economies of scale if the core network is provided by a vendor. Programs used by this manufacturing customer can be hosted on nodes also used by other customers. The same management system can be used to serve multiple customers.

[0412] In later deployments, special attention needs to be paid to latency, data regionality, and regional survivability. A portion of the user plane will always need to run on the regional factory cloud to achieve latency. However, the control plane can run very well remotely, as device control plane communications are primarily used for authentication (infrequent and not time-critical), work phase setup (typically only once for factory devices), and mobility across base stations (which may not occur at all for small deployments).

[0413] Communication is primarily used for authentication (infrequent and not time-critical), work phase setup (usually only once for factory installations), and mobility across base stations (which may not occur at all for small deployments). Figure 48 shows a high-level quasi-functional view of this deployment.

[0414] Certain core network functions used in MBB are not required in manufacturing. This imposes a requirement on one of the core network requirements for industrial applications to be scaled down to a very few features. Certain new features will be needed. The new features that will be needed are basic Ethernet support (native Ethernet PDU operation phase) and more advanced Ethernet features (for example, TSN).

[0415] It is necessary to be able to distinguish communications within a factory. For example, critical production equipment requires services that are different from those of "office" equipment. Several technologies exist to achieve this distinction; these include PLMN, cutting, APN, or µUPF links.

[0416] More features can be envisioned in the following areas: • Flexibility. • Redundancy (multiple UEs). • Data regionality. • Ability to access the factory floor network from outside the factory.

[0417] New features used in manufacturing will affect several interfaces of the core network. For example, running production-critical core network services requires running a production-critical cloud. Alternatively, a network deployment where some parts are regionally operated under the responsibility of the factory owner and others are centrally operated under the responsibility of the operator will require changes in the management system. Furthermore, if the 5G (core) network system is modeled as a single logical TSN switch, additional network public interfaces will be required.

[0418] Radio Access Network

[0419] In recent years, the cellular radio access capabilities necessary to support industrial IoT have been greatly improved, making both LTE and NR suitable technologies for providing this support. Several architectural options for URLLC, supporting reliable delivery and new MAC and PHY features, have been added to the specifications of LTE and NR Release 15. Additional URLLC enhancements are being researched for NR Release 16, with one goal being to achieve latency of 0.5ms to 1ms and reliability up to 1-10-6. Furthermore, improvements are envisioned for Release 16, particularly for support of Ethernet PDU delivery and TSN provided by the NR RAN.

[0420] The following describes the LTE and NR URLLC features specified in 3GPP Release 15 and the proposed RAN concepts in NR Release 16. First, it discusses how 5G RAN architecture options can be used to support data replication for greater reliability. Then, it describes the Layer 1 and Layer 2 features for URLLC, including the features currently considered in Rel-16 work regarding NR-Industrial IoT and enhanced URLLC (eURLLC). The following continues to explain how LTE and NR deliver precise time references to the UE and how Ethernet compression works when delivering Ethernet PDUs through the 5G RAN. For industrial IoT use cases, such as factory automation, reliability needs to be ensured for both the data and control planes. Furthermore, it describes how reliable control plane and reliable mobility can be achieved. A technology roadmap is presented, highlighting the feature sets specified in Release 15 LTE and Release 15 NR and planned for Release 16 NR, and summarizing the technology roadmap in an overview.

[0421] 5G RAN Architecture Options

[0422] This subsection introduces the 5G RAN architecture, and the subsequent explanation of the features supporting industrial IoT is based on this 5G RAN architecture.

[0423] The 5G standardization work in 3GPP has been summarized for Release 15 for NR, LTE, and multiple connectivity, encompassing both NR and LTE. Release 15 is the first version of the newly developed 5G NR radio access technology. In addition, several LTE features necessary for achieving 5G use cases have been specified. These new Rel-15 NR and LTE standards support the integration of the two technologies in multiple variants, that is, LTE base stations (eNBs) interact with NR base stations (gNBs) via the E-UTRA core network (EPC) and the 5G core network (5GC), respectively. In these integrated solutions, user equipment (UE) connects simultaneously to two radio base stations of LTE or NR type via different carriers, generally represented as dual connectivity (DC) and in the case of LTE+NR as EN-DC / NE-DC. Figures 49, 50, and 51 illustrate the network architecture that allows LTE and NR to interact.

[0424] Figure 49 illustrates the RAN control plane in a multi-connectivity scenario. In the EN-DC scenario, shown on the left side of the figure, the LTE primary eNB (MeNB) is anchored to the EPC's MME. In this scenario, the NR node (gNB) is integrated into the LTE network (hence the designation en-gNB). In the NR-NR DC scenario, shown on the right side, both the primary and secondary nodes (MN and SN) are of the NR gNB type, where the MN terminates the control plane interface to 5GC, i.e., AMF.

[0425] Figure 50 illustrates the user plane network architecture, again showing the EN-DC scenario on the left and the NR-NR DC scenario on the right. In the user plane, data can be routed directly from the core network to secondary nodes (en-gNB in ​​EN-DC and SN in NR-NR DC) or via MeNB / MN to secondary nodes. Transmission to / reception from the UE can then occur between the two nodes.

[0426] The protocol architecture for radio access in LTE and NR is largely the same and consists of the Physical Layer (PHY), Media Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), and Service Data Adaptive Protocol (SDAP) (for QoS flow processing of the 5GC used in NR). To provide low latency and high reliability for a single transport link, i.e., to transmit data for one radio bearer over a single carrier, several features of the user plane protocols for PHY and MAC have been introduced, as will be further discussed in the following sections. Furthermore, reliability can be improved by redundantly transmitting data over multiple transport links. For this purpose, several bearer type options are available.

[0427] Figure 51 illustrates the different radio bearer types that can be adopted for both user plane bearers and control plane bearers (DRB or SRB). In the primary cell group (MCG) or secondary cell group (SCG), bearer type transmissions occur independently via cell groups that are secondary nodes, such as the MeNB / MN or en-gNB / SN. It should be noted that MCG and SCG are defined from the UE's perspective. However, from the network's perspective, these bearers can terminate independently of the cell group used, either in the MN or SN.

[0428] In split bearer type operation, data is split or copied in the PDCP and transmitted via RLC entities associated with both the MCG and SCG cell groups. Furthermore, the split bearer can be terminated in the MN or SN. Data can be delivered to the UE via one or more of these bearers. Data copying is possible for MCG or SCG bearers when CA is used in another cell group or by using split bearers for copying within the cell group; this is further explained below. Additionally, redundancy can be introduced by transmitting the same data via multiple bearers (e.g., MCG-terminated bearers and SCG-terminated bearers), with this copying occurring at a higher layer, such as outside the RAN.

[0429] Facilitating Factors of URLLC in User Plane

[0430] For the operation of URLLC services, that is, the deployment of low latency and high reliability communication, several features have been introduced in Rel-15 for both LTE and NR. This set of features forms the basis of URLLC support, such as supporting 1ms latency and 1-10^-5 reliability.

[0431] In the RAN concept described herein, these URLLC features are considered as a baseline with enhancements for both Layer 1 and Layer 2. These URLLC features are used, on the one hand, to meet the more stringent latency and reliability targets of 0.5 ms and 1-10^-6 reliability, but on the other hand, they also allow for more efficient URLLC operation, i.e., to improve system capacity. These enhancements are also particularly relevant in a TSN context, i.e., where multiple services with different (mainly periodic) traffic characteristics must be provided with a deterministic latency.

[0432] This section describes the URLLC enabling factors for user plane data delivery, namely, Layer 1 and Layer 2 characteristics. This is only one part of the overall RAN concept; in order to support 5G TSN integration from the RAN, additional features are considered, such as reliability and mobility in the control plane, and accurate time reference deployment.

[0433] It should be noted that in most cases, the main descriptions herein are based on NR, although in specific cases, the LTE descriptions are provided as a baseline while the features are conceptually applicable to NR as well. Further, a table is provided below to identify whether a feature is specified for LTE / NR. Whether a feature is required in terms of latency and reliability depends on the specific URLLC QoS requirements. Furthermore, some features may not be considered contributing factors to URLLC itself, but enable the system to fulfill URLLC requirements more efficiently; that is, features that enhance capacity will result in an increased number of URLLC services available. Therefore, these features can be broadly grouped into essential features for achieving low latency, essential features for achieving high reliability, and other features, as described below.

[0434] Key features for achieving low latency: • Scalable and flexible digitization • Micro time slots and short TTI • Dynamic TDD for low latency optimization • Fast processing time and fast HARQ • Pre-scheduling (CG) on the uplink granted by configuration (Layer 2);

[0435] Essential characteristics for achieving reliability: • Lower MCS and CQI for achieving lower BLER targets

[0436] In addition, the following features have also been considered: • Short PUCCH: for example, for Fast Schedule Request (SR) and Faster HARQ Feedback • DL Preemption: for fast transmission of critical traffic while other traffic is in progress • Enhanced DL Control: for more efficient and robust transmission of downlink control • Multi-Antenna Technology: for improved reliability • Enhanced Schedule Request and BSR: for handling multiple traffic types • PDCP Replication: for carrier redundancy, i.e., even more reliability

[0437] Starting with layer 1 and continuing with layer 2, the following discussion will review the features as specified in version 15, describe one of the enhancements suitable for version 16, and describe the new features suitable for version 16.

[0438] URLLC enabler in the user plane

[0439] In NR, a time slot is defined as 14 OFDM symbols and a subframe as 1 ms. The length of a subframe is therefore the same as in LTE, but the number of time slots per subframe varies depending on the OFDM digits. (The term "digits" refers to the combination of carrier spacing, OFDM symbol duration, and time slot duration.) At carrier frequencies below 6 GHz (FR1), digits of 15 kHz and 30 kHz SCS (subcarrier spacing) are supported, while 60 kHz SCS is selected for the UE. 15 kHz SCS is equal to the LTE digits for the normal cyclic prefix. For frequency range 2 (FR2), digits of 60 and 120 kHz SCS are supported. This can be summarized in Table 8. Time slot duration Frequency range Support synchronization 0 15 1 ms FR1 yes 1 30 0.5 ms FR1 yes 2 60 0.25 ms FR1 (selected) and FR2 3 120 0.125 ms FR2 yes Table 8 – Summary of supported digitization for data transfer in NR version 15

[0440] The possibility of using different digits has the benefit of adapting NR to a wide range of different scenarios. A minimum 15 kHz subcarrier spacing simplifies coexistence with LTE and provides long symbol durations and long cyclic prefix lengths, making it suitable for large cell sizes. Higher digits have the following benefits: occupying a larger bandwidth; being more suitable for higher data rates and beamforming; having better frequency diversity, which is important for URLLC; and having a low latency due to short symbol durations.

[0441] Numerical characteristics can therefore be considered a feature of URLLC because the transmission time is shorter for high SCS systems. However, the communication limitations per time slot need to be considered, such as PDCCH monitoring, UE capabilities, and PUCCH transmission scenarios (which can be a limiting factor), because the UE does not have such a large capability per time slot under high SCS.

[0442] NR provides support for microslots. There are two mapping types supported in NR for PDSCH and PUSCH transmissions: Type A and Type B. Type A is generally referred to as slot-based, while Type B transmissions can be referred to as slotless or microslot-based. Microslot transmissions can be dynamically scheduled and are used in version 15: • For DL, they can be of length 7, 4, or 2 symbols, while for UL, they can be of any length. • They can begin and end at any symbol within a slot. Note that the last bullet point indicates that the transmission may not cross the slot boundary, which introduces complexity for specific combinations of numbers and microslot lengths.

[0443] Both micro-time slots and short TTIs reduce the maximum alignment delay (wait time for transmission opportunities) and transmission duration. Compared to the "normal" 14 OFDM symbol time slots, both the maximum alignment delay and transmission duration decrease linearly with the reduction of TTI and micro-time slot length, as can be seen in Figure 52 (which shows the latency resulting from the use of micro-time slots). Assuming Capability 2 UE processing, the results in Figure 52 are based on downlink FDD single time slot, unidirectional latency. In certain wide-area scenarios, higher-order digitization is unsuitable (shortened CP length may be insufficient to handle channel time dispersion), and the use of micro-time slots is the primary method for reducing latency.

[0444] One drawback of micro-slots is the need to assign more frequent PDCCH monitoring. Frequent monitoring can be challenging for the UE and can also deplete resources that could otherwise be used for DL ​​data. In NR Rel-15, the number of configurable monitoring scenarios will be limited by the maximum number of blind decodings per slot and per cell that the UE can perform, as well as the maximum number of non-overlapping control channel elements (CCEs) per slot and per cell.

[0445] To maintain the efficiency of data symbols, we can expect a higher L1 overhead due to the higher resolution resources used for DMRS in the case of microslots. Even if only one resolution of OFDM symbols is used for DMRS, it can be, for example, four out of 14 symbols in one slot instead of one out of two symbols.

[0446] Based on the described shortcomings, the following challenges related to micro-slots are addressed in NR Release 16: • Micro-slot duplication (including duplication that crosses slot boundaries); • Reduction of DMRS overhead; • Enhanced UE monitoring capabilities; • Faster processing in UEs and gNb. The Release 16 solutions to these challenges are described below.

[0447] Regarding micro-slot repetition, since URLLC traffic is highly latency-sensitive, the most relevant time allocation method is Type B, where transmission can begin at any OFDM symbol within a time slot. Simultaneously, reliability requirements may lead to very conservative link adaptive settings, thus a lower MCS requiring more RBs can be selected. Instead of a wider frequency allocation, the gNB can decide to allocate transmissions with longer time intervals, which can help schedule more UEs simultaneously. Unfortunately, due to the limitations of NR version 15, if a transmission overlaps with a time slot boundary, the transmission must be delayed in time. Figure 53 illustrates this problem graphically, showing one example of a long alignment delay resulting from transmissions crossing time slot boundary limitations in NR version 15. Here, the alignment delay is a time interval between two events: when the UE is ready to transmit and when the transmission occurs at the beginning of the next time slot.

[0448] To illustrate the potential latency gain by allowing a transmission's schedule to cross the time slot boundary using micro-time slot repetition, we examine the average latency gain compared to a scheduled transmission constrained to be assembled in a time slot. Figure 54 illustrates one method of achieving this using micro-time slot repetition, but other methods yield the same total latency.

[0449] Assuming that data packets may arrive at the UE at any symbol within a time slot, Tables 9 to 11 show the worst-case latency for different combinations of transmission duration and SCS for non-boundary and boundary-crossing schedules, respectively. This takes into account UL-granted and HARQ-based retransmissions. Since there are 14 symbols in a time slot and we typically aim for a very low probability of block errors, we need to ensure that the latency limit is reached when data arrives at the symbol giving the worst-case latency. We use Capability 2 UE to evaluate latency, and the gNB processing time is the same as the processing time at the UE. We assume that the gNB uses half the processing time for decoding, that is, if the transport block is decoded correctly, it can be delivered to the higher layer after half the processing time. Since allowing HARQ retransmissions reduces the amount of resources used by aiming for a higher BLER in the initial transmission, we evaluated the potential time after the initial transmission, the first, second, and third HARQ retransmissions. This took into account the time required to transmit the PDCCH to schedule the retransmission and the time required to prepare the PUSCH retransmission. We assumed that any retransmission used the same length as the initial transmission.

[0450] In Tables 9 through 14, we show the worst-case latency for HARQ-based retransmissions (transmissions not crossing time slot boundaries) achievable with version 15, and the worst-case latency when using micro-time slot repetitions to allow crossing time slot boundaries. We count any repetitions by considering SCS = 15, 30, or 120 kHz and a total PUSCH length of 2 to 14 symbols; that is, a 2-symbol micro-time slot repeated 4 times is shown in the table as a transmission of length 8. To make the tables easier to interpret, these tables focus on target latency of 0.5 ms, 1 ms, 2 ms, and 3 ms, respectively. In the tables showing the worst-case latency using micro-time slot repetitions, shaded cases indicate situations where one of these target latency boundaries can be met using micro-time slot repetitions but cannot be achieved with version 15. length 2 3 4 5 6 7 8 9 10 11 12 13 14 Init.tx 0.68 0.89 0.96 1.18 1.25 1.46 1.54 1.75 1.82 2.04 2.11 2.32 2.39 1 retx 1.68 1.89 1.96 2.18 2.54 2.68 2.82 2.96 3.82 4.04 4.11 4.32 4.39 2 retx 2.68 2.89 2.96 3.18 3.75 3.82 4.04 4.75 5.82 6.04 6.11 6.32 6.39 3 retx 3.68 3.89 3.96 4.18 4.75 5.46 5.54 5.96 7.82 8.04 8.11 8.32 8.39 Table 9 – Worst-case latency of SCS version 15 at 15 kHz Length 2 3 4 5 6 7 8 9 10 11 12 13 14 Init.tx 0.68 0.75 0.82 0.89 0.96 1.04 1.11 1.18 1.25 1.32 1.39 1.46 1.54 1 retx 1.61 1.68 1.89 1.96 2.18 2.25 2.46 2.54 2.75 2.82 3.04 3.11 3.32 2 retx 2.32 2.68 2.89 2.96 3.18 3.54 3.75 3.96 4.18 4.39 4.61 4.82 5.04 3 retx 3.18 3.68 3.89 3.96 4.18 4.82 5.04 5.25 5.46 5.82 6.04 6.54 6.75 Table 10 – Latency of 15 kHz SCS when micro-time slots are reused for scheduling across time slot boundaries length 2 3 4 5 6 7 8 9 10 11 12 13 14 Init.tx 0.40 0.51 0.54 0.65 0.69 0.79 0.83 0.94 0.97 1.08 1.12 1.22 1.26 1 retx 0.90 1.01 1.04 1.29 1.33 1.44 1.47 1.94 1.97 2.08 2.12 2.22 2.26 2 retx 1.40 1.51 1.54 1.94 1.97 2.29 2.33 2.94 2.97 3.08 3.12 3.22 3.26 3 retx 1.90 2.01 2.04 2.65 2.69 2.94 2.97 3.94 3.97 4.08 4.12 4.22 4.26 Table 11 – Worst-case latency of SCS version 15 – 30 kHz length 2 3 4 5 6 7 8 9 10 11 12 13 14 Init.tx 0.40 0.44 0.47 0.51 0.54 0.58 0.62 0.65 0.69 0.72 0.76 0.79 0.83 1 retx 0.90 1.01 1.04 1.15 1.19 1.29 1.33 1.44 1.47 1.58 1.62 1.72 1.76 2 retx 1.40 1.51 1.54 1.79 1.83 2.01 2.04 2.22 2.26 2.44 2.47 2.58 2.62 3 retx 1.90 2.01 2.04 2.44 2.47 2.65 2.69 2.94 2.97 3.29 3.33 3.51 3.54 Table 12 – Latency of 30 kHz SCS when micro-time slots are reused for scheduling across time slot boundaries length 2 3 4 5 6 7 8 9 10 11 12 13 14 Init.tx 0.44 0.46 0.47 0.50 0.51 0.54 0.54 0.57 0.58 0.61 0.62 0.64 0.65 1 retx 0.97 1.02 1.03 1.05 1.06 1.16 1.17 1.20 1.21 1.23 1.24 1.39 1.40 2 retx 1.51 1.59 1.60 1.63 1.63 1.79 1.79 1.82 1.83 1.86 1.87 2.14 2.15 3 retx 2.04 2.14 2.15 2.18 2.19 2.41 2.42 2.45 2.46 2.48 2.49 2.89 2.90 Table 13 – Worst-case latency of SCS version 15 at 120 kHz Length 2 3 4 5 6 7 8 9 10 11 12 13 14 Init.tx 0.44 0.45 0.46 0.46 0.47 0.48 0.49 0.50 0.51 0.52 0.53 0.54 0.54 1 retx 0.97 1.00 1.01 1.04 1.04 1.07 1.08 1.11 1.12 1.14 1.15 1.18 1.19 2 retx 1.51 1.55 1.56 1.61 1.62 1.66 1.67 1.70 1.71 1.77 1.78 1.80 1.81 3 retx 2.04 2.09 2.10 2.16 2.17 2.25 2.26 2.30 2.31 2.39 2.40 2.43 2.44 Table 14 – Latency of 120 kHz SCS when micro-time slots are reused for scheduling across time slot boundaries

[0451] Compared to version 15 scheduling, the following gains are achieved: • For a latency threshold of 0.5 ms, micro-time slots are used to allow an additional 5 cases. Gains occur for initial transmissions at 30 and 120 kHz SCS. • For a latency threshold of 1 ms, micro-time slots are used to allow an additional 6 cases. Gains occur for initial transmissions at 15 and 30 kHz SCS. • For a latency threshold of 2 ms, micro-time slots are used to allow an additional 11 cases. Gains occur for initial transmissions, first or second retransmissions at 15, 30, or 120 kHz SCS. • For a latency threshold of 3 ms, micro-time slots are used to allow an additional 7 cases. Gains occur for second or third retransmissions at 15 or 30 kHz SCS.

[0452] Microtime slot repetition in UL can be used with other features to achieve higher reliability, such as frequency hopping based on a specific pattern or pre-encoder cycles across repetitions.

[0453] PUCCH enhancements include the use of short PUCCHs. For DL ​​data transmission, the UE sends a HARQ feedback to acknowledge (ACK) the correct reception of the data. If the DL data packet is not received correctly, the UE sends a NACK and expects a retransmission. Due to the strict latency constraints of URLLC, short PUCCH formats with 1 to 2 symbols (e.g., PUCCH format 0) are expected to be highly relevant. Short PUCCHs can be configured to start at any OFDM symbol in a time slot, thus achieving fast ACK / NACK feedback suitable for URLLC. However, there is a trade-off between the low latency of HARQ feedback and high reliability. If more time resources are available, it is also beneficial to consider a longer PUCCH format with a duration of 4 to 14 symbols. Using longer time resources may enhance PUCCH reliability.

[0454] Another enhancement is UCI multiplexing with PUSCH. For a UE operating a hybrid service with both eMBB and URLLC, the reliability requirements for UCI transmitted on PUSCH can differ significantly from those for PUSCH data. (For example) when HARQ-ACK for DL ​​URLLC data is transmitted simultaneously with eMBB data, the reliability requirements for UCI can be higher than those for PUSCH data, or (for example) when CQI reports for eMBB are transmitted simultaneously with URLLC data, the reliability requirements for UCI can be lower than those for PUSCH data. In cases where UCI has lower requirements than PUSCH data, discarding some or all of the UCI may be preferable.

[0455] The encoding offset between the UCI and PUSCH data is controlled by the beta factor of different types of UCI (HARQ-ACK, CSI). An offset greater than 1.0 means encoding the corresponding UCI more reliably than the data. The beta factor defined in version 15 has a minimum value of 1.0. This value may not be low enough when considering URLLC data with eMBB UCI. A better solution would be to introduce a special beta factor value that allows the UCI on the PUSCH to be omitted to ensure URLLC reliability. This method is illustrated in Figure 55, which shows the use of a beta factor in the DCI signal to "omit" the UCI transmission. A related issue is when a scheduling request (SR) for URLLC microslot transmission arrives during slot-based transmission. This issue is further analyzed below.

[0456] Other enhancements in the field of power control. When transmitting UCI on the PUCCH, reliability requirements can vary significantly depending on whether the UCI is associated with eMBB or URLLC / eURLLC. For Format 0 and Format 1, the number of PRBs is equal to 1, and one attempt to increase reliability by using more PRBs is to make the PUCCH sensitive to time dispersion. Therefore, for Format 0 and Format 1, different reliability can be achieved by using different numbers of symbols and / or power adjustments.

[0457] The number of symbols can be dynamically indicated using the "PUCCH Resource Indicator" field in the downlink DCI, where two PUCCH resources are defined with different numbers of symbols. However, power adjustment is limited to a single TPC table and / or may use PUCCH spatial relationship information, where multiple power settings (such as P0) and up to two closed components can be defined. However, different PUCCH power settings can only be selected using MAC CE communication. This is clearly too slow in a mixed service scenario where the transmitted HARQ-ACK can change from being eMBB-related to being URLLC / eURLLC-related between two consecutive PUCCH transmission opportunities. As one solution to this problem, PUCCH power control enhancements can be introduced in NR Release 16 to achieve a larger power difference between eMBB-related PUCCH transmissions and URLLC-related PUCCH transmissions: • A new TPC table allows for larger power adjustment steps, and / or • Dynamic indication of power settings using DCI indicators (e.g., P0, closed-loop index).

[0458] Further enhancements regarding HARQ-ACK transmission opportunities. For URLLC with strict latency requirements, when using micro-slot-based PDSCH transmissions, several transmission opportunities are needed within a time slot, and therefore several opportunities for HARQ-ACK to be reported on the PUCCH within a time slot are also required. In Release 15, each time slot supports at most one PUCCH transmission including HARQ-ACK. This will increase the alignment time for sending HARQ-ACK and thus increase DL data latency. To reduce downlink data latency, it is necessary to increase the number of PUCCH opportunities for HARQ-ACK transmissions within a time slot, especially in cases where multiplexing of eMBB and URLLC traffic is supported on the downlink. Although a UE's processing capacity provides a minimum number of OFDM symbols from the end of a PDSCH transmission to the start of the corresponding HARQ-ACK transmission on a PUCCH, the actual transmission time of HARQ-ACK is further limited by the number of PUCCHs allowed within the time slot.

[0459] In version 15, a UE can be configured with a maximum of four PUCCH resource groups, each consisting of several PUCCH resources, which can be used for a certain range of UCI size provided by the configuration, including HARQ-ACK bits. The first group can only be used for 1 to 2 UCI bits containing HARQ-ACK information and can have a maximum of 32 PUCCH resources, while other groups (if configured) are used for two or more UCI bits containing HARQ-ACK and can have a maximum of 8 PUCCH resources. When a UE reports HARQ-ACK on the PUCCH, it determines a PUCCH resource group based on the number of HARQ-ACK information bits and the PUCCH resource indicator field in the last DCI format 1_0 or DCI format 1_1 (which has a value indicating the PDSCH to HARQ feedback timing indicator for the same time slot used for PUCCH transmission). When the size of the PUCCH resource group is up to 8, the PUCCH resource identity is explicitly indicated by the PUCCH resource indicator field in the DCI. If the size of the PUCCH resource group is more than 8, in addition to the PUCCH resource indicator field in the DCI, the PUCCH resource identity is also determined by the index of the first CCE used for PDCCH reception.

[0460] For URLLC with strict latency requirements, there are several transmission opportunities for PDSCH transmission within one time slot, and therefore several opportunities for HARQ-ACK to be reported on PUCCH within one time slot, as mentioned earlier.

[0461] This means that a UE needs to configure several PUCCH resources to achieve the possibility of multiple opportunities for HARQ-ACK transmission within a time slot, although only one of them can be used in each time slot. For example, a UE running URLLC service can be configured to receive PDCCH in every other OFDM symbol (e.g., symbols 0, 2, 4, ..., 12) and also receive PUCCH resources for HARQ-ACK transmission in every other symbol (e.g., 1, 3, ..., 13). This means that the UE needs to configure a set of 7 PUCCH resources solely for HARQ-ACK reporting for URLLC within a given UCI size. Since other PUCCH resources may be required for other needs, this may exceed the list of up to 8 PUCCH resources that can be explicitly indicated by the PUCCH resource indicator in the DCI. If there are more than 8 PUCCH resources in the set in the case of 1 to 2 HARQ-ACK bits, the index of the first CCE will control which PUCCH resource is indicated. Therefore, the location where DCI can be transmitted can be limited to one that can reference a given PUCCH resource. This can impose scheduling constraints when DCI can be transmitted and can also lead to "blocking" when DCI cannot be transmitted on the intended CCE (due to its use by another UE). Therefore, instead of configuring 7 PUCCH resources in the example above, it can be assumed that there is one periodic PUCCH resource with one transmission opportunity per two symbols within a time slot. This method is illustrated in Figure 56, which shows a short PUCCH occupying one OFDM symbol (i.e., Ns=1), where one period (P) is two OFDM symbols. Here, a total of 7 periodic PUCCH resources are defined in one time slot.

[0462] The solutions and problems described above apply to both FDD and TDD. However, for the fixed "micro-slot" TDD mode, eight PUCCH resources that can be explicitly indicated are sufficient, since only the UL portion of the slot can include PUCCH resources.

[0463] Regarding PDCCH enhancement, in situations with high reliability requirements for URLLC, it is crucial that the transmission of downlink control information (DCI) is sufficiently reliable. This can be achieved through several means, including improved UE / gNB hardware capabilities, enhanced gNB / UE implementation schemes, and well-chosen NR PDDCH design.

[0464] In terms of design choices, the NR PDCCH includes several features that enhance reliability. These features include: • DMRS-based, which allows for the use of beamforming; • Support for frequency-distributed transmission schemes; • Aggregated level 16; • Increased CRC length (24 bits).

[0465] NR supports two main DCI formats: normal-sized DCI formats 0-1 and 1-1, and smaller-sized downsized DCI formats 0-0 and 1-0. Although scheduling flexibility may be limited, it is reasonable to use downsized DCI after data scheduling to achieve PDCCH robustness for a given aggregation level due to the lower coding rate. Furthermore, note that normal DCI contains several fields that are irrelevant to URLLC (such as bandwidth portion indicators), CBG-related fields, and a second TB-related field.

[0466] One possible enhancement is a URLLC-specific DCI format. Both the aggregation level (AL) and the DCI size can affect PDCCH performance. The aggregation level has different channel coding rates and is used for PDCCH in link adaptation, while the DCI payload size is relatively fixed for configured connections. To make PDCCH transmission more robust, a high AL and / or a small DCI payload size can be used to reduce the PDCCH code rate. Table 15 summarizes the PDCCH performance comparison between different DCI sizes. Here, a DCI size of 40 bits is used as a reference for reducing DCI size after version 15, while DCI sizes of 30 and 24 can be referred to as compact DCI sizes. See also that the gain from reducing the DCI size from 40 bits to 24 bits is particularly small at high AL, and the gain is even smaller when reducing the DCI size from 40 bits to 30 bits. The gain essentially depends on the code rate reduction level. BLER Target Payload size excluding CRC bits (A->B) The total number of bits decreased SNR performance benefits (dB) AL16 AL8 AL4 AL2 AL1 1e-5 40->30 10 0.31 0.38 0.41 0.55 1.13 40->24 16 0.47 0.58 0.68 0.95 1.94 Table 15 – SNR Improvement (dB) for TDL-C at BLER Targets: 300 nS, 4 GHz, 4 Rx, 1 os

[0467] In situations with high reliability requirements for URLLC, it is crucial that the transmission of downlink control information (DCI) is sufficiently reliable. This can be achieved through several means, including improved UE / gNB hardware capabilities, enhanced gNB / UE implementation, and good NR PDDCH design choices.

[0468] In terms of design choices, the NR PDCCH includes several features that enhance reliability. These features include: • DMRS-based, which allows for the use of beamforming; • Support for frequency-distributed transmission schemes; • Aggregated level 16; • Increased CRC length (24 bits).

[0469] NR supports two main DCI formats: normal-sized DCI formats 0-1 and 1-1, and smaller-sized downsized DCI formats 0-0 and 1-0. Although scheduling flexibility may be limited, it is reasonable to use downsized DCI after data scheduling to achieve PDCCH robustness for a given aggregation level due to the lower coding rate. Furthermore, note that normal DCI contains several fields that are irrelevant to URLLC (such as bandwidth portion indicators), CBG-related fields, and a second TB-related field.

[0470] When a URLLC UE operates under good channel conditions, using a low AL for the PDCCH is reasonable. It has been argued that a compact DCI can positively impact PDCCH multiplexing capacity because more UEs with good channel conditions can utilize AL, thus reducing the probability of blocking. To examine this, the impact of using a compact DCI on PDCCH blocking probability was studied and found to vary with DCI size, number of UEs, and CORESET resources. The number of URLLC UEs in a cell is considered to be between 4 and 10. CORESET resources are determined based on CORESET duration and bandwidth. It is assumed that a CORESET occupies 1 or 2 OFDM symbols with a 40 MHz BW.

[0471] Figure 57 illustrates the blocking probability for each monitoring scenario as a function of DCI size, average number of UEs, and CORESET size. The simulation assumes use with version 15 enabled. As can be seen from Figure 57, the PDCCH blocking probability for each monitoring scenario depends on several parameters, such as DCI size, number of UEs, and CORESET size. Regarding improvements in blocking probability for a given number of UEs, it is clear that using a smaller DCI size provides a much smaller gain compared to using larger control resources.

[0472] Furthermore, due to the constraints of demodulation and decoding complexity at the UE, there is a budget for the number of DCI sizes that the UE should monitor per time slot, namely, three different sizes of DCI scrambled by C-RNTI and one additional size of other RNTIs as agreed in version 15. Therefore, introducing another DCI format with a smaller size will be even more challenging to meet the DCI size constraints.

[0473] One alternative to the compact DCI used for PDCCH enhancement in Release 16 can be considered. In NR Release 15, there are two main DCI formats for unicast data scheduling: the down-drop DCI format 0-0 / 1-0 and the normal DCI format 0-1 / 1-1. The down-drop DCI supports resource allocation type 1, where the DCI size depends on the bandwidth size. A single TB transmission inherently has limited flexibility, for example, it does not have any multi-antenna related parameters. On the other hand, the normal DCI provides flexible scheduling and multi-layer transmission.

[0474] Due to the high reliability requirements of URLLC, we see that using a small-sized feedback DCI to achieve good PDCCH performance is beneficial. At the same time, having parameters that support high-reliability transmission (such as multi-antenna related parameters) can be beneficial. This can encourage a new DCI format with the same size as the down-drop DCI, but improved from the down-drop DCI to include certain useful fields (e.g., fields present in the normal DCI but not in the down-drop DCI). By having a new DCI format with the same size as the existing DCI format, blind decoding complexity can remain the same. Note that its use is not limited to URLLC. Any use case requiring high PDCCH reliability and reasonable scheduling flexibility should be able to balance the new DCI format.

[0475] Another area for improved performance concerns the limitations on the number of blind decoders and CCEs. As discussed above, PDSCH / PUSCH mapping type B (micro-slots with flexible start positions) is a key enabling factor in URLLC use cases. To achieve the full latency benefits of type B scheduling, it is necessary to have multiple PDCCH monitoring scenarios within a slot. For example, to obtain the full benefits of two OFDM symbol transmissions, it is better to have PDCCH monitoring for every two OFDM symbols. In version 15, the limitation on the total number of blind decoders (BD) and non-overlapping CCEs for channel estimation in a slot strongly restricts scheduling options for these types of configurations, even when limiting the number of candidates in a search space.

[0476] The current limitations of 15 kHz SCS in NR are consistent with the limitations of 1 ms TTI in LTE, while these limitations are extended after the introduction of short TTI in LTE. It is expected that these Version 15 limitations, as shown in the first column of Tables 9 and 10, will be revised within the URLLC framework in NR Release 16. For example, with the current number of CCE limitations, if AL16 is used, there will be at most 3 transmission opportunities per time slot.

[0477] Instead of specifying multiple new UE capability levels, it proposes to specify support for an additional level for blind PDCCH decoding, doubling the number compared to version 15. For this additional level support, instead of defining it merely per slot, it makes more sense to consider how BD / CCE operations for micro-slots are distributed across a single slot. One possible option is to define BD / CCE limits for each half of a slot. For the first half of the slot, the same number as in other cases is naturally assumed. For the second half of the slot, assuming the UE has completed PDCCH processing in the first half, the UE should have the same PDCCH processing capability in the second half. Therefore, assuming the same number as in the first slot is reasonable.

[0478] Considering all the above, the corresponding increases in BD restrictions can be summarized in Table 16. Maximum number of PDCCH BDs per hour slot Subcarrier spacing 15kHz 30kHz 60kHz 120kHz NR version 15 44 36 twenty two 20 The proposed value in NR version 16 The first half of the time slot 44 36 twenty two 20 Halfway through the time slot 44 36 twenty two 20 Table 16 – Number of blind decodes in version 15 and proposed values ​​for version 16

[0479] Similarly, one of the CCE restrictions can be summarized in Table 17. Maximum number of PDCCH CCEs per hour slot Subcarrier spacing 15kHz 30kHz 60kHz 120kHz NR version 15 56 56 48 32 The proposed value in NR version 16 The first half of the time slot 56 56 48 32 Halfway through the time slot 56 56 48 32 Table 17 – CCE Limitations for Version 15 and Proposed Values ​​for Version 16.

[0480] As an alternative to one of Tables 16 and 17, a constraint may be introduced per sliding window, wherein the sliding window size and the number of blind decodings or CCEs per window may be further defined in the specification.

[0481] One consequence of the increased number of blind decoding and CCE restrictions is more PDCCH scenarios in a time slot, thus giving a UE a higher chance of being ultimately scheduled. Table 18 shows the PDCCH blocking probability after a specific number of PDCCH scenarios for a different number of UEs per cell. (DCI size = 40 bits, CORESET duration = 1 symbol.) Clearly, the PDCCH blocking probability in a time slot can be significantly reduced with more PDCCH scenarios. Blocking probability #UE = 10 #UE = 20 #UE = 30 #UE = 40 After 1 PDCCH scene 7.91% 39.03% 58.01% 68.46% After 2 PDCCH scenarios 0 1.42% 19.50% 37.75% After 3 PDCCH scenarios 0 0 0.17% 4.15% Table 18 – Probability of PDCCH blocking in a time slot for different numbers of UEs per cell with 1, 2, or 3 PDCCH scenarios.

[0482] Although limiting the PDCCH can improve alignment latency, reducing processing latency can also contribute to a reduction in total latency. Therefore, UE processing capabilities are addressed below.

[0483] Figure 58 illustrates the downlink data transmission timeline with a retransmission. Figure 59 illustrates the UL data transmission timeline with a retransmission for PUSCH via configured UL grant. Delay components: • TUE,proc: UE processing time for UL transmission. TUE,proc varies depending on DL and UL data, initial transmission and retransmission, etc. In the discussion of UE capabilities #1 and #2, variables N1 and N2 are used: o N1 is the number of OFDM symbols required from the end of PDSCH to the earliest possible start of UE processing for the corresponding ACK / NACK transmission on PUSCH or PUCCH, from the UE's perspective. o N2 is the number of OFDM symbols required from the end of PDCCH containing UL grant reception to the earliest possible start of UE processing for the corresponding PUSCH transmission, from the UE's perspective. • TUL,tx: UL data transmission time. This is approximately equal to the PUSCH duration. • TUL,align: Time alignment used to wait for the next UL transmission opportunity. • TgNB,proc: gNB processing time for DL ​​transmission. TgNB,proc varies depending on DL and UL data, initial transmission and retransmission, etc. For example, for PDSCH retransmission, this includes the processing time for the HARQ-ACK sent on the UL. For PUSCH, this includes the PUSCH reception time. • TDL,tx: DL data transmission time. This is approximately equal to the PDSCH duration. • TDL,align: Time alignment used to wait for the next DL transmission opportunity.

[0484] TUE,proc is an important latency component to be improved. In Release 15, UE processing time capabilities #1 and #2 have been defined, with capability #1 defined for SCS at 15 / 30 / 60 / 120 kHz and capability #2 defined for SCS at 15 / 30 / 60 kHz. The more aggressive capability #2 is still insufficient for the 1ms latency constraint. Since the latency requirement for eURLLC is approximately 1ms (e.g., 0.5ms), a new UE capability #3 can be defined in Release 16 NR to meet the latency requirement. The proposed UE capability #3 is summarized in Table 19. The impact of the proposed capability can be seen in Figures 60, 61, and 62. Figure 60 shows a comparison of downlink data latency between Release 15 and the new UE capability #3 shown in Table 19. Figure 61 shows a comparison of uplink data latency based on grant in Release 15 with one of the new UE capabilities #3. Figure 62 shows a comparison between configuration-granted uplink latency in version 15 and new UE capability #3. configuration HARQ timing 15 kHz SCS 30 kHz SCS 60 kHz SCS 120 kHz SCS Front-loaded DMRS only N1 2.5os 2.5os 5os 10os Frequency-First RE-Mapping N2 2.5os 2.5os 5os 10os Table 19 – UE Processing Time Capacity #3

[0485] The other delay component, TDL,align, is significantly affected by the PDCCH periodicity. In the worst case, TDL,align equals the PDCCH periodicity. In version 15, the PDCCH periodicity is affected by several constraints, including: (a) blind decoding constraints, (b) #CCE constraints, and (c) DCI size. To provide shorter PDCCH periodicity for eURLLC, it is necessary to relax the number of blind decoding constraints and CCE constraints in version 16.

[0486] Another important UE capability is related to the CSI report generation time. From a link adaptation perspective, the faster the UE can provide CSI reports, the more accurate the scheduling decision will be. Version 15 of the specification defines two key values: • Z corresponds to the timing requirement from the triggering of the PDCCH to the start of the PUSCH carrying the CSI report, and therefore should cover DCI decoding time, possible CSI-RS measurement time, CSI calculation time, UCI encoding time, and possible UCI multiplexing and UL-SCH multiplexing. • On the other hand, Z' corresponds to the timing requirement from the non-periodic CSI-RS (if used) to the start of the PUSCH carrying the report. The difference between Z and Z' is therefore only the DCI decoding time.

[0487] In version 15, there is no "advanced CSI processing capability," that is, only one baseline CSI processing capability that all UEs must support is defined. It was discussed that this advanced CSI processing capability would be included in version 15, but due to lack of time, this advanced CSI processing capability was not included. Version 15 of

[0488] defines three "latency categories" for CSI content: • Beam Reporting Category: L1-RSRP report with CRI / SSBRI • Low Latency CSI: Single broadband CSI report with up to 4 CSI-RS ports (no CRI report) defined using either Type I single-board codebook or non-PMI reporting mode • High Latency CSI: All other types of CSI content

[0489] For each of these three categories, define (according to CSI computation delay requirement 2) the different requirements for (Z, Z'). There is also a more stringent CSI requirement, namely CSI computation delay requirement 1, which applies only when the UE is triggered by a single low-latency CSI report in the absence of UL-SCH or UCI multiplexing and when all of the UE's CSI processing units are not occupied (i.e., they have not yet computed some other CSI reports).

[0490] In NR Release 15, mandatory UE CSI processing capability requires a UE to support the calculation of 5 simultaneous CSI reports (which can span different carriers, be on the same carrier, or be a single report with multiple CSI-RS resources). The value of (Z,Z') is CSI processing requirement 2, therefore CSI processing requirement 2 is determined so that all UEs should be able to calculate 5 CSI reports within this time period. When some UE implementations calculate multiple CSI reports serially, this means that, roughly speaking, CSI requirement 2 is about 5 times longer than the requirement in the case where only a single CSI report needs to be calculated.

[0491] In a typical URLLC scenario, and indeed in many typical deployments and scenarios, the gNB currently focuses on triggering only a single CSI report. Therefore, it is somewhat unfortunate that the timing requirements are 5 times longer than necessary in this scenario. This excessively long CSI calculation time imposes additional implementation limitations on the scheduler, as the N2 requirement for data triggering and the latency (K1) requirement for data to HARQ-ACK are far lower than the CSI processing requirements.

[0492] Further improvements are possible. To enhance the CSI processing timeline of eURLLC, a new CSI timing requirement ("CSI operation delay requirement 3") is introduced, which is beneficial for sporadic traffic to quickly obtain channel status at gNb. This new CSI timing requirement can be requested when the UE is triggered by a single CSI report. The initial position can be the value defined by CSI timing requirement 2 and divided by a factor of 5. Another possible enhancement to the CSI processing timeline is the introduction of an advanced CSI processing capability. That is, a new set of tables is introduced for the two existing CSI timing requirements (and the newly proposed third timing requirement). Then, a UE can indicate support for a more advanced CSI timeline in its capabilities, similar to the advanced processing capabilities of PDSCH / PUSCH.

[0493] Rapid HARQ is another improvement. Faster processing and UE capabilities, discussed in previous chapters, enable faster HARQ retransmission. It is assumed that the gNB can operate at a similar processing speed to the UE. To operate alongside HARQ retransmission while maintaining low latency, frequent PDCCH monitoring scenarios and PUCCH scenarios capable of transmitting HARQ-ACK are required. For simplicity, zero timing advance will be assumed, but this is not actually possible. In cases of non-zero timing advance, the latency value can change.

[0494] Here we can focus on the comparison between version 15 and version 16. The evaluation results are presented below. Regarding capability #2 of version 15, it is assumed that one of the five OFDM symbols (os) of the PDCCH is periodic. Note that with a CCE limit of 56 per time slot, up to three PDCCH monitoring scenarios are allowed per time slot, each containing at least one AL16 candidate. Regarding version 16, since the limitations on blind decoding and the number of CCEs may be improved, it is assumed that the values ​​of N1 and N2 (capability #3 discussed in previous sections) are improved and the PDCCH periodicity is two symbols.

[0495] Another improvement to UE preemption. Dynamic multi-site service provisioning is highly desirable for efficient use of system resources and maximizing their capacity. In the downlink, resource allocation can be transient and limited only by the scheduler implementation, while in the uplink, a standard-specific solution is required. The existing solution in version 15 and the additional solution in version 16 are discussed below.

[0496] It is highly desirable to dynamically multiply different services across multiple sites to efficiently utilize system resources and maximize their capacity. In the downlink, resource allocation can be transient and is limited only by the scheduler implementation. Once low-latency data appears in a buffer, a base station should select the fastest time when resources can be allocated normally (i.e., without conflict with resources already allocated for one of the UE's ongoing downlink transmissions). This can be the beginning of a time slot or a minimum time slot, which can begin at any OFDM symbol. Therefore, downlink preemption can occur when long-term allocations (e.g., time slot-based) occupy resources (specifically broadband resources) and there is no space for critical data transmissions that can normally be performed via the minimum time slot. In this case, a scheduler can send DCI to the critical data UE and change control of ongoing downlink transmissions. When time slot eMBB transmissions take priority, the priority portion of the original message occupies the soft buffer and should be cleared for good retransmission performance, which may occur. The NR version 15 specification allows preemption to be indicated by explicit messaging, which is implemented in the following ways: • Option 1. By using a special DCI format 2_1 based on a group-shared PDCCH, or; • Option 2. By using a special flag in the "CBG Clear Message" of the DCI retransmitted by multiple CBGs.

[0497] Option 1 provides an indication as a 14-bit dot matrix, addressed to the reference downlink resource field between two preemption indication messages. The highest time resolution of this message is one OFDM symbol and the highest frequency resolution is half of the BWP (bandwidth portion), but not both simultaneously. The longer the message periodicity, the coarser the resolution. Because this is a group-shared message, all UEs within the BWP can read it.

[0498] Option 2 is a user-specific communication method. A HARQ retransmission DCI containing a set of CB / CBGs may have a special bit to instruct the UE to first clear the relevant portion of the soft buffer and then store the retransmitted CB / CBGs in the soft buffer.

[0499] During the 3GPP discussion of Release 15 URLLC, the scope of the uplink preemption feature was narrowed due to insufficient time in the 3GPP URLLC work item. However, this feature is included in the discussion of Release 16. UL preemption can occur in the event that a longer eMBB UL transmission is interrupted by an urgent URLLC UL transmission. Furthermore, it can have two advantages: • Intra-UE preemption, where both transmissions belong to the same UE. Intra-UE preemption is similar to DL preemption, where the UE takes precedence over the gNB for transmissions in the UL direction. Therefore, the gNB needs some type of indication to introduce a URLLC transmission to replace the eMBB transmission. • Inter-UE multiplexing, where the gNB needs to provide resources to accommodate transmissions as quickly as possible to meet latency requirements based on requests from some UEs for urgent transmissions of high-priority UL traffic (URLLC traffic). It is possible that the gNB has assigned suitable UL resources to one or more other UEs for UL transmissions with less stringent latency requirements (eMBB traffic). Therefore, the gNB needs to reschedule those resources for priority URLLC transmissions. The following discussion further addresses UE-in-service preemption, as it implies a MAC mechanism, while the second option has a clearly defined entity layer scope.

[0500] Given that the two enable mechanisms based on power control and mute will achieve preemption at the following cost: 1) additional communication and complexity at both the UE and gNB due to ongoing or planned changes to UL transmissions; and 2) impact on eMBB service performance. It is important to adopt one of the mechanisms that best ensures the required quality of URLLC transmission in order to justify the investment. Figure 63 illustrates both approaches.

[0501] One drawback of power-controlled schemes is that URLLC transmissions are susceptible to interference from transmissions controlled by the serving gNB, which may have already been de-prioritized. Furthermore, increasing the power of URLLC transmissions not only increases interference from neighboring cells but also impacts eMBB service performance. Therefore, in a preemptive scheme, by canceling ongoing or pre-scheduled eMBB UL transmissions based on suitable resources prepared by the gNB for URLLC transmissions, the gNB can at least avoid potential degradation in URLLC service performance due to its own interference. It should be noted that this discussion concerns PUSCH transmissions, where other options are more suitable for reliability control. For PUCCH, the options are more limited.

[0502] When time-slot-based eMBB transmission interferes with small URLLC, Figure 64 demonstrates the performance of a power control-based solution for a 4GHz TDL-C with a DS of 100ns, a 4x2 antenna configuration, and an MMSE-MRC receiver. Low SE MC stability is in use.

[0503] Based on the above discussion, the indication-based solution can ensure URLLC reliability, while the power control-based solution can be regarded as a backward compatible solution in the interaction scenario of version 15 / 16. However, the former comes with a huge communication cost.

[0504] This means that although the UL preemption indication actually functions in a UE-specific manner, a better design option is to consider a group-shared UL preemption indication that can flexibly adjust the group size from a single UE to multiple UEs as needed, depending on the scenario. This approach preserves the characteristics of the single-UE scenario while reducing additional communication overhead and preventing the probability of multiple UEs requiring preemption.

[0505] In order to reuse existing mechanisms, when possible, the following two options should be considered for group sharing of UL preemption: • Option 1: UL preemption indication based on DCI format 2_0 (Dynamic SFI) • Option 2: UL preemption indication design similar to DCI format 2_1 (DL preemption indication)

[0506] Option 1 proposes using an existing dynamic SFI and defining a new (or extended) UE behavior as follows: When a UE detects that a flexible (or DL) signal has been assigned by one of the symbols in the UE-specific communication schedule used for UL transmission, the UE completely cancels the UL transmission. This design choice is based on two assumptions: for the purpose of UL preemption, 1) the dynamic SFI changes control the UE-specific communication; and 2) the preempted UL transmission is not delayed and reused but simply canceled. Since only the UL transmission needs to be canceled, this method is simple and requires less processing time at the UE. However, a new behavior needs to be defined, which is based on the assumption that a later SFI changes control a previous UE-specific DCI, which itself contradicts the design principles used in Release 15. Furthermore, relying on the existing SFI for simplicity means that the SFI table specified in Release 15 should be used. A careful examination of the entries in this table reveals limitations on the UL transmission cancellation that can occur compared to a bitmap pattern that provides full flexibility.

[0507] In Option 2, a DL preemption mechanism can be adopted for UL preemption indication. This method allows a gNB to indicate to a UE, with finer granularity, which resources need to be preempted using a dot matrix pattern. The flexibility of this mechanism lies in how UE behavior is defined or in its capabilities; a dot matrix pattern can be used to indicate when UL transmission should be stopped without subsequently restarting. Alternatively, if the UE is able to perform this operation within a reasonable time, a dot matrix pattern can be used to indicate to the UE when to stop and then restart UL transmission.

[0508] Lower MCS and CQI for lower BLER targets are additional issues. Based on the assessment presented above, it can be observed that only one radio transmission time is needed to meet the latency requirements of a URLLC. In this case, an air interface must be able to guarantee the extremely low BLER required for URLLC service. For this purpose, several enhancements have been made in version 15: • A new 64QAM CQI table has been introduced to report at a target BLER of 10^-5. This new table contains lower spectral efficiency (SE) values. • Low spectral efficiency 64QAM MC stabilization has been introduced for use without changing the precoding. • Low spectral efficiency 64QAM MC stabilization has been introduced for DFT extended OFDM waveform tables.

[0509] As an example, consider a TBS of 256 bits (= 32 bytes), a transmission duration of 4 OFDM symbols, and an additional overhead of 1 DMRS symbol. Figure 65 shows the PDSCH BLERs for different MCSs supported within a 40 MHz BW. Here, the coding rate of MCS 6 corresponds to the coding rate of MCS 0 in the old 64QAM table.

[0510] The network can semi-statically configure highlighted MC stability via RRC. In addition to the conventional C-RNTI, dynamic communication for MC stability can also be supported by configuring the UE with MCS-C-RNTI, where the MCS-C-RNTI is always associated with low SE MC stability. When the UE detects MCS-C-RNTI scrambling by PDCCH CRC, the UE always applies low SE MC stability; otherwise, it semi-statically applies the configured MC stability (64QAM or 256QAM). As another option, when the UE only has URLLC traffic, MC stability can be configured semi-statically; however, in cases where the UE can perform both eMBB and URLLC simultaneously, the dynamic approach is preferable. One drawback of dynamic MCS-table communication is that the introduction of the new MCS-C-RNTI leads to a higher PDCCH CRC false alarm rate.

[0511] It must be noted that CQI and MC stability can be configured independently. For example, the old 64QAM MC stability can be used with the new 64QAM CQI Table 10^-5 BLER report.

[0512] Multi-antenna technology presents another problem. It is known that there is a trade-off between increasing data rate (multiplexing) and increasing reliability (diversity). This means that an increase in one will inevitably come at the cost of a certain degree of degradation in the other. In mobile broadband, MIMO technology is typically used to increase data rate and network spectral efficiency. On the other hand, in URLLC, the degrees of freedom provided by MIMO can be used to increase reliability. Therefore, instead of using throughput as the optimization metric, the network can optimize reliability metrics (e.g., probability of outage). For example, UL performance can be improved using UL precoding and in-site UL CoMP (joint reception) as shown in Figure 66. Figure 66 shows the UL SINR of different multi-antenna technologies with and without UL CoMP (3-sector in-site joint reception) and UL precoding (Rel-10 level 14-port precoder). For "uncoded," a single antenna is used for transmission, while for "precoded," a 4-antenna element (1x2 X-pol, distance = 0.5λ) is used.

[0513] Cyclic delay diversity (CDD) or space-time coding can also be considered to provide additional frequency diversity in a spectrally transparent manner. Multiple receive antennas provide receive diversity and provide a means to maximize the received signal-to-interference-to-noise ratio (SINR) after receive combination at the receiver. Diversity schemes have the advantage of requiring less channel knowledge than precoding schemes.

[0514] Multiple antenna elements can also be used to establish directional antennas on the transmitter side and / or receiver side to increase the received SINR and thus increase reliability. Obviously, providing an improved SINR ensures that the beam is pointed in the correct direction, and therefore beamforming requires at least some channel knowledge to determine the correct direction of the beam.

[0515] L2 characteristics

[0516] This section describes the Layer 2 features in the RAN to support URLLC deployment. While several features for LTE and NR have been introduced for Release 15 to provide basic URLLC support, current research on the Release 16 standard seeks enhancements to improve system efficiency when providing URLLC, particularly when supporting TSN integration (i.e., supporting multiple traffic flows with different QoS requirements). It is assumed here that not only should non-critical traffic be transmitted efficiently, but other critical traffic flows should be served with a decisive latency. In a TSN scenario, these traffic flows are typically periodic, but not necessarily. Typically, the following scenario is addressed: it is impossible to infer when, at what size, and in what pattern / period, a traffic arrives at the gNB or UE. The Release 15 baseline and enhancements are examined in the following sections regarding SR and BSR, cyclic traffic pre-scheduling, UE multiplexing, and PDCP replication.

[0517] It should be noted that L2 features are generally independent of whether FDD or TDD is used.

[0518] Buffer Status Report (BSR) and Schedule Request (SR) are two methods that a UE can use to indicate that data is available in the transmission buffer. These indications allow the network to grant an award (i.e., UL-SCH resource) to the UE to allow data transmission. This is often referred to as dynamic scheduling. Figure 67 shows an example of SR and BSR operation.

[0519] In short, one of the main differences between SR and BSR is that SR is a 1-bit indication in PUCCH that the UE has data to transmit, while BSR explicitly provides an approximation of the amount of data in its buffer on a per logical channel group basis. BSR is transmitted in a MAC control element (CE), while MAC control elements are transmitted in PUSCH.

[0520] In NR Release 15, an SR configuration can be configured for each logical channel, and multiple logical channels can be configured with the same SR configuration. SRs are transmitted in PUCCH. Within a bandwidth portion (BWP), an SR can be configured with at most one PUCCH resource. This means that in NR, a network can be configured with multiple SR configurations, which can potentially be used for different types of traffic. The procedure can be summarized as follows: • Data arrives from a specific logical channel. • If the triggering criteria are met, a regular BSR is triggered due to arrival. • There are no PUSCH resources available for transmitting the BSR. • An SR is triggered and transmitted in the SR resource associated with the logical channel that triggered the BSR.

[0521] Dynamic scheduling introduces a delay into data transmission, as shown in Figure 67. This delay depends on the periodicity / offset of the SR configuration and the time spent allocating network resources and transmitting grants.

[0522] Certain industrial IoT services and communications may require strict latency requirements. Therefore, the "multiple SR configurations" specified in version 15 is a feature that plays an important role in ensuring service differentiation and meeting latency requirements. Figure 68 illustrates an example showing multiple SR configurations mapped to different services.

[0523] As per regulations, the UE transmits a Buffer Status Report (BSR) in the PUSCH. The BSR is transmitted in the MAC PDU as a MAC control element. The purpose of the BSR is to indicate the approximate amount of data in the buffer. This report is based on Logical Channel Groups (LCGs). Each logical channel is associated with one LCG. There are 8 LCGs. In scenarios where differentiation is required within a limited set of Traffic Profiles (DRBs), the number of LCGs is sufficient to provide a one-to-one mapping between logical channels and LCGs.

[0524] There are four different BSR formats, and depending on the selected format, the UE may be able to indicate the buffer status of one or more logical channel groups.

[0525] A BSR can be triggered by one of the following mechanisms: • Regular BSR: A regular BSR is triggered when new UL data is received for transmission on a logical channel belonging to a specific LCG. Additionally, this new data must meet one of the following two conditions: the new data belongs to a logical channel with a higher priority than any of the other logical channels that have data; or, no other data is available for LCG transmission in any logical channel. If more data is received in another specific logical channel and that channel already has data in its buffer, a regular BSR will never be triggered. A regular BSR can use only the short BSR format and the long BSR format. • Periodic BSR: A periodic BSR is triggered periodicall...

Claims

1. A method comprising a first device for assisting in registering a second device with an Internet of Things (IoT) environment and using the second device, the method comprising: Obtain a representation of a registration function associated with the second device, wherein the registration function is associated with at least one serialized registration application, the at least one serialized registration application including registration information associated with the first device and the second device; Deserialize the registration application such that the registration information associated with the first device and the registration information associated with the second device are separated; Transmit the registration information associated with the second device to the second device to initiate the second device's registration processing procedure by configuring the second device based on the registration information associated with the second device; Receive configuration information associated with the second device from the second device; A code module is transmitted to a second runtime environment executed on the second device using a first runtime environment executed on the first device, wherein the code module is configured to execute in the second runtime environment and expose to the first device a function of the second device supported by the second runtime environment; and an application is executed in the first runtime environment, which remotely invokes the function of the second device via the transmitted code module and the second runtime environment.

2. The method of claim 1, wherein the second device is an Internet of Things (IoT) device, and wherein the first device is a wireless communication device.

3. The method of request item 1 or 2, wherein the representation of the registration function is one or more of a QR code, a barcode, and an RF-ID chip.

4. The method of request item 1 or 2, wherein the registration information associated with the second device includes at least one of a public encryption key, software system, capabilities, steps related to the registration process, and functions of the IoT environment.

5. The method of request item 1 or 2, wherein the registration information includes information associated with one or more of the following: geographic location, organizational location, ownership, encryption key, communication parameters, communication key, and identity.

6. The method of request item 1 or 2, wherein the registration function includes at least two serialized registration applications, the method further comprising: The at least two serialized registration applications are deserialized into at least one registration application including registration information associated with the first device and at least one registration application including registration information associated with the second device; and the at least one registration application associated with the second device is transmitted to the second device.

7. The method of claim 1 or 2, further comprising: The registration of the second device has been successfully completed. And terminate the at least one registered application on the first device.

8. The method of claim 1 or 2, further comprising having the first runtime environment authenticated by the second runtime environment to obtain authorization to transfer the code module to the second runtime environment for execution within the second runtime environment.

9. The method of claim 1 or 2, further comprising directly communicating with the second runtime environment to invoke a different function of the second device.

10. The method of claim 1 or 2, wherein the transmission of the code module to the second runtime environment is performed via a wireless peer-to-peer connection between the first device and the second device.

11. The method of claim 1 or 2, wherein the second device is an electronic lock, and the function supported by the second operating environment locks or unlocks the electronic lock.

12. A method for a second device to perform a registration process assisted by a first device to an Internet of Things (IoT) environment and to provide the first device with access to the functionality of the second device, the method comprising: The first device receives registration information associated with the second device; The registration process is executed by configuring the second device based on the registration information; the configuration information associated with the second device is transmitted to the first device; a code module is received from a first runtime environment executing on the first device to a second runtime environment executing on the second device to expose a function of the second device supported by the second runtime environment to the first device; and the second runtime environment is used to control the execution of the function in response to a remote call to the function of the second device received by an application executing within the first runtime environment via the code module.

13. The method of claim 12, further comprising: If the registration is deemed successful, the registration information is deleted from the second device.

14. The method of request item 12 or 13, wherein the registration information associated with the second device is unknown to the second device.

15. The method of claim 12 or 13, wherein the registration information associated with the second device includes at least one of a public encryption key, software system, capabilities, steps related to the registration process, and functions of the IoT environment.

16. The method of claim 12 or 13, further comprising having the first runtime environment authenticated by the second runtime environment to authorize the transfer of the code module to the second runtime environment for execution within the second runtime environment.

17. The method of claim 12 or 13, further comprising using the second runtime environment to control the execution of different functions of the second device in response to direct communication from the first device to the second runtime environment.

18. The method of claim 12 or 13, wherein the transmission of the code module from the first runtime environment is performed via a wireless peer-to-peer connection between the first device and the second device.

19. The method of claim 12 or 13, wherein the second device is an electronic lock, and the function supported by the first operating time environment locks or unlocks the electronic lock.

20. A first apparatus for assisting in registering a second device with and using the second device in an Internet of Things (IoT) environment, the first apparatus being adapted to: obtain a representation of a registration function associated with the second device, wherein the registration function is associated with at least one serialized registration application, the at least one serialized registration application including registration information associated with the first device and the second device; deserialize the registration application such that the registration information associated with the first device and the registration information associated with the second device are separated; transmit the registration information associated with the second device to the second device to initiate the second device's registration processing procedure by configuring the second device based on the registration information associated with the second device; and receive configuration information associated with the second device from the second device. A code module is transmitted to a second runtime environment executed on the second device using a first runtime environment executed on the first device, wherein the code module is configured to execute in the second runtime environment and expose to the first device a function of the second device supported by the second runtime environment; and an application is executed in the first runtime environment, which remotely invokes the function of the second device via the transmitted code module and the second runtime environment.

21. The first device of claim 20, wherein the second device is an Internet of Things (IoT) device, and wherein the first device is a wireless communication device.

22. The first device as requested in item 20 or 21, wherein the representation of the registration function is one or more of a QR code, a barcode, and an RF-ID chip.

23. A second device for executing a registration process assisted by a first device to a Internet of Things (IoT) environment and providing the first device with access to a function of the second device, the second device being adapted to: receive registration information associated with the second device from the first device; execute the registration process by configuring the second device based on the registration information; transmit configuration information associated with the second device to the first device; receive a code module from a first runtime environment executing on the first device to a second runtime environment executing on the second device to expose a function of the second device supported by the second runtime environment to the first device; and control the execution of the function using the second runtime environment in response to a remote call to the function of the second device received by an application executing within the first runtime environment via the code module.

24. The second device, as requested in item 23, is further adapted to: determine that the registration is successful and delete the registration information from the second device.

25. The second device as requested in item 23 or 24, wherein the registration information associated with the second device is unknown to the second device.

26. The second device as requested in claim 23 or 24, wherein the registration information associated with the second device includes at least one of a public encryption key, software system, capabilities, steps related to the registration process, and functions of the IoT environment.

27. A first device for assisting in registering a second device with an Internet of Things (IoT) environment and using the second device, the first device comprising: A communication circuit system configured to communicate with the second device; and a processing circuit system operatively coupled to the communication interface circuit system and configured to control the transceiver circuit system and perform the following operations: obtaining a representation of a registration function associated with the second device, wherein the registration function is associated with at least one serialized registration application, the at least one serialized registration application including registration information associated with the first device and the second device; deserializing the registration application such that the registration information associated with the first device and the registration information associated with the second device are separated; transmitting the registration information associated with the second device to the second device to initiate the second device's registration processing procedure by configuring the second device based on the registration information associated with the second device; and receiving configuration information associated with the second device from the second device. A code module is transmitted to a second runtime environment executed on the second device using a first runtime environment executed on the first device, wherein the code module is configured to execute in the second runtime environment and expose to the first device a function of the second device supported by the second runtime environment; and an application is executed in the first runtime environment, which remotely invokes the function of the second device via the transmitted code module and the second runtime environment.

28. The first apparatus of claim 27, wherein the processing circuitry is configured to perform any one of claims 2 to 11.

29. A second device for performing a registration process assisted by a first device to an Internet of Things (IoT) environment and providing the first device with access to a function of the second device, the second device comprising: A communication circuit system configured to communicate with the second device; The transceiver circuitry is operatively coupled to and configured to control the transceiver circuitry and perform the following operations: receiving registration information associated with the second device from the first device; executing the registration processing procedure by configuring the second device based on the registration information; transmitting configuration information associated with the second device to the first device; receiving a code module from a first runtime environment executing on the first device to a second runtime environment executing on the second device to expose a function of the second device supported by the second runtime environment to the first device; and using the second runtime environment to control the execution of the function in response to a remote call to the function of the second device received by an application executing within the first runtime environment via the code module.

30. The second apparatus of claim 29, wherein the processing circuitry is configured to perform the method of any one of claims 13 to 19.

31. A computer program product comprising program instructions executed by a wireless device, the program instructions being configured to cause the wireless device to perform any one of claims 1 to 19.

32. A non-transitory computer-readable medium comprising a computer program product, as claimed in claim 31, stored thereon.

Images