KR102610923B1 - Ip 기반 차량 네트워크를 위한 차량 이웃 검색 - Google Patents

Abstract

본 명세서는, IP 기반 차량 네트워크에서, 제1 차량이 이웃 검색(Neighbor Discovery)을 수행하는 방법에 있어서, 상기 제1 차량이 인접한 RSU(Road-Side Unit)에 직접 등록을 위한 라우터 검색(Router Discovery)이 실패한 경우, 제2 차량으로 하나 이상의 제1 이웃 간청(Neighbor Solicitation, NS) 메시지를 전송하는 단계; 상기 제2 차량으로부터, 상기 제1 NS 메시지의 응답으로서, 제1 이웃 알림(Neighbor Advertisement, NA) 메시지를 수신하는 단계; 및 상기 제1 NA 메시지에 근거하여, 상기 제2 차량으로, 상기 제2 차량을 릴레이 차량으로 등록하기 위한 제2 NS 메시지를 전송하는 단계; 를 포함할 수 있다.

Description

IP 기반 차량 네트워크를 위한 차량 이웃 검색 {VEHICULAR NEIGHBOR DISCOVERY FOR IP-BASED VEHICULAR NETWORKS}

본 명세서는 차량 이웃 검색방법에 관한 것으로서, 보다 상세하게 IP 기반 차량 네트워크에 대한 IPv6 이웃 검색(Neighbor Discovery, ND)의 확장으로 차량 이웃 검색(Vehicular Neighbor Discovery, VND) 방법을 정의하기 위한 것이다.

차량용 애드혹 네트워크(Vehicular Ad Hoc Networks, VANET)는 주행 안전, 효율적인 주행, 엔터테인먼트 등 지능형 교통 시스템(Intelligent Transportation Systems, ITS)을 위해 연구됐다. IEEE는 전용단거리통신(Dedicated Short-Range Communications, DSRC)을 기반으로 한 차량 네트워크의 고속 이동성을 고려해 IEEE 802.11-OCB(Outside the Context of a Basic Service Set)를 표준화했다.

인터넷은 IETF (Internet Engineering Task Force)에서 공표 한 TCP / IP (전송 제어 프로토콜/인터넷 프로토콜)에 따라 운영되며, TCP/IP는 RFC (Request For Comments) 703 및 IETF에서 발행 한 RFC 791에서 찾을 수 있다.

본 명세서의 목적은, 빠른 차량 이동성 및 무선 제어 트래픽 오버헤드를 고려하여, IPv6 이웃 탐색[RFC4861]에 비해 차량 네트워크에 대한 적응력이 뛰어난 최적화된 ND를 제안하기 위함이다.

또한, 프리픽스(Prefix) 및 서비스 검색을 효율적으로 수행할 수 있는 방법을 제안하기 위함이다.

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

본 명세서의 일 양상은, IP 기반 차량 네트워크에서, 제1 차량이 이웃 검색(Neighbor Discovery)을 수행하는 방법에 있어서, 상기 제1 차량이 인접한 RSU(Road-Side Unit)에 직접 등록을 위한 라우터 검색(Router Discovery)이 실패한 경우, 제2 차량으로 하나 이상의 제1 이웃 간청(Neighbor Solicitation, NS) 메시지를 전송하는 단계; 상기 제2 차량으로부터, 상기 제1 NS 메시지의 응답으로서, 제1 이웃 알림(Neighbor Advertisement, NA) 메시지를 수신하는 단계; 및 상기 제1 NA 메시지에 근거하여, 상기 제2 차량으로, 상기 제2 차량을 릴레이 차량으로 등록하기 위한 제2 NS 메시지를 전송하는 단계; 를 포함할 수 있다.

또한, 상기 제2 차량을 통해, 상기 RSU 로부터 상기 제2 NS 메시지의 응답으로서, 제2 NA 메시지를 수신할 수 있다.

또한, 상기 제2 NA 메시지는 상기 IP 기반 차량 네트워크의 이동성을 관리하는 이동성 앵커(Mobility Anchor)에 포함된 중복 주소를 관리하기 위한 제1 테이블에 근거하여 생성될 수 있다.

또한, 상기 제1 NA 메시지를 수신하기 위해, 기설정된 시간 동안 대기하는 단계; 및 상기 제1 NA 메시지에 근거하여, 상기 제2 차량을 선택하는 단계; 를 더 포함하며, 상기 하나 이상의 제1 NS 메시지는 주변 차량들에게 멀티캐스팅 될 수 있다.

또한, 상기 릴레이 차량이 복수개인 경우, 상기 제1 차량 및 상기 릴레이 차량은 상기 RSU 까지의 릴레이(Relay) 패스(Path)를 나타내기 위한 제2 테이블을 갖을 수 있다.

본 명세서의 또 다른 일 양상은, IP 기반 차량 네트워크에서, 이웃 검색(Neighbor Discovery)을 수행하는 제1 차량에 있어서, 신호를 송수신하기 위한 송수신기; 데이터를 저장하는 메모리; 및 상기 송수신기 및 상기 메모리를 제어하는 프로세서;를 포함하고, 상기 프로세서는 상기 송수신기를 통해, 상기 제1 차량이 인접한 RSU(Road-Side Unit)에 직접 등록을 위한 라우터 검색(Router Discovery)이 실패한 경우, 상기 제2 차량으로 하나 이상의 제1 이웃 간청(Neighbor Solicitation, NS) 메시지를 전송하고, 제2 차량으로부터, 상기 제1 NS 메시지의 응답으로서, 제1 이웃 알림(Neighbor Advertisement, NA) 메시지를 수신하며, 상기 제1 NA 메시지에 근거하여, 상기 제2 차량으로, 상기 제2 차량을 릴레이 차량으로 등록하기 위한 제2 NS 메시지를 전송할 수 있다.

본 명세서를 통해, 빠른 차량 이동성 및 무선 제어 트래픽 오버헤드를 고려하여, [RFC4861]에 비해 차량 네트워크에 대한 적응력이 뛰어난 최적화된 ND를 구현할 수 있다.

또한, 프리픽스(Prefix) 및 서비스 검색을 효율적으로 수행할 수 있다.

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

본 명세서에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도면은 본 명세서에 대한 실시 예를 제공하고, 상세한 설명과 함께 본 명세서의 기술적 특징을 설명한다.
도 1은 본 명세서가 적용될 수 있는 V2I 및 V2V용 차량 네트워크 아키텍처의 예시이다.
도 2는 본 명세서가 적용될 수 있는 VPI 옵션의 형식을 예시한다.
도 3은 본 명세서가 적용될 수 있는 VSI 옵션의 형식을 예시한다.
도 4는 본 명세서가 적용되는 VMI 옵션의 형식을 예시한다.
도 5는 본 명세서가 적용될 수 있는 V2I 네트워킹에서의 메시지 교환 절차의 예시이다.
도 6은 본 명세서가 적용될 수 있는 주소 등록의 메시지 교환 절차를 예시한다.
도 7은 본 명세서가 적용될 수 있는 주소 등록과 멀티홉 DAD의 절차를 예시한다.
도 8은 본 명세서가 적용될 수 있는 V2V 릴레이를 통한, 주소 등록 및 멀티홉 DAD의 예시이다.
도 9는 본 명세서가 적용될 수 있는 둘 이상의 차량이 중간 릴레이 차량으로 동작하는 경우, Neighbor Routing Table의 매개변수를 예시한다.
도 10은 본 명세서가 적용될 수 있는 일 실시예이다.
도 11은 본 명세서가 적용될 수 있는 장치 일반의 예시이다.

이하, 본 명세서에 따른 바람직한 실시 형태를 첨부된 도면을 참조하여 상세하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 명세서의 예시적인 실시형태를 설명하고자 하는 것이며, 본 명세서가 실시될 수 있는 유일한 실시형태를 나타내고자 하는 것이 아니다. 이하의 상세한 설명은 본 명세서의 완전한 이해를 제공하기 위해서 구체적 세부사항을 포함한다. 그러나, 당업자는 본 명세서가 이러한 구체적 세부사항 없이도 실시될 수 있음을 안다.

몇몇 경우, 본 명세서의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나, 각 구조 및 장치의 핵심능력을 중심으로 한 블록도 형식으로 도시될 수 있다.

이하의 설명에서 사용되는 특정 용어들은 본 명세서의 이해를 돕기 위해서 제공된 것이며, 이러한 특정 용어의 사용은 본 명세서의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.

본 명세서는 차량 간 또는 차량과 RSU(Rode-Side Unit)간의 상호작용을 지원하기 위해, VND(Vehicular Neighbor Discovery)를 IP 기반 차량 네트워크를 위해 향상된 IPv6 ND(IPv6 Neighbor Discovery)로 제안한다[ID-IPWAVE-VND]. 효율적인 IPv6 비상태 주소 자동설정(IPv6 Stateless Address Autoconfiguration, SLAAC)[RFC4862]을 위해 VND는 멀티홉(Multihop) 중복 주소 탐지(Duplicate Address Detection, DAD)를 사용하여 최적화된 주소 등록을 적용할 수 있다. 이러한 멀티홉 DAD는 차량이 복수개 RSU의 무선 커버리지에 해당하는 동일한 IP Prefix를 가진 여러 무선 서브넷으로 구성된 멀티링크 서브넷에서 고유한 IP 주소를 가질 수 있도록 한다. 또한, VND는 차량이 외부 무선 인터페이스를 통해 내부 네트워크의 프리픽스들(Prefixes)을 교환할 수 있도록 함으로써 연결된 VANET(Vehicular Ad Hoc Networks)를 통한 IP 패킷 라우팅을 지원할 수 있다.

VND는 차량에 최적화된 주소 등록과 멀티홉 중복 주소 검색(Multihop DAD) 메커니즘을 제공한다. 또한 효율적인 이동성 관리 체계가 지정되어 효율적인 V2V, V2I, V2X 통신을 지원한다. 이동성 관리에 대한 자세한 설명은 [ID-IPWAVE-VMM]에서 다룬다.

본 명세서에서는 [RFC4861], [RFC4862] 및 [RFC6775]에 설명된 용어를 사용한다. 또한 다음과 같은 용어들이 정의될 수 있다.

o WAVE: "차량 환경에서의 무선 액세스(Wireless Access in Vehicular Environments)"의 약어 [WAVE-1609.0].

o RSU: 차량과의 무선 통신을 위한 물리적 통신 장치(예: DSRC, 가시광선 통신, 802.15.4, LTE-V2X 등)를 갖추고 있으며 패킷 포워딩을 위한 라우터 또는 스위치로서 인터넷에 연결될 수 있는 노드. RSU는 일반적으로 교차로 또는 도로 구획의 도로 인프라에 배치되지만 주차 구역에도 배치될 수 있다.

o 온보드 장치(On-Board Unit, OBU): 다른 OBU 및 RSU와의 무선 통신을 위한 DSRC 장치가 갖고, 차내 장치 또는 네트워크에 연결될 수 있는 노드. OBU는 차량에 탑재된다. 효율적인 주행을 위해, OBU가 장착된 차량은 무선 항법 수신기(예: 위성위치확인시스템(GPS))가 포함될 수 있다.

o 이동성 앵커(Mobility Anchor, MA): 도로 망에서 차량의 IP 주소와 이동성 정보를 유지 관리하여 차량의 주소 자동 구성 및 이동성 관리를 지원하는 노드. RSU와 종단간(End-to-End, E2E) 연결을 제어한다. RSU의 통신 범위 내에서 이동하는 차량의 IP 주소를 기록하는 DAD 테이블을 관리 할 수 있다.

o 차량용 클라우드(Vehicular Cloud): 컴퓨팅 노드, 스토리지 노드 및 네트워크 노드를 포함한 차량 네트워크를 위한 클라우드 인프라.

o 교통 관제 센터(Traffic Control Center, TCC): 도로 인프라 정보(예: RSU, 교통신호 및 루프 검출기), 차량 트래픽 통계(예: 도로 구간당 평균 차량 속도 및 차량 도착 시간), 차량 정보(예: 차량의 식별자, 위치, 방향, 속도 및 내비게이션 경로로서의 궤적)를 관리하는 노드. TCC는 차량용 클라우드에 포함되며 MA를 관리할 수 있다.

1.1 링크 모델(Link Model)

링크와 네트워크 프리픽스(Prefix) 사이에는 링크-로컬 및 글로벌 스코프(Scope)와 같이 도달할 수 있는 범위에 관련을 갖는다. 기존의 IPv6 이웃 탐색(IPv6 Legacy ND) 프로토콜[RFC4861]에는 다음과 같은 링크 모델이 있다.

온-링크 비트(On-link Bit)가 설정된 동일한 서브넷(Subnet) 프리픽스를 사용하는 동일한 온-링크 서브넷의 모든 IPv6 노드는 단일-홉(hop) 링크로 서로 연결될 수 있다. 여기서 노드 간 연결의 대칭성, 즉, 두 개의 온-링크 노드 간에는 양방향 연결을 가정한다.

단, 차량 네트워크의 링크 모델(차량 링크 모델이라고 함)은 무선 채널의 간섭과 무선 네트워크 인터페이스에 의해 사용되는 전송 강도의 다른 수준으로 인해 발생되는 단방향 링크 연결의 비대칭성을 고려해야 한다.

온-링크 서브넷은 멀티링크 서브넷[RFC6775]이라고 하는 하나의 링크(기본 서비스 집합) 또는 다중 링크(확장 서비스 집합)로 구성될 수 있다. 이러한 다중 링크 서브넷에서, 모든 노드 멀티캐스트 패킷이 복사되고 ND 프록시(Proxy)에 의해 다른 링크와 연관될 수 있다. 반면에, 빠르게 움직이는 차량을 가진 차량 네트워크에서, 다중 링크는 운영 효율을 위해 동일한 서브넷 프리픽스를 공유할 수 있다. 예를 들어, 두 개의 인접한 RSU 아래에 있는 두 개의 무선 링크가 동일한 서브넷에 있는 경우, IPv6 호스트로서의 차량은 RSU 간 핸드오버 동안 IPv6 주소를 재구성할 필요가 없다. 그러나 ND 프록시로서 RSU에 의한 패킷 릴레이는 확장된 서브넷에서 브로드캐스트 폭풍을 일으키지 않도록 수행되어야 한다. 그러므로, 다중 링크 서브넷에서, 모든 노드 멀티캐스팅은 현재 링크의 멀티캐스팅으로 제한 되거나(confined) 동일한 서브넷의 다른 링크에 전파되도록 잘 조정되어야(calibrated) 한다.

연결된 멀티-홉 VANET에서 효율적인 통신을 위해 RSU와 동일한 무선 링크에 있는 차량들은 라우터 역할을 하는 RSU를 통해서가 아닌, 서로 직접 통신할 수 있다. 이러한 직접 무선 통신은 이더넷을 유선 네트워크로 사용하는 온-링크 서브넷의 직접 유선 통신과 유사하다. 차량 링크 모델은 차량 간의 애드 혹(Ad Hoc) 기반 V2V 통신 및 차량과 RSU 사이의 V2I 통신 모두를 효율적이고 유연한 방식으로 수용할 수 있어야 한다. 따라서, IPv6 ND는 차량 네트워크에서 새로운 IPv6 링크 모델의 개념을 수용할 수 있도록 확장되어야 한다.

멀티-링크 서브넷을 지원하기 위해 본 명세서는 프리픽스 할당을 위한, 공유 프리픽스(Shared-Prefix) 모델을 사용한다. 공유 프리픽스 모델은 둘 이상의 노드에서 프리픽스를 공유하는 어드레싱 모델을 가리킨다. 본 명세서에서 특정 서브넷은 차량에 대한 프리픽스 할당을 위해 응답하는 RSU의 모든 인터페이스가 특정 서브넷의 스코프 안에서 같은 프리픽스를 획득하고 유지할 수 있도록 보장하는 동일한 프리픽스를 가지고 있다고 가정한다.

1.2 ND 최적화(Optimization)

본 명세서에서 차량 환경은 멀티-캐스팅에 의한 불필요한 무선 트래픽 감소 및 배터리의 에너지 절약과 같은, 6LoWPAN(Low-Power Wireless Personal Area Networks)[RFC6775]과 공통적인 파트를 갖으므로, 6LoWPAN에 최적화된 ND를 활용할 수 있다. 여기서 차량의 에너지원은 전기 자동차의 베터리와 같은 것일 수 있다.

6LoWPAN에 최적화된 IPv6 ND에서, 무선 환경의 변화 및 손실 신호로 인해 노드 간의 연결이 비대칭적이고 단방향인 것으로 가정한다. 본 명세서는 새로운 옵션과 주소 구성을 위한 새로운 기법(Scheme)을 이용함으로써 에너지를 절약하기 위해 링크-스코프 멀티캐스트를 효율적으로 제거하는 최적화된 IPv6 ND를 제안한다.

또한, 본 명세서는 IPv6 비상태 주소 자동설정(IPv6 Stateless Address Autoconfiguration, SLAAC)[RFC4862]를 위한 DAD와 같은 링크-스코프-멀티캐스트-기반 ND 동작을 제거함으로써 IPv6 ND의 개선을 제안한다. 따라서 본 명세서는 새로운 ND 옵션(예: 프리픽스 검색, 서비스 검색 및 이동성 정보 옵션)과 함께 차량 네트워크에 맞게 조정된 ND로서 IPv6 ND의 확장을 제안한다.

1.3 설계 목표

이 명세서에서 차량 ND는 다음과 같은 설계 목표를 갖는다.

o ND 절차를 통해 프리픽스 및 서비스 검색을 수행할 수 있다;

o 라우터 알림(Router Advertisement, RA)의 호스트-시작 새로 고침(refresh)을 구현하고, 라우터가 호스트를 찾기 위해 주기적 또는 요청되지 않은 멀티캐스트 RA를 사용할 필요성을 제거할 수 있다;

o NUD(Neighbor Unreachable Detection)를 대체하기 위해, Neighbor Solicitation (NS), Neighbor Advertisement (NA) 메시지에 Address Registration Option (ARO)을 추가하여 RSU 및 MA에 등록된 모든 차량에 대한 Neighbor Cache Entries (NCE)를 만들 수 있다;

o 멀티-캐스트 폭풍을 제거하고 에너지를 절약하기 위해 차량으로부터 수신된 ND 메시지를 MA로 전달함으로써 멀티홉 DAD를 지원할 수 있다.

o RSU의 적용 범위 밖의 차량이 릴레이 이웃 차량(Relay Neighbor Vehicle)을 통해 무선으로 멀티 홉으로 떨어진 RSU와 통신할 수 있도록 멀티-홉 통신을 지원할 수 있다.

차량 네트워크 아키텍처

이하에서 V2V 및 V2I 통신을 위한 차량 네트워크 아키텍처를 설명한다. 차량과 RSU는 각각 차내 장치나 서버를 포함한 내부 네트워크를 가지고 있다.

도 1은 본 명세서가 적용될 수 있는 V2I 및 V2V용 차량 네트워크 아키텍처의 예시이다.

도 1를 참조하면, 3개의 RSU가 도로변을 따라 배치되고, 유선 연결을 통해 MA에 연결되며, 서브넷1과 서브넷2로 명명된 두 개의 서브넷이 있다. RSU1과 RSU2의 무선 링크는 서브넷1 이라는 동일한 서브넷에 속하지만, RSU3의 무선 링크는 서브넷2 라는 다른 서브넷에 속한다. Vehicle2는 RSU1에 무선으로 연결되고 Vehicle3와 Vehicle4는 각각 RSU2와 RSU3에 연결된다. 차량은 V2V 연결(예: Vehicle1 및 Vehicle2)을 통해 직접 통신하여 주행 정보를 공유할 수 있다. 또한 RSU의 커버리지에 포함되지 않은 차량은 릴레이 차량을 통해 멀티-홉 연결에서 RSU와 연결될 수 있다(예: 차량1은 차량2를 통해 RSU1에 연결할 수 있음). 차량은 RSU의 커버리지에 들어갈 때, RSU에 대한 연결을 시작하는 것으로 가정한다.

본 명세서에서는 도 1과 같이 다중 RSU를 포함하는 다중 링크 서브넷을 제안한다. 이는 인접한 두 RSU 사이를 핸드오버(handover)하는 동안, 차량의 IP 주소를 변경하는 빈도를 줄이는 것을 목적으로 한다. 이러한 멀티-링크 서브넷을 구성하기 위해 공유 프리픽스(Shared-Prefix) 모델이 제안된다. 즉, 동일한 서브넷의 RSU의 경우, 차량에 대한 프리픽스 할당을 담당하는 인터페이스는 그들의 글로벌(global) 주소에서 동일한 프리픽스를 유지해야 한다. 또한, 이는 차량이 이러한 스코프에서 동일한 프리픽스를 얻을 것을 보장한다. 동일한 서브넷의 RSU를 통과할 때, 차량은 다음 RSU의 무선 커버리지에서 현재의 IP 주소를 사용할 수 있기 때문에 주소 등록과 DAD를 다시 수행할 필요가 없다.

이러한 제안은 동일한 IP 프리픽스 영역에 속하는 노드가 서로의 무선 통신 범위 내에 있는 경우, RSU의 개입 없이 직접 통신할 수 있다는 가정에 부합한다. 한편, 프리픽스가 다른 서브넷에 속하는 RSU의 무선 커버리지에 차량이 진입하는 경우, 차량은 주소 등록 및 DAD 절차를 반복하여 새로운 프리픽스로 IP 주소를 업데이트한다.

RSU1과 RSU2는 차량과의 연결을 위해 응답하는 무선 인터페이스에서 동일한 프리픽스 주소를 가진 멀티-링크 서브넷에 배치된다. 차량2가 RSU1의 커버리지에서 벗어나 RSU2로 진입할 때, 차량은 IP 주소 구성을 유지하고 주소 등록 및 DAD 단계를 무시한다. 차량2가 RSU3의 적용범위로 이동하는 경우, RSU3은 다른 서브넷에 속하고 RSU1 및 RSU2와 다른 프리픽스를 보유하므로, 차량2는 새로운 RSU에 연결되는 것과 같이, IP 주소 등록과 DAD를 다시 수행해야 한다. 차량과 RSU는 각각 차량 내 장치와 서버를 포함한 내부 네트워크를 갖을 수 있으며, 내부 네트워크의 구조는 [ID-IPWAVE-PS]에 기술되어 있다.

프리픽스 및 서비스 검색(Service Discovery)을 위한 ND 확장

이 절에서는 차량 대 차량(V2V) 또는 차량 대 인프라(V2I) 네트워킹을 위한 IPv6 ND 확장을 제안한다. 또한 이 절에서는 프리픽스 검색, 서비스 검색 및 이동성 정보 리포트: (i) 차량 프리픽스 정보(Vehicular Prefix Information, VPI) 옵션, (ii) 차량 서비스 정보(Vehicular Service Information, VSI) 옵션 및 (iii) 차량 이동성 정보(Vehicular Mobility Information, VMI) 옵션의 세 가지 새로운 ND 옵션을 정의한다. 또한 이러한 옵션과 함께 ND 프로토콜의 절차도 설명한다.

1. Vehicular Prefix Information Option

VPI 옵션은 내부 네트워크의 IPv6 프리픽스 정보를 포함한다. 도 2는 본 명세서가 적용될 수 있는 VPI 옵션의 형식을 예시한다.

표 1은 본 항목에서 VPI 옵션에 포함된 데이터 필드의 예시이다.

Type	IANA에서 할당한 VPI 옵션 유형의 8비트 식별자: TBD
Length	8비트 부호 없는 정수. 옵션의 길이(유형 및 길이 필드 포함)는 8옥텟 단위로 한다. 값은 3이다.
Prefix Length	8비트 부호 없는 정수. 프리픽스에서 유효한 선행 비트의 개수. 값은 0에서 128까지.
Distance	8비트 부호 없는 정수. 이러한 프리픽스를 알리는 서브넷과 이러한 프리픽스에 대응하는 서브넷 사이의 거리(홉 수)
Reserved	이 필드는 사용되지 않는다. 전송자는 0으로 초기화해야 하며 수신자는 무시해야함.
Prefix	IP 주소 또는 IP 주소의 프리픽스. 프리픽스 길이 필드에는 접두사의 유효한 선행 비트 수가 포함되어 있다. 프리픽스 길이 이후의 프리픽스의 비트는 예약되어 있고, 송신자는 0으로 초기화해야 하며 수신자는 무시해야 한다.

2. Vehicular Service Information Option

VSI 옵션은 내부 네트워크의 차량 서비스 정보를 포함한다. 도 3은 본 명세서가 적용될 수 있는 VSI 옵션의 형식을 예시한다.

표 2는 본 항목에서 VPI 옵션에 포함된 데이터 필드의 예시이다.

Type	IANA에서 할당한 VPI 옵션 유형의 8비트 식별자: TBD
Length	8비트 부호 없는 정수. 옵션의 길이(유형 및 길이 필드 포함)는 8옥텟 단위로 한다. 값은 3이다.
Reserved1	이 필드는 사용되지 않는다. 전송자는 0으로 초기화해야 하며 수신자는 무시해야함.
Protocol	전송 계층 프로토콜(예: TCP, UDP, SCTP)과 같은 상위 계층 프로토콜을 나타내는 8비트 부호 없는 정수.
Reserved2	이 필드는 사용되지 않는다. 전송자는 0으로 초기화해야 하며 수신자는 무시해야함.
Port Number	이 프로토콜의 포트 번호를 나타내는 16비트 부호없는 정수.
Service Address	이 차량 서비스를 제공하는 노드의 128비트 IPv6 주소.

3. Vehicular Mobility Information OptionVMI 옵션은 차량 또는 RSU의 하나의 차량 이동성 정보를 포함한다. 도 4는 본 명세서가 적용되는 VMI 옵션의 형식을 예시한다.

표 3은 본 항목에서 VPI 옵션에 포함된 데이터 필드의 예시이다.

Type	IANA에서 할당한 VPI 옵션 유형의 8비트 식별자: TBD
Length	8비트 부호 없는 정수. 옵션의 길이(유형 및 길이 필드 포함)는 8옥텟 단위로 한다. 값은 3이다.
Reserved1	이 필드는 사용되지 않는다. 전송자는 0으로 초기화해야 하며 수신자는 무시해야함.
Reserved2	이 필드는 사용되지 않는다. 전송자는 0으로 초기화해야 하며 수신자는 무시해야함.
Mobility Information	위치, 속도, 가속/가속 및 방향과 같은 128비트 이동성 정보.

4. Vehicular Neighbor Discovery

프리픽스 검색은 호스트(예: 차량 및 차내 장치)가 동일한 링크의 목적지와 RSU를 통해서만 도달할 수 있는 목적지를 구별할 수 있도록 한다. 차량(또는 차내 장치)은 RSU의 릴레이 없이 V2V 통신을 통해, VPI ND 옵션과 함께 온-링크 차량(또는 차내 장치)과 직접 통신할 수 있다. 이러한 VPI 옵션은 차량 내부 네트워크의 IPv6 프리픽스를 포함한다.

차량은 VSI ND 옵션을 통해 내부 네트워크의 서비스를 다른 차량에게 알린다. VSI 옵션은 차량의 또는 RSU의 내부 네트워크에 있는 차량 서비스 목록을 포함한다.

차량은 모든 이웃 노드에 도달하기 위해 프리픽스 및 서비스를 올-노드 멀티캐스트 주소(All-node-multicast-address)로 VPI 및 VSI 옵션을 포함하는 NS 메시지를 주기적으로 전달한다. 이러한 NS 메시지를 수신하면, 다른 이웃 노드는 NS-originating 노드로 VPI 및 VSI 옵션이 포함된 NA 메시지를 유니캐스트를 통해 전송함으로써, NS 메시지에 응답한다.

따라서 프리픽스 및 서비스 검색은 VPI 및 VSI 옵션이 포함된 차량 ND(예: NS 및 NA)에 의하여, ND 메시지(예: NS 및 NA)를 통해 수행될 수 있다. 이러한 VND 기반 검색은 ND 이외의 DNS 기반 서비스 검색 [RFC6763](예: 멀티캐스트 DNS(mDNS) [RFC6762] 및 DNSNA [ID-DNSNA])과 같은 추가 프리픽스 및 서비스 검색 기법을 필요하지 않게 할 수 있다. 즉, 차량과 RSU는 추가 서비스 검색 프로토콜 없이도 상대방의 네트워크 프리픽스 및 서비스를 신속하게 검색할 수 있다.

5. Message Exchange Procedure for V2I Networking

이하에서는 차량이 RSU를 통해 인터넷의 특정 노드와 통신하는 V2I 네트워킹에서 VND에 대한 메시지 교환 절차를 예시한다.

도 5는 본 명세서가 적용될 수 있는 V2I 네트워킹에서의 메시지 교환 절차의 예시이다. 절차의 자세한 단계는 "주소 등록 및 주소 중복 탐지" 절에 설명되어 있다. 또한, 이동성 관리 부분은 [ID-IPWAVE-VMM]에 설명되어 있다.

후술하는 도 7을 참조하면, 차량은 주소 등록 절차와 함께 접두사 및 서비스 검색을 동시에 수행할 수 있다.

본 명세서는 라우터로서의 RSU가 차량 네트워크에서의 차량의 에너지 절약을 위해, 프리픽스를 포함하는 정기적이고 요청되지 않은 멀티캐스트 RA 메시지를 전송하지 않는 것을 제안한다. 호스트로서의 차량은 시간 간격에 따라(위치 및 RSU의 커버리지 고려) 주기적으로 RS 메시지를 개시한다. 이러한 차량은 RSU의 정보(예: 위치 및 통신 커버리지)가 포함된 로컬 동적 맵(Local Dynamic Map, LDM)을 보유하므로, 차량은 RSU의 신호 강도(예: 수신 채널 전력 표시기(RCPI) [VIP-WAVE])와 함께 RSU의 통신 커버리지 밖으로 언제 나갈지 알 수 있다. RSU는 RS 메시지를 수신할 때만, 유니캐스트를 통해, 요청된 RA에 응답한다.

주소 등록 및 주소 중복 탐지

이 섹션에서는 V2I 또는 V2V를 통한 IP 주소 자동 구성, 주소 등록 및 멀티홉 DAD로 구성된 주소 구성을 예시한다.

본 명세서는 대규모 차량 네트워크에서 에너지 및 무선 채널 보전을 위해, 멀티캐스트 남용을 방지하고 링크-스코프 멀티캐스트를 줄이기 위해 새로운 주소 등록 및 DAD 방식을 제안한다. 호스트 기반의 RA 새로 고침(refresh)은 라우터가 호스트 수용을 위해 자주 그리고 요청되지 않은 멀티캐스트 RA를 사용할 필요성을 제거할 수 있다. 또한 서브넷을 통과할 때 동일한 IPv6 주소 프리픽스를 사용할 수 있다.

다음은 주소 등록 스킴에서 실현 가능한 세 가지 시나리오를 예시한다:

1. 차량이 처음으로 서브넷에 진입하거나 현재 RSU가 다른 서브넷에 속함: 차량은 다음에 예시된 대로 주소 등록 및 멀티-홉 DAD를 수행해야 한다.

2. 차량이 이미 이전 RSU로부터 획득한 프리픽스로 IP 주소를 구송하였고, 현재 RSU가 동일한 서브넷에 위치함: 즉, RSU들은 프리픽스가 같으며, 차량은 주소 등록과 멀티홉 DAD를 반복할 필요가 없다.

3. 차량이 RSU의 커버리지에 속하지 않지만, RSU에 등록된 이웃 차량이 있음: 본 명세서는 현재 RSU의 통신 범위에 속하지 않는 차량에 대해 새로운 멀티홉 V2V 시나리오를 제안한다. 만약 사용자 차량이 온-링크 RSU를 찾지 못하면, 차량은 RSU로부터 프리픽스를 공유하기 위해 릴레이 이웃 차량 이웃을 탐색하고, RSU로 DAD 메시지를 전달함으로써, 사용자 차량의 DAD를 수행한다.

1. Address Autoconfiguration

IPv6 호스트로서의 차량은 링크 로컬 IPv6 주소와 글로벌 IPv6 주소를 다음과 같이 생성한다 [RFC4862]. 차량으로부터 RS 메시지를 받으면(S500), RSU는 프리픽스 정보가 포함된 RA 메시지를 다시 보낸다(S510). 차량은 현재 링크의 프리픽스와 무선 인터페이스 식별자(Wireless Interface Identifier)를 결합하여 글로벌 IPv6 주소를 만든다.

주소 자동 구성은 [RFC4862]에 정의된 대로 기존의 IPv6 DAD(IPv6 Legacy DAD)를 수행하지 않는다. 대신 섹션 3의 새로운 멀티-홉 DAD가 수행된다.

2. Address Registration

RSU로부터 알려진 프리픽스와 링크-계층 주소로 IP 임시 주소 자동구성 후, 차량은 멀티-홉 DAD로 서비스 중인 RSU에 IP 주소를 등록한다(S520). 주소 등록 옵션(Address Register Option, ARO)은 이 단계에서 사용되며 그 형식은 [RFC6775]에 정의되어 있다.

ARO는 항상 차량에 의해 호스트-개시된다. 등록기간 및 결과를 표시하기 위해, ARO에 포함된 등록시간, 등록현황 등의 정보를 적용할 수 있다. 또한 ARO는 RSU에 의해 NS와 함께 MA로 전달된다(S530).

주소 등록의 메시지 교환 절차의 예는 도 6에서 예시한다. Address Registration은 멀티-홉 DAD와 동시에 수행되므로, 구체적인 절차는 섹션 3의 DAD 메커니즘과 함께 설명된다.

3. Multihop Duplicate Address Detection

IPv6 노드(즉 라우터 또는 호스트)는 IPv6 데이터 패킷을 교환하기 전에 자신의 IP 주소가 다른 노드에서 이미 사용되고 있는지 여부를 판단해야 한다. 레거시 IPv6 ND에서는 호스트는 NS 메시지를 동일한 온-링크 서브넷의 모든 노드로 멀티 캐스팅한다. 이것 대신에 최적화된 멀티홉 DAD는 에너지 절약을 위해, 멀티캐스트 메시지를 없애도록 설계되었다. 이러한 최적화된 멀티홉 DAD의 경우, 멀티홉 DAD 프로세스 중 주소 중복 검사를 위해 RSU와 MA에 의해 각각 Neighbor Cache와 DAD Table이 유지된다. 즉, 각 RSU는 자신의 Neighbor Cache에서 모든 온-링크 호스트들의 Neighbor Cache 항목(Neighbor Cache Entries, NCE)을 수집하여 만든다. 다시 말하면, MA는 RSU가 보고한 모든 NCE들을 통합하여 DAD 테이블에 저장한다.

이러한 멀티홉 DAD를 통해, 차량은 동일한 서브셋에서 다른 RSU의 커버리지에 들어갈 때, 현재의 무선 링크에서의 멀티캐스트-기반 DAD를 생략(skip) 할 수 있으며, 이는 차량 무선 링크의 트래픽 오버헤드를 감소시킬 수 있다.

멀티홉 DAD의 경우, [RFC6775]의 절차를 이용하지만, 중복 주소 요청(Duplicate Address Request, DAR)과 중복 주소 확인(Duplicate Address Confirmation, DAC)과 같은 두개의 새로운 ICMPv6 메시지 타입을 취소함으로써 메시지 흐름을 단순화했다. 대신에, ARO를 포함하는 NS와 NA는 RSU와 MA 사이에 직접 전달된다. 이러한 아이디어는 DAR 및 DAC 때문에 제기되었다.

3.1. DAD without Intermediate Vehicle

도 7은 본 명세서가 적용될 수 있는 주소 등록과 멀티홉 DAD의 절차를 예시한다. 도 7을 참조하면, 자세한 단계는 다음과 같다.

1. 차량은 주소를 등록하기 위해 ARO를 포함한 NS 메시지를 유니캐스트로 현재 통신범위에 있는 RSU에 전송한다.

2. RSU는 NS 메시지를 수신한 후 Neighbor Cache를 검사하여 ARO의 IPv6 주소의 중복 여부를 확인한다. 중복 NCE가 없는 경우, 이 주소에 대해 임시 NCE가 생성된 다음, RSU는 멀티홉 DAD에 대해 ARO가 포함된 NS 메시지를 MA로 전달한다.

3. MA는 RSU로부터 NS를 받으면, 등록 요청된 IPv6 주소가 DAD Table에 있는지 여부를 확인한다. 만약 동일한 주소를 가진 항목이 DAD 테이블에 존재한다면, 이는 해당 주소가 "중복 주소"로 간주된다는 것을 의미하며, MA는 주소 중복을 RSU에 알리기 위해 ARO의 등록 상태를 포함하는 NA 메시지를 반환한다. 만약 DAD 테이블에 동일한 주소를 가진 항목이 존재하지 않는다면, 이는 주소에 대한 항목이 생성됨을 의미하며, MA는 RSU에 NA 메시지를 회신하여 RSU에 등록 요청 주소가 고유함을 확인한다.

4. 주소 중복을 MA로부터 통보받은 경우, RSU는 잠정적인 NCE를 삭제하고, NA를 주소-등록 차량에 전달하여 등록 실패를 통지한다. 이와 다른 경우, RSU는 임시 NCE를 Neighbor Cache에 등록된 NCE로 변경한 후, NA를 차량으로 전달하여 등록 성공 사실을 알린다.

따라서, 멀티홉 DAD는 주소 등록과 동시에 처리된다. MA가 멀티홉 DAD에서 레지스터 요청 주소가 고유함을 확인할 때까지 임시 주소가 차량에 할당된 것으로 간주되지 않는다.

3.2. DAD with one Intermediate Vehicle

만일, 차량이 기본 라우터를 등록하지 못한 경우, 멀티-홉 통신을 사용하여 릴레이 서비스를 제공할 수 있는 차량 이웃을 찾기 위해 멀티홉 이웃 탐색(Multihop Neighbor Discovery)를 트리거한다. 여기서, 라우터 검색(Router Discovery, RD)이 실패할 경우에만, 차량은 V2V 통신이 RSU와 직접 연관되지 않고, 릴레이 시나리오를 통해 멀티홉 V2V를 트리거하는 것을 가정한다.

차량은 RSU의 정보가 수록된 로컬 동적 맵(예: LDM)은 RSU의 위치 및 통신 범위을 갖으므로, 릴레이 차량으로 사용할 수 있는지 여부를 판단할 수 있다. 임시 릴레이 역할을 할 수 있는 능력을 갖춘 차량만이 릴레이 서비스 요청을 받을 때, 액션을 취할 수 있다. 사용자 차량은 RSU의 적용 범위에 들어가기 전에 릴레이 차량을 통해 전역 주소 구성, 주소 등록 및 DAD를 처리할 수 있다.

도 8은 본 명세서가 적용될 수 있는 V2V 릴레이를 통한, 주소 등록 및 멀티홉 DAD의 예시이다.

도 8을 참조하면, 사용자 차량이 무선 통신 범위로 RSU에 직접 등록하지 못할 경우(S800) V2V 통신을 통해 차량 이웃 지역을 감지하기 위해 이웃 검색을 개시한다. 차량은 NS 메시지를 전송하여, 범위에 있는 이웃과 연결된다(S810). 이웃이 릴레이 서비스를 제공할 수 있는 경우, 사용자 차량용 NCE를 생성하여 자체 주소를 릴레이 주소로 설정하고, RSU로부터 수신한 프리픽스 정보가 포함된 NA를 전송한다(S820).

차량이 릴레이 차량 역할을 할 수 있는 여러 이웃으로부터 가장 가까운 이웃을 찾는 것을 보장하기 위해, 프리픽스 정보 옵션에서 제공하는 홉 거리 파라미터를 통해 가장 가까운 이웃을 선택할 수 있는 새로운 time-out 기반 라우팅 메커니즘이 제시될 수 있다. 즉, 사용자 차량은 RD가 실패한 후(S800), 릴레이 차량을 찾기 위해, NS 메시지를 멀티캐스트하고(S810), 이웃으로부터 모든 NA 응답을 받기 위해 1.5초 동안 기다린다. 각 NA는 프리픽스 정보 옵션에서 자체 글로벌 프리픽스 및 홉 거리를 제공한다(S820). 사용자 차량은 모든 NA 응답을 임시 라우터 목록에 보존하고, 시간 경과 후 홉 카운트가 가장 적은 회신을 릴레이 차량으로서 선택한다.

NA를 수신한 사용자 차량은 프리픽스 정보로 글로벌 주소를 구성할 수 있다. 이 후, 사용자 차량은 릴레이 차량을 통해 DAD 프로세스와 함께 주소 등록을 시작한다(S830). NS 메시지는 RSU에 도달하기 위해 다음 홉으로서 릴레이 차량의 주소를 나타낼 수 있다. 이 경우 릴레이 차량이 릴레이 요청 메시지를 수신하면 RSU로 NS 메시지를 전달한다(S840). MA를 제외한 이러한 절차는 릴레이 차량의 주소를 NCE에 릴레이 주소로 포함시켜, 현시점에서 직접 접속된(attached) 차량이 아님을 표시하고, 릴레이 주소를 다음 홉 주소로 설정한다. 릴레이 차량은 이러한 정보가 수신되는 즉시, 사용자 차량에 DAD 결과 정보 메시지를 전달한다(S850).

3.3. DAD with Multiple Intermediate Vehicles

본 명세서는 다중 릴레이 차량을 통한 릴레이 차량에 대한 멀티홉 통신(예: 멀티홉 DAD 및 UDP/TCP 전송)을 지원한다. 이미 DAD 프로세스가 완료된 차량은 릴레이 차량으로서 이동 라우터(Mobile Router) 또는 패킷 포워더(Packet Forwarder) 역할을 수행 할 수 있다.

복수개의 차량이 릴레이 차량으로 동작할 때, 사용자 차량과 서빙 RSU(Serving RSU) 사이에서 경로 선택을 수행하기 위한 라우팅 메커니즘을 이용할 수 있다. DSDV(Destination-Sequenced Distance-Vector Routing Protocol)[DSDV]를 이용하는, 새로운 라우팅 방식은 각 차량이 Neighbor Cache의 이웃 정보 및 원격 차량의 포워더(Forwarder) 정보를 통합하는 Neighbor Routing Table을 보유하는 것을 가정한다. 이러한 원격 차량의 릴레이 차량 역할을 하는 각각의 차량은 Neighbor Routing Table에 레코드를 생성한다.

도 9는 본 명세서가 적용될 수 있는 둘 이상의 차량이 중간 릴레이 차량으로 동작하는 경우, Neighbor Routing Table의 매개변수를 예시한다.

도 9를 참조하면, Vehicle3은 Vehicle2와 Vehicle1을 통해 RSU1와 간접적으로 연결된다. Vehicle1과 Vehicle2는 Vehicle3에 대해 메시지를 전달할 때, Vehicle3로 가는 경로를 나타내는 다음-홉 노드를 포함하여 Neighbor Routing Table에 기록을 만든다. 이를 통해 RSU에서 소스 차량으로 역방향 패킷 경로 뿐만 아니라 소스 차량에서 RSU로의 패킷도 성공적으로 전송될 수 있다.

도 10은 본 명세서가 적용될 수 있는 일 실시예이다.

도 10을 참조하면, 제1 차량은 제2 차량을 릴레이 노드로 하여, RSU에 등록을 수행하기 위한 동작을 할 수 있다.

제1 차량은 상기 제1 차량이 인접한 RSU(Road-Side Unit)에 직접 등록을 위한 라우터 검색(Router Discovery)이 실패한 경우, 제2 차량으로 하나 이상의 제1 이웃 간청(Neighbor Solicitation, NS) 메시지를 전송한다(S1010).

제1 차량은 상기 제2 차량으로부터, 상기 제1 NS 메시지의 응답으로서, 제1 이웃 알림(Neighbor Advertisement, NA) 메시지를 수신한다(S1020).

제1 차량은 상기 제1 NA 메시지에 근거하여, 상기 제2 차량으로, 상기 제2 차량을 릴레이 차량으로 등록하기 위한 제2 NS 메시지를 전송한다(S1030).

또한, 제1 차량은 상기 제2 차량을 통해, 상기 RSU 로부터 상기 제2 NS 메시지의 응답으로서, 제2 NA 메시지를 수신할 수 있다. 보다 자세하게, 상기 제2 NA 메시지는 상기 IP 기반 차량 네트워크의 이동성을 관리하는 이동성 앵커(Mobility Anchor)에 포함된 중복 주소를 관리하기 위한 제1 테이블에 근거하여 생성될 수 있다. 예를 들어, 제1 테이블은 DAD 테이블을 포함할 수 있다.

또한, 제1 차량은 상기 제1 NA 메시지를 수신하기 위해, 기설정된 시간 동안 대기하고, 상기 제1 NA 메시지에 근거하여, 상기 제2 차량을 선택할 수 있다, 예를 들어, 이러한, 하나 이상의 제1 NS 메시지는 주변 차량들에게 멀티캐스팅 될 수 있다. 보다 자세하게, 제1 차량은 제1 NA 메시지에 포함된 홉수에 따라, 가장 적은 홉수를 갖는 차량을 제2 차량으로 선택할 수 있다.

또한, 상기 릴레이 차량이 복수개인 경우, 상기 제1 차량 및 상기 릴레이 차량은 상기 RSU 까지의 릴레이(Relay) 패스(Path)를 나타내기 위한 제2 테이블을 갖을 수 있다. 예를 들어, 제2 테이블은 Neighbor Routing Table을 포함할 수 있다.

본 명세서가 적용될 수 있는 장치 일반

도 11을 참조하면 제안하는 실시 예에 따른 서버(X200)는, MEC(Multi-Access Edge Computing) 서버 또는 클라우드 서버 일 수 있으며, 통신모듈(X210), 프로세서(X220) 및 메모리(X230)를 포함할 수 있다. 통신모듈(X210)은 무선 주파수(radio frequency, RF) 유닛으로 칭해지기도 한다. 통신모듈(X210)은 외부 장치로 각종 신호, 데이터 및 정보를 전송하고, 외부 장치로 각종 신호, 데이터 및 정보를 수신하도록 구성될 수 있다. 서버(X200)는 외부 장치와 유선 및/또는 무선으로 연결될 수 있다. 통신모듈(X210)은 전송부와 수신부로 분리되어 구현될 수도 있다. 프로세서(X220)는 서버(X200) 전반의 동작을 제어할 수 있으며, 서버(X200)가 외부 장치와 송수신할 정보 등을 연산 처리하는 기능을 수행하도록 구성될 수 있다. 또한, 프로세서(X220)는 본 발명에서 제안하는 서버 동작을 수행하도록 구성될 수 있다. 프로세서(X220)은 본 발명의 제안에 따라 데이터 혹은 메시지를 UE(User Equipment) 혹은 다른 차량, 다른 서버에 전송하도록 통신모듈(X210)을 제어할 수 있다. 메모리(X230)는 연산 처리된 정보 등을 소정시간 동안 저장할 수 있으며, 버퍼 등의 구성요소로 대체될 수 있다.

또한, 위와 같은 단말 장치(X100) 및 서버(X200)의 구체적인 구성은, 전술한 본 발명의 다양한 실시예에서 설명한 사항들이 독립적으로 적용되거나 또는 2 이상의 실시예가 동시에 적용되도록 구현될 수 있으며, 중복되는 내용은 명확성을 위하여 설명을 생략한다.

이상에서 설명된 실시 예들은 본 명세서의 구성요소들과 특징들이 소정 형태로 결합된 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려되어야 한다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성요소들 및/또는 특징들을 결합하여 본 명세서의 실시 예를 구성하는 것도 가능하다. 본 명세서의 실시 예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시 예에 포함될 수 있고, 또는 다른 실시예의 대응하는 구성 또는 특징과 교체될 수 있다. 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시 예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함시킬 수 있음은 자명하다.

본 명세서에 따른 실시 예는 다양한 수단, 예를 들어, 하드웨어, 펌웨어(firmware), 소프트웨어 또는 그것들의 결합 등에 의해 구현될 수 있다. 하드웨어에 의한 구현의 경우, 본 명세서의 일 실시 예는 하나 또는 그 이상의 ASICs(application specific integrated circuits), DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays), 프로세서, 콘트롤러, 마이크로 콘트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다.

펌웨어나 소프트웨어에 의한 구현의 경우, 본 명세서의 일 실시 예는 이상에서 설명된 능력 또는 동작들을 수행하는 모듈, 절차, 함수 등의 형태로 구현될 수 있다. 소프트웨어 코드는 메모리에 저장되어 프로세서에 의해 구동될 수 있다. 상기 메모리는 상기 프로세서 내부 또는 외부에 위치하여, 이미 공지된 다양한 수단에 의해 상기 프로세서와 데이터를 주고 받을 수 있다.

본 명세서는 본 명세서의 필수적 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있음은 당업자에게 자명하다. 따라서, 상술한 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니 되고 예시적인 것으로 고려되어야 한다. 본 명세서의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 명세서의 등가적 범위 내에서의 모든 변경은 본 명세서의 범위에 포함된다.

본 명세서는 다양한 차량용 네트워크 시스템에 적용될 수 있다.

Claims (10)

1. 삭제
2. 삭제
3. 삭제
4. 삭제
5. 삭제
6. 복수 개의 RSU(Road-Side Unit)가 도로변을 따라 배치되고, 상기 복 수개의 RSU 중 일부는 무선 링크인 제1 서브넷을 통해 복수 개의 차량 중 일부 차량과 연결되고, RSU 중 다른 일부는 제1 서브넷과 구분되는 제2 서브넷을 통해 상기 복수 개의 차량 중 다른 차량과 연결되는 IP 기반 차량 네트워크 시스템에서,
   이웃 검색(Neighbor Discovery)을 수행하는 상기 제1 서브넷에 속한 제1 차량은,
   신호를 송수신하기 위한 송수신기;
   데이터를 저장하는 메모리; 및
   상기 송수신기 및 상기 메모리를 제어하는 프로세서;를 포함하고,
   상기 프로세서는
   상기 송수신기를 통해, 상기 제1 차량이 제2 서브넷에 속한 RSU에 직접 등록을 위한 라우터 검색(Router Discovery)이 실패한 경우, 상기 제2 서브넷에 속한 제2 차량으로 하나 이상의 제1 이웃 간청(Neighbor Solicitation, NS) 메시지를 전송하고, 상기 제2 차량으로부터, 상기 제1 NS 메시지의 응답으로서, 제1 이웃 알림(Neighbor Advertisement, NA) 메시지를 수신하며, 상기 제1 NA 메시지에 근거하여, 상기 제2 차량으로, 상기 제2 차량을 릴레이 차량으로 등록하기 위한 제2 NS 메시지를 전송하고,
   상기 복수개의 차량은, 상기 제1 서브넷과 상기 제2 서브넷에 속하는 동안 각각의 서브넷에서 같은 프리픽스가 할당되고, 상기 제1 서브넷에서 할당된 프리픽스와 상기 제2 서브넷에서 할당된 프리픽스는 다른, IP 기반 차량 네트워크 시스템.
   
7. 제6 항에 있어서,
   상기 프로세서는
   상기 제2 차량을 통해, 상기 RSU 로부터 상기 제2 NS 메시지의 응답으로서, 제2 NA 메시지를 수신하는, IP 기반 차량 네트워크 시스템.
   
8. 제7 항에 있어서,
   상기 제2 NA 메시지는
   상기 IP 기반 차량 네트워크의 이동성을 관리하는 이동성 앵커(Mobility Anchor, MA)에 포함된 중복 주소를 관리하기 위한 제1 테이블에 근거하여 생성되는, IP 기반 차량 네트워크 시스템.
   
9. 제8 항에 있어서,
   상기 프로세서는
   상기 제1 NA 메시지를 수신하기 위해, 기설정된 시간 동안 대기하고, 상기 제1 NA 메시지에 근거하여, 상기 제2 차량을 선택하며,
   상기 하나 이상의 제1 NS 메시지는 주변 차량들에게 멀티캐스팅되는, IP 기반 차량 네트워크 시스템.
   
10. 제8 항에 있어서,
    상기 릴레이 차량이 복수개인 경우, 상기 제1 차량 및 상기 릴레이 차량은 상기 RSU 까지의 릴레이(Relay) 패스(Path)를 나타내기 위한 제2 테이블을 갖는, IP 기반 차량 네트워크 시스템.
    

Images