TS 22.185 V1.0.0 (2016-02) TechService requirements for V2X services

《TS 22.185 V1.0.0 (2016-02) TechService requirements for V2X services》由會(huì)員分享，可在線閱讀，更多相關(guān)《TS 22.185 V1.0.0 (2016-02) TechService requirements for V2X services（10頁珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

3GPP TS 22.185 V1.0.0 (2016-02) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Service requirements for V2X services; Stage 1 (Release 14) The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners Publications Offices. 3GPP TS 22.185 V1.0.0 (2016-02) 10 (Release 14) Keywords MCC selects keywords from stock list. 3GPP Postal address 3GPP support office address 650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Internet http://www.3gpp.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. 2015, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved. UMTS? is a Trade Mark of ETSI registered for the benefit of its members 3GPP? is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTE? is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners GSM and the GSM logo are registered and owned by the GSM Association Contents Foreword 4 1 Scope 5 2 References 5 3 Definitions and abbreviations 5 3.1 Definitions 5 3.2 Abbreviations 5 4 Overview on V2X (informative) 6 4.1 Types of V2X application support in 3GPP 6 4.1.1 General 6 4.1.2 Vehicle-to-Vehicle (V2V) application 6 4.1.3 Vehicle-to-Infrastructure (V2I) application 7 4.1.4 Vehicle-to-Network (V2N) application 7 4.1.5 Vehicle-to-Pedestrian (V2P) application 7 5 Requirements 8 5.1 Overall Requirements 8 5.2 Specific Service Requirements 8 5.2.1 Latency/ Reliability Requirements 8 5.2.2 Message Size Requirements 9 5.2.3 Frequency Requirements 9 5.2.4 Range Requirements 9 5.2.5 Speed Requirements 9 5.3 Security Requirements 9 Annex A: Change history 11 Foreword This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. 1 Scope The present document provides 3GPP support for V2X service requirements to be supported by LTE transport. These requirements are identified by taking into account the V2X service requirements defined in other SDOs, e.g. ETSI ITS, US SAE. The specification includes requirements of safety and non-safety aspects. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document.- [1] 3GPPTR21.905: "Vocabulary for 3GPP Specifications". [2] 3GPPTR 22.885: "Study on LTE Support for V2X Services". [3] ETSI TR 102 638 V1.1.1: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Definitions". 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the terms and definitions given in 3GPP TR21.905[1] and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP TR21.905[1]. Road Side Unit: A stationary infrastructure entity supporting V2X applications that can exchange messages with other entities supporting V2X applications. NOTE: RSU is a term frequently used in existing ITS specifications, and the reason for introducing the term in the 3GPP specifications is to make the documents easier to read for the ITS industry. RSU is a logical entity that combines V2X application logic with the functionality of an eNB (referred to as eNB-type RSU) or UE (referred to as UE-type RSU). 3.2 Abbreviations For the purposes of the present document, the abbreviations given in 3GPP TR21.905 [1] and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 3GPP TR21.905[1]. RSU Road Side Unit V2I Vehicle-to-Infrastructure V2N Vehicle-to-Network V2P Vehicle-to-Pedestrian V2V Vehicle-to-Vehicle V2X Vehicle-to-Everything 4 Overview on V2X (informative) 4.1 Types of V2X application support in 3GPP 4.1.1 General The V2X applications in the present specification, referred to as Vehicle-to-Everything (V2X), contain the following four different types: - Vehicle-to-Vehicle (V2V) - Vehicle-to-Infrastructure (V2I) - Vehicle-to-Network (V2N) - Vehicle-to-Pedestrian (V2P) Figure 4.1.1-1: Types of V2X applications (V2V, V2P, V2N and V2I) These four types of V2X applications can use “co-operative awareness” to provide more intelligent services for end-users. Thismeans that entities, such as vehicles, roadside infrastructure, application server and pedestrians, can collect knowledge of their local environment (e.g., information received from other vehicles or sensor equipment in proximity) to process and share that knowledge in order to provide more intelligent services, such as cooperative collision warning or autonomous driving. These intelligent transportation services and the associated message sets have been defined in automotive SDOs outside 3GPP. Three basic classes of applications for providing ITS services: road safety, traffic efficiency, and other applications can be found in e.g., [3]. 3GPP only handles the transport of these messages to support different types of V2X applications. The message transport expectations are described in requirements defined in this specification. 4.1.2 Vehicle-to-Vehicle (V2V) application V2V applications expect UEs that are in proximity of each other to exchange V2V application information. 3GPP transport of messages containing V2V application information requires the UE to have a valid subscription and authorization from a network operator. Transport for a valid subscriber is provided whether the UE is served or not served by E-UTRAN. The UE supporting V2V applications transmits messages containing V2V application information (e.g. location, dynamics, and attributes). The message payloads may be flexible in order to accommodate varying amount of information. 3GPP transport of message containing V2V application information is predominantly broadcast-based as illustrated in Figure 4.1-2. Such 3GPP transport includes the transport between UEs directly and/or, due to the limited direct communication range, the transport between UEs via infrastructure supporting V2X communication, e.g., RSU, application server, etc. Error! Objects cannot be created from editing field codes. Figure 4.1.2-1: Broadcast-based V2V communications 4.1.3 Vehicle-to-Infrastructure (V2I) application The UE supporting V2I applications transmits messages containing V2I application information to an RSU. An RSU transmits messages containing V2I application information to one or more UEs supporting V2I applications. 4.1.4 Vehicle-to-Network (V2N) application The UE supporting V2N applications communicates with an application server supporting V2N applications. Both parties communicate with each other via EPS. The application server and its location are out of 3GPP scope. 4.1.5 Vehicle-to-Pedestrian (V2P) application V2P applications expect UEs that are in proximity of each other to exchange V2P application information. 3GPP transport of messages containing V2P application information requires the UE to have a valid subscription and authorization from a network operator. Transport for a valid subscriber is provided whether the UE is served or not served by E-UTRAN. The UE supporting V2P applications transmits messages containing V2P application information. It is expected that V2P application information can be transmitted either by a UE supporting V2X application in a vehicle (e.g., warning to pedestrian), or by a UE supporting V2X application associated with a vulnerable road user (e.g., warning to vehicle). 3GPP transport of messages containing V2P application information includes the transport between UEs directly and/or, due to the limited direct communication range, the transport between UEs via infrastructure supporting V2X communication, e.g., RSU, application server, etc. NOTE: The main difference between 3GPP transport of messages with V2P and V2V application information is due to the properties of the UE. A UE supporting V2P applications used by pedestrian might, for example, have lower battery capacity, the radio sensitivity might be limited, e.g. due to antenna design, and therefore it may not be able to send messages with the same periodicity as UEs supporting V2V application, and/or receive messages. 5 Requirements 5.1 Overall Requirements [R-5.1-001] The message transmission shall be under control of the 3GPP network when the transmitting UE is served by the E-UTRAN. [R-5.1-002] A UE supporting V2X application shall be able to be pre-configured by the 3GPP network with parameters to be used for the transmission and reception of messages when not served by E-UTRAN supporting V2X communication. [R-5.1-003] A UE supporting V2X application shall be able to transmit and receive messages when served or not served by E-UTRAN supporting V2X communication. [R-5.1-004] An RSU shall be able to transmit/receive messages to/from a UE supporting V2X application. [R-5.1-005] The 3GPP system shall be able to support message transfer between UEs when served or not served by the same PLMN supporting V2X communications. [R-5.1-006] The 3GPP system shall be able to provide means to prioritize message transmission among UEs supporting V2X application [R-5.1-007] The 3GPP system shall be able to provide means to prioritize transmission of messages according to their type (e.g. safety vs. non-safety). [R-5.1-008] The 3GPP system shall be able to vary the transmission rate and range of the V2X communication based on service conditions (e.g., UE speed, UE density). [R-5.1-009] The 3GPP system shall be able to distribute information in a resource efficient way to large numbers of UEs supporting V2X application. [R-5.1-010] A UE supporting V2X application shall be able to identify whether E-UTRAN supports V2X communication. [R-5.1-011] The 3GPP system shall be able to provide means for an application server and the RSU to control the area and the size of the area where the messages are being distributed. [R-5.1-012] The E-UTRA(N) shall be able to support a high density of UEs supporting V2X application. [R-5.1-013] Both the HPLMN and VPLMN operators shall be able to charge for network resource usage when messages are transferred by a UE supporting V2X application. [R-5.1-014] For UE supporting V2X application with limited resources (e.g., battery), the impact on its resources (e.g., battery consumption) due to message transfer should be minimized. [R-5.1-015] The 3GPP network should make available any supported positional accuracy improvement techniques (e.g., DGPS and/or OTDOA) in a resource efficient way to a subscribed UE supporting V2X application. 5.2 Specific Service Requirements 5.2.1 Latency/ Reliability Requirements [R-5.2.1-001] The E-UTRA(N) shall be capable of transferring messages between two UEs supporting V2V/P application, directly or via an RSU, with a maximum latency of 100ms. [R-5.2.1-002] For particular usage (i.e., pre-crash sensing) only, the E-UTRA(N) should be capable of transferring messages between two UEs supporting V2V application with a maximum latency of 20ms. [R-5.2.1-003] The E-UTRA(N) shall be capable of transferring messages between a UE supporting V2I application and an RSU with a maximum latency of 100ms. [R-5.2.1-004] The E-UTRAN shall be capable of transferring messages via 3GPP network entities between a UE and an application server both supporting V2N application with an end-to-end delay no longer than 1000 ms. [R-5.2.1-005] The E-UTRA(N) shall be able to support high reliability without requiring application-layer message retransmissions. 5.2.2 Message Size Requirements [R-5.2.3-001] The E-UTRA(N) shall be capable of transferring periodic broadcast messages between two UEs supporting V2X application with variable message payloads of 50-300 bytes, not including security-related message component. [R-5.2.3-002] The E-UTRA(N) shall be capable of transferring event-triggered messages between two UEs supporting V2X application with variable message payloads which can be up to 1200 bytes, not including security-related message component. NOTE: 3GPP only handles the transport of messages for V2X services/applications based on message characteristics (e.g., latency, message size) and is agnostic to message types. 5.2.3 Frequency Requirements [R-5.2.3-001] The E-UTRA(N) shall be able to support a maximum frequency of 10 messages per second per UE or per RSU. NOTE: It is assumed that V2X application provides messages to 3GPP layer for transport either periodically and/or triggered by certain events. 5.2.4 Range Requirements [R-5.2.4-001] The E-UTRAN shall be capable of supporting a communication range sufficient to give the driver(s) ample response time (e.g. 4 seconds). 5.2.5 Speed Requirements [R-5.2.5-001] The 3GPP system shall be capable of transferring messages between UEs supporting V2V application, while the maximum relative velocity of the UEs is 280 km/h, regardless of whether the UE(s) are served or not served by E-UTRAN supporting V2X communication. [R-5.2.5-002] The 3GPP system shall be capable of transferring messages between UEs supporting V2V and V2P application, respectively, while the UE’s maximum absolute velocity is 160 km/h, regardless of whether the UE(s) are served or not served by E-UTRAN supporting V2X communication. [R-5.2.5-003] The 3GPP system shall be capable of transferring messages between a UE and an RSU both supporting V2I application, while the UE’s maximum absolute velocity is 160 km/h, regardless of whether the UE or the RSU is served or not served by E-UTRAN supporting V2X communication. 5.3 Security Requirements [R.5.3-001] The 3GPP network shall provide a means for the MNO to authorize a UE supporting V2X application to perform V2X communication when served by E-UTRAN supporting V2X communication. [R.5.3-002] The 3GPP network shall provide a means (e.g., pre-authorization) for the MNO to authorize a UE supporting V2X application to perform V2X communication when not served by E-UTRAN supporting V2X communication. [R.5.3-003] The 3GPP network shall provide a means for the MNO to authorize UEs supporting V2X application separately to perform V2N communication. [R.5.3-004] The 3GPP system shall support the anonymity of UE supporting V2X application and the integrity protection of the transmission. [R.5.3-005] The 3GPP system should be able to support UE privacy for V2X communications, by ensuring that a UE cannot be tracked or identified by any other UE beyond a certain short time-period required by the application. [R.5.3-006] Subject to regulatory requirements and/or operator policy, the 3GPP system shall support UE privacy for V2X communication, such that UEs cannot be tracked or identified by the operator or a third party. Annex A: Change history Change history Date TSG# TSG Doc. CR Rev Subject/Comment Old New 2015-11 SA1#72 Skeleton 0.0.0 0.1.0 2016-02 SA1#73 Addition of scope, definition, overview, service requirements content agreed at SA1#73 0.1.0 0.2.0 2016-02 SA#71 SP-160099 Raised to v.1.0.0 for presentation to one-step approval to SA 0.2.0 1.0.0 3GPP