A method and system for door lock and mobile terminal secure session

Abstract

This invention discloses a method and system for secure communication between a door lock and a mobile terminal. The method includes: periodically collecting the Bluetooth signal strength of mobile terminals within the coverage area of ​​a unit door lock, dividing the signal strength into preset levels and generating corresponding connection states, then encapsulating these into IGMP join messages and sending them to a specific multicast address; upon receiving the IGMP join message, the door lock gateway registers or refreshes the unit door lock IP, connection state, and local forwarding interface corresponding to the Bluetooth address in its maintained Bluetooth address binding table; based on a voice call request initiated by an indoor extension, constructing a multicast message, forwarding it via a router network, and having the aggregation point RP transmit it in reverse along the established (S,G) table entry path according to the (S,G) multicast tree. Using this invention, a fast, accurate, and secure direct session can be established between the door lock and the mobile terminal, reducing communication latency and dependence on external networks.

Description

Technical Field

[0001] This invention belongs to the field of smart door lock technology, and in particular to a method and system for secure communication between a door lock and a mobile device. Background Technology

[0002] With the increasing prevalence of smart homes and community security systems, the demand for intelligent and convenient access control systems is growing. Currently, the interaction between door locks and mobile terminals (such as smartphones) primarily relies on direct Bluetooth pairing or remote communication based on a central server. The former has limited communication distance and cannot establish stable, cross-regional sessions in complex building environments; the latter depends on external networks and cloud relays, resulting in high latency, privacy risks, and single points of failure. Especially in real-time interaction scenarios requiring low latency and high security, such as visitor voice calls and remote door opening, existing solutions struggle to balance efficiency, reliability, and privacy protection. Therefore, the industry urgently needs a new method that can utilize local networks to achieve rapid and accurate device discovery and secure direct communication to improve user experience and overall system security. Summary of the Invention

[0003] The purpose of this invention is to provide a method and system for secure communication between a door lock and a mobile terminal, in order to overcome the shortcomings of the prior art, and to enable fast, accurate and secure direct communication between the door lock and the mobile terminal, thereby reducing communication latency and dependence on external networks.

[0004] One embodiment of this application provides a method for secure conversation between a door lock and a mobile device, the method comprising:

[0005] Bluetooth signal sensing and status reporting: The unit door lock periodically collects the Bluetooth signal strength of mobile devices within its coverage area, divides the signal strength into preset levels and generates corresponding connection statuses, and then encapsulates them into IGMP join messages carrying the Bluetooth address, unit door lock IP and connection status, and sends them to a specific multicast address.

[0006] Bluetooth address binding table dynamic maintenance: Based on the IGMP join message received by the door lock gateway, and according to the preset conflict arbitration and priority rules, the door lock IP, connection status and local forwarding interface corresponding to the Bluetooth address are registered or refreshed in the Bluetooth address binding table it maintains;

[0007] Establishment of the voice call multicast tree: Based on the voice call request initiated by the indoor extension, a multicast message carrying the target mobile terminal Bluetooth address and message urgency level is constructed, forwarded through the router network, and the aggregation point RP establishes a (S,G) source multicast tree from the indoor extension to the corresponding unit door lock according to the Bluetooth address binding table.

[0008] Implementation of bidirectional secure communication: According to the (S,G) multicast tree, the indoor extension sends voice data to the unit door lock via multicast. The unit door lock then constructs a reply message with the source address being the multicast address and the destination address being the unicast IP of the indoor extension, and transmits it in reverse along the established (S,G) table path to complete the bidirectional secure session.

[0009] Optionally, the Bluetooth signal sensing and status reporting includes:

[0010] Signal acquisition and level classification: Based on the Bluetooth signal received by the unit door lock in real time, the received signal strength indicator RSSI is obtained, and the RSSI is divided into three levels according to the preset threshold: first level stable, second level unstable, and third level weak, to obtain the corresponding signal level.

[0011] Connection status determination: Based on the signal strength and network monitoring results, the connection status with the Bluetooth address is determined: the first level is the linking state when there is no conflict, the second level is the standby state, and the third level is the alive state.

[0012] Local conflict avoidance: Before determining the first-level linking state, listen to the multicast announcements issued by other unit locks in the network. If it is found that the Bluetooth address has been declared as linking by other locks, the declaration is abandoned to avoid connection conflicts.

[0013] Periodic multicast announcement: Based on the determined connection status, the Bluetooth address, the IP address of the door lock of this unit, and the connection status are periodically encapsulated into an IGMP join message and sent to the specific multicast address to complete the status announcement.

[0014] Optionally, the Bluetooth address binding table is dynamically maintained, including:

[0015] Binding entry registration: Based on the first IGMP join message received by the door lock gateway for a certain Bluetooth address, register the Bluetooth address and its reported unit door lock IP, connection status, and local forwarding interface in the Bluetooth address binding table corresponding to the multicast address;

[0016] Same IP refresh: If the Bluetooth address in the subsequently received IGMP join message matches the entry in the table and the reported unit door lock IP is the same, then refresh the connection status and aging time in that entry.

[0017] IP contention resolution: If the Bluetooth address in the subsequently received IGMP join message matches the entry in the table but the reported unit lock IP is different, the resolution will be made according to the signal level priority and the specific rules of the same level, with the first level priority > the second level priority > the third level priority: If the new and old signals both belong to the first level, the original unit lock IP will remain unchanged; if the new and old signals both belong to the second level, the newly reported unit lock IP and interface will replace the original record; if the new and old signals both belong to the third level, the new unit lock IP and interface will be recorded incrementally.

[0018] Binding table synchronization: When the Bluetooth address binding table changes, the door lock gateway sends a (*,G) join message to the RP, causing the upstream router to update the multicast forwarding table outgoing interface information.

[0019] Optionally, the establishment of the voice call multicast tree includes:

[0020] Call request multicast encapsulation: Based on the voice call initiated by the indoor extension, the target mobile terminal Bluetooth address and the message urgency flag are encapsulated into an RTSP / RTP multicast message with the destination address being the specific multicast address.

[0021] Source multicast tree hop-by-hop establishment: Based on the forwarding of the multicast message in the router network, each router creates or matches a (S,G1) forwarding table entry based on the source IP (S) and multicast address (G1), with its outgoing interface facing the RP, thereby establishing a (S,G1) path from the indoor extension to the RP hop-by-hop.

[0022] RP Binding Table Query and Forwarding: Based on the multicast message received by the RP, extract the Bluetooth address carried in it, query the binding information that is synchronously updated from the door lock gateway, determine the unit door lock IP and connection status currently associated with the Bluetooth address, and set the outgoing interface of the (S,G1) table entry to point to the interface of the door lock gateway where the unit door lock is located.

[0023] Door lock gateway precise delivery: Based on the multicast message forwarded by the RP received by the door lock gateway, query the local Bluetooth address binding table:

[0024] If the connection status is linking or standby, the message will be sent from the corresponding local forwarding interface to the target unit door lock; if the connection status is alive, the message will be broadcast from all associated interfaces only when the message urgency flag is set.

[0025] Optionally, the implementation of the bidirectional secure communication includes:

[0026] Reverse unicast message construction: Based on the unit door lock's need to reply with voice data to the indoor extension, construct a reply message with the source IP address being the specific multicast address (G1), the destination IP address being the indoor extension's unicast IP, and the port number being interchanged with the received message;

[0027] Reverse routing based on (S,G) entries: According to the reply message received by the routers along the way with the source address as a multicast address, check whether there is a corresponding (S,G1) entry on the local machine. If it exists, forward it according to the RPF interface of the entry, and thus send it to the indoor extension gateway in reverse along the established (S,G1) multicast tree path.

[0028] Security verification: When the router performs reverse path forwarding RPF checks on packets with multicast source IP addresses, a specific rule is added: if a corresponding (S,G) entry exists, the packet is forwarded according to the entry; otherwise, it is considered an attack packet and discarded.

[0029] Optionally, the method further includes an anomaly and aging handling mechanisms:

[0030] Connection status aging: Based on the linking pairing information of other door locks in the network recorded locally by the unit door lock, an aging time is set, and the information is automatically cleared after the timeout to avoid outdated information interfering with conflict judgments;

[0031] Binding entry aging: If no IGMP join message to refresh the Bluetooth address is received within a set period, the entry in the Bluetooth address binding table maintained by the door lock gateway will be automatically aged out and deleted.

[0032] Another embodiment of this application provides a system for secure communication between a door lock and a mobile device, the system comprising:

[0033] The reporting module is used for Bluetooth signal sensing and status reporting: it periodically collects the Bluetooth signal strength of mobile terminals in the coverage area of ​​the unit door lock, divides the signal strength into preset levels and generates corresponding connection statuses, and then encapsulates them into IGMP join messages carrying the Bluetooth address, unit door lock IP and connection status, and sends them to a specific multicast address.

[0034] The maintenance module is used for dynamic maintenance of the Bluetooth address binding table: based on the IGMP join message received by the door lock gateway, and according to the preset conflict arbitration and priority rules, it registers or refreshes the unit door lock IP, connection status and local forwarding interface corresponding to the Bluetooth address in the Bluetooth address binding table it maintains;

[0035] The module is used to establish a voice call multicast tree: based on the voice call request initiated by the indoor extension, a multicast message carrying the target mobile terminal Bluetooth address and message urgency level is constructed, forwarded through the router network, and the aggregation point RP establishes a (S,G) source multicast tree from the indoor extension to the corresponding unit door lock according to the Bluetooth address binding table.

[0036] The communication module is used to implement two-way secure communication: According to the (S,G) multicast tree, the indoor extension sends voice data to the unit door lock via multicast. The unit door lock then constructs a reply message with the source address being the multicast address and the destination address being the unicast IP of the indoor extension, and transmits it in reverse along the established (S,G) table path to complete the two-way secure session.

[0037] Another embodiment of this application provides a storage medium storing a computer program, wherein the computer program is configured to execute the method described in any of the preceding claims when running.

[0038] Another embodiment of this application provides an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described in any of the preceding claims.

[0039] Compared with existing technologies, the present invention provides a method for secure communication between a door lock and a mobile terminal. This method involves periodically collecting Bluetooth signal strength data from mobile terminals within the coverage area of ​​the unit door lock, dividing the signal strength into preset levels and generating corresponding connection states, then encapsulating these into IGMP join messages and sending them to a specific multicast address. Upon receiving the IGMP join message, the door lock gateway registers or refreshes the unit door lock IP address, connection state, and local forwarding interface corresponding to the Bluetooth address in its maintained Bluetooth address binding table. Based on a voice call request initiated by an indoor extension, a multicast message is constructed, forwarded via the router network, and transmitted by the aggregation point RP according to the Bluetooth address binding table. Following the established (S,G) multicast tree, the message is transmitted in reverse along the established (S,G) table entry path to complete a two-way secure session. This enables fast, accurate, and secure direct session establishment between the door lock and the mobile terminal, reducing communication latency and dependence on external networks. Attached Figure Description

[0040] Figure 1 A hardware structure block diagram of a computer terminal for a method of secure conversation between a door lock and a mobile terminal provided in an embodiment of the present invention;

[0041] Figure 2 A flowchart illustrating a method for secure communication between a door lock and a mobile device, provided in an embodiment of the present invention;

[0042] Figure 3A schematic diagram illustrating the network relationship between a door lock and a mobile terminal secure session, provided as an embodiment of the present invention;

[0043] Figure 4 This is a schematic diagram of the structure of a system for secure communication between a door lock and a mobile terminal, provided as an embodiment of the present invention. Detailed Implementation

[0044] The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0045] Family members push strollers around the community. The strollers have Bluetooth addresses, and the unit door locks integrate voice call functionality, allowing for voice calls with the unit's extension. The nearest unit door lock detects the Bluetooth address and notifies the resident's extension, who can then use their extension to communicate with the unit door lock. The voice call also moves in real-time as the family members move with the stroller.

[0046] Indoor call extensions typically only allow one-to-one communication with the unit door lock. If a family member is walking around the neighborhood with a stroller, voice communication between the family member inside the unit and the family member in the stroller can only be achieved using mobile communication devices such as cell phones. If the mobile communication device is out of power or is muted and cannot be heard, crucial and timely voice calls can easily be missed. This invention designs a method and system for the door lock to sense the stroller's signal in real time and communicate with it, completing the establishment and calling of mobile communication without the involvement of a central server.

[0047] This invention first provides a method for secure communication between a door lock and a mobile device. This method can be applied to electronic devices, such as computer terminals, specifically ordinary computers.

[0048] The following detailed explanation uses a computer terminal as an example. Figure 1 This is a hardware structure block diagram of a computer terminal for a method of secure conversation between a door lock and a mobile terminal, provided in an embodiment of the present invention. Figure 1 As shown, the computer device includes a processor, memory, and network interface connected via a system bus, wherein the memory may include non-volatile storage media and internal memory.

[0049] Non-volatile storage media can store operating systems and computer programs. These computer programs include program instructions that, when executed, cause the processor to perform any method of door lock and mobile security session.

[0050] The processor provides computing and control capabilities, supporting the operation of the entire computer device.

[0051] Internal memory provides an environment for the execution of computer programs in non-volatile storage media. When executed by a processor, the computer program enables the processor to perform any method of door lock and mobile security session.

[0052] This network interface is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 1 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0053] It should be understood that the processor can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among these, a general-purpose processor can be a microprocessor or any conventional processor.

[0054] See Figure 2 The present invention provides a method for secure communication between a door lock and a mobile device, which may include the following steps:

[0055] S201, Bluetooth signal sensing and status reporting: Based on the periodic collection of Bluetooth signal strength of mobile devices within the coverage area of ​​the unit door lock, the signal strength is divided into preset levels and corresponding connection states are generated. This is then encapsulated into an IGMP join message carrying the Bluetooth address, unit door lock IP, and connection state, and sent to a specific multicast address. Specifically, the Bluetooth signal sensing and status reporting includes:

[0056] Signal acquisition and level classification: Based on the Bluetooth signal received by the unit door lock in real time, the received signal strength indicator RSSI is obtained, and the RSSI is divided into three levels according to the preset threshold: first level stable, second level unstable, and third level weak, to obtain the corresponding signal level.

[0057] Connection status determination: Based on the signal strength and network monitoring results, the connection status with the Bluetooth address is determined: the first level is the linking state when there is no conflict, the second level is the standby state, and the third level is the alive state.

[0058] Local conflict avoidance: Before determining the first-level linking state, listen to the multicast announcements issued by other unit locks in the network. If it is found that the Bluetooth address has been declared as linking by other locks, the declaration is abandoned to avoid connection conflicts.

[0059] Periodic multicast announcement: Based on the determined connection status, the Bluetooth address, the IP address of the door lock of this unit, and the connection status are periodically encapsulated into an IGMP join message and sent to the specific multicast address to complete the status announcement.

[0060] S202, Dynamic Maintenance of Bluetooth Address Binding Table: Based on the IGMP join message received by the door lock gateway, and according to the preset conflict arbitration and priority rules, the gateway registers or refreshes the unit door lock IP, connection status, and local forwarding interface corresponding to the Bluetooth address in its maintained Bluetooth address binding table; specifically, the dynamic maintenance of the Bluetooth address binding table includes:

[0061] Binding entry registration: Based on the first IGMP join message received by the door lock gateway for a certain Bluetooth address, register the Bluetooth address and its reported unit door lock IP, connection status, and local forwarding interface in the Bluetooth address binding table corresponding to the multicast address;

[0062] Same IP refresh: If the Bluetooth address in the subsequently received IGMP join message matches the entry in the table and the reported unit door lock IP is the same, then refresh the connection status and aging time in that entry.

[0063] IP contention resolution: If the Bluetooth address in the subsequently received IGMP join message matches the entry in the table but the reported unit lock IP is different, the resolution will be made according to the signal level priority and the specific rules of the same level, with the first level priority > the second level priority > the third level priority: If the new and old signals both belong to the first level, the original unit lock IP will remain unchanged; if the new and old signals both belong to the second level, the newly reported unit lock IP and interface will replace the original record; if the new and old signals both belong to the third level, the new unit lock IP and interface will be recorded incrementally.

[0064] Binding table synchronization: When the Bluetooth address binding table changes, the door lock gateway sends a (*,G) join message to the RP, causing the upstream router to update the multicast forwarding table outgoing interface information.

[0065] S203, Establishment of the voice call multicast tree: Based on the voice call request initiated by the indoor extension, a multicast message carrying the target mobile terminal's Bluetooth address and message urgency level is constructed, forwarded via the router network, and the aggregation point RP establishes a (S,G) source multicast tree from the indoor extension to the corresponding unit door lock according to the Bluetooth address binding table; specifically, the establishment of the voice call multicast tree includes:

[0066] Call request multicast encapsulation: Based on the voice call initiated by the indoor extension, the target mobile terminal Bluetooth address and the message urgency flag are encapsulated into an RTSP / RTP multicast message with the destination address being the specific multicast address.

[0067] Source multicast tree hop-by-hop establishment: Based on the forwarding of the multicast message in the router network, each router creates or matches a (S,G1) forwarding table entry based on the source IP (S) and multicast address (G1), with its outgoing interface facing the RP, thereby establishing a (S,G1) path from the indoor extension to the RP hop-by-hop.

[0068] RP Binding Table Query and Forwarding: Based on the multicast message received by the RP, extract the Bluetooth address carried in it, query the binding information that is synchronously updated from the door lock gateway, determine the unit door lock IP and connection status currently associated with the Bluetooth address, and set the outgoing interface of the (S,G1) table entry to point to the interface of the door lock gateway where the unit door lock is located.

[0069] Door lock gateway precise delivery: Based on the multicast message forwarded by the RP received by the door lock gateway, query the local Bluetooth address binding table:

[0070] If the connection status is linking or standby, the message will be sent from the corresponding local forwarding interface to the target unit door lock; if the connection status is alive, the message will be broadcast from all associated interfaces only when the message urgency flag is set.

[0071] S204, Implementation of bidirectional secure communication: According to the (S,G) multicast tree, the indoor extension sends voice data to the unit door lock via multicast. The unit door lock then constructs a reply message with the source address being the multicast address and the destination address being the unicast IP of the indoor extension, and transmits it in reverse along the established (S,G) table path to complete the bidirectional secure session. Specifically, the implementation of the bidirectional secure communication includes:

[0072] Reverse unicast message construction: Based on the unit door lock's need to reply with voice data to the indoor extension, construct a reply message with the source IP address being the specific multicast address (G1), the destination IP address being the indoor extension's unicast IP, and the port number being interchanged with the received message;

[0073] Reverse routing based on (S,G) entries: According to the reply message received by the routers along the way with the source address as a multicast address, check whether there is a corresponding (S,G1) entry on the local machine. If it exists, forward it according to the RPF interface of the entry, and thus send it to the indoor extension gateway in reverse along the established (S,G1) multicast tree path.

[0074] Security verification: When the router performs reverse path forwarding RPF checks on packets with multicast source IP addresses, a specific rule is added: if a corresponding (S,G) entry exists, the packet is forwarded according to the entry; otherwise, it is considered an attack packet and discarded.

[0075] Furthermore, the method also includes anomaly and aging handling mechanisms:

[0076] Connection status aging: Based on the linking pairing information of other door locks in the network recorded locally by the unit door lock, an aging time is set, and the information is automatically cleared after the timeout to avoid outdated information interfering with conflict judgments;

[0077] Binding entry aging: If no IGMP join message to refresh the Bluetooth address is received within a set period, the entry in the Bluetooth address binding table maintained by the door lock gateway will be automatically aged out and deleted.

[0078] I. Technical Solution

[0079] 1. Core idea:

[0080] 1. The unit door lock senses the signal on the Bluetooth address of the stroller in real time and performs mutual preemption according to the dual threshold strategy;

[0081] 2. The unit door lock listens to and records the correspondence between the Bluetooth addresses of all devices in the linking state on the network and the unit door lock's IP address, and then ages out after 10 seconds;

[0082] 3. The unit door lock periodically (every 10 seconds) sends an IGMP join message to a specific multicast address based on the real-time collected RSSI level, carrying the Bluetooth address, unit door lock IP, and connection status announcement;

[0083] 4. After receiving the IGMP join message, the unit door lock gateway registers or refreshes the Bluetooth address and its corresponding unit door lock IP, connection status, and local forwarding interface on the forwarding table of the specific multicast address. If the unit door lock IPs are the same (the originally bound unit door lock refreshes the RSSI signal), the RSSI level is refreshed. If the unit door lock IPs are different (the stroller moves or is collected by other unit door locks), if the RSSIs are both in the first level, the original signal connection is maintained (i.e., the original bound door lock is maintained). If the RSSIs are both in the second level, a replacement refresh is performed (i.e., the new unit door lock replaces the old unit door lock). If the RSSIs are both in the third level, an incremental refresh is performed (i.e., the new and old unit door locks coexist, in response to emergency communication).

[0084] 5. Voice calls initiated by indoor extensions carry RTSP sessions via a specific multicast address, while also carrying the Bluetooth address and message urgency level.

[0085] 6. The unit door lock gateway extracts the Bluetooth address from the multicast data and compares it with the forwarding table of the specific multicast address to find the unit door lock IP, connection status, and local forwarding interface corresponding to the Bluetooth address. At this point, (S,G) entries are established along the route from the indoor extension to the unit door lock.

[0086] 7. After receiving multicast data from the indoor extension unit, the unit door lock replies using a specific unicast 5-tuple communication method. The source address is the multicast group, and the destination address is the unicast IP address of the indoor extension unit.

[0087] 8. Traditional routers forward data based on the (S,G) table entries, forwarding it from the RPF interface to the indoor extension unit along that path.

[0088] 2. The complete technical implementation process is as follows:

[0089] (1) Pre-set conditions

[0090] a. Each stroller has a Bluetooth address and is linked to the in-home call extension of the household where the stroller is located;

[0091] b. The outdoor unit door locks on each floor can detect Bluetooth signals in real time and record the RSSI signal of the Bluetooth address and its Bluetooth address;

[0092] c. All routers within the community have already completed network formation via PIM, such as... Figure 3In this network configuration, router A is the RP of this multicast network, router D is the door lock gateway for outdoor unit door locks A, B, and C, router E is the door lock gateway for outdoor unit door locks D, E, and F, router B is the extension gateway for indoor call extension A, and router C is the extension gateway for indoor call extension B. The stroller A corresponding to indoor call extension A is moving around outdoor unit door lock F, the stroller B corresponding to indoor call extension B is moving from outdoor unit door lock A to E, and the stroller C is moving away from this area.

[0093] (2) The signal competition and connection mechanism between the outdoor unit door lock and the stroller can be completed in the following steps:

[0094] ① When a unit door lock sends an IGMP join message to a specific multicast group address G1 (e.g., 239.1.2.3), the unit door lock gateway creates a (*, G1) entry and simultaneously sends a (*, G1) join message to the RP. As a result, all routers from the unit door lock gateway to the RP create (*, G1) entries, and all unit door locks in the PIM network can listen for messages at this multicast address.

[0095] ② The unit door lock senses the Bluetooth address and signal on the stroller in real time, classifies the Received Signal Strength Indicator (RSSI) into three levels, and records them as shown in Table 1 below:

[0096] 1) The third level is characterized by weak signal and occasional connection. The RSSI value range is ≤ -76 dBm. The signal is very weak and can only establish occasional connections over very short distances or under specific conditions. The data acquisition failure rate is high (< 80%), and communication is impossible most of the time.

[0097] 2) The second level is unstable and prone to disconnection. The RSSI value ranges from -61 dBm to -75 dBm. The signal strength is moderately weak, the communication quality is unstable, and connection interruptions, data loss, or repeated connection attempts are common.

[0098] 3) First level: stable and reliable, RSSI value range ≥ -60 dBm, high and continuous stable signal strength between Bluetooth address and reading device, almost no communication interruption, and high data transmission integrity rate.

[0099] 4) For example Figure 3 In the network configuration, unit door locks A and B detected that stroller B's RSSI level was at the first level, while unit door lock C detected stroller A's RSSI level at the third level and stroller B's RSSI level at the second level. The sensing record table for unit door lock C is as follows:

[0100] Table 1. Sensing Record Table of Unit Door Lock C

[0101] ;

[0102] ③ The unit door lock listens to the multicast data of a specific multicast group address G1 and records the correspondence between the Bluetooth addresses in the linking state and the unit door lock IP in the network. The local records are shown in Table 2 below and will age out after 10 seconds.

[0103] Table 2. All linking pairs within the network recorded by unit door lock C.

[0104] ;

[0105] ④ Based on the real-time collected RSSI level, the unit door lock periodically (every 10 seconds) sends an IGMP join message to a specific multicast address G1, carrying the stroller's Bluetooth address, the unit door lock's IP address, and a connection status announcement:

[0106] 1) First step: Check if the collected Bluetooth address conflicts with the linking pairing in step 3 (i.e., listen to see if anyone has bound this Bluetooth address to the unit door lock IP):

[0107] a. If there is a conflict, do nothing and ignore the Bluetooth address;

[0108] b. If there is no conflict, send a connection status announcement in the IGMP join message: it is in the linking state and other unit locks are not allowed to preempt it; at the same time, send a multicast data packet with a specific multicast address G1 (carrying the first-level Bluetooth address, unit lock IP, and connection status) to notify other unit locks that the linking is paired.

[0109] 2) In the second stage, a connection status announcement is sent in the IGMP join message: the connection is in standby state, allowing other unit door locks with high signal strength to preempt it;

[0110] 3) In the third stage, send a connection status announcement in the IGMP join message: "In alive state, please have other unit door locks with high signal strength preempt it."

[0111] ⑤ After receiving the IGMP join message, the unit door lock gateway registers or refreshes the Bluetooth address and its corresponding unit door lock IP, connection status, and local forwarding interface in the forwarding table of the multicast address:

[0112] 1) If the forwarding table does not contain the Bluetooth address, register the Bluetooth address and its corresponding unit door lock IP, connection status, and local forwarding interface; for example... Figure 3 In the network configuration, router D receives the Bluetooth address BD_ADDR_D reported by unit door lock X (IP address is Lock_IP_X). Since this Bluetooth address is not in the table, it is directly added to table item 4.

[0113] 2) If the forwarding table contains the Bluetooth address and the corresponding unit door lock IP is the same, then update the RSSI signal level; if so... Figure 3 In the network configuration, if router D receives a Bluetooth address BD_ADDR_C reported by unit door lock B (IP address Lock_IP_X) with a connection status of standby (originally linking), then the connection status will be modified as shown in Table 3.

[0114] 3) If the Bluetooth address is the same, the unit door lock IP is different, and the RSSI signal is different, then take the higher RSSI signal level and its corresponding unit door lock IP and forwarding interface (first level > second level > third level); for example Figure 3 In the network configuration, router D records the connection status of unit door lock C corresponding to Bluetooth address BD_ADDR_B as alive. When it receives the Bluetooth address BD_ADDR_B reported by unit door lock A (IP address is Lock_IP_A) as linking, it modifies the connection status as shown in Table 2.

[0115] 4) If the Bluetooth address is the same, the unit door lock IP is different, and the RSSI signal is the same, then to ensure the consistency of the Bluetooth connection, the following applies:

[0116] a. If all are in RSSI first tier, then no refresh is needed; that is, the original unit door lock IP is maintained. Figure 3 In the network configuration, if router D has recorded that the connection status between Bluetooth address BD_ADDR_B and unit door lock Lock_IP_A is "linking", then it will ignore the packets from other unit door locks reporting the "linking" status, unless the unit door lock reports the connection status of Bluetooth address BD_ADDR_B as "standby" or "alive".

[0117] b. If all are RSSI Tier 2, then perform a replacement refresh, meaning the newly reported unit door lock IP and forwarding interface replace the previously registered unit door lock IP and forwarding interface; for example... Figure 3 In the network configuration, router D has recorded that the connection status between Bluetooth address BD_ADDR_C and unit door lock Lock_IP_B is standby. If other unit door locks also report that their connection status with Bluetooth address BD_ADDR_C is also standby, router D needs to keep track of the latest signal location and update the unit door lock.

[0118] c. If all are RSSI Tier 3, then perform incremental refresh, i.e., do not delete the previously registered unit door lock IPs and forwarding interfaces, and incrementally register the newly reported unit door lock IPs and forwarding interfaces later; such as Figure 3In the network configuration, router D has recorded the connection status of Bluetooth address BD_ADDR_A with unit door lock Lock_IP_C as "alive". If other unit door locks also report an "alive" status with Bluetooth address BD_ADDR_A, router D needs to incrementally refresh the status as shown in Table 5 to ensure that the Bluetooth address remains "alive" with more unit door locks, preparing for emergency calls. The Bluetooth address bindings maintained by router D are shown in Table 3.

[0119] Table 3 Bluetooth address binding table maintained by router D

[0120] ;

[0121] ⑥ When the Bluetooth address binding table changes, the router sends a (*, G1) join message to the RP. At this point, the Bluetooth address of the (*, G1) table entries on the path from the unit door lock gateway to the RP is refreshed.

[0122] (3) When an indoor extension initiates a voice call, the processing mechanism of the routers along the route is adjusted as follows:

[0123] ① The Real-Time Voice Protocol (RTSP) and Real-Time Voice Data Stream (RTP) are carried via a specific multicast address G1 (239.1.2.3), simultaneously carrying the Bluetooth address bound to the indoor extension and the message urgency level (e.g., urgency level is set to 1 for an emergency call). This project aims to establish a multicast voice call between the indoor extension and the unit access control system. Specifically, the indoor extension sends a multicast message with the extension address S as the source IP and multicast group G1 as the destination address to the unit access control system. The unit access control system replies with a message whose source IP is the multicast group address and whose destination address is the unicast address of the indoor extension, thus establishing a five-tuple session. To ensure the reply message successfully reaches the indoor extension, we need to quickly establish a (S, G1) multicast tree.

[0124] ② After multicast data arrives at the extension gateway router, the extension gateway establishes a (S, G1) forwarding table entry. The incoming interface is the interface on which the extension gateway receives the data, and the outgoing interface is the interface facing the RP (Router Portal). Specifically, the interface is determined by using the RP's address as the destination address and performing a best-of-chance match in the unicast routing table. The outgoing interface corresponding to the matched unicast routing table entry is the outgoing interface of the (S, G1) entry. The extension gateway router forwards the multicast data packet to the next router from the outgoing interface according to this (S, G1) entry. The next router performs a similar operation.

[0125] ③ After multicast data arrives at the RP, the RP creates an entry in the (S,G1) table, and the outgoing interface is the interface that carries the stroller's Bluetooth address in the (*,G1) entry. The RP continues to forward the packet from that interface. The next router operates similarly. In such cases... Figure 3In the network, the multicast data packet sent from indoor extension B to stroller B is forwarded to router D (unit door lock gateway) via RP (router A) along the (*, G1) table entry, thereby establishing the (S, G1) forwarding table entry along the path from router D to router C.

[0126] ④ When the unit door lock needs to reply with a data packet to the indoor extension, the source IP address uses the multicast group address G1, and the destination address uses the unicast IP address of the indoor extension. Upon receiving the data packet, the unit door lock's gateway looks up the local (S,G1) multicast forwarding table entry and forwards the reply data packet from the ingress interface. Its upstream routers perform similar operations until the data packet reaches the gateway router of the indoor extension. The gateway router of the indoor extension then sends the reply data packet to the indoor extension from the (S,G1) ingress interface.

[0127] ⑤ The unit door lock gateway extracts the Bluetooth address from the multicast data and compares it with the local Bluetooth address binding table to find the unit door lock IP, connection status, and local forwarding interface corresponding to that Bluetooth address:

[0128] 1) If the Bluetooth address carried in the multicast data packet is not found in the forwarding table, it means that the unit door lock connected to the unit door lock gateway has not collected the Bluetooth address, and the unit door lock gateway discards the multicast data packet.

[0129] 2) If the Bluetooth address carried in the multicast data packet corresponds to a linking or standby state, the multicast data is sent directly from the corresponding forwarding interface and arrives at the unit door lock IP.

[0130] 3) If the unit door lock IP corresponding to the Bluetooth address carried in the multicast data packet and its connection status are in an alive state, then the multicast data packet can only be sent out from the corresponding forwarding interface if the urgency level is set to 1. That is, only emergency multicast data such as emergency person search needs to be broadcast out from as many unit door locks as possible.

[0131] ⑥ Considering the identifiable and traceable connection status, and to protect the privacy of the unit door lock address and avoid security leakage risks, the unit door lock uses specific unicast 5-tuple communication to reply to calls from the indoor extension. The source address is the multicast address G1, the destination address is the unicast IP of the indoor extension (obtained from the source address of the multicast data packet), and the source port number is the destination port number of the received packet, and the destination port number is the source port number of the received packet. In such cases... Figure 3 In the network, unit door lock A processes RTSP interaction messages and RTP / RTCP reply messages. The source address is multicast address G1, the destination address is the unicast IP of the indoor extension, the source port number is the destination port number of the multicast data packet sent by the indoor calling extension B, and the destination port number is its source port number.

[0132] ⑦ Traditional routers receiving the above reply message will encounter problems with RPF security detection. Therefore, the following function is added: If the source IP of the message is a multicast address, check if a corresponding (S,G) entry exists locally. If not, it is considered an attack message and discarded; if it exists, it is forwarded from the RPF interface according to the (S,G) entry. Figure 3 In the network, after the specific unicast address sent by unit door lock A reaches router A, since (S, G) has been established by step 3.1, it continues to forward according to the unicast address of the indoor extension, thus reaching the indoor extension along this path.

[0133] II. Beneficial Effects

[0134] The interactive system between the door lock and the mobile stroller provided by this invention, based on the dual threshold detection of the unit door lock and the signal optimal selection and maintenance mechanism of the unit door lock gateway, achieves the strongest signal support between the stroller and the unit door lock. It utilizes the existing voice call function of the door lock to achieve point-to-multipoint communication and maintain call stability during movement. Multicast forwarding does not use encapsulated data packets and SPT switching, thereby saving link load efficiency and transmission latency. Voice calls are ensured to be completed on the unit door lock that has collected the corresponding Bluetooth address, while protecting the privacy of the unit door lock address and avoiding the risk of security leakage.

[0135] III. Protection Points

[0136] 1. The process of establishing the (S,G1) tree from the indoor extension gateway to the unit access control gateway.

[0137] 2. The process of forwarding reply messages from the unit access control gateway to the indoor extension unit.

[0138] 3. The unit door lock listens to and records the correspondence between the Bluetooth addresses of all devices in the linking state on the network and the unit door lock's IP address to avoid connection conflicts;

[0139] 4. The unit door lock periodically (every 10 seconds) sends an IGMP join message to a specific multicast address, carrying the Bluetooth address, unit door lock IP, and connection status announcement;

[0140] 5. The unit door lock gateway registers or refreshes the Bluetooth address and its corresponding information on the forwarding table of the multicast address based on refresh priority (same door lock), stronger priority (different door locks), keep priority (keep linking), substitute (standby state), and incremental (alive state);

[0141] 6. When the Bluetooth address binding table changes, the router sends a (*, G) join message to the RP.

[0142] 7. The voice call protocol RTSP and the real-time voice data stream RTP / RTCP are carried through a specific multicast address G1, and also carry the Bluetooth address bound to the indoor extension and the urgency level of the message (for example, the urgency level is set to 1 for emergency calls).

[0143] 8. After multicast data arrives at the RP, the RP creates an entry (S,G) based on (*,G). The outgoing interface is the interface in the (*,G) entry that carries the stroller's Bluetooth address.

[0144] 9. Emergency messages with the urgency level set to 1 are sent from all ports in the live state.

[0145] 10. RPF security checks have been enhanced: If the source IP of a packet is a multicast address, the system checks if a corresponding (S,G) entry exists locally. If not, the packet is considered an attack and is dropped. If it does exist, the packet is forwarded from the RPF interface based on the (S,G) entry.

[0146] As can be seen, the system periodically collects the Bluetooth signal strength of mobile devices within its coverage area, divides the signal strength into preset levels, generates corresponding connection states, and then encapsulates them into IGMP join messages, which are sent to a specific multicast address. Upon receiving the IGMP join message, the door lock gateway registers or refreshes the corresponding door lock IP, connection state, and local forwarding interface in its maintained Bluetooth address binding table. Based on voice call requests initiated by indoor extensions, a multicast message is constructed, forwarded via the router network, and transmitted in reverse along the established (S,G) table path according to the Bluetooth address binding table by the aggregation point RP, completing a two-way secure session. This enables fast, accurate, and secure direct session establishment between the door lock and the mobile terminal, reducing communication latency and dependence on external networks.

[0147] Another embodiment of the present invention provides a system for secure communication between a door lock and a mobile device, see [link to relevant documentation]. Figure 4 The system may include:

[0148] The reporting module 401 is used for Bluetooth signal sensing and status reporting: it periodically collects the Bluetooth signal strength of mobile terminals in the coverage area of ​​the unit door lock, divides the signal strength into preset levels and generates corresponding connection statuses, and then encapsulates them into IGMP join messages carrying the Bluetooth address, unit door lock IP and connection status, and sends them to a specific multicast address.

[0149] Maintenance module 402 is used for dynamic maintenance of Bluetooth address binding table: based on the IGMP join message received by the door lock gateway, and according to the preset conflict arbitration and priority rules, it registers or refreshes the unit door lock IP, connection status and local forwarding interface corresponding to the Bluetooth address in the Bluetooth address binding table it maintains;

[0150] Module 403 is used to establish a voice call multicast tree: based on the voice call request initiated by the indoor extension, a multicast message carrying the target mobile terminal Bluetooth address and message urgency level is constructed, forwarded through the router network, and the aggregation point RP establishes a (S,G) source multicast tree from the indoor extension to the corresponding unit door lock according to the Bluetooth address binding table.

[0151] Communication module 404 is used to implement bidirectional secure communication: According to the (S,G) multicast tree, the indoor extension sends voice data to the unit door lock via multicast, and the unit door lock constructs a reply message with the source address being the multicast address and the destination address being the unicast IP of the indoor extension, and transmits it in reverse along the established (S,G) table path to complete the bidirectional secure session.

[0152] This invention also provides a storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0153] This invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0154] Specifically, the aforementioned electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the aforementioned processor, and the input / output device is connected to the aforementioned processor.

[0155] The above description, based on the embodiments shown in the figures, details the structure, features, and effects of the present invention. The above description is only a preferred embodiment of the present invention, but the present invention is not limited to the scope of implementation shown in the figures. Any changes made in accordance with the concept of the present invention, or equivalent embodiments modified to have equivalent changes, that do not exceed the spirit covered by the specification and figures, should be within the protection scope of the present invention.

Claims

1. A method for secure dialogue between a door lock and a mobile terminal, characterized in that, The method includes: Bluetooth signal sensing and status reporting: The unit door lock periodically collects the Bluetooth signal strength of mobile devices within its coverage area, divides the signal strength into preset levels and generates corresponding connection statuses, and then encapsulates them into IGMP add messages carrying Bluetooth address, unit door lock IP and connection status, and sends them to a specific multicast address. Bluetooth address binding table dynamic maintenance: Based on the IGMP join message received by the door lock gateway, and according to the preset conflict arbitration and priority rules, the door lock IP, connection status and local forwarding interface corresponding to the Bluetooth address are registered or refreshed in the Bluetooth address binding table it maintains; Establishment of the voice call multicast tree: Based on the voice call request initiated by the indoor extension, a multicast message carrying the target mobile terminal Bluetooth address and message urgency level is constructed, forwarded through the router network, and the aggregation point RP establishes a (S,G) source multicast tree from the indoor extension to the corresponding unit door lock according to the Bluetooth address binding table. Implementation of bidirectional secure communication: According to the (S,G) multicast tree, the indoor extension sends voice data to the unit door lock via multicast. The unit door lock then constructs a reply message with the source address being the multicast address and the destination address being the unicast IP of the indoor extension, and transmits it in reverse along the established (S,G) table path to complete the bidirectional secure session.

2. The method according to claim 1, characterized in that, The Bluetooth signal sensing and status reporting includes: Signal acquisition and level classification: Based on the Bluetooth signal received by the unit door lock in real time, the received signal strength indicator RSSI is obtained, and the RSSI is divided into three levels according to the preset threshold: first level stable, second level unstable, and third level weak, to obtain the corresponding signal level. Connection status determination: Based on the signal strength and network monitoring results, the connection status with the Bluetooth address is determined: the first level is the linking state when there is no conflict, the second level is the standby state, and the third level is the alive state. Local conflict avoidance: Before determining the first-level linking state, listen to the multicast announcements issued by other unit locks in the network. If it is found that the Bluetooth address has been declared as linking by other locks, the declaration is abandoned to avoid connection conflicts. Periodic multicast announcement: Based on the determined connection status, the Bluetooth address, the IP address of the door lock of this unit, and the connection status are periodically encapsulated into an IGMP join message and sent to the specific multicast address to complete the status announcement.

3. The method according to claim 2, characterized in that, The Bluetooth address binding table is dynamically maintained, including: Binding entry registration: Based on the first IGMP join message received by the door lock gateway for a certain Bluetooth address, register the Bluetooth address and its reported unit door lock IP, connection status, and local forwarding interface in the Bluetooth address binding table corresponding to the multicast address; Same IP refresh: If the Bluetooth address in the subsequently received IGMP join message matches the entry in the table and the reported unit door lock IP is the same, then refresh the connection status and aging time in that entry. IP contention resolution: If the Bluetooth address in the subsequently received IGMP join message matches the entry in the table but the reported unit lock IP is different, the resolution will be made according to the signal level priority and the specific rules of the same level, with the first level priority > the second level priority > the third level priority: If the new and old signals both belong to the first level, the original unit lock IP will remain unchanged; if the new and old signals both belong to the second level, the newly reported unit lock IP and interface will replace the original record; if the new and old signals both belong to the third level, the new unit lock IP and interface will be recorded incrementally. Binding table synchronization: When the Bluetooth address binding table changes, the door lock gateway sends a (*,G) join message to the RP, causing the upstream router to update the multicast forwarding table outgoing interface information.

4. The method according to claim 3, characterized in that, The establishment of the voice call multicast tree includes: Call request multicast encapsulation: Based on the voice call initiated by the indoor extension, the target mobile terminal Bluetooth address and the message urgency flag are encapsulated into an RTSP / RTP multicast message with the destination address being the specific multicast address. Source multicast tree hop-by-hop establishment: Based on the forwarding of the multicast message in the router network, each router creates or matches a (S,G1) forwarding table entry based on the source IP (S) and multicast address (G1), with its outgoing interface facing the RP, thereby establishing a (S,G1) path from the indoor extension to the RP hop-by-hop. RP Binding Table Query and Forwarding: Based on the multicast message received by the RP, extract the Bluetooth address carried in it, query the binding information that is synchronously updated from the door lock gateway, determine the unit door lock IP and connection status currently associated with the Bluetooth address, and set the outgoing interface of the (S,G1) table entry to point to the interface of the door lock gateway where the unit door lock is located. Door lock gateway precise delivery: Based on the multicast message forwarded by the RP received by the door lock gateway, query the local Bluetooth address binding table: If the connection status is linking or standby, the message will be sent from the corresponding local forwarding interface to the target unit door lock; if the connection status is alive, the message will be broadcast from all associated interfaces only when the message urgency flag is set.

5. The method according to claim 4, characterized in that, The implementation of the bidirectional secure communication includes: Reverse unicast message construction: Based on the unit door lock's need to reply with voice data to the indoor extension, construct a reply message with the source IP address being the specific multicast address (G1), the destination IP address being the indoor extension's unicast IP, and the port number being interchanged with the received message; Reverse routing based on (S,G) entries: Based on the reply messages received by the routers along the route with the source address as a multicast address, check whether there is a corresponding (S,G1) entry on the local machine. If there is, the message is sent in reverse along the established (S,G1) multicast tree path to the indoor extension gateway. Security verification: When the router performs reverse path forwarding RPF checks on packets with multicast source IP addresses, a specific rule is added: if a corresponding (S,G) entry exists, the packet continues to be forwarded according to the unicast address of the indoor extension; if it does not exist, it is considered an attack packet and is discarded.

6. The method according to claim 5, characterized in that, The method also includes anomaly and aging handling mechanisms: Connection status aging: Based on the linking pairing information of other door locks in the network recorded locally by the unit door lock, an aging time is set, and the information is automatically cleared after the timeout to avoid outdated information interfering with conflict judgments; Binding entry aging: If no IGMP join message to refresh the Bluetooth address is received within a set period, the entry in the Bluetooth address binding table maintained by the door lock gateway will be automatically aged out and deleted.

7. A system for secure communication between a door lock and a mobile terminal, characterized in that, The system includes: The reporting module is used for Bluetooth signal sensing and status reporting: it periodically collects the Bluetooth signal strength of mobile devices in the coverage area of ​​the unit door lock, divides the signal strength into preset levels and generates corresponding connection statuses, and then encapsulates them into IGMP add messages carrying Bluetooth address, unit door lock IP and connection status, and sends them to a specific multicast address. The maintenance module is used for dynamic maintenance of the Bluetooth address binding table: based on the IGMP join message received by the door lock gateway, and according to the preset conflict arbitration and priority rules, it registers or refreshes the unit door lock IP, connection status and local forwarding interface corresponding to the Bluetooth address in the Bluetooth address binding table it maintains; The module is used to establish a voice call multicast tree: based on the voice call request initiated by the indoor extension, a multicast message carrying the target mobile terminal Bluetooth address and message urgency level is constructed, forwarded through the router network, and the aggregation point RP establishes a (S,G) source multicast tree from the indoor extension to the corresponding unit door lock according to the Bluetooth address binding table. The communication module is used to implement two-way secure communication: According to the (S,G) multicast tree, the indoor extension sends voice data to the unit door lock via multicast. The unit door lock then constructs a reply message with the source address being the multicast address and the destination address being the unicast IP of the indoor extension, and transmits it in reverse along the established (S,G) table path to complete the two-way secure session.

8. The system according to claim 7, characterized in that, The reporting module is specifically used for: Signal acquisition and level classification: Based on the Bluetooth signal received by the unit door lock in real time, the received signal strength indicator RSSI is obtained, and the RSSI is divided into three levels according to the preset threshold: first level stable, second level unstable, and third level weak, to obtain the corresponding signal level. Connection status determination: Based on the signal strength and network monitoring results, the connection status with the Bluetooth address is determined: the first level is the linking state when there is no conflict, the second level is the standby state, and the third level is the alive state. Local conflict avoidance: Before determining the first-level linking state, listen to the multicast announcements issued by other unit locks in the network. If it is found that the Bluetooth address has been declared as linking by other locks, the declaration is abandoned to avoid connection conflicts. Periodic multicast announcement: Based on the determined connection status, the Bluetooth address, the IP address of the door lock of this unit, and the connection status are periodically encapsulated into an IGMP join message and sent to the specific multicast address to complete the status announcement.

9. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method of any one of claims 1-6 when it is run.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method of any one of claims 1-6.

Images