Address resolution technique

Abstract

A technique for address resolution is described. As to a method aspect of the technique, a method (400) performed by a first network entity (100; 1400) for address resolution is provided. The method (400) comprises or initiates maintaining (408) a tuple table. The tuple table comprises one or more tuples. Each of the one or more tuples of the tuple table comprises a UE address component indicative of a UE address of a user equipment, UE, and a RAN UE ID component indicative of a RAN UE identifier, RAN UE ID, of the UE in a radio access network, RAN. The method (400) further comprises or initiates sending (412), to a second network entity (200; 1500), a resolution message indicative of the RAN UE ID of at least one of the one or more tuples of the maintained (408) tuple table.

Description

[0001] Address Resolution Technique

[0002] Technical Field

[0003] The present disclosure relates to a technique for address resolution, particularly for resolving the address of a user equipment. More specifically, and without limitation of the technique, methods and devices are provided for mapping distinct addressing schemes and identifiers.

[0004] Background

[0005] For efficient radio communication, radio access technologies (RATs) use specific identifiers, e.g. defined for an open radio access network (ORAN), optionally according to the O-RAN Alliance, as well as for a fifth generation (5G) network according to the third generation partnership project (3GPP). A radio access network (RAN) may be structured in cells as a cellular network or may comprise a distributed multiple-input multiple-output (D-MIMO) network. Furthermore, "ORAN" may be understood as a generic term for an open RAN concept, wherein specific ORAN architectures include the afore-mentioned standards of the "O-RAN" Alliance and an "OpenRAN" reference architecture of the Telecom Infra Project (TIP).

[0006] While at least one network node of the RAN such as a 5G node referred to as gNB serves a user equipment (UE), the RAN does not know a UE address of the UE, which is visible to interconnected data networks (DNs) and application servers outside of the RAN, e.g. application services such as data streaming servers. The RAN nodes only store an ephemeral and dynamically assigned UE identifier (RAN UE ID). By virtue of the RAN UE ID, the RAN and a core network (CN) serving the RAN are identifying and managing UE contexts, mobility procedures of UEs, etc. in both the RAN and the CN.

[0007] However, services and functions outside the RAN such as an application function (AF) can request radio-related analytics such as performance data from the RAN, e.g., according to O-RAN standards. For these requests, since the AF does not have access to the RAN UE ID, the AF may only use the UE address to identify the respective UE and the analytics. Since the RAN nodes are not aware of that UE address, such request cannot be processed.

[0008] Summary

[0009] Accordingly, there is a need for a technique that enables services and functions outside of a radio access network (RAN) to access UE-specific analytics and data from the RAN.

[0010] This need is met by a technique for address resolution. As to a first method aspect of the technique, a method performed by a first network entity for address resolution is provided. The method comprises or initiates maintaining a tuple table. The tuple table comprises one or more tuples. Each of the one or more tuples of the tuple table comprises an address component indicative of a UE address of a user equipment (UE) and a RAN UE ID component indicative of a RAN UE identifier (RAN UE ID) of the UE in a radio access network (RAN). The method further comprises or initiates sending, to a second network entity, a resolution message indicative of the RAN UE ID of at least one of the one or more tuples of the maintained tuple table.

[0011] Embodiments of the method enable the second network entity to request data (e.g., for radio analytics) relating to the UE from the RAN using the RAN UE ID received in the resolution message, e.g. a RAN identifier dynamically assigned to the UE. Same or further embodiments of the method can provide an address resolution (e.g., an address translation) function to enable the second network entity to address the RAN in a UE- specific request. The resolution message may enable the second network entity to retrieve and / or analyze RAN information for the specific UE.

[0012] Different network entities within and outside of the RAN may use different identifiers and / or different address types for the same UE. Embodiments of the method may enable an address resolution that maps by virtue of the tuple table and the resolution message different addressing schemes or different identifiers for the UE inside and outside of the RAN.

[0013] The "one or more tuples" may refer to all those tuples in the tuple table that comprise at least the UE address component and the RAN UE ID component, or a subset thereof. The tuple table may further comprise at least one tuple that comprises the UE address component and that does not (e.g., not yet) comprise the RAN UE ID component (i.e., no RAN UE ID component at all or no RAN UE ID component indicative of a RAN UE ID, e.g. an empty RAN UE ID component with a zero value or a "Not a Number" (NaN) value). Alternatively or in addition, the tuple table may further comprise at least one tuple that comprises a RAN UE ID component and that does not (e.g., not yet) comprise the UE address component (i.e., no RAN UE ID component at all or no RAN UE ID component indicative of a RAN UE ID, e.g. an empty RAN UE ID component with a zero value or a "Not a Number" (NaN) value). Such incomplete tuples may be related to (e.g., a failed or ongoing or planned step of) the maintaining of the tuple table, e.g. a substep of update or adding a tuple in the tuple table.

[0014] The RAN may be an open RAN (O-RAN). The first network entity may be different from the second network entity. The different network entities may relate to different network layers and / or different network segments. The second network entity may be any network function (e.g., an application function, AF) or service or server external to the RAN.

[0015] Embodiments of the technique may be used for public networks and / or private networks. Same or further embodiments of the technique may be used for networks providing fifth generation (5G) radio access and / or beyond 5G (B5G) as well as for the networks following (i.e., compliant to) or extending an open RAN (O-RAN) architecture. The 5G RAT and the B5G (or 6th generation) RAT may adhere to at least one of or both open RAN standards (e.g., according to the O-RAN Alliance) and 3GPP architecture.

[0016] Herein, a "corresponding" component may refer to a component within the same tuple of the tuple table and / or may refer to a component of the same UE.

[0017] The term "component" or "components" may refer to any one of the components disclosed herein, e.g. the UE address component and / or the RAN UE ID component. The UE address component and the RAN UE ID component may also be referred to as the component (e.g., of a tuple) for the UE address and the component (e.g., of a tuple) for the RAN UE ID component, respectively. In other words, the UE address component and the RAN UE ID component may be components (e.g., of a tuple) that are indicative of a UE address of a UE and a RAN UE ID of a UE, respectively.

[0018] A mobile network may comprise the RAN and a core node (CN) serving the RAN.

[0019] The message sent to the second network entity may be indicative of the UE address component. The address resolution may be referred to as a UE address resolution.

[0020] The UE address may be an IP address of the user equipment (UE). The UE address may be resolvable or visible outside of the RAN, e.g., in the internet (e.g., resolvable by a Domain Name System, DNS, server) or by an applications server. Alternatively or in addition, the UE address may be incompatible with an identity system of the RAN and / or may be not assigned or not resolvable by the RAN serving the UE.

[0021] Alternatively or in addition, the RAN UE ID may be an ephemeral (e.g., temporary) ID address of the UE, e.g., an internal temporary UE address of the RAN or O-RAN. The RAN UE ID may be not visible or not resolvable outside of the RAN. For example, the RAN UE ID may be incompatible with the Domain Name System (DNS) of the internet and / or may be not assigned or not resolvable by an applications server used by the UE.

[0022] Examples of the RAN UE ID may relate to an identifier related to a central unit (CU, also: centralized unit) of a RAN node. For example, the RAN UE ID may comprise a "gNB-CU UE F1AP ID" (e.g., according to the 3GPP TS 38.401, version 18.1.0). Alternatively or in addition, the RAN UE ID may relate to a Next Generation Application Protocol (NGAP). For example, the RAN UE ID may comprise a "RAN-UE NGAP ID" (e.g., according to the 3GPP TS 38.473, version 18.1.0).

[0023] Maintaining the tuple table may comprise updating, adding, and / or removing one or more of the UE address components of the tuple of the tuple table based on a received UE address binding request message indicative of a UE address and the corresponding RAN UE ID. The method may ensure that the tuple table is kept up to date.

[0024] The second network entity may use the updated ID-tuple table for (e.g., requesting) RAN analytics data.

[0025] The first network entity may be part of a service management and orchestration framework of O-RAN (SMO).

[0026] The second network entity may be an interface to an application function (AF) of the CN and / or an Y1 consumer of the O-RAN. The second network entity may also be referred to as an address resolution requester. The Y1 consumer may comprise at least one of a packet core function (e.g., the AF inside the CN), and an application server or edge server (e.g., an AF outside of the CN or in an untrusted data network).

[0027] The second network entity may comprise a user plane function (UPF) of the CN.

[0028] The first network entity and the second network entity may be spatially separated. Alternatively or in addition, the second network entity may be out of the communication network.

[0029] The sent resolution message (e.g., according to the first method aspect) may be indicative of at least one of the one or more tuples of the maintained tuple table. Alternatively or in addition, the sent resolution message may be indicative of a combination of the UE address and the RAN UE ID of at least one of the one or more tuples of the maintained tuple table. Alternatively or in addition, the sent resolution message may be indicative of the RAN UE ID in association with the UE address of at least one of the one or more tuples of the maintained tuple table.

[0030] For example, the sent resolution message may be indicative of each of the one or more tuples of the maintained tuple table.

[0031] At least one or each of the one or more tuples of the tuple table (e.g., according to the first method aspect) may further be indicative of, or may further comprise, a RAN node ID component indicative of a RAN node identifier (RAN node ID) of a RAN node serving the UE indicated by the respective tuple. The RAN UE ID may be a unique ID per RAN node. In other words, the pair of RAN UE ID and RAN node ID may uniquely identify the UE within the RAN. The RAN UE ID alone may be not necessarily unique within the RAN. For example, neighboring RAN nodes in the RAN may reuse the same ID space for their RAN UE IDs of UEs served by the respective RAN node. As a consequence, the same RAN UE ID may refer to different UEs in neighboring RAN nodes of the RAN, and / or the same UE may have different RAN UE IDs in neighboring RAN nodes of the RAN.

[0032] The RAN node may be a network node of the RAN. Alternatively or in addition, the RAN node may correspond to one or more cells of the RAN.

[0033] Herein, "serving" may require a connected state (e.g., a radio resource control, RRC, connected state or a discontinuous reception, DRX, state or an inactive state or a registered state) of the UE relative to the RAN node and / or may require that the UE is camping on (e.g., a cell of) the RAN node (e.g., in a deregistered state or an idle state of the UE relative to the RAN node)

[0034] Herein, the "corresponding" or "associated" UE address, the "corresponding" or "associated" RAN UE ID, and (if applicable) the "corresponding" or "associated" RAN node ID may refer to any pair or triple out of the UE address, the RAN UE ID, and (if applicable) the RAN node ID, which are indicated in the same tuple of the tuple table and / or which are indicated in combination or association by the resolution message.

[0035] Alternatively or in addition, the "corresponding" or "associated" UE address, the "corresponding" or "associated" RAN UE ID, and (if applicable) the "corresponding" or "associated" RAN node ID may refer to any pair or triple out of the UE address, the RAN UE ID, and (if applicable) the RAN node ID, which relate to the same UE.

[0036] The tuple table may further comprise at least one tuple that comprises a pair of UE address component and RAN UE ID component (e.g., analogous to the one or more tuples) and / or that does not (e.g., not yet) comprise a RAN node ID component.

[0037] The method (e.g., according to the first method aspect) may further comprise or initiate binding a UE address and a corresponding RAN UE ID, and / or a corresponding RAN node ID, to a tuple of the tuple table.

[0038] The binding may be a substep of the maintaining. Alternatively or in addition, the binding of a UE address and a corresponding RAN UE ID (and / or a corresponding RAN node ID) to a tuple of the tuple table may comprise adding (e.g., including) or updating the UE address component and the RAN UE ID component (and / or the RAN node ID component) in said tuple of the tuple table, e.g. for one UE per tuple. The third network entity may be a RAN node (e.g., gNB and / or a central unit (CU) of a RAN node, e.g. a gNB-CU) and / or a CU of a control plane (CP, i.e. a CU-CP, e.g. an O-RAN CU-CP or O-CU-CP). Alternatively or in addition, the third network entity may be a core node (e.g., a node or function of the core network, CN). Alternatively or in addition, the third network entity may be a user equipment (UE).

[0039] The UE may use an extended SDAP frame structure to include the UE address in an uplink SDAP frame sent to the gNB-CU or O-CU-CP. The gNB-CU or O-CU-CP may extract that UE address information (e.g., the UE address) and may use it in an ID-bind request (e.g., as a second message and / or in the step) towards the ID-bind SMOS (as an example of the first network entity).

[0040] The third network entity and the first network entity may be spatially separated. Alternatively or in addition, the third network entity may comprise the first network entity. Alternatively or in addition, the first network entity may comprise the third network entity.

[0041] The method (e.g., according to the first method aspect) may further comprise or initiate receiving a UE address binding request message from a third network entity, e.g. wherein the UE address binding request message may be indicative of the UE address of a UE and / or the RAN UE ID of a UE in the RAN.

[0042] The UE address binding request message may be indicative of a UE address binding request. The reception of the UE address binding request may trigger a step of UE address binding (or briefly: a step of binding) performed by the first network entity. Performing binding may comprise maintaining (e.g., adding or updating) at least the UE address component and the RAN UE ID component in a tuple of the tuple table for a UE (or for each UE) indicated in the UE address binding request message.

[0043] The binding may be performed by an ID-bind module of the first network entity, e.g., an ID-bind module of the SMO service (ID-bind SMOS).

[0044] The first network entity may bind the received UE address and the corresponding RAN UE ID into a tuple, e.g., the UE address as a first component of the tuple and the corresponding RAN UE ID as the second component of the tuple, or vice versa.

[0045] The maintaining of the tuple table (e.g., according to the first method aspect) may comprise maintaining the UE address component, the RAN UE ID component, and / or the RAN node ID component of a tuple of the tuple table based on the received UE address binding request message indicative of at least one of a UE address, a corresponding RAN UE ID and / or a corresponding RAN node ID.

[0046] The method (e.g., according to the first method aspect) may further comprise or initiate sending a UE address request message to a third network entity indicative of a request for one or more UE addresses, e.g. wherein the UE address request message may be sent responsive to one or more missing or outdated UE address component in a tuple of the tuple table.

[0047] Herein, "a tuple" of the tuple table may refer to one of the afore-mentioned "one or more tuples" of the tuple table, e.g. an existing tuple that is updated in the tuple table. Alternatively or in addition, "a tuple" of the tuple table may refer to a further tuple that is added to the tuple table.

[0048] The UE address request message may be further indicative of the RAN UE ID (e.g., the RAN UE ID corresponding to the missing or outdated UE address component). The first network entity may receive a response message from the third network entity indicative of the UE address and the RAN UE ID. The first network entity may maintain the tuple table based on the received response from the third network entity.

[0049] The method (e.g., according to the first method aspect) may further comprise or initiate receiving a resolution request message from the second network entity indicative of a request for at least the RAN UE ID of at least one of the one or more tuples of the maintained tuple table, e.g. wherein the resolution message may be sent responsive to the received resolution request message and / or wherein the resolution request message may be indicative of at least the UE address of the at least one of the one or more tuples.

[0050] Alternatively or in addition, the resolution request message may be indicative of a request for one or more tuples of the maintained tuple table. Alternatively or in addition, the resolution request message may be indicative of the complete maintained tuple table.

[0051] Alternatively or in addition, the resolution request message may be further indicative of (e.g., a request for) one or more tuples of the maintained tuple table or (e.g., a request for) the whole maintained tuple table.

[0052] The maintaining of the tuple table (e.g., according to the first method aspect) may further comprise, responsive to an event of the UE in the RAN, maintaining the RAN UE ID component corresponding to the UE or to the UE address of the UE and / or maintaining the RAN node ID component corresponding to the UE or to the UE address of the UE. For example, the event may comprise a mobility of the UE in the RAN and / or a random access procedure.

[0053] The mobility of the UE in the RAN may comprise a handover and / or a cell change of the UE in the RAN. The RAN UE ID may change, e.g., due to UE mobility in the RAN and / or a handover situation. Alternatively or in addition, the RAN node ID may change, e.g., due to UE mobility in the RAN and / or a handover situation.

[0054] The mobility (i.e., a mobility event) may comprise a handover of the UE from a source cell to a target cell in the RAN and / or a change in the RAN node (e.g., as indicated by the RAN node ID) serving the UE and / or a change in radio units (RUs serving the UE, e.g., as indicated by the RAN node ID) of a distributed multiple-input multiple output (D-MIMO) system of the RAN.

[0055] The sending of the resolution message indicative of the RAN UE ID of at least one of the one or more tuples of the maintained tuple table (e.g., according to the first method aspect) may be triggered by a change of one or more of the components of the at least one of the one or more tuples of the maintained tuple table.

[0056] Alternatively or in addition, the sending of the RAN UE ID of at least one of the one or more tuples of the maintained tuple table (e.g., of at least one changed tuple of the one or more tuples of the maintained tuple table) and / or the sending of the one or more (e.g., changed) tuples of the maintained tuple table and / or the sending of the whole maintained tuple table (e.g., an updated tuple table) may be performed periodically.

[0057] The change may relate to the maintaining, e.g., the updating and / or adding of the at least one of the one or more tuples of the maintained tuple table.

[0058] The method (e.g., according to the first method aspect) may further comprise or initiate storing the tuple table in a local storage of the RAN and / or in a network-distributed storage of the RAN.

[0059] As to a second method aspect, a method performed by a second network entity for address resolution is provided. The method comprises or initiates receiving, from a first network entity, a resolution message indicative of at least one of the RAN UE ID of one or more tuples of a tuple table maintained at the first network entity. The tuple table comprises one or more tuples. One or each of the tuples of the tuple table comprises an address of a user equipment (UE address) component and a corresponding radio access network UE identifier (RAN UE ID) component. The resolution message (e.g., according to the second method aspect) may be further indicative of one or more tuples of the maintained tuple table to a second network entity.

[0060] The one or each of the tuples of the tuple table (e.g., according to the second method aspect) may further comprise a corresponding ID of a RAN node (RAN node ID). The RAN node may be serving the UE.

[0061] The method (e.g., according to the second method aspect) may further comprise or initiate sending a resolution request message to the first network entity indicative of a request for the resolution message. Alternatively or in addition, the resolution message may be indicative of at least one of the RAN UE ID of one or more UE addresses and / or one or more tuples of the maintained tuple table.

[0062] The method (e.g., according to the second method aspect) may further comprise or initiate performing a RAN analysis for at least one UE based on at least one of the RAN UE ID of one or more tuples of the tuple table indicated by the received resolution message.

[0063] The method enables the third network entity to correlate the internally used UE address (e.g., temporary identity) with an externally visible address of the radio device, facilitating communication with the second network entity (e.g., entities outside of the radio access network).

[0064] As to a third method aspect, a method performed by a third network entity for address resolution is provided. The method comprises or initiates sending a UE address binding request message to a first network entity. The UE address binding request message is indicative of an address of a user equipment (UE address) for maintaining a tuple table comprising one or more tuples. One or each of the tuples of the tuple table comprises a UE address component and a corresponding radio access network UE identifier (RAN UE ID) component.

[0065] Alternatively or in addition, the UE address may not be known (e.g., may not be known to the third network entity) and the UE address binding request message is indicative of a void instead of the UE address component. The not known UE address may be asked by the first network entity from another third network entity (other than the one sent the UE address binding request message).

[0066] The not known UE address may be due to, e.g., a failed established PDU session between the UE and the third network entity in a certain time. The not known UE address may be requested by the third network entity from another third network entity before sending the UE address binding request message to the first network entity.

[0067] The method (e.g., according to the third method aspect) may further comprise or initiate receiving a UE address request message indicative of a request for one or more UE addresses. Alternatively or in addition, the UE address request message may be indicative of one or more RAN UE IDs of one or more UEs for which the one or more UE addresses are requested.

[0068] The received UE address request (e.g., according to the third method aspect) may be from the first network entity and / or from a third network entity other than the third network entity performing the method.

[0069] The method (e.g., according to the third method aspect) may further comprise or initiate sending a UE address to the third network entity performing the method, in response to the received UE address request from the third network entity performing the method.

[0070] Alternatively or in addition, sending the UE address to the third network entity may be initiative, i.e., without prior request. For example a UE (e.g., as a third network entity) may send UE address indication to a third network entity performing the third method aspect (e.g., a gNB-CU or O-CU-CP).

[0071] Alternatively or in addition, sending the UE address to the third network entity may be performed by a third network entity other than the third network entity performing the third method aspect.

[0072] The sending a UE address to the first network entity (e.g., according to the third method aspect) may be in response to the received UE address request from the first network entity.

[0073] As to computer device aspect a computer program product comprising program code portions is provided. The program code portion is for performing any one of the steps of the first method aspect, and / or the second method aspect, and / or the third method aspect when the computer program product is executed on one or more computing devices, optionally stored on a computer-readable recording medium.

[0074] As to a first device aspect a first network entity comprising memory operable to store instructions and processing circuitry operable to execute the instructions is provided. The first network entity is operable to maintain a tuple table. The tuple table comprises one or more tuples. One or each of the tuples of the tuple table comprises an address of a user equipment (UE address) component and a corresponding radio access network UE identifier (RAN UE ID) component. The first network entity is further operable to send a resolution message indicative of at least one of the RAN UE ID of one or more tuples of the maintained tuple table to a second network entity.

[0075] The radio device (e.g., according to the first device aspect) may further be operable to perform any one of the steps of the first method aspect.

[0076] As to another first device aspect a first network entity for address resolution is provided. The first network entity is configured to maintain a tuple table. The tuple table comprises one or more tuples. One or each of the tuples of the tuple table comprises an address of a user equipment (UE address) component and a corresponding radio access network UE identifier (RAN UE ID) component. The first network entity is further configured to send a resolution message indicative of at least one of the RAN UE ID of one or more tuples of the maintained tuple table to a second network entity.

[0077] The first network entity (e.g., according to the other first device aspect) may further be configured to perform any one of the steps of the first method aspect.

[0078] As to a second device aspect a second network entity comprising memory operable to store instructions and processing circuitry operable to execute the instructions is provided. The second network entity is operable to receive, from a first network entity, a resolution message indicative of at least one of the RAN UE ID of one or more tuples of a tuple table maintained at the first network entity. The tuple table comprises one or more tuples. One or each of the tuples of the tuple table comprises an address of a user equipment (UE address) component and a corresponding radio access network UE identifier (RAN UE ID) component.

[0079] The second network entity (e.g., according to the second device aspect) may further be operable to perform any one of the steps of the second method aspect.

[0080] As to another second device aspect a second network entity for address resolution is provided. The second network entity configured to receive, from a first network entity, a resolution message indicative of at least one of the RAN UE ID of one or more tuples of a tuple table maintained at the first network entity. The tuple table comprises one or more tuples. One or each of the tuples of the tuple table comprises an address of a user equipment (UE address) component and a corresponding radio access network UE identifier (RAN UE ID) component.

[0081] The second network entity (e.g., according to the other second device aspect) may further be configured to perform any one of the steps of the second method aspect. As to a third device aspect a third network entity comprising memory operable to store instructions and processing circuitry operable to execute the instructions is provided. The third network entity is operable to send a UE address binding request message to a first network entity. The UE address binding request message is indicative of an address of a user equipment (UE address) for maintaining a tuple table comprising one or more tuples. One or each of the tuples of the tuple table comprises a UE address component and a corresponding radio access network UE identifier (RAN UE ID) component.

[0082] The third network entity (e.g., according to the third device aspect) may further be operable to perform any one of the steps of the third network entity.

[0083] As to another third device aspect a third network entity for address resolution is provided. The third network entity configured to send a UE address binding request message to a first network entity. The UE address binding request message is indicative of an address of a user equipment (UE address) for maintaining a tuple table comprising one or more tuples. One or each of the tuples of the tuple table comprises a UE address component and a corresponding radio access network UE identifier (RAN UE ID) component.

[0084] The third network entity (e.g., according to the other third device aspect) may further be configured to perform any one of the steps of the third method aspect.

[0085] Without limitation, for example in a 3GPP implementation, any "user equipment" may be a radio device (RD). Any of the radio devices may be a 3GPP user equipment (UE) or a Wi-Fi station (STA). The radio device may be a mobile or portable station, a device for machine-type communication (MTC), a device for narrowband Internet of Things (NB- loT) or a combination thereof. Examples for the UE and the mobile station include a mobile phone, a tablet computer and a self-driving vehicle. Examples for the portable station include a laptop computer and a television set. Examples for the MTC device or the NB-loT device include robots, sensors and / or actuators, e.g., in manufacturing, automotive communication and home automation. The MTC device or the NB-loT device may be implemented in a manufacturing plant, household appliances and consumer electronics.

[0086] The technique may be applied in the context of 3GPP New Radio (NR), e.g., following or compliant to the O-RAN architecture. Alternatively or in addition, the technique may be applied in the context of 3GPP NR, e.g., following or compliant to the vRAN and / or OpenRAN and / or Cloud RAN.

[0087] The RAN may comprise one or more base stations, e.g., performing the first and / or the third method aspects. Alternatively or in addition, the radio network may be a vehicular, ad hoc and / or mesh network comprising two or more user equipment, e.g., acting as the remote user equipment and / or the relay user equipment. Whenever referring to the RAN and / or the O-RAN, the RAN and / or the ORAN may be implemented by one or more base stations. In this document the terms O-RAN and ORAN may be used interchangeably.

[0088] Open RAN may be referred to as an industry term for open radio access network architecture. It is a RAN that that may include open interoperable interfaces and virtualization and is big data and Al-enabled. O-RAN may be referred to the O-RAN Alliance. OpenRAN may be referred to initiatives driven by TIP's OpenRAN project group. vRAN may be referred to 5G becoming software-defined and programmable, generating additional RAN architecture flexibility, platform harmonization and simplification. Cloud RAN may be referred to Cloud RAN that is a virtualized RAN which is designed to be cloud native, built on future proof architectures and incorporating key elements such as micro services, CI / CD and containerization.

[0089] The base station may encompass any station that is configured to provide radio access to any of the radio devices. The base stations may also be referred to as cell, transmission and reception point (TRP), radio access node or access point (AP). The base station and / or the relay radio device may provide a data link to a host computer providing the user data to the remote radio device or gathering user data from the remote radio device. Examples for the base stations may include a 3G base station or Node B, 4G base station or eNodeB, a 5G base station or gNodeB, a Wi-Fi AP and a network controller (e.g., according to Bluetooth, ZigBee or Z-Wave).

[0090] The RAN may be implemented according to the Global System for Mobile Communications (GSM), the Universal Mobile Telecommunications System (UMTS), 3GPP Long Term Evolution (LTE) and / or 3GPP New Radio (NR).

[0091] Any aspect of the technique may be implemented on a Physical Layer (PHY), a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer, a packet data convergence protocol (PDCP) layer, and / or a Radio Resource Control (RRC) layer of a protocol stack for the radio communication.

[0092] Herein, referring to a protocol of a layer may also refer to the corresponding layer in the protocol stack. Vice versa, referring to a layer of the protocol stack may also refer to the corresponding protocol of the layer. Any protocol may be implemented by a corresponding method.

[0093] As to another aspect, a computer program product is provided. The computer program product comprises program code portions for performing any one of the steps of the method aspect disclosed herein when the computer program product is executed by one or more computing devices. The computer program product may be stored on a computer-readable recording medium. The computer program product may also be provided for download, e.g., via the radio network, the RAN, the Internet and / or the host computer. Alternatively, or in addition, the method may be encoded in a Field- Programmable Gate Array (FPGA) and / or an Application-Specific Integrated Circuit (ASIC), or the functionality may be provided for download by means of a hardware description language.

[0094] Any one of the embodiments of any one of the first method aspect and / or the second method aspect and / or the third method aspect disclosed, may be combined with each other.

[0095] Brief Description of the Drawings

[0096] Further details of embodiments of the technique are described with reference to the enclosed drawings, wherein:

[0097] Fig. 1 shows a schematic block diagram of an embodiment of a first network entity for address resolution;

[0098] Fig. 2 shows a schematic block diagram of an embodiment of a second network entity for address resolution;

[0099] Fig. 3 shows a schematic block diagram of an embodiment of a third network entity for address resolution;

[0100] Fig. 4 shows a flowchart for a method of address resolution, which method may be implementable by the device of Fig. 1;

[0101] Fig. 5 shows a flowchart for a method of address resolution, which method may be implementable by the device of Fig. 2;

[0102] Fig. 6 shows a flowchart for a method of address resolution, which method may be implementable by the device of Fig. 3;

[0103] Fig. 7 schematically illustrates an existing building blocks of the O-RAN architecture comprising SMO;

[0104] Fig. 8 schematically illustrates a basic O-RAN architecture and 3GPP terminology; Fig. 9 schematically illustrates a first example of a radio network comprising embodiments of the devices of Figs. 1 to 3 for performing the methods of Figs. 4 to 6;

[0105] Fig. 10 schematically depicts the building blocks and the overall proposed address resolution according to the methods of Figs. 4, 5, and 6, performed by the devices of Figs. 1, 2, and 3, respectively;

[0106] Fig. 11 schematically shows a message flow according to the first embodiment;

[0107] Fig. 12 schematically shows a message flow according to the second embodiment;

[0108] Fig. 13 schematically shows a message flow according to the third embodiment;

[0109] Fig. 14 shows a schematic block diagram of a first network entity embodying the device of Fig. 1;

[0110] Fig. 15 shows a schematic block diagram of a second network entity embodying the device of Fig. 2; and

[0111] Fig. 16 shows a schematic block diagram of a third network entity embodying the device of Fig. 3

[0112] Detailed Description

[0113] In the following description, for purposes of explanation and not limitation, specific details are set forth, such as a specific network environment in order to provide a thorough understanding of the technique disclosed herein. It will be apparent to one skilled in the art that the technique may be practiced in other embodiments that depart from these specific details. Moreover, while the following embodiments are primarily described for a New Radio (NR) or 5G implementation, it is readily apparent that the technique described herein may also be implemented for any other radio communication technique, including a Wireless Local Area Network (WLAN) implementation according to the standard family IEEE 802.11, 3GPP LTE (e.g., LTE- Advanced or a related radio access technique such as MulteFire), for Bluetooth according to the Bluetooth Special Interest Group (SIG), particularly Bluetooth Low Energy, Bluetooth Mesh Networking and Bluetooth broadcasting, for Z-Wave according to the Z-Wave Alliance or for ZigBee based on IEEE 802.15.4.

[0114] Moreover, those skilled in the art will appreciate that the functions, steps, units and modules explained herein may be implemented using software functioning in conjunction with a programmed microprocessor, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Digital Signal Processor (DSP) or a general purpose computer, e.g., including an Advanced RISC Machine (ARM). It will also be appreciated that, while the following embodiments are primarily described in context with methods and devices, the invention may also be embodied in a computer program product as well as in a system comprising at least one computer processor and memory coupled to the at least one processor, wherein the memory is encoded with one or more programs that may perform the functions and steps or implement the units and modules disclosed herein.

[0115] Fig. 1 schematically illustrates a block diagram of an embodiment of a first network entity for address resolution. The first network entity is generically referred to by reference sign 100.

[0116] The first network entity 100 comprises a module 108 that maintains a tuple table. The tuple table may comprise one or more tuples. The one or each of the tuples of the tuple table may comprise an address of a user equipment (UE address) component and a corresponding radio access network UE identifier (RAN UE ID) component. Optionally the one or each of the tuples of the tuple table may further comprise a RAN node ID.

[0117] The first network entity 100 further comprises a module 112 that sends a resolution message indicative of at least one of the RAN UE ID of one or more tuples of the maintained tuple table to a second network entity.

[0118] Optionally, the first network entity 100 may further comprise a module 102 that sends a UE address request message to a third network entity, indicative of a request for one or more UE address.

[0119] Optionally, the first network entity 100 may further comprise a module 104 that receives a UE address binding request message from a third network entity.

[0120] Optionally, the first network entity 100 may further comprise a module 106 that binds a UE address and a corresponding RAN UE ID to a tuple of the tuple table.

[0121] Optionally, the first network entity 100 may further comprise a module 110 that receives a request message from the second network entity indicative of a request for one or more tuples of the maintained tuple table. The resolution message may be sent responsive to the received request message.

[0122] Optionally, the first network entity 100 may further comprise a module 114 that store the tuple table in a local storage of the RAN and / or in a network-distributed storage of the RAN. Any of the modules of the first network entity 100 may be implemented by units configured to provide the corresponding functionality.

[0123] The first network entity 100 may also be referred to as, or may be embodied by, a transmitting station (or briefly: transmitter) or may be embodied by an orchestration and automation of a network or SMO (e.g., serving SMO).

[0124] Fig. 2 schematically illustrates a block diagram of an embodiment of a second network entity for address resolution. The device is generically referred to by reference sign 200.

[0125] The second network entity 200 comprises a module 212 that receives from a first network entity 100, a resolution message indicative of at least one of the RAN UE ID of one or more tuples of a tuple table maintained at the first network entity 100. The tuple table may comprise one or more tuples. The one or each of the tuples of the tuple table may comprise an address of a UE (UE address) component and a corresponding radio access network UE identifier (RAN UE ID) component.

[0126] Optionally, the second network entity 200 may further comprise a module 210 that sends a request message to the first network entity 100 indicative of a request for the resolution message.

[0127] Optionally, the second network entity 200 may further comprise a module 214 that initiates performing a RAN analysis for at least one UE based on one or more tuples of the tuple table indicated by the received resolution message.

[0128] Any of the modules of the second network entity 200 may be implemented by units configured to provide the corresponding functionality.

[0129] The second network entity 200 may also be referred to as, or may be embodied by, the address resolution requester. The address resolution requester may be in direct radio communication, e.g., at least for the multi-layer reception from the first network entity 100 to the second network entity 200. The second network entity 200 may be embodied by the first network entity 100.

[0130] Fig. 3 schematically illustrates a block diagram of an embodiment of a third network entity for address resolution. The device is generically referred to by reference sign 300.

[0131] The third network entity 300 comprises a module 304 that sends a UE address binding request message to a first network entity 100. The UE address binding request message may be indicative of an address of a UE address for maintaining a tuple table comprising one or more tuples. The one or each of the tuples of the tuple table comprises a UE address component and a corresponding radio access network UE identifier (RAN UE ID) component.

[0132] Optionally, the third network entity 300 may further comprise a module 302 that receives a UE address request message indicative of a request for one or more UE addresses.

[0133] Optionally, the third network entity 300 may further comprise a module 303 that sends a UE address to the third network entity 300 performing the third method aspect, in response to the received UE address request from the third network entity 300 performing the method.

[0134] Any of the modules of the third network entity 300 may be implemented by units configured to provide the corresponding functionality.

[0135] The third network entity 300 may also be referred to as, or may be embodied by, the 5G core (5GC) and / or a gNB central unit (gNB-CU) and / or an O-RAN central unit control plane (O-CU-CP) and / or a UE. The third network entity 300 may be direct radio communication, e.g., at least for the multi-layer reception from the transmitting station to the first network entity 100. Alternatively or in addition, the third network entity 300 may be embodied by the first network entity 100.

[0136] Fig. 4 shows an example flowchart for a method 400 performed by the first network entity 100 for address resolution.

[0137] In a step 408, the first network entity 100 maintains a tuple table. The tuple table may comprise one or more tuples. The one or each of the tuples of the tuple table may comprise an address of a UE (UE address) component and a corresponding radio access network UE identifier (RAN UE ID) component.

[0138] In a step 412, the first network entity 100 sends a resolution message indicative of one or more tuples of the maintained 408 tuple table to a second network entity 200.

[0139] Optionally, in a step 402, the first network entity 100 may send a UE address request message to the third network entity 300 indicative of a request for one or more UE address. Alternatively or in addition, the UE address request message may be sent 402 responsive to a missing or outdated UE address component in a tuple of the tuple table.

[0140] Optionally, in a step 404, the first network entity 100 may receive a UE address binding request message from a third network entity 300.

[0141] Optionally, in a step 406, the first network entity 100 may bind a UE address and a corresponding RAN UE ID to a tuple of the tuple table. Optionally, in a step 410, the first network entity 100 may receiving a request message from the second network entity 200 indicative of a request for one or more tuples of the maintained 408 tuple table. The resolution message may be sent 412 responsive to the received 410 request message.

[0142] Optionally, in a step 414, the first network entity 100 may store the tuple table in a local storage of the RAN and / or in a network-distributed storage of the RAN.

[0143] The method 400 may be performed by the first network entity 100. For example, the modules 102, to 114 may perform the steps 402 to 414, respectively.

[0144] Fig. 5 shows an example flowchart for a method 500 performed by the second network entity 200 for address resolution.

[0145] In a step 512, the second network entity 200 receives from a first network entity 100, a resolution message indicative of at least one of the RAN UE ID of one or more tuples of a tuple table maintained at the first network entity 100. The tuple table may comprise one or more tuples. The one or each of the tuples of the tuple table may comprise an address of a UE (UE address) component and a corresponding radio access network UE identifier (RAN UE ID) component.

[0146] Optionally, in a step 510, the second network entity 200 may send 510 a request message to the first network entity 100 indicative of a request for the resolution message. The resolution message may be indicative of one or more UE addresses and / or one or more tuples of the maintained 408 tuple table.

[0147] Optionally, in a step 514, the second network entity 200 may initiate performing a RAN analysis for at least one UE based on one or more tuples of the tuple table indicated by the received 510 resolution message.

[0148] The method 500 may be performed by the second network entity 200. For example, the modules 210, 212 and 214 may perform the steps 510, 512 and 514, respectively.

[0149] Fig. 6 shows an example flowchart for a method 600 performed by the third network entity 300 for address resolution.

[0150] In step 604, the third network entity 300 sends a UE address binding request message to a first network entity 100. The UE address binding request message may be indicative of an address of a UE (UE address) for maintaining a tuple table comprising one or more tuples. The one or each of the tuples of the tuple table may comprise a UE address component and a corresponding radio access network UE identifier (RAN UE ID) component. Optionally, in step 602, the third network entity 300 may receive a UE address request message indicative of a request for one or more UE addresses. The UE address request message may be indicative of one or more RAN UE IDs of one or more UEs for which the one or more UE addresses are requested.

[0151] Optionally, in step 603, the third network entity may send 603 a UE address to the third network entity 300 performing the method 600, in response to the received 602 UE address request from the third network entity 300 performing the method 600.

[0152] The method 600 may be performed by the third network entity 300. For example, the modules 302, 303 and 304 may perform the steps 602, 603 and 604, respectively.

[0153] The technique may be applied to uplink (UL), downlink (DL) or direct communications between radio devices, e.g., device-to-device (D2D) communications or sidelink (SL) communications.

[0154] The embodiments of the methods 400, 500, and 600 which performed by the embodiments of the first network entity 100, the second network entity 200, and the third network entity 300 respectively, enables the network to perform analysis based on the obtained UE address and the corresponding RAN UE ID (e.g., address resolution).

[0155] For example, a service (e.g., the first network entity 100) in the O-RAN management domain (e.g., SMO) that stores 414 the UE address and the ephemeral RAN UE ID (e.g., the corresponding RAN UE ID) may bind 406 them to a tuple (e.g., ID-tuple pair). The binding 406 may also refer to as ID-binding. The binding 406 may be used to offer an UE address resolution and / or address translation service (also referred to as UEAddRes) to any one of the network entities (e.g., the first network entity 100 and the second network entity 200).

[0156] The method 600 performed by the third network entity 300 (e.g., UE and the RAN-O-CU) may provide the UE address and the RAN UE ID to the first network entity 100 (e.g., a new resolution service in the SMO).

[0157] Alternatively or in addition, the method 600 performed by the third network entity 300 (e.g., O-RAN or O-CU) may bind the UE address and the RAN UE ID into a tuple.

[0158] Alternatively or in addition, the method 600 performed by the first network entity 100 (e.g., the new resolution service in the SMO) may bind 406 the UE address and the RAN UE ID into a tuple.

[0159] Alternatively or in addition, the second network entity 200 that may be embodied by any entity in the network may request 510 an address resolution service using the RAN UE ID and discover the UE address. Address resolution and translation between RAN (e.g., O-RAN) internal temporary identities makes the UE addresses visible to the externally mobile networks e.g. on internet or applications servers (e.g., the second network entity 200).

[0160] The technique performed by the embodiments of the first network entity 100, and / or the second network entity 200 and / or the third network entity 300 may offer such an address resolution to any entity that has the required authorization levels and is correctly authenticated.

[0161] With embodiments of the technique, an AF or any other entity that only knows the external UE address (e.g. UE's IP address) may request analytics data according to O- RAN specification from any RAN node which has no knowledge of the UE address. For example, the AF may before requesting analytics data from the RAN node, resolve the external UE address to a RAN UE ID which is understood by the RAN node, such that the RAN node may collect and deliver the analytics data to the AF for exactly that UE owning the UE address.

[0162] The ID-binding 406 in the first network entity 100 (e.g., SMOS service), in addition to the address resolution, may also provide to the AF the current RAN node ID that is serving the UE. Due to mobility both the RAN UE ID and the RAN node ID may change - the ID-bind SMOS always has the updated information and provides the current data to a requesting AF.

[0163] In a variant of any embodiment, RAN UE ID may the RAN UE ID (e.g., RAN UE NGAP ID or the gNB-CU UE F1AP ID) defined in the 3GPP document TS 38.401, version 18.1.0, section 6.2.5.

[0164] For example, the RAN UE ID is an identifier allocated to a UE by the gNB-DU during UE Initial Access or by the gNB-CU during UE Context Setup. It is transferred over El and Fl interface, in order to do correlation of data for a given UE in case of disaggregated gNB deployment. The RAN UE ID is unique within a gNB.

[0165] Alternatively or in addition, the RAN UE NGAP ID shall be allocated so as to uniquely identify the UE over the NG interface within a gNB. When an AMF receives an RAN UE NGAP ID it shall store it for the duration of the UE-associated logical NG-connection for this UE. Once known to an AMF this is included in all UE associated NGAP signaling.

[0166] The RAN UE NGAP ID shall be unique within the logical NG-RAN node.

[0167] Alternatively or in addition, the gNB-CU UE F1AP ID shall be allocated so as to uniquely identify the UE over the Fl interface within a gNB-CU. When a gNB-DU receives a gNB- CU UE F1AP ID it shall store it for the duration of the UE-associated logical Flconnection for this UE. The gNB-CU UE F1AP ID shall be unique within the gNB-CU logical node.

[0168] In a variant of any embodiment, the RAN node ID may be defined according to the 3GPP document TS 38.401, version 18.1.0, e.g. according to any one of the sections 6.2.2 to 6.2.4 or a gNB-DU ID, or a ng-eNB-DU ID, a gNB-CU-UP ID, or a RAN UE ID.

[0169] Fig. 7 depicts the existing building blocks of the O-RAN architecture including the Service Management and Orchestration plane (SMO) 10 and the Y1 interface.

[0170] Network controllers are a proven element of network virtualization (NV). RAN intelligent controllers (RICs), as exemplified by the O-RAN Alliance's documentation, are a crucial component to a RAN based on open standards. The specific documentation outlining the O-RAN Alliance's RICs is the second version of "O-RAN Architecture Description" from July 2020. The publicly available architecture documentation from the Telecom Infra Project (TIP) does not go into as much detail as the O-RAN Alliance's does. That is why most of the following information is sourced from the O-RAN Alliance.

[0171] The O-RAN Alliance's RIC has two forms, a non-real-time RIC and a near real-time RIC. The two get their names from their response times. The non-real-time RIC takes one second or more to execute its functions and the near real-time RIC executes functions between 10 milliseconds and one second. Because of the discrepancy, the two controllers are responsible for different types of functions.

[0172] The non-real-time RIC is a logical function, meaning it is software and not hardware. It exists in the service management and orchestration (SMO) system. This RIC houses the policies that are referenced by the near real-time RIC for enforcement. The non-real- time RIC manages machine learning (ML) models that the near real-time RIC then uses to make decisions based on the network's current context. It only connects to the near real-time RIC, providing the policies, data, and ML models necessary for RAN optimization. The near real-time RIC is a logical function as well. It communicates between the Application layer, which exists within it and the non-real-time RIC, and the infrastructure layer, which includes the open central unit (O-CU) and the open distributed unit (O-DU). In this model, the O-CU had disaggregated control and user planes to add flexibility to the architecture. This RIC more directly controls and optimizes the lower levels of the RAN. It uses artificial intelligence (Al) and ML for automation purposes and to decide when to enforce policies that control routing and quality of service (QoS), among other policies.

[0173] As mentioned, the non-real-time RIC exists within the SMO framework, which is a combination of several management services. It is capable of going beyond supporting a RAN, but also can conduct network core management, transport management, and network slicing management.

[0174] Outside of the non-real-time RIC, the key aspects of the SMO include managing and orchestrating the open cloud (O-Cloud) as well as containing the FCAPS services for the O-RAN network elements. FCAPS stands for fault, configuration, accounting, performance, security; which are various management categories for maintaining and securing the O-RAN virtualized network function (vnf).

[0175] The O-Cloud is a collection of physical RAN nodes that host the RICs, CUs, and DUs; the software components such as the operating systems and runtime environments; and the SMO. To be clear, the SMO is managing and orchestrating the O-Cloud from within.

[0176] There are several interfaces at work within an O-RAN architecture. They include Open fronthaul interface, Al, 01, 02, X2, Xn, NG, El, E2, Fl.

[0177] The open fronthaul interface connects the O-DU and open radio unit (O-RU). It breaks down into the management plane (M-Plane) and the control user synchronization plane (CUS-Plane). The M-Plane connects the O-RU to the O-DU, and only optionally connects the O-RU to the SMO. The O-DU uses the M-Plane to manage the O-RU, while the SMO can provide FCAPS services to the O-RU.

[0178] The CUS-Plane is multi-functional. The control and user aspects transfer control signals and user data respectively. The remaining aspect synchronizes activities between multiple RAN devices.

[0179] The Al interface enables communication between the two RICs and supports policy management, data transfer, and ML management. The data, actually called enrichment information, is specifically for assisting the model training for the Al and ML in the near real-time RIC. The 01 interface connects the SMO to the RAN managed elements. These include the near real-time RIC, O-CU, O-DU, O-RU, and the open evolved NodeB (O-eNB) 30. The O-eNB is the hardware aspect of a 4G RAN. The management and orchestration functions are received by the managed elements via the 01 interface. The SMO in turn receives data from the managed elements via the 01 interface for Al model training.

[0180] The 02 interface is how the SMO communicates with the O-Cloud it resides in.

[0181] Network operators that are connected to the O-Cloud can then operate and maintain the network with the 01 or 02 interfaces by reconfiguring network elements, updating the system, or upgrading the system.

[0182] The X2 interface is broken up into the X2-c and X2-u interfaces, where the former is for the control plane and the latter is for the user plane. Both are originally designed by 3GPP for sending information between a 4G network's eNBs, or between an eNB and a 5G network's en-gNB. In the 0-RAN Alliance's documentation, the interface has the same principles and protocols. In the above image, Both of the X2 interfaces enter from outside the architecture, showing that they are incoming to another deployment. The Xn, NG, Fl, and El interfaces are all also adopted from 3GPP standards.

[0183] The Xn interface is also broken into control and user subtypes — Xn-c and Xn-u. They transfer control and user plane information between next generation NodeBs (gNBs), between ng-eNBs (4G nodes capable of connecting to a 5G core), or between the two different types.

[0184] The NG control and user plane interfaces connect an O-CU control plane (O-CU-CP) 30 and O-CU user plane (O-CU-UP) 30 to the 5G core. The control plane information goes to the 5G access and mobility management function (AMF), which receives connection and session information from the user equipment. The user plane information goes to the 5G user plane function (UPF), which handles many aspects of routing, forwarding, and tunneling.

[0185] The Fl interface, again broken into control and user plane subtypes, connects the O- CU-CP and O-CU-UP to the O-DU. It exchanges data about the frequency resource sharing and other network statuses. One O-CU can communicate with multiple O-DU via Fl interfaces.

[0186] The last of the 3GPP-based interfaces is the El interface. It connects the two disaggregated O-CU user and control planes. It transfers configuration data and capacity information between the two O-CU planes. The configuration data ensures the two planes can interoperate. The capacity information is sent from the user plane to the control plane and includes the status of the user plane. The near real-time RIC in the O-RAN architecture connects to the O-CU, O-DU, and O- eNB with the E2 interface. These elements combined make the E2 Node. An E2 Node can only connect to one near real-time RIC, but one of those RICs can connect to multiple E2 nodes. The protocols that go over the E2 interface are only control plane protocols. The protocols are for controlling and optimizing the E2 Node elements and the resources they use. Again, data collected is returned to the RIC over the interface.

[0187] The current O-RAN standards define the above components as follows:

[0188] 1) near-RT RIC: O-RAN near-real-time RAN Intelligent Controller: a logical function that enables near-real-time control and optimization of O-RAN elements and resources via fine-grained data collection and actions over E2 interface.

[0189] 2) non-RT RIC: O-RAN non-real-time RAN Intelligent Controller: a logical function that enables non-real-time control and optimization of RAN elements and resources, AI / ML workflow including model training and updates, and policybased guidance of applications / features in near-RT RIC.

[0190] 3) O-CU: O-RAN Central Unit: a logical node hosting RRC, SDAP and PDCP protocols.

[0191] 4) O-CU-CP: O-RAN Central Unit - Control Plane: a logical node hosting the RRC and the control plane part of the PDCP protocol.

[0192] 5) O-CU-UP: O-RAN Central Unit - User Plane: a logical node hosting the user plane part of the PDCP protocol and the SDAP protocol.

[0193] 6) O-DU: O-RAN Distributed Unit: a logical node hosting RLC / MAC / High-PHY layers based on a lower layer functional split.

[0194] 7) O-RU: O-RAN Radio Unit: a logical node hosting Low-PHY layer and RF processing based on a lower layer functional split. This is similar to 3GPP's "TRP" or "RRH" but more specific in including the Low-PHY layer (FFT / iFFT, PRACH extraction).

[0195] 8) xAPP (not depicted): Independent software plug-in to the Near-RT RIC platform to provide functional extensibility to the RAN by third parties.

[0196] 9) rAPP (not depicted): Independent software plug-in to the Non-RT RIC platform to provide functional extensibility to the RAN by third parties.

[0197] Currently neither 3GPP nor O-RAN provide such an (externally visible) UE address to RAN UE ID resolution. At the same time O-RAN specifies an interface (Y1 interface) where AFs, as well as any other entity within the network, can request RAN analytics data. Currently in the O-RAN standards the AF, generically referred to as Y1 consumer 20 in O-RAN specifications, is using an arbitrary and unspecified address type or ID type to identify a UE. Then New interface for RAN analytics information exposure: Fine-grained RAN analytics exposed by the Near-RT RIC platform over the new Y1 services-based interface for consumers such as packet core functions or application servers or edge servers have a wide variety of use cases.

[0198] AFs currently cannot indicate to the RAN for which UE analytics data is requested and the RAN cannot identify the correct UE based on the information received from the AFs. Therefore, the currently specified RAN Analytics Information Exposure (RAIE) service, is not possible to be used in real network deployments.

[0199] Certain O-RAN architecture terms are derived from 3GPP architecture terms. For example, the O-RU and O-DU are analogous to a 3GPP DU and the O-CU and near RT- RIC are analogous to a 3GPP CU. Fig. 8 graphically depicts the correspondence of terms. Fig. 8 shows basic O-RAN architecture and 3GPP terminology.

[0200] Fig. 9 shows an exemplary communication system 700 e.g., a radio communication system in accordance with some embodiments.

[0201] In the example, the communication system 700 includes a telecommunication network 702 that includes an access network 704, such as a radio access network (RAN), and a core network 706, which includes one or more core network nodes 708. The access network 704 includes one or more access network nodes, such as network nodes 710a and 710b (one or more of which may be generally referred to as network nodes 710), or any other similar 3rd Generation Partnership Project (3GPP) access nodes or non- 3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 702 includes one or more Open-RAN (O-RAN) network nodes. An O-RAN network node is a node in the telecommunication network 702 that supports an O-RAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 702, including one or more network nodes 710 and / or core network nodes 708.

[0202] Examples of an O-RAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective "open" designating support of an O-RAN specification). The network node may support a specification by, for example, supporting an interface defined by the O-RAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an O-RAN access node may be a logical node in a physical node. Furthermore, an O-RAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the O-RAN Alliance or comparable technologies. The network nodes 710 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 712a, 712b, 712c, and 712d (one or more of which may be generally referred to as UEs 712) to the core network 706 over one or more wireless connections.

[0203] Fig. 10 shows an exemplary of the building blocks and the overall proposed technique for address resolution according to some embodiments.

[0204] The SMO 10 may embody a first network entity 100 (e.g., ID-binding Service & Management Orchestration Service (ID-bind SMOS)). The new entity ID-bind SMOS 100 may receive the request from a second network entity 200 (e.g., an 'Address resolution requester' entity). The address resolution requester may be embodied by the second network entity 200. The second network entity 200 may be, e.g., an external AF or an Y1 consumer or any network internal node or function.

[0205] The third network entity 300 (e.g., RAN nodes gNB or O-CU-CP) may send 604 a message indicative of a bind request to the first network entity 100 (ID-bind SMOS) including the RAN UE ID. That is to request to bind the RAN UE ID to the UE address.

[0206] The request may comprise the UE address which is known to the 'Address resolution requester' entity 200. As a reply 412 to that request the 'Address resolution requestor' 200 may expect the RAN UE ID corresponding to the UE address. Once the 'Address resolution requester' 200 receives 512 the RAN UE ID it may request, e.g., RAN analytics data from RAN nodes. That RAN data analytics service may be standardized.

[0207] Fig. 11 shows a message flow of a first exemplary embodiment of the proposed methods for address resolution, i.e., case 1.

[0208] The example of Fig. 11 may be a simple procedure that the third network entity 300-a (e.g., a UE) may send 603 its own UE address to another third network entity 300-b (e.g., a RAN node). In some cases the UE 300-a may not support providing the UE address, so that the first network entity 100 (e.g., ID-bind SMOS) will cater for that UE address resolution automatically (following case 2a and case 2b).

[0209] In case the RAN node 300-b (e.g., gNB-CU or O-CU-CP) also knows the UE address, it may send 604 both the RAN UE ID and UE address to the first network entity 100 (e.g., ID-bind SMOS). This is further referred to as case 1.

[0210] The UE 300-a may use an extended SDAP frame structure to include the UE address in an up-link SDAP frame sent 603 to another third network entity 300-b (e.g., gNB-CU or O-CU-CP) performing the method 600. The gNB-CU or O-CU-CP 300-b may extract that UE address information and use it in the ID-bind request 604 towards the ID-bind SMOS 100. Alternatively or in addition, the first network entity 100 (e.g., the ID-bind SMOS) may store 414 the tuples in a tuple table. This scenario may be referred to as case 1.

[0211] Fig. 12 shows a message flow of a second exemplary embodiment of the proposed methods for address resolution, i.e., case 2a.

[0212] In case 2a the third network entity 300-b (e.g., RAN node) may not know the UE address, and therefore, it may omit that information in the ID-bind request 604 and the ID-bind SMOS 100 may send 402 a UE address request to another third network entity 300-c (e.g., a 5G core network 5GC) to discover the UE address. The 5GC 300-c may reply 604 with the UE address, the ID-bind SMOS 100 may bind the RAN UE ID and UE address in a tuple. Alternatively or in addition, the first network entity 100 (e.g., the ID-bind SMOS) may store 414 the tuples in a tuple table. This scenario may be referred to as case 2a.

[0213] Fig. 13 shows a message flow of a third exemplary embodiment of the proposed technique, i.e., case 2b.

[0214] Alternatively to case 2a, if the UE address may not be known in the third network entity 300-b (e.g., a gNB) it may request 602 the UE address from another third network entity 300-c (e.g., 5GC) before sending 604 the ID-bind request to the first network entity 100 (e.g., ID-bind SMOS). After successful completion of this request 603 the RAN UE ID and UE address may be included in the ID-bind request 604 to the first network entity 100 (e.g., SMOS). This scenario may be referred to as case 2b.

[0215] The PDU session establishment in a third network entity 300-a (e.g., UE), according to Figs. 11 to 13: After a PDU session is established in the UE 300-a and the QoS Flow is mapped to a radio bearer, the UE 300-a, if supported, sends an up-link SDAP control message that may comprise the UE address and the address type used for that PDU session. The SDAP control message header bit D / C may be set to 0 (as per standard) indicating a control PDU (e.g., according to Fig. 11, case 1). The header of that control PDU according to the proposed technique, may further comprise an address type indicator to differentiate different types of UE addresses, the UE address length in octets, and the UE address.

[0216] The PDU session establishment in a third network entity 300-b (e.g., a RAN node) performing the method 600, according to Figs. 11 to 13:

[0217] After a PDU session is established in the third network entity 300-b (e.g., a RAN node and / or a gNB-CU and / or an O-CU-CP), the third network entity 300-b may start a timer Tl.

[0218] When the third network entity 300-b (e.g., a RAN node and / or a gNB-CU and / or an O- CU-CP) receives an extended SDAP control frame from the UE 300-a, it stops timer Tl, extracts the UE address type and the UE address and stores them (e.g., in the internal data base).

[0219] The RAN node 300-b may send 604 an ID-bind request to the first network entity 100 (e.g., ID-bind SMOS) comprising the RAN UE ID and UE address (Fig. 11, case 1). The SMOS 100 may store 414 the tuple and additionally the RAN node ID from which the ID-bind request was received (e.g., as a tuple table).

[0220] The expiration of timer Tl indicates that no SDAP control frame was received in a predefined time. In that case the RAN node 300-b may store a tuple with an empty (void) UE address and sends 604 a ID-bind request to the ID-bind SMOS 100 including the RAN UE ID only (Fig. 12, case 2a). As a result of the missing UE address, the SMOS 100 may send 402 a UE address request to the 5GC 300-c comprising the RAN UE ID. When the 5GC 300-c replies (e.g., sends) 604 with the UE address and address type, the SMOS 100 may store 414 the tuple and the RAN node ID from which the ID-bind request was received (e.g., as a tuple table). Alternatively or in addition (e.g., according to Fig. 13, case 2b), when the timer T1 expires (e.g., the connection is lost and / or the UE address is not received in a predefined time), the RAN node 300-b (e.g., the third network entity performing the method 600) may store an empty (void) UE address and send 602 a UE address request to another third network entity 300-c (e.g., the 5GC). When the 5GC 300-c sends (e.g., replies) 602 with the UE address and address type information, the RAN node 300-b may store the UE address and type. Afterwards the RAN node 300-b may send 604 an ID-bind request to the ID-bind SMOS 100 comprising the RAN UE ID and UE address e.g., similar to case 1. The SMOS 100 may further store 414 the tuple and the RAN node ID from which the ID-bind request was received 404.

[0221] In the event of a change of state of the UE RRC, according to Figs. 11 to 13:

[0222] When a UE changes state from RRC inactive to RRC active, it may send, if supported, an extended SDAP frame including UE address, type and length as described in case 1 above. If not supported, case 2a and case 2b may apply.

[0223] In case the UE context is re-established, e.g. due to a mobility event, according to Figs. 11 to 13:

[0224] When a third network entity 300-b (e.g., RAN node) is requested to establish a new UE context for a UE 300-a that already has one or more established PDU sessions, that RAN node 300-b may start Timer T1 and may execute all steps as described in case 1, 2a or 2b.

[0225] Alternatively or in addition, a UE context may expire in a RAN node 300-b due to UE inactivity or due to a mobility event (e.g. handover to another RAN node). In such cases the PDU session and the UE address may remain unchanged, but the RAN UE ID and the RAN node ID may be changed.

[0226] At any time an AF 200, or any other second network entity 200, may request from the ID-bind SMOS 100 the resolution of a UE address. The AF 200, or any other second network entity 200, may send 510 the 'Address Resolution Service Request' comprising the UE address. In case the UE address may be resolved the SMOS 100 may reply (e.g., send) 412 with Address Resolution Service response comprising the tuple RAN UE ID and UE address and also it may further comprise the RAN node ID. In case the UE address may not be resolvable, or the second network entity 200 (e.g., address resolution requestor) is not authorized for the service, an error indication is returned.

[0227] Based on the successful UE address resolution information, the AF 200 may then request 510, e.g., analytics data from the RAN node 300-b- identified by the RAN node ID- that serves the UE 300-a currently. The ID-bind SMOS 100 may also send 412 an Address Resolution Service Notify to the AF 200 at any time to indicate:

[0228] - an updated tuple or updated RAN node ID, and / or

[0229] - an updated tuple table, and / or

[0230] UE 300-a is no longer available for any resolution services, in which case all data is set to void.

[0231] The first network entity 100 (e.g., the ID-bind SMOS) may keep track of changes of any UE address and / or request for one or more UE address from third network entity 300 and keep the tuple table update by storing the new UE address and the corresponding RAN UE ID.

[0232] The first network entity 100 may send a resolution message indicative of one or more tuples of the maintained 408 tuple table to a second network entity 200 (e.g., according to Figs. 11 to 13). Sending 412 the resolution message may be based on a request message received 410 from the second network entity 200. Alternatively or in addition, sending 412 the resolution message may be periodically scheduled in the first network entity 100. Alternatively or in addition, sending the resolution message may be triggered by an event, such as, a change in the tuple table (e.g., a handover of a UE and / or a removed UE).

[0233] Fig. 14 shows a schematic block diagram for an embodiment of the first network entity 100. The first network entity 100 comprises processing circuitry, e.g., one or more processors 1404 for performing the method 400 and memory 1406 coupled to the processors 1404. For example, the memory 1406 may be encoded with instructions that implement at least one of the modules 102, to 114.

[0234] The one or more processors 1404 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, microcode and / or encoded logic operable to provide, either alone or in conjunction with other components of the first network entity 100, such as the memory 1406, transmitter functionality. For example, the one or more processors 1404 may execute instructions stored in the memory 1406. Such functionality may include providing various features and steps discussed herein, including any of the benefits disclosed herein. The expression "the device being operative to perform an action" may denote the first network entity 100 being configured to perform the action. As schematically illustrated in Fig. 14, the first network entity 100 may be embodied by a transmitting station 1400, e.g., functioning as a transmitting base station or a transmitting UE. The transmitting station 1400 comprises a radio interface 1402 coupled to the first network entity 100 for radio communication with one or more receiving stations, e.g., functioning as a receiving base station or a receiving UE.

[0235] Fig. 15 shows a schematic block diagram for an embodiment of the second network entity 200. The second network entity 200 comprises processing circuitry, e.g., one or more processors 1504 for performing the method 500 and memory 1506 coupled to the processors 1504. For example, the memory 1506 may be encoded with instructions that implement at least one of the modules 210, 212 and 214.

[0236] The one or more processors 1504 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, microcode and / or encoded logic operable to provide, either alone or in conjunction with other components of the second network entity 200, such as the memory 1506, receiver functionality. For example, the one or more processors 1504 may execute instructions stored in the memory 1506. Such functionality may include providing various features and steps discussed herein, including any of the benefits disclosed herein. The expression "the device being operative to perform an action" may denote the second network entity 200 being configured to perform the action.

[0237] As schematically illustrated in Fig. 15, the second network entity 200 may be embodied by a second network entity 1500, e.g., functioning as a receiving base station or a receiving UE. The second network entity 1500 comprises a radio interface 1502 coupled to the second network entity 200 for radio communication with one or more transmitting stations, e.g., functioning as a transmitting base station or a transmitting UE.

[0238] Fig. 16 shows a schematic block diagram for an embodiment of the third network entity 300. The second network entity 300 comprises processing circuitry, e.g., one or more processors 1604 for performing the method 600 and memory 1606 coupled to the processors 1604. For example, the memory 1606 may be encoded with instructions that implement at least one of the modules 302, 303 and 304.

[0239] The one or more processors 1604 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, microcode and / or encoded logic operable to provide, either alone or in conjunction with other components of the third network entity 300, such as the memory 1606, receiver functionality. For example, the one or more processors 1604 may execute instructions stored in the memory 1606. Such functionality may include providing various features and steps discussed herein, including any of the benefits disclosed herein. The expression "the device being operative to perform an action" may denote the second network entity 200 being configured to perform the action.

[0240] As schematically illustrated in Fig. 16, the third network entity 300 may be embodied by a second network entity 1600, e.g., functioning as a receiving base station or a receiving UE. The second network entity 1600 comprises a radio interface 1602 coupled to the third network entity 300 for radio communication with one or more transmitting stations, e.g., functioning as a transmitting base station or a transmitting UE.

[0241] Each of the embodiments of the address resolution technique described herein may be used independently or in combination with one or more of the other embodiments.

[0242] Many advantages of the present invention will be fully understood from the foregoing description, and it will be apparent that various changes may be made in the form, construction and arrangement of the units and devices without departing from the scope of the invention and / or without sacrificing all of its advantages. Since the invention can be varied in many ways, it will be recognized that the invention should be limited only by the scope of the following embodiments.

[0243] List of reference signs

[0244] 100 First network entity

[0245] 102 Sending UE address request module

[0246] 104 Receiving UE address binding request module

[0247] 106 Binding module

[0248] 108 Maintaining module

[0249] 110 Receiving request module

[0250] 112 Sending module

[0251] 114 Storing module

[0252] 200 Second network entity

[0253] 210 Sending request module

[0254] 212 Receiving module

[0255] 214 Performing module

[0256] 300 Third network entity

[0257] 302 Sending UE address request module

[0258] 303 Sending UE address module

[0259] 304 Sending UE address binding request module

[0260] 400 Method performed by the first network entity for address resolution

[0261] 402 Sending a UE address request message

[0262] 404 Receiving a UE address binding request message

[0263] 406 Binding a UE address and a corresponding RAN UE ID

[0264] 408 Maintaining a tuple table

[0265] 410 Receiving a request message

[0266] 412 Sending a resolution message

[0267] 414 Storing the tuple table

[0268] 500 Method performed by the second network entity for address resolution

[0269] 510 Sending a request message

[0270] 512 Receiving a resolution message

[0271] 514 initiate performing a RAN analysis

[0272] 600 Method performed by the third network entity for address resolution

[0273] 602 Receiving a UE address request

[0274] 603 sending a UE address to the third network entity

[0275] 604 Sending a UE address binding request

[0276] 700 Communication system

[0277] 702 Telecommunication network

[0278] 704 Access network

[0279] 706 Core network

[0280] 708 Core network nodes

[0281] 710 Network nodes

[0282] 10 SMO

[0283] 20 Y1 consumer

[0284] 30 O-CU interface 1400 Station

[0285] 1402 Radio interface

[0286] 1404 Processors

[0287] 1406 Memory 1500 Network entity

[0288] 1502 Radio interface

[0289] 1504 Processors

[0290] 1506 Memory

[0291] 1600 Network entity 1602 Radio interface

[0292] 1604 Processors

[0293] 1606 Memory

Claims

Claims1. A method (400) performed by a first network entity (100; 1400) for address resolution, the method (400) comprising or initiating: maintaining (408) a tuple table, wherein the tuple table comprises one or more tuples, each of which comprises a UE address component indicative of a UE address of a user equipment, UE, and a RAN UE ID component indicative of a RAN UE identifier, RAN UE ID, of the UE in a radio access network, RAN; and sending (412), to a second network entity (200; 1500), a resolution message indicative of the RAN UE ID of at least one of the one or more tuples of the maintained (408) tuple table.

2. The method (400) of claim 1, wherein the sent (412) resolution message is indicative of at least one of the one or more tuples of the maintained (408) tuple table; and / or wherein the sent (412) resolution message is indicative of a combination of the UE address and the RAN UE ID of at least one of the one or more tuples of the maintained (408) tuple table; and / or wherein the sent (412) resolution message is indicative of the RAN UE ID in association with the UE address of at least one of the one or more tuples of the maintained (408) tuple table.

3. The method (400) of claim 1 or 2, wherein each of the one or more tuples of the tuple table further comprises a RAN node ID component indicative of a RAN node identifier, RAN node ID, of a RAN node serving the UE indicated by the respective tuple.

4. The method (400) of any one of claims 1 to 3, further comprising or initiating: binding (406) a UE address and a corresponding RAN UE ID and / or a corresponding RAN node ID to a tuple of the tuple table.

5. The method (400) of any one of claims 1 to 4, further comprising or initiating: receiving (404) a UE address binding request message from a third network entity (300-a; 300-b; 300-c; 1600), optionally wherein the UE address binding request message is indicative of the UE address of a UE and / or the RAN UE ID of a UE in the RAN.

6. The method (400) of claim 5, wherein the maintaining (408) of the tuple table comprises maintaining (408) the UE address component, the RAN UE ID component,and / or the RAN node ID component of a tuple of the tuple table based on the received (404) UE address binding request message indicative of at least one of a UE address, a corresponding RAN UE ID and / or a corresponding RAN node ID.

7. The method (400) of any one of claims 1 to 6, further comprising or initiating: sending (402) a UE address request message to a third network entity (300-a;300-b; 300-c; 1600) indicative of a request for one or more UE addresses, optionally wherein the UE address request message is sent (402) responsive to one or more missing or outdated UE address component in a tuple of the tuple table.

8. The method (400) of any one of claims 1 to 7, further comprising or initiating: receiving (410) a resolution request message from the second network entity(200; 1500) indicative of a request for at least the RAN UE ID of at least one of the one or more tuples of the maintained (408) tuple table, optionally wherein the resolution message is sent (412) responsive to the received (410) resolution request message and / or wherein the resolution request message is indicative of at least the UE address of the at least one of the one or more tuples.

9. The method (400) of any one of claims 1 to 8, wherein the maintaining (408) of the tuple table comprises, responsive to an event of the UE in the RAN, maintaining (408) the RAN UE ID component corresponding to the UE or the UE address of the UE and / or maintaining (408) the RAN node ID component corresponding to the UE or the UE address of the UE, optionally wherein the event comprises a mobility of the UE in the RAN and / or a random access procedure .

10. The method (400) of any one of claims 1 to 9, wherein the sending (412) of the resolution message indicative of the RAN UE ID of at least one of the one or more tuples of the maintained (408) tuple table is triggered by a change of one or more of the components of the at least one of the one or more tuples of the maintained (408) tuple table.

11. The method (400) of any one of claims 1 to 10, further comprising or initiating: storing (414) the tuple table in a local storage of the RAN and / or in a network- distributed storage of the RAN.

12. A method (500) performed by a second network entity (200; 1500) for address resolution, the method (500) comprising or initiating:receiving (512), from a first network entity (100; 1400), a resolution message indicative of a RAN UE ID of at least one of one or more tuples of a tuple table maintained at the first network entity (100; 1400), wherein each of the one or more tuples comprises a UE address component indicative of a UE address of a user equipment, UE, and a RAN UE ID component indicative of a RAN UE identifier, RAN UE ID, of the UE in a radio access network, RAN.

13. The method (500) of claim 12, wherein the received (512) resolution message is indicative of at least one of the one or more tuples of the tuple table maintained at the first network entity (100; 1400); and / or wherein the received (512) resolution message is indicative of a combination of the UE address and the RAN UE ID of at least one of the one or more tuples of the tuple table maintained at the first network entity (100; 1400); and / or wherein the received (512) resolution message is indicative of the RAN UE ID in association with the UE address of at least one of the one or more tuples of the tuple table maintained at the first network entity (100; 1400).

14. The method (500) of claim 12 or 13, wherein one or each of the one or more tuples of the tuple table further comprises a RAN node ID component indicative of a RAN node identifier, RAN node ID, of a RAN node serving the UE indicated by the respective tuple.

15. The method (500) of any one of claims 12 to 14, further comprising or initiating: sending (510) a resolution request message to the first network entity (100;1400) indicative of a request for the resolution message for the at least one UE, optionally wherein the resolution message is received (512) responsive to the sent (510) resolution request message and / or wherein the resolution request message is indicative of at least the UE address of the at least one UE.

16. The method (500) of any one of claims 12 to 15, further comprising or initiating: performing (514) a RAN analysis for the UE based on the RAN UE ID indicated by the received (510) resolution message for the UE.

17. A method (600) performed by a third network entity (300-a; 300-b; 300-c; 1600) for address resolution, the method (600) comprising or initiating: sending (604) a UE address binding request message to a first network entity (100; 1400), wherein the UE address binding request message is indicative of a UE address of a user equipment, UE, for maintaining a tuple table comprising one or more tuples, each of which comprises a UE address component indicative of the UE address ofthe UE and a RAN UE ID component indicative of a RAN UE identifier, RAN UE ID, of the UE in a radio access network, RAN.

18. The method (600) of claim 17, further comprising or initiating: receiving (602) a UE address request message indicative of a request for one or more UE addresses of one or more UEs, optionally wherein the UE address request message is indicative of one or more RAN UE IDs of the one or more UEs for which the one or more UE addresses are requested and / or wherein the UE address binding request message is sent responsive to the received (602) UE address request message.

19. The method (600) of claim 17 or 18, wherein the UE address request message is received (602) from the first network entity (100; 1400) and / or from another third network entity (300-a; 300-b; 300-c; 1600) other than the third network entity (300-a; 300-b; 300-c; 1600) performing the method (600).

20. The method (600) of any one of claim 19, further comprising or initiating: sending (603) the one or more UE addresses to the first network entity (100; 1400) and / or the other third network entity (300-a; 300-b; 300-c; 1600) in response to the received (602) UE address request message.

21. The method (600) of claims 19 or 20, wherein the sending (603) of the one or more UE addresses to the first network entity (100; 1400) is in response to the UE address request message received (602) from the first network entity (100; 1400).

22. A computer program product comprising program code portions for performing the steps of any one of the claims 1 to 11, and / or 12 to 16, and / or 17 to 21 when the computer program product is executed on one or more computing devices (1404; 1504; 1604), optionally stored on a computer-readable recording medium (1406; 1506; 1606).

23. A first network entity (100; 1400) comprising memory operable to store instructions and processing circuitry operable to execute the instructions, such that the first network entity (100; 1400) is operable to: maintain (408) a tuple table, wherein the tuple table comprises one or more tuples, each of which comprises a UE address component indicative of a UE address of a user equipment, UE, and a RAN UE ID component indicative of a RAN UE identifier, RAN UE ID, of the UE in a radio access network, RAN; andsend (412), to a second network entity (200; 1500), a resolution message indicative of the RAN UE ID of at least one of the one or more tuples of the maintained (408) tuple table.

24. The first network entity (100; 1400; 1300) of claim 23, further operable to perform the steps of any one of claims 2 to 11.

25. A first network entity (100; 1400) for address resolution, configured to: maintain (408) a tuple table, wherein the tuple table comprises one or more tuples, each of which comprises a UE address component indicative of a UE address of a user equipment, UE, and a RAN UE ID component indicative of a RAN UE identifier, RAN UE ID, of the UE in a radio access network, RAN; and send (412), to a second network entity (200; 1500), a resolution message indicative of the RAN UE ID of at least one of the one or more tuples of the maintained (408) tuple table.

26. The first network entity (100; 1400; 1300) of claim 25, further configured to perform the steps of any one of claims 2 to 11.

27. A second network entity (200; 1500) comprising memory operable to store instructions and processing circuitry operable to execute the instructions, such that the second network entity (200; 1500) is operable to: receive (512), from a first network entity (100; 1400), a resolution message indicative of a RAN UE ID of at least one of one or more tuples of a tuple table maintained at the first network entity (100; 1400), wherein each of the one or more tuples comprises a UE address component indicative of a UE address of a user equipment, UE, and a RAN UE ID component indicative of a RAN UE identifier, RAN UE ID, of the UE in a radio access network, RAN.

28. The second network entity (200; 1500) of claim 27, further operable to perform any one of the steps of any one of claims 13 to 16.

29. A second network entity (200; 1500) for address resolution, configured to: receive (512), from a first network entity (100; 1400), a resolution message indicative of a RAN UE ID of at least one of one or more tuples of a tuple table maintained at the first network entity (100; 1400), wherein each of the one or more tuples comprises a UE address component indicative of a UE address of a user equipment, UE, and a RAN UE ID component indicative of a RAN UE identifier, RAN UE ID, of the UE in a radio access network, RAN.

30. The second network entity (200; 1500) of claim 29, further configured to perform the steps of any one of claims 13 to 16.

31. A third network entity (300-a; 300-b; 300-c; 1600) comprising memory operable to store instructions and processing circuitry operable to execute the instructions, such that the third network entity (300-a; 300-b; 300-c; 1600) is operable to: send (604) a UE address binding request message to a first network entity (100; 1400), wherein the UE address binding request message is indicative of a UE address of a user equipment, UE, for maintaining a tuple table comprising one or more tuples, each of which comprises a UE address component indicative of the UE address of the UE and a RAN UE ID component indicative of a RAN UE identifier, RAN UE ID, of the UE in a radio access network, RAN.

32. The third network entity (300-a; 300-b; 300-c; 1600) of claim 31, further operable to perform any one of the steps of any one of claims 18 to 21.

33. A third network entity (300-a; 300-b; 300-c; 1600) for address resolution, configured to: send (604) a UE address binding request message to a first network entity (100; 1400), wherein the UE address binding request message is indicative of a UE address of a user equipment, UE, for maintaining a tuple table comprising one or more tuples, each of which comprises a UE address component indicative of the UE address of the UE and a RAN UE ID component indicative of a RAN UE identifier, RAN UE ID, of the UE in a radio access network, RAN.

34. The third network entity (300-a; 300-b; 300-c; 1600) of claim 33, further configured to perform the steps of any one of claims 18 to 21.

Images