KR20210029834A - 멀티 코어 프로세서에서 연결 및 CAA(clat aware affinity) 기반 스케줄링 설정을 위한 방법 및 장치 - Google Patents

멀티 코어 프로세서에서 연결 및 CAA(clat aware affinity) 기반 스케줄링 설정을 위한 방법 및 장치 Download PDF

Info

Publication number
KR20210029834A
KR20210029834A KR1020217006543A KR20217006543A KR20210029834A KR 20210029834 A KR20210029834 A KR 20210029834A KR 1020217006543 A KR1020217006543 A KR 1020217006543A KR 20217006543 A KR20217006543 A KR 20217006543A KR 20210029834 A KR20210029834 A KR 20210029834A
Authority
KR
South Korea
Prior art keywords
packet
caa
ipv6
ipv4
server
Prior art date
Application number
KR1020217006543A
Other languages
English (en)
Inventor
차야 바르티
마드한 라즈 카나가라티남
로히트 산카르 린가파
지얀찬다니 몬티
한재광
카르시케얀 에이
이미림
산데시 쿠마르 스리바스타바
오왕근
Original Assignee
삼성전자주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자주식회사 filed Critical 삼성전자주식회사
Publication of KR20210029834A publication Critical patent/KR20210029834A/ko

Links

Images

Classifications

    • H04L67/32
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/167Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1008Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/50Queue scheduling
    • H04L47/62Queue scheduling characterised by scheduling criteria
    • H04L47/625Queue scheduling characterised by scheduling criteria for service slots or service orders
    • H04L47/6275Queue scheduling characterised by scheduling criteria for service slots or service orders based on priority
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/251Translation of Internet protocol [IP] addresses between different IP versions
    • H04L61/305
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • H04L61/4505Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/30Types of network names
    • H04L2101/35Types of network names containing special prefixes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1029Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers using data related to the state of servers by a load balancer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

본 개시의 실시 예들은, 멀티 코어 프로세서(120)를 포함하는 단말(user equipment, UE, 100)에 의해 연결 및 CAA(CLAT aware affinity, customer side translator aware affinity, 고객측 변환기 aware affinity) 기반 스케줄링을 설정하는 방법을 제공할 수 있다. 상기 방법은, CAA 스케줄러(180)가, 상기 단말(UE, 100)에서 패킷을 수신하는 과정 및 상기 패킷의 경로 특성을 결정하는 과정을 포함할 수 있다. 또한, 상기 방법은, 상기 CAA 스케줄러(180)가, 상기 패킷의 경로 특성에 기반하여 IPv4 연결 또는 IPv6 연결 중에서 적어도 하나를 결정하는 과정 및 상기 결정된 IPv4 연결 또는 IPv6 연결 중에서 적어도 하나에 기반하여 IPv4 서버 및 IPv6 서버 중에서 적어도 하나에 대한 연결을 설정하는 과정을 포함할 수 있다. 또한, 상기 방법은, 상기 CAA 스케줄러(180)가, 상기 패킷을 적어도 하나의 클래스로 분류하는 과정 및 상기 적어도 하나의 클래스에 기반하여 상기 멀티 코어 프로세서(120)의 적어도 하나의 코어상의 상기 패킷을 스케줄링하는 과정을 더 포함할 수 있다.

Description

멀티 코어 프로세서에서 연결 및 CAA(clat aware affinity) 기반 스케줄링 설정을 위한 방법 및 장치
본 개시의 실시 예들은 장치 관리에 관한 것으로, 특히 멀티 코어 프로세서에서 연결 및 CAA(clat aware affinity) 기반 스케줄링을 설정하기 위한 방법 및 단말(user equipment, UE)에 관한 것이다. 본 출원은 2018년 8월 3일에 출원된 인도 출원번호 201841029324에 기반하여 우선권을 주장하며, 그 개시 내용은 여기에 참조로 포함된다.
일반적으로 데이터와 속도에 대한 큰 수요는 특히 차세대 모바일 네트워크의 출현과 함께 모바일 사업자의 주요 초점이다. IPv6 배포는 전 세계적으로 9,000,000개 이상의 도메인 이름과 IPv6 연결을 광고하는 모든 네트워크의 23%로 증가하고 있다. 그러나 IPv4에서 IPv6로의 전환은 점진적이다. 현재 IPv6에서 IPv4로의 전환을 용이하게 하는 수많은 기술이 있으며, 이중 스택, 터널링 및 주소 변환과 같은 IPv4 및 IPv6 엔티티의 공존을 용이하게 한다.
그러나 CLAT(customer side translator, 고객측 변환기)에서 IPv4와 IPv6가 모두 공존하는 경우에 직면한 주요 문제 중에서 하나는 도 1에서 보는 바와 같이 데이터 패킷의 이중 처리다. IPv4 데이터는 단말(user equipment, UE, 100)에서 실행되는 CLAT로 전송되어 데이터 패킷의 주소를 IPv4에서 합성된 IPv6로 변환하고 합성된 IPv6 주소 데이터 패킷을 모바일 인터페이스(예: RMNET)를 사용하여 네트워크의 PLAT(platform side translator, 플랫폼측 변환기)서버로 전송한다. 도 1을 참조하면, 데이터는 다이렉트 IPv4 연결 또는 다이렉트 IPv6 연결에 비해 두 배로 처리된다. 따라서, 종래의 메커니즘은 멀티 레벨 데이터 처리, 이중 주소 변환 및 CPU/시스템 비인식 스케줄링으로 인해 단말(UE, 100)의 처리량에 영향을 미친다.
위의 정보는 독자가 본 발명을 이해하는 데 도움이 되는 배경 정보로만 제공된다. 출원인은 본 출원과 관련하여 상기 중에서 어느 하나가 선행 기술로 적용될 수 있는지 여부에 대해 어떠한 결정도 내리지 않으며 주장하지도 않는다.
본 개시의 실시 예들의 주요 목적은 멀티 코어 프로세서에서 연결 및 CAA(clat aware affinity) 기반 스케줄링을 설정하는 방법을 제공하는 것이다.
본 개시의 실시 예들의 다른 목적은 패킷의 경로 특성을 결정하고 IPv4 서버 및 IPv6 서버 중에서 적어도 하나에 대한 연결을 설정하는 것이다.
본 개시의 실시 예들의 다른 목적은 패킷의 IP 헤더에 기반하여 패킷을 클래스 A, 클래스 B 및 클래스 C 중에서 적어도 하나의 클래스로 분류하는 것이다.
본 개시의 실시 예들의 다른 목적은 패킷이 클래스 A, 클래스 B 및 클래스 C 중에서 하나로 분류되는지 여부를 결정하고; 및 높은 우선 순위 큐(queue), 중간 우선 순위 큐 및 낮은 우선 순위 큐 중에서 하나를 생성하고 패킷을 스케줄링한다.
본 개시의 실시 예들의 다른 목적은 적어도 하나의 클래스에 기반하여 멀티 코어 프로세서의 적어도 하나의 코어상에서 패킷을 스케줄링하는 것이다.
따라서, 본 개시의 실시 예들은, 멀티 코어 프로세서(120)를 포함하는 단말(user equipment, UE, 100)에 의해 연결 및 CAA(CLAT aware affinity, customer side translator aware affinity, 고객측 변환기 aware affinity) 기반 스케줄링을 설정하는 방법을 제공할 수 있다. 상기 방법은, CAA 스케줄러(180)가, 상기 단말(UE, 100)에서 패킷을 수신하는 과정 및 상기 패킷의 경로 특성을 결정하는 과정을 포함할 수 있다. 또한, 상기 방법은, 상기 CAA 스케줄러(180)가, 상기 패킷의 경로 특성에 기반하여 IPv4 연결 또는 IPv6 연결 중에서 적어도 하나를 결정하는 과정 및 상기 결정된 IPv4 연결 또는 IPv6 연결 중에서 적어도 하나에 기반하여 IPv4 서버 및 IPv6 서버 중에서 적어도 하나에 대한 연결을 설정하는 과정을 포함할 수 있다. 또한, 상기 방법은, 상기 CAA 스케줄러(180)가, 상기 패킷을 적어도 하나의 클래스로 분류하는 과정 및 상기 적어도 하나의 클래스에 기반하여 상기 멀티 코어 프로세서(120)의 적어도 하나의 코어상의 상기 패킷을 스케줄링하는 과정을 더 포함할 수 있다.
따라서, 본 개시의 실시 예들은, 연결 및 CAA(CLAT aware affinity, customer side translator aware affinity, 고객측 변환기 aware affinity) 기반 스케줄링 설정을 위한 단말(user equipment, UE, 100)을 제공할 수 있다. 상기 단말(UE, 100)은, 메모리, 멀티 코어 프로세서(120), 멀티 코어 프로세서(120) 및 메모리에 연결된 CAA 스케줄러(180)를 포함할 수 있다. 상기 CAA 스케줄러(180)는, 상기 단말(UE, 100)에서 패킷을 수신 및 상기 패킷의 경로 특성을 결정하도록 구성될 수 있다. 또한, 상기 CAA 스케줄러(180)는, 상기 패킷의 경로 특성에 기반하여 IPv4 연결 또는 IPv6 연결 중에서 적어도 하나를 결정 및 상기 결정된 IPv4 연결 또는 IPv6 연결 중에서 적어도 하나에 기반하여 IPv4 서버 및 IPv6 서버 중에서 적어도 하나에 대한 연결을 설정하도록 구성될 수 있다. 또한, 상기 CAA 스케줄러(180)는, 상기 패킷을 적어도 하나의 클래스로 분류 및 상기 적어도 하나의 클래스에 기반하여 상기 멀티 코어 프로세서(120)의 적어도 하나의 코어상의 상기 패킷을 스케줄링하도록 구성될 수 있다.
본 개시의 실시 예들의 이들 및 다른 측면들은 다음의 설명 및 첨부 도면들과 함께 고려될 때 더 잘 이해되고(appreciated) 이해될(understood) 것이다. 그러나, 다음 설명은 바람직한 실시 예 및 이의 수많은 특정 세부 사항을 나타내면서 제한이 아닌 예시로서 제공된다는 것을 이해해야 한다. 본 발명의 사상에서 벗어나지 않고 본 개시의 실시 예의 범위 내에서 많은 변경 및 수정이 이루어질 수 있으며, 본 개시의 실시 예는 그러한 모든 수정을 포함한다.
본 개시의 다양한 실시 예들은 보다 효과적인 연결 설정 및 CLAT 인식 선호도를 제공한다.
본 발명은 첨부된 도면에 예시되어 있으며, 전체에 걸쳐 유사한 참조 문자는 다양한 도면에서 대응하는 부분을 나타낸다. 본 개시의 실시 예들은 도면을 참조하여 다음 설명으로부터 더 잘 이해될 것이다.
도 1은 종래 기술에 따른 단말(user equipment, UE)의 CLAT(customer side translator, 고객측 변환기)에서 다단계 데이터 처리를 나타내는 시스템 다이어그램이다.
도 2A는 본 개시의 일 실시 예에 따른 멀티 코어 프로세서(120)에 CAA 기반 스케줄링을 제공하기 위한 단말(user equipment, UE, 100)의 블록도이다.
도 2B는 본 개시의 일 실시 예에 따른, 단말(UE, 100)의 멀티 코어 프로세서(120)상에서 CAA 기반 스케줄링을 제공하기 위한 CAA 스케줄러(CAA scheduler, 180)의 블록도이다.
도 2C는 본 개시의 일 실시 예에 따른, 멀티 코어 프로세서(120)상에서 CAA 기반 스케줄링을 제공하기 위한 단말(UE, 100)의 시스템 아키텍처를 예시한다.
도 3A는 본 개시의 일 실시 예에 따른, IPv4 서버 및 IPv6 서버 중에서 적어도 하나에 대한 연결을 설정하기 위한 방법을 예시하는 흐름도이다.
도 3B는 본 개시의 일 실시 예에 따른, 멀티 코어 프로세서(120)를 포함하는 단말(UE, 100)에 의한 CAA 기반 스케줄링을 위한 방법을 예시하는 흐름도이다.
도 3C는 본 개시의 일 실시 예에 따른, 적어도 하나의 클래스에 기반하여 멀티 코어 프로세서(120)의 적어도 하나의 코어상의 패킷을 스케줄링하는 방법을 예시하는 흐름도이다.
도 4는 본 개시의 실시 예들에 따른, CLAT-PLAT 아키텍처를 예시한다.
도 5는 종래 기술에 따른 듀얼 스택 아키텍처에서 데이터를 처리하는 종래의 메커니즘을 예시한다.
도 6A는 종래 기술에 따른 IPv6 서버가 없는 예시적인 시나리오를 도시한다.
도 6B는 본 개시의 실시 예들에 따른, IPv6 서버가 존재하지 않는다는 결정에 대한 응답으로 IPv4 서버에 연결하는 예시적인 시나리오를 도시한다.
도 7A는 종래 기술에 따라 IPv6 서버의 성능과 IPv4 서버의 성능이 동등하게 좋은 시나리오의 예시를 도시한다.
도 7B는 본 개시의 실시 예들에 따른, IPv6 서버의 성능과 IPv4 서버의 성능이 동일하다고 결정한 것에 대한 응답으로 IPv6 서버에만 접속하는 예시적인 시나리오를 도시한다.
도 8A는 종래 기술에 따라 IPv6 서버가 존재하지만 IPv4 서버의 성능이 IPv6 서버의 성능보다 우수한 시나리오의 예를 도시한다.
도 8B는 본 개시의 실시 예들에 따른, IPv4 서버의 성능이 IPv6 서버의 성능보다 우수하다는 결정에 대한 응답으로 IPv4 서버에 연결하는 예시적인 시나리오를 도시한다.
도 9는 본 개시의 실시 예들에 따른, 제1 기존 OS 활성화된 단말(UE, 100), 제2 기존 OS 활성화된 단말(UE, 100) 및 제안된 ILAT 활성화된 단말(UE, 100)의 연결 시간 비교를 도시한다.
도 10A는 본 개시의 일 실시 예에 따른, 기존의 단말(UE, 100) 및 CAA 활성화된 단말(UE, 100)에서의 패킷 처리의 비교를 도시한다.
도 10B는 본 개시의 일 실시 예에 따른, CAA 활성화된 단말(UE, 100) 및 CAA LITE 활성화된 단말(UE, 100)에서의 패킷 처리의 비교를 도시한다.
도 11은 본 개시의 일 실시 예에 따른, 패킷의 IP 헤더에 기반하여 패킷을 적어도 하나의 클래스로 분류하는 방법을 예시한다.
도 12는 본 개시의 일 실시 예에 따른, 패킷을 높은 우선 순위 큐(high priority queue), 중간 우선 순위 큐(mid priority queue) 및 일반 우선 순위 큐(normal priority queue) 중에서 하나로 분류하고 큐를 기반으로 패킷을 스케줄링하는 방법을 도시한다.
도 13은 본 개시의 일 실시 예에 따른, 데이터 패킷의 이중 처리없이 이중 IP 아키텍처에서 패킷의 분류를 예시한다.
도 14는 본 개시의 실시 예들에 따른, 제안된 방법의 평가를 위한 라이브 에어 실험 설정을 예시한다.
도 15A는 본 개시의 실시 예들에 따른, IPERF(internet performance working group) 테스트를 사용하는 기존의 OS 활성화된(enabled) 단말(UE, 100), CAA-LITE 활성화된 단말(UE, 100) 및 CAA 활성화된 단말(UE, 100)의 성능의 비교를 도시한다.
도 15B는 본 개시의 실시 예들에 따른, NIA 테스트를 사용하는 기존의 OS 활성화된(enabled) 단말(UE, 100), CAA-LITE 활성화된 단말(UE, 100) 및 CAA 활성화된 단말(UE, 100)의 성능의 비교를 예시한다.
도 16A는 본 개시의 실시 예들에 따른, 기존의 OS 활성화된(enabled) 단말(UE, 100), CAA-LITE 활성화된 단말(UE, 100) 및 CAA 활성화된 단말(UE, 100)의 처리량을 비교하기 위한 랩 시뮬레이션 설정을 예시한다.
도 16B는 본 개시의 실시 예들에 따른, 기존의 OS 활성화된(enabled) 단말(UE, 100), CAA-LITE 활성화된 단말(UE, 100) 및 CAA 활성화된 단말(UE, 100)의 처리량의 비교의 그래픽 표현이다.
도 17A는 본 개시의 실시 예들에 따른, 기존의 OS 활성화된(enabled) 단말(UE, 100), CAA-LITE 활성화된 단말(UE, 100) 및 CAA 활성화된 단말(UE, 100)에 대한 전력 소비의 비교의 그래픽 표현이다.
도 17B는 본 개시의 실시 예들에 따른, 기존의 OS 활성화된(enabled) 단말(UE, 100), CAA-LITE 활성화된 단말(UE, 100) 및 CAA 활성화된 단말(UE, 100)에 대한 전력 절약의 비교의 그래픽 표현이다.
이하, 첨부된 도면을 참조하여 본 발명의 다양한 실시 예들을 상세히 설명한다. 다음의 설명에서, 상세한 구성 및 구성 요소와 같은 특정 세부 사항은 단지 본 개시의 이러한 실시 예들의 전체적인 이해를 돕기 위해 제공된다. 따라서, 본 개시 내용의 범위 및 사상을 벗어나지 않고 여기에 설명된 실시 예들의 다양한 변경 및 수정이 이루어질 수 있다는 것은 당업자에게 명백할 것이다. 또한, 잘 알려진 기능 및 구성에 대한 설명은 명확성과 간결성을 위해 생략되었다.
또한, 일부 실시 예들은 새로운 실시 예들을 형성하기 위해 하나 이상의 다른 실시 예들과 조합될 수 있기 때문에, 여기에 설명된 다양한 실시 예들은 반드시 상호 배타적이지 않다.
본 개시에 사용된 용어 "또는"은 달리 명시되지 않는 한 비배타적(non-exclusive) 또는 비배타적(unless otherwise indicated)을 의미한다. 본 개시에서 사용된 예는 단지 본 개시의 실시 예들이 실시될 수 있는 방식의 이해를 용이하게 하고 당업자가 본 개시의 실시 예들을 실시할 수 있도록 하기 위한 것일 뿐이다. 따라서, 예들은 본 개시의 실시 예들의 범위를 제한하는 것으로 해석되어서는 안된다.
이 분야에서 전통적인 방식과 같이, 실시 예들은 설명된 기능 또는 기능을 수행하는 블록들의 관점에서 설명되고 예시될 수 있다. 본 개시에서 유닛들, 엔진들, 관리자, 모듈들 등으로 지칭될 수 있는 이러한 블록들은 논리 게이트들(logic gates), 집적 회로들(integrated circuits), 마이크로 프로세서(microprocessors), 마이크로 컨트롤러(microcontrollers), 메모리 회로들(memory circuits), 수동 전자 구성 요소들(passive electronic components), 능동 전자 구성 요소들(active electronic components), 광학 구성 요소들(optical components), 하드 와이어 회로들(hardwired circuits) 등과 같은 아날로그 및/또는 디지털 회로들에 의해 물리적으로 구현되거나, 선택적으로 펌웨어 및/또는 소프트웨어에 의해 구동될 수 있다. 회로들은 예를 들어 인쇄 회로 기판들 등과 같은 기판 지지대 또는 하나 이상의 반도체 칩에 구현될 수 있다. 블록을 구성하는 회로들은 전용 하드웨어에 의해, 또는 프로세서(예: 하나 이상의 프로그래밍된 마이크로 프로세서 및 관련 회로)에 의해, 또는 블록의 일부 기능들을 수행하기 위한 전용 하드웨어 및 블록의 다른 기능들을 수행하기 위한 프로세서의 조합에 의해 구현될 수 있다. 실시 예들의 각각의 블록은 본 개시의 범위를 벗어나지 않고 둘 이상의 상호 작용 및 개별 블록들로 물리적으로 분리될 수 있다. 마찬가지로, 실시 예들의 블록들은 본 개시의 범위를 벗어나지 않고 물리적으로 더 복잡한 블록들로 결합될 수 있다.
따라서, 본 개시의 실시 예들은 멀티 코어 프로세서(120)를 포함하는 단말(user equiptment, UE, 100)에 의한 CAA(clat aware affinity) 기반 스케줄링 방법을 제공한다. 방법은 패킷을 수신하고 패킷의 경로 특성을 결정하는 단말(UE, 100)의 CAA 스케줄러(180)를 포함한다. 또한, 상기 방법은 CAA 스케줄러(180)가 패킷의 경로 특성에 기반하여 IPv4 연결 및 IPv6 연결 중에서 적어도 하나를 결정하는 단계; 및 결정된 IPv4 연결 및 IPv6 연결 중에서 적어도 하나를 기반으로 IPv4 서버 및 IPv6 서버 중에서 적어도 하나에 연결을 설정한다. 또한, 상기 방법은 CAA 스케줄러(180)가 패킷을 적어도 하나의 클래스로 분류하고 적어도 하나의 클래스에 기반하여 멀티 코어 프로세서(120)의 적어도 하나의 코어에서 패킷을 스케줄링하는 단계를 포함한다.
일 실시 예에서, CAA 스케줄러가, 패킷을 하나 이상의 클래스로 분류하는 것은, 패킷의 IP 헤더가 IPv4 프리픽스(prefix) IP 주소 및 IPv6 프리픽스 IP 주소 중에서 하나를 포함하는지 여부를 결정 및 상기 패킷의 IP 헤더가 상기 IPv4 프리픽스 IP 주소를 포함한다는 결정에 대한 응답으로 클래스 A 네트워크로, 상기 패킷의 IP 헤더가 상기 IPv6 프리픽스 IP 주소를 포함한다는 결정에 대한 응답으로 클래스 B 네트워크로, 상기 패킷의 IP 헤더가 상기 IPv4 프리픽스 IP 주소 또는 상기 IPv6 프리픽스 IP 주소 모두를 포함하지 않는다는 결정에 대한 응답으로 클래스 C 네트워크 중에서 하나로 상기 패킷을 분류하는 과정을 포함한다.
일 실시 예에서, 상기 클래스 A 카테고리는, 상기 CLAT 및 IPv4 헤더를 갖는 애플리케이션들 간의, 포워딩된 패킷 또는 로컬 패킷을 나타낸다.
일 실시 예에서, 상기 클래스 B 카테고리는, 합성된 IPv6 헤더를 사용하여, RMNET 및 PLAT(provider side translator, 제공자측 변환기) 간의, 실제 패킷들 또는 라이브 에어 패킷들을 나타낸다.
일 실시 예에서, 상기 클래스 C 카테고리는, 상기 단말 내부의, 다이렉트(direct) IPv6 헤더 또는 로컬 소켓 통신이 있는 패킷들을 나타낸다.
일 실시 예에서, 상기 CAA 스케줄러가, 상기 적어도 하나의 클래스에 기반하여 상기 멀티 코어 프로세서의 적어도 하나의 코어상에 있는 상기 패킷을 스케줄링하는 과정은, 상기 패킷이 상기 클래스 A 카테고리, 상기 클래스 B 카테고리 및 상기 클래스 C 카테고리 중에서 하나로 분류되는지 여부를 결정하는 과정을 포함한다. 또한, 방법은 높은 우선 순위 큐를 생성하는 과정 및 상기 패킷이 상기 클래스 A 카테고리로 분류된 것으로 결정한 것에 대한 응답으로 상기 높은 우선 순위 큐에 상기 패킷을 표시하는 과정, 중간 우선 순위 큐를 생성하는 과정 및 상기 패킷이 상기 클래스 B 카테고리로 분류된 것으로 결정한 것에 대한 응답으로 상기 중간 우선 순위 큐에 상기 패킷을 표시하는 과정, 낮은 우선 순위 큐를 생성하는 과정 및 상기 패킷이 상기 클래스 C 카테고리로 분류된 것으로 결정한 것에 대한 응답으로 상기 낮은 우선 순위 큐에 상기 패킷을 표시하는 과정을 포함한다. 또한, 상기 방법은 게다가, 상기 CAA 스케줄러가, 상기 높은 우선 순위 큐, 상기 중간 우선 순위 큐 및 상기 낮은 우선 순위 큐 중에서 하나에 기반하여 상기 멀티 코어 프로세서의 적어도 하나의 코어에서 상기 패킷을 스케줄링하는 과정을 포함한다.
일 실시 예에서, 상기 CAA 스케줄러가, 상기 높은 우선 순위 큐, 상기 중간 우선 순위 큐 및 상기 낮은 우선 순위 큐 중에서 하나에 기반하여 상기 멀티 코어 프로세서의 적어도 하나의 코어에서 상기 패킷을 스케줄링하는 과정은, 상기 멀티 코어 프로세서의 동작 조건들을 모니터링하는 과정을 포함한다. 또한, 상기 동작 조건들, 상기 높은 우선 순위 큐, 상기 중간 우선 순위 큐 및 상기 낮은 우선 순위 큐 중에서 하나에 기반하여 상기 멀티 코어 프로세서의 CPU 어피니티를 수정하는 과정 및 상기 수정에 기반하여 상기 멀티 코어 프로세서의 적어도 하나의 코어에서 상기 패킷을 스케줄링하는 과정을 포함한다.
일 실시 예에서, 상기 동작 조건들은 CPU 부하, CPU 주파수, 현재 CPU 어피니티, RPS(receive packet steering, 수신 패킷 스티어링) 및 CAA 크로스 레이어 파라미터 중에서 적어도 하나를 포함한다.
일 실시 예에서, 상기 CAA 크로스 레이어 파라미터는 상기 단말의 무선 정보, 상기 단말의 배터리 정보, 상기 단말의 디스플레이 정보, RILD(radio interface layer daemon, RIL 데몬) 정보 및 NETD(network daemon, 네트워크 데몬) 정보 중에서 적어도 하나를 포함한다.
일 실시 예에서, 상기 CAA 스케줄러가, 상기 높은 우선 순위 큐, 상기 중간 우선 순위 큐 및 상기 낮은 우선 순위 큐 중에서 하나에 기반하여 상기 멀티 코어 프로세서의 적어도 하나의 코어에서 상기 패킷을 스케줄링하는 과정은, 상기 높은 우선 순위 큐, 상기 중간 우선 순위 큐 및 상기 낮은 우선 순위 큐 중에서 하나에 기반하여 상기 멀티 코어 프로세서의 CPU 어피니티를 수정하는 과정과, 상기 수정에 기반하여 상기 멀티 코어 프로세서의 적어도 하나의 코어에서 상기 패킷을 스케줄링하는 과정을 포함한다.
일 실시 예에서, 상기 CAA 스케줄러가, 상기 IPv4 서버 및 상기 IPv6 서버 중에서 적어도 하나에 대한 연결을 설정하는 과정은, 상기 IPv6 서버를 사용할 수 없다는 결정에 대한 응답으로 상기 IPv4 서버에 연결하는 과정, 상기 IPv6 서버의 성능 및 상기 IPv4 서버의 성능이 동일하다는 결정에 대한 응답으로 상기 IPv6 서버에 연결하는 과정, 상기 IPv4 서버의 성능이 상기 IPv6 서버의 성능보다 우수하다는 결정에 대한 응답으로 상기 IPv4 서버에 연결하는 과정 중에서 하나를 수행하는 과정을 포함한다.
종래의 방법 및 시스템에서는 CPU를 인식하지 못하는 스케줄링으로 인해 단말(UE)의 전력 소비가 증가한다. 종래의 방법 및 시스템과 달리 제안된 방법에서는 CAA 스케줄러가 실시간 CPU 부하를 추정하고 패킷을 동적으로 분류하여 전력 소비를 줄이고 처리량을 증가시킨다.
종래의 방법과 시스템은 IPv6를 LTE 네트워크에 배포한다. IPv6 LTE 네트워크에서는 IPv6 주소만 단말(UE)의 네트워크 인터페이스(예: Android의 RMNET)에 할당된다. 그러나 일부 응용 프로그램은 IPv4를 사용하기 때문에 IPv4 주소가 있는 인터페이스는 여전히 IPv4 패킷을 보내고 받아야한다.
기존의 464XLAT는 두 가지 아키텍처들을 포함하는 단순하고 확장 가능한 이중 주소 변환 기술이다. 하나는 CLAT(customer side translator 고객측 변환기)이고 다른 하나는 PLAT(platform side translator, 플랫폼측 변환기)다. CLAT는 일반적으로 최종 사용자 모바일 장치에 있다. 이것은 1:1 매핑을 제공하고 알고리즘 방식으로 IP 주소를 변환하는 상태 비저장 변환기인 반면에 PLAT는 매핑 데이터베이스를 유지하고 1:N 매핑을 제공하는 상태 저장 변환기다.
이제 도면, 보다 구체적으로 유사한 참조 문자가 도면 전체에 걸쳐 일관되게 대응하는 특징을 나타내는 도 1 내지 17B를 참조하면, 바람직한 실시 예가 도시되어 있다.
도 2A는 본 개시의 일 실시 예에 따른 멀티 코어 프로세서(120)에 CAA 기반 스케줄링을 제공하기 위한 단말(user equipment, UE, 100)의 블록도이다.
도 2A를 참조하면, 단말(UE, 100)은 고정형(fixed) 또는 이동형(mobile)일 수 있으며, 이동국(mobile station, MS), 사용자 단말(user terminal, UT), 가입자 스테이션(subscriber station, SS), 무선 장치(wireless device), PDA(personal digital assistant), 무선 모뎀(wireless modem), 핸드헬드 장치(handheld device) 또는 AT(access terminal, 액세스 단말)와 같은 다른 용어로도 불릴 수 있다. 일 실시 예에서, 단말(UE, 100)은, 예를 들어, 모바일 폰(mobile phone), 스마트 폰(smart phone), PDAs(personal digital assistants), 태블릿(tablet), 웨어러블 장치(wearable device), 사물 인터넷(internet of things, IoT) 장치 등일 수 있다.
단말(UE, 100)은 커뮤니케이터(communicator, 110), 멀티 코어 프로세서(multi-core processor, 120), 배터리 관리자(battery manager, 130), RILD(radio interface layer daemon, RIL 데몬, 140), 연결 관리자(connectivity manager, 150), NETD(network daemon, 네트워크 데몬, 160), 메모리(memory, 170), CAA 스케줄러(CAA scheduler, 180) 및 디스플레이(display, 190)를 포함한다.
일 실시 예에서, 커뮤니케이터(110)는 패킷을 수신하도록 구성된다. 커뮤니케이터(110)는 또한 단말(UE, 100)에 의해 신호를 송수신하도록 구성된다.
일 실시 예에서, 멀티 코어 프로세서(120)는 개별 코어 사이의 상호 접속들을 갖는 복수의 코어들로 구성된다. 복수의 코어들은 집합적으로(collectively) 또는 일반적으로(in general) 코어들로 지칭될 수 있다. 멀티 코어 프로세서(120)는 메모리(170)로부터 판독 및/또는 메모리(170)에 기록하도록 구성될 수 있다. 이러한 읽기 및 쓰기 동작들은 멀티 코어 프로세서(120)의 복수의 코어들의 동작들과 관련된 명령들 및 데이터 모두에 관련될 수 있다. 또한, 멀티 코어 프로세서(120) 내의 각 코어들은 개별적으로 메모리(170)에 액세스하도록 구성될 수 있다. 복수의 코어들 사이의 시그널링은 복수의 코어들에 소프트웨어 구동 하드웨어 인터럽트들을 생성함으로써 달성된다.
일 실시 예에서, 배터리 관리자(130)는 단말(UE, 100)의 배터리 및 배터리의 충전 특성들을 쿼리하는 방법을 제공하도록 구성된다.
일 실시 예에서, RILD(140)는 신호 강도(signal strength), 신호 대 잡음비(signal to noise ratio) 등과 같은 단말(UE, 100)의 무선 특성들과 관련된 정보를 결정하고 공유하도록 구성된다.
일 실시 예에서, 연결 관리자(150)는 단말(UE, 100)의 네트워크 연결 상태와 관련된 정보를 결정하고 전송하도록 구성된다. 연결 관리자(150)는 또한 네트워크 연결이 변경될 때 단말(UE, 100)에서 실행되는 애플리케이션에 통지하도록 구성된다.
일 실시 예에서, NETD(160)는 인터페이스 정보 및 기타 네트워크 관리 파라미터를 가져올 수 있는 운영 체제의 하드웨어 추상화 레이어다.
일 실시 예에서, 메모리(170)는 비휘발성 저장 요소(non-volatile storage element)를 포함할 수 있다. 이러한 비휘발성 저장 요소의 예는 자기 하드 디스크(magnetic hard disc), 광 디스크(optical disc), 플로피 디스크(floppy disc), 플래시 메모리(flash memory) 또는 EPROM(electrical programmable memory) 또는 EEPROM(electrical erasable and programmable) 메모리의 형태를 포함할 수 있다. 또한, 메모리(170)는 일부 예들에서 비일시적 저장 매체(non-transitory)로 간주될 수 있다. 용어 "비일시적"은 저장 매체가 반송파 또는 전파된 신호로 구현되지 않음을 나타낼 수 있다. 그러나, "비일시적"이라는 용어는 메모리(170)가 움직일 수 없는 것으로 해석되어서는 안된다. 일부 예들에서, 메모리(170)는 메모리보다 더 많은 양의 정보를 저장하도록 구성될 수 있다. 특정 예에서, 비일시적 저장 매체는 시간이 지남에 따라(예를 들어, RAM(random access memory) 또는 캐시에) 변경될 수 있는 데이터를 저장할 수 있다.
일 실시 예에서, CAA 스케줄러(180)는 패킷의 IP 헤더에 기반하여 패킷을 클래스 A, 클래스 B 및 클래스 C의 적어도 하나의 클래스로 분류하도록 구성된다. 또한, CAA 스케줄러(180)는 또한 높은 우선 순위 큐, 중간 우선 순위 큐 및 낮은 우선 순위 큐 중에서 적어도 하나에 기반하여 멀티 코어 프로세서(120)의 적어도 하나의 코어상의 패킷을 스케줄링하도록 구성된다. 높은 우선 순위 큐, 중간 우선 순위 큐 및 낮은 우선 순위 큐는 패킷이 분류되는 적어도 하나의 클래스를 기반으로 결정된다.
일 실시 예에서, 디스플레이(190)는 스크린의 일부 또는 스크린의 전체 영역에서 온 또는 오프와 같은 디스플레이 상태를 제공하도록 구성된다.
도 2A는 단말(UE, 100)의 하드웨어 요소를 도시하지만, 다른 실시 예들이 이에 제한되지 않음을 이해해야 한다. 다른 실시 예들에서, 단말(UE, 100)는 더 적거나 더 많은 수의 요소를 포함할 수 있다. 또한, 요소의 라벨 또는 이름은 예시 목적으로만 사용되며 본 발명의 범위를 제한하지 않는다. 하나 이상의 구성 요소가 함께 결합되어 단말(UE, 100)에서 상호 작용을 가능하게 하는 동일하거나 실질적으로 유사한 기능을 수행할 수 있다.
도 2B는 본 개시의 일 실시 예에 따른, 단말(UE, 100)의 멀티 코어 프로세서(120)상에서 CAA 기반 스케줄링을 제공하기 위한 CAA 스케줄러(CAA scheduler, 180)의 블록도이다. CAA 스케줄러(CAA scheduler, 180)는 CAA 분류기(CAA classifier, 182), CAA CPU 컨트롤러(CAA CPU controller, 184), 크로스 레이어 페처(cross layer fetcher, 186) 및 ILAT(intelligent learning based translator, 지능형 학습 기반 변환기, 188)를 포함한다.
일 실시 예에서, CAA 분류기(CAA classifier, 182)는 헤더 프로세서(header processor, 182a) 및 마커(marker, 182b)를 포함한다. 헤더 프로세서(182a)는 패킷의 IP 헤더를 결정하도록 구성된다. 헤더 프로세서(182a)는 또한 패킷이 IPv4 프리픽스, IPv6 프리픽스를 포함하는지 또는 IPv4 프리픽스 및 IPv6 프리픽스를 포함하지 않는지를 결정한다. 또한, 헤더 프로세서(182a)는 헤더에 기반하여 패킷을 분류한다. 마커(182b)는 패킷의 헤더를 디코딩한 후 클래스 A, 클래스 B 및 클래스 C의 클래스 중에서 하나에 속하는 것으로 각 클래스의 패킷을 표시한다.
일 실시 예에서, CAA CPU 컨트롤러(CAA CPU controller, 184)는 CPU 부하 모니터(CPU load monitor, 184a), CPU 주파수 컨트롤러(CPU frequency controller, 184b), CPU 어피니티 컨트롤러(CPU affinity controller, 184c) 및 RPS(receive packet steering, 수신 패킷 스티어링) 컨트롤러(184d)를 포함한다.
일 실시 예에서, CAA CPU 컨트롤러(184)는 CPU 부하 모니터(184a), CPU 주파수 컨트롤러(184b), CPU 어피니티 컨트롤러(184c) 및 RPS(receive packet steering, 수신 패킷 스티어링) 컨트롤러(184d)를 포함한다.
CPU 부하 모니터(184a)는 각각의 CPU의 현재 부하를 내부적으로 모니터링하도록 구성된다. CPU 주파수 컨트롤러(184b)는 CPU의 부하에 따라 CPU 주파수의 증가 또는 감소 중에서 하나를 수행하도록 구성된다. 또한, CPU 주파수 컨트롤러(184b)는 멀티 코어 프로세서(120)의 각 코어의 CPU 주파수를 동적으로 제어한다. 따라서, CPU 주파수 컨트롤러(184b)는 처리량에 대한 더 높은 요구가 있을 때 CPU 당 주파수의 증가를 가능하게 한다.
CPU 어피니티 컨트롤러(184c)는 결정된 패킷의 우선 순위와 함께 분류에 기반하여 프로세서 어피니티를 결정하도록 구성된다. 프로세서 선호도를 결정하면 최대 성능을 달성하는 데 도움이 된다.
RPS 컨트롤러(184d)는 큐에 축적되고 멀티 코어 프로세서(120)의 적어도 하나의 코어에 의해 처리되는 연결/패킷을 스케줄링하도록 구성된다. RPS 컨트롤러(184d)는 멀티 코어 프로세서(120) 중에서 적어도 하나에서 패킷을 스케줄링하는 데 사용되는 IP 주소 및 포트 번호로부터 해시를 생성하도록 구성된다. RPS 컨트롤러(184d)는 패킷 큐를 멀티 코어 프로세서(120) 중에서 적어도 하나에 할당하고 전체 시스템 활용을 증가시키는 패킷의 병렬 처리를 허용한다. CAA CPU 컨트롤러(184)는 멀티 코어 프로세서(120) 중에서 적어도 하나 사이에서 프로세스/태스크를 동적으로 할당하고 마이그레이션한다. 멀티 코어 프로세서(120)는 일련의 작은 코어 및 큰 코어를 포함한다. CAA CPU 컨트롤러(184) CAA는 대역폭과 처리량을 높이기 위해 프로세스 집약적인 작업에 큰 코어를 사용하고 전력 소비와 열 제어를 최소화하기 위해 덜 집약적인 작업에 작은 코어를 사용한다.
일 실시 예에서, 크로스 레이어 페처(cross layer fetcher, 186)는 무선 정보 엔진(radio information engine, 186a), 배터리 정보 엔진(battery information engine, 186b) 및 디스플레이 정보 엔진(display information engine, 186c) 중에서 적어도 하나를 포함하는 크로스 레이어 정보를 페치(fetch)하도록 구성된다. 무선 정보 엔진(186a)은 RAT(radio access technology, 무선 액세스 기술) 유형, RAT 작동 대역, RAT 아키텍처, 신호 강도 등과 같은 무선 파라미터의 정보를 페치하도록 구성된다. 배터리 정보 엔진(186b)은 멀티 코어 프로세서(120)에서 전력 효율적인 스케줄링을 위해 배터리 잔량, 배터리 상태 및 배터리 충전 정보 등과 같은 단말(UE, 100)의 배터리와 관련된 정보를 가져오도록 구성된다. 배터리 정보는 CPU 주파수를 비례적(proportionally)으로 클럭하는 데 사용된다. 예를 들어 처리량이 집중적이고 배터리 수준이 80% 이상이라고 가정한다. 그런 다음 CPU 주파수는 최대 값의 90%로 설정된다. 다른 예에서, 배터리 수준이 위험하거나 15% 미만이면 CPU 주파수는 최대 50%로 설정되거나 CAA 스케줄러(180)에 의해 작은 코어만 사용된다.
디스플레이 정보 엔진(186c)은 디스플레이 상태를 페치하도록 구성된다. 표시 상태는 다음 중에서 하나다:
a. ON/ON_SUSPEND/OFF 표시 상태: 이 디스플레이 상태에서, CAA 스케줄러(180)는 주파수를 클록하고 다른 파라미터에 기반하여 멀티 코어 프로세서(120)의 복수의 코어들 사이의 어피니티를 스케줄링한다.
b. DOZE/DOZE_SUSPEND 표시 상태: 이 디스플레이 상태에서 디스플레이는 저전력 상태 모델로 잠긴다. 단말(UE, 100)는 비대화 형(non-interactive)이며 전력 효율성에 더 많은 초점을 맞출 필요가 있다. 따라서, CAA 스케줄러(180)는 패킷을 스케줄링하는데 최소한의 노력을 기울인다. 제안된 방법은 단말(UE, 100)이 DOZE/DOZE_SUSPEND 상태에 있을 때 CAA-LITE 모드를 포함하여 더 많은 절전을 가능하게 한다.
c. STATE_UNKNOWN 표시 상태: 이 디스플레이 상태에서, 디스플레이의 상태는 알려지지 않았으므로 CAA 스케줄러(180)는 데이터 패킷의 기본 처리 메커니즘을 이용한다.
일 실시 예에서, ILAT(188)는 단말(UE, 100)에서 동작하는 기계 학습(machine learning) 기반 XLATing 서비스이다. ILAT(188)은 OSI 모델(open systems interconnection model, 개방형 시스템 상호 연결 모델)의 전송 레이어와 애플리케이션간에 작동한다. ILAT(188)는 패턴 분석기(pattern analyzer, 188a) 및 ILAT 실행기(ILAT executor, 188b)를 포함한다. 패턴 분석기(188a)는 사용자 히스토리를 학습하고 사용자 히스토리를 사용하여 DNS 패턴을 제어하도록 구성된다. ILAT(188)은 DNS 쿼리, TCP 연결, 경로 특성 및 CPU 패턴을 모니터링한다. ILAT(188)은 또한 애플리케이션 패턴, 듀얼 스택, 배터리, SIOP, CPU 성능, RAT 연결 등과 같은 단말(UE, 100)상태를 모니터링하도록 구성된다.
또한, ILAT 실행기(188b)는 패킷의 경로 특성에 기반하여 IPv4 연결 및 IPv6 연결 중에서 적어도 하나를 결정하도록 구성되고, 결정된 IPv4 연결 및 IPv6 연결 중에서 하나 이상을 기반으로 IPv4 서버 및 IPv6 서버 중에서 하나 이상에 연결을 설정한다. IPv4 서버 및 IPv6 서버 중에서 하나 이상에 대한 연결 설정에는 IPv6 서버가 없다는 결정에 대한 응답으로 IPv4 서버에 연결하는 중에서 하나를 수행하는 단계, IPv6 서버의 성능과 IPv4 서버의 성능이 동일하다는 결정에 대한 응답으로 IPv6 서버에 연결하는 단계, IPv4 서버의 성능이 IPv6 서버의 성능보다 우수하다는 결정에 대한 응답으로 IPv4 서버에 연결하는 단계를 포함한다.
도 2C는 본 개시의 일 실시 예에 따른, 멀티 코어 프로세서(120)상에서 CAA 기반 스케줄링을 제공하기 위한 단말(UE, 100)의 시스템 아키텍처를 예시한다.
도 2C를 참조하면, 제안된 시스템 아키텍처는 모듈 식이고 도 3C에 도시된 바와 같이 다양한 기능적 구성 요소를 포함한다. CAA 스케줄러(180)는 IP 헤더를 기반으로 각 애플리케이션으로부터 수신되는 패킷을 스케줄링한다. 패킷 도착은 패킷의 평균 도착 시간과 패킷 손실 감지에서 처리량을 도출하는 데 사용되는 포아송(poisson) 분포로 간주된다. CAA 스케줄링 알고리즘에 따른 포아송 도착 모델은 다음과 같다:
CAA 큐 추정: CAA 스케줄러(180)에 도착하는 패킷이 기하 급수적으로 분포된 도착 간 시간, 즉 1초 미만의 간격으로 포아송 도착을 갖는다는 것을 고려.
일반적으로 TCP 트래픽은 포아송 배포 및 특정 UDP 기반 트래픽을 따른다. CAA 스케줄(180)의 서비스 속도가 초당 μ 비트라고 가정한다. CAA 스케줄(180)에 도착하는 패킷은 고정된 양자에 대한 클래스 기반 FIFO(first-in-first-out, 선입 선출) 큐잉 규율에서 서비스된다. 복수의 애플리케이션들(즉, App1, App2, App3 등)이 단말(UE, 100)에서 실행되고 있고 복수의 애플리케이션들이 다중 소켓을 열었다. 소켓 i에있는 패킷의 경우 패킷의 평균 도착 속도는
Figure pct00001
로 제공된다. 따라서 CAA 일정 180에서 총 평균 도착률
Figure pct00002
는 다음과 같다.
Figure pct00003
최선의 활용도를 얻으려면 총 평균 도착 속도가 항상 스케줄러의 서비스 속도보다 낮아야 한다. 즉, λ≤μ이다. 소켓 i의 서비스 속도는 다음과 같이 쓸 수 있다.
Figure pct00004
서비스 시간은 μ=
Figure pct00005
속도로 제공되는 결정론적 시간 D이다. 길이가 L인 소켓 i의 패킷 서비스 기간은 고정된 기간인
Figure pct00006
,이다. 따라서, CAA 스케줄러(180)에 대해 M/D/1 큐 모델을 사용한다. 여기서 도착 속도는 λ이고 서비스 속도는 μ이고 사용률은 ρ = λ/μ이다. 소켓 i의 패킷에 대해 큐 E[Wi]의 평균 대기 시간과 스케줄러 E [Ti]의 평균 시간은 다음과 같이 제공된다.
Figure pct00007
Figure pct00008
스케줄러에서 패킷의 평균 시간은 Little 's Law를 사용하여 얻을 수도 있다.
Figure pct00009
패킷 손실은 특정 큐가 넘칠 때 발생한다(예: ρ> 1). 이것은 패킷이 서비스될 수 있는 것보다 더 빨리 도착한다는 것을 의미한다.
Figure pct00010
큐 오버 플로우로 인한 패킷 손실로부터 패킷의 처리량과 각 큐의 처리 용량을 제안된 방법으로 직접 식별할 수 있다.
CAA 스케줄링 알고리즘: CAA 분류기(182)로부터의 데이터는 도 7에 도시된 바와 같이 복수의 큐들을 결정하는 데 사용된다. 우선 순위가 높은 큐에는 로컬에서 처리되는 패킷이 포함된다. 따라서 처리 시간과 패킷 지연은 매우 낮거나 무시할 수 있다. 중간 우선 순위 큐는 PLAT와 단말(UE, 100) 간의 패킷 트랜잭션(transaction)을 포함한다. 패킷 지연은 클라이언트에 대한 최종 서버의 왕복 시간에 따라 다르다.
분류된 패킷은 복수의 코어들과 차례로 연관되는 복수의 큐들에서 처리된다. CAA 스케줄러(180)에 의해 분류된 정보로 패킷을 분할하면 단말(UE, 100)의 처리량이 1.2배 향상된다. 패킷 처리는 처리량을 80% 증가시키고 복수의 코어들 중에서 사용 가능한 코어들에 동적으로 할당하여 처리량을 90% 향상시킨다. 향상의 주된 이유는 패킷 지연 감소와 애플리케이션에 대한 패킷 드롭이다.
도 3A는 본 개시의 일 실시 예에 따른, IPv4 서버 및 IPv6 서버 중에서 적어도 하나에 대한 연결을 설정하기 위한 방법을 예시하는 흐름도(300)이다.
도 3A를 참조하면, 단계(301)에서 단말(UE, 100)는 패킷을 수신한다. 예를 들어, 도 2A에 도시된 단말(UE, 100)에서 커뮤니케이터(110)는 패킷을 수신하도록 구성된다.
단계(302)에서 단말(UE, 100)는 패킷의 경로 특성을 결정한다. 예를 들어, 도 2A에 도시된 단말(UE, 100)에서 CAA 스케줄러(180)는 패킷의 경로 특성을 결정하도록 구성된다.
단계(303)에서 단말(UE, 100)는 패킷의 경로 특성을 기반으로 IPv4 연결 및 IPv6 연결 중에서 적어도 하나를 결정한다. 예를 들어, 도 2A에 도시된 단말(UE, 100)에서 커뮤니케이터(110)는 패킷의 경로 특성을 기반으로 IPv4 연결 및 IPv6 연결 중에서 적어도 하나를 결정하도록 구성된다.
단계(304)에서, 단말(UE, 100)는 다음 중에서 하나를 수행하여 IPv4 서버 및 IPv6 서버 중에서 적어도 하나에 대한 연결을 설정한다: 단계(305)에 표시된 대로 IPv6 서버를 사용할 수 없다는 결정에 대한 응답으로 IPv4 서버에 연결한다. 단계(306)에 표시된 것처럼 IPv6 서버의 성능과 IPv4 서버의 성능이 동일한 지 확인한 경우에만 IPv6 서버에 연결하고, 단계(307)에 나타낸 바와 같이, IPv4 서버의 성능이 IPv6 서버의 성능보다 우수하다는 결정에 대한 응답으로 IPv4 서버에 연결한다.
방법에서 다양한 동작들(actions), 동작들(acts), 블록들(blocks), 단계들(steps) 등은 제시된 순서로, 다른 순서로 또는 동시에 수행될 수 있다. 또한, 일부 실시 예들에서, 동작들(actions), 동작들(acts), 블록들(blocks), 단계들(steps) 등의 일부는 본 발명의 범위를 벗어나지 않고 생략, 추가, 수정, 건너뛰기 등이 될 수 있다.
도 3B는 본 개시의 일 실시 예에 따른, 멀티 코어 프로세서(120)를 포함하는 단말(UE, 100)에 의한 CAA 기반 스케줄링을 위한 방법을 예시하는 흐름도이다.
도 3B를 참조하면, 단계(310)에서 단말(UE, 100)는 패킷을 수신한다. 예를 들어, 도 2A에 도시된 단말(UE, 100)에서 커뮤니케이터(110)는 패킷을 수신하도록 구성된다.
단계(320)에서 단말(UE, 100)는 패킷의 IP 헤더가 IPv4 프리픽스 IP 주소 및 IPv6 프리픽스 IP 주소 중에서 하나를 포함하는지 여부를 결정한다. 예를 들어, 도 2A에 도시된 단말(UE, 100)에서 CAA 스케줄러(180)는 패킷의 IP 헤더가 IPv4 프리픽스 IP 주소 및 IPv6 프리픽스 IP 주소 중에서 하나를 포함하는지 여부를 결정하도록 구성된다.
단계(330)에서, 단말(UE, 100)는 패킷의 IP 헤더가 IPv4 프리픽스를 포함한다는 결정에 대한 응답으로 패킷을 클래스 A 네트워크로 분류한다. 예를 들어, 도 2A에 도시된 단말(UE, 100)에서, CAA 스케줄러(180)는 패킷의 IP 헤더가 IPv4 프리픽스를 포함한다고 결정한 것에 대한 응답으로 패킷을 클래스 A 네트워크로 분류하도록 구성된다.
단계(340)에서, 단말(UE, 100)는 패킷의 IP 헤더가 IPv6 프리픽스를 포함한다고 결정한 것에 대한 응답으로 패킷을 클래스 B 네트워크로 분류한다. 예를 들어, 도 2A에 도시된 단말(UE, 100)에서, CAA 스케줄러(180)는 패킷의 IP 헤더가 IPv6 프리픽스를 포함한다고 결정한 것에 대한 응답으로 패킷을 클래스 B 네트워크로 분류하도록 구성된다.
단계(350)에서, 단말(UE, 100)는 패킷의 IP 헤더가 IPv4 프리픽스 또는 IPv6 프리픽스 모두를 포함하지 않는다는 결정에 대한 응답으로 패킷을 클래스 C 네트워크로 분류한다. 예를 들어, 도 2A에 도시된 단말(UE, 100)에서, CAA 스케줄러(180)는 패킷의 IP 헤더가 IPv4 프리픽스 또는 IPv6 프리픽스를 포함하지 않는다는 결정에 대한 응답으로 패킷을 클래스 C 네트워크로 분류하도록 구성된다.
단계(360)에서, 단말(UE, 100)는 적어도 하나의 클래스에 기반하여 멀티 코어 프로세서(120)의 적어도 하나의 코어에서 패킷을 스케줄링한다. 예를 들어, 도 2A에 도시된 단말(UE, 100)에서 CAA 스케줄러(180)는 적어도 하나의 클래스를 기반으로 멀티 코어 프로세서(120)의 적어도 하나의 코어에서 패킷을 스케줄링하도록 구성된다.
방법에서 다양한 동작들(actions), 동작들(acts), 블록들(blocks), 단계들(steps) 등은 제시된 순서로, 다른 순서로 또는 동시에 수행될 수 있다. 또한, 일부 실시 예들에서, 동작들(actions), 동작들(acts), 블록들(blocks), 단계들(steps) 등의 일부는 본 발명의 범위를 벗어나지 않고 생략, 추가, 수정, 건너뛰기 등이 될 수 있다.
도 3C는 본 개시의 일 실시 예에 따른, 적어도 하나의 클래스에 기반하여 멀티 코어 프로세서(120)의 적어도 하나의 코어상의 패킷을 스케줄링하는 방법을 예시하는 흐름도이다.
도 3C를 참조하면, 단계(361)에서 단말(UE, 100)는 패킷이 클래스 A 네트워크, 클래스 B 네트워크 및 클래스 C 네트워크 중에서 하나로 분류되는지 여부를 결정한다. 예를 들어, 도 2A에 도시된 단말(UE, 100)에서 CAA 스케줄러(180)는 패킷이 클래스 A 네트워크, 클래스 B 네트워크 및 클래스 C 네트워크 중에서 하나로 분류되는지 여부를 결정하도록 구성된다.
단계(362)에서 단말(UE, 100)는 패킷이 클래스 A 네트워크로 분류된 것으로 결정한 것에 대한 응답으로 높은 우선 순위 큐를 생성하고 높은 우선 순위 큐에 패킷을 표시한다. 예를 들어, 도 2A에 도시된 바와 같이 단말(UE, 100)에서 CAA 스케줄러(180)는 패킷이 클래스 A 네트워크로 분류된 것으로 결정한 것에 대한 응답으로 높은 우선 순위 큐를 생성하고 높은 우선 순위 큐에 패킷을 표시하도록 구성된다.
단계(363)에서 단말(UE, 100)는 패킷이 클래스 B 네트워크로 분류된 것으로 결정한 것에 대한 응답으로 중간 우선 순위 큐를 생성하고 중간 우선 순위 큐에 패킷을 표시한다. 예를 들어, 도 2A에 도시된 바와 같이 단말(UE, 100)에서 CAA 스케줄러(180)는 중간 우선 순위 큐를 생성하고, 패킷이 클래스 B 네트워크로 네트워크로 분류된 것으로 결정한 것에 대한 응답으로 중간 우선 순위 큐에 패킷을 표시하도록 구성된다.
단계(364)에서 단말(UE, 100)는 패킷이 클래스 C 네트워크로 분류된 것으로 결정한 것에 대한 응답으로 낮은 우선 순위 큐를 생성하고 낮은 우선 순위 큐에 패킷을 표시한다. 예를 들어, 도 2A에 도시된 바와 같이 단말(UE, 100)에서 CAA 스케줄러(180)는 패킷이 클래스 C 네트워크로 분류된 것으로 결정한 것에 대한 응답으로 낮은 우선 순위 큐를 생성하고 낮은 우선 순위 큐에 패킷을 표시하도록 구성된다.
단계(365)에서, 단말(UE, 100)는 높은 우선 순위 큐, 중간 우선 순위 큐 및 낮은 우선 순위 큐 중에서 하나로부터 멀티 코어 프로세서(120)의 적어도 하나의 코어상의 패킷을 스케줄링한다. 예를 들어, 도 2A에 도시된 단말(UE, 100)에서, CAA 스케줄러(180)는 높은 우선 순위 큐, 중간 우선 순위 큐 및 낮은 우선 순위 큐 중에서 하나로부터 멀티 코어 프로세서(120)의 적어도 하나의 코어상의 패킷을 스케줄링하도록 구성된다.
단계(366)에서 단말(UE, 100)는 멀티 코어 프로세서(120)의 동작 조건을 모니터링한다. 예를 들어, 도 2A에 도시된 단말(UE, 100)에서 CAA 스케줄러(180)는 멀티 코어 프로세서(120)의 동작 조건들을 모니터링하도록 구성된다.
단계(367)에서, 단말(UE, 100)는 동작 조건들 및 높은 우선 순위 큐, 중간 우선 순위 큐 및 낮은 우선 순위 큐 중에서 하나에 기반하여 멀티 코어 프로세서(120)의 CPU 어피니티를 수정한다. 예를 들어, 도 2A에 도시된 단말(UE, 100)에서, CAA 스케줄러(180)는 동작 조건들 및 높은 우선 순위 큐, 중간 우선 순위 큐 및 낮은 우선 순위 큐 중에서 하나에 기반하여 멀티 코어 프로세서(120)의 CPU 어피니티를 수정하도록 구성된다.
단계(368)에서, 단말(UE, 100)는 수정에 기반하여 멀티 코어 프로세서(120)의 적어도 하나의 코어에서 패킷을 스케줄링한다. 예를 들어, 도 2A에 도시된 단말(UE, 100)에서 CAA 스케줄러(180)는 수정에 기반하여 멀티 코어 프로세서(120)의 적어도 하나의 코어에 패킷을 스케줄링하도록 구성된다.
방법에서 다양한 동작들(actions), 동작들(acts), 블록들(blocks), 단계들(steps) 등은 제시된 순서로, 다른 순서로 또는 동시에 수행될 수 있다. 또한, 일부 실시 예들에서, 동작들(actions), 동작들(acts), 블록들(blocks), 단계들(steps) 등의 일부는 본 발명의 범위를 벗어나지 않고 생략, 추가, 수정, 건너뛰기 등이 될 수 있다.
도 4는 본 개시의 실시 예들에 따른, CLAT-PLAT 아키텍처를 예시한다.
도 4를 참조하면, CLAT 아키텍처는 다음을 포함한다: CLAT(customer side translator, 고객측 변환기): 단말(UE, 100) 내부에서 실행되어 상태 비저장 프로토콜 변환을 구현하고 CLAT는 사설 IPv4 주소를 제공한다. IPv4 애플리케이션은 CLAT를 사용하고 IPv4 주소는 CLAT에 의해 IPv6로 변환된다. 또한 패킷의 목적지는 PREF64/n과 CLAT에 의해 결정된 IPv4 주소를 사용하여 결정된다.
네이티브 IPv6: IPv6 주소가 활성화된(enabled) 웹 사이트는 IPv6 서버로 직접 라우팅된다.
DNS64는 AAAA 응답이 클라이언트로 전달되거나 그렇지 않으면 DNS64가 AAAA 응답에 IPv4 주소를 포함하는 경우 IPv4 주소(A) 레코드에서 IPv6 주소(AAAA) 리소스 레코드를 합성하는 메커니즘이다.
PLAT(provider side translator, 제공자측 변환기)는 운영자 백홀 내부에서 실행되며 상태 저장 프로토콜 변환을 구현한다. PLAT는 N:1 글로벌 IPv6 주소를 공용 IPv4 주소로 변환한다. PLAT은 획득한 IPv6 주소에서 대상 IPv4 주소를 파생한다. 또한 PLAT는 확장 가능하다.
도 5는 종래 기술에 따른 듀얼 스택 아키텍처에서 데이터를 처리하는 종래의 메커니즘을 예시한다.
일반적으로, 세션당 약 32K 이하의 데이터를 소비하는 기존 OS 활성화된(enabled) 단말(UE, 100)에서 연결의 약 91%가 수명이 짧다. 촉각 애플리케이션의 경우 5G에서 1ms 미만의 지연 시간이 보장되어야 하며 추가 경로는 평균 5-8ms에서 지연될 수 있으며 최대 400ms까지 올라갈 수 있으므로 처리량이 감소하고 단말(UE, 100)의 성능에 영향을 미칠 수 있다. 또한 IPv4에서 IPv6으로 또는 그 반대로 주소를 대화하는 동안 처리 오버 헤드가 발생할 수 있다.
대부분의 서버는 IPv4 주소와 IPv6 주소를 모두 지원한다. 따라서 IPv4 연결과 IPv6 연결 중에서 최상의 경로를 선택해야 한다. 깨진 지역성은 터널링 프로세스에서 볼 수 있는 가장 중요한 문제 중에서 하나다.
도 5를 참조하면, 주소의 변환과 함께 데이터 패킷의 복잡한 처리가 도시되어 있다. 듀얼 스택의 주요 단점 중에서 하나는 IPv4 및 IPv6 인프라가 모두 필요하다는 것이다. 결과적으로 네트워크 운영자는 여전히 IPv4 주소를 관리하고 네트워크에서 IPv6에 대한 지원을 도입해야 한다. 운영자가 네트워크의 모든 무선 장치에 대해 이중 IP 주소를 지원하고 관리해야 하기 때문에 운영자 비용이 증가한다.
다른 종래의 방법에서, 패킷 코어 도메인에서 IPv4에서 IPv6로의 전환을 위해 각 단말에 IPv6 주소만을 제공하는 것을 포함할 수 있다. 또한 주소 변환 메커니즘은 IPv4 패킷의 주소를 "합성"IPv6 주소로 변환하는 DNS64와 같은 IPv4 서버의 모든 DNS(도메인 이름 서비스) 조회에 사용된다. 합성 IPv6 주소에는 대상 IPv4 주소가 포함될 수 있다. 또한 IPv4 주소를 IPv6 주소로 변환하는 작업은 DNS64에서 반환한 IPv6 주소로 주소가 지정된 외부 NAT64에서 수행될 수 있다. 또 다른 일반적인 방법에서는 일부 응용 프로그램이 기본적으로 IPv4 주소를 사용한다. CLAT 메커니즘을 통해 464XLAT 기술을 지원하는 단말(UE, 100)의 경우, 단말(UE, 100)은 IPv4 주소를 NAT64를 향한 IPv6(상태 비저장 XLAT) 주소로 변환한다.
제안된 방법에서 단말(UE, 100)는 종래의 XLAT 아키텍처에서는 적용할 수 없는 연결 시간만을 기준으로 IPv4 서버 또는 IPv6 서버를 선택한다.
도 6A는 종래 기술에 따른 IPv6 서버가 없는 예시적인 시나리오를 도시한다.
IPv6 서버가 없는 시나리오를 고려. 그러면 최종 서버는 그림 6A에 표시된 것처럼 IPv4만 사용한다. 예를 들어 인도와 같은 많은 국가에서 응용 프로그램의 80%에 IPv6 서버가 없다. 따라서, 이러한 시나리오에서는 추가적인 DNS 질의 시간이 필요하지 않기 때문에 CAA 기반 스케줄링을 제공하는 단말(UE, 100)의 제안된 방법이 활용된다.
도 6B는 본 개시의 실시 예들에 따른, IPv6 서버가 존재하지 않는다는 결정에 대한 응답으로 IPv4 서버에 연결하는 예시적인 시나리오를 도시한다.
도 6B를 참조하면 다음 세 가지 경우를 고려:
1. 제1 기존 운영 체제는 해피 아이볼(happy eyeball)이 활성화(enable)되지 않은 단말(UE, 100)를 활성화.
2. 해피 아이볼이 활성화된(enabled) 단말(UE, 100)를 활성화하는 제2 기존의 운영 체제.
3. 제안된 ILAT 솔루션을 실행하는 ILAT 활성화된 단말(UE, 100).
일반적으로 DNS64는 A RR(resource record, 리소스 레코드)에서 AAAA RR를 합성하기 위한 메커니즘이다. 원래 A RR에서 DNS64에 의해 생성된 합성 AAAA RR에는 원래 A RR과 동일한 소유자 이름이 포함되지만 IPv4 주소 대신 IPv6 주소가 포함된다. IPv6가 없으면 DNS64 서버는 IPv4를 합성된 IPv6으로 변환하고 응답을 보낸다.
제1의 경우, 제1 기존 OS 활성화된 단말(UE, 100)는 IPv6 서버에 연결한다. 제2의 경우, 제2 기존 OS 활성화된 단말(UE, 100)는 IPv6 서버 및 IPv4 서버 중에서 하나에 연결된다. 제3의 경우, 제안된 ILAT 활성화된 단말(UE, 100)는 IPv4 서버에만 연결한다.
제안된 ILAT 활성화된 단말(UE, 100)는 최초의 기존 OS 활성화된 단말(UE, 100)와 비교할 때, 하나의 RTT(DNS) 및 하나의 연결 리소스(IPv6 DNS 소켓)이 더 나은 절약을 제공한다. 또한, 제안된 ILAT 활성화된 단말(UE, 100)는 기존의 제2 OS 활성화된 단말(UE, 100)와 비교할 때 IPv6 연결 및 2개의 연결 리소스들(IPv6 DNS 및 IPv6 TCP 소켓)을 회피한다.
도 7A는 종래 기술에 따라 IPv6 서버의 성능과 IPv4 서버의 성능이 동등하게 좋은 시나리오의 예시를 도시한다.
IPv6와 IPv4가 똑같이 좋은 시나리오를 고려. 기존 서버에서는 IPv6와 IPv4 모두에 동일한 RTT(round-trip-time) 및 TP가 제공된다. 그러나 제안된 방법에서는 CLAT 오버 헤드를 피하기 위해 다이렉트 IPv6를 선호한다.
도 7B는 본 개시의 실시 예들에 따른, IPv6 서버의 성능과 IPv4 서버의 성능이 동일하다고 결정한 것에 대한 응답으로 IPv6 서버에만 접속하는 예시적인 시나리오를 도시한다.
IPv4 서버 성능과 IPv6 서버 성능간에 큰 차이를 제공하지 않는 서버를 고려. 통상적으로, 제1 기존 OS 활성화된 단말(UE, 100)는 IPv6 서버에 연결하고, 제2 기존 OS 활성화된 단말(UE, 100)는 IPv6 서버 및 IPv4 서버 중에서 하나에 접속한다; 및 제안된 ILAT 활성화된 단말(UE, 100)는 IPv4 서버에만 연결된다.
제안된 ILAT 활성화된 단말(UE, 100)는 최초의 기존 OS 활성화된 단말(UE, 100)와 비교할 때, 하나의 RTT(DNS) 및 하나의 연결 리소스(IPv4 DNS 소켓)이 더 나은 절약을 제공한다.
제안된 ILAT 활성화된 단말(UE, 100)은 제2 기존 OS 활성화된 단말(UE, 100)과 비교할 때:
a) IPv4에 연결된 경우: 2 연결 리소스(IPv6 DNS 및 IPv6 TCP 소켓) 및 CLAT 이중 처리 오버 헤드.
b) IPv6에 연결된 경우: 2 개의 연결 리소스(IPv6 DNS 및 IPv6 TCP 소켓). 제안된 방법은 이중 CLAT 처리를 제공하여 처리량 및 CLAT 헤더 수준 오버 헤드를 감소시킨다.
도 8A는 종래 기술에 따라 IPv6 서버가 존재하지만 IPv4 서버의 성능이 IPv6 서버의 성능보다 우수한 시나리오의 예를 도시한다.
도 8A를 참조하면, 복수의 서버 중에서 일부 서버는 IPv4를 활성화하고, 복수의 서버 중에서 일부 다른 서버는 IPv6를 활성화한다. 그러나 IPv6 서버가 있다. 그러나 IPv6 사용 서버의 성능은 IPv4 사용 서버의 성능만큼 좋지 않다. 즉, 기존 방법에서 RTT 차이가 20ms 이상이다.
제안된 방법에서 단말(UE, 100)는 오버 헤드 문제가 있지만 CAA 기반 스케줄링을 제공한다.
도 8B는 본 개시의 실시 예들에 따른, IPv4 서버의 성능이 IPv6 서버의 성능보다 우수하다는 결정에 대한 응답으로 IPv4 서버에 연결하는 예시적인 시나리오를 도시한다.
IPv4 서버 성능과 IPv6 서버 성능 간에 큰 차이를 제공하지 않는 서버인 IPv6 성능보다 IPv4 성능이 더 좋은 서버가 여러 개 있음을 고려. 또한 위에서 언급한 시나리오에서는 이중 처리를 무시할 수 있다. 통상적으로, 제1 기존 OS 활성화된 단말(UE, 100)는 IPv6 서버에 연결하고, 제2 기존 OS 활성화된 단말(UE, 100)는 IPv6 서버 및 IPv4 서버 중에서 하나에 접속한다; 및 제안된 ILAT 활성화된 단말(UE, 100)는 IPv4 서버에만 연결된다.
제안된 ILAT 활성화된 단말(UE, 100)는 최초의 기존 OS 활성화된 단말(UE, 100)와 비교하여 RTT(DNS) 및 1 연결 리소스(IPv6 DNS 소켓)를 제공한다.
제안된 ILAT 활성화된 단말(UE, 100)은 제2 기존 OS 활성화된 단말(UE, 100)과 비교할 때 다음을 제공한다:
a) IPv6에 연결된 경우: 2 개의 연결 리소스(IPv4 DNS 및 IPv4 TCP 소켓) 및 감소된 처리량.
b) IPv4에 연결된 경우: 2 개의 연결 리소스(IPv6 DNS 및 IPv6 TCP 소켓).
도 9는 본 개시의 실시 예들에 따른, 제1 기존 OS 활성화된 단말(UE, 100), 제2 기존 OS 활성화된 단말(UE, 100) 및 제안된 ILAT 활성화된 단말(UE, 100)의 연결 시간 비교를 도시한다.
3 개의 UE와 병렬 테스트가 수행되었다, 즉, 제1 기존 OS 활성화된 단말(UE, 100), 제2 기존 OS 활성화된 단말(UE, 100) 및 제안된 ILAT 활성화된 단말(UE, 100)가 수행되었다. 연결 시간은 테스트에서 성능 평가 매개 변수로 사용된다.
도 9를 참조하면, 제안된 ILAT 활성화된 단말(UE, 100)는 항상 제1의 기존 OS 활성화된 단말(UE, 100)(예를 들어, 안드로이드)보다 성능이 우수하다. 제안된 ILAT 활성화된 단말(UE, 100)는 적어도 30%의 애플리케이션(도 9에 도시된 바와 같이)에서 제2의 통상적인 OS 활성화된 단말(UE, 100)(즉, 예를 들어, 해피 아이볼)보다 더 잘 수행한다. 고려할 수 있는 또 다른 메트릭은 리소스 사용률이다. 제안된 ILAT 활성화된 단말(UE, 100)는 제2 기존 OS 활성화된 단말(UE, 100)보다 50% 적은 연결을 사용하고 제1 기존 OS 활성화된 단말(UE, 100)보다 25% 적은 연결을 사용한다.
기존의 안드로이드 지원 단말(UE, 100)에서는 해피 아이볼이 구현되지 않았다. 따라서 제안된 ILAT 활성화된 단말(UE, 100)로 평가하는 동안, 적어도 1-RTT가 저장된다(도 6A-도 8B에서 설명됨).
테스트는 대기 시간이 긴(50-100ms) 네트워크에서 수행된다. 따라서 최소 100ms가 절약된다. 예를 들어, RTT 감소로 인해 서버가 최상이고 안정적인 경우 PLT는 제1 OS 사용 단말(UE, 100)에서 400ms이고 ILAT 사용 단말(UE, 100)이 있는 PLT는 300ms이다. 따라서 제안된 방법을 사용하면 25%의 효율을 얻을 수 있다.
또한 생성된 리소스의 수는 전력 소비에 영향을 미치기 때문에 기존 OS 지원 단말(UE, 100)에서 또 다른 중요한 벤치 마크다. 하나의 단일 응용 프로그램은 평균적으로 약 10-20 개의 연결을 열 수 있다.
따라서 기존 OS에서는 약 20~40 개의 TCP 연결이 필요하며 약 10~20 개의 DNS 쿼리가 생성된다. 그러나 제안된 ILAT 사용 방법에서는 TCP 연결 수가 약 10~20 개로 절반으로 줄어들고 DNS 쿼리 수도 5~10 개로 줄어든다.
도 10A는 본 개시의 일 실시 예에 따른, 기존의 단말(UE, 100) 및 CAA 활성화된 단말(UE, 100)에서의 패킷 처리의 비교를 도시한다.
도 10A를 참조하면, 기존의 단말(UE, 100) 및 CAA 활성화된 단말(UE, 100)에서의 패킷 처리가 모두 도시된다. 기존의 단말(UE, 100)에서 패킷 처리는 리틀 코어와 빅 코어 모두에서 발생한다. 빅 코어들을 많이 사용하면 단말(UE, 100)의 처리 시간과 전력 소비가 증가한다.
CAA 활성화된 단말(UE, 100)에서, CAA 스케줄러(180)는 실시간 CPU 부하를 추정하고 패킷을 동적으로 분류한다. CAA 활성화된 단말(UE, 100)는 CAA 스케줄러(180)에서 할당 및 필요한 처리 시간을 계산함으로써 동작 조건에 동적으로 적응함으로써 전력 효율을 증가시킨다.
도 10B는 본 개시의 일 실시 예에 따른, CAA 활성화된 단말(UE, 100) 및 CAA LITE 활성화된 단말(UE, 100)에서의 패킷 처리의 비교를 도시한다.
제안된 방법은 두 가지 버전, 즉, CAA 활성화된(enabled) 단말(UE, 100) 및 CAA LITE 활성화된 단말(UE, 100)에서의 패킷 처리를 포함한다.
CAA 활성화된(enabled) 단말(UE, 100)에서, CAA 스케줄러(180)는 실시간 CPU 부하를 추정하고 패킷을 동적으로 분류한다. CAA 활성화된 단말(UE, 100)는 CAA 스케줄러(180)에서 할당 및 요구되는 처리 시간을 계산함으로써 동작 조건에 동적으로 적응한다. 또한, CAA 활성화된 단말(UE, 100)는 또한 단말(UE, 100) 상태를 이해하기 위해 CPU 상태, 배터리 상태, 무선 파라미터, 디스플레이 상태와 같은 추가적인 크로스 레이어 정보를 가져오고 전력 효율을 제공하기 위해 패킷을 스케줄링한다.
CAA LITE 활성화된 단말(UE, 100)는 CPU(0x0F) 4, 5, 6, 7의 CLAT 패킷과 CPU(0xF0) 0, 1, 2, 3의 non-CLAT 패킷을 바인딩한다. 패킷로드 또는 작동 조건에 관계없이 모든 CPU 코어가 활성화되고 선호도가 위에서 언급한 CPU 코어에 바인딩된다. 반면, CAA 활성화된 단말(UE, 100)는 추가 정보를 가져오고 단말(UE, 100)를 전력 효율화하기 위해 동적으로 적응한다. 도 10B에서는 작은 코어들만 사용된다. 빅 코어들은 필요할 때까지 활성화되지 않는다.
CAA-LITE는 CLAT 패킷의 선호도가 특정 CPU 코어로 고정되는 경량 방법이다. CAA LITE 활성화된 단말(UE, 100)에서, CAA 스케줄러(180)는 추가 정보없이 특정 CPU 코어에 CLAT 패킷의 선호도를 할당한다. CAA LITE 버전의 목적은 전력 소비를 고려하지 않고 처리량을 늘리는 것이다. 작동 조건에 관계없이 CAA LITE는 항상 CLAT 및 non-CLAT 패킷을 각 CPU 코어에 바인딩한다.
도 11은 본 개시의 일 실시 예에 따른, 패킷의 IP 헤더에 기반하여 패킷을 적어도 하나의 클래스로 분류하는 방법을 예시한다.
패킷을 효과적으로 스케줄링하기 위해 먼저 패킷을 CLAT 패킷과 non-CLAT 패킷으로 구분한다. 또한, CAA 분류기(182)는 도 11에 도시된 바와 같이 패킷의 IP 헤더를 처리하여 3 개의 클래스 중에서 적어도 하나의 클래스로 패킷을 분류한다.
응용 프로그램과 로컬에서 처리되는 CLAT 데몬간에 전달되는 패킷은 클래스 A(class A)로 분류된다. 단말(UE, 100)의 인터페이스 RMNET과 PLAT 서버간에 전송되는 패킷은 클래스 B(class B)로 분류된다. 다이렉트 IPv6 라이브 에어 연결 및 기타 로컬 UNIX 소켓 전송을 포함하는 클래스 A 및 클래스 B로 분류된 패킷을 제외한 다른 모든 패킷은 클래스 C(class C)로 분류된다. 패킷의 분류에 기반하여, 패킷이 표시되고 CAA 스케줄러(180)는 패킷의 클래스에 기반하여 패킷을 처리한다.
도 12는 본 개시의 일 실시 예에 따른, 패킷을 높은 우선 순위 큐(high priority queue), 중간 우선 순위 큐(mid priority queue) 및 일반 우선 순위 큐(normal priority queue) 중에서 하나로 분류하고 큐를 기반으로 패킷을 스케줄링하는 방법을 도시한다.
CAA CPU 컨트롤러(184)는 CAA 분류기(182)로부터 클래스 A(class A), 클래스 B(class B) 및 클래스 C(class C) 중에서 적어도 하나의 클래스로 분류된 패킷을 수신한다. 도 12를 참조하면, 적어도 하나의 클래스로 분류된 패킷을 사용하여 다중 큐를 생성한다.
우선 순위가 높은 큐에는 로컬에서 처리되는 패킷이 포함된다. 따라서 처리 시간과 패킷 지연은 우선 순위가 높은 큐의 패킷에 대해 매우 낮거나 무시할 수 있다. 중간 우선 순위 큐에는 PLAT와 단말(UE, 100)간에 거래되는 패킷이 포함된다. 패킷 지연은 클라이언트에 대한 최종 서버의 왕복 시간에 따라 다르다. 처리 시간은 우선 순위가 높은 큐만큼 낮지 않다. 일반 우선 순위 큐에는 CLAT 및 PLAT를 제외한 다른 패킷으로 처리된 패킷이 포함된다. 분류된 패킷은 멀티 코어 프로세서(120)의 복수의 코어와 차례로 연관되는 복수의 큐에서 처리된다.
분류된 정보를 기반으로 패킷을 분류하면 처리량이 1.2배 향상된다. 단일 코어에서 클래스 A 패킷의 처리는 처리량에 80%까지 영향을 미치고 멀티 코어 프로세서(120)의 복수의 코어들에서 클래스 A로 분류된 패킷의 동적 할당은 처리량에 90%까지 영향을 미친다. 처리량이 향상되는 이유는 패킷 지연이 감소하고 패킷이 애플리케이션으로 떨어졌기 때문이다. 멀티 코어 프로세서(120)의 코어들 중에서 하나가 비어 있거나 적은 부하로 실행중인 경우 CAA 스케줄러(180)는 과중한 부하의 코어에서 빈 코어 또는 적은 부하로 실행중인 코어로 연결을 이동한다. 과중한 부하의 코어는 RPS 제어를 사용하기 위해 더 많은 처리 시간이 필요하다. 제안된 방법에서는 연결을 다른 코어로 이동하여 피할 수 있다. 과중한 부하의 코어에서 코어로 패킷을 이동하면 리눅스 커널 스택에서 끊어진 지역성이 향상된다. 또한, 동일한 부하를 갖는 복수의 코어들이 있는 경우, CAA 스케줄러(180)는 라운드 로빈(round-robin) 패러다임을 사용하여 복수의 코어들 사이에서 패킷을 푸시한다.
동일한 클래스에 속하는 패킷 또는 동일한 연결에 속하는 패킷이 CAA 스케줄러(180)에 도착하면, CAA 스케줄러(180)는 글로벌 매핑 테이블이 영향을 받지 않도록 패킷을 동일한 코어로 푸시할 것이다. 코어들은 두 가지 상태들을 가질 수 있다, 즉, 활성 상태와 유휴 상태다. CAA 스케줄러(180)는 복수의 코어들 중에서 더 많은 수의 코어들이 유휴 상태가 되도록 미세 조정함으로써 더 나은 전력 소비를 달성한다. CAA 스케줄러(180)는 2단계 동작, 즉, CPU 주파수 튜닝 및 CPU 어피니티 수정에 의해 더 나은 전력 소비를 달성한다.
CAA 스케줄러(180)는 추정된 패킷 도착률에 따라 CPU 주파수를 비례적으로 제어한다. 처음에는 모든 작은 코어들이 데이터를 처리하는 데 완전히 활용된다. 작은 코어들은 대부분의 인터넷 및 비디오 스트리밍 응용 프로그램을 처리하는 데 사용할 수 있다. 그러나 다운로드가 많은 경우 CAA 스케줄러(180)는 레벨 튜닝을 사용한다. 활성 CPU의 예상 패킷 손실이 더 높을 것으로 예상되는 경우(예: 활성 CPU가 데이터 패킷의 로드를 처리할 수 없는 경우) 빅 코어도 활성화된다. 활성 CPU 중에서 다른 클래스의 패킷은 우선 순위 큐에 따라 처리된다.
도 13은 본 개시의 일 실시 예에 따른, 데이터 패킷의 이중 처리없이 이중 IP 아키텍처에서 패킷의 분류를 예시한다.
기존의 이중 IP 아키텍처에서 CLAT의 주요 단점 중에서 하나는 데이터 패킷의 이중 처리다.
도 13을 참조하면, 제안된 방법에서는 IP 헤더를 기반으로 패킷을 적어도 하나의 클래스로 분류하고 각 IP 헤더로 패킷을 표시함으로써 패킷의 이중 처리를 피할 수 있다. 따라서 제안된 방법은 패킷의 이중 처리를 방지하여 이중 IP 아키텍처의 네트워크 성능에 대한 향상된 설계 및 최적화를 제공한다.
도 14는 본 개시의 실시 예들에 따른, 제안된 방법의 평가를 위한 라이브 에어 실험 설정을 예시한다.
도 14를 참조하면, 실험 설정은 다양한 네트워크 및 운영 조건에서 수행된 실험 결과를 기반으로 한 심층 분석이 뒤 따르는 평가를 위해 사용된다. 실험 설정에는 4G+(LTE advanced) 모바일 네트워크에 연결된 단말(UE, 100)이 포함된다.
도 15A는 본 개시의 실시 예들에 따른, IPERF(internet performance working group) 테스트를 사용하는 기존의 OS 활성화된(enabled) 단말(UE, 100), CAA-LITE 활성화된 단말(UE, 100) 및 CAA 활성화된 단말(UE, 100)의 성능의 비교를 도시한다.
도 15B는 본 개시의 실시 예들에 따른, NIA 테스트를 사용하는 기존의 OS 활성화된(enabled) 단말(UE, 100), CAA-LITE 활성화된 단말(UE, 100) 및 CAA 활성화된 단말(UE, 100)의 성능의 비교를 예시한다.
도 14와 함께 도 15A 및 도 15B를 참조하면, 단말(UE, 100)의 LTE-A 네트워크는 최대 600Mbps까지 도달할 수 있는 Cat 11 3CA(carrier aggregation)를 사용한다. 도 15A 및 도 15B에서 가리키는 각각의 데이터는 레거시 및 제안된 CAA 활성화된 단말(UE, 100) 및 CAA-LITE 활성화된 단말(UE, 100)에 대한 10 개의 트레일을 나타낸다. 결과는 평균 편차 막대로 보고된다. 도 15A 및 도 15B에서 채택된 주요 성능 측정은 다운로드 동안의 평균 처리량이다.
처리량에 대한 영향은 IPERF 테스트(도 15A에 표시됨) 및 NIA 테스트(도 15B에 표시됨)와 같은 다양한 도구를 사용하여 측정된다. 또한 제안된 방법은 서로 다른 위치(다양한 RTT)에 있는 서버를 사용하여 결과를 캡처했다. 다양한 테스트 및 서버 결과는 CAA 활성화된 단말(UE, 100) 및 CAA-LITE 활성화된 단말(UE, 100)가 애플리케이션 및 서버 종속성에 관계없이 기존의 OS 활성화된 단말(UE, 100)를 능가한다는 것을 나타낸다.
또한, 도 15A 및 도 15B에서, 조건에 관계없이 CAA 활성화된 단말(UE, 100) 및 CAA-LITE 활성화된 단말(UE, 100) 모두가 더 큰 마진에 의해 기존의 OS 활성화된 단말(UE, 100)를 능가한다는 것을 나타낸다. CAA 활성화된 단말(UE, 100)는 CPU 부하에 따라 동적으로 적응함으로써 전체 처리량을 약 92% 향상시킨다.
도 16A는 본 개시의 실시 예들에 따른, 기존의 OS 활성화된(enabled) 단말(UE, 100), CAA-LITE 활성화된 단말(UE, 100) 및 CAA 활성화된 단말(UE, 100)의 처리량을 비교하기 위한 랩 시뮬레이션 설정을 예시한다.
시뮬레이션은 전송 레이어의 일부로 수행된다. 도 16A를 참조하면, 단말(UE, 100)는 다양한 대역폭, 무선 및 네트워크 조건을 시뮬레이션하기 위해 시뮬레이션 장비에 연결된다. 또한 시뮬레이션 장비는 PLAT 서버에 차례로 연결된다. IPv4 서버는 PLAT 서버에 연결되고 IPv6 서버는 시뮬레이션 장비에 직접 연결된다.
도 16B는 본 개시의 실시 예들에 따른, 기존의 OS 활성화된(enabled) 단말(UE, 100), CAA-LITE 활성화된 단말(UE, 100) 및 CAA 활성화된 단말(UE, 100)의 처리량의 비교의 그래픽 표현이다.
유휴 상태에서 모바일 무선 패킷 손실은 0.00000001%에서 0.00001%까지 다양할 수 있고 왕복 시간은 네트워크 상태에 따라 10ms에서 15ms까지 다양할 수 있다는 점을 고려하여 제안된 방법은 여러 시나리오를 시뮬레이션했다.
서버는 다른 포트에 있는 IPERF 서버와 다른 포트에 있는 HTTP 서버로 호스팅된다. 도 15B에 표시된 각 데이터는 10 개의 트레일들로부터의 평균값을 나타낸다. 평가를 위해 채택된 주요 성능 측정은 애플리케이션의 평균 처리량이다. 테스트는 한 번에 개별 단말(UE, 100)를 순차적으로 취하여 수행된다.
도 16B를 참조하면, CAA는 HTTP 설정에서 80%까지, IPERF 설정에서 최대 90%까지 처리량을 지속적으로 개선했다. HTTP와 IPERF의 차이점은 IPERF에는 관련된 파일 I/O 작업이 없다는 것이다.
도 17A는 본 개시의 실시 예들에 따른, 기존의 OS 활성화된(enabled) 단말(UE, 100), CAA-LITE 활성화된 단말(UE, 100) 및 CAA 활성화된 단말(UE, 100)에 대한 전력 소비의 비교의 그래픽 표현이다.
도 17B는 본 개시의 실시 예들에 따른, 기존의 OS 활성화된(enabled) 단말(UE, 100), CAA-LITE 활성화된 단말(UE, 100) 및 CAA 활성화된 단말(UE, 100)에 대한 전력 절약의 비교의 그래픽 표현이다.
CAA, CAA-LITE 및 기존 OS에서 각각 실행되는 3 개의 동일한 단말(UE, 100)에서 전력 테스트가 수행된다. 단말(UE, 100)는 미리 정해진 순서대로 여러 서버로부터 파일을 다운로드한다. 처음에, 3 개의 동일한 단말(UE, 100)가 완전히 충전되고(100%) 배터리 소비가 도 17A에 도시된 바와 같이 지속 시간에 대해 플롯(plot)된다.
도 17A를 참조하면, CAA 활성화된 단말(UE, 100)는 CAA-LITE 활성화된 단말(UE, 100) 및 기존의 OS 활성화된 단말(UE, 100)와 비교할 때 전력 효율적이다. 3 개의 동일한 단말(UE, 100)에서 절약된 전력의 백분율이도 17B에 도시되어 있다. 도 17A 및 도 17B에 기반하여, CAA-LITE 활성화된 단말(UE, 100)는 더 나은 처리량을 달성한다. 그러나 정적으로 선호도를 할당하면 전력 소비가 영향을 받는다. CAA 활성화된 단말(UE, 100)의 경우, 여러 레벨의 정보를 가져와서 패킷이 효율적으로 스케줄링되어 전력을 최대 22%까지 절약할 수 있다.
또한, 멀티 코어 스케줄링 알고리즘에 중점을 두고 단말(UE, 100)의 대역폭 활용에 대한 DUAL IP 아키텍처의 효과도 테스트된다. CAA 스케줄러(180)는 듀얼 스택 단말(UE, 100)에서 개선된 처리량을 달성하기 위해 멀티 코어(120) 시스템의 복수의 코어들 사이의 네트워킹 패킷을 스케줄링한다. 또한, 제안된 CAA LITE 활성화된 단말(UE, 100)는 최소한의 단계로 정적 어피니티 스케줄링을 제공한다.
수행된 다양한 테스트의 결과를 기반으로 CAA 활성화된 단말(UE, 100)는 다양한 운영 조건에서 약 90%의 향상된 처리량을 제공함으로써 기존 OS 활성화된 단말(UE, 100)를 능가했다. 따라서 제안된 스케줄링 방법은 전력 소비 감소와 함께 증가된 처리량을 제공한다.
특정 실시 예에 대한 전술한 설명은 다른 사람들이 현재 지식을 적용함으로써 일반적인 개념에서 벗어나지 않고 특정 실시 예와 같은 다양한 애플리케이션에 대해 쉽게 수정 및/또는 적응할 수 있도록 본 개시의 실시 예의 일반적인 특성을 완전히 드러 낼 것이다. 따라서, 그러한 적응 및 수정은 개시된 실시 예의 균등물의 의미 및 범위 내에서 이해되어야 하고 이해되도록 의도되어야 한다. 본 개시에서 사용된 어법 또는 용어는 설명을 위한 것이지 제한을 위한 것이 아님을 이해해야 한다. 따라서, 본 개시의 실시 예가 바람직한 실시 예의 관점에서 설명되었지만, 당업자는 본 개시의 실시 예가 본 개시에 설명된 실시 예의 사상 및 범위 내에서 수정되어 실행될 수 있음을 인식할 것이다.

Claims (15)

  1. 멀티 코어 프로세서를 포함하는 단말(user equipment, UE)에 의해 연결 및 CAA(CLAT aware affinity, customer side translator aware affinity, 고객측 변환기 aware affinity) 기반 스케줄링을 설정하는 방법으로서,
    CAA 스케줄러가, 상기 단말에서 패킷을 수신하는 과정과,
    상기 CAA 스케줄러가, 상기 패킷의 경로 특성을 결정하는 과정과,
    상기 CAA 스케줄러가, 상기 패킷의 경로 특성에 기반하여 IPv4 연결 또는 IPv6 연결 중에서 적어도 하나를 결정하는 과정과,
    상기 CAA 스케줄러가, 상기 결정된 IPv4 연결 또는 IPv6 연결 중에서 적어도 하나에 기반하여 IPv4 서버 및 IPv6 서버 중에서 적어도 하나에 대한 연결을 설정하는 과정을 포함하는 방법.
  2. 청구항 1에 있어서, 상기 CAA 스케줄러가, 상기 IPv4 서버 및 상기 IPv6 서버 중에서 적어도 하나에 대한 연결을 설정하는 과정은,
    상기 CAA 스케줄러가, 상기 IPv6 서버를 사용할 수 없다는 결정에 대한 응답으로 상기 IPv4 서버에 연결하는 과정과,
    상기 IPv6 서버의 성능 및 상기 IPv4 서버의 성능이 동일하다는 결정에 대한 응답으로 상기 IPv6 서버에 연결하는 과정과,
    상기 IPv4 서버의 성능이 상기 IPv6 서버의 성능보다 우수하다는 결정에 대한 응답으로 상기 IPv4 서버에 연결하는 과정 중에서 어느 하나를 수행하는 방법.
  3. 청구항 1에 있어서,
    상기 CAA 스케줄러가, 상기 패킷을 적어도 하나의 클래스로 분류하는 과정과,
    상기 CAA 스케줄러가, 상기 적어도 하나의 클래스에 기반하여 상기 멀티 코어 프로세서의 적어도 하나의 코어상의 상기 패킷을 스케줄링하는 과정을 더 포함하는 방법.
  4. 청구항 3에 있어서, 상기 CAA 스케줄러가, 상기 패킷을 적어도 하나의 클래스로 분류하는 과정은,
    상기 패킷의 IP 헤더가 IPv4 프리픽스(prefix) IP 주소 및 IPv6 프리픽스 IP 주소 중에서 하나를 포함하는지 여부를 결정하는 과정과,
    상기 패킷을, 상기 패킷의 IP 헤더가 상기 IPv4 프리픽스 IP 주소를 포함한다는 결정에 대한 응답으로 클래스 A 카테고리로 분류하고,
    상기 패킷의 IP 헤더가 상기 IPv6 프리픽스 IP 주소를 포함한다는 결정에 대한 응답으로 클래스 B 카테고리로 분류하고,
    상기 패킷의 IP 헤더가 상기 IPv4 프리픽스 IP 주소 또는 상기 IPv6 프리픽스 IP 주소에 대하여 모두를 포함하지 않는다는 결정에 대한 응답으로 클래스 C 카테고리로 분류하는 것 중에서 한 카테고리로 분류하는 과정을 포함하는 방법.
  5. 청구항 4에 있어서, 상기 클래스 A 카테고리는, CLAT 및 IPv4 헤더를 갖는 애플리케이션들 간의, 포워딩된 패킷 또는 로컬 패킷을 나타내는 방법.
  6. 청구항 4에 있어서, 상기 클래스 B 카테고리는, 합성된 IPv6 헤더를 사용하여, RMNET 및 PLAT(provider side translator, 제공자측 변환기) 간의, 실제 패킷들 또는 라이브 에어 패킷들을 나타내는 방법.
  7. 청구항 4에 있어서, 상기 클래스 C 카테고리는, 상기 단말 내부의, 다이렉트(direct) IPv6 헤더 또는 로컬 소켓 통신이 있는 패킷들을 나타내는 방법.
  8. 청구항 4에 있어서, 상기 CAA 스케줄러가, 상기 적어도 하나의 클래스에 기반하여 상기 멀티 코어 프로세서의 적어도 하나의 코어상에 있는 상기 패킷을 스케줄링하는 과정은,
    상기 패킷이 상기 클래스 A 카테고리, 상기 클래스 B 카테고리 및 상기 클래스 C 카테고리 중에서 하나로 분류되는지 여부를 결정하는 과정과,
    다음 중에서 하나를 생성하는 과정을 포함하고,
    상기 다음 중에서 하나를 생성하는 과정은,
    높은 우선 순위 큐를 생성하는 과정 및 상기 패킷이 상기 클래스 A 카테고리로 분류된 것으로 결정한 것에 대한 응답으로 상기 높은 우선 순위 큐에 상기 패킷을 표시하는 과정과,
    중간 우선 순위 큐를 생성하는 과정 및 상기 패킷이 상기 클래스 B 카테고리로 분류된 것으로 결정한 것에 대한 응답으로 상기 중간 우선 순위 큐에 상기 패킷을 표시하는 과정과,
    낮은 우선 순위 큐를 생성하는 과정 및 상기 패킷이 상기 클래스 C 카테고리로 분류된 것으로 결정한 것에 대한 응답으로 상기 낮은 우선 순위 큐에 상기 패킷을 표시하는 과정과,
    상기 CAA 스케줄러가, 상기 높은 우선 순위 큐, 상기 중간 우선 순위 큐 및 상기 낮은 우선 순위 큐 중에서 하나에 기반하여 상기 멀티 코어 프로세서의 적어도 하나의 코어에서 상기 패킷을 스케줄링하는 과정을 포함하는 방법.
  9. 청구항 8에 있어서, 상기 CAA 스케줄러가, 상기 높은 우선 순위 큐, 상기 중간 우선 순위 큐 및 상기 낮은 우선 순위 큐 중에서 하나에 기반하여 상기 멀티 코어 프로세서의 적어도 하나의 코어에서 상기 패킷을 스케줄링하는 과정은,
    상기 멀티 코어 프로세서의 동작 조건들을 모니터링하는 과정과,
    상기 동작 조건들, 상기 높은 우선 순위 큐, 상기 중간 우선 순위 큐 및 상기 낮은 우선 순위 큐 중에서 하나에 기반하여 상기 멀티 코어 프로세서의 CPU 어피니티를 수정하는 과정과,
    상기 수정에 기반하여 상기 멀티 코어 프로세서의 적어도 하나의 코어에서 상기 패킷을 스케줄링하는 과정을 포함하는 방법.
  10. 청구항 9에 있어서, 상기 동작 조건들은 CPU 부하, CPU 주파수, 현재 CPU 어피니티, RPS(receive packet steering, 수신 패킷 스티어링) 및 CAA 크로스 레이어 파라미터 중에서 적어도 하나를 포함하는 방법
  11. 청구항 10에 있어서, 상기 CAA 크로스 레이어 파라미터는 상기 단말의 무선 정보, 상기 단말의 배터리 정보, 상기 단말의 디스플레이 정보, RILD(radio interface layer daemon, RIL 데몬) 정보 및 NETD(network daemon, 네트워크 데몬) 정보 중에서 적어도 하나를 포함하는 방법.
  12. 청구항 8에 있어서, 상기 CAA 스케줄러가, 상기 높은 우선 순위 큐, 상기 중간 우선 순위 큐 및 상기 낮은 우선 순위 큐 중에서 하나에 기반하여 상기 멀티 코어 프로세서의 적어도 하나의 코어에서 상기 패킷을 스케줄링하는 과정은,
    상기 높은 우선 순위 큐, 상기 중간 우선 순위 큐 및 상기 낮은 우선 순위 큐 중에서 하나에 기반하여 상기 멀티 코어 프로세서의 CPU 어피니티를 수정하는 과정과,
    상기 수정에 기반하여 상기 멀티 코어 프로세서의 적어도 하나의 코어에서 상기 패킷을 스케줄링하는 과정을 포함하는 방법.
  13. 연결 및 CAA(CLAT aware affinity, customer side translator aware affinity, 고객측 변환기 aware affinity) 기반 스케줄링 설정을 위한 단말(user equipment, UE)로서,
    메모리;
    멀티 코어 프로세서; 및
    멀티 코어 프로세서 및 메모리에 연결된 CAA 스케줄러를 포함하고,
    상기 CAA 스케줄러는,
    상기 단말에서 패킷을 수신하고,
    상기 패킷의 경로 특성을 결정하고,
    상기 패킷의 경로 특성에 기반하여 IPv4 연결 또는 IPv6 연결 중에서 적어도 하나를 결정하고,
    상기 결정된 IPv4 연결 또는 IPv6 연결 중에서 적어도 하나에 기반하여 IPv4 서버 및 IPv6 서버 중에서 적어도 하나에 대한 연결을 설정하는 장치.
  14. 청구항 13에 있어서,
    상기 CAA 스케줄러는, 상기 IPv4 서버 및 상기 IPv6 서버 중에서 적어도 하나에 대한 연결을 설정하기 위하여,
    상기 IPv6 서버를 사용할 수 없다는 결정에 대한 응답으로 상기 IPv4 서버에 연결하고,
    상기 IPv6 서버의 성능 및 상기 IPv4 서버의 성능이 동일하다는 결정에 대한 응답으로 상기 IPv6 서버에 연결하고,
    상기 IPv4 서버의 성능이 상기 IPv6 서버의 성능보다 우수하다는 결정에 대한 응답으로 상기 IPv4 서버에 연결하는 것 중에서 하나를 수행하는 장치.
  15. 청구항 13에 있어서, 상기 CAA 스케줄러는,
    상기 패킷을 적어도 하나의 클래스로 분류하고,
    상기 적어도 하나의 클래스에 기반하여 상기 멀티 코어 프로세서의 적어도 하나의 코어상의 상기 패킷을 스케줄링하는 장치.
KR1020217006543A 2018-08-03 2019-08-02 멀티 코어 프로세서에서 연결 및 CAA(clat aware affinity) 기반 스케줄링 설정을 위한 방법 및 장치 KR20210029834A (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
IN201841029324 2018-08-03
IN201841029324(PS) 2018-08-03
IN201841029324(CS) 2019-07-31
PCT/KR2019/009688 WO2020027631A1 (en) 2018-08-03 2019-08-02 Apparatus and method for establishing connection and clat aware affinity (caa)-based scheduling in multi-core processor

Publications (1)

Publication Number Publication Date
KR20210029834A true KR20210029834A (ko) 2021-03-16

Family

ID=69232671

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020217006543A KR20210029834A (ko) 2018-08-03 2019-08-02 멀티 코어 프로세서에서 연결 및 CAA(clat aware affinity) 기반 스케줄링 설정을 위한 방법 및 장치

Country Status (3)

Country Link
US (1) US11606418B2 (ko)
KR (1) KR20210029834A (ko)
WO (1) WO2020027631A1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200112439A (ko) * 2019-03-22 2020-10-05 삼성전자주식회사 멀티 코어를 포함하는 전자 장치 및 이의 패킷 처리를 위한 방법

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2413464A (en) 2004-04-21 2005-10-26 Orange Sa An inter-working unit with a protocol conversion or protocol encapsulation function, for use with dual stack user equipment on a packet radio network
US9264341B2 (en) * 2009-07-24 2016-02-16 Broadcom Corporation Method and system for dynamic routing and/or switching in a network
CN103023797B (zh) 2011-09-23 2016-06-15 百度在线网络技术(北京)有限公司 数据中心系统及装置和提供服务的方法
CN102904976B (zh) 2012-10-23 2015-02-18 清华大学 基于前缀分配的扩展双重无状态IPv4-IPv6翻译方法
CN102984300B (zh) 2012-12-13 2015-11-18 北京邮电大学 一种4-6-4混合协议网络中分布式网关系统和访问方法
WO2017021081A1 (en) 2015-07-31 2017-02-09 Telefonaktiebolaget Lm Ericsson (Publ) System and method for enabling ipv6 networks

Also Published As

Publication number Publication date
WO2020027631A1 (en) 2020-02-06
US11606418B2 (en) 2023-03-14
US20210176302A1 (en) 2021-06-10

Similar Documents

Publication Publication Date Title
CN109792410B (zh) 压缩流量的服务质量优先级重新排序的系统和方法
CN110249596B (zh) 用于saas应用的基于qos的分类和优先级排序的学习技巧
Ascigil et al. On uncoordinated service placement in edge-clouds
JP6913177B2 (ja) より良好なqosのためのパス品質および接続優先度に基づくdns応答並べ替えのための方法
CN108353040B (zh) 用于分布式分组调度的系统和方法
US8638799B2 (en) Establishing network quality of service for a virtual machine
US7554909B2 (en) Dynamic service management for multicore processors
CN108270813B (zh) 一种异构多协议栈方法、装置及系统
CN110896373A (zh) 用于动态选择虚拟交换的资源的技术
CN105721535A (zh) 对服务功能链中的服务功能的并行处理
CN113676361A (zh) 针对体验质量度量的按需探测
Hegyi et al. Application orchestration in mobile edge cloud: Placing of IoT applications to the edge
US10360514B2 (en) Method and system to dynamically enable SDN network learning capability in a user-defined cloud network
US20170214625A1 (en) System and method of providing increased data optimization based on traffic priority on connection
US11606418B2 (en) Apparatus and method for establishing connection and CLAT aware affinity (CAA)-based scheduling in multi-core processor
Caraguay et al. Framework for optimized multimedia routing over software defined networks
Bays et al. Flow based load balancing: Optimizing web servers resource utilization
Bifulco et al. CATENAE: A scalable service function chaining system for legacy mobile networks
US11374874B2 (en) Access control method, access control device, and data processing device
US11757742B2 (en) System and method to distribute traffic flows among a plurality of applications in a data center system
CN109818882B (zh) 一种执行QoS策略的方法及装置
Nahir et al. Distributed oblivious load balancing using prioritized job replication
Bolla et al. A high-end Linux based Open Router for IP QoS networks: tuning and performance analysis with internal (profiling) and external measurement tools of the packet forwarding capabilities
US10819632B2 (en) Routers and methods for traffic management
Bharti et al. CAA: CLAT Aware Affinity Scheduler for Next Generation Mobile Networks

Legal Events

Date Code Title Description
A201 Request for examination