Document status	DRAFT
Document owner	Avinoam Bernstein
Owner Details	+972-54-2891166, ab600d@intl.att.com

Abbreviation


RM	Routing Manager
E2T	E2 Terminator
KA	Keep Alive

General

The RIC contains several E2T Instances, each one of them manages several RANs. E2M is the one which manages them. It means:

When E2T Instance starts running and finished its Initialization, it sends RMR message (E2 Initialization) to E2M. E2M Inform to RM and Registers it in the E2M DB.
When a new RAN is sends the RIC Setup Request, E2M Inform to RM the association and associate this RAN to this E2T Instance in DB
When RAN Lost connection, E2M Inform to RM the disassociation and disassociate this RAN to this E2T Instance in DB
E2M Handle Keep Alive (KA) RMR handshake with the E2M Instances. When an Instance doesn’t respond for period of time to KA Request from E2M, E2M kills (Through K8S) this instance, signs all the RANs associated with it as Disconnected, delete the E2T address from DB and inform RM the disassociation.
For any new or dead E2M Instance, and for any RAN Association / disassociation, E2M informs RM. RM updates the Routing tables and publish an updated RMR to all RIC.
When existing E2T Instance restarts and sends RMR message (E2 Initialization) to E2M. E2M Inform to RM the disassociation of all its RANs and disassociate them in DB
If the RM isn't accessible, "positive" scenario (New E2T Address, new RAN Setup) are not executed, waiting for additional E2T will sends its Address or the RAN renew its Setup. But "negative" scenario (Like Lost connection, KA kills E2T, Existing E2T restarts) are executed. When RM will restarts and query E2M, it will sync with the E2T and RANs association and publish RMR to all RIC.

Keep Alive

Each Configurable time (500 Milliseconds currently) E2M sends broadcast KA Request to all living E2T Instances through the RMR.
Every E2T Instance which gets it, responds with KA Response.
If any E2T Instance doesn’t respond for a configurable time (1500 Milliseconds currently) - E2M “kills” it:
- E2M asks the K8S to kill the E2T Instance.
- E2M disassociate the RANs associated with this “dying” instance, signs them as disconnected and Updates the RM about the disassociation of the RANs and about the deletion of the dead E2T Instance.
There is some logic how to sync between parallel flows - Killing an E2T Instance parallel to E2 Initialize arrives. See below.

E2 Initialization

As described, when E2T Instance starts running and finished its Initialization, it sends RMR message (E2 Initialization) to E2M.
If this is a new address (IP) then -
- E2M updates the Routing Manager there is new E2T Instance
- If success - E2M Registers it in the E2M DB. If fail - E2M does nothing. E2T will sends another time E2 Initialize to E2M if no KA Request arrives during the 500 Milliseconds after the previous E2 Initialize.
If this is an existing E2T Instance, then
- E2M disassociate the RANs associated with this "restart" instance, signs them as disconnected and Updates the RM about the disassociation of the RANs
There is some logic how to sync between parallel flows - Killing an E2T Instance parallel to E2 Initialize arrives.

Sync between KA Killing, E2 Initialize arrives and KA Response

E2M manages States that E2T Instance can be in the DB:

Active (normal state)
To be deleted - KA moves it to this state in DB the moment is understand it is dead. It is stayed in this state until E2T shutdown process completed.

In case E2T initialize arrives and this E2T is in “To be Deleted” state - Don’t do anything. E2T will send another E2T initialize in case no KA during 300 milliseconds after E2 Initialize.

current State / trigger	State = Active	State =To be Deleted
KA decide to kill E2T instance	Move to “To be deleted” State; Try to find POD in K8S and if found kill it; Even if fails - continue. Disassociate all RANs, Delete the E2T Address at all. Update RM, if fail – error but continue In order to distinguish between 2 sequences KA cycle, KA updates the Timestamp when it moves the RAN to this state, and sees it wasn't stayed in this state too long. It is called E2 Instance Deletion Timeout MS (Micro seconds)	(Transient State, should not occurs) Do all the steps Just like in Active (Previous Cell), except updating the state which is already “To be Deleted”.
E2 Initialize	Don’t update RM Disassociate all RANs and inform RM	Ignore: E2T will send another E2 Initialize if no KA Request after previous E2 Initialize for some times.
KA Response	Update Timestamp	Ignore. This Instance is about to deleted
E2M Restart	Update Timestamp	?????

Association RAN to Instance

The only place where RAN is associated with E2T address is when Setup Request arrives.
It is stored in DB - in 2 places

This RAN is added to the list of RANs served in the E2T Object
The E2T Address is added to the RAN Object

The RM is informed on this Association between RAN and the E2T address
But also if RM isn't accessible, E2M doesn't rollback nor sending Setup Failure to remote RAN - since the simple way to ask the E2T to send Setup Failure not through the normal MEID flow is quite complicated.

Dissociation RAN

These are the places where E2M dissociate RAN:
1. When a Lost Connection arrives from E2T
2. When existing E2T Instance restart and E2M receives E2T Initialize message
3. When KA decides to kill an E2T Instance
4. When Red Button tears down all RANs.
In all these places - E2T address is cleared from the RAN(s) object(s), the RAN(s) removed from the list of RANs served in the E2T Object
The RM is informed

Interface to Routing Manager

RM updates the Routing Table in the following ways:
1. Add or Delete E2T Instance - There are 2 RMR messages that are “Broadcast”:
  1. KA Request
  2. Clear all Connection (“Red Button”)
2. Associate RAN(s) to E2T Instance (it can overrides previous association)
3. Delete RAN association

E2M updates the RM in the following flows:
1. When a new E2T Instance Initialized.
2. When a a Setup Request arrived from the RAN and associated to existing E2T Instance
3. When KA kills existing E2T Instance - in this update it also disassociates list of RANs and also delete E2T Instance
4. When RAN lost connection
5. When a Red Button is requested - E2M dissociate all RANs
6. When existing E2T Instance initialized, it disassociates list of RANs served by this Instance
Also, when RM initialized, it queries E2M on the mapping between E2T and RANs and update the RIC with the new RMR. See E2 Manager R3 Interface Design#GetAllE2TRequest
There are 4 REST APIs Routing Manager published. U can read their Swagger at Routing Manager Swagger

Red Button

When Red Button request from Dashboard arrives, E2M inform Routing Manager to disassociate all RANs
E2M sends “broadcast” the Close all connections to all E2T Instances.