KR20230051022A

KR20230051022A - 어플리케이션을 디플로이하는 전자 장치 및 동작 방법

Info

Publication number: KR20230051022A
Application number: KR1020210158955A
Authority: KR
Inventors: 이민하; 권대근
Original assignee: 삼성전자주식회사
Priority date: 2021-10-08
Filing date: 2021-11-17
Publication date: 2023-04-17

Abstract

다양한 실시예에 따라서, RIC의 동작 방법은, 제 1 xAPP의 Pod에 대한 디플로이 요청을 확인하는 동작, 상기 요청에 기반하여, 상기 Pod에 포함되는 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 기반하여, 상기 RIC에서 실행되는 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보를 확인하는 동작, 및 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보에 기반하여, 상기 복수 개의 노드들 중 선택된 제 1 노드에 상기 제 1 xAPP을 디플로이하는 동작을 포함할 수 있다. 그 밖의 다양한 실시예가 가능하다.

Description

어플리케이션을 디플로이하는 전자 장치 및 동작 방법{ELECTRONIC DEVICE DEPLOYING APPLICATION AND MEHOTD FOR OPERATING THEREOF}

다양한 실시예는 어플리케이션을 디플로이하는 전자 장치 및 동작 방법에 관한 것이다.

기존의 기지국(base station)은 기지국의 데이터 처리부(distributed unit, DU)와 무선 송수신부(radio unit 또는 remote unit, RU)가 함께 셀 사이트에 설치되는 형태로 구현되었다. 하지만, 이러한 일체형 구현 형태는 물리적 제약을 가진다. 예를 들어, 서비스 가입자 또는 트래픽의 증가에 따라, 사업자는 새롭게 셀 사이트에 기지국을 구축하여야 한다. 이를 극복하고자, C-RAN(centralized RAN(radio access network) 또는 cloud RAN) 구조가 구현되었다. C-RAN은 DU를 하나의 물리적 장소에 배치하고, 실제 사용자 장치(user equipment, UE)와 무선 신호를 송수신하는 셀 사이트에는 RU를 배치하는 구조를 가질 수 있다. DU 및 RU는 광케이블 또는 동축 케이블로 연결될 수 있다. RU 및 DU가 분리되면서 이들간의 통신을 위한 인터페이스 규격이 필요하였으며, CPRI (Common Public Radio Interface) 등의 규격이 RU와 DU간에 사용되고 있다. 3GPP (3rd Generation Partnership Project)에서도 기지국 구조가 규격화되고 있으며, 5G 시스템에 적용될 수 있는 개방형 네트워크 표준인 O-RAN(Open Radio Access Network)에 대한 논의가 진행되고 있다.

O-RAN은 기존의 3GPP NE인 RU, DU, CU-CP(central unit-control plane), CU-UP(central unit-user plane)를 각각 O-RU, O-DU, O-CU-CP, O-CU-UP라고 새로이 정의하고(이를 통합해서 O-RAN 기지국이라 칭할 수 있다), 그 외 추가로 RIC (RAN Intelligent Controller) 와 NRT-RIC(non-real-time RAN Intelligent Controller)를 제안하였다.

RIC는, k8s(Kubernetes) 클러스터(cluster)를 이용하여 동작할 수 있다. 클러스터는, 하나의 서버로 구성되는 싱글 노드, 또는 복수 개의 서버들로 구성되는 멀티 노드 중 어느 하나로 구현될 수 있다. 멀티 노드로 구현되는 경우, k8s Pod 스케줄러(scheduler)는, 복수 개의 노드들 중 어느 하나에 xAPP을 디플로이할 수 있다. k8s Pod 스케줄러는, xAPP이 요구하는 리소스 및 복수 개의 노드들 각각의 가용 리소스들을 비교함으로써, xAPP을 디플로이 할 수 있는 노드를 선택할 수 있다. xAPP이 선택된 노드와 상이한 다른 노드에 연결되는 E2 노드를 구독하는 경우에, 노드들 사이의 트래픽이 증가할 가능성이 있다. 하지만, xAPP이 구독하여야 하는 적어도 하나의 E2 노드가 처리하는 메시지와 연관된 정보에 대하여서는, xAPP을 디플로이할 노드 결정에 고려된 바가 없다.

다양한 실시예에 따른 전자 장치 및 그 동작 방법은, 적어도 하나의 E2 노드가 처리하는 메시지와 연관된 정보에 기반하여 xAPP을 디플로이할 노드를 결정할 수 있다.

다양한 실시예에 따라서, RIC의 동작 방법은, 제 1 xAPP의 Pod에 대한 디플로이 요청을 확인하는 동작, 상기 요청에 기반하여, 상기 Pod에 포함되는 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 기반하여, 상기 RIC에서 실행되는 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보를 확인하는 동작, 및 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보에 기반하여, 상기 복수 개의 노드들 중 선택된 제 1 노드에 상기 제 1 xAPP을 디플로이하는 동작을 포함할 수 있다.

다양한 실시예에 따라서, RIC의 동작 방법은, 제 1 xAPP의 Pod에 대한 디플로이 요청을 확인하는 동작, 상기 요청에 기반하여, 상기 Pod에 포함되는 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 기반하여, 상기 제 1 xAPP이 구독을 요구하는 E2 노드를 확인하는 동작, 및 상기 확인된 E2 노드에 연결된 상기 제 1 xAPP을 디플로이하는 동작을 포함할 수 있다.

다양한 실시예에 따라서, 데이터 처리 시스템에 의하여 억세스되는 xApp의 Pod를 저장하는 저장 매체에 있어서, 상기 Pod는, 제 1 데이터 및 제 2 데이터를 포함하고, 상기 제 1 데이터는, 상기 xAPP이 구독을 요구하는 적어도 하나의 E2 노드의 확인에 이용되는 제 1 서브 데이터, 상기 적어도 하나의 E2 노드 각각의 메시지 처리의 주기의 확인에 이용되는 제 2 서브 데이터, 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지 처리의 크기의 확인에 이용되는 제 3 서브 데이터, 또는 상기 적어도 하나의 E2 노드로부터의 E2 메시지가 UE와 연관된 정보를 포함하는 지 여부를 확인하는데 이용되는 제 4 서브 데이터 중 적어도 하나를 포함하고, 상기 제 2 데이터는, 상기 xAPP의 적어도 하나의 동작을 위한 정보를 포함할 수 있다.

다양한 실시예에 따라서, 적어도 하나의 E2 노드가 처리하는 메시지와 연관된 정보에 기반하여 xAPP을 디플로이할 노드를 결정할 수 있는 전자 장치 및 그 동작 방법이 제공될 수 있다.

도 1a는 다양한 실시예에 따른 RIC, RAN 및 코어 네트워크(core network, CN)를 설명하기 위한 블록도를 도시한다.
도 1b는, 다양한 실시예에 따른 RIC의 하드웨어적 구성을 설명하기 위한 블록도를 도시한다.
도 2는 다양한 실시예에 따른 RIC의 블록도를 도시한다.
도 3은 다양한 실시예와의 비교를 위한 비교예에 따른 RIC의 동작 방법을 도시하는 흐름도이다.
도 4는 다양한 실시예에 따른 RIC(101)를 도시하는 블록도이다.
도 5a는 다양한 실시예에 따른 RIC의 동작 방법을 도시하는 흐름도이다.
도 5b는 다양한 실시예에 따른 RIC의 동작 방법을 도시하는 흐름도이다.
도 6a는 다양한 실시예에 따른 RIC에서 실행되는 컴포넌트의 동작 방법을 도시하는 흐름도이다.
도 6b는 다양한 실시예에 따른 RIC에서 실행되는 컴포넌트의 동작 방법을 도시하는 흐름도이다.
도 7은 다양한 실시예에 따른 RIC의 동작 방법을 도시하는 흐름도이다.
도 8은 다양한 실시예에 따른 RIC의 동작 방법을 도시하는 흐름도이다.
도 9a는 다양한 실시예에 따른 RIC의 동작 방법을 도시하는 흐름도이다.
도 9b는 다양한 실시예에 따른 xAPP을 디플로이하는 과정을 도시하는 도면이다.
도 10은 다양한 실시예에 따른 RIC의 동작 방법을 도시하는 흐름도이다.
도 11a는 다양한 실시예에 따른 RIC의 동작 방법을 도시하는 흐름도이다.
도 11b는 다양한 실시예에 따른 xAPP의 디플로이 과정을 도시하는 도면이다.

도 1a는 다양한 실시예에 따른 RIC, RAN 및 코어 네트워크(core network, CN)를 설명하기 위한 블록도를 도시한다.

다양한 실시예에 따라서, RAN(150)은 적어도 하나의 DU(distributed unit)(151), 적어도 하나의 CU-CP(central unit-control plane)(152), 또는 적어도 하나의 CU-UP(central unit-user plane)(153) 중 적어도 하나를 포함할 수 있다. RAN(150)은 적어도 하나의 RU(remote unit, 또는 radio unit)(161)에 연결되는 것과 같이 도시되어 있지만, 이는 예시적인 것으로 적어도 하나의 RU(161)는, RAN(150)에 연결되거나, 또는 RAN(150)에 포함될 수 있다. RAN(150)은, O-RAN일 수도 있으며, 이 경우에는, DU(151)는 O-DU일 수 있으며, CU-CP(152)는 O-CU-CP일 수 있으며, CU-UP(153)는 O-CU-UP일 수 있으며, RU(161)는 O-RU일 수 있다.

다양한 실시예에 따라서, RU(161)는, 사용자 장치(user equipment, UE)(160)와 통신을 수행할 수 있다. RU(161)는, 하위 물리 계층(low-PHY) 기능 및 RF 프로세싱을 제공하는 논리적 노드일 수 있다. DU(151)는 RLC, MAC, 상위 물리 계층(high-PHY)의 기능을 제공하는 논리적 노드일 수 있으며, 예를 들어 RU(161)와 연결될 수 있다. CU(152,153)는 RRC(radio resource control), SDAP(service data adaptation protocol), PDCP(packet data convergence protocol) 프로토콜의 기능을 제공하는 논리적 노드일 수 있다. CU-CP(152)는 RRC 및 PDCP의 제어 평면 부분의 기능을 제공하는 논리적 노드일 수 있다. CU-UP(153)는 SDAP 및 PDCP의 사용자 평면 부분의 기능을 제공하는 논리적 노드일 수 있다.

다양한 실시예에 따라서, 코어 네트워크(예를 들어, 5GC 5th generation core)(154)는, AMF(access and mobility management function) (155), UPF(User plane Function)(156), 또는 SMF(Session Management Function)(157) 중 적어도 하나를 포함할 수 있다. AMF(155)는 UE(160) 단위의 접속 및 이동성 관리를 위한 기능을 제공할 수 있다. SMF(156)는 세션 관리 기능을 제공할 수 있다. UPF(156)는 데이터 네트워크로부터 수신한 하향링크 데이터를 UE(160)에게 전달하거나, 또는 UE(160)로부터 수신한 상향링크 데이터를 데이터 네트워크로 전달할 수 있다. 예를 들어, CU-CP(152)는 AMF(155)와 N2 인터페이스(또는, NGAP 인터페이스)로 연결될 수 있다. AMF(155)는 SMF(157)와 N11 인터페이스로 연결될 수 있다. CU-UP(153)는 UPF(153)와 N3 인터페이스로 연결될 수 있다.

다양한 실시예에 따라, RIC(101)는, 서비스 또는 지역적 자원 최적화(regional resource optimization)를 위한 RAN 기능성(functionality)을 커스터마이징할 수 있다. RIC(101)은 망 지능화(network intelligence)(예: 정책 강제(policy enforcement), 핸드 오버 최적화(handover optimization)), 자원 보증(resource assurance)(예: 무선 링크 관리(radio-link management), 개선된 SON(advanced self-organized-network)), 자원 제어(resource control)(예: 부하 균형(load balancing), 또는 슬라이싱 정책(slicing policy)) 중 적어도 하나의 기능을 제공할 수 있으며, RIC(101)가 제공 가능한 RAN(150)과 연관된 기능(또는, 수행되는 동작)에는 제한이 없다.

다양한 실시예에 따라, RIC(101)는, RAN(150)과 E2 메시지 (191,192)를 송신 및/또는 수신할 수 있다. 예를 들어, RIC(101)는 DU(151)와 E2-DU 인터페이스로 연결될 수 있다. 예를 들어, RIC(101)는 CU-CP(152)와 E2-CP 인터페이스로 연결될 수 있다. 예를 들어, RIC(101)는 CU-UP(153)와 E2-UP 인터페이스로 연결될 수 있다. RIC(101)와 RAN(150)과의 적어도 하나의 인터페이스를 E2 인터페이스로 명명할 수도 있다. 한편, RIC(101)는 RAN(150)과 별도의 장치인 것과 같이 도시되어 있지만, 이는 예시적인 것으로 RIC(101)는 RAN(150)과 별도의 장치로도 구현이 가능하며, 또는 하나의 장치로도 구현이 가능할 수도 있다.

다양한 실시예에 따라서, RIC(101)는 E2 노드(node)(예를 들어, DU(151), CU-CP(152), 또는 CU-UP(153) 중 적어도 하나)는 E2 메시지(191,192)를 송신 및/또는 수신할 수 있다. E2 노드는 E2 노드 기능(E2 노드 function)을 포함(또는, 제공)할 수 있다. E2 노드 기능은 RIC(101)에 설치된 특정 xApp(application S/W)에 기반하여 설정될 수 있다. 만약, KPI 모니터(monitor)의 기능이 제공되는 경우에는, RIC(101)에 KPI 모니터 수집 S/W가 설치될 수 있다. E2 노드는 KPI 파라미터들을 생성할 수 있으며, KPI 파라미터를 포함하는 E2 메시지(191)를 RIC(101)에 위치한 E2 종단(termination) 기능에 전달하는 E2 노드 기능을 포함할 수 있다. RIC(101)에 위치한 E2 종단 기능은 E2 메시지에 대한 RIC(101)의 종단으로서, E2 노드가 전달한 E2 메시지를 해석한 후, xApp에게 전달할 수 있다. RIC(101)는, RAN(150)의 동작과 연관된 정보를 E2 메시지(192)로 RAN(150)에 제공할 수 있다. RIC(101)는, xAPP을 디플로이할 수 있으며, RIC(101)에 디플로이된 xAPP은 E2 노드를 구독할 수 있다. xAPP은, 구독한 E2 노드로부터 주기적 또는 비주기적으로 E2 메시지를 수신할 수 있다.

도 1b는, 다양한 실시예에 따른 RIC의 하드웨어적 구성을 설명하기 위한 블록도를 도시한다.

다양한 실시예에 따라서, RIC(101)(또는, RIC(101)의 기능을 수행하도록 구성된 전자 장치)는, 프로세서(120), 저장 장치(130), 또는 통신 모듈(190) 중 적어도 하나를 포함할 수 있다.

다양한 실시예에 따라서, 프로세서(120)는, 예를 들면, 소프트웨어(예: 프로그램)를 실행하여 프로세서(120)에 연결된 RIC(101)(또는, RIC(101)의 기능을 수행하도록 구성된 전자 장치)의 적어도 하나의 다른 구성요소(예: 하드웨어 또는 소프트웨어 구성요소)를 제어할 수 있고, 다양한 데이터 처리 또는 연산을 수행할 수 있다. 소프트웨어는, 예를 들어 xAPP을 포함할 수 있으나 제한은 없다. 일실시예에 따르면, 데이터 처리 또는 연산의 적어도 일부로서, 프로세서(120)는 다른 구성요소로부터 수신된 명령 또는 데이터를 저장 장치(130)에 저장하고, 저장 장치(130)에 저장된 명령 또는 데이터를 처리하고, 결과 데이터를 저장 장치(130)에 저장할 수 있다. 일실시예에 따르면, 프로세서(120)는, 중앙 처리 장치, 어플리케이션 프로세서, 신경망 처리 장치(NPU: neural processing unit), 또는 커뮤니케이션 프로세서 중 적어도 일부를 포함할 수 있으나, 프로세서(120)의 종류에는 제한이 없다. 신경망 처리 장치는 인공지능 모델의 처리에 특화된 하드웨어 구조를 포함할 수 있다. 인공지능 모델은 기계 학습(예를 들어, 강화 학습, 지도형 학습(supervised learning), 비지도형 학습(unsupervised learning), 또는 준지도형 학습(semi-supervised learning)을 포함할 수 있으나, 전술한 예에 한정되지 않는다. 인공지능 모델은, 복수의 인공 신경망 레이어들을 포함할 수 있다. 인공 신경망은 심층 신경망(DNN: deep neural network), CNN(convolutional neural network), RNN(recurrent neural network), RBM(restricted boltzmann machine), DBN(deep belief network), BRDNN(bidirectional recurrent deep neural network), 심층 Q-네트워크(deep Q-networks) 또는 상기 중 둘 이상의 조합 중 하나일 수 있으나, 전술한 예에 한정되지 않는다. 인공지능 모델은 하드웨어 구조 이외에, 추가적으로 또는 대체적으로, 소프트웨어 구조를 포함할 수 있다. 저장 장치(130)는, 디스크(예를 들어, HDD)와 같은 데이터를 저장할 수 있는 장치라면 제한이 없음을 당업자는 이해할 것이다.

다양한 실시예에 따라서, 저장 장치(130)는, RIC(101)(또는, RIC(101)의 기능을 수행하도록 구성된 전자 장치)의 적어도 하나의 구성요소(예: 프로세서(120) 또는 통신 모듈(190))에 의해 사용되는 다양한 데이터를 저장할 수 있다. 데이터는, 예를 들어, 소프트웨어 및, 이와 관련된 명령에 대한 입력 데이터 또는 출력 데이터를 포함할 수 있다.

다양한 실시예에 따라서, 통신 모듈(190)은, RIC(101)(또는, RIC(101)의 기능을 수행하도록 구성된 전자 장치)와 외부 전자 장치(예: E2 노드) 간의 직접(예: 유선) 통신 채널 또는 무선 통신 채널의 수립, 및 수립된 통신 채널을 통한 통신 수행을 지원할 수 있다. 통신 모듈(190)은, 예를 들어 E2 인터페이스를 지원할 수 있다면, 그 타입에는 제한이 없다. 한편, RIC(101) 및 RAN(150)이 단일 장치로 구현되는 경우에는, 통신 모듈(190)은 양 엔티티를 위한 인터페이스를 의미할 수도 있다.

도 2는 다양한 실시예에 따른 RIC의 블록도를 도시한다.

다양한 실시예에 따르면, RIC(101)는, 복수 개의 노드들(210,220,230)을 실행(또는, 포함)할 수 있다. 복수 개의 노드들(210,220,230) 각각은 물리적인 프로세서이거나, 또는 가상 머신일 수 있다. 예를 들어, RIC(101)는, 물리적인 프로세서인 노드를 포함하거나, 또는 가상 머신인 노드를 실행할 수 있다. 복수 개의 노드들(210,220,230)은, 예를 들어 Kubernetes 클러스터 기반의 머신일 수 있으나, 제한은 없다. 복수 개의 노드들(210,220,230) 각각은, 예를 들어 컨트롤 플레인(control plane)을 형성하는 마스터 노드(master node)이거나, 및/또는 유저 플레인(user plane)을 형성하고 Pod를 이용하여 xAPP을 디플로이하는 워커 노드(worker node)일 수 있다. 예를 들어, 도 2의 실시예에서는, RIC(101)는, 제 1 노드(210)에는 제 1 xAPP(211)이 디플로이될 수 있다. 여기에서, 제 1 xAPP(211)의 제 1 노드(210)로의 디플로이는, 예를 들어 제 1 xAPP(211)가 제 1 노드(210)에서 구독, E2 메시지의 송수신, 및/또는 연산을 수행할 수 있는 상태로 진입하기 위한 적어도 하나의 동작의 수행(예를 들어, xAPP의 동작의 수행에 필요한 설정값(configuration)의 셋팅)이 완료됨을 의미할 수 있으며, 제 1 xAPP(211)이 제 1 노드(210)에 할당되거나, 제 1 xAPP(211)이 제 1 노드(210)에서 실행되거나, 1 xAPP(211)이 제 1 노드(210)에 설치되는 것으로 교환적으로 이용될 수도 있다.

다양한 실시예와의 비교를 위한 비교예에서는, k8s Pod 스케줄러(k8s Pod scheduler)에 의하여 xAPP이 디플로이될 노드가 결정될 수 있다. 예를 들어, k8s Pod 스케줄러는 노드들(210,220,230) 각각의 가용 리소스를 확인하고, 디플로이가 요구되는 xAPP이 요구하는 리소스를 이용하여, xAPP이 디플로이될 노드를 결정할 수 있다. k8s Pod 스케줄러는, 예를 들어 제 3 노드(230)의 가용 리소스가 제 3 xAPP(231)이 요구하는 리소스보다 큰 것에 기반하여, 제 3 노드(230)를 제 3 xAPP(231)을 디플로이할 노드로 선택할 수 있다. 이와는 대조적으로, 다양한 실시예에 따른 RIC(101)는, RIC(101) 내부의 트래픽이 최소화되거나, 및/또는 통신 비용이 최소화되도록 제 1 xAPP(211), 제 2 xAPP(221), 및 제 3 xAPP(223)이 디플로이되는 노드를 결정할 수 있으며, 이에 대하여서는 후술하도록 한다. 여기에서, 통신 비용은, 메시지의 전달에 기반하여 소모되는 리소스(예를 들어, 메시지 전달을 위한 적어도 하나의 프로세서 및/또는 메모리의 사용량 및/또는 대역폭)의 합(또는, 가중치 합), 또는 메시지가 전달되는 경로의 거리(물리적인 거리 및/또는 논리적인 거리) 중 적어도 하나를 포함할 수 있으며, 메시지 전달에 의하여 이용되는 파라미터라면 제한이 없다.

다양한 실시예에서, 제 1 노드(210)의 E2 종단 컴포넌트(212)은 E2 메시지에 대한 제 1 노드(210)의 종단으로서, 제 1 노드(210)에 연결되는 E2 노드들(241,242,243,244) 중 적어도 하나가 전달한 E2 메시지를 제 1 xAPP(211)에 전달할 수 있다. E2 종단 컴포넌트(212)은, E2 인터페이스(interface)를 지원하며, E2 인터페이스는 O-RAN WG3 E2AP(Application Protocol) 문서(specification)를 구현한 것일 수 있다. E2AP는 E2 노드의 서비스 모델을 정의한 E2SM(E2 service model)을 포함할 수 있다. RIC(101)와 E2 노드는, E2AP 및/또는 E2SM 기반의 메시지를 송신 및/또는 수신할 수 있다. E2 노드들(241,242,243,244)은, 예를 들어 RAN을 구성하는 적어도 하나의 엔티티일 수 있으며, 제한이 없다. E2 종단 컴포넌트들(212,222,232) 각각은 리소스 사용률(예를 들어, 단위 시간 당 프로세싱 리소스 사용량 및/또는 네트워크 트래픽 처리량)이 높아, 각각의 노드들(210,220,230)에 분산되어 실행될 수 있다. 도 2의 실시예에서는, 제 1 노드(210)에 제 1 xAPP(211) 하나만이 디플로이된 것을 도시하지만, 이는 예시적인 것으로 하나의 노드에 복수 개의 xAPP 들이 디플로이될 수 있음을 당업자는 이해할 것이다. 복수 개의 xAPP들이 디플로이된 경우, E2 종단 컴포넌트(212)은, E2 노드들(241,242,243,244) 중 적어도 하나가 전달한 E2 메시지를 전달할 xAPP을 결정할 수 있다.

다양한 실시예에서, 제 2 노드(220)에는, 제 2 xAPP(221)이 디플로이될 수 있다. 제 2 노드(220)의 E2 종단 컴포넌트(222)은 E2 메시지에 대한 제 2 노드(210)의 종단으로서, 제 2 노드(220)에 연결되는 E2 노드들(251,252,253,254) 중 적어도 하나가 전달한 E2 메시지를 제 2 xAPP(221)에 전달할 수 있다. 제 3 노드(230)에는, 제 3 xAPP(231)이 디플로이될 수 있다. 제 3 노드(230)의 E2 종단 컴포넌트(232)은 E2 메시지에 대한 제 3 노드(230)의 종단으로서, 제 3 노드(230)에 연결되는 E2 노드들(261,262,263,264) 중 적어도 하나가 전달한 E2 메시지를 제 3 xAPP(231)에 전달할 수 있다. 한편, 제 2 노드(220)의 E2 종단 컴포넌트(222)은, 예를 들어 E2 노드 #14(251)로부터의 E2 메시지의 종단이 제 3 xAPP(231)인 것으로 확인할 수도 있다. 이 경우, E2 메시지는, 제 2 노드(220)의 E2 종단 컴포넌트(222) 및/또는 제 3 노드(230)의 E2 종단 컴포넌트(232)에 의하여, 복수 개의 경로들(271,272,273,274,275)를 통하여 제 3 xAPP(231)로 전달될 수 있다. E2 노드 #14(251)를 구독하는 제 3 xAPP(231)이 제 2 노드(220)가 아닌 제 3 노드(230)에 디플로이됨에 따라서, 불필요한 노드들(220,230) 사이의 트래픽이 발생할 수 있다. 만약, E2 노드 #14 (251)를 구독하는 제 3 xAPP(231)이 제 3 노드(230)에 디플로이 되었다면, 제 2 노드(220)의 E2 종단 컴포넌트(222)은 제 3 xAPP(231)에 바로 E2 메시지를 전달할 수 있으며, 이에 따라 노드들(220,230) 사이의 트래픽이 발생하지 않을 수 있다. 하지만, 제 3 xAPP(231)은, E2 노드 #14(251)이외에도 다른 E2 노드를 구독할 수도 있으며, 경우에 따라서는 제 3 노드(230)에 디플로이되는 것이 내부 트래픽을 최소화할 가능성도 있다. 다양한 실시예에 따른 RIC(101)는, 내부 트래픽을 최소화 및/또는 통신 비용을 최소화할 수 있는 노드를 선택할 수 있으며, 이에 대하여서는 후술하도록 한다. 적어도 하나의 xAPP(211,221,231) 각각은 적어도 하나의 E2 노드에 구독을 요청할 수 있다. 예를 들어, 적어도 하나의 xAPP(211,221,231) 각각은 구독 요청(response request) 메시지를 송신할 수 있다. 구독 요청 메시지에는, 예를 들어 RIC 요청 ID, RIC 이벤트 트리거 정의 및 RIC 액션 ID의 시퀀스, RIC 액션 타입, RIC 액션 정의, 또는 RIC 차후 액션(subsequent action) 중 적어도 하나가 포함될 수 있다. E2 노드(241,242,243,244,245,251,252,253,254,261,262,263,264)는, 구독 요청 메시지에 응답하여, 구독 응답(subscription response) 메시지를 대응하는 xAPP(211,221,231)으로 송신할 수 있다. 구독이 완료됨에 따라서, 적어도 하나의 xAPP(211,221,231) 각각과 적어도 하나의 E2 종단 컴포넌트(212,222,232) 사이의 연결과, 적어도 하나의 E2 종단 컴포넌트(212,222,232)과 각각에 대응하는 E2 노드(241,242,243,244,245,251,252,253,254,261,262,263,264) 사이의 연결이 수립될 수 있으며, 연결들은 persistent 연결일 수 있다. Persistent 연결이 수립됨에 따라서, 비효율적인 네트워크 경로가 구성될 경우, 불필요한 RIC(101) 내부의 트래픽이 상대적으로 장시간 지속될 수 있으며, 이에 따라 RIC(101)의 성능 저하 및 리소스 낭비가 야기될 수 있다. 다양한 실시예에 따른 RIC(101)는, 내부의 트래픽을 최소화하거나, 및/또는 통신 비용이 최소화되도록 xAPP을 디플로이할 노드를 결정할 수 있다.

도 3은 다양한 실시예와의 비교를 위한 비교예에 따른 RIC의 동작 방법을 도시하는 흐름도이다. 비교예에 의하여 수행되는 적어도 하나의 동작 중 적어도 일부는, 다양한 실시예에 따른 RIC(101)에 의하여서도 수행될 수도 있다.

비교예에 따르면, RIC(101)는, 301 동작에서, 제 1 xAPP의 Pod에 대한 디플로이 요청을 확인할 수 있다. RIC(101)는, 303 동작에서, RIC(101)에서 실행되는 복수 개의 노드들(예를 들어, 도 2의 노드들(210,220,230)) 각각의 가용 리소스들 각각과 제 1 xAPP이 요구하는 리소스에 기반하여, 복수 개의 노드들 중 하나를 선택할 수 있다. 예를 들어, RIC(101)는, 제 1 xAPP이 요구하는 리소스보다 큰 가용 리소스를 가지는 노드를 선택할 수 있다. 또는, RIC(101)는, 제 1 xAPP이 요구하는 리소스보다 임계치 이상 큰 가용 리소스를 가지는 노드를 선택할 수 있다. 만약, 제 1 xAPP이 요구하는 리소스보다 큰 가용 리소스를 가지는 노드가 복수개인 경우에는, RIC(101)는, 가장 큰 가용 리소스를 가지는 노드를 선택할 수 있으나, 이는 예시적인 것으로 가용 리소스에 기반하여 노드를 선택하는 방식에는 제한이 없다. RIC(101)는, 305 동작에서, 선택된 노드에 제 1 xAPP을 디플로이할 수 있다. 상술한 바에 따라서, 제 1 xAPP은, 요구하는 리소스보다 큰 가용 리소스를 가지는 노드에 디플로이될 수 있으나, 제 1 xAPP이 구독하는 E2 노드는 다른 노드에 연결될 가능성이 있다. 이에 따라, 제 1 xAPP이 구독하는 E2 노드로부터의 E2 메시지가, 다른 노드로부터 선택된 노드를 거쳐서 제 1 xAPP으로 전달될 수 있으며, 이에 따른 RIC(101) 내부의 트래픽이 증가될 가능성이 있다. 다양한 실시예에 따른 RIC(101)는, 제 1 xAPP이 요구하는 리소스보다 큰 가용 리소스를 가지는 적어도 하나의 노드 중, 내부의 트래픽을 최소화하거나, 및/또는 통신 비용이 최소화할 수 있는 노드를 선택하여 제 1 xAPP을 디플로이할 수 있다.

도 4는 다양한 실시예에 따른 RIC(101)를 도시하는 블록도이다.

다양한 실시예에 따라서, RIC(101)(예를 들어, 프로세서(120))(또는, RIC(101)의 기능을 실행하는 전자 장치)는, 제 1 노드(210)에서 xAPP 매니저(xAPPMgr)(401)를 실행할 수 있다. 한편, xAPP 매니저(401)는, 제 1 노드(210)에서 실행되는 것과 같이 도시되어 있지만, 이는 예시적인 것으로 제 1 노드(210) 이외의 다른 워커 노드에서도 실행될 수도 있다. 또는, xAPP 매니저(401)는 마스터 노드에서도 실행될 수도 있으며, xAPP 매니저(401)가 실행되는 노드에는 제한이 없다. xAPP 매니저(401)는, xAPP의 디플로이와, 언디플로이(undeploy)를 수행할 수 있다. xAPP 매니저(401)는, 예를 들어 RIC(101)의 외부와의 데이터 송수신을 위한 인터페이스를 통하여, xAPP의 디플로이 요청을 확인할 수 있다. xAPP의 디플로이 요청이 확인되면, xAPP 매니저(401)는 xAPP의 Pod에 포함된 E2 노드의 구독과 연관된 정보에 기반하여, 실행되는 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보를 확인할 수 있다. E2 노드의 구독과 연관된 정보는, 예를 들어 xAPP의 Pod의 메타데이터 영역에 포함될 수 있으나, 정보가 포함되는 위치에는 제한이 없다. 한편, Pod에는, xAPP의 적어도 하나의 동작을 위한 데이터 및 메타데이터가 포함될 수 있다. 메타데이터에는 E2 노드의 식별을 위한 적어도 하나의 정보(예를 들어, 서비스 모델), E2 노드의 메시지의 처리 주기에 대한 정보, E2 노드의 메시지 템플릿의 크기에 대한 정보, 또는 UE에 대한 정보의 요구 여부가 포함될 수 있으며, 이에 대하여서는 후술하도록 한다. 한편, 메타데이터에는, 추가적으로 메트릭, 버전, 로그 레벨의 정보도 포함될 수도 있다. xAPP 매니저(401)는, 예를 들어 복수 개의 노드들 중 적어도 일부 각각이 단위 시간당 처리하는 메시지의 크기를 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보로서 확인할 수 있다. 예를 들어, xAPP 매니저(401)는, 복수 개의 노드들 중 적어도 일부의 메시지의 처리 빈도(또는, 처리 주기) 및/또는 처리하는 메시지의 크기를 이용하여, 복수 개의 노드들 중 적어도 일부 각각이 단위 시간당 처리하는 메시지의 크기를 확인할 수 있다. 또는, xAPP 매니저(401)는, 복수 개의 노드들 중 적어도 일부의 메시지의 처리 빈도(또는, 처리 주기) 및/또는 처리하는 메시지의 크기를, 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보로서 확인할 수도 있다. xAPP 매니저(401)는, 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보를 이용하여, 제 1 xAPP을 디플로이할 노드를 선택할 수 있다. 예를 들어, xAPP 매니저(401)는, 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보를 이용하여, RIC(101) 내부의 트래픽이 최소화되거나, 및/또는 통신 비용이 최소화되는 노드를 선택할 수 있다. 예를 들어, xAPP 매니저(401)는, 단위 시간당 처리하는 메시지의 크기가 가장 큰 노드를 선택할 수 있다. 예를 들어, xAPP 매니저(401)는, 통신 비용의 합계가 최소화되는 노드를 선택할 수 있다. 예를 들어, xAPP 매니저(401)는, 메시지의 처리 빈도가 가장 높은(또는, 처리 주기가 가장 작은) 노드를 선택할 수도 있다. 예를 들어, xAPP 매니저(401)는, 처리되는 메시지의 크기가 가장 큰 노드를 선택할 수도 있다.

도 5a는 다양한 실시예에 따른 RIC의 동작 방법을 도시하는 흐름도이다.

다양한 실시예에 따르면, RIC(101)(예를 들어, 프로세서(120))(또는, RIC(101)의 기능을 실행하는 전자 장치)는, 501 동작에서, 제 1 xAPP의 Pod에 대한 디플로이 요청을 확인할 수 있다. RIC(101)는, 503 동작에서, 디플로이 요청의 확인에 기반하여, 제 1 xAPP의 Pod에 포함되는 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 기반하여, RIC(101)에서 실행되는 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보를 확인할 수 있다. RIC(101)는, 제 1 xAPP이 구독하여야 할 E2 노드에 연결되는 노드에 대하여 메시지와 연관된 정보를 확인할 수 있으며, 이에 따라 RIC(101)에서 실행되는 노드들 전체에 대한 메시지와 연관된 정보가 확인될 수 있거나, 또는 경우에 따라서는 일부의 노드에 대한 메시지와 연관된 정보가 확인될 수 있음을 당업자는 이해할 것이다. 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보는, 예를 들어 서비스 모델(service model)을 포함할 수 있다. 다양한 실시예에서, RIC(101)는, E2 노드와 연결을 수립하는 과정(예를 들어, E2 셋업 과정)에서, E2 노드와 연관된 정보를 저장할 수 있다. 예를 들어, E2 셋업 과정에서, RIC(101)는, E2 노드의 식별 정보(예를 들어, gnb_AB00_1237), 서비스 모델(예를 들어, data_usage_level), 및 연결된 UE의 개수(예를 들어, 124개)를, 저장할 수 있다. RIC(101)는, 연결되는 복수 개의 E2 노드들 각각에 대한 정보를 저장 및/또는 관리할 수 있다. RIC(101)는, 제 1 xAPP의 구독과 연관된 정보와 관리 중인 E2 노드의 정보의 비교 결과에 기반하여, 제 1 xAPP이 구독하여야 하는 적어도 하나의 E2 노드를 식별할 수 있다. 예를 들어, 제 1 xAPP의 구독과 연관된 정보에 포함된 서비스 모델이 data_usage_level인 경우, RIC(101)는 제 1 xAPP이 구독하여야 하는 적어도 하나의 E2 노드로서 data_usage_level의 서비스 모델에 대응하는 적어도 하나의 E2 노드를 식별할 수 있다.

상술한 바와 같이, RIC(101)는, 제 1 xAPP이 구독하여야 하는 적어도 하나의 E2 노드를 확인할 수 있다. RIC(101)는, 제 1 xAPP이 구독하여야 하는 적어도 하나의 E2 노드 각각이 처리하는 메시지와 연관된 정보를 확인할 수 있다. RIC(101)는, 제 1 xAPP이 구독하여야 하는 적어도 하나의 E2 노드 각각이 처리하는 메시지와 연관된 정보를 이용하여, 실행되는 복수 개의 노드들 각각이 처리하는 메시지와 연관된 정보를 확인할 수 있다. RIC(101)는, 제 1 xAPP이 구독하여야 하는 적어도 하나의 E2 노드와 복수 개의 노드들 중 적어도 일부의 연결 관계에 기반하여, 실행되는 복수 개의 노드들 각각이 처리하는 메시지와 연관된 정보를 확인할 수 있다.

하나의 예에서, RIC(101)는 제 1 xAPP이 구독하여야 하는 적어도 하나의 E2 노드 각각의 단위 시간당 처리하는 메시지의 크기를, 메시지와 연관된 정보로서 확인할 수 있다. 적어도 하나의 E2 노드 각각의 단위 시간당 처리하는 메시지의 크기를 확인하기 위하여, RIC(101)는 적어도 하나의 E2 노드 각각의 메시지 처리 빈도(또는, 메시지 처리 주기)를 확인할 수 있다. 표 1은 적어도 하나의 E2 노드 각각의 메시지 처리 빈도(또는, 메시지 처리 주기)의 예시이다. 예를 들어, RIC(101)는, 제 1 xAPP이 구독하여야 하는 적어도 하나의 E2 노드를, E2 노드 #3, E2 노드 #14, E2 노드 #34, E2 노드 #35로 확인한 것을 상정하도록 한다. 아울러, E2 노드 #3는 제 1 노드에 연결되고, E2 노드 #14는 제 2 노드에 연결되고, E2 노드 #34 및 E2 노드 #35는 제 3 노드에 연결된 것을 상정하도록 한다.

제1xAPP이 구독하여야 할 E2 노드	메시지 처리 주기
E2 노드 #3	1000ms
E2 노드 #14	1000ms
E2 노드 #34	10ms
E2 노드 #35	100ms

적어도 하나의 E2 노드 각각의 단위 시간당 처리하는 메시지의 크기를 확인하기 위하여, RIC(101)는 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기를 확인할 수 있다. 표 2는, 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기의 예시이다.

제1xAPP이 구독하여야 할 E2 노드	처리하는 메시지의 크기
E2 노드 #3	128kb
E2 노드 #14	64kb
E2 노드 #34	256kb
E2 노드 #35	128kb

하나의 예에서, RIC(101)는, 처리하는 메시지의 크기를 메시지 처리 주기로 나눔으로써, 적어도 하나의 E2 노드 각각의 단위 시간당 처리하는 메시지의 크기를 확인할 수 있다. 표 3은 적어도 하나의 E2 노드 각각의 단위 시간당 처리하는 메시지의 크기의 예시이다.

제1xAPP이 구독하여야 할 E2 노드	단위 시간 당 처리하는 메시지의 크기
E2 노드 #3	128kb/1000ms = 0.128kb/ms
E2 노드 #14	64kb/1000ms = 0.064kb/ms
E2 노드 #34	256kb/10ms = 25.6kb/ms
E2 노드 #35	128kb/100ms = 1.28kb/ms

하나의 예에서, RIC(101)는, 제 1 xAPP이 구독하여야 할 E2 노드와 RIC(101)에서 실행되는 노드 사이의 연결에 기반하여, 노드 별 단위 시간 당 처리하는 메시지의 크기를 확인할 수 있다. 예를 들어, RIC(101)는, 표 4와 같은 노드 별 단위 시간당 처리하는 메시지의 크기를 확인할 수 있다.

제1xAPP이 구독하여야 할 E2 노드가 연결된 노드	단위 시간 당 처리하는 메시지의 크기
제 1 노드	0.128kb/ms (E2 노드 #3)
제 2 노드	0.064kb/ms (E2 노드 #14)
제 3 노드	25.6kb/ms (E2 노드 #34) + 1.28kb/ms (E2 노드 #35) = 27.4kb/ms

E2 노드 #3만이 연결되는 제 1 노드의 단위 시간 당 처리하는 메시지의 크기는, 0.128kb/ms로 결정될 수 있다. 예를 들어, E2 노드 #14만이 연결되는 제 2 노드의 단위 시간 당 처리하는 메시지의 크기는, 0.064kb/ms로 결정될 수 있다. 예를 들어, E2 노드 #34와 E2 노드 #35가 연결되는 제 3 노드의 단위 시간 당 처리하는 메시지의 크기는, 25.6kb/ms + 1.28kb/ms인 27.4kb/ms일 수 있다. RIC(101)는, 단위 시간 당 처리하는 메시지의 크기가 가장 큰 제 3 노드를, 제 1 xAPP을 디플로이할 노드로서 선택할 수 있다. 505 동작에서, RIC(101)는, 확인된 정보에 기반하여 선택된 노드에 제 1 xAPP을 디플로이할 수 있다.

다른 예에서, RIC(101)는, 제 1 xAPP이 구독하여야 하는 적어도 하나의 E2 노드 각각의 메시지 처리 빈도(또는, 메시지 처리 주기)를, 메시지와 연관된 정보로서 확인할 수 있다. 예를 들어, RIC(101)는 표 1과 같은 정보를 메시지와 연관된 정보로서 확인할 수 있다. RIC(101)는, 처리 빈도가 가장 높은(또는, 처리 주기가 가장 짧은) E2 노드(예를 들어, 표 1의 E2 노드 #34)를 확인할 수 있다. RIC(101)는, 처리 빈도가 가장 높은(또는, 처리 주기가 가장 짧은) E2 노드(예를 들어, 표 1의 E2 노드 #34)에 연결된 제 3 노드를 제 1 xAPP을 디플로이할 노드로서 선택할 수 있다. 또 다른 예에서, RIC(101)는, 제 1 xAPP이 구독하여야 하는 적어도 하나의 E2 노드 각각의 처리하는 메시지 크기를, 메시지와 연관된 정보로서 확인할 수 있다. 예를 들어, RIC(101)는 표 2와 같은 정보를 메시지와 연관된 정보로서 확인할 수 있다. RIC(101)는, 처리하는 메시지의 크기의 합계가 가장 큰 노드(예를 들어, 제 3 노드)를 제 1 xAPP을 디플로이할 노드로서 선택할 수 있다.

다양한 실시예에 따른 RIC(101)는, 상술한 다양한 예들 중 하나의 방식에 따라서 제 1 xAPP을 디플로이할 노드를 선택할 수 있으며, 그 선택 방식에는 제한이 없다. 또는, RIC(101)는, xAPP의 특성에 따라, 상술한 다양한 예들 중 하나의 방식을 선택할 수도 있다. 예를 들어, 초저지연 처리가 요구되는 xAPP에 대하여서는, RIC(101)는, 처리 빈도가 가장 높은(또는, 처리 주기가 가장 짧은) E2 노드에 연결된 노드를 제 1 xAPP을 디플로이할 노드로서 선택할 수 있다. 또는, 초저지연 처리가 요구되지 않는 xAPP에 대하여서는, RIC(101)는, 단위시간 당 처리하는 메시지의 크기가 가장 큰 노드를 제 1 xAPP을 디플로이할 노드로서 선택할 수 있다.

도 5b는 다양한 실시예에 따른 RIC의 동작 방법을 도시하는 흐름도이다.

다양한 실시예에 따르면, RIC(101)(예를 들어, 프로세서(120))(또는, RIC(101)의 기능을 실행하는 전자 장치)는, 511 동작에서, 제 1 xAPP의 Pod에 대한 디플로이 요청을 확인할 수 있다. RIC(101)는, 513 동작에서, 디플로이 요청의 확인에 기반하여, 제 1 xAPP의 Pod에 포함되는 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 기반하여, 실행되는 복수 개의 노드들 중 적어도 일부 각각에 대응하는 단위 시간당 처리하는 메시지의 크기와 연관된 제 1 정보를 확인할 수 있다. 예를 들어, RIC(101)는, 표 4와 같은 노드 별 단위 시간당 처리하는 메시지의 크기와 연관된 제 1 정보를 확인할 수 있다. RIC(101)는, 515 동작에서, 실행되는 복수 개의 노드들 중 적어도 일부 각각의 가용 리소스들 각각과 제 1 xAPP이 요구하는 리소스와 연관되는 제 2 정보를 확인할 수 있다. RIC(101)는, 517 동작에서, 제 1 정보 및 제 2 정보에 기반하여 선택된 노드에 제 1 xAPP을 디플로이할 노드를 선택할 수 있다. 예를 들어, RIC(101)는, 가용 리소스가 제 1 xAPP이 요구하는 리소스보다 큰 노드로부터, 제 1 정보를 이용하여 노드를 선택할 수 있다. 만약, 표 4와 같은 노드 별 단위 시간당 처리하는 메시지의 크기와 연관된 제 1 정보가 확인되었으며, 제 3 노드의 가용 리소스는 제 1 xAPP이 요구하는 리소스보다 작다는 제 2 정보가 확인된 경우, RIC(101)는, 제 3 노드와의 통신 속도가 가장 빠르거나, 및/또는 통신 비용이 가장 낮은 노드를 제 1 xAPP을 디플로이할 노드로서 선택할 수 있다. 또는, RIC(101)는, 차순위로 단위 시간 당 처리하는 메시지의 크기가 큰 제 1 노드를 제 1 xAPP을 디플로이할 노드로서 선택할 수 있다. 한편, 단위 시간당 처리하는 메시지의 크기는 단순히 예시적인 것으로, 본 실시예뿐만 아니라 다른 실시예에서의 단위 시간당 처리하는 메시지의 크기는 상술한 다양한 예시들로 치환될 수 있음을 당업자는 이해할 것이다.

다양한 실시예에서, RIC(101)는, 상술한 바와 같이, 표 1와 같은 제 1 정보와, 리소스와 연관된 제 2 정보를 이용하여 제 1 xAPP을 디플로이할 노드를 선택할 수 있다. 또는, RIC(101)는, 가용 리소스가 제 1 xAPP이 요구하는 리소스보다 큰 노드에 대하여서만, 단위 시간당 처리하는 메시지의 크기를 확인하고, 확인 결과에 기반하여 제 1 xAPP을 디플로이할 노드를 선택할 수도 있으며, 이는 도 5c를 참조하여 설명하도록 한다.

도 5c는 다양한 실시예에 따른 RIC의 동작 방법을 도시하는 흐름도이다.

다양한 실시예에 따르면, RIC(101)(예를 들어, 프로세서(120))(또는, RIC(101)의 기능을 실행하는 전자 장치)는, 521 동작에서, 제 1 xAPP의 Pod에 대한 디플로이 요청을 확인할 수 있다. RIC(101)는, 523 동작에서, 디플로이 요청의 확인에 기반하여, 실행되는 복수 개의 노드들 중 적어도 일부 각각의 가용 리소스들 각각과 제 1 xAPP이 요구하는 리소스에 기반하여, 복수 개의 노드들 중 적어도 일부 중 제 1 xAPP을 디플로이할 수 있는 적어도 하나의 노드를 확인할 수 있다. 예를 들어, RIC(101)는, 제 1 xAPP이 요구하는 리소스보다 큰 가용 리소스를 가지는 적어도 하나의 노드를 확인할 수 있다. 또는, RIC(101)는, 제 1 xAPP이 요구하는 리소스보다 임계 값 이상 큰 가용 리소스를 가지는 적어도 하나의 노드를 확인할 수 있으며, 가용 리소스 및 제 1 xAPP이 요구하는 리소스를 이용하여 적어도 하나의 노드를 확인하는 방식에는 제한이 없다.

다양한 실시예에서, RIC(101)는, 525 동작에서, 제 1 xAPP의 Pod에 포함되는 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 기반하여, 적어도 하나의 노드 각각에 대응하는 단위 시간당 처리하는 메시지의 크기를 확인할 수 있다. RIC(101)는, 실행 중인 복수 개의 노드들 중, 제 1 xAPP을 디플로이할 수 있는 적어도 하나의 노드에 대하여서만 단위 시간당 처리하는 메시지의 크기를 확인할 수 있으며, 나머지 노드에 대하여서는 단위 시간당 처리하는 메시지의 크기를 스킵할 수도 있다. 전자 장치(101)는, 527 동작에서, 적어도 하나의 노드 각각에 대응하는 단위 시간당 처리하는 메시지의 크기에 기반하여, 적어도 하나의 노드 중 하나를 선택할 수 있다. 예를 들어, 전자 장치(101)는, 적어도 하나의 노드 중 가장 큰 단위 시간당 처리하는 메시지의 크기를 가지는 노드를 선택할 수 있다. RIC(101)는, 529 동작에서, 선택된 노드에 제 1 xAPP을 디플로이할 수 있다.

도 6a는 다양한 실시예에 따른 RIC에서 실행되는 컴포넌트의 동작 방법을 도시하는 흐름도이다.

다양한 실시예에 따르면, RIC(101)(예를 들어, 프로세서(120))(또는, RIC(101) 기능을 수행하는 전자 장치)는, xAPP 매니저(601), k8s(602), k8s 스케줄러(603), 및 k8s 노드 매니저(604)를 실행할 수 있다. xAPP 매니저(601)는, 도 4를 참조하여 설명하였으므로 여기에서의 상세한 설명은 생략하도록 한다. k8s(602)는, xAPP을 노드에 디플로이할 수 있다. k8s 스케줄러(603)는 컨테이너 오케스트레이션 플랫폼(container orchestration platform) 내부에서 Pod를 스케줄링하는 컴포넌트일 수 있다. 만약, k8s 플랫폼이 아닌 다른 플랫폼이 구현되는 경우에는, k8s 스케줄러(603)를 대신하여 다양한 종류의 가상머신/컨테이너 오케스트레이션 플랫폼의 스케줄러가 동작할 수도 있다. k8s 노드 매니저(604)는 RIC(101)에서 실행 중인 노드의 상태(예를 들어, 전체 리소스, 현재 이용중인 리소스, 및/또는 가용 리소스)를 관리할 수 있다.

다양한 실시예에 따르면, xAPP 매니저(601)는, 611 동작에서, xAPP의 Pod에 대한 디플로이 요청을 확인할 수 있다. xAPP 매니저(601)는, 613 동작에서, RIC(101)에서 실행되는 복수 개의 노드들 중 적어도 일부 각각의 가용 리소스들에 대한 정보를 k8s(602)에 요청할 수 있다. k8s(602)는, 615 동작에서, RIC(101)에서 실행되는 복수 개의 노드들 중 적어도 일부 각각의 가용 리소스들에 대한 정보를 k8s 노드 매니저(604)에 요청할 수 있다. k8s 노드 매니저(604)는, 617 동작에서, 요청에 응답하여 RIC(101)에서 실행되는 복수 개의 노드들 중 적어도 일부 각각의 가용 리소스들에 대한 정보를 제공할 수 있다. k8s(602)는, 619 동작에서, RIC(101)에서 실행되는 복수 개의 노드들 중 적어도 일부 각각의 가용 리소스들에 대한 정보를 xAPP 매니저(601)로 제공할 수 있다. xAPP 매니저(601)는, 621 동작에서, 노드 별 가용 리소스에 대한 정보와, 구독과 연관된 정보(예를 들어, 실행되는 복수 개의 노드들 중 적어도 일부 중 적어도 일부 각각의 단위 시간당 처리하는 메시지의 크기와 연관된 정보)를 이용하여 노드를 선택할 수 있다. 예를 들어, xAPP 매니저(601)는, 제 1 xAPP이 요구하는 리소스보다 큰 가용 리소스를 가지는 적어도 하나의 노드 중, 가장 큰 단위 시간당 처리하는 메시지의 크기를 가지는 노드를 선택할 수 있다. 만약, 제 1 xAPP이 요구하는 리소스보다 큰 가용 리소스를 가지는 노드가 하나라면, xAPP 매니저(601)는 해당 노드를 선택할 수도 있다. xAPP 매니저(601)는, 623 동작에서, 선택된 노드에 xAPP의 디플로이를 k8s(602)에 요청할 수 있다. k8s(602)는, 625 동작에서, 선택된 노드에 xAPP을 디플로이할 수 있다. k8s(602)는, 627 동작에서, xAPP 디플로이 완료를 xAPP 매니저(601)에 통지할 수 있다.

도 6b는 다양한 실시예에 따른 RIC에서 실행되는 컴포넌트의 동작 방법을 도시하는 흐름도이다.

다양한 실시예에 따르면, xAPP 매니저(601)는, 631 동작에서, xAPP의 Pod에 대한 디플로이 요청을 확인할 수 있다. xAPP 매니저(601)는, 633 동작에서, 구독과 연관된 정보(예를 들어, 실행되는 복수 개의 노드들 중 적어도 일부 중 적어도 일부 각각의 단위 시간당 처리하는 메시지의 크기와 연관된 정보)를 이용하여 노드를 선택할 수 있다. xAPP 매니저(601)는, 635 동작에서, 선택된 노드에 xAPP의 디플로이를 k8s(602)에 요청할 수 있다. k8s(602)는, 637 동작에서, k8s 스케줄러(603)에 디플로이를 요청할 수 있다. k8s 스케줄러(603)는, 639 동작에서, RIC(101)에서 실행되는 복수 개의 노드들 중 적어도 일부 각각의 가용 리소스들에 대한 정보를 k8s 노드 매니저(604)에 요청할 수 있다. k8s 노드 매니저(604)는, 641 동작에서, 요청에 응답하여 RIC(101)에서 실행되는 복수 개의 노드들 중 적어도 일부 각각의 가용 리소스들에 대한 정보를 제공할 수 있다. 예를 들어, k8s 스케줄러(603)는, 643 동작에서, xAPP의 디플로이가 불가능함을 k8s(602)로 통지할 수 있다. k8s 스케줄러(603)는, 해당 노드의 가용 리소스가 xAPP의 디플로이에 불충분함에 기반하여, xAPP의 디플로이가 불가능함을 k8s(602)로 통지할 수 있다. k8s(602)는, 645 동작에서, xAPP의 디플로이가 불가능함을 xAPP 매니저(601)로 통지할 수 있다.

다양한 실시예에 따라서, xAPP 매니저(601)는, 647 동작에서, 해당 노드에서의 디플로이가 불가능함에 기반하여, 다른 노드를 선택할 수 있다. 하나의 예에서, xAPP 매니저(601)는, 실행되는 복수 개의 노드들 중 적어도 일부 중 적어도 일부 각각의 단위 시간당 처리하는 메시지의 크기가 차순위인 노드를 선택할 수 있다. 또는, xAPP 매니저(601)는, 실행되는 복수 개의 노드들 중 적어도 일부 중 적어도 일부 각각의 단위 시간당 처리하는 메시지의 크기가 가장 큰 노드와 통신 속도가 가장 빠르거나, 또는 통신 비용이 가장 낮은 노드를 선택할 수도 있으며, 제한은 없다. xAPP 매니저(601)는, 649 동작에서, 선택된 노드에 xAPP의 디플로이를 k8s(602)에 요청할 수 있다. k8s(602)는, 651 동작에서, k8s 스케줄러(603)에 디플로이를 요청할 수 있다. k8s 스케줄러(603)는, 653 동작에서, RIC(101)에서 실행되는 복수 개의 노드들 중 적어도 일부 각각의 가용 리소스들에 대한 정보를 k8s 노드 매니저(604)에 요청할 수 있다. k8s 노드 매니저(604)는, 655 동작에서, 요청에 응답하여 RIC(101)에서 실행되는 복수 개의 노드들 중 적어도 일부 각각의 가용 리소스들에 대한 정보를 제공할 수 있다. 예를 들어, k8s 스케줄러(603)는, xAPP의 디플로이가 가능함에 기반하여, 657 동작에서, k8s(602)로 디플로이를 요청할 수 있다. 예를 들어, k8s 스케줄러(603)는, 해당 노드의 가용 리소스가 xAPP의 디플로이에 충분함에 기반하여, 디플로이를 요청할 수 있다. k8s(602)는, xAPP의 디플로이가 불가능함을 xAPP 매니저(601)로 통지할 수 있다. k8s(602)는, 659 동작에서, 선택된 노드에 xAPP을 디플로이할 수 있다. k8s(602)는, 661 동작에서, xAPP 디플로이 완료를 xAPP 매니저(601)에 통지할 수 있다.

도 7은 다양한 실시예에 따른 RIC의 동작 방법을 도시하는 흐름도이다.

다양한 실시예에 따르면, RIC(101)(예를 들어, 프로세서(120))(또는, RIC(101)의 기능을 실행하는 전자 장치)는, 701 동작에서, 제 1 xAPP의 적어도 하나의 타겟 E2 노드를 확인할 수 있다. 도 5를 참조하여 설명한 바와 같이, RIC(101)는 예를 들어 제 1 xAPP의 Pod의 메타데이터에 포함된 구독과 연관된 정보에 기반하여, 제 1 xAPP의 적어도 하나의 타겟 E2 노드를 확인할 수 있다. 하나의 예에서, 제 1 xAPP의 Pod의 메타데이터에는, 서비스 모델, 메시지의 처리 주기, 메시지 템플릿의 크기 및/또는 UE별 정보 요구 여부가 포함될 수 있다. RIC(101)는, 예를 들어 제 1 xAPP의 Pod에 포함된 서비스 모델과 동일한 서비스 모델을 가지는 적어도 하나의 타겟 E2 노드를 확인할 수 있다. 상술한 바와 같이, RIC(101)는, 연결된 적어도 하나의 E2 노드들 각각의 정보를 관리할 수 있으며, 이에 따라 제 1 xAPP의 Pod에 포함된 서비스 모델과 동일한 서비스 모델을 가지는 적어도 하나의 타겟 E2 노드를 확인할 수 있다.

다양한 실시예에 따라서, RIC(101)는, 703 동작에서, 적어도 하나의 타겟 E2 노드 각각의 단위 시간당 처리하는 메시지의 크기를 확인할 수 있다. 예를 들어, RIC(101)는, 제 1 xAPP의 Pod의 메타데이터에 포함된 메시지의 처리 주기 및 메시지 템플릿의 크기에 기반하여, 적어도 하나의 타겟 E2 노드 각각의 단위 시간당 처리하는 메시지의 크기를 확인할 수 있다. 예를 들어, 제 1 xAPP의 Pod의 메타데이터에 포함된 구독과 연관된 정보에는, 서비스 모델 별로, 메시지의 처리 주기, 메시지 템플릿의 크기 및/또는 UE별 정보 요구 여부를 포함할 수도 있다. 예를 들어, E2 노드가 RIC(101)에 연결되는 E2 셋업 도중에, RIC(101)의 내부 데이터베이스에 서비스 모델 및 E2 노드 식별자(E2 node ID)가 연관되어 저장될 수 있다. 메시지의 템플릿의 크기 및 메시지의 처리 주기는, xAPP의 메타데이터에 포함되며, 해당 메타데이터에 기반하여 subscription이 생성될 수 있다. Subscription은 E2 노드 식별자를 기반으로 하기 때문에, subscription 도중에 서비스 모델 및 E2 노드 식별자가 연관되어 저장 및/또는 관리될 수도 있다. RIC(101)는, 메타데이터에 포함된 서비스 모델에 기반하여, 타겟 노드를 확인할 수 있다. RIC(101)는, 서비스 모델에 대응하는 메시지의 처리 주기, 메시지 템플릿의 크기 및/또는 UE별 정보 요구 여부를, 확인된 타겟 노드의 메시지의 처리 주기, 메시지 템플릿의 크기 및/또는 UE별 정보 요구 여부로서 확인할 수도 있다. 만약 제 1 xAPP이 UE별 정보를 요구하는 경우에는, RIC(101)는 적어도 하나의 타겟 E2 노드 각각에 연결된 UE의 개수를 더 이용하여, 적어도 하나의 타겟 E2 노드 각각의 단위 시간당 처리하는 메시지의 크기를 확인할 수 있다.

다양한 실시예에 따라서, RIC(101)는, 705 동작에서, 적어도 하나의 타겟 E2 노드 각각의 단위 시간당 처리하는 메시지의 크기에 기반하여, 복수 개의 노드들 중 적어도 일부 각각의 단위시간 당 처리하는 메시지의 크기를 확인할 수 있다. RIC(101)는, 707 동작에서, 확인된 복수 개의 노드들 중 적어도 일부 각각의 단위시간 당 처리하는 메시지의 크기에 기반하여, 제 1xAPP을 디플로이할 노드를 선택할 수 있다. 예를 들어, RIC(101)는, 복수 개의 노드들 중 적어도 일부로부터, 단위시간 당 처리하는 메시지가 가장 큰 노드를 선택할 수 있다.

도 8은 다양한 실시예에 따른 RIC의 동작 방법을 도시하는 흐름도이다.

다양한 실시예에 따르면, RIC(101)(예를 들어, 프로세서(120))(또는, RIC(101)의 기능을 실행하는 전자 장치)는, 801 동작에서, 제 1 xAPP의 Pod에 대한 디플로이 요청을 확인할 수 있다. RIC(101)는, 803 동작에서, 제 1 xAPP에 대응하는 적어도 하나의 타겟 E2 노드를 확인할 수 있다. 제 1 xAPP에 대응하는 적어도 하나의 타겟 E2 노드를 확인하는 방식은 상술하였으므로, 여기에서의 상세한 설명은 생략하도록 한다. RIC(101)는, 805 동작에서, 제 1 xAPP에 대응하는 적어도 하나의 타겟 E2 노드의 개수가 하나인지 여부를 확인할 수 있다. 만약, 적어도 하나의 타겟 E2 노드의 개수가 하나인 경우(805-예), RIC(101)는, 807 동작에서, 하나의 타겟 E2 노드에 연결된 제 1 노드의 가용 리소스가 제 1 xAPP이 요구하는 리소스 이상인지 여부를 확인할 수 있다. 만약, 하나의 타겟 E2 노드에 연결된 제 1 노드의 가용 리소스가 제 1 xAPP이 요구하는 리소스 이상인 경우(807-예), RIC(101)는 809 동작에서 제 1 노드에 제 1 xAPP을 디플로이할 수 있다. 하나의 타겟 E2 노드만이 존재하는 경우에는, 해당 E2 노드에 연결된 노드에 제 1 xAPP가 디플로이된 경우에 RIC(101)의 내부 트래픽이 최소화될 수 있다. 만약, 하나의 타겟 E2 노드에 연결된 제 1 노드의 가용 리소스가 제 1 xAPP이 요구하는 리소스 미만인 경우(807-아니오), RIC(101)는 811 동작에서 제 1 노드와의 통신 속도 및/또는 통신 비용에 기반하여 선택된 제 2 노드에 제 1 xAPP을 디플로이할 수 있다. 예를 들어, RIC(101)는, 제 1 노드와의 통신 속도가 가장 빠른 노드를 제 2 노드로서 선택할 수 있다. 또는, RIC(101)는, 제 1 노드와의 통신 비용이 가장 작은 노드를 제 2 노드로서 선택할 수 있다. 적어도 하나의 타겟 E2 노드의 개수가 둘 이상인 경우(805-아니오), RIC(101)는, 813 동작에서, 복수 개의 타겟 E2 노드들 중 적어도 일부 각각의 단위시간 당 처리하는 메시지의 크기에 기반하여, 제 1xAPP을 디플로이할 노드를 선택할 수 있다. 예를 들어, RIC(101)는, 복수 개의 타겟 E2 노드들 중 적어도 일부 중 가장 큰 단위시간 당 처리하는 메시지의 크기를 가지는 노드를 선택할 수 있다. 또는, 다른 예에서, RIC(101)는, 가장 큰 단위시간 당 처리하는 메시지의 크기를 가지는 노드와의 통신 속도 및/또는 통신 비용에 기반하여 제 1 xAPP을 디플로이할 노드를 선택할 수도 있다. 예를 들어, 가장 큰 단위시간 당 처리하는 메시지의 크기를 가지는 노드의 가용 리소스가 제 1 xAPP이 요구하는 리소스보다 작거나, 또는 제 1 xAPP이 요구하는 리소스보다 임계값 이상 크지 않은 경우에, RIC(101)는 해당 노드와의 통신 속도 및/또는 통신 비용에 기반하여 제 1 xAPP을 디플로이할 노드를 선택할 수도 있다. RIC(101)는 예를 들어 해당 노드와의 통신 속도가 가장 빠른 노드를 제 1 xAPP을 디플로이할 노드로서 선택할 수도 있다. 또는, RIC(101)는 예를 들어 해당 노드와의 통신 비용이 가장 낮은 노드를 제 1 xAPP을 디플로이할 노드로서 선택할 수도 있다. RIC(101)는, 815 동작에서, 선택된 노드에 제 1 xAPP을 디플로이할 수 있다.

도 9a는 다양한 실시예에 따른 RIC의 동작 방법을 도시하는 흐름도이다. 도 9a의 실시예는 도 9b를 참조하여 설명하도록 한다. 도 9b는 다양한 실시예에 따른 xAPP을 디플로이하는 과정을 도시하는 도면이다.

다양한 실시예에 따르면, RIC(101)(예를 들어, 프로세서(120))(또는, RIC(101)의 기능을 실행하는 전자 장치)는, 901 동작에서, 제 1 xAPP에 대응하는 적어도 하나의 타겟 E2 노드를 확인할 수 있다. RIC(101)는, 903 동작에서, 적어도 하나의 타겟 E2 노드 각각에 대응하는 메시지의 처리 주기를 확인할 수 있다. 예를 들어, RIC(101)는, 표 1과 같은, 적어도 하나의 타겟 E2 노드 각각에 대응하는 메시지의 처리 주기를 확인할 수 있다. 905 동작에서, RIC(101)는, 적어도 하나의 타겟 E2 노드 각각에 대응하는 메시지의 크기를 확인할 수 있다. 예를 들어, RIC(101)는, 표 2와 같은, 적어도 하나의 타겟 E2 노드 각각에 대응하는 메시지의 크기를 확인할 수 있다. RIC(101)는, 907 동작에서, 적어도 하나의 타겟 E2 노드 별, 메시지의 크기를, 메시지의 처리 주기로 나누는 계산에 기반하는 적어도 하나의 단위 시간당 처리하는 메시지의 크기를 확인할 수 있다. 예를 들어, RIC(101)는, 표 3과 같은 적어도 하나의 타겟 E2 노드 각각의 적어도 하나의 단위 시간당 처리하는 메시지의 크기를 확인할 수 있다. RIC(101)는, 909 동작에서, 적어도 하나의 단위 시간당 처리하는 메시지의 크기에 기반하여 제 1 xAPP을 디플로이할 노드를 선택할 수 있다. 예를 들어, RIC(101)는, 표 3과 같은 적어도 하나의 타겟 E2 노드 각각의 적어도 하나의 단위 시간당 처리하는 메시지의 크기에 기반하여, 표 4와 같은 노드 별 단위 시간당 처리하는 메시지의 크기를 확인할 수 있다. 표 4의 예시에서는, 도 9b에서의 제 3 노드(230)가 가장 큰 단위 시간당 처리하는 메시지의 크기를 가지는 것으로 확인될 수 있다. 예를 들어, xAPP 매니저(401)는, 제 3 노드(230)가 가장 큰 단위 시간당 처리하는 메시지의 크기를 가지는 것에 기반하여, 제 3 노드(230)를 선택할 수 있다. RIC(101)는, 911 동작에서, 선택된 노드에 xAPP을 디플로이할 수 있다. xAPP 매니저(401)는, 제 3 노드(230)에 xAPP(예를 들어, xAPP #3(901))을 디플로이할 수 있다. 디플로이된 xAPP(예를 들어, xAPP #3(901))는, E2 노드 #3(243), E2 노드 #14(251), E2 노드 #34(261), E2 노드 #35(262)를 구독할 수 있다. E2 노드 #3(243)의 E2 메시지는, 경로들(911,912,913,914)을 경유하여 디플로이된 xAPP(예를 들어, xAPP #3(901))으로 제공될 수 있다. E2 노드 #14(251)의 E2 메시지는, 경로들(921,922,923,924)을 경유하여 디플로이된 xAPP(예를 들어, xAPP #3(901))으로 제공될 수 있다. E2 노드 #34(261)의 E2 메시지 및 E2 노드 #35(262)의 E2 메시지는, 경로들(931,932,933)을 경유하여 디플로이된 xAPP(예를 들어, xAPP #3(901))으로 제공될 수 있다. 경로들(911,912,913)을 통하는 E2 메시지의 전달과 경로들(921,922,923)을 통하는 E2 메시지의 전달에 의하여 RIC(101) 내부 트래픽이 발생할 수 있다. 하지만, 상술한 내부 트래픽은, E2 노드 #34(261)로부터의 E2 메시지 및/또는 E2 노드 #35(262)로부터의 E2 메시지가 다른 노드로 전달된 경우에 발생할 수 있는 내부 트래픽보다는 작을 수 있다. 이에 따라, 내부 트래픽이 최소화될 수 있는 노드에 xAPP이 디플로이될 수 있다. 한편, 도 9a 및 도 9b에서는, 노드들(210,220,230) 사이의 통신 비용이 동일한 경우에 적용이 될 수 있다. 노드들(210,220,230) 사이의 통신 비용은 상이할 수도 있으며, 이에 대하여서는 도 10을 참조하여 설명하도록 한다.

도 10은 다양한 실시예에 따른 RIC의 동작 방법을 도시하는 흐름도이다.

다양한 실시예에 따르면, RIC(101)(예를 들어, 프로세서(120))(또는, RIC(101)의 기능을 실행하는 전자 장치)는, 1001 동작에서, 제 1 xAPP에 대응하는 적어도 하나의 타겟 E2 노드를 확인할 수 있다. 1003 동작에서, RIC(101)는 적어도 하나의 타겟 E2 노드 각각 별 단위 시간당 처리하는 메시지의 크기를 확인할 수 있다. 예를 들어, RIC(101)는, 표 3과 같은 적어도 하나의 타겟 E2 노드 각각 별 단위 시간당 처리하는 메시지의 크기를 확인할 수 있다. RIC(101)는, 1005 동작에서, 복수 개의 노드들 각각 사이의 통신 비용을 확인할 수 있다. 예를 들어, 제 1 노드(210) 및 제 2 노드(220) 사이의 통신 비용의 가중치는 c1이고, 제 2 노드(220) 및 제 3 노드(230) 사이의 통신 비용의 가중치는 c2이고, 제 1 노드(210) 및 제 3 노드(230) 사이의 통신 비용의 가중치는 c3인 것으로 확인된 것을 상정하도록 한다. 통신 비용의 가중치들(c1,c2,c3)은, 노드들 사이의 통신에 요구되는 비용의 상대적인 값일 수 있다. 예를 들어, 가중치가 높을수록 해당 노드들 사이의 통신 비용이 높은 것을 의미할 수 있다. RIC(101)는, 노드 별로, 통신 비용을 확인할 수 있다. 예를 들어, 제 1 노드(210)에 제 1 xAPP이 디플로이된 경우에는, E2 노드 #3으로부터의 단위 시간당 처리하는 메시지의 크기인 0.128kb/ms와, E2 노드 #14로부터의 단위 시간당 처리하는 메시지의 크기인 0.064kb/ms에 c1의 가중치를 곱한 값과, E2 노드 #34로부터의 단위 시간당 처리하는 메시지의 크기인 25.6kb/ms에 c3의 가중치를 곱한 값과, E2 노드 #35로부터의 단위 시간당 처리하는 메시지의 크기인 1.28kb/ms에 c3의 가중치를 곱한 값의 합계가 통신 비용을 고려한 단위 시간당 처리하는 메시지의 크기로서 확인될 수 있다. 예를 들어, 제 2 노드(220)에 제 1 xAPP이 디플로이된 경우에는, E2 노드 #3으로부터의 단위 시간당 처리하는 메시지의 크기인 0.128kb/ms에 c1의 가중치를 곱한 값과, E2 노드 #14로부터의 단위 시간당 처리하는 메시지의 크기인 0.064kb/ms와, E2 노드 #34로부터의 단위 시간당 처리하는 메시지의 크기인 25.6kb/ms에 c2의 가중치를 곱한 값과, E2 노드 #35로부터의 단위 시간당 처리하는 메시지의 크기인 1.28kb/ms에 c2의 가중치를 곱한 값의 합계가 통신 비용을 고려한 단위 시간당 처리하는 메시지의 크기로서 확인될 수 있다. 예를 들어, 제 3 노드(230)에 제 1 xAPP이 디플로이된 경우에는, E2 노드 #3으로부터의 단위 시간당 처리하는 메시지의 크기인 0.128kb/ms에 c3의 가중치를 곱한 값과, E2 노드 #14로부터의 단위 시간당 처리하는 메시지의 크기인 0.064kb/ms에 c2의 가중치를 곱한 값과, E2 노드 #34로부터의 단위 시간당 처리하는 메시지의 크기인 25.6kb/ms와, E2 노드 #35로부터의 단위 시간당 처리하는 메시지의 크기인 1.28kb/ms 의 합계가 통신 비용을 고려한 단위 시간당 처리하는 메시지의 크기로서 확인될 수 있다. RIC(101)는, 1007 동작에서, 복수 개의 노드들로부터 제 1 xAPP을 디플로이할 노드를 선택할 수 있다. 예를 들어, RIC(101)는, 복수 개의 노드들 중 통신 비용을 고려한 단위 시간당 처리하는 메시지가 가장 작은 노드를 제 1 xAPP을 디플로이할 노드로 선택할 수 있다. RIC(101)는, 1009 동작에서, 선택된 노드에 제 1 xAPP을 디플로이할 수 있다.

도 11a는 다양한 실시예에 따른 RIC의 동작 방법을 도시하는 흐름도이다. 도 11a의 실시예는 도 11b를 참조하여 설명하도록 한다. 도 11b는 다양한 실시예에 따른 xAPP의 디플로이 과정을 도시하는 도면이다.

다양한 실시예에 따르면, RIC(101)(예를 들어, 프로세서(120))(또는, RIC(101)의 기능을 실행하는 전자 장치)는, 1101 동작에서, 제 1 xAPP의 Pod에 대한 디플로이 요청을 확인할 수 있다. RIC(101)는, 1103 동작에서, 제 1 xAPP의 Pod에 포함되는 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보를 확인할 수 있다. RIC(101)는, 1105 동작에서, 구독과 연관된 정보에 기반하여, 제 1 xAPP이 제 1 노드에 연결된 E2 노드에 대한 구독을 요구함을 확인할 수 있다. 예를 들어, RIC(101)는, 구독과 연관된 정보에 포함된 서비스 모델에 기반하여, 제 1 노드에 연결된 E2 노드에 대한 구독을 요구함을 확인할 수 있다. RIC(101)는, 1107 동작에서, 확인된 E2 노드에 연결되는 노드에 xAPP을 디플로이 할 수 있다. 예를 들어, 도 11b의 실시예에서는, RIC(101)는, xAPP(예를 들어, xAPP #3(1110))이 E2 노드 #14(251)에 대한 구독을 요구함을 확인할 수 있다. RIC(101)는, 이에 따라 xAPP(예를 들어, xAPP #3(1110))을 E2 노드 #14(251)가 연결된 제 2 노드(220)에 디플로이할 수 있다. xAPP(예를 들어, xAPP #3(1110))은, 제 2 노드(220)에서 디플로이되어, E2 노드 #14(251)를 구독할 수 있다. E2 노드 #14(251)로부터의 E2 메시지는, 경로들(1101,1102,1103)을 통하여 xAPP(예를 들어, xAPP #3(1110))로 제공될 수 있으며, 이에 따라 내부 트래픽 및/또는 통신 비용이 최소화될 수 있다. 도시되지는 않았지만, xAPP(예를 들어, xAPP #3(1110))가 제 3 노드(230)에 연결되는 E2 노드 #34(261)에 대한 구독을 요구하는 경우에는, RIC(101)는 제 3 노드(230)에 xAPP(예를 들어, xAPP #3(1110))를 디플로이할 수도 있다. 또는, xAPP(예를 들어, xAPP #3(1110))가 제 1 노드(210)에 연결되는 E2 노드 #1(241)에 대한 구독을 요구하는 경우에는, RIC(101)는 제 1 노드(210)에 xAPP(예를 들어, xAPP #3(1110))를 디플로이할 수도 있으며, 하나의 노드에 복수 개의 xAPP이 디플로이될 수도 있다.

다양한 실시예에 따라서, RIC(예를 들어, RIC(101))의 동작 방법은, 제 1 xAPP의 Pod에 대한 디플로이 요청을 확인하는 동작, 상기 요청에 기반하여, 상기 Pod에 포함되는 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 기반하여, 상기 RIC에서 실행되는 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보를 확인하는 동작, 및 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보에 기반하여, 상기 복수 개의 노드들 중 선택된 제 1 노드에 상기 제 1 xAPP을 디플로이하는 동작을 포함할 수 있다.

다양한 실시예에 따라서, RIC의 동작 방법은, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보와, 상기 복수 개의 노드들 중 적어도 일부의 가용 리소스 및 상기 제 1 xAPP이 요구하는 리소스에 기반하여, 상기 제 1 노드를 선택하는 동작을 더 포함할 수 있다.

다양한 실시예에 따라서, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보와, 상기 복수 개의 노드들 중 적어도 일부의 가용 리소스 및 상기 제 1 xAPP이 요구하는 리소스에 기반하여, 상기 제 1 노드를 선택하는 동작은, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보에 기반하여, 상기 복수 개의 노드들 중 적어도 일부 중 하나의 노드를 선택하는 동작, 및 상기 선택된 하나의 노드의 가용 리소스 및 상기 제 1 xAPP이 요구하는 리소스에 기반하여, 상기 선택된 하나의 노드에 상기 제 1 xAPP이 디플로이 가능한 것으로 확인됨에 기반하여, 상기 선택된 하나의 노드를 상기 제 1 노드로서 선택하는 동작을 포함할 수 있다.

다양한 실시예에 따라서, RIC의 동작 방법은, 상기 선택된 하나의 노드의 가용 리소스 및 상기 제 1 xAPP이 요구하는 리소스에 기반하여, 상기 선택된 하나의 노드에 상기 제 1 xAPP이 디플로이 불가능한 것으로 확인됨에 기반하여, 상기 선택된 하나의 노드와 상이한 다른 노드를 상기 제 1 노드로서 선택하는 동작을 더 포함할 수 있다.

다양한 실시예에 따라서, 상기 선택된 하나의 노드와 상이한 다른 노드를 상기 제 1 노드로서 선택하는 동작은, 상기 다른 노드가 처리하는 메시지와 연관된 정보에 기반하여, 상기 다른 노드를 선택할 수 있다.

다양한 실시예에 따라서, 상기 선택된 하나의 노드와 상이한 다른 노드를 상기 제 1 노드로서 선택하는 동작은, 상기 선택된 하나의 노드와의 통신 속도 및/또는 통신 비용에 기반하여 상기 다른 노드를 선택할 수 있다.

다양한 실시예에 따라서, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보와, 상기 복수 개의 노드들 중 적어도 일부의 가용 리소스 및 상기 제 1 xAPP이 요구하는 리소스에 기반하여, 상기 제 1 노드를 선택하는 동작은, 상기 복수 개의 노드들 중 적어도 일부 각각의 가용 리소스 및 상기 제 1 xAPP이 요구하는 리소스에 기반하여, 상기 제 1 xAPP을 디플로이할 수 있는 적어도 하나의 노드를 확인하는 동작, 및 상기 적어도 하나의 노드 각각이 처리하는 메시지와 연관된 정보에 기반하여 상기 제 1 노드를 선택하는 동작을 포함할 수 있다.

다양한 실시예에 따라서, RIC의 동작 방법은, 상기 복수 개의 노드들 중 적어도 일부 각각이 단위 시간당 처리하는 메시지의 크기를, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보로서 확인하는 동작을 더 포함할 수 있다.

다양한 실시예에 따라서, 상기 복수 개의 노드들 중 적어도 일부 각각이 단위 시간당 처리하는 메시지의 크기를, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보로서 확인하는 동작은, 상기 제 1 xAPP이 구독을 요구하는 적어도 하나의 E2 노드를 확인하는 동작, 상기 적어도 하나의 E2 노드 각각의 메시지 처리 주기 및/또는 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기를 확인하는 동작, 상기 적어도 하나의 E2 노드 각각의 메시지 처리 주기 및/또는 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기에 기반하여, 상기 적어도 하나의 E2 노드 각각의 단위 시간당 처리하는 메시지의 크기를 확인하는 동작, 및 상기 적어도 하나의 E2 노드 각각에 연결되는 노드에 대한 정보에 기반하여, 상기 복수 개의 노드들 중 적어도 일부 각각이 단위 시간당 처리하는 메시지의 크기를 확인하는 동작을 포함할 수 있다.

다양한 실시예에 따라서, 상기 제 1 xAPP이 구독을 요구하는 상기 적어도 하나의 E2 노드를 확인하는 동작은, 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보와 상기 RIC에 저장된 상기 RIC에 연결된 복수 개의 E2 노드들 각각의 정보에 기반하여, 상기 적어도 하나의 E2 노드를 확인할 수 있다.

다양한 실시예에 따라서, 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보와 상기 RIC에 저장된 상기 RIC에 연결된 복수 개의 E2 노드들 각각의 정보에 기반하여, 상기 적어도 하나의 E2 노드를 확인하는 동작은, 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 포함되는 서비스 모델(service model)과 동일한 서비스 모델을 가지는 상기 적어도 하나의 E2 노드를 확인할 수 있다.

다양한 실시예에 따라서, 상기 적어도 하나의 E2 노드 각각의 메시지 처리 주기 및/또는 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기를 확인하는 동작은, 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 포함되는 메시지의 템플릿의 크기에 기반하여, 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기를 확인할 수 있다.

다양한 실시예에 따라서, 상기 적어도 하나의 E2 노드 각각의 메시지 처리 주기 및/또는 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기를 확인하는 동작은, 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 포함되는 메시지의 처리 주기에 기반하여, 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 처리 주기를 확인할 수 있다.

다양한 실시예에 따라서, RIC의 동작 방법은, 상기 복수 개의 노드들 중 적어도 일부 각각의 메시지 처리 주기 및/또는 처리하는 메시지의 크기를, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보로서 확인하는 동작을 더 포함할 수 있다.

다양한 실시예에 따라서, RIC의 동작 방법은, 상기 Pod에 포함되는 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 기반하여, 상기 제 1 xAPP에 대응하는 E2 노드의 개수가 하나로 확인됨에 기반하여, 상기 하나의 E2 노드에 연결된 노드에 상기 제 1 xAPP을 디플로이하는 동작을 더 포함할 수 있다.

다양한 실시예에 따라서, RIC의 동작 방법은, 상기 복수 개의 노드들 중 적어도 일부 각각에 대응하는 통신 비용을, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보로서 확인하는 동작을 더 포함할 수 있다.

다양한 실시예에 따라서, 상기 복수 개의 노드들 중 적어도 일부 각각에 대응하는 통신 비용을, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보로서 확인하는 동작은, 상기 제 1 xAPP이 구독을 요구하는 적어도 하나의 E2 노드를 확인하는 동작, 상기 적어도 하나의 E2 노드 각각의 메시지 처리 주기 및/또는 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기를 확인하는 동작, 상기 적어도 하나의 E2 노드 각각의 메시지 처리 주기 및/또는 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기에 기반하여, 상기 적어도 하나의 E2 노드 각각의 단위 시간당 처리하는 메시지의 크기를 확인하는 동작, 상기 적어도 하나의 E2 노드 각각에 연결되는 노드에 대한 정보에 기반하여, 상기 복수 개의 노드들 중 적어도 일부 각각이 단위 시간당 처리하는 메시지의 크기를 확인하는 동작, 및 상기 복수 개의 노드들 중 적어도 일부 각각이 단위 시간당 처리하는 메시지의 크기 및 상기 복수 개의 노드들 중 적어도 일부 사이의 통신 비용과 연관된 파라미터에 기반하여, 상기 복수 개의 노드들 중 적어도 일부 각각에 대응하는 통신 비용을 확인하는 동작을 포함할 수 있다.

다양한 실시예에 따라서, 상기 Pod에 포함되는 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 기반하여, 상기 제 1 xAPP이 구독을 요구하는 E2 노드를 확인하는 동작은, 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 포함되는 서비스 모델(service model)과 동일한 서비스 모델을 가지는 상기 E2 노드를 확인할 수 있다.

다양한 실시예에 따라서, RIC의 동작 방법은, 데이터 처리 시스템에 의하여 억세스되는 xApp의 Pod를 저장하는 저장 매체에 저장된 상기 Pod는 제 1 데이터 및 제 2 데이터를 포함하고, 상기 제 1 데이터는, 상기 xAPP이 구독을 요구하는 적어도 하나의 E2 노드의 확인에 이용되는 제 1 서브 데이터, 상기 적어도 하나의 E2 노드 각각의 메시지 처리의 주기의 확인에 이용되는 제 2 서브 데이터, 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지 처리의 크기의 확인에 이용되는 제 3 서브 데이터, 또는 상기 적어도 하나의 E2 노드로부터의 E2 메시지가 UE와 연관된 정보를 포함하는 지 여부를 확인하는데 이용되는 제 4 서브 데이터 중 적어도 하나를 포함하고, 상기 제 2 데이터는, 상기 xAPP의 적어도 하나의 동작을 위한 정보를 포함할 수 있다.

다양한 실시예에 따라서, RIC(예를 들어, RIC(101))는, 적어도 하나의 프로세서(예를 들어, 프로세서(120))는, 제 1 xAPP의 Pod에 대한 디플로이 요청을 확인하고, 상기 요청에 기반하여, 상기 Pod에 포함되는 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 기반하여, 상기 RIC에서 실행되는 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보를 확인하고, 및 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보에 기반하여, 상기 복수 개의 노드들 중 선택된 제 1 노드에 상기 제 1 xAPP을 디플로이하도록 설정될 수 있다.

다양한 실시예에 따라서, 적어도 하나의 프로세서는, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보와, 상기 복수 개의 노드들 중 적어도 일부의 가용 리소스 및 상기 제 1 xAPP이 요구하는 리소스에 기반하여, 상기 제 1 노드를 선택하도록 더 설정될 수 있다.

다양한 실시예에 따라서, 상기 적어도 하나의 프로세서는, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보에 기반하여, 상기 복수 개의 노드들 중 적어도 일부 중 하나의 노드를 선택하고, 상기 선택된 하나의 노드의 가용 리소스 및 상기 제 1 xAPP이 요구하는 리소스에 기반하여, 상기 선택된 하나의 노드에 상기 제 1 xAPP이 디플로이 가능한 것으로 확인됨에 기반하여, 상기 선택된 하나의 노드를 상기 제 1 노드로서 선택하도록 설정될 수 있다.

다양한 실시예에 따라서, 적어도 하나의 프로세서는, 상기 선택된 하나의 노드의 가용 리소스 및 상기 제 1 xAPP이 요구하는 리소스에 기반하여, 상기 선택된 하나의 노드에 상기 제 1 xAPP이 디플로이 불가능한 것으로 확인됨에 기반하여, 상기 선택된 하나의 노드와 상이한 다른 노드를 상기 제 1 노드로서 선택하도록 더 설정될 수 있다.

다양한 실시예에 따라서, 적어도 하나의 프로세서는, 상기 선택된 하나의 노드와 상이한 다른 노드를 상기 제 1 노드로서 선택하는 동작의 적어도 일부로, 상기 다른 노드가 처리하는 메시지와 연관된 정보에 기반하여, 상기 다른 노드를 선택할 수 있다.

다양한 실시예에 따라서, 적어도 하나의 프로세서는, 상기 선택된 하나의 노드와 상이한 다른 노드를 상기 제 1 노드로서 선택하는 동작의 적어도 일부로, 상기 선택된 하나의 노드와의 통신 속도 및/또는 통신 비용에 기반하여 상기 다른 노드를 선택할 수 있다.

다양한 실시예에 따라서, 적어도 하나의 프로세서는, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보와, 상기 복수 개의 노드들 중 적어도 일부의 가용 리소스 및 상기 제 1 xAPP이 요구하는 리소스에 기반하여, 상기 제 1 노드를 선택하는 동작의 적어도 일부로, 상기 복수 개의 노드들 중 적어도 일부 각각의 가용 리소스 및 상기 제 1 xAPP이 요구하는 리소스에 기반하여, 상기 제 1 xAPP을 디플로이할 수 있는 적어도 하나의 노드를 확인하고, 상기 적어도 하나의 노드 각각이 처리하는 메시지와 연관된 정보에 기반하여 상기 제 1 노드를 선택할 수 있다.

다양한 실시예에 따라서, 적어도 하나의 프로세서는, 상기 복수 개의 노드들 중 적어도 일부 각각이 단위 시간당 처리하는 메시지의 크기를, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보로서 확인하도록 더 설정될 수 있다.

다양한 실시예에 따라서, 적어도 하나의 프로세서는, 상기 복수 개의 노드들 중 적어도 일부 각각이 단위 시간당 처리하는 메시지의 크기를, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보로서 확인하는 동작의 적어도 일부로, 상기 제 1 xAPP이 구독을 요구하는 적어도 하나의 E2 노드를 확인하고, 상기 적어도 하나의 E2 노드 각각의 메시지 처리 주기 및/또는 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기를 확인하고, 상기 적어도 하나의 E2 노드 각각의 메시지 처리 주기 및/또는 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기에 기반하여, 상기 적어도 하나의 E2 노드 각각의 단위 시간당 처리하는 메시지의 크기를 확인하고, 상기 적어도 하나의 E2 노드 각각에 연결되는 노드에 대한 정보에 기반하여, 상기 복수 개의 노드들 중 적어도 일부 각각이 단위 시간당 처리하는 메시지의 크기를 확인할 수 있다.

다양한 실시예에 따라서, 적어도 하나의 프로세서는, 상기 제 1 xAPP이 구독을 요구하는 상기 적어도 하나의 E2 노드를 확인하는 동작의 적어도 일부로, 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보와 상기 RIC에 저장된 상기 RIC에 연결된 복수 개의 E2 노드들 각각의 정보에 기반하여, 상기 적어도 하나의 E2 노드를 확인할 수 있다.

다양한 실시예에 따라서, 적어도 하나의 프로세서는, 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보와 상기 RIC에 저장된 상기 RIC에 연결된 복수 개의 E2 노드들 각각의 정보에 기반하여, 상기 적어도 하나의 E2 노드를 확인하는 동작의 적어도 일부로, 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 포함되는 서비스 모델(service model)과 동일한 서비스 모델을 가지는 상기 적어도 하나의 E2 노드를 확인할 수 있다.

다양한 실시예에 따라서, 적어도 하나의 프로세서는, 상기 적어도 하나의 E2 노드 각각의 메시지 처리 주기 및/또는 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기를 확인하는 동작의 적어도 일부로, 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 포함되는 메시지의 템플릿의 크기에 기반하여, 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기를 확인할 수 있다.

다양한 실시예에 따라서, 적어도 하나의 프로세서는, 상기 적어도 하나의 E2 노드 각각의 메시지 처리 주기 및/또는 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기를 확인하는 동작의 적어도 일부로, 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 포함되는 메시지의 처리 주기에 기반하여, 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 처리 주기를 확인할 수 있다.

다양한 실시예에 따라서, 적어도 하나의 프로세서는, 상기 복수 개의 노드들 중 적어도 일부 각각의 메시지 처리 주기 및/또는 처리하는 메시지의 크기를, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보로서 확인하도록 더 설정될 수 있다.

다양한 실시예에 따라서, 적어도 하나의 프로세서는, 상기 Pod에 포함되는 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 기반하여, 상기 제 1 xAPP에 대응하는 E2 노드의 개수가 하나로 확인됨에 기반하여, 상기 하나의 E2 노드에 연결된 노드에 상기 제 1 xAPP을 디플로이하도록 더 설정될 수 있다.

다양한 실시예에 따라서, 적어도 하나의 프로세서는, 상기 복수 개의 노드들 중 적어도 일부 각각에 대응하는 통신 비용을, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보로서 확인하도록 더 설정될 수 있다.

다양한 실시예에 따라서, 적어도 하나의 프로세서는, 상기 복수 개의 노드들 중 적어도 일부 각각에 대응하는 통신 비용을, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보로서 확인하는 동작의 적어도 일부로, 상기 제 1 xAPP이 구독을 요구하는 적어도 하나의 E2 노드를 확인하고, 상기 적어도 하나의 E2 노드 각각의 메시지 처리 주기 및/또는 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기를 확인하고, 상기 적어도 하나의 E2 노드 각각의 메시지 처리 주기 및/또는 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기에 기반하여, 상기 적어도 하나의 E2 노드 각각의 단위 시간당 처리하는 메시지의 크기를 확인하고, 상기 적어도 하나의 E2 노드 각각에 연결되는 노드에 대한 정보에 기반하여, 상기 복수 개의 노드들 중 적어도 일부 각각이 단위 시간당 처리하는 메시지의 크기를 확인하고, 상기 복수 개의 노드들 중 적어도 일부 각각이 단위 시간당 처리하는 메시지의 크기 및 상기 복수 개의 노드들 중 적어도 일부 사이의 통신 비용과 연관된 파라미터에 기반하여, 상기 복수 개의 노드들 중 적어도 일부 각각에 대응하는 통신 비용을 확인할 수 있다.

다양한 실시예에 따라서, 적어도 하나의 프로세서는, 제 1 xAPP의 Pod에 대한 디플로이 요청을 확인하고, 상기 요청에 기반하여, 상기 Pod에 포함되는 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 기반하여, 상기 제 1 xAPP이 구독을 요구하는 E2 노드를 확인하고, 및 상기 확인된 E2 노드에 연결된 상기 제 1 xAPP을 디플로이하도록 설정될 수 있다.

다양한 실시예에 따라서, 적어도 하나의 프로세서는, 상기 Pod에 포함되는 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 기반하여, 상기 제 1 xAPP이 구독을 요구하는 E2 노드를 확인하는 동작의 적어도 일부로, 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 포함되는 서비스 모델(service model)과 동일한 서비스 모델을 가지는 상기 E2 노드를 확인할 수 있다.

본 문서에 개시된 다양한 실시예들에 따른 전자 장치는 다양한 형태의 장치가 될 수 있다. 전자 장치는, 예를 들면, 휴대용 통신 장치(예: 스마트폰), 컴퓨터 장치, 휴대용 멀티미디어 장치, 휴대용 의료 기기, 카메라, 웨어러블 장치, 또는 가전 장치를 포함할 수 있다. 본 문서의 실시예에 따른 전자 장치는 전술한 기기들에 한정되지 않는다.

본 문서의 다양한 실시예들 및 이에 사용된 용어들은 본 문서에 기재된 기술적 특징들을 특정한 실시예들로 한정하려는 것이 아니며, 해당 실시예의 다양한 변경, 균등물, 또는 대체물을 포함하는 것으로 이해되어야 한다. 도면의 설명과 관련하여, 유사한 또는 관련된 구성요소에 대해서는 유사한 참조 부호가 사용될 수 있다. 아이템에 대응하는 명사의 단수 형은 관련된 문맥상 명백하게 다르게 지시하지 않는 한, 상기 아이템 한 개 또는 복수 개를 포함할 수 있다. 본 문서에서, "A 또는 B", "A 및 B 중 적어도 하나", "A 또는 B 중 적어도 하나", "A, B 또는 C", "A, B 및 C 중 적어도 하나", 및 "A, B, 또는 C 중 적어도 하나"와 같은 문구들 각각은 그 문구들 중 해당하는 문구에 함께 나열된 항목들 중 어느 하나, 또는 그들의 모든 가능한 조합을 포함할 수 있다. "제 1", "제 2", 또는 "첫째" 또는 "둘째"와 같은 용어들은 단순히 해당 구성요소를 다른 해당 구성요소와 구분하기 위해 사용될 수 있으며, 해당 구성요소들을 다른 측면(예: 중요성 또는 순서)에서 한정하지 않는다. 어떤(예: 제 1) 구성요소가 다른(예: 제 2) 구성요소에, "기능적으로" 또는 "통신적으로"라는 용어와 함께 또는 이런 용어 없이, "커플드" 또는 "커넥티드"라고 언급된 경우, 그것은 상기 어떤 구성요소가 상기 다른 구성요소에 직접적으로(예: 유선으로), 무선으로, 또는 제 3 구성요소를 통하여 연결될 수 있다는 것을 의미한다.

본 문서의 다양한 실시예들에서 사용된 용어 "모듈"은 하드웨어, 소프트웨어 또는 펌웨어로 구현된 유닛을 포함할 수 있으며, 예를 들면, 로직, 논리 블록, 부품, 또는 회로와 같은 용어와 상호 호환적으로 사용될 수 있다. 모듈은, 일체로 구성된 부품 또는 하나 또는 그 이상의 기능을 수행하는, 상기 부품의 최소 단위 또는 그 일부가 될 수 있다. 예를 들면, 일실시예에 따르면, 모듈은 ASIC(application-specific integrated circuit)의 형태로 구현될 수 있다.

본 문서의 다양한 실시예들은 기기(machine)(예: RIC(101)) 의해 읽을 수 있는 저장 매체(storage medium)(예: 내장 메모리(136) 또는 외장 메모리(138))에 저장된 하나 이상의 명령어들을 포함하는 소프트웨어(예: 프로그램(140))로서 구현될 수 있다. 예를 들면, 기기(예: RIC(101))의 프로세서(예: 프로세서(120))는, 저장 매체로부터 저장된 하나 이상의 명령어들 중 적어도 하나의 명령을 호출하고, 그것을 실행할 수 있다. 이것은 기기가 상기 호출된 적어도 하나의 명령어에 따라 적어도 하나의 기능을 수행하도록 운영되는 것을 가능하게 한다. 상기 하나 이상의 명령어들은 컴파일러에 의해 생성된 코드 또는 인터프리터에 의해 실행될 수 있는 코드를 포함할 수 있다. 기기로 읽을 수 있는 저장 매체는, 비일시적(non-transitory) 저장 매체의 형태로 제공될 수 있다. 여기서, ‘비일시적’은 저장 매체가 실재(tangible)하는 장치이고, 신호(signal)(예: 전자기파)를 포함하지 않는다는 것을 의미할 뿐이며, 이 용어는 데이터가 저장 매체에 반영구적으로 저장되는 경우와 임시적으로 저장되는 경우를 구분하지 않는다.

일실시예에 따르면, 본 문서에 개시된 다양한 실시예들에 따른 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다. 컴퓨터 프로그램 제품은 기기로 읽을 수 있는 저장 매체(예: compact disc read only memory(CD-ROM))의 형태로 배포되거나, 또는 어플리케이션 스토어(예: 플레이 스토어TM)를 통해 또는 두 개의 사용자 장치들(예: 스마트 폰들) 간에 직접, 온라인으로 배포(예: 다운로드 또는 업로드)될 수 있다. 온라인 배포의 경우에, 컴퓨터 프로그램 제품의 적어도 일부는 제조사의 서버, 어플리케이션 스토어의 서버, 또는 중계 서버의 메모리와 같은 기기로 읽을 수 있는 저장 매체에 적어도 일시 저장되거나, 임시적으로 생성될 수 있다.

다양한 실시예들에 따르면, 상기 기술한 구성요소들의 각각의 구성요소(예: 모듈 또는 프로그램)는 단수 또는 복수의 개체를 포함할 수 있으며, 복수의 개체 중 일부는 다른 구성요소에 분리 배치될 수도 있다. 다양한 실시예들에 따르면, 전술한 해당 구성요소들 중 하나 이상의 구성요소들 또는 동작들이 생략되거나, 또는 하나 이상의 다른 구성요소들 또는 동작들이 추가될 수 있다. 대체적으로 또는 추가적으로, 복수의 구성요소들(예: 모듈 또는 프로그램)은 하나의 구성요소로 통합될 수 있다. 이런 경우, 통합된 구성요소는 상기 복수의 구성요소들 각각의 구성요소의 하나 이상의 기능들을 상기 통합 이전에 상기 복수의 구성요소들 중 해당 구성요소에 의해 수행되는 것과 동일 또는 유사하게 수행할 수 있다. 다양한 실시예들에 따르면, 모듈, 프로그램 또는 다른 구성요소에 의해 수행되는 동작들은 순차적으로, 병렬적으로, 반복적으로, 또는 휴리스틱하게 실행되거나, 상기 동작들 중 하나 이상이 다른 순서로 실행되거나, 생략되거나, 또는 하나 이상의 다른 동작들이 추가될 수 있다.

Claims

RIC(radio access network intelligent controller)의 동작 방법에 있어서,
제 1 xAPP의 Pod에 대한 디플로이 요청을 확인하는 동작;
상기 요청에 기반하여, 상기 Pod에 포함되는 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 기반하여, 상기 RIC에서 실행되는 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보를 확인하는 동작, 및
상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보에 기반하여, 상기 복수 개의 노드들 중 선택된 제 1 노드에 상기 제 1 xAPP을 디플로이하는 동작
을 포함하는 RIC의 동작 방법.
제 1 항에 있어서,
상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보와, 상기 복수 개의 노드들 중 적어도 일부의 가용 리소스 및 상기 제 1 xAPP이 요구하는 리소스에 기반하여, 상기 제 1 노드를 선택하는 동작
을 더 포함하는 RIC의 동작 방법.
제 2 항에 있어서,
상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보와, 상기 복수 개의 노드들 중 적어도 일부의 가용 리소스 및 상기 제 1 xAPP이 요구하는 리소스에 기반하여, 상기 제 1 노드를 선택하는 동작은,
상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보에 기반하여, 상기 복수 개의 노드들 중 적어도 일부 중 하나의 노드를 선택하는 동작, 및
상기 선택된 하나의 노드의 가용 리소스 및 상기 제 1 xAPP이 요구하는 리소스에 기반하여, 상기 선택된 하나의 노드에 상기 제 1 xAPP이 디플로이 가능한 것으로 확인됨에 기반하여, 상기 선택된 하나의 노드를 상기 제 1 노드로서 선택하는 동작
을 포함하는 RIC의 동작 방법.
제 3 항에 있어서,
상기 선택된 하나의 노드의 가용 리소스 및 상기 제 1 xAPP이 요구하는 리소스에 기반하여, 상기 선택된 하나의 노드에 상기 제 1 xAPP이 디플로이 불가능한 것으로 확인됨에 기반하여, 상기 선택된 하나의 노드와 상이한 다른 노드를 상기 제 1 노드로서 선택하는 동작
을 더 포함하는 RIC의 동작 방법.
제 4 항에 있어서,
상기 선택된 하나의 노드와 상이한 다른 노드를 상기 제 1 노드로서 선택하는 동작은, 상기 다른 노드가 처리하는 메시지와 연관된 정보에 기반하여, 상기 다른 노드를 선택하는 RIC의 동작 방법.
제 4 항에 있어서,
상기 선택된 하나의 노드와 상이한 다른 노드를 상기 제 1 노드로서 선택하는 동작은, 상기 선택된 하나의 노드와의 통신 속도 및/또는 통신 비용에 기반하여 상기 다른 노드를 선택하는 RIC의 동작 방법.
제 2 항에 있어서,
상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보와, 상기 복수 개의 노드들 중 적어도 일부의 가용 리소스 및 상기 제 1 xAPP이 요구하는 리소스에 기반하여, 상기 제 1 노드를 선택하는 동작은,
상기 복수 개의 노드들 중 적어도 일부 각각의 가용 리소스 및 상기 제 1 xAPP이 요구하는 리소스에 기반하여, 상기 제 1 xAPP을 디플로이할 수 있는 적어도 하나의 노드를 확인하는 동작, 및
상기 적어도 하나의 노드 각각이 처리하는 메시지와 연관된 정보에 기반하여 상기 제 1 노드를 선택하는 동작
을 포함하는 RIC의 동작 방법.
제 1 항에 있어서,
상기 복수 개의 노드들 중 적어도 일부 각각이 단위 시간당 처리하는 메시지의 크기를, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보로서 확인하는 동작
을 더 포함하는 RIC의 동작 방법.
제 8 항에 있어서,
상기 복수 개의 노드들 중 적어도 일부 각각이 단위 시간당 처리하는 메시지의 크기를, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보로서 확인하는 동작은,
상기 제 1 xAPP이 구독을 요구하는 적어도 하나의 E2 노드를 확인하는 동작;
상기 적어도 하나의 E2 노드 각각의 메시지 처리 주기 및/또는 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기를 확인하는 동작;
상기 적어도 하나의 E2 노드 각각의 메시지 처리 주기 및/또는 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기에 기반하여, 상기 적어도 하나의 E2 노드 각각의 단위 시간당 처리하는 메시지의 크기를 확인하는 동작, 및
상기 적어도 하나의 E2 노드 각각에 연결되는 노드에 대한 정보에 기반하여, 상기 복수 개의 노드들 중 적어도 일부 각각이 단위 시간당 처리하는 메시지의 크기를 확인하는 동작
을 포함하는 RIC의 동작 방법.
제 9 항에 있어서,
상기 제 1 xAPP이 구독을 요구하는 상기 적어도 하나의 E2 노드를 확인하는 동작은,
상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보와 상기 RIC에 저장된 상기 RIC에 연결된 복수 개의 E2 노드들 각각의 정보에 기반하여, 상기 적어도 하나의 E2 노드를 확인하는 RIC의 동작 방법.
제 10 항에 있어서,
상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보와 상기 RIC에 저장된 상기 RIC에 연결된 복수 개의 E2 노드들 각각의 정보에 기반하여, 상기 적어도 하나의 E2 노드를 확인하는 동작은, 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 포함되는 서비스 모델(service model)과 동일한 서비스 모델을 가지는 상기 적어도 하나의 E2 노드를 확인하는 RIC의 동작 방법.
제 9 항에 있어서,
상기 적어도 하나의 E2 노드 각각의 메시지 처리 주기 및/또는 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기를 확인하는 동작은, 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 포함되는 메시지의 템플릿의 크기에 기반하여, 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기를 확인하는 RIC의 동작 방법.
제 9 항에 있어서,
상기 적어도 하나의 E2 노드 각각의 메시지 처리 주기 및/또는 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기를 확인하는 동작은, 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 포함되는 메시지의 처리 주기에 기반하여, 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 처리 주기를 확인하는 RIC의 동작 방법.
제 1 항에 있어서,
상기 복수 개의 노드들 중 적어도 일부 각각의 메시지 처리 주기 및/또는 처리하는 메시지의 크기를, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보로서 확인하는 동작
을 더 포함하는 RIC의 동작 방법.
제 1 항에 있어서,
상기 Pod에 포함되는 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 기반하여, 상기 제 1 xAPP에 대응하는 E2 노드의 개수가 하나로 확인됨에 기반하여, 상기 하나의 E2 노드에 연결된 노드에 상기 제 1 xAPP을 디플로이하는 동작
을 더 포함하는 RIC의 동작 방법.
제 1 항에 있어서,
상기 복수 개의 노드들 중 적어도 일부 각각에 대응하는 통신 비용을, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보로서 확인하는 동작
을 더 포함하는 RIC의 동작 방법.
제 17 항에 있어서,
상기 복수 개의 노드들 중 적어도 일부 각각에 대응하는 통신 비용을, 상기 복수 개의 노드들 중 적어도 일부 각각이 처리하는 메시지와 연관된 정보로서 확인하는 동작은,
상기 제 1 xAPP이 구독을 요구하는 적어도 하나의 E2 노드를 확인하는 동작;
상기 적어도 하나의 E2 노드 각각의 메시지 처리 주기 및/또는 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기를 확인하는 동작;
상기 적어도 하나의 E2 노드 각각의 메시지 처리 주기 및/또는 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지의 크기에 기반하여, 상기 적어도 하나의 E2 노드 각각의 단위 시간당 처리하는 메시지의 크기를 확인하는 동작;
상기 적어도 하나의 E2 노드 각각에 연결되는 노드에 대한 정보에 기반하여, 상기 복수 개의 노드들 중 적어도 일부 각각이 단위 시간당 처리하는 메시지의 크기를 확인하는 동작, 및
상기 복수 개의 노드들 중 적어도 일부 각각이 단위 시간당 처리하는 메시지의 크기 및 상기 복수 개의 노드들 중 적어도 일부 사이의 통신 비용과 연관된 파라미터에 기반하여, 상기 복수 개의 노드들 중 적어도 일부 각각에 대응하는 통신 비용을 확인하는 동작
을 포함하는 RIC의 동작 방법.
RIC(radio access network intelligent controller)의 동작 방법에 있어서,
제 1 xAPP의 Pod에 대한 디플로이 요청을 확인하는 동작;
상기 요청에 기반하여, 상기 Pod에 포함되는 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 기반하여, 상기 제 1 xAPP이 구독을 요구하는 E2 노드를 확인하는 동작, 및
상기 확인된 E2 노드에 연결된 상기 제 1 xAPP을 디플로이하는 동작
을 포함하는 RIC의 동작 방법.
제 18 항에 있어서,
상기 Pod에 포함되는 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 기반하여, 상기 제 1 xAPP이 구독을 요구하는 E2 노드를 확인하는 동작은, 상기 제 1 xAPP의 E2 노드에 대한 구독과 연관되는 정보에 포함되는 서비스 모델(service model)과 동일한 서비스 모델을 가지는 상기 E2 노드를 확인하는 RIC의 동작 방법.
데이터 처리 시스템에 의하여 억세스되는 xApp의 Pod를 저장하는 저장 매체에 있어서,
상기 Pod는 제 1 데이터 및 제 2 데이터를 포함하고,
상기 제 1 데이터는, 상기 xAPP이 구독을 요구하는 적어도 하나의 E2 노드의 확인에 이용되는 제 1 서브 데이터, 상기 적어도 하나의 E2 노드 각각의 메시지 처리의 주기의 확인에 이용되는 제 2 서브 데이터, 상기 적어도 하나의 E2 노드 각각이 처리하는 메시지 처리의 크기의 확인에 이용되는 제 3 서브 데이터, 또는 상기 적어도 하나의 E2 노드로부터의 E2 메시지가 UE와 연관된 정보를 포함하는 지 여부를 확인하는데 이용되는 제 4 서브 데이터 중 적어도 하나를 포함하고,
상기 제 2 데이터는, 상기 xAPP의 적어도 하나의 동작을 위한 정보를 포함하는 저장 매체.