<figure><img src="image_1.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Slicing Mechanism Deployment in 5G Networks for Robotic Use Cases

Christina C. Lessi¹(✉), George Tsiouris¹, George Agapiou², Renxi Qiu³, Andreas Gavrielides⁴, Konstantinos C. Lessis², and Ioannis P. Chochliouros¹

¹ Hellenic Telecommunications Organization (OTE) S.A., 99 Kifissias Avenue, 15124 Maroussi, Athens, Greece
clessi@oteresearch.gr

² WINGS ICT Solutions, 189, Siggrou Avenue, 17121 Athens, Greece

³ School of Computer Science, University of Bedfordshire, Luton, UK

⁴ eBOS Technologies Ltd., Arch. Makariou III and Mesaorias 1, 2090 Lakatamia, Nicosia, Cyprus

**Abstract.** Robotics is a rapidly growing field that is set to play an important role in automating many activities. The requirements that a robot can have for effective use can have large appeals. For example, in the case of its use for transport applications where it moves between people and vehicles, it is necessary to connect to a network with extremely low latency so that its reaction is immediate. In contrast, applications such as video transmission and recording and sending data require high throughput. The different demands on network resources lead to the need to implement flexible networks that can guarantee the necessary resources in the most efficient and reliable way. Slicing is a network capability that can provide specific network characteristics and can be implemented in different 5G network domain elements such as Radio Access Network (RAN), 5G Core or end-to-end. This paper presents the slicing mechanism that was implemented to be utilized for the needs of the use cases described in the 5G-ERA research project. In phase 1 of the implementation, which is described, slicing is focused on the packet core of the network that was integrated based on 5G SA Rel. 16 architecture.

**Keywords:** Slicing · 5G networks · Management and Orchestration · Middleware · Standalone architecture · Slice Manager · API · 5QI · Allocation and Retention Priority

## 1 Introduction

5G-ERA is a European funded research project that focuses on integrating vertical knowledge into the existing 5G testing framework to improve Quality of Experience (QoE) for customers which are targeting vertical sectors such as transport, healthcare, Public Protection and Disaster Relief (PPDR), and Industry 4.0 [1]. These sectors require high data transmission and processing and offer demanding services that could be integrated in a 5G network taking advantage from its capabilities in order to implement robotic collective intelligence approaches.
The use case analysis [2, 3] proved that several types of services are required. For example, in the PPDR use case that is proposed by 5G-ERA, the robot should be able to transmit a large amount of data since it should be able to send video streaming and data collected from sensors. At the same time, the reliability of the network should be high, because the robot, due to the emergency situation in which it is called upon to contribute, must communicate without interruptions with the control center. In the healthcare use case high data transmission is required, as well as high reliability. However the mobility, which is the ability of a moving user to send and receive data, is not high, since the robot is not expected to move very fast. The transport sector does not require high data transmission, but the network should support high location accuracy and availability when the robot is moving. Finally in Industry 4.0 network reliability seems to be essential, unlike throughput which is not critical.

<figure><img src="image_2.png" /><figcaption>Fig. 1. 5G-ERA high level architecture</figcaption></figure>

In order to manage network resources optimally and provide the QoS that is needed, the slicing feature is important. 5G Rel. 16 architecture [4] which is used in 5G-ERA (Fig. 1.) is able to support, by using network slicing, new network services [5, 6] such as:

* Enhanced Mobile Broadband (eMBB), which offers high bandwidth and is ideal to be used in cases where a large amount of data should be transferred

* Ultra-Reliable and Low Latency Communications (URLLC), which supports data transmission with lower delay than the 4G technology or the other types of services

* Massive Machine Type Communications (mMTC), which is used when large number of devices should be used at the same time

Slicing is a network capability that can provide specific network characteristics optimally, based on the end users demands [7, 8]. For instance, there could be network slices
that provide high bandwidth, others that ensure the low latency or high reliability. Slicing could be implemented in RAN or in 5G Core or in end-to-end network infrastructure.

<figure><img src="image_3.png" /><figcaption>Fig. 2. Network components in 5G-ERA ecosystem</figcaption></figure>

## 2 The Slicing Mechanism

The architecture of the network deployed is presented in Fig. 2. The components that will be used for the slicing selection are: the 5G Core (5GC), the Slice Manager and the Middleware.

The testbed that is deployed could support the following options:

* One or more slices available for each subscribed robot

* A robot could be registered and use one or more slices

* Different slices can be associated to different User Planer Functions (UPFs).

* One UPF can be both dedicated or shared among several slices

The phase 1 slicing mechanism design focuses on the 5G Core slicing. Several slices are configured in the 5G Core (which is implemented based on the 5G SA Rel. 16 architecture) supporting different types of services. One of these slices is defined as the default slice where a robot will be registered for the first time it gets access to the network. If the slice is not the preferred one, then a slice selection mechanism will be activated. The flow diagram of the mechanism is presented in Fig. 3:

Multiple user profiles are configured in the packet core. These profiles contain pro- visioning of information about the users, the access and session management data, the network slices etc. Even though the user profiles are not the same as slices, for the mechanism that is designed each user profile will be mapped to a specific slice:

user profile (1) = slice profile (1)

user profile (2) = slice profile (2)

user profile (3) = slice profile (3)

Therefore, according to the above implementation, it is ensured that the reference to a specific user profile coincides with the reference to a specific slice.
<figure><img src="image_4.png" /><figcaption>Fig. 3. Slicing flow diagram</figcaption></figure>

The component that will trigger the mechanism described above is the Middleware which will send the request for slice change. More specifically, the Middleware will send a message to the slice manager to get information about the available user profiles. Then, the slice manager will send the request to the packet core and the packet core will respond with the list of user profiles which will be forwarded to the Middleware. In this list, the slices characteristics are not provided. Only the user profile name will be included: eg. UserProfile1 (UserProfile characteristics will be pre-installed in Middleware). Middleware will choose the proper user profile based on the needs of the robot for the specific use case and inform the slice manager. The slice manager will then send a request to delete User Equipment (UE) from the default UserProfile and re-register in a new one.

The slicing mechanism described above has been tested by using a Teltonika TRB500 [9] Customer Premises Equipment (CPE). The use of this CPE was preferred since its operation is the same as the one of the robots that are used in 5G-ERA. TRB500 was
initially registered in Slice1. Then, Slice2 was manually requested and after a CPE reboot, it was connected to slice2.

The slicing mechanism that is implemented is currently static. TRB500 is not able to request a slice automatically neither to be registered to the new slice without reboot. An external user should request for a slice change by interfering with Middleware and then UE should terminate the Protocol Data Unit session (PDU session) and restart a new one. Even though the mechanism is not dynamic, it could offer the advantages of the slicing feature. The UE is able to use the resources it requires, reliably and secured, while the network operator is able to manage the network resources optimally, offering to each UE only the resources it needs.

## 3 Slice Manager

As it was shown in Fig. 3, the Slice Manager is a component directly connected to the 5G Core requesting slice changing. It is built in Java using the Spring Boot Framework [10], while its southbound interface is used to interact with the slice plugins deployed in 5G testbed. Application programming interfaces (APIs) were implemented in order to:

* get the authentication token from the 5G Core

* retrieve the complete list of Provisioned Data Profiles

* retrieve information on a specific provisioned Profile

* delete an existing Provisioned Data Profile

* create a new Provisioned Data Profile

* replace an existing Provisioned Data profile or creates a new one if it doesn't exist

* retrieve the rule for a specific Public Land Mobile Network (PLMN) of an existing provisioned data profile

* create a new rule or replace an existing one for a specific PLMN for an existing Provisioned Data Profile

* delete an existing PLMN rule for a Provisioned Data Profile

* replace the policy data profile associated to an existing Subscription Permanent Identifier (SUPI)

* replace the provisioned data profile associated to an existing SUPI

The Slice Manager plays an important role in the designed mechanism since it is the component responsible for the slice management. Additionally, it receives the information from the middleware about the specific slice that the robot needs based on the Use Case requirements. As it is illustrated in Fig. 3, Slice Manager is the component that lets the Middleware to access the services offered by the packet core, translating the messages that both packet core and Middleware send and receive through the REST API it includes. These messages include important information about slices such as the Allocation and Retention Priority (ARP) and the 5G QoS Identifier (5QI) [11, 12].

## 4 The Middleware in the Proposed Slicing Mechanism

Middleware is a component in 5G-ERA infrastructure which is responsible to address the needs of vertical developers. Network Applications, Machine Learning (ML) tools and Artificial intelligence (AI) algorithms will be installed in Middleware. However,
it will be used for additional purposes such as to optimise teleoperators' experience in handling unknown vertical applications, aggregate optimised vertical requests to the Open Source MANO (OSM) autonomously and request slices for the interconnected robots.

<figure><img src="image_5.png" /><figcaption>Fig. 4. Slicing control logical view</figcaption></figure>

The Middleware will be implemented in two different places within the 5G-ERA infrastructure. The first implementation will be done centrally (Middleware2 in Fig. 4), where it will be possible for different networks to access and utilize Network Applications and the services it provides. The second implementation will be done at the edge (Middleware1 in Fig. 4), bringing the services closer to the user. More specifically, the second implementation of the Middleware will be local to the specific network infrastructure from which it will be leveraged. This choice was made with the aim of being able to offer services with different needs. For example, if a service has a requirement for low delays, it should necessarily be offered by the local middleware, in contrast to services that do not have such a requirement and can be offered by the central middleware, saving physical resources. In Fig. 4 the slicing control logic is presented. Middleware1 is installed in the edge layer of the network infrastructure, communicating with Slice Manager which is installed close to 5G Core, and Middleware2 which is a centralized component. Middleware1 will be synchronised with Middleware2 offering services that require low latency.

This local Middleware will be used in the slicing mechanism and its integration should focus not only on the demonstration of the standardised API for the Network Application developers, but also on the deployment of the proper interface to interconnect
with the Slice Manager, allowing UEs to access 5G resources by using the required slice [13]. As it is presented in Fig. 5, Middleware will include several REST APIs to let it communicate with all the main components of the 5G-ERA infrastructure.

<figure><img src="image_6.png" /><figcaption>Fig. 5. Illustration of the Middleware end-to-end service creation and management</figcaption></figure>

More specifically, in order to communicate with the Northbound Interface of the Slice Manager, a JSON message should be sent through the API requesting the proper slice as it is presented in the flow diagram of Fig. 3.

# 5 Conclusion

In this paper the slicing mechanism that was deployed for the needs of 5G-ERA project was presented. The use cases of 5G-ERA propose solutions in sensitive sectors such as PPDR and healthcare, but also in demanding sectors such as transport and Industry 4.0. The requirements that users have from the network are very diverse and it is important to be able to provide the necessary services in a reliable and efficient manner. Therefore, slicing is an important feature provided by the network to achieve this service offering.

The mechanism that was designed and presented in this paper focused on the packet core slicing, where several slices were designed. An advanced network architecture was designed, including a Slice Manager, which is responsible for the direct communication with the packet core, requesting the proper slice, and a Middleware, which is an external network component, communicating with the robots and knowing their needs for resources. Middleware is the component that drives the slice change process by asking from the slice manager a specific slice.

Currently, as it is the phase 1 of slicing mechanism deployment, this mechanism could be considered as a static one. Robots will be able to use one slice based on their needs and change it, if it is required, but the process is not taking place autonomously
and robots should be rebooted in order to reconnect to the new slice. However, it is a
mechanism that offers the advantages of slicing in better resources management and
services availability.

**Acknowledgments.** This work has been performed in the scope of the 5G-ERA European Research Project and has been supported by the Commission of the European Communities (Grant Agreement No. 101016681).

**References**

1. 5G-ERA project. https://www.5g-era.eu

2. Lessi, C., Agapiou, G., Sophocleous, M., Chochliouros, I., Qiu, R., Androulidakis, S.: The use of robotics in critical use cases: the 5G-ERA Project solution. In: AIAI 2022: Artificial Intelligence Applications and Innovations. AIAI 2022 IFIP WG 12.5 International Workshops, pp. 148–155 (2022). https://doi.org/10.1007/978-3-031-08341-9_13

3. 5G-ERA D1.1. (2021). Use case scenarios definition and evaluation specification. https://5g-era.eu

4. 3GPP TR 21.916 V1.0.0 (2020-12) Release 16. https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3493

5. SRS Project (2013). http://wiki.ros.org/srs_public

6. KnowRob Project (2014). http://knowrob.org

7. NGMN Alliance: Description of network slicing concept. Next Generation Mobile Networks Alliance (2016). https://ngmn.org/wp-content/uploads/160113_NGMN_Network_Slicing_v1_0.pdf

8. 3GPP TS 28 530: 5G Management and orchestration; Concepts, use cases and requirements. V15.0.0, November (2018)

9. https://teltonika-networks.com/products/gateways/trb500

10. https://spring.io/

11. ETSI TS 123 502 V16.12.0 (2022-03): 5G Procedures for the 5G System (5GS) (3GPP TS 23.502 version 16.12.0 Release 16), March (2022). https://www.etsi.org/deliver/etsits/123500123599/123502/16.12.0060/ts123502v161200p.pdf. Accessed Feb (2023)

12. 3GPP: Study on new services and markets technology enablers. 3GPP TS 22.891. European Telecommunications Standards Institute (ETSI), technical report version 14.2.0. (14 Sep 2016)

13. 5G-ERA D4.1: 5G-ERA Middleware initial version (2022). https://5g-era.eu