...
Table of Contents | ||
---|---|---|
|
Abbreviation
RM | Routing Manager |
E2T | E2 Terminator |
General
In R3 the 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 requested to sends the RIC Setup Request, E2M chooses the E2M with the least # of RANs, Inform to RM the association and associate this RAN to this this E2T Instance in DB
When RAN is stopped, E2M dissociation it from the E2T InstanceLost 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 divides its Associated RANs to other living E2T Instances and kills (Through K8S) this instance. Probably E2M will receive a new E2 Initialization to E2M. E2M Registers it in the E2M DB, 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 / dissociationdisassociation, E2M informs Routing ManagerRM. Routing Manager RM updates the Routing tables and publish an updated RMR to all RIC.When there are no living E2T instance, the RAN which should connected are treated as Orphans. E2M should associate them to new living E2T instance when available
- 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 (100 Milliseconds) 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 (400 Milliseconds) - E2M “kills” it:
E2M asks the K8S to kill the E2T Instance.
E2M divides the RANs associated with this “dying” instance to other living E2T Instances. If not found - they are treated as Orphans.
E2M Updates the Routing Managers about the association of the RANs to other E2T Instances, about the Orphans (if any) and about the deletion of the dead E2T Instance.
If success - E2M stores in its DB the new associations and sends Setup for this RANs through the updated RMR
There is some logic how to sync between parallel flows - Killing an E2T Instance parallel to E2 Initialize arrives. See below.
...
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 | State = Routing Manager Failure |
---|---|---|---|
KA decide to kill E2T instance |
| (Transient State, should not occurs)
|
|
E2 Initialize |
|
|
|
KA Response |
|
|
|
Association RAN to Instance
...