Access control method and device, and communication system

Abstract

To provide an access control method and apparatus, an access method, a program, and a communication system, which are used for short-range communication.SOLUTION: A method includes: determining that a status of a first device is a first status; and sending first indication information that is used to indicate whether access of at least one second device to the first device is allowed. A system broadcast message carrying system status information is sent, and after a non-vehicle-mounted device receives the system broadcast message, the non-vehicle-mounted device determines, on the basis of the system status information, whether to initiate a random access request. This avoids impact caused by random access request initiation performed by the non-vehicle-mounted device in this phase, on access performed by a control domain cockpit (CDC) and a vehicle-mounted device.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present application relates to the field of communications, and in particular to a method and apparatus for differentiated access control and a communication device, particularly used for short-range communications, e.g., cockpit domain communications. [Background technology]

[0002] Short-range communication technologies such as Bluetooth and Wi-Fi play a very important role in people's daily lives. As vehicles become more widely used and widespread, the functions of short-range communication technologies become more prominent. With the development of science and technology, advanced driving assistance systems (ADAS) and automated driving systems (ADS) for vehicles are constantly evolving. In the future, vehicle operation will likely be performed by machines, eliminating the need for people to use their hands and feet to drive. In addition to being a user's transportation device, a vehicle is also one of the living spaces in daily life. By using smart cockpit technology, a wealth of functions, such as rich entertainment activities, audio and video playback, and an office environment, can be provided to people in the vehicle. As a result, people can work in the vehicle, enjoy customized audio and video entertainment services, and have a customized driving experience.

[0003] Currently, a smart cockpit mainly includes a cockpit domain controller (CDC), in-vehicle devices, and non-in-vehicle devices. The CDC is mainly connected to in-vehicle devices via wires, and the CDC is mainly connected to non-in-vehicle devices via wireless. However, because the CDC is connected to the in-vehicle devices via wires, this method requires a large number of cables and is therefore expensive. Due to the limited space inside the vehicle, wiring becomes more difficult as the number of in-vehicle devices increases. The cable wiring and high cost are constraints on the development of smart cockpit technology. Therefore, wirelessly connecting the CDC to in-vehicle or non-in-vehicle devices is an urgent problem to be solved. Summary of the Invention [Means for solving the problem]

[0004] An embodiment of the present application provides an access control method applied to the field of universal transmission. Information elements carrying system status information or access indication information are transmitted to indicate the current system state, so that after receiving the aforementioned information, a non-vehicle device determines whether to initiate a random access request. The access of the non-vehicle device is restricted in a specific phase. This avoids the impact caused by the initiation of a random access request performed by a non-vehicle device in this phase on the CDC's checking of the status of the vehicle device and the vehicle device's access. This also ensures that the vehicle device can run normally and some basic services can be performed normally.

[0005] According to a first aspect, the present application provides an access control method. The method includes: determining that a status of a first device is a first status; and transmitting first indication information, the first indication information being used to indicate whether at least one second device is permitted to access the first device. Optionally, the first indication information is carried in a system message or transmitted by broadcast. The first indication information may be a master information block (MIB), a system information block (SIB), or a broadcast frame. The MIB may be carried on a physical broadcast channel (PBCH). The SIB is typically included in radio resource control (RRC) signaling. Optionally, the first indication information is transmitted by broadcast.

[0006] In a possible implementation, the first status includes at least one of a system readiness state and an in-vehicle device access state, and the first indication information is used to indicate that access for at least one second device is not permitted, or the first status includes at least one of a system execution state and an access permission state, and the first indication information is used to indicate that access for the second device is permitted. The system readiness state and / or the in-vehicle device access state may be used to indicate that the in-vehicle device is accessing the control domain cockpit CDC or that the in-vehicle device is performing a self-check, and therefore, the non-in-vehicle device may choose not to access the control domain cockpit CDC based on these types of system states. The system execution state and / or the access permission state may be used to indicate that the in-vehicle device has accessed the control domain cockpit CDC. In this case, the non-in-vehicle device may be permitted to access the control domain cockpit CDC.

[0007] In a possible implementation, the first indication information is used to indicate whether access of at least one third device is permitted.

[0008] In one possible implementation, the first indication information includes device type information, and the device type of the at least one second device belongs to the at least one device type indicated by the device type information. Further, the second device determines whether to access the first device based on the device type information.

[0009] In a possible implementation, the first indication information further includes access indication information, which is used to indicate whether access to the first device is permitted.

[0010] In a possible implementation, the first indication information includes priority information, and the priority of the at least one second device belongs to at least one priority indicated by the priority information.

[0011] In one possible implementation, the first indication information further includes access indication information, and the access indication information is used to indicate whether access to the first device is permitted. Furthermore, the second device determines whether to access the first device based on the priority information and the access indication information.

[0012] In a possible implementation, the first indication information includes first time information, and the first time information is used to indicate that access of at least one second device to the first device is not permitted within a first time range.

[0013] In a possible implementation, the first time range is a time domain offset relative to a first reference frame or a time domain offset relative to a first signaling. The first reference frame may be a first system frame number pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be a first system frame number defined in a protocol. The first signaling may be specific signaling pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be specific signaling defined in a protocol. For example, the first signaling may be RRC signaling. One or more time domain offsets may be present.

[0014] In a possible implementation, the first indication information includes resource indication information, and the resource indication information indicates resources to be used for at least one third device, or the resources indicated by the resource indication information are not used for at least one second device.

[0015] In a possible implementation, there is a correspondence between the resources indicated by the resource indication information and the device type and / or priority of the at least one third device.

[0016] In a possible implementation, the first indication information includes a Boolean variable or an enumeration variable. Of course, any other equivalent type of variable may alternatively be included.

[0017] In a possible implementation, the device type includes at least one of an in-vehicle device and a non-in-vehicle device.

[0018] According to a second aspect, the present application provides an access method. The method includes receiving first indication information from a first device and determining, based on the first indication information, whether a second device is permitted to access the first device. Optionally, the first indication information may be carried in a system message or transmitted by broadcast. For example, the system message may be a system broadcast message. The first indication information may be a MIB, a SIB, or a broadcast frame. The MIB may be carried on a PBCH. The SIB is typically included in RRC signaling.

[0019] In a possible implementation, the first indication information is used to indicate whether access of at least one third device is permitted.

[0020] In one possible implementation, the first indication information includes device type information, and the device type of the at least one second device belongs to the at least one device type indicated by the device type information. Further, the second device determines whether to access the first device based on the device type information.

[0021] In a possible implementation, the first indication information further includes access indication information, which is used to indicate whether access to the first device is permitted.

[0022] In a possible implementation, the first indication information includes priority information, and the priority of the at least one second device belongs to at least one priority indicated by the priority information.

[0023] In one possible implementation, the first indication information further includes access indication information, and the access indication information is used to indicate whether access to the first device is permitted. Furthermore, the second device determines whether to access the first device based on the priority information and the access indication information.

[0024] In a possible implementation, the first indication information includes first time information, and the first time information is used to indicate that access of at least one second device to the first device is not permitted within a first time range.

[0025] In a possible implementation, the first time range is a time domain offset relative to a first reference frame or a time domain offset relative to a first signaling. The first reference frame may be a first system frame number pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be a first system frame number defined in a protocol. The first signaling may be specific signaling pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be specific signaling defined in a protocol. For example, the first signaling may be RRC signaling. One or more time domain offsets may be present.

[0026] In a possible implementation, the first indication information includes resource indication information, and the resource indication information indicates resources to be used for at least one third device, or the resources indicated by the resource indication information are not used for at least one second device.

[0027] In a possible implementation, there is a correspondence between the resources indicated by the resource indication information and the device type and / or priority of the at least one third device.

[0028] In a possible implementation, the first indication information includes a Boolean variable or an enumeration variable. Of course, any other equivalent type of variable may alternatively be included.

[0029] In a possible implementation, the CDC is also referred to as a control domain cockpit or a control domain cockpit CDC, the first device is a control domain cockpit CDC, the third device is an in-vehicle device, and the second device is a non-in-vehicle device.

[0030] In a possible implementation, the second device is a mobile phone.

[0031] According to a third aspect, the present application provides an access control device. The access control device may be a first device or a chip or integrated circuit within the first device. For example, the access control device may be a control domain cockpit CDC, or the access control device may be a chip or integrated circuit within the control domain cockpit CDC. Indeed, the access control device may alternatively be a mobile phone, a tablet computer, a desktop computer, a laptop computer, a handheld computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a personal digital assistant (PDA), an augmented reality (AR) device, a virtual reality (VR) device, an artificial intelligence (AI) device, a wearable device, an in-vehicle device, a smart home device, and / or a smart city device. The specific type of the first device is not limited in this embodiment of the present application. The apparatus includes: a processing unit configured to determine that a status of the first device is a first status; and a transmitting unit configured to transmit first indication information, the first indication information being used to indicate whether access of at least one second device to the first device is permitted. Optionally, the first indication information is carried in a system message or transmitted by broadcast. The first indication information may be a MIB, a SIB, or a broadcast frame. The MIB may be carried on a PBCH. The SIB is typically included in RRC signaling. Optionally, the first indication information is transmitted by broadcast.

[0032] In a possible implementation, the first status includes at least one of a system readiness state and an in-vehicle device access state, and the first indication information is used to indicate that access for at least one second device is not permitted, or the first status includes at least one of a system execution state and an access permission state, and the first indication information is used to indicate that access for the second device is permitted. The system readiness state and / or the in-vehicle device access state may be used to indicate that the in-vehicle device is accessing the control domain cockpit CDC or that the in-vehicle device is performing a self-check, and therefore, the non-in-vehicle device may choose not to access the control domain cockpit CDC based on these types of system states. The system execution state and / or the access permission state may be used to indicate that the in-vehicle device has accessed the control domain cockpit CDC. In this case, the non-in-vehicle device may be permitted to access the control domain cockpit CDC.

[0033] In a possible implementation, the first indication information is used to indicate whether access of at least one third device is permitted.

[0034] In one possible implementation, the first indication information includes device type information, and the device type of the at least one second device belongs to the at least one device type indicated by the device type information. Further, the second device determines whether to access the first device based on the device type information.

[0035] In a possible implementation, the first indication information further includes access indication information, which is used to indicate whether access to the first device is permitted.

[0036] In a possible implementation, the first indication information includes priority information, and the priority of the at least one second device belongs to at least one priority indicated by the priority information.

[0037] In one possible implementation, the first indication information further includes access indication information, and the access indication information is used to indicate whether access to the first device is permitted. Furthermore, the second device determines whether to access the first device based on the priority information and the access indication information.

[0038] In a possible implementation, the first indication information includes first time information, and the first time information is used to indicate that access of at least one second device to the first device is not permitted within a first time range.

[0039] In a possible implementation, the first time range is a time domain offset relative to a first reference frame or a time domain offset relative to a first signaling. The first reference frame may be a first system frame number pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be a first system frame number defined in a protocol. The first signaling may be specific signaling pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be specific signaling defined in a protocol. For example, the first signaling may be RRC signaling. One or more time domain offsets may be present.

[0040] In a possible implementation, the first indication information includes resource indication information, and the resource indication information indicates resources to be used for at least one third device, or the resources indicated by the resource indication information are not used for at least one second device.

[0041] In a possible implementation, there is a correspondence between the resources indicated by the resource indication information and the device type and / or priority of the at least one third device.

[0042] In a possible implementation, the first indication information includes a Boolean variable or an enumeration variable. Of course, any other equivalent type of variable may alternatively be included.

[0043] In a possible implementation, the device type includes at least one of an in-vehicle device and a non-in-vehicle device.

[0044] According to a fourth aspect, the present application provides an access device. The access device may be a second device or a chip or integrated circuit within the second device. For example, the access device may be a chip or integrated circuit within an in-vehicle device or a non-in-vehicle device. Indeed, the access device may alternatively be a mobile phone, a tablet computer, a desktop computer, a laptop computer, a handheld computer, a notebook computer, a UMPC, a netbook, a cellular phone, a PDA, an AR device, a VR device, an AI device, a wearable device, an in-vehicle device, a smart home device, and / or a smart city device. The specific type of the first device is not limited in this embodiment of the application. The device includes a receiving unit and a processing unit. The receiving unit is configured to receive first indication information from the first device. The processing unit is configured to determine whether the second device is authorized to access the first device based on the first indication information. Optionally, the first indication information may be carried in a system message or transmitted by broadcast. For example, the system message may be a system broadcast message. The first indication information may be a MIB, a SIB, or a broadcast frame. The MIB may be carried on a PBCH. The SIB is typically included in RRC signaling.

[0045] In a possible implementation, the first indication information is used to indicate whether access of at least one third device is permitted.

[0046] In one possible implementation, the first indication information includes device type information, and the device type of the at least one second device belongs to the at least one device type indicated by the device type information. Further, the second device determines whether to access the first device based on the device type information.

[0047] In a possible implementation, the first indication information further includes access indication information, which is used to indicate whether access to the first device is permitted.

[0048] In a possible implementation, the first indication information includes priority information, and the priority of the at least one second device belongs to at least one priority indicated by the priority information.

[0049] In one possible implementation, the first indication information further includes access indication information, and the access indication information is used to indicate whether access to the first device is permitted. Furthermore, the second device determines whether to access the first device based on the priority information and the access indication information.

[0050] In a possible implementation, the first indication information includes first time information, and the first time information is used to indicate that access of at least one second device to the first device is not permitted within a first time range.

[0051] In a possible implementation, the first time range is a time domain offset relative to a first reference frame or a time domain offset relative to a first signaling. The first reference frame may be a first system frame number pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be a first system frame number defined in a protocol. The first signaling may be specific signaling pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be specific signaling defined in a protocol. For example, the first signaling may be RRC signaling. One or more time domain offsets may be present.

[0052] In a possible implementation, the first indication information includes resource indication information, and the resource indication information indicates resources to be used for at least one third device, or the resources indicated by the resource indication information are not used for at least one second device.

[0053] In a possible implementation, there is a correspondence between the resources indicated by the resource indication information and the device type and / or priority of the at least one third device.

[0054] In a possible implementation, the first indication information includes a Boolean variable or an enumeration variable. Of course, any other equivalent type of variable may alternatively be included.

[0055] In a possible implementation, the first device is a control domain cockpit CDC, the third device is an in-vehicle device, and the second device is a non-in-vehicle device.

[0056] In a possible implementation, the second device is a mobile phone.

[0057] According to a fifth aspect, the present application provides a computer storage medium, the computer storage medium including computer instructions that, when executed by at least one processor, perform the methods of the first and second aspects.

[0058] According to a sixth aspect, the present application provides a computer program product, the computer program product including program code that, when executed by a processor in an electronic device, performs the methods of the first and second aspects.

[0059] According to a seventh aspect, the present application provides a communication system, the system including an access control device according to any implementation of the third aspect.

[0060] Possible implementations further include an access device according to any implementation of the fourth aspect.

[0061] The present application provides an access control method and apparatus, as well as a communication system. Information elements carrying system status information, time thresholds, and / or access indication information are transmitted to indicate the current system state, so that after the non-vehicle device receives the new information, the non-vehicle device determines whether to initiate a random access request. This avoids the impact of the initiation of a random access request performed by the non-vehicle device on the CDC's check of the in-vehicle device's status and the in-vehicle device's access, which would be caused by this phase. This also ensures that the in-vehicle device can operate normally and that some basic services can be performed normally. [Brief explanation of the drawings]

[0062] [Figure 1] 1 is a schematic diagram of an application scenario according to an embodiment of the present application; [Figure 2] FIG. 2 is a diagram of information exchange between a CDC, an in-vehicle device, and a non-in-vehicle device according to an embodiment of the present application. [Figure 3] FIG. 10 is a diagram of another type of information exchange between a CDC, an in-vehicle device, and a non-in-vehicle device according to an embodiment of the present application. [Figure 4] FIG. 10 is a diagram of yet another type of information exchange between a CDC, an in-vehicle device, and a non-in-vehicle device according to an embodiment of the present application. [Figure 5] 1 is a flow chart of an access control method according to an embodiment of the present application; [Figure 6] 4 is a flow chart of another access control method according to an embodiment of the present application; [Figure 7] 1 is a schematic diagram of an access control device according to an embodiment of the present application; [Figure 8] 1 is a schematic diagram of an access device according to an embodiment of the present application; [Figure 9] 1 is a schematic diagram of a communication system according to an embodiment of the present application; DETAILED DESCRIPTION OF THE INVENTION

[0063] The following describes the technical solutions of the embodiments of the present application with reference to the accompanying drawings of the embodiments of the present application.

[0064] For ease of explanation, a smart cockpit scenario applied to a vehicle is used as an example to explain the present application. However, the present application is not limited to the vehicle scenario. The solution of the present application may also be used for short-range communication in other scenarios. FIG. 1 is a schematic diagram of an application scenario according to an embodiment of the present application. As shown in FIG. 1, the scenario mainly exists in a smart cockpit environment in a vehicle, which may include a CDC, an in-vehicle device, and a non-in-vehicle device. The in-vehicle device and the non-in-vehicle device are two types of nodes with different attributes. The in-vehicle device may include, but is not limited to, any electronic device in a vehicle, such as an in-vehicle microphone, an in-vehicle speaker, and an in-vehicle screen. Typically, the in-vehicle device is integrated by the vehicle / car manufacturer. Since the integration of the in-vehicle device and the CDC is usually performed by a single vehicle manufacturer, the connection relationship between the in-vehicle device and the CDC is fixed. The fixed connection relationship may be, for example, a communication relationship with a fixed topology. Indeed, the fixed connection relationship between the in-vehicle device and the CDC may be a wired connection or a wireless connection. The non-vehicle devices may include, but are not limited to, any portable electronic device that does not belong to a vehicle, such as a mobile phone, a headset, a wearable device, a tablet computer, a notebook computer, a digital camera, a personal digital assistant (PDA), or a laptop computer. The CDC is connected to the vehicle devices and non-vehicle devices by wire or wirelessly to control or manage the vehicle devices and non-vehicle devices and provide various functions for the smart cockpit environment.

[0065] It will be understood that a vehicle is a ground-based means of transportation that moves on wheels, including, but not limited to, a car, a scooter, a truck, a bus, etc. A CDC is connected to and controls an infotainment product installed in the vehicle. Functionally, a CDC allows a person to control the in-vehicle infotainment equipment and related devices, and may also be used to communicate information between the vehicle and the external environment. It will be understood that a CDC is typically referred to as a control domain cockpit or a control domain cockpit CDC. As used in this application, the terms "CDC," "control domain cockpit CDC," and "control domain cockpit" all have the same meaning.

[0066] In the case of wireless connections, the control domain cockpit CDC is responsible for the overall management and coordination of radio resources and needs to allocate various types of devices for data transmission. Because the in-vehicle device and the control domain cockpit CDC are usually integrated by one vehicle manufacturer, the relevant information of the control domain cockpit CDC may be pre-configured in the in-vehicle device, and the relevant information of the in-vehicle device may be pre-configured in the control domain cockpit CDC. For example, the in-vehicle device has vehicle properties, so the in-vehicle device can quickly perform authentication and access. However, the existence of non-vehicle devices is uncertain, and there is little pre-configured relevant information between the non-vehicle device and the control domain cockpit CDC. When a non-vehicle device connects to the control domain cockpit CDC, procedures such as discovery, association, and security authentication are usually required for successful connection and communication. Therefore, when the in-vehicle device and the cockpit CDC are powered on, how to prioritize the status of the in-vehicle device and establish a connection with the control domain cockpit CDC is a problem that needs to be solved. Normally, when powered on, the control domain cockpit CDC sends a system broadcast message so that all in-vehicle or non-in-vehicle devices can initiate a connection. However, in this case, the control domain cockpit CDC should check or know the status of the in-vehicle devices first and establish a connection with them. Any interruption of this process caused by the access of a non-in-vehicle device is not anticipated by the control domain cockpit CDC.

[0067] Therefore, in this application, the status of the control domain cockpit CDC is determined, and then the status is carried in an information element of a system broadcast message and transmitted to the non-vehicle device by broadcast, so that the non-vehicle device determines whether to perform access based on the status of the control domain cockpit CDC. In this way, it is ensured that the access of the in-vehicle device to the control domain cockpit CDC is not affected by the access of the non-vehicle device. Therefore, it is ensured that the in-vehicle device runs normally and performs basic service functions.

[0068] It will be understood that "XX information" and "XX message" in this application have the same meaning.

[0069] The following describes in detail the technical solutions of the embodiments of the present application with reference to the accompanying drawings of the embodiments of the present application.

[0070] FIG. 2 is a diagram of information exchange between a control domain cockpit CDC, an on-board device, and a non-on-board device according to an embodiment of the present application.

[0071] The present application relates to a communication system, the system including a master node and a slave node.

[0072] Master nodes and slave nodes are two types of nodes distinguished by their logical functions. The master node manages the slave nodes. The master node can schedule resources and is responsible for scheduling time-frequency resources for the slave nodes. The slave nodes communicate with the master node using the time-frequency resources scheduled by the master node. The master node may be an access control device, for example, a control domain cockpit (CDC), or another device with access control functionality. The slave node may be an access device, for example, an on-board device or a non-on-board device.

[0073] Those skilled in the art will know that the technical solution of the present application can be applied to any kind of first device, second device, and third device to which the communication method provided in the present application can be applied, and the second device and the third device are different kinds of devices that can communicate with the first device.

[0074] The present application may be applied to the smart cockpit environment shown in FIG. 1 , as well as to a smart home environment, a smart office environment, or any other environment where a similar device relationship exists. For example, the devices in the environment may be mobile phones, tablet computers, desktop computers, laptop computers, handheld computers, notebook computers, UMPCs, netbooks, cellular phones, PDAs, AR devices, VR devices, AI devices, wearable devices, in-vehicle devices, smart home devices, and / or smart city devices. The specific types of the first device, second device, and third device are not limited in the embodiments of the present application.

[0075] It should be noted that in the following embodiments of the present application, the interactions between the first device, the second device, and the third device are mainly described by using the interactions between the control domain cockpit CDC, the on-board device, and the non-on-board device as an example. However, in the present application, the first device is not limited to the control domain cockpit CDC, the second device is not limited to the non-on-board device, and the third device is not limited to the on-board device. It will be understood that in the following embodiments, the control domain cockpit CDC may be replaced by the first device, the on-board device may be replaced by the third device, and the non-on-board device may be replaced by the second device.

[0076] It can be seen from FIG. 2 that normally, after the vehicle is started, the control domain cockpit CDC and on-board devices are powered on and started up.

[0077] S201. Send a first indication message.

[0078] The control domain cockpit CDC sends a first indication message, and as a result, the in-vehicle device or the non-in-vehicle device receives the first indication message and performs a corresponding operation.

[0079] Optionally, the first indication message may be carried in a system message (system information) or may be transmitted by broadcast. For example, the system message may be a system broadcast message. In the following description of the present application, the system broadcast message is used as an example. To some extent, the first indication message may be considered as a system broadcast message. The system broadcast message may be a MIB, a SIB, or a broadcast frame. The MIB may be carried on the PBCH. The SIB is usually carried on RRC signaling. It should be noted that in all embodiments of the present application, there is no restriction that the first indication information is carried only in a system message or transmitted by broadcast, and the first indication information may be transmitted by using another type of signaling.

[0080] Generally, frames at the media access control (MAC) layer are classified into management frames and data frames. Data frames are used to carry service data exchanged between the master node and the slave node. Before the master node and the slave node can communicate with each other, a communication link between the master node and the slave node must first be established so that corresponding operations, such as security authentication and resource allocation, can be performed on the communication link. Management frames are primarily used by the master node to manage the slave nodes, including, for example, establishing and releasing connections between the master node and the slave node, performing security authentication, allocating communication resources, and enabling hibernation and wake-up. It will be understood that when the above-mentioned management functions are implemented, messages sent by the slave nodes to the master node also need to be carried within management frames.

[0081] From the perspective of a receiving end of a MAC frame, the MAC frame may be classified into a broadcast frame, a multicast frame, and a unicast frame. A unicast frame is a MAC frame transmitted to a single receiving end, a multicast frame is a MAC frame transmitted to a group of receiving ends, and a broadcast frame is a MAC frame transmitted to all receiving ends. Indeed, it will be understood that the method of transmitting the first indication message is not limited in this application, and the first indication message may be transmitted by broadcast, multicast, unicast, or any other equivalent method.

[0082] In some embodiments, before the control domain cockpit CDC sends the system broadcast message, the control domain cockpit CDC may further determine the system status and then allocate corresponding resources for the in-vehicle devices or the non-in-vehicle devices. The first indication message carries indication information, which may be the allocated resources for the in-vehicle devices or the non-in-vehicle devices, and is information used to indicate whether the in-vehicle devices or the non-in-vehicle devices are allowed to access the control domain cockpit CDC.

[0083] In some examples, the indication information may be represented by indicating whether an in-vehicle device or a non-in-vehicle device is authorized to access the control domain cockpit CDC. For example, a first indication message sent to in-vehicle device A carries information representing "access to the control domain cockpit CDC is authorized," or a first indication message sent to non-in-vehicle device B carries information representing "access to the control domain cockpit CDC is not authorized." The information may be represented by an information element or several bits. As another example, the indication information may be system status indication information. After receiving the system status indication information, the in-vehicle device or the non-in-vehicle device may determine whether access to the control domain cockpit CDC is authorized based on the system status.

[0084] For example, when the control domain cockpit CDC is powered on, the control domain cockpit CDC may determine the system status of the system currently running on the control domain cockpit CDC and then generate a first indication message. The first indication message may carry system status indication information. The system status indication information may be an element used for status indication that is used to indicate the system status of the system running on the control domain cockpit CDC. In an example, the system status indication information may be a Boolean variable. For example, different states of a bit may represent different indications. In another example, the system status indication information may alternatively be an enumeration type. Certainly, those skilled in the art should know that the system status indication information may alternatively be any other equivalent data type. This is not limited in this specification of the present application.

[0085] Indeed, in some other examples, the indication information may alternatively be expressed as a resource, for example, a time domain resource, a frequency domain resource, a code domain resource, a time-frequency resource, or any other equivalent resource. This is not limited in this specification of the present application. When the corresponding resource is allocated to an in-vehicle device or a non-in-vehicle device, it means that the in-vehicle device or the non-in-vehicle device is authorized to access the control domain cockpit CDC. It will be understood that the allocated corresponding resource may be used as a response resource of the in-vehicle device or the non-in-vehicle device, and thus the in-vehicle device or the non-in-vehicle device transmits response information on the allocated resource.

[0086] For example, when allocating corresponding response resources for devices to perform access, the control domain cockpit CDC may determine the corresponding response resources for each device to perform access. The response resources may be specific determined time-frequency resources. To ensure that the corresponding devices can transmit response information to the control domain cockpit CDC on the determined time-frequency resources, the corresponding time-frequency resources are allocated to each device. The response information may indicate the device status of the accessing device. Thus, the first indication message may further carry a correspondence between the response resources and the accessing device. In an example, the correspondence between the response resources and the accessing device may be explicit. For example, the correspondence between the response resources and the accessing device is directly carried in the system broadcast message. Indeed, in another example, the correspondence between the response resources and the accessing device may be implicit. For example, the accessing device may obtain the response resources of the accessing device based on a preconfigured identifier (e.g., ID), the time-frequency resources indicated in the system broadcast message, and a pre-set rule. In other words, the access device obtains a preconfigured identifier (e.g., ID), the time-frequency resources indicated in the system broadcast message, and the response resources satisfy a preconfigured rule or mapping relationship. The preconfigured rule may be pre-agreed in a protocol, and / or the preconfigured identifier may be configured before the accessing device is delivered from the factory, or may be configured by the control domain cockpit CDC for the accessing device the last time the accessing device connects to the control device cockpit CDC. Indeed, the configured response resources may alternatively be pre-negotiated by the control domain cockpit CDC and the accessing device, and the control domain cockpit CDC does not use the system broadcast message to carry information about the response message.The corresponding accessing device may directly indicate the device status of the device accessing the control domain cockpit CDC on the corresponding time-frequency resource based on the negotiated response message.

[0087] In some other embodiments, the control domain cockpit CDC may further group the terminal devices to which access should be performed. It will be understood that the terminal devices to which access should be performed may be in-vehicle devices or non-in-vehicle devices. For example, the devices may be grouped based on the device location or the device type of the device. Typically, in-vehicle devices and non-in-vehicle devices in the same location are not classified into the same group. In other words, the terminal devices in the same group are all in-vehicle devices, or non-in-vehicle devices, or devices of the same pre-defined type. Optionally, each group has a corresponding multicast address. It will be understood that the grouping may be performed according to any criteria. This is not limited in this specification of the present application.

[0088] The control domain cockpit CDC groups terminal devices having the same characteristics into groups. In-vehicle devices are used as an example. Speakers and microphones in the rear row in the smart cockpit environment may be classified into one group, speakers and microphones in the front row in the smart cockpit environment may be classified into another group, and so on. As another example, speakers at all positions in the smart cockpit environment may be classified into one group, microphones at all positions may be classified into one group, and so on. The control domain cockpit CDC then allocates response resources corresponding to each group of devices. The allocated response resources are used by all terminal devices in the group. It will be understood that, with respect to the corresponding resources allocated to each group, terminal devices in the group may further determine their own response resources from the response resources allocated to the group according to specific rules. Similarly, a similar grouping manner may be implemented for non-in-vehicle devices.

[0089] In another example, the group may be in the form of an array. For example, a speaker or a microphone may be in the array. Typically, the physical locations of multiple terminal devices in the array are close, and there is a central node that manages the terminal devices in the array. For the array, one response resource may be allocated to one array so that the array can feedback the status of the devices in the array on the allocated response resource.

[0090] In an example, after the in-vehicle device is powered on, a self-check of the in-vehicle device may be performed based on a program or instruction pre-configured in the in-vehicle device. It will be understood that the self-check of the in-vehicle device is mainly performed by the in-vehicle device to check whether problems such as damage or errors occur on the in-vehicle device and to ensure that the in-vehicle device can run normally. The pre-configured information may be configuration information pre-stored in the in-vehicle device. In an example, the configuration information of the in-vehicle device may be configured before the vehicle is delivered from a factory, or indeed may be pre-configured in another way before the in-vehicle device is powered on.

[0091] In some examples, the device to perform the access is an in-vehicle device. Because the probability of an in-vehicle device exception occurring is very low, when allocating the corresponding response resources for the in-vehicle device or the non-in-vehicle device, the control domain cockpit CDC may configure only the in-vehicle device whose device status is abnormal to use the response resource, so that only the abnormal device will send its device status to the control domain cockpit CDC on the response resource.

[0092] S202. Receive a first indication message, and further determine a corresponding resource.

[0093] With respect to an in-vehicle device, after receiving the first indication message sent by the control domain cockpit CDC, the in-vehicle device may determine whether it is authorized to access the control domain cockpit CDC based on the first indication message. If the in-vehicle device may obtain a response resource corresponding to the in-vehicle device from the first indication message, the in-vehicle device may be deemed to be authorized to access the control domain cockpit CDC. It will be understood that if the correspondence between the response resource and the accessing device is explicit, each in-vehicle device may directly obtain the response resource corresponding to the in-vehicle device from the first indication message. Indeed, if the correspondence between the response resource and the accessing device is implicit, each in-vehicle device may obtain the response resource of the accessing device by calculation based on a pre-configured identifier (e.g., ID), the time-frequency resource indicated in the system broadcast message, and a pre-set rule. It will be understood that the response resources corresponding to different terminal devices may be different, i.e. the control domain cockpit CDC may allocate the response resources of different terminal devices respectively, or the response resources may be the same, i.e. different terminal devices share the same response resource.

[0094] In some examples, after receiving the first indication message, the in-vehicle device may generate a response message.

[0095] For each in-vehicle device, after obtaining the corresponding response resource, the in-vehicle device may generate a response message for the in-vehicle device. The response message includes device status information. The device status information is used to indicate the device status of the terminal device, for example, a normal state or an abnormal state. Indeed, in some examples, the device status information may be represented by 0 and 1. For example, 1 indicates a normal state of the device, and 0 indicates an abnormal state of the device. Indeed, in some other examples, 0 indicates a normal state of the device, and 1 indicates an abnormal state of the device. Indeed, any other equivalent form, such as a value, a character, or a word, may be used for substitution. This is not limited in this specification of the present application.

[0096] It will be appreciated that the response message may further include the ID of the device.

[0097] It will be appreciated that in some instances, the two parties may agree in their protocols that only devices in an abnormal state are reported. In this case, the response message may include only the device ID, and after receiving the device ID, the CDC may know that the device is in an abnormal state. Similarly, alternatively, the protocols may agree that only devices in a normal state are reported, and the details will not be described again herein.

[0098] In some examples, devices may report both a device ID and a device status. If device 1 is in a normal state, the response message may indicate the ID of device 1 and indicate that the state is normal. If device 2 is in an abnormal state, the response message may indicate the ID of device 2 and indicate that the state is abnormal. For example, information such as "normal state" or "abnormal state" may be represented by an information element or several bits.

[0099] In some examples, the CDC requests that only devices in an abnormal state report a response message. Assume that device 1 and device 2 are grouped into one group and allocated a shared response resource, with the group address being ID 1. Device 1 is in a normal state and device 2 is in an abnormal state. In this case, device 2 may transmit its ID or the group address ID 1 to which device 2 belongs on the resource.

[0100] When the control domain cockpit CDC groups the onboard devices, the device group may be in the form of an array. For multiple onboard devices in the array, one response message is jointly generated to indicate the device status of the devices in the array. For example, 1 indicates a normal state of the devices in the array, and 0 indicates an abnormal state of the devices in the array. Indeed, in some other examples, 0 indicates a normal state of the devices in the array, and 1 indicates an abnormal state of the devices in the array.

[0101] Regarding the status of devices in an array, if all devices in the array are in a normal state, the devices in the device group are considered to be in a normal state, and if any amount of devices in the array are in an abnormal state, the devices in the array are considered to be in an abnormal state. Indeed, in another example, the status of devices in an array may alternatively be determined based on the proportion of normal or abnormal devices in the array. For example, when the proportion of normal or abnormal devices is higher than a preset percentage threshold, the devices in the array are considered to be in an abnormal state, otherwise the devices in the array are considered to be in a normal state. Indeed, the status of devices in an array may alternatively be determined based on the amount of abnormal devices in the array. For example, if the amount of abnormal devices in the array exceeds a preset amount threshold, the devices in the array are considered to be in an abnormal state, otherwise the devices in the array are considered to be in a normal state. It is clear that the status of devices in an array may be determined in any equivalent manner. This is not limited in this specification of the present application.

[0102] In some examples, when the in-vehicle device generates a response message, the device ID of the in-vehicle device may be further carried. If multiple in-vehicle devices form an array, the response message may further carry at least one of an array address and a multicast address.

[0103] In some other examples, the response resource may be shared by multiple in-vehicle devices. For devices in an abnormal state, the device may send the ID of the device on the response resource, so when the control domain cockpit CDC receives the response message, it determines which in-vehicle device is in an abnormal state. Typically, both the control domain cockpit CDC and the in-vehicle devices are manufactured by one vehicle manufacturer and installed in one vehicle, so the control domain cockpit CDC may pre-store the IDs of the in-vehicle devices.

[0104] It will be appreciated that allocating shared response resources to multiple in-vehicle devices is appropriate because in-vehicle devices typically have a low failure rate and the probability of two devices being in an abnormal state at the same time is also low.

[0105] S203. Send a response message on the corresponding resource. Note that this step is optional and is only for in-vehicle devices whose access is authorized and can send a response message. In-vehicle devices whose access is not authorized do not need to send a response message.

[0106] Optionally, after generating corresponding response information, the in-vehicle device may send a response message to the control domain cockpit CDC on a response resource corresponding to the in-vehicle device.

[0107] S204. Receive the response message and further generate a second indication message.

[0108] Execution of S204 corresponds to execution of S203. It will be understood that after receiving the response message, the control domain cockpit CDC may redetermine the system status. If the control domain cockpit CDC does not receive the response message, the system status may not need to be redetermined. Indeed, in another example, the control domain cockpit CDC may alternatively determine the system status periodically, semi-periodically, or aperiodically without determining whether the response message sent by the in-vehicle device is received.

[0109] After receiving the response message sent by the on-board device, if the corresponding response resource is allocated to a different on-board device or array, the control domain cockpit CDC may determine which on-board device or array sends the response message based on the different response resource. Then, based on the device status in the response message or the status of the device in the array, it is determined whether the on-board device or array is in an abnormal state. Indeed, if the control domain cockpit CDC does not allocate time-frequency resources to different on-board devices respectively, the response information further carries a device ID. Therefore, it may be determined which on-board device or device group is in an abnormal state based on the device ID.

[0110] After determining the device status of the in-vehicle device, the control domain cockpit CDC may re-determine the system status and determine a second indication message based on the new system status. The second indication message is a new system broadcast message. The type of the new system broadcast message may be the same as or different from the type of the system broadcast message in S201. For ease of explanation, the details will not be described again in this specification.

[0111] It will be appreciated that if the control domain cockpit CDC receives the response message and determines that all expected on-board devices are in a normal state, the control domain cockpit CDC may redetermine the system status and allow access for non-on-board devices by sending a second indication message.

[0112] Indeed, if the on-board device predicted by the control domain cockpit CDC is in an abnormal state or other processing needs to be performed, the control domain cockpit CDC may not redetermine the system status, and since system broadcast messages are typically sent periodically, the non-on-board devices continue to perform the operations in accordance with the instructions of the first indication message.

[0113] It will be appreciated that receiving a response message and redetermining the system status may be somewhat related to each other, or may be independent of each other.

[0114] In an example, the system status may include one of a system readiness state, an in-vehicle device access state, a system execution state, and an access permission state. Certainly, in another example, other possible system states may also be included. This is not limited in this application. The system readiness state and / or the in-vehicle device access state may be used to indicate that the in-vehicle device is accessing the control domain cockpit CDC or that the in-vehicle device is performing a self-check, and therefore, the non-in-vehicle device may choose not to access the control domain cockpit CDC based on these types of system states. The system execution state and / or the access permission state may be used to indicate that the in-vehicle device has accessed the control domain cockpit CDC. In this case, the non-in-vehicle device may be authorized to access the control domain cockpit CDC.

[0115] Those skilled in the art will understand that the process by which the control domain cockpit CDC determines the status of the in-vehicle device may also be considered as the process by which the in-vehicle device accesses the control domain cockpit CDC. The response message sent from the in-vehicle device may, to some extent, be considered as an access request message for the in-vehicle device.

[0116] Return to S201. After the control domain cockpit CDC sends the first indication message, the non-vehicle device may also receive the first indication message sent by the control domain cockpit CDC. Therefore, after S201, the following steps may be further executed:

[0117] S205. A first indication message is received.

[0118] For a non-vehicle device, a first indication message transmitted by the control domain cockpit CDC is received. For example, when the first indication message is a system broadcast message, it is determined based on the system broadcast message whether the non-vehicle device is authorized to access the control domain cockpit CDC. In an example, a system status of a system currently running on the control domain cockpit CDC may be determined based on the system status indication information carried in the system broadcast message, and whether the non-vehicle device is authorized to access the control domain cockpit CDC is determined based on the system status. Indeed, in another example, when the first indication message transmitted by the control domain cockpit CDC directly indicates whether the non-vehicle device is authorized to access the control domain cockpit CDC, based on the information in the first indication message, S207 may be executed if the non-vehicle device is not authorized to access the control domain cockpit CDC, or S208 may be executed if the non-vehicle device is authorized to access the control domain cockpit CDC.

[0119] S206. Determine whether the system status is a preset system state. Note that this step is optional and applies only when the first indication message includes system status indication information. If the first indication message includes information used to directly indicate whether access is permitted, the system status does not need to be determined.

[0120] Specifically, in S205, the non-vehicle device determines whether the system status is a preset system state.

[0121] In the example, if the preset system state is a system ready state or an in-vehicle device access state, it is determined that the non-in-vehicle device is not permitted to access the control domain cockpit CDC, and S207 is executed; otherwise, it is determined that the non-in-vehicle device is permitted to access the control domain cockpit CDC, and S208 is executed. Of course, the system status may alternatively be any other equivalent system state. This is not limited in the present specification of the present application. However, it will be understood that in this example, when the system status is a preset system state, the in-vehicle device is performing device access.

[0122] In another example, if the preset system state is the system execution state or the access permission state, it is determined that the non-vehicle device is permitted to access the control domain cockpit CDC, and S208 is executed; otherwise, it is determined that the non-vehicle device is not permitted to access the control domain cockpit CDC, and S207 is executed. Of course, the system status may alternatively be any other equivalent system state. This is not limited in this specification of the present application. It will be understood that in this example, when the system status is the preset system state, the in-vehicle device has completed device access.

[0123] S207. Prohibit non-vehicle devices from initiating random access requests.

[0124] Non-vehicle devices are prohibited from initiating random access requests to the control domain cockpit CDC.

[0125] S208. Allow non-vehicle devices to initiate random access requests.

[0126] Non-vehicle devices are permitted to initiate random access requests to the control domain cockpit CDC.

[0127] In this application, system broadcast messages carry system status indication information. When an in-vehicle device is performing a self-check or establishing a connection to the control domain cockpit CDC, non-in-vehicle devices are prohibited from initiating random access requests. This avoids the impact of the initiation of random access requests performed by non-in-vehicle devices during this phase on the control domain cockpit CDC's checking of the in-vehicle device's status and on the in-vehicle device's access. In this way, it is ensured that the in-vehicle device can run normally and that some basic services can run normally.

[0128] FIG. 3 is a diagram of another type of information exchange between a CDC, an in-vehicle device, and a non-in-vehicle device according to an embodiment of the present application.

[0129] Alternatively, instead of the manner of determining the system status described in S201 of Figure 2, a method of setting a time threshold may be used, for example, S301 may be performed.

[0130] S301. Send a first indication message.

[0131] After the control domain cockpit CDC transmits the first indication message and the non-vehicle device receives the first indication message, the non-vehicle device determines whether to be granted access to the control domain cockpit CDC. Optionally, the first indication message may be a system broadcast message. It will be understood that the manner of transmitting the first indication message is not limited in this application and that the first indication message may be transmitted via broadcast, multicast, or any other equivalent manner. It will be understood that this application mainly describes how to avoid the influence of the initiation of a random access request performed by a non-vehicle device in this phase on the control domain cockpit CDC's checking of the status of the in-vehicle device and the in-vehicle device's access. Therefore, the in-vehicle device may ignore the time threshold information in the first indication message. It is true that in some examples, the in-vehicle device may alternatively determine whether to access the control domain cockpit CDC based on the time threshold information.

[0132] In some embodiments, the first indication message may carry time threshold information. The time threshold information may be time-domain indication information used to indicate a time threshold. The time threshold information may be a system frame number (SFN) or an offset from a specific fixed reference frame. For example, the fixed reference frame may be the first reference frame. The fixed reference frame may be frame 0, or indeed, alternatively, any other reference frame. Indeed, the time threshold may alternatively be a specific value or a time range. This is not limited in this specification of the present application.

[0133] In any implementation, the time threshold information may be a system frame number. Take system frame number 256 as an example. When the non-in-vehicle device determines that the current system frame number is less than or equal to system frame number 256, the non-in-vehicle device is not allowed to initiate access.

[0134] In another optional implementation, the time threshold information may be one or more time domain offsets relative to a specific fixed reference frame. For example, the time domain offset may be 256 ms. The fixed reference frame may be negotiated or agreed upon in advance between the head unit CDC and the in-vehicle device or the non-in-vehicle device, or may be defined in a protocol. For example, the fixed reference frame is assumed to be frame number 64, and the time length of a single frame is assumed to be 0.5 ms. Assume that the current frame number is 20, and the current absolute time is assumed to be 10 ms. The non-in-vehicle device is not permitted to start access within the absolute time of 256 ms + 64 × 0.5 = 288 ms.

[0135] In yet another optional implementation, the time threshold information may alternatively be a time domain offset relative to the first signaling, which may be a time threshold indicating that random access initiation is not permitted within a certain time range.

[0136] The first signaling may be specific signaling agreed or negotiated in advance between the control domain cockpit CDC and the non-vehicle device, or specific signaling defined in a protocol. Take specific RRC signaling as an example. The RRC signaling includes a signaling information base (SIB). For example, the SIB may be transmitted periodically. When the SIB is transmitted at a specific fixed time, in a possible implementation, the non-vehicle device may not be permitted to initiate access within a specific time frame after the control domain cockpit CDC transmits the SIB because the control domain cockpit CDC may need to handle other issues during this time period. In this case, after the moment the CDC transmits the SIB + [time domain offset 1, time domain offset 2], the terminal is not permitted to initiate random access to the CDC within the time frame [the moment the CDC transmits the SIB + time domain offset 1, the moment the CDC transmits the SIB + time domain offset 2]. It will be understood that the RRC signaling may be carried in a management frame. It should be noted that [time domain offset 1, time domain offset 2] may be represented by an information element or several bits.

[0137] As another example, in a possible implementation, a non-vehicle device may not be allowed to initiate access within a certain time frame after obtaining a particular RRC signaling (e.g., a first RRC signaling) because the control domain cockpit CDC may need to handle other issues during this time period. For example, if the moment at which the non-vehicle device successfully receives the first RRC signaling is the first moment, the terminal is not allowed to initiate random access to the control domain cockpit CDC within the time frame [first moment + time domain offset 1, first moment + time domain offset 2]. It will be understood that the RRC signaling may be carried in a control frame.

[0138] It will be appreciated that the time threshold information may be one time domain offset or multiple time domain offsets.

[0139] To ensure that the on-board device is not affected by the access of a non-on-board device when the on-board device performs a self-check or accesses the control domain cockpit CDC, the time threshold information carried in the first indication message may be for the non-on-board device. In an example, different time thresholds may be set for different non-on-board devices. Indeed, if there is a device group including multiple non-on-board devices, the device group may be in the form of an array. Alternatively, different time thresholds may be set for different arrays of non-on-board devices. This is not limited in the present specification of the present application. In another example, the expression format of the time threshold in the system broadcast message may be explicit or may indeed be implicit. For the implementation process, please refer to S201. For ease of explanation, the details will not be described again in this specification.

[0140] Regarding the setting of the time threshold, the control domain cockpit CDC may be set based on the status of a self-check performed by the in-vehicle device or the status of the establishment of a connection with the control domain cockpit CDC.

[0141] S202 and S203 are executed after S301. The implementation process of S202 and S203 in Figure 3 is the same as the implementation process of S202 and S203 in Figure 2. For ease of explanation, the details will not be described again in this specification.

[0142] S302 may be executed after S203.

[0143] S302. Receive the response message and further generate a second indication message.

[0144] Execution of S302 corresponds to execution of S203. It will be appreciated that the control domain cockpit CDC may reset the time thresholds of different non-in-vehicle devices after receiving a response message. If the control domain cockpit CDC does not receive a response message, the time thresholds may not need to be reset. In another example, the control domain cockpit CDC may alternatively set the time thresholds periodically, semi-periodically, or aperiodically without determining whether a response message sent by an in-vehicle device is received.

[0145] In particular, after the response message is received, the time threshold may be reset. It will be understood that receiving the response message and resetting the time threshold may be somewhat related to each other or may be independent of each other.

[0146] After receiving the response message sent by the on-board device, the control domain cockpit CDC determines the device status of the on-board device and resets the time threshold based on the device status of the on-board device. Then, a second indication message can be determined based on the new time threshold. The second indication message is a new system broadcast message. The type of the new system broadcast message is the same as or different from the type of the system broadcast message in S301. For ease of explanation, details will not be described again in this specification.

[0147] Return to S301. After the control domain cockpit CDC sends the first indication message, the non-vehicle device may also receive the first indication message sent by the control domain cockpit CDC. Therefore, after S301, the following steps may be further executed:

[0148] S303. A first indication message is received.

[0149] For a non-vehicle device, a first indication message transmitted by the control domain cockpit CDC is received. For example, when the first indication message is a system broadcast message, it is determined based on the system broadcast message whether the non-vehicle device is authorized to access the control domain cockpit CDC. In an example, a time threshold set by the control domain cockpit CDC for the non-vehicle device may be determined based on time threshold information carried in the system broadcast message, and whether the non-vehicle device is authorized to access the control domain cockpit CDC is determined based on the time threshold of the non-vehicle device. Indeed, in another example, when the first indication message transmitted by the control domain cockpit CDC directly indicates whether the non-vehicle device is authorized to access the control domain cockpit CDC, based on the information in the first indication message, S207 may be executed if the non-vehicle device is not authorized to access the control domain cockpit CDC, or S208 may be executed if the non-vehicle device is authorized to access the control domain cockpit CDC.

[0150] S304. Determine whether the current moment reaches a time threshold. Note that this step is optional and is only applied if the first indication message includes time threshold information. If the first indication message directly indicates whether access is permitted, it is not necessary to determine whether the time threshold reaches the time threshold.

[0151] In particular, the non-vehicle device determines whether the current moment reaches a time threshold.

[0152] In the example, if the current instant reaches the time specified by the time threshold, it is determined that the non-vehicle device is not allowed to access the control domain cockpit CDC and S207 is executed, otherwise it is determined that the non-vehicle device is allowed to access the control domain cockpit CDC and S208 is executed. Indeed, the time threshold may be a system frame number or an offset from a particular fixed reference frame.

[0153] The implementation process of S207 and S208 is the same as the implementation process of S207 and S208 in Figure 2. For ease of explanation, the details will not be described again herein.

[0154] In this application, the system broadcast message carries time threshold information to ensure that non-vehicle devices are prohibited from initiating random access requests before a preset time threshold is reached, or are allowed to initiate random access requests after the preset time threshold is reached. This avoids the impact of the initiation of random access requests performed by non-vehicle devices in this phase on the CDC's checking of the status of the vehicle devices and their access. In this way, it is ensured that the vehicle devices can run normally and some basic services can run normally.

[0155] FIG. 4 is a diagram of yet another type of information exchange between a CDC, an in-vehicle device, and a non-in-vehicle device according to an embodiment of the present application.

[0156] In addition, instead of the manner of determining the system status described in S201 of Fig. 2 and the manner of setting the time threshold described in S301 of Fig. 3, a manner of setting access indication information may be used. For example, S401 may be executed.

[0157] S401. Send a first indication message.

[0158] After the control domain cockpit CDC transmits the first indication message, and the in-vehicle device or the non-in-vehicle device receives the first indication message, the in-vehicle device or the non-in-vehicle device determines whether access to the control domain cockpit CDC is permitted. Optionally, the first indication message may be a system broadcast message. Indeed, it will be understood that the manner of transmitting the first indication message is not limited in this application, and the first indication message may be transmitted in a broadcast, multicast, or any other equivalent manner.

[0159] In some embodiments, the system broadcast message may carry access indication information. The access indication information may be a mapping table of device types and access relationships. In other words, the access indication information may indicate a mapping relationship between device types and access relationships. The mapping table or mapping relationship is used to indicate which types of devices are allowed to initiate random access requests and which types of devices are prohibited from initiating random access requests. In an example, the device types may be classified into in-vehicle devices and non-in-vehicle devices, or may be classified into microphones, speakers, mobile phones, etc., or into in-vehicle devices previously connected to the control domain cockpit CDC or in-vehicle devices that have never been connected to the control domain cockpit CDC, etc. The device types may also be indicated by corresponding type indexes or numbers. This is not limited in this specification of the present application.

[0160] The mapping table for device types and access relationships may be explicit or implicit. For example, an explicit correspondence table, such as Table 1, may be constructed. It should be noted that all tables in the solution of this application are intended to reflect the correspondence and are merely representations of the correspondence. Any other representations that can reflect the correspondence may replace the table. In this application, a table is a generalization of all possible representations. [Table 1]

[0161] It is assumed that 0 indicates that access is permitted, and 1 indicates that access is not permitted. It can be seen from Table 1 that access for the car microphone and the car speaker is permitted, and access for the mobile phone is not permitted. It will be understood that the type of the responding device may be indicated by the device type indication information. For example, if "000" is used to identify the car microphone, {000, 0} may indicate that the car microphone is permitted to access.

[0162] When the mapping table for device types and access relationships is implicit, for example, based on a protocol agreement, a bitmap may be used to indicate which types of devices are allowed to access. Typically, according to the protocol agreement, each bit in the bitmap may identify a device type. It is assumed that the length of the bitmap is 3 bits, and each bit corresponds to a car microphone, a car speaker, and a mobile phone, respectively. When a bitmap {001} is transmitted, the bitmap indicates that the car microphone and the car speaker are allowed to access, and the mobile phone is not allowed to access. Indeed, in another example, 1 may alternatively indicate that access is allowed, 0 may indicate that access is not allowed, or any other number may be used as an equivalent replacement. This is not limited in the present specification of the present application.

[0163] In the example, further, different types of devices may have different device priorities. The mapping table for device types and access relationships may be replaced by a mapping table based on device priorities and access relationships. The mapping table is used to indicate whether devices of different priorities are allowed to initiate random access requests. It will be understood that different types of devices may have the same device priority. Optionally, the device priority may be an access priority. Typically, a device with a higher priority may have a higher access priority. For example, the priority of a car microphone and a car speaker is 1, and the priority of a mobile phone is 2. If the device priority carried in the first indication message is 1, the access of the car microphone and the car speaker is allowed.

[0164] In another example, when a device group including multiple non-vehicle devices exists, the device group may be in the form of an array. For the array of different non-vehicle devices, a mapping table for device types and access relationships, or a mapping table based on device priorities and access relationships, may be set. This is not limited in the specification of this application. In another example, the expression format of the access indication information in the system broadcast message may be explicit or may indeed be implicit. For the implementation process, please refer to S201. For ease of explanation, the details will not be described again in this specification.

[0165] S202 and S203 are executed after S401. The implementation process of S202 and S203 in Figure 4 is the same as the implementation process of S202 and S203 in Figure 2. For ease of explanation, the details will not be described again in this specification.

[0166] S402 may be executed after S203.

[0167] S402. Receive the response message and further generate a second indication message.

[0168] Execution of S402 corresponds to execution of S203. It will be understood that if the control domain cockpit CDC receives the response message and determines that all expected in-vehicle devices are in a normal state, the control domain cockpit CDC may reset the access indication information and allow access for the non-in-vehicle device by sending a second indication message. Indeed, if the in-vehicle device expected by the control domain cockpit CDC is in an abnormal state or other processing needs to be performed, the control domain cockpit CDC may not reset the access indication information. Since the system broadcast message is usually sent periodically, the non-in-vehicle device continues to perform the operation in accordance with the instructions of the first indication message.

[0169] After receiving the response message sent by the on-board device, the control domain cockpit CDC determines the device status of the on-board device and resets the access indication information based on the device status of the on-board device. Then, a second indication message can be determined based on the new indication information. The second indication message is a new system message. The type of the new system message is the same as or different from the type of the system broadcast message in S301. For ease of explanation, details will not be described again in this specification.

[0170] Return to S401. After the control domain cockpit CDC sends the first indication message, the non-vehicle device may also receive the first indication message sent by the control domain cockpit CDC. Therefore, after S401, the following steps may be further executed:

[0171] S403. A first indication message is received.

[0172] For a non-vehicle device, a first indication message transmitted by the control domain cockpit CDC is received. For example, when the first indication message is a system broadcast message, it is determined based on the system broadcast message whether the non-vehicle device is authorized to access the control domain cockpit CDC. In an example, the device type and access relationship of the non-vehicle device may be determined based on the access indication information carried in the system broadcast message, and whether the non-vehicle device is authorized to access the control domain cockpit CDC is determined based on the device type and access relationship. Indeed, in another example, when the first indication message transmitted by the control domain cockpit CDC directly indicates whether the non-vehicle device is authorized to access the control domain cockpit CDC, based on the information in the first indication message, S207 may be executed if the non-vehicle device is not authorized to access the control domain cockpit CDC, or S208 may be executed if the non-vehicle device is authorized to access the control domain cockpit CDC.

[0173] S404. Determine whether the access indication information satisfies a preset condition. Note that this step is optional and is only applied when the first indication message includes access indication information. If the first indication message directly indicates whether access is permitted, it is not necessary to determine whether the access indication information satisfies a preset condition.

[0174] Specifically, the non-in-vehicle device determines whether the device type of the non-in-vehicle device is allowed to initiate a random access request based on the device type and access relationship determined in S403.

[0175] In the example, if the device type of the non-vehicle device does not allow initiation of a random access request, it is determined that the non-vehicle device is not allowed to access the domain cockpit CDC and S207 is executed, or if the device type of the non-vehicle device does allow initiation of a random access request, it is determined that the non-vehicle device is allowed to access the control domain cockpit CDC and S208 is executed.

[0176] The implementation process of S207 and S208 is the same as the implementation process of S207 and S208 in Figure 2. For ease of explanation, the details will not be described again herein.

[0177] In this application, the system broadcast message carries access indication information to ensure that only devices whose device types meet the preset conditions are allowed to send random access requests, and devices whose device types do not meet the preset conditions are prohibited from sending random access requests. This avoids the impact of initiating a random access request performed by a non-vehicle device on the CDC's checking of the status of the in-vehicle device and the access of the in-vehicle device. In this way, it is ensured that the in-vehicle device can operate normally and some basic services can be performed normally.

[0178] Certainly, those skilled in the art should realize that the time threshold set in Figure 3 and the access indication information set in Figure 4 may be used together with the system status determined in Figure 2. Certainly, any one or two of the time threshold, the access indication information, and the system status may be selected so that the control domain cockpit CDC can control the access of on-board devices and non-on-board devices.

[0179] FIG. 5 is a flow chart of an access control method according to an embodiment of the present application.

[0180] The present application provides an access control method, as shown in Figure 5. The interaction processes of Figures 2 to 4 may be implemented by using this method. The method may include the following steps:

[0181] S501. Determine that the status of the first device is a first status.

[0182] S502. Transmit first indication information. The first indication information is used to indicate whether at least one second device is allowed to access the first device. Optionally, the first indication information may be carried in a system message or transmitted by broadcast. For example, the system message may be a system broadcast message. The first indication information may be a MIB, a SIB, or a broadcast frame. The MIB may be carried on a PBCH. The SIB is usually included in RRC signaling.

[0183] In a possible implementation, the first status includes at least one of a system readiness state and an in-vehicle device access state, and the first indication information is used to indicate that access for at least one second device is not permitted, or the first status includes at least one of a system execution state and an access permission state, and the first indication information is used to indicate that access for the second device is permitted. The system readiness state and / or the in-vehicle device access state may be used to indicate that the in-vehicle device is accessing the control domain cockpit CDC or that the in-vehicle device is performing a self-check, and therefore, the non-in-vehicle device may choose not to access the control domain cockpit CDC based on these types of system states. The system execution state and / or the access permission state may be used to indicate that the in-vehicle device has accessed the control domain cockpit CDC. In this case, the non-in-vehicle device may be permitted to access the control domain cockpit CDC.

[0184] In a possible implementation, the first indication information is used to indicate whether access of at least one third device is permitted.

[0185] In one possible implementation, the first indication information includes device type information, and the device type of the at least one second device belongs to the at least one device type indicated by the device type information. Further, the second device determines whether to access the first device based on the device type information.

[0186] In a possible implementation, the first indication information further includes access indication information, which is used to indicate whether access to the first device is permitted.

[0187] In one possible implementation, the first indication information includes priority information, and the priority of at least one second device belongs to at least one priority indicated by the priority information. The first indication information further includes access indication information, and the access indication information is used to indicate whether access to the first device is permitted. Furthermore, the second device determines whether to access the first device based on the priority information and the access indication information.

[0188] In a possible implementation, the first indication information includes first time information, and the first time information is used to indicate that at least one second device is not allowed to access the first device within a first time range.

[0189] In a possible implementation, the first time range is a time domain offset relative to a first reference frame or a time domain offset relative to a first signaling. The first reference frame may be a first system frame number pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be a first system frame number defined in a protocol. The first signaling may be specific signaling pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be specific signaling defined in a protocol. For example, the first signaling may be RRC signaling. One or more time domain offsets may be present.

[0190] In a possible implementation, the first indication information includes resource indication information, and the resource indication information indicates resources to be used for at least one third device, or the resources indicated by the resource indication information are not used for at least one second device.

[0191] In a possible implementation, there is a correspondence between the resources indicated by the resource indication information and the device type and / or priority of the at least one third device.

[0192] In a possible implementation, the first indication information includes a Boolean variable or an enumeration variable. Of course, any other equivalent type of variable may alternatively be included.

[0193] In a possible implementation, the device type includes at least one of an in-vehicle device and a non-in-vehicle device.

[0194] FIG. 6 is a flow chart of another access control method according to an embodiment of the present application.

[0195] As shown in Figure 6, the present application provides another access control method. The interaction processes of Figures 2 to 4 may be implemented by using this method. The method may include the following steps:

[0196] S601. Receive first indication information from a first device. Optionally, the first indication information is carried in a system message or transmitted by broadcast. For example, the system message may be a system broadcast message. The first indication information may be a MIB, a SIB, or a broadcast frame. The MIB may be carried on a PBCH. The SIB is typically included in RRC signaling.

[0197] S602. Determine whether the second device is allowed to access the first device based on the first indication information.

[0198] In a possible implementation, the first indication information is used to indicate whether access of at least one third device is permitted.

[0199] In one possible implementation, the first indication information includes device type information, and the device type of the at least one second device belongs to the at least one device type indicated by the device type information. Further, the second device determines whether to access the first device based on the device type information.

[0200] In a possible implementation, the first indication information further includes access indication information, which is used to indicate whether access to the first device is permitted.

[0201] In one possible implementation, the first indication information includes priority information, and the priority of at least one second device belongs to at least one priority indicated by the priority information. The first indication information further includes access indication information, and the access indication information is used to indicate whether access to the first device is permitted. Furthermore, the second device determines whether to access the first device based on the priority information and the access indication information.

[0202] In a possible implementation, the first indication information includes first time information, and the first time information is used to indicate that at least one second device is not allowed to access the first device within a first time range.

[0203] In a possible implementation, the first time range is a time domain offset relative to a first reference frame or a time domain offset relative to the first signaling. The first reference frame may be a first system frame number pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be a first system frame number defined in a protocol. The first signaling may be specific signaling pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be specific signaling defined in a protocol. For example, the first signaling may be RRC signaling. One or more time domain offsets may be present. In a possible implementation, the first indication information includes resource indication information, where the resource indication information indicates resources used for at least one third device, or the resources indicated by the resource indication information are not used for at least one second device.

[0204] In a possible implementation, there is a correspondence between the resources indicated by the resource indication information and the device type and / or priority of the at least one third device.

[0205] In a possible implementation, the first indication information includes a Boolean variable or an enumeration variable. Of course, any other equivalent type of variable may alternatively be included.

[0206] In a possible implementation, the first device is a control domain cockpit CDC, the third device is an in-vehicle device, and the second device is a non-in-vehicle device.

[0207] In a possible implementation, the second device is a mobile phone.

[0208] FIG. 7 is a schematic diagram of an access control device according to an embodiment of the present application.

[0209] As shown in FIG. 7 , the present application provides an access control device 700. The access control device 700 may be a first device, for example, a control domain cockpit (CDC), or the access control device may be a chip, an internal component, or the like within the first device. Indeed, the access control device may alternatively be a mobile phone, a tablet computer, a desktop computer, a laptop computer, a handheld computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a personal digital assistant (PDA), an augmented reality (AR) device, a virtual reality (VR) device, an artificial intelligence (AI) device, a wearable device, an in-vehicle device, a smart home device, and / or a smart city device. The specific type of the first device is not limited in this embodiment of the present application.

[0210] The access control device 700 may implement the interaction processes of Figures 2 to 4. The access control device 700 includes: a processing unit 701 configured to determine that a status of a first device is a first status; and a transmitting unit 702 configured to transmit first indication information, where the first indication information is used to indicate whether access of at least one second device to the first device is permitted. Optionally, the first indication information is carried in a system message or transmitted by broadcast. The first indication information may be a MIB, a SIB, or a broadcast frame. The MIB may be carried on a PBCH. The SIB is usually included in RRC signaling. Optionally, the first indication information is transmitted by broadcast.

[0211] In a possible implementation, the first status includes at least one of a system readiness state and an in-vehicle device access state, and the first indication information is used to indicate that access for at least one second device is not permitted, or the first status includes at least one of a system execution state and an access permission state, and the first indication information is used to indicate that access for the second device is permitted. The system readiness state and the in-vehicle device access state may be used to indicate that the in-vehicle device is accessing the control domain cockpit CDC or that the in-vehicle device is performing a self-check, and therefore, the non-in-vehicle device may choose not to access the control domain cockpit CDC based on these types of system states. The system execution state and the access permission state may be used to indicate that the in-vehicle device has accessed the control domain cockpit CDC, in which case, access for the non-in-vehicle device to the control domain cockpit CDC is permitted.

[0212] In a possible implementation, the first indication information is used to indicate whether access of at least one third device is permitted.

[0213] In one possible implementation, the first indication information includes device type information, and the device type of the at least one second device belongs to the at least one device type indicated by the device type information. Further, the second device determines whether to access the first device based on the device type information.

[0214] In a possible implementation, the first indication information further includes access indication information, which is used to indicate whether access to the first device is permitted.

[0215] In one possible implementation, the first indication information includes priority information, and the priority of at least one second device belongs to at least one priority indicated by the priority information. The first indication information further includes access indication information, and the access indication information is used to indicate whether access to the first device is permitted. Furthermore, the second device determines whether to access the first device based on the priority information and the access indication information.

[0216] In a possible implementation, the first indication information includes first time information, and the first time information is used to indicate that at least one second device is not allowed to access the first device within a first time range.

[0217] In a possible implementation, the first time range is a time domain offset relative to a first reference frame or a time domain offset relative to a first signaling. The first reference frame may be a first system frame number pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be a first system frame number defined in a protocol. The first signaling may be specific signaling pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be specific signaling defined in a protocol. For example, the first signaling may be RRC signaling. One or more time domain offsets may be present.

[0218] In a possible implementation, the first indication information includes resource indication information, and the resource indication information indicates resources to be used for at least one third device, or the resources indicated by the resource indication information are not used for at least one second device.

[0219] In a possible implementation, there is a correspondence between the resources indicated by the resource indication information and the device type and / or priority of the at least one third device.

[0220] In a possible implementation, the first indication information includes a Boolean variable or an enumeration variable. Of course, any other equivalent type of variable may alternatively be included.

[0221] In a possible implementation, the device type includes at least one of an in-vehicle device and a non-in-vehicle device.

[0222] FIG. 8 is a schematic diagram of an access device according to an embodiment of the present application.

[0223] 8 , the present application provides an access device 800. The access device 800 may be a second device or a third device, for example, an in-vehicle device or a non-in-vehicle device, or the access device may be a chip, internal component, etc., within the second device or a third device, for example, a chip or internal component within an in-vehicle device or a non-in-vehicle device. Indeed, the access device may alternatively be a mobile phone, a tablet computer, a desktop computer, a laptop computer, a handheld computer, a notebook computer, a UMPC, a netbook, a cellular phone, a PDA, an AR device, a VR device, an AI device, a wearable device, an in-vehicle device, a smart home device, and / or a smart city device. The specific type of the first device is not limited in this embodiment of the present application.

[0224] The access device 800 may be configured to implement the interaction processes of Figures 2 to 4. The access device 800 includes a receiving unit 801 and a processing unit 802. The receiving unit 801 is configured to receive first indication information from a first device. The processing unit 802 is configured to determine whether access of a second device to the first device is permitted based on the first indication information. Optionally, the first indication information may be carried in a system message or transmitted by broadcast. For example, the system message may be a system broadcast message. The first indication information may be a MIB, a SIB, or a broadcast frame. The MIB may be carried on a PBCH. The SIB is usually included in RRC signaling.

[0225] In a possible implementation, the first indication information is used to indicate whether access of at least one third device is permitted.

[0226] In one possible implementation, the first indication information includes device type information, and the device type of the at least one second device belongs to the at least one device type indicated by the device type information. Further, the second device determines whether to access the first device based on the device type information.

[0227] In a possible implementation, the first indication information further includes access indication information, which is used to indicate whether access to the first device is permitted.

[0228] In one possible implementation, the first indication information includes priority information, and the priority of at least one second device belongs to at least one priority indicated by the priority information. The first indication information further includes access indication information, and the access indication information is used to indicate whether access to the first device is permitted. Furthermore, the second device determines whether to access the first device based on the priority information and the access indication information.

[0229] In a possible implementation, the first indication information includes first time information, and the first time information is used to indicate that access of at least one second device to the first device is not permitted within a first time range.

[0230] In a possible implementation, the first time range is a time domain offset relative to a first reference frame or a time domain offset relative to a first signaling. The first reference frame may be a first system frame number pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be a first system frame number defined in a protocol. The first signaling may be specific signaling pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be specific signaling defined in a protocol. For example, the first signaling may be RRC signaling. One or more time domain offsets may be present.

[0231] In a possible implementation, the first indication information includes resource indication information, and the resource indication information indicates resources to be used for at least one third device, or the resources indicated by the resource indication information are not used for at least one second device.

[0232] In a possible implementation, there is a correspondence between the resources indicated by the resource indication information and the device type and / or priority of the at least one third device.

[0233] In a possible implementation, the first indication information includes a Boolean variable or an enumeration variable. Of course, any other equivalent type of variable may alternatively be included.

[0234] In a possible implementation, the first device is a control domain cockpit CDC, the third device is an in-vehicle device, and the second device is a non-in-vehicle device.

[0235] In a possible implementation, the second device is a mobile phone.

[0236] FIG. 9 is a schematic diagram of a communication system according to an embodiment of the present application.

[0237] As shown in Figure 9, the present application provides a communication system 900. The communication system 900 includes the access control device 700 shown in Figure 7.

[0238] The access control device 700 includes at least one processor and a communication interface. Furthermore, the access control device 700 may further include at least one memory. Optionally, the processor, memory, and communication interface of the access control device 700 may establish a communication connection through a bus. The communication interface provides input and / or output of information to the at least one processor.

[0239] The at least one processor may include at least one of a central processing unit (CPU), a graphics processing unit (GPU), and a digital signal process (DSP) chip.

[0240] The memory may include volatile memory such as random-access memory (RAM), or the memory may further include non-volatile memory such as read-only memory (ROM), flash memory, a hard disk drive (HDD), or a solid state drive (SSD), or the memory 2002 may further include a combination of the above types of memory.

[0241] At least one processor is coupled to the memory and configured to read and execute instructions in the memory, such that when the processor executes the instructions, the processor can perform the functions of the access control device 700.

[0242] In a possible implementation, the access control device 700 may be a chip capable of implementing the functions of FIG. 7, or a vehicle capable of implementing the functions of FIG.

[0243] In a possible implementation, the communication system 900 further includes the access device 800 shown in FIG.

[0244] The access device 800 includes a processor, a memory, a communication interface, and a bus. The processor, memory, and communication interface of the access device 800 may establish a communication connection through the bus.

[0245] The processor may be a central processing unit (CPU).

[0246] The memory may include volatile memory such as random-access memory (RAM), or the memory may further include non-volatile memory such as read-only memory (ROM), flash memory, a hard disk drive (HDD), or a solid state drive (SSD), or the memory 2002 may further include a combination of the above types of memory.

[0247] The processor is coupled to the memory and configured to read and execute instructions in the memory. When the processor executes the instructions, the processor is able to perform the functions of the access device 800.

[0248] In a possible implementation, the access device 800 may be a chip capable of performing the functions of FIG.

[0249] The present application further provides a transportation device or an intelligent device, for example, an unmanned aerial vehicle, an automobile, an automated guided vehicle, or a robot. The transportation device or the intelligent device includes the access control device described above. Furthermore, optionally, the transportation device further includes the access device described above.

[0250] The present application provides an access control method and apparatus, as well as a communication system. A system broadcast message carrying system status information, a time threshold, and / or access indication information is transmitted. After a non-vehicle device receives the system broadcast message, the non-vehicle device determines whether to initiate a random access request based on the system status information, the time threshold, and / or the access indication information. This avoids the impact of the initiation of a random access request by a non-vehicle device on the CDC's check of the in-vehicle device's status and the in-vehicle device's access. In this way, it is ensured that the in-vehicle device can operate normally, and that some basic services can be performed normally.

[0251] Those skilled in the art should know that the functions described in the embodiments of the present application in one or more examples above may be implemented by hardware, software, firmware, or any combination thereof. When the functions are implemented by software, the functions may be stored on a computer-readable medium or transmitted as one or more instructions or code in a computer-readable medium. Computer-readable media include computer storage media and communication media, and communication media include any medium that facilitates the transmission of a computer program from one place to another. Storage media may be any available medium that can be accessed by a general-purpose computer or a special-purpose computer.

[0252] The steps of the methods or algorithms according to the embodiments disclosed herein may be implemented by hardware, by software modules executed by a processor, or a combination thereof. The software modules may be configured in random access memory (RAM), memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk drive, a removable disk, a CD-ROM, or any other form of storage medium well known in the art.

[0253] In the above-mentioned specific implementation, the objectives, technical solutions and beneficial effects of the present application are further described in detail. It should be understood that the above description is only a specific implementation of the present application and is not intended to limit the protection scope of the present application. All modifications, equivalent replacements, improvements, etc. made based on the technical solutions of the present application fall within the protection scope of the present application. [Explanation of symbols]

[0254] 700 Access Control Device 701 Processing Unit 702 transmitting unit 800 Access Device 801 receiving unit 802 Processing Unit 900 Communication Systems

Claims

1. 1. An access control method, comprising:

1. An access control method, comprising: a step of transmitting first indication information, wherein the first indication information includes access indication information, the access indication information is used to indicate a mapping relationship between a device type and an access relationship, and the device type includes an in-vehicle device and a non-in-vehicle device.

2. The access control method of claim 1, wherein the access relationship indicates whether access is permitted or not permitted.

3. 2. The access control method of claim 1, wherein the access indication information is a bitmap, a first bit of the bitmap is used to indicate whether the non-vehicle device is allowed to access, and a second bit of the bitmap is used to indicate whether the vehicle device is allowed to access.

4. wherein the first bit of the bitmap being 0 indicates that the non-vehicle device is authorized for access, and the first bit of the bitmap being 1 indicates that the non-vehicle device is not authorized for access; 4. The access control method of claim 3, wherein the second bit of the bitmap being 0 indicates that the in-vehicle device is permitted to access, and the second bit of the bitmap being 1 indicates that the in-vehicle device is not permitted to access.

5. The step of transmitting the first indication information, 2. The access control method of claim 1, further comprising the step of transmitting the first indication information to a second device, wherein the second device is a non-vehicle device, and the first indication information is used to indicate whether the second device is authorized to access the first device.

6. The access control method according to claim 5, wherein the first indication information includes priority information, and the priority of the second device belongs to at least one priority indicated by the priority information.

7. 6. The access control method of claim 5, wherein the first indication information includes first time information, and the first time information is used to indicate that the second device is not authorized to access the first device within a first time range.

8. 8. The access control method of claim 7, wherein the first time range is a time domain offset relative to a first reference frame or a time domain offset relative to a first signaling.

9. The access control method of claim 1, wherein the first indication information is carried within a system message.

10. The access control method according to claim 1 , wherein the first indication information is transmitted by broadcast.

11. The access control method of claim 5, wherein the first device is a control domain cockpit (CDC).

12. 1. An access method comprising: receiving first indication information from a first device, the first indication information including access indication information, the access indication information being used to indicate a mapping relationship between a device type and an access relationship, the device type including an in-vehicle device and a non-in-vehicle device; and determining whether a second device is permitted to access the first device based on the first indication information.

13. The access method of claim 12, wherein the access relationship indicates whether access is permitted or not permitted.

14. An access method as described in claim 12, wherein the access indication information is a bitmap, a first bit of the bitmap is used to indicate whether the non-vehicle device is allowed to access, and a second bit of the bitmap is used to indicate whether the vehicle device is allowed to access.

15. The method of claim 15, wherein the first bit of the bitmap is 0 to indicate that the non-vehicle device is authorized for access, and the first bit of the bitmap is 1 to indicate that the non-vehicle device is not authorized for access; 15. The access method of claim 14, wherein the second bit of the bitmap being 0 indicates that the in-vehicle device is authorized to access, and the second bit of the bitmap being 1 indicates that the in-vehicle device is not authorized to access.

16. The access method according to claim 12, wherein the first indication information includes priority information, and the priority of the second device belongs to at least one priority indicated by the priority information.

17. 13. The access method of claim 12, wherein the first indication information includes first time information, and the first time information is used to indicate that the second device is not authorized to access the first device within a first time range.

18. 18. The access method of claim 17, wherein the first time range is a time domain offset relative to a first reference frame or a time domain offset relative to a first signaling.

19. The access method of claim 12, wherein the first indication information is carried within a system message.

20. The access method of claim 12, wherein the first indication information is transmitted by broadcast.

21. The access method of claim 12 , wherein the first device is a control domain cockpit (CDC) and the second device is a non-vehicle device.

22. 22. The method of claim 21, wherein the second device is a mobile phone.

23. An apparatus comprising at least one processor and a memory storing computer instructions that, when executed by the at least one processor, cause the apparatus to perform a method according to any one of claims 1 to 22.

24. 23. A computer storage medium containing computer instructions which, when executed by at least one processor, perform the method of any one of claims 1 to 22.

Images