KR20230157194A

KR20230157194A - 스위치를 이용하는 트래픽 처리를 위한 장치 및 방법

Info

Publication number: KR20230157194A
Application number: KR1020220056916A
Authority: KR
Inventors: 현도원; 박승훈
Original assignee: 삼성전자주식회사
Priority date: 2022-05-09
Filing date: 2022-05-09
Publication date: 2023-11-16
Also published as: WO2023219252A1

Abstract

본 개시의 실시예들에 따를 때, 통신 시스템에서, 프로그래밍 가능한 스위치(programable switch) 및 하나 이상의 FPGA(field programmable gate array)들을 포함하는 스위치 서버에 수행되는 방법은 오프로딩 서버로부터 플로우 테이블에 대한 정보를 수신하는 동작을 포함할 수 있다. 상기 방법은 데이터 패킷을 수신하는 동작을 포함할 수 있다. 상기 방법은 상기 데이터 패킷에 대응하는 FPGA를 식별하는 동작을 포함할 수 있다. 상기 방법은 상기 데이터 패킷이 상기 FPGA의 플로우 테이블(flow table)의 플로우 엔트리(flow entry)에 매칭되는지 여부를 식별하는 동작을 포함할 수 있다. 상기 방법은 상기 데이터 패킷이 상기 플로우 테이블의 플로우 엔트리(flow entry)에 매칭되는 경우, 상기 플로우 엔트리에 기반하여 상기 데이터 패킷을 처리하고, 상기 처리된 데이터 패킷을 전송하는 동작을 포함할 수 있다. 상기 방법은 상기 데이터 패킷이 상기 플로우 테이블의 엔트리에 매칭되지 않은 경우, 상기 데이터 패킷을 상기 오프로딩 서버에게 제공하는 동작을 포함할 수 있다.

Description

스위치를 이용하는 트래픽 처리를 위한 장치 및 방법{APPARATUS AND METHOD FOR TRAFFIC PROCESSING USING PROGRAMMABLE SWITCH}

본 개시(disclosure)는 트래픽 처리(traffic processing)에 관한 것이다. 보다 구체적으로, 본 개시는 스위치를 이용하는 트래픽 처리를 위한 장치 및 방법에 관한 것이다.

코어 네트워크의 구성하는 장비들은 패킷 처리를 위하여 대부분 CPU(central processing unit)를 사용한다. 네트워크 장비는 특정 패킷이 어떤 사용자의 패킷인지 확인하고, 해당 사용자의 위치에 맞는 장비로 전달 또는 해당 사용자의 정책 및 부가 기능에 맞춰 처리하기 때문이다. 네트워크 장비는 사용자의 컨텍스트 정보와 트래픽 플로우의 정보에 기반하여 패킷 처리를 수행할 수 있다. 최근에는 패킷 처리 성능을 높이기 위해 CPU에만 의존하는 것에서 탈피하여 NIC(Network Interface Card)과 같은 하드웨어에 패킷 처리 기능을 일부 오프로딩(offloading)하는 스마트 NIC가 제안되고 있다. 그러나, 모든 패킷 처리 기능들을 오프로딩하는 것은 거의 불가능하며 게다가 패킷 처리시 부가 기능이 요구될 경우는 더더욱 어렵다. 따라서 폭발적으로 증가하고 있는 대용량 트래픽을 처리하는데 있어, 추가적인 기술들이 요구된다.

본 개시(disclosure)는, 스위치 서버(switch-server)를 이용하여 트래픽을 처리하기 위한 장치 및 방법을 제공한다.

본 개시(disclosure)는, 스위치 서버와 COTS(Commercial off-the-shelf) 서버를 포함하는 UPF(user plane function)를 위한 장치 및 방법을 제공한다.

본 개시는, UPF의 스위치 서버를 제어하기 위한 장치 및 방법을 제공한다.

본 개시는, 프로그래밍이 가능한(programmable) 스위치(switch)와 FPGA(field programmable gate array)를 포함하는 스위치 서버를 위한 장치 및 방법을 제공한다.

본 개시의 실시예들에 따를 때, 통신 시스템에서, 오프로딩 서버에 수행되는 방법은, 프로그래밍 가능한 스위치(programable switch) 및 하나 이상의 FPGA(field programmable gate array)들을 포함하는 스위치 서버로부터 데이터 패킷을 수신하는 동작을 포함할 수 있다. 상기 방법은 상기 데이터 패킷을 처리하는 동작을 포함할 수 있다. 상기 방법은 상기 데이터 패킷에 대한 플로우 테이블(flow table)을 생성할 지 여부를 결정하는 동작을 포함할 수 있다. 상기 방법은 상기 데이터 패킷에 대한 상기 플로우 테이블을 생성하는 것으로 결정된 경우, 상기 플로우 테이블에 대한 정보 및 상기 처리된 패킷을 상기 스위치 서버에게 제공하는 동작을 포함할 수 있다. 상기 방법은 상기 데이터 패킷에 대한 상기 플로우 테이블을 생성하지 않는 것으로 결정된 경우, 상기 플로우 테이블에 대한 정보 없이 상기 처리된 패킷을 상기 스위치 서버에게 제공하는 동작을 포함할 수 있다.

본 개시의 실시예들에 따를 때, 통신 시스템에서, 스위치 서버는, 프로세서; 프로그래밍 가능한 스위치(programable switch); 및 하나 이상의 FPGA(field programmable gate array)들을 포함할 수 있다. 상기 프로그래밍 가능한 스위치는 오프로딩 서버로부터 플로우 테이블에 대한 정보를 수신하도록 구성될 수 있다. 상기 프로그래밍 가능한 스위치는 데이터 패킷을 수신하도록 구성될 수 있다. 상기 프로그래밍 가능한 스위치는 상기 데이터 패킷에 대응하는 FPGA를 식별하도록 구성될 수 있다. 상기 프로그래밍 가능한 스위치는 상기 데이터 패킷이 상기 FPGA의 플로우 테이블(flow table)의 플로우 엔트리(flow entry)에 매칭되는지 여부를 식별하도록 구성될 수 있다. 상기 프로그래밍 가능한 스위치는 상기 데이터 패킷이 상기 플로우 테이블의 플로우 엔트리(flow entry)에 매칭되는 경우, 상기 플로우 엔트리에 기반하여 상기 데이터 패킷을 처리하고, 상기 처리된 데이터 패킷을 전송하도록 구성될 수 있다. 상기 프로그래밍 가능한 스위치는 상기 데이터 패킷이 상기 플로우 테이블의 엔트리에 매칭되지 않은 경우, 상기 데이터 패킷을 상기 오프로딩 서버에게 제공하도록 구성될 수 있다.

본 개시의 실시예들에 따를 때, 통신 시스템에서, 오프로딩 서버는 적어도 하나의 송수신기; 및 적어도 하나의 프로세서를 포함할 수 있다. 상기 적어도 하나의 프로세서는, 프로그래밍 가능한 스위치(programable switch) 및 하나 이상의 FPGA(field programmable gate array)들을 포함하는 스위치 서버로부터 데이터 패킷을 수신하고, 상기 데이터 패킷을 처리하도록 구성될 수 있다. 상기 적어도 하나의 프로세서는, 상기 데이터 패킷에 대한 플로우 테이블(flow table)을 생성할 지 여부를 결정하도록 구성될 수 있다. 상기 적어도 하나의 프로세서는, 상기 데이터 패킷에 대한 상기 플로우 테이블을 생성하는 것으로 결정된 경우, 상기 플로우 테이블에 대한 정보 및 상기 처리된 패킷을 상기 스위치 서버에게 제공하도록 구성될 수 있다. 상기 적어도 하나의 프로세서는, 상기 데이터 패킷에 대한 상기 플로우 테이블을 생성하지 않는 것으로 결정된 경우, 상기 플로우 테이블에 대한 정보 없이 상기 처리된 패킷을 상기 스위치 서버에게 제공하도록 구성될 수 있다.

본 개시의 실시예들에 따른 UPF(user plane function)는 추가적인 스위치 서버(switch server)를 통해 패킷을 오프로딩(offloading)함으로써, 효율적인 네트워크 패킷 처리가 가능하게 한다.

본 개시에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

도 1a는 실시예들에 따른 무선 통신 시스템을 도시한다.
도 1b는 실시예들에 따른 UPF(user plane function)의 기능적 구성을 도시한다.
도 2는 실시예들에 따른 UPF의 스위치-칩(switch chip)의 구현 예를 도시한다.
도 3은 실시예들에 따른 스위치 서버(switch server)의 프로그래밍이 가능한 스위치(programmable switch)와 FPGA(field programmable gate array)의 예를 도시한다.
도 4는 실시예들에 따른 UPF의 적응적(adaptive) 트래픽 처리의 예를 도시한다.
도 5a는 실시예들에 따른 UPF의 트래픽 처리의 예를 도시한다.
도 5b는 실시예들에 따른 UPF의 사용자 평면(user plane)의 처리(processing) 및 제어 평면(control plane)의 처리의 예를 도시한다.
도 6은 실시예들에 따른 UPF의 초기화 동작의 예를 도시한다.
도 7a 및 도 7b는 실시예들에 따른 UPF의 상향링크 데이터 처리의 예를 도시한다.
도 8a 및 도 8b는 실시예들에 따른 UPF의 하향링크 데이터 처리의 예를 도시한다.
도 9는 실시예들에 따른 UPF의 시스템의 예를 도시한다.
도 10은 실시예들에 따른 UPF의 플로우 테이블 생성을 위한 시그널링의 예를 도시한다.
도 11은 실시예들에 따른 UPF의 신규 패킷 처리의 예를 도시한다.
도 12는 실시예들에 따른 UPF의 QER(QoS(quality of service) Enforcement Rule) 처리의 예를 도시한다.
도 13a 및 도 13b는 실시예들에 따른 UPF의 UDP(user datagram protocol) 처리의 예를 도시한다.
도 14는 실시예들에 따른 UPF의 TCP(Transmission Control Protocol) 처리의 예를 도시한다.

본 개시에서 사용되는 용어들은 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 다른 실시예의 범위를 한정하려는 의도가 아닐 수 있다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함할 수 있다. 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 용어들은 본 개시에 기재된 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가질 수 있다. 본 개시에 사용된 용어들 중 일반적인 사전에 정의된 용어들은, 관련 기술의 문맥상 가지는 의미와 동일 또는 유사한 의미로 해석될 수 있으며, 본 개시에서 명백하게 정의되지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다. 경우에 따라서, 본 개시에서 정의된 용어일지라도 본 개시의 실시예들을 배제하도록 해석될 수 없다.

이하에서 설명되는 본 개시의 다양한 실시예들에서는 하드웨어적인 접근 방법을 예시로서 설명한다. 하지만, 본 개시의 다양한 실시예들에서는 하드웨어와 소프트웨어를 모두 사용하는 기술을 포함하고 있으므로, 본 개시의 다양한 실시예들이 소프트웨어 기반의 접근 방법을 제외하는 것은 아니다.

이하 설명에서 사용되는 신호를 지칭하는 용어(예: 신호, 정보, 메시지, 시그널링), 자원을 지칭하는 용어(예: 심볼(symbol), 슬롯(slot), 서브프레임(subframe), 무선 프레임(radio frame), 서브캐리어(subcarrier), RE(resource element), RB(resource block), BWP(bandwidth part), 기회(occasion)), 연산 상태를 위한 용어(예: 단계(step), 동작(operation), 절차(procedure)), 데이터를 지칭하는 용어(예: 패킷, 사용자 스트림, 정보(information), 비트(bit), 심볼(symbol), 코드워드(codeword)), 채널을 지칭하는 용어, 네트워크 객체(network entity)들을 지칭하는 용어, 장치의 구성 요소를 지칭하는 용어 등은 설명의 편의를 위해 예시된 것이다. 따라서, 본 개시가 후술되는 용어들에 한정되는 것은 아니며, 동등한 기술적 의미를 가지는 다른 용어가 사용될 수 있다.

본 개시에서, 특정 조건의 만족(satisfied), 충족(fulfilled) 여부를 판단하기 위해, 초과 또는 미만의 표현이 사용될 수 있으나, 이는 일 예를 표현하기 위한 기재일 뿐 이상 또는 이하의 기재를 배제하는 것이 아니다. '이상'으로 기재된 조건은 '초과', '이하'로 기재된 조건은 '미만', '이상 및 미만'으로 기재된 조건은 '초과 및 이하'로 대체될 수 있다. 또한, 이하, 'A' 내지 'B'는 A부터(A 포함) B까지의(B 포함) 요소들 중 적어도 하나를 의미한다.

본 개시는, 일부 통신 규격(예: 3GPP(3rd Generation Partnership Project), xRAN(extensible radio access network), O-RAN(open-radio access network)에서 사용되는 용어들을 이용하여 다양한 실시예들을 설명하지만, 이는 설명을 위한 예시일 뿐이다. 본 개시의 다양한 실시예들은, 다른 통신 시스템에서도, 용이하게 변형되어 적용될 수 있다.

도 1a는 실시예들에 따른 무선 통신 시스템을 도시한다.

도 1을 참고하면, 5G 네트워크 무선 통신 시스템의 구조가 도시된다. 5G 네트워크 무 선 통신 시스템을 구성하는 네트워크 엔티티 또는 네트워크 노드들의 설명은 다음과 같다.

(R)AN((Radio) Access Network)는 단말의 무선 자원할당을 수행하는 주체로서, 이노드비(eNode B), 노드비 (Node B), 기지국(base station, BS), NG-RAN(next generation radio access network), 5G-AN(5G-access network), 무선 접속 유닛, 기지국 제어기, 또는 네트워크 상의 노드 중 적어도 하나일 수 있다. 단말은 사용자 장비(user equipment, UE), NG UE(next generation UE), 이동국(mobile station, MS), 셀룰러폰, 스마트폰, 컴퓨터, 또는 통신 기능을 수행할 수 있는 멀티미디어시스템을 포함할 수 있다. 또한, 본 개시의 실시예들을 위한 네트워크 시스템으로서, 5G 시스템이 예시되나, 유사한 기술적 배경을 갖는 여타의 통신 시스템에도 본 개시의 실시예들이 적용될 수 있다.

무선 통신 시스템이 4G 시스템에서 5G 시스템으로 진화를 하면서 새로운 코어 네트워크(core network)인 차세대 코어(next gen core, NG core) 혹은 5GC(5G core network)가 정의된다. 새로운 코어 네트워크(core network)는 기존의 네트워크 엔티티(network entity, NE)들의 가상화를 이용하는 네트워크 기능(network function, NF)을 포함한다. NF는 3GPP 규격에 정의되는 기능 또는 외부 애플리케이션(application)에 따른 기능을 수행할 수 있다. 본 개시의 일 실시예에 따르면, 네트워크 기능이란 네트워크 엔티티, 네트워크 컴포넌트, 네트워크 자원을 의미할 수 있다.

본 개시의 일 실시예에 따르면, 5GC는 도 1에 도시된 NF들을 포함할 수 있다. 물론 도 1의 예시에 제한되는 것은 아니며, 5GC는 도 1에 도시된 NF보다 더 많은 수의 NF들을 포함할 수도 있고 더 적은 수의 NF들을 포함할 수도 있다.

본 개시의 일 실시예에 따르면, AMF(access and mobility management function)은 단말의 이동성을 관리하는 네트워크 기능일 수 있다.

본 개시의 일 실시예에 따르면, SMF(session management function)은 단말에게 제공하는 PDN(packet data network) 연결을 관리하는 네트워크 기능일 수 있다. PDN 연결은 PDU(protocol data unit) 세션(session)이라는 이름으로 지칭될 수 있다.

본 개시의 일 실시예에 따르면, PCF(policy control function)는 단말에 대한 이동 통신 사업자의 서비스 정책, 과금 정책, 그리고 PDU 세션에 대한 정책을 적용하는 네트워크 기능일 수 있다.

본 개시의 일 실시예에 따르면, UDM(unified data management)은 가입자에 대한 정보를 저장하는 네트워크 기능 일 수 있다.

본 개시의 일 실시예에 따르면, NEF(network exposure function)은 단말에 관한 정보를 5G 네트워크 외부에 있는 서버에게 제공하는 기능일 수 있다. 또한, NEF는 5G 네트워크에 서비스를 위해서 필요한 정보를 제공하여 UDR(unified data repository)에 저장하는 기능을 제공할 수 있다.

본 개시의 일 실시예에 따르면, UPF(user plane function)는 사용자 데이터(PDU)를 DN(data network)으로 전달하는 게이트웨이 역할을 수행하는 기능일 수 있다. 특히, 본 개시의 실시예들에 따른 UPF는 오프로딩(offloading)을 위해, 스위치 서버(switch-server)와 상용 서버(예: COTS(Commercial off-the-shelf) 서버)로 구현될 수 있다. 일 실시예에 따라, 상기 UPF는 하이브리드(hybrid) UPF, 오프로딩(offloading) UPF, 스위칭(switching) UPF, 또는 이와 동등한 기술적 의미를 갖는 용어로 지칭될 수 있다.

본 개시의 일 실시예에 따르면, NRF(network repository function)은 NF을 발견(discovery)하는 기능을 수행할 수 있다.

본 개시의 일 실시예에 따르면, AUSF(authentication server function)은 3GPP 접속 망과 비-3GPP(non-3GPP) 접속 망에서의 단말 인증을 수행할 수 있다.

본 개시의 일 실시예에 따르면, NSSF(network slice selection function)은 단말에게 제공되는 네트워크 슬라 이스 인스턴스(network slice instance)를 선택하는 기능을 수행할 수 있다.

본 개시의 일 실시예에 따르면, DN(data network)는 망 사업자의 서비스나 제3자(3rd party) 서비스를 이용하기 위해서 단말이 데이터를 송수신하는 데이터 네트워크일 수 있다.

본 개시의 실시예들은 네트워크 장비에 대한 것으로, 트래픽 처리에 있어 추가적인 하드웨어로 오프로딩(offloading)을 구현하기 위한 장치 및 방법에 관한 것이다. 통신 시스템의 코어망(core network)(예: EPC(evolved packet core) 혹은 5GC(5G core)의 장비들(예: UPF(user plane function), CU(central unit), P-GW(packet-gateway), S-GW(serving gateway))은 패킷을 처리하기 위해, 대부분 CPU(central processing unit)(예: x86 CPU)를 사용한다. 패킷 처리 용량을 늘리기 위해서, 기존 CPU 기반 서버 수를 늘리는 방법이 이용된다. 이와 같은 방법은, 트래픽 처리 용량에 따라 서버 수를 증가시킨다. 따라서, 비용도 비례해서 증가한다. 또한, 많은 서버들의 사용으로 인해 에너지 소모 증가, 공간 사용 증가, 그리고 서버간 연결 및 설정 등 복잡성 증가 및 운용상에 어려움을 야기한다.

일반적인 상용 서버(예: COTS 서버)는 CPU와 NIC(network interface card)(~ 200Mbps(bit per seconds)로 구성된다. NIC의 기능은 고정되어 있다. 최근에는 스마트 NIC가 도입되었다. 상용 서버는 패킷 처리를 하는데 있어 일부 패킷 처리 기능을 NIC으로 오프로딩한다. CPU 여유의 증가로 패킷 처리 용량 일부가 증가하지만, 스마트 NIC는 정해진 기능 및 패킷 처리를 위한 극히 일부 기능만 제공한다.

반면 스위치 서버(switch-server)는 CPU와 대용량 스위치-칩(switch chip)(~12.6Tbps)으로 구성된다. P4(Programming Protocol-independent Packet Processors)와 같은 언어를 통해, 스위치 서버는 사용자가 원하는 대로 패킷 처리를 수행할 수 있다. 여기서, 스위치-칩은 프로그래밍 가능한 스위치(programmable switch)가 구현된 하드웨어를 의미할 수 있다. 스위치 서버 단독으로 상용 서버(즉, COTS 서버)처럼 패킷 처리 장비를 구성할 수 있다. 그러나, 패킷 처리시 트래픽 플로우(traffic flow)에 대한 정보가 필요한 스테이트풀한(stateful) 처리가 요구되는데, 현재 스위치-칩은 아래와 같은 크게 3가지 문제들로 인해, 스위치 서버 단독으로는 스테이트풀한 대용량 패킷 처리가 어렵다. 여기서, 스테이트풀한 처리란, 서버가 사용자(브라우저)의 상태, 클라이언트 정보, 또는 세션 정보를 기억하고 있다가, 상태, 클라이언트 정보나 세션 정보를 이용하는 처리를 의미한다.

1) 플로우 생성/삭제 처리 성능 이슈

스테이트풀한 처리를 위해서 스위치-칩에서 플로우별 스테이트를 저장하고 있어야 한다. 이를 위해 CPU에서 스위치-칩으로 플로우별 처리를 위한 정보를 전달해줘야 한다. 그러나, CPU와 스위치-칩간 인터페이스 속도 및 기타 제약으로 플로우 정보 생성/삭제 속도 제약이 있어 대용량 스테이트풀한 플로우 처리에 한계가 있다.

2) 메모리 부족

스테이트풀한 플로우 처리를 위해서 앞서 말한 스테이트풀 정보를 스위치-칩에서 저장해야 하는데, 현재 시중의 스위치-칩은 내부 탑재 메모리 크기가 적어 대용량 플로우 정보를 저장하기 어렵기에 스테이트풀한 처리를 하는데 있어 한계가 있다.

3) 기능 제약

스위치-칩에서는 주로 L2(layer 2)~L4(layer 4)에서 사용자가 원하는 대로 program을 통해 패킷 처리가 가능하다. 따라서, 스위치-칩은 전통적인 방화벽(firewall) 기능은 가능하나, 웹 방화벽(web firewall) 과 같은 L7(layer 7)(ex, URL(Uniform Resource Locator) filtering 등)의 정보를 사용자가 원하는 대로 처리하기 힘들다.

본 개시의 실시예들은, 대용량 스위치-칩을 통해, 모든 트래픽 또는 일부 트래픽을 CPU에서 스위치-칩으로 오프로딩하기 위한 방안을 제안한다. 본 개시의 실시예들은, 대용량 스위치-칩을 통해, 패킷 처리 용량을 획기적으로 늘리면서 동시에 서버 개수 증가의 최소화, 에너지 사용 절감, 공간 사용 최소화, 복잡성 감소, 그리고 비용 감소를 달성하기 위한 방안을 제안한다.

본 개시의 실시예들은 스위치 서버와 상용 서버(즉, COTS 서버)를 활용한 네트워크 오프로딩 구조 및 구성 방법, 스위치 서버를 사용한 5G 네트워크 적용 구조 및 방법, 스위치 서버와 상용 서버 서버간 트래픽 처리 구조 및 방법, 트래픽 별 오프로딩 방법들을 제안한다. 이하, 본 개시에서는 이동 통신망을 구성하는 코어 네트워크 엔티티가 오프로딩을 위한 패킷 처리 동작을 수행하는 것으로 서술되나, 본 개시의 실시예들은 이에 한정되지 않는다. 본 개시의 실시예들은, 이동 통신망의 네트워크 장비뿐만 아니라, 모든 패킷 처리 시스템의 장비에도 적용될 수 있다.

도 1b는 실시예들에 따른 UPF(user plane function)의 기능적 구성을 도시한다.

도 1b를 참고하면, UPF는 스위치 서버(110)과 상용 서버(120)를 포함할 수 있다. 스위치 서버(110)는 CPU(예: x86 PCU)와 스위치-칩을 포함할 수 있다. 일 실시예에 따라, 스위치-칩은 대용량 스위치-칩으로서, 트래픽의 전부 또는 일부를 오프로딩할 수 있다. 스위치 서버(110)는 사용자 플레인(user plane) 데이터를 처리할 수 있다. 스위치 서버(110)는 데이터 트래픽을 처리할 수 있다. 스위치 서버(110)는 사용량을 측정하고 수집할 수 있다. 스위치 서버(110)는 프로그래밍이 가능한(programmable) 스위치를 포함할 수 있다. 스위치 서버(110)는 FPGA(field programmable gate array)를 포함할 수 있다. 상용 서버(120)는 COTS 서버를 의미한다. 상용 서버(120)는 기존 패킷 처리를 담당하는 서버를 의미한다. 상용 서버(120)는 UPF의 동작들을 수행할 수 있다. 상용 서버(120)는 CPU와 NIC(network interface card)를 포함할 수 있다.

도 2는 실시예들에 따른 UPF의 스위치-칩(switch-chip)의 구현 예를 도시한다. 스위치-칩은 도 1b에 도시된 스위치 서버(110)의 스위치-칩을 예시한다.

도 2b를 참고하면, UPF(230)는 일반적인 구현 방식으로 구성될 수 있다. UPF(230)는 컨트롤러 기능을 수행하는 CPU(231)와 스위치-칩(233)을 포함할 수 있다. 컨트롤러 기능을 수행하는 CPU(231)와 스위치-칩(233)은 하나의 하드웨어 장비에 구현될 수 있다. 한편, UPF(240)는 본 개시의 실시예들에 따른 분리형 배치 방식으로 구성될 수 있다. UPF(240)는 컨트롤러 기능을 수행하는 CPU(211)와 스위치-칩(213)을 포함할 수 있다. 컨트롤러 기능을 수행하는 CPU(211)와 스위치-칩(213)은 서로 별도의 하드웨어 장비들에 구현될 수 있다. 컨트롤러 기능을 수행하는 CPU(211)를 포함하는 장비는 스위치-칩(213)을 포함하는 장비와 다를 수 있다. 스위치-칩(213)을 포함하는 장비는, 스위치-칩(213)의 구동을 위한 CPU(215)를 더 포함할 수 있다.

일 실시예에 따라, 스위치-칩(213)을 포함하는 장비는 도 1b의 스위치 서버(110)일 수 있다. 일 실시예에 따라, 컨트롤러 기능을 수행하는 CPU(211)를 포함하는 장비는 도 1b의 상용 서버(120)일 수 있다. 본 개시의 실시예들에 따른 UPF는 UPF(240)과 같이 분리형 배치 방식을 이용할 수 있다. 이 때, 스위치-칩(213)을 제어하기 위한 컨트롤러는, 신규로 추가되는 것이 아니라, 기존 트래픽을 처리하는 서버, 즉 상용 서버(예: 상용 서버(120))로부터 구현될 수 있다. 상용 서버의 활용을 통해, 기존 서버의 수정 및 스위치-칩과 상용 서버 간의 연결을 통해, 본 개시의 실시예들에 따른 하이브리드 UPF가 구현될 수 있다. 한편, 다른 방식에 따라, 컨트롤러는 신규 서버로 구현될 수 있음은 물론이다.

도 3은 실시예들에 따른 스위치 서버(switch server)의 프로그래밍이 가능한 스위치(programmable switch)와 FPGA(field programmable gate array)의 예를 도시한다. 전술한 바와 같이, 스테이트풀한 플로우 처리를 위해서는, 스위치는 스테이트풀 정보(예: 사용자의 컨텍스트 정보, 트래픽 플로우의 정보)를 저장할 것이 요구된다. 일반적인 스위치의 내부에 탑재된 메모리는 속도는 빠르지만 크기가 적어 대용량 플로우 정보를 저장하기 용이하지 않다. 상술된 메모리 문제의 해소를 위해, 본 개시의 실시예들에 따른 프로그래밍이 가능한 스위치는 FPGA를 이용할 수 있다. 스위치에 복수의 FPGA 메모리들이 결합되는 구조를 통해, 메모리 용량이 증가할 수 있다. 대용량 데이터의 오프로딩 구현을 위해, 스위치 서버는 프로그래밍이 가능한 스위치 및 FPGA를 포함할 수 있다.

도 3을 참고하면, CPU(340), 스위치 서버는 프로그래밍이 가능한 스위치(341)(즉, 스위치-칩), 및 복수의 FPGA들(예: 제1 FPGA(350a), 제2 FPGA(350b), 제3 FPGA(350c), 제4 FPGA(350d))를 포함할 수 있다. 프로그래밍이 가능한 스위치(341)는 스위치-칩을 예시한다. 이하, 별도의 다른 정의가 없는 한, 스위치는 프로그래밍이 가능한 스위치로서, 대용량 스위치-칩을 지칭한다. 프로그래밍이 가능한 스위치(341)는 SRAM(static random access memory)을 포함할 수 있다.

FPGA는 설계 가능 논리 소자와 프로그래밍이 가능한 내부 회로가 포함된 반도체 소자를 의미한다. 프로세서 내부 회로가 프로그램에 맞게 직접 설계되므로, FPGA는, 프로그램의 호출과 작업을 병렬적으로 수행함으로써, CPU(340) 보다 훨씬 빠른 계산 속도를 낼 수 있다. 각 FPGA는 하나 이상의 DRAM(dynamic random access memory)들(예: 2개의 DRAM들)을 포함할 수 있다. 스위치와 각 FPGA(예: 제1 FPGA(350a), 제2 FPGA(350b), 제3 FPGA(350c), 제4 FPGA(350d))는 유기적으로 동작할 수 있다. 각 FPGA는 프로그래밍이 가능한 스위치(341)에 대하여 투명(transparent)하게 동작할 수 있다. 본 개시의 실시예들에 따른 스위치 서버는 스위치-칩과 FPGA를 통해, 확장된 메모리를 제공할 수 있다.

일 실시예에 따라, UPF는 프로그래밍 가능한 스위치(341)에 연결되는 FPGA를 슬라이스 별로 할당할 수 있다. 예를 들어, UPF는 제1 슬라이스를 제1 FPGA(350a)에 할당할 수 있다. 예를 들어, UPF는 제2 슬라이스를 제1 FPGA(350b)에 할당할 수 있다. 예를 들어, UPF는 제3 슬라이스를 제1 FPGA(350c)에 할당할 수 있다. 예를 들어, UPF는 제4 슬라이스를 제1 FPGA(350d)에 할당할 수 있다. UPF는 프로그래밍 가능한 스위치(341)를 통해, ATSSS(access traffic steering, switching, splitting) 기능을 수행할 수 있다.

도 4는 실시예들에 따른 UPF의 적응적(adaptive) 트래픽 처리의 예를 도시한다. 스위치 서버에서 처리하지 못하는 기능의 트래픽 플로우에 대해서는 스위치 서버로 오프로딩하지 않고, 기존 COTS 서버에서 처리하는 방식이 요구된다. 도 4에서는, 스위치 서버와 COTS 서버를 통해 구현되는 UPF가 포함된 5G 네트워크가 예시된다.

도 4를 참고하면, UPF(425)는 스위치 서버와 하나 이상의 COTS 서버들을 포함할 수 있다. 기존 5G 네트워크와 같이, COTS 서버에 구현된 UPF(425)는 SMF(440)와 연동될 수 있다. UPF(425)는 SMF(440)과 N4 인터페이스를 통해 통신을 수행할 수 잇다. 스위치 서버는 COTS 서버와 연동될 수 있다. 따라서, 논리적으로는 현재 3GPP 코어망의 변경 없이, UPF(425)가 3GPP 코어망의 다른 네트워크 엔티티들과 통신을 수행할 수 있다. 2개의 서버들(COTS 서버, 스위치 서버)는 외부에서 볼 때, 하나의 서버처럼 동작할 수 있다. 예를 들어, 제어 평면 입장에서, 외부의 제어 장비(예: SMF(440))는 COTS 서버에만 연결될 수 있다. 제어 장비는 스위치 서버의 존재를 알 수 없다. 예를 들어, 데이터 평면 입장에서, 다른 네트워크 장비는 스위치 서버에만 연결된다. 다른 네트워크 장비는 COTS 서버의 존재를 알 수 없다. 하나의 네트워크 엔티티(예: UPF)로 동작하기 위하여, 스위치 서버(110)는 상용 서버(120)와 통신을 수행할 수 있다. 스위치 서버(110)는 상용 서버(120)와 이더넷 통신을 수행할 수 있다.

트래픽은 사용자 평면(혹은 데이터 평면)의 패킷 또는 제어 평면의 패킷 중 적어도 하나를 포함할 수 있다. 기존 5G UPF에서는, COTS 서버는 SMF로부터 수신된 제어 평면 정보(GTP tunnel info, user QoS, 패킷 사용량 제한 등)에 기반하여, 수신된 패킷을 사용자 평면에서 처리한다. 즉 하나의 COTS 서버에서 제어 평면의 패킷과 사용자 평면의 패킷 모두를 처리하였다. 그러나, 본 개시의 실시예들에 따른 UPF(425)는 기존 COTS 서버에 스위치 서버가 결합된 구조를 갖는다. UPF(425)의 COTS 서버는 UPF의 제어 평면의 패킷을 처리할 수 있다. UPF(425)의 COTS 서버는 신규 알려지지 않은(unknown) 플로우에 대한 패킷의 처리를 수행할 수 있다. UPF(425)의 COTS 서버는 스위치 서버로 플로우 엔트리를 생성 처리할 수 있다. UPF(425)의 스위치 서버는 알려진(known) 플로우에 대해 사용자 평면의 패킷을 처리할 수 있다.

본 개시의 실시예들에 따른 UPF(425)의 스위치 서버는 판단 조건에 따라 수신된 패킷을 직접 처리할 수 있다. 수신된 패킷은 COTS 서버에 의해 오프로딩된 패킷(430)일 수 있다. 본 개시의 실시예들에 따른 UPF(425)의 COTS 서버는 동일한 사용자 평면이더라도, 판단 조건에 따라 스위치 서버로부터 수신된 패킷을, 직접 처리할 수 있다. 수신된 패킷은 신규 플로우의 패킷 또는 언-오프로딩된 패킷(435)일 수 있다.

도 5a는 실시예들에 따른 UPF의 트래픽 처리의 예(500)를 도시한다. 데이터 센터 구조로서, 스위치 서버 및 COTS 서버가 예시된다.

도 5a를 참고하면, 스위치 서버는 프로그래밍이 가능하고(programmable), 용량이 크기 때문에, 서버 랙(server rack)의 ToR(top-of-rack) 스위치를 이용할 수 있다. ToR 스위치의 제어를 위해, 스위치 서버의 CPU가 컨트롤러로 이용될 수 있다. 본 개시의 실시예들에 따른 UPF는 ToR 스위치 기능을 수행할 수 있다. 즉, UPF는 스위치 서버의 남는 용량을 활용하여, ToR 스위치를 대체할 수 있다. 일 실시예에 따라, UPF는 SDN(software-defined network)을 지원할 수 있다. 본 개시의 실시예들에 따른 UPF는 SDN 스위치의 기능을 수행할 수 있다.

도 5b는 실시예들에 따른 UPF의 사용자 평면(user plane)의 처리(processing) 및 제어 평면(control plane)의 처리의 예를 도시한다. UPF는 스위치 서버(110) 및 상용 서버(120)를 포함할 수 있다.

도 5b를 참고하면, 사용자 평면의 처리(551)는 스위치 서버(110)에 의해 수행되거나 상용 서버(120)에 의해 수행될 수 있다. 스위치 서버(110)는 수신되는 사용자 평면의 트래픽들(패킷들)을 분류할 수 있다. 스위치 서버(110)는 지정된 규칙에 기반하여, 특정 트래픽은 직접 처리하고, 다른 트래픽은 COTS 서버에게 포워딩할 수 있다. 오프로딩된 패킷(430)은 스위치 서버(110)에 의해 처리될 수 있다. 신규 플로우의 패킷 또는 언-오프로딩된 패킷(435)은 상용 서버(120)에 의해 수행될 수 있다. 일 실시예에 따라,

일 실시예에 따라, UDP(user datagram protocol) 트래픽은 오프로딩된 패킷(430)을 포함할 수 있다. UDP 트래픽은 스위치 서버(110)에 의해 처리될 수 있다. 일 실시예에 따라, TCP(transmission control protocol) 트래픽은 신규 플로우의 패킷 또는 언-오프로딩된 패킷(435)을 포함할 수 있다. TCP 트래픽은 상용 서버(120)에 의해 수행될 수 있다.

제어 평면의 처리(551)는 COTS 서버에 의해 수행된다. COTS 서버는 기존 UPF가 담당하던 제어 평면의 패킷들을 처리할 수 있다. 즉, 5G 시그널링은 UPF의 분리 구현으로 인해 달라지지 않는다. 외부 네트워크 엔티티(예: SMF(440))는 COTS 서버와 통신을 수행할 수 있다.

도 1 내지 도 5b를 통해, 프로그래밍 가능한 스위치, 즉, 스위치-칩을 포함하는 스위치 서버를 이용하는 UPF의 구현 방안이 서술되었다. UPF의 제어 시그널링을 담당하는 상용 서버와 스위치 서버가 분리됨으로써, 트래픽의 효율적인 처리가 가능하다. 이하, 트래픽의 효율적인 처리를 위해, 상용 서버와 스위치 서버 간 구체적인 동작들이 도 6 내지 도 8b를 통해 구체적으로 서술된다.

도 6은 실시예들에 따른 UPF의 초기화 동작의 예(600)를 도시한다. UPF는 두 개의 엔티티들을 통해 구현될 수 있다. 일 실시예에 따라, UPF의 구현을 위해, 스위치 서버(110) 및 상용 서버(120)(예: COTS 서버)가 이용될 수 있다. 스위치 서버(110)는 프로그래밍 가능한 스위치와 하나 이상의 FPGA들을 포함할 수 있다. 도 6에서는 제2 FPGA(즉, FPGA_2)가 예시되나, 제2 FPGA 외에 다른 FPGA들 또한 프로그래밍 가능한 스위치와 결합될 수 있다.

프로그래밍 가능한 스위치는 패킷을 수신할 수 있다. 프로그래밍 가능한 스위치는 수신된 패킷의 처리 방향을 식별할 수 있다. 프로그래밍 가능한 스위치는 플로우 테이블에 기반하여, 수신된 패킷의 처리 방향을 식별할 수 있다. 즉, 프로그래밍 가능한 스위치는, 플로우 테이블에 기반하여, 패킷을 스위치 서버(110)에서 자체적으로 처리할 것인지 아니면 상용 서버(120)가 패킷을 처리하도록 상용 서버(120)에게 전달할 것인지 여부를 식별할 수 있다. 이 때, 플로우 테이블은 상용 서버(120)에 의해 설정될 수 있다.

도 6을 참고하면, 상용 서버(120)는 초기화(initialization) 동작을 수행할 수 있다. 일 실시예에 따라, 상용 서버(120)는 스위치 서버(120)의 액션(action)들을 제어하기 위한 정보를 생성할 수 있다. 상용 서버(120)는 구성 정보에 기반하여, 스위치 서버(120)의 액션들을 설정할 수 있다. 일 실시예에 따라, 상용 서버(120)는 스위치 서버(120)에서 처리하기 위한 플로우 엔트리 및 플로우 테이블을 설정할 수 있다. 플로우 엔트리는 스위치-칩 또는 FPGA 내 플로우 테이블에서 생성 또는 삭제되는 플로우 정보 및 기타 처리를 위한 정보를 포함하는 데이터 셋(set)을 의미한다. 스위치-칩 내 플로우 테이블은 수신된 패킷을 어떤 FPGA로 전달할지를 가리키는 룩-업 테이블(look-up table)일 수 있다. 플로우 테이블은 포워딩 테이블로 지칭될 수도 있다.

도 7a 및 도 7b는 실시예들에 따른 UPF의 상향링크 데이터 처리의 예를 도시한다. 일 실시예에 따라, UPF의 구현을 위해, 스위치 서버(110) 및 상용 서버(120)(예: COTS 서버)가 이용될 수 있다. 스위치 서버(110)는 프로그래밍 가능한 스위치와 하나 이상의 FPGA들을 포함할 수 있다.

도 7a에서는 스위치 서버(110) 및 상용 서버(120)의 신규 플로우에 대한 패킷 처리 동작(700)이 서술된다. 여기서, 패킷은 상향링크 데이터일 수 있다. 스위치 서버(120)에 플로우 엔트리가 생성되면 도 7a의 패킷 처리 동작(700)은 수행되지 않는다.

제1 단계에서, 스위치 서버(110)는 프로그래밍 가능한 스위치를 통해 패킷을 수신할 수 있다. 스위치 서버(110)는 스위치를 통해, 대응하는 FPGA(예: FPGA_2)를 식별할 수 있다. 스위치 서버(110)는 대응하는 FPGA에게 수신된 패킷을 전달할 수 있다. 예를 들어, 수신된 패킷은 상향링크 데이터로서, IP 패킷, GTP(GPRS(General Packet Radio Service) Tunnelling Protocol) 헤더, 및 Outer IP(internet protocol) 헤더를 포함할 수 있다.

제2 단계에서, 스위치 서버(110)는 수신된 패킷의 플로우 엔트리가 FPGA에 없음을 식별할 수 있다. FPGA는 패킷을 다시 스위치에게 전달할 수 있다. 스위치 서버(110)는, 스위치를 통해, 상용 서버(120)에게 상기 패킷을 전달할 수 있다. 즉, 플로우 엔트리가 없는 패킷이 스위치 서버(110)에 도착하면, 스위치 서버(110)는 플로우 엔트리를 찾아본다. 만약 해당 패킷에 대응하는 플로우 엔트리가 없다면, 스위치 서버(110)는 상기 패킷을 신규 플로우 패킷으로 인식하고, 상용 서버(120)에게 해당 패킷을 전달할 수 있다.

제3 단계에서, 상용 서버(120)는 패킷을 처리할 수 있다. 상용 서버(120)는 수신된 패킷을 기존 UPF 동작과 동일하게 처리할 수 있다. 상용 서버(120)는 플로우 엔트리 처리 및 UE 컨텍스트 기반 PDR(packet detection rule) 처리를 수행할 수 있다.

제4 단계에서, 상용 서버(120)는 플로우 오프로딩 여부를 결정할 수 있다. 상용 서버(120)는 패킷을 스위치 서버(110)에서 처리할 것인지 여부를 판단할 수 있다. 상용 서버(120)는 플로우 오프로딩을 수행할 것으로 결정하는 것에 기반하여, 스위치 서버(110)에서 처리하기 위한 메타데이터(예: DSCP(Differentiated Service Code Point) 값)를 상기 패킷에 추가할 수 있다. 상용 서버(120)는 해당 패킷의 사용자 정보를 보고 패킷 처리시 필요한 액션(action)과 이와 관련된 파라미터 값(GTP Info, DSCP, QoS 정보 등)을 메타로 하여 해당 패킷에 메타를 추가할 수 있다. 상용 서버(120)는 사용량을 기록할 수 있다. 수신된 패킷에 일부 데이터(예: 메타데이터, IP, UDP)를 추가함으로써, 상용 서버(120)는 처리된 패킷을 생성할 수 있다. 상용 서버(120)는 처리된 패킷을 FPGA로 전달할 수 있다.

일 실시예에 따라, 메타데이터는 엔트리 ID를 포함할 수 있다. 엔트리 ID는 UE ID 및 PDR에 기반하여 결정될 수 있다. 엔트리 ID는 향후 PDR 별 사용량 카운트에 이용될 수 있다. 일 실시예에 따라, 일 실시예에 따라, 메타데이터는 GTP 정보를 포함할 수 있다. 상용 서버(120)는 GTP 헤더에 포함된 TEID(tunnel endpoint identifier)를 식별 및 처리할 수 있다. 메타데이터는 TEID(tunnel endpoint ID)를 포함할 수 있다. 일 실시예에 따라, 메타데이터는 DSCP 값을 포함할 수 있다. 상용 서버(120)는 DSCP를 식별 및 처리할 수 있다. TEID 또는 DSCP는 스위치 서버(110)의 FPGA에서 패킷 처리를 위해 이용될 수 있다. 한편, 도 7a에 도시된 바와 달리, 상용 서버(120)는 아직 플로우 오프로딩을 수행할 필요가 없다고 판단할 경우, 메타데이터 없이, 처리된 패킷을 스위치 서버(110)에게 전달할 수 있다. 즉, 해당 패킷에 대한 플로우 엔트리 생성 및 특정 처리과정을 원하지 않는다면, 상용 서버(120)는 메타 정보없이, 패킷을 스위치 서버(110)로 전달하여, 외부로(egress) 내보낼 수 있다. 메타데이터가 없어, 스위치 서버에 플로우 엔트리가 생성되지 않을 수 있다.

제5 단계에서, 스위치 서버(120)는 메타데이터에 기반하여 플로우 엔트리를 생성할 수 있다. 스위치 서버(120)의 FPGA는 메타데이터에 기반하여 플로우 엔트리를 생성할 수 있다. 패킷을 수신한 스위치 서버(110)는 메타 정보에 기반하여 해당 패킷의 플로우 엔트리를 생성할 수 있다.

제6 단계에서, 스위치 서버(120)의 FPGA는 패킷을 스위치에게 전달할 수 있다. 패킷을 수신한 스위치 서버(110)는 생성된 엔트리에 기반하여, 패킷 처리를 수행할 수 있다. 스위치 서버(120)의 FPGA는 UDP 정보 및 IP 정보를 제거할 수 있다. 스위치 서버(120)의 스위치는, UDP 정보 및 IP 정보가 제거된 패킷을 수신할 수 있다.

제7 단계에서, 스위치 서버(120)는 스위치를 통해, 지정된 액션에 대한 처리 후, 처리된 패킷을 외부로 전달할 수 있다. 스위치 서버(120)의 스위치는 스위치 서버(120)의 FPGA로부터 수신된 패킷의 GTP 헤더, Outer IP 헤더, 및 메타데이터를 제거할 수 있다. 스위치 서버(120)의 스위치는 IP 패킷을 외부로 전달할 수 있다.

제1 단계 내지 제7 단계를 통해, 스위치 서버(120)는 패킷을 오프로딩하거나 직접 처리할 수 있다. 일 실시예에 따라, 특정 L2/L3/L4 조건이 충족되는 패킷에 대해서는, 스위치 서버(110)는 플로우 엔트리가 없더라도 상용 서버(120)에게 패킷을 전달하지 않고 스위치 서버(110)에서 패킷을 직접 처리할 수 있다. 이러한 동작은, 스위치 서버(110)의 스위치-칩에 대한 프로그램에 의해 결정될 수 있다. 이하, URL 필터링(filtering)이 예제로 설명된다.

스위치 서버(110)는 HTTP 신규 플로우를 위한 첫번째 패킷인 TCP SYN(synchronization) 패킷을 수신할 수 있다. 스위치 서버(110)는 플로우 엔트리가 없음을 확인하고 해당 패킷을 상용 서버(120)에게 전달할 수 있다. 상용 서버(120)는 목적 포트(destination port)가 80 또는 8080인 경우 HTTP(HyperText Transfer Protocol) 플로우로 인식할 수 있다. 상용 서버(120)는 HTTP 요청(request) 패킷을 수신할 때까지 해당 플로우에 대한 스위치 서버(110)로의 트래픽 오프로딩을 보류할 수 있다. 상용 서버(120)는, HTTP 요청 패킷의 URL 정보를 확인한 후에, 해당 플로우를 계속 유지할지, 아니면 해당 플로우를 드랍(drop)할지 여부를 결정할 수 있기 때문이다. 따라서, 상용 서버(120)는 플로우 엔트리 생성을 위한 메타 정보는 없이 상용 서버(120)에서 필요한 처리(플로우 엔트리 생성 및 패킷 count 등)를 수행한 후에, 처리된 패킷을 다시 스위치 서버(110)로 돌려보내, 외부로의 패킷 전송을 완료할 수 있다.

이후 HTTP 패킷이 스위치 서버(110)에 도착하게 되면, 스위치 서버(110)는 여전히 해당 플로우 엔트리가 스위치 서버(110)에 없기 때문에 해당 패킷을 다시 상용 서버(120)에게 전달할 수 있다. 상용 서버(120)는 필요한 처리 후 HTTP 헤더(header)의 URL 정보를 보고, 해당 트래픽(traffic) 플로우를 허용하여 스위치 서버(110)로의 오프로딩을 진행할지, 아니면 차단할지 결정할 수 있다. 만약 상용 서버(120)가 해당 URL의 접속을 허용하고 동시에 오프로딩을 하기로 결정했으면, 상용 서버(120)는 HTTP 요청 패킷에 해당 플로우의 상태 정보, 스위치 서버(110)에서 해야할 액션(action) 및 액션 데이터(action data) 등을 메타데이터에 포함시킬 수 있다. 상용 서버(120)는 메타데이터를 스위치 서버(110)에게 전송할 수 있다. 만약 해당 URL의 접속을 차단해야 한다면, 상용 서버(120)는 해당 패킷을 드랍할 수 있다. 스위치 서버(110)는 해당 패킷 수신 후, 메타 정보에 기반하여 플로우 엔트리를 생성하고, 대응되는 패킷 처리를 수행할 수 있다. 이후 수신되는 플로우 패킷에 대해서는 스위치 서버(110)에 플로우 엔트리가 있으므로, 스위치 서버(110)는 상용 서버(120)로 전달하지 않고 스위치 서버(110)에 직접 처리하게 되어 오프로딩을 수행할 수 있다.

도 7b에서는 스위치 서버(110) 및 상용 서버(120)의 등록된 플로우에 대한 패킷 처리 동작(750)이 서술된다. 여기서, 패킷은 상향링크 데이터일 수 있다. 플로우 엔트리가 스위치 서버(120)에 등록된 상황에서, 스위치 서버(110)는 등록된 패킷을 처리할 수 있다.

제1 단계에서, 스위치 서버(110)는 프로그래밍 가능한 스위치를 통해 패킷을 수신할 수 있다. 스위치 서버(110)는 스위치를 통해, 대응하는 FPGA(예: FPGA_2)를 식별할 수 있다. 스위치 서버(110)는 대응하는 FPGA에게 수신된 패킷을 전달할 수 있다. 예를 들어, 수신된 패킷은 IP 패킷, GTP 헤더, 및 Outer IP 헤더를 포함할 수 있다.

제2 단계에서, 스위치 서버(110)의 FPGA는 수신된 패킷에 매치되는 플로우 엔트리로부터 액션 및 액션 데이터 정보를 획득하고, 획득된 액션 및 액션 데이터 정보를 메타데이터에 포함시킬 수 있다.

제3 단계에서, 스위치 서버(110)의 FPGA는 패킷에 메타데이터를 추가하여, 처리된 패킷을 생성할 수 있다. FPGA는 생성된 패킷을 프로그래밍 가능한 스위치에게 전달할 수 있다.

제4 단계에서, 스위치 서버(110)의 스위치는 메타데이터가 지시하는 액션을 처리한 후, 처리된 패킷을 외부에게 전달할 수 있다. 일 실시예에 따라, 스위치 서버(110)의 스위치는 GTP(GPRS Tunnelling Protocol) 헤더를 제거할 수 있다. 일 실시예에 따라, 스위치 서버(110)의 스위치는 Outer IP(internet protocol) 헤더를 제거할 수 있다. 일 실시예에 따라, 스위치 서버(110)의 스위치는 DSCP 마킹(marking)을 수행할 수 있다.

제1 단계 내지 제4 단계를 통해, 수신 패킷이 스위치 서버(110)의 플로우 엔트리에 존재하는 패킷이면, 스위치 서버(110)는 자체적으로 처리해 패킷을 외부로 전달할 수 있다. 도 7b에 도시된 바와 같이, 스위치 서버(110)에서 패킷을 자체적으로 처리하는 경우, 상용 서버(120)는 패킷 처리에 관여하지 않는다. 상용 서버(120)에게 패킷이 전송되었다가 스위치 서버(110)로 다시 돌아오는 과정 없이, 스위치-칩의 하드웨어에 의해서만 패킷이 처리되기 때문에, 대용량 패킷이 고속으로 처리될 수 있다.

도 7a 및 도 7b에서는 상향링크 패킷의 처리 동작이 서술되었으나, 본 개시의 실시예들은 이에 한정되지 않는다. 본 개시의 실시예들에 따른 스위치 서버를 이용하는 UPF의 동작 원리는 하향링크 패킷을 위해서도 적용될 수 있다. 이하, 도 8a 및 도 8b를 통해 하향링크 패킷의 처리 동작이 서술된다.

도 8a 및 도 8b는 실시예들에 따른 UPF의 하향링크 데이터 처리의 예를 도시한다. 일 실시예에 따라, UPF의 구현을 위해, 스위치 서버(110) 및 상용 서버(120)(예: COTS 서버)가 이용될 수 있다. 스위치 서버(110)는 프로그래밍 가능한 스위치와 하나 이상의 FPGA들을 포함할 수 있다.

도 8a에서는 스위치 서버(110) 및 상용 서버(120)의 신규 플로우에 대한 패킷 처리 동작(800)이 서술된다. 여기서, 패킷은 하향링크 데이터일 수 있다. 스위치 서버(120)에 플로우 엔트리가 생성되면 도 8a의 패킷 처리 동작(800)은 수행되지 않는다. 도 7a에서 언급된 동작들은 동일 또는 유사한 방식으로 도 8a에서도 적용될 수 있다.

제1 단계에서, 스위치 서버(110)는 프로그래밍 가능한 스위치를 통해 패킷을 수신할 수 있다. 스위치 서버(110)는 스위치를 통해, 대응하는 FPGA(예: FPGA_2)를 식별할 수 있다. 스위치 서버(110)는 대응하는 FPGA에게 수신된 패킷을 전달할 수 있다. 예를 들어, 수신된 패킷은 하향링크 데이터로서, IP 패킷을 포함할 수 있다.

제3 단계에서, 상용 서버(120)는 패킷을 처리할 수 있다. 상용 서버(120)는 수신된 패킷을 기존 UPF 동작과 동일하게 처리할 수 있다. 상용 서버(120)는 UE 컨텍스트 기반 PDR(packet detection rule) 처리, UDR(usage reporting rule) 처리, 및 플로우 엔트리 처리를 수행할 수 있다.

일 실시예에 따라, 메타데이터는 엔트리 ID를 포함할 수 있다. 엔트리 ID는 UE ID 및 PDR에 기반하여 결정될 수 있다. 엔트리 ID는 향후 PDR 별 사용량 카운트에 이용될 수 있다. 일 실시예에 따라, 메타데이터는 GTP 정보를 포함할 수 있다. 상용 서버(120)는 GTP 헤더 및 IP 헤더를 메타데이터에 추가할 수 있다. 일 실시예에 따라, 메타데이터는 DSCP 값을 포함할 수 있다. 상용 서버(120)는 DSCP 마킹을 수행할 수 있다. 상용 서버(120)는 DSCP 값을 메타데이터에 추가할 수 있다. 메타데이터는 스위치 서버(110)의 FPGA에서 패킷 처리를 위해 이용될 수 있다. 한편, 도 8a에 도시된 바와 달리, 상용 서버(120)는 아직 플로우 오프로딩을 수행할 필요가 없다고 판단할 경우, 메타데이터 없이, 처리된 패킷을 스위치 서버(110)에게 전달할 수 있다. 즉, 해당 패킷에 대한 플로우 엔트리 생성 및 특정 처리과정을 원하지 않는다면, 상용 서버(120)는 메타 정보없이, 패킷을 스위치 서버(110)로 전달할 수 있다. 메타데이터가 없어, 스위치 서버에 플로우 엔트리가 생성되지 않을 수 있다.

제7 단계에서, 스위치 서버(120)는 스위치를 통해, 지정된 액션에 대한 처리 후, 처리된 패킷을 외부로 전달할 수 있다. 스위치 서버(120)의 스위치는 스위치 서버(120)의 FPGA로부터 수신된 패킷의 메타데이터를 제거하고, 스위치 서버(120)의 스위치는 GTP 헤더 및, Outer IP 헤더를 상기 패킷에 부가할 수 있다. 스위치 서버(120)의 스위치는 IP 패킷, GTP 헤더 및, Outer IP 헤더를 포함하는 패킷을 외부로 전달할 수 있다.

도 8b에서는 스위치 서버(110) 및 상용 서버(120)의 등록된 플로우에 대한 패킷 처리 동작(750)이 서술된다. 여기서, 패킷은 하향링크 데이터일 수 있다. 플로우 엔트리가 스위치 서버(120)에 등록된 상황에서, 스위치 서버(110)는 등록된 패킷을 처리할 수 있다. 도 7b에서 언급된 동작들은 동일 또는 유사한 방식으로 도 8b에서도 적용될 수 있다.

제1 단계에서, 스위치 서버(110)는 프로그래밍 가능한 스위치를 통해 패킷을 수신할 수 있다. 스위치 서버(110)는 스위치를 통해, 대응하는 FPGA(예: FPGA_2)를 식별할 수 있다. 스위치 서버(110)는 대응하는 FPGA에게 수신된 패킷을 전달할 수 있다. 예를 들어, 수신된 패킷은 IP 패킷을 포함할 수 있다.

제2 단계에서, 스위치 서버(110)는 수신된 패킷의 플로우 엔트리가 액션 및 액션 데이터 정보를 메타데이터에 포함시킬 수 있다.

제4 단계에서, 스위치 서버(110)의 스위치는 프로세싱 후, 처리된 패킷을 외부에게 전달할 수 있다. 일 실시예에 따라, 스위치 서버(110)의 스위치는 GTP(GPRS Tunnelling Protocol) 헤더를 추가할 수 있다. 일 실시예에 따라, 스위치 서버(110)의 스위치는 Outer IP(internet protocol) 헤더를 추가할 수 있다. 일 실시예에 따라, 스위치 서버(110)의 스위치는 DSCP 마킹(marking)을 수행할 수 있다.

제1 단계 내지 제4 단계를 통해, 수신 패킷이 스위치 서버(110)의 플로우 엔트리에 존재하는 패킷이면, 스위치 서버(110)는 자체적으로 처리해 패킷을 외부로 전달할 수 있다. 도 8b에 도시된 바와 같이, 스위치 서버(110)에서 패킷을 자체적으로 처리하는 경우, 상용 서버(120)는 패킷 처리에 관여하지 않는다. 상용 서버(120)에게 패킷이 전송되었다가 스위치 서버(110)로 다시 돌아오는 과정 없이, 스위치-칩의 하드웨어에 의해서만 패킷이 처리되기 때문에, 대용량 패킷이 고속으로 처리될 수 있다.

스위치 서버의 스위치-칩(예: 프로그래밍 가능한 스위치(341))에는 패킷 파서(parser)가 있다. 스위치-칩은 L2/L3/L4 기반으로 운영자가 원하는 트래픽에 대해서만 오프로딩을 선택적으로 할 수 있다. 또한, 스위치 서버는 신규 플로우의 패킷을 COTS 서버로 전달하고, COTS 서버는 DPI(deep packet inspection) 등을 이용하여 사용자가 정의한 특정한 애플리케이션에 대해서도 오프로딩을 수행할 수 있다.

일례로 URL filtering 기능에서, 패킷은, 스위치 서버에서 없는 플로우에 대응하는 경우, 우선 COTS 서버로 전달된다. COTS 서버는 L7의 HTTP의 URL 정보를 보고 허용해야 할지 말아야 할지를 결정할 수 있다. 만약 허용해도 되는 플로우라면 스위치 서버에서 해당 플로우 엔트리의 등록 절차를 수행할 수 있다. COTS 서버는 패킷에 메타 정보를 추가한 다음, 처리된 패킷을 스위치 서버에게 전달할 수 있다. 스위치 서버는 해당 메타 정보를 식별할 수 있다. 스위치 서버는 메타 정보에 기반하여, 적절한 플로우 엔트리를 스위치-칩에 생성할 수 있다. 만약 해당 URL을 허용하기 어렵다면(즉 허용 불가), COTS 서버는 해당 패킷을 드랍할 수 있다. 추가적으로 해당 URL과 같은 다른 사용자의 패킷을 더이상 COTS 서버에서 처리하기 않기 위해서, COTS 서버는 스위치 서버로 URL의 목적(destination) IP 주소 정보를 필터링 리스트에 등록할 수 있다. 이러한, 필터링 리스트는 스위치 서버에게 제공될 수 있다. 향후에 해당 URL로 가는 패킷에 대해, 스위치 서버가 처음부터 필터링을 수행할 수 있다.

도 9는 실시예들에 따른 UPF의 시스템의 예를 도시한다. 본 개시에서 제안되는 하이브리드 UPF 시스템의 전체적인 구성이 서술된다.

도 9를 참고하면, 하이브리드 UPF 시스템(900)은 하나의 스위치 서버(910)와 복수의 상용 서버들(예: 제1 서버(950a), 제2 서버(950b), 제3 서버(950c))을 포함할 수 있다.

각 서버는 UPF 처리부와 오프로딩 클라이언트부를 포함할 수 있다. 제1 서버(950a)는 제1 UPF 처리부(930a)와 제1 오프로딩 클라이언트부(935a)를 포함할 수 있다. 제2 서버(950b)는 제2 UPF 처리부(930b)와 제2 오프로딩 클라이언트부(935b)를 포함할 수 있다. 제3 서버(950c)는 제3 UPF 처리부(930c)와 제3 오프로딩 클라이언트부(935c)를 포함할 수 있다.

Hybrid UPF 시스템(900)에서 외부 패킷의 인입(Ingress)과 배출(Egress)은 분배기(Load Balancer) 및 Action 수행 역할을 하는 패킷 처리 파이프라인(Packet Processing Pipeline, PPP)(913)에서 수행한다. PPP(913)는 내장된 Match Action Pipeline의 동작에 따라 들어온 패킷을 확장 매치 액션 파이프라인(Extended Match Action Pipeline)(915, 917)으로 전달하거나 각 서버의 UPF로 전달한다. 확장 매치 액션 파이프라인이나 서버의 UPF에서 처리된 패킷을 밖으로 내보내기 위해서, 패킷은 다시 PPP로 전달된다. 외부 주소 또는 배출용임을 표시하는 정보를 PPP가 구분하여 배출 방향으로 전달한다.

한편, 본 개시의 실시예들에서 해결하고자 하는 과제는 서버에 위치한 UPF에서 처리할 과다한 패킷이 유입될 때, 서버의 용량이 이를 감당하지 못하여 전송 품질이 저하되거나, 서버의 수를 다수 배치해야 함으로써 비용이 증가하는 문제이다. 추가로, 이러한 문제를 해결하기 위해 사용자 평면의 패킷 처리 업무를 스위치 서버(910)으로 위임 또는 오프로딩(오프로딩)하는 방안이 서술된다. 서버의 부담이 줄고 결과적으로 기존 대비 패킷 처리 용량이 비약적으로 확장될 수 있다.

본 개시의 실시예들에 따른 처리 방법은, 서버에서 처리가 용이한 L4부터 L7 세션(session)에 대한 동작을, 스위치 서버(910)에서 처리하는 L2부터 L3 패킷 플로우 (플로우)에 대한 동작으로 변환할 수 있다. 스위치 서버(910)으로 패킷 처리가 위임되기 때문에, 스위치 서버(910)에서 처리하기 어려운 동작이 여전히 남아 있다. 특정 조건에 따라 위임을 취소하여 다시 서버에서 처리하도록 하는 방법이 본 개시의 실시예들이 제안하는 문제 해결의 핵심이 된다.

서버는 패킷 위임(즉, 오프로딩)을 설정/제어하기 위한 오프로딩 클라이언트부를 포함할 수 있다. 오프로딩 클라이언트부는 UPF의 요청에 따라 L4 내지 L7 세션에 대한 상태(state) 정보를 L2 내지 L33 패킷 플로우에 대한 상태 정보로 변환할 수 있다. 오프로딩 클라이언트부는 스위치 서버(910)에 의해 제공되는 프로그래밍 인터페이스를 통해 스위치 서버(910)의 정책을 설정할 수 있다. 스위치 서버(910)가 제공하는 프로그래밍 인터페이스는 스위치 서버(910)의 제어부(switch server control)(911))가 제공하는 방식과 스위치 서버의 전송부(예: 패킷 처리 파이프라인(Packet Processing Pipeline)(913) 및 확장 매치 액션 파이프라인(915))가 제공하는 방식이 있다.

스위치 서버(910)의 제어부, 곧 CPU와 그 주변 장치에 의해 제공되는 인터페이스는 오프로딩 클라이언트부의 요청 메시지를 CPU가 컴파일하여 패킷 처리 파이프라인(913)의 상태값을 설정할 수 있다. 이러한 과정을 거치므로, 실시간으로 설정이 갱신되어야 하는 처리에는 상술된 방식이 적합하지 않다. 반면, 스위치 서버의 전송부가 제공하는 인터페이스는 패킷 헤더에 요청 메시지를 실어 보내므로, 스위치 서버(910)는, 전송부의 자체 동작에 의해 지시된 상태값을 추가/갱신/삭제할 수 있다. 오프로딩 클라이언트부는 이러한 스위치 서버의 여러 종류의 프로그래밍 인터페이스와 통신할 수 있게 구현되어 스위치 서버(910)와 상호 통신이 가능하다.

본 개시에서 위임/오프로딩의 대상이 되는 L4 내지 L7 세션은 특히 5G UPF 관점에서 사용자 평면 세션의 패킷 처리 기능에 해당한다. 본 개시의 실시예들의 이해를 위해, 서버의 UPF 동작이 간략히 서술된다. 5G 코어망에서 SMF에 의해 어떤 단말에 대한 세션이 수립되면, SMF는 세션에 대한 규칙 정보를 특정 UPF에 설정한다. 이러한 규칙 정보는 그 용도에 따라 PDR(Packet Detection Rule), FAR(Forwarding Action Rule), QER(QoS Enforcement Rule), URR(Usage Reporting Rule)로 구분되며, 패킷이 UPF에 수신되면 이러한 규칙에 대한 처리 동작은 특정한 순서에 따라 순차적으로 수행된다. 일 예로, 패킷의 헤더로부터 패킷 구분자(e.g. 5 tuple)를 획득하고, 이 구분자로 판별한 패킷 처리를 위한 3가지 규칙, FAR, QER, URR의 상태 정보에 따라 처리 동작이 수행된다. FAR은 패킷의 목적지 주소에 따라 전송하는 동작에 대한 규칙, QER은 패킷의 우선순위 또는 처리 속도에 대한 규칙, URR은 패킷의 사용량 및 과금에 관련한 규칙에 대한 상태를 저장하고 있다.

패킷 처리를 오프로딩한다는 의미는, 이 3가지 주요한 규칙들이 스위치 서버에 설정됨을 의미한다. 따라서, 패킷을 서버까지 올려서 처리할 필요 없이, 스위치 서버 내에서 바로 처리됨을 의미한다. 스위치 서버는 3가지 규칙들에 따라 패킷 헤더의 어떤 필드값을 수정하거나 새로운 필드를 추가하고, 이렇게 변경된 패킷 헤더를 원래 패킷 바디와 함께 다음 주소로 전송하는 동작을 수행한다. 스위치 서버는 이러한 동작을 매치(Match)와 액션(action)이라는 방식으로 프로그래밍할 수 있게 한다. 매치 동작에 앞서 패킷의 프로토콜(Ethernet, IPv4, IPv6, UDP, TCP 등)에 따라 필요한 헤더 내 정보 및 메타데이터(metadata)를 추출하는 파싱(parsing)이 요구된다. 파싱된 헤더 내 정보에 기반하여 생성된 키(key)를 기준으로, 검색(look-up)하는 매치 동작이 이어진다. 키 값은 비교 대상이 되는 정보 그 자체일 수도 있고, 용량의 제약을 완화하기 위해 해시(hash) 함수로 만든 요약값일 수 있다. 매치 동작은 수신된 패킷의 IP 주소, 포트 등 튜플(tuple) 정보이거나, 시스템 내재 메타데이터(intrinsic metadata) 정보이거나 또는 사용자-정의 메타데이터(user-defined metadata)가 미리 등록된 Key 값과 일치하는지를 판별하는 동작이다. 키가 판별이 되면, 그 키와 쌍(pair)으로 저장된 값 역시 판별이 된다. 액션 동작은 판별된 값에 대응하는 액션 타입(Action Type)과 액션 데이터(Action Data)에 따른, 해당 패킷에 대한 변경 동작을 포함할 수 있다. 액션 타입은 전달(forward), 드랍(drop), 헤더처리(header processing) 등이며, 헤더 처리는 터널링(tunneling), 마킹(marking), 캡슐화(encapsulation), 분열(fragmentation) 등을 표현하는 객체들(objects)을 포함한다. 추가로 액션 타입에는 사용자 맞춤형도 설정이 가능하다. 따라서, 기본 액션 데이터뿐 아니라 맞춤형으로 사용하는 외부 객체(extern objects)(counters, meters, registers)에 대한 처리 형식이 액션 타입에 설정될 수 있다. 또한, 판별된 액션을 키로 하여 연쇄적인 액션 룩-업이 가능하다. 이렇게 판별된 액션 타입(action type) 및 대상들에 기반하여, 스위치 서버(910)는 역파싱(deparsing)을 위한 패킷 헤더 변경 절차를 수행할 수 있다.

패킷 처리 파이프 라인(913)의 매치 액션 파이프라인(Match Action Pipeline)은 인입과 배출에 하나씩 위치한다. 매치 액션 파이프라인(913)은 인입에서 판별된 액션에 따라 인입에서의 역파싱을 수행하지 않고 넘어가서(bypassing), 배출에서 재차 매치-액션(Match-Action) 절차를 통해 배출을 위한 역파싱을 바로 수행할 수도 있다. 키(Key), 액션(Action), 액션 데이터(Action Data), 외부 객체들(extern objects)은 행과 열로 구성된 테이블(table)로 구현될 수 있다.

스위치 서버(910)는 패킷 처리 파이프 라인(913)과 확장 매치 액션 파이프라인(915, 917)로 구성되어 있는데, 논리적으로는 상기 설명된 Parsing Match Action의 동작을 공통적으로 수행할 수 있다. 다만 실 구현의 차이점으로 인해, 패킷 처리 파이프 라인(913)은 작은 용량의 MAT(Match Action Table)를 가지고, 확장 매치 액션 파이프라인(915)은 큰 용량의 MAT를 가진다. 서버 내 오프로딩 클라이언트부는 패킷 처리 파이프 라인(913)과 확장 매치 액션 파이프라인(915, 917)을 스위치 서버 제어부를 통한 시그널링으로 프로그래밍(생성/조회/수정/삭제)할 수 있다. 추가로 확장 매치 액션 파이프라인(915, 917)은 패킷 자체에 사용자-정의 메타데이터에 따라 프로그래밍을 할 수 있는 기능을 제공한다. 서버 내 오프로딩 클라이언트부 또는 스위치 서버(910) 내 패킷 처리 파이프 라인(913)은 이러한 프로그래밍 기능에 기반하여, 확장 매치 액션 파이프라인(915, 917)으로 전송되는 패킷에 원하는 사용자-정의 메타데이터 값을 추가하여 전송할 수 있다. 이 패킷을 수신한 확장 매치 액션 파이프라인(915, 917)은 파싱 과정에서 판별을 통해 보유한 MAT의 필드에 대한 생성/조회/수정/삭제의 동작을 수행한다. 한편 확장 매치 액션 파이프라인(915, 917)의 MAT에 저장되어 있는 상태 정보를 조회하는 동작은, 사용자-정의 메타데이터에 특정 키('Key')의 값('Value')을 조회하려는 요청을 받으면, 요청을 보낸 소스 주소(source address)를 목적지로 하도록 패킷 헤더를 수정하고, 해당 메타데이터의 내용을 채워서 회송하는 동작을 포함한다.

오프로딩 클라이언트부는 이러한 MAT Key-Value(KV) 열의 상태 생성/조회/수정/삭제 기능을 적절히 활용하여 L4 내지 L7 세션의 상태와 L2 내지 L3 패킷 플로우의 상태를 필요한 때, 필요한 수준으로 일관되게(consistent) 만들어야 한다. 실시간으로 세션과 플로우의 상태를 일치하기 위해서는 상태 변경을 위한 시그널링이 과다해지므로, 본 개시에서는 특정한 조건이 충족될 때, 상태 변경을 수행하는 방식을 제안한다. UPF가 판단하여 오프로딩 클라이언트부에 요청하거나, 또는 UPF의 동작 결과를 관찰하여 오프로딩 클라이언트가 판단함에 의하여, 세션의 상태를 플로우의 상태로 변환하여 스위치 서버의 MAT를 설정하게 된다. 여기서 기술적으로 중요한 요구사항은 세션의 상태 정보와 플로우 상태 정보가 정량적으로 정합이 되면서도, 한 순간에는 한 종류의 상태 정보만이 활성화되어야 한다는 점이다. 즉, 스위치 서버 내 플로우의 KV열이 새로 추가되면, 즉시 인입된 패킷은 스위치 서버에서 처리되면서 관련한 상태(예. counter)는 갱신된다. 반대로 스위치 서버 내 플로우 KV열이 삭제되면, 즉시 인입된 패킷은 스위치에서 UPF로 전송되고, UPF에서 다루는 세션에 대한 상태 정보가, 해당 플로우 KV열의 가장 최신 정보에 기반하여 갱신될 것이 요구된다. 이러한 요구사항을 만족하기 위해, 본 개시의 실시예들은 사용자-정의 메타데이터로 오프로딩 취소 (offloading canceling) 형식을 제안한다.

오프로딩 취소 형식에 따른 스위치 서버(910)의 동작은 메타데이터에 의해 지시되는 KV열의 값을 조회하여 요청한, 오프로딩 클라이언트에 조회한 값을 포함한 패킷을 전송하는 동작과, 조회가 완료된 KV열을 삭제하는 동작을 함께 포함할 수 있다. 스위치 서버 부에서 오프로딩 취소 동작의 실행 시점과 오프로딩 클라이언트를 통해 UPF에서 세션 활성화하는 시점 간 차이가 발생할 수 있기 때문에, 이를 보완하기 위해서 타이머 방식이 이용될 수 있다. 타이머 방식에 따르면, 사용자-정의 메타데이터로 오프로딩 취소를 요청할 때, 메타데이터는 타이머 정보를 포함할 수 있다. 스위치 서버는 KV열의 현재 상태 정보를 오프로딩 클라이언트에게 알려주되 KV열을 삭제하지 않고 대기하다가 타이머가 만료되는 순간에 해당 KV열을 삭제하면서 마지막 상태 정보를 오프로딩 클라이언트에 한 번 더 알려줄 수 있다. UPF는 타이머 기간 동안 세션 활성화를 준비할 수 있다. UPF가 가지고 있는 타이머 완료 시점이 스위치 서버에 지시한 타이머 완료 시점과 거의 동일할 것이므로, 세션과 플로우 간 상태 정보 정합성이 유지될 수 있다.

도 9를 통해 서술된 Hybrid UPF 시스템(900) 구조 하에서, UPF의 기본 기능인 PDR, FER, QER, URR과 부가 기능들 (HTTP Header Enrichment(HHE), URL/SNI filtering, TCP 재전송 패킷 무과금)에 대한 실시예들이 서술된다.

UPF 기본 기능 오프로딩의 일 실시예에 따르면, PDR에서 탐지에 사용하는 5 tuple과 같은 값 또는 PDR과 다른 규칙 간 연결을 위한 PDR 인덱스 값은 스위치 서버의 MAT 내 Key 값으로 설정될 수 있다. FER, QER, URR은 탐지된 패킷에 대한 Action에 해당하므로, 스위치 서버의 MAT 내 Value 값으로 설정될 수 있다.

FER은 주로 다음 목적지 주소(destination address)를 설정하기 때문에, "Forward" 형식은 Action으로 등록되고 이에 필요한 주소 등은 Action Data에 등록된다.

QER은 대역폭 관리를 위한 기능으로서, 하나의 세션에 대한 처리속도(rate)를 bps 단위로 측정하면서, 처리속도가 일정량 이상이라는 조건에 따라 패킷의 우선순위를 조정하는 동작이다. 따라서, 스위치 서버에 오프로딩하는 하나 이상의 플로우마다 사용량 정보를 갱신할 수 있도록 설정되어야 한다. 이 때, 스위치 서버 MAT의 KV열은 하나의 패킷 플로우에 해당하므로, 복수의 KV열들에 저장된 사용량 상태 정보를 하나의 세션에 대해 통합하여 전체 사용량이 구해져야 한다. 이러한 동작을 위해 2가지 방식들이 가능하다.

1) 세션에 해당하는 KV열을 추가하고 ActionAction 기능을 사용하여 플로우 별 사용량 값을 전달하여 합쳐진 세션 사용량 값이 획득된다. 오프로딩 클라이언트는 주기적으로 또는 이벤트에 따라 스위치 서버로부터 이 합쳐진 세션 사용량 값을 조회하여 서버의 QER 상태를 갱신한다.

2) 오프로딩 클라이언트가 주기적으로 스위치 서버 내 KV열의 플로우 별 사용량 정보를 조회하여, 세션별 사용량 정보로 변환하고, 변환된 세션별 사용량 정보를 UPF에 알려준다.

UPF는 최신의 세션별 사용량 정보를 기반으로 처리속도를 구하고, 처리속도 값으로 QER 상태를 갱신한다. 세션에 따라 총 처리속도가 CIR(committed information rate)에 가까워지면, UPF는 그 세션에 대해 오프로딩한 모든 플로우에 대해 오프로딩 취소를 요청하여 회수하여, CIR을 초과하는지를 감시한다. CIR을 초과하여 PIR (Peak Information Rate)에 도달하면, UPF는 이 세션에 설정된 속도 제어(rate control) 정책에 따라 패킷 우선순위를 재조정한다. 다른 실시예에 따르면, 미리 협약된 정책에 따라, 세션 별 CIR/PIR을 플로우 별 CIR/PIR로 분해하여 운용하는 방법이 이용될 수도 있다.

URR은 하나의 세션에 대해 그동안 처리한 패킷의 양을 비트/바이트(bits/bytes) 단위인 사용량으로 저장하면서, 세션 사용량에 대해 과금을 위한 기록(Charging Data Record)을 생성하여 SMF로 송신하는 동작다. 따라서 스위치 서버에 오프로딩되는 하나 이상의 플로우들마다 사용량 정보를 갱신할 수 있도록 설정되어야 한다. 이 때, 스위치 서버 MAT의 KV열은 하나의 패킷 플로우에 해당하므로, 복수의 KV열들에 저장된 사용량 상태 정보를 하나의 세션에 대해 통합하여 전체 사용량을 구할 것이 요구된다. 이러한 동작을 위해 2가지 방식들이 가능하다.

2가지 방식들 중 하나에 따라 UPF는 최신의 세션 별 사용량 정보로 URR 상태를 갱신할 수 있다. 세션에 따라 총 사용량이 허용된 최대 사용량에 가까워지면, UPF는 그 세션에 대해 오프로딩한 모든 플로우에 대해 오프로딩 취소를 요청하여 회수하고, UPF는 갱신된 최신 사용량 정보를 기반으로 URR 동작을 수행하여 SMF가 요구한 다양한 CDR을 생성하여 보고한다.

UPF 부가 기능 오프로딩의 일 실시예에 따르면, HHE(HTTP Header Enrichment)는 HTTP 요청 패킷의 HTTP 헤더에 사업자가 원하는 정보(예를 들어 IMSI(international mobile subscriber identity))를 추가하는 동작을 포함한다. HHE는 업스트림(upstream) 패킷의 TCP 시퀀스 번호(sequence number)를 일정한 규칙으로 변경하고, 다운스트림(downstream) 패킷의 TCP ACK 번호(acknowledge number)를 일정한 규칙으로 변경하는 동작을 포함한다. 오프로딩 클라이언트는 이러한 규칙을 액션(action)으로 기술하여 스위치 서버에 설정할 수 있다. 또한, 오프로딩 클라이언트는 패킷 헤더에 추가할 IMSI 정보를 액션 데이터(action data)로 설정할 수 있다.

UPF 부가 기능 오프로딩의 일 실시예에 따르면, URL(Uniform Resource Locator) 필터링은 포트 번호(D.port = 80/8080) 및 패킷 헤더의 URL 값에 기반하여 패킷을 드랍하는 동작을 포함한다. UPF에서 최초 URL 필터링 대상으로 판별된 세션에 대해서 오프로딩 클라이언트에게 드랍을 요청하면, 오프로딩 클라이언트는 필터링될 URL의 실제 주소에 기반하여, 해당 세션에 속한 플로우의 키(key)에 대한 드랍 규칙을 액션(action)으로 기술하고, 상기 기술된 사항을 스위치 서버에 설정한다.

UPF 부가 기능 오프로딩의 일 실시예에 따르면, SNI(Server Name Indication) 필터링은 포트 번호 (D.port=443) 및 TSL client hello message의 SNI 필드의 URL값을 기반하여 패킷을 드랍하는 동작을 포함한다. UPF에서 최초 SNI 필터링 대상으로 판별된 세션에 대해서 오프로딩 클라이언트에게 드랍을 요청하면, 오프로딩 클라이언트는 필터링될 URL의 실제 주소에 기반하여, 해당 세션에 속한 플로우의 키에 한 드랍 규칙을 액션으로 기술하고, 상기 기술된 사항을 스위치 서버에 설정한다.

UPF 부가 기능 오프로딩의 일 실시예에 따르면, TCP 재전송 패킷 무과금은 이통망 내에서 오류에 의해 재전송된 패킷에 대해서 과금을 위한 기반 사용량에서 제외하는 기능이다. 상기 기능은 다운스트림 패킷에 한해 고려할 필요가 있는데, 업스트림 패킷의 경우, 단말에서 재전송되므로 UPF에서 알 수 없기 때문이다. UPF는 오프로딩 클라이언트를 통해 스위치 서버에 TPC 재전송 패킷 무과금 기능을 활성화할 수 있다. 오프로딩 클라이언트는 상기 기능을 위한 로직(logic)을 액션(action) 설정할 수 있다. 상기 로직에 따르면, UPF는 수신된 패킷의 시퀀스 번호를 '마지막 시퀀스 값'으로 저장하고, 동일한 키의 다음 패킷을 수신하였을 때, 시퀀스가 연속되었는지를 판단하여, 시퀀스가 연속된 경우 이번에 수신한 패킷 시퀀스로 '마지막 시퀀스 값'을 갱신할 수 있다. UPF는, 시퀀스가 연속되지 않은 경우 '마지막 시퀀스 값'을 그대로 유지한다. 시퀀스가 연속되지 않은 경우에는, UPF는 추가로 '마지막 시퀀스 값' 정보와 방금 수신하여 판단에 사용한 패킷의 시퀀스 값을 모두 포함하여 오프로딩 클라이언트를 향해 사용자-정의 메타데이터로 송신한다. 이 메타데이터를 수신한 오프로딩 클라이언트는 두 값들에 기반하여, 패킷 시퀀스 번호의 순차적인 수신 상태 및 특정 시퀀스를 위한 재전송 횟수에 대한 전체 정보를 갱신할 수 있다. UPF는 이 전체 정보를 기반으로 과금 정보를 결정한다.

도 10은 실시예들에 따른 UPF의 플로우 테이블 생성을 위한 시그널링의 예를 도시한다. 클라이언트 장치(1010)와 UPF(1020)간 시그널링이 서술된다. UPF(1020)는 본 개시의 실시예들에 따른 스위치 서버를 포함하는 하이브리드 UPF일수 있다. 신규 패킷 처리(즉, 플로우 엔트리에 해당 패킷의 플로우가 없는 경우)의 일 실시예는 플로우 테이블 생성을 포함할 수 있다.

도 10을 참고하면, 동작(S1001)에서, 클라이언트 장치(1010)는 UPF(1020)에게 동기 패킷을 전송할 수 있다. 동기 패킷은 TCP SYN일 수 있다. UPF(1020)의 CPU는 최초 패킷(즉, TCP SYN)의 목적 포트가 80/8080인 경우, UPF의 PDR/FAR/URR/QER 처리를 수행할 수 있다. 이 때, UPF(1020)의 스위치(예: 도 3의 프로그래밍 가능한 스위치(341))에서 패킷 처리를 위한 플로우 테이블은 생성하지 않을 수 있다.

동작(S1003)에서, UPF(1020)는 클라이언트 장치(1010)에게 동기 패킷의 확인을 전송할 수 있다. 동기 패킷의 확인은 TCP SYN ACK일 수 있다.

동작(S1005)에서, 클라이언트 장치(1010)는 UPF(1020)에게 HTTP 요청 패킷을 수신할 수 있다. 동작(S1007)에서, 클라이언트 장치(1010)는 UPF(1020)에게 다음 HTTP 요청 패킷을 수신할 수 있다. UPF(1020)는 HTTP 요청 패킷을 수신할 수 있다.

일 실시예에 따라, UPF(1020)는 HTTP 요청 패킷에 기반하여 플로우 테이블의 생성 여부를 결정할 수 있다. UPF(1020)는 URL 필터와 매칭 작업(operation)을 통해, 통과되는 플로우에 대한 플로우 테이블을 생성할 수 있다. UPF(1020)는 URL 필터와 매칭 작업(operation)을 통해, 차단되는(blocked) 플로우에 대한 플로우 테이블을 생성하지 않을 수 있다. 차단되어야 할 플로우인 경우, 스위치용 플로우 테이블은 생성되지 않고, 과금에서 제외된다. UPF(1020)의 스위치는 패킷을 수신할 수 있다. 스위치는 IP 패킷에 기반하여 5-tuple 해시 키(hash key)를 생성할 수 있다. 스위치는 키 값에 기반하여, 대응하는 FPGA를 식별할 수 있다. 예를 들어, 4개의 FPGA들이 스위치에 연결된 경우, 스위치는 모듈로 (modulo, MOD) 4 연산을 통해 어떤 FPGA로 해당 패킷을 보낼지 결정할 수 있다. UPF(1020)의 스위치는 식별된 FPGA로 패킷을 전달할 수 있다. FPGA는 차단 플로우의 패킷을 UPF(1020)의 COTS 서버의 CPU로 전달할 수 있다. UPF(1020)의 CPU는 기존 UPF의 PDR/FAR/QER/카운트(count) 처리, GTP 디캡슐화(decapsulation), 또는 DSCP 마킹(marking)을 수행할 수 있다. UPF(1020)는 데이터 네트워크 네임(data network name, DNN)의 데이터 네트워크(data network)에게 처리된 패킷을 전송할 수 있다.

동작(S1009)에서, UPF(1020)는 HTTP 요청에 대한 응답을 클라이언트 장치(1010)에게 전송할 수 있다.

한편, 개별 HTTP 요청에 대응하는 동작을 서술하기 위해, 동작(S1005) 및 동작(S1007)이 함께 도시되었을 뿐, 도 10이 본 개시의 실시예들을 제한하는 것으로 해석되지 않는다. HTTP 요청은 한 회만 전송되거나, 복수 회들에 걸쳐 전달될 수 있다.

상술된 실시예들에서는, 판단 조건에 따라, 스위치 서버가 COTS 서버 UPF에서 처리되던 패킷을 오프로딩하고, 스위치 서버가 상기 패킷을 직접 처리하는 방안이 서술되었다. 일 실시예에 따라, 판단 조건은, 상위 계층(예: L4 내지 L7)의 패킷 처리의 결과에 따른 하위 계층(예: L2 내지 L3)의 패킷 플로우의 패킷 포워딩 및 QoS 정책(policy) 규칙의 생성을 포함할 수 있다. 일 실시예에 따라, 판단 조건은, 상위 계층(예: L4 내지 L7)의 세션의 상태(state)로부터 하위 계층(예: L2 내지 L3)의 패킷 플로우의 상태의 획득을 포함할 수 있다. 일 실시예에 따라, 판단 조건은 상위 계층(예: L4 내지 L7)의 세션의 보안 처리 동작의 완료를 포함할 수 있다. 일 실시예에 따라, 판단 조건은 상위 계층(예: L4 내지 L7)의 세션의 과금 처리 동작의 완료를 포함할 수 있다. 일 실시예에 따라, 판단 조건은 상위 계층(예: L4 내지 L7)의 세션의 상태의 변경에 따른, 해당 세션에 속한 하나 이상의 하위 계층(예: L2 내지 L3)의 패킷들의 상태의 변경을 포함할 수 있다. 일 실시예에 따라, 판단 조건은 복수의 하위 계층(예: L2 내지 L3)의 패킷 플로우들의 상태를 종합하여 판단하는 동작의 완료를 포함할 수 있다. 일 실시예에 따라, 판단 조건은 하위 계층(예: L2 내지 L3)의 패킷 플로우의 오프로딩 타이머 설정의 완료를 포함할 수 있다. 일 실시예에 따라, 판단 조건은 그 외 UPF 서버의 기능에 의해 오프로딩될 하위 계층(예: L2 내지 L3)의 패킷 플로우의 생성/갱신의 결정을 포함할 수 있다.

상술된 실시예들에서는, 판단 조건에 따라 스위치 서버에서 오프로딩하여 처리하는 대신, COTS 서버가 직접 처리하는 방안이 서술되었다. 일 실시예에 따라, 판단 조건은, 유입(ingested)된 하위 계층(예: L2 내지 L3)의 패킷에 대한 판별(match)이 실패할 것을 포함할 수 있다. 일 실시예에 따라, 판단 조건은, 하위 계층(예: L2 내지 L3)의 패킷의 목적지가 UPF 서버 내(예. 특정 파드(pod))일 것을 포함할 수 있다. 일 실시예에 따라, 판단 조건은, 하위 계층(예: L2 내지 L3)의 패킷 플로우에 대한 패킷 포워딩 및 QoS 정책이 만료될 것을 포함할 수 있다. 일 실시예에 따라, 판단 조건은, 상위 계층(예: L4 내지 L7)의 세션의 보안 처리가 요구될 것을 포함할 수 있다. 일 실시예에 따라, 판단 조건은, 상위 계층(예: L4 내지 L7)의 세션의 과금 처리가 요구될 것을 포함할 수 있다. 일 실시예에 따라, 판단 조건은, 하위 계층(예: L2 내지 L3)의 패킷 플로우의 상태 정보가 주어진 조건을 만족할 것을 포함할 수 있다. 일 실시예에 따라, 판단 조건은, 그 외 UPF 서버의 기능에 의해 하위 계층(예: L2 내지 L3)의 패킷 플로우에 대한 오프로딩의 종료/정지를 포함할 수 있다.

상술된 예시들 외에도, 판단 조건은 상술된 예시들 중에서 적어도 하나 혹은 그 조합일 수 있다. 또한, 판단 조건은 상술된 예시들로부터, 동일 또는 유사한 기술적 원리를 통해 변형된 조건을 포함할 수 있다.

도 11은 실시예들에 따른 UPF의 신규 패킷 처리의 예(1100)를 도시한다.

도 11을 참고하면, 신규 패킷 처리의 실시예가 서술된다. 패킷이 수신되면, UPF의 프로그래밍 가능한 스위치는 테이블의 존재 여부를 판단할 수 있다. UPF의 프로그래밍 가능한 스위치는 패킷에 대한 테이블이 확인되지 않으면, 상기 패킷을 CPU로 전달할 수 있다. 여기서, CPU는 UPF의 컨트롤러를 포함하는 CPU를 의미할 수 있다. CPU는 DPI(deep packet inspection)를 수행할 수 있다. CPU는 패킷 플로우의 컨텍스를 처리할 수 있다. CPU는 해당 플로우의 패킷 처리 정보만을 추출(GTP IP, TEID, DSCP, QER required 등)할 수 있다. CPU는 프로그래밍 가능한 스위치에서 사용될 MAT(Match-action table) 형태의 신규 플로우 엔트리를 생성할 수 있다. 플로우 테이블은 세션, 플로우, GTP, QCI(QoS Class Identifier) 정보 등 패킷 처리에 필요한 정보가 포함될 수 있다. 일 실시예에 따라, UL 패킷을 위한 매치 룰(match rule)로, TEID가 사용될 수 있다.

첫 번째 패킷에 대한 과금 및 사용량은 CPU가 직접 기록할 수 있다. CPU는 생성된 플로우 엔트리를 프로그래밍 가능한 스위치에게 설정할 수 있다. CPU는 P4Runtime 또는 BRI(barefoot runtime interface)를 통해, 프로그래밍 가능한 스위치에 MAT을 추가할 수 있다. CPU 테이블과 프로그래밍 가능한 스위치의 테이블이 동기화될 수 있다. 이후, 프로그래밍 가능한 스위치가 패킷을 수신하면, 프로그래밍 가능한 스위치는, 패킷 처리할 수 있다. 프로그래밍 가능한 스위치는, 처리된 패킷에 대한 패킷 카운트/미터를 플로우 엔트리에 기록할 수 있다. CPU는 플로우 엔트리의 카운트/미터 정보를 UE IP를 포함하여 주기적으로 요청할 수 있다. CPU는 수신된 정보를 첫번째 패킷 정보와 합쳐 최종 값을 계산할 수 있다. 일 예로, CounterData P4Runtime message 또는 BRI의 bf_switch_counter_get API가 이용될 수 있다.

UPF의 CPU는 컨트롤러로서, 현재 UPF의 메모리 구조를 그대로 이용할 수 있다. CPU는 스위치-칩을 위한 매치-액션 플로우 엔트리를 추가적으로 생성할 수 있다. CPU는 패킷에 대한 과금 및 사용량 처리를 수행할 수 있다. UPF의 프로그래밍 가능한 스위치는, GTP 캡슐화를 수행할 수 있다. UPF의 프로그래밍 가능한 스위치는, GTP 디캡슐화를 수행할 수 있다. UPF의 프로그래밍 가능한 스위치는, DSCP 마킹을 수행할 수 있다. UPF의 프로그래밍 가능한 스위치는, 패킷 측정(예: 패킷 카운트/미터(count/meter))를 수행할 수 있다.

도 12는 실시예들에 따른 UPF의 QER(QoS(quality of service) Enforcement Rule) 처리의 예(1200)를 도시한다.

도 12를 참고하면, 신규 UE가 망에 접속하는 경우(즉, UE attach), UE 별 QoS는 미터 테이블(meter table)에 추가될 수 있다. QoS의 매핑을 위해, UE 별 미터 인덱스가 이용될 수 있다. CPU는 생성된 테이블을 UPF의 프로그래밍 가능한 스위치에게 설정할 수 있다. 예를 들어, CPU는 생성된 테이블을P4Runtime으로 프로그래밍 가능한 스위치에게 추가할 수 있다. 플로우 별 QoS는, 신규 플로우 패킷이 수신되면, CPU는 플로우 테이블을 생성할 수 있다. 이 때, CPU는 QER을 참조하여, QoS 설정을 수행할 수 있다. CPU는 액션 데이터에 UE 별 미터 인덱스에 기반하여, QoS를 설정할 수 있다. CPU는 생성된 MAT 엔트리와 미터 플로우 엔트리를 프로그래밍 가능한 스위치에게 설정할 수 있다. 예를 들어, CPU는 P4Runtime 또는 BRI(Barefoot Runtime Interface)을 이용해서 생성된 MAT 엔트리와 미터 플로우 엔트리를 프로그래밍 가능한 스위치에게 추가할 수 있다. 프로그래밍 가능한 스위치는 우선 플로우 레벨에서, 패킷 및 QoS 처리 후, 미터 테이블을 참조하여 UE 별 QoS 처리를 수행할 수 있다. 즉, 프로그래밍 가능한 스위치는 파이프라인 처리를 수행할 수 있다.

본 개시의 일 실시예에 따라, UPF의 스위치 서버는 UDP 플로우와 TCP 플로우를 구별할 수 있다. 이하, 도 13a 내지 도 14를 통해, UDP 플로우와 TCP 플로우의 처리 방안이 서술된다.

도 13a 및 도 13b는 실시예들에 따른 UPF의 UDP(user datagram protocol) 처리의 예를 도시한다. UDP 처리를 설명하기 위하여, 상향링크 패킷이 예로 서술된다.

도 13a에서는 스위치 서버(110) 및 상용 서버(120)의 신규 플로우에 대한 패킷 처리 동작(1300)이 서술된다. 도 7a에서 언급된 동작들은 동일 또는 유사한 방식으로 도 13a에서도 적용될 수 있다.

도 13a를 참고하면, 스위치 서버(110)는 UDP 패킷을 수신할 수 있다. 수신된 패킷은 첫번째 패킷, 즉 신규 패킷일 수 있다. 스위치 서버(110)는 첫 번째 패킷을 상용 서버(120)에게 전달할 수 있다.

상용 서버(120)는 메타데이터를 생성할 수 있다. 메타데이터는 상용 서버(120)는 해당 패킷의 플로우의 액션 및 액션 데이터를 포함할 수 있다. 상용 서버(120)는 메타데이터를 스위치 서버(110)에게 전달할 수 있다. 일 실시예에 따라, 메타데이터는 TEID를 포함할 수 있다. TEID는 스위치 서버(110)에서의 패킷 처리를 위해 이용될 수 있다. 일 실시예에 따라, 메타데이터는 DSCP를 포함할 수 있다. TEID는 스위치 서버(110)에서의 패킷 처리를 위해 이용될 수 있다. 일 실시예에 따라, 메타데이터는 엔트리 ID를 포함할 수 있다. 엔트리 ID는 UE ID 및 PDR에 기반하여 결정될 수 있다. PDR 별 카운트를 위해 엔트리 ID가 이용될 수 있다. 처리된 패킷에 대한 과금 및 사용량 정보는 상용 서버(120)에서 갱신될 수 있다.

스위치 서버(110)는 메타 데이터에 기반하여 플로우 엔트리를 생성할 수 있다. 서버(110)는 플로우 엔트리에 기반하여, 패킷을 처리할 수 있다. 스위치 서버(110)는 수신된 패킷에서 GTP 헤더 및 Outer IP 헤더를 제거할 수 있다. 스위치 서버(110)는 IP 패킷을 외부로 전달할 수 있다.

도 13b에서는 스위치 서버(110) 및 상용 서버(120)의 등록된 플로우에 대한 패킷 처리 동작(1350)이 서술된다. 도 7b에서 언급된 동작들은 동일 또는 유사한 방식으로 도 13b에서도 적용될 수 있다.

도 13b를 참고하면, 스위치 서버(110)는 UDP 패킷을 수신할 수 있다. 수신된 패킷은 두 번째 패킷 또는 두 번째 이후 패킷일 수 있다. 스위치 서버(110)는 도 13a에서 생성된 플로우 엔트리를 참조할 수 있다. 스위치 서버(110)는 패킷의 수신에 대응하여, 플로우 엔트리를 참조할 수 있다. 스위치 서버(110)는 플로우 엔트리에 기반하여 수신된 패킷을 처리할 수 있다. 스위치 서버(110)는 수신된 패킷에서 GTP 헤더 및 Outer IP 헤더를 제거할 수 있다. 스위치 서버(110)는 IP 패킷을 외부로 전달할 수 있다.

일 실시예에 따라, 스위치 서버(110)는 처리된 패킷의 사용량을 측정할 수 있다. 스위치 서버(110)는 패킷 카운트를 수행할 수 있다. 스위치 서버(110)의 CPU(예: 도 2의 CPU(215))는 카운트 값을 읽을 수 있다. 예를 들어, 스위치 서버(110)의 CPU는 주기적으로(예: 1초)마다 플로우 테이블의 카운트 값을 수집할 수 있다. 스위치 서버(110)의 CPU는 사용자 별, PDR 별 사용량 카운트를 취합할 수 있다. 스위치 서버(110)는 취합된 결과를 상용 서버(120)에게 전달할 수 있다.

도 14는 실시예들에 따른 UPF의 TCP(Transmission Control Protocol) 처리의 예를 도시한다. TCP 처리를 설명하기 위하여, 상향링크 패킷이 예로 서술된다.

도 14를 참고하면, 스위치 서버(110)는 TCP 패킷을 수신할 수 있다. 스위치 서버(110)는 파서를 통해, 패킷 필터링을 수행할 수 있다. 스위치 서버(110)는 수신된 패킷이 TCP 패킷임을 식별하는 것에 기반하여, TCP 패킷을 상용 서버(120)에게 바로 전달할 수 있다. 스위치 서버(110)의 스위치는 FPGA를 거치지 않고, 직접 상용 서버(120)에게 TCP 패킷을 전송할 수 있다. 상용 서버(120)는 수신된 패킷에서 GTP 헤더 및 Outer IP 헤더를 제거할 수 있다. 상용 서버(120)는 IP 패킷을 스위치 서버(110)에게 제공할 수 있다. 스위치 서버(110)는 IP 패킷을 외부로 전달할 수 있다.

도 14에서는 TCP 플로우 패킷의 처리가 항상 상용 서버(120)에 의해 수행되는 것으로 도시되었으나, 다른 일부 실시예에 따라, TCP 플로우 패킷에 대한 오프로딩이 스위치 서버(110)에게 설정될 수도 있다.

도 13a 내지 도 14에서는 TCP 플로우와 UDP 플로우의 처리가 서술되었다. 과금 처리를 위해, 상용 서버(120)는 TCP 플로우의 사용량과 UDP 플로우의 사용량을 합칠 수 있다. 상용 서버(120)는 합쳐진 사용량을 과금 서버에게 제공할 수 있다. 사용량이 임계값에 가까워지면, 상용 서버(120)는 잔여 사용량에 대해서는 오프로딩이 이용되지 않도록, 스위치 서버(110)를 재설정할 수 있다. 예를 들어, 상용 서버(120)는 관련 UDP 플로우의 엔트리를 스위치 서버에서 삭제할 수 있다. 이후, 잔여 사용량에 대한 패킷은 상용 서버(120)에서 처리되거나 드랍될 수 있다. 또한, 상용 서버(120)는 이후, 신규 플로우 패킷의 생성은 거절할 수 있다.

일 실시예에 따라, 상기 플로우 테이블은 엔트리 ID(identifier), 해시 키(hash key), 액션(action), 액션 데이터(action data), 사용량을 포함할 수 있다. 상기 엔트리 ID는 UE(user equipment) ID 및 PDR(packet detection rule)와 연관될 수 있다.

일 실시예에 따라, 상기 플로우 테이블에 대한 정보는 엔트리 ID(identifier), TEID(tunnel endpoint identifier), DSCP(differentiated service code point) 값을 포함할 수 있다.

일 실시예에 따라, 상기 데이터 패킷이 하향링크 패킷인 경우, 상기 데이터 패킷의 처리는 GTP(GPRS(General Packet Radio Service) tunnelling protocol) 캡슐화 및 DSCP(differentiated service code point) 마킹을 포함할 수 있다. 상기 데이터 패킷이 상향링크 패킷인 경우, 상기 데이터 패킷의 처리는 GTP 디캡슐화 및 DSCP 마킹을 포함할 수 있다.

일 실시예에 따라, 상기 플로우 테이블에 대한 정보는, 이전 패킷의 헤더가 지정된 범위의 URL(uniform resource indicator)를 갖는 경우, 상기 오프로딩 서버로부터 수신될 수 있다. 상기 플로우 테이블에 대한 정보는, 상기 지정된 범위의 URL의 목적(destination) IP(internet protocol) 주소 정보를 포함할 수 있다.

일 실시예에 따라, 상기 플로우 테이블은 엔트리 ID(identifier), 해시 키(hash key), 액션(action), 액션 데이터(action data), 사용량을 포함할 수 있다. 상기 엔트리 ID는 UE(user equipment) ID 및 PDR(packet detection rule)에 기반하여 결정될 수 있다.

일 실시예에 따라, 상기 플로우 테이블에 대한 정보는, 이전 패킷의 헤더가 지정된 범위의 URL(uniform resource indicator)를 갖는 경우, 상기 스위치 서버에게 전송될 수 있다. 상기 플로우 테이블에 대한 정보는, 상기 지정된 범위의 URL의 목적(destination) IP(internet protocol) 주소 정보를 포함할 수 있다.

본 개시의 실시예들은, 스위치-칩의 적은 메모리를 보완하기 위하여, 스위치-칩에 하나 이상의 FPGA들이 결합되는 실시예들이 서술되었다. 그러나, 본 개시의 모든 실시예들이 이러한 구조에 의해 제한 해석되지 않는다. 적은 메모리를 보완하기 위해, FPGA들 뿐만 아니라 독립된 칩들이 스위치-칩과 결합되는, 스위치-서버 또한 본 개시의 일 실시예로써 이해될 수 있다. 또한, 다른 일 실시예에 따라, 스위치 서버는 스위치-칩의 메모리를 통해 FPGA 이용 없이, 도 6 내지 도 14를 통해 서술된 COTS 서버와의 동작을 수행할 수도 있다.

본 개시의 실시예들은, 대용량 패킷 처리 시스템을 구현하는데 있어 비용, 서버의 수, 전력을 줄이면서 동시에, 줄어든 서버로 인해 보다 쉬운 네트워크 운영을 지원할 수 있다.

본 개시의 청구항 또는 명세서에 기재된 실시예들에 따른 방법들은 하드웨어, 소프트웨어, 또는 하드웨어와 소프트웨어의 조합의 형태로 구현될(implemented) 수 있다.

소프트웨어로 구현하는 경우, 하나 이상의 프로그램(소프트웨어 모듈)을 저장하는 컴퓨터 판독 가능 저장 매체가 제공될 수 있다. 컴퓨터 판독 가능 저장 매체에 저장되는 하나 이상의 프로그램은, 전자 장치(device) 내의 하나 이상의 프로세서에 의해 실행 가능하도록 구성된다(configured for execution). 하나 이상의 프로그램은, 전자 장치로 하여금 본 개시의 청구항 또는 명세서에 기재된 실시예들에 따른 방법들을 실행하게 하는 명령어(instructions)를 포함한다.

이러한 프로그램(소프트웨어 모듈, 소프트웨어)은 랜덤 액세스 메모리 (random access memory), 플래시(flash) 메모리를 포함하는 불휘발성(non-volatile) 메모리, 롬(read only memory, ROM), 전기적 삭제가능 프로그램가능 롬(electrically erasable programmable read only memory, EEPROM), 자기 디스크 저장 장치(magnetic disc storage device), 컴팩트 디스크 롬(compact disc-ROM, CD-ROM), 디지털 다목적 디스크(digital versatile discs, DVDs) 또는 다른 형태의 광학 저장 장치, 마그네틱 카세트(magnetic cassette)에 저장될 수 있다. 또는, 이들의 일부 또는 전부의 조합으로 구성된 메모리에 저장될 수 있다. 또한, 각각의 구성 메모리는 다수 개 포함될 수도 있다.

또한, 프로그램은 인터넷(Internet), 인트라넷(Intranet), LAN(local area network), WAN(wide area network), 또는 SAN(storage area network)과 같은 통신 네트워크, 또는 이들의 조합으로 구성된 통신 네트워크를 통하여 접근(access)할 수 있는 부착 가능한(attachable) 저장 장치(storage device)에 저장될 수 있다. 이러한 저장 장치는 외부 포트를 통하여 본 개시의 실시예를 수행하는 장치에 접속할 수 있다. 또한, 통신 네트워크상의 별도의 저장장치가 본 개시의 실시예를 수행하는 장치에 접속할 수도 있다.

상술한 본 개시의 구체적인 실시예들에서, 개시에 포함되는 구성 요소는 제시된 구체적인 실시예에 따라 단수 또는 복수로 표현되었다. 그러나, 단수 또는 복수의 표현은 설명의 편의를 위해 제시한 상황에 적합하게 선택된 것으로서, 본 개시가 단수 또는 복수의 구성 요소에 제한되는 것은 아니며, 복수로 표현된 구성 요소라 하더라도 단수로 구성되거나, 단수로 표현된 구성 요소라 하더라도 복수로 구성될 수 있다.

한편 본 개시의 상세한 설명에서는 구체적인 실시예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다.

Claims

통신 시스템에서, 프로그래밍 가능한 스위치(programable switch) 및 하나 이상의 FPGA(field programmable gate array)들을 포함하는 스위치 서버에 수행되는 방법에 있어서,
오프로딩 서버로부터 플로우 테이블에 대한 정보를 수신하는 동작과,
데이터 패킷을 수신하는 동작과,
상기 데이터 패킷에 대응하는 FPGA를 식별하는 동작과,
상기 데이터 패킷이 상기 FPGA의 플로우 테이블(flow table)의 플로우 엔트리(flow entry)에 매칭되는지 여부를 식별하는 동작과,
상기 데이터 패킷이 상기 플로우 테이블의 플로우 엔트리(flow entry)에 매칭되는 경우, 상기 플로우 엔트리에 기반하여 상기 데이터 패킷을 처리하고, 상기 처리된 데이터 패킷을 전송하는 동작과,
상기 데이터 패킷이 상기 플로우 테이블의 엔트리에 매칭되지 않은 경우, 상기 데이터 패킷을 상기 오프로딩 서버에게 제공하는 동작을 포함하는 방법.
청구항 1에서,
상기 플로우 테이블은 엔트리 ID(identifier), 해시 키(hash key), 액션(action), 액션 데이터(action data), 사용량을 포함하고,
상기 엔트리 ID는 UE(user equipment) ID 및 PDR(packet detection rule)와 연관되는 방법.
청구항 1에서,
상기 플로우 테이블에 대한 정보는 엔트리 ID(identifier), TEID(tunnel endpoint identifier), DSCP(differentiated service code point) 값을 포함하는 방법.
청구항 1에서,
상기 데이터 패킷이 하향링크 패킷인 경우, 상기 데이터 패킷의 처리는 GTP(GPRS(General Packet Radio Service) tunnelling protocol) 캡슐화 및 DSCP(differentiated service code point) 마킹을 포함하고,
상기 데이터 패킷이 상향링크 패킷인 경우, 상기 데이터 패킷의 처리는 GTP 디캡슐화 및 DSCP 마킹을 포함하는 방법.
청구항 1에서,
상기 플로우 테이블에 대한 정보는, 이전 패킷의 헤더가 지정된 범위의 URL(uniform resource indicator)를 갖는 경우, 상기 오프로딩 서버로부터 수신되고,
상기 플로우 테이블에 대한 정보는, 상기 지정된 범위의 URL의 목적(destination) IP(internet protocol) 주소 정보를 포함하는 방법.
통신 시스템에서, 오프로딩 서버에 수행되는 방법에 있어서,
프로그래밍 가능한 스위치(programable switch) 및 하나 이상의 FPGA(field programmable gate array)들을 포함하는 스위치 서버로부터 데이터 패킷을 수신하는 동작과,
상기 데이터 패킷을 처리하는 동작과,
상기 데이터 패킷에 대한 플로우 테이블(flow table)을 생성할 지 여부를 결정하는 동작과,
상기 데이터 패킷에 대한 상기 플로우 테이블을 생성하는 것으로 결정된 경우, 상기 플로우 테이블에 대한 정보 및 상기 처리된 패킷을 상기 스위치 서버에게 제공하는 동작과,
상기 데이터 패킷에 대한 상기 플로우 테이블을 생성하지 않는 것으로 결정된 경우, 상기 플로우 테이블에 대한 정보 없이 상기 처리된 패킷을 상기 스위치 서버에게 제공하는 동작을 포함하는 방법.
청구항 6에서,
상기 플로우 테이블은 엔트리 ID(identifier), 해시 키(hash key), 액션(action), 액션 데이터(action data), 사용량을 포함하고,
상기 엔트리 ID는 UE(user equipment) ID 및 PDR(packet detection rule)에 기반하여 결정되는 방법.
청구항 6에서,
상기 플로우 테이블에 대한 정보는 엔트리 ID(identifier), TEID(tunnel endpoint identifier), DSCP(differentiated service code point) 값을 포함하는 방법.
청구항 6에서,
상기 데이터 패킷이 하향링크 패킷인 경우, 상기 데이터 패킷의 처리는 GTP(GPRS(General Packet Radio Service) tunnelling protocol) 캡슐화 및 DSCP(differentiated service code point) 마킹을 포함하고,
상기 데이터 패킷이 상향링크 패킷인 경우, 상기 데이터 패킷의 처리는 GTP 디캡슐화 및 DSCP 마킹을 포함하는 방법.
청구항 6에서,
상기 플로우 테이블에 대한 정보는, 이전 패킷의 헤더가 지정된 범위의 URL(uniform resource indicator)를 갖는 경우, 상기 스위치 서버에게 전송되고,
상기 플로우 테이블에 대한 정보는, 상기 지정된 범위의 URL의 목적(destination) IP(internet protocol) 주소 정보를 포함하는 방법.
통신 시스템에서, 스위치 서버에 있어서,
프로세서;
프로그래밍 가능한 스위치(programable switch); 및
하나 이상의 FPGA(field programmable gate array)들을 포함하고,
상기 프로그래밍 가능한 스위치는
오프로딩 서버로부터 플로우 테이블에 대한 정보를 수신하고,
데이터 패킷을 수신하고,
상기 데이터 패킷에 대응하는 FPGA를 식별하고,
상기 데이터 패킷이 상기 FPGA의 플로우 테이블(flow table)의 플로우 엔트리(flow entry)에 매칭되는지 여부를 식별하고,
상기 데이터 패킷이 상기 플로우 테이블의 플로우 엔트리(flow entry)에 매칭되는 경우, 상기 플로우 엔트리에 기반하여 상기 데이터 패킷을 처리하고, 상기 처리된 데이터 패킷을 전송하고,
상기 데이터 패킷이 상기 플로우 테이블의 엔트리에 매칭되지 않은 경우, 상기 데이터 패킷을 상기 오프로딩 서버에게 제공하도록 구성되는 스위치 서버.
청구항 11에서,
상기 플로우 테이블은 엔트리 ID(identifier), 해시 키(hash key), 액션(action), 액션 데이터(action data), 사용량을 포함하고,
상기 엔트리 ID는 UE(user equipment) ID 및 PDR(packet detection rule)와 연관되는 스위치 서버.
청구항 11에서,
상기 플로우 테이블에 대한 정보는 엔트리 ID(identifier), TEID(tunnel endpoint identifier), DSCP(differentiated service code point) 값을 포함하는 스위치 서버.
청구항 11에서,
상기 데이터 패킷이 하향링크 패킷인 경우, 상기 데이터 패킷의 처리는 GTP(GPRS(General Packet Radio Service) tunnelling protocol) 캡슐화 및 DSCP(differentiated service code point) 마킹을 포함하고,
상기 데이터 패킷이 상향링크 패킷인 경우, 상기 데이터 패킷의 처리는 GTP 디캡슐화 및 DSCP 마킹을 포함하는 스위치 서버.
청구항 11에서,
상기 플로우 테이블에 대한 정보는, 이전 패킷의 헤더가 지정된 범위의 URL(uniform resource indicator)를 갖는 경우, 상기 오프로딩 서버로부터 수신되고,
상기 플로우 테이블에 대한 정보는, 상기 지정된 범위의 URL의 목적(destination) IP(internet protocol) 주소 정보를 포함하는 스위치 서버.
통신 시스템에서, 오프로딩 서버에 있어서,
적어도 하나의 송수신기; 및
적어도 하나의 프로세서를 포함하고,
상기 적어도 하나의 프로세서는,
프로그래밍 가능한 스위치(programable switch) 및 하나 이상의 FPGA(field programmable gate array)들을 포함하는 스위치 서버로부터 데이터 패킷을 수신하고,
상기 데이터 패킷을 처리하고,
상기 데이터 패킷에 대한 플로우 테이블(flow table)을 생성할 지 여부를 결정하고,
상기 데이터 패킷에 대한 상기 플로우 테이블을 생성하는 것으로 결정된 경우, 상기 플로우 테이블에 대한 정보 및 상기 처리된 패킷을 상기 스위치 서버에게 제공하고,
상기 데이터 패킷에 대한 상기 플로우 테이블을 생성하지 않는 것으로 결정된 경우, 상기 플로우 테이블에 대한 정보 없이 상기 처리된 패킷을 상기 스위치 서버에게 제공하도록 구성되는 오프로딩 서버.
청구항 16에서,
상기 플로우 테이블은 엔트리 ID(identifier), 해시 키(hash key), 액션(action), 액션 데이터(action data), 사용량을 포함하고,
상기 엔트리 ID는 UE(user equipment) ID 및 PDR(packet detection rule)에 기반하여 결정되는 오프로딩 서버.
청구항 16에서,
상기 플로우 테이블에 대한 정보는 엔트리 ID(identifier), TEID(tunnel endpoint identifier), DSCP(differentiated service code point) 값을 포함하는 오프로딩 서버.
청구항 16에서,
상기 데이터 패킷이 하향링크 패킷인 경우, 상기 데이터 패킷의 처리는 GTP(GPRS(General Packet Radio Service) tunnelling protocol) 캡슐화 및 DSCP(differentiated service code point) 마킹을 포함하고,
상기 데이터 패킷이 상향링크 패킷인 경우, 상기 데이터 패킷의 처리는 GTP 디캡슐화 및 DSCP 마킹을 포함하는 오프로딩 서버.
청구항 16에서,
상기 플로우 테이블에 대한 정보는, 이전 패킷의 헤더가 지정된 범위의 URL(uniform resource indicator)를 갖는 경우, 상기 스위치 서버에게 전송되고,
상기 플로우 테이블에 대한 정보는, 상기 지정된 범위의 URL의 목적(destination) IP(internet protocol) 주소 정보를 포함하는 오프로딩 서버.