New PCI xApp based on O-RAN E2SM RC

I. Introduction

The goal of this is to design a new PCI xApplication to resolve the PCI conflict with the RC service model. The RC service model is a general-purpose service model from O-RAN to control RAN, which has a lot of functionalities, message definitions, etc. Thus, we try to replace the existing RC-Pre service model that the current PCI xApplication is using with the RC service model for the PCI conflict resolution use-case. 

II. Overall workflow

For the PCI conflict resolution use-case basically assumes the situation where neighbor cells are running in the same ARFCN/EARFCN with the same PCI value. Since the neighbor cells should have the unique PCI in the same channel, this use-case tries to resolve the situation. In this use-case, there are several phases: (i) E2 setup and subscription; (ii) Neighbor cell discovery; (iii) PCI conflict resolution; (iv) new PCI value assignment. 

• E2 setup and subscription: Once the near-RT RIC, the PCI xApplication, and gNBs boot up, each gNB set up a E2 session with E2T in the near-RT RIC. Then, the gNB subscribes to the PCI xApplication. 

• Neighbor cell discovery: After Xn setup procedures happen between two neighbor gNBs, each gNB sends neighbor cell information with an E2 indication message. Once the xApplication receives the indication message, it stores the neighbor cell information to R-NIB. 

• PCI conflict resolution: receiving the neighbor cell information, if the PCI conflict situation among neighbor cells is detected, the xApplication runs the PCI conflict resolution logic. Basically, this logic checks the number of UEs for each cell in the PCI conflict situation. Then, it assigns the new PCI value to the cell that services the lower number of UEs. The new PCI value is assigned to the number that does not cause another PCI conflict situation in the PCI range from 1 to 255. 

• New PCI value assignment: Once the PCI conflict resolution logic picks the new PCI for the cell, the xApplication sends the control message to the cell with the new PCI. 

Open

Fig. 1 depicts an example of overall PCI use-case workflow. We assume that there are three gNBs and they are running in the same channel. Since gNB 1 and gNB 3 have the same PCI value, the PCI xApplication in the near-RT RIC (RIC in this figure) should assign the new PCI value to one of gNBs. The workflow of the PCI use-case in this situation is as follows. First, each gNB and RIC set up E2 session and create a E2 subscription. After that, gNB1 and gNB2 set up the Xn interface; they send a RIC indication message to report that gNB1 and gNB2 are neighbors. Likewise, after Xn setup procedure between gNB2 and gNB3 (gNB1 and gNB3), each gNB sends indication message. The xApplication then notices that gNB1 and gNB3 are running in the same ARFCN with the same PCI – the PCI conflict situation. In order to resolve the PCI conflict situation, the xApplication assigns the new PCI value to the gNB that services the lower number of UEs than the other gNB. Last, the xApplication sends the control message to the gNB with the new PCI. 

III. E2 workflow

a. Challenges

In order to use the RC service model directly, there are some challenges to use the control message to assign a new PCI to a specific gNB. 

• Define a new control service style #9 PCI control: First, the control message does not have a control service style for the PCI use-case. According to the RC service model, there are eight types: #1 radio bearer control, #2 radio resource allocation control, #3 connected mode mobility control, #4 radio access control, #5 Dual Connectivity (DC) control, #6 Carrier Aggregation (CA) control, #7 idle mode mobility control, and #8 UE information and assignment. However, there are no style related with the cell ID or parameter configuration. Therefore, we should define a new control service style such as #9 PCI control. 

• Define a new control action #1 PCI control: After defining the new control service style, we should define a new control action ID. Each control service style in the RC service model has control actions. For example, the control service style #4 radio access control has five control actions: #1 UE admission control, #2 RACH backoff control, #3 access barring control, #4 RRC connection release control, and #5 RRC connection reject control. Same as what other control service styles define, the #9 PCI control service style also has the new control action such as #1 PCI control. 

• Define a new RAN parameter #1 NR-PCI for control service: Also, each control action has a lot of RAN parameters being sent to each gNB via the control message. Since the control action #1 PCI control is newly defined, we should also define what parameters will be controlled by the PCI xApplication in near-RT RIC. Mainly, this use-case assigns the new PCI value to gNBs, we should define #1 Serving Cell NR-PCI as a new RAN parameter. The NR-PCI format is defined in the 3GPP TS 38.473 Section 9.3.1.10. 

• Define a new RAN parameter #2 CGI for control service: Last, since the control message in the RC service model is `per-UE message`, there is no cell ID field – CGI field. According to the RC service model specification field, there is only UE ID field. The UE ID field indicates both UE ID (e.g., AMF ID, NGAP ID, etc.) and UE’s serving gNB ID. However, since a single gNB is able to open multiple cells, the control message should also have the cell identifier such as CGI. To resolve this issue, we define one more RAN parameter such as #2 CGI. Thus, when sending a control message, the xApplication added both the new NR-PCI value as well as the target cell’s CGI. 

b. E2 setup phase

The E2 setup is the initial phase that creates an E2 session between the near-RT RIC and each gNB. Since the E2 Termination (E2T) is responsible for the E2 setup in the near RT RIC, each gNB sends or receives E2 setup messages to or from the E2T, respectively. Fig. 2 depicts the workflow of this phase. The gNB/E2 node initiates this phase by sending the E2 setup request message. When the E2T receives the message, it creates or updates the gNB/E2 node information (e.g., RAN function definition, interfaces, ID, etc.) to R-NIB (onos-topo). And then, the E2T acknowledges it with E2 setup response message. 

Open

  In order to report what service each gNB/E2 node supports in E2 interface for the PCI use-case, the E2 setup request message format is defined as Fig. 3. Basically, the RAN function definition item should be two-fold – the one for REPORT service and the other one for CONTROL service. The RAN function definition for REPORT has the type E2 node information and the trigger type E2 node information changes. The action definition format, the indication header format, and the indication message format should be format 1, format 1, and format 3, respectively. With this definition, gNB/E2 node reports each cell’s information and its neighbor cell information, after neighbor cell discovery through Xn interface is done. On the other hand, the RAN function definition for CONTROL has the new RIC control style #9 PCI control and the new control action #1 PCI control. Aforementioned before, since there is no control style and action for PCI control, this use-case should define the new one. The RAN control parameters should also be the new one – #1 NR-PCI and #2 CGI – to assign a new PCI value to a specific cell. Both the control header format and the control message format are format 1. 

c. E2 subscription phase

After E2 setup phase is done, then the PCI xApplication starts the E2 subscription phase by sending the RIC subscription request message to each gNB/E2 node through the E2T. Fig. 4 shows a workflow for this phase. Once E2 node receives the request message, it sends the RIC subscription response message back to the PCI xApplication. 

Fig. 5 shows the RIC subscription request message format for the PCI use-case. The RIC event definition format should be 3 and E2 node information change ID should be #1 cell configuration change and # 2 cell neighbor relation change. The first one is for each gNB/E2 node to report the NR-PCI when it changes and the second one is for reporting the neighbor cell list. RIC action definition format should be 1 which includes the RAN parameters CGI and NR-PCI same as the control service to make sure that the indication message has to have those values. 

d. E2 report phase

Once the subscription phase is finished, the indication message channel is established between the PCI xApplication and each gNB/E2 node. Through this indication message channel, each gNB/E2 node sends an indication message when (i) the PCI value is changed or (ii) the new neighbor cell is discovered due to the Xn interface established. This is the report phase, which is shown in Fig. 6. 

  Fig. 7 depicts the indication message format. This message has the CGI as mandatory. And all other remaining fields are optional field. However, in the PCI use-case, the neighbor relation table field should be filled out as mandatory. This filed has the serving cell’s PCI, ARFCN, and neighbor cell list which is defined in the E2SM-RC specification Section 9.3.38. 

e. E2 control phase

The last phase is the control phase, which sends the control request message from the PCI xApplication to specific gNBs/E2 nodes. Once gNBs/E2 node receive it, they acknowledge it with RIC control ACK message (Fig. 8). The PCI xApplication sends the control request message to the target gNB/E2 node, where the control message has the CGI to identify the target cell and the new NR-PCI to be assigned to the target cell (Fig. 9). 

IV. PCI xApp workflow diagram

New MHO xApp based on O-RAN E2SM RC

I. Introduction

The goal of this is to design a new Mobile HandOver (MHO) xApplication to control handover when A3 measurement event happens. The RC service model is a general-purpose service model from O-RAN to control RAN, which has a lot of functionalities, message definitions, etc. Thus, we try to replace the existing MHO service model designed by Open Networking Foundation (ONF) SD-RAN community for the current MHO xApplication with the RC service model for the handover control.

II. Overall workflow

The overall MHO use-case workflow is as follows. First, there are three assumptions for this use case as follows: there are multiple cells deployed and UEs are moving around them; eNBs/gNBs support handover features; every UEs attached to an eNB/gNB will have the A3 measurement report configured. Those assumptions cause the UEs’ received signal strength changed dynamically; some UEs should be handed over to the other neighbor cell getting better received signal. While the current eNB/gNB decides the handover, the MHO use-case separates some parts of the handover intelligence from the eNB/gNB and then put them into the MHO xApplication.  

  Fig. 1 illustrates the new workflow of the MHO use-case. First, an eNB/gNB and MHO xApplication set an E2AP session and then create a subscription (E2 setup and subscription phase). Then, the eNB/gNB reports to the MHO xApplication by sending an indication message when the event A3 measurement report arrives from a UE. This indication message is INSERT service indication message where the service asks the control message to the xApplication to control something (Insert service phase). In order to match a control message and an indication message, those messages have an identifier called the RIC call process ID. If a control message and an indication message have the same RIC call process ID, the control message is triggered by the indication message. The important thing is that the eNB/gNB suspends the handover procedure until the MHO xApplication sends the control message. Once the MHO xApplication decides that the reported event A3 requires the handover1, the MHO xApplication sends the control message to the eNB/gNB (Control service phase). The MHO xApplication can make a handover decision with a policy driven manner, such as handover events allowed for a UE group or handovers always forbidden for the other UE group. Finally, the eNB/gNB resumes the handover process after the control message received. Of course, the handover is rejected if (1) the target cell ID in the control message is equal to the serving cell ID, (2) the target cell ID in the control message does not match with any cell ID in gNB’s neighbor list, or (3) the target cell ID in the control message is the reserved ID such as 0xFFFFFF. 

III. E2 workflow

a. E2 setup and subscription phase

The first phase initially creates an E2 session between near-RT RIC and each gNB by exchanging the E2 setup request and response message. Since the E2T is responsible for the E2 setup in the near-RT RIC, each gNB sends or receives E2 setup or response message to or from the E2T, respectively. Fig. 2 shows the workflow of the E2 setup procedure in this phase. The gNB initiates this phase by sending the E2 setup request message. When the E2T receives the message, it creates or updates the gNB information to R-NIB such as RAN function definitions, interfaces, E2 node IDs, gNB IDs, etc.). Then, the E2T acknowledges it with the E2 setup response message. 

To report what service each gNB supports on E2 interface for the MHO use-case, the E2 setup request message format is defined as Fig. 3. Basically, the RAN function definition items should be two-fold: the one for INSERT service and the other one for CONTROL service. The RAN function definition for INSERT has the style type #3 Connected Mode Mobility Control Request. The RIC event trigger style type #1 Message Event and sequence of insert indication has a single item, #1 Handover Control Request. The RIC indication header format, the RIC indication message format, and the RIC call process ID format should be format 2, format 5, and format 1, respectively. On the contrary, the RAN function definition for CONTROL has the RIC control style #3 Connected Mode Mobility. The sequence of control actions has a single item, #1 Handover Control, and the sequence of associated RAN parameters are the Target Primary Cell ID which has the RAN parameter ID from 1. The RIC control header format, the RIC control message format, call the RIC process ID format, and the RIC control outcome format type should be all format 1. The sequence of associated RAN parameters for control outcome should be #1 Received Timestamp. 

After creating an E2 session between a near-RT RIC and a gNB, the MHO xApplication starts to subscribe with the gNB by sending RIC subscription request message to the gNBs supporting the RC service model through the E2T. Fig. 4 shows a E2 subscription process. Once a gNB receives the RIC subscription request message, it sends the RIC subscription response message back to the MHO xApplication. 

Fig. 5 depicts the RIC subscription request message format for the MHO use-case. The RIC event trigger definition should be defined with the RIC event trigger definition format 1. The sequence of message for event triggers has one item to monitor the RRC message for A3 measurement report from a UE to its serving gNB. Since the UE sends a A3 measurement report with UL-DCCH RRC message, RRC message ID field should be UL-DCCH. The associated UE event field is defined with the Event Trigger UE Information which should be #2 Event A3 Measurement Report Reception. According to the E2SM-RC specification, although the associated UE event field is optional, it should be identified for the MHO use-case. Otherwise, all other UL-DCCH message types will be reported to the MHO xApplication, which includes RRC messages unrelated with the event A3 measurement/handover. The RIC Action ID in the RIC subscription request message should be 3 and type should be Insert. The RIC action definition should be defined with action definition format 3. In the format, it should have the RAN parameter ID #1 Target Primary Cell ID. 

b. Insert service phase

After the subscription process, the indication message channel is established between the MHO xApplication and each gNB. Through the channel, each gNB sends an indication message when an event A3 measurement report arrives from a UE (Fig. 6). 

Fig. 7 shows the RIC indication message format for the MHO use-case. The RIC indication header which is formatted with the RIC indication header format 2 should include the UE ID, the RIC insert style type, and the insert indication ID2. The RIC insert style type should be #3 Connected Mode Mobility Control Request. The RIC indication message field should be defined with the RIC indication message format 5. This field has a single RAN parameter ID #1 Target Primary Cell ID and its value. The RIC call process ID is assigned by the gNB to identify which an upcoming control message is for this indication message. 

c. Control service phase

Once the indication message arrives due to the event A3 measurement report arrival, the MHO xApplication initially checks if the UE in the report should be handed over to the neighbor cell or not according to the policies. If necessary, the MHO xApplication sends a control message to the gNB as shown in Fig. 8. 

Fig. 9 shows a RIC control request message format. First, this message should have the RIC call process ID which has to be same as the RIC indication message that triggers this control message. Otherwise, the gNB is impossible to know the reason why the MHO xApplication is sending this control message. The RIC control header field is defined with the control header format 1. The RIC style type and control action ID in this header should be 3 and 1, respectively. The RIC control message which is formatted with the control message format 1 has the RAN parameter ID #1 Target Primary Cell ID and its value. 

Appendix A. Detailed MHO logic

• Logic 1 –MHO considering with target neighbor cell load:  Receiving the A3 measurement report, the MHO xApplication initially checks the load of target neighbor cell3. If the target neighbor cell suffers from the heavy load (i.e., the cell is overloaded), the xApplication rejects the handover. 

• Logic 2 – Ping-pong effect aware MHO: The MHO xApplication does not immediately allow the UE to move out to the target neighbor cell. In order to avoid the ping-pong effect, the xApplication first receives consequent multiple indication messages for a UE. Then, if the xApplication estimates4 that the UE will not come back to the source cell again after the HO, the MHO xApplication finally accepts the HO. 

• Logic 3 – CQI aware MHO: Receiving the A3 measurement report, the MHO xApplication checks the channel quality with the CQI5. Even though the Event A3 is detected, the MHO xApplication does not allow a UE to do a HO if the CQI is still good, i.e., the UE is close to the center of its serving cell. Only the MHO xApplication allows the UE to run HO, if CQI is low, i.e., the UE is in the edge of its serving cell. 

New MLB xApp based on O-RAN E2SM RC

I. Introduction

The goal of this is to design a new Mobility Load Balancing (MLB) xApplication to balance the load among cells by adjusting the handover (HO) region. Even though the existing MLB xApplication in SD-RAN project offloads the overloaded cells by resizing the HO region, it leverages a pre-standard service model, RC-Pre service model. RC-Pre service model is originally designed within SD-RAN community, which is not an approved standardized service model. However, O-RAN WG3 has released RC service model which is a generic and standard service model for RAN control. Therefore, in order to follow the standard, we should replace the pre-standard service model to the standard service model. In this design note, we will propose a new MLB xApplication workflow with RC service model. 

II. Overall workflow

The MLB use-case has following assumptions: (1) there are multiple cells deployed and UEs are moving around them; (2) eNB/gNB supports HO features; (3) A3 HO is allowed when a UE enters A3 event; (4) a UE gets HO parameters when attached through RRC; (5) In the A3 event, a UE sends measurement report messages. Those assumptions cause two observations. First one is that the received signal strength for each UE is changed dynamically. Second, since UEs are moving randomly, the load of each cell is changed in time. In this situation, some cells are overloaded at some point, and some other cells are underloaded; it is the situation that the load balancing is required. 

To balance the load among cells, the MLB use-case expands or shrinks the HO region by adjusting a HO parameter. In fact, there are two types of MLB approaches: the one adjusts the transmission power; the other one modifies HO parameters. The purpose of those two approaches is to adjust the HO region. The difference between them is that the first one touches the transmission power which causes the SINR degradation, but the second one does not. Since the first one physically reduces the transmission power, all connected UEs encounter the SINR degradation. It is able to cause a service quality decreased, such as decreased data rate. On the contrary, the second one logically shrinks the HO region but does not touch the transmission power. This can achieve both balancing the load by leveraging HO and maintaining a service quality. Thus, this use-case works with the second approach to keep each UE’s service quality maintained while balancing the load. 

Among the HO parameters, the MLB use-case will modify the neighbor cell offset (Ocn). Indeed, there are some other HO parameters, such as hysteresis margin, frequency offset, and A3 offset. Compared with all other HO parameters, Ocn is the parameter related with the neighbor cells; we can control the HO region between a specific neighbor cell and primary cell. Let us assume that a cell has three neighbor cells, N-A, N-B, and N-C. In this situation, we want to offload the cell to N-A because N-B and N-C is also processing heavy load. We adjust the Ocn for N-A for this goal, so that the offloading will be happening only with N-A. If the MLB use-case utilizes another HO parameters, we cannot control the load balancing per neighbor cell - HO region for all cells will be resized.  

In the MLB use-case, there are two threshold parameters: the overload threshold and the target threshold. The overload threshold is to assess which cells are overloaded. On the other hand, we check if a cell has enough capacity with the target threshold. If the load of a cell exceeds the overloaded threshold, we can call that the cell is overloaded. Or, if the load of a cell does not reach the target threshold, the cell is underloaded and has enough capacity to handle more load. Otherwise (i.e., the load is between the target threshold and overload threshold), a cell is moderate cell. One thing for those two thresholds is that the overload threshold is always higher than the target threshold. 

The MLB use-case defines the cell load as the number of connected UEs, simply. Since this is the primer use-case and for PoC, we just defined the load as the number of connected UEs. Of course, for the future, we can define the new load sophisticated and realistic. For example, the data traffic, the control traffic, and the PRB utilization can be candidates for the new load. 

The load balancing logic in the MLB use-case operates periodically. At each period, the MLB xApplication gets each cell’s load and neighbor cell information. This information is stored to R-NIB by KPIMON and PCI xApplications. Thus, the MLB use-case also deploys the KPIMON and PCI xApplications along with the MLB xApplication. Getting the information for each cell, the MLB xApplication assesses if a cell is overloaded (i.e., the load of a cell exceeds the overload threshold) or underloaded (i.e., the load of a cell is below the target threshold). For each result, the MLB logic works like below: 

• Condition 1: If the cell is underloaded, all Ocn values increase. 

• Condition 2: If the cell is overloaded, some Ocn values for the neighbor cells which face the load under the target threshold decreases; the Ocn values for the other neighbor cells are untouched. 

Increasing all Ocn values expands the HO region to all neighbor cells, which means that the connected UEs can be handed over conservatively. On the contrary, decreasing Ocn values for the underloaded neighbor cells expands the HO region to the neighbor cells. It brings about some connected UEs are forced to hand over to the neighbor cells. The Ocn values for the other neighbor cells which process the load more than the target threshold are not changed. It does not make sense to offload from the overloaded serving cell to the neighbor cells already overloaded or facing heavy load. 

While updating Ocn values, the MLB xApplication does not propagate it to connected UEs because it impacts the user performance. In order to update any HO parameter, a serving gNB should transmit the RRC connection reconfiguration message, which is the factor to decrease the performance. If the gNB sends the RRC connection reconfiguration message when the MLB xApplication sets the new Ocn, connected UEs should receive the RRC connection reconfiguration messages and set the new Ocn parameter. Thus, the MLB use-case defines two types of Ocn, Ocn_init and Ocn_rc. Ocn_init is the Ocn value initially configured to connected UEs, whereas Ocn_rc is the Ocn value that the MLB xApplication sets to the gNB but not to connected UEs. This means that UEs sends the A3 measurement report when A3 event condition meets with Ocn_init.  

In the MLB use-case, once a gNB receives an A3 measurement report message which is calculated with Ocn_init by a UE, the gNB evaluate A3 event condition again with Ocn_rc. If it is still in A3 event, the gNB proceeds the HO logic. Otherwise, the gNB considers that the UE is not in A3 event. As a result, the HO logic is not executed and the received A3 measurement report is dropped. 

However, since a UE only knows the initially configured Ocn (Ocn_init) not recent Ocn (Ocn_rc), some A3 measurement reports are missed or unnecessary from the Ocn_rc perspective. There are three possible scenarios: 

• Case 1. Ocn_init == Ocn_rc: a UE sends an A3 measurement report properly. 

• Case 2. Ocn_init > Ocn_rc: a UE sends an A3 measurement report earlier than expected. 

• Case 3. Ocn_init < Ocn_rc: a UE sends an A3 measurement report lately; there are A3 measurement reports missed. 

At first, if Ocn_init and Ocn_rc are the same, there is no issue. A UE sends an A3 measurement report at the correct timing. In the case 2, because Ocn_init is higher than Ocn_rc, a UE sends an A3 measurement report earlier than expected. I should be fine from the MLB perspective. After recalculating the A3 event condition with Ocn_rc, the gNB just drops an unnecessary A3 measurement report. However, the case 3 is critical because there are A3 measurement reports missed. For instance, Ocn_init and Ocn_rc are 0 dB and 2 dB, respectively. And, if a UE measured the received signal strength from a serving cell and the neighbor cell to -80 dBm and -79 dBm, respectively. With Ocn_init, the UE is not in the A3 event: -80 dBm + 0 < -79 dBm. On the contrary, the UE is in the A3 event with Ocn_rc: -80 dBm + 2 > -79 dBm. In this situation, the MLB use-case expects that the UE should send the A3 measurement report, but the UE does not.  

  To solve this problem, the MLB use-case sets the Ocn_init as +24 dB which is the maximum Ocn value. Since the Ocn_init is the maximum value, the case 3 in the above list does not occur. Only case 1 and case 2 can happen, so that the MLB use-case can guarantee that there is no missing A3 measurement report. Even though there are unnecessary A3 measurement report arrived due to the case 2, the gNB ignores them by recalculating the A3 condition with Ocn_rc. 

With above assumptions and definitions, the MLB workflow designs as shown in Fig. 1. Before creating an E2 session, a gNB sets the Ocn to the maximum value that is +24 dB. It can be set with RRC connection reconfiguration message when the UE is attached. Then, the gNB sends the E2 setup request message for the Policy service. After the E2 session is established, the MLB xApplication periodically runs the MLB logic for each gNB. The MLB logic gets the load monitoring result and neighbor cell information at each period1. After that, the MLB logic checks if a gNB is overloaded or underloaded, and then increases or decreases Ocn_rc, appropriately. The MLB xApplication sets the new Ocn_rc to the gNB. In order to set the new Ocn_rc, the MLB xApplication sends the E2 subscription request message to install the policy which defines the new Ocn_rc. Then, at the next period, if the MLB xApplication needs to update the Ocn_rc like Ocn_t1 to Ocn_t2, the MLB xApplication sends the E2 subscription message again with the new Ocn_rc to update the policy. In this case, the RIC Request ID in the subscription message should be the same for a specific neighbor cell. Since there is no policy update procedure defined in the E2 interface yet, we should override the policy by sending the new E2 subscription message again with the RIC Request ID. After the policy installation, once an A3 measurement report message arrives, the gNB calculates the A3 condition again. If the UE which sent the A3 measurement report is still in A3 event even with Ocn_rc, the gNB executes the HO. Otherwise, the A3 measurement report is ignored. 

III. E2 workflow

a. E2 setup phase

The first phase initially creates an E2 session between near-RT RIC and each gNB by exchanging the E2 setup request and response message. Since the E2T is responsible for the E2 setup in the near-RT RIC, each gNB sends or receives E2 setup or response message to or from the E2T, respectively. Fig. 2 shows the workflow of the E2 setup procedure in this phase. The gNB initiates this phase by sending the E2 setup request message. When the E2T receives the message, it creates or updates the gNB information to R-NIB such as RAN function definitions, interfaces, E2 node IDs, gNB IDs, etc.). Then, the E2T acknowledges it with the E2 setup response message. 

  To report what service each gNB supports on E2 interface for the MLB use-case, the E2 setup request message format is defined as Fig. 3. The E2 setup request message should have the RAN function definition. Since the MLB use-case only leverages the policy service, there is only one RAN function definition. The RIC policy type and name are #3 Connected Mode Mobility Control. The supported RIC event trigger style type is #1 Message Event. Since the gNB has to recalculate the A3 event condition when an A3 measurement report arrives, event trigger type should be set as a message event. The policy action ID and name should be #1 Policy for Handover Control and RIC action definition format type should be #2. The RAN parameters for the Policy Action are #1 Target Primary Cell ID and #10201 Cell-specific offset. Also, the RAN parameters for the Policy Condition are the same, #1 Target Primary Cell ID and #10201 Cell-specific offset. 

b. E2 subscription phase to install policy

After creating an E2 session between a RIC and a gNB, the MLB xApplication starts to subscribe with the gNB by sending RIC subscription request message to the gNB supporting the RC service model through the E2T. Fig. 4 shows an E2 subscription process. Once a gNB receives the RIC subscription request message, it sends the RIC subscription response message back to the MLB xApplication. Mostly, the RIC subscription phase is to install a policy to set Ocn_rc value. 

Fig. 5 depicts the RIC subscription request message format for the MLB use-case. In the RIC subscription request message, there is a RIC event trigger definition. The MLB use-case defines it with the RIC event trigger definition format 1. The sequence of message for event triggers has one item to monitor the RRC message for an A3 measurement report form a UE to its serving gNB. Since the UE sends an A3 measurement report with UL-DCCH RRC message, RRC message ID field is set to UL-DCCH. The associated UE event field is defined with the Event Trigger UE Event information. The sequence of UE event for event triggering in the Event trigger UE event information has one item with UE event ID #2. And, the RIC subscription request message has a sequence of Actions. The MLB use-case has one action item which includes the RIC Action ID and type as #1 and Policy, respectively. Also, this item has RIC action definition defined with Action definition format 2 for policy service. Mainly this action definition format 2 contains the policy definition. The policy definition has two parts – one for policy action and the other one for the policy condition. In the policy action definition, the policy action ID should be the unique ID per gNB. RAN parameters in the policy action are #1 primary target cell ID and #10201 cell-specific offset. In the policy condition definition, there are also same RAN parameters. The test condition for the primary target cell ID is contains, while the test condition for the cell-specific offset is difference. This means that if the target primary cell ID is in the gNB’s neighbor cell list and the Ocn_rc is different from the Ocn_init, the gNB will recalculate the A3 event condition with the Ocn_rc for the target neighbor cell defined in the policy action definition.