WO2018121874A1

WO2018121874A1 - Policy- and location-based multi-connectivity

Info

Publication number: WO2018121874A1
Application number: PCT/EP2016/082918
Authority: WO
Inventors: Berthold PANZNER; Ruediger Halfmann
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2016-12-30
Filing date: 2016-12-30
Publication date: 2018-07-05
Anticipated expiration: 2019-06-30

Abstract

A solution for providing policy- and location-based multi-connectivity is proposed. According to an aspect, a method comprises receiving in a network node, location information on a terminal device; retrieving by the network node, using the location information, location-dependent multi-connectivity related information; determining by the network node, based on the location-dependent multi-connectivity related information, a multi-connectivity mode for the terminal device; and causing sending the multi-connectivity mode for the terminal device to the terminal device.

Description

DESCRIPTION

TITLE POLICY- AND LOCATION-BASED MULTI-CONNECTIVITY

TECHNICAL FIELD

The invention relates to communications.

BACKGROUND

The following description of background art may include insights, discover- ies, understandings or disclosures, or associations together with disclosures not known to the relevant art prior to the present invention but provided by the invention. Some such contributions of the invention may be specifically pointed out below, whereas other such contributions of the invention will be apparent from their context.

The number of networking devices is increasing rapidly, and future cellular communication systems need to have capability of handling vast numbers of connecting terminal devices. One solution to provide the required capability is to use multi-connectivity. In multi-connectivity, a connecting terminal device, such as a user terminal, is not connected only to a single cell on a single frequency layer, but simultaneously to two or more cells.

In order to benefit from multi-connectivity gains, the terminal device has to permanently monitor and report all frequency bands and radio access technologies it supports. This generates large overhead in terms of measurement reports that the terminal device signals to the access node.

BRIEF DESCRIPTION

According to an aspect, there is provided the subject matter of the independent claims. Embodiments are defined in the dependent claims.

One or more examples of implementations are set forth in more detail in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF DRAWINGS

In the following, exemplary embodiments will be described with reference to the attached drawings, in which

Figure 1 illustrates a wireless communication scenario to which embodiments of the invention may be applied;

Figure 2 illustrates an embodiment for a data structure of a multi-connectiv- ity database;

Figure 3 illustrates a flow diagram of updating the coverage map(s) based on terminal measurements;

Figures 4, 5 and 6 illustrate flow diagrams of processes for determining the multi-connectivity mode for a terminal device according to some embodiments;

Figures 7 illustrates an embodiment for determining the multi-connectivity mode for a terminal device;

Figures 8 illustrates a flow diagram of a process for calculating the deployment suggestion based on terminal measurements and

Figures 9 illustrates a block diagram of apparatus according to some em- bodiments of the invention.

DETAILED DESCRIPTION OF SOME ENMBODIMENTS

The following embodiments are exemplary. Although the specification may refer to "an", "one", or "some" embodiment(s) in several locations, this does not neces- sarily mean that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments.

Embodiments described may be implemented in a radio system, such as in at least one of the following: Worldwide Interoperability for Microwave Access (WiMAX), Global System for Mobile communications (GSM, 2G), GSM EDGE radio access Network (GERAN), General Packet Radio Service (GRPS), Universal Mobile Telecommunications System (UMTS, 3G) based on basic wideband-code division multiple access (W-CDMA), high-speed packet access (HSPA), Long Term Evolution (LTE), LTE-Ad- vanced, a system based on IEEE 802.1 1 specifications, a system based on IEEE 802.15 specifications, and/or a fifth generation (5G) mobile or cellular communication system.

The embodiments are not, however, restricted to the system given as an example but a person skilled in the art may apply the solution to other communication systems provided with necessary properties. One example of a suitable communications system is the 5G system, as listed above. 5G has been envisaged to use multiple- input-multiple-output (MIMO) multi-antenna transmission techniques, more base stations or nodes than the current network deployments of LTE, by using a so-called small cell concept including macro sites operating in co-operation with smaller local area access nodes and perhaps also employing a variety of radio technologies for better coverage and enhanced data rates. 5G will likely be comprised of more than one radio access technology (RAT), each optimized for certain use cases and/or spectrum. 5G system may also incorporate both cellular (3GPP) and non-cellular (for example IEEE) technologies. 5G mobile communications will have a wider range of use cases and related applications including video streaming, augmented reality, different ways of data sharing and various forms of machine type applications, including vehicular safety, different sensors and real-time control. 5G is expected to have multiple radio interfaces, including apart from earlier deployed frequencies below 6GHz, also higher, that is cmWave and mmWave frequencies, and also being capable of integrating with existing legacy radio access technologies, such as the LTE. Integration with the LTE may be implemented, at least in the early phase, as a system, where macro coverage is provided by the LTE and 5G radio interface access comes from small cells by aggregation to the LTE. In other words, 5G is planned to support both inter-RAT operability (such as LTE-5G) and inter-RI operability (inter-radio interface operability, such as inter-RI operability between cmWave and mmWave). One of the concepts considered to be used in 5G networks is network slicing in which multiple independent and dedicated virtual sub networks (network instances) may be created within the same infrastructure to run services that have different requirements on latency, reliability, throughput and mobility.

It should be appreciated that future networks will most probably utilize network functions virtualization (NFV) which is a network architecture concept that proposes virtualizing network node functions into "building blocks" or entities that may be operationally connected or linked together to provide services. A virtualized network function (VNF) may comprise, in addition to standard high-volume servers, switches and storage devices, one or more virtual machines running computer program codes using standard or general type servers instead of customized hardware. Cloud computing or cloud data storage may also be utilized. In radio communications, this may mean that node operations are carried out, at least partly, in a server, host or node operationally coupled to a remote radio head. It is also possible that node operations will be distributed among a plurality of servers, nodes or hosts. It should also be understood that the distribution of labor between core network operations and base station opera- tions may differ from that of the LTE or even be non-existent. Some other technology advancements probably to be used are Software-Defined Networking (SDN), Big Data, and all-IP, which may change the way networks are being constructed and managed.

Figure 1 illustrates an example of a communication system 10 to which some embodiments of the invention may be applied. The system 10 may be a wireless communication system composed of one or more radio access networks 150 of access nodes 102, 1 12, 122, each providing and controlling a respective cell or cells. The access nodes may provide one or more terminal devices (user equipment, UEs) 104 with wireless access to other networks such as the Internet 156, either directly or via a core network 180. In the illustrated example, the system 10 further comprises a positioning system 106.

In a wireless system, an access node provides and manages one or more cells. From another point of view, the cell may define a coverage area or a service area of the access node. The cell may be, for example, a macro cell or an indoor/outdoor small cell (a micro, femto, or a pico cell). The cells 100, 1 10, 120 may be at least partially overlapping with each other. In Figure 1 , the cells 1 10, 120 may also be referred to as sub-cells or local area cells. The network elements 1 12, 122 may be referred to as subnetwork elements or local area access nodes, for example. The cell 100 may be referred also to as a macro cell. The network element 102 may be referred to as a macro network element. In an embodiment, the local area access nodes are network elements similar to the network element 102. Thus, for example, the local area access node 1 12 may be an evolved Node B (eNB) as in the LTE and LTE-A, a next generation node B (NGNB), like in 5G, an access point of an IEEE 802.1 1 -based network (Wi-Fi or wireless local area network, WLAN), a radio network controller (RNC) as in the UMTS, a base station controller (BSC) as in the GSM/GERAN, Access Point (AP), or any other apparatus capable of controlling wireless communication and managing wireless resources within a cell. Typically the wireless communication is radio communication. For 5G solutions, the implementation may be similar to LTE-A, as described above. The access node may equally be called a base station. In some scenarios, one or more local area access nodes may be arranged within a control area of a macro cell access node. The local area access node may provide wireless access within a sub cell that may be comprised within a macro cell. Typically, the sub cell provides a hot spot within the macro cell. The operation of the local area access node may be controlled by an access node under whose control area the sub cell is provided. In some scenarios, a plurality of local area access nodes may be controlled by a single macro cell access node.

In the case of multiple access nodes in the communication network, the access nodes may be connected to each other with an interface 108, 1 18, 128. LTE specifications call such an interface an X2 interface. In IEEE 802.1 1 networks, a similar interface is provided between access points. Other wired or wireless communication methods between the access nodes may also be possible. The access nodes may be further connected via another interface 138, 148, 158 to a mobility management entity (MME) 1 16 in a core network 180.

The MME may handle mobility of terminal devices in a tracking area en- compassing a plurality of cells and also handle signaling connections between the terminal devices and the core network. In the illustrated embodiment, the MME 1 16 comprises a multi-connectivity controller (MCC) 126. The MME 1 16 is connected to a multi- connectivity database (MCD) 136 via an interface (called herein the primary interface) 168. The MCD may also have another, secondary interface 178. In some embodiments, the MME comprises also the MCD 136. In another embodiment, the MCC is a separate node connected to the MME. Different functionalities of the MCC are described below in more detail as well as the content of the MCD 136.

The MCD comprises at least policy data 103 and performance indicator data 1 13. Detailed descriptions of said data types and their usage will be given in conjunction with Figure 2. In some embodiments, the MCD may also comprise a set of multi-connectivity mapping rules 123, a set of deployment rules 133 and/or information on the movement trajectories 143 of the terminal devices 104. In some embodiments, the set of multi-connectivity mapping rules 123, the set of deployment rules 133 and/or the information on the movement trajectories 143 of the terminal devices 104 may be com- prised at least partly in another database connected to or comprised in MCC and/or MME. Detailed descriptions of the multi-connectivity mapping rules, the deployment rules and the information on the movement trajectories and their usage will be given in conjunction with Figures 5, 8 and 6, respectively. In some scenarios, the different access nodes may be connected to different core networks. The different core networks may be operated by the same operator or by different operators. In such scenarios, the MMEs in different core networks may be connected to a shared MCC and/or to a shared MCD.

The system further comprises an operation and maintenance center (O&M)

146 in a network management system. The operation and maintenance center 146 may feed data to the MCD via the secondary interface 178.

The cells 100, 1 10, 120 may provide service for one or more terminal devices 104 (only one illustrated in Figure 1 ), when the one or more terminal devices 104 are located within service area of one or more of the cells 100, 1 10, 120. The one or more terminal device 104 may communicate with the network elements 102, 1 12, 122 using communication link(s). For example, the terminal device 104, which is located midway between network elements 1 12, 122, may be able to use service provided by the all the cells 100, 1 10, 120.

The terminal device (TD) 104 refers to a portable computing device (equipment, apparatus), and it may also be referred to as a user device, a user terminal or a mobile terminal or a machine-type-communication (MTC) device, also called Machine- to-Machine device and peer-to-peer device. Such computing devices (apparatuses) include wireless mobile communication devices operating with or without a subscriber identification module (SIM) in hardware or in software, including, but not limited to, the following types of devices: mobile phone, smart-phone, personal digital assistant (PDA), handset, laptop and/or touch screen computer, e-reading device, tablet, game console, notebook, multimedia device, sensor, actuator, video camera, car, wearable computer, telemetry appliances, and telemonitoring appliances.

MTC may enable providing service for a large amount of MTC capable devices. These devices may provide further functionality compared to the MTC scheme, such as communication link for voice, video and/or data transfer. However, in MTC perspective the device may be understood as a MTC device. It needs to be understood that the device may also comprise another MTC capable device, such as a sensor de- vice providing position, acceleration and/or temperature information to name a few examples. Some embodiments of the invention may thus be applicable to Internet of Things (loT) systems, for example, a radio access technology supporting a narrowband loT (NB-loT) communication scheme. The one or more terminal devices 104 may support one or more radio access technologies such as LTE, 5G or Wi-Fi as well as one or more carrier frequencies. The one or more terminal devices 104 support also one or more service types which depend on the properties of said terminal device (for example, which radio access tech- nologies/carrier frequencies are supported). Some or all of the terminal devices 104 may support multiple services/flows. In some scenarios, some or all of the terminal devices 104 may be situated inside a building or buildings and/or all the terminal devices may be situated outside. In some embodiments, some or all of the terminal devices 104 may follow pre-defined trajectories or tracks.

The positioning system 106 may be an indoor positioning system based on radio or non-radio navigation or tracking technologies. Radio navigation positioning system may use Wi-Fi, Bluetooth or any other suitable radio technology. Non-radio navigation may be based on, for example, optical, acoustical or magnetic positioning. The positioning system may also be an outdoor positioning system, for example, a receiver for a global navigation satellite system such as GPS (Global Positioning System) or for a mobile network positioning system or it may integrate multiple indoor and outdoor positioning systems forming a hybrid positioning system. The terminal devices 104 may be connected to the positioning system 106 wirelessly using any suitable radio access technology. A positioning system integrated into some or all terminal devices, for ex- ample, a GPS receiver, may also be used for the positioning of the terminal devices. Moreover, the MME 1 16 and/or the MCC 126 may also be connected to the positioning system 106 over an interface 198 so that the MME 1 16 and/or the MCC 126 are able to determine the positions of the terminal devices 104 directly. It should be appreciated that in another embodiment no separate positioning system is used but the location information of the wireless access network is used.

An exemplary embodiment of the data structure of the MCD is shown in Figure 2. In an embodiment, the MCD 200 comprises location-dependent multi-connectivity related information on network structure 240. In the illustrated example, the multi- connectivity related information 240 further comprises two types of information: policy data 232 and performance indicator data 230.

The policy data may be given region-specifically and/or service type specifically. A policy data set 212, 214, 222, 224, 226 for a specific service type in a specific region may comprise requirements for data rate, latency, reliability, bit error rate, error correction and/or other quantities critical to the operation of a communications link. Moreover, one or more Service Level Agreements (SLAs), which give strict limits to certain quantities critical for the operation of a particular terminal device within a particular area and time frame, may also be specified in the policy data set. SLAs may give limits, for example, to the outage probability, radio coverage probability and/or bit-error rate (BER). In other words, a policy data set defines service settings.

The policy data set definitions 212, 214, 222, 224, 226 may be stored service type -specifically in the MCD as shown in the exemplary embodiment of Figure 2. In the illustrated example, each of the z policy data sets corresponding to a certain service type 250, 252 further comprises / separate policy data sets for different regions in the environment, where z and / can be any natural numbers. The regions may be two-dimensional, defined by rectangles, circles and/or any other 2-dimensional shapes, or three-dimensional, defined by cubes, spheres and/or any other 3-dimensional shapes. For example, the regions may be defined as cubes by setting upper and lower limits to latitude, longitude and height. In some embodiments, some of the regions may be defined in two dimensions and some in three dimensions. In the embodiment of Figure 2, the regions are the same for service types 250, 252 though in some embodiments, the regions may be defined differently for different service types. This may be beneficial especially if the terminal devices support multiple flows/services with different service requirements. In some embodiments, each service type 250, 252 may also be dependent on time of day and/or date.

To give an example, the policy data for a service type may be given as a code in the following form: service_type_1 := SEQUENCE {

region 1 {

region_definition= {Iatitude_min1 , Iatitude_max1 , longitude_min1 , longi- tude_max1 , height_min1 , height_max1 },

datarate_requirement=high,

latency=uncritical,

reliability=low,

BER=10%,

SLA={provide min. 20Mbit/s, max. HARQ RTT 30ms}

}

region2 { region_definition= {Iatitude_min2, Iatitude_max2, longitude_min2, longi- tude_max2, height_min2, height_max2},

datarate_req uirement=low,

latency=very mission critical,

reliability=medium,

BER=5%,

SLA={max. u-plane latency 5ms,}

}

region3 {

region_definition= {Iatitude_min3, Iatitude_max3, longitude_min3, longi- tude_max3, height_min3, height_max3},

datarate_req uirement=low,

latency=uncritical,

reliability=very high,

BER=5%,

SLA={provide 99.99% coverage}

}

As can be seen from the above, the region definitions make the policy data sets location-dependent data sets. A terminal device receives for the service type 1 different service in different regions due to the different policy data sets applied in different regions for the service type 1 . Naturally, as illustrated in Figure 2, there are different policy data sets for different service types. While in this embodiment the regions are organized under the service type, in another embodiment, the hierarchy between region and service type may be switched, that is, service types may be defined separately for each region. In embodiments which include time-dependence in policy definitions, the hierarchy between location, service type and time may be defined similarly to have any order.

In this example, the SLAs differ drastically for the three defined regions. In region 1 , achieving high capacity at all times is the priority. As latency is not a critical factor for this region, the MCC may employ HARQ (hybrid automatic repeat request) error correcting/coding method to improve transmission though a limit is set for the maximum HARQ RTT (round-trip time). In region 2, latency must be kept to an absolute minimum. Therefore, the MCC may be configured to determine that HARQ is not used in this region and a more robust, i.e., lower, multi-connectivity service is used in order to better enforce the given latency requirements. In region 3, the outage probability must be minimized, that is, the reliability must be very high. The MCC may employ HARQ also in this case.

It should be appreciated that the policy data sets may comprise other definitions, such as a time of a day when the policy data is to be applied.

The performance indicator data 230 of different radio access networks may be fed to the MCD via the primary interface from the MME. In general, the primary interface may be used for feeding and/or retrieving data. Naturally, in some embodi- ments, the resulting data may be fed to the database also via the secondary interface.

In the illustrated embodiment, the performance indicator data 230 comprises xcoverage maps 202, 204, where xcan be any natural number. A coverage map defines a coverage area within which a service provided by an access node is available with the service probability above a certain threshold and provides information on the expected quality of said service within said coverage area. For example, a coverage map may contain information on the average electric field strength or the expected data rate within the coverage area. A separate coverage map is defined not only for each access node, but also for each radio access technology (RAT) and carrier frequency which the access node employs. Since the performance indicator data is defined cell- specifically, i.e., service area -specifically, the performance indicator data may comprise location-dependent information on maximum data rate, latency, bit-error rate and/or any other Quality of Service (QoS) indicators.

The performance indicator data can be calculated or collected in multiple ways. Network/radio planning may calculate said data based on the location information of the access nodes and the expected coverage of said access nodes, possibly utilizing advanced software-based tools such as ray tracing and radio propagation simulation software. Alternatively, one or more drive tests may be conducted using a terminal device capable of supporting a plurality of radio access technologies and carrier frequencies or drive test measurement equipment. A plurality of terminal measurements may also be conducted at a plurality of locations with the terminal devices used in the access network. Moreover, two or more of the methods may be used in parallel.

After the initial performance indicator data needed for the database has been calculated or measured and stored to the MCD, supplemental terminal measure- merits may still be conducted if, for example, the environment has changed or if additional access nodes have been deployed after the initial data collection. The resulting data may be used to update and further optimize the coverage maps. In some embodiments, this process may be automated.

Figure 3 illustrates a process executed by the MCC for updating the coverage maps. First, the MCC receives in block 300 location information and measured performance indicator data from a terminal device. Here, the measured performance indicator data may correspond to one or more radio access technologies supported by the terminal device and may comprise information on maximum data rate, latency, bit- error rate and/or any other QoS indicators provided by one or more access nodes to the terminal device. Based on the location information, the current performance indicator data stored in the MCD for the location of the terminal device is retrieved from the MCD in block 302. Thereafter, the current performance indicator data stored in the MCD is compared in block 304 to the measured performance indicator data. If one or more current performance indicator value deviates from the corresponding measured performance indicator value by more than a pre-defined threshold value in block 320, the corresponding one or more coverage maps in the MCD are retrieved and updated accordingly in block 306. In some embodiments, one or more deviating performance indicator values for a given location need to be detected by two or more terminal devices before the coverage map is retrieved and updated.

Once the data needed for the MCD has been collected, constant terminal measurements and reporting back to the MME may not be necessary anymore for all the supported RATs and carrier frequencies and/or it may not be necessary or sensible to keep conducting measurements with the same measurement interval as before. Therefore, the MCC may, in such a case, send a command to the terminal device to reduce the monitoring activity. Similarly, if further measurements are again required, the MCC may send a command to the terminal device to increase the monitoring activity.

As described above, the terminal device may be within the coverage area of two or more cells. Therefore, it may be advantageous if two or more cells may be utilized in wireless transmission between the terminal device and the core network, that is, if a multi-connectivity scheme can be employed. Figure 4 illustrates a process executed by the MCC for determining the multi-connectivity mode for the terminal device. In the illustrated example it is assumed that only one service type is in use and there are no time-dependent settings, i.e., the policy data sets are only area-specific, not service type and area-specific.

Referring to Figure 4, upon receiving in block 400 location information from a terminal device or directly from the positioning system, the MCC retrieves in block 402, using the location information, location-dependent multi-connectivity related information from the MCD. The location-dependent multi-connectivity related information may comprise performance indicator data and/or policy data. Based on the received location-dependent multi-connectivity related information, the MCC determines in block 404 a multi-connectivity mode for the terminal device using a mapping function. For example, if only one radio coverage is available at the location, the multi-connectivity mode is "no multi-connectivity", whereas if two or more radio coverages are available, the multi-connectivity mode may be employed, and more detailed mode settings may be deduced from the received information. Once the multi-connectivity mode is determined, sending the multi-connectivity mode for the terminal device is caused in block 408.

Another embodiment of the process for determining the multi-connectivity mode for the terminal device is presented in Figure 5. In the example, it is assumed that a plurality of service types are in use.

Referring to Figure 5, the process comprises receiving in block 500 in the MCC location information from the terminal device or from the positioning system and information on the service type supported by the terminal device from the terminal device. The MCC retrieves in block 502, using the location information and the service type, location-dependent multi-connectivity related information from the MCD. The location-dependent multi-connectivity related information may comprise performance in- dicator data and policy data. If the location-dependent multi-connectivity related information is observed in block 520 to comprise time-dependent settings, the current time is determined in block 504 by the MCC. Based on the time and the received location- dependent multi-connectivity related information, the MCC determines in block 506 a multi-connectivity mode for the terminal device using a mapping function, as described above but using only the location-dependent multi-connectivity related information that is valid at the current time. Once the multi-connectivity mode is determined, sending the multi-connectivity mode for the terminal device is caused in block 508. If no time- dependence is observed in the location-dependent multi-connectivity related information in block 520, the MCC determines in block 510 a multi-connectivity mode for the terminal device, as described above only based on the received location-dependent multi-connectivity related information. Once the multi-connectivity mode is determined, sending the multi-connectivity mode and an updated measurement command for the terminal device is caused in block 512. The updated measurement command directs the terminal device to restrict its measurement activity (i.e., monitoring) to radio access technologies and carrier frequencies which are necessary to the operation of the multi- connectivity mode which leads to a reduction in reporting activity and savings in power consumption for the terminal device.

The multi-connectivity mode may include one of the following settings: inter- frequency aggregation for two or more access nodes supporting two or more carrier frequencies and one or more radio access technologies, intra-frequency aggregation for two or more access nodes supporting one or more radio access technologies, duplication for two or more access nodes supporting one or more carrier frequencies and one or more radio access technologies, any combination of the aforementioned modes and exclusive service by a single access point.

The multi-connectivity functionalities listed above will be explained in more detail below. It should be appreciated that the settings listed above and described here in detail are mere examples and the multi-connectivity mode may comprise other functionalities. In inter-frequency aggregation or inter-frequency carrier aggregation, one or more access nodes use two or more different frequency bands in unison for establishing communication between the terminal device and the core network. Inter-frequency aggregation may be implemented, for example, as a split in PDCP (Packet Data Convergence Protocol) layer in LTE or UMTS. In intra-frequency aggregation, a single frequency band is used with two or more access nodes to service a single terminal device. A single access node providing multiple cells for the same carrier frequency may also be used for intra-frequency aggregation. Intra-frequency aggregation can be contiguous and non-contiguous. In the simpler contiguous intra-frequency aggregation, component carriers (CCs) are adjacent to each other and the multi-carrier signal can be treated effectively as a single signal. For non-contiguous intra-frequency aggregation, where the CCs are separated by a gap in frequency, this is not the case. Therefore, two transceivers are typically required in the terminal device to realize non-contiguous intra-frequency aggregation. The additional bandwidth attained with aggregation may be used to increase the data rate and improve network performance. In duplication, the same signal is sent to the terminal device by two or more access nodes using one or more carrier frequencies in order to provide redundancy, that is, increase reliability due to diversity gain. Duplication may be implemented, for example, as a split in MAC (medium access control) layer. Different aggregation methods and duplication may also be used simultaneously if more than two access nodes are available. In some scenarios, for example, if the signal from a particular access node is very dominant and/or if latency requirement is very strict, it may be the best option to forgo the multi-connectivity altogether even if other access nodes are available.

The MCC determines the multi-connectivity mode based on a mapping function which takes as its input at least policy data and performance indicator data and produces as its output the multi-connectivity mode of the terminal device. The mapping function is defined in advance by network/radio planning, for example, based on results from Radio Resource Management (RRM) emulators. The resulting mapping function may be implemented in the MCC by storing a plurality of pre-calculated multi-connectivity mapping rules to the MCD as illustrated in the embodiment of Figure 1 . Alterna- tively, Radio Resource Management (RRM) emulators or other analysis tools for determining and/or employing the mapping function may be implemented directly in the MCC in which case the MCC may conduct all the calculations autonomously.

In an embodiment, the location-dependent multi-connectivity related information comprises information on the future locations of the terminal device. Naturally, this type of information cannot be easily attained for any arbitrary scenario. For example, a mobile phone of a customer in a shopping mall may change movement direction at any moment. However, if the terminal device moves following a predefined track or trajectory or in an otherwise predictable way, the future location of the terminal device may be predicted in a meaningful way. Many such scenarios are industrial in nature. The terminal devices may be operated, for example, inside or in the vicinity of a factory/manufacturing environment. A forklift unloading a cargo trailer and transporting the cargo to a high-rise rack in a warehouse along known pathways is one example of such a scenario. By taking advantage of the future location information, the multi-connectivity settings can be prepared well in advance, i.e., before the terminal is entering an area which requires a modification of the multi-connectivity settings.

The process for determining the multi-connectivity mode for the terminal device presented in Figure 6 represents an embodiment where the terminal device is moving along a pre-defined trajectory. The process is similar to the process depicted in Figure 5 apart from the following considerations. It is assumed in this case that the information on the predefined trajectories of the terminal devices comprising a set of coordinate values is stored to the MCD and the policy information may include time- dependent settings. Once the location and service type information is received in block 600 by the MCC, the location-dependent multi-connectivity related information for the current location of the terminal device is retrieved in block 602 by the MCC, similar to the previous embodiments. However, in addition to this information, the MCC is also configured to retrieve in block 604 the location-dependent multi-connectivity related information for a set of one or more consecutive future positions of the terminal device along the pre-defined trajectory of the terminal device. The location-dependent multi- connectivity related information performance comprises indicator data and policy data in both cases. The spacing between consecutive future positions may be defined in time and/or space. In an embodiment, said positions may be defined as a set upper and lower coordinate limits in two- or three dimensions. In this case, the performance indicator data and policy data for the positions may be defined, for example, by averaging performance indicator values over said limits and by choosing the prevailing policy for said limits, respectively. If the location-dependent multi-connectivity related information is observed to comprise in block 620 time-dependent settings, the current time is determined in block 606 by the MCC. In blocks 606 and 610, the performance indicator data and policy data for the current position and the set of one or more future consecutive positions is used by the MCC to determine the multi-connectivity mode for the terminal device using a mapping function. The mapping function takes in this case also as an input the performance indicator data and policy data corresponding to a set of consecutive future positions along the trajectory of the terminal device. Alternatively, the MCC may be configured to determine the multi-connectivity mode for the current position and the set of one or more consecutive future positions separately using a simpler mapping function similar to the one used in conjunction with Figure 5 and to determine the decisive multi-connectivity mode based on the results of said calculations. Once the multi- connectivity mode is determined, sending the multi-connectivity mode and an update measurement command for the terminal device is caused in block 610 or 614.

In order to illustrate how the MCC may be configured to determine the multi- connectivity mode using the mapping function in different scenarios, an exemplary embodiment of a radio access network to which the method can be applied is presented in Figure 7. In the illustrated example, a terminal device moves along a path 701 and the multi-connectivity mode is determined for the terminal device by the MCC at particular locations denoted by 722, 724, 726, 728, 790. The three policy regions 750, 760, 770 shown in Figure 7 correspond to the three policy regions defined in the exemplary code above. In this embodiment, the environment comprises three macro cells 782, 788, 790 and two small cells 784, 786 which each correspond to one of the three frequencies supported by the terminal device and may be partially overlapping with each other. The small cells 784, 786 may be indoor or outdoor small cells. Furthermore, it is assumed that the terminal device supports service type 1 and the movement trajectory of the terminal device is pre-defined and stored in the MCD. However, it is a straight- forward process for one skilled in the art to implement the example of Figure 7 to freely moving terminal devices.

As described earlier, in region 1 the data rate should be optimized while requirements for latency and reliability are lenient. Three locations of the terminal device 722, 724, 726 are within region 1 , each representing a different scenario for multi- connectivity. In the first location 722, the terminal device is only within the coverage area 782 of one access node 702. Therefore, no multi-connectivity is possible and the SLAs for the region have to be achieved, for example, via scheduling mechanisms. In the second location 724, the terminal device is served by two access nodes 702, 704 corresponding to a macro cell 782 and a small cell 784 operating at different carrier frequencies (frequencies 1 and 2, respectively). Therefore, the MCC may be configured in this case to select inter-frequency aggregation in order to maximize the data rate. In the third location 726, the terminal device is serve by three access nodes 702, 704, 708 corresponding to two macro cells 782, 788 for frequency 1 and a micro cell 784 for frequency 2. Therefore, the MCC may be configured to select a combination of both inter- and intra-frequency aggregation in this case to maximize data rate. The MCC could be configured also to select duplication here in conjunction with either inter- or intra-frequency aggregation, but as the reliability of the link is of little interest in this example, the SLAs are more likely fulfilled when all the access nodes implement aggregation.

In region 2, latency must be kept to a minimum while requirements for data rate and reliability are low and moderate, respectively. In the fourth location 728, the terminal device is within region 2, next to an access node 706 corresponding to a small cell 786 and supporting frequency 3. Moreover, the terminal device is also served by the access node 708 corresponding to the macro cell 788. Due to the strict latency requirement for this region, the MCC may be configured to determine that the SLA can be best met if the terminal device is served exclusively by the near-by access node 706. However, when the terminal device reaches the fifth location 730, there is no more latency benefit in using the access node exclusively as the access nodes 706, 708 are equally close to the terminal device. Knowing that the terminal device will soon go out of coverage of the access node 706, the MCC may be configured to select duplication between the two available access nodes 706, 708 to ensure uninterrupted transmission.

Finally, in region 3, outage probability must be very small (that is, reliability must be very high) while the requirements for latency and data rate are lenient. When the terminal device is in the sixth location 732, requirements can be best achieved if the MCC is configured to select duplication between the two available access nodes 708, 710 corresponding to macro cells 788, 790 which both support frequency 1 .

If the terminal device is only within the coverage area of a single access node or in some cases even if multi-connectivity is utilized, it may occur that the required service level defined in the SLAs cannot be reached at a given location. In other words, at least one performance indicator value for the given location is below a limit defined in the service requirements (i.e., SLAs) of the terminal device. In an embodiment, the supplemental terminal device measurements, described above in connection with forming/updating the coverage maps, may be used to prevent such occurrences. Instead of modifying the coverage maps based on the measurements, the radio access networks themselves may be modified in this case.

An embodiment of the method is presented in Figure 8. First, the MCC receives location information and measured performance indicator data from a terminal device in block 800. Here, the measured performance indicator data may correspond to the terminal device being served by a single access node or by two or more access nodes utilizing a multi-connectivity mode. Based on the location information, the policy data stored in the MCD corresponding to the location of the terminal device is retrieved from the MCD in block 802. Thereafter, the SLAs defined in the policy data are compared to the measured performance indicators in block 804. If one or more SLAs are not satisfied based on the measured performance indicator data in block 820, the MCC retrieves information on the network from the MCD in block 806 and based on this information calculates in block 808 a deployment suggestion for satisfying the SLAs using a set of deployment rules stored to the MCD. Finally, the MCC sends the deployment suggestion to the O&M in block 810. The information on the network may comprise a plurality of performance indicator and policy data sets contained in the MCD corresponding to a plurality of locations surrounding the location of the terminal device. The deployment rules are defined beforehand by the network/radio planning, for example, based on results from RRM emulators and/or measurements and knowledge of the lo- cation dependent service requirements. The deployment suggestion provided by the MCC may be, for example, that another small cell could be deployed near the location where the problem occurred, that one or more access nodes could be shifted to the direction of the problem location, that the settings of one or more access nodes could be changed or a combination of one or more said functionalities. For example, if the terminal device detects that one or more QoS indicators fall below one or more SLAs for a short time, the MCC may suggest relocating one or more existing access nodes or adjusting the down-tilt of one or more base station antennas to bridge the coverage gap. However, if the problem is more severe and the service quality drops below the level defined in the SLAs for a longer time, the MCC may suggest deploying a new access node. In some embodiments, one or more failures to satisfy the SLAs for a given location need to be detected by two or more terminal devices before the deployment suggestion is calculated and sent to the O&M. In some embodiments, instead of calculating a deployment suggestion and sending it to the O&M, the MCC may only send information on the service deficiency, comprising the location information, the policy data and the measured performance indicator data, to the O&M.

Although in the above the embodiments and examples are described for a situation in which one service with one data flow is in use, it should be appreciated that the processes may be performed service and/or data flow -specifically.

The blocks, related functions, and information exchanges described above by means of Figures 2 to 8 are in no absolute chronological order, and some of them may be performed simultaneously or in an order differing from the given one. For example, the process for updating the coverage maps presented in Figure 3 may be run simultaneously or at different times with the process presented in any of the Figures 4- 6. In the latter case, the process presented in any of the Figures 4-6 may, for example, be run first for a certain amount time after which it is interrupted and the process presented in Figure 3 is run alone to update the coverage map to account for changes in the environment and/or deployment. Naturally similar processes for several terminal devices may run in parallel. Other functions can also be executed between the blocks and related functions or within them, and other information may be sent. For example, in implementation in which the MCD or any corresponding database is external to the MCC, updating of the mapping function or mapping rules may take place, and/or cloud computing may be used, possibly requiring some additional functions. Some of the blocks or part of the blocks or one or more pieces of information can also be left out or replaced by a corresponding block or part of the block or one or more pieces of information. For example, if two processes are run one after another, the MCC may already have received or retrieved some of the data needed for running the latter process while running the former process and therefore the corresponding blocks in the flow diagram of the latter process may be omitted.

Figure 9 illustrates an apparatus configured to carry out the functions described above in connection with the MCC 126. The apparatus may be an electronic device comprising electronic circuitries. The apparatus may be the MCC 126 or it may be comprised in or be applicable to the MCC 126. The apparatus may comprise the MCD 136. The apparatus may be a separate network entity or a plurality of separate entities. The apparatus may be connected to a network controller 1 16 or comprised fully or partly in the network controller 1 16. The apparatus may comprise a communication control circuitry 900 such as at least one processor, and at least one memory 904 including a computer program code (software) 910 wherein the at least one memory and the computer program code (software) are configured, with the at least one processor, to cause the apparatus to carry out any one of the embodiments of the MCC and MCD described above.

The memory 904 may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The memory may comprise a database 914 which may comprise a multi-connectivity database for storing location-dependent multi-connectivity related information as described in previous embodiments. In some embodiments, the multi- connectivity related information may also be dependent of the service-type of the terminal device and/or time. The database 914 may further comprise the multi-connectivity mapping function(s) and/or means for calculating the deployment suggestions, for example, a set of deployment rules. The database may also comprise information on the trajectories of the terminal devices. The memory 904 may also comprise other databases which may not be related to multi-connectivity functionalities. The memory 904 may be connected to the communication control circuitry 900 via an interface. Another interface to the memory 904 may also be provided.

The apparatus may further comprise a communication interface (Tx/Rx) 902 comprising hardware and/or software for realizing communication connectivity according to one or more communication protocols. The communication interface may provide the apparatus with communication capabilities to communicate in the cellular communication system and enable communication with other access nodes and terminal devices, for example. The communication interface 902 may comprise standard well- known components such as an amplifier, filter, frequency-converter, (de)modulator, and encoder/decoder circuitries and one or more antennas. The communication interface 902 may comprise radio interface components providing the apparatus with radio communication capability in the cell.

Referring to Figure 9, the communication control circuitry 900 may comprise multi-connectivity control circuitry 920 configured to determine multi-connectivity modes for terminal devices. The multi-connectivity control circuitry 920 further comprises infor- mation retrieval circuitry 922 and multi-connectivity mode determination circuitry 924. The information retrieval circuitry 922 is configured to retrieve multi-connectivity related information from the database 914, or from a corresponding external database. This retrieval may be conducted based on information received by the apparatus on the terminal device, for example, location and/or service-type of the terminal device. The in- formation retrieval circuitry 922 may be configured to carry out blocks 302, 402, 502 or 602 described above. The multi-connectivity mode determination circuitry 924 is configured to determine the multi-connectivity mode for the terminal device based on the information retrieved by the information retrieval circuitry 922. The multi-connectivity mode determination circuitry 924 may be configured to carry out block 404, blocks 506 and 510 or blocks 608 and 612 described above. Blocks 520 and 504 or blocks 620 and 606 may be performed also by either the information retrieval circuitry 922 or the multi-connectivity mode determination circuitry 924 or by a third set of circuitry comprised in the communication control circuitry 900. The multi-connectivity control circuitry 920 may also comprise circuitry for carrying out blocks 320 and 306. The information retrieval circuitry 922 and the multi-connectivity mode determination circuitry may be configured to carry out MCC functionality described with Figure 8

As used in this application, the term 'circuitry' refers to all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of circuits and soft-ware (and/or firmware), such as (as applicable): (i) a combination of processor(s) or (ii) portions of processors/software including digital signal processor(s), software, and memory(ies) that work together to cause an apparatus to perform various functions, and (c) circuits, such as a microprocessor(s) or a portion of a microprocessor(s), that require software or firmware for operation, even if the software or firmware is not physically present. This definition of 'circuitry' applies to all uses of this term in this application. As a further example, as used in this application, the term 'circuitry' would also cover an implementation of merely a processor (or multiple processors) or a portion of a processor and its (or their) accompanying software and/or firmware. The term 'circuitry' would also cover, for example and if applicable to the particular element, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in a server, a cellular network device, or another network device.

In an embodiment, at least some of the processes described in connection with Figures 2 to 8 may be carried out by an apparatus comprising corresponding means for carrying out at least some of the described processes. Some example means for carrying out the processes may include at least one of the following: detector, processor (including dual-core and multiple-core processors), digital signal processor, controller, receiver, transmitter, encoder, decoder, memory, RAM, ROM, software, firmware, display, user interface, display circuitry, user interface circuitry, user interface software, display software, circuit, antenna, antenna circuitry, and circuitry. In an embodiment, the at least one processor, the memory, and the computer program code form processing means or comprises one or more computer program code portions for carrying out one or more operations according to any one of the embodiments of Figures 2 to 8 or operations thereof.

The techniques and methods described herein may be implemented by various means. For example, these techniques may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or combinations thereof. For a hardware implementation, the apparatus(es) of embodiments may be implemented within one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof. For firmware or software, the implementation can be carried out through modules of at least one chipset (procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory unit and executed by processors. The memory unit may be implemented within the processor or externally to the processor. In the latter case, it can be communicatively coupled to the processor via various means, as is known in the art. Additionally, the components of the systems described herein may be rearranged and/or complemented by additional components in order to facilitate the achievements of the various aspects, etc., described with regard thereto, and they are not limited to the precise configurations set forth in the given figures, as will be appreciated by one skilled in the art.

Embodiments as described may also be carried out in the form of a computer process defined by a computer program or portions thereof. Embodiments of the methods described in connection with Figures 2 to 8 may be carried out by executing at least one portion of a computer program comprising corresponding instructions. The computer program may be in source code form, object code form, or in some interme- diate form, and it may be stored in some sort of carrier, which may be any entity or device capable of carrying the program. For example, the computer program may be stored on a computer program distribution medium readable by a computer or a processor. The computer program medium may be, for example but not limited to, a record medium, computer memory, read-only memory, electrical carrier signal, telecommuni- cations signal, and software distribution package, for example. The computer program medium may be a non-transitory medium. Coding of software for carrying out the embodiments as shown and described is well within the scope of a person of ordinary skill in the art.

Even though the invention has been described above with reference to an example according to the accompanying drawings, it is clear that the invention is not restricted thereto but can be modified in several ways within the scope of the appended claims. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment. It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be imple- mented in various ways. Further, it is clear to a person skilled in the art that the described embodiments may, but are not required to, be combined with other embodiments in various ways.

Claims

1 . A method comprising

receiving in a network node, location information on a terminal device; retrieving by the network node, using the location information, location-dependent multi-connectivity related information;

determining by the network node, based the location-dependent multi-connectivity related information, a multi-connectivity mode for the terminal device; and causing sending the multi-connectivity mode for the terminal device to the terminal device.

2. A method according to claim 1 , further comprising:

receiving in the location-dependent multi-connectivity related information a policy data set and one or more sets of performance indicators, wherein the policy data set defines service settings in the location and a set of performance indicators defines performance of a radio access network in the location; and

using both the policy data set and the one or more sets of performance indicators when determining the multi-connectivity mode.

3. A method according to claim 1 or 2, further comprising:

receiving in the network node information on the service type supported by the terminal device from the terminal device; and

using also the service type when performing said retrieving.

4. A method according to any preceding claim, further comprising:

receiving in the location-dependent multi-connectivity related information one or more time-dependent settings; and

using the time of day when selecting which ones of the time-dependent settings to use when performing said determining a multi-connectivity mode for the terminal device.

5. A method according to any preceding claim, further comprising using a mapping function to determine the multi-connectivity mode.

6. A method according to claim 5, wherein the mapping function comprises a plurality of pre-stored mapping rules.

7. A method according to any preceding claim, further comprising causing sending an updated measurement command to the terminal device.

8. A method according to any preceding claim, further comprising:

retrieving, using future location information determined from a predefined trajectory for the terminal device, one or more sets of future location-dependent multi- connectivity related information; and

using also the one or more sets of future location-dependent multi-connectivity related information when determining the multi-connectivity mode for the terminal device.

9. A method according to any of claims 2 to 8, further comprising: receiving, in a network node, information on the measured performance in- dicators of the terminal device;

comparing the measured performance indicators of the terminal device to the service settings in the policy data set for the terminal device; and

causing, in response to the measured performance indicators failing to satisfy service requirements defined in the service settings, sending at least the information on the measured performance indicators of the terminal device and corresponding location information to an operations and maintenance center.

10. A method according to any of claims 2 to 8, further comprising:

receiving, in a network node, information on the measured performance indicators of the terminal device;

comparing the measured performance indicators of the terminal device to the service settings in the policy data set for the terminal device;

retrieving, in response to the measured performance indicators failing to satisfy service requirements defined in the service settings, by the network node, sets of performance indicators defining performance of one or more radio access networks for a plurality of locations surrounding the location of the terminal device;

determining a deployment suggestion based on retrieved sets of performance indicators and the information on the measured performance indicators of the terminal device, wherein the deployment suggestion comprises one or more of the following: introducing one or more additional access nodes, relocating one or more exist- ing access nodes and changing the settings of one or more existing access nodes; and causing sending the deployment suggestion to an operations and maintenance center.

1 1 . An apparatus comprising:

at least one processor, and at least one memory comprising a computer program code, wherein the processor, the memory, and the computer program code are configured to cause the apparatus to:

retrieve, upon receiving location information on a terminal device, using the location information, location-dependent multi-connectivity related information;

determine, based on the location-dependent multi-connectivity related information, a multi-connectivity mode for the terminal device; and

cause sending the multi-connectivity mode for the terminal device to the terminal device.

12. The apparatus of claim 1 1 , wherein the processor, the memory, and the computer program code are further configured to cause the apparatus to use a policy data set and one or more sets of performance indicators received in the location-dependent multi-connectivity related information to determine the multi-connectivity mode for the terminal device, wherein the policy data set defines service settings in the location and a set of performance indicators defines performance of a radio access network in the location.

13. The apparatus according to any of claims 1 1 or 12, wherein the processor, the memory, and the computer program code are further configured to cause the apparatus to use, in response to receiving information on a service type supported by the terminal device, also the service type when performing said retrieving.

14. The apparatus of according to any of claims 1 1 -13, wherein the processor, the memory, and the computer program code are further configured to cause the apparatus to use, in response to receiving in the location-dependent multi-connectivity related information one or more time-dependent settings, the time of day when selecting which ones of the time-dependent settings to use when performing said determining a multi-connectivity mode for the terminal device.

15. The apparatus according to any of claims 1 1 -14, wherein the processor, the memory, and the computer program code are further configured to cause the apparatus to use a mapping function to determine the multi-connectivity mode.

16. The apparatus according to claim 15, wherein the mapping function comprises a plurality of pre-stored mapping rules.

17. The apparatus according to any of claims 1 1 -16, wherein the processor, the memory, and the computer program code are further configured to cause the apparatus to cause sending an updated measurement command to the terminal device.

18. The apparatus according to any of claims 1 1 -17, wherein the processor, the memory, and the computer program code are further configured to:

retrieve, using future location information determined from a predefined trajectory for the terminal device, one or more sets of future location-dependent multi- connectivity related information; and

use also the one or more sets of future location-dependent multi-connectivity related information when determining the multi-connectivity mode for the terminal device.

19. The apparatus according to any of claims 12-18, wherein the processor, the memory, and the computer program code are further configured to:

compare, upon receiving information on the measured performance indicators of the terminal device, the measured performance indicators of the terminal device to the service settings in the policy data set for the terminal device; and

cause, in response to the measured performance indicators failing to satisfy service requirements defined in the service settings, sending at least the information on the measured performance indicators of the terminal device and corresponding location information to an operations and maintenance center.

20. The apparatus according to any of claims 12-18, wherein the processor, the memory, and the computer program code are further configured to:

compare, upon receiving information on the measured performance indicators of the terminal device, the measured performance indicators of the terminal device to the service settings of the terminal device in the location;

retrieve, in response to the measured performance indicators failing to satisfy service requirements defined in the service settings, sets of performance indica- tors defining performance of one or more radio access networks for a plurality of locations surrounding the location of the terminal device;

determine a deployment suggestion based on retrieved sets of performance indicators and the information on the measured performance indicators of the terminal device, wherein the deployment suggestion comprises one or more of the following: introducing one or more additional access nodes, relocating one or more existing access nodes and changing the settings of one or more existing access nodes; and

cause sending the deployment suggestion to an operations and maintenance center.

21 . An apparatus comprising means for carrying out the method ac-cording to any one of claims 1 -10.

22. A non-transitory computer readable media having stored thereon instructions that, when executed by a computing device, cause the computing device to:

23. A non-transitory computer readable media according to claim 22, having stored thereon further instructions that, when executed by a computing device, cause the computing device further to use a policy data set and one or more sets of performance indicators received in the location-dependent multi-connectivity related infor- mation to determine the multi-connectivity mode for the terminal device, wherein the policy data set defines service settings in the location and a set of performance indicators defines performance of a radio access network in the location.

24. A non-transitory computer readable media according to any of claims 22-23, having stored thereon further instructions that, when executed by a computing device, cause the computing device further to cause the apparatus to use, in response to receiving information on a service type supported by the terminal device, also the service type when performing said retrieving.

25. A non-transitory computer readable media according to any of claims 22-24, having stored thereon further instructions that, when executed by a computing device, cause the computing device further to use, in response to receiving in the location-dependent multi-connectivity related information one or more time-dependent settings, the time of day when selecting which ones of the time-dependent settings to use when performing said determining a multi-connectivity mode for the terminal device.

26. A non-transitory computer readable media according to any of claims 22-25, having stored thereon further instructions that, when executed by a computing device, cause the computing device further to use a mapping function to determine the multi-connectivity mode.

27. A non-transitory computer readable media according to claim 26, wherein the mapping function comprises a plurality of pre-stored mapping rules.

28. A non-transitory computer readable media according to any of claims 22-27, having stored thereon further instructions that, when executed by a computing device, cause the computing device further to cause sending an updated measurement command to the terminal device.

29. A non-transitory computer readable media according to any of claims

22-28, having stored thereon further instructions that, when executed by a computing device, cause the computing device further to:

30. A non-transitory computer readable media according to any of claims 23-29, having stored thereon further instructions that, when executed by a computing device, cause the computing device further to:

31 . A non-transitory computer readable media according to any of claims 23-29, having stored thereon further instructions that, when executed by a computing device, cause the computing device further to:

retrieve, in response to the measured performance indicators failing to satisfy service requirements defined in the service settings, sets of performance indicators defining performance of one or more radio access networks for a plurality of locations surrounding the location of the terminal device; determine a deployment suggestion based on retrieved sets of performance indicators and the information on the measured performance indicators of the terminal device, wherein the deployment suggestion comprises one or more of the following: introducing one or more additional access nodes, relocating one or more existing ac- cess nodes and changing the settings of one or more existing access nodes; and

32. A computer program product comprising program instructions configuring a network node to perform a method according to any of claims 1 -10 when the computer program is run.