A voice intercom system supporting relationship hierarchy and adjacency awareness

Abstract

The application discloses a voice intercom system supporting relationship grading and adjacency awareness, and relates to the technical field of wireless communication. The voice intercom system comprises a cloud server and a plurality of user terminal devices. The user terminal device comprises a communication module, an adjacency awareness module, a local relationship database, a relationship management module and a strategy control module. The communication module is used for establishing a data transmission channel between the current user terminal device, the cloud server and other user terminal devices. The adjacency awareness module is used for generating and broadcasting a local broadcast signal of the current user terminal device, and is also used for scanning a peer broadcast signal of other user terminal devices within a broadcast effective range. The local relationship database is used for storing a friend list, wherein the friend list comprises a plurality of friends and device unique identifiers corresponding to each friend. The relationship management module is used for managing the local relationship database. The strategy control module is used for executing voice link management decisions. The scheme can significantly improve the resource scheduling efficiency and user experience of the voice intercom system.

Description

Technical Field

[0001] This invention relates to the field of wireless communication technology, specifically to a voice intercom system that supports hierarchical relationships and adjacency awareness. Background Technology

[0002] Voice intercom systems are widely used in scenarios such as security dispatching, team collaboration, outdoor communication, and instant messaging. With the development of wireless communication technology, user terminal devices (such as walkie-talkies, smartphones, and wearable communication devices) typically support multiple wireless communication links and can automatically discover surrounding devices and establish voice connections within a certain range.

[0003] In practical use, users desire both long-term, stable voice communication with key contacts (such as family and team members) and brief conversations with strangers or non-key individuals encountered only temporarily. However, existing voice intercom systems suffer from the following technical shortcomings:

[0004] On the one hand, most existing intercom systems are based on broadcast or group call modes, treating all devices as peer nodes in terms of communication permissions. The system cannot distinguish between "friends" and "strangers" between the current device and surrounding devices, thus treating all connections the same way: either setting them all to persistent, leading to unnecessary connections occupying resources for extended periods, or setting them all to temporary calls, failing to meet the needs of friends requiring continuous voice communication. This results in the failure to prioritize persistent voice communication between friends, while temporary calls from strangers may be unreasonably rejected due to resource exhaustion.

[0005] On the other hand, limited by factors such as the hardware processing power, wireless channel bandwidth, and power consumption of the equipment, a user terminal device can typically only maintain a limited number of voice links simultaneously. Once established connections have filled all link resources, even if a device with higher communication priority or better signal quality appears, the existing system cannot proactively free up resources. Users can only manually disconnect existing connections, a cumbersome and slow-responding process. More seriously, the system cannot automatically assess the signal strength of connected devices and cannot proactively disconnect the weakest existing link to optimize overall communication quality when a new device with a better signal appears.

[0006] In summary, existing voice intercom systems, under limited concurrent link resources, cannot intelligently schedule and dynamically replace voice links based on the relationship level between devices and real-time signal strength. This leads to problems such as unreasonable allocation of communication resources, unreliable service quality for core communication objects, and poor adaptability to dynamic environments. Therefore, there is an urgent need for a voice intercom system that supports hierarchical relationship and adjacency awareness to address these technical shortcomings. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention provides a voice intercom system that supports hierarchical relationships and adjacency awareness, thus solving the problems mentioned in the background section.

[0008] To achieve the above objectives, the present invention provides the following technical solution: a voice intercom system that supports hierarchical relationship and adjacency awareness, comprising a cloud server and several user terminal devices;

[0009] The user terminal equipment includes:

[0010] A communication module is used to establish a data transmission channel between the current user terminal device and the cloud server and other user terminal devices; wherein, the data transmission channel includes a voice link for transmitting voice data, and the voice link includes a persistent voice link and a temporary voice link;

[0011] The adjacency sensing module is used to generate and broadcast the local broadcast signal of the current user terminal device, and also to scan the peer broadcast signals of other user terminal devices within the effective range of the broadcast; the local broadcast signal includes the unique device identifier of the current user terminal device; the peer broadcast signal includes the unique device identifier of the corresponding other user terminal device;

[0012] A local relationship database is used to store a friend list, which includes several friends and a unique device identifier for each friend;

[0013] The relationship management module is used to manage the local relationship database;

[0014] The strategy control module is used to execute voice link management decisions, including: determining the type of voice link established between the current user terminal device and other user terminal devices based on the friend list and the broadcast signal from the other end; generating link control instructions to control the communication module to establish, maintain and disconnect the voice link based on the number of voice links established by the current user terminal device, the preset upper limit of the number of connections, and the voice link type and signal strength of each established voice link.

[0015] Furthermore, the policy control module executes voice link management decisions, including the initial connection phase and the dynamic discovery phase:

[0016] The initial connection phase includes: detecting the online status of each friend in the current user terminal device's friend list, and the command communication module establishing a persistent voice link with the currently online friends;

[0017] The dynamic discovery phase includes: continuously scanning the peer broadcast signals of other user terminal devices, comparing the unique device identifier in each peer broadcast signal with the unique device identifier of each friend in the friend list, and analyzing whether the corresponding other user terminal devices are friends.

[0018] If it is a friend, then analyze whether the number of voice links established by the current user terminal device has reached the preset connection limit.

[0019] If this is not achieved, the instruction communication module establishes a persistent voice link with other corresponding user terminal devices;

[0020] If the condition has been met, the system analyzes whether there is a temporary voice link among the established voice links of the current user terminal device. If there is, the system instructs the communication module to disconnect the temporary voice link with the weakest signal strength and establish a persistent voice link with the corresponding other user terminal device. If there is no such link, the system instructs the communication module to select the persistent voice link with the weakest signal strength among the established persistent voice links and disconnect it, and then establish a persistent voice link with the corresponding other user terminal device.

[0021] If they are not friends, then analyze whether the number of voice links established by the current user terminal device has reached the preset connection limit:

[0022] If this is not achieved, the instruction communication module establishes a temporary voice link with other corresponding user terminal devices;

[0023] If the condition has been met, the system analyzes whether there is a temporary voice link among the established voice links of the current user terminal device. If there is, the system instructs the communication module to select the temporary voice link with the weakest signal strength among the established temporary voice links and disconnect it, and then establish a temporary voice link with the corresponding other user terminal device. If there is no such link, no action is taken, and the currently established persistent voice link is maintained.

[0024] Furthermore, the strategy control module is also configured with a temporary voice link management mechanism, including: after the temporary voice link of the current user terminal device is established, continuously monitoring whether the peer broadcast signal of other user terminal devices that have established a temporary voice link can be scanned; when the corresponding peer broadcast signal is not scanned within a preset duration, it is determined that the adjacency relationship is terminated, the communication connection is automatically disconnected, the call is terminated, and the disconnection information is synchronized to other user terminal devices that maintain a voice link with the current user terminal device.

[0025] Furthermore, the adjacency sensing module is configured with a scene-adaptive broadcasting and scanning strategy, including:

[0026] The system broadcasts the local broadcast signal of the current user terminal device according to a preset period, and scans the remote broadcast signals of other user terminal devices within the effective range of the broadcast in a preset near-field frequency band. If the remote broadcast signal of the corresponding other user terminal device is detected within a preset duration, it is determined that the two parties establish an adjacency relationship; if the remote broadcast signal of the corresponding other user terminal device is not detected within the preset duration, it is determined that the adjacency relationship is terminated.

[0027] The broadcast cycle and scan cycle are dynamically adjusted based on the current usage scenario and power consumption status of the user terminal device. The usage scenarios include the default scenario, the active collaboration scenario, and the low power scenario.

[0028] Furthermore, the relationship management module supports multiple modes for establishing friend relationships, including invitation confirmation mode, search and add mode, and local exchange mode.

[0029] The invitation confirmation mode includes: the current user terminal device generates an invitation request and sends it to the cloud server, which then pushes it to the corresponding other user terminal devices. After confirmation by the corresponding other user terminal devices, both parties write the other party's unique device identifier into the friend list of the local relationship database and synchronize the two-way friend relationship through the cloud server.

[0030] The search and add mode includes: the current user terminal device selects other user terminal devices from the online user list and initiates an add request to the cloud server. The cloud server performs automatic approval or confirmation processing according to the preset privacy settings of the other user terminal devices. After confirmation, both parties write the other party's unique device identifier into the friend list of the local relationship database and synchronize the two-way friend relationship through the cloud server.

[0031] The local exchange mode includes: the current user terminal device and other corresponding user terminal devices establish a connection and exchange standardized data packets through near-field data exchange technology. After the local verification process is passed, both parties write the other party's unique device identifier into the friend list of the local relationship database, and choose to immediately synchronize to the cloud server or temporarily store it locally and synchronize it after connecting to the network, depending on the network status.

[0032] Furthermore, the relationship management module is also configured with a data synchronization mechanism, including an online real-time synchronization mode and an offline temporary storage and recovery mode;

[0033] The online real-time synchronization mode is used when the current user terminal device is connected to the Internet, to actively pull the latest relationship list from the cloud server and receive update instructions pushed by the cloud server to update the local relationship database in real time.

[0034] Offline temporary storage and recovery mode is used when the current user terminal device is not connected to the Internet. Modifications to the local relational database take effect in real time and the operation record is temporarily stored. After the current user terminal device restores the network, the temporary record is automatically uploaded to the cloud server for merging.

[0035] Furthermore, the cloud server is configured with a load balancing mechanism, which includes:

[0036] Each user terminal device maintains its own unique incrementing request sequence number and attaches its own unique identifier and current request sequence number when sending a request to the cloud server;

[0037] The cloud server queues and processes requests in an orderly manner based on the device's unique identifier and request sequence number, and discards requests with duplicate or expired sequence numbers without processing them again.

[0038] This invention provides a voice intercom system that supports hierarchical relationship and adjacency awareness, and has the following beneficial effects:

[0039] This invention maintains a friend list locally on the user's terminal device and defines two different types of connections: persistent voice links (for friends) and temporary voice links (for non-friends). This allows the policy control module to make differentiated connection decisions based on the relationship level of the communication objects. When link resources are scarce, the system prioritizes sacrificing temporary voice links to free up resources for establishing new persistent voice links. For connection requests initiated by non-friends, replacement is only performed if a temporary voice link exists and its signal strength is lower than the new request, never occupying the resources of an established persistent voice link. This mechanism effectively solves the problem of unreasonable resource allocation caused by the inability to distinguish the relationship level of communication objects and the equal treatment of all connections in existing technologies, ensuring that persistent communication with friends receives the highest resource guarantee.

[0040] This invention uses a strategy control module to acquire the signal strength of established links in real time. When the number of links reaches a preset limit, it performs intelligent replacement based on signal strength and link type: For friend connections, it prioritizes disconnecting the temporary voice link with the weakest signal strength; if no temporary voice link exists, it only disconnects the weakest persistent voice link if a weaker signal strength exists, ensuring that the new friend can connect without affecting existing friends with stronger signals. For non-friend connections, it only allows replacement with temporary voice links with weaker signal strength, never preempting persistent voice link resources. This mechanism solves the shortcomings of existing technologies that cannot automatically free up resources after link resources are full and cannot optimize connection composition based on signal quality, enabling the system to automatically maintain the set of links with the best overall signal quality in a dynamic environment.

[0041] This invention divides the operation of the strategy control module into an initial connection phase and a dynamic discovery phase: In the initial phase, it proactively establishes persistent voice links with all online friends, ensuring that core communication targets gain connection immediately; in the dynamic phase, it continuously scans surrounding devices and responds promptly to newly appearing devices (including newly online friends or passing non-friends). This two-phase collaboration avoids the tedious manual selection process for each call while ensuring the system's real-time awareness of the dynamic environment.

[0042] This invention also includes a temporary voice link management mechanism. After a temporary voice link is established, it continuously monitors whether the broadcast signal of the other device can still be scanned. If it cannot be scanned within a preset duration, the connection is automatically disconnected and the disconnection information is synchronized. This mechanism can promptly release temporary voice links that are no longer needed due to physical distance, avoiding invalid connections from occupying valuable link resources for a long time, and further improving resource utilization efficiency. Attached Figure Description

[0043] Figure 1 This is a schematic diagram of the overall architecture and interaction of a voice intercom system that supports hierarchical relationship and adjacency awareness according to the present invention.

[0044] Figure 2 This is a flowchart illustrating the voice link management decision-making process of the policy control module in a voice intercom system that supports hierarchical relationship and adjacency awareness, according to the present invention.

[0045] Figure 3 This is a timing diagram of the voice link establishment phase with a friend's device in a voice intercom system that supports hierarchical relationship and adjacency awareness according to the present invention.

[0046] Figure 4 This is a timing diagram of the voice link establishment phase with a non-friend device in a voice intercom system that supports hierarchical relationship and adjacency awareness according to the present invention.

[0047] Figure 5 This is a flowchart illustrating a multi-mode friend relationship establishment method in a voice intercom system that supports hierarchical relationship and adjacency awareness, according to the present invention.

[0048] Figure 6 This is a scenario diagram illustrating the establishment of different voice link relationships in a voice intercom system that supports hierarchical relationships and adjacency awareness, as described in this invention. Detailed Implementation

[0049] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0050] Example 1

[0051] Please see Figures 1 to 6 The present invention provides a voice intercom system that supports hierarchical relationship and adjacency awareness, including a cloud server and several user terminal devices, wherein the cloud server is an enhanced service module, and the user terminal devices can independently realize the core intercom function when there is no cloud server.

[0052] User terminal devices are the terminal carriers participating in voice intercom, including but not limited to smartphones, dedicated walkie-talkies, wearable communication devices, etc. Each user terminal device integrates a communication module, a proximity sensing module, a local relation database, a relation management module, and a policy control module. Each module functions independently yet works collaboratively. In this embodiment, for ease of description, user terminal devices are defined as devices A, B, C, and D, etc., where device A is designated as the current user terminal device, and devices B, C, and D are other user terminal devices that may establish a voice link with device A. This embodiment specifically uses the voice link establishment process between device A and device B as an example to explain the specific functions of each module in the user terminal device. This example also applies to the interaction between device A and other devices such as device C and device D. It should be noted that this system supports two-way intercom communication, and the roles of device A and device B can be interchanged. That is, when device B is the current user terminal device, device A can also be the target device to be connected to device B.

[0053] The specific functions of each module in the user terminal device are as follows:

[0054] The communication module is used to establish a data transmission channel between the current user terminal device and the cloud server and other user terminal devices; wherein, the data transmission channel includes a voice link for transmitting voice data, and the voice link includes a persistent voice link and a temporary voice link.

[0055] In this embodiment, to achieve full-scenario voice coverage from short-range direct connection to wide-area network, the communication module integrates both near-field wireless communication technology and far-field wireless communication technology. Near-field wireless communication technologies include Bluetooth (including classic Bluetooth BR / EDR and Bluetooth Low Energy BLE), Wi-Fi, Starlink, and Zigbee, primarily used for short-range direct voice communication between devices, offering advantages such as low latency, high bandwidth, and no need for cellular network coverage. Far-field wireless communication technologies include cellular networks, LoRa, and LTE-V2X PC5, used for wide-area coverage scenarios, supporting remote voice communication via base stations or direct connections, and can also cooperate with cloud servers for data relay forwarding. The communication module can dynamically select one or more of the above technologies to establish a voice link based on the current network environment, device capabilities, and service requirements. The communication module has link monitoring and adaptive switching functions. When the signal quality of the current link is detected to be lower than a preset threshold, the link is interrupted, voice service requirements change (such as changes in bandwidth or latency requirements), or device power consumption and resource status change (such as insufficient power requiring reduced power consumption), the communication module, in conjunction with the policy control module, automatically performs link switching to ensure the continuity and quality of service of voice communication. The policy control module is responsible for making the switching decision, while the communication module is responsible for establishing, disconnecting, and migrating the underlying link. When multiple wireless communication links are available simultaneously, the policy control module follows a hierarchical dynamic decision tree for link selection. Its core principle is to pursue the overall optimization of performance, power consumption, and cost while meeting the minimum requirements of the current voice communication service. Specifically, the evaluation proceeds hierarchically as follows: first, links that cannot meet the minimum service requirements are excluded; then, among the links that meet the requirements, the link with the best performance is selected first; when the performance of multiple links is similar, power consumption and communication cost are further weighed. Furthermore, the above evaluation weights can be dynamically adjusted according to device status or user settings.

[0056] The adjacency sensing module is used to generate and broadcast the local broadcast signal of the current user terminal device, and also to scan the peer broadcast signals of other user terminal devices within the effective range of the broadcast; the local broadcast signal includes the unique device identifier of the current user terminal device; the peer broadcast signal includes the unique device identifier of the corresponding other user terminal device;

[0057] The adjacency sensing module supports at least one short-range wireless communication technology such as Bluetooth, Wi-Fi, ZigBee, and Starlink. Its core functions include active scanning and detection of surrounding devices, adjacency determination, and adjacency removal. The module possesses bidirectional adjacency sensing capabilities: on one hand, it periodically broadcasts its own broadcast signal according to a preset period (e.g., every 170ms). This local broadcast signal includes the unique identifier of the current user terminal device and may also include fields such as device type, service UUID, and current link status, allowing other user terminal devices within the broadcast's effective range to discover and identify it. On the other hand, the module actively scans the environment within a preset near-field frequency band, detecting the peer broadcast signals of other user terminal devices within its effective range. These peer broadcast signals include the unique identifier of the corresponding other user terminal device. Through the coordinated operation of broadcasting and scanning, each user terminal device can both be discovered by other user terminal devices and actively discover other user terminal devices, achieving bidirectional discovery and adjacency determination between devices.

[0058] The adjacency sensing module is configured with scene-adaptive broadcasting and scanning strategies, including:

[0059] The system broadcasts the local broadcast signal of the current user terminal device according to a preset period, and scans the remote broadcast signals of other user terminal devices within the effective range of the broadcast in a preset near-field frequency band. If the remote broadcast signal of the corresponding other user terminal device is detected within a preset duration, it is determined that the two parties establish an adjacency relationship; if the remote broadcast signal of the corresponding other user terminal device is not detected within the preset duration, it is determined that the adjacency relationship is terminated.

[0060] The broadcast cycle and scan cycle are dynamically adjusted based on the current usage scenario and power consumption status of the user terminal device. The usage scenarios include the default scenario, the active collaboration scenario, and the low power scenario.

[0061] In this embodiment, the preset near-field frequency band includes at least one of the following: 2.4 GHz ISM band, 5 GHz band, 6 GHz band, 915 MHz band, and 868 MHz band. Specifically: for devices using Bluetooth technology, the 2.4 GHz ISM band is used; for devices using Wi-Fi technology, the 2.4 GHz, 5 GHz, or 6 GHz band is used; for devices using ZigBee technology, the 2.4 GHz, 915 MHz, or 868 MHz band is used; and for devices using Starfleet technology, the 2.4 GHz, 5 GHz, or 6 GHz band is used. These frequency bands are common operating bands for near-field wireless communication technologies. Devices can perform broadcast transmission and scanning reception operations within the corresponding preset frequency band according to their supported wireless communication technologies. The preset duration is 1 minute. Figure 6As shown in the figure, the dashed circle indicates the effective range of the broadcast. This range is not a fixed physical distance, but rather the spatial area within the operating frequency band of the short-range wireless communication technologies (such as Bluetooth, Wi-Fi, ZigBee, and Starflash) supported by the device adjacency sensing module, where the broadcast signal from the other device can be successfully received and parsed. In environments with strong interference, such as cities, the effective range is reduced, while in environments with weak interference, such as in the wild, the effective range is expanded. The adjacency sensing module continuously detects broadcast signals within this range to achieve dynamic determination and maintenance of adjacency relationships.

[0062] In this embodiment, the broadcast period and scanning period are adjusted using a scenario-adaptive broadcast and scanning strategy, dynamically changing within a preset adjustment range based on the current usage scenario and device power consumption. The preset adjustment range is pre-configured in the device firmware based on device hardware capabilities and application scenario requirements, specifically ranging from 100ms to 1s for both the broadcast period and the scanning period. The upper and lower limits of these ranges can be differentiated according to the device model and application scenario. For example, the upper limit can be appropriately extended in low-power devices, while the lower limit can be appropriately shortened in professional devices with high real-time requirements. The scenario-adaptive dynamic adjustment strategy intelligently adjusts the broadcast period and scanning period based on the user's current usage scenario and device power consumption, balancing proximity detection sensitivity with device battery life. The strategy defines the following three scenarios:

[0063] Default scenario: The device is in normal standby and non-cooperative state. In this case, the broadcast period is set to 170ms and the scan period is set to 200~220ms. Power consumption control is given priority while ensuring basic adjacency discovery capabilities.

[0064] Proactive collaboration scenario: The user initiates an intercom request or is in a call. In this case, the broadcast period is set to 170ms, and the scanning period is shortened to 150~180ms to maintain real-time awareness of adjacency status at the highest frequency, ensuring that temporary voice links can be quickly established and maintained.

[0065] Low-power scenario: When the device's battery level is below a preset low-power threshold (e.g., 20%), the device is in a low-power state. At this time, the broadcast period is extended to 1 second, and the scanning period is extended to 1 second, significantly reducing the power consumption of the adjacent sensing module and prioritizing the device's battery life.

[0066] The dynamic switching of strategies is triggered by the following conditions:

[0067] User-manual scene mode switching: Users can actively select the scene mode according to their actual needs, and the system will adjust the broadcast cycle and scanning cycle in real time after responding.

[0068] Device battery level below low battery threshold: The system automatically monitors the device battery level and automatically switches to low power mode when the battery level is below the preset threshold, adjusting the cycle parameters accordingly;

[0069] When a user initiates a call request, the system automatically switches to the active collaboration scenario, using high-frequency broadcasting and scanning to ensure the real-time nature of adjacency determination; when the call ends after a preset time (e.g., 30 seconds) and there is no subsequent communication activity, it automatically reverts to the default scenario.

[0070] The broadcast period and scan period can be adjusted independently and configured separately according to scenario requirements. In proactive collaboration scenarios, the broadcast period and scan period are shortened simultaneously to ensure real-time bidirectional discovery; in low-power scenarios, the broadcast period and scan period are lengthened simultaneously to reduce overall power consumption; in the default scenario, the broadcast period can be set to be slightly longer than the scan period to optimize scan energy consumption while ensuring passive discoverability.

[0071] A local relationship database is used to store a friend list on a user's terminal device. The friend list includes several friends and a unique device identifier for each friend. The unique device identifier can be any one of a general device address, serial number, or unique identifier (UUID). In this embodiment, user terminal devices whose unique device identifiers are stored in the friend list are defined as friends, and user terminal devices whose unique device identifiers are not stored in the friend list are defined as non-friends.

[0072] Specifically, the local relational database adopts a layered design and unique identifier mapping architecture, including storage design, device unique identifiers, and anti-tampering mechanisms. The storage design uses a device-local key-value storage engine, compatible with various lightweight local storage media (including but not limited to lightweight key-value databases, structured files, and embedded relational databases). It stores core data using a key-value mapping structure of device unique identifiers and relational attributes, supporting fast CRUD operations on single records and adapting to the lightweight computing needs of terminal devices. The device unique identifier associated with the communication object is an inherent unique identifier of the device hardware. This identifier is immutable and fixed in the hardware module at the time of manufacture, possessing global uniqueness, immutability, and uniqueness throughout the device's lifecycle, ensuring the accuracy of the relational mapping. The anti-tampering mechanism constructs a dual anti-tampering protection system at the local storage layer and data layer. The storage layer relies on local storage media with access control, allowing only authorized core processes of this system to perform CRUD operations on the relational database. The data layer generates data verification values ​​to perform integrity checks on all data in the relational database. This dual protection ensures that the local relational database data is not maliciously tampered with, deleted, or forged.

[0073] The relationship management module is used to manage the local relationship database. Specifically, it performs add, delete, modify, and query operations on the local relationship database and supports data synchronization with the cloud server. The relationship management module supports three operation interfaces: manual editing via local GUI; direct exchange and writing of the list with other devices via near-field communication such as NFC and QR code scanning; and synchronization with the cloud server when connected to the network, including list retrieval and receiving push notifications.

[0074] like Figure 5 As shown, the relationship management module supports multiple modes for establishing friend relationships, including invitation confirmation mode, search and add mode, and local exchange mode:

[0075] The invitation confirmation mode includes: the current user's terminal device generates an invitation request and sends it to the cloud server, which then pushes it to other relevant user terminal devices. After confirmation by the other relevant user terminal devices, both parties write the other's device unique identifier into their local friend list and synchronize their mutual friend relationship through the cloud server. The specific process is as follows:

[0076] Device A selects Device B from the online user list through the local GUI (local graphical user interface), generates an invitation request containing Device A's identifier, public key, timestamp, and digital signature, and sends it to the cloud server via the communication module;

[0077] After receiving the invitation request, the cloud server's synchronization service engine queries the online status of device B and its preset privacy settings, and performs the following operations based on its preset privacy settings:

[0078] If device B is set to "Confirmation Required", the invitation request will be pushed to device B, and device B will display a confirmation prompt to the user. After the user selects "Confirm Acceptance", device B will write device A's identifier into the friend list of the local relationship database. If the user selects "Decline", the process will terminate.

[0079] If device B is set to "auto-access", then no user interaction or confirmation is required; device B will automatically write device A's identifier into the local friend list.

[0080] After successful writing, Device B sends a confirmation message to the cloud server. The cloud central relationship database updates the two-way friend relationship record and pushes a relationship establishment notification to Device A through the synchronization service engine. After receiving the relationship establishment notification, Device A writes Device B's identifier into the friend list of the local relationship database. At this point, the two-way friend relationship is established. This mode has the characteristics of two-way confirmation and strict control, and is suitable for social scenarios that emphasize privacy protection.

[0081] The search-and-add mode includes: the current user's terminal device selects other user terminal devices from the online user list and initiates an add request to the cloud server. The cloud server automatically approves or requires confirmation based on the other user's terminal device's preset privacy settings. After confirmation, both parties write the other's device's unique identifier into their local friend list and synchronize their mutual friend relationship through the cloud server. The specific process is as follows:

[0082] Device A unilaterally searches for and selects Device B in the online list through its local GUI, and unilaterally initiates an add request. The request includes Device A's identifier, the intent to add the device, and optional verification information, and is sent to the cloud server via the communication module.

[0083] The cloud server queries the preset privacy settings of device B and performs the following operations based on the preset privacy settings of device B:

[0084] If device B is set to "automatically accept friend requests", the cloud server directly sends a relationship establishment command to device B. Device B automatically writes device A's identifier into the friend list of the local relationship database and returns a confirmation message to the cloud server. The cloud central relationship database updates the bidirectional friend relationship record, and the synchronization service engine pushes the relationship establishment notification to device A. After receiving the notification, device A writes device B's identifier into the friend list of the local relationship database.

[0085] If device B is set to "requires confirmation for friend requests", the cloud server pushes an add notification to device B; device B displays the request information to the user. If the user selects "decline", the process terminates, and the cloud pushes a rejection notification to device A; if the user selects "accept", device B writes device A's identifier into the friend list of the local relational database and returns a confirmation message to the cloud server; the cloud central relational database updates the two-way friend relationship record, and the synchronization service engine pushes a relationship establishment notification to device A; after receiving the notification, device A writes device B's identifier into the friend list of the local relational database.

[0086] This mode allows for flexible switching between automatic approval and confirmation via privacy settings, balancing efficiency and security. It is suitable for scenarios that require rapid team formation and scenarios that prioritize privacy protection.

[0087] The local exchange mode includes: the current user terminal device establishes a connection with other corresponding user terminal devices through near-field data exchange technology and exchanges standardized data packets. After successful verification through the local verification process, both parties write the other party's unique device identifier into the friend list of the local relationship database, and choose to immediately synchronize to the cloud server or temporarily store it locally for synchronization after connecting to the network, depending on the network status; the specific process is as follows:

[0088] Device A and Device B establish a physical layer connection through near-field data exchange technology, which includes NFC touch, QR code optical recognition, and Bluetooth Low Energy Direct. After the connection is established, the data exchanged between the two devices is a standardized structured data packet. The core of the data packet includes the unique identifiers of both devices, digital signatures, and optional auxiliary extension fields. All data is transmitted using a unified encoding format. In this embodiment, the near-field data exchange technology is an exchange function implemented based on near-field wireless communication technology.

[0089] After the receiving device obtains the data packet, it performs the local verification process: data integrity verification (verifying that the data packet has not been tampered with through a hash algorithm), identity legitimacy verification (verifying the authenticity of the sender's identity through a digital signature), and optional timeliness verification (verifying that the timestamp is within the valid window period).

[0090] If verification fails, terminate the process and send a "Exchange failed (invalid data)" message to the sender.

[0091] If the verification is successful, the receiver temporarily stores the sender's device unique identifier and generates a response data packet containing its own device unique identifier to return to the sender. Both parties then write the other party's device unique identifier and relationship attributes into their local relationship database friend list and mark it as "local exchange established".

[0092] Execute the following branches based on the device's network connectivity status:

[0093] If the network is connected, a synchronization task will be automatically triggered to update and upload the local relational database to the cloud server, update the central relational database, and achieve consistency between local and cloud data.

[0094] If the device is not connected to the network, the synchronization task will be temporarily stored locally and will be automatically executed once the network connection is restored.

[0095] After the exchange is completed, each party independently possesses the other's device information and can establish a voice connection without network synchronization.

[0096] This mode features complete offline operation, rapid setup, and data security, making it suitable for emergency scenarios without network coverage, such as underground spaces and remote areas.

[0097] To ensure consistency between the local relational database and the cloud-based central relational database, the relational management module is configured with a data synchronization mechanism. This mechanism follows the core principle that all communication permission decisions are ultimately based on the local relational database, and synchronization operations are only used to update the local relational database, rather than querying the cloud database with each communication.

[0098] Data synchronization mechanisms include online real-time synchronization mode and offline temporary storage and recovery mode;

[0099] The online real-time synchronization mode is used when the current user terminal device is connected to the internet. It proactively retrieves the latest relationship list from the cloud server and receives update commands pushed by the cloud server to update the local relationship database in real time. Specifically, when the device is connected to the internet, the system performs the following synchronization operations:

[0100] Pull Sync: The device actively sends a request to the cloud server to pull the latest friend relationship list for updating the local relationship database.

[0101] Push synchronization: When the friend relationships in the cloud central relational database change, the cloud server immediately pushes an update command to all relevant online devices. After receiving the command, the relevant devices update their local relational database in real time. The situations in which friend relationships change include adding friends, deleting friends, and modifying relationship attributes.

[0102] Offline temporary storage and recovery mode is used when the current user terminal device is not connected to the internet. Modifications to the local relational database take effect in real time and the operation record is temporarily stored. After the current user terminal device regains network access, the temporary record is automatically uploaded to the cloud server for merging. Specifically, offline temporary storage and recovery mode is used when the device is offline and online real-time synchronization cannot be performed. The system automatically switches to offline temporary storage and recovery mode, which includes the following stages:

[0103] Local Operations and Temporary Storage: All modifications performed by users on the local relational database in an offline environment (including adding friends through near-field exchanges, manually editing the friend list, modifying relational attributes, etc.) take effect in real time and are saved to the local relational database. At the same time, the system temporarily stores these operation records in a structured manner on the local storage medium.

[0104] Automatic network recovery: When the device detects that the network connection has been restored, the system automatically triggers a synchronization task to upload the locally stored operation records to the cloud server.

[0105] Data merging and conflict resolution: After receiving the temporary records, the cloud server merges them with the existing data in the central relational database. If a conflict occurs between the local modification and the existing data in the cloud during the merging process, the system will automatically handle it according to the preset conflict resolution rules to ensure that the data is not lost or duplicated, and ultimately achieve consistency between local and cloud data.

[0106] The relationship management module is also equipped with a data synchronization conflict resolution mechanism. When a conflict arises between local modifications and cloud updates, the mechanism resolves the conflict based on the last modification timestamp of the relationship attribute, retaining the attribute value updated by the timestamp. If the timestamps are the same, the local modification record takes precedence. Specifically, when a data conflict occurs between a modification operation in the local relationship database and an update command pushed by the cloud server (such as adding a friend in a different location or changing a friend relationship), the system uses the latest timestamp priority principle for resolution. The specific mechanism is as follows:

[0107] Each friend relationship attribute is associated with a last modified timestamp, which is generated by the device (local or cloud) that initiated the modification operation when the modification was made.

[0108] When two different versions of the same relational attribute (local version and cloud version) conflict, the system compares the timestamps of the two versions and retains the attribute value with the updated timestamp (i.e., the later value between the local modification timestamp and the cloud update timestamp).

[0109] In extreme cases, if the timestamps of the two versions are exactly the same, the system will prioritize the local modification record by default to ensure the immediate effectiveness and good experience of the user's local operations. At the same time, the local modification record will be synchronized to the cloud to ensure that the cloud data is ultimately consistent with the local data.

[0110] The strategy control module is used to execute voice link management decisions, including: determining the type of voice link established between the current user terminal device and other user terminal devices based on the friend list and the broadcast signal from the other end; generating link control instructions to control the communication module to establish, maintain and disconnect the voice link based on the number of voice links established by the current user terminal device, the preset upper limit of the number of connections, and the voice link type and signal strength of each established voice link.

[0111] The policy control module executes voice link management decisions, including the initial connection phase and the dynamic discovery phase:

[0112] The initial connection phase includes: detecting the online status of each friend in the current user terminal device's friend list, and the command communication module establishing a persistent voice link with the currently online friends;

[0113] The dynamic discovery phase includes: continuously scanning the peer broadcast signals of other user terminal devices, comparing the unique device identifier in each peer broadcast signal with the unique device identifier of each friend in the friend list, and analyzing whether the corresponding other user terminal devices are friends.

[0114] If it is a friend, then analyze whether the number of voice links established by the current user terminal device has reached the preset connection limit.

[0115] If this is not achieved, the instruction communication module establishes a persistent voice link with other corresponding user terminal devices;

[0116] If the condition has been met, the system analyzes whether there is a temporary voice link among the established voice links of the current user terminal device. If there is, the system instructs the communication module to disconnect the temporary voice link with the weakest signal strength and establish a persistent voice link with the corresponding other user terminal device. If there is no such link, the system instructs the communication module to select the persistent voice link with the weakest signal strength among the established persistent voice links and disconnect it, and then establish a persistent voice link with the corresponding other user terminal device.

[0117] If they are not friends, then analyze whether the number of voice links established by the current user terminal device has reached the preset connection limit:

[0118] If this is not achieved, the instruction communication module establishes a temporary voice link with other corresponding user terminal devices;

[0119] If the condition has been met, the system analyzes whether there is a temporary voice link among the established voice links of the current user terminal device. If there is, the system instructs the communication module to select the temporary voice link with the weakest signal strength among the established temporary voice links and disconnect it, and then establish a temporary voice link with the corresponding other user terminal device. If there is no such link, no action is taken, and the currently established persistent voice link is maintained.

[0120] Specifically, such as Figures 2 to 4 ,as well as Figure 6 As shown, the policy control module executes the following voice link management decisions, including an initial connection phase and a dynamic discovery phase: In the initial connection phase, when device A enters a working mode (e.g., power-on, wake-up from standby), the policy control module first queries the local relational database to obtain a list of unique device identifiers for all friends. Then, the policy control module detects the online status of each friend in the friend list: for distant friends who can be connected via far-field wireless communication technology through a cloud server, the communication module obtains their online status from the cloud server; for nearby friends who can be directly connected via near-field wireless communication technology, the module determines whether they are online based on the scanning results of the adjacency sensing module. The policy control module establishes persistent voice links with all currently online friends, forming a basic communication network.

[0121] During the dynamic discovery phase, the policy control module controls the neighbor sensing module of the current user terminal device to continuously scan, obtain the continuous scanning results of the neighbor sensing module, and monitor other user terminal devices in the surrounding environment. When the peer broadcast information of the corresponding other user terminal device is detected, and when the current user terminal device (device A) needs to establish a voice link with a target device (device B), the policy control module executes the following voice link management decision:

[0122] The policy control module queries the friend list of the current user terminal device (device A), compares the device unique identifier in the peer broadcast signal of device B with the device unique identifier of each friend in the friend list, and analyzes whether device B is a friend.

[0123] If device B is a friend, the policy control module executes the following sub-process:

[0124] Query the number of voice links currently established by device A and compare it with the preset upper limit of the number of connections. This upper limit can be configured by the user according to the device performance and usage scenario, with a default value of 16 concurrent connections.

[0125] If the preset connection limit is not reached, a persistent voice link will be directly authorized. This persistent voice link is persistent and its establishment and maintenance are not limited by the physical distance between the two parties, network conditions, or whether it can be wirelessly searched. It can be used for short-range calls through near-field wireless communication technologies such as Bluetooth, or for long-field wireless communication technologies such as Internet routing.

[0126] If the preset connection limit has been reached, further analysis will be conducted to determine if any temporary voice links exist among the established voice links of device A:

[0127] If a temporary voice link exists, the link with the weakest signal strength among all established temporary voice links is selected and disconnected, thus breaking the connection resource. Then, a persistent voice link is established with device B (the current friend) first. This design reflects the hierarchical principle that persistent connections take precedence over temporary connections.

[0128] If no temporary voice link exists (i.e., all currently connected links are persistent voice links), then select all links with weaker signal strength than device B from the established persistent voice links; if such a link exists, then disconnect the one with the weakest signal strength (i.e., the smallest value) and establish a new persistent voice link with device B; if no persistent voice link with weaker signal strength than device B exists (i.e., the current friend's signal strength is not lower than the signal strength of any connected persistent voice link), then refuse to establish a new voice link.

[0129] When a new persistent voice link is established with device B, the policy control module continuously monitors the call termination trigger conditions, which include user-initiated hanging up or network interruption. When either trigger condition is met, the system terminates the call normally.

[0130] If device B is not a friend, the policy control module executes the following sub-process:

[0131] Query the number of voice links currently established by device A and compare it with the preset upper limit of the number of connections. This upper limit can be configured by the user according to the device performance and usage scenario, with a default value of 16 concurrent connections.

[0132] If the preset connection limit is not reached, a temporary voice link will be established directly. This temporary voice link is temporary and can be used for short-range calls via near-field wireless communication technologies such as Bluetooth, or for long-range calls via far-field wireless communication technologies such as Internet routing. However, the establishment and maintenance of this link are limited by the physical distance between the two parties and the network conditions.

[0133] If the preset connection limit has been reached, further analysis will be conducted to determine if any temporary voice links exist among the established voice links of device A:

[0134] If a temporary voice link exists, select all voice links with weaker signal strength than those of device B (the currently unfamiliar device) from the temporary voice links already established by device A. If such a voice link exists, select the one with the weakest signal strength (i.e., the smallest signal strength value) and disconnect it, then establish a new temporary voice link with device B. If no temporary voice link with weaker signal strength than device B exists, i.e., the signal strength of all temporary voice links already established by device A is not lower than that of device B, then no action is taken, i.e., the establishment of a new temporary voice link is rejected.

[0135] If there is no temporary voice link, that is, all the voice links currently established by device A are permanent voice links, then no action is taken, and the currently established permanent voice links are maintained. This design reflects the core principle of prioritizing relationships: non-friends cannot preempt the resources of permanent voice links, but can only replace them with temporary voice links.

[0136] The strategy control module is also configured with a temporary voice link management mechanism, including: after the temporary voice link of the current user terminal device is established, continuously monitoring whether the peer broadcast signal of other user terminal devices that have established a temporary voice link can be scanned; when the corresponding peer broadcast signal is not scanned within a preset duration, it is determined that the adjacency relationship is terminated, the communication connection is automatically disconnected, the call is terminated, and the disconnection information is synchronized to other user terminal devices that maintain a voice link with the current user terminal device.

[0137] Temporary voice link management: After a temporary voice link is established, the policy control module continuously monitors whether the adjacency sensing module can scan the peer device (corresponding other user terminal devices) for the peer broadcast signal. The monitoring frequency adopts a scenario-adaptive dynamic adjustment strategy: the monitoring frequency is once every 170ms in the default scenario, once every 170ms in the active collaboration scenario, and once every 1s in the low power scenario.

[0138] During monitoring, if the peer device's broadcast signal is continuously detected within a preset duration, the temporary voice link is maintained, i.e., the temporary call state is maintained, and normal communication continues. At this time, the policy control module continuously monitors the call termination trigger conditions, which include user-initiated hanging up or network interruption. When either trigger condition is met, the system normally terminates the call and disconnects the temporary voice link resource.

[0139] If no broadcast signal from the peer device is detected within a preset duration, the system determines that the adjacency relationship is terminated, automatically disconnects the communication connection, and ends the call. The preset duration is 1 minute. After disconnection, the policy control module synchronizes the disconnection information with other user terminal devices maintaining the voice link with the current user terminal device through the communication module, ensuring the consistency of the connection status of devices within the network.

[0140] In this embodiment, the signal strength is determined as follows: all steps involving signal strength comparison use the filtered Received Signal Strength Indication (RSSI) estimate. The filtering process employs a two-stage filtering scheme of moving average filtering and Kalman filtering: the first-stage filtering quickly smooths high-frequency jitter through a sliding window, and the second-stage filtering suppresses low-frequency fluctuations through Kalman filtering, ultimately outputting a stable RSSI estimate for signal strength comparison and link replacement decision-making.

[0141] like Figure 6 The diagram illustrates different connection scenarios for this invention. Centered on the current user terminal device (marked as "me" in the diagram), it shows three types of connection relationships: A persistent connection establishes a persistent voice link between the current user terminal device and confirmed friend devices (friend 1, friend 2). This type of connection is unaffected by physical distance, network conditions, or environmental interference and can be maintained through short-range wireless links or long-range cloud relays. A temporary connection establishes a temporary voice link between the current user terminal device and a non-friend device (non-friend 1) based on the neighbor perception module scanning the other party's broadcast signal. This type of connection depends on the physical proximity between the devices and the quality of the wireless link. The connection termination is illustrated when, for another non-friend device (non-friend 2), since its broadcast signal cannot be scanned within a preset duration (as marked "not scanned within the preset duration" in the diagram), the system determines that the neighbor relationship is terminated and automatically disconnects the temporary voice link.

[0142] The strategy control module is also configured with a two-way call conflict resolution mechanism, which is used to resolve two-way call conflicts when the current user terminal device and other corresponding user terminal devices initiate call requests to each other within a preset time window, and ensure the uniqueness and orderliness of the voice link establishment.

[0143] The two-way call conflict resolution mechanism includes a conflict detection mechanism, a priority determination mechanism, and a conflict handling execution mechanism.

[0144] The conflict detection mechanism is as follows: both devices broadcast a call identifier. When a device receives the other party's call identifier at the same time as initiating a call, a two-way call conflict is determined to have occurred.

[0145] The priority determination mechanism is as follows: extract the unique device identifiers of both devices, convert them into comparable values ​​according to the preset unified encoding conversion rules, and determine the connection priority based on the numerical comparison results;

[0146] The conflict handling mechanism is as follows: the higher-priority device continues to maintain the connection establishment request, while the lower-priority device terminates its own call request and switches to the connection receiving mode to respond to the call request of the higher-priority device and complete the link establishment.

[0147] In this embodiment, the conflict detection mechanism, priority determination mechanism, and conflict handling execution mechanism of the two-way call conflict resolution mechanism are as follows:

[0148] The conflict detection mechanism is as follows: when both user terminals initiate a call request, they broadcast a signal with a call request identifier through the adjacency sensing module. The call request identifier contains at least the unique identifier of the user terminal device. When either device receives the call request identifier signal from the other device while initiating a call, the policy control module determines it to be a two-way call conflict.

[0149] The priority determination mechanism is as follows: the strategy control module extracts the unique identifiers of the conflicting devices, converts them into comparable values ​​according to a preset unified encoding conversion rule, and determines the link establishment priority by comparing the values; the unique identifier of the device is a globally unique identifier fixed at the factory, ensuring the determinism and immutability of the priority determination; the unified encoding conversion rule is to convert the unique identifier of the device into a decimal value, and the user terminal with the larger value gets a higher link establishment priority.

[0150] The conflict resolution mechanism is as follows: the user terminal with higher link establishment priority continues the original call process and maintains the connection establishment request; the user terminal with lower link establishment priority automatically terminates its own call request, immediately switches to called party response mode, responds to the call request of the higher-priority user terminal, and completes the voice link establishment. The preset time window is set according to network latency and signal propagation characteristics to ensure the timeliness of conflict detection; the two-way call conflict resolution mechanism ensures that only one unique voice link is established in concurrent call scenarios, avoiding resource waste and communication chaos.

[0151] The cloud server is used to provide enhanced services, including a central relational database and a synchronization service engine. The cloud server is configured with a load balancing mechanism and a multi-link adaptive routing strategy to ensure service stability and communication reliability for remote intercom between friends in scenarios with large-scale device access.

[0152] The central relationship database is used to store network-wide friend relationship data, including device unique identifier mapping, relationship type, relationship attributes, and timestamp information; the synchronization service engine is used to process the device terminal's active pull request and monitor the change events of the central relationship database. When a relationship changes, it actively pushes update instructions to the relevant online device terminal to achieve real-time synchronization between the local relationship database and cloud data.

[0153] The cloud server is configured with a load balancing mechanism, which includes:

[0154] Each user terminal device maintains its own unique incrementing request sequence number and attaches its own unique identifier and current request sequence number when sending a request to the cloud server;

[0155] The cloud server queues and processes requests in an orderly manner based on the device's unique identifier and request sequence number, and discards requests with duplicate or expired sequence numbers without processing them again.

[0156] In this embodiment, the load balancing mechanism is used to handle scenarios with a large number of concurrent accesses to the cloud server from multiple device terminals. It employs an ordered processing mechanism based on the device's unique identifier and request sequence number to avoid duplicate requests and disordered accumulation, ensuring the stability of the cloud service: Each user terminal maintains its own unique incrementing request sequence number, attaching this sequence number and its own unique identifier to each request sent to the cloud server; upon receiving a request, the cloud server extracts the device's unique identifier and the request sequence number, and queues and processes the requests in order according to the sequence number; the cloud server discards requests with duplicate or expired sequence numbers without reprocessing; through the combination of the device's unique identifier and the request sequence number, accurate identification and orderly scheduling of requests are achieved, distributing concurrent access pressure and realizing lightweight load balancing.

[0157] The system employs a multi-link adaptive routing strategy during remote intercom communication with friends. This multi-link adaptive routing strategy includes:

[0158] Real-time monitoring of the near-field wireless link status between two friends;

[0159] When the near-field wireless link is available and the communication quality meets the preset requirements, voice data is transmitted simultaneously through two paths: the near-field wireless link and the cloud server relay forwarding.

[0160] When the near-field wireless link is unreachable or the communication quality does not meet the preset requirements, voice data is relayed through the cloud server.

[0161] All control commands and voice data are transmitted using end-to-end encryption.

[0162] In this embodiment, the multi-link adaptive routing strategy is used in a remote intercom scenario between friends. Based on the physical distance and link quality between the two friends, it automatically selects the optimal voice data transmission path and ensures transmission security: Link reachability detection monitors the near-field wireless link status between the two friends in real time, including the signal strength and connection quality of technologies such as Bluetooth, Wi-Fi Direct, and Starlink; Multi-link parallel transmission: When the near-field wireless link is reachable and its quality meets communication requirements, voice data is transmitted simultaneously through two paths—the near-field wireless link and a cloud server relay, or simultaneously through the near-field wireless link and other far-field wireless communication technologies—achieving multi-link parallel backup and improving communication stability; Cloud relay: When the near-field wireless link is unreachable or its quality does not meet communication requirements, voice data is transmitted entirely through the cloud server relay, or entirely through other far-field wireless communication technologies, ensuring the connectivity of the remote intercom; End-to-end encryption: Regardless of the transmission path used, all control commands and voice data are transmitted using end-to-end encryption to ensure the privacy and security of communication data.

[0163] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A voice intercom system supporting hierarchical relationship and adjacency awareness, characterized in that: This includes cloud servers and several user terminal devices; The user terminal equipment includes: A communication module is used to establish a data transmission channel between the current user terminal device and the cloud server and other user terminal devices; wherein, the data transmission channel includes a voice link for transmitting voice data, and the voice link includes a persistent voice link and a temporary voice link; The adjacency sensing module is used to generate and broadcast the local broadcast signal of the current user terminal device, and also to scan the peer broadcast signals of other user terminal devices within the effective range of the broadcast; the local broadcast signal includes the unique device identifier of the current user terminal device; the peer broadcast signal includes the unique device identifier of the corresponding other user terminal device; A local relationship database is used to store a friend list, which includes several friends and a unique device identifier for each friend; The relationship management module is used to manage the local relationship database; The strategy control module is used to execute voice link management decisions, including: determining the type of voice link established between the current user terminal device and other user terminal devices based on the friend list and the broadcast signal from the other end; generating link control instructions to control the communication module to establish, maintain and disconnect the voice link based on the number of voice links established by the current user terminal device, the preset upper limit of the number of connections, and the voice link type and signal strength of each established voice link. The policy control module executes voice link management decisions, including the initial connection phase and the dynamic discovery phase: The initial connection phase includes: detecting the online status of each friend in the current user terminal device's friend list, and the command communication module establishing a persistent voice link with the currently online friends; The dynamic discovery phase includes: continuously scanning the peer broadcast signals of other user terminal devices, comparing the unique device identifier in each peer broadcast signal with the unique device identifier of each friend in the friend list, and analyzing whether the corresponding other user terminal devices are friends. If it is a friend, then analyze whether the number of voice links established by the current user terminal device has reached the preset connection limit. If this is not achieved, the instruction communication module establishes a persistent voice link with other corresponding user terminal devices; If the condition has been met, the system analyzes whether there is a temporary voice link among the established voice links of the current user terminal device. If there is, the system instructs the communication module to disconnect the temporary voice link with the weakest signal strength and establish a persistent voice link with the corresponding other user terminal device. If there is no such link, the system instructs the communication module to select the persistent voice link with the weakest signal strength among the established persistent voice links and disconnect it, and then establish a persistent voice link with the corresponding other user terminal device. If they are not friends, then analyze whether the number of voice links established by the current user terminal device has reached the preset connection limit: If this is not achieved, the instruction communication module establishes a temporary voice link with other corresponding user terminal devices; If the condition has been met, the system analyzes whether there is a temporary voice link among the established voice links of the current user terminal device. If there is, the system instructs the communication module to select the temporary voice link with the weakest signal strength among the established temporary voice links and disconnect it, and then establish a temporary voice link with the corresponding other user terminal device. If there is no such link, no action is taken, and the currently established persistent voice link is maintained.

2. The voice intercom system supporting hierarchical relationship and adjacency awareness according to claim 1, characterized in that: The strategy control module is also configured with a temporary voice link management mechanism, including: after the temporary voice link of the current user terminal device is established, continuously monitoring whether the peer broadcast signal of other user terminal devices that have established a temporary voice link can be scanned; when the corresponding peer broadcast signal is not scanned within a preset duration, it is determined that the adjacency relationship is terminated, the communication connection is automatically disconnected, the call is terminated, and the disconnection information is synchronized to other user terminal devices that maintain a voice link with the current user terminal device.

3. A voice intercom system supporting hierarchical relationships and adjacency awareness according to claim 1, characterized in that: The adjacency sensing module is configured with a scene-adaptive broadcasting and scanning strategy, including: The system broadcasts the local broadcast signal of the current user terminal device according to a preset period, and scans the remote broadcast signals of other user terminal devices within the effective range of the broadcast in a preset near-field frequency band. If the remote broadcast signal of the corresponding other user terminal device is detected within a preset duration, it is determined that the two parties establish an adjacency relationship; if the remote broadcast signal of the corresponding other user terminal device is not detected within the preset duration, it is determined that the adjacency relationship is terminated. The broadcast cycle and scan cycle are dynamically adjusted based on the current usage scenario and power consumption status of the user terminal device. The usage scenarios include the default scenario, the active collaboration scenario, and the low power scenario.

4. A voice intercom system supporting hierarchical relationships and adjacency awareness according to claim 1, characterized in that: The relationship management module supports multiple modes for establishing friend relationships, including invitation confirmation mode, search and add mode, and local exchange mode. The invitation confirmation mode includes: the current user terminal device generates an invitation request and sends it to the cloud server, which then pushes it to the corresponding other user terminal devices. After confirmation by the corresponding other user terminal devices, both parties write the other party's unique device identifier into the friend list of the local relationship database and synchronize the two-way friend relationship through the cloud server. The search and add mode includes: the current user terminal device selects other user terminal devices from the online user list and initiates an add request to the cloud server. The cloud server performs automatic approval or confirmation processing according to the preset privacy settings of the other user terminal devices. After confirmation, both parties write the other party's unique device identifier into the friend list of the local relationship database and synchronize the two-way friend relationship through the cloud server. The local exchange mode includes: the current user terminal device and other corresponding user terminal devices establish a connection and exchange standardized data packets through near-field data exchange technology. After the local verification process is passed, both parties write the other party's unique device identifier into the friend list of the local relationship database, and choose to immediately synchronize to the cloud server or temporarily store it locally and synchronize it after connecting to the network, depending on the network status.

5. A voice intercom system supporting hierarchical relationships and adjacency awareness according to claim 1, characterized in that: The relationship management module is also configured with a data synchronization mechanism, including an online real-time synchronization mode and an offline temporary storage and recovery mode; The online real-time synchronization mode is used when the current user terminal device is connected to the Internet, to actively pull the latest relationship list from the cloud server and receive update instructions pushed by the cloud server to update the local relationship database in real time; Offline temporary storage and recovery mode is used when the current user terminal device is not connected to the Internet, so that the modification operation of the local relational database takes effect in real time and the operation record is temporarily stored; Once the user's terminal device restores network access, the temporary records will be automatically uploaded to the cloud server for merging.

6. A voice intercom system supporting hierarchical relationships and adjacency awareness according to claim 1, characterized in that: The cloud server is configured with a load balancing mechanism, which includes: Each user terminal device maintains its own unique incrementing request sequence number and attaches its own unique identifier and current request sequence number when sending a request to the cloud server; The cloud server queues and processes requests in an orderly manner based on the device's unique identifier and request sequence number, and discards requests with duplicate or expired sequence numbers without processing them again.

Images