Description

E2Term and E2Manager to adapt to WG-3 E2 Standard as described in the latest  E2AP document. 

Requirements

The E2M and E2T must be compiled with the latest version of E2AP and E2SM ASN files

The E2T and E2M must support the following E2AP Global Procedures:

• E2Setup Request -> Only from RAN -> RIC
• E2Setup Response Only from RIC -> RAN ( we need to consider Global RIC ID)
• E2Setup Failure Only from RIC -> RAN
• E2 Reset Request bi directional RIC <-> RAN
• E2Reset Response bi directional RIC <-> RAN
• RIC Service Update family- Not supported in R4
• RIC Service Query  - not supported in R4
  **

There will be a dedicated Epic for reverse of direction flow.

The E2T must support the following E2AP Functional Procedures:

• RIC Subscription Request RIC -> RAN
• RIC Subscription Response RAN -> RIC
• RIC Subscription Failure RAN -> RIC
• RIC Subscription Delete Request RIC -> RAN
• RIC Subscription Delete Response RAN -> RIC
• RIC Subscription Delete Failure RAN -> RIC
• RIC Indication RAN -> RIC
• RIC Control Request RIC -> RAN
• RIC Control Acknowledge RAN -> RIC
• RIC Control Failure RAN -> RIC 

The support need to be passive, it means that the E2T does not open the payload of this message.

It just gets the message from the calling xApp in RMR, passes it to the relevant gNB via E2 protocol and sends back the response via RMR to the calling xApp.

RNIB Support

The E2M must store the gNB details in the RNIB.

In difference that the previous versions the data is in the Setup Request that comes from the RAN and not in the response.

The E2M must store in the RNIB the gNB data where the KEY is E2 Node ID  

 The E2M must store in RNIB the list of functions that the gNB supports.

RNIB Queries

• Get E2 Nodes  List - Returns a list of all gNB IDs (E2 Node IDs) that are stored in the RNIB
• Get E2 Node -  Key is E2 Node ID and Returns the gNB and the list of functions that are associated to it

Global RIC ID Support

 In the new version of the E2AP protocol the RIC has a Global RIC identifier that is defined in the spec.

Each response that the RIC sends has to gNB node has this ID as part of it.

• We should find the way how this ID gets to the RIC? Configuration file? APIs? O1/A1?
• We need to agree with Thoralf where we store this ID in the RIC (RNIB?) and we obtain it (API?)
• We need to make sure to return this ID in every message that requires it

9.2.4 Global RIC ID

This IE is used to globally identify an Near-RT RIC.

Limitations

In the co-create version of the E2 protocol the Setup Request and Response messages included detailed Information Elements about the Cells and the Neighbours of the gNB.

This information no longer exists in the new Setup message therefore all the RNIB queries that returned cell information in Amber Release will no longer function.

Backwards Compatibility

There is no requirement to support eNBs in Bronze, therefore unless otherwise specified the E2T and E2M will handle connections to gNBs only.

In case it will be required to support eNBs, the E2T and E2M will support pure X2 protocol and not the co-create version of E2.

------------------------------------------------------------------------------------------  E N D ------------------------------------------------------