Internet-Draft Seok-J. Koh Intended status: Informational Dong-K. Choi Expires: 7 May 2020 Joong-H. Jung Hye-B. Nam Kyungpook National University 4 November 2019 Configurable Car Infotainment Service draft-sjkoh-ccis-01 Abstract As the connected car and autonomous car technologies grows, many car manufacturers are interested in in-vehicle infotainment (IVI) services. In addition, car-sharing services are expected to attract attention in the future automotive industry. The devices and contents in the car are frequently used not only by the car owner but also by others. Automobile manufacturers are currently researching on developing their own IVI service platforms. Contrary to these trends, however, IVI services present a risk that anyone can access the IVI services and lack scalability with other manufacturers. In this document, we introduce the system which provide the basic function that can be commonly used in IVI services growing very rapidly. This system is consisting of master, device and user. This system Users are categorized into different types, and services provided by devices have different levels. These are registered and managed by master. So, users are delivered different services according to user type. In addition, devices can be dynamically registered and deregistered to the master. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 May 2020. Koh, et al. Expires 7 May 2020 [Page 1] Internet-Draft CCIS November 2019 Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Overview of CCIS . . . . . . . . . . . . . . . . . . . . 3 2. CCIS Entities . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. CCIS user . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. CCIS device . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. CCIS master . . . . . . . . . . . . . . . . . . . . . . . 5 3. CCIS Level . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Service flows . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Scenarios of Service Level High . . . . . . . . . . . . . 6 4.2. Scenarios of Service Level Medium . . . . . . . . . . . . 7 4.3. Scenarios of Service Level Low . . . . . . . . . . . . . 8 5. Security consideration . . . . . . . . . . . . . . . . . . . 9 6. Normative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction 1.1. Background With the development of the autonomous car, automobiles are becoming a cultural life space than the original purpose of automobiles. This has led many manufacturers to be interested in the research of in- vehicle infotainment (IVI) services and devices, as illustrated by the examples of Mercedes-Benz, Toyota, BMW, and General Motors. The infotainment is a new compound word combining 'information' and 'entertainment'. Infotainment devices include navigation systems, cameras, speakers, headrest displays, air-conditioners, thermometers and heating seats, and light. Koh, et al. Expires 7 May 2020 [Page 2] Internet-Draft CCIS November 2019 Despite these trends, the current IVI system provides only a manufacturer's own service platform and is not flexible compatible with other manufacturers. It is difficult for a user to add/remove their infotainment device arbitrarily. This leads to inconvenient, like having to unify all their infotainment devices into one manufacturer. Therefore, research on IVI services that provide integrated management for IVI devices is needed. 1.2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.3. Overview of CCIS The Car Configurable Infotainment Services (CCIS) is a service that provides a function of integrated management of in-vehicle infotainment for users. The CCIS consists of CCIS user, CCIS device, and CCIS master. Figure 1 describes the CCIS overview. The CCIS system connects the CCIS master to the CCIS user's device and a variety of CCIS devices within a car to control the CCIS devices. The CCIS users can be classified into 4 types: Car Owner, Temporary Owner, Private Owner, and Public Owner. Different services are available depending on the user type. This is discussed in detail in section 3 of this specification. The CCIS users can access CCIS devices with registration and authentication processes with the CCIS master. Then, the CCIS users can utilize CCIS services through a communication interface with CCIS master, in which a CCIS user may control a CCIS device or enjoy the CCIS content contained in the device. CCIS devices are divided into personal devices such as headrest displays and heated seats and shared devices that can affect other CCIS users. The CCIS master shall provide a user interface for CCIS services and store CCIS device information and CCIS profile, like device status and availability. Koh, et al. Expires 7 May 2020 [Page 3] Internet-Draft CCIS November 2019 +-----------+ +-----------+ | CCIS user |--------+ |CCIS device|--------+ +-----------+ | +-----------+ | | | | | | +---------------+ | +-----------+ | | | | Car Owner | | |CCIS master|---+ | +---------------+ | | +---------------+ | +-----------+ | | |Personal Device| | | | Temp. Owner | | | +-----------+ | | +---------------+ | | +---------------+ |--|-| Authority |-|--| | | | Private Owner | | | | check | | | +---------------+ | | +---------------+ | | +-----------+ | | | Shared Device | | | | Public Owner | | +---------------+ | +---------------+ | | +---------------+ | | | | | | | +--------------------+ +--------------------+ Figure 1: CCIS Overview 2. CCIS Entities 2.1. CCIS user The CCIS user is a user that can utilize and control the CCIS devices within the car with the help of CCIS master. CCIS user is classified into Car Owner, Temporary Owner, Public Client, and Private Client. CCIS user can be registered/removed to CCIS master through initial setup or user registration/removal procedure. CCIS users who are not registered to the CCIS master cannot utilize the CCIS service. In addition, through the authority check of the CCIS master, CCIS users can only utilize CCIS services that meet the authority of each user type. Depending on the user type, it must be restricted to utilize CCIS services such as registration/removal, device control, and contents delivery. 2.2. CCIS device The CCIS device is a device that can be controlled and managed by a CCIS master in a vehicle. This includes not only devices (smart phone, speaker, black box, etc.) but also multimedia contents (music, video, navigation information, etc.). Each CCIS device can be accessed by one or more CCIS users, depending on device characteristics. The CCIS device can be utilized after registering to CCIS master through Car Owner. The CCIS user must control and utilize the CCIS device only through the CCIS master. Koh, et al. Expires 7 May 2020 [Page 4] Internet-Draft CCIS November 2019 2.3. CCIS master The CCIS master is a center device to provide overall management and control functions for CCIS services and CCIS users. The CCIS master has CCIS user registration/removal, CCIS device registration/removal, device control, device monitoring, and contents delivery. The CCIS master connects the CCIS user with the CCIS device and provides an interface to the CCIS user. The CCIS master must store both user and device information. The CCIS master checks the service level that can be accessed by the user based on the information stored when registering the user or device. 3. CCIS Level All services provided by the CCIS master have a service level so that the CCIS master can deliver the different services according to the CCIS user type. Each CCIS service is categorized into Service Level High, Service Level Medium, and Service Level Low. Private Client or Public Client can use low level CCIS and Temporary Owner can additionally use Medium level service. Car Owner can use all services registered in CCIS master. Table 1 shows an example of the service level configurations, in which each CCIS service is classified as three levels (High, Medium, Low), by considering the service features (Mission-critical or not) and the impact on overall CCIS system. +-----------------------------------------+---------------------+ | | service level | | CCIS services |------+--------+-----| | | high | medium | low | +-----------------------------------------+------+--------+-----+ | system settings | V | | | +-----------------------------------------+------+--------+-----+ | device registration and deregistration | V | | | +-----------------------------------------+------+--------+-----+ | authority check | | V | | +-----------------------------------------+------+--------+-----+ | client registration and deregistration | | V | | +-----------------------------------------+------+--------+-----+ | usage of shared service | | V | | +-----------------------------------------+------+--------+-----+ | usage of high-level personal service | V | | | +-----------------------------------------+------+--------+-----+ | usage of medium-level personal service | | V | | +-----------------------------------------+------+--------+-----+ | usage of low-level personal service | | | V | +------------------------------------------------+--------+-----+ Table 1: CCIS Level Koh, et al. Expires 7 May 2020 [Page 5] Internet-Draft CCIS November 2019 4. Service flows 4.1. Scenarios of Service Level High In this clause, we take a look at the service flow of the CCIS device registration. The CCIS device must be registered with the CCIS master to provide services to the CCIS user, and Car Owner only process the device registration because device registration service is High Level Service. Figure 2 shows the service flow of CCIS device registration. The CCIS master periodically broadcasts its general information to the prospective devices. Then, a CCIS device transmits a notification message to the CCIS master and waits for a registration request. The CCIS master now informs Car Owner of the discovery of a CCIS device. With a Device Registration Authentication message from Car Owner, the CCIS master sends a registration request message to CCIS device. In response to the registration request message, the CCIS device sends its own profile information, such as identifier, a list of functional interaction it can provide, and a level of authority for the functional interaction. Then, the CCIS master stores the information and informs the registration result to Car Owner. Koh, et al. Expires 7 May 2020 [Page 6] Internet-Draft CCIS November 2019 +---------------+ +---------------+ +---------------+ | Car Owner | | CCIS master | | CCIS device | +---------------+ +---------------+ +---------------+ | | | | | Broadcast Master | | | Information | | |.......................>| | | Device Identity | | | Notification | | |<-----------------------| | Device Discovery | | | Notification | | |<----------------------| | | Device Registration | | | Authentication | | |---------------------->| | | | Device Registration | | | Request | | |----------------------->| | | Device Registration | | | Response | | |<-----------------------| | Device Registration | | | Confirmation | | |<----------------------| | | | | Figure 2: Registration of CCIS device 4.2. Scenarios of Service Level Medium In this clause, we take a look at the service flow of the shared device control. A user who wants Device Control MUST first occupy the CCIS device. Shared device control is a medium level service. So, private or public clients MUST obtain the permission of the car owner or temporary owner to occupy and control the shared device. Figure 3 shows the service flow of the shared device control by Private Client or Public Client, in which the authority check operations are added between master and owner to obtain a permission for device control. After occupation, the CCIS user can control the CCIS device via CCIS master. This procedure is discussed in the clause of scenarios of service level low. Koh, et al. Expires 7 May 2020 [Page 7] Internet-Draft CCIS November 2019 +-----------+ +--------------+ +------+ +------+ |Car Owner/ | |Private Client| | CCIS | | CCIS | |Temp. Owner| |/Public Client| |master| |device| +-----------+ +--------------+ +------+ +------+ | | | | | | Device Occupation | | | | Request | | | |------------------>| | | | | | | Authority Check Request | | |<--------------------------------------| | | Authority_Check_Response | | |-------------------------------------->| | | Authority_Check_Confirmation | | |<--------------------------------------| | | | | | | | Device Occupation | | | | Response | | | |<------------------| | | | Device Control | | | | Request | | | |------------------>| | | | |Device Control| | | | Transmission | | | |------------->| | | |Device Control| | | | Confirmation | | | |<-------------| | | Device Control | | | | Response | | | |<------------------| | | | | | Figure 3: Usage of shared service 4.3. Scenarios of Service Level Low All CCIS users can control the low level personal CCIS devices without the permission of owner. Figure 4 shows the service flow of Low Level device control service. A user who want to control a CCIS device MUST requests the occupation of a specific CCIS device to the CCIS master. Then, the CCIS master MUST check the user of the availability and status of the concerned device and respond the result. If the occupation request is successfully performed, the user can send a control request message to CCIS master. Based on this request, the CCIS master performs the device control operation and sends a feed back to the user. Koh, et al. Expires 7 May 2020 [Page 8] Internet-Draft CCIS November 2019 +-------------+ +--------+ +--------+ | Car Owner/ | | CCIS | | CCIS | | Temp. Owner | | master | | device | +-------------+ +--------+ +--------+ | | | | Device Occupation Request | | |-------------------------->| | | Device Occupation Response| | |<--------------------------| | | | | | Device Control Request | | |-------------------------->| | | | Device Control | | | Transmission | | |----------------------->| | | Device Control | | | Confirmation | | |<-----------------------| | Device Control Response | | |<--------------------------| | | | | Figure 4: Usage of low-level personal service 5. Security consideration TBD 6. Normative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Koh, et al. Expires 7 May 2020 [Page 9] Internet-Draft CCIS November 2019 Authors' Addresses Seok-Joo Koh Kyungpook National University Daehakro 80, Bukgu, Daegu, South Korea 41566 Phone: +82 53 950 7356 Email: sjkoh@knu.ac.kr Dong-Kyu Choi Kyungpook National University Daehakro 80, Bukgu, Daegu, South Korea 41566 Email: supergint@gmail.com Joong-Hwa Jung Kyungpook National University Daehakro 80, Bukgu, Daegu, South Korea 41566 Email: godopu16@gmail.com Hye-Been Nam Kyungpook National University Daehakro 80, Bukgu, Daegu, South Korea 41566 Email: hbnam129@gmail.com Koh, et al. Expires 7 May 2020 [Page 10]