Access control method and apparatus, and communication system
An access control method for smart cockpits manages access requests from non-vehicle devices to ensure in-vehicle device functionality and reduce cabling needs by using system status and indication information to authorize connections.
Patent Information
- Application Number
- JP2024158124
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-09-12
- Publication Date
- 2025-01-14
- Estimated Expiration
- 2040-03-23
AI Technical Summary
The challenge of reducing the need for extensive cabling and high costs associated with wired connections between cockpit domain controllers (CDC) and in-vehicle devices, while ensuring normal operation and basic services in smart cockpits.
Implementing an access control method that uses system status and indication information to manage access requests from non-vehicle devices, allowing only authorized devices to connect with the control domain cockpit CDC, thereby minimizing interference and ensuring in-vehicle device functionality.
This approach ensures that in-vehicle devices operate normally and basic services function correctly by controlling access requests from non-vehicle devices, reducing the impact of interference and cabling constraints.
Smart Images

Figure 2025003986000001_ABST
Abstract
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 communications 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 life. As vehicles are increasingly used and more 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) of vehicles are constantly evolving. In the future, the driving of vehicles is very likely to be performed by machines, so that people do not need to use their hands and feet to drive. In addition to being a user's transportation device, a vehicle is one of the living spaces in daily life. By using smart cockpit technology, a large amount of functions, such as rich entertainment activities, audio and video playback, and 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] At present, smart cockpit mainly includes a cockpit domain controller (CDC), an in-vehicle device, and a non-in-vehicle device. The CDC is mainly connected to the in-vehicle device by wire, and the CDC is mainly connected to the non-in-vehicle device by wireless. However, since the CDC is connected to the in-vehicle device by wire, this method requires a large amount of cables, and therefore the cost is high. Due to the small space in the vehicle, the wiring becomes more difficult as the amount of in-vehicle devices increases. The wiring and high cost of the cables become a constraint on the development of smart cockpit technology. Therefore, wirelessly connecting the CDC with the in-vehicle device or the non-in-vehicle device becomes 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 in the field of universal transmission. An information element carrying system status information or access indication information is transmitted to indicate the current system state, so that after receiving the aforementioned information, the non-vehicle device judges whether to initiate a random access request. The access of the non-vehicle device is restricted in a certain phase. This avoids the impact caused by the initiation of a random access request performed by the non-vehicle device in this phase on the checking of the status of the vehicle device by the CDC and the access of the vehicle device. Also, this ensures that the vehicle device can run normally and some basic services can be run 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 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 broadcasting. 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 usually included in radio resource control (RRC) signaling. Optionally, the first indication information is transmitted by broadcasting.
[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 the access of 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 the access of 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 a control domain cockpit CDC or that the in-vehicle device is performing a self-check, and thus the non-in-vehicle device chooses 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 the at least one third device is permitted.
[0008] In a 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, where the access indication information 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 a priority of the at least one second device belongs to at least one priority indicated by the priority information.
[0011] In a 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 for a first reference frame or a time domain offset for 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 a specific signaling pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be a specific signaling defined in a protocol. For example, the first signaling may be an RRC signaling. There may be one or more time domain offsets.
[0014] 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.
[0015] In a possible implementation, there is a correspondence between the resources indicated by the resource indication information and a device type and / or a 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 be included instead.
[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 whether the second device is allowed 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 usually included in RRC signaling.
[0019] In a possible implementation, the first indication information is used to indicate whether access of the at least one third device is permitted.
[0020] In a 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, where the access indication information 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 a priority of the at least one second device belongs to at least one priority indicated by the priority information.
[0023] In a 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 for a first reference frame or a time domain offset for 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 a specific signaling pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be a specific signaling defined in a protocol. For example, the first signaling may be an RRC signaling. There may be one or more time domain offsets.
[0026] 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.
[0027] In a possible implementation, there is a correspondence between the resources indicated by the resource indication information and a device type and / or a 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 be included instead.
[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 may be a chip or integrated circuit in the first device. For example, the access control device is a control domain cockpit CDC, or the access control device is a chip or integrated circuit in 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 usually included in an 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 the access of 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 the access of 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 thus the non-in-vehicle device chooses 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 the at least one third device is permitted.
[0034] In a 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, where the access indication information 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 a priority of the at least one second device belongs to at least one priority indicated by the priority information.
[0037] In a 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 for a first reference frame or a time domain offset for 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 a specific signaling pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be a specific signaling defined in a protocol. For example, the first signaling may be an RRC signaling. There may be one or more time domain offsets.
[0040] 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.
[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 be included instead.
[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 in the second device. For example, the access device is a chip or integrated circuit in 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. 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 access of the 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 the RRC signaling.
[0045] In a possible implementation, the first indication information is used to indicate whether access of the at least one third device is permitted.
[0046] In a 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, where the access indication information 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 a priority of the at least one second device belongs to at least one priority indicated by the priority information.
[0049] In a 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 for a first reference frame or a time domain offset for 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 a specific signaling pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be a specific signaling defined in a protocol. For example, the first signaling may be an RRC signaling. There may be one or more time domain offsets.
[0052] 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.
[0053] In a possible implementation, there is a correspondence between the resources indicated by the resource indication information and a device type and / or a 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 be included instead.
[0055] In a possible implementation, the first device is a control domain cockpit CDC, the third device is an on-board device and the second device is a non-on-board 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 comprising 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 method according to the first and second aspects being performed when a program code included in the computer program product is executed by a processor in an electronic device.
[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] In a possible implementation, the access device according to any implementation of the fourth aspect is further included.
[0061] The present application provides an access control method and apparatus, and a communication system. Information elements carrying system status information, time thresholds, and / or access indication information are sent to indicate the current system state, so that after the non-vehicle device receives the aforementioned new information, the non-vehicle device judges whether to initiate a random access request. This avoids the impact caused by the initiation of a random access request performed by the non-vehicle device in this phase on the CDC's checking of the vehicle device's status and the vehicle device's access. This also ensures that the vehicle device can run normally and some basic services can run normally. [Brief description of the drawings]
[0062] [Figure 1] FIG. 2 is a schematic diagram of an application scenario according to an embodiment of the present application. [Diagram 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. [Diagram 3] FIG. 13 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. 13 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. [Diagram 5] 1 is a flow diagram 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 PREFERRED EMBODIMENTS
[0063] Hereinafter, the technical solutions of the embodiments of the present application will be described 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 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 CDC, on-board devices, and non-on-board devices. The on-board devices and non-on-board devices are two kinds of nodes with different attributes. The on-board devices may include, but are not limited to, any electronic devices in a vehicle, such as on-board microphones, on-board speakers, and on-board screens. Usually, the on-board devices are integrated by a vehicle / car manufacturer. The integration of the on-board devices and the CDC is usually performed by one vehicle manufacturer, so the connection relationship between the on-board devices 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 on-board devices 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 the non-vehicle devices by wire or wirelessly to control or manage the vehicle devices and the non-vehicle devices and provide various functions for the smart cockpit environment.
[0065] It will be understood that a vehicle is a means of transportation that moves on wheels on the ground, including but not limited to cars, scooters, trucks, buses, etc. The CDC is connected to an infotainment product installed in the vehicle and controls the infotainment product in the vehicle. In terms of function, the CDC allows a person to control the in-vehicle infotainment equipment and related devices, and may also be used to implement information communication between the vehicle and the external environment. It will be understood that the CDC is usually referred to as a control domain cockpit or a control domain cockpit CDC. As used in this application, "CDC", "control domain cockpit CDC", and "control domain cockpit" all have the same meaning.
[0066] For wireless connection, the control domain cockpit CDC is responsible for the overall management and coordination of radio resources and needs to arrange various kinds of devices for data transmission. Since 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 the property of the vehicle, and therefore the in-vehicle device can quickly perform authentication and access. However, the existence of the non-vehicle device is uncertain, and there is little pre-configured relevant information between the non-vehicle device and the control domain cockpit CDC. When the non-vehicle device is connected to the control domain cockpit CDC, procedures such as discovery, association, and security authentication are usually required to successfully connect and communicate. Therefore, when the in-vehicle device and the cockpit CDC are powered on, how to preferentially guarantee 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 as a priority and establish a connection with them. Any interruption of this process caused by the access of a non-in-vehicle device is not foreseen 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 on a priority basis.
[0068] It will be understood that "XX information" and "XX message" in this application have the same meaning.
[0069] Hereinafter, the technical solutions of the embodiments of the present application will be described in detail 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, on-board devices and non-on-board devices 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 logical functions. Master nodes manage slave nodes. Master nodes can schedule resources and are responsible for scheduling time-frequency resources for slave nodes. Slave nodes communicate with the master node using the time-frequency resources scheduled by the master node. Master nodes may be access control devices, for example, a control domain cockpit CDC, or another device with access control functions. Slave nodes may be access devices, for example, on-board devices or non-on-board devices.
[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 can be applied to the smart cockpit environment shown in FIG. 1, and can also be applied 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 can 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 types of the first device, the second device, and the 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, so that 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 or may be sent 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 a PBCH. The SIB is usually carried on an RRC signaling. It should be noted that in this specification, in all the embodiments of the present application, there is no restriction that the first indication information is carried only in a system message or sent by broadcast, and the first indication information may be sent by using another type of signaling.
[0080] Generally, frames of 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 communicate with each other, a communication link between the master node and the slave node needs to be established first so that corresponding operations such as security authentication and resource allocation can be performed on the communication link. Management frames are mainly used by the master node to manage the slave node, including, for example, establishing and releasing a connection between the master node and the slave node, performing security authentication, performing allocation of 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 node to the master node also need to be carried in the management frame.
[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 manner 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 manner.
[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-vehicle devices. The first indication message carries indication information, which may be the allocated resources for the in-vehicle devices or the non-vehicle devices, and is information used to indicate whether the in-vehicle devices or the non-vehicle devices are allowed to access the control domain cockpit CDC.
[0083] In some examples, the indication information may be represented by indicating whether the in-vehicle device or the non-in-vehicle device is permitted to access the control domain cockpit CDC. For example, the first indication message sent to the in-vehicle device A carries information representing "access to the control domain cockpit CDC is permitted", or the first indication message sent to the non-in-vehicle device B carries information representing "access to the control domain cockpit CDC is not permitted". The information may be represented by an information element or some 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 permitted 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 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 one bit may represent different indications. In another example, the system status indication information may alternatively be an enumeration type. Certainly, a person 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 application. When the corresponding resource is allocated to the in-vehicle device or the non-vehicle device, it means that the in-vehicle device or the non-vehicle device is allowed 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-vehicle device, and thus the in-vehicle device or the non-vehicle device transmits the response information on the allocated resource.
[0086] For example, when allocating corresponding response resources of devices to perform access, the control domain cockpit CDC may determine corresponding response resources of each device to perform access. The response resources may be a specific determined time-frequency resource. To ensure that the corresponding devices can transmit response information to the control domain cockpit CDC on the determined time-frequency resource, each device is allocated a corresponding time-frequency resource. 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 resource and the accessing device. In an example, the correspondence between the response resource and the accessing device may be explicit. For example, the correspondence between the response resource and the accessing device is directly carried in the system broadcast message. Indeed, in another example, the correspondence between the response resource and the accessing device may be implicit. For example, the accessing device may obtain the response resource of the accessing device based on a preconfigured identifier (e.g., ID), the time-frequency resource indicated in the system broadcast message, and a pre-set rule. In other words, the access device obtains, the preconfigured identifier (e.g., ID), the time-frequency resource indicated in the system broadcast message, and the response resource satisfy a preconfigured rule or mapping relationship. The preconfigured rule may be pre-agreed in the 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 when the accessing device last connects to the control device cockpit CDC. Indeed, the configured response resource 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 perform the access. It will be understood that the terminal devices to perform the access may be in-vehicle devices or non-vehicle devices. For example, the devices may be grouped based on the location of the device or the device type of the device. Usually, in-vehicle devices and non-vehicle devices at 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-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 indeed be performed according to any criteria. This is not limited in the present specification of the present application.
[0088] The control domain cockpit CDC groups terminal devices having the same characteristics into groups. An in-vehicle device is used as an example. The speakers and microphones in the back row in the smart cockpit environment may be classified into one group, and the speakers and microphones in the front row in the smart cockpit environment may be classified into another group, and so on. As another example, the speakers at all positions in the smart cockpit environment are classified into one group, and the microphones at all positions are classified into one group, and so on. Then, the control domain cockpit CDC 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, the terminal devices in the group may further determine the response resources of the terminal device from the response resources allocated to the group according to a certain rule. 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 an array. Usually, the physical locations of multiple terminal devices in an array are close, and there is a central node that manages the terminal devices in the array. For an 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 the 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 a problem such as damage or an error occurs on the in-vehicle device and 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 the example, the configuration information of the in-vehicle device may be configured before the vehicle is delivered from the 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. Since the probability of an exception occurring for an in-vehicle device is very low, when allocating the corresponding response resource for an in-vehicle device or a 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 transmits 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] For the on-board device, after receiving the first indication message sent by the control domain cockpit CDC, the on-board device may determine whether it is allowed to access the control domain cockpit CDC based on the first indication message. If the on-board device may obtain the response resource corresponding to the on-board device from the first indication message, the on-board device may be deemed to be allowed 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 on-board device may directly obtain the response resource corresponding to the on-board device from the first indication message. Indeed, if the correspondence between the response resource and the accessing device is implicit, each on-board 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 vehicle-mounted device, after obtaining the corresponding response resource, the vehicle-mounted device may generate a response message of the vehicle-mounted 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 replacement. 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 examples, it may be agreed in the protocol between the two parties that only devices in an abnormal state are reported. In this case, the response message may only include the device ID, and after receiving the device ID, the CDC may know that the device is in an abnormal state. Similarly, alternatively, it may be agreed in the protocol that only devices in a normal state are reported, and the details will not be described again in this specification.
[0098] In some examples, a device 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 "the state is normal" or "the state is abnormal" 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 classified into one group and allocated a shared response resource, and the group address is 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 on-board devices, the device group may be in the form of an array. For multiple on-board 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 device in the array, and 0 indicates an abnormal state of the device in the array. Indeed, in some other examples, 0 indicates a normal state of the device in the array, and 1 indicates an abnormal state of the device 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 percentage of normal or abnormal devices in the array. For example, when the percentage 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 that when the control domain cockpit CDC receives the response message, the control domain cockpit CDC determines which in-vehicle device is in an abnormal state. Since both the control domain cockpit CDC and the in-vehicle devices are usually manufactured by one vehicle manufacturer and installed in one vehicle, the control domain cockpit CDC may pre-store the ID of the in-vehicle device.
[0104] It will be appreciated that allocating shared response resources to multiple in-vehicle devices is appropriate since 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 only for the in-vehicle devices whose access is authorized and can send a response message, the 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 different on-board devices or arrays, 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 the time-frequency resource to the different on-board devices respectively, the response information further carries the 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 is 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, since the system broadcast message is usually sent periodically, the non-on-board device will still perform the operation according to the instructions of the first indication message.
[0113] It will be appreciated that receiving the 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, another possible system state may further 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 thus, the non-in-vehicle device chooses 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 a process by which the in-vehicle device accesses the control domain cockpit CDC. The response message sent from the in-vehicle device may be considered to some extent 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 the 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 permitted 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 permitted 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 permitted to access the control domain cockpit CDC, S207 may be executed if the non-vehicle device is not permitted to access the control domain cockpit CDC, or S208 may be executed if the non-vehicle device is permitted to access the control domain cockpit CDC, based on the information in the first indication message.
[0119] S206. Determine whether the system status is a preset system state. Note that this step is optional and only applies when the first indication message includes system status indication information. If the first indication message includes information that is used to directly indicate whether access is allowed, 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 status. This is not limited in the present specification of the present application. However, it will be understood that the in-vehicle device is performing device access when the system status is a preset system state in this example.
[0122] In another example, if the preset system state is a system execution state or an 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 status. This is not limited in this specification of the present application. It will be understood that when the system status is a preset system state in this example, the 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 the on-board device is performing a self-check or establishing a connection to the control domain cockpit CDC, non-on-board devices are prohibited from initiating random access requests. This avoids the impact caused by the initiation of random access requests performed by non-on-board devices in this phase on the check of the on-board device's status and on the on-board device's access by the control domain cockpit CDC. In this way, it is ensured that the on-board device can run normally and 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, a method of setting a time threshold may be used instead of the manner of determining the system status described in S201 of FIG. 2. For example, S301 may be executed.
[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 access to the control domain cockpit CDC is permitted. 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 the present application, and the first indication message may be transmitted in a broadcast, multicast, or any other equivalent manner. It will be understood that the present application mainly describes how to avoid the influence caused by the initiation of a random access request performed by a non-vehicle device in this phase on the check of the status of the in-vehicle device by the control domain cockpit CDC and the access of the in-vehicle device. Therefore, the in-vehicle device may ignore the time threshold information in the first indication message. Indeed, 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 particular fixed reference frame. For example, the fixed reference frame may be the first reference frame. The fixed reference frame may be frame 0, and certainly may alternatively be any other reference frame. Indeed, the time threshold may alternatively be a particular value or range of time. 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, for example, system frame number 256. When the non-vehicle device determines that the current system frame number is less than or equal to system frame number 256, the non-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 particular fixed reference frame. For example, the time domain offset may be 256 ms. The fixed reference frame may be pre-negotiated or agreed upon 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. The current frame number is assumed to be 20, and the current absolute time is assumed to be 10 ms. The non-in-vehicle device is not allowed to start access within the absolute time 256 ms + 64 x 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 a specific signaling that is pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or a specific signaling defined in a protocol. Take the specific RRC signaling as an example. The RRC signaling includes a 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 allowed to start access within a certain time frame after the control domain cockpit CDC transmits the SIB, because the control domain cockpit CDC may need to handle another issue 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 allowed to start random access to the CDC within the time frame [moment the CDC transmits the SIB + time domain offset 1, 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 window after acquiring a certain RRC signaling (e.g., a first RRC signaling), because the control domain cockpit CDC may need to handle other issues during this period of time. 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 window [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] In order to ensure that the on-board device is not affected by the access of the 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, when 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 the array of different non-on-board devices. This is not limited in this specification of the application. In another example, the expression format of the time threshold in the system broadcast message may be explicit, or certainly may be implicit. For the implementation process thereof, 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 after receiving the response message, the control domain cockpit CDC may reset the time thresholds of the different non-on-board devices. 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 on-board 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, the 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 the 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 permitted 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 the time threshold information carried in the system broadcast message, and whether the non-vehicle device is permitted 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 permitted to access the control domain cockpit CDC, S207 may be executed if the non-vehicle device is not permitted to access the control domain cockpit CDC, or S208 may be executed if the non-vehicle device is permitted to access the control domain cockpit CDC based on the information in the first indication message.
[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 allowed, it is not necessary to determine whether the time threshold reaches a time threshold.
[0151] In particular, the off-board 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 in this specification.
[0154] In this application, the system broadcast message carries time threshold information to ensure that the non-vehicle device is prohibited from initiating a random access request before the preset time threshold is reached, or the non-vehicle device is allowed to initiate a random access request after the preset time threshold is reached. 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 access of the vehicle device. In this way, it is ensured that the vehicle device 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] 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, in yet another case, the manner of setting the 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 the present 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 for device types and access relationships, in other words, the access indication information may indicate the mapping relationship between device types and access relationships. The mapping table or mapping relationship is used to indicate which types of devices can 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 on-board devices and non-on-board devices, or may be classified into microphones, speakers, mobile phones, etc., or may be classified into on-board devices that have previously been connected to the control domain cockpit CDC or on-board 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 application.
[0160] The mapping table for device types and access relationships may be explicit or implicit. For example, an explicit correspondence table, for example, Table 1, may be constructed. Please note 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, the 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 the access of the car microphone and the car speaker is permitted, and the access of the mobile phone is not permitted. Indeed, 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] If 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 of 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 the bitmap {001} is sent, it 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 for equivalent replacement. This is not limited in this specification of the present application.
[0163] In the example, furthermore, different kinds of devices may be different device priorities. The mapping table for device type and access relationship may be replaced by a mapping table based on device priority and access relationship. The mapping table is used to indicate whether devices of different priorities are allowed to initiate a random access request. It will be understood that, indeed, different kinds of devices may be the same device priority. Optionally, the device priority may be an access priority. Usually, a higher priority device may have a higher access priority. For example, the priority of the car microphone and the car speaker is 1, and the priority of the 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 there is a device group including multiple non-vehicle devices, the device group may be in the form of an array. For the array of different non-vehicle devices, a mapping table for device type and access relationship, or a mapping table based on device priority and access relationship may be set. This is not limited in this specification of the application. In another example, the expression format of the access indication information in the system broadcast message may be explicit, or indeed implicit. For the implementation process thereof, 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] The execution of S402 corresponds to the execution of S203. It will be understood that if the control domain cockpit CDC receives the response message and determines that all expected on-board devices are in a normal state. In this case, the control domain cockpit CDC may reset the access indication information and allow the access of the non-on-board device by sending a second indication message. Indeed, if the on-board 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-on-board device continues to perform the operation according to the instruction 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, the 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 the non-vehicle device, when 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 permitted 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 permitted to access the control domain cockpit CDC is determined based on the device type and the 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 permitted to access the control domain cockpit CDC, S207 may be executed if the non-vehicle device is not permitted to access the control domain cockpit CDC, or S208 may be executed if the non-vehicle device is permitted to access the control domain cockpit CDC based on the information in the first indication message.
[0173] S404. Determine whether the access indication information meets the preset condition. Note that this step is optional and only applies when the first indication message includes the access indication information. If the first indication message directly indicates whether the access is allowed, it is not necessary to determine whether the access indication information meets the preset condition.
[0174] Specifically, the non-vehicle device determines whether the device type of the non-vehicle device is permitted to initiate a random access request based on the device type and the access relationship determined in S403.
[0175] In an 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 authorized 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 authorized 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 in this specification.
[0177] In this application, the system broadcast message carries access indication information to ensure that only devices whose device type meets the preset condition are allowed to send random access requests, and devices whose device type does not meet the preset condition are prohibited from sending random access requests. This avoids the impact caused by the initiation of random access requests performed by non-vehicle devices on the CDC's checking of the status of the vehicle device and the access of the vehicle device. In this way, it is ensured that the vehicle device can run normally and some basic services can run 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] As shown in Figure 5, the present application provides an access control method. The interaction process 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 a first device is a first status.
[0182] S502. Send first indication information. 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 may be carried in a system message or sent 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 the access of 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 the access of 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 thus the non-in-vehicle device chooses 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 the at least one third device is permitted.
[0185] In a 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, where the access indication information is used to indicate whether access to the first device is permitted.
[0187] 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. 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 for a first reference frame or a time domain offset for 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 a specific signaling pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be a specific signaling defined in a protocol. For example, the first signaling may be an RRC signaling. There may be one or more time domain offsets.
[0190] 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.
[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 be included instead.
[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 process 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 usually 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 the at least one third device is permitted.
[0199] In a 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, where the access indication information is used to indicate whether access to the first device is permitted.
[0201] 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. 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 for a first reference frame or a time domain offset for 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 a specific signaling pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be a specific signaling defined in a protocol. For example, the first signaling may be an RRC signaling. There may be one or more time domain offsets. In a possible implementation, the first indication information includes resource indication information, and the resource indication information indicates a resource used for at least one third device, or the resource indicated by the resource indication information is 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 a device type and / or a 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 be included instead.
[0206] In a possible implementation, the first device is a control domain cockpit CDC, the third device is an on-board device and the second device is a non-on-board 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, etc. in 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 process of Fig. 2 to Fig. 4. The access control device 700 includes: a processing unit 701 configured to determine that the status of the first device is a first status; and a sending unit 702 configured to send first indication information, the first indication information being used to indicate whether the access of at least one second device to the first device is allowed. Optionally, the first indication information is carried in a system message or sent by broadcast. The first indication information may be a MIB, a SIB, or a broadcast frame. The MIB may be carried on the PBCH. The SIB is usually included in the RRC signaling. Optionally, the first indication information is sent 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 the access of 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 the access of 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 thus the non-in-vehicle device chooses 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 this case, the access of 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 the at least one third device is permitted.
[0213] In a 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, where the access indication information is used to indicate whether access to the first device is permitted.
[0215] 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. 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 for a first reference frame or a time domain offset for 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 a specific signaling pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be a specific signaling defined in a protocol. For example, the first signaling may be an RRC signaling. There may be one or more time domain offsets.
[0218] 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.
[0219] In a possible implementation, there is a correspondence between the resources indicated by the resource indication information and a device type and / or a 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 be included instead.
[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] As shown in FIG. 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., in the second device or the third device, for example, a chip or internal component in the 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 process of Fig. 2 to Fig. 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 the access of the 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 sent 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 the RRC signaling.
[0225] In a possible implementation, the first indication information is used to indicate whether access of the at least one third device is permitted.
[0226] In a 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, where the access indication information is used to indicate whether access to the first device is permitted.
[0228] 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. 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 for a first reference frame or a time domain offset for 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 a specific signaling pre-agreed or negotiated between the control domain cockpit CDC and the non-vehicle device, or may be a specific signaling defined in a protocol. For example, the first signaling may be an RRC signaling. There may be one or more time domain offsets.
[0231] 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.
[0232] In a possible implementation, there is a correspondence between the resources indicated by the resource indication information and a device type and / or a 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 be included instead.
[0234] In a possible implementation, the first device is a control domain cockpit CDC, the third device is an on-board device and the second device is a non-on-board 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 Fig. 9, the present application provides a communication system 900. The communication system 900 includes the access control device 700 shown in Fig. 7.
[0238] The access control device 700 includes at least one processor and a communication interface. In addition, 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 executed, the processor executes the instructions such that 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 such that, when executed, the processor executes the instructions such that the processor can perform the functions of the access device 800.
[0248] In a possible implementation, the access device 800 may be a chip capable of implementing the functions of FIG.
[0249] The present application further provides a transport device or an intelligent device, for example an unmanned aerial vehicle, an automobile, an automated guided vehicle, or a robot. The transport device or the intelligent device includes the access control device described above. Furthermore, optionally, the transport device further includes the access device described above.
[0250] The present application provides an access control method and apparatus, and a communication system. A system broadcast message carrying system status information, a time threshold, and / or access indication information is sent, so that after a non-vehicle device receives the system broadcast message, the non-vehicle device judges 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 caused by the initiation of a random access request performed by a non-vehicle device in this phase on the checking of the status of the vehicle device by the CDC and the access of the vehicle device. In this way, it is ensured that the vehicle device can run normally and some basic services can run 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 in a computer-readable medium or transmitted as one or more instructions or codes 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 method or algorithm according to the embodiments disclosed herein may be implemented by hardware, a software module executed by a processor, or a combination thereof. The software module may be configured in a random access memory (RAM), memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, 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 specific implementation, the objectives, technical solutions and beneficial effects of the present application are described in more 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 Transmitter Unit 800 Access Device 801 Receiver Unit 802 Processing Unit 900 Communication Systems
Claims
1. 1. A method for access control, comprising: determining that a status of a first device is a first status; and a step of transmitting 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.
2. 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 the at least one second device is not allowed to access; or 2. The access control method of claim 1, wherein 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 of the second device is permitted.
3. 3. The access control method according to claim 1 or 2, wherein the first indication information is used to indicate whether access of at least one third device is permitted.
4. The access control method according to any one of claims 1 to 3, wherein the first indication information includes device type information, and the device type of the at least one second device belongs to at least one device type indicated by the device type information.
5. The access control method according to claim 4, wherein 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.
6. 5. An access control method according to claim 1, wherein 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.
7. The access control method according to claim 6, wherein 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.
8. 7. The access control method according to claim 4, wherein the first indication information includes first time information, and the first time information is used to indicate that the at least one second device is not allowed to access the first device within a first time range.
9. 9. The method of claim 8, 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.
10. 10. The access control method according to claim 1, wherein the first indication information includes resource indication information, the resource indication information indicating a resource used for the at least one third device, or the resource indicated by the resource indication information is not used for the at least one second device.
11. The access control method according to claim 10, wherein there is a correspondence between the resource indicated by the resource indication information and a device type and / or a priority of the at least one third device.
12. The access control method according to claim 1 , wherein the first indication information includes a Boolean variable or an enumeration variable.
13. The access control method of any one of claims 4, 5 and 11, wherein the device types include at least one of an in-vehicle device and a non-in-vehicle device.
14. 1. A method of accessing a computer-readable medium, comprising: receiving a first indication from a first device; determining whether access of a second device to the first device is permitted based on the first indication information.
15. The access method according to claim 14, wherein the first indication information is used to indicate whether access of at least one third device is permitted.
16. The access method according to claim 14 or 15, wherein the first indication information includes device type information, and the device type of the at least one second device belongs to at least one device type indicated by the device type information.
17. The access method of claim 16, wherein 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.
18. The access method according to any one of claims 14 to 17, wherein 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.
19. 20. The access method of claim 18, wherein 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.
20. 20. The access method according to claim 14, wherein the first indication information includes first time information, and the first time information is used to indicate that the at least one second device is not allowed to access the first device within a first time range.
21. 21. The method of claim 20, 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.
22. 22. The access method according to claim 14, wherein the first indication information includes resource indication information, the resource indication information indicating a resource used for the at least one third device, or the resource indicated by the resource indication information is not used for the at least one second device.
23. The access method according to claim 22, wherein there is a correspondence between the resource indicated by the resource indication information and a device type and / or a priority of the at least one third device.
24. 24. The method of claim 14, wherein the first indication information comprises a Boolean variable or an enumeration variable.
25. 25. The access method according to claim 14, wherein 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.
26. 26. The method of claim 25, wherein the second device is a mobile phone.
27. An access control device, a processing unit configured to determine a status of the first device to be a first status; 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; and
28. 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 the at least one second device is not allowed to access; or 28. The access control device of claim 27, wherein 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 of the second device is permitted.
29. The access control device according to claim 27, wherein the first indication information is used to indicate whether access of at least one third device is permitted.
30. 30. The apparatus of claim 27, wherein the first indication information includes device type information, and the device type of the at least one second device belongs to at least one device type indicated by the device type information.
31. 31. The apparatus of claim 30, wherein the first indication information further includes access indication information, the access indication information being used to indicate whether access to the first device is permitted.
32. 31. The apparatus of claim 27, wherein the first indication information includes priority information, and a priority of the at least one second device belongs to at least one priority indicated by the priority information.
33. 33. The apparatus of claim 32, wherein the first indication information further includes access indication information, the access indication information being used to indicate whether access to the first device is permitted.
34. 33. The apparatus of claim 30, wherein the first indication information comprises first time information, the first time information being used to indicate that the at least one second device is not authorized to access the first device within a first time range.
35. 35. The apparatus of claim 34, 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.
36. 36. The apparatus of claim 27, wherein the first indication information includes resource indication information, the resource indication information indicating a resource used for the at least one third device, or the resource indicated by the resource indication information is not used for the at least one second device.
37. 37. The apparatus of claim 36, wherein a correspondence exists between the resources indicated by the resource indication information and a device type and / or a priority of the at least one third device.
38. 38. The apparatus of claim 27, wherein the first indication information comprises a Boolean variable or an enumerated variable.
39. 38. The apparatus of any one of claims 30, 31 and 37, wherein the device type includes at least one of an in-vehicle device and a non-in-vehicle device.
40. A receiving unit and a processing unit, The receiving unit is configured to receive first indication information from a first device; The access apparatus, wherein the processing unit is configured to determine, based on the first indication information, whether access of a second device to the first device is permitted.
41. 41. The apparatus of claim 40, wherein the first indication information is used to indicate whether access of at least one third device is permitted.
42. 42. The apparatus according to claim 40 or 41, wherein the first indication information includes device type information, and a device type of the at least one second device belongs to at least one device type indicated by the device type information.
43. 43. The apparatus of claim 42, wherein the first indication information further includes access indication information, the access indication information being used to indicate whether access to the first device is permitted.
44. 44. The apparatus of claim 40, wherein the first indication information includes priority information, and a priority of the at least one second device belongs to at least one priority indicated by the priority information.
45. 45. The apparatus of claim 44, wherein the first indication information further includes access indication information, the access indication information being used to indicate whether access to the first device is permitted.
46. 46. The apparatus of claim 40, wherein the first indication information comprises first time information, the first time information being used to indicate that the at least one second device is not authorized to access the first device within a first time range.
47. 47. The apparatus of claim 46, 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.
48. 48. The apparatus of claim 40, wherein the first indication information includes resource indication information, the resource indication information indicating a resource used for the at least one third device, or the resource indicated by the resource indication information is not used for the at least one second device.
49. 49. The apparatus of claim 48, wherein a correspondence exists between the resources indicated by the resource indication information and a device type and / or a priority of the at least one third device.
50. 50. The apparatus of claim 40, wherein the first indication information comprises a Boolean variable or an enumerated variable.
51. 51. The apparatus of any one of claims 40 to 50, wherein the first device is a control domain cockpit CDC, the third device is an on-board device, and the second device is a non-on-board device.
52. 52. The apparatus of claim 51, wherein the second device is a mobile phone.
53. 27. A computer storage medium containing computer instructions which, when executed by at least one processor, performs the method of any one of claims 1 to 26.
54. A computer program product, the method of any one of claims 1 to 26 being performed when program code contained in the computer program product is executed by a processor in an electronic device.
55. A communication system comprising an access control device according to any one of claims 27 to 39.
56. A communication system according to claim 55, further comprising an access device according to any one of claims 40 to 52.
Citation Information
Patent Citations
Base station and control method thereof
JP2016195448A
Access control in new radio
WO2018184512A1
Access category and establishment cause
WO2018203263A1
Method and apparatus for performing access barring check
WO2018236196A1