RAN Intelligent Controller(RIC)

Abstract

This radio access network (RAN) intelligent controller (RIC) (1, 3) acquires a first identifier associated with user equipment (UE) (6), and acquires, from a core network (7), a first type UE identifier corresponding to the first identifier. The RIC (1, 3) uses the first type UE identifier or a second type UE identifier associated with the first type UE identifier, in order to cause one or more RAN nodes (5) within a RAN (4) to perform control related to the UE (6). This configuration contributes to, for example, enabling the RIC to: identify a target UE on the basis of user identification information (first identifier) that is designated by an entity or an external server such as an application server; and perform continuous control with respect to the target UE.

Description

Technical Field

[0001] The present disclosure relates to an interface between a plurality of logical functions, controllers, or systems for the control and optimization of a wireless access network.

Background Art

[0002] The Open Radio Access Network (O-RAN) Alliance is a community of mobile network operators, vendors, and research and academic institutions, with the mission of reconstructing radio access networks (RANs) to be more intelligent, open, virtualized, and fully interoperable. The O-RAN Working Group 2 (WG2) has conducted technical studies on the Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC) and the A1 interface, and provided technical specifications regarding them (see, for example, Non-Patent Documents 1-5). On the other hand, the O-RAN Working Group 3 (WG3) has conducted technical studies on the Near-Real-Time (Near-RT) RIC and the E2 interface, and provided technical specifications regarding them (see, for example, Non-Patent Documents 6-11).

[0003] Non-RT RIC is a logical function within the Service Management and Orchestration (SMO) framework. The SMO framework is sometimes simply referred to as SMO. Non-RT RIC consists of the Non-RT RIC framework and Non-RT RIC applications (rApps). The Non-RT RIC framework includes the functionality to logically terminate the A1 interface and expose a set of R1 services to rApps. The A1 termination allows the Non-RT RIC framework and Near-RT RIC to exchange messages over the A1 interface. The set of R1 services includes A1-related services and O1-related services, along with other services.

[0004] A1-related services, along with other services, include creating, updating, querying, and deleting A1 policies, querying the enforcement status of A1 policies, and subscribing to event notifications related to A1 policies, including notifications of changes in the enforcement status of A1 policies.

[0005] O1-related services are provided by either the SMO framework or the Non-RT RIC framework, or both. O1-related services enable rApps to retrieve alarm information, network-related performance information, the current network configuration, provision changes to the network configuration, and additional network-related information.

[0006] The SMO framework provides various unanchored logical functions within the Non-RT RIC. These logical functions, along with other functions, include O1 termination, O2 termination, and external terminations. O1 termination enables the SMO framework to exchange messages with Near-RT RIC and E2 nodes over the O1 interface.

[0007] Near-RT RIC is a logical function that enables near real-time control and optimization of RAN elements and resources through granular data acquisition and action on the E2 interface. Near-RT RIC hosts a set of applications called xApps and provides a set of platform functions commonly used to support the specific functions hosted by xApps. The set of platform functions, along with other functions, includes interface terminations. Interface terminations include E2 terminations, A1 terminations, and O1 terminations, which provide terminations for the E2 interface, A1 interface, and O1 interface, respectively.

[0008] The E2 interface connects the Near-RT RIC to one or more E2 nodes. An E2 node is a logical node that terminates the E2 interface. An E2 node is a RAN node and exposes one or more RAN functions to the Near-RT RIC and hosted xApps. For NR access, an E2 node includes one or more O-RAN Central Units - Control Planes (O-CU-CPs), one or more O-RAN Central Units - User Planes (O-CU-UPs), one or more O-RAN Distributed Units (O-DUs), or any combination thereof. On the other hand, for Evolved Universal Terrestrial Radio Access (E-UTRA) access, an E2 node includes one or more O-RAN eNodeBs (O-eNBs).

[0009] An E2 node provides one or more services to the Near-RT RIC to provide access to messages and measurements, to enable control of the E2 node from the Near-RT RIC, or both. These services are called RIC services. The RIC services provided by the E2 node and available to the Near-RT RIC include four services: REPORT, INSERT, CONTROL, and POLICY. These RIC services can be combined in different ways to implement the E2 Service Model (E2SM). The E2 Service Model relies on the E2 node's RAN function and Radio Access Technology (RAT) and describes the functions of the E2 node and associated procedures that may be controlled by the Near-RT RIC. Currently, the E2 Service Model includes E2SM Key Performance Measurement (E2SM-KPM), E2SM Network Interfaces (E2SM-NI), and E2SM RAN Control (E2SM-RC).

[0010] The E2 interface provides E2 Application Protocol (E2AP) procedures to enable the exchange of control signal information between endpoints, realize RIC services, and make a set of services described as the E2SM service model available to Near-RT RICs and hosted xApps. These E2AP procedures, along with other procedures, include RIC Subscription, RIC Subscription Delete, RIC Control, and RIC Indication.

[0011] Incidentally, Patent Document 1 describes an apparatus and method for mobile edge computing. Specifically, Figures 4, 5 and paragraphs

[0052] -

[0067] of Patent Document 1 show that a Mobile Edge Computing (MEC) server obtains a second identifier from a core network node to identify a User Equipment (UE). The second identifier is used by the RAN node to identify the UE. The MEC server associates the received second identifier with a first identifier. The first identifier is used by the MEC server or an application (or service) hosted on the MEC server to identify the UE. The MEC server then communicates with the RAN node using the second identifier. This enables the MEC server (or an MEC application hosted on the MEC server) and the RAN node to directly exchange control messages (messages) regarding a particular UE.

[0012] The second identifier may uniquely identify the UE on the interface between the RAN node and the control plane core network node. Alternatively, the second identifier may uniquely identify the UE on the interface between the RAN node and the user plane core network node.

[0013] If the mobile network in Patent Document 1 is a Long Term Evolution (LTE) and LTE-Advanced network, the RAN node is an eNB, and the core network node may be a Mobility Management Entity (MME), Serving Gateway (S-GW), or Packet Data Network Gateway (P-GW). The first identifier may be a UE Internet Protocol (IP) address or the ID (or name) of the UE at the application layer. For example, the second identifier may be an S1 eNB Tunnel Endpoint Identifier (TEID) or an S1 S-GW TEID, or a combination thereof. The second identifier may be a combination of an S1 S-GW TEID and an S-GW identifier (e.g., an S-GW address). The second identifier may be an eNodeB UE S1 Application Protocol (S1AP) ID, or a combination of an eNodeB UE S1AP ID and an S1 eNB TEID. The second identifier may be a combination of an eNodeB UE S1AP ID and an MME UE S1AP ID. Alternatively, the second identifier may be a combination of the MME UE S1AP ID and the MME identifier (e.g., MME Code (MMEC), MME Identifier (MMEI), Globally Unique MMEI (GUMMEI)). [Prior art documents] [Patent Documents]

[0014] [Patent Document 1] International Publication No. 2017 / 099165 [Non-patent literature]

[0015] [Non-Patent Document 1] O-RAN ALLIANCE Working Group 2, "O-RAN Non-RT RIC Architecture 2.0", O-RAN.WG2.Non-RT-RIC-ARCH-TS-v02.00, July 2022 [Non-licensed document 2] O-RAN ALLIANCE Working Group 2, "O-RAN Non-RT RIC & A1 Interface: Use Cases and Requirements 6.0", O-RAN.WG2.Use-Case-Requirements-v06.00, July 2022 [Non-licensed document 3] O-RAN ALLIANCE Working Group 2, "O-RAN A1 interface: General Aspects and Principles 2.03", O-RAN.WG2.A1GAP-v02.03, October 2021

Non-licensed Document 4

Non-licensed Document 5

Non-licensed Document 6

Non-licensed Document 7

[0016] The inventors have investigated RAN control for UEs using Non-RT RICs and Near-RT RICs and identified various issues. One of these issues concerns continuous control of specific UEs. Another issue concerns improvements to enable Non-RT RICs and Near-RT RICs to identify target UEs based on user identification information specified by an external server or entity such as an application server, and to perform continuous control of those target UEs. User identification information may be, for example, an identifier used to identify a user, UE, or device in an application that utilizes connectivity or communication services provided by a wireless communication network including a RAN managed by O-RAN RICs (e.g., Protocol Data Unit (PDU) Connectivity services provided by a 5G network). Firstly, the current O-RAN technical specifications do not clearly define how Non-RT RICs and Near-RT RICs identify target UEs from user identification information specified by an external server. Secondly, a Non-RT RIC can create an A1 policy that identifies a target UE using a UE identifier based on the RAN's UE ID, and can request control over the target UE from the Near-RT RIC by providing such an A1 policy to the Near-RT RIC. The UE identifier based on the RAN's UE ID is a UE identifier assigned by the RAN node, specifically such as gNB-CU-CP UE E1AP ID, gNB-CU-UP UE E1AP ID, gNB-DU UE F1AP ID, or gNB-CU UE F1AP ID. However, the value of such a UE identifier changes depending on the RAN node to which the UE is connected due to handover or other reasons. Therefore, for example, if the RAN node changes frequently, frequent update processes between the Non-RT RIC and the Near-RT RIC may occur in response to the frequent changes in the value of the UE identifier.

[0017] Patent Document 1 discloses that the MEC server associates the first identifier of the UE in the application layer with the second identifier (e.g., MME UE S1AP ID and MME identifier) used in the core network, and communicates with the RAN node using the second identifier. However, Patent Document 1 does not contain an explicit description regarding the RIC.

[0018] Other problems obtained by the inventors relate to various elemental technologies for enabling or enhancing the above-described improvements. In the current O-RAN technical specifications, it is not stipulated that the Non-RT RIC instructs the Near-RT RIC with the UE identifier assigned by the core network rather than the RAN for controlling the target UE or providing policies. Also, the current O-RAN technical specifications do not sufficiently provide a method for the Near-RT RIC to notify the Non-RT RIC of the change in the value of the UE identifier assigned by the core network rather than the RAN.

[0019] One of the objectives to be achieved by the embodiments disclosed in this specification is to provide an apparatus, a method, and a program that contribute to solving at least one of a plurality of problems including the problems described above. It should be noted that this objective is only one of the plurality of objectives to be achieved by the plurality of embodiments disclosed in this specification. Other objectives or problems and novel features will be clarified from the description of this specification or the attached drawings.

Means for Solving the Problems

[0020] In a first embodiment, the RIC includes at least one memory and at least one processor coupled to the at least one memory. The at least one processor is configured to obtain a first identifier associated with a UE and to obtain a first type UE identifier corresponding to the first identifier from the core network. The at least one processor is configured to use the first type UE identifier or a second type UE identifier associated with the first type UE identifier to cause one or more RAN nodes in the RAN to perform control over the UE.

[0021] In the second aspect, the method performed by the RIC includes the following steps: (a) Obtain a first identifier associated with the UE, (b) Obtaining a first type UE identifier corresponding to the first identifier from the core network, and (c) To have one or more RAN nodes in the RAN perform control over the UE, use the first type UE identifier or the second type UE identifier associated with the first type UE identifier.

[0022] In a third embodiment, the first RIC includes at least one memory and at least one processor coupled to the at least one memory. The at least one processor is configured to transmit a first type of UE identifier of a UE assigned by the core network to a second RIC located between the first RIC and the RAN.

[0023] In a fourth aspect, the method performed by the first RIC includes transmitting a first type of UE identifier of a UE assigned by the core network to a second RIC located between the first RIC and the RAN.

[0024] A fifth aspect is directed toward a second RIC located between a first RIC and one or more RAN nodes. The second RIC includes at least one memory and at least one processor coupled to the at least one memory. The at least one processor is configured to receive a first type of UE identifier for a UE assigned by the core network from the first RIC.

[0025] A sixth aspect relates to a method performed by a second RIC located between a first RIC and one or more RAN nodes. This method comprises receiving a first type of UE identifier for a UE assigned by the core network from the first RIC.

[0026] In a seventh aspect, the first RIC includes at least one memory and at least one processor coupled to the at least one memory. The at least one processor is configured to receive notifications from a second RIC located between the first RIC and the RAN indicating a change in the value of a first type of UE identifier for a UE assigned by the core network.

[0027] In the eighth aspect, the method performed by the first RIC includes receiving a notification from a second RIC located between the first RIC and the RAN indicating a change in the value of a first type of UE identifier for a UE assigned by the core network.

[0028] A ninth aspect is directed toward a second RIC located between a first RIC and one or more RAN nodes. The second RIC includes at least one memory and at least one processor coupled to the at least one memory. The at least one processor is configured to send notifications to the first RIC indicating a change in the value of a first type of UE identifier of a UE assigned by the core network.

[0029] A tenth aspect relates to a method performed by a second RIC located between a first RIC and one or more RAN nodes. This method includes sending a notification to the first RIC indicating a change in the value of a first type of UE identifier for a UE assigned by the core network.

[0030] The eleventh aspect is directed towards a program, which, when loaded into a computer, includes a set of instructions (software code) for causing the computer to perform the methods relating to the second, fourth, sixth, eighth, or tenth aspect described above. [Effects of the Invention]

[0031] According to the above-described embodiment, it is possible to provide an apparatus, method, and program that contribute to solving at least one of the above-mentioned problems. [Brief explanation of the drawing]

[0032] [Figure 1] This diagram shows the configuration of a communication system or network according to the embodiment. [Figure 2] This diagram shows the configuration of a communication system or network according to the embodiment. [Figure 3] This flowchart shows an example of an operation performed by a Non-RT RIC or Near-RT RIC according to the embodiment. [Figure 4] This flowchart shows an example of an operation performed by a Non-RT RIC or Near-RT RIC according to the embodiment. [Figure 5] This is a sequence diagram showing an example of the operation of the Non-RT RIC and Near-RT RIC according to the embodiment. [Figure 6] This is a sequence diagram showing an example of the operation of the Non-RT RIC and Near-RT RIC according to the embodiment. [Figure 7] This is a sequence diagram showing an example of the operation of the Non-RT RIC and Near-RT RIC according to the embodiment. [Figure 8]This is a sequence diagram showing an example of the operation of the Non-RT RIC and Near-RT RIC according to the embodiment. [Figure 9] This is a block diagram showing example configurations of Non-RT RIC and Near-RT RIC according to the embodiment. [Modes for carrying out the invention]

[0033] The following describes specific embodiments in detail with reference to the drawings. In each drawing, the same or corresponding elements are denoted by the same reference numerals, and redundant explanations are omitted where necessary for clarity.

[0034] The multiple embodiments described below can be implemented independently or in combination as appropriate. These multiple embodiments have novel features that differ from each other. Therefore, these multiple embodiments contribute to solving different objectives or problems and contribute to producing different effects.

[0035] The following embodiments are primarily described for Non-RT RICs and Near-RT RICs that conform to the O-RAN technical specifications. However, these embodiments may also be applied to other systems that support technologies similar to O-RAN Non-RT RICs and Near-RT RICs.

[0036] As used herein, depending on the context, “(if)” may be interpreted as meaning “when,” “at or around the time,” “after,” “upon,” “in response to determining,” “in accordance with a determination,” or “in response to detecting.” These expressions may be interpreted as having the same meaning depending on the context.

[0037] First, the configuration and operation of several elements common to multiple embodiments will be described. Figure 1 shows an example configuration of a communication system or network according to multiple embodiments. In the example in Figure 1, the system includes a Non-RT RIC 1, an SMO framework 2, a Near-RT RIC 3, a RAN 4, and a 5G Core Network (5GC) 7. The SMO framework 2 may simply be called SMO. Each element (network function) shown in Figure 1 can be implemented, for example, as a network element on dedicated hardware, as a running software instance on dedicated hardware, or as an instantiated virtualization function on an application platform.

[0038] Non-RT RIC 1 is a logical function within SMO or SMO Framework 2. Non-RT RIC 1 consists of a Non-RT RIC framework and Non-RT RIC applications (rApps). The Non-RT RIC framework includes the functionality to logically terminate the A1 interface and expose a set of R1 services to rApps. The A1 termination enables the Non-RT RIC framework and Near-RT RIC to exchange messages over the A1 interface. The set of R1 services includes A1-related services and O1-related services, along with other services.

[0039] A1-related services, along with other services, include creating, updating, querying, and deleting A1 policies, querying the enforcement status of A1 policies, and subscribing to event notifications related to A1 policies, including notifications of changes in the enforcement status of A1 policies.

[0040] O1-related services are provided by the SMO Framework 2 and the Non-RT RIC Framework. These O1-related services enable rApps to retrieve alarm information, network-related performance information, the current network configuration, provision changes to the network configuration, and additional network-related information.

[0041] The SMO Framework 2 provides various logical functions that are not anchored within Non-RT RIC 1. These logical functions, along with other functions, include O1 termination, O2 termination, and external terminations. The O1 termination enables the SMO Framework 2 to exchange messages with Near-RT RIC 3 and E2 nodes over the O1 interface. The O2 termination enables the SMO Framework 2 to exchange messages with O-Cloud over the O2 interface. O-Cloud is a cloud computing platform consisting of a collection of physical infrastructure nodes that meet O-RAN requirements, hosting relevant O-RAN functions, supporting software components, and appropriate management and orchestration capabilities. Relevant O-RAN functions include, for example, Near-RT RIC and E2 nodes. External terminations enable the SMO Framework 2 or Non-RT RIC framework to exchange messages with external entities via interfaces outside the scope of O-RAN.

[0042] Near-RT RIC 3 is a logical function that enables near real-time control and optimization of RAN elements and resources through granular (e.g., UE basis, Cell basis) data collection and action on the E2 interface. Near-RT RIC hosts a set of applications called xApps and provides a set of platform functions commonly used to support the specific functions hosted by xApps. The set of platform functions includes databases and shared data layers (SDL), xApp subscription management, conflict mitigation, messaging infrastructure, interface termination, and Application Programming Interface (API) enablement. Interface termination includes E2 termination, A1 termination, and O1 termination, which provide termination for the E2 interface, A1 interface, and O1 interface, respectively.

[0043] RAN 4 includes one or more RAN nodes. In the O-RAN framework, RAN nodes are called E2 nodes. An E2 node is a logical node that terminates an E2 interface and exposes one or more RAN functions to Near-RT RIC 3 and hosted xApps.

[0044] In the example in Figure 1, RAN 4 is a Next Generation RAN (NG-RAN) and includes one or more gNBs 5. Note that gNBs 5 are merely examples of RAN nodes or E2 nodes. For example, if Central Unit (CU)-Distributed Unit (DU) separation is applied, each gNB 5 may include one gNB Central Unit (CU) and one or more gNB Distributed Units (DUs). If Control Plane (CP)-User Plane (UP) separation is further applied, gNB-CU may include gNB-CU-CP and gNB-CU-UP. RAN 4 may include other types of RAN nodes in place of or in addition to gNBs 5. For example, RAN 4 may include other NG-RAN nodes. Other NG-RAN nodes may include one or more ng-eNBs. Each ng-eNB may include one ng-eNB-CU and one or more ng-eNB-DUs. Each ng-eNB-CU may contain one ng-eNB-CU-CP and one or more ng-eNB-CU-UPs. If RAN 4 is or includes an Evolved Universal Terrestrial Radio Access Network (E-UTRAN), RAN 4 may contain one or more eNBs.

[0045] 5GC 7 includes one or more Access and Mobility Management Functions (AMFs) 71, one or more Session Management Functions (SMFs) 72, and one or more User Plane Functions (UPFs) 73. AMF 71 is one of the network function nodes in the control plane of 5GC 7. AMF 71 provides the termination of the RAN Control Plane (CP) interface (i.e., N2 interface). AMF 71 terminates a single signaling connection (i.e., N1 NAS signalling connection) with UE 6 and provides registration management, connection management, and mobility management.

[0046] SMF 72 is one of the network function nodes in the control plane of 5GC 7. SMF 72 manages PDU Sessions. SMF 72 sends and receives SM signaling messages (NAS-SM messages, N1 SM messages) to and from the Non-Access-Stratum (NAS) Session Management (SM) layer of UE 6 via communication services provided by AMF 71.

[0047] UPF 73 is one of the network function nodes in the user plane of 5GC 7. UPF 73 processes and forwards user data. The functionality of UPF 73 is controlled by SMF 72. UPF 73 may include multiple UPFs interconnected via the N9 interface. The UP path for one PDU Session of UE 6 may include one or more PDU Session Anchor (PSA) UPFs, one or more Intermediate UPFs (I-UPFs), and one or more Uplink Classifier (UL CL) UPFs (or Branching Point (BP) UPFs). The UP path for a PDU Session is the path configured within 5GC 7 to route user plane data (e.g., Internet Protocol (IP) packets) of that PDU Session from UE 6 to DN 8 and vice versa. The UP path includes at least one UPF 73 and includes the N6 interface with DN 8. An UP path may include one or more N9 tunnels. An N9 tunnel is a tunnel between two UPFs.

[0048] The 5GC 7 may include other network functions not shown in the diagram. For example, the 5GC 7 may include a Policy Control Function (PCF), Unified Data Management (UDM), and Network Exposure Function (NEF).

[0049] The PCF is one of the network function nodes in the 5GC 7 control plane. The PCF supports interactions with access and mobility policy enforcement within the AMF 71. The PCF provides access and mobility management-related policies to the AMF 71. Furthermore, the PCF provides session-related policies to the SMF 72.

[0050] The UDM is one of the network function nodes in the control plane of 5GC 7. The UDM provides access to the database (i.e., User Data Repository (UDR)) where subscriber data (subscription information) is stored.

[0051] The NEF is one of the network function nodes within the control play of 5GC 7. The NEF plays a role similar to the Service Capability Exposure Function (SCEF) of the Evolved Packet System (EPS). Specifically, the NEF supports the exposure of services and capabilities from 3rd Generation Partnership Project (3GPP®) systems (e.g., 5GC 7) to applications and network functions both inside and outside the operator network.

[0052] Application server 9 may communicate with applications running on the processor of UE 6 (or the processor of a machine, vehicle, or device coupled to or using UE 6) by utilizing connectivity or communication services (i.e., PDU Connectivity services) provided by 5GC 7 and RAN 4. Application server 9 may include one or more servers. One or more servers may provide different functions from each other. For example, one server may communicate with UE 6 at the application layer, while other servers may provide interfaces with Non-RT RIC 1 or SMO framework 2. These servers may be distributed. For example, in addition to the central server, application server 9 may include one or more edge computing servers located near RAN 4.

[0053] UE 6 connects to one or more RAN nodes (e.g., gNBs 5) in RAN 4 via an air interface, and further connects to 5GC 7 via RAN 4. UE 6 communicates with DN 8 via user plane connectivity (e.g., PDU Session) provided by RAN 4 and 5GC 7. UE 6 may also be referred to in other terms such as wireless terminal, mobile terminal, mobile station, or wireless transmit-receive unit (WTRU). UE 6 may be implemented in machinery, vehicles, or devices. For example, but not limited to, UE 6 may be implemented in mobile machinery, vehicles, or devices, more specifically in automated guided vehicles (AGVs), mobile robots, or construction machinery.

[0054] In the example in Figure 1, Non-RT RIC 1 or SMO Framework 2 provides the interface termination with 5GC 7. This interface may be an N5 interface or an N33 interface. An N5 interface is an interface or reference point between a PCF and an Application Function (AF) in 3GPP scope or terminology. An N33 interface is an interface or reference point between an NEF and an AF. In other words, Non-RT RIC 1 or SMO Framework 2 may operate as an AF. Depending on the policy of the network operator providing 5GC 7, Non-RT RIC 1 or SMO Framework 2 as an AF may interact directly with network functions within 5GC 7. Otherwise, Non-RT RIC 1 or SMO Framework 2 interacts with network functions within 5GC 7 via an NEF.

[0055] Furthermore, in the example shown in Figure 1, Non-RT RIC 1 or SMO framework 2 provides the interface termination with application server 9.

[0056] The RAN 4 and 5GC 7 shown in Figure 1 may be provided by a Mobile Network Operator (MNO) or may be Non-Public Networks (NPNs) provided by entities other than MNOs. If these are NPNs, they may be independent networks referred to as Stand-alone Non-Public Networks (SNPNs) or NPNs linked to an MNO network referred to as Public network integrated NPNs (PNI-NPNs).

[0057] Figure 2 shows a variation of the configuration shown in Figure 1. In the example in Figure 2, Near-RT RIC 3 provides the interface termination with application server 9. Also in the example in Figure 2, (PSA) UPF 73 is located near RAN 4 for local access to DN 8 near RAN 4. Such a UPF may be called a local UPF. UPF 73 may share computing resources with some of the functions of gNB 5. In other words, UPF 73 may be collocated with any of the RAN nodes. Alternatively, UPF 73 may be collocated at the network aggregation site between RAN 4 and 5GC 7.

[0058] The configurations shown in Figures 1 and 2 can be modified as appropriate. The configuration of UPF 73 in the examples in Figures 1 and 2 is just one example. For example, even if the application server 9 interfaces with the Near-RT RIC 3 as shown in Figure 2, UPF 73 may be located at the central site as in Figure 1. Conversely, even if the application server 9 interfaces with the Non-RT RIC 1 as shown in Figure 1, UPF 73 may be located at the local site as in Figure 2. gNBs 5 and 5GC 7 may be replaced with other wireless networks, such as the corresponding elements of the EPS. Specifically, RAN 4 may include eNBs. The core network (e.g., Evolved Packet Core (EPC)) that replaces 5GC 7 may include MME, S-GW, P-GW, PCRF, Home Subscriber Server (HSS), and SCEF, etc.

[0059] <First Embodiment> The configuration example of the wireless communication system according to this embodiment may be the same as the example shown in Figure 1 or Figure 2. This embodiment provides an example of operation performed by Non-RT RIC 1, Near-RT RIC 3, or a combination thereof.

[0060] Figure 3 shows an example of operation performed by Non-RT RIC 1, Near-RT RIC 3, or a combination thereof. In the following description of Figure 3, the term "RIC" may refer to Non-RT RIC 1, Near-RT RIC 3, or a combination thereof, unless otherwise specified.

[0061] In step 301, the RIC obtains a first identifier associated with the UE 6. The first identifier may also be referred to as first identification information. The RIC may obtain the first identifier from the application server 9. The RIC may obtain the first identifier from the application server 9 via an external interface. The external interface may be provided by Non-RT RIC 1, SMO framework 2, or Near-RT RIC 3. In the configuration example in Figure 1, Non-RT RIC 1 may obtain the first identifier from the application server 9 via an external interface provided by Non-RT RIC 1 or SMO framework 2. In the configuration example in Figure 2, Near-RT RIC 3 may obtain the first identifier from the application server 9 via the external interface of Near-RT RIC 3.

[0062] For example, the first identifier may be an identifier (e.g., AGV ID) for identifying a machine, vehicle, or device that uses or implements UE 6. Alternatively, the first identifier may include an identifier for identifying a user or application that uses UE 6. In other words, the first identifier may include an identifier for an application running on the UE 6 processor. The first identifier may include an identifier for an application running on the processor of a machine, vehicle, or device coupled to UE 6. Alternatively, the first identifier may be an IP address for identifying a packet forwarding service, PDU Session, or Packet Data Network (PDN) Connection used by UE 6. Packet forwarding services refer to connectivity services provided by RAN 4 and 5GC 7.

[0063] In step 302, the RIC obtains a first-type UE identifier corresponding to the first identifier from the core network (e.g., 5GC 7). More specifically, in the configuration example in Figure 1, Non-RT RIC 1 may obtain the first-type UE identifier directly from AMF 71 or SMF 72 within 5GC 7, or via other network elements such as PCF or NEF. Non-RT RIC 1 may request 5GC 7 to send or provide the first-type UE identifier. Non-RT RIC 1 may query 5GC 7 for the first-type UE identifier. Non-RT RIC 1 may query 5GC 7 for the first-type UE identifier using the first identifier or a second identifier associated with the first identifier. The second identifier may include, but is not limited to, a Subscription Permanent Identifier (SUPI), International Mobile Subscriber Identity (IMSI), or Generic Public Subscription Identifier (GPSI). Non-RT RIC 1 may maintain a correspondence list between a first identifier and a second identifier. This correspondence list may be stored in storage accessible to Non-RT RIC 1. This correspondence list may be prepared in advance by the operator.

[0064] In the configuration example shown in Figure 2, Near-RT RIC 3 may obtain a first type UE identifier from 5GC 7 via Non-RT RIC 1. Specifically, Near-RT RIC 3 may send a first identifier obtained from application server 9, or a second identifier associated with the first identifier, to Non-RT RIC 1. Near-RT RIC 3 may request Non-RT RIC 1 to provide a first type UE identifier corresponding to the first identifier (or second identifier). Near-RT RIC 3 may then receive the first type UE identifier obtained from 5GC 7 by Non-RT RIC 1 via a query using the first identifier (or second identifier) ​​from Non-RT RIC 1. Near-RT RIC 3 may send the first identifier (or second identifier) ​​to Non-RT RIC 1 via a request to create or execute an A1 enrichment information job that indicates the first identifier (or second identifier). Near-RT RIC 3 may then receive the first type of UE identifier from Non-RT RIC 1 using a delivery procedure for providing the results of the A1 enrichment information job.

[0065] The first type of UE identifier must be a UE identifier that is commonly known to both RAN 4 and 5GC 7. Therefore, the first type of UE identifier may be a UE identifier assigned by a RAN node in RAN 4 (e.g., gNB 5), for example, a combination of the gNB UE NGAP ID and the gNB ID (e.g., Global gNB ID). However, it is preferable to avoid frequent changes in the value of the first type of UE identifier. In this respect, it is preferable that the first type of UE identifier is an identifier assigned by the core network (e.g., 5GC 7 or EPC). The first type of UE identifier may be assigned by the core network on the control interface (e.g., N2 or NG-C interface) between the core network (e.g., 5GC 7 or EPC) and RAN 4. In other words, the first type of UE identifier may be assigned by the core network to identify UE 6 on the control interface between the core network and RAN 4. The first type of UE identifier may be assigned by a control node (e.g., AMF 71 or MME) located within the core network (e.g., 5GC 7 or EPC) and providing mobility management for UE 6. If the first type of UE identifier is obtained from 5GC 7, it may include an AMF UE NGAP ID, or a combination of an AMF UE NGAP ID and an AMF identifier. The AMF identifier may be all or part of a Globally Unique AMF Identifier (GUAMI). If the first type of UE identifier is obtained from EPC, it may include an MME UE S1AP ID, or a combination of an MME UE S1AP ID and an MME identifier. The MME identifier may be all or part of a Globally Unique MME Identifier (GUMMEI).

[0066] In step 303, the RIC uses a first-type UE identifier or a second-type UE identifier associated with a first-type UE identifier to have one or more RAN nodes (e.g., gNBs 5) in RAN 4 take control of UE 6. Specifically, in the configuration example in Figure 1, Non-RT RIC 1 may request Near-RT RIC 3 to implement an A1 policy regarding UE 6 based on a first-type UE identifier. In other words, Non-RT RIC 1 may provide a first-type UE identifier to Near-RT RIC 3 by requesting Near-RT RIC 3 to create or implement an A1 policy defined using a first-type UE identifier.

[0067] In this case, the UE identifiers included in the scope identifier within the A1 policy may be extended to indicate first-type UE identifiers (e.g., AMF UE NGAP ID and AMF identifier). The A1 policy consists of a scope identifier and one or more policy statements. The scope identifier represents the target to which the policy statements apply (e.g., UEs, Quality of Service (QoS) flows, or cells). The policy statements express goals to Near-RT RIC 3 and cover policy objectives and policy resources.

[0068] In the configuration examples shown in Figures 1 and 2, Near-RT RIC 3 may request a RAN node (e.g., gNB 5, gNB-CU, or gNB-CU-CP) to perform control over UE 6 using the first type UE identifier of UE 6. Near-RT RIC 3 may obtain a list of first type UE identifiers of UEs connected to each RAN node from one or more RAN nodes via the E2 interface. Near-RT RIC 3 may select a RAN node that has provided a list containing the values ​​of the first type UE identifiers of UE 6 obtained from the core network (e.g., 5GC 7), and request the selected RAN node to perform control over UE 6. Control over UE 6 may include, but is not limited to, QoS control for devices running mission-critical applications that require meeting certain delays, throughput, or both conditions. Mission-critical applications may include, for example, equipment control or video surveillance applications. For example, Near-RT RIC 3 may request the RAN node to perform QoS control on the UE 6's radio bearer, specifying a packet delay budget (PDB).

[0069] Alternatively, Near-RT RIC 3 may request a RAN node to perform control over UE 6 using a second type of UE identifier for UE 6. In particular, Near-RT RIC 3 may request a RAN node that does not have a control plane connection to the core network to perform control over UE 6 using a second type of UE identifier. Such a RAN node may be, for example, a DU (e.g., gNB-DU) when CU-DU isolation is applied, a CU-UP (e.g., gNB-CU-UP) when CP-UP isolation is applied, or a secondary node (e.g., Secondary gNB) when Dual Connectivity is set up. The second type of UE identifier may be a gNB-CU UE F1AP ID for controlling gNB-DU. The second type of UE identifier may be a gNB-CU-CP UE E1AP ID for controlling gNB-CU-UP. Alternatively, the second type of UE identifier may include an M-NG-RAN node UE XnAP ID for controlling a secondary node.

[0070] As described with reference to Figure 3, Non-RT RIC 1, Near-RT RIC 3, or a combination thereof, obtains a first-type UE identifier from the core network (e.g., 5GC 7) that corresponds to the user identification information (i.e., first identifier) ​​specified by the external server (e.g., application server 9). This allows Non-RT RIC 1, Near-RT RIC 3, or a combination thereof, to identify the target UE corresponding to the user identification information specified by the external server.

[0071] In addition, as mentioned above, in one preferred example, the first type UE identifier may be an identifier assigned by the core network. This can help avoid frequent changes to the first type UE identifier. This can, for example, avoid an increase in the number of update processes between Non-RT RIC 1 and Near-RT RIC 3 due to frequent changes in the value of the first type UE identifier.

[0072] Figure 4 shows a modified version of the operation shown in Figure 3. Figure 4 shows an example of operation performed by Non-RT RIC 1 or Near-RT RIC 3 or a combination thereof. In the following description of Figure 4, the term "RIC" may refer to Non-RT RIC 1 or Near-RT RIC 3 or a combination thereof unless otherwise specified.

[0073] Steps 401-403 in Figure 4 are the same as steps 301-303 in Figure 3. In step 404, the RIC tracks or monitors changes in the value of the first type UE identifier based on notifications from RAN 4. More specifically, the RIC receives notifications from RAN 4 indicating changes in the value of the first type UE identifier and updates the association between the first identifier and the first type UE identifier. In other words, the RIC tracks or monitors changes in the value of the first type UE identifier based on notifications from RAN 4, thereby keeping the association between the first identifier and the first type UE identifier up to date.

[0074] In other words, after the RIC learns the first type of UE identifier corresponding to the first identifier by querying the core network (e.g., 5GC 7), the RIC tracks changes in the value of the first type of UE identifier based on notifications from RAN 4. This allows the RIC to request the RAN node managing the updated value to take control of UE 6 based on the updated value of the first type of UE identifier.

[0075] In the configuration example shown in Figure 1, Non-RT RIC 1 may receive notifications from Near-RT RIC 3 via the A1 interface indicating a change in the value of a first-type UE identifier. Generally, information gathering on the A1 interface takes less time than information gathering on the O1 interface. Therefore, this allows Non-RT RIC 1 to become aware of changes in the value of a first-type UE identifier more quickly than when using the O1 interface.

[0076] For example, Non-RT RIC 1 may receive notification from Near-RT RIC 3 indicating a change in the value of a first type UE identifier via policy feedback regarding the A1 policy. However, existing policy feedback on the A1 interface can only indicate the non-implementation of the A1 policy and its brief cause. Specifically, the policy feedback can only indicate that the reason for non-implementation is "SCOPE_NOT_APPLICABLE", "STATEMENT_NOT_APPLICABLE", or "OTHER_REASON". To address this problem, in this embodiment, the A1 policy feedback may be improved or extended to indicate the changed value of the first type identifier. Alternatively, the A1 policy feedback may be improved or extended to indicate the old value of the first type UE identifier before the change and the new value after the change.

[0077] In another example, Non-RT RIC 1 may receive notification from Near-RT RIC 3 indicating a change in the value of a Type 1 UE identifier in one or more new A1 policy procedures distinct from the feedback policy procedures. The newly defined procedures may include push-type procedures similar to the feedback policy procedures. Alternatively, the newly defined procedures may include pull-type procedures involving queries from Non-RT RIC 1 and responses from Near-RT RIC 3.

[0078] In the configuration examples shown in Figures 1 and 2, Near-RT RIC 3 receives a notification from the RAN node that detected the change in the first type of UE identifier. This RAN node may be the target node for UE 6's handover. Alternatively, this RAN node may be the RAN node from which UE 6 re-established a Radio Resource Control (RRC) connection. UE 6 re-establishes the RRC connection, for example, in response to the detection of a Radio Link Failure (RLF) or a handover failure.

[0079] Near-RT RIC 3 can receive notifications indicating a change in a first type of UE identifier via a RIC INDICATION message on the E2 interface. This RIC INDICATION message may be an E2 Service Model (E2SM) RAN Control (RC) REPORT Service Style 4: UE Information RIC INDICATION message. This REPORT service style is initiated by E2SM-RC Event Trigger style 4: UE Information Change. This event trigger style is used to detect changes in UE context information. Changes in UE context information supported as event triggers include changes in UE identifiers. Event triggers related to changes in UE identifiers may be New UE Connected, UE Handed Over, UE ID Changed, or UE ID Removed. The New UE Connected event trigger is triggered when a new UE ID is assigned to a newly connected UE. The UE Handed Over event trigger is triggered when a new UE ID is assigned due to a handover from another node. The UE ID Changed event trigger is triggered when the content of any of the assigned UE IDs is changed. The RIC INDICATION message may be triggered by any of these changes to the UE identifier.

[0080] Figure 5 shows an example of the operation of Non-RT RIC 1 and Near-RT RIC 3 in the configuration example shown in Figure 1. In step 501, Non-RT RIC 1 receives a first identifier (e.g., user ID) from the application server (AS) 9. In step 502, Non-RT RIC 1 queries 5GC 7 for a first type UE identifier corresponding to the first identifier. Non-RT RIC 1 may also query 5GC 7 for a first type UE identifier using a second identifier associated with the first identifier. As previously explained, the first type UE identifier may be an AMF UE NGAP ID. Hereafter, we will assume that the first type UE identifier is an AMF UE NGAP ID. In step 503, Non-RT RIC 1 receives the first type UE identifier of UE 6, i.e., the current value of the first type UE identifier of UE 6, from 5GC 7. In step 504, Non-RT RIC 1 manages the association between a first identifier (e.g., User ID) and a first type of UE identifier (AMF UE NGAP ID).

[0081] In step 505, Non-RT RIC 1 requests Near-RT RIC 3 to create or implement an A1 policy. This policy creation request indicates a Type 1 UE identifier (AMF UE NGAP ID) to identify the target UE. Specifically, the Type 1 UE identifier (AMF UE NGAP ID) may be included in the scope identifier within the policy object contained in the policy creation request.

[0082] In step 506, Near-RT RIC 3 initiates control over UE 6, identified by the AMF UE NGAP ID provided in the A1 policy, in order to achieve the goal indicated in one or more policy statements provided in the A1 policy. Specifically, Near-RT RIC 3 sends one or both of the RIC SUBSCRIPTION REQUEST and RIC CONTROL REQUEST to the target RAN node (e.g., gNB 5) in RAN 4. The RIC SUBSCRIPTION REQUEST and RIC CONTROL REQUEST indicate the AMF UE NGAP ID. Alternatively, the RIC SUBSCRIPTION REQUEST and RIC CONTROL REQUEST may indicate other UE IDs associated with the AMF UE NGAP ID, such as a UE identifier assigned by the RAN node (e.g., gNB-CU UE F1AP ID).

[0083] In step 507, Near-RT RIC 3 receives a RIC INDICATION from RAN 4 indicating the updated new value of the AMF UE NGAP ID. In step 508, Near-RT RIC 3 notifies Non-RT RIC 1 of the new value of the AMF UE NGAP ID. Specifically, Near-RT RIC 3 may also send an extended A1 policy feedback to Non-RT RIC 1 on the A1 interface, indicating the new value of the AMF UE NGAP ID.

[0084] In step 509, Non-RT RIC 1 updates the association between the first identifier (e.g., User ID) and the first type of UE identifier (AMF UE NGAP ID) with the new value of the AMF UE NGAP ID.

[0085] In step 510, Non-RT RIC 1 sends an A1 policy update request to Near-RT RIC 3, indicating the new value for the AMF UE NGAP ID. The A1 policy update request requests an update to the A1 policy created in step 505. Alternatively, Non-RT RIC 1 may request Near-RT RIC 3 to delete the A1 policy created in step 505 and create a new A1 policy with the new value for the AMF UE NGAP ID.

[0086] In step 511, Near-RT RIC 3 takes control of UE 6, which is identified by the new value of the AMF UE NGAP ID. However, in response to receiving the RIC INDICATION in step 507 indicating the new value of the AMF UE NGAP ID, Near-RT RIC 3 may promptly start processing in step 511. In other words, Near-RT RIC 3 may perform step 511 before step 508. Alternatively, Near-RT RIC 3 may perform step 511 before step 510. In these cases, step 510 may be omitted. Near-RT RIC 3 may autonomously track or monitor changes in the AMF UE NGAP ID and promptly request the new RAN node to take control of UE 6 in response to the change in the AMF UE NGAP ID. Whether Near-RT RIC 3 should perform this action may be indicated by the A1 policy received in step 505. In other words, the A1 policy in step 505 may explicitly require Near-RT RIC 3 to continue to maintain control over a specific UE while autonomously tracking or monitoring changes in the AMF UE NGAP ID.

[0087] As described with reference to Figure 5, Non-RT RIC 1 and Near-RT RIC 3 can identify a target UE based on user identification information (first identifier) ​​specified by an external server or entity such as application server 9, and can perform continuous control over that target UE.

[0088] Figure 6 shows an example of the operation of Non-RT RIC 1 and Near-RT RIC 3 in the configuration example of Figure 2. In step 601, Near-RT RIC 3 receives a first identifier (e.g., user ID) from application server 9. In step 602, Near-RT RIC 3 sends the first identifier (e.g., user ID) to Non-RT RIC 1. Near-RT RIC 3 may also send the first identifier (e.g., user ID) to Non-RT RIC 1 over the A1 interface. Steps 603 and 604 are the same as steps 502 and 503 in Figure 5. As already explained, the first type of UE identifier may be an AMF UE NGAP ID. Hereafter, we will assume that the first type of UE identifier is an AMF UE NGAP ID.

[0089] In step 605, Non-RT RIC 1 sends a first type UE identifier (AMF UE NGAP ID) to Near-RT RIC 3. For example, Non-RT RIC 1 requests Near-RT RIC 3 to create or implement an A1 policy. This policy creation request specifies a first type UE identifier (AMF UE NGAP ID) to identify the target UE. Specifically, the first type UE identifier (AMF UE NGAP ID) may be included in a scope identifier within the policy object contained in the policy creation request. The A1 policy may further specify a first identifier (e.g., user ID). The A1 policy may explicitly request Near-RT RIC 3 to continue to maintain control over a particular UE while autonomously tracking or monitoring changes in the AMF UE NGAP ID.

[0090] In step 606, Near-RT RIC 3 manages the association between a first identifier (e.g., User ID) and a first type of UE identifier (AMF UE NGAP ID).

[0091] Steps 607 and 608 are the same as steps 506 and 507 in Figure 5. In step 609, Near-RT RIC 3 updates the association between the first identifier (e.g., user ID) and the first type of UE identifier (AMF UE NGAP ID) with the new value of the AMF UE NGAP ID. In step 610, Near-RT RIC 3 takes control of UE 6 identified by the new value of the AMF UE NGAP ID. In other words, Near-RT RIC 3 autonomously tracks or monitors changes in the AMF UE NGAP ID and promptly requests a new RAN node to take control of UE 6 in response to the change in the AMF UE NGAP ID.

[0092] As described with reference to Figure 6, Non-RT RIC 1 and Near-RT RIC 3 can identify a target UE based on user identification information (first identifier) ​​specified by an external server or entity such as application server 9, and can perform continuous control over that target UE.

[0093] <Second Embodiment> The configuration example of the wireless communication system according to this embodiment may be the same as the example shown in Figure 1 or Figure 2. This embodiment provides an example of operation performed by Non-RT RIC 1, Near-RT RIC 3, or a combination thereof.

[0094] Figure 7 shows an example of the operation of Non-RT RIC 1 and Near-RT RIC 3. In step 701, Non-RT RIC 1 sends or provides Near-RT RIC 3 with the first type of UE identifier for UE 6 assigned by the core network (e.g., 5GC 7). Non-RT RIC 1 may also send the first type of UE identifier over the A1 interface.

[0095] The first type of UE identifier may be assigned by the core network (e.g., 5GC 7 or EPC) on the control interface (e.g., N2 or NG-C interface) between the core network (e.g., 5GC 7 or EPC) and RAN 4. In other words, the first type of UE identifier may be assigned by the core network to identify UE 6 on the control interface between the core network and RAN 4. The first type of UE identifier may also be assigned by a control node (e.g., AMF or MME) located within the core network (e.g., 5GC 7 or EPC) that provides mobility management for UE 6. If the first type of UE identifier is obtained from 5GC 7, the first type of UE identifier may include an AMF UE NGAP ID, or may be a combination of an AMF UE NGAP ID and an AMF identifier. The AMF identifier may be all or part of GUAMI. If the first type of UE identifier is obtained from EPC, the first type of UE identifier may include an MME UE S1AP ID, or may be a combination of an MME UE S1AP ID and an MME identifier. The MME identifier may be all or part of GUMMEI.

[0096] As shown in Figure 7, Non-RT RIC 1 may request Near-RT RIC 3 to create or implement an A1 policy for UE 6 based on the AMF UE NGAP. In other words, Non-RT RIC 1 may request Near-RT RIC 3 to create or implement an A1 policy for UE 6 identified by the AMF UE NGAP. This policy creation request prompts Near-RT RIC 3 to request one or more RAN nodes to take control of UE 6 using a first-type UE identifier or a second-type UE identifier associated with a first-type UE identifier. In this case, the UE identifier included in the scope identifier within the A1 policy may be extended to indicate a first-type UE identifier (e.g., AMF UE NGAP ID and AMF identifier). Note that an A1 policy consists of a scope identifier and one or more policy statements. The scope identifier represents the target to which the policy statements apply (e.g., UEs, QoS flows, or cells). Policy statements express the goals of Near-RT RIC 3 and cover policy objectives and resources.

[0097] As described with reference to Figure 7, Non-RT RIC 1 can instruct Near-RT RIC 3 to use a UE identifier (e.g., AMF UE NGAP ID) assigned by the core network (e.g., 5GC 7) rather than RAN 4.

[0098] <Third Embodiment> The configuration example of the wireless communication system according to this embodiment may be the same as the example shown in Figure 1 or Figure 2. This embodiment provides an example of operation performed by Non-RT RIC 1, Near-RT RIC 3, or a combination thereof.

[0099] Figure 8 shows an example of the operation of Non-RT RIC 1 and Near-RT RIC 3. In step 801, Near-RT RIC 3 sends a notification to Non-RT RIC 1 indicating a change in the value of the first type UE identifier (e.g., AMF UE NGAP ID) of UE 6 assigned by the core network (e.g., 5GC 7). Near-RT RIC 3 may also send the notification over the A1 interface. The notification may show the changed value of the first type UE identifier. The notification may show the old value of the first type UE identifier before the change and the new value after the change.

[0100] The first type of UE identifier may be assigned by the core network (e.g., 5GC 7 or EPC) on the control interface (e.g., N2 or NG-C interface) between the core network (e.g., 5GC 7 or EPC) and RAN 4. In other words, the first type of UE identifier may be assigned by the core network to identify UE 6 on the control interface between the core network and RAN 4. The first type of UE identifier may also be assigned by a control node (e.g., AMF or MME) located within the core network (e.g., 5GC 7 or EPC) that provides mobility management for UE 6. If the first type of UE identifier is obtained from 5GC 7, the first type of UE identifier may include an AMF UE NGAP ID, or may be a combination of an AMF UE NGAP ID and an AMF identifier. The AMF identifier may be all or part of GUAMI. If the first type of UE identifier is obtained from EPC, the first type of UE identifier may include an MME UE S1AP ID, or may be a combination of an MME UE S1AP ID and an MME identifier. The MME identifier may be all or part of GUMMEI.

[0101] As shown in Figure 8, Near-RT RIC 3 may send a notification to Non-RT RIC 1 via policy feedback regarding the A1 policy indicating a change in the value of a first type UE identifier (e.g., AMF UE NGAP ID). The A1 policy feedback may be improved or extended to indicate the changed value of the first type identifier. Alternatively, the A1 policy feedback may be improved or extended to indicate the old value of the first type UE identifier before the change and the new value after the change.

[0102] In another example, Near-RT RIC 3 may send a notification to Non-RT RIC 1 indicating a change in the value of a Type 1 UE identifier in one or more new A1 policy procedures distinct from the feedback policy procedures. The newly defined procedures may include push-type procedures similar to the feedback policy procedures. Alternatively, the newly defined procedures may include pull-type procedures involving queries from Non-RT RIC 1 and responses from Near-RT RIC 3.

[0103] In response to receiving notification of a change in a Type 1 UE identifier via policy feedback or other procedures, Non-RT RIC 1 may, if necessary, send a request to Near-RT RIC 3 for an update to the A1 policy. The updated A1 policy may indicate the changed value of the Type 1 UE identifier and may indicate one or more policy statements relating to the UE 6 identified by the changed value. The updated A1 policy may prompt Near-RT RIC 3 to request RAN 4 to take control relating to the UE 6 identified by the changed value.

[0104] Based on notification of a change in the first type UE identifier via policy feedback or other procedures, Non-RT RIC 1 may track or monitor changes in the value of the first type UE identifier. In some implementations, based on such notification, Non-RT RIC 1 may keep up-to-date the association between the first type UE identifier and user identification information (first identifier) ​​specified by an external server or entity such as application server 9. Specific examples of the first identifier may be similar to those described in the first embodiment.

[0105] The operation in Figure 8 can be used in appropriate combination with the operation in Figure 7 as described in the second embodiment. Specifically, as described with reference to Figure 7, Non-RT RIC 1 may provide Near-RT RIC 3 with a first type UE identifier (e.g., AMF UE NGAP ID) by requesting Near-RT RIC 3 to create or implement an A1 policy defined using the first type UE identifier. Near-RT RIC 3 may then send a notification to Near-RT RIC 3 indicating a change in the value of the first type UE identifier via policy feedback regarding the A1 policy.

[0106] As described with reference to Figure 8, Near-RT RIC 3 can notify Non-RT RIC 1 of a change in the value of a UE identifier assigned by the core network (e.g., 5GC 7) rather than RAN 4. In particular, this notification may be sent over the A1 interface. Generally, information gathering on the A1 interface takes less time than information gathering on the O1 interface. Therefore, this allows Non-RT RIC 1 to become aware of changes in the value of a first type of UE identifier more quickly than when using the O1 interface.

[0107] Next, we will describe configuration examples of Non-RT RIC 1 and Near-RT RIC 3 according to the multiple embodiments described above. Figure 9 is a block diagram showing a configuration example of Non-RT RIC 1. Near-RT RIC 3 may also have a configuration similar to that shown in Figure 9.

[0108] In the example shown in Figure 9, Non-RT RIC 1 is implemented as a computer system. The computer system includes one or more processors 910, memory 920, and mass storage 930, which communicate with each other via a bus 970. The one or more processors 910 may include, for example, a Central Processing Unit (CPU) or a Graphics Processing Unit (GPU), or both. The computer system may also include other devices such as one or more output devices 940, one or more input devices 950, and one or more peripherals 960. The one or more peripherals 960 may include a modem or a network adapter, or any combination thereof.

[0109] One or both of the memory 920 and the mass storage 930 include a computer-readable medium storing one or more instruction sets. These instructions may be partially or completely located in the memory of one or more processors 910. When executed in one or more processors 910, these instructions cause one or more processors 910 to provide the Non-RT RIC 1 functionality described in the embodiments described above.

[0110] As illustrated with reference to Figure 9, each of the processors in Non-RT RIC 1 and Near-RT RIC 3 according to the above embodiment can execute one or more programs, each containing a set of instructions for causing a computer to perform the algorithms described with reference to the drawings. The program, when loaded into a computer, contains a set of instructions (or software code) for causing the computer to perform one or more of the functions described in the embodiment. The program may be stored on a non-temporary computer-readable medium or a physical storage medium. Examples, but not limited to, include random-access memory (RAM), read-only memory (ROM), flash memory, solid-state drive (SSD) or other memory technologies, CD-ROM, digital versatile disk (DVD), Blu-ray® disc or other optical disc storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage devices. The program may be transmitted over a temporary computer-readable medium or a communication medium. Examples, but not limited to, include temporary computer-readable medium or a communication medium containing electrical, optical, acoustic or other forms of propagating signals.

[0111] Furthermore, the embodiments described above are merely examples of how the technical concept obtained by the present inventor can be applied. In other words, the technical concept is not limited to the embodiments described above, and various modifications are certainly possible.

[0112] For example, some or all of the above embodiments may also be described as follows, but are not limited to the following.

[0113] (Note 1) A Radio Access Network (RAN) Intelligent Controller (RIC), At least one memory, At least one processor coupled to the at least one memory, Equipped with, The aforementioned at least one processor is Obtain the first identifier associated with User equipment (UE), Obtain a first type UE identifier corresponding to the first identifier from the core network, To cause one or more RAN nodes within a radio access network (RAN) to perform control over the aforementioned UE, the first type UE identifier or a second type UE identifier associated with the first type UE identifier is used. Structured in such a way RIC. (Note 2) The at least one processor is configured to track or monitor changes in the value of the first type of UE identifier based on notifications from the RAN. The RIC listed in Appendix 1. (Note 3) The at least one processor is configured to receive a notification from the RAN indicating a change in the value of the first type of UE identifier and to update the association between the first identifier and the first type of UE identifier. The RIC listed in Appendix 1. (Note 4) The aforementioned RIC includes an Open Radio Access Network (O-RAN) Non-Real-Time (Non-RT) RIC, The at least one processor is configured to receive notifications from the O-RAN Near-Real-Time (Near-RT) RIC via the A1 interface indicating a change in the value of the first type of UE identifier. The RIC as specified in Appendix 2 or 3. (Note 5) The at least one processor is configured to request the Near-RT RIC based on the first type of UE identifier to implement the policy relating to the UE. RIC as described in Appendix 4. (Note 6) The aforementioned at least one processor is By requesting the Near-RT RIC to create or implement an A1 policy defined using the first type of UE identifier, the first type of UE identifier is provided to the Near-RT RIC. The Near-RT RIC receives the notification indicating a change in the value of the first type UE identifier via feedback regarding the A1 policy. Structured in such a way RIC as described in Appendix 4. (Note 7) The at least one processor is configured to obtain the first identifier from an application server located outside the Non-RT RIC and the Near-RT RIC, via an external interface provided by the Non-RT RIC or by the Service Management and Orchestration (SMO) framework on which the Non-RT RIC is located. The RIC listed in any one of the appendices 4 to 6. (Note 8) The aforementioned at least one processor is The core network is requested to provide the first type of UE identifier using the first identifier or a second identifier associated with the first identifier. Configured to receive the first type of UE identifier from the core network, The RIC specified in any one of the appendices 4 to 7. (Note 9) The aforementioned second identifier includes a Subscription Permanent Identifier (SUPI), an International Mobile Subscriber Identity (IMSI), or a Generic Public Subscription Identifier (GPSI). RIC as described in Appendix 8. (Note 10) The aforementioned RIC includes an Open Radio Access Network (O-RAN) Near-Real-Time (Near-RT) RIC, The at least one processor is configured to receive the first type of UE identifier obtained by the O-RAN Non-Real-Time (Non-RT) RIC from the Non-RT RIC. The RIC as specified in Appendix 2 or 3. (Note 11) The aforementioned at least one processor is The first identifier is obtained from an application server located outside the Non-RT RIC and the Near-RT RIC. The Non-RT RIC is requested to provide the first type of UE identifier corresponding to the first identifier. Structured in such a way The RIC listed in Appendix 10. (Note 12) The aforementioned at least one processor is The first identifier is sent to the Non-RT RIC via a request to create or execute an A1 enrichment information job indicating the first identifier. Using a delivery procedure for providing the results of the A1 enrichment information job, the first type of UE identifier is received from the Non-RT RIC. Structured in such a way The RIC listed in Appendix 11. (Note 13) The first type of UE identifier is assigned by the core network, The RIC specified in any one of the appendices 1 to 12. (Note 14) The first type of UE identifier is assigned by the core network on the control interface between the core network and the RAN. The RIC specified in any one of the appendices 1 to 13. (Note 15) The first type of UE identifier is assigned by a control node located within the core network and providing mobility management for the UE. The RIC listed in any one of the appendices 1 to 14. (Note 16) The control node is an Access and Mobility Management Function (AMF) or a Mobility Management Entity (MME). RIC as described in Appendix 15. (Note 17) The aforementioned first type of UE identifier includes an Access and Mobility Management Function (AMF) UE NG Application Protocol (NGAP) ID or a Mobility Management Entity (MME) UE S1 Application Protocol (S1AP) ID, The RIC specified in any one of the appendices 1 to 16. (Note 18) The second type of UE identifier is the UE identifier used when Central Unit (CU)-Distributed Unit (DU) isolation is applied to a RAN node, the UE identifier used when Control Plane (CP)-User Plane (UP) isolation is applied to a RAN node, or the UE identifier used when Dual Connectivity is set up. The RIC specified in any one of the appendices 1 to 17. (Note 19) The first identifier includes an identifier for identifying a machine, vehicle, or device that utilizes or implements the UE. The RIC specified in any one of the appendices 1 to 18. (Note 20) The first identifier includes an identifier for identifying a user or application that uses the UE. The RIC specified in any one of the appendices 1 to 18. (Note 21) The first identifier includes an Internet Protocol (IP) address for identifying the packet forwarding service, Protocol Data Unit (PDU) Session, or Packet Data Network (PDN) Connection used by the UE. The RIC specified in any one of the appendices 1 to 18. (Note 22) A method performed by a Radio Access Network (RAN) Intelligent Controller (RIC), To obtain the first identifier associated with User equipment (UE), Obtaining a first type UE identifier corresponding to the first identifier from the core network, and To have one or more RAN nodes within a radio access network (RAN) perform control over the aforementioned UE, use the first type UE identifier or a second type UE identifier associated with the first type UE identifier. A method for providing this. (Note 23) A program for causing a computer to perform methods for a Radio Access Network (RAN) Intelligent Controller (RIC), The aforementioned method, To obtain the first identifier associated with User equipment (UE), Obtaining a first type UE identifier corresponding to the first identifier from the core network, and To have one or more RAN nodes within a radio access network (RAN) perform control over the aforementioned UE, use the first type UE identifier or a second type UE identifier associated with the first type UE identifier. A program that includes the following features. (Note 24) The first Radio Access Network (RAN) Intelligent Controller (RIC) is, At least one memory, At least one processor coupled to the at least one memory, Equipped with, The at least one processor is configured to transmit a first type of UE identifier of User equipment (UE) assigned by the core network to a second RIC located between the first RIC and the radio access network (RAN). The first RIC. (Note 25) The at least one processor is configured to send the first type of UE identifier to the second RIC on the A1 interface. The first RIC as described in Appendix 24. (Note 26) The first type of UE identifier is assigned by the core network on the control interface between the core network and the RAN. The first RIC as described in Appendix 24 or 25. (Note 27) The first type of UE identifier is assigned by a control node located within the core network and providing mobility management for the UE. The first RIC as described in any one of the appendices 24 to 26. (Note 28) The control node is an Access and Mobility Management Function (AMF) or a Mobility Management Entity (MME). The first RIC described in Appendix 27. (Note 29) The aforementioned first type of UE identifier includes an Access and Mobility Management Function (AMF) UE NG Application Protocol (NGAP) ID or a Mobility Management Entity (MME) UE S1 Application Protocol (S1AP) ID. The first RIC as described in any one of the appendices 24-28. (Note 30) The at least one processor is configured to receive a notification from the second RIC indicating a change in the value of the first type of UE identifier. The first RIC as described in any one of the appendices 24 to 29. (Note 31) The at least one processor is configured to track or monitor changes in the value of the first type of UE identifier based on the notification. The first RIC as described in Appendix 30. (Note 32) The at least one processor is configured to update the association between the first type of UE identifier and the first identifier associated with the UE. The first RIC as described in Appendix 30 or 31. (Note 33) The aforementioned notification indicates the changed new value of the first type UE identifier, The first RIC as described in any one of the appendices 30 to 32. (Note 34) The notification shows the old value of the UE identifier of the first type before the change and the new value after the change. The first RIC as described in any one of the appendices 30 to 32. (Note 35) The at least one processor is configured to request the second RIC based on the first type of UE identifier to implement the policy relating to the UE. The first RIC as described in any one of the items 24 to 34 of the appendix. (Note 36) The request causes the second RIC to request one or more RAN nodes to perform control over the UE using the first type UE identifier or a second type UE identifier associated with the first type UE identifier. The first RIC as described in Appendix 35. (Note 37) The aforementioned at least one processor is The first type of UE identifier is provided to the second RIC by requesting the second RIC to create or implement an A1 policy defined using the first type of UE identifier. Through feedback regarding the A1 policy, the notification indicating a change in the value of the first type of UE identifier is received from the second RIC. Structured in such a way The first RIC as described in any one of the appendices 30 to 34. (Note 38) The at least one processor is configured to request the second RIC to update the A1 policy based on the feedback. The first RIC as described in Appendix 37. (Note 39) The first RIC mentioned above is an Open Radio Access Network (O-RAN) Non-Real-Time (Non-RT) RIC, The second RIC is an O-RAN Near-Real-Time (Near-RT) RIC. The first RIC as described in any one of the appendices 24 to 38. (Note 40) A method performed by a first Radio Access Network (RAN) Intelligent Controller (RIC), The system provides a second RIC, located between the first RIC and the radio access network (RAN), with a first type of UE identifier for User equipment (UE) assigned by the core network. method. (Note 41) A program for causing a computer to perform a method for a first Radio Access Network (RAN) Intelligent Controller (RIC), The method comprises providing a second RIC located between the first RIC and the radio access network (RAN) with a first type of UE identifier for user equipment (UE) assigned by the core network. program. (Note 42) A second Radio Access Network (RAN) Intelligent Controller (RIC) is located between the first RIC and the Radio Access Network (RAN), At least one memory, At least one processor coupled to the at least one memory, Equipped with, The at least one processor is configured to receive a first type of UE identifier for User equipment (UE) assigned by the core network from the first RIC. The second RIC. (Note 43) The at least one processor is configured to receive the first type of UE identifier from the first RIC on the A1 interface. The second RIC as described in Appendix 42. (Note 44) The first type of UE identifier is assigned by the core network on the control interface between the core network and the RAN. The second RIC as described in Appendix 42 or 43. (Note 45) The first type of UE identifier is assigned by a control node located within the core network and providing mobility management for the UE. The second RIC as described in any one of the appendices 42 to 44. (Note 46) The control node is an Access and Mobility Management Function (AMF) or a Mobility Management Entity (MME). The second RIC as described in Appendix 45. (Note 47) The aforementioned first type of UE identifier includes an Access and Mobility Management Function (AMF) UE NG Application Protocol (NGAP) ID or a Mobility Management Entity (MME) UE S1 Application Protocol (S1AP) ID. The second RIC as described in any one of the appendices 42 to 46. (Note 48) The at least one processor is configured to send a notification to the first RIC indicating a change in the value of the first type of UE identifier. The second RIC as described in any one of the appendices 42 to 47. (Note 49) The notification enables the first RIC to track or monitor changes in the value of the first type of UE identifier. The second RIC as described in Appendix 48. (Note 50) The notification enables the first RIC to update the association between the first type of UE identifier and the first identifier associated with the UE. The second RIC as described in Appendix 48 or 49. (Note 51) The aforementioned notification indicates the changed new value of the first type UE identifier, The second RIC as described in any one of the appendices 48-50. (Note 52) The notification shows the old value of the UE identifier of the first type before the change and the new value after the change. The second RIC as described in any one of the appendices 48-50. (Note 53) The aforementioned at least one processor is The first type of UE identifier is received from the first RIC via a request to create or implement an A1 policy defined using the first type of UE identifier, Through feedback regarding the A1 policy, the notification indicating a change in the value of the first type of UE identifier is sent to the first RIC. Structured in such a way The second RIC as described in any one of the appendices 48 to 52. (Note 54) The at least one processor is configured to receive a request from the first RIC for updating the A1 policy based on the feedback. The second RIC as described in Appendix 53. (Note 55) A method performed by a second Radio Access Network (RAN) Intelligent Controller (RIC) positioned between a first RIC and a radio access network (RAN), The system includes receiving a first type of UE identifier for User equipment (UE) assigned by the core network from the first RIC, method. (Note 56) A program for causing a computer to perform a method for a second Radio Access Network (RAN) Intelligent Controller (RIC) to be positioned between a first RIC and a Radio Access Network (RAN), The method comprises receiving a first type of UE identifier for User equipment (UE) assigned by the core network from the first RIC. program. (Note 57) The first Radio Access Network (RAN) Intelligent Controller (RIC) is, At least one memory, At least one processor coupled to the at least one memory, Equipped with, The at least one processor is configured to receive a notification from a second RIC located between the first RIC and the radio access network (RAN) indicating a change in the value of a first type of UE identifier for User equipment (UE) assigned by the core network. The first RIC. (Note 58) The at least one processor is configured to receive the notification from the second RIC on the A1 interface. The first RIC as described in Appendix 57. (Note 59) The aforementioned notification indicates the changed value of the first type UE identifier, The first RIC as described in Appendix 57 or 58. (Note 60) The notification shows the old value of the UE identifier of the first type before the change and the new value after the change. The first RIC as described in Appendix 57 or 58. (Note 61) The first type of UE identifier is assigned by the core network on the control interface between the core network and the RAN. The first RIC as described in any one of the appendices 57-60. (Note 62) The first type of UE identifier is assigned by a control node located within the core network and providing mobility management for the UE. The first RIC as described in any one of the appendices 57 to 61. (Note 63) The control node is an Access and Mobility Management Function (AMF) or a Mobility Management Entity (MME). The first RIC as described in Appendix 62. (Note 64) The aforementioned first type of UE identifier includes an Access and Mobility Management Function (AMF) UE NG Application Protocol (NGAP) ID or a Mobility Management Entity (MME) UE S1 Application Protocol (S1AP) ID. The first RIC as described in any one of the appendices 57-63. (Note 65) The aforementioned at least one processor is The first type of UE identifier is provided to the second RIC by requesting the second RIC to create or implement an A1 policy defined using the first type of UE identifier. Through feedback regarding the A1 policy, the notification indicating a change in the value of the first type of UE identifier is received from the second RIC. Structured in such a way The first RIC as described in any one of the appendices 57-64. (Note 66) The at least one processor is configured to track or monitor changes in the value of the first type of UE identifier based on the notification. The first RIC as described in any one of the appendices 57-65. (Note 67) The at least one processor is configured to update the association between the first type of UE identifier and the first identifier associated with the UE. The first RIC as described in any one of the appendices 57 to 66. (Note 68) The first identifier includes an identifier for identifying a machine, vehicle, or device that utilizes or implements the UE. The first RIC as described in Appendix 67. (Note 69) The first identifier includes an identifier for identifying a user or application that uses the UE. The first RIC as described in Appendix 67. (Note 70) The first identifier includes an Internet Protocol (IP) address for identifying the packet forwarding service, Protocol Data Unit (PDU) Session, or Packet Data Network (PDN) Connection used by the UE. The first RIC as described in Appendix 67. (Note 71) A method performed by a first Radio Access Network (RAN) Intelligent Controller (RIC), The system includes receiving notifications from a second RIC located between the first RIC and the radio access network (RAN) indicating a change in the value of a first type of UE identifier for User equipment (UE) assigned by the core network, method. (Note 72) A program for causing a computer to perform a method for a first Radio Access Network (RAN) Intelligent Controller (RIC), The method comprises receiving a notification from a second RIC located between the first RIC and the radio access network (RAN) indicating a change in the value of a first type of UE identifier for User equipment (UE) assigned by the core network. program. (Note 73) A second Radio Access Network (RAN) Intelligent Controller (RIC) is located between the first RIC and the Radio Access Network (RAN), At least one memory, At least one processor coupled to the at least one memory, Equipped with, The at least one processor is configured to send a notification to the first RIC indicating a change in the value of a first type of UE identifier of User equipment (UE) assigned by the core network. The second RIC. (Note 74) The at least one processor is configured to send the notification to the first RIC on the A1 interface. The second RIC as described in Appendix 73. (Note 75) The aforementioned notification indicates the changed value of the first type UE identifier, The second RIC as described in Appendix 73 or 74. (Note 76) The notification shows the old value of the UE identifier of the first type before the change and the new value after the change. The second RIC as described in Appendix 73 or 74. (Note 77) The first type of UE identifier is assigned by the core network on the control interface between the core network and the RAN. The second RIC as described in any one of the appendices 73 to 76. (Note 78) The first type of UE identifier is assigned by a control node located within the core network and providing mobility management for the UE. The second RIC as specified in any one of the appendices 73 to 76. (Note 79) The control node is an Access and Mobility Management Function (AMF) or a Mobility Management Entity (MME). The second RIC as described in Appendix 78. (Note 80) The aforementioned first type of UE identifier includes an Access and Mobility Management Function (AMF) UE NG Application Protocol (NGAP) ID or a Mobility Management Entity (MME) UE S1 Application Protocol (S1AP) ID. The second RIC as specified in any one of the appendices 73 to 79. (Note 81) The aforementioned at least one processor is The first type of UE identifier is received from the first RIC via a request to create or implement an A1 policy defined using the first type of UE identifier, Through feedback regarding the A1 policy, the notification indicating a change in the value of the first type of UE identifier is sent to the first RIC. Structured in such a way The second RIC as described in any one of the appendices 73 to 80. (Note 82) A method performed by a second Radio Access Network (RAN) Intelligent Controller (RIC) positioned between a first RIC and a radio access network (RAN), The system includes sending a notification to the first RIC indicating a change in the value of a first type of UE identifier for User equipment (UE) assigned by the core network, method. (Note 83) A program for causing a computer to perform a method for a second Radio Access Network (RAN) Intelligent Controller (RIC) to be positioned between a first RIC and a Radio Access Network (RAN), The method comprises sending a notification to the first RIC indicating a change in the value of a first type of UE identifier for User equipment (UE) assigned by the core network. program.

[0114] This application claims priority based on Japanese Patent Application No. 2022-128679, filed on 12 August 2022, and incorporates all of its disclosures herein. [Explanation of Symbols]

[0115] 1 Non-RT RIC 2. SMO Framework 3. Near-RT RIC 4 RAN 5 gNB 6 UE 7 5GC 9. Application Server 910 Processor 920 memory 930 Mass Storage

Claims

1. A Radio Access Network (RAN) Intelligent Controller (RIC), Means for obtaining a first identifier associated with User equipment (UE), Means for obtaining a first type UE identifier from the core network that corresponds to the first identifier and is of a different type from the first identifier, Means for using the first type of UE identifier or a second type of UE identifier associated with the first type of UE identifier, in order to cause one or more RAN nodes in the radio access network (RAN) to perform control over the UE, Equipped with, RIC.

2. The aforementioned RIC includes an Open Radio Access Network (O-RAN) Non-Real-Time (Non-RT) RIC, The system further includes means for receiving notifications from an O-RAN Near-Real-Time (Near-RT) RIC via an A1 interface indicating a change in the value of the first type of UE identifier. The RIC according to claim 1.

3. The system further provides means for providing the Near-RT RIC with the first type of UE identifier by requesting the Near-RT RIC to create or implement an A1 policy defined using the first type of UE identifier, The receiving means is configured to receive the notification from the Near-RT RIC indicating a change in the value of the first type UE identifier via feedback relating to the A1 policy. The RIC according to claim 2.

4. The means for obtaining the first identifier is configured to obtain the first identifier from an application server located outside the Non-RT RIC and the Near-RT RIC, via an external interface provided by the Non-RT RIC or by the Service Management and Orchestration (SMO) framework on which the Non-RT RIC is located. The RIC according to claim 2 or 3.

5. The first identifier is, (a) an identifier for identifying a machine, vehicle, or device that utilizes or on which the UE is implemented. (b) an identifier for identifying a user or application using the UE, (c) Identifier of an application running on the processor of the UE, (d) Identifier of an application running on the processor of a machine, vehicle, or device coupled to the UE, (e) Internet Protocol (IP) addresses for identifying the packet forwarding service, Protocol Data Unit (PDU) Session, or Packet Data Network (PDN) Connection used by the UE, Including at least one of the following: The RIC according to any one of claims 1 to 3.

6. The first type of UE identifier includes, at least as part, an identifier assigned by the core network, The first identifier does not include the identifier assigned by the core network. The RIC according to any one of claims 1 to 3.

7. The first Radio Access Network (RAN) Intelligent Controller (RIC) is, Means for transmitting a first type of UE identifier of User equipment (UE) assigned by the core network to a second RIC located between the first RIC and the radio access network (RAN), Means for receiving a notification from the second RIC indicating a change in the value of the first type of UE identifier, Equipped with, The transmitting means is configured to provide the first type of UE identifier to the second RIC by requesting the second RIC to create or implement an A1 policy defined using the first type of UE identifier, The receiving means is configured to receive the notification from the second RIC indicating a change in the value of the first type of UE identifier via feedback relating to the A1 policy. The first RIC.

8. A second Radio Access Network (RAN) Intelligent Controller (RIC) is located between the first RIC and the Radio Access Network (RAN), Means for receiving a first type of UE identifier for User equipment (UE) assigned by the core network from the first RIC, Means for sending a notification to the first RIC indicating a change in the value of the first type of UE identifier, Equipped with, The receiving means is configured to receive the first type of UE identifier from the first RIC via a request to create or implement an A1 policy defined using the first type of UE identifier. The sending means is configured to send the notification indicating a change in the value of the first type of UE identifier to the first RIC via feedback relating to the A1 policy. The second RIC.

9. The receiving means is configured to receive the first type of UE identifier from the first RIC on the A1 interface. The second RIC according to claim 8.

10. The system further includes means for receiving a request from the first RIC for updating the A1 policy based on the aforementioned feedback. The second RIC according to claim 8 or 9.

Images