0% found this document useful (0 votes)
88 views14 pages

Rahul Banerji (Samsung Open Source Team) : (O-RAN - WG3.E2AP-v01.01)

The document discusses changes and additions needed to support new functionality in the E2AP 1.01 specification, including: - Adding an E2 Node configuration update procedure to update application-level configuration between E2 nodes and RICs. - Changes to existing protobuf messages and additions of new messages to support the new E2 node configuration feature. - Modifications to the E2Manager, E2Term, and E2Sim components to handle the new messages and update flows. - Ensuring backwards compatibility by supporting both new and old message versions.

Uploaded by

mohit
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
88 views14 pages

Rahul Banerji (Samsung Open Source Team) : (O-RAN - WG3.E2AP-v01.01)

The document discusses changes and additions needed to support new functionality in the E2AP 1.01 specification, including: - Adding an E2 Node configuration update procedure to update application-level configuration between E2 nodes and RICs. - Changes to existing protobuf messages and additions of new messages to support the new E2 node configuration feature. - Modifications to the E2Manager, E2Term, and E2Sim components to handle the new messages and update flows. - Ensuring backwards compatibility by supporting both new and old message versions.

Uploaded by

mohit
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 14

E2AP 1.

01
(O-RAN.WG3.E2AP-v01.01)

Rahul Banerji (Samsung Open Source team)


Agenda

› New Flows Introduced


› Flows Affected
› Suggested Protobuf changes
› E2Mgr changes
› E2Term changes
› E2Sim
› Backwards Compatibility
E2 Node Configuration

› Added as part of new spec


› The purpose of the E2 Node Configuration Update procedure is to update application level E2 Node
configuration data needed for E2 Node and Near-RT RIC to interoperate correctly over the E2
interface.
› Format:

E2 Node conf Update E2 Node conf Update Ack


Flows Affected

› E2 Setup req/Resp  RIC Service Update only

Before Ran Function OID

Now
Code Flows
Suggested Protobuf/Rnib Changes
New Message
message RanFunction {
uint32 ran_function_id = 1; message E2NodeComponentConfig{
string ran_function_definition = 2; uint64 e2NodeComponentID = 1; //optional
uint32 ran_function_revision = 3; Existing messages oneof e2NodeComponentType{
string ran_function_oid = 4;//new EnbType enbtype =2;
modified GnbType gnbtype=3;
}
}
//or skip as redundant
message Enb{ string e2nodeComponentConfigUpdate = 4;
EnbType enb_type = 1; } //New
repeated ServedCellInfo served_cells = 2;
repeated string gu_group_ids = 3;
repeated E2NodeComponentConfig e2NodeComponentConfig = 4; //new
}

• The following changes will need to be


message Gnb{ added to rnib
repeated ServedNRCell served_nr_cells = 1; • Associated DB function calls to retrieve
repeated RanFunction ran_functions = 2; e2config from DB has to be added in
GnbType gnb_type = 3; sdl/rnibreader/rnibwriter layer
repeated E2NodeComponentConfig e2NodeComponentConfig = 4; //new • Removed as part of Design 2.0 ->
}
E2NodeConfigHandler xApp

› All E2 Configuration handling will be done by this xApp


› The E2Manager will just forward all ‘E2 Node Component Configuration
Update List’ directly to this xApp
› xApp will handle all storage (to rnib or somewhere else) and will support
the following standard rest Api calls to E2Mgr (or other xApps):
› GET /e2config/gnb/{ranName} (xapp->e2mgr)
› POST /e2config/gnb/{ranName} (e2mgr->xapp)
› GET /e2config/enb/{ranName} (xapp->e2mgr)
› POST /e2config/enb/{ranName} (e2mgr->xapp)
› GET /e2config/health (Heartbeat of e2config xapp | e2mgr->xapp)
› The entire business logic to decode and store E2 node config should be
proprietary and implemented by the user (this will not be a part of O-RAN
SC due to licence conflicts)
› This xApp must be stateless, and all of its state must be persistent for the
sake of consistency
E2Mgr Main Changes

› New RMR API added for E2Configuration changes


› This api was not a part of e2ap1.0 so no issues with backward compatibility

› Protobuf changes will take care of database layer as well as storage


› E2Mgr to add a queue to store e2config msg in case the config xApp crashes or goes offline
temporarily
› The queue will be in memory by default, but interface will be provided for future extension using
external libraries
› New http api to fetch E2Configuration (stretch goal)
› GET /e2config/enb/{ranName} //stretch
› GET /e2config/gnb/{ranName}
E2Mgr Main Changes

› E2setup model xml file needs to be changed, add ran OID and e2config pdu to be kept as string

› Check needs to be added for new fields in the e2setup request and e2 service update and
depreciation warning to be generated if using e2ap1.0

› If api call comes for e2ap1.0, all e2ap1.1 new fields will be set to null

› Need to add new UT for e2setup for newly added fields (e2config and ranF OID)

› Not handling edge cases where e2ap1.0 and 1.1 are used by the same e2node at same time, i.e
e2ap1.0 based setup request but config update request follows e2ap1.1
E2Term

› ASN support needs to be added for xml to per encoding and vice versa for associated affected flows

› Not sure how asn handles optional fields yet


› need to explore w.r.t backwards compatibility

› Need to add support for associated flows (both on sctp and e2mgr side)
› Will not be supporting Prometheus counters as part of initial release
E2SIM

› Add support for e2config msg and oid field


› E2setup
› E2confupdate
› E2serviceupdate
Backwards Compatibility

› E2term will need to add support for new messages and implement the interface to talk with
e2config xapp

› Update E2setup and ric service query model files as well as need to add check to all associated
flows

› E2Mgr, will keep a check for optional fields and log a depreciation warning, e.g for ran oid, and
e2config pdu
› Thank You

› Any questions?
E2 Node Connection

› Added as part of new spec


› The purpose of the E2 Connection Update procedure is to update the E2 interface
connection between the E2 Node and Near-RT RIC
› Format:

E2 connection Update E2 connection Update Ack

You might also like