A RIC Intelligens Load Balancing funkció az O-RAN által kidolgozott szabványrendszeren alapuló funkciója.
A Hagyományos vs RIC Intelligens Load Balancing
A hagyományos RAN hálózatok a Rádió Erőforrás Management (Radio Resource Management – RRM) és forgalom management inkább cella centrikus mint UE centrikus. A szolgáltatók lehetőségei korlátozottak néhány paraméter beállitásra ami inkább reaktiv mint proaktiv megoldásokat eredményez.
Az új RIC xApp és rApp mikroszervizek alkalmazásával valamint a ML algoritmusok használatával ezek a korlátok leküzdhetőek és egyedi innovativ megoldások érhetőek el.
Az egyik legfontosabb RRM funkció a RAN hálózatokban a Load Balancing, melynek eredményeként a túlterhelt cellák forgalma átterelhető a szomszédos kevésbé forgalmas cellákba.
A Deep Learning-et és az xApp-ok adatvezérelt zárt hurkú (closed loop) technológiáját alkalmazva dinamikusan előre észlelhető és igy elkerülhető a service cella torlódása. Az alkalmazásoknak köszönhetően szintén előre jelezhető és elkerülhető a felhasználók átterelése (load balancing) egy olyan cellára mely előreláthatóan torlódni fog mielőtt vagy miután az egyes UE-k oda át lennének mozgatva. Ezzel elkerülhető a további torlódás vagy kör-körös torlódás és ping-pong handovereek, ami minőségromlást okoz.
Load Balancing Fukciók
A RIC torlódás managelő Load Balancing funkciója két részre bontható:
- Torlódás detektálás (Oveload Detection)
- Forgalom terelés (Traffic Steering)
Torlódás Detektálás
Az új módszer alapja a hagyományos torlódás felismerésének az elórejelzése. A hagyományos torlódás szintjét a szolgáltatók határértékekkel (threshold) határozzák meg és az adott torlódás szint elérésekor indul a forgalom átmozgatása a szomszédos alacsonyabb forgalmú cellákba.
Az egyik lehetséges load balancing megoldás a Deep Learning technológia alklamazása a dinamikus torlódás előrejelzésre. Erre az egyik legmegfelelóbb a Long Short-Term Memory (LSTM) alapú Deep Learning modell. Az LSTM az Repeated Neurális Network (RNN) egy típusa, amelyet kifejezetten szekvenciális adatok, például idősorok, beszéd és szöveg kezelésére terveztek. Az LSTM-en alapuló deep learning startégia képes a túlterhelés előrejelzésére és ezáltal a forgalom irányításának elősegitésére.
1-Ábra. Hagyományos Load Balancing és ML Based Load Balancing
2.Ábra. ML Based Load Balancing Funtcions
Torlódás Detektálás
A RIC Deep Learning technológiája a torlódás detektálásához a Distributed Unit (DU) által generált KPI-ket is felhasználja a döntéshozatalnál. Az egyik ilyen performance indikátor az RRC Connection (RRC) Utilization ami a cellához kapcsolódó UE-k számát mutatja a maximális számú UE kapcsolathoz viszonyitva. Ezzel a cella kihasználtsága a UE-k részéről mérhető.
Ez alapján a torlódás detektor funkció kategorizálja a cellát : Nem torlódó, Alacsony forgalmú és Túlterhelt kategóriákba.
Ezt az információt a torlódás detektor továbbitja a Forgalom management funkcióhoz ahol a megfelelő UE-k és cél cellák kiválasztása a következő lépés.
A megfelelő UE kiválasztásásnak alapja a DU-tól származó vételi jelszint (RSRP). A cellához kapcsolódó összes UE az áltauk mért RSRP jelszint alapján rangsorban kerül, majd a legalacsonyabb jelszintű UE lesz kiválasztva először az áthelyezésre.
A target cellák is rangsorba kerülnek. Szintén a UE-k által mért jelszintek (RSRP) alapján. Itt a legerősebb jelszintű szomszéd cella lesz előre sorolva. Ezután a CU / UP (CP – Control Plane és UP – User Plane) erőforrások használata kerül felmérésre és a legalacsonyabb CU/CP terhelésű cella lesz kiválaszva először. Ha nincs torlódás mentes traget cella a forgalom tereléshez akkor további torlódás mérés és értékelés után egy bizonyos szintű torlódást megengedhető a target celláknál ami még nem befolyásolja a felhasználói élményt. Ha megvan a target cella akkor a következő lépés a UE vagy UE-k target cellára való átmozgatása handoverrel. Ha nincs egyetlen target cella sem ami megfelelne a kritériumoknak akkor a kiválasztott UE vagy UE-k lekapcsolása történik a service celláról, vagyis UE Release Requested.
A Torlódás Detektálás és Forgalom Terelés Folyamata
3.Ábra. Near-RT RIC és xApps architecture
A Torlódás Detektálás és Forgalom Terelés Folyamata a következő:
- Az KPI Monitoring xApp a Subscriber Manageren keresztül begyüjti szükséges KPI-ket a DU-tól.
- A KPI Monitoring xApp-hoz megérkeznek a kért KPI-k a E2 interfészen keresztül a DU-tól.
- A KPI Monitoring xApp feldogozza a KPI-ket és továbbitja a feldogozott adatokat az Overload Detection xApp-felé.
- Az Overload Detection xApp a feldolgozott KPI-ket továbbitja az ML Prediction Module-hoz ahol a LSTM neuro network felhasználásával a torlódás predikció elkészül a megfelelő algoritmusok alapján.
- A torlódás predikció továbbit’va leszásra kerül az Overload Detection xApp-hoz ami igy már komplett torlódás predikcióval rendelkezik és a Traffic Steering xApp-nak továbbitja a rendelkezésére álló adatokat.
- A Traffic Steering xApp az Overload Detection információk alapján értesiti a RAN Control xApp-ot a döntéséről amit a RAN Control xApp végrehajt (például handover a target cella felé) a Conflict Resolver-en keresztül.
- A Conflict Resolver feladata, hogy ha több intézkedés is történik egyidőben vagy közvetlenül egymás után akkor az egyes parancsok ne ütközzenek egymással illetve ne okozzanak performance romlást. A Conflict Resolver ha bármilyen KPI illetve performance romlást detektál egy intézkedés utásn akkor azonnal jelzést küld erről az operátor felé és ha engedélyezve van akkor azonnla visszaállitást is végez az legutolsó intézkedésből (Rollback).
- Az E2 interfészen keresztül a BBU megkapja az utasitást, amelyet végrehajt. Az eredményről KPI performace report készül periodikusan és továbbitódik a KPI Monitoring xApp felé ami elemzi az eredményt és ennek megfelelően tovább intézkedik.