Traitement en cours

Veuillez attendre...

Paramétrages

Paramétrages

Aller à Demande

1. WO2020164697 - DISPOSITIFS POUR OPTIMISATION DE RESSOURCES DE RÉSEAU D'ACCÈS RADIO

Note: Texte fondé sur des processus automatiques de reconnaissance optique de caractères. Seule la version PDF a une valeur juridique

[ EN ]

DEVICES FOR RADIO ACCESS NETWORK RESOURCE OPTIMIZATION

TECHNICAL FIELD

The present disclosure relates to resource optimization methods for a Radio Access Network (RAN). In particular, the disclosure presents a device for resource optimization of the RAN, and presents another device for supporting the resource optimization of the RAN. The resource optimization of the RAN bases on the exchange of location information, of one or more wireless communication devices in the RAN, on RAN level or between Core Network (CN) and RAN.

BACKGROUND

Recently, a new RAN study item on“ RAN-centric Data Collection and Utilization for NR” was approved, wherein both traditional Self-Organizing Network (SON) functions and some new use cases for RAN resource optimization methods are for 5G. SON functions include, for example, Mobility Robustness Optimization (MRO), Mobility Load Balancing (MLB) optimization, Random Access Channel (RACH) optimization, as well as Energy Saving.

Furthermore, Radio Resource Management (RRM) functions, as defined in TS36.300, consider the optimization of RAN resources either per user, or per cell (granularity). Among these RRM functions, for example, Dynamic Resource Allocation (DRA), Interference Coordination (ICIC), Connection Mobility Control (CMC), Radio Bearer Admission and Control (RAC, RBC), Energy Efficiency (EE), Load Balancing (LB), Inter node Coordination Multipoint (CoMP) either operate at the Media Access Control (MAC) layer dynamically, or above the Packet Data Convergence Protocol (PDCP) coordinating between multiple access nodes. In 5G, the RRM function can be either performed at a Base Station (BS), or parts of it can be virtualized e.g. in centralized cloud processing units. This centralization may optimize the RAN performance. However, this will also impact negatively on the complexity and the signaling overhead.

Both the RRM functions and the SON functions provide optimization of the RAN, particularly of RAN resources. These functions take as input radio related measurements and other information from the CN, e.g. policies, and from the Operation, Administration, Maintenance (OAM), e.g. configurations.

In 4G, the location information (e.g. a geographical position) of a wireless communication device, particularly of a User Equipment (UE), is not available in the Evolved Universal Terrestrial RAN (E-UTRAN). For the particular use case of Vehicle-to-Everything (V2X), the V2X sidelink resource allocation can be possible with UE location assistance: In particular, TS 36.300, 23.14.1 states: fin order to assist the eNB to provide sidelink resources, the UE in RRC CONNECTED may report geographical location information to the eNB. The eNB can configure the UE to report the complete UE geographical location information based on periodic reporting via the existing measurement report signaling”. However, the main drawback here is that a reliable location information of the UE may not always be available, especially for non-vehicle type UEs.

In 5G, discussions are ongoing. However, a hierarchical Location Service (LCS) architecture was recently proposed in [TR 23.731] In this architecture, a Location Management Function (LMF) is defined as a centralized location server in the CN. In addition, a Location Management Component (LMC) is defined as a distributed location server function in RAN/UE. Hence, the location information of a UE can be obtained at the LMC in the RAN.

SUMMARY

In view of the above, embodiments of the present invention aim to improve the current implementations for resource optimization in RAN. An objective is in particular to provide devices and methods that are able to provide more precise resource optimization of the RAN, particularly in 5G. To this end, embodiments of the invention intend to provide a device implementing an enhanced SON and/or RRM function. Further, embodiments of the invention also intend to provide a device implementing an enhanced LMC and/or LMF.

The objective is achieved by the embodiments of the invention as described in the enclosed independent claims. Advantageous implementations of the present invention are further defined in the dependent claims.

In particular, embodiments of the invention propose that accurate user locations (or group user locations), i.e. generally location information of one or more wireless communication devices, is used as an input for a RAN resource optimization method. The location information can e.g. be used by the enhanced SON and/or RRM function, and can be provided by an enhanced distributed location server/function (e.g. LMC or distributed LMF), which reside in RAN or a distributed CN entity. Embodiments of the invention thus allow for a faster and more precise RAN resource optimization and mobility enhancement, and can further exploit the benefits of virtualized RRM/SON functions. The location information can be used on demand, in order to optimize the RAN resources.

Embodiments of the invention thus use LMC as a means of improving resource management. This can be of major importance, for instance, for Ultra-Reliable Low-Latency Communication (URLLC), where the critical latency and reliability Key Performance Indicators (KPIs) require fast actions to avoid service discontinuity. Therefore, RAN functions (like RRM and SON functions) are optimized in embodiments of the invention by taking into account precise UE and/or group-UEs positions.

A first aspect provides a device for resource optimization of a RAN, the device being configured to: obtain location information related to at least one wireless communication device in the RAN, particularly at least one UE, perform a RAN resource optimization method based on the obtained location information.

By taking into account the location information, the RAN resource optimization method can be performed more precisely. The location information can be used as needed, e.g. on demand, in order to better optimize the RAN resources.

In an implementation form of the first aspect, the location information is related to one UE or to a group of UEs.

In an implementation form of the first aspect, the location information includes at least one of: a position of the at least one wireless communication device, an identification, ID, or a group ID of the at least one wireless communication device, an accuracy of the position of the at least one wireless communication device, a positioning method used for obtaining the position of the at least one wireless communication device, a difference between the position and a previously measured position of the at least one communication device.

A position of the wireless communication device can include, for instance, coordinates of the wireless communication device, e.g. UE, or a region in which the wireless communication device is located (e.g. estimated based on the cell to which it belongs).

In an implementation form of the first aspect, the RAN resource optimization method is based on a RRM function or is based on a SON function.

The device of the first aspect may be or include an entity implementing the RRM or SON function. In this way RRM/SON functions can be optimized and benefits of virtualized RRM/SON functionalities can be exploited.

In an implementation form of the first aspect, the RAN resource optimization method based on a SON function includes at least one of: MRO, MLB optimization, RACH optimization.

In an implementation form of the first aspect, the RAN resource optimization method based on a RRM function includes at least one of: DRA, ICIC, CMC, Inter-node CoMP, RAC/RBC, LB, and EE.

In an implementation form of the first aspect, the device is further configured to: send a location request or a subscription message intended for a network location service (LCS) to a RAN node, particularly to a LMC or to a CN, in particular to a LMF, and obtain the location information in response to the location request or the subscription message.

Notably, the LMC may be deployed in the RAN node, while the LMF may be deployed in the CN.

In an implementation form of the first aspect, the location request or the subscription message to the RAN node comprises at least one of: an ID or group ID of the at least one wireless communication device, one or more parameters for a positioning measurement, a geographical area, a time of validity of the location request or subscription message, a periodicity of performing a positioning measurement, a type of the request or the subscription, a purpose of the request or the subscription.

In an implementation form of the first aspect, the device is, or is implemented in, a RAN node.

This RAN node may implement SON and/or RRM functions. The RAN node may also be provided with a LMC.

In an implementation form of the first aspect, the device is further configured to exchange the location information and/or a result of performing the RAN resource optimization method with at least one other device, particularly with another RAN node.

Thus, RAN resource optimization can be further improved.

In an implementation form of the first aspect, the device is further configured to exchange the location information or the result of performing the RAN resource optimization method via an Xn/X2, FI or NG interface.

A second aspect provides a device for supporting resource optimization of a RAN, the device being configured to: receive a location request or a subscription message from another device, determine location information related to at least one wireless communication device in the RAN, particularly at least one UE, based on the location request or the subscription message, and provide the location information to the other device.

By providing the location information to the other device, the other device, e.g. the device of the first aspect, can perform an improved, e.g. more precise, RAN resource optimization method.

In an implementation form of the second aspect, the device and/or the other device is, or is implemented in a RAN node or in the CN.

In an implementation form of the second aspect, the device is further configured to: determine the location information by using a LMC and/or LMF implemented in the device or distributed over multiple devices.

For example, the LMC may be implemented in the device, which may be implemented by a RAN node. The LMF may be distributed over multiple devices, particularly in the CN.

In an implementation form of the second aspect, the location request or the subscription message is from a RRM function or from a SON function implemented in the other device.

The other device, e.g. the device of the first aspect, may be implemented in a RAN node, and may implement the RRM and/or SON function.

In an implementation form of the second aspect, the device is further configured to: determine a purpose of the request or the subscription from the location request or the subscription message, respectively, and adapt the location information based on the determined purpose, before providing it to the other device.

For instance, the location information can be adapted by associating it with the purpose, when feeding it back, so that it can be used by the correct device/function, or can be input to the resource optimization method, for which it was requested.

A third aspect provides a method for resource optimization of a RAN, the method comprising: obtaining location information related to at least one wireless communication device in the RAN, particularly at least one UE, performing a RAN resource optimization method based on the obtained location information.

In an implementation form of the third aspect, the location information is related to one UE or to a group of UEs.

In an implementation form of the third aspect, the location information includes at least one of: a position of the at least one wireless communication device, an identification, ID, or a group ID of the at least one wireless communication device, an accuracy of the position of the at least one wireless communication device, a positioning method used for obtaining the position of the at least one wireless communication device, a difference between the position and a previously measured position of the at least one communication device.

In an implementation form of the third aspect, the RAN resource optimization method is based on a RRM function or is based on a SON function.

In an implementation form of the third aspect, the RAN resource optimization method based on a SON function includes at least one of: MRO, MLB optimization, RACH optimization.

In an implementation form of the third aspect, the RAN resource optimization method based on a RRM function includes at least one of: DRA, ICIC, CMC, Inter-node CoMP, RAC/RBC, LB, and EE.

In an implementation form of the third aspect, the method further comprises: sending a location request or a subscription message intended for a network LCS to a RAN node, particularly to a LMC or to a CN entity, in particular to a LMF, and obtaining the location information in response to the location request or the subscription message.

In an implementation form of the third aspect, the location request or the subscription message to the RAN node comprises at least one of: an ID or group ID of the at least one wireless communication device, one or more parameters for a positioning measurement, a geographical area, a time of validity of the location request or subscription message, a periodicity of performing a positioning measurement, a type of the request or the subscription, a purpose of the request or the subscription.

In an implementation form of the third aspect, the method is performed at a RAN node.

In an implementation form of the third aspect, the method further comprises: exchanging the location information and/or a result of performing the RAN resource optimization method with at least one device, particularly with a RAN node.

In an implementation form of the third aspect, the method further comprises: exchanging the location information or the result of performing the RAN resource optimization method via an Xn/X2, FI or NG interface.

The method of the third aspect and its implementation forms achieve the same advantages and effects as the device of the first aspect and its respective implementation forms.

A fourth aspect provides a method for supporting resource optimization of a RAN, the method comprising: receiving a location request or a subscription message from a device, determining location information related to at least one wireless communication device in the RAN, particularly at least one UE, based on the location request or the subscription message, and providing the location information to the device.

In an implementation form of the fourth aspect, the device is, or is implemented in, a RAN node or in the Core Network and/or the method is performed by a RAN node.

In an implementation form of the fourth aspect, the method further comprises: determining the location information by using a LMC and/or LMF implemented in a device or distributed over multiple devices.

In an implementation form of the fourth aspect, the location request or the subscription message is from a RRM function or from a SON function implemented in the other device.

In an implementation form of the fourth aspect, the method further comprises: determining a purpose of the request or the subscription from the location request or the subscription message, respectively, and adapting the location information based on the determined purpose, before providing it to the other device.

The method of the fourth aspect and its implementation forms achieve the same advantages and effects as the device of the second aspect and its respective implementation forms.

A fifth aspect provides a computer program product comprising a program code for controlling the device according to the first or second aspect, and any of their implementation forms, or for carrying out, when implemented on a processor, the method according to the third or fourth aspect, on any of their implementation forms.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above described aspects and implementation forms of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

FIG. 1 shows a device according to an embodiment of the invention.

FIG. 2 shows another device according to an embodiment of the invention.

FIG. 3 shows an implementation overview of devices/functions according to embodiments of the invention.

FIG. 4 shows a subscription procedure performed by devices according to

embodiments of the invention.

FIG. 5 shows a request/response procedure performed by devices according to embodiments of the invention.

FIG. 6 shows a reporting procedure performed by devices according to

embodiments of the invention.

FIG. 7 shows an Xn-based exchange performed by devices according to embodiments of the invention.

FIG. 8 shows a FI -based exchange performed by a device according to an embodiment of the invention.

FIG. 9 shows a NG-based exchange performed by devices according to embodiments of the invention.

FIG. 10 shows a reporting procedure performed by devices according to embodiments of the invention.

FIG. 11 shows an example of a MLB SON functionality.

FIG. 12 shows an example of a MRO SON functionality.

FIG. 13 shows an example of a RRM ICIC functionality.

FIG. 14 shows an example of positioning for enhanced MAC configuration.

FIG. 15 shows an example of positioning for enhanced MAC configuration for IAB.

FIG. 16 shows a method according to an embodiment of the invention.

FIG. 17 shows a method according to an embodiment of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1 shows a device 100 according to an embodiment of the invention. The device 100 is configured to perform a resource optimization of a RAN. To this end, the device 100 is configured to perform a RAN resource optimization method 103. The RAN resource optimization method 103 may be based on a RRM function or may be based on a SON function. Accordingly, the device 100 may be, include or implement a RRM function or a SON function, respectively. The device 100 may, for example, be a RAN node, or may be implemented in a RAN node.

The device 100 is further configured to obtain location information 101 related to at least one wireless communication device 102 in the RAN. The at least one wireless communication device 102 may be at least one UE, i.e. a UE or UE group. The device 100 is configured to perform the RAN resource optimization method 103 based on the obtained location information 101 , i.e. used the location information as an input to the RAN resource optimization method 103.

FIG. 2 shows another device 200 according to an embodiment of the invention. The device 200 is configured to support a resource optimization of a RAN, particularly to support the resource optimization of the RAN performed by the device 100 shown in FIG. 1. To this end, the device 200 is configured to obtain the location information 101 and to provide it to the device 100. The device 100 may be, include or implement a LMC and/or LMF. The device 200 may, for example, be a RAN node, or may be implemented in a RAN node with LMC, or may be implemented in the CN with LMF.

In particular, the device 200 is configured to receive a location request 201 or a subscription message 201 from another device, particularly from the device 100 shown in FIG. 1, and to determine location information 101 related to at least one wireless communication device 102 in the RAN, e.g. a UE or UE group, based on the location request 201 or the subscription message 202. Then, the device 200 is configured to provide the location information 101 to the other device, particularly to the device 100 shown in FIG. 1.

This means that, in order to obtain the location information 101, the device 100 shown in FIG. 1 may be configured to send a location request 201 or a subscription message 201 to the device 200. The request/subscription 201 may be intended for a network LCS (e.g. LMC) of the device 200. The request/subscription 201 may come from a RRM or SON function of the device 100. The device 100 may then receive the location information 101 from the device 200 in response to the location request/subscription 201.

The RAN resource optimization method 103 performed by the device 100 may - when it is based on a SON function - include MRO, MLB optimization, and/or a RACH optimization. These optimization methods are explained below in some detail.

• MRO: In Long Term Evolution (LTE), MRO was introduced to reduce Handover (HO) problems, such as HO ping-pongs, HO failures, and radio link failures (RLF), which deteriorate user experience and waste network resources. By analyzing the report from a UE, HO related parameters may be reconfigured to resolve detected problems. The device 100 is able to perform an enhanced MRO operation taking into account the location information 101 (e.g. accurate UE positioning/location), in order to reduce HO failure problems.

• MLB optimization: The objective of LB is to distribute cell load evenly among cells, or to transfer part of the traffic from congested cells. This is done by the means of self-optimization of mobility parameters or HO actions. The LB action based on HOs may be based on the location information 101 (e.g. UE positioning information) in the device 100. Hence, the source cell may initiate HO due to load, taking into account the users at the edges of the cell (and not just radio measurements). Furthermore, based on the actual UE positioning, MLB can adapt HO and/or reselection configuration, without requiring real-time measurement reporting.

• RACH optimization: The target of this function is to a.) Minimize access delays for all UEs in the system; b.) Minimize UL interference due to RACH; c.) Minimize interference among RACH attempts. The RACH optimization function will attempt to automatically set several parameters related to the performance of RACH, e.g. PRACH configuration index, RACH preamble split, RACH back-off parameter value, PRACH transmission power control parameters. The setting and adaptation of such parameters in the device 100 will take into account the location information 101 (e.g. also UE Positioning information) as provided e.g. by RAN LMC. This allows optimizing RACH.

The RAN resource optimization method 103 performed by the device 100 may - when it is based on a RRM function (and/or MAC function) - include a DRA, ICIC, CMC, Inter node CoMP, RAC/RBC, LB, and/or EE, wherein some of these methods are explained in some detail below.

• Location information 101 (Location Measurements by e.g. RAN LMC) to support Uplink (UL), Downlink (DL), Sidelink (SL) scheduling for DRA can be used by the device 101 in addition to radio measurements. This, together with the Mobility Context Information, can relax the constraint for real-time radio measurement reporting.

• ICIC can be enhanced in the device 100 by using the location information 101 (UE location information), and can be exchanged together with other ICIC info (HII, OI) between eNBs/gNBs.

• Inter-gNB CoMP is a functionality that provides a hypothetical resource allocation using different CoMP schemes. In the device 100 this can also include the location information 101 (e.g. real-time UE positioning information) for more precise CoMP policy selection.

The above RAN resource optimization methods and functions are particular examples for the applicability of the location information 101 to optimize the resources of the RAN.

FIG. 3 shows an overview of a possible implementation of or configuration including the devices 100 and 200 (or specifically functions implemented by these devices 100 and 200) according to embodiments of the invention. The example shows, on the one hand, the configuration of control plane or management plane RAN functionalities, in particular enhanced SON and/or RRM functions, which may be implemented by the device 100. For instance, device 100 may thereby be a BS/gNB. The example shows, on the other hand, the introduction of new functionalities at the RAN level (covering also virtualized RAN deployments), particularly enhanced LMC and/or LMF, which may be implemented by the device 200. For instance, device 200 may thereby be, or may include, a BS/gNB. The enhanced functions may be configured by the CN, or by the management domain (OAM, C-SON), or by the application domain (Location Management Server, Application Function, V2X Server). The following procedures can then generally be carried out by device 100 (implementing SON/RRM function(s)):

1. Request/subscribe to LCS using LMC/LMF.

2. Obtain the location information 101 e.g. for a UE 102 or for a group of UEs 102.

3. Apply the location information 101 to an SON/RRM 100 algorithm, i.e. perform a RAN optimization method 103 based on the location information 101.

4. Provide location-based decisions, results of the RAN optimization method 103, and/or the location information 101 to other involved entities (e.g. using Xn, FI, NG interfaces).

In the following, procedures that can be carried out by devices according to embodiments of the invention are described in detail.

FIG. 4 and FIG. 5 show generally a location information (metric) request/subscription procedure. Two types of requesting ECS by RAN CP/MP, in order to improve resource optimization functions (RRM or SON), are at least possible. FIG. 4 shows a subscription procedure performed by the devices 100 and 200 according to embodiments of the invention. FIG. 5 shows a request/response procedure performed by the devices 100 and 200 according to embodiments of the invention.

The procedure of FIG. 4 may be a subscription on ECS by a RRM/SON function (implemented in device 100) for a certain time, area. The new information, which needs to be sent by the RRM/SON function to the EMC (implemented in device 200, wherein device 100 and 200 may reside in the same or in different RAN nodes) for this option is the:

• Location Subscription information/message 400 (from RAN function to EMC), which includes at least one of the following parameters:

o UE ID(s) or Group UE ID

o Parameters like the positioning method and accuracy level

o Cause/purpose (e.g. type of function, like SON MLB/MRO/RACH Opt/..., RRM (ICIC, CoMP, DRA, ...))

o Geographical area, for which this applies (cell or TA level)

o Time validity for the reporting subscription

o Periodicity of measurements

The procedure of FIG. 5 may be a one-time or Periodic or Continuous Request/Response of LCS from LMF. The new information, which need to be exchanged between the RRM/SON function (implemented in device 100) and the LMC (implemented in device 200, which may reside at the same or in different RAN node than device 100) for this option is the:

• Location Request information/message 500 (from RAN function to LMC), which includes at least one of the following parameters:

o UE ID(s) or Group UE ID

o Parameters like the positioning method and accuracy level

o Cause/purpose (e.g. type of function, like SON MLB/MRO/RACH Opt/..., RRM (ICIC, CoMP, DRA, ...))

o Geographical area, for which this applies (cell or TA level)

o Time validity for the reporting request

o Periodicity of measurements

o Type of request (one-time or in determined time-intervals)

Time intervals

• Location Response information/message 501 (from LMC to RAN function), which includes at least one of the following parameters:

o Result (Mandatory)

ACK (acceptance of request)

NACK (rejection of request)

Negotiation (proposal of different offering based on network capabilities etc.). This may include

• Parameters like the positioning method and accuracy level

• Geographical area for which this applies (cell or TA level)

• Time validity for the reporting request

• Periodicity of measurements

• Type of request (one-time or in determined time-intervals) o Location Report (Optionally; the report can be part of the response 501 or can be a separate message as shown below).

FIG. 6 shows a reporting procedure (location metric reporting) performed by devices 100 and 200 according to embodiments of the invention. Two types of location information reporting can be performed:

• Per UE location reporting, subject to request and type of function, which requires this information from LMC.

• Per Group of UEs reporting, which belong to the same service or in proximity (targeting group-based communications).

o This aggregated report may have some RRM/SON functions for non-real time RAN related optimizations (e.g. LB considering group HO expectation).

The new information, which is needed for the reporting in both cases is:

• Location or Group-location Report information/message 600 (from LMC to RAN function), which includes at least one of the following parameters:

o UE ID(s) or Group UE ID

o UE position (s)

o Cause/purpose (e.g. type of function, like SON MLB/MRO/RACH Opt/..., RRM (ICIC, CoMP, DRA, ...))

o Accuracy

o Method

o (Optionally) Delta positioning parameter from previous reporting

FIG. 7-10 show a location information (metric) exchange with other RRM/SON functions (implemented by other devices 100). FIG. 7 shows an Xn-based exchange (over Xn interface) performed by devices 100 according to embodiments of the invention. FIG. 8 shows a FI -based exchange performed by a device 100 according to an embodiment of the invention. FIG. 9 shows a NG-based exchange performed by devices according to embodiments of the invention. FIG. 10 shows a reporting procedure performed by devices according to embodiments of the invention. That is, four types of location reporting notification can be exchanged between e.g. RAN nodes, after the reporting from the LMC.

The procedure shown in FIG. 7 may be an Xn/X2 -based reporting location reporting exchange. This may be provided to enhance RRM/SON (implemented by device(s) 100), which may distributed among different RAN nodes, or to functions which have dependencies and require the reporting for joint optimization (e.g. ICIC, Inter-gNB CoMP or D-SON - D-SON interactions).

• Location Reporting notification information/message 700 (from RAN function to other RAN function), which includes at least one of the following parameters:

o UE ID(s) or Group UE ID

o Cause/purpose (type of function, e.g. SON MLB/MRO/RACH Opt/..., RRM (ICIC, CoMP, DRA, ...))

o UE position (s)

o Accuracy

The procedure shown in FIG. 8 may be a FI -based reporting (over FI interface) for CU-DU splits. In this case a Central Unit (CU) in a gNB split deployment may include upper layer functions (e.g. D-SON, slow RRM), whereas the MAC layer resides at DU. In that case, lower layer may require the location information for adapting scheduling of traffic.

• Location Reporting notification information/message 800 (from CU to DU), which includes at least one of the following parameters:

o UE ID(s) or Group UE ID

o Cause/purpose (type of function, e.g. SON MLB/MRO/RACH Opt/..., RRM (ICIC, CoMP, DRA, ...))

o UE position (s)

o Accuracy

The procedure shown in FIG. 9 may be a NG-based reporting (over NG interface) for scenarios, where an Xn/X2 (interface) is not available. This signaling may be used for notifying AMF/LMF or for notifying other gNBs, when the Xn is not available.

• NG_based Location Reporting notification information/message 900 (from RAN node to CN and vice versa), which includes at least one of the following parameters: o UE ID(s) or Group UE ID

o gNB ID, eNB ID, CU ID,...

o Cause/purpose (type of function, e.g. SON MLB/MRO/RACH Opt/..., RRM (ICIC, CoMP, DRA, ...))

o UE position (s)

o Accuracy

The procedure shown in FIG. 10 may be a reporting between different SON functions (Itf-S or Itf-N or Service Based Interface (SBI)). This case applies only for the scenario where SON functions are distributed to Centralized-SON (C-SON) and Distributed SON (D-SON). In 3GPP it is discussed that SON can be either distributed in CN or RAN entities and the exchange of information needs to be supported (ref: S5- 186486).

In the following some key implementations of embodiments according to the invention for specific services are provided.

FIG. 11 shows an example of a MLB SON functionality. Initially, when the SON function is initiated, the configuration by O&M should include whether positioning (location information 101) can be used by the function, to enhance the operation. If this feature is supported, the parameterization e.g. which LMC/LMF supports, method of positioning, etc. needs to be sent by O&M to relevant gNB.

After MLB activation, a Location Request 500 is sent to LMC (implemented by device 200) by gNB (implementing device 100) with parameters: the UE(s) for which the positioning applies, a cause/purpose for the request (which SON function needs this request), and other configuration requests. Then, after the Location response 501 to gNB, LMC sends to CN-C (LMF or AMF) a notification of the location reporting 900 for the cause (SON MLB) to inform CN.

The positioning is calculated in LMC and then LMC sends the reporting to the gNB using the SON MLB functionality. Finally, gNB performs MLB and sends via Xn or NG interface a HO trigger request or adaptive mobility configuration information to other nodes, using as new parameter the UE location reporting.

FIG. 12 shows an example of a MRO SON functionality. Initially, when the SON function is initiated, the configuration by O&M should include whether positioning (location information 101) can be used by the function, to enhance the operation. If this feature is supported, the parameterization e.g. which LMC/LMF supports, method of positioning etc. needs to be sent by O&M to relevant gNB.

After MRO activation, Location Request 500 is sent to LMC (implemented by device 200) by gNB (implementing device 100) with parameters: the UE(s) for which the positioning applies, a cause/purpose for the request (which SON MRO function needs this request), and other configuration requests.

Then, after the Location response 501 to gNB, LMC sends to CN-C (LMF or AMF) a notification of the location reporting 900 for the cause (SON MRO) to inform CN. The positioning is calculated in LMC and then LMC sends the reporting to the gNB using the SON MRO functionality. Linally, gNB performs MRO and may send via Xn or NG interface adaptive HO configuration information 700 to other involved nodes, using as new parameter the UE location reporting.

LIG. 13 shows an example of a RRM ICIC functionality. Initially, a Location Request 500 is sent to LMC (implemented by device 200) by gNB (implementing device 100) with parameters: the UE(s) for which the positioning applies, a cause/purpose for the request (ICIC function that needs this request), and other configuration parameters. Then, after the location response 501 to gNB, LMC sends to CN-C (LML or AML) a notification 900 of the location reporting for the cause (ICIC) to inform CN.

The positioning (location information 101) is calculated in LMC and then LMC sends the reporting to the gNB using the ICIC functionality. The gNB performs ICIC and may send via Xn or NG interface ICIC/elCIC information 700 (e.g. HII, OI etc.), using as new parameter the UE location reporting.

LIG. 14 shows an example of positioning for enhanced MAC configuration. This example shows the case of CU-DU split, when RRC and MAC reside in different entities. The

RRM/SON function will have impact on L1/L2 (e.g. change of scheduling, prioritization, RLC bearer configuration, power config, HARQ timings etc.).

Initially, a Location Request 500 is sent to LMC (implemented by device 200) by gNB (implementing device 100) with parameters: the UE(s) for which the positioning applies, a Cause for the request (e.g. RRM or SON function), and other configuration parameters. Then, after the Location response 501 zo gNB, LMC sends to CN-C (LMF or AMF) a notification of the location reporting 900 for the cause to inform CN.

The positioning (location information 101) is calculated in LMC and then LMC sends the reporting to the gNB-CU. The gNB performs RRM/SON function which is the required configuration of the DU. Then, CU sends via Fl-C interface information 800 to gNB-DU MAC the DU configuration (PHY, MAC, RLC configuration), using as new parameter an abstracted version of the UE location reporting.

FIG. 15 shows an example of positioning for enhanced MAC configuration for IAB. This example shows the case of Integrated Access and Backhaul (IAB), when a CU-DU split considers the scenario of wireless DUs with multiple hops. In this example, RRC and MAC may reside in different entities. The RRM/SON function will have impact on L1/L2 (e.g. change of scheduling, prioritization, RLC bearer configuration, power config, HARQ timings etc.).

Initially, a Location Request 500 is sent to LMC (implemented by device 200) by gNB (implementing device 100 with parameters: the UE(s) for which the positioning applies, a Cause for the request (e.g. RRM or SON function), and other configuration parameters. Then, after the Location response 501 to gNB, LMC sends to CN-C (LMF or AMF) a notification of the location reporting 900 for the cause to inform CN.

The positioning (location information 101) is calculated in LMC and then LMC sends the reporting to the gNB-CU. The gNB performs RRM/SON function which is the required configuration of the DU. Then, CU sends via Fl-C interface information 800 to gNB-DU MAC the IAB node configuration (PHY, MAC, RLC configuration), using as new parameter an abstracted version of the UE location reporting.

FIG. 16 shows a method 1600 according to an embodiment of the invention. The method 1600 is in particular for resource optimization of a RAN. The method 1600 may be carried out by device 100. The method 1600 comprises a step 1601 of obtaining location information related to at least one wireless communication device in the RAN, particularly at least one UE, and a step 1602 of performing a RAN resource optimization method based on the obtained location information.

FIG. 17 shows a method 1700 according to an embodiment of the invention. The method 1700 is in particular for supporting resource optimization of a RAN, e.g. the one made by the method of FIG. 17. The method 1700 may be carried out by device 200. The method 1700 comprises a step 1701 of receiving a location request 201 or a subscription message 201 from a device 100, a step 1702 of determining location information 101 related to at least one wireless communication device 102 in the RAN, particularly at least one UE, based on the location request 201 or the subscription message 201, and a step 1703 of providing the location information to the device.

Embodiments of the present invention have been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word“comprising” does not exclude other elements or steps and the indefinite article“a” or“an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.