KR20180112842A

KR20180112842A - 데이터 유닛을 전송하는 방법 및 사용자기기와, 데이터 유닛을 수신하는 방법 및 사용자기기

Info

Publication number: KR20180112842A
Application number: KR1020187026520A
Authority: KR
Inventors: 천성덕; 김래영; 김동수
Original assignee: 엘지전자 주식회사
Priority date: 2016-03-22
Filing date: 2017-03-22
Publication date: 2018-10-12
Also published as: EP3435702A4; US11070963B2; EP3435702A2; KR102127397B1; CN108781383A; WO2017164641A2; WO2017164641A3; CN108781383B; US10638285B2; US20190110175A1; EP3435702B1; US20200236519A1

Abstract

사용자기기(user equipment, UE)가 프로토콜 데이터 유닛(protocol data unit, PDU)을 수신 혹은 전송할 수 있다. 상기 PDU는 서비스 데이터 유닛(service data unit, SDU) 타입 필드를 포함한다. 상기 SDU 타입 필드는 V2X(Vehicle-to-Everything) 타입임을 나타내는 값으로 세팅될 수 있다. 상기 SDU 타입 필드가 V2X 타입임을 나타내는 값으로 세팅되면, 상기 PDU는 상기 PDU 내 SDU의 데이터를 위한 어플리케이션 혹은 프로토콜 타입을 지시하는 추가 필드를 포함할 수 있다.

Description

데이터 유닛을 전송하는 방법 및 사용자기기와, 데이터 유닛을 수신하는 방법 및 사용자기기

본 발명은 무선 통신 시스템에 관한 것으로서, 데이터 유닛을 전송/수신하는 방법 및 장치에 관한 것이다.

무선 통신 시스템이 음성이나 데이터 등과 같은 다양한 종류의 통신 서비스를 제공하기 위해 광범위하게 전개되고 있다. 일반적으로 무선 통신 시스템은 가용한 시스템 자원(대역폭, 전송 파워 등)을 공유하여 다중 사용자와의 통신을 지원할 수 있는 다중 접속(multiple access) 시스템이다. 다중 접속 시스템의 예들로는 CDMA(code division multiple access) 시스템, FDMA(frequency division multiple access) 시스템, TDMA(time division multiple access) 시스템, OFDMA(orthogonal frequency division multiple access) 시스템, SC-FDMA(single carrier frequency division multiple access) 시스템, MC-FDMA(multi carrier frequency division multiple access) 시스템 등이 있다.

기기간(Machine-to-Machine, M2M) 통신과, 높은 데이터 전송량을 요구하는 스마트폰, 태블릿 PC 등의 다양한 장치 및 기술이 출현 및 보급되고 있다. 이에 따라, 셀룰러 네트워크에서 처리될 것이 요구되는 데이터 양이 매우 빠르게 증가하고 있다. 이와 같이 빠르게 증가하는 데이터 처리 요구량을 만족시키기 위해, 더 많은 주파수 대역을 효율적으로 사용하기 위한 반송파 집성(carrier aggregation) 기술, 인지무선(cognitive radio) 기술 등과, 한정된 주파수 내에서 전송되는 데이터 용량을 높이기 위한 다중 안테나 기술, 다중 기지국 협력 기술 등이 발전하고 있다.

한편, 사용자기기(user equipment, UE)가 주변에서 접속(access)할 수 있는 노드(node)의 밀도가 높아지는 방향으로 통신 환경이 진화하고 있다. 노드라 함은 하나 이상의 안테나를 구비하여 UE와 무선 신호를 전송/수신할 수 있는 고정된 지점(point)을 말한다. 높은 밀도의 노드를 구비한 통신 시스템은 노드들 간의 협력에 의해 더 높은 성능의 통신 서비스를 UE에게 제공할 수 있다.

V2X(Vehicle to Everything) 통신 시스템에서 차량 어플리케이션 데이터를 효과적으로 처리하기 위한 방안이 요구된다.

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

PDU 내 SDU의 타입을 나타내는 SDU 타입 필드는 적어도 상기 SDU의 데이터가 V2X용 IP(internet protocol)인지, 비-V2X용 IP인지, V2X용 비-IP인지 혹은 비-V2X용 비-IP인지를 구별할 수 있다.

본 발명의 일 양상으로, 무선 통신 시스템에서 사용자기기(user equipment, UE)가 데이터 유닛을 수신하는 방법이 제공된다. 상기 방법은: 프로토콜 데이터 유닛(protocol data unit, PDU)을 수신; 및 상기 PDU 내 서비스 데이터 유닛(service data unit, SDU) 타입 필드가 V2X(Vehicle-to-Everything) 타입임을 나타내는 값으로 세팅되어 있으면, 상기 PDU 내 추가 필드를 기반으로 상기 PDU 내 SDU를 상위 계층으로 전달 혹은 삭제하는 것을 포함할 수 있다. 상기 추가 필드는 상기 SDU의 데이터에 대응하는 어플리케이션 혹은 프로토콜 타입을 지시할 수 있다.

본 발명의 다른 양상으로, 무선 통신 시스템에서 데이터 유닛을 수신하는 사용자기기(user equipment, UE)가 제공된다. 상기 사용자기기는 무선 주파수(radio frequency, RF) 유닛 및 상기 RF 유닛을 제어하도록 구성된 프로세서를 포함하여 구성된다. 상기 프로세서는: 프로토콜 데이터 유닛(protocol data unit, PDU)을 수신하도록 상기 RF 유닛을 제어; 및 상기 PDU 내 서비스 데이터 유닛(service data unit, SDU) 타입 필드가 V2X(Vehicle-to-Everything) 타입임을 나타내는 값으로 세팅되어 있으면, 상기 PDU 내 추가 필드를 기반으로 상기 PDU 내 SDU를 상위 계층으로 전달 혹은 삭제할 수 있다. 상기 추가 필드는 상기 SDU의 데이터에 대응하는 어플리케이션 혹은 프로토콜 타입을 지시할 수 있다.

본 발명의 또 다른 양상으로, 무선 통신 시스템에서 사용자기기(user equipment, UE)가 데이터 유닛을 전송하는 방법이 제공된다. 상기 방법은: 상위 계층에서 생성된 V2X(Vehicle-to-Everything) 데이터를 담은 서비스 데이터 유닛(service data unit, SDU)를 포함하는 프로토콜 데이터 유닛(protocol data unit, PDU)를 생성; 및 상기 PDU를 전송하는 것을 포함할 수 있다. 상기 PDU는 상기 SDU가 V2X 타입임을 나타내는 값으로 세팅된 SDU 타입 필드와, 상기 SDU의 데이터에 해당하는 어플리케이션 혹은 프로토콜 타입을 지시하는 추가 필드를 포함할 수 있다.

본 발명의 또 다른 양상으로, 무선 통신 시스템에서 데이터 유닛을 전송하는 사용자기기(user equipment, UE)가 제공된다.상기 사용자기기는 무선 주파수(radio frequency, RF) 유닛 및 상기 RF 유닛을 제어하도록 구성된 프로세서를 포함하여 구성된다. 상기 프로세서는: 상위 계층에서 생성된 V2X(Vehicle-to-Everything) 데이터를 담은 서비스 데이터 유닛(service data unit, SDU)를 포함하는 프로토콜 데이터 유닛(protocol data unit, PDU)를 생성; 및 상기 PDU를 전송하도록 상기 RF 유닛을 제어할 수 있다. 상기 PDU는 상기 SDU가 V2X 타입임을 나타내는 값으로 세팅된 SDU 타입 필드와, 상기 SDU의 데이터에 해당하는 어플리케이션 혹은 프로토콜 타입을 지시하는 추가 필드를 포함할 수 있다.

본 발명의 각 양상에 있어서, 상기 SDU 타입 필드는 적어도 상기 SDU의 데이터가 V2X용 IP(internet protocol)인지, 비-V2X용 IP인지, V2X용 비-IP인지 혹은 비-V2X용 비-IP인지를 구별할 수 있다.

본 발명의 각 양상에 있어서, 상기 UE가 상기 어플리케이션 혹은 프로토콜 타입을 지원하면 상기 SDU가 상기 상위 계층으로 전달될 수 있다. 상기 UE가 상기 어플리케이션 혹은 프로토콜 타입을 지원하지 않으면 상기 SDU가 삭제될 수 있다.

본 발명의 각 양상에 있어서, 상기 상위 계층은 ITS(Intelligent Transport Systems) 계층일 수 있다.

상기 과제 해결방법들은 본 발명의 실시예들 중 일부에 불과하며, 본원 발명의 기술적 특징들이 반영된 다양한 실시예들이 당해 기술분야의 통상적인 지식을 가진 자에 의해 이하 상술할 본 발명의 상세한 설명을 기반으로 도출되고 이해될 수 있다.

V2X(Vehicle to Everything) 통신 시스템에서 차량 어플리케이션 데이터가 효과적으로 처리될 수 있다.

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

본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도면은 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 사상을 설명한다.
도 1은 EPC(Evolved Packet Core)를 포함하는 EPS(Evolved Packet System)의 개략적인 구조를 나타내는 도면이다.
도 2는 일반적인 E-UTRAN과 EPC의 아키텍처를 나타낸 예시도이다.
도 3은 제어 평면에서의 무선 인터페이스 프로토콜의 구조를 나타낸 예시도이다.
도 4는 사용자 평면에서의 무선 인터페이스 프로토콜의 구조를 나타낸 예시도이다.
도 5는 사용자 평면 및 제어 평면을 위한 LTE(Long Term Evolution) 프로토콜 스택들을 예시한 것이다.
도 6은 임의 접속(random access) 과정을 설명하기 위한 흐름도이다.
도 7은 무선 자원 제어(RRC) 계층에서의 연결 과정을 나타내는 도면이다.
도 8은 V2X (Vehicle to everything) 통신 환경을 나타내는 도면이다.
도 9는 ETSI ITS에서 제정하는 ITS 프로토콜 구조를 예시한 것이다.
도 10은 3GPP 기반 V2X 시스템에서 구현되는 네트워크 구조를 예시한 것이다.
도 11은 ProSe 통신에서 사용되는 사용자 평면 프로토콜 스택을 예시한 것이다.
도 12는 V2X 통신에 사용 가능한 프로토콜 스택을 예시한 것이다.
도 13은 본 발명에 따른 PDCP PDU 구조를 예시한 것이다.
도 14는 본 발명의 제안에 적용되는 노드 장치의 구성을 도시하는 도면이다.

본 발명에서 사용되는 용어는 본 발명에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어들을 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도 또는 판례, 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 발명의 설명 부분에서 상세히 그 의미를 기재할 것이다. 따라서 본 발명에서 사용되는 용어는 단순한 용어의 명칭이 아닌, 그 용어가 가지는 의미와 본 발명의 전반에 걸친 내용을 토대로 정의되어야 한다.

이하의 실시 예들은 본 발명의 구성요소들과 특징들을 소정 형태로 결합한 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려될 수 있다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성요소들 및/또는 특징들을 결합하여 본 발명의 실시 예를 구성할 수도 있다. 본 발명의 실시 예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시 예의 일부 구성이나 특징은 다른 실시 예에 포함될 수 있고, 또는 다른 실시 예의 대응하는 구성 또는 특징과 교체될 수 있다.

도면에 대한 설명에서, 본 발명의 요지를 흐릴 수 있는 절차 또는 단계 등은 기술하지 않았으며, 당업자의 수준에서 이해할 수 있을 정도의 절차 또는 단계는 또한 기술하지 아니하였다.

명세서 전체에서, 어떤 부분이 어떤 구성요소를 "포함(comprising 또는 including)"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있는 것을 의미한다. 또한, 명세서에 기재된 "...부", "...기", "모듈" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하드웨어나 소프트웨어 또는 하드웨어 및 소프트웨어의 결합으로 구현될 수 있다. 또한, "일(a 또는 an)", "하나(one)", "그(the)" 및 유사 관련어는 본 발명을 기술하는 문맥에 있어서(특히, 이하의 청구항의 문맥에서) 본 명세서에 달리 지시되거나 문맥에 의해 분명하게 반박되지 않는 한, 단수 및 복수 모두를 포함하는 의미로 사용될 수 있다.

본 발명의 실시 예들은 무선 접속 시스템들인 IEEE 802.xx 시스템, 3GPP 시스템, 3GPP LTE 시스템 및 3GPP2 시스템 중 적어도 하나에 개시된 표준 문서들에 의해 뒷받침될 수 있다. 즉, 본 발명의 실시 예들 중 설명하지 않은 자명한 단계들 또는 부분들은 상기 문서들을 참조하여 설명될 수 있다.

또한, 본 문서에서 개시하고 있는 모든 용어들은 상기 표준 문서에 의해 설명될 수 있다. 예를 들어, 본 명세서는 3GPP TS 36.300, 3GPP TS 36.321, 3GPP TS 36.322, 3GPP TS 36.323, 3GPP TS 36.331, 3GPP TS 23.303, 3GPP TS 23.401, 3GPP TS 24.301, 3GPP TR 22.885, TS 23.285, ETSI TS 302 637-2, ETSI TS 302 637-3, ETS TR 102 638, IEEE 1609.12의 표준 문서들 중 하나 이상에 의해 뒷받침될(incorporate by reference) 수 있다.

이하, 본 발명에 따른 바람직한 실시 형태를 첨부된 도면을 참조하여 상세하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 발명의 예시적인 실시형태를 설명하고자 하는 것이며, 본 발명이 실시될 수 있는 유일한 실시형태를 나타내고자 하는 것이 아니다.

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

먼저, 본 명세서에서 사용되는 용어들은 다음과 같이 정의된다.

- IMS(IP Multimedia Subsystem or IP Multimedia Core Network Subsystem): IP 상으로 음성 또는 다른 멀티미디어 서비스를 배달하기 위한 표준화를 제공하기 위한 구조적(architectural) 프레임워크(framework).

- UMTS(Universal Mobile Telecommunications System): 3GPP에 의해서 개발된, GSM(Global System for Mobile Communication) 기반의 3 세대(Generation) 이동 통신 기술.

- EPS(Evolved Packet System): IP(Internet Protocol) 기반의 PS(packet switched) 코어(core) 네트워크인 EPC(Evolved Packet Core)와 LTE/UTRAN 등의 접속(access) 네트워크로 구성된 네트워크 시스템. UMTS가 진화된 형태의 네트워크이다.

- NodeB: GERAN/UTRAN의 기지국. 옥외에 설치하며 커버리지는 매크로 셀(macro cell) 규모이다.

- eNodeB/eNB: E-UTRAN의 기지국. 옥외에 설치하며 커버리지는 매크로 셀(macro cell) 규모이다.

- UE(User Equipment): 사용자 기기. UE는 UE(terminal), ME(Mobile Equipment), MS(Mobile Station) 등의 용어로 언급될 수도 있다. 또한, UE는 노트북, 휴대폰, PDA(Personal Digital Assistant), 스마트폰, 멀티미디어 기기 등과 같이 휴대 가능한 기기일 수 있고, 또는 PC(Personal Computer), 차량 탑재 장치와 같이 휴대 불가능한 기기일 수도 있다. MTC 관련 내용에서 UE 또는 단말이라는 용어는 MTC 디바이스를 지칭할 수 있다.

- HNB(Home NodeB): UMTS 네트워크의 기지국으로서 옥내에 설치하며 커버리지는 마이크로 셀(micro cell) 규모이다.

- HeNB(Home eNodeB): EPS 네트워크의 기지국으로서 옥내에 설치하며 커버리지는 마이크로 셀 규모이다.

- MME(Mobility Management Entity): 이동성 관리(Mobility Management; MM), 세션 관리(Session Management; SM) 기능을 수행하는 EPS 네트워크의 네트워크 노드.

- PDN-GW(Packet Data Network-Gateway)/PGW/P-GW: UE IP 주소 할당, 패킷 스크리닝(screening) 및 필터링, 과금 데이터 취합(charging data collection) 기능 등을 수행하는 EPS 네트워크의 네트워크 노드.

- SGW(Serving Gateway)/S-GW: 이동성 앵커(mobility anchor), 패킷 라우팅(routing), 휴지(idle) 모드 패킷 버퍼링, MME가 UE를 페이징하도록 트리거링하는 기능 등을 수행하는 EPS 네트워크의 네트워크 노드.

- PCRF (Policy and Charging Rule Function): 서비스 플로우(service flow)별로 차별화된 QoS 및 과금 정책을 동적(dynamic) 으로 적용하기 위한 정책 결정(Policy decision)을 수행하는 EPS 네트워크의 네트워크 노드.

- OMA DM (Open Mobile Alliance Device Management): 핸드폰, PDA, 휴대용 컴퓨터 등과 같은 모바일 디바이스들 관리를 위해 디자인 된 프로토콜로써, 디바이스 설정(configuration), 펌웨어 업그레이드(firmware upgrade), 오류 보고 (Error Report)등의 기능을 수행함.

- OAM (Operation Administration and Maintenance): 네트워크 결함 표시, 성능정보, 그리고 데이터와 진단 기능을 제공하는 네트워크 관리 기능군.

- NAS(Non-Access Stratum): UE와 MME 간의 제어 플레인(control plane)의 상위 단(stratum). LTE/UMTS 프로토콜 스택에서 UE와 코어(core) 네트워크간의 시그널링, 트래픽 메시지를 주고 받기 위한 기능적인 계층으로서, UE의 이동성을 지원하고, UE와 PDN GW 간의 IP 연결을 수립(establish) 및 유지하는 세션 관리 절차 및 IP 주소 관리 등을 지원한다.

- EMM (EPS Mobility Management): NAS 계층의 서브-계층으로서, UE가 네트워크 어태치(attach)되어 있는지 디태치(detach)되어 있는지에 따라 EMM은 "EMM-Registered" 아니면 "EMM-Deregistered" 상태에 있을 수 있다.

- ECM (EMM Connection Management) 연결(connection): UE와 MME가 사이에 수립(establish)된, NAS 메시지의 교환(exchange)을 위한 시그널링 연결(connection). ECM 연결은 UE와 eNB 사이의 RRC 연결과 상기 eNB와 MME 사이의 S1 시그널링 연결로 구성된 논리(logical) 연결이다. ECM 연결이 수립(establish)/종결(terminate)되면, 상기 RRC 및 S1 시그널링 연결은 마찬가지로 수립/종결된다. 수립된 ECM 연결은 UE에게는 eNB와 수립된 RRC 연결을 갖는 것을 의미하며, MME에게는 상기 eNB와 수립된 S1 시그널링 연결을 갖는 것을 의미한다. NAS 시그널링 연결, 즉, ECM 연결이 수립되어 있는지에 따라, ECM은 "ECM-Connected" 아니면 "ECM-Idle" 상태를 가질 수 있다.

- AS (Access-Stratum): UE와 무선(혹은 접속) 네트워크 간의 프로토콜 스택을 포함하며, 데이터 및 네트워크 제어 신호 전송 등을 담당한다.

- NAS 설정(configuration) MO (Management Object): NAS 기능(Functionality)과 연관된 파라미터들(parameters)을 UE에게 설정하는 과정에서 사용되는 MO (Management object).

- PDN(Packet Data Network): 특정 서비스를 지원하는 서버(예를 들어, MMS(Multimedia Messaging Service) 서버, WAP(Wireless Application Protocol) 서버 등)가 위치하고 있는 네트워크.

- PDN 연결: 하나의 IP 주소(하나의 IPv4 주소 및/또는 하나의 IPv6 프리픽스)로 표현되는, UE와 PDN 간의 논리적인 연결.

- APN (Access Point Name): PDN을 지칭하거나 구분하는 문자열. 요청한 서비스나 네트워크에 접속하기 위해서는 특정 P-GW를 거치게 되는데, 이 P-GW를 찾을 수 있도록 네트워크 내에서 미리 정의한 이름(문자열)을 의미한다. (예를 들어, internet.mnc012.mcc345.gprs)

- RAN(Radio Access Network): 3GPP 네트워크에서 NodeB, eNodeB 및 이들을 제어하는 RNC(Radio Network Controller)를 포함하는 단위. UE 간에 존재하며 코어 네트워크로의 연결을 제공한다.

- HLR(Home Location Register)/HSS(Home Subscriber Server): 3GPP 네트워크 내의 가입자 정보를 가지고 있는 데이터베이스. HSS는 설정 저장(configuration storage), 식별자 관리(identity management), 사용자 상태 저장 등의 기능을 수행할 수 있다.

- PLMN(Public Land Mobile Network): 개인들에게 이동통신 서비스를 제공할 목적으로 구성된 네트워크. 사업자별로 구분되어 구성될 수 있다.

- ANDSF(Access Network Discovery and Selection Function): 하나의 네트워크 엔티티(entity)로서 사업자 단위로 UE가 사용 가능한 접속(access)을 발견하고 선택하도록 하는 정책(policy)를 제공.

- EPC 경로(또는 infrastructure data path): EPC를 통한 사용자 평면 통신 경로.

- E-RAB (E-UTRAN Radio Access Bearer): S1 베어러와 해당 데이터 무선 베어러의 연결(concatenation)을 말한다. E-RAB가 존재하면 상기 E-RAB와 NAS의 EPS 베어러 사이에 일대일 매핑이 있다.

- GTP (GPRS Tunneling Protocol): GSM, UMTS 및 LTE 네트워크들 내에서 일반 패킷 무선 서비스(general packet radio service, GPRS)를 나르기 위해 사용되는 IP-기반 통신들 프로토콜들의 그룹. 3GPP 아키텍쳐 내에는, GTP 및 프록시 모바일 IPv6 기반 인터페이스들이 다양한 인터페이스 포인트 상에 특정(specify)되어 있다. GTP는 몇몇 프로토콜들(예, GTP-C, GTP-U 및 GTP')으로 분해(decompose)될 수 있다. GTP-C는 게이트웨이 GPRS 지원 노드들(GGSN) 및 서빙 GPRS 지원 노드들(SGSN) 간 시그널링을 위해 GPRS 코어(core) 네트워크 내에서 사용된다. GTP-C는 상기 SGSN이 사용자를 위해 세션을 활성화(activate)(예, PDN 컨텍스트 활성화(activation))하는 것, 동일 세션을 비활성화(deactivate)하는 것, 서비스 파라미터들의 품질(quality)를 조정(adjust)하는 것, 또는 다른 SGSN으로부터 막 동작한 가입자(subscriber)를 위한 세션을 갱신하는 것을 허용한다. GTP-U는 상기 GPRS 코어 네트워크 내에서 그리고 무선 접속 네트워크 및 코어 네트워크 간에서 사용자 데이터를 나르기 위해 사용된다. 도 1은 EPC(Evolved Packet Core)를 포함하는 EPS(Evolved Packet System)의 개략적인 구조를 나타내는 도면이다.

- 근접 서비스(proximity service)(또는 ProSe 서비스 또는 근접 기반 서비스(proximity based service)): 물리적으로 근접한 장치 사이의 디스커버리 및 상호 직접적인 통신 또는 기지국을 통한 통신 또는 제3의 장치를 통한 통신이 가능한 서비스. 이때, 사용자 평면 데이터(user plane data)는 3GPP 코어 네트워크(예를 들어, EPC)를 거치지 않고 직접 데이터 경로(direct data path)를 통해 교환된다.

- ProSe 통신(communication): 둘 이상의 ProSe 가능한 UE들 사이의 ProSe 통신 경로를 통한 통신을 의미한다. 특별히 달리 언급되지 않는 한, ProSe 통신은 ProSe E-UTRA 통신, 두 UE 사이의 ProSe-보조(ProSe-assisted) WLAN 직접(direct) 통신, ProSe 그룹 통신 또는 ProSe 브로드캐스트 통신 중 하나를 의미한다.

- ProSe E-UTRA 통신 : ProSe E-UTRA 통신 경로를 사용한 ProSe 통신.

- ProSe-보조 WLAN 직접 통신(ProSe-assisted WLAN direct communication): 직접 통신 경로를 사용한 ProSe 통신.

- ProSe 통신 경로 : ProSe 통신을 지원하는 통신 경로로서, ProSe E-UTRA 통신 경로는 E-UTRA를 사용하여 ProSe-가능화된(enabled) UE들 사이에서 또는 로컬 eNB를 통해 수립될 수 있다. ProSe-보조 WLAN 직접 통신 경로는 WLAN을 사용하여 ProSe-가능화된 UE들 사이에서 직접 수립될 수 있다.

- EPC 경로(또는 기간(infrastructure) 데이터 경로): EPC를 통한 사용자 평면 통신 경로.

- ProSe 디스커버리: E-UTRA를 사용하여, 근접한 ProSe-가능화된 UE를 식별/확인하는 과정.

- ProSe 그룹 통신: 근접한 둘 이상의 ProSe-가능화된 UE들 사이에서, 공통 통신 경로를 사용하는 일 대 다 ProSe 통신

- ProSe UE-to-네트워크(UE-to-Network) 릴레이: E-UTRA를 사용하는 ProSe-가능화된 네트워크와 ProSe-가능화된 UE 사이의 통신 릴레이로 동작하는 ProSe-가능화된 공공 안전 UE.

- 리모트 UE(remote UE): E-UTRAN에 의해 서비스되지 않고, ProSe UE-to-네트워크 릴레이를 통해 EPC 네트워크에 연결되는, 즉, PDN으로 통신하는 ProSe-가능화된 UE.

EPC는 3GPP 기술들의 성능을 향상하기 위한 SAE(System Architecture Evolution)의 핵심적인 요소이다. SAE는 다양한 종류의 네트워크 간의 이동성을 지원하는 네트워크 구조를 결정하는 연구 과제에 해당한다. SAE는, 예를 들어, IP 기반으로 다양한 무선 접속 기술들을 지원하고 보다 향상된 데이터 전송 능력(capability)를 제공하는 등의 최적화된 패킷-기반 시스템을 제공하는 것을 목표로 한다.

구체적으로, EPC는 3GPP LTE 시스템을 위한 IP 이동 통신 시스템의 코어 네트워크이며, 패킷-기반 실시간 및 비실시간 서비스를 지원할 수 있다. 기존의 이동 통신 시스템(즉, 2 세대 또는 3 세대 이동 통신 시스템)에서는 음성을 위한 CS(Circuit-Switched) 및 데이터를 위한 PS(Packet-Switched)의 2 개의 구별되는 서브-도메인을 통해서 코어 네트워크의 기능이 구현되었다. 그러나, 3 세대 이동 통신 시스템의 진화인 3GPP LTE 시스템에서는, CS 및 PS의 서브-도메인들이 하나의 IP 도메인으로 단일화되었다. 즉, 3GPP LTE 시스템에서는, IP 능력(capability)를 가지는 UE와 UE 간의 연결이, IP 기반의 기지국(예를 들어, eNodeB(evolved Node B)), EPC, 애플리케이션 도메인(예를 들어, IMS(IP Multimedia Subsystem))을 통하여 구성될 수 있다. 즉, EPC는 단-대-단(end-to-end) IP 서비스 구현에 필수적인 구조이다.

EPC는 다양한 구성요소들을 포함할 수 있으며, 도 1에서는 그 중에서 일부에 해당하는, SGW(Serving Gateway), PDN GW(Packet Data Network Gateway), MME(Mobility Management Entity), SGSN(Serving GPRS(General Packet Radio Service) Supporting Node), ePDG(enhanced Packet Data Gateway)를 도시한다.

SGW(또는 S-GW)는 무선 접속 네트워크(RAN)와 코어 네트워크 사이의 경계점으로서 동작하고, eNB와 PDN GW 사이의 데이터 경로를 유지하는 기능을 하는 요소이다. 또한, UE가 eNB에 의해서 서빙(serving)되는 영역에 걸쳐 이동하는 경우, SGW는 로컬 이동성 앵커 포인트(anchor point)의 역할을 한다. 즉, E-UTRAN (3GPP 릴리즈-8 이후에서 정의되는 Evolved-UMTS(Universal Mobile Telecommunications System) Terrestrial Radio Access Network) 내에서의 이동성을 위해서 SGW를 통해서 패킷들이 라우팅될 수 있다. 또한, SGW는 다른 3GPP 네트워크(3GPP 릴리즈-8 전에 정의되는 RAN, 예를 들어, UTRAN 또는 GERAN(GSM(Global System for Mobile Communication)/EDGE(Enhanced Data rates for Global Evolution) Radio Access Network)와의 이동성을 위한 앵커 포인트로서 기능할 수도 있다.

PDN GW(또는 P-GW)는 패킷 데이터 네트워크를 향한 데이터 인터페이스의 종료 포인트(termination point)에 해당한다. PDN GW는 정책 집행 특징(policy enforcement features), 패킷 필터링(packet filtering), 과금 지원(charging support) 등을 지원할 수 있다. 또한, 3GPP 네트워크와 비-3GPP 네트워크 (예를 들어, I-WLAN(Interworking Wireless Local Area Network)과 같은 신뢰되지 않는 네트워크, CDMA(Code Division Multiple Access) 네트워크나 WiMax와 같은 신뢰되는 네트워크)와의 이동성 관리를 위한 앵커 포인트 역할을 할 수 있다.

도 1의 네트워크 구조의 예시에서는 SGW와 PDN GW가 별도의 게이트웨이로 구성되는 것을 나타내지만, 두 개의 게이트웨이가 단일 게이트웨이 구성 옵션(Single Gateway Configuration Option)에 따라 구현될 수도 있다.

MME는, UE의 네트워크 연결에 대한 접속(access), 네트워크 자원의 할당, 트래킹(tracking), 페이징(paging), 로밍(roaming) 및 핸드오버 등을 지원하기 위한 시그널링 및 제어 기능들을 수행하는 요소이다. MME는 가입자 및 세션 관리에 관련된 제어 평면(control plane) 기능들을 제어한다. MME는 수많은 eNB들을 관리하고, 다른 2G/3G 네트워크에 대한 핸드오버를 위한 종래의 게이트웨이의 선택을 위한 시그널링을 수행한다. 또한, MME는 보안 과정(Security Procedures), 단말-대-네트워크 세션 핸들링(Terminal-to-network Session Handling), 휴지 단말 위치결정 관리(Idle Terminal Location Management) 등의 기능을 수행한다.

SGSN은 다른 3GPP 네트워크(예를 들어, GPRS 네트워크)에 대한 사용자의 이동성 관리 및 인증(authentication)과 같은 모든 패킷 데이터를 핸들링한다.

ePDG는 신뢰되지 않는 비-3GPP 네트워크(예를 들어, I-WLAN, WiFi 핫스팟(hotspot) 등)에 대한 보안 노드로서의 역할을 한다.

도 1을 참조하여 설명한 바와 같이, IP 능력(capability)를 가지는 UE는, 3GPP 접속은 물론 비-3GPP 접속 기반으로도 EPC 내의 다양한 요소들을 경유하여 사업자(즉, 운영자(operator))가 제공하는 IP 서비스 네트워크(예를 들어, IMS)에 접속할 수 있다.

또한, 도 1은 다양한 참조 포인트(reference point)들(예를 들어, S1-U, S1-MME 등)을 도시한다. 3GPP 시스템에서는 E-UTRAN 및 EPC의 상이한 기능 엔티티(functional entity)들에 존재하는 2 개의 기능을 연결하는 개념적인 링크를 참조 포인트라고 정의한다. 다음의 표 1은 도 1에 도시된 참조 포인트를 정리한 것이다. 표 1의 예시들 외에도 네트워크 구조에 따라 다양한 참조 포인트들이 존재할 수 있다.

Reference Point	Description
S1-MME	Reference point for the control plane protocol between E-UTRAN and MME.
S1-U	Reference point between E-UTRAN and Serving GW for the per bearer user plane tunneling and inter eNB path switching during handover.
S3	It enables user and bearer information exchange for inter 3GPP access network mobility in idle and/or active state. This reference point can be used intra-PLMN or inter-PLMN (e.g. in the case of Inter-PLMN HO).
S4	It provides related control and mobility support between GPRS Core and the 3GPP Anchor function of Serving GW. In addition, if Direct Tunnel is not established, it provides the user plane tunnelling.
S5	It provides user plane tunnelling and tunnel management between Serving GW and PDN GW. It is used for Serving GW relocation due to UE mobility and if the Serving GW needs to connect to a non-collocated PDN GW for the required PDN connectivity.
S11	Reference point between MME and Serving GW.
SGi	It is the reference point between the PDN GW and the packet data network. Packet data network may be an operator external public or private packet data network or an intra operator packet data network, e.g. for provision of IMS services. This reference point corresponds to Gi for 3GPP accesses.)

도 1에 도시된 참조 포인트 중에서 S2a 및 S2b는 비-3GPP 인터페이스에 해당한다. S2a는 신뢰되는 비-3GPP 접속 및 PDN GW 간의 관련 제어 및 이동성 지원을 사용자 평면에 제공하는 참조 포인트다. S2b는 ePDG 및 PDN GW 간의 관련 제어 및 이동성 지원을 사용자 평면에 제공하는 참조 포인트다.

도 2는 일반적인 E-UTRAN과 EPC의 아키텍처를 나타낸 예시이다.

도시된 바와 같이, eNB는 RRC(Radio Resource Control) 연결(connection)이 활성화되어 있는 동안 게이트웨이로의 라우팅, 페이징 메시지의 스케줄링 및 전송, 방송 채널(BCH)의 스케줄링 및 전송, 상향링크 및 하향링크에서의 자원을 UE에게 동적 할당, eNB의 측정을 위한 설정 및 제공, 무선 베어러 제어, 무선 허가 제어(radio admission control), 그리고 연결 이동성 제어 등을 위한 기능을 수행할 수 있다. EPC 내에서는 페이징 발생, LTE_IDLE 상태 관리, 사용자 평면의 암호화, SAE 베어러 제어, NAS 시그널링의 암호화 및 무결성 보호 기능을 수행할 수 있다.

도 3은 UE와 eNB 사이의 제어 평면에서의 무선 인터페이스 프로토콜(radio interface protocol)의 구조를 나타낸 예시도이고, 도 4는 UE와 eNB 사이의 사용자 평면에서의 무선 인터페이스 프로토콜의 구조를 나타낸 예시도이다.

상기 무선 인터페이스 프로토콜은 3GPP 무선 접속 네트워크 규격을 기반으로 한다. 상기 무선 인터페이스 프로토콜은 수평적으로 물리계층(physical layer), 데이터 링크 계층(data link layer) 및 네트워크 계층(network layer)으로 이루어지며, 수직적으로는 데이터정보 전송을 위한 사용자 평면(user plane)과 제어신호(signaling) 전달을 위한 제어 평면(control plane)으로 구분된다.

상기 프로토콜 계층들은 통신 시스템에서 널리 알려진 개방형 시스템간 상호접속(Open System Interconnection; OSI) 기준모델의 하위 3개 계층을 바탕으로 L1 (제1계층), L2 (제2계층), L3(제3계층)로 구분될 수 있다.

이하에서, 상기 도 3에 도시된 제어 평면의 무선프로토콜과, 도 4에 도시된 사용자 평면에서의 무선 프로토콜의 각 계층을 설명한다.

제1 계층인 물리계층은 물리채널(Physical Channel)을 이용하여 정보전송서비스(Information Transfer Service)를 제공한다. 상기 물리계층은 상위에 있는 매체접속제어(Medium Access Control) 계층과는 전송 채널(Transport Channel)을 통해 연결되어 있으며, 상기 전송 채널을 통해 매체접속제어계층과 물리계층 사이의 데이터가 전달된다. 그리고, 서로 다른 물리계층 사이, 즉 전송측과 수신측의 물리계층 사이는 물리채널을 통해 데이터가 전달된다.

물리 채널(physical channel)은 시간 축 상에 있는 여러 개의 서브프레임과 주파수축상에 있는 여러 개의 부반송파(subcarrier)로 구성된다. 여기서, 하나의 서브프레임(subframe)은 시간 축 상에 복수의 OFDM 심볼(symbol)들과 복수의 부반송파들로 구성된다. 하나의 서브프레임은 복수의 자원 블록(resource block)들로 구성되며, 하나의 자원블록은 복수의 OFDM 심볼(Symbol)들과 복수의 부반송파들로 구성된다. 데이터가 전송되는 단위시간인 TTI(Transmission Time Interval)는 1개의 서브프레임에 해당하는 1ms이다.

상기 전송 측과 수신 측의 물리계층에 존재하는 물리 채널들은 3GPP LTE에 따르면, 데이터 채널인 PDSCH(Physical Downlink Shared Channel)와 PUSCH(Physical Uplink Shared Channel) 및 제어채널인 PDCCH(Physical Downlink Control Channel), PCFICH(Physical Control Format Indicator Channel), PHICH(Physical Hybrid-ARQ Indicator Channel) 및 PUCCH(Physical Uplink Control Channel) 등으로 나눌 수 있다.

제2계층에는 여러 가지 계층이 존재한다. 먼저, 제2계층의 매체 접속 제어 (medium access control, MAC) 계층은 다양한 논리 채널(logical channel)을 다양한 전송채널에 매핑시키는 역할을 하며, 또한 여러 논리채널을 하나의 전송채널에 매핑시키는 논리 채널 다중화(multiplexing)의 역할을 수행한다. MAC 계층은 상위계층인 RLC 계층과는 논리 채널로 연결되어 있으며, 논리채널은 크게 전송되는 정보의 종류에 따라 제어 평면(control plane)의 정보를 전송하는 제어 채널(control channel)과 사용자 평면(user plane)의 정보를 전송하는 트래픽 채널(traffic channel)로 나뉜다.

제2 계층의 무선 링크 제어(radio link control, RLC) 계층은 상위계층으로부터 수신한 데이터를 분할 (Segmentation) 및 연결 (Concatenation)하여 하위계층이 무선 구간(radio interface)으로 데이터를 전송하기에 적합하도록 데이터 크기를 조절하는 역할을 수행한다.

제2 계층의 패킷 데이터 수렴 프로토콜(packet data convergence protocol, PDCP) 계층은 IPv4나 IPv6와 같은 IP 패킷 전송 시에 대역폭이 작은 무선 구간에서 효율적으로 전송하기 위하여 상대적으로 크기가 크고 불필요한 제어정보를 담고 있는 IP 패킷 헤더 사이즈를 줄여주는 헤더 압축(header compression) 기능을 수행한다. 또한, LTE 시스템에서는 PDCP 계층이 보안(security) 기능도 수행하는데, 이는 제 3자의 데이터 감청을 방지하는 암호화(ciphering)와 제 3자의 데이터 조작을 방지하는 무결성 보호 (integrity protection)로 구성된다.

제3 계층의 가장 상부에 위치한 무선 자원 제어(radio resource control, RRC) 계층은 제어평면에서만 정의되며, 무선 베어러(radio bearer, RB)들의 설정(Configuration), 재설정(Re-configuration) 및 해제(Release)와 관련되어 논리 채널, 전송 채널 및 물리 채널들의 제어를 담당한다. 이때, RB는 UE와 E-UTRAN간의 데이터 전달을 위해 제2계층에 의해 제공되는 서비스를 의미한다.

UE의 RRC와 무선 네트워크의 RRC 계층 사이에 RRC 연결(RRC connection)이 수립된(established) 경우 UE는 RRC 연결 모드(Connected Mode)에 있게 되고, 그렇지 못할 경우 RRC 휴지 모드(Idle Mode)에 있게 된다.

이하 UE의 RRC 상태 (RRC state)와 RRC 연결 방법에 대해 설명한다. RRC 상태란 UE의 RRC가 E-UTRAN의 RRC와 논리적 연결(logical connection)이 되어 있는가 아닌가를 말하며, 연결되어 있는 경우는 RRC_CONNECTED 상태(state), 연결되어 있지 않은 경우는 RRC_IDLE 상태라고 부른다. RRC_CONNECTED 상태의 UE는 RRC 연결이 존재하기 때문에 E-UTRAN은 해당 UE의 존재를 셀 단위에서 파악할 수 있으며, 따라서 UE를 효과적으로 제어할 수 있다. 반면에 RRC_IDLE 상태의 UE는 E-UTRAN이 UE의 존재를 파악할 수는 없으며, 셀 보다 더 큰 지역 단위인 TA(Tracking Area) 단위로 코어 네트워크가 관리한다. 즉, RRC_IDLE 상태의 UE는 셀에 비하여 큰 지역 단위로 해당 UE의 존재 여부만 파악되며, 음성이나 데이터와 같은 통상의 이동통신 서비스를 받기 위해서는 해당 UE가 RRC_CONNECTED 상태로 천이하여야 한다. 각 TA는 TAI(Tracking area identity)를 통해 구분된다. UE는 셀에서 방송(broadcasting)되는 정보인 TAC(Tracking area code)를 통해 TAI를 구성할 수 있다.

사용자가 UE의 전원을 맨 처음 켰을 때, UE는 먼저 적절한 셀을 탐색한 후 해당 셀에서 RRC 연결을 맺고, 코어 네트워크에 UE의 정보를 등록한다. 이 후, UE는 RRC_IDLE 상태에 머무른다. RRC_IDLE 상태에 머무르는 UE는 필요에 따라서 셀을 (재)선택하고, 시스템 정보(System information)나 페이징 정보를 살펴본다. 이를 셀에 캠프 온(Camp on)한다고 한다. RRC_IDLE 상태에 머물러 있던 UE는 RRC 연결을 맺을 필요가 있을 때 비로소 RRC 연결 과정 (RRC connection procedure)을 통해 E-UTRAN의 RRC와 RRC 연결을 맺고 RRC_CONNECTED 상태로 천이한다. RRC_IDLE 상태에 있던 UE가 RRC 연결을 맺을(establish) 필요가 있는 경우는 여러 가지가 있는데, 예를 들어 사용자의 통화 시도, 데이터 전송 시도 등이 필요하다거나, 아니면 E-UTRAN으로부터 페이징 메시지를 수신한 경우 이에 대한 응답 메시지 전송 등을 들 수 있다.

상기 RRC 계층 상위에 위치하는 NAS(Non-Access Stratum) 계층은 연결관리(Session Management)와 이동성 관리(Mobility Management)등의 기능을 수행한다.

아래는 도 3에 도시된 NAS 계층에 대하여 상세히 설명한다.

NAS 계층에 속하는 ESM (Evolved Session Management)은 디폴트 베어러(default bearer) 관리, 전용 베어러(dedicated bearer) 관리와 같은 기능을 수행하여, UE가 네트워크로부터 PS 서비스를 이용하기 위한 제어를 담당한다. 디폴트 베어러 자원은 특정 Packet Data Network(PDN)에 최초 접속 할 시에 네트워크에 접속될 때 네트워크로부터 할당 받는다는 특징을 가진다. 이때, 네트워크는 UE가 데이터 서비스를 사용할 수 있도록 UE가 사용 가능한 IP 주소를 할당하며, 또한 디폴트 베어러의 QoS를 할당해준다. LTE에서는 크게 데이터 전송/수신을 위한 특정 대역폭을 보장해주는 GBR(Guaranteed bit rate) QoS 특성을 가지는 베어러와 대역폭의 보장 없이 Best effort QoS 특성을 가지는 Non-GBR 베어러의 두 종류를 지원한다. 디폴트 베어러의 경우 Non-GBR 베어러를 할당 받는다. 전용 베어러의 경우에는 GBR 또는 Non-GBR의 QoS 특성을 가지는 베어러를 할당 받을 수 있다.

네트워크에서 UE에게 할당한 베어러를 EPS(evolved packet service) 베어러라고 부르며, EPS 베어러를 할당할 때 네트워크는 하나의 ID를 할당하게 된다. 이를 EPS 베어러 ID라고 부른다. 하나의 EPS 베어러는 MBR(maximum bit rate) 또는/그리고 GBR(guaranteed bit rate)의 QoS 특성을 가진다.

도 5는 사용자 평면 및 제어 평면을 위한 LTE 프로토콜 스택들을 예시한 것이다. 도 5(a)는 사용자 평면 프로토콜 스택들을 UE-eNB-SGW-PGW-PDN에 걸쳐 예시한 것이고, 도 5(b)는 제어 평면 프로토콜 스택들을 UE-eNB-MME-SGW-PGW에 걸쳐 예시한 것이다. 프로토콜 스택들의 키(key) 계층들의 기능(function)들을 간략하게 설명하면 다음과 같다.

도 5(a)를 참조하면, GTP-U 프로토콜은 S1-U/S5/X2 인터페이스 상으로(over) 사용자 IP 패킷들을 포워드하기 위해 사용된다. GTP 터널이 LTE 핸드오버동안 데이터 포워딩을 위해 수립되면 종단 마커 패킷(End Marker Packet)이 마지막 패킷으로서 상기 GTP 터널 상으로 전달(transfer)된다.

도 5(b)를 참조하면, S1AP 프로토콜은 S1-MME 인터페이스에 적용된다. S1AP 프로토콜은 S1 인터페이스 관리, E-RAB 관리, NAS 시그널링 전달 및 UE 컨텍스트 관리와 같은 기능을 지원한다. S1AP 프로토콜은 E-RAB(들)을 셋업하기 위해 초기 UE 컨텍스트를 eNB에게 전달하고, 그 후 상기 UE 컨텍스트의 수정 혹은 해제를 관리한다. S11/S5 인터페이스들에는 GTP-C 프로토콜이 적용된다. GTP-C 프로토콜은 GTP 터널(들)의 생성, 수정(modification) 및 종료(termination)를 위한 제어 정보의 교환(exchange)를 지원한다. GTP-C 프로토콜은 LTE 핸드오버의 경우에 데이터 포워딩 터널들을 생성한다.

도 3 및 도 4에서 예시된 프로토콜 스택들 및 인터페이스들에 대한 설명은 도 5의 동일 프로토콜 스택들 및 인터페이스들에도 그대로 적용될 수 있다.

도 6은 3GPP LTE에서 임의 접속 과정을 나타낸 흐름도이다.

임의 접속 과정은 UE가 기지국과 UL 동기를 얻거나 UL 무선자원을 할당 받기 위해 수행된다.

UE는 루트 인덱스(root index)와 PRACH(physical random access channel) 설정 인덱스(configuration index)를 eNB로부터 수신한다. 각 셀마다 ZC(Zadoff-Chu) 시퀀스에 의해 정의되는 64개의 후보(candidate) 임의 접속(random access, RA) 프리앰블이 있으며, 루트 인덱스는 UE가 64개의 후보 임의 접속 프리앰블을 생성하기 위한 논리적 인덱스이다.

임의 접속 프리앰블의 전송은 각 셀마다 특정 시간 및 주파수 자원에 한정된다. PRACH 설정 인덱스는 임의 접속 프리앰블의 전송이 가능한 특정 서브프레임과 프리앰블 포맷을 지시한다.

임의 접속 과정, 특히, 경쟁-기반 임의 접속 과정은 다음의 3 단계를 포함한다. 다음의 단계 1, 2, 3에서 전송되는 메시지는 각각 msg1, msg2, msg4로 지칭되기도 한다.

> 1. UE는 임의로 선택된 임의접속 프리앰블을 eNB로 전송한다. UE는 64개의 후보 임의 접속 프리앰블 중 하나를 선택한다. 그리고, PRACH 설정 인덱스에 의해 해당되는 서브프레임을 선택한다. UE는 은 선택된 임의 접속 프리앰블을 선택된 서브프레임에서 전송한다.

> 2. 상기 임의 접속 프리앰블을 수신한 eNB는 임의 접속 응답(random access response, RAR)을 UE로 보낸다. 임의 접속 응답은 2단계로 검출된다. 먼저 UE는 RA-RNTI(random access-RNTI)로 마스킹된 PDCCH를 검출한다. UE는 검출된 PDCCH에 의해 지시되는 PDSCH 상으로 MAC(Medium Access Control) PDU(Protocol Data Unit) 내의 임의 접속 응답을 수신한다. RAR은 UL 동기화를 위한 타이밍 오프셋 정보를 나타내는 타이밍 어드밴스(timing advance, TA) 정보, UL 자원 할당 정보(UL 그랜트 정보), 임시 UE 식별자(예, temporary cell-RNTI, TC-RNTI) 등을 포함한다.

> 3. UE는 RAR 내의 자원 할당 정보(즉, 스케줄링 정보) 및 TA 값에 따라 UL 전송을 수행할 수 있다. RAR에 대응하는 UL 전송에는 HARQ가 적용된다. 따라서, UE는 UL 전송을 수행한 후, 상기 UL 전송에 대응하는 수신 응답 정보(예, PHICH)를 수신할 수 있다.

도 7은 무선자원제어(RRC) 계층에서의 연결 과정을 나타낸다.

도 7에 도시된 바와 같이 RRC 연결 여부에 따라 RRC 상태가 나타나 있다. 상기 RRC 상태란 UE의 RRC 계층의 엔티티(entity)가 eNB의 RRC 계층의 엔티티와 논리적 연결(logical connection)이 되어 있는가 아닌가를 말하며, 연결되어 있는 경우는 RRC 연결 상태(connected state)라고 하고, 연결되어 있지 않은 상태를 RRC 휴지 상태(idle state)라고 부른다.

상기 연결 상태(Connected state)의 UE는 RRC 연결(connection)이 존재하기 때문에 E-UTRAN은 해당 UE의 존재를 셀 단위에서 파악할 수 있으며, 따라서 UE를 효과적으로 제어할 수 있다. 반면에 휴지 모드(idle state)의 UE는 eNB가 파악할 수는 없으며, 셀 보다 더 큰 지역 단위인 트래킹 지역(Tracking Area) 단위로 코어 네트워크가 관리한다. 상기 트래킹 지역(Tracking Area)은 셀들의 집합단위이다. 즉, 휴지 모드(idle state) UE는 큰 지역 단위로 존재여부만 파악되며, 음성이나 데이터와 같은 통상의 이동통신 서비스를 받기 위해서는 UE는 연결 상태(connected state)로 천이해야 한다.

사용자가 UE의 전원을 맨 처음 켰을 때, 상기 UE는 먼저 적절한 셀을 탐색한 후 해당 셀에서 휴지 모드(idle state)에 머무른다. 상기 휴지 모드(idle state)에 머물러 있던 UE는 RRC 연결을 맺을 필요가 있을 때 비로소 RRC 연결 과정(RRC connection procedure)을 통해 eNB의 RRC 계층과 RRC 연결을 맺고 RRC 연결 상태(connected state)로 천이한다.

상기 휴지 모드(Idle state)에 있던 UE가 RRC 연결을 맺을 필요가 있는 경우는 여러 가지가 있는데, 예를 들어 사용자의 통화 시도 또는 상향 데이터 전송 등이 필요하다거나, 아니면 EUTRAN으로부터 페이징 메시지를 수신한 경우 이에 대한 응답 메시지 전송 등을 들 수 있다.

휴지 모드(idle state)의 UE가 상기 eNB와 RRC 연결을 맺기 위해서는 상기한 바와 같이 RRC 연결 과정(RRC connection procedure)을 진행해야 한다. RRC 연결 과정은 크게, UE가 eNB로 RRC 연결 요청 (RRC connection request) 메시지 전송하는 과정, eNB가 UE로 RRC 연결 설정 (RRC connection setup) 메시지를 전송하는 과정, 그리고 UE가 eNB로 RRC 연결 설정 완료 (RRC connection setup complete) 메시지를 전송하는 과정을 포함한다. 이와 같은 과정에 대해서 도 7을 참조하여 보다 상세하게 설명하면 다음과 같다.

> 1. 휴지 모드(Idle state)의 UE는 통화 시도, 데이터 전송 시도, 또는 eNB의 페이징에 대한 응답 등의 이유로 RRC 연결을 맺고자 할 경우, 먼저 상기 UE는 RRC 연결 요청(RRC connection request) 메시지를 eNB로 전송한다.

> 2. 상기 UE로부터 RRC 연결 요청 메시지를 수신하면, 상기 eNB는 무선 자원이 충분한 경우에는 상기 UE의 RRC 연결 요청을 수락하고, 응답 메시지인 RRC 연결 설정(RRC connection setup) 메시지를 상기 UE로 전송한다.

> 3. 상기 UE가 상기 RRC 연결 설정 메시지를 수신하면, 상기 eNB로 RRC 연결 설정 완료(RRC connection setup complete) 메시지를 전송한다.

상기 UE가 RRC 연결 설정 메시지를 성공적으로 전송하면, 비로소 상기 UE는 eNB과 RRC 연결을 맺게 되고 RRC 연결 모드로 천이한다.

도 8은 V2X (vehicle to everything) 통신 환경을 나타내는 도면이다.

차량은 사고 발생시 인명 피해와 재산상의 피해가 크게 발생한다. 따라서, 차량의 운행시 차량에 탑승한 사람의 안전 뿐만 아니라 보행자의 안전을 확보할 수 있는 기술에 대한 요구가 커지고 있다. 이에, 차량에 특화된 하드웨어와 소프트웨어 기반의 기술이 차량에 접목되고 있다.

3GPP에서 시작된 LTE 기반 V2X(Vehicle-to-everything) 통신 기술도 IT(information technology)가 차량에 접목되는 추세를 반영하고 있다. 일부 차종을 중심으로 연결성 기능(connectivity function)이 적용되고 있으며, 통신 기능의 진화를 통해 차량간(Vehicle-to-Vehicle, V2V) 통신, 차량-인프라간(Vehicle-to-Infrastructure, V2I) 통신, 차량-보행자간 (Vehicle-to-Pedestrian, V2P) 통신, 차량-네트워크간 (Vehicle-to-Network, V2N) 통신을 지원하는 연구가 지속되고 있다.

V2X 통신에 의하면, 차량은 지속적으로 자신의 위치, 속도, 방향 등에 관한 정보를 브로드캐스팅한다. 브로드캐스팅된 정보를 수신한 주변의 차량은 자신 주변의 차량들의 움직임을 인지하여 사고 방지에 활용한다.

즉, 개인이 스마트폰 또는 스마트 시계 등의 형태를 갖는 단말을 소지하는 것과 유사하게, 각 차량도 특정 형태의 UE를 설치하게 된다. 이때, 차량에 설치되는 UE는 통신 네트워크에서 실제 통신 서비스를 제공받는 기기를 말하며, 예를 들어 차량에 설치되는 UE는 E-UTRAN 에서 eNB에 접속되어 통신 서비스를 제공받을 수 있다.

그러나, V2X 통신을 차량에 구현하는 과정에서는 여러 가지 고려되어야 할 사항이 있다. 이는, V2X 기지국 등의 교통안전 기반시설의 설치에 천문학적인 비용이 필요하기 때문이다. 즉, 차량이 움직일 수 있는 모든 도로에서 V2X 통신이 지원되기 위해서는 수십 만개 이상의 V2X 기지국 설치가 요구된다. 또한, 각 네트워크 노드는 안정적인 서버와의 통신을 위해 유선 네트워크를 기본으로 사용하여 인터넷 또는 중앙 제어 서버에 접속하기 때문에, 유선 네트워크 설치 유지 비용도 높다.

LTE 또는 EPS 시스템에서는 V2X를 효과적으로 지원하기 위해서 V2X 어플리케이션에서 생성한 데이터에 최적화된 QoS를 제공하고자 하고 있다.

V2X 어플리케이션은 ETSI(European Telecommunications standards Institute) ITS(Intelligent Transport Systems) 또는 SAE(System Architecture Evolution) 등에서 제정된다. 도 9는 ETSI ITS에서 제정하는 ITS 프로토콜 구조를 예시한 것이다.

도 9에서 ITS 상위 계층은 3GPP 계층(예, PDCP 등의 3GPP에서 정의한 프로토콜) 위에 존재하는 V2X/ITS 관련 모든 계층/프로토콜 통칭한다. ETSI ITS에서 정의한 아키텍쳐에 따르면, ITS 접속 기술(ITS Access Technologies) 계층 위의 모든 계층/프로토콜이 ITS 상위 계층에 해당한다.

3GPP는 통신 표준의 제정을 담당하고 있으며, 자동차의 동작이 전문분야가 아니므로, 3GPP는 ETSI ITS또는 SAE에서 정한 ITS 상위 계층을 그대로 지원하고, 다만 상기 어플리케이션에서 생성한 데이터를 최대한 효율적이고 안정적으로 전송하는 것을 목적으로 LTE 기반 V2X 기능을 제정한다.

그런데, 도 9를 보면, ITS 상위 계층에도 여러 가지 프로토콜 계층이 존재한다. 도 9를 참조하면, ITS 상위 계층, 즉, V2X 프로토콜 스택은 ITS 어플리케이션 계층, ITS 퍼실리티 계층, 기본 교통 프로토콜/그 외 계층, 지오네트워킹 계층을 포함한다. 또한 ETSI ITS 또는 SAE에서 V2X 관련 프로토콜 스택을 정의할 때는 LTE에 V2X 기능 지원이 없었다. 3GPP 계층의 입장에서는 ITS 상위 계층으로부터의 데이터는 ITS 상위 계층 내 서브 계층들 중 어떤 서브 계층에서 생성되는지 혹은 어떤 서브계층들을 거쳐 상기 3GPP 계층에 도달하는지에 관계없이 V2X 데이터, 즉, ITS 데이터로 인식된다. 다시 말해 현재까지의 표준에 의하면 3GPP 계층은 ITS 상위 계층 내 서브 계층들을 구분할 수 없으며, ITS 상위 계층 전체를 V2X 상위 계층, 즉, ITS 상위 계층으로 인식한다. 예를 들어, 3GPP 계층은 ITS 접속 기술 계층의 상위에서 내려오는 메시지들을 하나의 V2X 계층으로부터 내려오는 메시지들로 인식한다.

본 발명에서, ITS 상위 계층 내 서브 계층인 "ITS 어플리케이션" 계층/프로토콜을 지칭할 때를 제외하면, V2X와 ITS는 일반적으로 동등한 어휘로 사용된다. 예를 들어, ITS 상위 계층, ITS 어플리케이션, ITS 데이터, ITS 프로토콜은 각각 V2X 상위 계층, V2X 어플리케이션, V2X 데이터, V2X 프로토콜로 언급되기도 한다. 본 발명에서 V2X 어플리케이션은 ITS 어플리케이션과 일대일 대응관계를 의미하는 것은 아니며, ITS 어플리케이션 계층의 어플리케이션/프로토콜, ITS 퍼실리티 계층의 어플리케이션/프로토콜, 기본 교통 프로토콜/그 외 계층의 어플리케이션/프로토콜, 혹은 지오네트워킹 계층의 어플리케이션/프로토콜을 V2X 어플리케이션이 될 수 있다. 본 발명의 제안들에서 "ITS 어플리케이션 계층"이라고 명시되지 않은 "ITS 어플리케이션"이라는 표현은 V2X 어플리케이션과 동등한 의미로 사용된다. 따라서 V2X 어플리케이션은 ITS 어플리케이션 계층의 어플리케이션/프로토콜인 것으로 한정되는 것은 아니다.

따라서, 실제 ETSI ITS 또는 SAE의 V2X 상위 계층과 3GPP에서 지원하는 V2X 기능을 연동할 때, 구현에 따라서, 서로 다른 UE가 상호 연동을 제대로 할 수 없는 상황이 발생하는 문제점이 발생한다. 예를 들어, 한 구현에서는 ITS 퍼실리티(ITS Facilities) 계층에서 생성된 데이터가 3GPP 전송 기능에 제공되도록 구현될 수 있고, 또 다른 구현에서는 ITS 어플리케이션 계층에서 생성된 데이터가 3GPP 전송 기능에 제공되도록 구현될 수 있다. 이 경우, 3GPP 계층은 다른 구현으로부터 수신한 데이터를 다른 프로토콜 계층에서 처리하는 오류가 발생하여 원래 의도하고자 한 교통 안전의 목적을 달성할 수 없게 된다. 예를 들어, 3GPP는 차량 간의 V2X 통신(communication)을 지원하기 위해서, 크게 두 가지 모드를 정의한다.

- 첫 번째 V2X 모드는 직접(direct) 모드로서, 차량과 차량이 서로 직접 V2X 관련 정보를 주고 받는다. 첫 번째 V2X 모드에서는 예를 들어 PC5 인터페이스가 사용된다.

- 두 번째 V2X 모드는 간접(indirect) 모드로서, 차량과 차량이 서로 직접 V2X 관련 정보를 주고 받는 것이 아니라, 네트워크를 거쳐서 데이터를 주고 받는다. 예를 들어 한 차량은 우선 자신의 V2X 정보를 네트워크로 전송하고, 상기 네트워크가 다시 다른 차량에게 상기 차량으로부터 수신한 상기 V2X 정보를 전달한다. 두 번째 V2X 모드에서는 Uu 인터페이스가 사용된다.

현재 차량 제조사들은 3GPP 기반의 V2X 기능을 자신들의 차량에 구현하려고 하고 있다. 그런데, 차량 제조사들마다, 구현의 목적이 다를 수 있고, 또한 각 차량이 가입한 이동 통신 사업자에 따라서, 각 차량간의 통신을 지원하는 방식이 다를 수 있다. 예를 들어 다음의 두 경우를 생각할 수 있다.

자동차 제조사 A: 저가 자동차 생산을 위해서, 다양한 기능을 추가할 수 없어서, 첫 번째 V2X모드만 지원.

자동차 제조사 B: 서버를 이용한 다양한 V2X 어플리케이션을 지원하기 위해서, 첫 번째 모드 뿐만 아니라 두 번째 모드만 지원.

자동차 제조사 A의 경우에는, 단순 V2X 어플리케이션만 구비하게 되어, 서버와 통신하는 기능이 필요한 V2X 어플리케이션이 없을 수 있고, 이 경우 서버와 통신하는 데 필요한 IP 프로토콜을 구비할 필요는 없다. 또한 PC5에서 데이터 전송 효율을 높이기 위해서, 비-IP 형태의 V2X 데이터를 3GPP 계층으로 전송하기로 결정할 수 있다.

자동차 제조사 B의 경우에는, 서버와 통신하는 상황이 있다고 가정하면, 서버와의 통신을 위해서 IP 프로토콜을 구현해야 한다. 이 때, 첫 번째 V2X 모드와 두 번째 V2X 모드 중에서 어느 것을 사용하는 가에 따라서 IP 프로토콜의 사용/미사용이 달라질 경우, IP 프로토콜 사용과 비사용 간 스위칭을 수행하는 시간 동안 발생하는 끊김(interruption) 과정에서의 데이터 손실(loss) 발생을 우려가 있으므로, 자동차 제조사 B는 항상 IP 프로토콜을 V2X 데이터에 적용하기로 결정한다.

상기 두 자동차 제조사는 각각 최선의 선택을 하였다. 그럼에도 안전을 위해서는 상기 두 자동차 사이에는 통신이 지원되어야 한다. 그런데, 각기 수신한 PDCP PDU에 포함된 데이터 포맷에 대한 정보, 예를 들어, IP를 적용했는지 아닌지에 대한 정보가 없으면, 수신된 PDU를 올바르게 복호(decode)하지 못하는 문제점이 발생하게 된다.

도 10은 3GPP 기반 V2X 시스템에서 구현되는 네트워크 구조를 예시한 것이다.

도 10을 참조하면, V2X 어플리케이션에서 생성한 데이터가 V2X 어플리케이션 서버로 전달될 때, E-UTRAN을 거치게 되는데, 상기 E-UTRAN에 해당하는 eNB는 UE로부터 수신한 데이터가 IP 정보를 포함하고 있는지 아닌지, 또는 어떤 ITS 프로토콜 계층에서 최종적으로 생성된 데이터인지에 대해서 정확하게 판단하지 못하면, 임의로 ITS 상위 계층의 프로토콜 포맷을 적용하게 된다. 따라서, V2X 제어 기능(Control Function)이나 V2X 어플리케이션 서버(Application Server)에 전달되어야 할 메시지들이 삭제되거나, 혹은 복호 에러가 발생되어 처리되지 못하는 문제점이 발생할 수 있다.

V2X 어플리케이션들에는 여러 종류가 있으며, 각각의 V2X 어플리케이션은 또 다른 여러 타입의 메시지들을 이용할 수 있다. 서로 비슷한 특성을 가진 메시지들이 묶여서 하나의 메시지 세트를 이루게 되며, 이러한 메시지 세트들의 예로, BSM(Basic Safety Message) 또는 CAM(Co-operative Awareness message) 또는 DENM(Decentralized Environmental Notification Message) 등이 있다.

IEEE 1609.12은 각각의 V2X 어플리케이션들에 대해서 ID를 할당하고 있다("IEEE Standards Association Registration Authority" 웹사이트에서 1609 PSID 페이지 참조). 표 2는 IEEE 1602.12에 따른 PSID 할당(allocation)들 중 일부를 나타낸 것이다.

PSID values (hex)	P-encoded PSID values (hex)	Application area	Organization/ Documentation	Number of values (decimal)
0x00	0p00	system	ISO 15628^a	1
...	...	...	...	...
0x20	0p20	vehicle to vehicle safety and awareness	SAE J2735	1
0x21	0p21	tracked vehicle safety an awareness	SAE J2735	1
...	...	...	...	...
0x82	0p80-02	intersection safety and awareness	SAE J2735	1
0x83	0p80-03	traveller information and roadside signage	SAE J2735	1
0x84	0p80-04	mobile probe exchanges	SAE J2735	1
0x85	0p80-05	emergency and erratic vehicles present in roadway	SAE J2735	1
...	...	...	...	...
0x40-80	0pC0-00-00	Cooperative Awareness Message (CAM) processor (deprecated)	ETSI	1
0x40-81	0pC0-00-01	Decentralized Environmental Notification Message (DENM) processor (deprecated)	ETSI	1
...	...	...	...	...

각각의 사용 예(use case) 또는 어플리케이션이 어떤 상황을 발견하게 되면, 각각의 판매사(vendor)들은 자신들이 적절하다고 생각하는 메시지 세트를 이용하여 해당 상황에 따른 메시지를 전송하게 될 것이다.

ETSI에서는 ITS 관련 다양한 사용 예 및 V2X 메시지들을 정의하고 있다. 예를 들어, ETSI ITS는 CAM 타입의 메시지들과 DENM 타입의 메시지들과 각각 사용 예들을 정의하고 있다. 예를 들어, ETSI ITS CAM 타입의 메시지들은 "Vehicle type warnings", "Dynamic vehicle warnings", "Collision Risk Warning" 및 "Others"의 카테고리에 해당되는 사용 예들에서 사용될 수 있다. "Vehicle type warnings" 카테고리의 사용 예에는 "Emergency Vehicle Warning", "Slow Vehicle Indication", "Motorcycle Approaching Indication" 및 "Vulnerable road user Warning" 등이 있으며, "Dynamic vehicle warnings" 카테고리의 사용 예에는 "Overtaking vehicle warning", "Lane change assistance" 및 "Co-operative glare reduction" 등이 있으며, "Collision Risk Warning" 카테고리의 사용 예에는 "Across traffic turn collision risk warning", "Merging Traffic Turn Collision Risk Warning", "Co-operative merging assistance", "Intersection Collision Warning", "Traffic light optimal speed advisory", "Traffic information and recommended itinerary", "Enhanced route guidance and navigation(RSU Capability)", "Intersection management", "Co-operative flexible lane change", ""Limited access warning, detour notification" 등이 있으며, "Others" 카테고리의 사용 예에는 "Point of interest notification", "Automatic access control/parking access", "Local electronic commerce", "Car rental/sharing assignment/reporting", "Media downloading", "Map download and update" 등이 있다. 한편, DENM 타입의 메시지들은 "Vehicle status warnings"과 "Traffic hazard warnings"의 사용 예 카테고리들에서 사용될 수 있다. "Vehicle status warnings" 카테고리의 사용 예에는 "Emergency electronic brake lights"와 "Safety function out of normal condition warning"이 있으며, "Traffic hazard warnings" 카테고리의 사용 예에는 "Wrong way driving warning", "Stationary vehicle warning", "Signal violation warning", "Roadwork warning" 및 "Collision Risk Warning from RSU" 등이 있다. 자세한 사항은 ETSI TS 302 637-2, ETSI TS 302 637-3, ETS TR 102 638 참조한다.

V2X 메시지는 도로 안전(road safety) 관점에서 메시지가 유효한 지역(범위)에 있는 모든 UE가 수신해야 한다. 이에 따라 V2X 메시지의 전송에는 MBMS(Multimedia Broadcast Multicast Services), SC-PTM(Single-cell Point-to-Multipoint)과 같은 브로드캐스트 방식의 전송이 사용될 수 있다.

V2X 어플리케이션들을 지원하기 위한 가장 기본(basic) 메시지 즉, 교통 안전에 있어서 가장 우선적으로 구현될 메시지로 CAM/DENM/BSM(Basic Safety Message) 등이 있다. 특히 CAM/DENM 메시지는 ETSI ITS에서 정의하는 프로토콜에서 퍼실리티 계층에 해당되는 메시지로서, 퍼실리티 계층의 하위 계층으로는 추가적으로 지오네트워킹(Geonetworking) 계층 및 ITS G5 등이 있다. ETSI에서는 ITS 표준화 그룹을 통해서, 오래 전부터 차량 통신 간 프로토콜을 제정해 오고 있다. ETSI ITS는 각각의 어플리케이션 및 하위 계층, 실제 물리 계층까지 정의했다. ITS 어플리케이션 계층의 데이터가 혹은 ITS 퍼실리티 계층의 데이터가 BTS(Basic Transport Protocol)과 지오네트워킹을 거치면 IP 헤더가 있는 IP 타입의 데이터가 ITS 접속 기술 계층에 전달되고, BTS와 지오네트워킹을 거치지 않으면 IP 헤더가 없는 비-IP 타입의 데이터가 ITS 접속 기술 계층에 전달된다. ETSI ITS에 의하면 CAM/DENM 메시지는 BTS와 지오네트워킹을 거치지 않고 ITS 접속 기술 계층에 전달된다. 즉, ETSI ITS에 의하면 BTP(Basic Transport Protocol) 계층 및 지오네트워킹 계층은 CAM/DENM의 수송에 사용되고, IP/UDP/TCP는 CAM/DENM의 수송에 사용되지 않는다.

2015년부터 시작된 V2X 관련 LTE 표준화에서는, 3GPP가 통신 전문가로 이루어져있고, 교통 안전 전문가들이 아니므로, ITS 상위 계층의 여러 프로토콜 중에서, ITS 상위 계층, 즉, ITS 접속 기술 계층 위에 존재하는 계층들에 관련해서는 별도로 표준을 정하지 않고, 상기 ITS 상위 계층을 최적으로 지원하는 통신 시스템의 표준만 정하기로 하였다. 따라서 3GPP는 예를 들어, CAM/DENM 등의 메시지들을 최적으로 전송하는 통신 시스템을 개발하고 있다. 그런데, 3GPP에서 개발 중인 LTE V2X 프로토콜은, EPS를 기반으로 하고 있으며, EPS는 IP 데이터를 주고 받는 시스템이다. 따라서, 네트워크를 통해서 데이터가 전달되는, V2X 모드에서는, EPS는 비-IP 데이터를 지원할 수 없다. 그런데, ETSI ITS에서 정의된 CAM/DENM 기반의 V2X 프로토콜에 의하면, CAM/DENM 메시지가 ITS 접속 기술(ITS access technology) 계층에 전달될 때에는 IP 헤더가 없는 비-IP 데이터의 형태로 전달된다. 따라서, 현재 LTE 기반의 통신 시스템에서, 예를 들어 네트워크를 경유하는 간접 차량 간 통신의 CAM/DENM 메시지가 비-IP 형태를 취하는 경우, 상기 CAM/DENM 메시지가 차량 간에 제대로 전달될 수 없는 상황이므로, ETSI ITS에서 제정된 ITS 상위 계층을 제대로 지원하지 못한다는 문제가 발생한다. 이러한 문제점을 해결하기 위해 다음과 같은 옵션을 고려해 볼 수 있다.

- 옵션 1: ITS 어플리케이션 계층의 메시지가 3GPP 전송으로 직접 푸쉬(push)된다. 즉, CAM, DENM, BSM 메시지가 ITS 어플리케이션 계층과 3GPP 시스템 간에 직접 교환된다. 이 경우, ITS 어플리케이션 계층에서 생성된 메시지는 ITS 퍼실리티 계층/프로토콜 및/또는 지오네트워킹 계층/프로토콜을 건너뛰고, 3GPP 계층, 예를 들어, 3GPP의 PDCP 계층으로 직접 전달된다.

- 옵션 2: ITS 어플리케이션, 즉, V2X 어플리케이션의 메시지를 3GPP에서 기대하는 메시지 타입과 일치시킨다. 예를 들어, ITS 안전 메시지는 ITS 상위 계층에서 3GPP 계층으로 전달되기 전에 IP/TCP/UDP 프로토콜로 캡슐화된다.

그러나 이러한 옵션들도 여전히 또 다른 문제를 야기한다. 예를 들어, 통신 모듈을 장착하여 인터넷에 접속할 수 있는 차량이 향후에 증가할 것인데, 인터넷에 접속된 차량은 웹브라우징, 음악 스트리밍 서비스를 사용할 것이다. 즉, 상기 인터넷에 접속된 차량이 IP에 기반한 통신을 해야 한다는 것을 의미한다. 또한, 또 다른 V2X 서비스의 예로, 네비게이션(navigation)을 들 수 있는데, 네비게이션도 IP를 기반으로 한다. 따라서, 옵션 1을 사용될 경우, 인터넷 기반 서비스를 제공받지 못하는 문제가 발생한다. 옵션 2가 사용될 경우, CAM/DENM 메시지 전송에 매번 IP 헤더가 붙어야 하고, 그에 따라서 IP 헤더를 기반으로 무선 전송이 이루어지면, 지속적으로 무선 자원이 추가적으로 소요되는 문제점이 발생한다.

한편, 도 11은 ProSe 통신에서 사용되는 사용자 평면 프로토콜 스택을 예시한 것이다(3GPP TS 23.303 참조). PC5를 사용하년 V2V/P 시비스들을 위한 V2X 메시지 전송/수신을 위한 원-to-올(one-to-all) ProSe 직접 통신의 경우, PC5-U가 사용될 수 있다. PC5-U는 PC5 인터페이스를 통한 비-IP 타입 V2X 메시지들의 전송/수신에 사용될 수 있을 것으로 예상된다. 즉, ProSe는 UE와 UE 간의 직접 통신을 이용하고, 네트워크 노드를 거치지 않으므로, UE와 UE 사이에 직접 통신을 할 때에는 IP를 쓰지 않도록 설정될 수도 있다. 그러나, 만약 통신 네트워크의 혼잡으로, V2X 메시지가 UE와 UE 사이의 직접 통신이 아닌, 네트워크 노드로 전송되어야 할 경우에는 다시 IP를 사용해야만 통신이 가능하다. 따라서 옵션 1과 옵션 2 중 하나로 ITS 어플리케이션을 제약하는 것은 LTE 기반 V2X 통신을 위한 적절한 해결 방법이라고 하기 어렵다.

따라서 본 발명은 ITS 상위 계층에서 3GPP 스택으로 데이터의 전송을 요청할 때 3GPP 스택/계층이 상기 데이터가 IP 데이터인지 아니면 비-IP 데이터인지 모르는 문제를 해결하기 위한 방안을 제안한다. 구체적으로 본 발명은 이동 통신 시스템에서 ITS 상위 계층의 데이터를 효과적으로 처리하여 다양한 V2X를 위해서 정의된 다양한 프로토콜을 지원하는 방법을 제안한다. 아울러 차량 간 통신을 지원하는 이동 통신 시스템에서 IP 타입 데이터와 비-IP 타입 데이터를 효율적으로 지원하는 방법을 제안한다.

또한 본 발명은 3GPP 스택/계층으로 하여금 ITS/V2X 상위 계층에서 생성된 데이터의 타입에 따라 다른 처리를 할 수 있도록 하는 방안을 제안한다.

본 발명의 제안 1-1과 제안 1-2는 3GPP 계층이 전달을 요청받은 V2X 데이터가 IP 데이터인지 아니면 비-IP 데이터인지 모르는 문제를 해결하기 위한 방안들이다. 본 발명의 제안 2는 3GPP 계층이 전달을 요청받은 V2X 데이터의 타입을 구별(discriminate)할 수 있도록 하는 방안이다. 본 발명의 제안 2는 제안 1-1 또는 제안 1-2와 함께 적용될 수 있다.

<제안 1-1: ITS 상위 계층이 3GPP 계층에 ITS/V2X 데이터가 IP인지 아니면 비-IP인지를 지시>

본 발명의 제안 1-1은 ITS 상위 계층 또는 V2X 상위 계층에서 3GPP 스택으로 데이터 전송을 요청할 때, 각각의 데이터에 대해서 어떤 프로토콜 계층에 해당하는 데이터가 포함되어 있는지 알려줄 것을 제안한다. 이를 바탕으로, 본 발명의 제안 1-1은 3GPP 스택의 상위 계층의 엔티티는 3GPP 무선(radio)을 통해서 상기 데이터를 포함하는 데이터 유닛을 전송할 때, 그 데이터 유닛에 상기 데이터 유닛의 데이터가 어떤 프로토콜 엔티티에 해당하는 데이터인지의 정보를 포함할 것을 제안한다. 본 발명의 제안 1-1에 따른 예시를 설명하면 다음과 같다.

전송 측 ITS 상위 계층에서 생성한 데이터가 PDCP 엔티티에 전달된다. 상기 ITS 상위 계층은 상기 PDCP 엔티티에게 상기 데이터가 어떤 프로토콜에서 생성된 데이터인지의 정보를 전달할 수 있다. 상기 ITS 상위 계층은 상기 PDCP 엔티티에게 상기 데이터가 어떤 프로토콜에 해당하는 데이터 유닛인지에 관한 정보를 전달할 수 있다. 예를 들어, 상기 정보는 상기 데이터가 BTP 프로토콜 데이터인지, 지오네트워킹 프로토콜 데이터인지, CAM 프로토콜 데이터인지, DENM 프로토콜 데이터인지, 아니면 그 외 ITS의 어떤 프로토콜 데이터인지의 정보를 나타낸다. 다른 예로, 상기 정보는 상기 데이터가 BTP 프로토콜에서 생성된 것인지, 지오네트워킹 프로토콜에서 생성된 것인지, CAM 프로토콜에서 생성된 것인지, DENM 프로토콜에서 생성된 것인지, 아니면 그 외 ITS의 어떤 프로토콜에서 생성된 것인지에 관한 내용을 나타낸다. 특히, 상기 ITS 상위 계층은 상기 PDCP 엔티티에게 상기 데이터가 IP 프로토콜 데이터인지 아닌지의 여부를 알려줄 수 있다. 또는 IP 프로토콜에서 생성한 것인지의 정보를 전달할 수 있다. 상기 정보는 데이터가 PDCP 엔티티에 전달될 때마다 상기 PDCP 데이터에 제공될 수 있고, 아니면 반고정적으로 미리 설정될 수도 있다.

전송 측 PDCP 엔티티는 상기 ITS 상위 계층이 자신에게 전달한 데이터를 이용하여 PDCP 프로토콜 데이터 유닛(protocol data unit, PDU)를 구성하고, 상기 PDCP PDU를 하위 계층에게 전달한다. PDCP PDU들은 PDCP 제어 PDU와 PDCP 데이터 PDU로 구분된다. PDCP 제어 PDU는 PDCP 서비스 데이터 유닛(service data unit, SDU)들이 분실됨(missing) 및 PDCP 재-수립을 따르지(following) 않음을 나타내는 PDCP 상태(status) 보고 또는 헤더 압축 제어 정보(예, interspersed ROHC 피드백) 등을 나르는(convey) 데 사용된다. PDCP 데이터 PDU는 다음을 나르는 데 사용된다: PDCP SDU 시퀀스 번호(sequence number, SN); 및 일대다(one-to-many) 통신에 사용되는 사이드링크 무선 베어러(sidelink radio bearer, SLRB)들의 경우, PGK(ProSe Group Key) 인덱스, PTK(ProSe Traffic Key) 인덱스 및 SDU 타입; 또는 일대일(one-to-one) 통신에 사용되는 SLRB들의 경우, K_D-sess식별자 및 SDU 타입; 및 압축되지 않은(uncompressed) PDCP SDU를 담은 사용자 평면 데이터; 또는 압축된 PDCP SDU를 담은 사용자 평면 데이터, 제어 평면 데이터; 및 SRB(Signaling Radio Bearer)들을 위한 MAC-I 필드; 또는 일대다 통신을 위한 무결성 보호를 필요로 하는 SLRB의 경우, MAC-I 필드; 또는 릴레이 노드(relay node, RN)의 경우, (무결성 보호가 설정되면) DRB(Data Radio Bearer)를 위한 MAC-I 필드.

본 발명에 따라 PDCP 엔티티가 생성하여 하위 계층에게 전달하는 PDCP PDU는 다음과 같은 정보를 포함할 수 있다:

- PDCP PDU 데이터 타입 지시자; 또는

- ITS 데이터 타입 지시자.

상기 지시자는 PDCP PDU에 포함된 데이터가 어떤 프로토콜에서 생성되었는지, 혹은 어떤 성격의 데이터인지를 나타낼 수 있다. 예를 들어, 상기 지시자는 해당 데이터가 BTP 프로토콜 데이터인지, 지오네트워킹 프로토콜 데이터인지, CAM 프로토콜 데이터인지, DENM 프로토콜 데이터인지, 아니면 그 외 ITS의 어떤 프로토콜 데이터인지의 정보를 나타낸다. 다른 예로, 상기 지시자는 해당 데이터가 BTP 프로토콜에서 생성된 것인지, 지오네트워킹 프로토콜에서 생성된 것인지, CAM 프로토콜에서 생성된 것인지, DENM 프로토콜에서 생성된 것인지, 아니면 그 외 ITS의 어떤 프로토콜에서 생성된 것인지에 관한 내용을 나타낸다.

ITS 상위 계층은 PDCP 엔티티에게 해당 데이터가 IP프로토콜 데이터인지 아닌지의 여부를 알려줄 수 있고, 상기 PDCP 엔티티는 이를 바탕으로 PDCP PDU 혹은 ITS 데이터 타입 지시자를 적절하게 세팅하여 PDCP PDU에 포함시킬 수 있다.

본 발명에 따른 수신 측 PDCP 엔티티는 하위 계층으로부터 전달 받은 PDCP PDU를 다음과 같이 핸들링할 수 있다. 상기 PDCP 엔티티는 수신한 PDCP PDU의 헤더를 검사하여 어떤 프로토콜 데이터가 포함되었는지 혹은 어떤 프로토콜에서 생성한 데이터인지 판별할 수 있다. 상기 판별 과정은 PDCP PDU 헤더에 포함된 다음의 정보를 이용할 수 있다:

- PDCP PDU 데이터 타입 지시자; 또는

- ITS 데이터 타입 지시자.

상기 지시자는 PDCP PDU에 포함된 데이터가 ITS 상위 계층의 어떤 프로토콜에서 생성되었는지, 혹은 어떤 성격의 데이터인지를 나타낼 수 있다. 예를 들어, 상기 지시자는 해당 데이터가 BTP 프로토콜 데이터인지, 지오네트워킹 프로토콜 데이터인지, CAM 프로토콜 데이터인지, DENM 프로토콜 데이터인지, 아니면 그 외 ITS의 어떤 프로토콜 데이터인지의 정보를 나타낸다. 다른 예로, 상기 지시자는 해당 데이터가 BTP 프로토콜에서 생성된 것인지, 지오네트워킹 프로토콜에서 생성된 것인지, CAM 프로토콜에서 생성된 것인지, DENM 프로토콜에서 생성된 것인지, 아니면 그 외 ITS의 어떤 프로토콜에서 생성된 것인지에 관한 내용을 나타낸다.

송신 측의 경우, ITS 상위 계층은 PDCP 엔티티에게 해당 데이터가 IP프로토콜 데이터인지 아닌지의 여부를 알려준다.

수신 측 PDCP 엔티티는 PDCP PDU에 포함된 데이터를 상위 ITS 상위 계층에 전달할 때, 상기 데이터와 함께 상기 데이터가 어떤 프로토콜의 데이터인지 혹은 어떤 프로토콜에서 처리해야 하는지의 정보를 같이 전달할 수 있다.

수신 측 ITS 상위 계층에서는 PDCP 엔티티로부터 데이터를 전달 받으면 다음과 같이 처리할 수 있다. 수신 측 ITS 상위 계층에서는 PDCP로부터 데이터와 함께 전달받은 정보, 즉, 해당 데이터가 어떤 프로토콜의 데이터인지 혹은 어떤 프로토콜과 관련되어 있는지의 정보를 확인하고, 그에 따라 해당되는 프로토콜의 표준에 맞게 해당 데이터를 처리하거나 또는 해당 프로토콜에 데이터를 전달한다. 예를 들어, IP 프로토콜 데이터라고 지시하면 IP 프로토콜로 전달한다. IP 프로토콜 데이터가 아니라고 지시하면, IP 헤더가 없는 것으로 간주하고 해당 데이터를 처리한다. 예를 들어, CAM 프로토콜이라고 지시하면, 해당 데이터를 CAM 프로토콜 엔티티로 전달한다.

각 엔티티는 자신이 어떤 데이터를 어떻게 처리할 것인지 미리 설정될 수 있다. 예를 들어, 시스템은 어떤 PDCP 엔티티에 대해서, 상기 PDCP 엔티티가 BTP 프로토콜에서 생성된 데이터만을 처리하도록 지시할 수 있다. 이 경우, 상기 PDCP 엔티티는 자신이 전송해야 하거나 수신한 데이터에 대해서, 상기 데이터가 BTP 프로토콜 데이터인 경우에만, 하위 엔티티로 전송을 요청하거나 혹은 상위 엔티티로 전달한다. 이 경우, 상기 PDCP 엔티티는 자신이 전송해야 하거나 수신한 데이터에 대해서, 상기 데이터가 BTP 프로토콜 데이터가 아니면, 하위 엔티티로 전송을 요청하지도 않고, 상위 엔티티로 전달하지도 않는다. 그리고 상기 데이터를 삭제한다.

<제안 1-2: 네트워크가 IP 헤더의 부착 여부를 지시>

본 발명의 제안 1-2는, V2X 메시지들을 전송/수신함에 있어서, LTE 기반 통신 프로토콜에서 어떤 V2X 메시지들에 대해서 IP 헤더가 필요한지 아닌지의 여부를 알려주고, V2X 상위 계층에서는 그에 따라서 IP 헤더를 V2X 메시지에 붙이는 동작을 수행하거나 수행하지 않을 것을 제안한다.

제안 1-1은 ITS 데이터, 즉, V2X 데이터에 IP 헤더의 부착 여부가 ITS 상위 계층의 구현 문제로 둔다. 즉, 제안 1-1은 ITS 데이터가 IP 타입일 수도 있고 비-IP 타입일 수도 있음을 전제로, 3GPP 계층, 즉, 통신 시스템에서 IP 타입의 ITS 데이터와 비-IP 타입의 ITS 데이터를 구별할 수 있는 방안이다. 이에 반해 제안 1-2는 네트워크가 ITS 데이터에 IP 헤더를 부착할 것인지 여부를 UE에게 지시한다.

다음은 본 발명의 제안 1-2에 따라서, CAM/DENM 관련 어플리케이션만 사용하는 어떤 UE에 대해서, PC5 인터페이스를 이용해서 V2X 메시지를 전송/수신하던 UE가, Uu 인터페이스를 통해서 V2X 메시지를 전송/수신하는 과정으로 변경되는 과정을 설명한다. 예를 들어, PC5 인터페이스 통신으로 IP 헤더 없이 CAM/DENM 타입의 메시지를 생성하던 UE가, Uu 인터페이스를 사용하게 되면서 IP 헤더를 CAM/DENM 타입의 메시지와 함께 전송할 수 있다.

도 12는 V2X 통신에 사용 가능한 프로토콜 스택을 예시한 것이다. 도 12에서 안전 메시지로는 예를 들어 충돌 방지용 메시지가 있을 수 있으며, 비-안전 메시지로는 지도 다운로드 등 충돌 방지와 관계없는 메시지가 있을 수 있다.

UE는 도 12의 프로토콜 스택을 유지하면서, PC5를 통한 V2X 메시지 전송을 하고 있을 수 있다. 이후 네트워크는 상기 UE에게 PC5를 통한 메시지 전송을 중지하고 Uu를 통한 V2X 메시지 전송을 지시할 수 있다. 예를 들어, 각 eNB는 셀에서 V2X 제어 정보를 포함하는 시스템 정보의 변경을 알릴 수 있다. 셀 상에서 전송되는 시스템 정보의 변경에 관한 자세한 사항은 3GPP TS 36.331의 섹션 5.2를 참조한다. 변경된 시스템 정보를 통해서 UE는 새로운 V2X 관련 시스템 정보를 수신할 수 있다. 상기 V2X 관련 시스템 정보는 UE가 V2X 어플리케이션을 사용하기 위해 PC5(사이드링크) 인터페이스를 사용해야 하는지 아니면 Uu 인터페이스를 사용해야 하는지를 나타내는 V2X 연결(connection) 모드 정보를 포함할 수 있다.

상기 V2X 연결 모드 정보가 Uu를 사용하라고 지시할 경우, UE가 아직 eNB과 RRC 연결(connection)을 수립하지 않은 경우, 상기 UE는 RRC 연결 상기 eNB와 수립하는 RRC 연결 수립 과정을 수행한다. 상기 RRC 연결 수립 과정에서, 서비스 요청 과정(3GPP TS 23.401의 섹션 5.3.4 참조) 수행된다. 서비스 요청 과정에서, 상기 UE는 서비스 요청 메시지 내에 자신이 현재 어떤 V2X 어플리케이션을 사용하고 있는지에 대한 정보를 전달할 수 있다.

예를 들어, UE 트리거(triggered) 서비스 요청 과정에서 UE는 eNB로의 RRC 메시지에 캡슐화된(encapsulated) 이동성 관리 엔티티(mobility management entity, MME)를 향한(toward) NAS 메시지인 서비스 요청 메시지를 에게 보낸다. 본 발명에 따라 상기 서비스 요청 메시지는 해당 UE가 V2X 어플레키이션을 사용 중인지 여부, 사용 중이면 상기 UE에 의해 사용되는 V2X 어플리케이션들을 포함할 수 있다.

상기 서비스 요청을 수신한 MME는 (서빙 GW 어드레스, S1-TEID(들) (UL), EPS 베어러 QoS(들), 보안 컨텍스트, MME 시그널링 연결(connection) ID, 핸드오버 제약(restriction) 리스트, CSG 멤버쉽 지시(indication)을 포함하는) S1-AP 초기 컨텍스트 셋업 요청 메시지를 상기 eNB에게 보낸다. 이 단계는 모든 활성(active) EPS 베어로들을 위한 무선(radio) 및 S1 베어러들을 활성화(activate)한다. 상기 eNB는 보안 컨텍스트, MME 시그널링 연결 ID, EPS 베어러 QoS(들) 및 S1-TEID(들)을 UE RAN 컨텍스트에 저장한다. 이 때 네트워크 노드(예, MME 및/또는 eNB)는 상기 UE에게 다음의 설정 정보를 제공할 수 있다:

- 어떤 V2X 어플리케이션이 상기 UE에 의해 사용되는 것이 허용되는지;

- 각 허용된 V2X 어플리케이션에 대해, 어떤 EPS 베어러 혹은 무선 베어러가 해당 V2X 어플리케이션을 위한 데이터의 전달에 사용되는지;

- 각 허용된 V2X 어플리케이션에 대해, ITS 상위 계층이 IP 헤더를 해당 V2X 어플리케이션을 위한 메시지들에 부가(add)하는지 (혹은 IP 프로토콜이 해당 V2X 어플리케이션을 위한 메시지들에 사용되는지;

- 각 허용된 V2X 어플리케이션에 대해, ITS 상위 계층에서 생성된 메시지들을 수신하는 PDCP 계층이 상기 수신된 메시지들에 IP 헤더를 부가하는지; 또는

- 각 DRB 혹은 EPS 베어러에 대해, IP 헤더/프로토콜이 사용되는지 여부.

상기 설정 정보가 수신되면, 상기 UE는 상기 설정 정보를 해당 설정 정보가 의도한 대로 적용한다.

상기 설정 정보는 EPS 베어러를 설정하는 과정에서 전달될 수 있다. GTP 기반(based) S5/S8을 위한 PDN GW, 즉, P-GW 개시(initiated) 베어러 수정(modification) 과정이 도시된, 3GPP TS 23.401의 섹션 5.4.2의 "Figure 5.4.2.1-1"을 참조하면, P-GW 개시 베어러 수정 과정이 사용되기 전에, 단계 0에서 UE가 요청 베어러 자원 수정(Request Bearer Resource Modification)(3GPP TS 23.401의 섹션 5.4.5 참조)과 같은 UE 정보 과정 혹은 다른 과정을 이용하여 활성(active) V2X 어플리케이션의 리스트를 네트워크(예, MME)에 알릴 수 있다. 상기 UE의 베어러 자원 수정의 요청이 승낙(accept)되면, P-GW 개시 베어러 수정 과정이 작동(invoke)된다. P-GW 개시 베어러 수정 과정은 EPS QoS 파라미터들 QCI(QoS Class Identifier), GBR(Guaranteed Bit Rate), MBR(Maximum Bit Rate) 또는 ARP(Allocation and Retention Priority) 중 하나 이상이 수정되는 경우들에 혹은 APN-AMBR (per APN Aggregated Maximum Bit Rate)을 수정하기 위해 사용된다. 여기서 QCI는 베어러 레벨 패킷 포워딩 처리(treatment)(예, 스케줄링 가중치(weight), 허용 임계치(admission threshold), 큐 관리 임계치, 링크 계층 프로토콜 설정, 등)를 제어하는 노드-특정적 파라미터들에 접속(access)하기 위한 참조(reference)로서 사용되고, eNB를 소유하는 운영자(operator)에 의해 미리-설정된, 스칼라(scalar)이다. 여기서, ARP는 자원 제약(limitation)들의 경우에 베어러 수립/수정 요청이 수락될 수 있는지 혹은 거절될 필요가 있는지를 결정하는 데 사용된다. 아울러 ARP는 예외적 자원 제약들(예, 핸드오버) 동안 어떤 베어러(들)을 드랍할 것인지 결정하기 위해 eNB에 의해 사용될 수 있다.

상기 MME는 PTI(Procedure Transaction Id), EPS 베어러 QoS 파라미터들(ARP 제외), TFT(Traffic Flow Template), APN-AMBR, EPS 베어러 식별자 및 WLAN 오프로딩가능성(offloadability) 지시를 포함하는 세션 관리 요청을 만들어(build), eNB에게 보낸다(3PP TS 23.401의 "Figure 5.4.2.1-1"의 단계 4 참조). 상기 UE가 활성 V2X 어플리케이션을 갖는 경우, 각각의 EPS 베어러에 대해, 상기 MME는 어떤 V2X 어플리케이션이 어떤 EPS 베어러를 사용하는지를 지시한다. 또한, 각각의 EPS 베어러에 대해, 상기 MME는 해당 EPS 베어러가 비-IP 데이터 또는 IP 데이터를 전송해야 하는지 여부에 대한 정보도 상기 세션 관리 요청에 포함시킬 수 있다. 이 단계에서 네트워크 노드(예, MME 혹은 eNB)는 UE에 다음 설정 정보를 제공할 수 있다:

- 어떤 V2X 어플리케이션이 상기 UE에 의해 사용되도록 허용되는지;

- 허용된 각 V2X 어플리케이션에 대해, 어떤 EPS 베어러 또는 무선 베어러가 해당 V2X 어플리케이션을 위한 데이터의 전송을 위해 사용되는지;

- 허용된 각 V2X 어플리케이션에 대해, ITS 상위 계층이 해당 V2X 어플리케이션을 위한 메시지에 IP 헤더를 추가하는지 여부 (또는 V2X 상위 계층에서 IP 프로토콜을 사용하는지 여부);

- 허용된 각 V2X 어플리케이션에 대해, 해당 V2X 어플리케이션을 위한 메시지를 수신하는 PDCP 계층이 해당 V2X 메시지에 IP 헤더를 추가하는지 여부 (또는 해당 V2X 어플리케이션을 위한 데이터에 대해 IP 프로토콜을 사용해야 하는지 여부); 또는

- 각 DRB 또는 EPS 베어러에 대해, IP 헤더/ 프로토콜을 사용하는지 여부.

<제안 2: 3GPP 계층에서 V2X 데이터 타입의 구별>

앞서 언급한 바와 같이, 기본적으로 LTE 시스템, 즉, EPS 시스템은 IP 통신을 기본으로 한다. 따라서 특별한 조건이 없으면 LTE 시스템, 즉, EPS 시스템은 IP 패킷의 전송을 담당한다. 그런데, ProSe의 경우, 소규모 그룹의 UE가 직접적으로 통신하게 되고, 또한 중앙 조정(central coordination) 역할을 하는 엔티티가 없는 경우도 있다. 따라서 ProSe 통신에서는, IP 기반의 통신을 해야 할 경우, 각각의 UE가 자기 스스로 자신이 쓸 IP 주소(address)를 선택한다. 이로 인해, 경우에 따라서는 ProSe 통신을 하는 UE들 중 같은 IP 주소를 가진 UE가 존재할 수 있다. 이를 방지하기 위해, ProSe를 위한 PDCP의 경우, IP뿐만 아니라 주소 해결 프로토콜(address resolution protocol, ARP) 프로토콜을 지원한다. ARP는 IP 네트워크 주소들을 데이터 링크 프로토콜에 의해 사용되는 하드웨어 주소들에 매핑하기 위해 사용되는 프로토콜이다. 또한 기지국밖에 위치한 UE들이 ProSe 관련 파라미터를 제어하기 위한 시그널링을 주고 받도록 하기 위해서 PC5 시그널링(PC5-S) 프로토콜도 정의되었다. PC5-S 프로토콜은 PC5 상으로의 제어 평면 시그널링(예, PC5 상의 안전한(secure) 계층-2 링크의 수립, 유지(maintenance) 및 해제, TMGI 모니터링 요청들, 셀 ID 선언(announcement 요청들 등)을 위해 사용된다. 이로 인해 이러한 서로 다른 데이터를 구별하기 위해서, PDCP 헤더의 SDU 타입은 IP, PC5-S, ARP 등을 지시하는 값을 지원한다. 그리고 PDCP 헤더가 커짐에 따라 무선(air) 인터페이스 상에서 발생하는 오버헤드 및 효율 저하를 막기 위해서, SDU 타입은 3 비트로 제한되었다. 다음 표는 현재 3GPP TS 36.323 표준 문서에 따른 SDU 타입 필드를 예시한 것이다. SDU 타입 필드는 PDCP 헤더에 위치하며, IP, ARP 및 PCG 시그널링을 구별(discriminate)하기 위해 사용된다.

Bit	Description
000	IP
001	ARP
010	PC5 Signaling
011-111	reserved

PDCP 엔티티는 SDU 타입별로 다르게 SDU를 핸들링할 수 있다. 예를 들어, IP SDU에는 헤더 압축을 적용하고, ARP SDU에는 헤더 압축을 적용하지 않을 수 있다.

ITS 어플리케이션, 즉, V2X 어플리케이션 및 그에 관련된 메시지 세트는 이미 20~30개 정도 존재한다. LTE에서 V2X를 지원한다는 것은 LTE 시스템이 상기 ITS 어플리케이션 및 그에 다른 메시지 세트를 지원한다는 것을 의미한다. 기본적으로 LTE V2X는 ProSe 통신을 기반으로 할 것으로 보이며, 따라서 앞서 설명된 PDCP SDU 포맷을 따를 것으로 예상된다. 즉, PDCP PDU의 헤더에 포함된 SDU 타입 정보를 이용하여, ITS 어플리케이션들을 구별하는 것이 필요할 것으로 예상되나, 표 3에서 나타난 바와 같이 SDU 타입은 최대 총 8가지의 SDU 타입들까지만 구별할 수 있고, 현재 추가 할당 가능한 값은 5개밖에 없으므로, 수많은 ITS 어플리케이션들을 지원하기에는 현재 PDCP PDU 구조는 한계가 있다.

따라서 본 발명의 제안 2는 다양한 ITS 어플리케이션들 또는 메시지 세트를 PDCP 계층에서 효율적으로 지원하는 방법을 제시하고자 한다. 본 발명의 제안 1-1 및 제안 1-2를 적용하더라도 ITS 어플리케이션들 또는 메시지 세트들을 구체적으로 구별할 방법이 필요하므로, 제안 2는 제안 1-1 또는 제안 1-2와 함께 적용될 수 있다.

* 제안 2-1

본 발명의 제안 2-1은 PDCP PDU 헤더에 포함되는 SDU 타입 필드를 이용하여, 해당 PDCP PDU에 포함된 PDCP SDU가 ITS용인지 아닌지에 대해서 알려줄 것을 제안한다. 다음은 본 발명의 제안 2-2에 따른 구현 예시들이다.

본 발명의 예시 2-1에 따라 표 3는 다음과 같이 수정될 수 있다.

> SDU 타입

>> 길이: 3 비트

>> PDCP SDU 타입, 즉, 계층-3 프로토콜 데이터 유닛 타입. PDCP 엔티티는 SDU 타입별로 다르게 SDU를 핸들링할 수 있다. 예를 들어, IP SDU에는 헤더 압축을 적용하고, ARP SDU에는 헤더 압축을 적용하지 않을 수 있다.

Bit	Description
000	IP
001	ARP
010	PC5 Signaling
011	ITS Application Data
100-111	reserved

전송 측에서 ITS 어플리케이션 데이터, 즉, V2X 데이터를 전송할 경우, PDCP PDU 헤더의 SDU 타입을 011으로 세팅하고, 상기 V2X 데이터를 PDCP PDU에 포함시켜 전송한다. 수신 측에서는, PDCP PDU를 수신한 경우, 상기 PDCP PDU의 헤더를 검사하고, 상기 PDCP PDU 헤더의 SDU 타입 필드의 값이 011인 경우, 상기 PDCP PDU에 포함된 PDCP SDU는 ITS용 데이터라고 간주하고, 상기 수신 측의 ITS 어플리케이션, 즉, V2X 어플리케이션으로 상기 데이터를 전달한다.

표 4에서, 011은 하나의 예시이며, 100, 101, 110 혹은 110 등 다른 값이 ITS 어플리케이션 데이터를 나타내는 값으로서 지정될 수도 있다.

UE에서 하나 이상의 ITS/V2X 어플리케이션 또는 ITS 프로토콜들이 사용될 수 있으므로 SDU 타입이 ITS/V2X 어플리케이션 임을 나타낼 경우, SDU에 포함된 ITS 데이터가, 어떤 ITS/V2X 어플리케이션에 해당하는 지가 추가 판별될 필요가 있을 수 있다. 이를 위해서, 본 발명은 추가적인 필드, 예를 들어, ITS 어플리케이션 필드를 PDCP PDU의 헤더에서 추가적으로 포함시킬 수 있다. 다음은 본 발명에 따른 ITS 어플리케이션 타입 필드를 예시한 것이다.

> ITS 어플리케이션 타입

>> 길이: Y 비트

>> 이 필드는 PDCP PDU헤더의 SDU 타입 필드가 ITS 데이터 또는 그와 비슷한 의미의 값을 지시할 경우, 추가적으로 PDCP PDU헤더에 포함된다. 이 필드는 PDCP PDU에 포함된 PDCP SDU가 어떤 ITS 어플리케이션의 데이터인지 지시한다.

Bit	Description
000	Basic Safety Message
001	CAM message
010	DENM message
011	ITS application X
100-111	reserved

예를 들어, 전송 측에서 CAM에 관련된 ITS 데이터를 전송할 때, 전송 측 PDCP는 상기 ITS 데이터를 PDCP SDU로 사용하여 PDCP PDU를 구성할 수 있다. 이때 상기 전송 측 PDCP 엔티티는 SDU 타입을 ITS 데이터임을 지시하도록 세팅(표 4를 적용하면, 011로 세팅)하고, 추가적으로 상기 ITS 데이터에 해당하는 ITS 어플리케이션 타입 값(표 5를 적용하면, 001)로 세팅된 ITS 어플리케이션 타입 필드를 PDCP PDU의 헤더에 포함시킬 수 있다. 상기 PDCP PDU는 수신 측에 전송된다.

수신 측에서는 PDCP PDU를 수신하면, 해당 PDCP PDU의 헤더를 검사하고, 만약 헤더의 SDU 타입이 ITS 데이터임을 지시하면, 추가적으로 상기 PDCP PDU의 헤더에 포함된 ITS 어플리케이션 타입 필드를 검사한다. 상기 ITS 어플리케이션 타입 필드에 세팅된 ITS 어플리케이션 타입 값에 따라서, 상기 수신 측은 상기 PDCP PDU에 포함된 데이터를 상기 ITS 어플리케이션 타입이 지시하는 ITS 어플리케이션, 즉, V2X 어플리케이션에게 해당 데이터를 전달할 수 있다.

* 제안 2-2

본 발명은 다양한 ITS/V2X 어플리케이션 또는 메시지 세트를 PDCP 계층에서 효율적으로 지원하는 방법을 제시하고자 한다. 이를 위해서 본 발명의 제안 2-2는 PDCP PDU 헤더에 포함되는 SDU 타입 필드를 이용하여, 해당 PDCP PDU에 포함된 PDCP SDU가 ITS용인지 아닌지에 대해서 알려줄 것을 제안한다. 특히, 본 발명의 제안 2-2는 ITS/V2X에 해당되는 어플리케이션의 종류가 많을 것을 대비할 뿐만 아니라, ProSe를 이용하여 ITS/V2X 이외의 다양한 어플리케이션을 지원하도록 하기 위해서, PDCP PDU의 헤더에 포함되는 SDU 타입 값을 확장 방법을 제시하고자 한다.

PDCP PDU의 헤더에 포함되는 SDU 타입이 특정 값으로 설정되는 경우, 상기 특정 값은 SDU 타입이 확장되었음을 지시하도록 사용한다. 즉, 상기 특정 값은 추가적인 관련 필드가 있음을 나타낼 수 있고, 수신 측 PDCP 계층은 SDU 타입 필드가 상기 특정 값으로 세팅되어 있으면, 추가적인 관련 필드가 PDCP PDU 내에 존재한다고 간주할 수 있다. 예를 들어, PDCP PDU의 헤더에 포함되는 SDU 타입이 특정 값으로 세팅되는 경우, 상기 특정 값으로 세팅된 PDCP 타입 필드는 또 다른 SDU 타입(이하, 확장 SDU 타입) 값이 상기 PDCP PDU에 포함되어 있음을 지시하는 것일 수 있다. PDCP PDU의 헤더에 포함되는 SDU 타입이 특정 값으로 세팅되는 경우, 상기 특정 값으로 세팅된 PDCP 타입 필드는 상기 특정 값과 추가적으로 포함된 SDU 타입 필드의 값을 이용하여 최종적으로 SDU 타입 값을 산출하도록 지시하는 것일 수 있다.

다음은 본 발명에 따른 SDU 타입 필드와 확장 SDU 타입 필드를 예시한 것이다.

> SDU 타입

본 발명의 예시 2-2에 따라 표 3는 다음과 같이 수정될 수 있다.

>> 길이: 3 비트

>> PDCP SDU 타입, 즉, 계층-3 프로토콜 데이터 유닛 타입. PDCP 엔티티는 SDU 타입별로 다르게 SDU를 핸들링할 수 있다. 예를 들어, IP SDU에는 헤더 압축을 적용하고, ARP SDU에는 헤더 압축을 적용하지 않을 수 있다. SDU 타입이 111로 세팅되면, 확장 SDU 타입이 사용된다.

Bit	Description
000	IP
001	ARP
010	PC5 Signaling
011-110	reserved
111	Use extended SDU Type

SDU 타입 필드가 특정 값(예, 표 6의 111)로 세팅되면, 상기 특정 값은 SDU 타입 필드와 동일 목적의 다른 SDU 타입 필드가 PDCP PDU에 존재하고 상기 다른 SDU 타입 필드를 이용하여 SDU 타입을 구별할 것을 지시하는 역할을 할 수 있다.

> 확장 SDU 타입(extended SDU type)

>> 예: X 비트

>> 이 확장 SDU 타입은 SDU 타입이 111로 세팅되면 사용/포함된다.

Bit	Description
0000	Non-ITS application data type 1
0001	ITS application data type 2
0010	Non-ITS application data type 3
0011	ITS application. CAM
0100	ITS application. BSM
0101-1111	reserved

예를 들어, ITS 및 비-ITS 어플리케이션 데이터 타입으로 인하여 최소 5개의 새로운 SDU 타입이 필요한 상황이라고 가정하자. 그런데 기존의 SDU 타입(표 3 참조) 필드만으로는 기존 SDU 타입들과 새로운 SDU 타입들을 모두 표현하기 어렵다. 따라서, 본 발명에서는 앞서 언급한 바와 같이, 새로운 어플리케이션 데이터 타입을 지시하기 위해서 확장 SDU 타입을 정의하고, 여기에 새로운 각 어플리케이션 데이터 타입을 지시하는 코드 포인트를 할당한다. 예를 들어, 만약 PDCP PDU에 포함되는 SDU가 IP면, 상기 PDCP PDU 내 SDU 타입은 000으로 세팅되고 확장 SDU 필드는 상기 PDCP PDU 내에 포함하지 않는다. 그리고 PDCP PDU에 포함되는 SDU가 CAM면 SDU 타입은 111로 세팅되고, 추가적으로 0010으로 세팅한 확장 SDU 타입 필드가 상기 PDCP PDU의 헤더에 포함되며, 해당 데이터가 상기 PDCP PDU에 포함된다. 수신 측도 비슷한 동작을 할 수가 있다. 예를 들어, 수신 측 PDCP 계층은 수신한 PDU의 SDU 타입에 따라서, 포함된 SDU를 처리하거나 또는 설정된 어플리케이션으로 전달한다. 만약 수신한 PDU 내 SDU 타입이 111로 세팅되어 있으면, 상기 수신 측 PDCP 계층은 추가적으로 확장 SDU 타입 필드가 상기 PDU 내에 있다고 간주하고, 상기 확장 SDU 타입 필드 값을 읽어서, 실제 포함된 SDU가 어떤 어플리케이션의 데이터 타입인지 판별한 후, 해당 어플리케이션으로 전달한다. 표 6 및 표 7에서 111, 0010 등의 값은 예시이며 다른 값으로 대체될 수 있다.

상기 확장 SDU 타입 필드는 ITS 어플리케이션 데이터의 타입뿐만 아니라 비-ITS 어플리케이션 데이터의 타입도 구별할 수 있도록 정의될 수 있다. IP, ARP 및 PC5 시그널링을 제외한 모든 프로토콜들이 확장 SDU 타입에 의해 구별될 수 있도록 확장 SDU 타입 필드 값들이 정의될 수 있다.

* 제안 2-3

앞서 언급한 바와 같이 ITS 상위 계층에서 3GPP 계층으로 V2X 관련 데이터의 전송을 요청하는 경우, 상기 데이터는 IP 패킷의 형태를 취할 수도 있고, 비-IP 패킷 형태를 취할 수도 있다. 일반적으로 UE는 V2X 통신도 지원하지만 통신의 기본적인 목적(예, 인터넷 검색, 통화, SMS)을 위한 데이터 통신도 지원한다. 따라서, IP 형태를 취하는 데이터는 V2X용 데이터일 수도 있고 비-V2X용 데이터일 수도 있다. 비슷하게, 비-IP 형태를 취하는 데이터는 V2X용 데이터일 수도 있고 비-V2X용 데이터일 수도 있다.

따라서, 본 발명은 PDCP 헤더를 이용하여, PDCP PDU에 포함된 데이터가 어떤 V2X 어플리케이션에 관련된 데이터인지를 정확하게 지시하기 위해서, SDU 타입에서 IP와 비-IP를 구별하는 것 이상의 정보를 알려줄 것을 제안한다. 예를 들어 SDU 타입은 비-V2X용 IP, V2X용 IP, 비-V2X용 비-IP, V2X용 비-IP를 구별하도록 정의될 수 있다. 다시 말해, SDU 타입은 비-ITS 어플리케이션용 IP 데이터, ITS 어플리케이션/프로토콜용 IP 데이터, 비-ITS 어플리케이션용 비-IP 데이터, ITS 어플리케이션/프로토콜용 비-IP 데이터를 구별하도록 정의될 수 있다.

본 발명에 따라 기존 SDU 타입을 정의한 표 3은 예를 들어 표 8과 같이 수정될 수 있다. 표 8 내 값은 임의로 지정된 것으로서, 표 8에 예시된 SDU 타입들과 비트 값들이 다른 형태로 매핑 관계가 정의될 수도 있다.

Bit	Description
000	IP (Non-V2X)
001	ARP
010	PC5 Signaling
011	IP (V2X)
100	Non-IP (Non-V2X)
101	Non-IP (V2X)
110-111	reserved

본 발명의 제안 2-3는 PDCP 헤더에 포함된 SDU 타입 정보에, 비-IP 타입의 데이터 지시자를 추가하고, V2X와 비-V2X 데이터의 종류를 보다 정확하게 알려줄 수 있다. 따라서, PDCP PDU를 수신한 수신 측 PDCP 엔티티는 SDU 타입 필드 정보를 통해서, 해당 PDCP PDU에 포함된 데이터가 IP 형태의 데이터인지 아니면, 비-IP 형태의 데이터인지 알 수 있다. 아울러 상기 수신 측 PDCP 엔티티는 해당 PDCP PDU에 포함된 데이터를 V2X 상위 계층에 전달할지 말지, 그리고 상기 PDCP PDU에 포함된 데이터가 V2X 관련 데이터인지 아닌지 알 수 있다.

본 발명의 제안 2-3은 제안 2-1 혹은 제안 2-2와 함께 사용될 수 있다. 예를 들어, SDU 타입이 해당 PDCP PDU에 포함된 데이터가 V2X 관련 데이터임을 지시하는 경우, 상기 PDCP PDU는 해당 데이터가 어떤 V2X 어플리케이션에 해당하는 데이터인지 알려주는 추가적인 필드를 포함할 수도 있다. 수신 측 PDCP 엔티티는 해당 PDCP PDU에 포함된 데이터가 V2X 관련 데이터라면, SDU 타입 필드에 설정된 값에 따라 해당 PDCP PDU에 어떤 V2X 어플리케이션에 해당하는 데이터인지 알려주는 추가적인 필드(예, 표 5 또는 표 7의 ITS 어플리케이션 타입 필드)가 존재하는지 여부도 있게 된다.

도 13은 본 발명에 따른 PDCP PDU 구조를 예시한 것이다. 도 13은 예시에 불과하며, 설명의 편의를 위해 PDCP PDU 내 다른 필드들은 도 13에 표시되지 않았다.

표 8 및 도 13(a)를 참조하면, SDU 타입이 000으로 세팅되면, 상기 SDU 타입은 해당 PDCP PDU에 포함된 데이터가 IP 타입의 비-V2X 데이터임을 나타낸다. 상기 PDCP PDU는 IP 타입의 비-V2X 데이터를 PDCP SDU에 포함한다. 상기 PDCP PDU는 V2X 데이터의 타입을 구별하는 ITS 어플리케이션 타입 필드는 포함하지 않는다.

표 8 및 도 13(b)를 참조하면, SDU 타입이 011으로 세팅되면, 상기 SDU 타입은 해당 PDCP PDU에 포함된 데이터가 IP 타입의 V2X 데이터임을 나타낸다. SDU 타입 필드가 V2X 데이터가 PDCP PDU에 포함되어 있음을 나타내므로, 상기 V2X 데이터의 타입을 나타내는 ITS 어플리케이션 타입 필드가 상기 PDCP PDU에 포함된다. 상기 ITS 어플리케이션 타입 필드가 V2X 앱 A를 나타내는 값으로 세팅되면, 상기 PDCP PDU는 IP 타입의 V2X 앱 A에 해당하는 데이터를 PDCP SDU에 포함한다.

표 8 및 도 13(c)를 참조하면, SDU 타입이 100으로 세팅되면, 상기 SDU 타입은 해당 PDCP PDU에 포함된 데이터가 비-IP 타입의 비-V2X 데이터임을 나타낸다. 상기 PDCP PDU는 비-IP 타입의 비-V2X 데이터를 PDCP SDU에 포함한다. 상기 PDCP PDU는 V2X 데이터의 타입을 구별하는 ITS 어플리케이션 타입 필드는 포함하지 않는다.

표 8 및 도 13(d)를 참조하면, SDU 타입이 101으로 세팅되면, 상기 SDU 타입은 해당 PDCP PDU에 포함된 데이터가 비-IP 타입의 V2X 데이터임을 나타낸다. SDU 타입 필드가 V2X 데이터가 PDCP PDU에 포함되어 있음을 나타내므로, 상기 V2X 데이터의 타입을 나타내는 ITS 어플리케이션 타입 필드가 상기 PDCP PDU에 포함된다. 상기 ITS 어플리케이션 타입 필드가 V2X 앱 B를 나타내는 값으로 세팅되면, 상기 PDCP PDU는 비-IP 타입의 V2X 앱 B에 해당하는 데이터를 PDCP SDU에 포함한다.

본 발명의 제안들에서 "어플리케이션"은 어플리케이션을 의미하는 대신 "프로토콜"을 의미하는 것으로 간주될 수도 있다. 즉, 본 발명의 제안들에서 어플리케이션은 퍼실리티 혹은 지오네트워킹이 될 수도 있다.

수신 측 UE는 다른 UE 혹은 eNB로부터 PDU를 수신하고 상기 PDU를 본 발명의 제안들 중 어느 하나에 따라 처리할 수 있다. 예를 들어, 수신 측 UE는 본 발명의 제안 1-1, 제안 1-2 및/또는 제안 2에 따라 PDU 내 SDU 타입(및 추가 필드)를 기반으로 SDU를 상위 계층에 전달 혹은 삭제할 수 있다.

전송 측 UE는 본 발명의 제안들 중 어느 하나에 따라 PDU를 생성하고, 상기 PDU를 다른 UE에게 전송할 수 있다. 예를 들어 전송 측 UE는 상위 계층으로부터의 데이터 담은 SDU를 포함하는 PDU를 본 발명의 제안 1-1, 제안 1-2 및/또는 제안 2에 따라 생성할 수 있다.

UE 또는 eNB는 자신이 지원하는 다양한 V2X 어플리케이션들의 데이터를 MBMS 형태로 브로드캐스트할 수 있다. 본 발명의 제안 2에 따르면, 각 UE는 다른 UE 혹은 eNB가 브로드캐스트한 어플리케이션 데이터 중 해당 UE에서 실제 사용/지원/설치된 어플리케이션에 해당하는 데이터만 상기 UE의 상위 계층에 알려줄 수 있다.

예를 들어, 수신 측에 해당 V2X 어플리케이션이 있으면 해당 SDU 혹은 해당 SDU에 포함된 V2X 데이터가 상위 계층(예, ITS 상위 계층 혹은 어플리케이션 계층)에 전달될 수 있다. 해당 V2X 어플리케이션이 없으면 해당 SDU 혹은 해당 SDU에 포함된 V2X 데이터가 상위 계층에 전달되지 않고 (예, 3GPP 계층 혹은 PDCP 계층에서) 삭제될 수 있다.

본 발명에 의하면, 차량 간 통신을 지원하는 이동 통신 시스템에서, 차량 간 통신 어플리케이션의 프로토콜 스택을 효과적으로 구별하여, 상기 이동 통신 시스템에서 데이터의 처리 경로를 적절히 제어하고 각 데이터에 최적의 QoS를 적용할 수 있다.

본 발명에 의하면, 광대역 모바일 브로드밴드 서비스를 지원하는 이동 통신 시스템에서, 서로 다른 V2X 어플리케이션에서 생성하는 서로 다른 타입의 데이터들이 효과적으로 처리될 수 있다.

본 발명에 의하면 광 대역 모바일 브로드밴드 서비스를 지원하는 이동 통신 시스템에서, 기존의 통신 프로토콜에서 상위 어플리케이션 서비스를 구별하여 데이터 처리를 지원함으로써, 복수 개의 차량 통신 어플리케이션 서비스를 무선 자원 효율적으로 지원할 수 있다.

본 발명에서 동일 V2X 어플리케이션의 메시지는 통신 방법에 따라 다르게 구성될 수 있다. 예를 들어, 동일 V2X 어플리케이션 메시지가 통신 방법에 따라 IP 타입이 될 수도 있고, 비-IP 타입이 될 수도 있다. 예를 들어 특정 V2X 어플리케이션의 메시지가 기지국을 거치지 않고 차량 간 직접 통신으로 UE에 전송되면 상기 메시지는 비-IP 타입으로 생성되고, 상기 특정 V2X 어플리케이션의 메시지가 기지국의 도움을 받아 전송되면 상기 메시지는 IP 타입으로 생성될 수 있다. 동일 V2X 어플리케이션의 메시지가 IP 타입인지 혹은 비-IP 타입인지를 본 발명의 제안 1-1 및/또는 제안 2에 따라 식별될 수 있다. 다시 말해, 동일 V2X 어플리케이션의 메시지에 대한 IP 타입 혹은 비-IP 타입의 구분과 해당 메시지의 처리에 본 발명의 제안들이 적용될 수 있다.

도 14는 본 발명의 제안에 적용되는 노드 장치의 구성을 도시하는 도면이다.

제안하는 실시 예에 따른 UE 장치(100)는, 송수신장치(110), 프로세서(120) 및 메모리(130)를 포함할 수 있다. 송수신장치(110)은 무선 주파수(radio frequency, RF) 유닛으로 칭해지기도 한다. 송수신장치(110)은 외부 장치로 각종 신호, 데이터 및 정보를 전송하고, 외부 장치로 각종 신호, 데이터 및 정보를 수신하도록 구성될 수 있다. 또는, 송수신장치(110)는 전송부와 수신부로 분리되어 구현될 수도 있다. UE 장치(100)는 외부 장치와 유선 및/또는 무선으로 연결될 수 있다. 프로세서(120)는 UE 장치(100) 전반의 동작을 제어할 수 있으며, UE 장치(100)가 외부 장치와 송수신할 정보 등을 연산 처리하는 기능을 수행하도록 구성될 수 있다. 또한, 프로세서(120)는 본 발명에서 제안하는 UE 동작을 수행하도록 구성될 수 있다. 프로세서(120)은 본 발명의 제안에 따라 데이터 혹은 메시지를 전송하도록 송수신장치(110)을 제어할 수 있다. 메모리(130)는 연산 처리된 정보 등을 소정시간 동안 저장할 수 있으며, 버퍼(미도시) 등의 구성요소로 대체될 수 있다.

도 14를 참조하면 제안하는 실시 예에 따른 네트워크 노드 장치(200)는, 송수신장치(210), 프로세서(220) 및 메모리(230)를 포함할 수 있다. 송수신장치(210)은 무선 주파수(radio frequency, RF) 유닛으로 칭해지기도 한다. 송수신장치(210)는 외부 장치로 각종 신호, 데이터 및 정보를 전송하고, 외부 장치로 각종 신호, 데이터 및 정보를 수신하도록 구성될 수 있다. 네트워크 노드 장치(200)는 외부 장치와 유선 및/또는 무선으로 연결될 수 있다. 송수신장치(210)는 전송부와 수신부로 분리되어 구현될 수도 있다. 프로세서(220)는 네트워크 노드 장치(200) 전반의 동작을 제어할 수 있으며, 네트워크 노드 장치(200)가 외부 장치와 송수신할 정보 등을 연산 처리하는 기능을 수행하도록 구성될 수 있다. 또한, 프로세서(220)는 본 발명에서 제안하는 네트워크 노드 동작을 수행하도록 구성될 수 있다. 프로세서(220)은 본 발명의 제안에 따라 데이터 혹은 메시지를 UE 혹은 다른 네트워크 노드에 전송하도록 송수신장치(110)을 제어할 수 있다. 메모리(230)는 연산 처리된 정보 등을 소정시간 동안 저장할 수 있으며, 버퍼(미도시) 등의 구성요소로 대체될 수 있다.

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

UE의 송수신장치(110)는 다른 UE 혹은 네트워크 장치로부터 프로토콜 데이터 유닛(protocol data unit, PDU)을 수신할 수 있다. 상기 PDU 내 서비스 데이터 유닛(service data unit, SDU) 타입 필드가 V2X(Vehicle-to-Everything) 타입임을 나타내는 값으로 세팅되어 있으면, 상기 UE의 프로세서(120)는 상기 PDU 내 추가 필드를 기반으로 상기 PDU 내 SDU를 상위 계층으로 전달 혹은 삭제할 수 있다. 상기 추가 필드는 상기 SDU의 데이터에 대응하는 어플리케이션 혹은 프로토콜 타입을 지시할 수 있다. 상기 프로세서(120)는 상기 SDU 타입 필드를 바탕으로 적어도 상기 SDU의 데이터가 V2X용 IP(internet protocol)인지, 비-V2X용 IP인지, V2X용 비-IP인지 혹은 비-V2X용 비-IP인지를 구별할 수 있다. 상기 프로세서(120)는 상기 UE가 상기 어플리케이션 혹은 프로토콜 타입을 지원하면 상기 SDU를 상기 상위 계층으로 전달하고, 상기 UE가 상기 어플리케이션 혹은 프로토콜 타입을 지원하지 않으면 상기 SDU를 삭제할 수 있다. 상기 상위 계층은 ITS(Intelligent Transport Systems) 계층일 수 있다. 상기 PDU는 상기 ITS 상위 계층의 하위 계층인 통신 계층의 PDU일 수 있다. 상기 통신 계층은 예를 들어 PDCP 계층일 수 있다.

UE의 프로세서(120)는 상위 계층에서 생성된 V2X(Vehicle-to-Everything) 데이터를 담은 서비스 데이터 유닛(service data unit, SDU)를 포함하는 프로토콜 데이터 유닛(protocol data unit, PDU)를 생성할 수 있다. 상기 프로세서(120)는 상기 SDU가 V2X 타입임을 나타내는 값으로 세팅된 SDU 타입 필드를 포함하도록 상기 PDU를 생성할 수 있다. 상기 프로세서(120)는 상기 SDU의 데이터에 해당하는 어플리케이션 혹은 프로토콜 타입을 지시하는 추가 필드를 포함하도록 상기 PDU를 생성할 수 있다. 상기 UE의 송수신장치(110)는 다른 UE 혹은 네트워크 장치에게 상기 PDU를 전송할 수 있다. 상기 SDU 타입 필드는 적어도 상기 SDU의 데이터가 V2X용 IP(internet protocol)인지, 비-V2X용 IP인지, V2X용 비-IP인지 혹은 비-V2X용 비-IP인지를 나타낼 수 있다. 상기 상위 계층은 ITS(Intelligent Transport Systems) 계층일 수 있다. 상기 PDU는 상기 ITS 상위 계층의 하위 계층인 통신 계층에서 생성될 수 있다. 상기 통신 계층은 예를 들어 PDCP 계층일 수 있다.

상술한 본 발명의 실시예들은 다양한 수단을 통해 구현될 수 있다. 예를 들어, 본 발명의 실시예들은 하드웨어, 펌웨어(firmware), 소프트웨어 또는 그것들의 결합 등에 의해 구현될 수 있다.

하드웨어에 의한 구현의 경우, 본 발명의 실시예들에 따른 방법은 하나 또는 그 이상의 ASICs(Application Specific Integrated Circuits), DSPs(Digital Signal Processors), DSPDs(Digital Signal Processing Devices), PLDs(Programmable Logic Devices), FPGAs(Field Programmable Gate Arrays), 프로세서, 컨트롤러, 마이크로 컨트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다.

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

상술한 바와 같이 개시된 본 발명의 바람직한 실시형태에 대한 상세한 설명은 당업자가 본 발명을 구현하고 실시할 수 있도록 제공되었다. 상기에서는 본 발명의 바람직한 실시 형태를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다. 따라서, 본 발명은 여기에 나타난 실시형태들에 제한되려는 것이 아니라, 여기서 개시된 원리들 및 신규한 특징들과 일치하는 최광의 범위를 부여하려는 것이다.

상술한 바와 같은 통신 방법은 3GPP 시스템뿐 아니라, 그 외에도 IEEE 802.16x, 802.11x 시스템을 포함하는 다양한 무선 통신 시스템에 적용하는 것이 가능하다. 나아가, 제안한 방법은 초고주파 대역을 이용하는 mmWave 통신 시스템에도 적용될 수 있다.

Claims

무선 통신 시스템에서 사용자기기(user equipment, UE)가 데이터 유닛을 수신함에 있어서,
프로토콜 데이터 유닛(protocol data unit, PDU)을 수신; 및
상기 PDU 내 서비스 데이터 유닛(service data unit, SDU) 타입 필드가 V2X(Vehicle-to-Everything) 타입임을 나타내는 값으로 세팅되어 있으면, 상기 PDU 내 추가 필드를 기반으로 상기 PDU 내 SDU를 상위 계층으로 전달 혹은 삭제하는 것을 포함하며,
상기 추가 필드는 상기 SDU의 데이터에 대응하는 어플리케이션 혹은 프로토콜 타입을 지시하는,
데이터 유닛 수신 방법.
제1항에 있어서,
상기 SDU 타입 필드는 적어도 상기 SDU의 데이터가 V2X용 IP(internet protocol)인지, 비-V2X용 IP인지, V2X용 비-IP인지 혹은 비-V2X용 비-IP인지를 구별하는,
데이터 유닛 수신 방법.
제1항에 있어서,
상기 UE가 상기 어플리케이션 혹은 프로토콜 타입을 지원하면 상기 SDU가 상기 상위 계층으로 전달되고, 상기 UE가 상기 어플리케이션 혹은 프로토콜 타입을 지원하지 않으면 상기 SDU가 삭제되는,
데이터 유닛 수신 방법.
제1항에 있어서,
상기 상위 계층은 ITS(Intelligent Transport Systems) 계층인,
데이터 유닛 수신 방법.
무선 통신 시스템에서 사용자기기(user equipment, UE)가 데이터 유닛을 수신함에 있어서,
무선 주파수(radio frequency, RF) 유닛, 및
상기 RF 유닛을 제어하도록 구성된 프로세서를 포함하며, 상기 프로세서는:
프로토콜 데이터 유닛(protocol data unit, PDU)을 수신하도록 상기 RF 유닛을 제어; 및
상기 PDU 내 서비스 데이터 유닛(service data unit, SDU) 타입 필드가 V2X(Vehicle-to-Everything) 타입임을 나타내는 값으로 세팅되어 있으면, 상기 PDU 내 추가 필드를 기반으로 상기 PDU 내 SDU를 상위 계층으로 전달 혹은 삭제하며,
상기 추가 필드는 상기 SDU의 데이터에 대응하는 어플리케이션 혹은 프로토콜 타입을 지시하는,
사용자기기.
제5항에 있어서,
상기 SDU 타입 필드는 적어도 상기 SDU의 데이터가 V2X용 IP(internet protocol)인지, 비-V2X용 IP인지, V2X용 비-IP인지 혹은 비-V2X용 비-IP인지를 구별하는,
사용자기기.
제5항에 있어서,
상기 프로세서는 상기 UE가 상기 어플리케이션 혹은 프로토콜 타입을 지원하면 상기 SDU를 상기 상위 계층으로 전달하고, 상기 UE가 상기 어플리케이션 혹은 프로토콜 타입을 지원하지 않으면 상기 SDU를 삭제하는,
사용자기기.
제5항에 있어서,
상기 상위 계층은 ITS(Intelligent Transport Systems) 계층인,
사용자기기.
무선 통신 시스템에서 사용자기기(user equipment, UE)가 데이터 유닛을 전송함에 있어서,
상위 계층에서 생성된 V2X(Vehicle-to-Everything) 데이터를 담은 서비스 데이터 유닛(service data unit, SDU)를 포함하는 프로토콜 데이터 유닛(protocol data unit, PDU)를 생성; 및
상기 PDU를 전송하는 것을 포함하며,
상기 PDU는 상기 SDU가 V2X 타입임을 나타내는 값으로 세팅된 SDU 타입 필드와, 상기 SDU의 데이터에 해당하는 어플리케이션 혹은 프로토콜 타입을 지시하는 추가 필드를 포함하는,
데이터 유닛 전송 방법.
제9항에 있어서,
상기 SDU 타입 필드는 적어도 상기 SDU의 데이터가 V2X용 IP(internet protocol)인지, 비-V2X용 IP인지, V2X용 비-IP인지 혹은 비-V2X용 비-IP인지를 구별하는,
데이터 유닛 전송 방법.
제9항에 있어서,
상기 상위 계층은 ITS(Intelligent Transport Systems) 계층인,
데이터 유닛 전송 방법.
무선 통신 시스템에서 사용자기기(user equipment, UE)가 데이터 유닛을 전송함에 있어서,
무선 주파수(radio frequency, RF) 유닛, 및
상기 RF 유닛을 제어하도록 구성된 프로세서를 포함하며, 상기 프로세서는:
상위 계층에서 생성된 V2X(Vehicle-to-Everything) 데이터를 담은 서비스 데이터 유닛(service data unit, SDU)를 포함하는 프로토콜 데이터 유닛(protocol data unit, PDU)를 생성; 및
상기 PDU를 전송하도록 상기 RF 유닛을 제어하며,
상기 PDU는 상기 SDU가 V2X 타입임을 나타내는 값으로 세팅된 SDU 타입 필드와, 상기 SDU의 데이터에 해당하는 어플리케이션 혹은 프로토콜 타입을 지시하는 추가 필드를 포함하는,
사용자기기.
제12항에 있어서,
상기 SDU 타입 필드는 적어도 상기 SDU의 데이터가 V2X용 IP(internet protocol)인지, 비-V2X용 IP인지, V2X용 비-IP인지 혹은 비-V2X용 비-IP인지를 구별하는,
사용자기기.
제12항에 있어서,
상기 상위 계층은 ITS(Intelligent Transport Systems) 계층인,
사용자기기.