How Device-to-Device Communication can be used to Support an Industrial Mobile Network Infrastructure

. With the increasing number of sensors and other connected devices in industrial settings like factories or warehouses requiring reliable, low latency communication and mobility, alternatives to current standards have to be considered. In this paper, we investigate how Device-to-Device communication can be used to support an industrial mobile communication infrastructure. We consider a number of possible applications and discuss requirements and potential issues. We focus on the handover from a direct connection to a relay connection and examine whether that is a viable approach to enhancing wireless coverage for mobile wireless machines like automated guided vehicles. Proposed approaches to relay switching exist, but have not been experimentally validated. In this paper, we compare the X2 based handover with the PC5 based path switch procedure and evaluate the expected performance with respect to latency through simulations.


Introduction
Currently, 5G is starting to be implemented for real world applications. With 3GPP Release 15, the first version of the 5G standard is posed to be released by 2019. One of the key issues being researched right now is therefore how to successfully integrate the new technology into the existing infrastructure. Especially in industry scenarios, where expensive hardware is expected to be used for 15-20 years, it is usually not feasible to replace the existing infrastructure. Similarly, extending existing infrastructure by, for example, adding new base stations is also very expensive. A promising approach is to use LTE Deviceto-Device (D2D) communication to support existing networks, as it is part of the ongoing 3GPP 5G standardization efforts [HAL18]. D2D enabled devices can communicate with each other without the need for base station support, allowing new applications in industrial settings without the need for extensive infrastructure investments. Therefore, in this paper, we investigate applications where we can use D2D communication to support an already present mobile network infrastructure.

Related Works
The research area of D2D communication can be roughly divided into three general topics. The first topic is D2D communication as a means to support the vehicle-toeverything infrastructure. First and foremost, this means Cellular Vehicle-to-Everything (C-V2X), introduced by 3GPP as part of Release 14 [3GP18e]. This has been shown to be a promising approach [OKTMT + 17]. Aside from work on C-V2X itself, there are general connectivity issues related to the high speeds and irregular User Equipment (UE) distributions in vehicular communication that are being investigated. Both [JL17] and [ZYX + 17] propose D2D multihop architectures for vehicular communication networks in order to increase the effective communication range of the roadside infrastructure. The focus of [JL17] is on routing, while [ZYX + 17] proposes a joint relay selection and spectrum allocation algorithm. A related approach is described in [AEST + 15], where a handover to D2D communication is proposed to provide connectivity while a vehicle is out of range for V2V communications. Given the greater range of LTE-Direct transmission, the vehicle can stay connected until the next set of connected vehicles is reached and V2V communication is reestablished. The second topic is aiming to enhance mobile coverage and spectrum efficiency through offloading mobile communication and services to the unlicensed spectrum when possible. [AWM13] gives an overview of these D2D applications in cellular networks. One of the major issues with this is handling the interference in the unlicensed band. While LTE uses scheduling based access, Wi-Fi is contention based. Both [ZLS17] and [BH17] propose approaches to allocate resources fairly to all participants. The third topic is about the technology necessary to enable automation in industrial settings. In [LY18], an ultra-reliable and low latency communications (URLLC) protocol for D2D communication in industrial automation applications is proposed. Similarly, [MA18] also considers D2D for URLLC applications. They introduce cooperation into D2D communication and evaluate their proposed scheme on a Software Defined Radio (SDR) testbed in a factory hall. The authors of [WCI + 18] integrate D2D communication capabilities into their information interaction model for dynamic resource management for the Industrial Internet of Things (IIoT).

Approach
In this paper, we consider where and how the different aspects of the D2D technology can be used to improve an existing industrial mobile network infrastructure. For this, we look at several possible applications for D2D communication in a factory setting. Part of this work is then assessing the conceptual validity of the proposed example applications. In section 2, a short introduction to the considered scenario is given. As part of this scenario, we consider possible applications as examples of how D2D technology can be used to improve industrial mobile network infrastructures. In section 3, we examine a handover between a direct link and a D2D relay link and where that can be successfully applied in the scenarios we considered beforehand. The paper ends with a short conclusion in section 4.

Scenario
We consider a factory setting where communication is handled by a mobile network infrastructure. In this scenario, representative applications for D2D communication are examined. These applications are chosen according to the requirements they impose on the infrastructure. D2D communication refers to the direct communication of devices without the involvement of the network infrastructure. Depending on the device, application, and used technology, either the licensed or unlicensed spectrum is used. Here, we consider an industrial factory setting, where the mobile network infrastructure is expected to be private and operating in the unlicensed spectrum. D2D communication can be used with different communication technologies in the unlicensed frequency bands. These are usually either based on the Wi-Fi or LTE technologies. For Wi-Fi, there is for example the Wi-Fi Direct technology [CMGSS], where the Wi-Fi Direct device itself acts as an access point. This allows the device to directly communicate with other Wi-Fi devices, without the need for a "real" access point. For LTE, there is LTE-License Assisted Access (LTE-LAA) [3GP15a], which is based on LTE-Unlicensed but incorporates Listen-Before-Talk in order to comply with requirements for unlicensed spectrum usage. However, contention with Wi-Fi is still a problem for LTE-LAA. LTE Wi-Fi Link Aggregation (LWA) [3GP18e] aims to solve that issue by using the Wi-Fi protocol to transmit LTE traffic in the unlicensed spectrum band. Here, we will only consider LTE based D2D communication (LTE-D2D) due to its integration into 5G and the resulting relevance for future communication infrastructures [HAL18]. The three core functionalities of LTE-D2D are provided by the Proximity Services (ProSe), specified in TS 23.303 [3GP18d]. These functionalities are the "direct communication", "direct discovery", and "synchronization". They enable the devices to find other D2D capable devices in the vicinity, establish a communication link, and transceive messages. For this, three basic scenarios are considered. The first is in-coverage, where both devices are covered by the network infrastructure. The second is out-of-coverage, where neither device is covered by the network infrastructure. The third is partial coverage, where one device is in-coverage and the other is out-of-coverage. These three cases mainly differ by the networks ability to manage the D2D communication. Without network management, the devices have to use predefined resources for their communication.
The "direct discovery" functionality of the ProSe has two modes of operation. In Model A, the UE announces its services publicly, for any nearby UE to discover. In Model B, the UE uses a request/response process to relay information to a requesting UE in proximity.

Automated services without coverage
The first application example we consider is use of ProSe's "direct discovery" by a local system to provide a service that is relevant only to UEs in proximity. The advantage here is that these systems do not need to be covered by the communication infrastructure. This results in reduced cost both due to needing less communication infrastructure and the existing infrastructure having to serve fewer participants. The Model A version of the ProSe's "direct discovery" can be used by a local system with a function that is relevant to every mobile UE or user in proximity. An example would be an automated guided vehicle (AGV) driving around the factory. At the edge of the communication infrastructure coverage, the AGV could provide a wireless communication link to the communication infrastructure via relay. This relay link can be used by UEs to send information where regular updates are not important enough to warrant a dedicated link, but can be send opportunistically whenever an AGV is close by. The Model B version can be used by a local system with a function that is relevant to only select mobile UEs or users in proximity. For example a maintenance worker using his tablet to receive relevant information while on-site. If the information is not needed for general operation, making it available on the network infrastructure is unnecessarily expensive. A Model B D2D communication link can make the information locally available on-demand without taxing the whole communication infrastructure. From a feasibility point of view, these applications are unlikely to pose any issues since they uncritical for safety or production.

Extended connectivity outside coverage
For the second application example, we consider an autonomous forklift driving around the factory, inside and outside the building. For the operation of this automated vehicle, a reliable connection to the communication infrastructure is necessary. The communication infrastructure might not always be able to provide the necessary connection. For example, if the forklift leaves the coverage range of the factory's wireless network. Or the pathway is obstructed to such a degree by machinery or stored parts that the received signal strength is insufficient. In those cases, to be able to continue operations, an alternative connection is necessary. One possible approach to this issue is a direct D2D connection. Similar use cases are discussed in the 3GPP study TR 22.804 [3GP18a].
According to TR 22.804 [3GP18a], the movement speed of an automated forklift is <14 m/s. This is significantly slower than the normal speed of vehicles on roads and allows for more lax requirements on the latency. Even the relative speed of two vehicles would not exceed 28 m/s in this scenario. Regarding the distance coverage, the 300 m achievable with typical UE transmission power (23 dBm) suffice to facilitate inter-vehicle communication, for example for collision detection or status updates. For fully automated operations, assuming the control is handled in the edge cloud, a constant connection to the network infrastructure is required. In order for a D2D connection to allow for continuous operation, the handover procedure from network infrastructure to direct communication link has to be shorter than the maximum allowed downtime for the communication link.
Regarding the data transfer, the necessary control communication to allow automated operations can be assumed to require data rates in the kbit/s to Mbit/s range and is therefore within the capabilities of a D2D communication link.

Low latency communication and synchronization
In the production of steel girders, the heavy and still hot girders get transported by autonomously operating vehicles. Due to the size of the girders, transportation on a single vehicle is inconvenient and instead two or more vehicles work together for transportation. This, however, means that the vehicles need very strict synchronization, imposing very stringent requirements on the communication infrastructure. Aside from the low latency required to allow autonomous driving, communication has to be uninterrupted even when handovers are necessary. Due to the length of the steel girders, this usually means one vehicle initiating a handover before the other. Despite this, synchronicity has to be upheld. To keep the vehicles synchronized, a D2D communication link between them can be used. Due to the nature of this application, common issues in industrial V2V communication can be ignored. While transporting a steel girder, the distance between vehicles is fixed. Similarly, line of sight is always guaranteed. Thus, the communication between vehicles is independent of external infrastructure coverage and handovers. However, synchronization between the vehicles aside, they still need a constant communication link to the local infrastructure to allow autonomous operation. For this, low latency communication and seamless handovers are necessary. Seamless handovers are especially relevant in industrial settings due the nature of the environment. Factories usually have a lot of heavy equipment and machinery that is mostly metal and thus heavily impacts connectivity. This necessitates frequent handovers to different base stations or D2D-capable UEs.

Handover Comparison
A core issue with automated vehicles is a continuous communication link to allow uninterrupted operation. However, a factory usually has very difficult radio propagation conditions: Many machines, mostly metal, rarely line-of-sight. Due to this, a mobile UE is forced to frequently change its access point, requiring frequent handovers. When considering D2D communication to extend the infrastructure coverage to facilitate the continuous operation of AGVs, the relevant handover procedure to consider is the PC5 Path Switch from the 3GPP study TR 36.746 [3GP18c]. The document describes the switch from a direct connection between the ProSe Remote UE and the eNB, to a relay link between the ProSe Remote UE, a ProSe UE-to-Network Relay UE, and the eNB. However, the PC5 Path Switch handover in D2D communication is not yet standardized. The seamless handover process is also an ongoing topic in the 5G standardization. In TR 23.725 [3GP18b], a possible solution is proposed. During handover, the UPF sends downlink data to both the source and target RAN nodes. The data is cached at the target RAN node until the data radio bearer is established, at which time the cached data will be transmitted. Thus, continuous communication can be achieved. However, the focus here lies in continuous operation of an existing D2D communication link. For D2D-based autonomous vehicle operation, it is also necessary to allow for seamless handover between D2D communication partners, or from D2D connection to infrastructure connection. In order to be able to assess whether a switch to a D2D communication link is a viable approach to the considered scenarios, it is necessary to know how long the switching takes. Since the procedure is not yet finalized, we can only make an estimate based on what we know. For this, we look at the X2 based handover and the PC5 based Path Switch. From the similarities between both procedures, we try to estimate the PC5 based Path Switch duration. Figure 1 shows the process of an X2 based handover, an intra-RAT handover between two eNBs described in TS 36.300 [3GP18e]. The handover can be broadly divided into four parts. First is the handover decision (1-3). The UE collects measurements about the connection quality and reports them to the source eNB. Based on these measurements the source eNB decides whether to initiate a handover to another eNB. Once that decision is made, the second part begins: the handover preparation (4-6). The source eNB sends a handover request to the target eNB and, upon receive the acknowledgement, forwards relevant information about the target eNB to the UE. In the third part, the handover execution (7-11), the source eNB sends relevant information about the UE to the target eNB. The target eNB and UE exchange information for synchronization and resource allocation. The UE connects to the target eNB, completing the handover from the UE side. In the fourth part, the handover completion (12-18), the target eNB informs the Mobility Management Entity (MME) and Serving Gateway about the handover so that communication paths can be adjusted. The handover ends with the release of the resources for the UE by the source eNB. 3.2 PC5 based Path Switch Figure 2 shows the process of a PC5 based handover, a path switch between a direct link and a relay link described in TR 36.746 [3GP18c]. The handover decision happens similarly as in the X2 based handover, though it is not shown in the Figure 2. Steps (2-9) depict the establishing of a relay link, whereas steps (10-14) show the switch from a relay link to a direct link. While it is not shown in Figure 2, the path switch decision is made based on measurements made by the UE and reported to the eNB, similar to the X2 based handover. For the Path Switch from direct to relay link (2-9), first the remote UE and the relay UE directly connect via the PC5 interface (2). After the connection is established, the relay UE forwards the RRC connection request/setup/confirmation messages between the remote UE and the eNB (3). The eNB then informs both UE's MMEs about the relay relationship (4-6). Afterwards, the eNB triggers the RRC reconfiguration of both the remote and relay UEs (7-8). The switch to a relay link finishes with the eNB confirming the context change to the remote UE MME (9). For the Path Switch from relay to direct link (10-14), the eNB sends the RRC reconfiguration message both to the Remote UE and the Relay UE (11-12). After receiving the RRC reconfiguration confirmation message, the eNB sends messages to the MMEs of both UEs, informing them of the changed relationship between the Remote UE and Relay UE (13-14). With this, the path switch process is finished. Fig. 2. PC5 based Path Switch according to [3GP18c]

X2 -PC5 Comparison
The reason for choosing the X2 based handover to compare to the PC5 Path Switch, is that both follow a very similar structure. The handover measurement part is functionally identical between both procedures. The RRC reconfiguration and MME messaging also happens in both cases. The message content differs between both procedures, but since we are only interested in the delays, the message content has no relevance to this examination. Obviously, the PC5 Path Switch in this case is missing the eNB-to-eNB handover part, which corresponds to steps 4-11 from the X2 Handover. For the sake of comparison these steps can simply be ignored as they have no impact on the other steps. A PC5 Path Switch including eNB-to-eNB handover is also proposed in TR 36.746 [3GP18c], but won't be considered here, as it isn't relevant for the industry scenarios described in Section 2. The PC5 Path Switch procedure described in TR 36.746 [3GP18c] is not yet finalized, and therefore not yet standardized. For this reason, there are no experimental results or simulation implementations can be used as a basis for the feasibility evaluation of the considered application scenarios. The approach in this paper is to look at the X2 based Handover, which is already implemented for simulation, and relate it to the PC5 based Path Switch to get an estimate on the duration of the path switch process. For the simulation, the ns-3 1 network simulator is used. The included Lena LTE model implements the X2 based handover [Req]. This handover implementation models all the interactions that are relevant for our purpose: The RRC messaging between the UE and the eNB, the X2 interface between eNBs and the path switch messaging between the eNB and the MME. Using the extensive logging feature of the ns-3 simulator, the different steps in the handover and the durations are obtained from the associated timestamps. For the delay comparison of the X2 based handover and the PC5 based Path Switch, it is assumed that the duration of similar steps is also similar. Specifically, in both processes the eNB sends an "RRC connection reconfiguration" message. In the X2 based handover to the UE (step 7-11), in the PC5 based Path Switch to both UEs (steps 7-8/11-12). The ProSe UE's user plane and control plane data are relayed through the ProSe UE-to-Network Relay UE. Since the transmission duration itself is negligible it is assumed the reconfiguration process to happen in parallel at both UEs, limiting the delay. While the RRC connection procedure is not part of the X2 handover, the delay requirement is given in TR 36.331 [3GP15b], same as the RRC reconfiguration procedure. After the RRC connection or reconfiguration, dependent on the direction of the path switch, the eNB informs the MMEs of both ProSe UEs about the changed relationship of the UEs (steps 4-6,9/13-14). These steps, again, are similar to the target eNB messaging the MME about the UE cell change in the X2 based handover. Similarly, it is assumed that the messaging of both MMEs happens at the same time, since the transmission delay should have no relevant impact on the overall process duration. In Table 1 these values are collected and associated with their respective sources. By adding up the delays of the individual steps, we estimate the complete PC5 Path Switch procedure to last roughly 57 ms when switching from a direct to a relay link, and roughly 42 ms when switching from a relay to a direct link. In TR 22.804 [3GP18a], the survival time for AGVs is assumed to be between 1-50 ms, depending on the specific application. Step 3 RRC connection Steps 4-6,9/13-14 MME messaging Steps 7-8/11-12 RRC reconfiguration Ns3 X2 Handover simulation [Req] 12.9 ms 0ms (14ms) 2 13.9ms Requirements from TR 36.331 [3GP15b] 15ms 15ms

Conclusion & Future Work
In this paper, we discussed possible applications where device-to-device communication could be used in industrial settings. Three different general scenarios were considered and examples given. For each scenario, the feasibility was discussed based on the requirements the applications put on the communication infrastructure. The first scenario, "automated services without coverage", is feasible.
For the second and third scenario, "extended connectivity outside coverage" and "low latency communication and synchronization", the main issue is the delay imposed by the path switch procedure when the AGVs shift their communication links between different relays and access points. Whether the communication link downtime is lesser or greater than the survival time depends on the application and its specific requirements. The breadth of the requirements for AGVs do not allow for a simple, single conclusion. For applications in the higher end of the survial time spectrum the path switch delay is short enough to allow for continuous operation. For applications in the lower end of the survival time spectrum the path switch delay is insufficient. Here, additional sensor and processing capabilities on the AGVs should be used to extend the acceptable communication link downtime. Otherwise, a seamless path switch or make-before-break approach to the path switch procedure is necessary. As of now, these are still a work in progress.
However, these conclusions are based on rough estimates of the PC5 Path Switch delay and application requirements. For future work, this procedure should be implemented in ns-3 to obtain a better understanding through simulation. Simulating the Path Switch should give a more accurate representation of the delay imposed by the procedure. Finally, a demonstrator implementation in a 5G Testbed could give actual real-world measurements and verifiable results.

Acknowledgement
This work was funded by the Federal Ministry for Economic Affairs and Energy of Germany in the project IC4F (grant no. 01MA17008).