Method and apparatus for integrating radio access networks to a service-based core architecture

Abstract

Method and Apparatus for Integrating Radio Access Networks to a Service-based Core Architecture Various aspects of the present disclosure relate to a base station 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 base station to receive a network request for a RAN service, in response to receiving the network request, determine RAN parameters required for the RAN service, and provide the RAN service based on the determined RAN parameters.

Description

Method and Apparatus for Integrating Radio Access Networks to a Service-based Core ArchitectureTECHNICAL FIELD

[0001] The present disclosure relates to wireless communications and more specifically to a method and apparatus for integrating Radio Access Networks to a service-based core architecture.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 listsuch 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 a base station 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 base station to receive a network request for a RAN service, in response to receiving the network request, determine RAN parameters required for the RAN service, and provide the RAN service based on the determined RAN parameters.

[0005] In some implementations of the method and apparatuses described herein the processor may be configured to, prior to providing the RAN service, obtain a service configuration for the RAN service based on the determined RAN parameters, wherein the service configuration is used to provide the RAN service.

[0006] The processor may be configured to send the service configuration to one or more of an entity identified as a producer of the RAN service, for example an entity within the apparatus or a different apparatus, and a RAN service repository.

[0007] The processor may be configured to determine RAN parameters by sending a request to at least one RAN entity acting as the RAN service producer to provide at least one RAN parameter for configuring the RAN service, and receiving the at least one RAN parameter for configuring the RAN service, wherein the service configuration comprises a RAN service area, time of validity, a RAN service producer identity and one or more RAN service API information.

[0008] The processor may be configured to obtain a service configuration based on a type of consumer.

[0009] The processor may be configured to cause the apparatus to publish the service configuration to at least one external entity.

[0010] The processor may be configured to send the service configuration to an 0AM function.

[0011] The processor may be configured to obtain a network request by receiving the request from a service consumer being one of a:Network Function;Application Function;0AM function; andRAN function, for example a further base station.

[0012] The processor may be configured to determine RAN parameters required to support the RAN service by selecting one or more RAN parameters from a preconfigured set of available RAN parameters.

[0013] The network request 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; and an edge or cloud resource. a data radio bearer and / or a QoS flow.

[0014] The RAN service may be a service-based interaction between the RAN and an external network or domain or a management system.

[0015] The processor may be configured to cause the apparatus to form a chain corresponding to a plurality of RAN services.

[0016] The processor may be configured to cause the apparatus to place the RAN service to one or more RAN entities, wherein the RAN entities comprise a DU, CU, RU, RIC, or RAN protocols.

[0017] The processor may be configured to send a response to a service consumer indicating a positive response to the network request.

[0018] The processor may be configured to cause the apparatus to receive from an 0AM function configuration information including one or more of: cell ID(s); target area and time of validity;RAN configurations / slices supported;RAN entity IDs, permissions and tasks of RCE-GW; expected consumers of RCE-GW;SB A deployment (e.g. bus, mesh); andRAN service repository ID and address.

[0019] 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 network request for a RAN service, in response to receiving the network request, determining RAN parameters required for the RAN service, and providing the RAN service based on the determined RAN parameters.

[0020] Prior to providing the RAN service, the method may comprise obtaining a service configuration for the RAN service based on the determined RAN parameters, wherein the service configuration is used to provide the RAN service.

[0021] The network request may be received from a service consumer being one of a:Network Function;Application Function;0AM function; andRAN function, for example a further base station.BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0024] Figure 3 illustrates an extension of a SB A in RAN.

[0025] Figure 4 illustrates a Service-based Integration Protocol (SBIP) as part of the SBA bus.

[0026] Figure 5 illustrates a process embodying the SBIP involving a RAN function / entity connected to an RCE-GW for the exposure / abstraction of RAN services.

[0027] Figure 6 illustrates schematically a CAPIF functional model representation using service-based interfaces.

[0028] Figure 7 illustrates a high level capability of RAN Exposure Support Function (RESF) for supporting the exposure to the RAN API consumer.

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

[0030] Figure 9 illustrates an example of a network equipment (NE) 100 in accordance with aspects of the present disclosure.

[0031] Figure 10 illustrate a flowcharts of method performed by a NE in accordance with aspects of the present disclosure.DETAILED DESCRIPTION

[0032] In the context of communication networks, the Service Based Architecture has evolved from monolithic to service-oriented architecture (SOA) towards microservices and serverless.

[0033] 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. A SOA relies upon 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.

[0034] Microservice is a type of service-oriented software architecture that focuses on building a series of autonomous components that make up an application or “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 microservice over other architectures is that small single services can be built, tested, and deployed independently. On the other hand, a disadvantage of a microservice basedarchitecture is that each functionality that communicates externally via an API will increase the chance of malicious attacks. [Of course, such attacks are likely to succeed only if proper security measurements are not implemented when building an app.] A further disadvantages arises when different apps are implemented using different languages, making deployment more difficult.

[0035] A 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 does not mean “no server”, as the application is still running on servers; rather 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.

[0036] 3 GPP, including the enablement layer (as specified in SA6), uses service-based representations of the architecture. However, different architectures have different types of service-based architecture (SBA). These include:

[0037] 3 GPP SA2, which relates to the 3 GPP system architecture, uses conventionalSBA, where the Network Function (NF) is the service producer and the Service Based Interface (SBI) bus is used for the interaction with service consumers (Network Functions (NFs) / Application Functions (AFs)).

[0038] 3 GPP SA5, which is about Operations, Administration and Maintenance (0AM) aspects of the network, uses service-based management architecture, closer to a microservice paradigm.

[0039] 3 GPP SA5 specifies the concept of Management Services (MnS) as an API that can be integrated into 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.

[0040] 3 GPP SA6 uses an SA2 paradigm for Service Enabler Architecture Layer(SEAL).However, in other enablers (like EDGEAPP), the service-based support has different variants (SA2-based for interaction with 5G Core (5GC), and microservice-based for interaction among EDGEAPP entities including EEC).

[0041] The SBA extension to the Radio Access Network (RAN) is a natural evolution of the architecture for 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 extension may include the following:

[0043] Enable core NFs to consume RAN services.

[0044] One example can be that the Network Data Analytics Function (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 0AM. Another example can be the Session Management Function (SMF) for session management and QoS related decision consuming Data Radio Bearer (DRB) load info by the RAN entity, to allow for pro-active actions related to a possible RAN QoS downgrade.

[0045] Enable RAN functions to consume Core NF services

[0046] One example is that NWDAF can provide UE analytics / QoS analytics on demand to Radio Resource Management (RRM) / Self-Organizing Network (SON) functions, so as to optimize the decisions based on core analytics. Another example can be that location and slice related services (e.g., Location Management Function (LMF) services, Network Slice Selection Function (NSSF) services) can be consumed by RAN functions to optimize decisions related to the flow to bearer mapping and scheduling.

[0047] Enable a standard way of exposing RAN control services to AF without involvingCN functions

[0048] Currently, an AF (3rdparty 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 withvertical customers / app developers and will also facilitate the virtualized of RRM / SON functionality to the 3rd party.

[0049] The SBA extension to the Radio Access Network (RAN) requires a holistic rethinking of the RAN architecture and a re-visiting of the interactions among functionalities in both RAN. NB. There may be different implementations of SBA in RAN. However, for the purpose of this discussion and by way of example, a generic approach is considered which is applicable to multiple implementations based on different use cases. Other implementations are not however excluded..

[0050] 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 RFNs as “services” in the service-oriented RAN approach.Radio parameters comprise at least some of the following:RRM / RLM parametersRRC user parameters RRC cell parameters RRM outputs- ICIC, elCIC info (OI, 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 parametersService-tailored (V2X tailored, IIOT tailored) radio parameters (e.g. V2X SL resource pool configuration,) UE context parameters.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 huge. 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).

[0051] Such evolution brings some challenges which may not exist in SBA in the core network. These include:

[0052] A need to foresee possible redundant functionalities within RAN and across RAN and Core. Such evolution may require enhancements of NFs in the 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 changes from an architecture perspective. For example, so far, the acquisition of measurements related to RAN are obtain 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.

[0053] 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 at the level of seconds / minute or greater. The dynamic nature of actions in the RAN will require the adaptation of core NF to be more dynamic, and this may 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).

[0054] Trust issues surrounding the inclusion of the RAN in the SBA needs to be investigated, since this will allow a RAN vendor to be able to consume CN services. Currently the RAN can be seen as a “black box” which is less trusted than core NFs;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 may be a key issue to be investigated.

[0055] The RAN functionalities / protocols (or services if we assume service-oriented RAN) comprise a 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).

[0056] As an 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 ICICDynamic Resource Allocation (DRA) and ICIC.

[0057] At the same time, exposing “raw” radio parameters may significantly affect RAN performance considering the 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.

[0058] Radio parameters need to be understood and processed by the AFs (which may be 3rd party apps) as well as Core NFs.

[0059] 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, ... ).

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

[0061] In light of the above considerations, problems to be solved when introducing SBA to the RAN may include:

[0062] How to support the RAN service abstraction and exposure to consumers residing in different domains (core, edge / cloud) 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)?

[0063] How to define RAN functionalities and RAN services to accommodate rapid and flexible RAN and core interaction with the minimum impact to the mobile network?

[0064] How to integrate RAN function services in a service bus, considering both RAN and other domains (e.g., 0AM, Core)?

[0065] A system and method are proposed here for extending SBA in RAN with potentially reduced impact on existing mobile networks. This solution provides a system for defining service-oriented RAN and a mechanism for supporting the exposure of RAN services via abstracting and chaining the services for a given use case (e.g. application service profile) or slice or QoS / QoE target or for a given intent / goal. Aspects of the present disclosure are described in the context of a wireless communications system.

[0066] Such a system is illustrated in Figure 3 and introduces a new RAN upper layer protocol (referred to as a “Service-based Integration Protocol”). According to an example embodiment the system can be an enhancement to an existing protocol (e.g., SDAP, RRC)] to support the integration with Core Network for service-based interactions.

[0067] It will be appreciated that RAN services are not limited to RRM and D-SON capabilities. However, the following discussion considers primarily 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. Such services can be for example related to a UE / group UE sessions, a slice, a cell area or sub-areas or cluster of cells, a certain service profile or application service, a QoS / QoE requirement, a core or DN operation:

[0068] 1) RRM functionalities, such as:Inter-cell RRMConnection Mobility ControlRadio Bearer Control, Radio Admission Control DRA / Scheduling / Measurement configuration Energy Saving / Cell Switch On-Off

[0069] 2) D-SON functionalities, such as:Automatic Neighbor RelationMobility Load BalancingMobility Robustness OptimizationEnergy SavingCell Degradation DetectionCoverage and capacity optimization

[0070] 3) AI / ML support services:Al-enabled RAN analytics servicesAl support for RAN analytics (ML training / inference for RAN analytics ID) Al support and analytics for enhancing existing RRM / SON functionalities.

[0071] 4) RAN Exposure support services (e.g. SBIP):RAN abstraction service.RAN registry service.RAN exposure / gateway service.

[0072] Referring again to Figure 3, RAN refers to a gNB or multiple gNBs covering one or more cells. In certain embodiments, such services can be for a given hotspot area or for a given cluster of cells (e.g. macro-cell and small cells / pico-cells). This is also referred as RAN domain in this disclosure. The illustration in Figure 3 concerns service-based upperRAN control functionalities. There can however be different groupings and implementations.

[0073] 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, I AB,..)UE-associated control services (decision for UE related parameters)RAN related monitoring servicesUE related monitoring servicesRAN policy related servicesRAN Slice associated services. A RAN slice is defined as the RAN part of a network slice which can be characterized as a specific RAN parameter configuration for a given slice type (e.g. eMBB, URLLC).- RNI services (RNIS) as defined in ETSI MEC (ETSI GS MEC 012). RNIS is a service that provides radio network related information to MEC applications and to MEC platforms. Such service in service-oriented design can be introduced as a new service, e.g. in cases where RAN services are deployed at the edge / MEC platforms and may interact with other RAN services to fetch data / measurements and provide configurations (e.g from / to MAC and RRC) for the RAN entities for the given MEC service area.XNAP / X2APP services (for interaction among BSs). Such services already support the interaction among BSs; however not in service-based manner. In this classification we introduce Xn / X2 interface capabilities as services which can be produced and consumed by different BSs / gNBs.

[0074] SBIP is defined here as a new protocol comprising RAN Exposure Services, and in particular the abstraction and gateway functionalities. This protocol allows the evolution of SBA without providing strict requirements on changing completely the RAN architecture and can also work with 5G NR and LTE radio access. The SBIP tasks include:Gateway functionality at RAN (acts as an entity similar to CCF in CAPIF for RAN service / API exposure).Chaining / Grouping capability of RAN services based on consumer requirements.A chain of services means that due to dependencies among RAN services these may be chained / grouped together to form a chained service. For example a load balancing RRM functionality with an inter-cell RRM functionality can be grouped together since there is a close interaction among them (e.g. any change in one function impacts the other). The notion of network service chaining, also known as service function chaining (SFC), is a capability that uses software-defined networking (SDN) capabilities to create a chain of connected network services.Monitoring capability and reporting.Registering RAN services on behalf of RAN (including one or more CUs / DUs / RUs. RAN context building and abstraction to ease the interaction with Core and App Server which “speak a different language”.

[0075] Figure 4 introduces the SBIP as part of the SBA bus and identifies a main differences when compared to 5G SBA. This is:The SBIP is part of the SBA bus at the gNB (at CU or abstracted at an edge RAN), where SBIP may also include RAN services which are “hidden” behind SBIP.

[0076] It is assumed that the SBIP (and / or the underlying RAN services via SBIP) is registered and discovered using NRF or a new SB repository at the core network which can also be distributed in the RAN (so the RAN service repository can be either in the Core or at the RAN). Figure 4 shows the SBIP running in both an anchor BS (e.g. macro, CU) and another RAN entity (e.g. a small cell or DU). This interaction allows the configuration of RAN services and provisioning or resources for the instantiated services.

[0077] The RAN entities can be a CU or DU or RAN controllers in RAN side. For the case of macro and small cells and multiple access points or even virtualization of RAN entities in different edge / cloud platforms it is not straightforward where an RAN service will run. The placement of RAN service could be for example at the CU or at the DU. It means where the actual processing happens (or where the algorithm runs). It is possible that the RCE-GW selects where a certain service is going to run.

[0078] Example of SBIP usage:SBIP to receive the UE / RAN parameters and translate them to actions / events which are perceivable by the Consumer NF (e.g., high load indication, RAN UE KPI reaching a low threshold) if the RAN service is about RAN performance.SBIP to receive an updated RRM policy from OAM or directly from AF or core network (e.g. PCF) and translate it to exact RAN services and radio parameters to be used, based on the real-time radio conditions.SBIP to support the abstraction / build of RAN context at RAN and will have the benefit of processing real-time measurements (e.g., CSI / CQI). Example RAN context building:• SBIP receives RAN / UE context (e.g., L2 measurements) from RAN and processes and abstracts to:UE QoE / QoS downgrade indicationHigh resource load indicationHigh RAN delay indicationLow backhaul / access resource availability indication.Frequent QoS fluctuations indicationRadio Link failures indication.

[0079] An exemplary method may comprises:1. Obtaining a requirement [for a given service / profile / use case / session / area]2. Determining a plurality of radio parameters to be involved using the service- oriented RAN based on the requirement.3. Determining at least one RAN service, wherein the at least one RAN service comprises the determined plurality of radio parameters. a. Determining a group of RAN services4. Registering the at least one RAN service or group of RAN services to a RAN service repository.5. Notifying information for the availability at least one RAN service to an involved domain entity (RAN, Core, OAM, UE).6. Acting as Gateway for the exposure of RAN services to at least one consumer.

[0080] A first embodiment, Embodiment 1 , provides the steps from 1 -5 in the above high level procedure for the scenario where the RCE-GW is triggered by the network and the consumer to determine the RAN services and their configuration. The RAN-GW is implemented as a function with a RAN Base Station, although the term “Base Station” should be interpreted broadly encompassing RAN Base Station functionality rather than necessarilyas a single entity. On the other hand, a second embodiment, Embodiment 2, focuses on the case where the RAN entity, i.e. Base Station (e.g. CU or gNB or DU), triggers the addition of RAN services to the extended SBA, and the run-time phase follows (the service consumption / API invocation phase) for the scenario where CAPIF is being leveraged. If we want to map embodiment 2 to the above high level steps it involves 1) receiving the requirement from the RAN entity itself, 2) abstracting the RAN service based on the exposure level / requirements, 3) registering the RAN services as APIs to the API repository (other IDF), 3) after discovery by the consumer, the RAN service API invocation phase and service consumption. As such, embodiment 2 is more about the RAN service addition to the SBA as RAN API and considers both the abstraction (as configuration) and the run-time operation. Embodiments 1 and 2 will now be discussed in more detail.

[0081] Embodiment 1 : SBIP as RAN Capability Exposure GW (RCE-GW) function / services.

[0082] In this embodiment, the SBIP is implemented as a RAN capability exposure gateway (RCE-GW) which can be deployed (as protocol or function / service or as entity / proxy) at the gNB or for a group of gNBs covering one or more cells. Such deployment covers also disaggregated RAN deployments, where RCE-GW is connected to one CU and a plurality of DUs / RU.

[0083] 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 RCE-GW for the exposure / abstraction of RAN services.

[0084] The mechanism has the following steps, illustrated in Figure 5:

[0085] Step 1 : The network provider via 0AM configures the RCE-GW in a target RAN area (RAN area can be defined as the topological area covering one or more cells). Such configuration may be based on the deployment of a new slice or based on a certain customer requirement or based on a network provider’s decision to expose RAN functionalities as services in a service-based cross-domain bus / mesh for a given use case / event. The configuration by 0AM includes at least some of the following parameters: cell ID(s), target area and time of validity, RAN configurations / slices supported, RAN entity IDs (e.g. CU ID, DU ID), permissions and tasks of RCE-GW [where permissions refer to authorizedcapabilities, CRUD operations and allowed exposure from RCE GW to external entities / consumers - such permissions can be based on the consumer type (e.g. network entity, external entity, OAM function, trusted 3rdparty entity)], expected consumers of RCE-GW (e.g. NFs, trusted AF, un-trusted AF), SBA deployment (e.g. bus, mesh), RAN service repository ID and address.

[0086] Step 2: RCE-GW (based on the configuration in step 1) or the OAM registers its available tasks for external usage with a given area / use case or slice / RAN configuration its gateway services (e.g. exposure, abstraction) to a RAN service Repository (RSR).

[0087] Step 3 : A prospective consumer of RAN services, which can be an NF or AF or MF (as RAN service consumer at OAM side), wishes to discover the RAN services for a given area / use case / slice / service profile / application etc., and queries the RSR to discover what RAN services are offered in the target cell(s). Such query can instead be provided directly towards the RCE-GW if known by the consumer. The RSR responds to the prospective consumer with information of available RAN services based on his request.

[0088] Step 4: The consumer (e.g. NF) sends to the RCE-GW a RAN service requirement request to provide the requirement and filtering information in terms of RAN parameters to be exposed for a given task. Such task can relate to a core network process / procedure, an analytics ID, a slice ID, an AF ID, a QoS flow, one or more UEs, one or more service profiles, one or more RATs. This requirement comprises in certain embodiments a goal / intent (for example a certain optimization target like QoE or performance metric) without having the knowledge of the exact RAN parameters to be exposed (an example of intent is the exposure of RAN latency analytics for a certain cell ID).

[0089] Step 5: RCE-GW determines a RAN capability exposure requirement, i.e. the RAN parameters, which are needed for the requirement and maps these to the RAN entities / function involved (e.g., CU / DU or RRC / MAC / PHY) for deriving these parameters. In this step, RCE-GW identifies dependencies among RAN entities / functions for deriving such parameters (e.g., inter-cell RRM and MAC scheduling dependencies). Based on this, RCE- GW identifies a set of RAN entities / functions as producers of the RAN parameters to be transformed to RAN services.

[0090] The RAN capability exposure requirement may be defined as the explicit requirement for radio parameters and / or services or functionalities or interfaces which arerequired to be transformed or abstracted in order to support the service-based integration, where support the service-based integration can be defined as providing the necessary enhancement in RAN (in one or more RAN entities) to enable the service-based integration with the core network entity and / or data network. The necessary enhancement in RAN may in turn be defined as the possible transformation of a RAN parameter to a "RAN service" or the creation or instantiation of a RAN service based on the underlying radio parameters and capabilities. The necessary enhancement in RAN may also refer to enhancing the RAN-Core interface (aka NGAP or N2 or N3) or the RAN to OAM interface, to support the servicebased integration.

[0091] Step 6: RCE-GW requests / subscribes to the RAN entities (e.g. CU / DU, RRC / MAC) to receive the required RAN parameters or to instantiate RAN services (and be configured as RAN service producer) based on the RAN parameters.

[0092] Some RAN functions / entities can be already service-based in a service-based RAN control fabric (which is hidden to other domains), and in that case the RCE-GW may query the RSR to discover RAN service info. In such a case, this step involves requesting RAN functions that are the RAN service producers and the RCE-GW is the RAN service consumer which is permitted to provide abstraction and exposure. For non-service-based RAN function / entities, RCE-GW in this step: either subscribes / requests to receive RAN parameters, and “transforms to” a RAN service on top without changing the below protocols, or requests the RAN entity (e.g. CU) to instantiate a new RAN service (e.g. RRM service).

[0093] Step 7: RCE-GW performs the abstraction of RAN parameters or services, to “exposable” RAN services based on the requirement from the consumer. Such abstraction can be also a grouping of RAN parameters / services for a given slice / RAN configuration or QoS / QoE target, considering also the dependencies among RAN parameters and entities.

[0094] Step 8: RCE-GW sends a RAN service requirement response to the consumer indicating a positive or negative response to the requirement, and providing also information on the RAN service availability (e.g. D-SON) and the RAN capability exposure.

[0095] Step 9: RCE-GW also notifies OAM on the new RAN services which are available at the target gNB / CU / DU / list of cells / RAN slice.

[0096] Step 10: After confirming with or obtaining approval from the 0AM, the RCE- GW registers the new RAN services to the RSR (or informs the RAN service producer entities to register their services: for example, the CU is notified by the RCE-GW that it can register the new RAN services with the given permissions for exposure to RSR).

[0097] Step 11 : In the run-time operation phase, based on the registered RAN services, the Consumer requests to consume a RAN service (e.g. subscribing for receiving RAN monitoring events, or requesting a certain radio measurement) from the RCE-GW.

[0098] Step 12: The RCE-GW further interacts with the RAN function / RAN service producer to get the RAN service output. For example, the RCE-GW interacts with the CU to receive L2 measurements. Based on the configuration, the RSE-GW may abstract the RAN service for exposing it to the consumer (e.g. changing the granularity, averaging the measurements or filtering some data).

[0099] Step 13 : Based on the abstraction or processing of step 12, the RCE-GW provides the RAN service output to the consumer based on the request (and the consumer’s? type and permissions for exposure). As example, in this step the consumer NF (e.g. NWDAF) receives RAN analytics for target cell performance, based on the configuration and the data received by the RAN analytics function at the gNB.

[0100] Embodiment 2: Enhancements to CAPIF

[0101] This embodiment provides a mechanism for exposing 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.

[0102] The CAPIF is hosted within the PLMN operator network or trust domain. The API invoker is typically provided by a 3rdparty application provider who has a service agreement with the PLMN operator. The API invoker may reside within the same trust domain as the PLMN operator network.

[0103] 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 interact with the CAPIF core function via CAPIF-3, CAPIF-4 and CAPIF-5 respectively.

[0104] In a service-based model, the CAPIF functional model uses service-based interfaces (Cccf, Caef). 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 of 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).AEF / APF / API management: existing functions can be enhanced to act as RAN service exposure support functions. AEF acts as a gateway, APF as the publishing function for advertising RAN services, and API management for supporting the management of RAN API from the RAN provider (e.g. MNO, RAN vendor).

[0105] Figure 6 illustrates schematically a CAPIF functional model representation using service-based interfaces.

[0106] Figure 7 illustrates describes the high level capability of RAN Exposure Support Function (RESF) for the supporting the exposure to the RAN API consumer who can be anAF or an NF or a MF, depending on which domain is leveraging CAPIF (core, management, service enabler layer, edge).

[0107] Step 1 : The RAN service function (e.g. CU or protocol function such as RRM / RRC) requests RESF to be added as exposable service in a service-oriented network architecture (e.g. core SBA, SBMA, Service-based application architecture). This request includes the RAN function ID, the list of RAN services and parameters, the type of RAN service (UE-associated, RAN-associated, slice-associated), the abstraction needed for exposure (e.g., hiding topology, changing granularity of exposure), the permissions for the consumers (e.g. only NFs, trusted AFs).

[0108] Step 2: The RESF authorizes the requests and performs the abstraction / translation of the RAN services based on the type of consumer / RAN API invoker or based on the process / use case / service / application for which the RAN service exposure may be needed. The RESF may also generate and configure the “RAN APIs” based on the RAN function services.

[0109] Step 3: The RESF sends a registration request to CCF (acting as RSR) and receives a registration response, to register the RAN services / APIs based on step 2.

[0110] Step 4: The RESF sends a notification to the RAN service function to inform about the success of the registration. The RESF may also advertise / publish the RAN services. The notification includes the RAN function ID, the RAN service identities and type, the RAN service producer identity, the permissions and exposure level, the area and time of validity, the QoS requirements (e.g. latency) and reporting configurations for the RAN service.

[0111] Step 5: The API invoker (RAN service consumer) requests the CCF to discover the RAN service APIs.

[0112] Step 6: CCF interacts with RESF to fetch the RAN service API information, to check the availability and status of RAN service APIs (e.g. CU service APIs). RESF checks with the RAN service function, which can be done by querying or subscribing to the RAN service function to receive updates on the RAN service availability and conditions. RSEF provides the updates to CCF.

[0113] Step 7 : CCF sends the discovery response to API invoker.

[0114] Step 8: The API invoker sends a RAN service API invocation request to the RESF. The request includes the API invoker identity (can be the NF ID or AF ID),authorization information, network slice information, RAN service API identification, RAN service producer identity / RAN function identity, RAN configuration ID, RAN entity identity (CU ID, DU ID), cell identity(-ies).

[0115] Step 9: The RESF obtains the authorization and access control on the RAN API invocation.

[0116] Step 10: The RESF sends a RAN service API invocation response to the API invoker. The response includes the success or failure of service API invocation, including also possible identity of the RAN service producer (RAN API provider) if not provided in step 8, and the invocation is in-direct via the RESF initially. For example the NF as API invoker invokes the API from the RCEF, and RCEF provides the CU ID which will be the RAN API provider function.

[0117] The RAN service consumer (API invoker) starts consuming the RAN services via the invoked RAN APIs.

[0118] The solution presented here introduces a Service-based Integration Protocol (SBIP) which can work in both service-based RAN evolved architectures and existing RAN architectures by utilizing a new entity for transforming the non-SB RAN to service-based.

[0119] Figure 8 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 LIE network or an LIE- 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.

[0120] 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.

[0121] 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.

[0122] 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.

[0123] A UE 104 may be able to support wireless communication directly with other UEs104 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 bereferred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.

[0124] 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).

[0125] 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.

[0126] 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).

[0127] 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.

[0128] 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.

[0129] 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.

[0130] 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 anumber (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.

[0131] 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.

[0132] 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 kHzsubcarrier 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.

[0133] Figure 9 illustrates an example of a NE 100 in accordance with aspects of the present disclosure. The NE 100 may include a processor 102, a memory 104, a controller 106, and a transceiver 108. The processor 102, the memory 104, the controller 106, or the transceiver 108, 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.

[0134] The processor 102, the memory 104, the controller 106, or the transceiver 108, 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.

[0135] The processor 102 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 102 may be configured to operate the memory 104. In some other implementations, the memory 104 may be integrated into the processor 102. The processor 102 may be configured to execute computer-readable instructions stored in the memory 104 to cause the NE 100 to perform various functions of the present disclosure.

[0136] The memory 104 may include volatile or non-volatile memory. The memory 104 may store computer-readable, computer-executable code including instructions when executed by the processor 102 cause the NE 100 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 104 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 storagemedium may be any available medium that may be accessed by a general-purpose or specialpurpose computer.

[0137] In some implementations, the processor 102 and the memory 104 coupled with the processor 102 may be configured to cause the NE 100 to perform one or more of the functions described herein (e.g., executing, by the processor 102, instructions stored in the memory 104). For example, the processor 102 may support wireless communication at the NE 100 in accordance with examples as disclosed herein.

[0138] The NE 100 may be configured to support a base station 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 base station to receive a network request for a RAN service, in response to receiving the network request, determine RAN parameters required for the RAN service, and provide the RAN service based on the determined RAN parameters.

[0139] The processor may be configured to, prior to providing the RAN service, obtain a service configuration for the RAN service based on the determined RAN parameters, wherein the service configuration is used to provide the RAN service.

[0140] The processor may be configured to send the service configuration to one or more of an entity identified as a producer of the RAN service, for example an entity within the apparatus or a different apparatus, and a RAN service repository.

[0141] The processor may be configured to determine RAN parameters by sending a request to at least one RAN entity acting as the RAN service producer to provide at least one RAN parameter for configuring the RAN service, and receiving the at least one RAN parameter for configuring the RAN service, wherein the service configuration comprises a RAN service area, time of validity, a RAN service producer identity and one or more RAN service API information.

[0142] The processor may be configured to obtain a service configuration based on a type of consumer.

[0143] The processor may be configured to cause the apparatus to publish the service configuration to at least one external entity.

[0144] The processor may be configured to send the service configuration to an 0AM function.

[0145] The processor may be configured to obtain a network request by receiving the request from a service consumer being one of a:Network Function;Application Function;0AM function; andRAN function, for example a further base station.

[0146] The processor may be configured to determine RAN parameters required to support the RAN service by selecting one or more RAN parameters from a preconfigured set of available RAN parameters.

[0147] The network request may define or otherwise 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 “minimizinginterference 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.

[0148] The RAN service may be a service-based interaction between the RAN and an external network or domain or a management system.

[0149] The processor may be configured to cause the apparatus to form a chain corresponding to a plurality of RAN services.

[0150] The processor may be configured to cause the apparatus to place the RAN service to one or more RAN entities, wherein the RAN entities comprise a DU, CU, RU, RIC, or RAN protocols.

[0151] The processor may be configured to send a response to a service consumer indicating a positive response to the network request.

[0152] The processor may be configured to cause the apparatus to receive from an 0 AM function configuration information including one or more of: cell ID(s); target area and time of validity;RAN configurations / slices supported;RAN entity IDs, permissions and tasks of RCE-GW; expected consumers of RCE-GW;SB A deployment (e.g. bus, mesh); andRAN service repository ID and address.

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

[0154] In some implementations, the NE 100 may include at least one transceiver 108. In some other implementations, the NE 100 may have more than one transceiver 108. The transceiver 108 may represent a wireless transceiver. The transceiver 108 may include one or more receiver chains 110, one or more transmitter chains 112, or a combination thereof.

[0155] A receiver chain 110 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 110 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 110 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. The receiver chain 110 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 110 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0156] A transmitter chain 112 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 112 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 112 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 112 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0157] Figure 10 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 describedherein. In some implementations, the NE may execute a set of instructions to control the function elements of the NE to perform the described functions.

[0158] At 202, the method may include receiving a network request for a RAN service. 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 9.

[0159] At 204, the method may include, in response to receiving the network request, determining RAN parameters required for the RAN service. 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 9.

[0160] At 206, the method may include providing the RAN service based on the determined RAN parameters. 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 9.

[0161] 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.

[0162] 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. A base station 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 base station to: receive a network request for a RAN service; in response to receiving the network request, determine RAN parameters required for the RAN service; and provide the RAN service based on the determined RAN parameters.

2. A base station according to claim 1, wherein the processor is configured to, prior to providing the RAN service, obtain a service configuration for the RAN service based on the determined RAN parameters, wherein the service configuration is used to provide the RAN service.

3. Apparatus according to claim 2, wherein the processor is configured to send the service configuration to one or more of: an entity identified as a producer of the RAN service, for example an entity within the apparatus or a different apparatus; and a RAN service repository.

4. Apparatus according to claim 2 or 3, wherein the processor is configured to determine RAN parameters by: sending a request to at least one RAN entity acting as the RAN service producer to provide at least one RAN parameter for configuring the RAN service; and receiving the at least one RAN parameter for configuring the RAN service; wherein the service configuration comprises a RAN service area, time of validity, a RAN service producer identity and one or more RAN service API information.

5. Apparatus according to any one of claims 2 to 4, wherein the processor is configured to obtain a service configuration based on a type of consumer.

6. Apparatus according to any one of claims 2 to 5, wherein the processor is configured to cause the apparatus to publish the service configuration to at least one external entity.

7. A base station according to any one of claims 2 to 6, wherein the processor is configured to send the service configuration to an OAM function.

8. A base station according to any one of the preceding claims, wherein the processor is configured to obtain a network request by receiving the request from a service consumer being one of a:Network Function;Application Function;OAM function; andRAN function, for example a further base station.

9. A base station according to any one of the preceding claims, wherein the processor is configured to determine RAN parameters required to support the RAN service by selecting one or more RAN parameters from a preconfigured set of available RAN parameters.

10. A base station according to any one of the preceding claims, wherein said network request 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.

11. A base station according to any one of the preceding claims, wherein the RAN service is a service-based interaction between the RAN and an external network or domain or a management system.

12. A base station according to any one of the preceding claims, wherein the processor is configured to cause the apparatus to form a chain corresponding to a plurality of RAN services.

13. A base station according to any one of the preceding claims, wherein the processor is configured to cause the apparatus to place the RAN service to one or more RAN entities, wherein the RAN entities comprise a DU, CU, RU, RIC, or RAN protocols.

14. A base station according to any one of the preceding claims, wherein the processor is configured to send a response to a service consumer indicating a positive response to the network request.

15. Apparatus according to any one of the preceding claims, wherein the processor is configured to cause the apparatus to receive from an OAM function configuration information including one or more of: cell ID(s); target area and time of validity;RAN configurations / slices supported;RAN entity IDs, permissions and tasks of RCE-GW; expected consumers of RCE-GW;SB A deployment (e.g. bus, mesh); andRAN service repository ID and address.

18. A method implemented in a Radio Access Network, RAN, and comprising: receiving a network request for a RAN service; in response to receiving the network request, determining RAN parameters required for the RAN service; and providing the RAN service based on the determined RAN parameters.

19. A method according to claim 18 and comprising, prior to providing the RAN service, obtaining a service configuration for the RAN service based on the determined RAN parameters, wherein the service configuration is used to provide the RAN service.

20. A method according to claim 18 or 19, wherein said network request is received from a service consumer being one of a:Network Function;Application Function;0AM function; andRAN function, for example a further base station.

Images