Paper


## Intro

해당 논문은 Private 5G Network에서 Intent Based Network 관리를 Natural Language를 통해서 수행할 수 있는지를 보인 논문이다. 해당 논문에서는 Design과 실제 구현 사례를 3개의 usecase에 적용한 사례를 보인다. 해당 논문은 2023년에 publish 되었지만, LLM을 적용하지는 않았고, 이에 대한 적용은 Future Work에서도 고려하고 있다고 언급한다.

## Background

### Intent Based Network(IBN)

Non-Public Network(NPN)은 관리자에 의해서 자유롭게 설정이 가능하다는 장점을 갖고 있다. 하지만, 5G를 다룰 수 있는 숙련된 기술자가 아닌 경우 이를 효율적으로 운용하는데에는 한계가 있다. 따라서, 이러한 문제를 해결하기 위해서 **Intent Based Network(IBN)**이 제안되었다. IBN을 활용하면, private 5G network를 네트워크에 대한 지식이 없이도 단순한 의도(Intent)를 작성하는 것만으로 문제를 해결할 수 있다. 즉, IBN의 목표는 Network가 하는 일을 최대한 추상화하여 private network 관리자의 운영을 단순화하는 것이다.

```plaintext
 🤔 Intent란?

 Intent란 사용자의 의도를 의미한다.
 따라서, 사용자는 자신의 요구사항을 작성할 뿐,
 이를 어떻게(How) 구현할지는 기술하지 않는다.
```

### 5G-CLARITY

5G Private nework에 대한 하나의 architecture이다. 이는 이전 논문 "5G-CLARITY: 5G-Advanced Private Networks Integrating 5GNR, WiFi, and LiFi"에서 처음 제시된 구조로, 해당 구조에서는 5G New Radio(5GNR)을 포함한 WiFi, LiFi와 같은 Protocol을 지원한다. 이를 통해서 virtual, physical network function들을 모두 설정하고 관리할 수 있는 구조를 제시한다. 해당 architecture는 5G network를 위한 3가지의 구성 요소를 가진다.

1. **Infrastructure Stratum(계층)**  
   각종 가상화된 장치나 Router, Switch, 통신 단말 등을 실제로 접근할 수 있는 계층으로 이를 통해서 해당 장치를 모니티링하거나 설정 및 관리할 수 있다.
2. **Virtualised Network and Application function Stratum(계층)**  
   실제 Network function을 구현한 계층으로 Infrastructure의 Telemetry를 수집하는 역할이나 Virtual Machine(VM)에서 기능핧 가족 기능들을 포함하는 계층이다.
3. **Management and Orchestration Stratum(계층)**  
   각 장비와 VM을 관리하고, 이를 통해서 Service를 제공하는 계층이다.

### 기존 연구의 한계

기존에도 Intent를 반영하기 위한 여러 시도가 있었다. 하지만, 해당 논문에서는 현재까지 실제로 NLP를 활용하여 Intent를 추출한 사례는 존재하지 않는다고 말한다. 따라서, 해당 연구에서 핵심 골자는 NLP를 통해서 Intent를 추출할 수 있고, 이를 통해서 Network Management를 수행할 수 있음을 보이는 것이다.

## Design

해당 연구는 기존 Background에서 제시한 5G-CLARITY를 구조에서 나아가 하나의 계층(Intelligence Stratum)을 추가적으로 더하는 것을 제안한다. 해당 계층에서는 Machine Learning 모델을 포함한 ML Engine과 NLP 모델에 기반한 Intent Engeine을 포함하고 있는데, 이를 활용하여 기존 5G-CLARITY 구조에 적절한 Query를 전달하여 Network 장치의 상태를 조회하고, 관리를 할 수 있도록 하였다.
해당 시스템에서는 우선 Natural Language로 입력이 들어오면 Intent Engine에서 이를 여러 개의 Intent로 분리한다. 여기서 중요한 것은 실제로 어떻게 Intent를 추출하냐인데, 해당 논문에서는 Intent를 정의하는 것부터 시작한다. 여기서는 Intent를 아래와 같은 형태로 정의한다.

```json
{
  "intent": {
    "request": "Create a slice",
    "parameters": {
      "name": "nova",
      "user-list": [
        {"imsi": "001035432100005"}
      ],
      "location": {
        "latitude": 0.0,
        "longitude": 0.0,
      },
      "technology": [
        "AMRISOFT_CELL",
        "SUB6_ACCESS",
      ]
    }
  }
}
```

`request`는 사용자의 요청을 natural language로 표현하고, `parameters`는 해당 요청에 대한 추가적인 정보를 포함한다. 이를 추출하는 과정에서 NLP를 수행했는데 이때는 굉장히 간단히 Wikipedia data를 활용해서 text distance를 측정하는 방식을 활용했다.

## Usecases

1. Network Slice Provisioning  
   5G에서 서비스마다 다른 QoS를 제공하기 위해서 Network Slicing 기술을 제공하는데 이를 위한 기반을 Intent만 갖고도 적용이 가능하다. 만약, 특정 시스템을 위한 Slicing이 필요하다는 Intent가 들어온다면, 해당 시스템에서는 NLP를 통해서 Intent를 세분화하고, ML을 통해서 더 좋은 Network Configuration을 다시 변경할 수 있도록 구현하였다.
2. NLoS Identification  
   Line of Sight(LoS)는 통신 가용성을 평가하는 지표이다. 통신 장비마다 위치에 따라서 LoS가 다르기 때문에 이를 고려해서 통신 장비를 배치해야 한다. 이를 위해서는 NLoS(Non-Line of Sight)를 식별해야 한다. 이 또한, Intent를 통해서 구현할 수 있다. 단순히 각 Line의 상태를 받아서 처리하면 충분하다.
3. Network Service Provisioning  
   VNF와 같은 Network Service를 제공할 때에도 특정 요구사항에 맞게 Intent를 입력하면 이를 추출해서 수행할 수 있다.

## Evaluation

Evaluation은 아래와 같은 표가 제시된 것이 끝이다. 실제 예측이나 실행 능력에 대한 지표는 제시하지 않았다. 대신에 이는 충분히 잘 되었고, 이를 실행하는데 걸린 시간만 단순히 제시하였다.

|                               | Network Slice Provisioning | NLoS Identification | Network Service Provisioning |
| ----------------------------- | -------------------------- | ------------------- | ---------------------------- |
| Average intent execution time | 3 minutes                  | 1 seconds           | 4 minutes                    |

## Opinion

전체적인 구현은 단순했다. 5G Network를 구성할 수 있는 system을 도입하고, 여기서 Intent를 해석하는 시스템을 도입했는데 이 또한 어려운 구현이 없이 Wikipedia data엤서 단순히 word distance만 활용하여 위에서 제시한 usecase를 모두 커버했다고 논문에서 주장하니 직접 확인해보지 않은 이상 뭐라고 말할 수 있는 것은 없는 거 같다. 대신에 전체 흐름 자체가 Natural Language를 입력 받아서 이를 어떻게 Encoding할 지 그리고, 이렇게 Encoding 된 데이터를 어떻게 시각화할지 그리고 이를 어떻게 실제 네트워크에 반영할지에 대한 힌트 정도는 얻을 수 있었다. 해당 시스템에서는 애초에 Natural Language로 다시 Encoding을 했었다. 이러한 구조도 이해하기 쉬운 구조로 만들기 좋은 거 같다. 그러나 현재 Network Configuration을 적용하는 과정에 대한 설명은 전혀없는데 이에 대한 내용도 추가적으로 찾아보아야할 것 같다.

## Reference

- J. Mcnamara et al., "NLP Powered Intent Based Network Management for Private 5G Networks," in IEEE Access, vol. 11, pp. 36642-36657, 2023, doi: 10.1109/ACCESS.2023.3265894.
- T. Cogalan et al., "5G-CLARITY: 5G-Advanced Private Networks Integrating 5GNR, WiFi, and LiFi," in IEEE Communications Magazine, vol. 60, no. 2, pp. 73-79, February 2022, doi: 10.1109/MCOM.001.2100615.
- Thumbnail: Photo by<a href="https://unsplash.com/@annikamaria?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Annika Gordon</a> on <a href="https://unsplash.com/ko/%EC%82%AC%EC%A7%84/cZISY8ai2iA?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>


NLP Powered Intent Based Network Management for Private 5G Networks

LMPT


## Intro

<https://ieeexplore.ieee.org/document/6838228>에 기재된 `OpenNetMon: Network Monitoring in OpenFlow Software-Defined Networks`의 내용에 대한 리뷰이다. 이름에서 알 수 있듯이 OpenNetMon은 POX OpenFlow Controller를 이용하여 수많은 network component로 이루어진 fine-grained Network에서 Traffic Engineering을 위한 QoS Metric을 flow 단위로 제공하는 것을 목표로 한다. 수집하는 데이터는 **Throughput**, **Packet Loss**, **Delay**를 측정한다.

## Monitoring

Monitoring의 종류 그리고 OpenNetMon 이전의 Monitoring 방법론에 대한 소개를 먼저한다.

> **Type of Monitoring**

세 가지 기준에서 Monitoring 방법들을 구분한다. 그 중에서 첫 번째로 제시된 것이 **Active**, **Passive**이다.

- **Active** : 추가적인 packet을 Network 상에 삽입하여, 해당 packet의 동작을 통해서 측정을 하는 방법으로 과도한 추가 packet은 Network에 영향을 주기 때문에 이에 유의해야 한다. 반대로 너무 적은 packet을 사용하는 경우에도 정확성과 실시간성이 떨어질 수 있다.
- **Passiv** : 추가적인 packet의 삽입없이 기존 traffic에 대한 관측만으로 측정하는 방법으로 모든 네트워크에 적용할 수 잇는 범용적인 방법은 사실상 불가능하다고 할 수 있으며 각 Network를 위한 전용 Hardware 장비가 필요할 수도 있다. 또한, Synchronization을 위한 별도의 방법 또한 필요하다.(각 Network 장비에서 관측한 Traffic이 서로 대응되는지 확인할 수 있어야 하기 때문)

두 번째는 어떤 Layer에서 Monitoring을 수행하는가이다. Application Layer에서 측정을 하게 된다면, 활용할 수 있는 데이터가 많아지고, 실제 user 입장에서의 최종 데이터를 얻는 것이 가능하다. 하지만, 실제 서비스 제공자 입장에서 모든 End Device에 대한 접근이 불가능한 경우가 많다. 반대로 Network Layer에서 측정을 수행하는 경우에는 사용할 수 있는 데이터가 각 Switch 와 같은 Network 장비에서 packet이 어느 port로 나갔는지와 같은 간단한 정보밖에 사용할 수 없다는 단점이 있었다.

세 번째로 제시되는 것이 `OpenFlow`를 이용하였는가 아니면 이를 사용하지 않았는가이다. `OpenFlow`가 등장하면서 결국 Network Layer에서의 측정이 더 큰 의미를 가지게 된다. 왜냐하면, **Switch에 설정을 미리 주입하거나 새로운 traffic에 대한 정보를 실시간으로 추가할 수 있으며 Flow 단위로 통계치를 얻거나 임의의 packet을 추가하는 등의 작업을 수행할 수 있었기 때문에 Network Layer에서의 더 많은 Monitoring이 가능해졌다.** 이것이 해당 논문이 OpenFlow를 통해서 구현하고자 하는 바이다. Network Layer에서 복잡한 네트워크에서도 보다 정확하고, 실시간의 통계 데이터를 추출할 수 있다는 것이다.

아래는 해당 논문에서 추가로 제시하는 OpenNetMon 이전에 존재했던 Monitoring 방법에 대한 정리이다.

|                 | Active/Passive | Layer   | OpenFlow 여부 | 설명                                                                                                                                                                                                            |
| :-------------- | :------------- | :------ | :------------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| SNMP            | Active         | Network | X             | port 단위의 packet counter 기능 제공 <br/> switch의 통계정보 제공(CPU, RAM)                                                                                                                                     |
| NetFlow / cSamp | Passive        | Network | X             | switch를 통과하는 n개의 packet마다 임의의 1개의 packet을 선별하여 이를 대표값으로 하여 Network 상태를 측정하지만, 정확도가 많이 떨어질 수 있다.                                                                 |
| Skitter         | Active         | Network | X             | 전체적인 Network Delay를 측정하기 위해 대표지역에 측정기를 설치하여 실행한 project로, 이를 통해 대략적인 지연을 예측할 수는 있지만 정확하지는 않다.                                                             |
| IPMON           | Passive        | Network | X             | TCP/IP packet header를 추출하여, timestamp와 함께 중앙 server로 전송하여 이를 분석하는 방식이다. <br /> Passive임에도 Synchronization을 맞추기 위해서 통신은 불가피하며 Network 크기가 커질 수록 비용이 커진다. |
| OpenTM          | Passive        | Network | O             | 각 Flow의 통계 데이터를 일정 주기로 Query하여 수집한다. Flow의 시작과 끝 지점에서만 측정하는 Last-Switch 방식을 사용한다.                                                                                       |
| OpenSAFE        | Passive        | Network | O             | SDN의 모든 새로운 Flow가 Controller로 이동하는 것을 이용하여 Monitoring 시스템으로 Controller가 이를 전달하도록 하는 방식이다.                                                                                  |
| OpenSketch      | -              | -       | -             | Monitoring을 위해 OpenFlow 자체를 재정의하자는 것으로 새로운 Protocol을 정의해서 더 나은 Monitoring을 수행하자는 방법이다. <br /> 하지만, 이렇게 새로운 Protocol을 만드는 것은 Risk가 너무 크다.                |

## OpenNetMon

기존의 Monitoring 방식들은 OpenFlow의 Packet 삽입을 이용한 방식을 제대로 사용하지 않았을 뿐만 아니라 Flow 측정에 있어 최적화에 한계가 있었을 뿐만 아니라 **Throughput**, **Packet Loss**, **Delay**을 통합하고자 하지 않았다. 따라서, OpenNetMon은 이를 수행하는 것을 목표로 한다.

각 측정 요소를 어떻게 수집할 것인지를 각 각 정리한다.

> **1. Throughput**

OpenFlow의 `FlowStatsReq`(Controller에서 각 Switch로 전송하는 Request)를 주기적으로 호출하여 각 Switch에서 전송한 Byte의 양과 각 Flow의 지속 시간을 얻는다. 주기적 호출 싱레는 경로 상의 처음과 끝을 호출하는 Last Switch 방식을 사용하며, 이는 Round Robin이 대규모 네트워크 환경에서 비효율적일 뿐만 아니라 Packet Loss 측정 시에도 Last Switch는 필수적으로 필요한 요소이기에 최적 요소만을 사용하는 것이다.

또한, 이러한 호출 주기는 변동적으로 설정되었는데 이는 Link State Information에 기반한 Routing Discovery 시에 이를 교환 및 동기화하는 것은 Network Throughput에 많은 영향을 미치며 Throughput을 굉장히 큰 범위로 변동되게 한다. 이에 따라 아직 convergence(수렴)이 안된 시점에는 주기를 더 빈번하게 하고, 후에는 이를 되돌리도록 하는 설정이 필요하기에 이 또한 추가되었다.

> **2. Packet Loss**

시작지와 목적지의 Switch에서 해당 Flow에 대한 Packet Counting을 수행하여 계산한다.

> **3. Delay**

Packet을 하나 생성하여 출발 시간과 도착 시간을 통해 측정한다. 따라서, 다음과 같은 식으로 정리할 수 있다. 아래 RTT는 Controller와 각 Switch 간의 RTT를 의미한다.

$$ t_{delay} = (t_{arrival} - t_{sent} - {{1}\over{2}}({RTT}_{sentSwitch-controller} + {RTT}_{arrivalSwitch-controller})) $$

## Evaluation

실제 실험을 통해서 OpenNetMon에 대한 성능을 테스팅하였다. 이과정에서 총 4개의 OpenFlow를 지원하는 Switch를 일자로 연결하고 각 말단에 Server와 Client를 연결한 후에 각 Switch가 POX OpenFlow Controller에 직접적으로 연결되도록 구성하고, 각 말단과 Server/Client로의 연결은 1Gbps Ethernet로 연결하고, Switch간의 연결은 100Mbps에 1% loss, 1ms delay로 설정을 하였다. 실제 전송 데이터는 video stream traffic을 활용하여 복잡한 traffic 전송을 표현하고자 했다.

실제 그래프와 Topology는 직접적으로 가져오지는 않았다. 아무래도 저작권에 대해서 제대로 알 수 없어서 가져오지 않았다. 하지만, 논문과 같이 비교하면서 보면 도움을 받을 수 있을 것이다.

> **1. Throughput**

Application Level에서 구현한 `tcpstat`과 비교했을 때, 16KB/s(1.2%) 정도 밖에 차이가 나지 않았다. 하지만, 초기에 17.8%까지 차이가 발생하는데 이는 초기 준비 기간으로 만약 초기 준비 기간을 준다면 해결 가능하다. 또한, 한 번씩 spike가 발생하는데 이는 polling 과정에서 이전 요청보다 현재 요청이 먼저 도착할 때 발생한다. 이를 위해 synchronization을 맞춰주기 위한 로직을 추가한다면 해결이 가능하다. 여기서는 sleep과 mutual exclusion을 이용하기를 권장한다.

> **2. Packet Loss**

정확하지는 않지만 받아들일 수 있을 정도의 오차밖에 발생하지 않는다.

> **3. Delay**

Control Plane에 기반하여 전송하는 방법과 VLAN을 기반으로 Data plane으로 전송하는 법 그리고 실제로 user가 체감하는 delay를 비교했을 때, Control Plane을 그대로 이용하는 경우에는 생각보다 큰 오차가 발생한다. 이는 Controller에서 Software Scheduling 과정에서 발생하는 에러이기에, VLAN을 기반으로 Data Plane을 이용하는 경우에는 실제 데이터와 비교해도 오차가 거의 없는 것을 볼 수 있다.

## Review

해당 논문은 OpenFlow가 나오고 이를 이용해서 Monitoring을 수행하고자 했던 여러 ISP와 연구자들에게 도움을 주었다고 생각한다. 이를 통해서 OpenFlow를 이용한 여러 Monitoring 방식이 연구되었던 것 같다. 그래서 Network 논문임에도 261건 정도의 인용수를 획득한 것으로 보인다. 또한, OpenFlow를 이용한 Monitoring 방식을 사용한다는 것이 흥미로웠고, 기존의 Monitoring 방식을 OpenFlow를 통해서 적용해보는 것이 당시 연구에서 중요했던 포인트였던 것으로 보인다. 새로운 기술에 기존 기술의 아이디어를 접목하는 것도 고려해서 논문을 작성하는 것도 좋은 방법이라고 생각된다. 또한, 구현이 Github로 open되어있기 때문에 신뢰도도 높았던 것으로 보인다. 만약 해당 부분을 좀 더 확인하고 싶다면 인용 논문을 좀 더 탐색해보는 것도 좋은 방법이 될 것 같다.

작성자가 Posting을 작성하는 날짜를 기준으로 261 번의 인용수를 자랑하는 논문을 리뷰한 것이다. 앞으로도 NOMS 논문 중에서 인용수가 많았던 논문들을 위주로 한 번 Review를 진행할 예정이다.

## Reference

- Niels L. M. van Adrichem, Christian Doerr, Fernando A.Kuipers, [`"OpenNetMon: Network Monitoring in OpenFlow Software-Defined Networks"`](https://ieeexplore.ieee.org/document/6838228), June 2014
- Thumbnail : Photo by [Tobias Tullius](https://unsplash.com/@tobiastu?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/@tobiastu?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)
