Programmability of Connectivity Control

as key features of next generation communications enable innovative services. While the programmability is focused on the core network of the fifth-generation system, the edge computing moves the network intelligence to the radio access network. This paper presents a study on the programmability of connectivity control as a function of radio access network using Multi-access Edge Computing. The capability of using more than one radio access technology simultaneously enhances reliability and increases the throughput, especially in dense networks. Opening the radio access network interfaces for programmability of multi-connectivity enables analytics applications to control the device connections to multiple radio links simultaneously based on information of radio conditions, user location or specific policies. The research novelty is in opening the radio access network interfaces for edge applications to access connectivity control.


I. INTRODUCTION
Next generation networks will further increase the capabilities to transfer large data volumes, to provide greater service diversity, improved performance, and efficiency. Achieving the service requirements for ultra-low latency, higher capacity, and vastly improved reliability and availability is a challenge and one of the solutions is multiconnectivity [1]. Multi-connectivity is a feature, which allows the user device to have simultaneously multiple connections to the network even using different radio technologies. The feature makes available for the device resources of two or more cells, and it improves network performance and reliability in a dense environment, especially in the case of link outage events [2]. As an evolution of dual connectivity introduced for Long Term Evolution (LTE), multi-radio dual connectivity in 5G reduces the signalling between core network and radio access network (RAN) and all forms of interworking in 5G among different radio variants and among carriers of the same radio variant, and different transmission points are possible on RAN level [3].
In RAN interfaces for third party control on multi-radio dual connectivity in 5G.
O-RAN is an initiative for RAN virtualization empowered by the principles of artificial intelligence and cloud computing [4]. RAN openness enables fast introduction of innovative services and network customization. Edge computing makes possible the usage of artificial intelligence for traffic steering, quality of experience optimization, and quality of service resource optimization [5]. While O-RAN focuses on use cases and deployment scenarios, we propose and approach to virtualize the multi-connectivity functionality and to enable third party cloud applications deployed at the network edge to make intelligent decisions about device connections.
The rest of the paper presents an approach to define RESTful Application Programming Interfaces (APIs) for connectivity control. First, Section II provides a brief review on related works. Next, Section III illustrates the usage of the proposed API by typical use cases. Section IV describes the data model, which enables applications to access connectivity data in a uniform way increasing interoperability. Section V presents the research mathematical foundation and considers aspects of API implementation, including models of multi-connectivity states as seen by MEC applications and by the network. Section VI presents a study on API performance metrics and provides a discussion on simulation results related to APIinjected latency. The conclusion summarizes the paper contribution.

II. RELATED WORKS
The benefits of multi-connectivity are demonstrated in [6]- [9]. In [10], the authors study different degrees of multiconnectivity in 5G in the context of outage probability and associated spectral efficiency. In [11], solutions and enablers for 5G spectrum sharing in satellite and terrestrial multi-connectivity are discussed. Advanced architectures, protocols, and schemes for multi-connectivity, which improve the throughput and affect the latency, are proposed in [12]- [15].
Network cloudification and programmability allow telecom operators making their networks more scalable, flexible, and agile and to offer innovative and marketoriented services. By centralizing certain functionalities, cloud computing enables on-demand resource sharing and it empowers applications with elasticity and scalability at low cost [16], [17]. In [18], it is shown that the cloud-based heterogeneous access network architecture exceeds the distributed architecture in terms of throughput performance. Network programmability opens the network capabilities and services for third party developers, enabling attractive applications and personalized user experience [19]. It makes service provisioning faster, simpler, and more cost effective [20]- [22]. Enablers for programmability are cloud-based applications and services. With the distribution of cloud resources at the network edge, closer to where they are needed, Multi-access Edge Computing (MEC) may improve network performance and enhance user quality of experience. MEC provides an execution environment for applications with strong requirements for low latency and high bandwidth and security. Performance analysis on edge computing in IoT is presented in [23].
The paper novelty is in the exposure of RAN functionality of connectivity control to MEC applications. The proposed API enables edge applications to configure multiple radio links to a given device to improve reliability and spectral efficiency. Opening the network edge for this functionality enables applications deployed at the network edge to influence the device connectivity based on local policy, actual radio network conditions, device location or context.

III. CONNECTIVITY CONTROL AS A SERVICE
Ultrahigh reliability, enhanced bandwidth, and strong security are required in different use cases envisaged in next generation networks, such as industrial automation (e.g., power and process system automation, motor control, industrial Ethernet), smart grids (e.g., for fault detection, frequency and voltage control), tactile internet (e.g., remote health care and gaming), intelligent transportation (e.g., autonomous driving), virtual/augmented reality, and different mission critical scenarios (disasters, public safety, and emergency).
MEC provides a cloud environment for applications at the edge with requirements for low latency, high bandwidth, location, and context awareness. Opening the connectivity control for third parties enables trusted MEC applications to dynamically manage device connections to the network based on prevailing radio conditions, device context or location, available radio access technologies, and local quality of service policies. Using capabilities for connectivity control, MEC applications may be mission critical ones in saving lives, responding on time, delivering utilities or preventing serious injuries by lowering the latency, and increasing reliability.
In multi-radio dual connectivity, a device, which is capable to use multiple radio technologies simultaneously, may use resources provided by two different RAN nodes connected via non-ideal backhaul, one providing 5G radio access and the other one providing 4G or 5G radio access. The RAN node, which provides the control plane connection to the core network, is a master node, while a secondary node is a RAN node, which provides resources to the device, but does not have a control plane connection to the core network [3].
The open access to connectivity control may be provided by a new MEC service called "Multi-radio Dual Connectivity Control (MRDCC) service", which enables applications to:  access information about device supported radio access technologies,  configure device measurements required for multiconnectivity,  access measurement information, and  add and remove a RAN node. Having information about supported radio access technologies by the device (User Equipment, UE) and based on the level of network congestion, device location, quality of service requirements or application-specific policy, a trusted MEC application may add or release a RAN node.
In the case of so-called "bump in the wire" MEC deployment scenario, the MEC platform and applications are co-located with a RAN node or placed at the aggregation point, and the communication between the MRDCC service and the RAN node is internal [24].
The design of MRDCC API follows the RESTful principles, where the communication between applications and the service is in the form of request/response and subscription/notifications.
The MEC platform, where the MEC application and the MRDCC service are executed, may be associated with the master RAN node or with the secondary RAN node. Both master node and secondary node initiated secondary node addition and change can be supported. When a MEC application requests a RAN node addition/modification/release, it depends on the MEC deployment scenario which network procedure will be executed. In the following case, we assume that the MEC platform is co-located with the master node.
In a dense environment, a dedicated MEC application may configure connectivity-specific triggers for measurement reporting (e.g., a whitelist of cells and/or a blacklist of cells, which are not applicable in event evaluation or measuring reports). The application with an active subscription may receive notifications about device measurements when the application-specific thresholds are reached. Figure 1 shows the flow for application query about device capabilities, subscription, and notifications about connectivity-related measurements.
The application uses a HTTP GET request to retrieve information about supported device capabilities. The RAN node uses the device capability enquiry procedure to receive capability information. The application uses a HTTP POST request to configure connectivity-specific measurements (e.g., thresholds for serving cells and neighbour cells). Details regarding measurement events triggering notifications are provided in [25]. The RAN node initiates Radio Resource Control (RRC) Reconfiguration procedure to configure the device measurements [25]. To subscribe for notifications about device measurements, the MEC application sends a HTTP POST request defining the appropriate filter criteria and an address at which it wants to receive notifications. When the device reports an event related to configured measurements, the MRDCC service uses a HTTP POST request to notify the MEC application.
The subscription request issued by MEC application may indicate the subscription expiry, and when the subscription expiry approaches, the MEC application may update the subscription if required. In addition, the MEC application may terminate an existing subscription when it is no more interested in connectivity-related measurements.
Based on connectivity-related measurement reports, the MEC application may initiate RAN node addition, modification, or release of the added RAN node.  Figure 2 shows the flow of application-initiated RAN node addition. When the application decides to provide additional resources from a target RAN node to the UE, it sends a POST request for adding the target RAN node to the RAN node to which it is associated (master node), and a secondary node addition/modification procedure is executed in the network [3]. The respective network actions include resource allocation in the target RAN node, RRC Reconfiguration, and device synchronization towards the target RAN node. The MEC application is informed about the result of the requested RAN node addition. The MEC application may also modify or release a previously added RAN node. The MEC application uses a HTTP PUT request to modify a RAN node added by itself and a RAN node modification procedure is executed in the network. The flow of application-initiated RAN node release is shown in Fig. 3.

IV. DATA STRUCTURES AND ENTITY TYPES
The data model is a part of MRDCC API definition, and it describes data structures and entity types. The data model encourages interoperability and application collaboration increasing agility in development.
The measurementInfo type represents information about the measurement configuration set by a MEC application. The attributes of the measurementInfo data type are provided in Table I. The measurementSubscription type represents a subscription for measurement notifications. The attributes of the measurementSubscription data type are provided in Table II.
The measurementNotification type represents a notification from the MRDCC service with regards to UE measurements. The notification is sent to inform the mobile edge application that some thresholds set by the application are reached. The attributes of the measurementNotification data type are provided in Table III. The ranNodeInfo type represents information about the RAN node that has to be added. The attributes of the ranNodeInfo are provided in Table IV. The mobile edge application may also provide some predictions on UE expected behaviour if applicable.
The ueCapabilities type represents device capabilities. It includes the UE identity, supported radio access technologies, transmission mode (FDD and/or TDD), and frequency bands. Figure 4 shows the structure of entities supported by the MRDCC service. The MRDCC service may be published in service registry, e.g., //{apiRoot}/mrdcc/v1. The service entities are uniquely identified and follow the service root. Table V provides a description of MRDCC service entities. The ueCapabilityQueries entity represents all queries about device capabilities. All configured connectivityrelated measurements by MEC application are represented by configuredMeasurements entity. All connectivity-related measurement subscriptions are represented by measurementSubscription entity. The addedNodes entity acts for all application added RAN nodes. All these entities may be manipulated by HTTP GET method, which retrieves a respective list of all child entities, and by HTTP POST method, which creates a new child entity.

V. MATHEMATICAL MODELS OF BEHAVIOURAL SETTINGS
The application development that uses the MRDCC API requires modelling of the device connectivity state. This model must be harmonized with the device connectivity model maintained by the network. From the network point of view, the device may be connected to a master node and to a secondary node, so the network maintains device connectivity models for the master and secondary RAN nodes.
This section presents the three models, their mathematical representation as Finite State Machines (FSM) and formal verification. Figure 5 shows the simplified model of the RAN node state, as seen by a MEC application. The model does not include exceptional situations and modifications of the added RAN node. The MEC application has a subscription for device connectivity-related measurements. Upon receiving a notification that the thresholds for secondary node adding are reached, the MEC application requests a RAN node addition using the MRDCC API. In case of successful secondary node addition, the MEC application is notified and considers the respective RAN node as connected to the device. Upon receiving a notification that the thresholds for secondary node release are reached, the MEC application requests the RAN node release, and when the MRDCC responses, the application considers the RAN node as disconnected from the device. Figure 6 shows the simplified model of the RAN node state supported by the master node in the network. The model includes resource allocation in the secondary node, RRC connection reconfiguration for adding a secondary node, and resource release for secondary node release.  Figure 7 shows the simplified state model of the RAN node in the role of a secondary node, which may be added or released by a MEC application. Each of the three models is mathematically described as an FSM represented by a quadruple of a set of states, a set of actions, a set of transitions, and an initial state.
By  The mathematical formalism of bi-simulation is used to prove that the FSMs are harmonized, i.e., their behaviour on stimulus from the network and MEC application is equivalent [26], [27].
Proposition: T app , T mn , and T sn have a weak bi-simulation relationship.
Proof: By U mc it is denoted the relationship between the states of the three FSMs, where U mc = {(s 1 app , s 1 mn , s 1 sn ), (s 3 app , s 4 mn , s 3 sn )}. The following transitions in the FSMs result in the respective states in U mc .

VI. THEORETICAL EVALUATION OF API FUNCTIONAL PERFORMANCE
As to [28], MEC functional performance metrics impact on user perception, and the end-to-end latency is one of the functional key performance indicators. The latency is defined per service base, and for the MRDCC service, it is the round-trip time required for a generated request to be transferred to the destination and the respective response to be sent back.
The latency injected by an application-initiated request for adding or releasing of a RAN node may be evaluated as the time required to notify the application about the measurement thresholds reached and to enforce applicationinitiated action.
The latency injected by a notification includes the time required for processing the notification request by the MRDCC service and by the application (α s notifreq and α app notifreq ) and the time required for processing of the notification response by the application and by the service (α app notifres and α s notifres ). The communication between the service and the application is internal, and the time is negligible.
Let T notification be the time for application notification, where T notification = α s notifreq + α app notifreq + α app notifres + α s notifres .
The latency injected by an application action request includes the time required to process the request by the application and by the MRDCC service (α app actreq and α s actreq ), as well as the time required to process the response by the service and by the application (α app actres and α s actres ).
Let T action be the time for application action request, where T act = α app actreq + α s notifreq + α s actres + α app actres .

VII. PERFORMANCE TEST
The prototype of the service, being a REST-based one, is implemented using the well-known Apache Cassandra [29] and Vertx [30]. Both are Java [31] based, as the service portability is an important factor. As far as the further research will be focused also on the aspect of service high availability, so the choice of Cassandra becomes obvious because of its proven qualities of fault tolerant and scalable types. The sustainable community support and flexibility of Vertx, especially its multi-lingual essence, make it the choice for the REST part of the implementation.
The performance test is of a client-server load type, where the server side is containerized using Docker [32]. The frontend REST exposes IPv6 contact point over 1 GbE interface. The load is consisted of a package containing 20000 create operations. The selected part that will be observed and analysed (well after the initial warm-up) is the tail. It is shown in Fig. 8. The numerical results show that most of the operations would add to the latency around 3 ms, yet the spikes may get over 1 s. This test is conducted with replication factor 1 and the durable writes are not spread across any cluster but kept within a single node. The probability density function of this stochastic process just for the given time window of the last thousand operations is shown in Fig. 9. While not being of the fat tail type, which is presumed by the lack of hyperlinked consequent traffic, still the L-type of the distribution shows that part of the operation will be exhibited at a higher latency.
Threshold values for the replication, when a high availability test must be run, should be carefully chosen.

VIII. CONCLUSION
Opening the RAN interfaces for third parties enables fast creation and deployment of innovative applications, which improve the network performance and increase user quality of experience.
In existing standards, it is the network, which configures device measurements and controls the device connections. In this paper, a new MEC service, which exposes the network functions for device connectivity control, is proposed. The service functionality is outlined by use cases illustrating the edge application capabilities to retrieve information about device capabilities, to configure device measurements, to receive notification about reaching measurement thresholds, and to add, modify, and release RAN nodes to/from the device serving a set of nodes.
With the proposed service API, authorized edge applications may control the device connectivity state based on device location or context, the load level of RAN, specific quality of service requirements, and other policies.
The service APIs are based on REST, which provides great flexibility, portability, and scalability. As a part of the service API definition, a data model is specified, which determines the service resource structure and data types and provides interoperability in data manipulation by different applications. The service feasibility is mathematically proved by modelling the device connectivity state from the application and network point of view.
The injected latency by service APIs is evaluated theoretically and by emulation, where the average levels open the door for further improvement of API performance.
The service APIs are beneficial when the connection's high reliability and availability, high throughput and low latency are of great importance.