Page History

Table of Contents

absoluteUrl	true

...

Association RAN to Instance

There are 2 places where E2M search for a living E2T Instance to associate it with RAN:
1. When a Setup Request from Dashboard arrives. This is for New RAN or for existing RAN which isn’t associated with any E2T Instance
2. When KA kills an E2T Instance and divides its RANs to other living E2T Instances
E2M chooses the E2T Instance with the least # of RANs.
Anyhow, until the Routing Manager isn’t synced with this association, it isn’t stored in E2M DB
Setup Request from Dashboard which fails either in choosing any E2T Instance or updating the Routing Manager, either for New RAN or existing which isn’t associate with any E2T Instance , returns special rejection error is telling the Dashboard to try later.
In case KA failure in choosing the E2T to the RAN, the RANs are inserted to Orphan List. See below how E2M handle with Orphan List. It is usually when the last E2T Instance fails.

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

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.

There are 3
RAN which is already associated with E2T Instance, stays with this association, even if it lost connection. E2M will try to re-new the Setup until Max Retries (Configurable) reached.
There are 2 places where E2M dissociate RAN:
1. When the Max Retries of sending Setup arrives, as a result of Lost Connection. The RAN is disassociate.When a request to Red Button arrives (See below)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
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 Routing Manager RM in the following flows:
1. When a new E2T Instance Initialized.
2. When a new RAN is added 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 associates disassociates list of RANs to other existing E2T Instance (Or dissociate list of RANs since it was the last E2T Instance) and also delete E2T Instance
4. When RAN lost connection and it exceed the Max Retry.connection
5. When a Red Button is requested - E2M dissociate all RANs
6. When existing E2T Instance initialized, it is the first, and list of Orphans “are waiting” for it - E2M associates list of RANs to this E2T Instance 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 Interface Design
There are 4 REST APIs Routing Manager published. U can read their Swagger at Routing Manager Swagger

...

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.

As described above, when last E2T Instance fails, its RAN are entering the Orphan List.
The KA Job, after sending the KA request and after checking there is no any E2T which doesn’t respond and need to be killed. examines the Orphan List is not empty and there is a E2T Instance to associate them. If yes, it is updating the Routing Manager and if OK - sends Setup on each RAN
Also, on Red Button, we empty the Orphan List.

To summarize, RAN can be in the following:

RAN can be in the following state:

Connected
Connected Failure
Disconnect, but with Count of Retry less then Max, Usually this is in case RMR Failure

RAN should be in a Disconnect State, while Count of Retry is 0.

RAN can be in the following state: