[ORAN] FlexRIC Sevice Model (3): RIC 對應程式的修改

作者： -
在完成 Service Model 的定義之後,
我們需要透過程式對所定義的 Service Model 進行操作,
考慮到 FlexRIC 的實作架構, 我們在修改 xApp 和 E2 Agent 的程式前,
要先修改 FlexRIC 相關的程式, 以提供 xApp 和 E2 Agent 串接的支援,
在此實作中, 我們以 Indication 作為開發的應用,
此應用中, xApp 負責送出訂閱 Indication 的需求,
E2 Agent 則將數值填入 Indication Message 中, 並定期發送.
在 FlexRIC 官方網站中, 提供教學的連結如下:

在 FlexRIC 中, 整體的資料交換流程如下:
來自: https://gitlab.eurecom.fr/mosaic5g/flexric/-/wikis/Create%20a%20xApp

在上述的流程中, 我們可以歸類於以下 5 個步驟:
  1. E2 Agent 透過 E2 Setup 向 FlexRIC 註冊 (ID, 以及所支援的服務)
  2. xApp 向 FlexRIC 進行註冊 (為自定義的 E42 介面)
  3. xApp 向 E2 Agent 註冊 Indication 服務 (Subscription Request)
  4. E2 Agent 根據訂閱的資訊以及時間間隔, 進行資料回報
  5. xApp 收到資料將數值存入 SQLite (不是標準的 O-RAN 流程, 在此先略去)
  6. xApp 向 E2 Agent 刪除 Indication 服務 (Subscription Delete Request)
在 FlexRIC 對應的 c-code 程式中, 為了加入一個新的 Service Model,
我們也要進行相對應的修改, 包含三個部分: xApp, RIC, 和 E2 Agent,
對應的資料夾位置為: ~/flexric/src/xApp/, ~/flexric/src/ric/iApps/, ~/flexric/examples/,
我們從 xApp 端要進行的修改開始, 這邊所指的 xApp 並非收值的 xApp,
而主要的修改在於 xApp 和 RIC 之間溝通的部分, 包含 FlexRIC 定義的 E42 介面:
(紅字為修改的部分, 藍字為註解)
  • ~/flexric/src/xApp/e42_xapp.c
    // 讓 RIC 平台可以看懂新建立的 Service Model
    // 需要匯入 header 檔, 並修正判斷項次
    #include "../sm/new_sm/new_sm_id.h"
    ...

    static
    bool valid_ran_func_id(uint16_t ran_func_id)

      if(ran_func_id == SM_SLICE_ID 
          ..
          || ran_func_id == SM_NEW_ID
        )
        return true;
      return false;
    }

  • ~/flexric/src/xApp/e42_xapp_api.c
    // 把 Service Model 的 ID 加入判斷式, 按照之前設定, 此數值為 148
    static inline
    bool valid_sm_id(global_e2_node_id_t* id, uint32_t sm_id)
    {
      assert(id != NULL);

      // Only for testing purposes
      assert(sm_id == 142 || sm_id == 143 || sm_id == 144 || sm_id == 145 || sm_id == 147 || sm_id == 148);

      return true;
    }

  • ~/flexric/src/xApp/msg_handler_xapp.c
    // 考慮到對應 Indication 的功能
    // 將 Indication type 中對應的型態加入新的 Service Model
    #include "../sm/new_sm/new_sm_id.h"
    // E2 -> RIC
    e2ap_msg_t e2ap_handle_indication_xapp(e42_xapp_t* xapp, const e2ap_msg_t* msg){
         ...
         assert(msg_disp.rd.type == MAC_STATS_V0 
                 ...
                 || msg_disp.rd.type == NEW_STATS_V0
               );
     }
接下來, 我們要修改 RIC 平台中的 iApp, 
在 FlexRIC 中, iApp 可以想像成 RIC 平台的管理介面,
負責將運作過程中的 log 與資料記錄下來或顯示 (我們之後會解釋),
提供 RIC 平台管理, 或是 xApp 除錯的對應功能.
  • ~/flexric/src/ric/iApps/influx.c
    #include "ric/iApps/../../sm/new_sm/ie/new_data_ie.h"    // for new_ind_msg_t

    void notify_influx_listener(sm_ag_if_rd_t const* data){
      assert(data->type == MAC_STATS_V0 ... || data->type == NEW_STATS_V0);
     
      if(data->type == MAC_STATS_V0){
      ...
      } else if (data->type == NEW_STATS_V0){
        new_ind_msg_t const* new = &data->new_stats.msg;

        char stats[1024] = {0};
        to_string_new_ngut(&new->ngut, new->tstamp, stats, 1024);

         int const rc = sendto(sockfd, stats, strlen(stats),  MSG_CONFIRM, (const struct sockaddr *)
    &servaddr, sizeof(servaddr));
         assert(rc != -1);
      }     else {
        assert(0 != 0 || "invalid data type ");
      }
    }

  • ~/flexric/src/ric/iApps/redis.c
    void notify_redis_listener(sm_ag_if_rd_t const* data){
      assert(data->type == MAC_STATS_V0 ... || data->type == NEW_STATS_V0);
    }

  • ~/flexric/src/ric/iApps/stdout.c
    // 當收到新的 Service Model 時, 將數值印出來
    // 注意: 資料型態為自定義格式 (new_ng_u_tunnel_stats_t)
    #include "ric/iApps/../../sm/new_sm/ie/new_data_ie.h"

    static
    void print_new_stats(new_ng_u_tunnel_stats_t const* new)
    {
      assert(new != NULL);

      if(fp == NULL)
        init_fp(&fp, file_path);

      
      char stats[1024] = {0};
      to_string_new_ngut(&new->ngut, new->tstamp , stats , 1024);

      int const rc = fputs(stats , fp);
      assert(rc > -1);
      
    }

    void notify_stdout_listener(sm_ag_if_r    d_t const* data)
    {
      assert(data != NULL);
      if(data->type == MAC_STATS_V0) 
        ...
      else if (data->type == NEW_STATS_V0)
        print_new_stats(&data->new_stats.msg);
      else
        assert(0!= 0);
    }

  • ~/flexric/src/ric/iApps/string_parser.c
    // 把 Service Model 的數值轉換成 String 的格式,
    // 這邊請參照之前 Indication Message 定義的格式填入
    // 注意: 資料型態為自定義格式 (new_ng_u_tunnel_stats_t)
    #include "ric/iApps/../../sm/new_sm/ie/new_data_ie.h"

    void to_string_new_ngut(new_ng_u_tunnel_stats_t* ngut, int64_t tstamp , char* out, size_t out_len)
    {
      assert(new != NULL);
      assert(out != NULL);
      const size_t max = 1024;
      assert(out_len >= max);
     
      int const rc = snprintf(out, max,
            "new_stats: tstamp=%ld,"
            "data1=%ld,"
            "data2=%ld,"
            "data3=%ld,"
            "data4=%ld"
            "\n"
            , tstamp 
            , new->data1
            , new->data2
            , new->data3
            , new->data4
            );
      assert(rc < (int)max && "Not enough space in the char array to write all the data");
    }

  • ~/flexric/src/ric/iApps/string_parser.h

    #include "../../sm/new_sm/ie/new_data_ie.h"

    void to_string_new_ngut(new_ng_u_tunnel_stats_t* ngut, int64_t tstamp, char* out, size_t out_len);

  • ~/flexric/src/ric/msg_handler_ric.c

    e2ap_msg_t e2ap_handle_indication_ric(near_ric_t* ric, const e2ap_msg_t* msg){
        ...
        assert(d.type == MAC_STATS_V0 
         ...   
         || d.type == NEW_STATS_V0);
    }
在修改完上述部分的程式後, FlexRIC 才算真的能夠了解新定義的 Service Model,
幸好, 多數的程式定義都和 Service Model 的內容格式無關,
因此, 建立 Sevice Model 的程式修改主要是出現在第一次建立的時候,
之後, 若是修改或是擴充自定義的 Service Model, 只需修改 stdout 的 iApp 就好,
在確定好 FlexRIC 對定義的 Service Model 支援後, 
我們修改測試的 E2 Agent 程式, 引入定義的 Service Model 資訊:
  • ~/flexric/examples/xApp/c/monitor/CMakeLists.txt
    // 編譯路徑的修改
    add_executable(xapp_new_moni 
                    xapp_new_moni.c
                    //... 如果有其他相關的 SM
                    ../../../../src/sm/new_sm/ie/new_data_ie.c
                    )
         
    target_link_libraries(xapp_new_moni
                            PUBLIC
                            e42_xapp
                            -pthread
                            -lsctp
                            -ldl
                            )

  • ~/flexric/examples/emulator/agent/test_agent.c
    // 將填值對應程式放入 read_RAN 的程式中,
    // 真實填值的程式位於: ~/flexric/test/sm/common/fill_ind_data.c
    // 我們將在之後說明此部分程式
    static
    void read_RAN(sm_ag_if_rd_t* data)
    {
      assert(data->type == MAC_STATS_V0 ...
             data->type == NEW_STATS_V0);

      if(data->type == MAC_STATS_V0 ){
        ...
      } else if(data->type == NEW_STATS_V0){
        fill_new_ind_data(&data->new_stats);
      }     else {
        assert("Invalid data type");
      }
    }

  • ~/flexric/examples/ric/near_ric.c
    // 加入 Service Model 的 ID
    const uint16_t NEW_ran_func_id = 148; //
以上大致完成 FlexRIC 架構中, 加入一個新的 Service Model 所需的修改,
接下來我們會繼續介紹 E2 Agent 和 xApp 所要做的對應修正.

留言

張貼留言

熱門文章

LTE筆記: RSRP, RSSI and RSRQ

作者： -
圖片
在一般通訊系統中, 我們常用 RSSI (Received Signal Strength Indication) 來表示訊號強度,  其單位為 (dBm), 可以轉換成功率大小 (mW): https://en.wikipedia.org/wiki/DBm [註] dBm 的原意即是: (dB) reference to (m)W, 因此, 1 W = 10*log10(1000mW) = 30dBm. 在 LTE 通訊系統中, 除了 RSSI 之外, 又額外定義了兩個用以標示訊號強度的數值: RSRP 和 RSRQ 以下, 我們將介紹 RSRP, RSRQ 和 RSSI 的不同： Reference Symbol Received Power (RSRP) RSRP 為 UE 量測 Reference Signals (RS) 的平均訊號強度, DRS 為基地台在下行訊號中, 於固定 RB (Resource Block) 上傳送的訊號, 由於這些訊號具有特定的傳送格式, 接收端便可以解出這些控制訊號的強度, 對於不同的相鄰基地台, 甚至是同一基地台不同的天線, 可以透過不同的 RS 配置, 讓使用者得知不同目標的量測數值, 如下圖所示: 紅色為 RS, 不同基地台或天線使用不同的 RS 排列方法, 可分開量測 來自: https://api.semanticscholar.org/CorpusID:22030582 RSRP 的回報由 UE 進行 Measurement Report, 回傳給基地台, 其中, 關於 Measurement Report 的設置定義於 RRC 的規範中, 我們之後有機會再提, RSRP 的量測, 通常在換手 (handover) 時進行量測, 用以指出目標基地台的訊號強度, 其中, UE 所量測的數值, 將藉由下表進行轉換 (訊號強度 (dBm) - (-140)), 並回報給 eNB 作為換手的決策使用: (3GPP Reference: TS 36.133) RSSI (Received Signal Strength Indication)  RSSI 是 UE 接收到的 wide-band 訊號強度, 包含 DRS 以及其他 RB 的訊號強度 (第一張
閱讀完整內容

[WiFi] WiFi 網路的識別: BSS, ESS, SSID, ESSID, BSSID

作者： -
圖片
在 WiFi 網路中, 一個基本的識別方式就是 SSID (Service Set Identifier), 也就是我們口語中的 "WiFi 網路名稱", 然而, 此網路事實上是一個服務集合 (Service Set) 的概念, 而一個服務群集, 也可以對應到一個基本的無線網路, 包含: 一個 WiFi AP 以及多個 WiFi 使用者, 對於剛剛這種簡單的網路架構, 又稱為 BSS (Basic Service Set), 若是多個 BSS 都使用同一個 SSID, 則稱為 ESS (Extend Service Set), 如下圖所示: 來自: https://ppt.cc/fXIvex 對於 ESS 來說, 有兩個假設, 第一, 底下的 BSS 必須是相鄰 (有交疊範圍) 第二, 這些 BSS 有網路連線, (有線或是無線都可以) 這兩個假設是為了完成 ESS 的主要功能, 也就是換手 (handoff), 當裝置在同一個 ESS 下不同 BSS 範圍中移動時, 可不必重新連線就可以繼續傳輸. 這樣的流程事實上是由原本服務的 AP (BSS 1), 把使用者的資料轉傳到換手目標的 AP (BSS 2), 資料流程為: DS -> BSS 1 -> BSS 2 -> Sation, 也因此, 兩個 AP 之間必須連線, 同時切換時間也不能太久 (相鄰條件), 那麼在上述例子中, 如何知道 BSS 1 和 BSS 2 的差別呢? 在 WiFi 網路中, 為了完成這件事情, 所以就有了 ESSID 和 BSSID, ESSID 如上所述, 對應於 ESS 所使用的 SSID, 至於 BSSID (通常是 WiFi AP 的 MAC 位址) 來區分同個 SSID 下的網路. 反過來說, 同一個 WiFi AP 也可以擁有多個 SSID, 此功能稱為 VAP (Virtual AP), 此時, 一個 WiFi AP 會虛擬出多個 BSSID, 通常作法就是從原有的 MAC 位址往上加一, 作為多個不同的 BSSID. 這些 VAP 會對應到 WiFi AP 中的不同 VLAN 中, 因此, 我們可以給他們不同的網路設定, 例如: 流量, 安全性, 頻寬等,
閱讀完整內容

LTE筆記: 波束成型 (beamforming) 和天線陣列

作者： -
圖片
在5G的技術中, 其中一個新被引入的通訊技術就是波束成型 (beamforming), 波束成型技術可以大略的分成兩種: 第一種、藉由量測到的通道係數, 設計傳送參數 (precoder), 最佳化通道 第二種、透過多天線的相位偏移 (phase shifter), 決定電波傳遞強度模 在文章中, 會著重介紹第二種波束成型的架構, 在第二種波束成型的架構中, 所使用的是電磁波干射的物理特性, 簡單來說, 透過電磁波的建設性干涉與破壞性干涉, 我們就可以在某個方向上產生一個較強的訊號, 而在其他方向上減低此訊號的影響. 來自:  https://en.wikipedia.org/wiki/Phased_array 在上圖中, 我們可以發現這種波束成型架構的兩個需求: 1. 必須有多根天線服務同一筆傳輸訊號 2. 每個天線都必須要有一個相位調節器 (phase shifter)
閱讀完整內容