WO2025124751A1 - Method and apparatus for registering and discovering radio access network services - Google Patents

Abstract

Various aspects of the present disclosure relate to apparatus of a Radio Access Network, RAN, comprising at least one memory, and at least one processor coupled with the at least one memory and configured to cause the apparatus to receive a request for registering one or more RAN services, authenticate the request and, in response to authenticating the request, generate a registration identity for the or each RAN service, and update a RAN service database with the registration identity.

Description

Method and Apparatus for Registering and Discovering Radio Access Network Services

TECHNICAL FIELD

[0001] The present disclosure relates to wireless communications, and more specifically to a method and apparatus for registering and discovering Radio Access Network services.

BACKGROUND

[0002] A wireless communications system may include one or multiple network communication devices, such as base stations, which may support wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE), or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers, or the like). Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G)).

SUMMARY

[0003] An article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a,” “at least one,” “one or more,” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of’ or “one or more of’ or “one or both of’) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Also, as used herein, the phrase “based on” shall not be construed as a reference to a closed set of conditions. For example, an example step that is described as “based on condition A” may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be constmed in the same manner as the phrase “based at least in part on. Further, as used herein, including in the claims, a “set” may include one or more elements.

[0004] Some implementations of the method and apparatuses described herein may further include an apparatus of a Radio Access Network, RAN, comprising at least one memory, and at least one processor coupled with the at least one memory and configured to cause the apparatus to receive a request for registering one or more RAN services, authenticate the request and, in response to authenticating the request, generate a registration identity for the or each RAN service, and update a RAN service database with the registration identity.

[0005] In some implementations of the method and apparatuses described herein the request may include RAN service exposure information for the or each RAN service, and the processor may be configured to cause the apparatus to update the RAN service database with the RAN service exposure information.

[0006] The processor may be configured to further update the RAN service database with an identification of the or each RAN entity providing said RAN service exposure information. The or each RAN entity may be one of a RAN network function, a Distributed Unit (DU), Centralized Unit (CU), Resource Unit (RU), RAN Intelligent Controller (RIC), or a RAN protocol function. The processor may be configured to cause the apparatus to obtain a further request from a consumer entity to discover at least one registered RAN service based on a requirement, fetch at least one of the registered RAN services based on the requirement, an identity or property of the consumer, and the RAN service exposure information, and send a discovery response to the further request indicating the identity and RAN service exposure information for the fetched at least one of the registered RAN services. [0007] The requirement may define or otherwise be associated with one or more of: a network slice; a core network procedure; a RAT or RAN configuration; a QoS/QoE target or intent/goal; a UE or group of UEs; an application or application service; a cell or list of cells; at least one RAN entity; an edge or cloud resource; and a data radio bearer and/or a QoS flow.

[0008] The consumer entity may be a core network function, an application function, a management function, an edge or cloud function, or a further RAN entity. A RAN entity may comprise one or more RAN functions or RAN network functions, which in turn consist of one or more RAN function services or RAN services. A RAN entity may be a gNB or a part of gNB (CU, DU) in disaggregated RAN deployments.

[0009] The apparatus may be a base station or forming part of a base station.

[0010] The processor may be configured to cause the apparatus to send a response to the request including the registration identity and registration information.

[0011] The or each RAN service may comprise at least one or combination of: an RRM function service; a Distributed-SON function service; a RAN analytics service; an Al / ML support service; a RAN Capability Exposure Support Service; a RAN proxy or gateway service; a CU service, a DU service; and an XnAPP service, an NGAPP service, a MEC service.

[0012] The processor may be configured to publish the RAN service database update to at least one external entity, wherein the external entity is a core network function, a management function, an application function or a combination thereof.

[0013] The processor may configured to obtain a request for registering one or more RAN services by receiving the request from a RAN service exposure gateway or a RAN network function.

[0014] The apparatus may be a repository entity covering one or more RAN nodes. [0015] The apparatus may be a RAN service API registry, for example a CAPIF Core Function.

[0016] A registration identity may be shared by two or more RAN services, for example with a group of RAN services that are “clustered” together due to dependencies or physical placement in different RAN nodes.

[0017] Some implementations of the method and apparatuses described herein may further include a method implemented in a Radio Access Network, RAN, and comprising receiving a request for registering one or more RAN services, authenticating the request and, in response to authenticating the request, generating a registration identity for the or each RAN service, and updating a RAN service database with the registration identity.

[0018] In some implementations of the method and apparatuses described herein the request may include RAN service exposure information for the or each RAN service, the method comprising updating the RAN service database with the RAN service exposure information.

[0019] The RAN service database may be updated with an identification of the or each RAN entity providing said RAN service exposure information.

[0020] The or each RAN entity may be one of a RAN network function, a DU, CU, RU, RIC, or a RAN protocol function.

[0021] The method may comprise obtaining a further request from a consumer entity to discover at least one registered RAN service based on a requirement, fetching at least one of the registered RAN services based on the requirement, an identity or property of the consumer, and the RAN service exposure information, and sending a discovery response to the further request indicating the identity and RAN service exposure information for the fetched at least one of the registered RAN services.

[0022] Said requirement may define or be associated with one or more of: a network slice; a core network procedure; a RAT or RAN configuration; a QoS/QoE target or intent/goal; a UE or group of UEs; an application or application service; a cell or list of cells; at least one RAN entity; an edge or cloud resource; and a data radio bearer and/or a QoS flow.

BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 illustrates RAN control functionality and RAN-CN split in current mobile networks.

[0024] Figure 2 illustrates an example of dependencies if RRM functionalities split in the gNB (or even CU and DU) and edge/cloud.

[0025] Figure 3 illustrates an example of a wireless communications system in accordance with aspects of the present disclosure.

[0026] Figure 4 illustrates a high level service-based architecture.

[0027] Figure 5 illustrates a procedure for registering RAN service exposure GW services.

[0028] Figure 6 illustrates procedures for registering RAN service(s).

[0029] Figure 7 illustrates a procedure for discovering RAN service exposure GW services.

[0030] Figure 8 illustrates a procedure for discovering RAN service(s).

[0031] Figure 9 illustrates a CAPIF service-based architecture using interfaces (Cccf, Caef).

[0032] Figure 10 illustrates a procedure for registration of API provider domain functions on CAPIF.

[0033] Figure 11 illustrates a procedure for discovering RAN APIs .

[0034] Figure 12 illustrates an example of a network equipment (NE) 200 in accordance with aspects of the present disclosure.

[0035] Figure 13 illustrate a flowchart of a method performed by a NE in accordance with aspects of the present disclosure.

DETAILED DESCRIPTION [0036] The Service based architecture has evolved from monolithic to service-oriented architecture (SO A) towards microservices and serverless:

[0037] A SOA is a software architecture style that refers to an application composed of discrete and loosely coupled software agents that perform a required function. SOA has two main roles: a service provider and a service consumer. Both roles can be played by a software agent. The concept of SOA lies in the following: an application can be designed and built in a way that its modules are integrated seamlessly and can be easily reused.

[0038] Microservice is a type of service-oriented software architecture that focuses on building a series of autonomous components that make up an app. Unlike monolithic apps built as a single indivisible unit, microservice apps consist of multiple independent components that are glued together with APIs. The biggest advantage of microservices over other architectures is that small single services can be built, tested, and deployed independently. On the other hand, a disadvantage of microservices based architecture is that each functionality that communicates externally via an API increases the chance of attacks. These attacks can only happen however if proper security measurements are not implemented when building an app. Also, using different languages makes deployment more difficult.

[0039] Serverless architecture is a cloud computing approach to building and running apps and services without the need for infrastructure management. In serverless apps, code execution is managed by a server, allowing developers to deploy code without worrying about server maintenance and provision. In fact, “serverless” here does not mean “no server”: the application is still running on servers, but a third-party cloud service like AWS™ takes full responsibility for these servers. A serverless architecture eliminates the need for extra resources, application scaling, server maintenance, and database and storage systems.

[0040] 3 GPP including the enablement layer (as specified in SA6) uses service-based representations of the architecture. However, different architectures have different types of SBA: 3 GPP SA2, which concerns the 3gpp system architecture, uses conventional SB A, where the NF is the service producer and the SBI bus is used for the interaction with service consumers (NFs/AFs).

3 GPP SA5. which concerns OAM aspects of the network, uses service-based management architecture, closer to a microservice paradigm. 3 GPP SA5 specifies the notion of MnS as an API that can be integrated in any management function. It allows an MnS Producer to interact with an MnS Consumer (a service producer with a service consumer) via a standardized MnS interface.

3 GPP SA6 uses SA2 paradigm for SEAL; however in other enablers (like EDGEAPP) the service-based support has different variants (SA2-based for interaction with 5GC, and microservice-based for interaction among EDGEAPP entities incl. EEC).

[0041] The SBA extension to RAN is a natural evolution of the architecture in future mobile networks, in particular to allow the configuration of RAN services, where a RAN service is a capability or group of capabilities produced by one or more RAN entities and consumed by a further entity (RAN entity, core entity, application entity, UE), wherein the functionality comprises an RRM functionality, a CU functionality, a DU functionality, a D- SON functionality, or a protocol functionality. RAN service may relate to one or more UE sessions, one or more QoS flows, one or more radio bearers, one or more radio resource, one or more network or compute resource, a cell, a slice, a RAT or RAN configuration, a RAN entity.

[0042] The motivating factors for such an extension can be the following:

Enable core NFs to consume RAN services.

One example can be that NWDAF can consume RAN measurements/ analytics on demand, since currently this is not possible, and all RAN-related measurements are provided in an averaged/abstracted manner by OAM.

Another example can be the SMF for session management and QoS related decision to consume DRB load information by the RAN entity, to allow for pro-active actions related to possible RAN QoS downgrade.

Enable RAN functions to consume Core NF services One example is that NWDAF can provide UE analytics/ QoS analytics on demand to RRM / SON functions, so as to optimize the decisions based on core analytics.

Another example can be that location and slice related services (e.g., LMF services, NSSF services) can be consumed by RAN functions to optimize decisions related to the flow to bearer mapping and scheduling.

Enable a standard way of exposing RAN control services to AF without involving CN functions. Currently, AF (3^rd party or MNO apps) cannot consume RAN services e.g., for measurements and scheduling related decisions. SBA to RAN will allow the RAN services which are registered in the global repository (e.g., NRF) to be discovered and consumed by trusted AFs (if there is agreement in place). Such exposure will simplify interactions with vertical customers / app developers and will also facilitate the virtualized of RRM/SON functionality to the 3rd party.

[0043] This requires holistic re-thinking of the RAN architecture and a re-visiting of the interactions among functionalities in both RAN.

[0044] It is noted that there can be different implementations of SBA in RAN; however, for the purpose of this disclosure and by way of example, we will consider a generic approach which can be applicable to multiple implementations based on different use cases. Other implementations are not however excluded.

[0045] Figure 1 illustrates RAN control functionality and RAN-CN split in current mobile networks. In the discussion which follows the following assumptions and definitions may be helpful:

RAN functions (RNF) can be RRM/RRC/PDCP/RLC/MAC functions (examples can be seen in Fig. 1). o A RNF can be a RAN functionality or a group of functionalities which supports a certain RAN capability. The term RNF can be equivalent to RAN NF in certain embodiments. A RAN NF can be for example a CU functionality (enclosing all CU protocol functions and parameters) or a DU functionality or a gNB as a whole or any part of it.

RIC can be a RNF which provides RNSs. RAN services (RNS) comprise the configuration, control, and operations of radio parameters (can be also triggers or an abstraction of them) which can be provided by RAN functions or RNFs as “services” in the service-oriented RAN approach.

Radio parameters comprise at least some of the following:

RRM / RLM parameters

RRC user parameters RRC cell parameters RRM outputs

- ICIC, elCIC info (01, HII, RNTP, ABS patterns)

CoMP info (RB muting, coordination areas, hypothetical allocations/restrictions)

HO related parameters.

Slice related parameters (e.g., slice capacity, slice RRM policies)

DC related parameters (bearer split configurations, SN configuration policies,... ) QoE parameters

Service-tailored (V2X tailored, HOT tailored) radio parameters (e.g. V2X SL resource pool configuration,)

UE context parameters

[0046] NB. If we assume radio parameters to be provided for multiple Air Interface Variants (HF, LF) and for different radio access technologies integrated in 5G, the list of variables will be large. For example there can be parameters for given air interfaces (e.g. for beamforming support) or for given RAN deployments (e.g. Integrated Access and Backhaul). [0047] Such evolution brings challenges which may not exist with a SBA in core network. These include:

A need to foresee possible redundant functionalities within RAN and across RAN and Core. Such evolution may require enhancements of NFs in Core also to support interaction with RAN in a service-based manner. Currently RAN only interacts with the AMF (or with other NFs via the AMF). The SBA paradigm will introduce significant changes from an architecture perspective. For example, so far, the acquisition of measurements related to RAN are obtained via 0AM in an abstracted manner. The direct exposure of RAN measurements in the core network may pose some complexity and storage issues in NFs.

The feasibility of enabling service-based interactions in all RAN protocols is questionable (esp. in PHY / lower MAC) and needs to be evaluated due to timing and granularity constraints. For example, in lower layers the timing is in tens of milliseconds, whereas the core NF granularity is in sec/minute or higher level. The dynamic nature of actions in RAN will require the adaptation of core NF to be more dynamic, and this may have an impact on the deployments and limitations (e.g., bringing Core NFs close to the BS may require additional signaling and complexity in scenarios with UE mobility etc).

Trusting of the RAN to be part of SB A needs to be investigated, since this will allow a RAN vendor to be able to consume CN services. So far, the RAN can be seen as a “black box” with less trust than core NFs; and such evolution of architecture will change the position of RAN entities in the end-to-end service bus. In this context, the level of exposure and privacy/security aspects can be a key issue to be investigated. The RAN functionalities / protocols (or services if we assume service-oriented RAN) comprise high number of radio parameters with different granularities and timers. The definition and grouping of RAN services as part of the service-oriented RAN and as part of the end to end SBA needs to assume minimum impact on existing systems and at the same time to meet the use cases and performance requirements (we need to ensure that the new system is viable, addresses the need for such evolution, and also solves more issues than the ones it creates).

- As example, the dependencies among radio parameters if we split them, may have high signaling impact, esp. between RRC/RRM and low layer protocols (PHY, MAC).

Load Balancing (LB) and ICIC

Dynamic Resource Allocation (DRA) and ICIC

At the same time, exposing “raw” radio parameters may significantly affect RAN performance, considering huge signaling load / complexity, since such parameters are provided for finer granularities (10s or 100s milliseconds) and it would require exposing such parameters from multiple RAN entities to core network (which can be for the whole PLMN) real time or near real time. This would require huge signaling, storage and translation capabilities at the core network to enable the core network understand the radio parameters.

Finally, radio parameters need to be understood and processed by the AFs (which may be 3rd party apps) as well as Core NFs.

Some of the radio parameters cannot be exposed to AF mainly due to timing / latency constraints (e.g., CSI) and need to tailor the services based on the deployments (backhaul, AF location, ... ).

[0048] One example of dependencies if RRM functionalities split in the gNB (or even CU and DU) and edge/cloud is illustrated in Figure 2. In the case of a service-based RAN the issue is bigger since we need to design the services even at the same entity with the minimum dependency and we need to see how these services are registered and discovered by which repository.

[0049] Current solutions do not support service-oriented RAN and exposure of RAN services to core and AF. NRF in Core network only supports the registry of Core NF services. Also CAPIF only considers service APIs which are at the core network/ service enabler / 0AM side.

[0050] A problem to be solved may be summarized as how to support the registration and discovery of RAN services to be consumed by RAN or other domains (core, 0AM, AF) including but not limited to:

- another RAN possibly using other RAT (e.g. LTE, 5G, 6G) or spectrum considerations (e.g. mmWave radio) or different RAN provider (e.g. private RAN provided by a vertical);

- a core network which can be a virtual EPC or 5G core, or next generation core network;

- an edge or cloud platform which is owned by the MNO; and

- a domain at the mobile device side or behind the device (for example a local / enterprise cloud where the apps at the UE side physically reside).

NB. A RAN service can be equivalent in certain service-based implementations to a RAN service API. [0051] The solution introduces apparatus, e.g. a RAN node which may be a RAN Service Repository, which can work in both service-based RAN evolved architectures and existing RAN architectures by utilizing a new entity for supporting as registry in both non-SB RAN to service-based RAN. The registry may be physically deployed at an edge platform (if RAN is virtualized at the edge). Such a RAN architecture may comprise a repository which is "logically" within the RAN but may also be deployed at the edge/cloud platform which hosts RAN services.

[0052] The solution presented here provides a registry for supporting service-oriented RAN and a mechanism for supporting the registration and discovery of RAN services for a given use case (e.g. application service profile) or slice or QoS/QoE target or for a given intent/goal.

[0053] Aspects of the present disclosure are described in the context of a wireless communications system.

[0054] Figure 3 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure. The wireless communications system 100 may include one or more NE 102, one or more UE 104, and a core network (CN) 106. The wireless communications system 100 may support various radio access technologies. In some implementations, the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE- Advanced (LTE-A) network. In some other implementations, the wireless communications system 100 may be a NR network, such as a 5G network, a 5G- Advanced (5G-A) network, or a 5G ultrawideband (5G-UWB) network. In other implementations, the wireless communications system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20. The wireless communications system 100 may support radio access technologies beyond 5G, for example, 6G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA), frequency division multiple access (FDMA), or code division multiple access (CDMA), etc.

[0055] The one or more NE 102 may be dispersed throughout a geographic region to form the wireless communications system 100. One or more of the NE 102 described herein may be or include or may be referred to as a network node, a base station, a network element, a network function, a network entity, a radio access network (RAN), a NodeB, an eNodeB (eNB), a next-generation NodeB (gNB), or other suitable terminology. An NE 102 and a UE 104 may communicate via a communication link, which may be a wireless or wired connection. For example, an NE 102 and a UE 104 may perform wireless communication (e.g., receive signaling, transmit signaling) over a Uu interface.

[0056] An NE 102 may provide a geographic coverage area for which the NE 102 may support services for one or more UEs 104 within the geographic coverage area. For example, an NE 102 and a UE 104 may support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcast, etc.) according to one or multiple radio access technologies. In some implementations, an NE 102 may be moveable, for example, a satellite associated with a non-terrestrial network (NTN). In some implementations, different geographic coverage areas 112 associated with the same or different radio access technologies may overlap, but the different geographic coverage areas may be associated with different NE 102.

[0057] The one or more UE 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as a remote unit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as an Internet-of- Things (loT) device, an Internet-of-Everything (loE) device, or machine-type communication (MTC) device, among other examples.

[0058] A UE 104 may be able to support wireless communication directly with other UEs 104 over a communication link. For example, a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to- everything (V2X) deployments, or cellular-V2X deployments, the communication link 114 may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.

[0059] An NE 102 may support communications with the CN 106, or with another NE 102, or both. For example, an NE 102 may interface with other NE 102 or the CN 106 through one or more backhaul links (e.g., SI, N2, N2, or network interface). In some implementations, the NE 102 may communicate with each other directly. In some other implementations, the NE 102 may communicate with each other or indirectly (e.g., via the CN 106. In some implementations, one or more NE 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC). An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs).

[0060] The CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The CN 106 may be an evolved packet core (EPC), or a 5G core (5GC), which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME), an access and mobility management functions (AMF)) and a user plane entity that routes packets or interconnects to external networks (e.g., a serving gateway (S-GW), a Packet Data Network (PDN) gateway (P-GW), or a user plane function (UPF)). In some implementations, the control plane entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signal bearers, etc.) for the one or more UEs 104 served by the one or more NE 102 associated with the CN 106.

[0061] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an SI, N2, N2, or another network interface). The packet data network may include an application server. In some implementations, one or more UEs 104 may communicate with the application server. A UE 104 may establish a session (e.g., a protocol data unit (PDU) session, or the like) with the CN 106 via an NE 102. The CN 106 may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server using the established session (e.g., the established PDU session). The PDU session may be an example of a logical connection between the UE 104 and the CN 106 (e.g., one or more network functions of the CN 106).

[0062] In the wireless communications system 100, the NEs 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communications). In some implementations, the NEs 102 and the UEs 104 may support different resource structures. For example, the NEs 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the NEs 102 and the UEs 104 may support a single frame structure. In some other implementations, such as in 5G and among other suitable radio access technologies, the NEs 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures). The NEs 102 and the UEs 104 may support various frame structures based on one or more numerologies.

[0063] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g., /r=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g., /r=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g., /r=l) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., /r=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g., /r=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., /r=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0064] A time interval of a resource (e.g., a communication resource) may be organized according to frames (also referred to as radio frames). Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframe may have a duration, for example, a 1 ms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.

[0065] Additionally or alternatively, a time interval of a resource (e.g., a communication resource) may be organized according to slots. For example, a subframe may include a number (e.g., quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (i.e., /r=0, jU=l, /r=2, jU=3, /r=4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively. Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM symbols). In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing), a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., /i =0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

[0066] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc. By way of example, the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designations FR1 (410 MHz - 7.125 GHz), FR2 (24.25 GHz - 52.6 GHz), FR3 (7.125 GHz - 24.25 GHz), FR4 (52.6 GHz - 114.25 GHz), FR4a or FR4-1 (52.6 GHz - 71 GHz), and FR5 (114.25 GHz - 300 GHz). In some implementations, the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the NEs 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data). In some implementations, FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.

[0067] FR1 may be associated with one or multiple numerologies (e.g., at least three numerologies). For example, FR1 may be associated with a first numerology (e.g., /r=0), which includes 15 kHz subcarrier spacing; a second numerology (e.g., /r=l), which includes 30 kHz subcarrier spacing; and a third numerology (e.g., /r=2), which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies). For example, FR2 may be associated with a third numerology (e.g., /r=2), which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., /r=3), which includes 120 kHz subcarrier spacing. [0068] A method is proposed here for extending SBA in RAN by supporting the registration and discovery of RAN services. The RAN services are not limited to RRM and D-SON capabilities; however, by way of example only, the focus here is on the RRM (e.g., Inter-cell RRM, CMC, ...) and D-SON services which are configured by SBIP, even if these capabilities are not meant to have service-based interactions among them.

[0069] Such services can be:

1) RRM functionalities, such as:

Inter-cell RRM,

Connection Mobility Control,

Radio Bearer Control, Radio Admission Control, DRA / Scheduling / Measurement configuration, Energy Saving / Cell Switch On-Off.

2) D-SON functionalities, such as:

Automatic Neighbor Relation,

Mobility Load Balancing,

Mobility Robustness Optimization,

Energy Saving,

Cell Degradation Detection

Coverage and capacity optimization.

3) O-RAN defined RIC functionalities, such as:

Traffic Steering xApp services,

QoS Optimization xApp services,

Energy Optimization xApp services,

RAN slice optimization xApp services,

Near-RT RIC framework services (AI/ML support, Database services, API, Enablement services, Conflict Mgmt, etc),

Non-RT RIC management and Real-time RIC (not defined yet) control services.

4) AI/ML support services:

Al-enabled RAN analytics services,

Al support for RAN analytics (ML training / inference for RAN analytics ID), Al support and analytics for enhancing existing RRM/SON functionalities. 5) RAN Exposure support services (e.g. SBIP):

RAN abstraction service,

RAN registry service,

RAN exposure / gateway service.

[0070] An example illustration of SBA to RAN, i.e. a high level service-based architecture, including the above services is shown in Figure 4.

[0071] A further embodiment may propose an alternative classification of services which can be related to one or more of the following:

RAN-associated control services (decision for radio bearers or flow to DRB, DU activation, IAB,..),

UE-associated control services (decision for UE related parameters),

RAN related monitoring services,

UE related monitoring services,

RAN policy related services,

RAN Slice associated services,

RNI services as defined in ETSI MEC,

XNAP/X2APP services (for interaction among BSs).

[0072] The solution comprises a new entity for acting as a RAN Service Repository (RSR) for a Radio Access Network comprising one or more cells, for supporting the integration to a service-oriented mobile network. The method may comprise:

1. Receiving a request [for a given service / profile / use case / session / area] for registering a RAN service and/or RAN service exposure function.

2. Registering the at least one RAN service or group of RAN services.

3. Notifying information for the availability at least one RAN service to an involved domain entity (RAN, Core, 0AM, UE).

4. Supporting the discovery of the at least on RAN service based on a consumer’s request (e.g. NF, 0AM, AF)

[0073] Embodiment 1 : RAN Service Repository for supporting the Registration

[0074] In this embodiment, the RAN Service Repository (RSR) is implemented at the RAN side which can be deployed as a protocol or function/service or as a separate RAN entity / proxy at the gNB or for a group of gNBs covering one or more cells. Such deployment covers also disaggregated RAN deployments, where the RSR is connected to one or more CUs and a plurality of DUs / RU.

[0075] The RAN function / entity can be a CU/DU/RU function or a RAN protocol function or a gNB/ BS or even a small cell access point with different spectrum and RAT considerations. Such RAN function /entity (as defined in this embodiment) is assumed to be connected to the RSR for the registry of RAN services.

[0076] This embodiment includes the following procedures:

[0077] 1) Registration of RSE-GW services

[0078] Figure 5 illustrates a procedure for registering RAN service exposure GW services. This includes:

0. The RAN Service Exposure Gateway (RSE-GW) is deployed at the RAN side (at the gNB or a RAN controller) and is configured to provide gateway functionalities for the underlying RAN entities (CU, DU,..).

1. The RSE-GW sends a registration request to the RSR to register the RAN gateway services. Such services comprise the abstraction, exposure and proxy services. Such registration request includes the RSE-GW type and other information such as time availability, area of interest or location the GW resides, interoperability information, use case availability/limitations and whether gateway function is per slice/ RAT/service profile /... .

2. The RSR validates the received request and generates the identity and other security related information for all the RAN gateway services listed in the registration request.

3. The RSR sends the generated information in the registration response message to the RSE-GW.

4. The RSR publishes / advertises the registered services to the involved entities:

To RAN service consumer (e.g. NF) or core network / management repositories which require to be notified of the new RAN registry services.

To the RAN functions which need to be informed about the availability of the GW services.

[0079] 2) Registration of RAN services with and w/o RSE-GW [0080] Figure 6 illustrates in a more detail procedures for registering RAN service(s). This embodiment includes two options. In Option 1, the RSE GW is used to register RAN services whereas in option 2 the RAN NF directly registers RAN services to the RSR.

[0081] Option 1

0. The RAN function (e.g. CU, protocol function) interacts with the GW to support the registry of the RAN services.

1. The RSE-GW sends a registration request to the RSR to register the RAN function services, which can be either all “original services” or abstracted services based on the role of the GW. Such services comprise for example RRM, D-SON, AI/ML and RAN analytics services as described above. Such registration request includes the RAN NF ID or RAN service ID and other information such as time availability, area of interest or location the RAN NF/service resides (CU, DU, RIC,..), interoperability information, spectrum considerations, permissions and exposure level, flag for hiding RAN topology, slice ID or RAN configuration ID, use case availability/limitations and whether RAN service is registered per slice/ RAT/service profile /... .

2. The RSR validates the received request and generates the identity and other security related information for all the RAN services listed in the registration request.

3. The RSR sends the generated information in the registration response message to the RSE-GW.

[0082] Option 2

4. The RAN NF sends a registration request to the RSR. Such registration request includes the RAN NF ID or RAN service ID and other information such as time availability, area of interest or location the RAN NF/service resides (CU, DU, RIC,..), interoperability information, spectrum considerations, permissions and exposure level, flag for hiding RAN topology, use case availability/limitations and whether RAN service is registered per slice/ RAT/service profile /... .

5. The RSR validates the received request and generates the identity and other security related information for all the RAN services listed in the registration request. The RSR registers all the RAN services of the requestor RAN NF.

6. The RSR sends the generated information in the registration response message to the RAN NF. [0083] Embodiment 2: RAN Service Repository for supporting the Discovery

[0084] In this embodiment, the RAN service repository is implemented at the RAN side which can be deployed as a protocol or function/service or as a separate RAN entity / proxy at the gNB or for a group of gNBs covering one or more cells. Such deployment covers also disaggregated RAN deployments, where the RSR is connected to one or more CUs and a plurality of DUs / RU.

[0085] The RAN function / entity can be a CU/DU/RU function or a RAN protocol function or a gNB/ BS or even a small cell access point with different spectrum and RAT (e.g. NTN) considerations. Such RAN function /entity (as defined in this embodiment) is assumed to be connected to the RSR for the registry of RAN services.

[0086] This embodiment includes the following procedures:

[0087] 1) Discovery of RSE-GW services

[0088] Figure 7 illustrates the procedure for discovering RAN service exposure GW services. This includes:

0. The RAN Service Exposure Gateway (RSE-GW) is deployed at the RAN side (at the gNB or a RAN controller) and is configured to provide gateway functionalities for the underlying RAN entities (CU, DU,..).

1. The RAN service consumer or the RAN NF itself sends a discovery request to the RSR to discover whether RAN gateway services are available (e.g. for abstraction or supporting the exposure of RAN services). Such discovery request includes the RSE- GW type and other information such as filters, time availability, area of interest or location the GW resides, interoperability information, use case availability /limitations and whether discovery criteria is per slice/ RAT/service profile /... .

2. The RSR validates the received discovery request and fetches the RSE-GW information which match the criteria in step 1. This step may be needed in case of availability changes in RSE-GW capabilities based on dynamic conditions (e.g. traffic changes, BS load, energy limitations, RAN topology changes).

3. The RSR sends the set of RSE-GW capabilities in the discovery response message to the RAN service consumer or the RAN NF itself.

[0089] 2) Discovery of RAN services with and w/o RSE-GW [0090] Figure 8 illustrates the procedure for discovering RAN service(s). This embodiment includes two options. In Option 1, the RSE GW is used to discover RAN services whereas in option 2 other RAN NF or RAN service consumer directly discovers RAN services to the RSR.

[0091] Option 1

1. The RAN service consumer (who can be another RAN NF or a Core NF or other domain entity) sends a discovery request to the RSE-GW to discover the RAN function services for a given use case or slice / RAT / RAN configuration / intent / service profile / application / core network task.

2. The RSE-GW sends the discovery request to RSR based on step 1 , which can be either to discover all “original services” or abstracted services based on the role of the GW. This step may be a translation of the intent in step 1 to the actual RAN services to be discovered. Such services comprise for example RRM, D-SON, AI/ML and RAN analytics services as described above. Such discovery request includes the RAN NF ID or RAN service ID, the filters/criteria for the discovery, and other information such as time availability, area of interest or location the RAN NF/service resides (CU, DU, RIC,..), interoperability information, spectrum considerations, slice ID or RAN configuration ID, use case availability/limitations and whether RAN service needs to be discovered per slice/ RAT/service profile /... .

3. The RSR validates the received discovery request and fetches the RAN NF service information which match the criteria in step 1. This step may be needed in case of availability changes in RAN service or RAN NF capabilities based on dynamic conditions (e.g. traffic changes, BS load, energy limitations, RAN topology changes).

4-5. The RSR sends the set of RAN NF service capabilities in the discovery response message to the RAN service consumer directly or via the RSE-GW to the RAN service consumer.

[0092] Option 2

6. The RAN NF sends a discovery request to the RSR. Such discovery request includes the RAN NF ID or RAN service ID, the filters/criteria for the discovery, and other information such as time availability, area of interest or location the RAN NF/service resides (CU, DU, RIC,..), interoperability information, spectrum considerations, slice ID or RAN configuration ID, use case availability/limitations and whether RAN service needs to be discovered per slice/ RAT/service profile /... .

7. The RSR validates the received discovery request and fetches the RAN NF service information which match the criteria in step 1. This step may be needed in case of availability changes in RAN service or RAN NF capabilities based on dynamic conditions (e.g. traffic changes, BS load, energy limitations, RAN topology changes).

8. The RSR sends the generated information in the discovery response message to the RAN service consumer.

[0093] Embodiment 3 : Enhancing CAPIF

[0094] This embodiment describes a mechanism for registering and discovering RAN capabilities as services using CAPIF (with enhancements to support RAN exposure). In 3GPP [TS 23.222, TS 29.222], a Common API Framework (CAPIF) was developed to enable a unified Northbound API framework across 3 GPP network functions, and to ensure that there is a single and harmonized approach for API development. Some key functionalities in CAPIF are:

CAPIF Core Function (CCF) is a repository of all, PLMN and 3rd party, service APIs API Exposing Function (AEF) is the provider of the services as APIs

API Invoker is typically the applications that require service from the service providers

API management function: The API management function enables the API provider to perform administration of the service APIs. This includes auditing the service API invocation logs received from the CAPIF core function, monitoring the events reported by the CAPIF core function etc

API publishing function: The API publishing function enables the API provider to publish the service APIs information in order to enable the discovery of service APIs by the API invoker.

[0095] The CAPIF is hosted within the PLMN operator network or trust domain. The API invoker is typically provided by a 3^rd party application provider who has service agreement with PLMN operator. The API invoker may reside within the same trust domain as the PLMN operator network. [0096] In a reference point based model, the API invoker within the PLMN trust domain interacts with the CAPIF via CAPIF-1 and CAPIF-2. The API invoker from outside the PLMN trust domain interacts with the CAPIF via CAPIF-1 e and CAPIF -2e. The API exposing function, the API publishing function and the API management function of the API provider domain (together known as API provider domain functions) within the PLMN trust domain interacts with the CAPIF core function via CAPIF-3, CAPIF-4 and CAPIF-5 respectively.

[0097] In a service-based model, the CAPIF functional model uses service-based interfaces (Cccf, Caef). This is illustrated in Figure 9. In this embodiment, one possible deployment is the addition of RAN service function as part of the CAPIF SB architecture, and the introduction in the existing CAPIF entities the following tasks:

CCF : CCF is enhanced to support the RAN service API registry (acting as RSR). The benefit of such enhancement is the deployment of RSR in different domains which are leveraging CAPIF (e.g. edge, core, 0AM).

[0098] The following procedure describes the high level capability of CCF for supporting the registration and discovery of RAN services/ APIs to the RAN API consumer who can be an AF or an NF or a MF depending on which domain is leveraging CAPIF (core, management, service enabler layer, edge).

[0099] 1) Enhancements to CAPIF for RAN service registration

[0100] Figure 10 illustrates a procedure for registration of API provider domain functions on CAPIF. This includes:

1. For registration of RAN domain functions on the CAPIF core function, the RAN API management function sends a registration request to the CAPIF core function. The registration request contains a list of information about all the RAN NF services, which require registration on the CAPIF core function, as well as information about the RAT / slice / interface impacted. Also, this may include the granularity and dynamicity of the service (real time , near real time), spectrum considerations, access limitations, RAN API provider entity (CU ID, DU ID, RIC ID) and time validity/ cell area of interest. 2. The CAPIF core function validates the received request and generates the identity and other security related information for all the RAN API provider domain functions listed in the registration request.

3. The CAPIF core function sends the generated information in the registration response message to the RAN API management function.

4. The RAN API management function configures the received information to the individual API provider domain functions (e.g. RAN NFs, RAN units like CU, DU, RIC).

[0101] 2) Enhancements to CAPIF for RAN service discovery

[0102] The service API discovery mechanism is supported by the CAPIF core function.

[0103] Pre-conditions:

1. The API invoker is onboarded and has received an API invoker identity.

2. The CAPIF core function is configured with a discovery policy information (e.g. to restrict discovery to category of APIs) for API invoker(s) including policy information for the RAN service APIs by 0AM or the RAN API provider.

[0104] Figure 11 illustrates a procedure for discovering RAN APIs including:

1. The API invoker (RAN service consumer like NF or AF or other gNB) sends a RAN API discover request to the CAPIF core function. It includes the API invoker identity, and may include query information. For RAN APIs, this may include information on the RAN topology, the RAT and slices supported, the RAN capabilities supported, whether RAN is disaggregated and the RAN entity IDs (CU, DU, RIC), the API type for RAN APIs which are cell-associated or UE-associated, and SBA related information (bus, mesh).

2. Upon receiving the RAN API discover request, the CAPIF core function verifies the identity of the API invoker (via authentication). The CAPIF core function retrieves the stored RAN API(s) information from the CAPIF core function (API registry) as per the query information in the service API discover request for the given RAN area (cell, group of cells). Further, the CAPIF core function applies the discovery policy and performs filtering of RAN APIs information retrieved from the CAPIF core function. 3. The CAPIF core function sends a RAN API discover response to the API invoker with the list of RAN API information for which the API invoker has the required authorization. In this step, the CCF may also include information on the RAN topology, the RAT and slices supported, the RAN capabilities supported, whether RAN is disaggregated and the RAN entity IDs (CU, DU, RIC), the API type for RAN APIs which are cell-associated or UE-associated and SBA information (bus, mesh).

[0105] Figure 12 illustrates an example of a NE 200 in accordance with aspects of the present disclosure. The NE 200 may include a processor 202, a memory 204, a controller 206, and a transceiver 208. The processor 202, the memory 204, the controller 206, or the transceiver 208, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0106] The processor 202, the memory 204, the controller 206, or the transceiver 208, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0107] The processor 202 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof). In some implementations, the processor 202 may be configured to operate the memory 204. In some other implementations, the memory 204 may be integrated into the processor 202. The processor 202 may be configured to execute computer-readable instructions stored in the memory 204 to cause the NE 200 to perform various functions of the present disclosure.

[0108] The memory 204 may include volatile or non-volatile memory. The memory 204 may store computer-readable, computer-executable code including instructions when executed by the processor 202 cause the NE 200 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 204 or another type of memory. Computer-readable media includes both non- transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or specialpurpose computer.

[0109] In some implementations, the processor 202 and the memory 204 coupled with the processor 202 may be configured to cause the NE 200 to perform one or more of the functions described herein (e.g., executing, by the processor 202, instructions stored in the memory 204). For example, the processor 202 may support wireless communication at the NE 200 in accordance with examples as disclosed herein. The NE 200 may be configured to provide an apparatus of a Radio Access Network, RAN, comprising at least one memory, and at least one processor coupled with the at least one memory and configured to cause the apparatus to receive a request for registering one or more RAN services, authenticate the request and, in response to authenticating the request, generate a registration identity for the or each RAN service, and update a RAN service database with the registration identity.

[0110] The request may include RAN service exposure information for the or each RAN service, and the processor may be configured to cause the apparatus to update the RAN service database with the RAN service exposure information.

[0111] The processor may be configured to further update the RAN service database with an identification of the or each RAN entity providing said RAN service exposure information.

[0112] The or each RAN entity may be one of a RAN network function, a DU, CU, RU, RIC, or a RAN protocol function.

[0113] The processor may be configured to cause the apparatus to obtain a further request from a consumer entity to discover at least one registered RAN service based on a requirement, fetch at least one of the registered RAN services based on the requirement, an identity or property of the consumer, and the RAN service exposure information, and send a discovery response to the further request indicating the identity and RAN service exposure information for the fetched at least one of the registered RAN services.

[0114] The requirement may be associated with one or more of: a network slice; a core network procedure. A core network procedure can be defined as a procedure initiated by a core network entity. Such procedures can be found in 3 GPP TS 23.402 (for 4G) and 23.502 (for 5G) and relate to network session related procedures, mobility management procedures, procedure applicable to a network analytics event, a procedure for QoS control / PCC rule setting, user plane procedure triggered by UPF; a RAT or RAN configuration.

A RAT can apply to a different technology (e.g. LTE RAN, NR, 6G RAN) or a different interface (NR-Uu, NR-PC5) or a non-3gpp access technology (wifi access, satellite access).

A RAN configuration comprises a certain customization of the radio parameters of the base station for a given use case (e.g. slice). RAN configuration is also referred as RAN slice or RAN part of a network slice; a QoS/QoE target or intent/goal.

A QoS / QoE target can be a certain KPI or performance target for the RAN (target cell latency or throughput) or for one or more UEs / services in RAN (e.g. RAN UE throughput or latency).

Intent is another granularity of target where the request includes only that target performance or availability metric or the expected outcome and not the exact capability to be consumed. For example an intent / goal can be “minimizing interference by X%” or “achieving HO failure rate of X% or less for the target cells” or “achieving homogeneous performance (without fluctuations) for a list of cells”; a UE or group of UEs; an application or application service. an application service can be a service provided by a 3rd party or vertical (e.g. V2X service, IIOT service, gaming service) or can be also an application service applicable to an edge service area hosted by an edge platform provider; a cell or list of cells; at least one RAN entity; and an edge or cloud resource.

This refers to the scenario where the request is for a given edge support /MEC service (e.g. RNIS) or edge/MEC application service; A data radio bearer and/or a QoS flow.

[0115] The consumer entity may be a core network function, an application function, a management function, an edge or cloud function, or a further RAN function.

[0116] The apparatus may be a base station or form part of a base station.

[0117] The processor may be configured to cause the apparatus to send a response to the request including the registration identity and registration information.

[0118] The or each RAN service may comprise at least one or combination of: an RRM function service; a Distributed-SON function service; a RAN analytics service; an Al / ML support service; a RAN Capability Exposure Support Service; a RAN proxy or gateway service; a CU service, a DU service; and an XnAPP service, an NGAPP service.

[0119] The processor may be configured to publish the RAN service database update to at least one external entity, wherein the external entity is a core network function, a management function, an application function or a combination thereof.

[0120] The processor may be configured to obtain a request for registering one or more RAN services by receiving the request from a RAN service exposure gateway or a RAN network function.

[0121] The apparatus may be a repository entity covering one or more RAN nodes. In this case, the repository is not deployed only for one base station but rather for a cluster of base stations (for example for a hotspot scenario with plurality of small cells or for an industrial environment for a plurality of access points which are clustered together). It may be also possible that this repository is deployed in an edge platform covering a set of cells being served by plurality of RAN nodes. Each RAN node can be a gNB or a CU or a DU or an RU. The apparatus may be a RAN service API registry, for example a CAPIF Core Function.

[0122] The controller 206 may manage input and output signals for the NE 200. The controller 206 may also manage peripherals not integrated into the NE 200. In some implementations, the controller 206 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 206 may be implemented as part of the processor 202.

[0123] In some implementations, the NE 200 may include at least one transceiver 208. In some other implementations, the NE 200 may have more than one transceiver 208. The transceiver 208 may represent a wireless transceiver. The transceiver 208 may include one or more receiver chains 210, one or more transmitter chains 212, or a combination thereof.

[0124] A receiver chain 210 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 210 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 210 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. The receiver chain 210 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 210 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0125] A transmitter chain 212 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 212 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The transmitter chain 212 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 212 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0126] Figure 13 illustrates a flowchart of a method in accordance with aspects of the present disclosure. The operations of the method may be implemented by a NE as described herein. In some implementations, the NE may execute a set of instructions to control the function elements of the NE to perform the described functions. [0127] At 202, the method may include obtaining a further request from a consumer entity to discover at least one registered RAN service based on a requirement. The operations of 202 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 202 may be performed by a NE as described with reference to Figure 12.

[0128] At 204, the method may include fetching at least one of the registered RAN services based on the requirement, an identity or property of the consumer, and the RAN service exposure information. The operations of 204 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 204 may be performed by a NE as described with reference to Figure 12.

[0129] At 206, the method may include sending a discovery response to the further request indicating the identity and RAN service exposure information for the fetched at least one of the registered RAN services. The operations of 206 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 206 may be performed a NE as described with reference to Figure 12.

[0130] It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0131] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

Claims

What is claimed is:

1. Apparatus of a Radio Access Network, RAN, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the apparatus to: receive a request for registering one or more RAN services; authenticate the request and, in response to authenticating the request, generate a registration identity for the or each RAN service; and update a RAN service database with the registration identity.

2. Apparatus according to claim 1, wherein the request includes RAN service exposure information for the or each RAN service, and the processor is configured to cause the apparatus to update the RAN service database with the RAN service exposure information.

3. An apparatus according to claim 2, the processor being configured to further update the RAN service database with an identification of the or each RAN entity providing said RAN service exposure information.

4. An apparatus according to claim 3, wherein the or each RAN entity is one of a RAN network function, a DU, CU, RU, RIC, or a RAN protocol function.

5. An apparatus according to any one of claims 2 to 4, the processor being configured to cause the apparatus to: obtain a further request from a consumer entity to discover at least one registered RAN service based on a requirement; fetch at least one of the registered RAN services based on the requirement, an identity or property of the consumer, and the RAN service exposure information; and send a discovery response to the further request indicating the identity and RAN service exposure information for the fetched at least one of the registered RAN services.

6. An apparatus according to claim 5, wherein said requirement defines or is otherwise associated with one or more of: a network slice; a core network procedure; a RAT or RAN configuration; a QoS/QoE target or intent/goal; a UE or group of UEs; an application or application service; a cell or list of cells; at least one RAN entity; an edge or cloud resource; and a data radio bearer and/or a QoS flow.

7. An apparatus according to claim 5 or 6, wherein said consumer entity is a core network function, an application function, a management function, an edge or cloud function, or a further RAN function.

8. An apparatus according to any one of the preceding claims, the apparatus being a base station or forming part of a base station.

9. An apparatus according to any one of the preceding claims, the processor being configured to cause the apparatus to send a response to the request including the registration identity and registration information.

10. An apparatus according to any one of the preceding claims, wherein the or each RAN service comprises at least one or combination of: an RRM function service; a Distributed-SON function service; a RAN analytics service; an Al / ML support service; a RAN Capability Exposure Support Service; a RAN proxy or gateway service; a CU service, a DU service; and an XnAPP service, an NGAPP service, a MEC service.

11. An apparatus according to any one of the preceding claims, the processor being configured to publish the RAN service database update to at least one external entity, wherein the external entity is a core network function, a management function, an application function or a combination thereof.

12. An apparatus according to any one of the preceding claims, the processor being configured to obtain a request for registering one or more RAN services by receiving the request from a RAN service exposure gateway or a RAN network function.

13. An apparatus according to any one of the preceding claims, the apparatus being a repository entity covering one or more RAN nodes.

14. An apparatus according to any one of the preceding claims, the apparatus being a RAN service API registry, for example a CAPIF Core Function.

15. A method implemented in a Radio Access Network, RAN, and comprising: receiving a request for registering one or more RAN services; authenticating the request and, in response to authenticating the request, generating a registration identity for the or each RAN service; and updating a RAN service database with the registration identity.

16. A method according to claim 15, wherein the request includes RAN service exposure information for the or each RAN service, the method comprising updating the RAN service database with the RAN service exposure information.

17. A method according to claim 16 and comprising updating the RAN service database with an identification of the or each RAN entity providing said RAN service exposure information.

18. A method according to claim 17, wherein the or each RAN entity is one of a RAN network function, a DU, CU, RU, RIC, or a RAN protocol function.

19. A method according to any one of claims 16 to 18 and comprising: obtaining a further request from a consumer entity to discover at least one registered RAN service based on a requirement; fetching at least one of the registered RAN services based on the requirement, an identity or property of the consumer, and the RAN service exposure information; and sending a discovery response to the further request indicating the identity and RAN service exposure information for the fetched at least one of the registered RAN services.

20. A method according to claim 19, wherein said requirement defines or is otherwise associated with one or more of: a network slice; a core network procedure; a RAT or RAN configuration; a QoS/QoE target or intent/goal; a UE or group of UEs; an application or application service; a cell or list of cells; at least one RAN entity; an edge or cloud resource; and a data radio bearer and/or a QoS flow.