KR20240058079A - 차량 데이터 - Google Patents

차량 데이터 Download PDF

Info

Publication number
KR20240058079A
KR20240058079A KR1020247005777A KR20247005777A KR20240058079A KR 20240058079 A KR20240058079 A KR 20240058079A KR 1020247005777 A KR1020247005777 A KR 1020247005777A KR 20247005777 A KR20247005777 A KR 20247005777A KR 20240058079 A KR20240058079 A KR 20240058079A
Authority
KR
South Korea
Prior art keywords
address
data packet
data
network
incoming
Prior art date
Application number
KR1020247005777A
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 KR20240058079A publication Critical patent/KR20240058079A/ko

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/302Route determination based on requested QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/302Route determination based on requested QoS
    • H04L45/304Route determination for signalling traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/66Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/74Address processing for routing
    • H04L45/745Address table lookup; Address filtering
    • 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
    • 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
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/46Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for vehicle-to-vehicle communication [V2V]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/48Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for in-vehicle communication
    • 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/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Traffic Control Systems (AREA)

Abstract

차량 내 데이터 트래픽을 분류하는 방법이 제공된다.

Description

차량 데이터
본 출원은 네트워크 트래픽을 분석하기 위한 방법 및 시스템에 관한 것이다. 특히 본 출원은 차량과 데이터 서비스 공급자들 간의 데이터 트래픽의 분석을 제공하는 방법 및 시스템에 관한 것이다.
차량 내 인터넷 트래픽 사용량은 해마다 증가하고 있다. 비디오 및 오디오 스트리밍 서비스들, 내비게이션 시스템들, 사용자 생성 컨텐츠 공유 등의 제공이 보편화되고 있다. 많은 새로운 차량들이 인터넷 연결을 제공받는다. 이를 가능하게 하는 다른 방식들은 차량의 온보드 진단(OBD: on-board diagnostics) 시스템에 장착될 수 있는 제3자 Wi-Fi 디바이스들의 사용을 포함한다. 연결이 제공되는 방식에 관계없이, 일단 제공되면 이는 통상적으로 차량과 요청된 트래픽과 연관된 적절한 데이터 서비스 공급자 간에 데이터 트래픽을 적절하게 라우팅하는 셀룰러 네트워크를 통해 제공된다. 이러한 서비스 공급자들의 예들은 Netflix, Spotify, Google 등을 포함한다.
도 1은 차량 내 네트워크 데이터의 통상의 제공을 위한 단순화된 아키텍처를 도시한다. 차량(105)은 셀룰러 네트워크(110)를 통해 셀룰러 서비스 공급자(115)와 통신하도록 구성된다. 셀룰러 네트워크는 트래픽의 해당 진출 포인트 및 진입 포인트가 됨으로써 차량(104)으로부터 외부 패킷 데이터 네트워크(PDN: packet data network)들로의 연결을 제공하는 패킷 데이터 네트워크 게이트웨이, PGW와 같은 통상의 네트워크 구성 요소들을 포함할 것이다. 셀룰러 서비스 공급자(115)는 차량(105)과 연관된다. 셀룰러 서비스 공급자(115)를 통해 네트워크 서비스들에 액세스할 수 있는 허가된 차량들은 통상적으로 해당 국제 모바일 가입자 식별자(IMSI: International Mobile Subscriber Identifier) 또는 해당 차량에 특정한 다른 모바일 디바이스 식별자들을 사용하여 식별된다. 네트워크 서비스에 대한 액세스 요청을 수신한 서비스 공급자(115)는 클라우드 기반 서비스 공급자(120)인 것으로 도 1의 개략도에 도시된 적절한 네트워크 서비스 공급자에게 트래픽을 라우팅한다. 도 1의 아키텍처는 엔드 포인트 데이터 소비 디바이스로서 차량(105)을 도시하지만 모바일 디바이스 네트워크들과 매우 유사한 방식으로 동작한다.
실제로, 서비스 공급자(115)에서 발생하는 일은 허가된 차량으로부터의 트래픽이 트래픽 요청과 연관된 적절한 목적지로 라우팅되는 것이다. 예를 들어, 요청이 음악 스트리밍 서비스에 대한 것인 경우, 해당 요청은 인터넷 기반 음악 스트리밍 서비스로 라우팅된다. 해당 요청이 비디오 스트리밍에 대한 것인 경우, 해당 요청은 인터넷 기반 비디오 스트리밍 서비스로 라우팅된다. 두 경우들 모두에서, 서비스 공급자(115)는 단순히 이러한 서비스들과 차량 사이의 트래픽을 라우팅한다. 통상의 배열들에서, 서비스 공급자(115)는 이러한 요청을 일반적으로 데이터 서비스들로서 단순히 분류하고, 상이한 유형들의 데이터 서비스들 간에 구별할 수 있는 능력을 갖지 않는다.
세분화된 서비스 레벨 상에서 차량 데이터 트래픽을 분류하고 또한 서비스당 사용되는 트래픽의 볼륨에 대한 임의의 세부 레벨을 제공하는 것과 연관된 문제들이 있다. 차량 내 트래픽에 대한 임의의 세부 분석의 결여는 임의의 레벨의 상세 네트워크 사용량을 식별하는 능력이 감소시키고 보안 및 운영 문제들을 포함한 이상(anomaly)들을 식별하는 능력들을 감소시킨다.
또한, 이에 의해 차량 제조사가 해당 차량 액세스를 전용 서비스 공급자(115)와 사전-연관시킬 수 있지만 차량 내에서 어떠한 데이터 서비스가 소비되는지 관리 가능할 필요가 있을 수 있는 문제들도 있다.
또한, 전용 채널들을 통해 해당 트래픽의 라우팅을 용이하게 하기 위해, 특정 네트워크 데이터 서비스 공급자들과 연관되는 것으로 특정 네트워크 트래픽을 식별 가능할 필요가 있다.
이러한 이유들로 네트워크 내에서 이용되는 실제 데이터 서비스들에 대해 증가된 세분성을 제공할 필요가 있다.
따라서, 본 출원의 제1 실시예는 청구항 1에 정의된 방법을 제공한다. 유리한 실시예들이 종속 청구항들에 제공된다. 본 방법을 제공하도록 구성된 네트워크 노드가 또한 제공된다.
본 발명의 일 양태에 따르면, 차량 내 데이터 트래픽을 분류하는 네트워크 노드에서의 방법이 제공되며, 본 방법은,
네트워크 노드에서 제1 네트워크 명칭 공간 및 제2 네트워크 명칭 공간을 정의하는 단계 ― 제1 네트워크 명칭 공간은 들어오는 요청 데이터 패킷들을 수신하고 응답 데이터 패킷들을 전달하도록 구성된 진입 네트워크 인터페이스를 포함하고, 제2 네트워크 명칭 공간은 들어오는 요청 데이터 패킷들을 수신하고 요청 데이터 패킷들을 전달하도록 구성된 진출 네트워크 인터페이스를 포함하고, 채널들이 제1 네트워크 명칭 공간과 제2 네트워크 명칭 공간 사이에 제공되어 진입 네트워크 인터페이스와 진출 네트워크 인터페이스 사이의 트래픽이 채널들을 통해 라우팅됨 ―;
차량으로부터, 네트워크 노드에서 복수의 들어오는 요청 데이터 패킷들을 수신하는 단계 ― 데이터 패킷들은 차량에서 실행되는 애플리케이션으로부터 발생함 ―;
복수의 들어오는 요청 데이터 패킷들 중 각각의 데이터 패킷에 대해:
데이터 패킷의 헤더로부터 데이터 패킷에 대한 소스 IP 주소를 추출하는 단계 ― 소스 IP 주소는 차량과 연관됨 ―;
데이터 패킷의 헤더로부터 데이터 패킷에 대한 목적지 IP 주소를 추출하는 단계 ― 목적지 IP 주소는 애플리케이션에 의해 요청된 서비스와 연관됨 ―;
데이터 패킷의 헤더를 검사함으로써 들어오는 데이터 패킷에 대한 데이터의 볼륨을 결정하는 단계;
라우팅 테이블에 대해 목적지 IP 주소를 확인하는 단계; 및
목적지 IP 주소가 라우팅 테이블 내에 정의된 것으로 결정할 시, 해당 목적지 IP 주소에 대해 정의된 채널을 통해 들어오는 데이터 패킷을 라우팅하는 단계, 또는
목적지 IP 주소가 라우팅 테이블 내에 정의되지 않은 것으로 결정할 시, 정의되지 않은 모든 목적지 IP 주소들에 대해 제공되는 디폴트(default) 채널을 통해 들어오는 데이터 패킷을 라우팅하는 단계;
들어오는 요청 데이터 패킷에 대해 결정된 데이터 볼륨에 기초하여 채널 볼륨 표시자를 업데이트하는 단계;
네트워크 노드로부터 요청 데이터 패킷들의 각각과 연관된 목적지 IP 주소들로 복수의 들어오는 요청 데이터 패킷들을 계속 송신하는 단계를 포함한다.
바람직하게는 들어오는 요청 데이터 패킷들은 셀룰러 데이터 네트워크를 통해 적어도 부분적으로 수신된다.
바람직하게는 라우팅 테이블은 동일한 목적지 IP 주소 트래픽에 대해 동일한 채널을 사용한다.
바람직하게는 본 방법은,
네트워크 노드로부터 목적지 IP 주소들로 복수의 들어오는 요청 데이터 패킷들을 계속 송신하는 것에 응답하여 네트워크 노드에서 복수의 들어오는 응답 데이터 패킷들을 수신하는 단계,
복수의 들어오는 응답 데이터 패킷들의 각각의 데이터 패킷에 대해:
데이터 패킷의 헤더로부터 데이터 패킷에 대한 목적지 IP 주소를 추출하는 단계 ― 목적지 IP 주소는 차량과 연관됨 ―;
데이터 패킷의 헤더로부터 데이터 패킷에 대한 소스 IP 주소를 추출하는 단계 ― 소스 IP 주소는 애플리케이션에 의해 요청된 서비스와 연관됨 ―;
데이터 패킷의 헤더를 검사함으로써 들어오는 데이터 패킷에 대한 데이터의 볼륨을 결정하는 단계;
라우팅 테이블에 대해 소스 IP 주소를 확인하는 단계; 및
소스 IP 주소가 라우팅 테이블 내에 정의된 것으로 결정할 시, 해당 소스 IP 주소에 대해 정의된 채널을 통해 들어오는 데이터 패킷을 라우팅하는 단계, 또는
소스 IP 주소가 라우팅 테이블 내에 정의되지 않은 것으로 결정할 시, 정의되지 않은 모든 소스 IP 주소들에 대해 제공되는 디폴트 채널을 통해 들어오는 데이터 패킷을 라우팅하는 단계;
들어오는 요청 데이터 패킷에 대해 결정된 데이터 볼륨에 기초하여 채널 볼륨 표시자를 업데이트하는 단계;
네트워크 노드로부터 응답 데이터 패킷들의 각각에 대한 목적지 IP 주소와 연관된 개개의 차량으로 복수의 들어오는 응답 데이터 패킷들의 각각을 계속 송신하는 단계를 포함한다. 목적지 IP 주소는 응답 데이터 패킷들의 각각에 대한 모바일 디바이스 식별자에 대해 프록시와 연관되거나 프록시로서의 역할을 할 수 있다는 것이 이해될 것이다.
바람직하게는 송신하는 단계는 셀룰러 데이터 네트워크를 사용하여 적어도 부분적으로 수행된다.
바람직하게는 라우팅 테이블은 동일한 소스 IP 주소 트래픽에 대해 동일한 채널을 사용한다.
바람직하게는 복수의 채널들의 각각은 차량에서 실행되는 별개의 애플리케이션들과 연관된다.
바람직하게는 본 방법은 라우팅 테이블 내에서 채널들을 정의하는 단계를 포함하고, 본 방법은 알려진 IP 주소 값들을 특정 채널들과 연관시키는 단계를 포함하여, 특정 채널과 연관된 IP 주소로 향하는 해당 트래픽이 해당 채널을 통해 라우팅된다.
바람직하게는 본 방법은 라우팅 테이블을 동적으로 업데이트하는 단계를 포함하고, 본 방법은 들어오는 DNS 요청 데이터 패킷에 대해 정의된 표현들의 집합에 대해 DNS 질의의 영역을 우선 매칭함으로써 패킷 검사를 수행하는 단계를 포함하고, 각각의 정의된 표현은 특정 서비스와 연관되고 매치가 발견되면, 본 방법은 요청 데이터 패킷에 대한 응답 데이터 패킷을 수신할 시, IP 주소 또는 영역에 대한 주소들을 갖는 라우팅 테이블을 업데이트하는 단계를 포함하여 해당 IP 주소들로 그리고 해당 IP 주소들로부터의 후속 트래픽이 DNS 요청 데이터 패킷에 대해 원래 매칭된 특정 서비스와 연관된 채널을 통해 라우팅될 것이다.
바람직하게는 본 방법은 라우팅 테이블을 동적으로 업데이트하는 단계를 포함하고, 본 방법은,
TLS 핸드셰이크를 식별하기 위해 업스트림 TLS 패킷들을 모니터링하는 단계,
TLS 핸드셰이크가 프로세스 중인지 결정할 시 패킷이 SNI 헤더를 포함하는지 여부를 결정하기 위해 패킷을 검사하는 단계,
SNI 헤더를 찾을 시, 헤더의 값을 추출하고 해당 값을 각각의 서비스에 대해 정의된 SNI 매칭 규칙들과 비교하는 단계,
SNI 규칙이 매칭되면, TLS 패킷의 목적지 IP 주소 헤더로 규칙을 소유하는 서비스에 대한 라우팅 테이블을 업데이트하는 단계를 포함한다.
본 발명의 추가 양태에 따르면, 프로세서, 제1 네트워크 인터페이스 및 제2 네트워크 인터페이스를 포함하는 네트워크 노드가 제공된다.
바람직하게는 네트워크 노드는 본 방법을 수행하도록 구성된다.
본 출원은 이제 첨부 도면을 참조하여 설명될 것이다.
도 1은 종래 기술에 따른 시스템의 네트워크 아키텍처를 도시하는 개략도이다.
도 2는 본 발명에 따른 시스템의 네트워크 아키텍처를 도시하는 개략도이다.
도 3은 특정 차량으로 그리고 특정 차량으로부터 전달되는 트래픽을 분석하는 특정 경우에서의 아키텍처를 개략적인 형태로 도시한다.
도 4는 차량으로부터 발생한 데이터가 라우팅될 수 있는 방식을 도시하는 프로세스 흐름이다.
도 5는 차량으로 향하는 데이터가 라우팅될 수 있는 방식을 도시하는 프로세스 흐름이다.
도 6은 본 교시의 시스템을 사용하여 생성될 수 있는 채널당 데이터 서비스들의 개요를 도시하는 히스토그램의 예이다.
도 7은 본 교시에 따라 채용될 수 있는 DNS 룩업(lookup) 프로세스 흐름의 일부의 예이다.
도 8은 본 교시에 따라 채용될 수 있는 DNS 룩업 프로세스 흐름의 다른 부분의 예이다.
도 9는 본 교시에 따라 채용될 수 있는 TLS 패킷 검사 프로세스 흐름의 예이다.
도 2는 본 발명에 따른 프로세싱 또는 분류 시스템(200)을 통합하는 네트워크 아키텍처이다. 프로세싱 또는 분류 시스템(200)은 이를 통해 목적지 서비스들로 흐르는 네트워크 트래픽을 분류하고 서비스당 트래픽의 볼륨에 대해 보고하도록 구성된다. 시스템(200)은 차량(105)으로부터 수신된 임의의 트래픽의 최종 목적지를 식별하고, 식별된 목적지를 해당 차량(105)에서 소비되는 데이터 서비스의 분류자로서 사용하도록 구성된다.
데이터 패킷들의 형태로 수신된 차량(105)으로부터 들어오는 트래픽은 해당 트래픽에 대한 목적지 IP 주소를 식별하기 위해 파싱(parsing)된다. 목적지 IP 주소를 결정한 후 시스템(200)은 해당 IP 주소가 알려진 데이터 서비스 공급자와 이미 사전 연관되어 있는지 여부를 결정하도록 구성된다. 알려진 데이터 서비스 공급자가 있는 것으로 결정 시, 시스템은 해당 데이터 서비스 공급자에 대한 트래픽 전용인 시스템 내의 채널을 통해 들어오는 트래픽을 채널링(channeling)한다. 데이터 서비스 공급자 A로 향하는 트래픽은 채널 A를 통해 라우팅되고, 데이터 서비스 공급자 B로 향하는 트래픽은 채널 B를 통해 라우팅되는 등이다. 목적지 IP 주소에 기초하여 전용 채널들을 통해 트래픽을 채널링함으로써, 트래픽이 패킷의 실제 페이로드(payload)에 대한 조사를 요구하는 것이 아니라 헤더 정보에 기초하여 분석 및 분류될 수 있다. 이는 트래픽의 실시간 최소 지연 분류를 용이하게 한다.
본 발명에 따른 분류 시스템은 임의의 하나의 채널을 통과하는 데이터의 볼륨이 그에 따라 특정 데이터 서비스들의 실제 사용량을 반영하고 모니터링, 보고 또는 다르게 제어될 수 있음을 보장한다는 것이 이해될 것이다.
시스템 기능은 5 개의 코어 블록들(205-225)로 시각화될 수 있지만, 이는 이해를 쉽게 하기 위한 것이며 하나의 블록을 참조하여 아래에서 논의되는 기능은 다른 블록에 의해 동일하게 제공될 수 있다는 것이 이해될 것이다. 기능 측면에서, 하지만 어느 하나의 특정 구현에 한정되지 않고, 시스템은 이하를 포함한다는 것이 이해될 수 있다.
구성 관리자(205)
구성 관리자(205)는 구성 옵션들을 검증하고 시스템(200)의 다른 구성 요소들에 대한 구성 업데이트들을 게시한다.
DNS 모니터(210)
DNS 모니터(210)는 시스템을 통과하는 DNS 트래픽을 스캐닝하며, 구성 관리자 데이터 구조들 내에 정의된 서비스 규칙들에 대한 응답들과 질의들을 비교하고, 매칭이 발견되면 라우팅 제어기(220)에 업데이트들을 게시한다.
SNI 모니터(215)
SNI 모니터(215)는 TLS 핸드셰이크들을 스캐닝하고 SNI 헤더들에 서비스 매칭 규칙들을 적용한다. 매치가 발견되면, 업데이트가 라우팅 제어기(220)에 게시된다.
라우팅 제어기(220)
라우팅 제어기는 시스템(200)을 통과하는 트래픽의 암시적 분류를 허용하도록 라우팅 테이블을 구성한다. 초기 라우팅 테이블 구성은 각각의 서비스의 구성에 포함된 IP 주소와 네트워크 범위들에 기초한다. 그러나, 라우팅 제어기는 또한 DNS 및 SNI 모니터들로부터 수신된 업데이트들에 응답하여, 런타임에서 라우팅 테이블들을 동적으로 수정할 수 있다.
EDR 생성기(225)
EDR 생성기(225)는 시스템의 각각의 채널을 통해 흐르는 패킷들의 헤더들을 모니터링하고 차량별 서비스별 트래픽을 요약한 정기적인 업데이트들을 게시한다.
분류 시스템(200)의 구성 요소 기능 블록들(205-225)은 관리 시스템(230)을 사용하여 구성 및 모니터링될 수 있다. 도 2는 별도의 디바이스, 관리 네트워크(235)에 제공되는 이러한 관리 시스템을 도시하지만, 이는 분류 시스템(200)을 통과하는 트래픽과 능동적으로 인터페이싱하는 기능적 구성 요소들로부터 관리 및 사후-프로세싱 기능을 시각적으로 분리하기 때문에 개략적인 복적을 위한 것임이 이해될 것이다. 관리 네트워크(235)는 또한 EDR 생성기(225)에 의해 게시된 EDR 데이터가 저장될 수 있는 데이터베이스(240) 및 데이터 분석 엔진(250)을 호스팅할 수 있다. 선택적인 실시예들에서 데이터베이스(240) 및/또는 분석 엔진(250)은 관리 시스템(230)과 별도로 하나 이상의 추가 디바이스들 상에 제공될 수 있다. 도 2의 시스템의 상세 사항들 중 일부가 도 3을 참조하여 추가로 논의된다.
본 교시를 임의의 하나의 특정 네트워크 운영 체제 등에 한정하려는 의도는 아니지만, 본 목적을 위해 분류 시스템(200)이 3 개의 네트워크 카드들을 갖는 LINUX 머신(물리적 또는 가상 머신일 수 있음) 상에서 호스팅되는 것으로 가정될 것이다.
제어 NIC(315)는 시스템(200)과 관리 네트워크(235) 사이의 통신을 제공한다. 제어 NIC(315)는 시스템(200)을 관리하는 데 사용되는 관리 시스템(230)으로부터 통신들을 수신하고 송신하는 데 사용될 수 있다. 제어 NIC(315)는 또한 EDR 생성기(225)로부터 데이터베이스(240) 및 분석 엔진(250)으로 데이터 송신을 제공하는 데 사용될 수 있다;
진입 NIC(305)는 차량과 통신하기 위해 진입 네트워크에 연결된다; 그리고
진출 NIC(310)는 차량에 의해 요청되는 서비스들과 같은 외부 네트워크 요소들과 통신하기 위해 진출 네트워크에 연결된다.
분류 시스템(200) 내에서 발생하는 프로세싱 중 적어도 일부를 개략적인 형태로 도시하는 도 3에 도시된 바와 같이, 분류 시스템은 2 개의 네트워크 명칭 공간, 즉, 진입 명칭 공간(301) 및 진출 명칭 공간(302)을 실행하도록 구성된다. 진입 NIC(305)는 진입 명칭 공간(301)에 위치되고, 진출 NIC(310)는 진출 명칭 공간(302)에 위치된다. 진입 네트워크는 요청 패킷들을 수신하고 응답 패킷들을 전달하는 데 사용된다. 진출 네트워크는 요청 패킷들을 전달하고 응답 패킷들을 수신하는 데 사용된다. 이러한 패킷들의 라우팅은 라우팅 제어기(220)에 의해 제어된다.
본 기술 분야의 통상의 기술자는 네트워크 명칭 공간이 IP 스택의 독립적인 구현임을 이해할 것이다. 별개의 명칭 공간 진입 및 진출 NIC들을 호스팅하는 것은 각각의 네트워크 상의 트래픽을 효과적으로 격리한다. 네트워크들 간에 패킷들을 송신하는 것은 패킷들이 명칭 공간들 간에 송신될 것을 필요로 한다. 개개의 명칭 공간들 사이의 이러한 송신을 달성하기 위해, 본 교시의 시스템은 개개의 명칭 공간들 사이에 로컬 이더넷 터널의 생성을 가능하게 하는 가상 이더넷(VETH: virtual Ethernet)의 알려진 Linux 구성을 채용한다. veth 쌍은 2 개의 엔드 포인트들을 갖는 가상 이더넷 연결이며; 하나의 엔드 포인트에 기입된 패킷들은 다른 엔드 포인트들로부터 판독될 수 있고, 그 반대의 경우도 마찬가지이다. 도 3의 호스트 시스템 내에서, 본 교시는 진입 명칭 공간(301)의 각각의 개개 쌍의 일 단부와 진출 명칭 공간(302)의 타 단부를 위치시킴으로써 네트워크 명칭 공간들을 브릿징(bridging)하기 위해 veth 쌍들 1-5를 사용한다.
트래픽의 분류를 준비하기 위한 시스템의 초기 구성의 일부로서, 본 교시는 초기에 분류되는 각각의 서비스에 대한 진입 및 진출 명칭 공간들 사이의 veth 쌍과 분류되지 않은 트래픽에 대한 하나의 추가 veth 쌍을 생성한다. 이러한 veth 쌍들은 분류된 트래픽이 흐르는 채널들로서 효과적으로 작용한다. 이러한 예에서, 분류되는 서비스들은 채널 A부터 D로 식별되는 서비스들인 반면, 최종 채널, 채널 E는 분류되지 않은 모든 트래픽이 라우팅되는 채널이다. 도시된 채널들 개수는 순전히 예시를 위한 것이며 다시 순전히 이해의 용이성을 위해 채널 A는 제1 음악 스트리밍 서비스에 사용될 수 있고 채널 B는 비디오 스트리밍 서비스에 사용될 수 있으며 채널 C는 제2 음악 스트리밍 서비스에 사용될 수 있고 채널 D는 Google 맵들에 의해 제공되는 것과 같은 내비게이션 서비스에 사용될 수 있고, 채널 E는 다른 모든 인터넷 트래픽-브라우징, 다른 데이터 서비스 공급자들 등에 사용될 수 있는 것으로 간주될 수 있다는 것이 이해될 것이다. 이러한 채널들의 개수 또는 특정 서비스들과의 연관은 시스템의 특정 요건들에 따라 변할 수 있다는 것이 이해될 것이다.
패킷-기반 네트워크를 통과하는 임의의 패킷은 헤더와 페이로드를 포함한다는 것이 이해될 것이다. 헤더는 페이로드를 전달하기 위한 데이터(예를 들어, 소스 및 목적지 네트워크 주소들)를 제공하는 제어 정보를 포함하고, 페이로드는 사용자 데이터를 포함한다. 본 시스템은 차량 발신 패킷들에 대한 목적지 주소와 차량 종단 패킷들에 대한 소스 주소를 검사함으로써 트래픽을 분류한다. 라우팅 테이블 내에서 특정 주소들을 특정 채널들과 연관시키는 엔트리들을 정의함으로써, 헤더 정보 내의 특정 주소를 식별할 때 라우팅 테이블의 엔트리들을 사용하여 패킷들을 적절한 veth 쌍으로 보내는 것이 가능하다. 따라서, 특정 채널을 통해 트래픽을 라우팅하는 행위는 트래픽을 특정 유형의 데이터 서비스와 연관된 것으로 암묵적으로 분류한다.
도 4는 차량 발신 트래픽을 라우팅하는 것과 연관된 프로세스 흐름을 도시한다. 패킷들은 차량으로부터 진입 NIC에 도달한다(단계 405). 통상적으로 실제 차량 식별자, VIN 또는 차량에 대한 모바일 식별자, IMSI는 진입 NIC(301)에서 볼 수 없다는 점이 이해될 것이다. 통상 트래픽 세션들마다, 차량으로부터 발생하는 트래픽은 이해될 바와 같이 셀룰러 네트워크(110)의 통상의 구성 요소인 패킷 게이트웨이(PGW: packet gateway)로 초기에 라우팅된다. PGW는 세션의 지속 시간 동안 차량에 IP 주소를 할당한다. PGW는 또한 MSISDN 식별자를 세션에 할당된 IP 주소와 상관시키는 데이터 피드(feed)를 게시한다. 본 교시에 따라 이러한 피드는 MSISDN이 분석 페이즈(phase) 동안 VIN/IMSI 대역 외로 확인될 수 있으므로 서비스 트래픽을 특정 차량들에 귀속시키기 위해 진입 및 진출 NIC를 통해 라우팅된 트래픽을 후속적으로 조정하는 데 사용될 수 있다. 예를 들어, 시스템(200)을 통해 라우팅되는 트래픽의 일정 비율은 개별 차량(105a)에 기인할 수 있는 반면, 트래픽의 다른 비율들은 차량들(105b 및 105c)에 기인할 수 있다. 통상적으로, 이러한 조정은 분석 엔진(250)에 의해 EDR 생성기(225)로부터의 채널 볼륨 데이터 및 PGW 피드의 오프라인 프로세싱을 통해 실시될 것이다. 따라서, 분석 엔진(250)은 채널별 및 차량별 기준으로 트래픽을 분석할 수 있다. 응답 패킷의 목적지 IP 주소와 개개의 차량의 MSISDN 사이에 연관이 있지만, 이는 통상적으로 패킷 게이트웨이(PGW)에서만 알려져 있다는 것이 이해될 것이다. 이러한 IP 주소는 특정 차량과 연관될 수 있지만 이는 통상적으로 PGW 자체로서 수행되지 않는다. 그럼에도 불구하고, 진입 NIC(301)에서 차량으로부터 패킷들이 수신되면, 헤더들이 목적지 IP 주소에 대해 확인된다(단계 410). 해당 IP 주소가 추출된 다음 라우팅 테이블에 대해 확인된다(단계 415). 매치가 있는 경우(단계 420), 이는 목적지 IP 주소에 따라 정의된 veth 쌍에 의해 제공되는 적절한 채널로 라우팅된다(단계 425).
목적지 IP 주소에 대해 정의된 라우팅 테이블에 정의된 명시적 루트가 없다는 사실로 인해 매치가 없다면(단계 420), 패킷들은 그 자체의 특정 veth 쌍과 연관된 디폴트 채널로 라우팅된다(단계 430). 도 3의 예에서, 이러한 디폴트 채널은 채널 5이며 다른 곳에서 분류되지 않은 모든 인터넷 트래픽과 연관된다.
두 시나리오(매치 또는 매치 없음)에서 패킷들은 진출 명칭 공간에서 veth 쌍에서 나가고 서비스와 연관된 업스트림 게이트웨이를 통해 또는 명시적인 게이트웨이가 구성되지 않은 경우 디폴트 게이트웨이를 통해 계속 라우팅된다. 그 후 패킷들은 패킷들이 송신되는 진출 NIC에 기입된다(단계 435).
도 5는 차량 종단 트래픽에 대한 등가의 프로세스를 도시한다. 패킷들은 진출 NIC에 도달하고(단계 505) 소스 IP 주소에 따라, 즉, 패킷들이 발생된 곳으로부터 적절한 veth 쌍으로 라우팅되는 정책이다. 이는 소스 IP 주소에 대한 헤더를 확인하고(단계 510) 식별된 소스 주소에 대한 라우팅 테이블을 확인(단계 515)함으로써 달성된다. 명시적인 정책 루트가 존재하지 않으면(매치 결정 단계 520에서 매치가 없음), 패킷들은 디폴트 veth 쌍을 통해 라우팅된다(단계 530). 명시적인 정책 루트가 존재하는 경우(매치 결정 단계 520에서 매치), 패킷들은 매치와 연관된 채널로 라우팅된다(단계 525). 두 시나리오에서, 패킷들은 진입 명칭 공간의 veth 쌍에서 나가고 목적지 주소와 연관된 다운스트림 게이트웨이를 통해 계속 라우팅된다. 이는 진입 NIC를 통해 송신된다.
IP 주소에 따라 트래픽을 분류함으로써, 채널들 중 임의의 하나를 통과하는 트래픽의 볼륨에 대해 시간 경과에 따른 데이터를 집계할 수 있다.
도 6은 컴퓨팅될 수 있는 시간 경과에 따른 트래픽의 히스토그램의 일 예를 도시한다. 이는 순전히 예시적이지만 시간이 지남에 따라 차량 또는 차량들의 그룹에 의해 이용되는 데이터 트래픽의 특성에 관한 의미 있는 데이터를 추출할 수 있음이 이해될 것이다. 데이터는 패킷들이 veth 쌍들의 각각을 통과할 때 패킷들의 헤더들을 검사함으로써 서비스당 트래픽을 계산함으로써 집계된다. 도 6의 데이터는 특정 차량(105)에 대응하는 하나의 특정 IP 주소와 연관된 채널별 데이터일 수 있거나, 시스템(200)을 통한 모든 트래픽(즉, 복수의 차량들(105a-c)로부터의 트래픽)과 연관된 집계된 채널별 데이터일 수 있다.
차량 발신 패킷들의 경우, 시스템은 패킷의 바이트들 수를 기록할 수 있고 이를 패킷 헤더들에서 발견되는 소스 IP 주소와 연관시키며; 차량 종단 패킷들의 경우 시스템은 헤더들로부터 바이트들의 수를 기록한 다음 이를 패킷 헤더들에서 발견되는 목적지 IP 주소와 연관시키도록 구성될 수 있다. 위에서 개략 설명한 바와 같이, 소스/목적지 IP 주소들은 PGW에 의해 게시된 데이터 피드와의 비교를 통해 특정 차량들과 상관될 수 있다. 이러한 방식으로 시스템은 각각의 차량에 대한 각각의 서비스에 대해 업로드 및 다운로드된 바이트들의 카운트를 유지할 수 있다. 이러한 통계는 정기적인 간격들에서 수집되고 데이터 프로세싱 및 분석을 위해 계속 전송되며, 이 시점에서 후속 사용을 위해 카운트들이 리셋되거나 보관된다.
시스템(200)에 의해 수집된 분류 데이터는 집계된 데이터세트로서 출력되고 저장 및/또는 추가 프로세싱을 위해 데이터베이스(240) 및/또는 분석 엔진(250)으로 전송된다.
일 예에서, 채널별 트래픽 데이터를 포함하는 집계된 데이터세트는 저장을 위해 시스템(200)으로부터 데이터베이스(240)로 전송된다. 분석 엔진(250)은 데이터베이스(240)로부터 집계된 데이터세트를 검색하고 프로세싱한다. 분석 엔진(250)은 특정 채널 상의 트래픽을 특정 IMSI, 차량 및/또는 차량들의 그룹과 연관시키기 위해 집계된 데이터세트를 플랫폼 데이터로 보강한다. 예를 들어, 특정 브랜드(예를 들어, VW, Porsche 등)의 모든 차량들에 의한 특정 서비스 공급자(예를 들어, Netflix, Spotify 등)의 사용은 보강된 집계 데이터세트로부터 추론될 수 있으며 이는 청구 및/또는 보고 데이터를 제공하는 데 사용될 수 있다.
분석 엔진(250)은 시스템(200)으로부터 출력되고 데이터베이스(240)에 저장된 채널별/IP 주소별 트래픽 데이터를 취하여 이를 조정하여 등가의 서비스별/차량별 트래픽 요약들을 생성한다. 소비된 데이터(업로드 및 다운로드)는 샘플링된 빈도로 수집되어 해당 데이터를 소비하는 서비스(사용자 가입 서비스)에 대해 저장된다.
필요한 라우팅 테이블을 생성하고 시스템을 통과하는 패킷들의 의미 있는 분류를 허용하기 위해, 시스템은 특정 데이터 서비스 공급자들에 의해 사용되고 있는 IP 주소들에 대한 지식을 필요로 한다. Spotify, Netflix 등과 같은 인기 있는 데이터 서비스 공급자들은 그 개개의 서비스들에 대해 알려진 영구 IP 주소들 또는 서브넷들의 리스트를 채용하는 것으로 알려져 있음이 이해될 것이다. 이는 해당 서비스에 대한 트래픽을 분류하는 초기 라우팅 구성을 생성하는 데 사용된다.
그러나, 이러한 정적 구성에 대한 향상에서, 본 시스템은 또한 DNS 및 TLS 패킷들을 검사함으로써 서비스에 대한 새로운 IP 주소들을 동적으로 탐색하도록 구성된다.
이러한 맥락에서 통상의 인터넷 트래픽 라우팅에 따라, 클라이언트 디바이스 상의 애플리케이션이 인터넷 호스트에 연결하려고 하지만 해당 호스트에 대한 이름만 갖는 경우(예를 들어, services.cubictelecom.com) DNS 룩업이 트리거링된다는 점이 이해될 것이다. 연결을 열기 위해, 디바이스(또는 네트워크 노드) 상에서 실행되는 애플리케이션은 주소를 필요로 한다. DNS의 역할은 이름을 조회하고 연관된 호스트에 접촉하는 데 사용될 수 있는 하나 이상의 IP 주소들을 반환하는 것이다. 본 교시에 따르면, 어떠한 특정 인터넷 서비스들이 특정 차량들에 의해 사용되는지에 대한 후속 분석을 용이하게 하기 위해 특정 채널들을 통해 특정 트래픽을 보내는 데 사용되는 라우팅 테이블들은 알려진 특정 서비스들별로 특정 IP 주소들로 채워진다. 이러한 방식으로, 라우팅 테이블은 알려진 서비스들에 대해 알려진 IP 주소들을 사용하여 해당 IP 주소들과 연관된 채널을 통해 해당 서비스들에 대한 트래픽을 라우팅할 것이다.
특정 서비스들은 해당 서비스와 연관된 정적 IP 주소들을 가지며, 본 발명의 시스템이 트래픽 분석이 필요할 것으로 예상할 수 있는 서비스에 대해, 해당 서비스들과 연관된 채널들에 대한 라우팅 테이블들은 해당 IP 주소들로 사전 구성될 수 있다. 복수의 IP 주소들이 하나의 서비스 공급자와 연관될 수도 있으며, 본 발명의 라우팅 테이블들은 하나의 전용 서비스에 대한 트래픽을 라우팅하기 위해 복수의 IP 주소들을 사용하는 것을 수용할 수 있다는 것이 이해될 것이다.
다른 서비스들의 경우 또는 특정 서비스가 특정 IP 주소들로 트래픽을 지오펜싱(geofencing)하는 예에 있어서도, 애플리케이션 요청을 서빙하는 데 사용되는 실제 IP 주소는 시간이 지남에 따라 다를 수 있다. 본 교시의 시스템은 서비스와 연관된 IP 주소들의 변화들을 식별하기 위해 들어오는 트래픽을 분석한 다음 해당 타깃 서비스에 대한 새로운 IP 주소가 발견되면 라우팅 테이블을 업데이트함으로써 이러한 유형의 동적 IP 주소들을 처리할 수 있다. 후속 패킷들의 분류에 사용되는 라우팅 테이블을 동적으로 업데이트하는 이러한 배열에서, 시스템은 정규 표현들의 집합에 대해 DNS 질의의 영역을 우선 매칭하여 DNS 패킷(UDP 포트(53)) 검사를 수행하도록 구성될 수 있다. 시스템 구성의 일부로서, 분석 채널이 필요한 각각의 서비스는 매칭시킬 정의된 정규 표현들의 세트를 가질 수 있다. 매치가 발견되면, 시스템은 요청 ID를 캐싱(caching)하고 대응하는 DNS 응답을 기다린다. 응답이 도달하면, 영역과 연관된 IP 주소들이 라우팅 제어기로 전달되며, 이는 서비스에 대한 라우팅 테이블 엔트리들을 업데이트한다. 해당 IP 주소들로 그리고 해당 IP 주소들로부터의 후속 트래픽은 이제 해당 서비스에 속하는 것으로 분류될 것이다.
특정 경우들에 있어서, 질의되는 영역이 너무 일반적이어서 서비스와 연관되지 않을 수 있다. 이 경우, DNS 규칙은 DNS 응답의 CNAME을 매칭시키기 위한 추가 규칙들을 포함될 수 있다. 응답에서 반환된 IP 주소들은 응답이 CNAME을 포함하고 CNAME이 제공된 규칙들 중 하나와 매칭되는 경우 그리고 이러한 경우에만 라우팅 제어기로 전달된다.
도 7 및 도 8은 본 교시에 따른 시스템이 적절한 채널들이 사용되는 것을 보장하기 위해 시스템을 통해 라우팅되는 트래픽을 해결할 수 있는 방식과 연관된 예시적인 프로세스 흐름을 도시하는 개략도들이다.
프로세스는 클라이언트 디바이스, 차량이 호스트에 대한 연결을 열려고 시도할 때 개시된다(단계 705). 클라이언트 디바이스는 호스트 이름을 하나 이상의 IP 주소들로 확인하기 위해 이름 서버로 DNS 요청을 전송한다(단계 710). DNS 요청은 진입 NIC에 도달하면 식별된다. 도달 시, 요청이 검사되고 호스트가 각각의 서비스에 대해 정의된 규칙들과 비교된다(단계 715). 매칭이 없는 경우, 요청 ID는 저장되지 않지만(단계 730), 요청은 여전히 DNS 이름 서버로 계속해서 라우팅된다(단계 735).
호스트에 대해 매칭이 존재하는 경우(단계 720), DNS 요청 ID가 캐싱되고 DNS 요청은 진출 NIC를 통과하여 요청을 확인하고 DNS 응답으로 응답하는 DNS 이름 서버로 라우팅된다.
이름 서버로부터 DNS 응답이 수신되면(단계 740), DNS 응답의 응답 ID가 요청 ID 캐시에 대해 확인되어 매칭이 있는지 확인한다(단계 741).
매칭이 발견되면(단계 745), 시스템은 A 기록들을 라우팅 제어기로 전달하도록 구성되며, 본 기술 분야의 통상의 기술자는 A 기록들이 영역과 연관된 IP 주소를 포함하는 DNS 응답의 일부라는 것을 이해할 것이다. 그 후 라우팅 제어기는 연관된 서비스에 대해 라우팅 테이블들을 업데이트할 것이다.
매칭이 발견되었는지 여부에 관계없이, DNS 응답은 요청 클라이언트로 계속 송신된다(단계 750).
클라이언트는 DNS 응답에 포함된 IP 주소들 중 하나에 대한 연결을 연다(단계 755).
요청으로 인한 트래픽은 라우팅 제어기에 의해 정의된 대로 올바른 채널을 통해 라우팅된다(단계 760).
도 9의 프로세스 흐름에 따라, 시스템은 또한 진입 NIC 상의 모든 업스트림 TLS 패킷(TCP 포트(443))을 모니터링하도록 구성될 수 있다. 단계 805에서 프로세스 중인 TLS 핸드셰이크를 식별하면, 단계 810에서 ClientHandshake 패킷을 검사하여 SNI(서버 이름 표시(Server Name Indication)) 확장 헤더를 포함하는지 여부를 결정한다. SNI 헤더를 찾으면, 헤더의 값이 추출되고(단계 820), 각각의 서비스에 대해 정의된 SNI 매칭 규칙들과 비교된다. 서비스 규칙이 매칭되는 경우(단계 825), 패킷의 목적지 IP 주소는 해당 서비스에 대한 구별 IP 주소인 것으로 가정되고, 목적지 IP 주소는 단계 835에서 라우팅 제어기로 전달된다. DNS 매치의 경우와 마찬가지로, 라우팅 제어기는 서비스에 대한 라우팅 테이블 엔트리들을 업데이트한다(840).
본 교시에 따른 시스템은 해당 트래픽을 생성하고 있는 서비스들에 기초하여 네트워크 레벨에서 데이터 사용의 분류를 가능하게 한다는 것이 위에서 이해될 것이다. 상이한 데이터 서비스 공급자들의 IP 주소를 식별함으로써, 본 교시에 따라 이러한 상이한 데이터 서비스 공급자들에 특정한 채널들을 통해 네트워크 레벨에서 네트워크 트래픽을 라우팅하는 것이 가능하다. 라우팅은 네트워크를 통과하는 패킷들의 헤더들을 파싱한 다음 소스 또는 목적지 IP 주소에 기초하여 특정 채널로 패킷을 라우팅함으로써 실시된다. 이러한 방식으로 네트워크를 통과하는 개별 패킷들에 대해 심층적인 패킷 분석을 수행하는 것이 아니라 데이터 서비스 공급자의 IP 주소를 생성하는 것으로부터 트래픽의 특성이 추론된다.
본 교시의 시스템은 상이한 데이터 서비스 공급자들에 특정한 채널들을 통해 특정 차량들에서 발생하는 트래픽을 라우팅하도록 구성된다. 이러한 방식으로 특정 차량에 의해 사용되고 있는 데이터 서비스들 유형에 대한 세부적인 개요가 네트워크 레벨에서 실시된다. 시스템은 예를 들어 브라우징 활동, 쿠키 등의 실제 차량에 대한 질문을 요구하지 않는다. 분석은 네트워크 디바이스를 통과하는 패킷에 기초하여 수행된다. 차량의 디바이스 식별자, 통상적으로 IMSI를 사용하여, 해당 차량으로부터 발생하거나 상이한 데이터 서비스 공급자들로부터 해당 차량으로 라우팅되는 트래픽을 추적할 수 있다. 이는 데이터 사용의 모니터링을 용이하게 할 뿐만 아니라, 서비스 차단, 사용 중인 디바이스 또는 데이터 서비스에 기초한 라우팅 구성 변경, 청구 데이터 등과 같은 추가적인 기능도 허용한다.
본 교시의 시스템은 브라우저 또는 특정 애플리케이션 레벨이 아닌 디바이스 특정 레벨에서 추적을 제공한다는 것이 이해될 것이다. 데이터 분석은 디바이스별로 수행되지만, 트래픽을 추정하기 위해 통계적 샘플링을 수행하지 않고 네트워크들 상에서 특정된 모든 디바이스들의 활동에 대한 전반적인 보기를 제공하기 위해 네트워크를 사용하여 모든 디바이스들을 추적할 수 있다.
위에서 상세히 설명한 바와 같이, 본 교시의 시스템은 웹 브라우저와 같은 애플리케이션이 아닌 네트워크 레벨로부터의 요청들을 추적하므로, 인터넷 유형 데이터 서비스 공급자들로부터 데이터 서비스들에 대한 모든 요청들을 확인하고 추적할 수 있다. 이는 웹 기반 서비스들을 포함할 뿐만 아니라 텔레매틱스(telematics), 맵들, 다른 머신 대 머신 데이터와 같은 항목들에 대한 머신 대 머신 서비스들뿐만 아니라 Netflix/Spotify와 같은 웹사이트 요청들 OR 스트리밍 데이터 서비스들과 같은 소비자 기반 서비스들과 같은 논(non) 인간/사용자 대면 서비스들을 포함하도록 확장된다.
데이터 요청들은 네트워크를 통해 들어오는 미가공(raw) 요청 레벨에서 추적된다. 이는 OS 등으로부터의 업데이트들 등을 위해 터미널 윈도우로부터의 다른 요청들(예를 들어, PC 사용)을 볼 수 없는 웹 브라우저 내에서 이루어진 요청들로부터 기록하는 다른 트래픽 분석 도구들과 상이하다.
네트워크 노드 내에, 예를 들어, 차량과 데이터 서비스 공급자 사이에 위치되는 데이터 분석 시스템의 예시적인 배열들이 이해될 것이다. 시스템은 해당 차량에 의해 사용되고 있는 특정 데이터 서비스들의 특성에 대해 데이터 분석이 수행될 수 있도록 하기 위해 특정 차량으로부터 발생하거나 특정 차량으로 향하는 데이터의 패킷들을 파싱하고 해당 패킷들의 헤더 정보에 기초하여 네트워크 노드 내의 특정 채널들을 통해 패킷들을 라우팅하도록 구성된다. 후속하는 청구항들에 비추어 필요한 경우에만 제한되도록 의도된 본 출원의 범위를 벗어나지 않고 본원에 설명된 것에 대한 수정들이 이루어질 수 있다.
본 명세서에서 사용되는 포함한다(comprise)/포함하는(comprising)이라는 단어들은 언급된 특징들, 정수들, 단계들 또는 구성 요소들의 존재를 특정하기 위한 것이지만, 하나 이상의 다른 특징들, 정수들, 단계들, 구성 요소들 또는 이들의 그룹들의 존재 또는 추가를 배제하지 않는다.

Claims (11)

  1. 차량 내 데이터 트래픽을 분류하는 네트워크 노드에서의 방법으로서,
    상기 네트워크 노드에서 제1 네트워크 명칭 공간(namespace) 및 제2 네트워크 명칭 공간을 정의하는 단계 ― 상기 제1 네트워크 명칭 공간은 들어오는 요청 데이터 패킷들을 수신하고 응답 데이터 패킷들을 전달하도록 구성된 진입 네트워크 인터페이스를 포함하고, 상기 제2 네트워크 명칭 공간은 들어오는 요청 데이터 패킷들을 수신하고 요청 데이터 패킷들을 전달하도록 구성된 진출 네트워크 인터페이스를 포함하고, 채널들이 상기 제1 네트워크 명칭 공간과 상기 제2 네트워크 명칭 공간 사이에 제공되어 상기 진입 네트워크 인터페이스와 상기 진출 네트워크 인터페이스 사이의 트래픽이 상기 채널들을 통해 라우팅됨 ―;
    차량으로부터, 상기 네트워크 노드에서 복수의 들어오는 요청 데이터 패킷들을 수신하는 단계 ― 상기 데이터 패킷들은 상기 차량에서 실행되는 애플리케이션으로부터 발생함 ―;
    상기 복수의 들어오는 요청 데이터 패킷들 중 각각의 데이터 패킷에 대해:
    상기 데이터 패킷의 헤더로부터 상기 데이터 패킷에 대한 소스 IP 주소를 추출하는 단계 ― 상기 소스 IP 주소는 상기 차량과 연관됨 ―;
    상기 데이터 패킷의 상기 헤더로부터 상기 데이터 패킷에 대한 목적지 IP 주소를 추출하는 단계 ― 상기 목적지 IP 주소는 상기 애플리케이션에 의해 요청된 서비스와 연관됨 ―;
    상기 데이터 패킷의 상기 헤더를 검사함으로써 상기 들어오는 데이터 패킷에 대한 데이터의 볼륨을 결정하는 단계;
    라우팅 테이블에 대해 상기 목적지 IP 주소를 확인하는 단계; 및
    상기 목적지 IP 주소가 상기 라우팅 테이블 내에 정의된 것으로 결정할 시, 해당 목적지 IP 주소에 대해 정의된 채널을 통해 상기 들어오는 데이터 패킷을 라우팅하는 단계, 또는
    상기 목적지 IP 주소가 상기 라우팅 테이블 내에 정의되지 않은 것으로 결정할 시, 정의되지 않은 모든 목적지 IP 주소들에 대해 제공되는 디폴트(default) 채널을 통해 상기 들어오는 데이터 패킷을 라우팅하는 단계;
    상기 들어오는 요청 데이터 패킷에 대해 상기 결정된 데이터 볼륨에 기초하여 채널 볼륨 표시자를 업데이트하는 단계;
    상기 네트워크 노드로부터 상기 요청 데이터 패킷들의 각각과 연관된 상기 목적지 IP 주소들로 상기 복수의 들어오는 요청 데이터 패킷들을 계속 송신하는 단계를 포함하는, 방법.
  2. 제1 항에 있어서,
    들어오는 요청 데이터 패킷들은 셀룰러 데이터 네트워크를 통해 적어도 부분적으로 수신되는, 방법.
  3. 제1 항 또는 제2 항에 있어서,
    상기 라우팅 테이블은 동일한 목적지 IP 주소 트래픽에 대해 동일한 채널을 사용하는, 방법.
  4. 제1 항 내지 제3 항 중 어느 한 항에 있어서,
    상기 네트워크 노드로부터 상기 목적지 IP 주소들로 상기 복수의 들어오는 요청 데이터 패킷들을 계속 송신하는 것에 응답하여 상기 네트워크 노드에서 복수의 들어오는 응답 데이터 패킷들을 수신하는 단계,
    상기 복수의 들어오는 응답 데이터 패킷들의 각각의 데이터 패킷에 대해:
    상기 데이터 패킷의 헤더로부터 상기 데이터 패킷에 대한 목적지 IP 주소를 추출하는 단계 ― 상기 목적지 IP 주소는 상기 차량과 연관됨 ―;
    상기 데이터 패킷의 상기 헤더로부터 상기 데이터 패킷에 대한 소스 IP 주소를 추출하는 단계 ― 상기 소스 IP 주소는 상기 애플리케이션에 의해 요청된 서비스와 연관됨 ―;
    상기 데이터 패킷의 상기 헤더를 검사함으로써 상기 들어오는 데이터 패킷에 대한 데이터의 볼륨을 결정하는 단계;
    상기 라우팅 테이블에 대해 상기 소스 IP 주소를 확인하는 단계; 및
    상기 소스 IP 주소가 상기 라우팅 테이블 내에 정의된 것으로 결정할 시, 해당 소스 IP 주소에 대해 정의된 채널을 통해 상기 들어오는 데이터 패킷을 라우팅하는 단계, 또는
    상기 소스 IP 주소가 상기 라우팅 테이블 내에 정의되지 않은 것으로 결정할 시, 정의되지 않은 모든 소스 IP 주소들에 대해 제공되는 디폴트 채널을 통해 상기 들어오는 데이터 패킷을 라우팅하는 단계;
    상기 들어오는 요청 데이터 패킷에 대해 상기 결정된 데이터 볼륨에 기초하여 채널 볼륨 표시자를 업데이트하는 단계;
    상기 네트워크 노드로부터 상기 응답 데이터 패킷들의 각각에 대한 IP 주소와 연관된 상기 개개의 차량으로 상기 복수의 들어오는 응답 데이터 패킷들의 각각을 계속 송신하는 단계를 포함하는, 방법.
  5. 제4 항에 있어서,
    상기 송신하는 단계는 셀룰러 데이터 네트워크를 사용하여 적어도 부분적으로 수행되는, 방법.
  6. 제4 항 또는 제5 항에 있어서,
    상기 라우팅 테이블은 동일한 소스 IP 주소 트래픽에 대해 동일한 채널을 사용하는, 방법.
  7. 제1 항 내지 제6 항 중 어느 한 항에 있어서,
    복수의 채널들의 각각은 상기 차량에서 실행되는 별개의 애플리케이션들과 연관되는, 방법.
  8. 제1 항 내지 제7 항 중 어느 한 항에 있어서,
    상기 라우팅 테이블 내에서 상기 채널들을 정의하는 단계를 포함하고, 상기 방법은 알려진 IP 주소 값들을 특정 채널들과 연관시키는 단계를 포함하여, 특정 채널과 연관된 IP 주소로 향하는 해당 트래픽이 해당 채널을 통해 라우팅되는, 방법.
  9. 제1 항 내지 제8 항 중 어느 한 항에 있어서,
    상기 라우팅 테이블을 동적으로 업데이트하는 단계를 더 포함하고, 상기 방법은 들어오는 DNS 요청 데이터 패킷에 대해 정의된 표현들의 집합에 대해 DNS 질의의 영역을 우선 매칭함으로써 패킷 검사를 수행하는 단계를 포함하고, 각각의 정의된 표현은 특정 서비스와 연관되고 매치가 발견되면, 상기 방법은 상기 요청 데이터 패킷에 대한 응답 데이터 패킷을 수신할 시, 상기 IP 주소 또는 상기 영역에 대한 주소들을 갖는 라우팅 테이블을 업데이트하는 단계를 포함하여 해당 IP 주소들로 그리고 해당 IP 주소들로부터의 후속 트래픽이 상기 DNS 요청 데이터 패킷에 대해 원래 매칭된 상기 특정 서비스와 연관된 상기 채널을 통해 라우팅되는, 방법.
  10. 제1 항 내지 제9 항 중 어느 한 항에 있어서,
    상기 라우팅 테이블을 동적으로 업데이트하는 단계를 더 포함하고, 상기 방법은,
    TLS 핸드셰이크를 식별하기 위해 업스트림 TLS 패킷들을 모니터링하는 단계,
    TLS 핸드셰이크가 프로세스 중인지 결정할 시 상기 패킷이 SNI 헤더를 포함하는지 여부를 결정하기 위해 상기 패킷을 검사하는 단계,
    SNI 헤더를 찾을 시, 상기 헤더의 값을 추출하고 상기 값을 각각의 서비스에 대해 정의된 SNI 매칭 규칙들과 비교하는 단계,
    SNI 규칙이 매칭되면, 상기 TLS 패킷의 상기 목적지 IP 주소 헤더로 상기 규칙을 소유하는 상기 서비스에 대한 상기 라우팅 테이블을 업데이트하는 단계를 포함하는, 방법.
  11. 프로세서, 제1 네트워크 인터페이스 및 제2 네트워크 인터페이스를 포함하는 네트워크 노드로서,
    상기 네트워크 노드는 제1 항 내지 제10 항 중 어느 한 항의 방법을 실행하도록 구성되는, 네트워크 노드.
KR1020247005777A 2021-07-27 2022-07-26 차량 데이터 KR20240058079A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB2110791.7 2021-07-27
GB2110791.7A GB2609258B (en) 2021-07-27 2021-07-27 Vehicle data
PCT/EP2022/070894 WO2023006716A1 (en) 2021-07-27 2022-07-26 Vehicle data

Publications (1)

Publication Number Publication Date
KR20240058079A true KR20240058079A (ko) 2024-05-03

Family

ID=77541067

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020247005777A KR20240058079A (ko) 2021-07-27 2022-07-26 차량 데이터

Country Status (7)

Country Link
EP (1) EP4348969A1 (ko)
JP (1) JP2024528854A (ko)
KR (1) KR20240058079A (ko)
AU (1) AU2022317220A1 (ko)
CA (1) CA3226586A1 (ko)
GB (1) GB2609258B (ko)
WO (1) WO2023006716A1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12095648B2 (en) * 2021-10-13 2024-09-17 Hewlett Packard Enterprise Development Lp Routing table anomaly detection using unsupervised machine learning

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8863256B1 (en) * 2011-01-14 2014-10-14 Cisco Technology, Inc. System and method for enabling secure transactions using flexible identity management in a vehicular environment
CN106953788B (zh) * 2017-02-16 2019-12-13 北京西普阳光教育科技股份有限公司 一种虚拟网络控制器及控制方法
US10855531B2 (en) * 2018-08-30 2020-12-01 Juniper Networks, Inc. Multiple networks for virtual execution elements
US10992777B2 (en) * 2019-06-19 2021-04-27 Netscout Systems, Inc System and method for identifying OTT applications and services

Also Published As

Publication number Publication date
CA3226586A1 (en) 2023-02-02
GB202110791D0 (en) 2021-09-08
WO2023006716A1 (en) 2023-02-02
GB2609258B (en) 2024-01-31
AU2022317220A1 (en) 2024-02-08
EP4348969A1 (en) 2024-04-10
JP2024528854A (ja) 2024-08-01
GB2609258A (en) 2023-02-01

Similar Documents

Publication Publication Date Title
US11362950B2 (en) Multi-phase IP-flow-based classifier with domain name and HTTP header awareness
CN107241186B (zh) 网络设备和用于网络通信的方法
US9210122B2 (en) System and method for inspecting domain name system flows in a network environment
CA2947325C (en) Protocol type identification method and apparatus
US20210014340A1 (en) Method and device for analyzing service-oriented communication
EP3484101B1 (en) Automatically determining over-the-top applications and services
EP3484102A1 (en) Cloud computing environment system for automatically determining over-the-top applications and services
KR20240058079A (ko) 차량 데이터
CN107409047B (zh) 用于加密会话的协调分组递送的方法
US10812352B2 (en) System and method for associating network domain names with a content distribution network
US20240356837A1 (en) Vehicle data
Oztoprak et al. A hybrid asymmetric traffic classifier for deep packet inspection systems with route asymmetry