KR20210127564A

KR20210127564A - 이동 통신 네트워크에서 동적이고 효율적인 로드 밸런싱을 위한 방법 및 장치

Info

Publication number: KR20210127564A
Application number: KR1020200045594A
Authority: KR
Inventors: 김태우; 아쉬쉬 빌로르; 박종한
Original assignee: 삼성전자주식회사
Priority date: 2020-04-14
Filing date: 2020-04-14
Publication date: 2021-10-22
Also published as: CN115918044A; US20230033272A1; WO2021210801A1; EP4120641A4; EP4120641A1

Abstract

본 개시는 4G 시스템 이후 보다 높은 데이터 전송률을 지원하기 위한 5G 통신 시스템을 IoT 기술과 융합하는 통신 기법 및 그 시스템에 관한 것이다. 본 개시는 5G 통신 기술 및 IoT 관련 기술을 기반으로 지능형 서비스 (예를 들어, 스마트 홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 헬스 케어, 디지털 교육, 소매업, 보안 및 안전 관련 서비스 등)에 적용될 수 있다. 본 개시는 동적이고 효율적인 로드 밸런싱 방법 및 장치를 개시한다.

Description

이동 통신 네트워크에서 동적이고 효율적인 로드 밸런싱을 위한 방법 및 장치{METHOD AND APPARATUS FOR DYNAMIC AND EFFICIENT LOAD BALANCING IN MOBILE COMMUNICATION NETWORK}

본 개시는 이동 통신 시스템에 대한 것으로, 구체적으로는 이동 통신 시스템에서 로드 밸런싱(load balancing)을 위한 방법과 장치에 관한 것이다. 특히, 동적이고 효율적인 로드 밸런싱을 위한 방법 및 장치에 관한 것이다.

4G 통신 시스템 상용화 이후 증가 추세에 있는 무선 데이터 트래픽 수요를 충족시키기 위해, 개선된 5G 통신 시스템 또는 pre-5G 통신 시스템을 개발하기 위한 노력이 이루어지고 있다. 이러한 이유로, 5G 통신 시스템 또는 pre-5G 통신 시스템은 4G 네트워크 이후 (Beyond 4G Network) 통신 시스템 또는 LTE 이후 (Post LTE) 시스템이라 불리어지고 있다. 이러한 5G 통신 시스템을 NR (New Radio) 시스템이라 일컫는다.

높은 데이터 전송률을 달성하기 위해, 5G 통신 시스템은 초고주파(mmWave) 대역 (예를 들어, 60기가(60GHz) 대역과 같은)에서의 구현이 고려되고 있다. 초고주파 대역에서의 전파의 경로손실 완화 및 전파의 전달 거리를 증가시키기 위해, 5G 통신 시스템에서는 빔포밍(beamforming), 거대 배열 다중 입출력(massive MIMO), 전차원 다중입출력(Full Dimensional MIMO: FD-MIMO), 어레이 안테나(array antenna), 아날로그 빔형성(analog beam-forming), 및 대규모 안테나 (large scale antenna) 기술들이 논의되고 있다.

또한 시스템의 네트워크 개선을 위해, 5G 통신 시스템에서는 진화된 소형 셀, 개선된 소형 셀 (advanced small cell), 클라우드 무선 액세스 네트워크 (cloud radio access network: cloud RAN), 초고밀도 네트워크 (ultra-dense network), 기기 간 통신 (Device to Device communication: D2D), 무선 백홀 (wireless backhaul), 이동 네트워크 (moving network), 협력 통신 (cooperative communication), CoMP (Coordinated Multi-Points), 및 수신 간섭제거 (interference cancellation) 등의 기술 개발이 이루어지고 있다.

이 밖에도, 5G 시스템에서는 진보된 코딩 변조(Advanced Coding Modulation: ACM) 방식인 FQAM (Hybrid FSK and QAM Modulation) 및 SWSC (Sliding Window Superposition Coding)과, 진보된 접속 기술인 FBMC(Filter Bank Multi Carrier), NOMA(non orthogonal multiple access), 및 SCMA(sparse code multiple access) 등이 개발되고 있다.

한편, 인터넷은 인간이 정보를 생성하고 소비하는 인간 중심의 연결 망에서, 사물 등 분산된 구성 요소들 간에 정보를 주고 받아 처리하는 IoT(Internet of Things, 사물인터넷) 망으로 진화하고 있다. 클라우드 서버 등과의 연결을 통한 빅데이터(Big data) 처리 기술 등이 IoT 기술에 결합된 IoE (Internet of Everything) 기술도 대두되고 있다. IoT를 구현하기 위해서, 센싱 기술, 유무선 통신 및 네트워크 인프라, 서비스 인터페이스 기술, 및 보안 기술과 같은 기술 요소 들이 요구되어, 최근에는 사물간의 연결을 위한 센서 네트워크(sensor network), 사물 통신(Machine to Machine, M2M), MTC(Machine Type Communication)등의 기술이 연구되고 있다. IoT 환경에서는 연결된 사물들에서 생성된 데이터를 수집, 분석하여 인간의 삶에 새로운 가치를 창출하는 지능형 IT(Internet Technology) 서비스가 제공될 수 있다. IoT는 기존의 IT(information technology)기술과 다양한 산업 간의 융합 및 복합을 통하여 스마트홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 스마트 그리드, 헬스 케어, 스마트 가전, 첨단의료서비스 등의 분야에 응용될 수 있다.

이에, 5G 통신 시스템을 IoT 망에 적용하기 위한 다양한 시도들이 이루어지고 있다. 예를 들어, 센서 네트워크(sensor network), 사물 통신(Machine to Machine, M2M), MTC(Machine Type Communication)등의 기술이 5G 통신 기술이 빔 포밍, MIMO, 및 어레이 안테나 등의 기법에 의해 구현되고 있는 것이다. 앞서 설명한 빅데이터 처리 기술로써 클라우드 무선 액세스 네트워크(cloud RAN)가 적용되는 것도 5G 기술과 IoT 기술 융합의 일 예라고 할 수 있을 것이다.

한편, 이러한 5G 통신 시스템을 지원하기 위해 코어(core) 망 또한 개선되었으며, 5G 통신 시스템을 지원하는 코어망은 5GC(5G core)라 불린다. 이와 같이 개선된 코어망을 구성하는 다양한 네트워크 엔티티들의 부하를 조절하기 위한 로드 밸런싱에 대한 개선이 요구되는 상황이다.

본 개시는 상술한 문제점을 해결하기 위해 도출된 것으로, 본 개시는 네트워크 리소스를 충분히 확보할 수 없는 상황에서도 효율적으로 로드 밸런싱을 수행하기 위한 방안을 제안하는 것이다.

또한, 본 개시는 다양한 요청들을 효율적으로 처리하기 위한 로드 밸런싱 방안을 제안함으로써, 데이터 트래픽에 최적화된 로드 밸런싱을 동적으로 수행하기 위한 방안을 제안하는 것이다.

상술한 기술적 과제를 해결하기 위한 일 실시 예에 따른 로드 밸런싱 방법은, 네트워크 엔티티와 관련된 서비스 요청을 수신하는 단계; 상기 서비스 요청과 관련된 정책(policy)에 기초하여, 로드 밸런싱을 수행할 엔진을 선택하는 단계; 상기 선택된 엔진을 포함하는 로드 밸런싱 인스턴스를 생성하는 단계; 및 상기 로드 밸런싱 인스턴스를 통해, 상기 서비스 요청과 관련된 데이터 패킷에 대해서 로드 밸런싱을 수행하는 단계를 포함한다.

상술한 기술적 과제를 해결하기 위한 일 실시 예에 따른 로드 밸런서는, 적어도 하나의 엔진; 기설정된 정책에 따라 상기 적어도 하나의 엔진을 선택하는 오케스트레이터; 및 상기 적어도 하나의 엔진 및 상기 오케스트레이터와 연결되어 상기 로드 밸런서를 제어하는 컨트롤러를 포함하고, 상기 컨트롤러는 네트워크 엔티티와 관련된 서비스 요청을 수신하고, 상기 오케스트레이터는 상기 서비스 요청과 관련된 정책에 기초하여, 로드 밸런싱을 수행할 엔진을 선택하고, 상기 컨트롤러는 상기 선택된 엔진을 포함하는 로드 밸런싱 인스턴스를 생성하고, 상기 선택된 엔진은 상기 로드 밸런싱 인스턴스를 통해 상기 서비스 요청과 관련된 데이터 패킷에 대해서 로드 밸런싱을 수행한다.

본 개시에서 제안된 실시 예들에 따르면, 요청을 분류하고 그에 따라 로드 밸런싱이 수행됨으로써, 요청에 따라 최적화된 서비스 제공이 가능하다. 또한, 로드 밸런서(또는, 로드 밸런싱 인스턴스)를 통해 요청에 따라 최적화된 결과를 제공할 수 있으므로, 로드 밸런싱을 위한 네트워크 리소스가 효율적으로 절약될 수 있다.

도 1은 본 개시의 실시 예와 관련된 코어 망 구조 및 네트워크 엔티티들을 도시하는 도면이다.
도 2는 본 개시의 실시 예와 관련된 네트워크 엘리먼트의 로드 밸런싱 과정을 설명하는 도면이다.
도 3은 본 개시의 일 실시 예에 따른 로드 밸런싱 과정을 설명하는 도면이다.
도 4는 본 개시의 일 실시 예에 따른 로드 밸런싱 과정과 로드 밸런서의 구조를 설명하는 도면이다.
도 5는 본 개시의 일 실시 예에 따른 로드 밸런싱 과정을 설명하는 흐름도이다.
도 6은 본 개시의 일 실시 예에 따른 로드 밸런싱 과정과 로드 밸런서의 구조를 설명하는 도면이다.
도 7은 본 개시의 일 실시 예에 따른 로드 밸런싱 과정을 설명하는 흐름도이다.
도 8은 본 개시의 일 실시 예에 따른 코어 망 구조와 네트워크 엔티티들을 도시하는 도면이다.

이하, 첨부된 도면을 참조하여 본 개시의 바람직한 실시 예들을 상세히 설명한다. 이 때, 첨부된 도면에서 동일한 구성 요소는 가능한 동일한 부호로 나타내고 있음에 유의해야 한다. 또한 본 개시의 요지를 흐리게 할 수 있는 공지 기능 및 구성에 대한 상세한 설명은 생략할 것이다.

본 명세서에서 실시 예를 설명함에 있어서 본 개시가 속하는 기술 분야에 익히 알려져 있고 본 개시와 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다. 이는 불필요한 설명을 생략함으로써 본 개시의 요지를 흐리지 않고 더욱 명확히 전달하기 위함이다.

마찬가지 이유로 첨부 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성요소에는 동일한 참조 번호를 부여하였다.

본 개시의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 개시는 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 개시의 개시가 완전하도록 하고, 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 개시의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 개시는 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.

이 때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능하다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능하다.

또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능하다.

이 때, 본 실시 예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA또는 ASIC과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행한다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다.

한편, 이하에서 단말(terminal 또는 UE(user equipment))은 이동 통신 서비스를 제공 받는 사용자의 휴대폰이나 스마트폰, 랩탑 등 휴대 단말이나 고정식 단말을 모두 포함할 수 있다. 기지국(base station, BS)은 사용자 단말에 무선 채널을 통해 서비스를 제공하는 주체로서, eNB(evolved node B), gNB(next generation node B), TP(transmission point), TRP(transmission and reception point), RAN(radio access network) 노드 등을 포함할 수 있다.

본 개시의 실시 예들을 구체적으로 설명함에 있어서, 이동통신 규격 표준화 단체인 3GPP(3^rd generation partnership project) 및 ESTI(European Telecommunication Standards Institute)가 명세하고 있는 이동 통신 규격 상의 코어 망인 패킷 코어(또는, 5G System, 또는 5G Core Network, 또는 NG Core(Next Generation Core))를 주된 대상으로 하지만, 본 개시의 주요한 요지는 유사한 기술적 배경을 가지는 여타의 통신 시스템에도 본 개시의 범위를 크게 벗어 나지 아니 하는 범위에서 약간의 변형으로 적용될 수 있다. 이러한 적용은 본 개시의 기술 분야에서 숙련된 기술적 지식을 가진 자의 판단으로 가능 할 것이다.

이하 설명의 편의를 위하여, 3GPP 규격 및 ETSI 규격에서 정의하고 있는 용어 및 명칭들이 일부 사용될 수 있다. 하지만, 본 개시가 상기 용어 및 명칭들에 의해 한정되는 것은 아니며, 다른 규격에 따르는 시스템에도 동일하게 적용될 수 있다.

또한 이하 설명에서 사용되는 코어 망의 객체들을 지칭하는 용어, 메시지들을 지칭하는 용어, 네트워크 엔티티들 간 인터페이스를 지칭하는 용어, 다양한 식별 정보들을 지칭하는 용어 등은 설명의 편의를 위해 예시된 것이다. 따라서, 본 개시에서 사용하는 용어들에 한정되는 것은 아니며, 동등한 기술적 의미를 가지는 대상을 지칭하는 다른 용어가 사용될 수 있다. 예를 들어, 네트워크 엔티티(network entity)는 네트워크 엘리먼트(network element), 네트워크 기능(network function), 네트워크 인스턴스(network instance), 네트워크 노드(network node) 등 다양한 용어들과 동일한 기술적 의미를 가질 수 있을 것이다.

도 1은 본 개시의 실시 예와 관련된 코어 망 구조 및 네트워크 엔티티들을 도시하는 도면이다.

5G 시스템이 제공하는 각 기능들을 수행하는 단위는 네트워크 엔티티, NE(네트워크 엘리먼트, network element) 또는 NF(네트워크 기능, network function)로 정의될 수 있다. 이러한 5G 이동통신 시스템의 코어 망 구조 및 이를 구성하는 네트워크 엔티티들이 도 1에 도시되어 있다.

대표적인 네트워크 엔티티로는, 단말의 네트워크 접근과 이동성을 관리 하는 AMF(Access and Mobility Management Function), 세션과 관련된 기능을 수행하는 SMF(Session Management Function), 사용자 평면(user plane) 데이터의 전달을 담당하는 UPF(User Plane Function), 서비스 요구사항을 고려하여 사용자 평면 라우팅 상태 제어를 보조하는 AF (Application Function), 코어 망 엔티티의 기능을 외부로 노출하기 위한 기능을 수행하는 NEF (Network Exposure Function), 데이터 저장 및 관리를 위한 UDM (Unified Data Management)과 UDR (Unified Data Repository), 과금 및 정책을 관리 하는 PCF (Policy and Control Function), 단말의 PDU(Packet Data Network) 세션 요청에 대해서 NSSAI (Network Slice Selection Assistance Information)를 이용하여 특정 네트워크 슬라이스를 선택하는 NSSF (Network Slice Selection Function), 다양한 종류의 서비스들에 대한 가입자들의 단일화된 인증을 제공하는 AUSF (Authentication Server Function), 코어 망 NF들의 서비스 상태를 모니터링하고 NF 간의 상호 연동을 지원하는 NRF (Network Repository Function), 그리고 오퍼레이터 또는 서드파티(third party)의 서비스를 단말에 제공하기 위한 서비스 네트워크인 DN(Data Network)이 있다.

도 1에 도시된 각각의 네트워크 엔티티들은 서로 간에 정의된 인터페이스를 통해 연결되며, 예를 들어 AMF와 SMF 간의 인터페이스는 N11, SMF와 UPF 간의 인터페이스는 N4, UPF와 DN 간의 인터페이스는 N6, AMF와 RAN 간의 인터페이스는 N2, RAN과 UPF 간의 인터페이스는 N3 등으로 정의될 수 있다.

또한, 특정 네트워크 엔티티들에 대해서는 서비스 기반의 인터페이스(service based interface, SBI)가 정의되며, 예를 들어 NSSF의 인터페이스는 Nnssf, AMF의 인터페이스는 Namf, SMF의 인터페이스는 Nsmf, PCF의 인터페이스는 Npcf 등으로 정의될 수 있다.

도 1에서 설명한 코어 망 구조는 일 예시에 불과하며, 코어 망에는 이동 통신 서비스를 제공하기 위한 더 많은 수의 다른 네트워크 엔티티가 포함될 수 있다. 뿐만 아니라, 상술한 네트워크 엔티티와 인터페이스의 명칭 또한 일 예시에 불과하며, 네트워크 엔티티의 이름과 기능, 인터페이스의 명칭은 얼마든지 다른 것으로 명명될 수 있다. 즉, 이하에서 설명될 본 개시의 내용은 도 1에 도시된 네트워크 엔티티와 인터페이스에 대한 정의와 설명으로 제한 해석되지 않아야 할 것이다.

한편, 최근 SDN(Software Defined Network)와 NFV(Network Function Virtualization)에 대한 다양한 연구 개발이 이루어지고 있다. 이에, SDN과 NFV에 대해 설명한다.

먼저, SDN이란 네트워크 엔티티의 제어 기능을 담당하는 부분과 송수신 기능을 담당하는 부분을 분리하는 개념이다. 즉, 네트워크 엔티티는 송수신 기능만을 담당하도록 하고, 제어 기능을 별도의 범용 서버에 이전시키는 것을 의미한다. 이러한 분리를 통해서 제어 기능을 담당하는 별도의 서버가 여러 개의 네트워크 장치를 효율적으로 제어할 수 있게 된다.

이와 별도로, NFV란 네트워크 엔티티를 가상화하는 것을 의미한다. 구체적으로, NFV란 물리적 네트워크 엔티티의 리소스를 논리적으로 나눔으로써 여러 사용자 또는 장치와 나누어 사용할 수 있도록 하는 것을 의미한다. 이와 같이 NFV를 통해 네트워크 엔티티의 리소스를 여러 가상 머신(virtual machine, VM)들이 공유함으로써 리소스 사용 효율이 증대될 수 있으며, 소프트웨어/하드웨어의 분리를 통해 네트워크 구축 비용이 절감될 수 있고, 물리적 네트워크 엔티티에 비하여 유연한 설치가 가능하다.

이와 같이 물리적 네트워크 리소스를 가상화함으로써, 물리 네트워크 설정이 변경되더라도 가상 네트워크 설정을 동일하게 유지하여 VM VNF(virtualized network function)에 영향을 미치지 않는 것 또한 가능하다. 이때 물리 네트워크를 언더레이(underlay), 가상 네트워크를 오버레이(overlay)라고 부를 수 있다.

앞서 설명한 내용에 더하여, 최근 텔코(telco, telecommunication company) 망을 클라우드 화하는 것에 대한 연구 개발이 이루어지고 있다. 클라우드는 앞서 설명한 가상 머신이나 NFV 보다 훨씬 유연한 컨테이너(container)를 사용할 수 있다는 장점이 있으며, 이에 텔코 향 VNF를 컨테이너화(containerization)하여 텔코 클라우드 망을 구축함으로써, 네트워크 엔티티를 유연하게 운영하고 확장하는 것에 대한 연구가 이루어지고 있다.

이러한 텔코 클라우드 망은 기존의 사업자 플랫폼(platform)이 제공하던 기술, 제품, 솔루션 등을 클라우드 기반으로 구현한 것을 의미한다. 텔코 클라우드 망에 있어서, 성능을 판단하기 위한 주요 지표로써 신뢰성(reliability), 가용성(availability), QoS(Quality of service), 서비스 연속성(continuity) 등을 들 수 있다.

도 2는 본 개시의 실시 예와 관련된 네트워크 엘리먼트의 로드 밸런싱 과정을 설명하는 도면이다.

이하에서 설명할 네트워크 엘리먼트는, 앞서 정의한 바와 같이 네트워크 엔티티, 네트워크 기능, 네트워크 인스턴스, 네트워크 노드와 같은 의미를 가질 수 있다.

코어 망을 구성하는 네트워크 엘리먼트는 소정의 인터페이스를 통해 다른 네트워크 엘리먼트와 통신하며 패킷을 주고받는다. 이러한 과정에서, 네트워크 엘리먼트가 수신한 패킷 또는 요청을 처리하기 위해서는 부하(load) 상태를 고려해야 하며, 이와 같이 네트워크 엘리먼트(또는, 네트워크 엔티티) 간에 부하 상태를 고려하여 소정의 기준에 따라 패킷이나 요청을 처리하기 위한 부담을 나누거나 분배 하는 것을 로드 밸런싱이라 할 수 있다.

한편, 종래의 로드 밸런싱은 네트워크 엘리먼트의 외부에 존재하는 별도 서버에 의해 수행되는데, 이러한 로드 밸런싱 방식은 앞서 설명한 컨테이너화된 코어 망을 위한 요구사항(requirements)을 충족하지 못한다. 예를 들어, 종래의 로드 밸런싱은 L4 프로토콜 또는 L7 프로토콜이 적용되는 클라우드 망이나 웹 스케일(web scale)의 사용 사례(use case)에 적합한 방식이다. 따라서, 종래 방식의 로드 밸런싱 방식에 따르면, 두 프로토콜을 모두 처리해야 하는 경우 각각을 위한 로드 밸런서가 순차적으로 연결되는 캐스케이딩(cascading) 형태로 구현될 수 밖에 없다.

그러나, 이러한 종래 방식에 따르면 아래와 같은 텔코 클라우드 망의 요구사항을 충족시킬 수 없게 된다.

첫째로, 단일(single) 로드 밸런서에 의해 다양한 프로토콜(예를 들어, SCTP(stream control transmission protocol), HTTP2.0(hypertext transfer protocol version 2) 등)의 처리를 지원하는 것이 요구된다. 특히, 다수의 프로토콜이나 계층을 지원하기 위해서 다중 레벨의(multi-level) 로드 밸런서를 구현하기에 네트워크 리소스가 충분하지 않은 엣지(edge) 시나리오나 파-엣지(far-edge) 시나리오에서는 종래 방식에 따른 로드 밸런싱 방식과 다른 새로운 방식이 요구된다.

둘째로, 로드 밸런싱 토폴로지(topology)를 동적으로 조절할 수 있는 기능이 요구된다. 즉, 네트워크 상에서 인-미들(in-middle), 엣지(edge), 패스스루(pass-through) 로드 밸런싱 등 다양한 토폴로지를 동적으로 제어나 변경하기 위해 종래의 로드 밸런싱 방식과는 다른 새로운 방식이 요구된다.

셋째로, 분류(classification) 또는 텔코 관련 속성(telco relevant attribute)에 최적화된 로드 밸런싱이 요구된다. 이러한 분류와 속성을 동적으로 반영하기 위해서, 종래와는 달리 커널 기반의 라우팅(kernel based routing) 또는 하드웨어 오프로딩(hardware offloading)을 활용하기 위한 로드 밸런싱 방식이 요구된다.

마지막으로, 요청에 따라 수신된 패킷을 처리하기 위해 로드 밸런싱 체인(chain)을 구성하는 경우, 차등적이고(differential) 우선화된(prioritized) 로드 밸런싱 경로의 구성이 요구된다. 즉, 수신된 패킷의 출발지(source), 목적지(destination), 음성이나 데이터인지 등을 나타내는 특성(nature) 등을 기반으로 로드 밸런싱 체인을 우선순위에 따라 효율적으로 구성하기 위한 새로운 방식이 요구된다.

도 3은 본 개시의 일 실시 예에 따른 로드 밸런싱 과정을 설명하는 도면이다.

이하의 실시 예에서는, 코어 망의 네트워크 엔티티들로 전달되는 요청을 지능적이고 동적으로 처리하는 로드 밸런싱 방식 및 이를 위한 로드 밸런서를 제안한다.

제안하는 로드 밸런싱 및 로드 밸런서는 클라이언트 요청에 따라 수신되는 패킷 플로우(flow)에 대해서, 데이터 패킷 분류(classification)와 개선된 플랫폼 인식(enhanced platform awareness, EPA)을 지원하면서도 성능적으로는 저지연(low-latency), 저공간(low-footprint), 자원 최적화가 가능한 방식이 될 수 있다.

이러한 로드 밸런싱 및 로드 밸런서는, 도 3에 도시된 바에 따라 네트워크 엘리먼트와의 관계가 정의된다. 제안하는 실시 예에 따른 로드 밸런서(300)는 특정 네트워크 엘리먼트(310)에 대응하도록 구현되며, 클라이언트로부터 네트워크 엘리먼트(310)로 전달되는 요청을 감지하고 이를 처리하기 위한 로드 밸런싱을 수행한다.

구체적으로, 일 실시 예에 따른 로드 밸런서(300)는 클라이언트로부터 네트워크 엘리먼트(310)가 제공하는 다양한 서비스(예를 들어, 도 3의 서비스 A, 서비스 B, 서비스 C 등)에 대한 요청을 수신하고, 네트워크 엘리먼트(310)가 해당 요청을 처리하기 위한 네트워크 리소스를 효율적으로 활용할 수 있도록 요청에 대한 로드 밸런싱을 수행한다.

특히, 앞서 설명했듯이 다양한 클라이언트로부터 서로 다른 계층의 프로토콜과 패킷 특성에 따른 요청들이 수신될 수 있기 때문에, 로드 밸런서(300)는 네트워크 엘리먼트(310)가 이러한 요청들을 효율적으로 처리할 수 있도록 지능적으로 로드 밸런싱을 수행해야 한다. 이를 위해, 로드 밸런서(300)는 네트워크 엘리먼트(310)가 최적화된 서비스를 제공할 수 있게끔 클라이언트의 요청을 분류(classification)해야 할 것이다.

또한, 이러한 로드 밸런서(300)는 네트워크 엘리먼트(310)에 대응하도록 구현될 수 있다. 즉, 도 2에서 설명한 종래 방식에 따르면 특정 네트워크 엘리먼트의 로드 밸런싱을 처리하는 별도의 서버가 존재하였으나, 제안하는 실시 예에 따른 로드 밸런서(300)는 네트워크 엘리먼트(310)에 대응되도록(또는, 종속되도록) 구현될 수 있다.

이러한 관계는 네트워크 엘리먼트(310)가 내부 또는 외부에 자체적으로 로드 밸런서(300)를 구비하는 것으로 이해될 수도 있으며, 네트워크 엘리먼트(310)는 자신과 대응하는 로드 밸런서(300)를 하나 또는 복수 개 구비할 수 있다. 예를 들어, 클라이언트로부터 수신되는 요청의 양이 상대적으로 많다면, 네트워크 엘리먼트(310)는 이를 처리하기 위한 로드 밸런서(300)를 복수 개 구비할 수도 있을 것이다.

도 4는 본 개시의 일 실시 예에 따른 로드 밸런싱 과정과 로드 밸런서의 구조를 설명하는 도면이다.

제안하는 일 실시 예에 따르면, 네트워크 엘리먼트(450)를 위한(또는, 대응하는) 로드 밸런서(400)는, 도 4에 도시된 구성 요소들을 포함할 수 있다. 예를 들어, 일 실시 예에 따른 로드 밸런서(400)는 컨트롤러(410), 엔진 그룹(420) 및 오케스트레이터(430)를 포함할 수 있으며, 기술분야에서 통상의 지식을 가진 자라면 도 4에 도시된 구조와 구성은 단순한 예시에 불과함을 쉽게 알 수 있을 것이다.

도 4에 도시된 로드 밸런서(400)의 각 구성요소들은 소프트웨어로 구현되는 논리적인 구성일 수 있으며, 예를 들어 서비스, 컨테이너, 또는 여타 다른 개념적인 구성으로써 구현될 수 있다. 또는, 이와 달리 구성요소 중 일부 또는 전부가 하드웨어로 구현될 수도 있다. 이하에서는 도 4에 도시된 각 구성요소들에 대해 구체적으로 설명한다.

먼저, 엔진 그룹(420)은 하나 이상의 엔진(도 4의 엔진 A, 엔진 B, 엔진 C 등)을 포함하며, 엔진 그룹(420)에 포함된 하나 이상의 엔진(또는 모듈)들은 패킷 플로우에 대한 실질적인 로드 밸런싱을 수행한다. 이를 위해, 엔진 그룹(420)은 하나 이상의 엔진(또는 모듈)들에 대한 백엔드(backend)의 목록, 현재 상태, 연결 추적, 특정 백엔드의 선택을 수행한다.

특히, 엔진 그룹(420)에 포함된 각각의 엔진들은 특정한 프로토콜에 대한 로드 밸런싱을 수행하며, 예를 들어 엔진 그룹(420)은 SCTP 프로토콜에 대한 패킷 플로우의 로드 밸런싱을 수행하는 ipvsadm 엔진(또는 모듈)을 포함할 수 있고, HTTP2.0 프로토콜에 대한 패킷 플로우의 로드 밸런싱을 수행하는 envoy 엔진(또는 모듈)이나 ngnix 엔진(또는 모듈)을 포함할 수 있다. 또한, 엔진 그룹(420)은 대용량 패킷을 오프로딩(off-loading)하여 처리하기 위한 하드웨어 가속기(hardware accelerator)로써 스마트 NIC(network interface card) 또는 FPGA(field programmable gate array)를 포함할 수 있다. 또한, 이러한 엔진 또는 모듈들은 L4 또는 L7 등의 다양한 계층의 프로토콜과 관련된 로드 밸런싱을 수행할 수 있다.

특정 프로토콜의 패킷 플로우에 대한 로드 밸런싱은 엔진 그룹(420)에 포함된 하나의 엔진(모듈)에 의해 처리될 수 있음은 물론이고, 해당 프로토콜을 지원하는 복수의 서로 다른 엔진(모듈)들에 의해서 처리될 수도 있다. 반대로, 복수의 서로 다른 프로토콜에 대한 패킷 플로우가 하나의 엔진(모듈)에 의해서 처리될 수도 있음은 물론이다.

한편, 엔진 그룹(420)에 포함되는 하나 이상의 엔진 또는 모듈은 서비스 또는 컨테이너와 같이 가상 리소스를 이용하여 구현될 수 있으며, 하나 이상의 엔진 또는 모듈은 이와는 달리 하드웨어적으로 엔진 그룹 내에 포함될 수 있다. 엔진 또는 모듈이 하드웨어적으로 구현된다는 것은 로드 밸런서(400)와 해당 엔진 또는 모듈이 물리적으로 연결됨을 의미할 수 있다.

다음으로, 오케스트레이터(430)는 로드 밸런싱과 관련된 정책(policy)와 설정(configuration)을 저장 및 관리한다. 즉, 오케스트레이터(430)는 로드 밸런서(400)가 사용할 수 있는 로드 밸런싱 방식과 엔진(또는 모듈)에 대한 정보를 보유하고, 네트워크 엘리먼트(450)와 상호작용함으로써, 네트워크 엘리먼트(450)가 제공하는 서비스(460)에 대한 클라이언트 요청(405)에 대해서 어떠한 로드 밸런싱 방식을 선택할지 동적으로 결정한다.

이러한 결정 과정은 오케스트레이터(430)에 입력된 정책과 기준에 따라 수행될 수 있으며, 예를 들어 오케스트레이터(430)는 요청에 해당하는 프로토콜의 종류, 패킷 플로우의 특성 등에 따라서, 해당 패킷 플로우의 SLA(service level agreement)와 QoS(quality of service)를 만족시킬 수 있는 로드 밸런싱 방식을 결정한다. 오케스트레이터(430)가 로드 밸런싱 방식을 결정하는 과정은 개략적으로 어플리케이션 레벨(즉, L7)의 로드 밸런싱을 수행할 것인지, 커널 레벨(즉, L4)의 로드 밸런싱을 수행할 것인지, 또는 하드웨어 레벨의 로드 밸런싱을 수행할 것인지 결정하는 과정으로 설명될 수 있다. 또한, 오케스트레이터(430)는 이러한 로드 밸런싱 방식을 결정하는 것에 더하여 로드 밸런싱을 수행하기 위한 특정 엔진을 선택할 수도 있다.

마지막으로, 컨트롤러(410)는 로드 밸런서(400)의 전반적인 동작을 제어한다. 예를 들어, 컨트롤러(410)는 클라이언트 요청(405)가 감지되면 로드 밸런서(400)의 인스턴스화(instantiate)를 개시하며, 오케스트레이터(430)에 의해 선택된 로드 밸런싱 방식과 엔진(또는 모듈)을 포함하는 로드 밸런싱 인스턴스를 생성한다. 또한, 컨트롤러(410)는 필요에 따라 로드 밸런싱 인스턴스에 변경이 필요하다면, 로드 밸런서(400)의 구성을 변경하거나 업데이트할 수도 있다.

이러한 컨트롤러(410)의 요청에 따라 로드 밸런서(400) 또는 로드 밸런싱 인스턴스가 구성되면, 로드 밸런서(400) 또는 로드 밸런싱 인스턴스는 네트워크 엘리먼트(450)가 패킷 플로우에 해당하는 서비스(예를 들어, 서비스 X 또는 서비스 Y 등)를 제공하기 위한 Pod(470)를 할당할 수 있다. 서비스 제공을 위한 Pod(470)는 복수 개 할당될 수 있으며, 로드 밸런서(400) 또는 로드 밸런싱 인스턴스는 네트워크 엘리먼트(450)가 패킷 플로우를 처리할 수 있도록 Pod(470)들을 할당할 수 있다.

한편, 앞서 설명했듯이 로드 밸런서(400) 또는 로드 밸런싱 인스턴스는 네트워크 엘리먼트(450)에 대응하도록 구현되는데, 이러한 로드 밸런서(400) 또는 로드 밸런싱 인스턴스의 토폴로지는 다양하게 구현될 수 있을 것이다. 예를 들어, 도 4에 도시된 바와 같이 로드 밸런서(400) 또는 로드 밸런싱 인스턴스는 네트워크 엘리먼트(400)의 외부에 위치하는 프로토콜 터미네이션(protocol termination) 토폴로지로써 구현될 수 있으며, 점선(480)으로 도시된 바와 같이 네트워크 엘리먼트(480)의 내부에 위치하는 패스스루(pass-through) 기반의 인-미들 프록시(in-middle proxy) 토폴로지로 구현될 수도 있으며, 쿠버네티스(kubernetes) 환경에서는 사이드카(sidecar) 토폴로지로 구현될 수도 있을 것이다.

상술한 다양한 토폴로지의 예시에 있어서, 로드 밸런서(400) 또는 로드 밸런싱 인스턴스는 네트워크 엘리먼트(450)와 연결(490)되어 시그널링을 주고받을 수 있으며, 이를 통해 패킷 플로우에 대한 로드 밸런싱이 원활하게 이루어질 수 있다.

도 5는 본 개시의 일 실시 예에 따른 로드 밸런싱 과정을 설명하는 흐름도이다. 도 5에 도시된 흐름도(flowchart)는 앞서 설명한 실시 예에 따른 로드 밸런서 또는 로드 밸런싱 인스턴스의 동작들을 시계열적인 흐름에 따라 도시한 것이다.

한편, 도 5에 도시된 흐름도는 제안하는 로드 밸런싱 과정의 일 예시에 불과하며, 이에 제한되지 않고 도시된 동작들의 흐름이 다른 순서에 따라 수행될 수 있음은 물론이다. 즉, 도 5에서 설명하는 실시 예와는 달리, 로드 밸런서 또는 로드 밸런싱 인스턴스의 구성요소들 간의 동작 중 일부가 동시에 수행되거나, 설명한 것과는 달리 특정 동작이 다른 동작보다 먼저(또는 나중에) 수행되게끔 구현되는 것 또한 가능함은 물론이다.

먼저, 로드 밸런서(또는, 로드 밸런싱 인스턴스)는 클라이언트 요청을 감지한다(510). 이러한 과정은 외부로부터 서비스에 대한 요청을 수신하는 것으로 이해될 수도 있을 것이다.

로드 밸런서(또는, 로드 밸런싱 인스턴스)는 요청이 감지되면, 로드 밸런서의 인스턴스화를 개시한다(520). 구체적으로, 앞서 설명한 로드 밸런서(또는, 로드 밸런싱 인스턴스)의 컨트롤러는 요청에 따라 로드 밸런싱을 수행할 필요가 있다고 판단하고, 로드 밸런싱 인스턴스를 구성하기 위한 동작을 개시(또는 시작)한다.

이어서, 로드 밸런서(또는, 로드 밸런싱 인스턴스)는 요청에 따라 감지된 패킷 플로우의 프로토콜에 따라 로드 밸런싱 인스턴스를 생성한다(530). 이 과정은, 로드 밸런서(또는, 로드 밸런싱 인스턴스)의 컨트롤러가 요청을 오케스트레이터에 전달하고, 오케스트레이터가 선택한 로드 밸런싱 방식과 엔진(또는 모듈)을 확인하여 로드 밸런싱을 수행할 엔진 그룹을 결정하는 과정으로 설명될 수도 있을 것이다.

로드 밸런서(또는, 로드 밸런싱 인스턴스)는 구성된 엔진 그룹의 엔진을 이용하여 로드 밸런싱을 수행한다(540). 즉, 로드 밸런서(또는, 로드 밸런싱 인스턴스)는 요청에 이어서 실제로 수신되는 패킷 플로우를 네트워크 엔티티가 처리할 수 있도록, 서비스를 제공하기 위한 Pod들을 선택하고 할당하는 과정을 수행할 수 있다.

로드 밸런서(또는, 로드 밸런싱 인스턴스)는 연속적으로 수신되는 패킷 플로우에 대해서 네트워크 엔티티가 동적이고 효율적으로 처리될 서비스를 제공할 수 있도록 Pod를 선택하고 구성함으로써, 네트워크 리소스를 할당하는 동작을 수행하게 된다.

한편, 로드 밸런서(또는, 로드 밸런싱 인스턴스)는 로드 밸런싱 과정에서 로드 밸런싱 인스턴스의 변경이 필요하다는 것을 감지할 수도 있다(550). 예를 들어, 특정 Pod가 다시 시작되거나 네트워크 리소스의 스케일 인(scale in), 스케일 아웃(scale out) 등을 통해 IP(internet protocol) 정보가 변경되는 경우, 로드 밸런서(또는, 로드 밸런싱 인스턴스)는 로드 밸런싱 인스턴스의 변경이 필요하다고 결정할 수 있다.

이러한 경우, 로드 밸런서(또는, 로드 밸런싱 인스턴스)의 컨트롤러는 로드 밸런서(또는, 로드 밸런싱 인스턴스)의 로드 밸런싱 방식을 변경하거나 엔진(또는 모듈)을 새롭게 구성함으로써, 변경된 사항에 최적화된 로드 밸런싱 인스턴스를 구축할 수 있다. 즉, 로드 밸런서(또는, 로드 밸런싱 인스턴스)는 로드 밸런싱 인스턴스를 업데이트할 수 있다(560).

이어서, 로드 밸런서(또는, 로드 밸런싱 인스턴스)는 더 이상의 로드 밸런싱이 필요하지 않다고 판단되면, 로드 밸런싱 인스턴스를 종료한다(570). 예를 들어, 명시적인 종료 입력이 있거나, 일정 시간 동안 패킷 플로우가 입력되지 않는 경우 등 소정의 조건이 만족되면, 로드 밸런서(또는, 로드 밸런싱 인스턴스)는 로드 밸런싱 인스턴스를 종료할 수 있을 것이다.

도 6은 본 개시의 일 실시 예에 따른 로드 밸런싱 과정과 로드 밸런서의 구조를 설명하는 도면이다. 도 6에서는 앞서 도 4 및 도 5에서 설명한 실시 예에 따라 로드 밸런싱 인스턴스가 구성되어 패킷 플로우에 대한 로드 밸런싱을 수행하는 과정을 설명한다.

컨트롤러(610)가 클라이언트 요청을 수신하고 오케스트레이터(630)에 의해서 엔진 그룹(620)으로부터 선택된 로드 밸런싱 방식과 엔진(또는 모듈)을 확인하면, 컨트롤러(610)는 이러한 엔진(예를 들어, 엔진 D)을 포함하는 로드 밸런싱 인스턴스(600)를 생성한다.

로드 밸런싱 인스턴스(600)는 수신되는 네트워크 엘리먼트(650)가 패킷 플로우(605)를 원활하게 처리할 수 있도록 로드 밸런싱을 수행하며, 로드 밸런싱 인스턴스(600)는 네트워크 엘리먼트(650)가 패킷 플로우(605)를 효율적으로 제공할 수 있도록 복수의 Pod들을 할당할 수 있다. 이를 통해, 네트워크 엘리먼트(650)는 서비스 Z를 제공하기 위한 복수의 Pod(예를 들어, Pod z1, Pod z2, Pod z3, Pod z4)를 구성하고, 이를 통해 패킷 플로우(605)를 처리할 수 있다.

도 7은 본 개시의 일 실시 예에 따른 로드 밸런싱 과정을 설명하는 흐름도이다. 도 7에서는 로드 밸런서(또는, 로드 밸런싱 인스턴스)가 다양한 요청이 수신됨에 따라 구체적으로 로드 밸런싱 인스턴스를 구성하는 예시에 대해 설명한다.

앞서 설명했듯이, 로드 밸런서(또는, 로드 밸런싱 인스턴스)의 오케스트레이터는 로드 밸런싱 방식을 결정하고 엔진을 선택하기 위한 기준, 정책 및 설정을 관리할 수 있다. 이러한 기준, 정책 및 설정은 사용자 또는 외부 시스템으로부터 오케스트레이터로 제공될 수 있으며, 오케스트레이터는 제공된 기준, 정책 및 설정에 따라 수신되는 요청을 어떠한 로드 밸런싱 방식으로 처리할지 선택할 수 있다.

이하에서는 이러한 기준, 정책, 설정의 예시에 대해 구체적으로 설명한다. 오케스트레이터가 관리하고 로드 밸런싱 인스턴스 생성에 활용되는 기준, 정책 및 설정은, 다음의 요소 중 적어도 하나 이상을 포함할 수 있다.

- 출발지(source)/목적지(destination) 쌍(pair): 이 요소는 어떠한 클라이언트로부터 어떠한 서비스에 대한 요청이 수신되었는지에 대한 파라미터로써, 요청을 처리하기 위한 최적의 로드 밸런싱 인스턴스와 그 토폴로지를 구성하기 위한 파라미터이다. 만약 백엔드 서비스에서 지원하지 않는 특정 프로토콜이 요구되거나, 신뢰할 수 없는 연결로부터 요청이 도달하여 즉각적인 응답이 필요한 경우, 이 파라미터에 기반하여 생성되는 로드 밸런싱 인스턴스는 종료 기반의 (termination based) 로드 밸런싱 인스턴스가 될 수 있을 것이다.

- 어플리케이션 프로토콜 지원여부: 이 요소는 수신되는 요청이 예를 들어 HTTP2, gRPC(google remote procedure call), SQL(structured query language)인 경우에 해당하는 파라미터이다. 이 파라미터에 맞는 요청이 수신되면, 컨트롤러와 오케스트레이터는 서비스 인식(service awareness)이 가능한 어플리케이션 프로토콜 지원을 제공하며, 이러한 지원이 가능한 백엔드들의 로드를 적절히 관리하기 위해서 초당 요청의 수, 큐(queue) 당 메시지 수 등 텔레메트리(telemetry)를 도출할 수도 있다. 일 실시 예에 따르면, 이러한 어플리케이션 프로토콜을 지원하기 위한 엔진으로는 예를 들어 envoy, nginix L7 proxy 등의 엔진이 선택될 수 있으며, 로드 밸런싱 인스턴스의 토폴로지는 사이드카 패턴이 효율적인 토폴로지가 될 수 있을 것이다.

- 지연 중요도가 높은(latency critical) 요청: 이 요소는 수신되는 요청과 관련한 데이터 트래픽의 유형이 음성 처리(voice processing)과 같이 중요도가 높고 지연에 민감함을 나타내는 파라미터이다. 컨트롤러와 오케스트레이터는 처리 지연을 최소화하기 위해서 하드웨어 가속을 지원하는 엔진 또는 모듈(예를 들어, dpdk, P4 programmable module)을 포함하는 로드 밸런싱 인스턴스가 구성될 수 있을 것이다.

- 커널 스택 지원여부: 이 요소는 linux 커널에서 지원되는 SCTP와 같은 일부 프로토콜을 안정적으로 처리하여 연결을 제공하기 위한 경우에 해당하는 파라미터이다. 이 파라미터에 맞는 요청이 수신되면, 컨트롤러 및 오케스트레이터는 ipvsadm 엔진(또는, 모듈)을 예로 들어 선택할 수 있으며, 일 실시 예에 따른 로드 밸런싱 인스턴스는 패스스루(pass through) 기반의 토폴로지로 구성되고 연결 추적(connection tracking)과 NAT(network address translation)을 수행하여 오버헤드를 줄일 수 있을 것이다.

상술한 요소와 파라미터들은 로드 밸런싱 인스턴스를 구성하기 위한 기준, 정책, 설정의 다양한 예시에 불과하며, 이에 제한되지 않고 그 외에도 다른 요소와 파라미터들이 다양하게 고려될 수 있음은 물론이다. 예를 들어, 컨트롤러와 오케스트레이터는 요구되는 성능, 요청과 관련된 프로토콜 타입, 요구사항, 데이터 패킷의 타입(음성, 데이터), 데이터 패킷의 티어(tier) 또는 중요도 중 하나 이상의 요소와 파라미터를 고려하여 로드 밸런싱 인스턴스와 그 토폴로지를 구성할 수 있다.

도 7에 도시된 예를 들면, 로드 밸런서(720)는 다양한 요청들(710)을 수신하고, 요청들을 분류(classification)하여 로드 밸런싱 인스턴스를 구성하고 로드 밸런싱 처리를 수행한다.

예를 들어, 요청에 따른 데이터 패킷이 SCTP 관련 트래픽이라면, SCTP 프로토콜 관련 트래픽을 처리하기 위한 엔진을 포함하고 L4 처리가 가능한 로드 밸런싱 인스턴스가 구성될 것이다. 또 다른 예를 들면, 요청에 따른 데이터 패킷이 SCTP 프로토콜과 관련이 없고 지연 중요도 또한 낮은 경우라면, HTTP 프로토콜 관련 트래픽을 처리하기 위한 엔진을 포함하고 L7 처리가 가능한 로드 밸런싱 인스턴스가 구성될 것이다. 또 다른 예를 들면, 요청에 따른 데이터 패킷이 SCTP과 관련이 없지만 지연 중요도가 높은 경우라면, 하드웨어 가속기로 동작할 수 있는 엔진을 포함하는 로드 밸런싱 인스턴스가 구성될 것이다.

이와 같이, 다양한 종류의 요청에 대해서 최적화된 로드 밸런싱을 수행하기 위해, 로드 밸런서(또는, 로드 밸런싱 인스턴스)는 요청을 분류하고 그에 해당하는 효율적인 로드 밸런싱 인스턴스를 구성할 수 있다.

도 8은 본 개시의 일 실시 예에 따른 코어 망 구조와 네트워크 엔티티들을 도시하는 도면이다.

도 8에서는 도 1의 코어 망 구조에 더하여, 상술한 실시 예에 따라 각 네트워크 엔티티들에 대응하는 따라 로드 밸런서(또는, 로드 밸런싱 인스턴스)가 구성된 상황을 도시한다. 도 8에 기재된 LB(Load Balancer)가 상술한 로드 밸런싱 인스턴스를 의미한다.

또한, 도 8에서는 각 네트워크 엔티티의 인터페이스 별로 로드 밸런서(또는, 로드 밸런싱 인스턴스)가 구성된 상황을 도시하였다. 그러나, 앞서 설명했듯이 로드 밸런서(또는, 로드 밸런싱 인스턴스)는 클라이언트의 요청에 따라 생성될 수 있기 때문에, 네트워크 엔티티에 대해서 특정 시점에는 로드 밸런서(또는, 로드 밸런싱 인스턴스)가 구성되지 않을 수 있으며, 또 다른 시점에는 하나의 로드 밸런서(또는, 로드 밸런싱 인스턴스)가 구성될 수도 있고, 또 다른 시점에는 복수의 로드 밸런서(또는, 로드 밸런싱 인스턴스)가 구성될 수도 있다.

또한, 도 8에서 특정 네트워크 엔티티에 대해서는 복수의 로드 밸런서(또는, 로드 밸런싱 인스턴스)가 구성된 것으로 도시하였으나, 이는 네트워크 엔티티가 인터페이스를 통해 다른 네트워크 엔티티와 연결된 상황을 쉽게 이해할 수 있도록 도시한 예시에 지나지 않는다. 따라서, 도 8에서 특정 네트워크 엔티티에 여러 LB들이 구성된 것으로 도시된다 하더라도, 실제로는 해당 LB들은 하나의 로드 밸런서(또는, 로드 밸런싱 인스턴스)를 의미할 수도 있다.

이러한 로드 밸런서(또는, 로드 밸런싱 인스턴스)는 각 네트워크 엔티티 또는 인터페이스의 특수성을 고려하도록 구성될 수도 있다. 즉, 로드 밸런서(또는, 로드 밸런싱 인스턴스)는 대응되는 네트워크 엔티티나 인터페이스를 고려하여 커스터마이즈될 수도 있을 것이다.

예를 들면, UPF의 경우 다른 네트워크 엔티티에 비해 많은 수의 패킷을 처리한다는 특징이 있다. 따라서, UPF에 대해서는 다른 네트워크 엔티티 대비 많은 수의 로드 밸런서(또는, 로드 밸런싱 인스턴스)가 구성될 수 있을 것이다.

또 다른 예를 들면, AMF와 RAN 사이의 N2 인터페이스(또는, NGAP(next generation application protocol))는 SCTP 프로토콜을 이용하여 통신하므로, AMF와 RAN 간의 패킷 플로우를 처리하기 위한 로드 밸런서(또는, 로드 밸런싱 인스턴스)는 ipvsadm 엔진을 포함하는 리눅스 커널 기반으로 구성될 수 있을 것이다. 또한, 이러한 N4 인터페이스의 경우 수신되는 데이터 패킷이 로드 밸런서(또는, 로드 밸런싱 인스턴스)를 거쳐가는 과정에서 SNAT(source NAT)을 수행하지 않아야 하는 특징이 있다. 따라서, 로드 밸런서(또는, 로드 밸런싱 인스턴스)는 이러한 특징을 반영하기 위한 로드 밸런싱 방식과 토폴로지로 커스터마이즈되어 구성될 수 있을 것이고, 커스터마이즈의 일 예로 라우팅(routing)을 위해 Pod가 생성되는 시점에서 Pod들의 디폴트 라우팅(default routing)을 로드 밸런싱 인스턴스로 설정하는 추가 동작이 수행될 수도 있다.

또 다른 예를 들면, SMF와 UPF 사이의 N4 인터페이스는 GTP-C(General Packet Radio Service tunneling protocol control) 프로토콜을 이용하여 통신하므로, envoy 또는 nginix 엔진(또는, 모듈)을 포함하는 로드 밸런싱 인스턴스가 구성될 수 있을 것이다. 또한, N4 인터페이스를 통해 UPF로부터 패킷을 수신하는 로드 밸런서(또는, 로드 밸런싱 인스턴스)에 대해서도, N2 인터페이스와 유사하게 데이터 패킷에 대한 SNAT이 수행되지 않아야 하므로, 상술한 커스터마이즈를 반영하여 로드 밸런서(또는, 로드 밸런싱 인스턴스)가 구성되고 동작할 수 있을 것이다.

또 다른 예를 들면, RAN과 UPF 간의 N3 인터페이스와 UPF와 DN 간의 N6 인터페이스는 GTP-U(GTP user) 프로토콜을 이용하여 통신하고 대역폭에 걸쳐서 다수의 패킷이 송수신되어 패킷 처리부담이 큰 편이다. 따라서, 로드 밸런서(또는, 로드 밸런싱 인스턴스)는 하드웨어 가속기를 포함하도록 구성될 수 있을 것이고, 예를 들어 스마트 NIC, FPGA NIC, NIC 가속이 구비된 GPU(graphics processing unit)를 포함하도록 구성될 수 있다.

또 다른 예를 들면, SBI(service based interface), 즉 Nnssf, Namf, Nausf, Nsmf, Nudm, Npcf, Nnef, Naf, Nnrf 등의 인터페이스는 HTTP2.0 프로토콜을 이용하여 통신하거나 gRPC 기반의 요청으로 통신하므로, envoy 엔진(또는, 모듈)을 통해 L7 기반의 로드 밸런싱을 제공하거나 또 다른 LBaaS(load balancing as a service) 솔루션을 제공하기 위한 로드 밸런싱 인스턴스가 구성될 수 있을 것이다.

앞서 도 1 내지 도 8에서 설명한 다양한 실시 예들에 따른 로드 밸런싱 방법 및 로드 밸런서(또는, 로드 밸런싱 인스턴스)에 의하면, 패킷 플로우와 그에 따른 데이터 패킷에 대해 최적화된 서비스를 제공할 수 있게 된다. 특히, 클라이언트의 요청의 특성을 포함한 다양한 파라미터에 기반하여 요청들을 분류한 결과에 따라 로드 밸런싱 인스턴스가 구성됨으로써, 요청의 요구사항과 성능이 만족될 뿐 아니라 네트워크 리소스 또한 효율적으로 사용될 수 있다.

또한, 기준, 정책, 설정에 따라 최적화된 엔진과 로드 밸런싱 방식, 토폴로지가 구성될 수 있으므로, 다수의 로드 밸런서를 순차적으로 배치하기 위한 리소스가 부족한 상황에서도 하나의 로드 밸런서(또는, 로드 밸런싱 인스턴스)만으로도 효율적인 로드 밸런싱이 수행될 수 있다.

뿐만 아니라, 제안하는 실시 예에 따른 로드 밸런서와 로드 밸런싱 방법에 따르면, 메타데이터나 서비스 경로를 위한 별도의 NSH(네트워크 서비스 헤더)가 필요치 않기 때문에, 네트워크 엔티티의 서비스 헤더 프로세싱 모듈을 구비할 필요가 없다. 따라서, 네트워크 환경이나 아키텍쳐에 제약되지 않고 어떠한 네트워크 엔티티에도 최적으로 적용될 수 있다는 장점이 있다.

나아가, 로드 밸런서들이 네트워크 망에 걸쳐서 완전히 분산되어 위치하기 때문에, 요청을 분류한 결과에 따라 특정 네트워크 엔티티가 불가피하게 선택되는 상황이 발생하지 않는다. 또한, 서비스 기능 체인(service function chain, SFC)와 유즈케이스(use-case)의 특별한 결합 없이, 일반적인 유즈케이스에도 적용될 수 있다.

이상에서 본 명세서와 도면에 개시된 실시 예들은 본 개시의 내용을 쉽게 설명하고, 이해를 돕기 위해 특정 예를 제시한 것일 뿐이며, 본 개시의 범위를 한정하고자 하는 것은 아니다. 따라서 본 개시의 범위는 여기에 개시된 실시 예들 이외에도 본 개시를 바탕으로 도출되는 모든 변경 또는 변형된 형태가 본 개시의 범위에 포함되는 것으로 해석되어야 한다.

또한, 이상에서 설명한 실시 예들 중 하나 이상이 서로 결합되어 수행될 수 있으며, 특정 실시 예들 중 일부 또는 전부가 다른 실시 예의 일부 또는 전부와 결합되어 수행될 수도 있음은 물론이다.

Claims

통신 시스템의 로드 밸런서(load balancer)에 의해 수행되는 로드 밸런싱 방법에 있어서,
네트워크 엔티티와 관련된 서비스 요청을 수신하는 단계;
상기 서비스 요청과 관련된 정책(policy)에 기초하여, 로드 밸런싱을 수행할 엔진을 선택하는 단계;
상기 선택된 엔진을 포함하는 로드 밸런싱 인스턴스를 생성하는 단계; 및
상기 로드 밸런싱 인스턴스를 통해, 상기 서비스 요청과 관련된 데이터 패킷에 대해서 로드 밸런싱을 수행하는 단계를 포함하는, 방법.
제1항에 있어서,
상기 방법은 상기 정책에 따라 상기 서비스 요청을 분류(classify)하는 단계를 더 포함하고,
상기 선택된 엔진은 상기 분류된 결과에 따라 복수의 엔진을 포함하는 엔진 그룹으로부터 선택되는 것인, 방법.
제2항에 있어서,
상기 엔진 그룹은 envoy 엔진, ipvsadm 엔진, ngnix 엔진, 스마트 NIC(network interface card), 및 FPGA(field programmable gate array) NIC 중 하나 이상을 포함하는 것인, 방법.
제1항에 있어서,
상기 정책은, 상기 서비스 요청과 관련된 출발지(source), 목적지(destination), 프로토콜의 종류, 지연 중요도, 요구 성능, 요구사항, 데이터 패킷의 타입, 데이터 패킷의 티어, 데이터 패킷의 중요도 및 상기 네트워크 엔티티 또는 네트워크 인터페이스의 특성 중 적어도 하나를 포함하는 것인, 방법.
제4항에 있어서,
상기 로드 밸런서는 복수의 서로 다른 프로토콜들을 지원하며,
상기 복수의 서로 다른 프로토콜들은 L4 프로토콜, L7 프로토콜, SCTP(stream control transmission protocol), HTTP2.0(hypertext transfer protocol version 2), GTP-C(General Packet Radio Service tunneling protocol control), GTP-U(GTP user), gRPC(google remote procedure call) 및 SQL(structured query language) 중 둘 이상을 포함하는 것인, 방법.
제1항에 있어서,
상기 방법은 상기 정책에 기초하여 상기 로드 밸런싱 인스턴스의 토폴로지를 선택하는 단계를 더 포함하고,
상기 로드 밸런싱 인스턴스는 상기 토폴로지에 따라 생성되는 것인, 방법.
제6항에 있어서,
상기 토폴로지는 인-미들(in-middle), 엣지(edge), 패스스루(pass-through), 사이드카(sidecar) 및 프로토콜 터미네이션(termination) 중 어느 하나를 포함하는 것인, 방법.
제1항에 있어서,
상기 선택된 엔진은 둘 이상의 엔진을 포함하는 엔진 체인(chain)으로 구성되며,
상기 엔진 체인의 로드밸런싱 경로는 상기 둘 이상의 엔진의 우선순위에 따라 결정되는 것인, 방법.
제1항에 있어서,
상기 방법은,
상기 로드 밸런싱 인스턴스에 대한 변경이 필요하다고 판단하는 단계; 및
상기 판단 결과에 따라 상기 로드 밸런싱 인스턴스를 업데이트하는 단계를 더 포함하는 것인, 방법.
제9항에 있어서,
상기 로드 밸런싱 인스턴스가 할당한 Pod가 다시 시작되거나, 네트워크 리소스의 스케일 인 또는 스케일 아웃이 감지되거나, 상기 네트워크 리소스의 IP(internet protocol) 정보가 변경되면, 상기 로드 밸런싱 인스턴스에 대한 변경이 필요하다고 판단되는 것인, 방법.
통신 시스템에서 로드 밸런싱을 수행하는 로드 밸런서에 있어서,
적어도 하나의 엔진;
기설정된 정책에 따라 상기 적어도 하나의 엔진을 선택하는 오케스트레이터; 및
상기 적어도 하나의 엔진 및 상기 오케스트레이터와 연결되어 상기 로드 밸런서를 제어하는 컨트롤러를 포함하고,
상기 컨트롤러는 네트워크 엔티티와 관련된 서비스 요청을 수신하고,
상기 오케스트레이터는 상기 서비스 요청과 관련된 정책에 기초하여, 로드 밸런싱을 수행할 엔진을 선택하고,
상기 컨트롤러는 상기 선택된 엔진을 포함하는 로드 밸런싱 인스턴스를 생성하고,
상기 선택된 엔진은 상기 로드 밸런싱 인스턴스를 통해 상기 서비스 요청과 관련된 데이터 패킷에 대해서 로드 밸런싱을 수행하는 것인, 로드 밸런서.
제11항에 있어서,
상기 오케스트레이터는 상기 정책에 따라 상기 서비스 요청을 분류(classify)하고,
상기 선택된 엔진은 상기 분류된 결과에 따라 복수의 엔진을 포함하는 엔진 그룹으로부터 선택되는 것인, 로드 밸런서.
제12항에 있어서,
상기 엔진 그룹은 envoy 엔진, ipvsadm 엔진, ngnix 엔진, 스마트 NIC(network interface card), 및 FPGA(field programmable gate array) NIC 중 하나 이상을 포함하는 것인, 로드 밸런서.
제11항에 있어서,
상기 정책은, 상기 서비스 요청과 관련된 출발지(source), 목적지(destination), 프로토콜의 종류, 지연 중요도, 요구 성능, 요구사항, 데이터 패킷의 타입, 데이터 패킷의 티어, 데이터 패킷의 중요도 및 상기 네트워크 엔티티 또는 네트워크 인터페이스의 특성 중 적어도 하나를 포함하는 것인, 로드 밸런서.
제14항에 있어서,
상기 로드 밸런서는 복수의 서로 다른 프로토콜들을 지원하며,
상기 복수의 서로 다른 프로토콜들은 L4 프로토콜, L7 프로토콜, SCTP(stream control transmission protocol), HTTP2.0(hypertext transfer protocol version 2), GTP-C(General Packet Radio Service tunneling protocol control), GTP-U(GTP user), gRPC(google remote procedure call) 및 SQL(structured query language) 중 둘 이상을 포함하는 것인, 로드 밸런서.
제11항에 있어서,
상기 오케스트레이터는 상기 정책에 기초하여 상기 로드 밸런싱 인스턴스의 토폴로지를 선택하고,
상기 로드 밸런싱 인스턴스는 상기 토폴로지에 따라 생성되는 것인, 로드 밸런서.
제16항에 있어서,
상기 토폴로지는 인-미들(in-middle), 엣지(edge), 패스스루(pass-through), 사이드카(sidecar) 및 프로토콜 터미네이션(termination) 중 어느 하나를 포함하는 것인, 로드 밸런서.
제11항에 있어서,
상기 선택된 엔진은 둘 이상의 엔진을 포함하는 엔진 체인(chain)으로 구성되며,
상기 엔진 체인의 로드밸런싱 경로는 상기 둘 이상의 엔진의 우선순위에 따라 결정되는 것인, 로드 밸런서.
제11항에 있어서,
상기 컨트롤러는, 상기 로드 밸런싱 인스턴스에 대한 변경이 필요하다고 판단하고, 상기 판단 결과에 따라 상기 로드 밸런싱 인스턴스를 업데이트하는 것인, 로드 밸런서.
제19항에 있어서,
상기 로드 밸런싱 인스턴스가 할당한 Pod가 다시 시작되거나, 네트워크 리소스의 스케일 인 또는 스케일 아웃이 감지되거나, 상기 네트워크 리소스의 IP(internet protocol) 정보가 변경되면, 상기 로드 밸런싱 인스턴스에 대한 변경이 필요하다고 판단되는 것인, 로드 밸런서.