Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Keep Alive

  • Each Configurable time (100 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 (400 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.

...

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

  • Active (normal state). Selector mechanism can choose it.

  • To be deleted - KA moves it to this state in DB the moment is understand it is dead. Selector mechanism can’t choose it. It is stay in stayed in this state until Routing manager success (in this case the entire entry is deleted) or failure, which is moved to the next stepE2T 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
  • ?????

...

  • 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

  • There These are 3 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

...

  • 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 DesignDesign#GetAllE2TRequest
  • There are 4 REST APIs Routing Manager published. U can read their Swagger at Routing Manager Swagger

...