TR 26.985 V0.8.6 (2019-01) Vehicle-to-everything (V2X) Media handling and interaction

《TR 26.985 V0.8.6 (2019-01) Vehicle-to-everything (V2X) Media handling and interaction》由會(huì)員分享，可在線閱讀，更多相關(guān)《TR 26.985 V0.8.6 (2019-01) Vehicle-to-everything (V2X) Media handling and interaction（20頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

3GPP TR 26.985 V0.8.6 (2019-01) Technical Report 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Vehicle-to-everything (V2X); Media handling and interaction (Release 15) 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 Report 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 TR 26.985 V0.8.6 (2019-01) 20 Release 15 Keywords V2X, V2N, V2I, V2V, VaD, RSU, MTSI, MBMS, FLUS, PC5, ADAS 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. 2017, 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 5 Introduction 5 1 Scope 6 2 References 6 3 Definitions, symbols and abbreviations 7 3.1 Definitions 7 3.2 Symbols 8 3.3 Abbreviations 8 4 V2X overview 8 5 Media use cases in V2X 8 6 System architecture 9 6.1 General 9 6.2 System 9 6.3 Terminal 10 6.4 Procedures 11 7 Protocols 16 7.1 General 16 7.2 Uplink 16 7.3 Downlink 16 7.4 Direct link 16 8 Media consideration 16 8.1 General 16 8.2 Video 16 9 Sensor sharing of object information 17 9.1 On-going work 17 9.2 Example objects 18 9.3 Considerations 19 Annex : 20 A.1 Heading levels in an annex 20 Annex : Change history 21 Foreword This Technical Report 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. Introduction With connected car often considered as one of key applications of 5G, 3GPP has been working on the features and required technologies of vehicle-to-everything (V2X), in which coordinated efforts are made by vehicles and networks to realize advanced driver assistance systems (ADAS) or self-driving vehicles. The initial works on V2X focused on the exchange or delivery of short control messages to avoid collision, and did not consider the functionalities required for advanced connected cars. However, the use cases for advanced driving of eV2X, specified in TR 22.886, include various scenarios including media, such as video and sensor data. Although more advanced transmission capabilities are required, media can overcome the limitations of coded messages that might not be able to describe arbitrary situations on the road, and can be a more intuitive source of information for the decision of driver or artificial intelligence, e.g., by providing visual information that cannot be provided by the on-board cameras or sensors of vehicles with limited coverage or accuracy. Strong tolerance to the variance of weather is another advantage of media-based V2X that can exploit the point-to-point transmission or multicasting/broadcasting capability of 3GPP radio access. 1 Scope In the present document, media-related use cases of V2X described in TR 22.886 and their requirements in TS 22.186 are analysed in detail, to clarify the operation of advanced driving using networked visual information. The required procedures for media capture, compression, and transmission, based on the mechanisms for media handling and transportation, such as MTSI, MBMS, and FLUS, are investigated. Operation over the PC5 interface is currently outside of the scope of this document. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. - References are either specific (identified by date of publication, edition number, version number, etc.) or nonspecific. - For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] 3GPPTR21.905: "Vocabulary for 3GPP Specifications". [2] 3GPP TR 22.885: "Study on LTE support for Vehicle to Everything (V2X) services". [3] 3GPP TR 22.886: "Study on enhancement of 3GPP Support for 5G V2X Services". [4] 3GPP TS 22.185: "Service requirements for V2X services". [5] 3GPP TS 22.186: "Enhancement of 3GPP Support for V2X Scenarios". [6] 3GPP TR 23.785: "Study on architecture enhancements for LTE support of V2X services". [7] 3GPP TS 23.285: "Architecture enhancements for V2X services". [8] 3GPP TR 23.786: "Study on architecture enhancements for EPS and 5G System to support advanced V2X services". [9] 3GPP TS 23.468: "Group Communication System Enablers for LTE (GCSE_LTE); Stage 2". [10] 3GPP TR 33.885: "Study on security aspects for LTE support of Vehicle-to-Everything (V2X) services". [11] 3GPP TS 33.185: "Security aspect for LTE support of Vehicle-to-Everything (V2X) services". [12] 3GPP TR 36.885: "Study on LTE-based V2X services". [13] SAE International, "AUTOMATED DRIVING LEVELS OF DRIVING AUTOMATION ARE DEFINED IN NEW SAE INTERNATIONAL STANDARD J3016". [14] P. Gomes, F. Vieira and M. Ferreira, "The See-Through System: From implementation to test-drive," Vehicular Networking Conference (VNC), 2012 IEEE, Seoul, 2012, pp. 40-47. [15] 5G-PPP-White-Paper-on-Automotive-Vertical-Sectors. [16] S4-180312 Clarifications to video-related V2X use cases. [17] 3GPP TS 26.238 “Uplink Streaming” (FLUS). [18] 3GPP TR 26.939 “Guidelines on the Framework for Live Uplink Streaming (FLUS)”. [19] Automotive Edge Computing Consortium (AECC) whitepaper on “General Principle and Vision”, 25th April 2018, available https://aecc.org/wp-content/uploads/2018/02/AECC_White_Paper.pdf. [20] 3GPP TS 26.114: "IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction". [21] 3GPP TS 26.346: "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs ". [22] ETSI TS 102 894-1: "Intelligent Transport Systems (ITS); Users and applications requirements; Part 1: Facility layer structure, functional requirements and specifications". [23] ETSI TS 102 894-2: "Intelligent Transport Systems (ITS); Users and applications requirements; Part 2: Applications and facilities layer common data dictionary". [24] ETSI TS 103 324: "Intelligent Transport Systems (ITS); Cooperative Observation Services (COS)". [25] ETSI TR 103 562: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Analysis of the Collective Perception Service (CPS) ; Informative Report for the Collective Perception Service" [26] EU Project "Sustainable Intelligent Mining Systems (SIMS)", part of EU Research and Innovation Horizon 2020, https://www.simsmining.eu/ [27] Ingemar Johansson, Siddarth Dadhich, Ulf Bodin, and Tomas Jnsson, "Adaptive Video with SCReAM over LTE for Remote-Operated Working Machines", 2nd August 2018, available https://www.hindawi.com/journals/wcmc/2018/3142496/ [28] IETF RFC 8298: "Self-Clocked Rate Adaptation for Multimedia", Dec 2017, https://tools.ietf.org/html/rfc8298 3 Definitions, symbols 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]. The following definitions of V2X are from [2], [3]. 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). V2I Service: A type of V2X Service, where one party is a UE and the other party is an RSU both using V2I application. V2N Service: A type of V2X Service, where one party is a UE and the other party is a serving entity, both using V2N applications and communicating with each other via LTE network entities. V2P Service: A type of V2X Service, where both parties of the communication are UEs using V2P application. V2V Service: A type of V2X Service, where both parties of the communication are UEs using V2V application. V2X Service: A type of communication service that involves a transmitting or receiving UE using V2V application via 3GPP transport. Based on the other party involved in the communication, it can be further divided into V2V Service, V2I Service, V2P Service, and V2N Service. 3.2 Symbols For the purposes of the present document, the following symbols apply: Symbol format (EW) 3.3 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 SAE Society of Automotive Engineers LIDAR Light Detection and Ranging 4 V2X overview 3GPP started a feasibility study on V2X as a message-based mechanism for improved safety and group driving (platooning), defining a variety of use cases including the interaction of vehicles, networks, and pedestrians, and their potential requirements [2]. As new needs for facilitating more advanced applications such as autonomous driving became elevated, the study continued to investigate the aspects of handling higher bit-rate sensor data and media [3]. Basic requirements set from these studies were specified in [4], [5]. From the outcomes of these feasibility studies, further studies on the network architecture that could meet the requirements of V2X followed [6], [7]. Initial consideration of V2X was in the operating environments of LTE but its applications were extended to 5G [8]. In addition to the conventional Uu interface between UE (vehicle) and eNodeB/gNB, PC5, a new interface enabling direct communication between vehicles, were defined, which re-uses the functionalities of group communication system enablers defined for mission-critical applications [9]. Based on the V2X architectures defined, security aspects were studied, and potential vulnerability of new interfaces were investigated [10], [11]. Finally, advanced features of radio access technologies are under study for higher performance [12]. 5 Media use cases in V2X The first five use cases are specified in TR 22.886 [3], and explained further in [16]. 5.1 Support for remote driving In this use case, specified in clause 5.4 of TR 22.886 [3], a vehicle is controlled remotely by either a human operator or cloud computing. NOTE 1: The assumption is that each H.265/ HEVC stream is up to 10 Mbps and outside-vehicle video streams showing the lane situations around a vehicle are delivered to a remote driver. In addition, outside-vehicle audio streams may be delivered to a remote driver for conveying the noises and horn sounds from other vehicles. NOTE 2: At least an inside-vehicle video stream and an inside-vehicle audio stream, whose delay requirements can be more relaxed than those of outside-vehicle video and audio, may be delivered to a remote driver for monitoring the situations. 5.2 Information sharing for high/full automated driving This use case, specified in clause 5.11 of TR 22.886 [3], is interpreted as an automated driving at the level of e.g. SAE Level 4 and Level 5 automation [13]. Each vehicle shares its high resolution perception data (e.g., camera, LIDAR, occupancy grid) and/or detailed planned trajectory with other vehicles, directly or via the network. An RSU may capture high resolution perception data around a corner or an obstacle, or an intersection. Each RSU shares its high resolution perception data with vehicles A, B, and C, via point-to-point transmission or multicast/broadcast. 5.3 Video data sharing for assisted and improved automated driving (VaD) The visual range of the driver is in some road traffic situations obstructed, for instance by trucks driving in front [14], [15]. In this use case specified in clause 5.16 of TR 22.886 [3], video data sent from one vehicle to the other can support drivers in these safety-critical situations. Video data may also be collected and sent through a capable UE-type RSU. 5.4 Teleoperated support (TeSo) Teleoperated Support (TeSo), specified in clause 5.21 of TR 22.886 [3], enables a single human operator to remotely control autonomous vehicles for a short period of time. TeSo enables efficient road construction (control of multiple autonomous vehicles from a single human operator), e.g., snow plowing. 5.5 Video composition In this use case, specified in clause 5.25 of TR 22.886 [3], UEs have a camera and they take a video of the environment, and send this video to a server. The server can be in the cloud or in the near the UE point of attachment (i.e., Mobile Edge Computing (MEC)). The server/MEC will then post-process the videos received and combine the information in order to create a single video of the environment. The videos may also be supplied by RSUs when there are UEs not sufficient for the composition. The UEs location and direction information, allows the server to accurately represent the location, relative speed and distance of vehicles, pedestrians, and any objects in that area. 6 System architecture 6.1 General Many use cases of V2X including uplink and downlink transmission of media can be realized with the LTE-Uu interface and existing media services including MTSI, MBMS, or FLUS, without any architectural changes. There are two modes of operation for V2X communication, i.e., over the PC5 and LTE-Uu interfaces. LTE-Uu provides the conventional point-to-point or point-to-many transport services at high bit-rate or QoS. PC5, compared to the Uu interface, is limited in reachable range but is generally better at localization of the communications, has shorter delays, and is less impacted by coverage issues. 6.2 System Figure 6.2-1 shows a high level view of the non-roaming architecture for V2X system based on the PC5 and LTE-Uu interfaces. Functionalities of the network entities and reference points in this architecture can be found in [7]. Figure 6.2-1: Non-roaming reference architecture for PC5 and LTE-Uu based V2X communication NOTE 1: RSU is not an architectural entity but an implementation option that may be achieved by collocating a V2X application logic/server with some entities of the 3GPP system. NOTE 2: V2X application servers in different domains can communicate with each other for the exchange of V2X messages but the interface between V2X application servers and methods of the message exchange is out of the scope of this document. Figure 6.2-2 shows a high level view of the reference architecture with MBMS for LTE-Uu based V2X communication. The xMB reference point provides functionality overall for any content and supports security framework between content provider and BM-SC. The content in this context can be the information on traffic or road situation. A similar reference architecture using MB2 reference point can be found in [7]. Figure 6.2-2: Reference architecture for MBMS for LTE-Uu based V2X communication via xMB 6.3 Terminal Figure 6.3-1 [7] shows three types of services, V2V, V2P, and V2I, a V2X system may provide. Depending on the use cases, a terminal in V2X may be a vehicle with Universal Integrated Circuit Card (UICC) embedded and capable of directly communicating with the network, a vehicle connected to the network via a smartphone, or a typical smartphone a pedestrian is carrying, which can transmit or receive V2X-related media or data. Figure 6.3-1: Types of V2X (V2V, V2P, and V2I) 6.4 Procedures This clause outlines the strategies to realize V2X use cases with codecs and protocols. 6.4.1 Support for remote driving In this basic use case, media streams including the audio-visual information of scenes in several directions around the vehicle are transmitted in the uplink. It would be essential to maintain the QoS during the operation, e.g., by using MTSI or FLUS that supports IMS. Each stream may be assigned a bit-rate or a resolution that depends on its relative importance in the remote control of vehicle, which may also depend on the roadside situation. For example, streams corresponding to the side or backward directions may be considered more important than the stream for the front when moving a car stopped in the first lane to the roadside. The inside-vehicles video may cover a wide angle or be made up of by stitching images captured by multiple cameras, as they are not used for controlling purposes. In contrast, the outside-vehicle videos would have to be captured as conventional images, to avoid the distortion that may compromise the accuracy of remote driving. 6.4.1.1 Description TS 22.186 [5] contains a use-case around Remote Driving (Clause 5.4 in TR 22.886 [3]). The use-case is subdivided into several sub cases. TR 22.886 lists a human as remote driver or a “cloud” as possible remote driver. In case of a “Cloud” based driver, a remote driving application server is deployed using cloud computing technologies. Here, we focus on the case of a human as a remote driver. Figure 6.4-1 depicts an illustration of the setup. The Remote Driving (RD) application on the UE side collects information from various sensors and also connects to the engine, steering and braking system for command execution (automation system actuators). Note, this is an example list of potential sensors and actuators. Figure 6.4-1: Application flows in Remote Driving (RD) concept On the remote driver side, a Remote Driving (RD) application dispatches the incoming information to appropriate rendering devices, such as display or sound system. The RD is also converting the controller device actions into a protocol, which provides the manoeuvre instruction