Communication control device

Abstract

According to the disclosed technology, provided are a configuration and a method for appropriately controlling a policy related to radio access network communication. This communication control device controls, for a communication device that operates on the basis of a policy, implementation of the policy in the communication device. The communication control device comprises a conflict determination unit and a control unit. When a first policy is implemented in the communication device, in response to receiving a policy request requesting that a second policy be implemented in the communication device, the conflict determination unit determines whether the first policy and the second policy conflict with each other. The control unit controls implementation of the first policy and the second policy in the communication device on the basis of the determination result by the conflict determination unit.

Description

communication control device

[0001] The present invention relates to a communication control device, a communication system, and a communication control method for wireless communication.

[0002] Standardization organizations such as 3GPP (registered trademark) (3rd Generation Partnership Project) and the O-RAN (Open RAN) Alliance are working on standardization of radio access networks (RANs). O-RAN also provides an O-RAN architecture based on 3GPP specifications and incorporating a RAN Intelligent Controller (RIC).

[0003] A policy for controlling communications is set in a base station based on the O-RAN architecture. For example, the A1 policy specifies the quality of service (QoS), the user's quality of experience (QoE), and the power consumption value that a communication device (e.g., a radio unit of a base station) should achieve. The base station then controls communications based on this A1 policy. The A1 policy is described in, for example, the following non-patent documents 1 and 2.

[0004] O-RAN.WG2.A1GAP-R003-v04.00O-RAN.WG2.A1TD-R003-v07.00

[0005] As described above, communication can be controlled using A1 policies. However, if multiple different A1 policies are generated for a common resource, policy conflicts may occur, resulting in unexpected behavior. To date, no specific standards have been proposed for how to handle the situation when multiple different A1 policies are generated for a common RAN resource.

[0006] An object of one aspect of the present invention is to provide a configuration and method for appropriately controlling policies related to communications in a radio access network.

[0007] A communication control device according to one aspect of the present invention is a communication device that operates based on a policy, and controls implementation of the policy in the communication device. The communication control device includes: a conflict determination unit that, in response to receiving a policy request requesting implementation of a second policy in the communication device when a first policy is implemented in the communication device, determines whether the first policy and the second policy conflict with each other; and a control unit that controls implementation of the first policy and the second policy in the communication device based on a result of the determination by the conflict determination unit.

[0008] According to the above-described aspect, policies relating to communications in a radio access network can be appropriately controlled.

[0009] 1 is a diagram showing an example of the functional configuration of a base station based on O-RAN architecture. FIG. 1 is a diagram showing an example of a hierarchical structure of contexts in O-RAN. FIG. 2 is a diagram showing an example of the structure of an A1 policy. FIG. 3 is a diagram showing types of A1 policies defined in O-RAN. FIG. 4 is a diagram explaining targets to which an A1 policy is applied. FIG. 5 is a diagram showing an example of a communication system according to a first embodiment. FIG. 6 is a flowchart showing an example of a communication control method according to the first embodiment. FIG. 7 is a diagram showing an example of a method for determining a conflict between A1 policies. FIG. 8 is a diagram showing an example of a classification of policy types for determining a conflict between A1 policies. FIG. 9 is a flowchart showing an example of a process for detecting a conflict between policies. FIG. 10 is a diagram showing an example of a relationship between traffic load and policy priority. FIG. 11 is a diagram showing an example of resource priority ownership authority for each policy. FIG. 12 is a flowchart showing an example of a process for determining priority between policies. FIG. 13 is a flowchart showing an example of a method for processing an A1 policy according to a result of conflict determination. FIG. 14 is a diagram showing an example of a communication system according to a second embodiment. FIG. 15 is a flowchart showing an example of a method for processing an A1 policy according to a result of conflict determination in the second embodiment. FIG. 16 is a diagram showing a first example of communication control based on an A1 policy. FIG. 17 is a diagram showing an operation sequence in the first example. FIG. 18 is a diagram showing the contents of a policy generated in the first example. Fig. 1 is a diagram showing a second embodiment of communication control based on the A1 policy. Fig. 2 is a diagram showing an operation sequence in the second embodiment. Fig. 3 is a diagram showing a third embodiment of communication control based on the A1 policy. Fig. 4 is a diagram showing an operation sequence in the third embodiment. Fig. 5 is a diagram showing an example of the hardware configuration of a non-real-time RIC framework that operates as a communication control device.

[0010] 1 shows an example of the functional configuration of a base station based on the O-RAN architecture. In the example shown in Fig. 1, the base station includes a Service Management Orchestration (SMO) 10, an E2 node 22, and an O-RU 23.

[0011] The SMO 10 is an example of a communication management device, and manages each device or function in the O-RAN architecture. The SMO 10 is connected to the E2 node 22 and the O-RU 23 via an O1 interface. The SMO 10 is also connected to the O-RU 23 via an Open Fronthaul interface. The SMO 10 can collect configuration information and statistical information (including information representing traffic load) of the radio access network via the O1 interface or the Open Fronthaul interface. The SMO 10 can also send instructions to change the configuration of the E2 node 22 via the O1 interface. The SMO 10 can also control the operation of the O-RU 23 via the Open Fronthaul interface.

[0012] The O-RAN architecture includes a RAN Intelligent Controller (RIC). The RIC provides services to each device or function within the O-RAN architecture. The RIC includes a non-real-time RIC 11 and a near-real-time RIC 21. The non-real-time RIC 11 is implemented inside the SMO 10, and the real-time RIC 21 is provided outside the SMO 10. The non-real-time RIC 11 and the real-time RIC 21 are connected via an A1 interface. The A1 interface includes A1-P and A1-EI.

[0013] The non-real-time RIC 11 collects various data from the E2 node 22 via the O1 interface. For example, PM counters (Performance Management counters), FM data (Fault Management data), and TM data (Trace Management data) are collected from the E2 node 22. The non-real-time RIC 11 also determines optimal parameters based on the radio environment and traffic demand using the AI / ML model, and provides the optimal parameters to the E2 node via the O1 interface. The non-real-time RIC 11 also generates policies related to the control of the radio access network, and notifies the real-time RIC 21 of the policies via the A1 interface. In the following description, an application program running on the non-real-time RIC 11 may be referred to as "rApp."

[0014] The real-time RIC 21 collects and analyzes configuration information and statistical information of the radio access network from the E2 node 22 via the E2 interface. The real-time RIC 21 also controls the E2 node in accordance with a policy notified by the non-real-time RIC 11. In the following description, an application program running on the real-time RIC 21 may be referred to as an "xApp."

[0015] The E2 node 22 includes an O-CU and an O-DU. The E2 node 22 provides radio link control, medium access control, PHY-High functions, and the like, and processes signals from the O-RU 23 in higher layers. Note that multiple O-RUs 23 can be connected to the O-DU. The E2 node 22 may also acquire configuration information and statistical information of the radio access network and provide the information to the real-time RIC 21.

[0016] The O-RU 23 has a radio circuit and can accommodate multiple terminals UE. The O-RU 23 connects to the SMO 10 via the O1 interface or the M plane of the Open fronthaul interface. The O-RU 23 also performs radio communication according to instructions given from the E2 node 22 (here, the O-DU).

[0017] The A1 interface connects the non-real-time RIC 11 and the real-time RIC 21. The E2 interface connects the real-time RIC 21 and the E2 node 22. The R1 interface connects the non-real-time RIC framework 12 and the rApp.

[0018] Figure 2 shows an example of the hierarchical structure of contexts in an O-RAN. In an O-RAN, solutions for various use cases are realized by transferring contexts between each functional block in the O-RAN architecture. In the O-RAN architecture, contexts such as Intent, A1 policy, and E2SM IE / objects are used to generate contexts in each functional block and to transfer control and guidance to lower layers.

[0019] Intents are generated by a CSC (Communication Service Customer) or rApp and implemented in the rApp. A1 policies related to Intents are generated by the rApp and implemented in the xApp. E2SM IEs / objects related to A1 policies are generated by the xApp and implemented in the E2 node.

[0020] FIG. 3 shows an example of the structure of an A1 policy. The A1 policy information representing the A1 policy consists of scope identifier and policy statement(s). The scope identifier indicates the target to which the A1 policy should be applied (i.e., cell, QoS, slice, group, UE). The policy statement includes policy objective and resource information, and indicates the policy content related to the operation of the base station. The objective / target value indicates the target value for performance. The resource information indicates the policy application method (preference [PREFER / AVOID / SHALL / FORBID], primary), etc. The structure of the A1 policy is described in 5.1.4 of Non-Patent Document 1. In the following description, the A1 policy information representing the A1 policy may be simply referred to as "A1 policy" or "policy."

[0021] Figure 4 shows the types of A1 policies defined in O-RAN. A1 policies are defined for each use case and specified by the A1 policy type. Currently, nine policy types are defined. For example, policy type #1 specifies the quality parameters (policy objective target) to be achieved for QoS. The types of A1 policies are described in 7.2 of Non-Patent Document 2.

[0022] Figure 5 shows the target of application of the A1 policy. The target of application of the A1 policy is specified by one or a combination of five elements (ueID, groupID, sliceID, qosID, cellID). The method of specifying each element is defined for each A1 policy type. The target of application of the A1 policy is described in 7.2 of Non-Patent Document 2.

[0023] <First Embodiment> Fig. 6 shows an example of a communication system according to the first embodiment. As shown in Fig. 6, the communication system 1 according to the first embodiment includes a non-real-time RIC framework 12, a real-time RIC 21, and an E2 node 22. The non-real-time RIC framework 12 is implemented in the SMO 10 as shown in Fig. 1. The real-time RIC 21 connects to the non-real-time RIC framework 12 via an A1 interface as shown in Fig. 1. The E2 node 22 connects to the real-time RIC 21 via an E2 interface and also connects to the non-real-time RIC framework 12 via an O1 interface as shown in Fig. 1. The communication system 1 further includes an O-RU 23 as shown in Fig. 1.

[0024] The non-real-time RIC framework 12 includes an R1 termination unit 31, an A1-related function unit 32, an A1 termination unit 33, an O1 termination unit 34, and an O1-related function unit 35. The R1 termination unit 31 provides an interface with the rApp. That is, the R1 termination unit 31 accepts requests from the rApp. The R1 termination unit 31 can also send processing results of the non-real-time RIC framework 12 to the rApp. The A1-related function unit 32 executes processing related to an A1 policy generated by the rApp. For example, when an A1 policy generated by the rApp can be implemented in the corresponding xApp, the A1-related function unit 32 sends the A1 policy to the real-time RIC 21. The A1 termination unit 33 provides an interface with the real-time RIC 21. That is, the A1 termination unit 33 can send instructions generated by the A1-related function unit 32 to the real-time RIC 21. The A1 termination unit 33 also receives a response sent from the real-time RIC 21. The O1-related function unit 35 can collect radio access network statistical information (e.g., information representing traffic load) from the E2 node 22 via the O1 termination unit 34.

[0025] The non-real-time RIC framework 12 further includes a conflict detection R1 service provider 36. The conflict detection R1 service provider 36 provides services related to A1 policy conflicts to rApps connected to the R1 termination unit 31. Therefore, the conflict detection R1 service provider 36 operates as an A1 policy conflict detection R1 service provider to the rApp that generates the A1 policy. In this case, the rApp operates as an A1 policy conflict detection R1 service consumer. The rApp can send requests related to the creation / update / deletion of A1 policies to the non-real-time RIC framework 12 via the R1 interface depending on various use cases.

[0026] The conflict detection R1 service providing unit 36 ​​is not particularly limited, but may be realized, for example, as an additional function of the A1-related function unit 32. The conflict detection R1 service providing unit 36 ​​can also collect information related to the traffic load of cells via the O1 interface. The conflict detection R1 service providing unit 36 ​​further includes a policy information storage unit 37 and a conflict determination unit 38.

[0027] The policy information storage unit 37 manages the A1 policies that are normally implemented (enforced) in the real-time RIC 21. That is, policy information related to the A1 policies implemented in the real-time RIC 21 is stored in the policy information storage unit 37. The conflict determination unit 38 references the policy information storage unit 37 and detects conflicts between A1 policies. For example, assume that a new A1 policy is generated when an A1 policy (hereinafter, "implemented A1 policy") in the real-time RIC 21 is implemented. In this case, the conflict determination unit 38 determines whether there is a conflict between the implemented A1 policy and the new A1 policy. Note that "conflict" refers to a state in which it is undesirable or impossible for multiple A1 policies to be implemented simultaneously.

[0028] Then, the non-real-time RIC framework 12 (mainly the A1-related function unit 32) processes the A1 policy in accordance with the determination result by the conflict determination unit 38. At this time, the non-real-time RIC framework 12 requests the real-time RIC 21 to generate / update / delete the A1 policy via the A1 interface. The non-real-time RIC framework 12 also notifies the rApp of the determination result via the R1 interface.

[0029] Next, an outline of the operation of the communication system 1 when a new A1 policy is generated will be described. Here, it is assumed that policy #1 generated by rApp #1 is implemented in the real-time RIC 21 in FIG.

[0030] Step P0: The contention determination unit 38 constantly or periodically monitors the traffic load of the base station. At this time, the contention determination unit 38 may monitor the traffic load for each cell. Note that the contention determination unit 38 is assumed to be able to obtain information indicating the traffic load from the E2 node 22.

[0031] Step P1: rApp#2 generates policy #2. Then, rApp#2 sends a policy creation request related to policy #2 to the non-real-time RIC framework 12. This policy creation request requests that policy #2 be implemented in the real-time RIC 21. In other words, this policy creation request is essentially a policy implementation request. The policy creation request is sent from rApp#2 to the non-real-time RIC framework 12 via the R1 interface.

[0032] Step P2: When the non-real-time RIC framework 12 receives a policy generation request from rApp#2, the A1-related function unit 32 transmits a conflict check request to the conflict determination unit 38. This conflict check request requests the conflict determination unit 38 to determine whether or not policy#2 conflicts with another A1 policy.

[0033] Steps P3 to P4: The conflict determination unit 38 detects the A1 policy that is actually implemented in the real-time RIC 21 by referring to the policy information storage unit 37. In this embodiment, the real-time RIC 21 implements policy #1.

[0034] Step P5: The conflict determination unit 38 determines whether or not there is a conflict between the A1 policy (i.e., policy #1) actually implemented in the real-time RIC 21 and the newly generated A1 policy (i.e., policy #2). The conflict determination unit 38 then notifies the A1-related function unit 32 of the determination result.

[0035] Step P6: The A1-related functional unit 32 notifies the rApp of the determination result by the conflict determination unit 38. At this time, the determination result by the conflict determination unit 38 is notified to rApp#2 as a response to the request of step P1. Furthermore, the determination result by the conflict determination unit 38 is notified to rApp#1 as needed. Furthermore, the A1-related functional unit 32 provides instructions to the real-time RIC 21 corresponding to the determination result by the conflict determination unit 38 as needed.

[0036] Step P7: When an instruction is received from the A1-related function unit 32 in step P6, the real-time RIC 21 transmits a response to the non-real-time RIC framework 12. This response includes information indicating whether the instructed A1 policy has been implemented.

[0037] Step P8: The A1-related function unit 32 updates the policy information storage unit 37 based on the response from the real-time RIC 21. Therefore, the policy information storage unit 37 stores information indicating the latest state of the A1 policy in the real-time RIC 21.

[0038] Step P9: Based on the response from the real-time RIC 21, the A1-related function unit 32 notifies the rApp (#1 and / or #2) of the state of the A1 policy in the real-time RIC 21.

[0039] In this way, when a new A1 policy is generated in the communication system 1, it is determined whether or not the new A1 policy conflicts with an already implemented A1 policy. Then, depending on the result of the determination, the implementation of the A1 policy is processed. Therefore, since A1 policy conflicts do not occur, unexpected operations in the communication system can be avoided.

[0040] 7 is a flowchart showing an example of a communication control method according to the first embodiment. In this example, it is assumed that policy #1 generated by rApp #1 is implemented in the real-time RIC 21. Furthermore, rApp #2 generates a new A1 policy (policy #2). Then, rApp #2 transmits a policy generation request related to policy #2 to the non-real-time RIC framework 12. This policy generation request includes policy #2 and requests that policy #2 be implemented in the real-time RIC 21. Furthermore, this policy generation request is sent to the non-real-time RIC framework 12 via the R1 interface.

[0041] In S1, the A1-related functional unit 32 receives a policy generation request related to policy #2 via the R1 interface. In S2, the A1-related functional unit 32 requests the conflict determination unit 38 to determine whether policy #2 can be implemented in the real-time RIC 21. That is, the A1-related functional unit 32 requests the conflict determination unit 38 to determine whether policy #2 conflicts with other A1 policies.

[0042] In S3, the conflict determination unit 38 searches for the A1 policy implemented in the real-time RIC 21 by referring to the policy information storage unit 37. In this embodiment, the real-time RIC 21 implements policy #1.

[0043] In S4, the conflict determination unit 38 determines whether the newly generated A1 policy (i.e., policy #2) conflicts with the A1 policy (i.e., policy #1) implemented in the real-time RIC 21. If policy #1 and policy #2 conflict with each other, the conflict determination unit 38 performs priority determination for policy #1 and policy #2 in S5. Then, in S6, the conflict determination unit 38 notifies the A1-related function unit 32 of the determination results of S4 to S5. The determination methods related to S4 to S5 will be described later.

[0044] In S7, the A1-related function unit 32 processes policy #2 based on the determination result by the conflict determination unit 38. For example, when policy #1 and policy #2 do not conflict with each other, the A1-related function unit 32 implements policy #2 in the real-time RIC 21. In this case, the real-time RIC 21 controls communication of the base station based on both policy #1 and policy #2. Furthermore, when policy #1 and policy #2 conflict with each other, the A1 policy with the higher priority is implemented in the real-time RIC 21. The processing of S7 will also be described later.

[0045] FIG. 8 shows an example of a method for determining conflicts between A1 policies. In this embodiment, conflicts between A1 policies are determined based on the policy objective and the scope of application of the policy. The policy objective is set according to the policy type. In this embodiment, the A1 policies are defined by nine policy types shown in FIG. 4. Then, by comparing the policy type of policy #1 with the policy type of policy #2, it is determined whether or not policy #1 and policy #2 conflict. Furthermore, by comparing the scope of application of policy #1 with the scope of application of policy #2, it is determined whether or not policy #1 and policy #2 conflict. Here, the scope of application of a policy is represented by, for example, five elements (cell, QoS, slice, group, and UE) as shown in FIG. 5. In this case, by comparing combinations of elements representing the scope of application, it is determined whether or not policy #1 and policy #2 conflict.

[0046] 9 shows an example of classification of policy types for determining conflicts between A1 policies. Here, the nine policy types shown in FIG. 4 are classified into resource reservation type policies and resource release type policies.

[0047] The resource reservation type A1 policy involves reserving or securing RAN resources for use by the base station. The resource release type A1 policy involves releasing RAN resources for use by the base station. That is, the resource reservation type policy and the resource release type policy have a mutually exclusive relationship in handling RAN resources. Furthermore, the resource reservation type policy and the resource release type policy are in an exclusive-competitive relationship at the cell level.

[0048] For example, the service quality guarantee (#1) involves a process of reserving fixed RAN resources, whereas the load balancing (#8) does not reserve specific RAN resources but distributes RAN resources among cells. Therefore, it is not desirable to simultaneously implement these two A1 policies.

[0049] Alternatively, cell power saving (#9) includes a process of releasing RAN resources to increase power saving opportunities. That is, service quality guarantee (#1) and cell power saving (#9) are mutually contradictory.

[0050] In this embodiment, the A1 policy is classified into either a resource reservation type policy group involving the reservation of RAN resources or a resource release type policy group involving the release of RAN resources. When the new A1 policy (i.e., policy #2) and the A1 policy (i.e., policy #1) implemented in the real-time RIC 21 belong to different policy groups, the conflict determination unit 38 determines that policy #1 and policy #2 conflict with each other.

[0051] 10 is a flowchart showing an example of a process for detecting a conflict between policies. The process of this flowchart corresponds to S4 shown in FIG. 7. In the following description, a conflict between policy #1 and policy #2 is detected.

[0052] In S11, the conflict determination unit 38 determines whether policy #1 and policy #2 belong to the same policy classification. If policy #1 and policy #2 belong to different policy classifications, the conflict determination unit 38 determines in S12 that policy #1 and policy #2 conflict with each other. For example, if policy #1 is a resource reservation type policy and policy #2 is a resource release type policy, the conflict determination unit 38 determines that policy #1 and policy #2 conflict with each other. Similarly, if policy #1 is a resource release type policy and policy #2 is a resource reservation type policy, the conflict determination unit 38 also determines that policy #1 and policy #2 conflict with each other. Note that if a conflict is detected in S11 to S12, the processing of the conflict determination unit 38 proceeds to S5, where priority determination is performed.

[0053] When policy #1 and policy #2 belong to the same policy classification, the conflict determination unit 38 compares the application target of policy #1 with the application target of policy #2 in S13 to S14. Here, the application target (Scope ID) of the A1 policy is expressed by five elements (UE, group, slice, QoS, cell) as shown in FIG. 5. Then, for each A1 policy, one or more elements selected from the five elements are set as the application target by rApp. At this time, a value specifying the application target is set for each selected element. For example, when the application target of the policy is "cell," a value identifying the cell to which the policy should be applied from among multiple cells managed by the base station is set.

[0054] Specifically, when policy #1 and policy #2 have the same combination of elements to which they are applied, and the values ​​of the elements are the same, the conflict determination unit 38 determines in S15 that policy #1 and policy #2 conflict with each other (scope conflict). When policy #1 and policy #2 have the same combination of elements to which they are applied, but the values ​​of the elements to which they are applied are different, the conflict determination unit 38 determines in S16 that policy #1 and policy #2 do not conflict with each other. When policy #1 and policy #2 have different combinations of elements to which they are applied, the conflict determination unit 38 determines in S17 that the objects to which the two A1 policies are applied have an inclusion relationship (scope unmatched).

[0055] For example, in case 1, the conflict relationship is determined as follows: Policy #1: Policy type: QoS target value (policy type #1 in FIG. 4 or FIG. 9) Applicable object: cell C1 Policy #2: Policy type: power saving (policy type #9 in FIG. 4 or FIG. 9) Applicable object: cell C1

[0056] In this case, policy #1 is a resource reservation policy and policy #2 is a resource release policy. That is, policy #1 and policy #2 belong to different policy classifications. Therefore, policy #1 and policy #2 are determined to be in conflict with each other (objective conflict).

[0057] In case 2, the conflict relationship is determined as follows: Policy #1: Policy type: QoS target value (policy type #1 in FIG. 4 or FIG. 9) Applicable to: cell C1 Policy #2: Policy type: QoS optimization (policy type #4 in FIG. 4 or FIG. 9) Applicable to: cell C1

[0058] In this case, both policy #1 and policy #2 are resource reservation policies. Furthermore, the application target of both policy #1 and policy #2 is cell C1. Therefore, policy #1 and policy #2 are determined to be in conflict with each other (scope conflict).

[0059] In case 3, the conflict relationship is determined as follows: Policy #1: Policy type: QoS target value (policy type #1 in FIG. 4 or FIG. 9) Applicable to: cell C1 Policy #2: Policy type: QoS optimization (policy type #4 in FIG. 4 or FIG. 9) Applicable to: cell C2

[0060] In this case, both policy #1 and policy #2 are resource reservation policies. However, policy #1 is applied to cell C1, and policy #2 is applied to cell C2. That is, the values ​​of the elements to which policy #1 and policy #2 are applied are different. Therefore, it is determined that policy #1 and policy #2 do not conflict with each other.

[0061] In case 4, the conflict relationship is determined as follows: Policy #1: Policy type: QoS target value (policy type #1 in FIG. 4 or FIG. 9) Applied to: cell C1 Policy #2: Policy type: slice control (policy type #7 in FIG. 4 or FIG. 9) Applied to: slice X in cell C1

[0062] In this case, both policy #1 and policy #2 are resource reservation policies. However, policy #1 applies to "cells" and policy #2 applies to "slices." That is, policy #1 and policy #2 have different combinations of elements to which they apply. Therefore, policy #1 and policy #2 are determined to have an inclusion relationship (scope unmatched).

[0063] Next, priority determination will be explained. In this embodiment, the priority of the A1 policy is determined according to the traffic load of the base station.

[0064] 11 shows an example of the relationship between traffic load and policy priority. The horizontal axis represents the traffic load of the base station (e.g., the usage rate of RAN resources). The vertical axis represents the priority ownership of the RAN resources. For example, priority ownership = 1 represents a state in which the RAN resources can be used with full priority, and priority ownership = 0 represents a state in which the RAN resources cannot be used with priority. Therefore, the priority ownership essentially represents the priority of the policy.

[0065] When the traffic load is high, there are few unused RAN resources, so it is preferable to be able to reserve RAN resources preferentially in order to execute a resource reservation policy. For example, in order to maintain service quality under a high traffic load, it is necessary to reserve RAN resources preferentially. Therefore, when the traffic load is high, it is necessary to increase the priority of the resource reservation policy (e.g., QoS target). Conversely, when the traffic load is low, there are surplus RAN resources, so the priority of the resource reservation policy may be decreased.

[0066] The resource release type policy is realized by releasing RAN resources in use. For example, cell power saving (Network energy saving) is realized by stopping communication on a cell-by-cell, antenna-by-antenna, or symbol-by-symbol basis. Therefore, when the traffic load is high, it is easy to release RAN resources in use, so the priority of the resource release type policy may be low. Conversely, when the traffic load is low, it is preferable to increase the priority of the resource release type policy because there are fewer RAN resources to be released.

[0067] 11 may be created in advance by, for example, simulation or measurement. In this case, the characteristics shown in FIG. 11 may be created for each policy type shown in FIG.

[0068] The RAN resource ownership priority may be set in smaller increments. For example, in the example shown in Fig. 12, in a mode with a large power saving effect (cell switch off), the RAN resource ownership priority is large when the traffic load is sufficiently small. In contrast, in a mode with a small power saving effect (ASM: Advanced Sleep Mode), the RAN resource ownership priority is large even when the traffic load is relatively large.

[0069] Therefore, the conflict determination unit 38 determines the priority of the policy based on the traffic load of the base station. Specifically, the conflict determination unit 38 acquires information indicating the traffic load of the base station from the E2 node 22. Then, by comparing the traffic load with a predetermined threshold, it determines which of the priority of policy #1 or policy #2 has a higher priority.

[0070] FIG. 13 is a flowchart showing an example of a process for determining the priority between policies. In this embodiment, it is assumed that a conflict (object conflict) has been detected between policy #1 and policy #2. That is, the process of this flowchart corresponds to S5 shown in FIG. 7 or FIG. 10. Specifically, when it is determined in S11 to S12 shown in FIG. 10 that "policy #1 and policy #2 conflict," the procedure of the flowchart shown in FIG. 13 is executed. That is, it is assumed that policy #1 and policy #2 belong to different policy classifications (resource reservation type, resource release type).

[0071] In S21, the contention determination unit 38 acquires traffic load information indicating the traffic load of the base station from the E2 node 22. At this time, the contention determination unit 38 acquires, for example, traffic load information of the cell to which policies #1 and #2 should be applied.

[0072] In S22, the contention determination unit 38 compares the traffic load with a predetermined threshold. The predetermined threshold is determined in advance through simulation, measurement, or the like. The traffic load may be, for example, a usage rate of wireless resources. In the case shown in FIG. 11, the threshold may be "50."

[0073] When the traffic load is higher than the threshold, the priorities of the policies are determined in steps S23 to S25. That is, when the traffic load is higher than the threshold, policy #1 is a resource reservation type policy, and policy #2 is a resource release type policy, the priority of policy #1 is determined to be higher than the priority of policy #2. On the other hand, when the traffic load is higher than the threshold, policy #1 is a resource release type policy, and policy #2 is a resource reservation type policy, the priority of policy #1 is determined to be lower than the priority of policy #2.

[0074] When the traffic load is lower than the threshold, the priorities of the policies are determined in steps S26 to S28. That is, when the traffic load is lower than the threshold, policy #1 is a resource reservation type policy, and policy #2 is a resource release type policy, the priority of policy #1 is determined to be lower than the priority of policy #2. On the other hand, when the traffic load is lower than the threshold, policy #1 is a resource release type policy, and policy #2 is a resource reservation type policy, the priority of policy #1 is determined to be higher than the priority of policy #2.

[0075] In this way, when policy #1 and policy #2 belong to different policy classifications and a conflict (object conflict) is detected between policy #1 and policy #2, the priority between the policies is determined according to the traffic load. Note that when policy #1 and policy #2 belong to the same policy classification and a conflict (scope conflict) is detected between policy #1 and policy #2, for example, the operator of the base station system may determine the priority between the policies.

[0076] 14 is a flowchart showing an example of a method for processing the A1 policy depending on the result of the conflict determination. The process of this flowchart corresponds to S7 shown in FIG. 7. In the following description, it is assumed that the conflict determination unit 38 has completed the conflict determination between policy #1 and policy #2. The result of the conflict determination has been notified to the A1-related function unit 32 by the conflict determination unit 38.

[0077] In this embodiment, as in the case described above, it is assumed that policy #1 generated by rApp #1 has already been implemented in the real-time RIC 21. It is also assumed that policy #2 has been newly generated by rApp #2, and a conflict determination has been performed between policy #1 and policy #2.

[0078] In S31, the A1-related function unit 32 checks whether or not policy #1 and policy #2 conflict with each other. If policy #1 and policy #2 do not conflict with each other, the A1-related function unit 32 executes processing to implement policy #2 in the real-time RIC 21. That is, the processing of the A1-related function unit 32 proceeds to S32.

[0079] In S32, the A1-related function unit 32 transmits a request to create policy #2 (A1 policy creation request) via the A1 interface to the real-time RIC 21. The real-time RIC 21 then determines whether policy #2 can be implemented and transmits the determination result to the A1-related function unit 32. Thus, in S33 and S34, the A1-related function unit 32 receives the determination result indicating whether policy #2 can be implemented in the real-time RIC 21.

[0080] When policy #2 is implemented in the real-time RIC 21, the A1-related function unit 32 stores, in S35, policy information indicating that policy #2 has been implemented in the real-time RIC 21 in the policy information storage unit 37. In addition, in S36, the A1-related function unit 32 transmits an OK notification via the R1 interface to rApp #2, which generated policy #2. This OK notification is a response to the generation request from rApp #2, and indicates that policy #2 has been successfully implemented in the real-time RIC 21.

[0081] If policy #2 is not implemented in the real-time RIC 21 (S34: No), the A1-related function unit 32 sends an NG notice to rApp #2 via the R1 interface in S37. This NG notice is a response to the creation request from rApp #2, and indicates that policy #2 was not properly implemented in the real-time RIC 21.

[0082] When policy #1 and policy #2 conflict, the A1-related functional unit 32 checks the priorities of policy #1 and policy #2 in S41-S42. Here, if policy #1 and policy #2 conflict and the priorities of policy #1 and policy #2 are the same, it is undesirable to implement policy #2 in the real-time RIC 21. Therefore, in this case, the A1-related functional unit 32 sends a NG notice to rApp #2 via the R1 interface in S43 without sending a creation request to the real-time RIC 21. This NG notice indicates that policy #2 conflicts with the implemented A1 policy (i.e., policy #1). "CNF" in FIG. 14 indicates the occurrence of a conflict. "Scope_info" indicates a case where the policy targets match (S15 in FIG. 10) or a case where the policy targets have an inclusion relationship (S17 in FIG. 10). When rApp#2 receives the NG notification in S43, it may generate an alternative policy, for example.

[0083] When policy #1 and policy #2 conflict and the priority of policy #1 is higher than the priority of policy #2, policy #2 cannot be implemented in the real-time RIC 21, or it is undesirable to implement policy #2 in the real-time RIC 21. Therefore, in this case, the A1-related function unit 32 sends a NG notice to rApp #2 via the R1 interface in S44 without sending a generation request to the real-time RIC 21. This NG notice indicates that policy #2 conflicts with the implemented A1 policy and that the priority of policy #2 is lower than the priority of the implemented A1 policy. "P_LOW" shown in FIG. 14 indicates that the priority of the policy is lower than the priority of other A1 policies. Note that when rApp #2 receives the NG notice in S43, it may, for example, generate an alternative policy.

[0084] When policy #1 and policy #2 conflict and policy #2 has a higher priority than policy #1, policy #2 should be implemented in the real-time RIC 21 instead of policy #1. Therefore, in this case, the A1-related function unit 32 sends a NG notification to rApp #1, which generated policy #1, via the R1 interface in S45. This NG notification indicates that policy #1 conflicts with the new A1 policy and that the priority of policy #1 is lower than the priority of the new A1 policy. When rApp #1 receives the NG notification in S45, it executes a process to delete policy #1 from the real-time RIC 21. The deletion of policy #1 is executed by the A1-related function unit 32, for example, in response to a request from rApp #1.

[0085] Furthermore, in S46, the A1-related function unit 32 sends an NG notice to rApp#2 via the R1 interface. This NG notice indicates that policy #2 conflicts with the implemented A1 policy, but the priority of policy #2 is higher than the priority of the implemented A1 policy. "P_High" shown in FIG. 14 indicates that the priority of the policy is higher than the priority of other A1 policies. Note that when rApp#2 receives the NG notice in S46, it may generate policy #2 again. Then, after policy #1 is deleted in the real-time RIC 21, policy #2 is implemented in the real-time RIC 21.

[0086] In this way, when multiple A1 policies compete with each other, the A1 policy with the highest priority is selected and implemented in the real-time RIC 21. The real-time RIC 21 then controls communication of the base station based on the implemented A1 policy. Therefore, stable communication in accordance with the preferred A1 policy is realized.

[0087] In the above-described embodiment, when replacing the A1 policy (i.e., policy #1) implemented in the real-time RIC 21 with a new A1 policy (i.e., policy #2), rApp #1 requests the deletion of policy #1, and rApp #2 requests the implementation of policy #2. However, the first embodiment is not limited to this procedure. For example, the A1-related function unit 32 may request the real-time RIC 21 to create / update / delete the A1 policy depending on the determination result by the conflict determination unit 38. For example, in the flowchart shown in FIG. 14, when the priority of policy #2 is higher than the priority of policy #1 (S42: No), the A1-related function unit 32 may send an instruction to delete policy #1 and a process to implement policy #2 to the real-time RIC 21. In this case, policy #1 implemented in the real-time RIC 21 is replaced with policy #2 without receiving a request or instruction from rApp.

[0088] Second Embodiment In the first embodiment, the conflict detection R1 service providing unit 36 ​​is implemented in the non-real-time RIC framework 12. That is, the conflict determination unit 38 is realized as an additional function of the A1-related function unit 32. In contrast, in the second embodiment, the function of determining conflicts between policies is realized as rApp.

[0089] Fig. 15 shows an example of a communication system according to the second embodiment. Similar to the communication system 1 shown in Fig. 6, the communication system 2 according to the second embodiment includes a non-real-time RIC framework 12, a real-time RIC 21, and an E2 node 22. Furthermore, the communication system 2 includes the O-RU 23 shown in Fig. 1.

[0090] In the second embodiment, the function of determining whether a conflict exists between policies is realized by rApp. In the following description, the application program that determines whether a conflict exists between policies may be referred to as "rApp#3."

[0091] rApp#3 includes a conflict determination unit 41 and a policy information storage unit 42. The conflict determination unit 41 and the policy information storage unit 42 are substantially the same as the conflict determination unit 38 and the policy information storage unit 37 shown in FIG. 6, respectively. That is, the conflict determination unit 41 can determine a conflict between an already implemented A1 policy and a new A1 policy. Furthermore, the policy information storage unit 42 stores information representing the A1 policy implemented in the real-time RIC 21.

[0092] The communication system 2 executes the process of the flowchart shown in Fig. 7, similar to the communication system 1 according to the first embodiment. However, in the second embodiment, rApp #2g, which has generated a new A1 policy (here, policy #2), requests rApp #3 to check for conflicts between policies before requesting implementation of the A1 policy.

[0093] rApp#3 receives a conflict check request via the R1 interface. For example, in a case where a conflict check request is sent from rApp#2 to the non-real-time RIC framework 12, rApp#3 receives the conflict check request from the non-real-time RIC framework 12 via the R1 interface. Alternatively, in a case where direct communication between rApps is possible, rApp#3 receives the conflict check request from rApp#2. The conflict determination unit 41 then performs conflict determination in response to the conflict check request. The result of the conflict determination is sent to rApp#2 via the R1 interface. At this time, the non-real-time RIC framework 12 may be involved in the communication between rApp#3 and rApp#2.

[0094] The method of conflict determination (including priority determination) is substantially the same in the first and second embodiments. That is, the conflict determination unit 41 determines whether or not there is a conflict according to the flowchart shown in Fig. 10, and determines the priority of the A1 policy according to the flowchart shown in Fig. 13.

[0095] 16 is a flowchart showing an example of a method for processing the A1 policy according to the result of the conflict determination in the second embodiment. The method for processing the A1 policy according to the result of the conflict determination is almost the same in the first and second embodiments. However, in the second embodiment, the result of the conflict determination is sent to the rApp that generates a new A1 policy. In this example, rApp#2 receives the result of the conflict determination. Then, if the new A1 policy does not conflict with the implemented A1 policy, rApp#2 requests the non-real-time RIC framework 12 to implement the new A1 policy.

[0096] Therefore, when policy #2 does not conflict with other A1 policies, the A1-related function unit 32 receives a creation request related to policy #2 from rApp #2 in S51. Then, upon receiving the creation request related to policy #2, the A1-related function unit 32 executes the processes of S32 to S37, as in the first embodiment.

[0097] In this way, in the second embodiment, the function of determining conflicts between policies is realized by an application program (i.e., rApp) that runs on the non-real-time RIC framework 12. Therefore, the design of the function of determining conflicts between policies can be easily changed.

[0098] <Example> Fig. 17 shows a first example of communication control based on the A1 policy. Fig. 18 shows an operation sequence in the first example. In the first example, the communication system 1 shown in Fig. 6 controls the communication.

[0099] Policy #1 generated by rApp #1 is "QoS optimization." Policy #2 generated by rApp #2 is "Energy saving." Policy #1 is implemented in the real-time RIC 21. Policy #1 is applied to the QoS in the specified cell via the E2 node 22. Then, policy #2 is newly generated.

[0100] 19 shows the contents of policies generated in the first embodiment. Policy #1 is a resource reservation policy that implements "qosID=Q1" in cell C1. "GFBR (Guaranteed Flow Bit Rate)=300Mbps" is specified as the target value for service quality. Policy #2 is a resource release policy that reduces the power consumption of cell C1. "O-RU power consumption=200kW / h" is specified as the target parameter.

[0101] The contention determination unit 38 acquires information indicating the traffic load on a cell-by-cell basis from the E2 node 22. In this embodiment, it is assumed that the traffic load of the cell C1 is higher than a predetermined threshold. The policy information storage unit 37 stores policy information for the A1 policy (i.e., policy #1) implemented in the real-time RIC 21.

[0102] rApp#2 requests the non-real-time RIC framework 12 to implement policy #2. This request corresponds to the "Policy creation request" shown in Fig. 18. In the non-real-time RIC framework 12, the A1-related function unit 32 requests the conflict determination unit 38 to determine whether there is a conflict between the newly created A1 policy (i.e., policy #2) and the already implemented A1 policy. This request corresponds to the "Conflict check request" shown in Fig. 18.

[0103] The conflict determination unit 38 detects that policy #1 is implemented in the real-time RIC 21 by referring to the policy information storage unit 37. Then, the conflict determination unit 38 determines whether policy #1 and policy #2 conflict with each other. In this embodiment, policy #1 is a resource reservation type policy, and policy #2 is a resource release type policy. That is, it is determined that policy #1 and policy #2 conflict with each other. Furthermore, since the traffic load of cell C1 is higher than a predetermined threshold, the priority of the resource reservation type policy is high. Therefore, it is determined that the priority of policy #1 is higher than the priority of policy #2.

[0104] The conflict determination unit 38 transmits the result of the conflict determination to the A1-related function unit 32. The result of the conflict determination indicates that "Policy #2 conflicts with the implemented A1 policy" and that "the priority of Policy #2 is lower than the priority of the implemented A1 policy." The notification of this determination result corresponds to the "Conflict check response" shown in FIG. 18.

[0105] Based on the determination result received from the conflict determination unit 38, the A1-related functional unit 32 recognizes that policy #2 cannot be implemented in the real-time RIC 21. The A1-related functional unit 32 then transmits a NG notification to rApp #2, indicating that policy #2 cannot be implemented in the real-time RIC 21. This NG notification corresponds to the "Response of request" shown in FIG. 18 . Upon receiving this NG notification, rApp #2 generates an alternative policy as necessary. Alternatively, rApp #2 may generate policy #2 again during a time period when the traffic load is low.

[0106] In this way, in a configuration in which the conflict determination unit 38 is implemented in the non-real-time RIC framework 12, cases in which a new policy cannot be implemented in the real-time RIC 21 due to policy conflicts are handled by the R1 service. Therefore, access to the real-time RIC 21 via the A1 interface is suppressed. Furthermore, behavior related to application of the A1 policy is controlled in a unified manner.

[0107] Fig. 20 shows a second embodiment of communication control based on the A1 policy. Fig. 21 shows an operation sequence in the second embodiment. Note that in the second embodiment, the communication system 1 shown in Fig. 6 also controls communication.

[0108] Policy #1 and policy #2 are substantially the same in the first and second embodiments, except that in the second embodiment, the traffic load in cell C1 is lower than a predetermined threshold.

[0109] The conflict determination is substantially the same in the first and second embodiments. That is, it is determined that policy #1 and policy #2 conflict with each other. However, since the traffic load of cell C1 is lower than a predetermined threshold, the priority of the resource-release policy is higher. Therefore, it is determined that the priority of policy #2 is higher than the priority of policy #1.

[0110] When the A1-related functional unit 32 receives the result of the conflict determination by the conflict determination unit 38, it recognizes that policy #1 implemented in the real-time RIC 21 needs to be replaced with policy #2. The A1-related functional unit 32 then transmits to the real-time RIC 21 an instruction to delete policy #1 and an instruction to implement policy #2. These instructions correspond to the "Deletion request (Policy #1)" and "Creation request (Policy #2)" shown in FIG. 21 . In response to these instructions, the real-time RIC 21 deletes policy #1 and implements policy #2. If the deletion and implementation processes are successful, the real-time RIC 21 transmits a response to the A1-related functional unit 32.

[0111] The A1-related functional unit 32 sends a notification to rApp#1 indicating that "Policy #1 conflicts with the new A1 policy" and that "the priority of policy #1 is lower than the priority of the new A1 policy." This notification corresponds to "Notification" shown in Fig. 21. In addition, the A1-related functional unit 32 sends a notification to rApp#2 indicating that "Policy #2 conflicts with the already implemented A1 policy" and that "the priority of policy #2 is higher than the priority of the already implemented A1 policy." This notification corresponds to "Response of request" shown in Fig. 21.

[0112] In this way, when a new A1 policy conflicts with an already implemented A1 policy and the priority of the new A1 policy is higher than the priority of the already implemented A1 policy, it is possible to replace the already implemented A1 policy with the new A1 policy with a single access from rApp to the non-real-time RIC framework 12.

[0113] Fig. 22 shows a third embodiment of communication control based on the A1 policy. Fig. 23 shows an operation sequence in the third embodiment. In the third embodiment, the communication system 2 shown in Fig. 15 controls the communication.

[0114] Policy #1 and policy #2 are substantially the same in the first and third embodiments, except that in the second embodiment, the traffic load in cell C1 is lower than a predetermined threshold.

[0115] rApp#2 requests the conflict determination unit 41 to determine whether there is a conflict between policy #2 and the implemented A1 policy. This request corresponds to the "Conflict check request" shown in FIG. 21. The conflict determination unit 41 then executes the conflict determination. The determination result is the same as in the second embodiment. That is, it is determined that policy #1 and policy #2 conflict with each other. It is also determined that the priority of policy #2 is higher than the priority of policy #1.

[0116] In this case, a process is executed to replace policy #1 implemented in the real-time RIC 21 with policy #2. That is, a notification indicating that "policy #1 conflicts with the new A1 policy" and that "the priority of policy #1 is lower than the priority of the new A1 policy" is sent to rApp #1. This notification corresponds to "Notification (CNF & P_Low)" shown in FIG. 23. In addition, a notification indicating that "policy #2 conflicts with the implemented A1 policy" and that "the priority of policy #2 is higher than the priority of the implemented A1 policy" is sent to rApp #2. This notification corresponds to "Conflict check response (CNF & P_High)" shown in FIG. 21.

[0117] In response to the above notification, rApp #1 requests the real-time RIC 21 to delete policy #1. This request corresponds to the "Deletion request (Policy #1)" shown in FIG. 23. In response to the above notification, rApp #2 requests the real-time RIC 21 to implement policy #2. This request corresponds to the "Creation request (Policy #2)" shown in FIG. 23. As a result, policy #1 implemented in the real-time RIC 21 is replaced with policy #2.

[0118] In this way, even in a configuration in which the conflict determination unit 41 is implemented as an rApp, cases in which a new policy cannot be implemented in the real-time RIC 21 due to policy conflicts are handled by the R1 service. Therefore, access to the real-time RIC 21 via the A1 interface is suppressed. Furthermore, behavior related to the application of the A1 policy is controlled in a unified manner.

[0119] 23, the A1 policy implemented in the real-time RIC 21 is replaced in response to a request (Deletion, Creation) from the rApp, but the third embodiment is not limited to this procedure. For example, the A1-related function unit 32 may request the real-time RIC 21 to replace the A1 policy.

[0120] 24 shows an example of the hardware configuration of the non-real-time RIC framework 12 that operates as a communication control device. The communication control device is realized by a computer system 100 that includes a processor system 101, a memory 102, a storage device 103, an input / output device 104, a recording medium reader 105, and a communication interface 106.

[0121] The processor system 101 realizes the non-real-time RIC framework 12 by executing a communication control program stored in the storage device 103. The processor system 101 is realized by one or more processors. When the processor system 101 includes multiple processors, the multiple processors may be connected to each other via a network. When the processor system 101 executes the communication control program, the functions of the A1-related functional unit 32, the O1-related functional unit 35, and the conflict determination unit 38 shown in FIG. 6 are provided. The memory 102 is used as a work area for the processor system 101. The storage device 103 stores the above-mentioned communication control program and other programs.

[0122] The input / output device 104 may include input devices such as a keyboard, a mouse, a touch panel, and a microphone. The input / output device 104 may also include output devices such as a display device and a speaker. The recording medium reader 105 can acquire data and information recorded on the recording medium 110. The recording medium 110 is a removable recording medium that can be attached to and detached from the computer system 100. The recording medium 110 may be implemented, for example, as a semiconductor memory, a medium that records signals optically, or a medium that records signals magnetically. The communication control program may be provided to the computer system 100 from the recording medium 110. The communication interface 106 provides a function for connecting to a network. When the communication control program is stored in the program server 120, the computer system 100 may acquire the communication control program from the program server 120.

[0123] 1, 2 Communication system 12 Non-real-time RIC framework 21 Real-time RIC 22 E2 node 23 O-RU 31 R1 termination unit 32 A1 related function unit 33 A1 termination unit 34 O1 termination unit 35 O1 related function unit 36 ​​Conflict detection R1 service providing unit 37, 42 Policy information storage unit 38, 41 Conflict determination unit

Claims

1. A communication control device that controls the implementation of a policy in a communication device that operates based on the policy, comprising: a conflict determination unit that determines whether the first policy and the second policy conflict with each other in response to receiving a policy request requesting the communication device to implement a second policy when a first policy is implemented in the communication device; and a control unit that controls the implementation of the first policy and the second policy in the communication device based on the determination result by the conflict determination unit.

2. The communication control device described in claim 1, characterized in that the policies are classified into either a first policy group that involves the reservation of communication resources to be used by the communication device or a second policy group that involves the release of the communication resources, and when the first policy and the second policy belong to different policy groups, the conflict determination unit determines that the first policy and the second policy conflict with each other.

3. The communication control device described in claim 2, characterized in that the policy includes application target information indicating the target to which the policy should be applied, and when the first policy and the second policy belong to the same policy group and the application target information of the first policy and the application target information of the second policy match each other, the conflict determination unit determines that the first policy and the second policy conflict with each other.

4. The communication control device according to claim 2, wherein when the first policy and the second policy do not conflict with each other, the control unit implements the second policy in the communication device.

5. A communication control device as described in claim 2, characterized in that when the first policy and the second policy conflict with each other, the conflict determination unit determines the priority of the first policy and the second policy based on the traffic load of the communication device.

6. The communication control device according to claim 5, characterized in that the conflict determination unit determines that the priority of the policy belonging to the first policy group is higher than the priority of the policy belonging to the second policy group when the traffic load is greater than a predetermined threshold.

7. The communication control device according to claim 5, characterized in that the conflict determination unit determines that the priority of the policy belonging to the second policy group is higher than the priority of the policy belonging to the first policy group when the traffic load is smaller than a predetermined threshold.

8. The communication control device according to claim 5, characterized in that when the priority of the first policy is higher than the priority of the second policy, the control unit notifies the second policy generation unit that generated the second policy of the determination result made by the conflict determination unit.

9. A communication control device as described in claim 5, characterized in that when the priority of the second policy is higher than the priority of the first policy, the control unit notifies the first policy generation unit that generated the first policy and the second policy generation unit that generated the second policy of the judgment result by the conflict judgment unit.

10. The communication control device according to claim 9, wherein the control unit instructs the communication device to replace the first policy implemented in the communication device with the second policy.

11. The communication control device according to claim 1, wherein the contention determination unit is implemented within a non-real-time RIC (RAN Intelligent Controller) framework in an O-RAN architecture.

12. The communication control device according to claim 1, characterized in that the contention determination unit is realized by an application that operates on a non-real-time RIC (RAN Intelligent Controller) framework in the O-RAN architecture.

Images