Dynamic priority-based auracast broadcast source collaborative management system

Abstract

The application belongs to the technical field of wireless communication, and relates to an Auracast broadcast source cooperative management system based on dynamic priority, which comprises the following modules: a context credential generation module, which generates a context credential; an opportunistic broadcast cluster construction module, which constructs an opportunistic broadcast cluster; a campaign message generation and distribution module, which is distributed in the opportunistic broadcast cluster; a distributed credential verification module, which outputs a list of valid competitors; a broadcast right arbitration calculation module, which determines the dynamic attribution of a priority broadcast token; an adaptive transmission strategy generation module, which generates an adaptive transmission strategy; and a broadcast stream transmission execution module, which transmits an Auracast audio broadcast stream. The application solves the problem that it is difficult to meet the signal conflict and differentiated service quality requirements in a multi-source coverage overlapping scene.

Description

Technical Field

[0001] This invention belongs to the technical field of wireless communication and relates to an Auracast broadcast source collaborative management system based on dynamic priority. Background Technology

[0002] Bluetooth Auracast, with its ability to receive audio from multiple devices simultaneously, is widely used in public places such as airports, museums, and convention centers, providing users with flexible auditory services. The multi-channel nature of LE audio broadcasting also enables the simultaneous delivery of multiple languages ​​and content. As these application scenarios become increasingly diverse, overlapping coverage of multiple broadcast sources is becoming more common. Ensuring consistent listening for users, avoiding conflicts between multiple broadcast signals, and ensuring timely transmission of high-priority services have become crucial for improving the user experience and service reliability of LE audio broadcasting. Related collaborative management and synchronization optimization technologies are gradually becoming a research focus in this field.

[0003] Currently, there are relevant broadcast optimization and priority management technologies in the industry. Application number 202110883429.X discloses a method and device for synchronous listening to LE audio broadcast streams. This method helps users access the nearest channel to obtain a complete listening experience by playing audio streams with different start offset times in a loop through multiple channels.

[0004] Existing LE audio synchronous listening technology focuses on optimizing the listening integrity after user access, without considering the coordination and priority management between multiple broadcast sources. It cannot guarantee the timeliness of high-priority services in a multi-source environment, resulting in frequent signal conflicts during multi-source broadcasts. High-priority services are susceptible to interference, and the channel occupation of low-priority services also affects the overall spectrum resource utilization.

[0005] Existing broadcast-related technologies have shortcomings in adaptability to multi-source collaborative scenarios, dynamic priority management, and linkage optimization of physical layer parameters and priority states, making it difficult to meet the signal conflict and differentiated service quality requirements in scenarios with overlapping multi-source coverage. Summary of the Invention

[0006] To address the aforementioned problems, this invention provides an Auracast broadcast source collaborative management system based on dynamic priority.

[0007] The Auracast broadcast source collaborative management system based on dynamic priority includes the following modules: The context credential generation module receives business event data packets sent from the network side, verifies the business event data packets using digital signature technology, and generates context credentials after successful verification. The opportunistic broadcast cluster building module scans the signals of neighboring nodes in the wireless spectrum environment and builds opportunistic broadcast clusters based on signal coverage overlap. The campaign message generation and distribution module constructs campaign messages containing business priority parameters based on context credentials and distributes them within the opportunistic broadcast cluster. The distributed credential verification module receives campaign messages from other member nodes in the opportunistic broadcast cluster, performs distributed credential verification, and outputs a list of valid competitors. The broadcast right arbitration calculation module performs broadcast right arbitration calculation based on the local context credentials and the list of valid competitors to determine the dynamic ownership of the priority broadcast token; The adaptive transmission strategy generation module generates an adaptive transmission strategy for the physical layer of the Auracast protocol in response to the ownership status of the priority broadcast token. The broadcast stream transmission execution module executes an adaptive transmission strategy, modulating and transmitting the Auracast audio broadcast stream using the configured RF parameters.

[0008] In a further embodiment of the present invention, the context credential generation module is configured to perform the following steps: The digital signature field is decrypted using a pre-configured public key certificate to restore the original message digest, and a hash operation is performed on the business event data payload to generate a local message digest; When the local message digest matches the original message digest, the business event data payload and local device status information are encapsulated to generate a context credential.

[0009] In a further embodiment of the present invention, the opportunistic broadcast cluster construction module is used to perform the following steps: Analyze the captured beacon frames to obtain the received signal strength indication, physical location parameters, and signal coverage radius of neighboring nodes; If the received signal strength indication is higher than the preset signal strength threshold, the Euclidean distance between the local machine and the neighboring node is calculated. When the Euclidean distance is less than the sum of the local signal coverage radius and the signal coverage radius of the neighboring nodes, the neighboring nodes are added to the opportunistic broadcast cluster.

[0010] A further aspect of this invention involves constructing an election message that includes business priority parameters, comprising the following steps: Extract the business type field from the context credential and convert it into a numerical business priority parameter based on a preset mapping table; Obtain the device's unique identifier and monotonically increasing anti-replay serial number; The business priority parameters, context credential timestamp information, device unique identifier, and anti-replay serial number are encapsulated into a campaign message according to the collaborative protocol format.

[0011] In a further embodiment of the present invention, the distributed credential verification module is configured to perform the following steps: Parse campaign messages from other member nodes and extract their context credentials and digital signatures; Verify the validity of the digital signature field using a pre-installed public key certificate; Get the current system time and determine whether the current system time is within the closed interval defined by the event effective timestamp of the other party's context credential; Nodes that have passed signature verification and are within their validity period will be added to the list of valid competitors.

[0012] A further aspect of this invention involves performing distributed credential verification, including the following steps: Extract the event timestamps of the context credentials from the campaign message; Get the current system time and compare it with the event's effective timestamp; Filter out campaign messages whose current system time is outside the range of the event's effective timestamp.

[0013] In a further embodiment of the present invention, the broadcast right arbitration calculation module is used to perform the following operations: Compare the local business priority parameters with the highest business priority parameters in the list of valid competitors; If the service priority parameter of this machine is equal to the highest service priority parameter, then the random backoff counter value of this machine is further compared with the random backoff counter value of a competitor with the same service priority parameter. If the random backoff counter value of this machine is the minimum value among all the values ​​participating in the comparison, then the ownership status of the priority broadcast token is determined to be held by this machine.

[0014] In a further embodiment of the present invention, the adaptive emission strategy generation module is configured to perform the following steps: If the priority broadcast token is held by the local machine, a dominant transmission policy is generated, and the policy is configured with transmission power parameters and broadcast interval parameters. If the priority broadcast token is not held by the local machine, a courtesy broadcasting policy is generated. The policy configuration reduces the transmission power to below a preset power threshold or increases the broadcast interval parameter through a power backoff operation.

[0015] In a further embodiment of the present invention, the broadcast stream transmission execution module is configured to perform the following operations: Load the audio payload data to be broadcast, and encode the audio payload data into broadcast isochronous stream data packets using the broadcast interval parameters and metadata identifiers determined in the adaptive transmission strategy; The RF front-end circuit is driven to transmit broadcast time stream data packets on the target broadcast channel using the transmit power parameters determined in the adaptive transmit strategy.

[0016] A further aspect of the present invention involves transmitting broadcast time stream data packets on a target broadcast channel, comprising the following steps: During the transmission of broadcast and other time-stream data packets, the dynamic ownership status of the priority broadcast token is monitored in real time. In response to an event of lost priority broadcast token, an interrupt service routine is triggered to either abort the current broadcast process or switch to a courtesy broadcast strategy to degrade the Auracast audio broadcast stream.

[0017] In summary, the present invention has the following beneficial technical effects: 1. The system receives service event data packets from the network side and generates time-sensitive and verifiable context credentials, enabling each broadcast source's broadcast behavior to be associated with authenticated service instructions. This mechanism provides an objective and unified decision-making basis for inter-node collaboration, thereby achieving broadcast resource allocation based on the real-time importance of services and ensuring that high-priority services can obtain broadcast resources first.

[0018] 2. An opportunistic broadcast cluster is constructed, and an election based on distributed credential verification is executed within the cluster, establishing a collaborative mechanism that does not require a centralized coordinator. Each broadcast source node can autonomously discover potential interference sources and verify the legitimacy of broadcast requests on an equal footing, reducing dependence on a single control node and enabling it to operate effectively even when local network connections are unstable.

[0019] 3. Based on the broadcast right arbitration result, an adaptive transmission strategy of dominance or concession is dynamically generated. The logical priority decision is transformed into a specific radio frequency parameter adjustment at the physical layer. The winning node can adopt more aggressive transmission parameters to ensure broadcast coverage and timeliness, while the losing node can actively reduce channel occupation by adjusting power or spacing, thereby realizing dynamic control of wireless spectrum resources and reducing the possibility of signal collision. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. The drawings are used to provide a further understanding of the present invention.

[0021] Figure 1 This discloses a schematic diagram of the framework in the embodiments of this application.

[0022] Figure 2This discloses a flowchart of an embodiment of this application. Detailed Implementation

[0023] The following is in conjunction with the appendix Figures 1-2 A preferred description of the present invention is provided below.

[0024] See attached document Figures 1-2 This invention proposes an Auracast broadcast source collaborative management system based on dynamic priority, comprising the following modules: The context credential generation module receives business event data packets sent from the network side, verifies the business event data packets using digital signature technology, and generates context credentials after successful verification. The opportunistic broadcast cluster building module scans the signals of neighboring nodes in the wireless spectrum environment and builds opportunistic broadcast clusters based on signal coverage overlap. The campaign message generation and distribution module constructs campaign messages containing business priority parameters based on context credentials and distributes them within the opportunistic broadcast cluster. The distributed credential verification module receives campaign messages from other member nodes in the opportunistic broadcast cluster, performs distributed credential verification, and outputs a list of valid competitors. The broadcast right arbitration calculation module performs broadcast right arbitration calculation based on the local context credentials and the list of valid competitors to determine the dynamic ownership of the priority broadcast token; The adaptive transmission strategy generation module generates an adaptive transmission strategy for the physical layer of the Auracast protocol in response to the ownership status of the priority broadcast token. The broadcast stream transmission execution module executes an adaptive transmission strategy, modulating and transmitting the Auracast audio broadcast stream using the configured RF parameters.

[0025] In one embodiment of the present invention, the context credential generation module is configured to perform the following steps: The digital signature field is decrypted using a pre-set public key certificate to restore the original message digest, and a hash operation is performed on the business event data payload to generate a local message digest. When the local message digest matches the original message digest, the business event data payload and local device status information are encapsulated to generate a context credential.

[0026] Specifically, the context credential generation module is executed by the terminal device acting as the broadcast source. The terminal device has a built-in network communication module and a data processing unit. The network communication module maintains a connection with a preset network context server with a unique network address through an encrypted socket layer channel established based on the transmission control protocol, and obtains business event data packets sent by the network context server in real time.

[0027] Business event data packets use a standardized data exchange format, such as the lightweight data exchange format JSON, to encode the data structure. The data mainly includes the business type, target group identifier, event effective timestamp, and geofence information. The business type is a classifier indicating the nature of the broadcast content, such as emergency alerts, boarding notices, public announcements, or background music. The event effective timestamp follows the ISO 8601 standard or a Unix timestamp and is used to define the effective start and end times of the context credential. The target group identifier is used to identify the broadcast service recipients, which can be a flight number, meeting agenda number, or a general identifier for all users. The geofence information is used to define the coordinate data of the physical spatial range of the broadcast's effective area. It can be a combination of the center point's latitude and longitude coordinates and the radius length, or it can be a sequence of coordinates of multiple vertices defining a polygonal region.

[0028] Once the network communication module receives the complete business event data packet, it hands it over to the data processing unit. The data processing unit parses the business event data packet, separating it into a business event data payload and an additional digital signature field. The data processing unit retrieves the public key certificate of a pre-configured network context server from its local secure storage. The network context server uses its confidential private key to encrypt the hash digest of the business event data payload to generate a digital signature. The terminal device, acting as the broadcast source, uses the corresponding public key to decrypt and verify the signature. The private key signature mechanism is based on asymmetric encryption technology, such as the elliptic curve digital signature algorithm. The data processing unit then uses a preset hash algorithm, such as the secure hash algorithm SHA-256, to process the business event data payload and generate a local message digest.

[0029] Simultaneously, using the public key of the network context server, the digital signature field is decrypted to restore the original message digest calculated by the network context server before sending. By comparing the local message digest with the original message digest, if the two are completely consistent, it is confirmed that the source of the business event data packet is genuine and the content has not been tampered with during transmission, and the verification is successful; if the verification fails, the business event data packet is discarded.

[0030] After successful verification, the data processing unit further obtains the device status information of the local machine, such as the device's media access control address or universally unique identifier. The data processing unit encapsulates the verified business event data payload and the local device status information into a unified structured data object. The local device status information contains at least one device identifier that can uniquely identify the broadcast source within the opportunistic broadcast cluster. The encapsulated data object generates a context credential with authorization validity, timeliness, and verifiability. The context credential is a locally generated data structure that logically aggregates authoritative business instructions from the network side and the local machine's identity information. The context credential is temporarily stored in local memory for use in subsequent broadcast right elections.

[0031] For example, suppose an Auracast broadcast source device at Gate 1 of an airport, with the unique identifier DEV-GATE01-AURA-001, receives a service event data packet from a network context server with the IP address 192.168.1.1. The data packet received by the broadcast source device contains a JSON-formatted service event data payload, the content of which is {“eventType”:“FINAL_CALL”,“targetGroupId”:“CZ3101”,“validFrom”:1672531200”,“validTo”:1672531500”,“geoFence”:{“type”:“circle”,“center”:[113.3,23.1],“radius”:50}} and an additional digital signature field, the value of which is a hexadecimal string 0xABCDEF….

[0032] The broadcast source device performs a SHA-256 hash operation on the JSON data payload to obtain a local message digest, such as "0x123456...". The device uses a pre-stored network context server public key to decrypt the digital signature "0xABCDEF...", restoring the original message digest, which also has the value "0x123456...". Since the two digest values ​​are equal, the data verification passes. The broadcast source device integrates the verified business event data payload with the local identifier "DEV-GATE01-AURA-001" to generate a complete context credential in memory. The data structure of the context credential is {"credentialConten": {"eventType": "FINAL_CALL", "targetGroupId": "CZ3101", ...}, "sourceId": "DEV-GATE01-AURA-001", "signatureVerified": true}, which is used in the subsequent broadcast rights competition process.

[0033] In one embodiment of the present invention, the opportunistic broadcast cluster construction module is used to perform the following steps: The system analyzes and captures beacon frames to obtain the received signal strength indication, physical location parameters, and signal coverage radius of neighboring nodes. If the received signal strength indication is higher than a preset signal strength threshold, the system calculates the Euclidean distance between itself and neighboring nodes. When the Euclidean distance is less than the sum of the signal coverage radius of itself and the signal coverage radius of neighboring nodes, the system adds the neighboring nodes to the opportunistic broadcast cluster.

[0034] Specifically, after generating context credentials, the terminal device executes the opportunistic broadcast cluster building module. The terminal device's radio frequency control unit switches its wireless transceiver to scanning mode and performs periodic scanning operations on a preset broadcast management channel. The broadcast management channel is a logical channel dedicated to collaborative information exchange between broadcast sources. In a specific embodiment, it can be set to one of the three main broadcast channels of Bluetooth Low Energy technology, such as the channel with channel index 37, to avoid conflict with the standard Auracast audio data stream channel.

[0035] Periodic scanning operations can be set to a scanning period of 1000ms-2000ms, with a scanning window within each period. The scanning window can be set to 100ms-200ms, based on the analysis of typical Bluetooth Low Energy beacon frame length and transmission interval. A 100ms window is sufficient to capture beacon frames from neighboring nodes within a single broadcast event period, ensuring timely discovery. Controlling the upper limit of the window to within 200ms effectively limits the time the RF front-end is in a high-power receiving state, which conforms to low-power design principles. This parameter configuration is adjusted within this range according to the actual network density and device power consumption requirements. This parameter configuration aims to balance the timeliness of node discovery with the device's own power consumption, in order to capture beacon frames sent by other Auracast broadcast sources in space. The beacon frame is a specially formatted Bluetooth Low Energy broadcast data packet, and its data payload adopts a custom format, encapsulating the physical location parameters of the transmitting source and the signal coverage radius.

[0036] When the receiving front end of the terminal device captures a beacon frame, the physical layer hardware synchronously measures and outputs the received signal strength indication of the beacon frame, and submits the raw data of the beacon frame to the data processing unit. The data processing unit first parses the fixed header of the beacon frame to obtain the unique identifier of the transmitting source device, and then parses its data payload, which contains the physical location parameters pre-written by the transmitting source and its own signal coverage radius.

[0037] The data processing unit executes a two-stage screening process. In the first stage, the received signal strength indication is compared with a preset signal strength threshold. This threshold is an empirical value set based on a wireless signal attenuation model for typical indoor environments. For example, a threshold of -75dBm is estimated based on the logarithmic distance path loss model in wireless propagation theory, applicable to typical scenarios such as open office environments or airport waiting halls. If the received signal strength is below the threshold, it usually means the signal source is outside the effective communication range or is severely obstructed. In this case, the neighboring node is considered too far away, and the data is discarded without further processing. In the second stage, for neighboring nodes that pass the first stage screening, the data processing unit uses its pre-stored local physical location parameters and local signal coverage radius to perform geometric coverage overlap calculations with the physical location parameters and signal coverage radius of the other party parsed from the beacon frame. The physical location parameters are a set of data describing the spatial location of the device, such as two-dimensional or three-dimensional Cartesian coordinates provided by an indoor UWB positioning system.

[0038] Geometric coverage overlap is calculated by determining the straight-line distance between two broadcast sources and comparing it to the sum of their signal coverage radii. Specifically, the straight-line distance is calculated using the following formula:

[0039] in, This represents the calculated straight-line distance between the two broadcast sources; This represents the physical location parameters of the broadcast source device in a two-dimensional coordinate system. The physical location parameters can be statically configured during device deployment or dynamically obtained through an indoor positioning system. This represents the physical location parameters of nearby broadcast sources parsed from the beacon frame; the unit of each coordinate value is meters (m); the condition for determining whether the signal coverage areas overlap in this step is... ,in This is the signal coverage radius of this broadcast source. The signal coverage radius of the nearest broadcast source is defined, and both are preset through device configuration. If the calculation results show that the signal coverage ranges of the two sources overlap spatially, then the nearest node is determined to be a valid candidate member of the cluster.

[0040] The data processing unit adds or updates the unique device identifiers, physical location parameters, and latest received signal strength indications of all selected cluster candidate members to a dynamically maintained topology list in local memory. The locally maintained topology list is stored in a data structure, such as a hash table, in the device's dynamic random access memory, using the unique device identifier as the key and objects containing information such as location and signal strength as the value. The real-time set of members in this list constitutes the opportunistic broadcast cluster used for subsequent broadcast rights negotiation. The opportunistic broadcast cluster is a logical concept referring to the set of all neighboring broadcast source nodes that exist in the locally maintained topology list at any given time, and its members are dynamically changing.

[0041] For example, the broadcast source for Gate 1, DEV-GATE01-AURA-001, assumes its physical location parameters are coordinates (10, 20), and its signal coverage radius is... The range is 50m. The system begins scanning and receives a beacon frame from the broadcast source DEV-GATE02-AURA-002 at gate 2 within a scanning window. The received signal strength is measured to be -68dBm, and the physical location parameters of the other party are (40, 60) obtained from its payload. The signal coverage radius is 50m. The distance is 50m. The system determines that -68dBm is greater than the preset signal strength threshold of -75dBm, therefore it proceeds to the second stage of geometric calculation, substituting the values ​​into the formula to calculate the distance between the two points. m. Then, calculate the sum of the signal coverage radii of the two devices as... m, because Since m is less than the sum of the radii (100m), the overlap condition is met. Therefore, the system stores the information of DEV-GATE02-AURA-002 in the locally maintained topology list.

[0042] Within the same scan cycle, suppose the system receives another beacon frame from a distant coffee shop broadcast source, DEV-CAFE-AURA-001, and measures its received signal strength as -90dBm. Since -90dBm is less than the signal strength threshold of -75dBm, the system discards the beacon frame data. After this round of scanning, the opportunistic broadcast cluster established by broadcast source DEV-GATE01-AURA-001 contains only one member, namely DEV-GATE02-AURA-002.

[0043] In one embodiment of the present invention, constructing an election message containing business priority parameters includes the following steps: Extract the business type field from the context credential and convert it into a numerical business priority parameter according to the preset mapping table; obtain the local device unique identifier and monotonically increasing anti-replay serial number; encapsulate the business priority parameter, context credential timestamp information, device unique identifier and anti-replay serial number into a campaign message according to the collaborative protocol format.

[0044] Specifically, after establishing the opportunistic broadcast cluster, the data processing unit of the terminal device then executes the campaign message generation and distribution module to generate and broadcast campaign messages. The campaign messages clearly define all the information required for winning broadcast rights. The data processing unit retrieves the generated context credentials from local memory. The data processing unit parses the context credentials, extracting the business type field value and the event effective timestamp field value, and converts the string value of the business type field into a numerical business priority parameter according to a preset mapping table. The business priority parameter quantifies the business importance level as an integer value. For example, the mapping relationship can be set as "emergency alarm" corresponding to priority 10, "boarding notification" to priority 8, "public address" to priority 5, and "background music" to priority 2. The business priority parameter and the event effective timestamp together constitute the core data payload for participating in the broadcast rights competition.

[0045] The data processing unit obtains the device's unique identifier and reads the current count value from a locally maintained monotonically increasing counter. This count is used as a sequence number to prevent replay attacks. The sequence number is a 32-bit unsigned integer that increments by one with each campaign message sent. The receiver can defend against malicious replay attacks by checking the monotonicity of the sequence number. The data processing unit ensures that all nodes in the cluster can parse the message coordination protocol format in the same way, according to a predefined arrangement, data type, and byte length of the fields in the campaign message. It encapsulates the core data payload, the device's unique identifier, the sequence number, and the complete context credential itself into a structured data packet. This data packet is the campaign message containing source authentication information, which in this embodiment is the complete context credential. It serves as unforgeable evidence to prove the legitimacy and urgency of the broadcast source service.

[0046] The data processing unit submits the election message to the radio frequency control unit (RF control unit). The RF control unit, according to a preset time division multiple access (TDMA) scheduling strategy, waits for a specific broadcast time slot allocated to it. When the specific broadcast time slot arrives, the RF control unit drives the radio frequency front-end circuitry. A time slot on the broadcast management channel refers to a time segment within the TDMA mechanism used on the broadcast management channel. Each cluster member is allocated one or more unique time slots within a superframe period to send its election message, thus avoiding broadcast collisions. Data frames encapsulating the election message are sent as broadcast packets on the broadcast management channel, ensuring that all member nodes within the opportunistic broadcast cluster can receive the message.

[0047] For example, broadcast source DEV-GATE01-AURA-001, located at gate 1, begins generating campaign messages after constructing an opportunistic broadcast cluster containing DEV-GATE02-AURA-002. The data processing unit invokes the context credentials, extracts the service type as FINAL_CALL, and converts it into a numerical service priority parameter of 10 according to the internal mapping table. It then extracts the event validity timestamp information {"validFrom": 1672531200, "validTo": 1672531500}. These two elements constitute the data payload.

[0048] The system obtains the device's unique identifier, DEV-GATE01-AURA-001, and reads the local sequence number counter, finding its current value to be 125. The system assembles the service priority parameter 10, timestamp information, device unique identifier DEV-GATE01-AURA-001, sequence number 125, and the context credential generated in the context credential generation module into a complete election message data packet according to the coordination protocol format. Assuming that DEV-GATE01-AURA-001 is allocated to the first time slot of the current superframe according to the scheduling policy, the system broadcasts the election message on the broadcast management channel at the beginning of that time slot through its radio frequency front-end. At this time, DEV-GATE02-AURA-002, as a cluster member, will acquire and receive this election message. Simultaneously, DEV-GATE01-AURA-001 updates its local sequence number counter to 126 for future use.

[0049] In one embodiment of the present invention, the distributed credential verification module is configured to perform the following steps: Parse campaign messages from other member nodes to extract their context credentials and digital signatures; verify the validity of the digital signature fields using a pre-set public key certificate; obtain the current system time and determine whether it falls within the closed interval defined by the event effective timestamp of the other party's context credentials; add node information that has passed signature verification and is within its validity period to the list of valid competitors.

[0050] Specifically, after the campaign message is broadcast in the campaign message generation and distribution module, the data processing unit of the terminal device, together with its radio frequency control unit, executes the distributed credential verification module. The radio frequency control unit switches the wireless transceiver to the receiving mode and continuously acquires the broadcast management channel, specifically capturing data frames transmitted in the time slots allocated to other member nodes in the opportunistic broadcast cluster.

[0051] Whenever a data frame is received, the RF control unit delivers it to the data processing unit. The data processing unit first parses the data frame according to the cooperation protocol format; if it is not in the election message format, it is discarded. For valid election messages, they are temporarily stored in a dedicated receive buffer. The receive buffer is memory space allocated in the device's volatile memory, used to temporarily store election messages from other nodes that are yet to be processed. Then, the data processing unit initiates the distributed credential verification process. Distributed credential verification is a verification process executed independently by each node in the cluster without the participation of a centralized certification authority. Its core lies in establishing trust using asymmetric encryption technology and a shared time base. The distributed credential verification process includes two core stages.

[0052] In the first stage, the data processing unit extracts the sender's unique identifier and its accompanying complete context credential from the campaign message. The context credential is separated into a credential data payload and a digital signature field. The unit then retrieves the pre-installed public key certificate of the network context server from its local secure storage. This public key certificate, which is pre-written into the device's non-volatile storage via a secure channel when the device leaves the factory or joins the network, contains the network context server's identity information and public key. Using standard cryptographic libraries, such as the widely used open-source library LibTomCryp (whose source code and documentation are publicly available), LibTomCryp performs digital signature verification calculations to confirm that the context credential was indeed issued by a legitimate network context server and has not been tampered with. If the signature verification fails, the campaign message is determined to be forged or corrupted and removed from the receive buffer.

[0053] In the second phase, for campaign messages that have passed signature verification, the data processing unit further parses the event validity timestamp in its context credentials. It obtains the current system time provided by the local real-time clock module. This current system time is provided by the device's internal hardware clock and periodically synchronized with an authoritative time server via the Network Time Protocol (NTP) to ensure consistent time bases across all nodes in the cluster and prevent timestamp verification errors caused by clock drift. The current system time is compared with the valid start and end times in the event validity timestamp. Only when the current system time falls within the closed interval defined by the timestamp is the campaign message considered time-sensitive and valid. If the context credentials have expired or have not yet taken effect, the campaign message is also considered invalid and removed.

[0054] All senders of campaign messages that pass the verification in the above two stages are considered valid competitors. The list of valid competitors is a data structure, such as a linked list or dynamic array, where each element contains at least one competitor's unique device identifier and its business priority parameter, clearly describing the current competitive landscape. The data processing unit extracts these competitors' unique device identifiers and the business priority parameters contained in their campaign messages, collectively forming a dynamically updated list of valid competitors, which is stored in local memory for use in subsequent broadcast right arbitration calculations.

[0055] For example, after broadcasting its campaign message, the broadcast source DEV-GATE01-AURA-001 at gate 1 enters the acquisition state. Assuming the current system time is Unix timestamp 1672531300, it receives a campaign message from opportunistic broadcast cluster member DEV-GATE02-AURA-002 within its acquisition time slot. First, broadcast source DEV-GATE01-AURA-001 parses the message, extracting the context credentials of DEV-GATE02-AURA-002. The credential data payload is {"eventType": "BOARDING", "targetGroupId": "MU5101", "validFrom": 1672531250, "validTo": 1672531600, ...}, with the attached digital signature field "0xGHIJKL...".

[0056] The first stage of verification is initiated. DEV-GATE01-AURA-001 uses the pre-set network context server public key to verify “0xGHIJKL…”. Assuming the calculation result shows that the signature is legal and valid, the second stage of verification is then initiated. DEV-GATE01-AURA-001 compares the current system time 1672531300 with the timestamp in the credential.

[0057] Because 1672531250≤1672531300≤1672531600, the timestamp 1672531300 is valid. Since both verification stages have passed, DEV-GATE02-AURA-002 is confirmed as a valid competitor. The processor of DEV-GATE01-AURA-001 stores the unique device identifier of DEV-GATE02-AURA-002 and its service priority parameters, assuming that "BOARDING" corresponds to priority 8, into its local list of valid competitors. The current content of the list of valid competitors is [{deviceId: "DEV-GATE02-AURA-002", priority: 8}].

[0058] In one embodiment of the present invention, the broadcast right arbitration calculation module is used to perform the following steps: Compare the local machine's business priority parameter with the highest business priority parameter in the list of valid competitors; if the local machine's business priority parameter is equal to the highest business priority parameter, then further compare the local machine's random backoff counter value with the random backoff counter value of a competitor with the same business priority parameter; if the local machine's random backoff counter value is the minimum value among all the values ​​compared, then determine that the priority broadcast token is held by the local machine.

[0059] Specifically, after the distributed credential verification module generates a list of valid competitors, the data processing unit of the terminal device executes the broadcast right arbitration calculation module to perform broadcast right arbitration calculation. This calculation is a deterministic algorithm implicitly synchronized across all nodes in the cluster. Each node independently calculates and arrives at a consistent conclusion regarding token ownership based on the same input data—all valid campaign messages—without requiring additional negotiation or voting. The data processing unit reads the business priority parameter generated for itself in the campaign message generation and distribution module from local storage as its local business priority weight. This business priority weight is a value generated by the local context credentials in the campaign message generation and distribution module. Simultaneously, it iterates through the list of valid competitors, extracts the business priority weights of all competitors, and finds the maximum value, i.e., the highest competitive priority.

[0060] The data processing unit executes a two-stage comparison logic. In the first stage, it compares the local machine's business priority weight with the highest competing priority. If the local machine's business priority weight is significantly greater than the highest competing priority, the local machine wins the arbitration. If it is less, the local machine loses the arbitration. If the two are equal, the second stage proceeds to a tie-breaking logic. In the second stage, the data processing unit selects all competitors with the same business priority weight from the list of valid competitors, forming a set of tie-breaking competitors.

[0061] The random backoff counter is an unsigned integer generated by the device's local pseudo-random number generator before each election message is generated. Its value is included in the election message and broadcast to other nodes. It is specifically used to break deadlocks when priorities are equal, ensuring that arbitration always produces a unique winner. The local random backoff counter value is compared with the random backoff counter values ​​of each competitor in the set of tie-breaker competitors. If the local random backoff counter value is the unique minimum among all compared values, the local node is determined to have won in a tie. In any other case, the local node is determined to have lost.

[0062] Based on the final arbitration result, the data processing unit updates the locally maintained system state machine. The system state machine is a state variable in the device firmware or operating system kernel, containing at least two basic states: "holder" and "acquirer." Its state transitions are driven by the result of the broadcast right arbitration calculation. If the arbitration result is a win, the system state machine is set to the "holder" state. This state logically indicates that the local machine has obtained and holds a virtual priority broadcast token. The priority broadcast token is a logical, non-physical token that represents the right to broadcast first in the opportunistic broadcast cluster within a specific time period. If the arbitration result is a failure, the system state machine is set to the "acquirer" state.

[0063] For example, broadcast source DEV-GATE01-AURA-001 at gate 1 begins arbitration calculation. First, it learns from its own records that its service priority weight is 10 and the random backoff counter value generated when producing the election message is 42. Meanwhile, to make the example more complete, assume that during this period it also receives a valid election message from VIP lounge broadcast source DEV-VIP-LOUNGE-001, which also has a service priority weight of 10 and a random backoff counter value of 99. Therefore, the list of valid competitors for DEV-GATE01-AURA-001 is updated to [{deviceId: "DEV-GATE02-AURA-002", priority: 8, random: 150}, {deviceId: "DEV-VIP-LOUNGE-001", priority: 10, random: 99}].

[0064] The data processing unit traverses the list, determining the highest competition priority to be 10. The system then compares its own priority weight of 10 with the highest competition priority of 10, finding them equal. A tie-breaking logic is then initiated, selecting DEV-VIP-LOUNGE-001 as the tie-breaker with the same priority of 10. Next, the system compares its own random backoff counter value of 42 with DEV-VIP-LOUNGE-001's value of 99. Since 42 is less than 99, according to the minimum value wins rule, DEV-GATE01-AURA-001 wins the tie, resulting in a final arbitration result of victory. The data processing unit switches the local system state machine from the "acquirer" state to the "holder" state, logically marking that the local machine has successfully acquired the priority broadcast token.

[0065] In one embodiment of the present invention, the adaptive launch strategy generation module is configured to perform the following steps: If the priority broadcast token is held by the local machine, a dominant transmission strategy is generated, which configures the transmission power parameters and broadcast interval parameters. If the priority broadcast token is not held by the local machine, a courtesy transmission strategy is generated, which configures the transmission power to be reduced to below a preset power threshold or the broadcast interval parameter to be increased through a power backoff operation.

[0066] Specifically, after the broadcast right arbitration calculation module updates the system state machine, the terminal device's data processing unit responds to the current state of the state machine and executes the adaptive transmission strategy generation module to generate an adaptive transmission strategy. The adaptive transmission strategy dynamically adjusts the set of parameters used to control the behavior of the radio frequency front-end, and its content is directly determined by the ownership status of the priority broadcast token. The data processing unit first initiates a real-time monitoring task. This task polls at intervals shorter than the broadcast management channel scanning period, such as every 50ms, which is less than the minimum broadcast interval parameter of 100ms. This ensures that at least one token state change is detected within a single broadcast event cycle, thereby achieving a rapid response to dynamic broadcast right ownership and reducing the possibility of unnecessary signal conflicts caused by state update delays. The system state machine's current state is checked through polling. If the system state machine is detected to be in the "holder" state, it indicates that the device currently holds the priority broadcast token, and a high-priority metadata identifier is set.

[0067] The data processing unit then loads the preset dominant transmission strategy into the physical layer parameter buffer to be configured. The dominant transmission strategy specifically includes the following configuration instructions: Command 1: Set the transmit power parameter to the maximum allowable value within the range supported by the device, such as +10dBm. The maximum transmit power parameter is the highest legal transmit power value set according to local radio management regulations and the device's own radio frequency hardware capabilities. Command 2 sets the broadcast interval parameter to the shortest duration allowed by the Auracast protocol specification. The shortest broadcast interval parameter is a parameter that indicates the minimum time interval between two consecutive Auracast broadcast events. A shorter interval means more timely information updates and lower latency. For example, 100ms has a broadcast interval that meets or is close to the minimum time interval supported by the Auracast broadcast and other time-stream BIS to achieve low-latency audio transmission. Instruction 3: In the metadata field of the extended broadcast data packet of the Auracast audio stream to be broadcast, a specific identifier code indicating high priority is placed. The high priority metadata identifier is a special byte sequence or bit that is pre-agreed among all nodes in the cluster to distinguish the importance of the broadcast stream at the application layer or the receiver user interface.

[0068] Conversely, if the system state machine is detected to be in the "acquirer" state, indicating that the local machine does not currently hold a token, the data processing unit loads a preset courtesy transmission strategy. This courtesy transmission strategy specifically includes one or a combination of the following configuration instructions: Instruction 1: Execute a power backoff operation. The power backoff operation is an action that actively reduces the signal transmission power to below a preset power threshold. Its purpose is to create clear communication space for the token-holding entity's priority broadcast without completely stopping broadcasting. For example, -5dBm is set as the preset power threshold. The value is selected based on suitability for airports, museums, and exhibitions. In the core application scenario of the center, -5dBm can achieve short-range broadcast coverage of 10-20m, which matches the needs of high-density deployment of broadcast sources and only local small-area coverage of a single device in such scenarios. Compared with the dominant transmission strategy of +10dBm and the default transmission power of +5dBm of the device, -5dBm can achieve 15dB and 10dB of power attenuation, reducing the coverage range of the broadcast signal. The preset power threshold can be used in combination with any broadcast interval adjustment value. Using power back-off to this threshold alone can also achieve the design goal of yielding transmission, adapting to broadcast source deployment scenarios with different densities. Instruction two, increasing the broadcast interval parameter, is another form of courtesy behavior. It reduces channel occupancy by decreasing the amount of data packets sent per unit time. For example, extending it to a courtesy interval of 500ms or longer doubles the broadcast period, reducing channel occupancy to 1 / 5 or less of that of the priority broadcast source, thus actively releasing spectrum resources by reducing the broadcast frequency. Whether it's a dominant transmission strategy or a courtesy transmission strategy, the physical layer configuration parameters are stored in a physical layer parameter buffer, waiting for the RF control unit to read and apply them.

[0069] For example, the system state machine of broadcast source DEV-GATE01-AURA-001 at gate 1 has switched to the "holder" state. After the real-time monitoring task of the data processing unit detects this state, it generates a dominant transmission strategy. It writes the following instructions into the physical layer parameter buffer: sets the transmit power to +10dBm, sets the broadcast interval to 100ms, and adds a key-value pair with priority_flag=1 to the Auracast metadata to be sent.

[0070] Meanwhile, DEV-GATE02-AURA-002 and DEV-VIP-LOUNGE-001, as the losers in the competition, also completed the same arbitration calculation within their respective devices and concluded that they had failed. Therefore, their system state machines are both in the "acquirer" state. Accordingly, the data processing unit of DEV-GATE02-AURA-002 generates a concessionary transmission strategy, such as backing down its transmission power from the default +5dBm to a preset power threshold of -5dBm, and increasing the broadcast interval from 200ms to 800ms. DEV-VIP-LOUNGE-001 may adopt another concessionary strategy, such as keeping the transmission power unchanged, but increasing the broadcast interval to 1000ms. In this way, DEV-GATE01-AURA-001, which holds the token, obtains the most favorable physical layer resources for broadcasting, while other nodes actively reduce potential interference.

[0071] In one embodiment of the present invention, the broadcast stream transmission execution module is configured to perform the following steps: The audio payload data to be broadcast is loaded, and the audio payload data is encoded into broadcast isochronous stream data packets using the broadcast interval parameters and metadata identifiers determined in the adaptive transmission strategy. The radio frequency front-end circuit is driven to transmit the broadcast isochronous stream data packets on the target broadcast channel using the transmit power parameters determined in the adaptive transmission strategy.

[0072] Specifically, after generating an adaptive transmission strategy and storing it in the physical layer parameter buffer, the terminal device's data processing unit and RF control unit work together to execute the broadcast stream transmission execution module. The data processing unit loads the audio payload data to be broadcast from local storage or a real-time audio input stream. The audio payload data is an uncompressed digital audio signal, such as 16-bit quantized, 24kHz sampling rate pulse code modulation (PCM) data.

[0073] The audio payload data, along with the adaptive transmission strategy read from the physical layer parameter buffer, is submitted to the baseband processing module. Baseband encoding is the process of converting the audio payload data into a digital baseband signal suitable for wireless transmission, including audio compression, channel coding, and packet construction. Based on the broadcast interval parameters and metadata identifiers determined in the adaptive transmission strategy, the baseband processing module calls an audio codec conforming to the Bluetooth core specification, such as the LC3 codec, to encode and package the audio payload data, generating a series of data in broadcast and other time-stream formats sent to the radio frequency control unit.

[0074] The RF control unit configures the gain of the power amplifier in the RF front-end circuit according to the transmit power parameters determined in the adaptive transmit strategy. The RF front-end circuit is the hardware part responsible for converting digital baseband signals into RF signals and transmitting them over the air. It mainly includes a digital-to-analog converter, a mixer, a power amplifier, and an antenna. The RF front-end circuit operates on the target broadcast channel, which is one of the Bluetooth Low Energy physical channels specified by the Auracast protocol for transmitting broadcast and other time-series data.

[0075] According to the set broadcast interval, broadcast isochronous stream BIS data packets are modulated and transmitted sequentially. Broadcast isochronous stream BIS data packets are the basic transmission units that carry a small segment of encoded audio data, forming a continuous Auracast audio broadcast stream. The Auracast audio broadcast stream is a collection of one or more broadcast isochronous stream BIS as defined by the Bluetooth LEAudio technical specification, used for connectionless audio data transmission to an undetermined number of receiving devices.

[0076] Throughout the transmission process, a parallel monitoring thread continuously and frequently checks the system state machine defined in the RF control unit. Once this monitoring thread detects a transition from the "holder" state to the "acquirer" state in the system state machine, a token loss event occurs. This token loss event is a logical event, signifying that the device has failed in the most recent round of broadcast right arbitration and has lost its priority broadcasting right. The token loss event triggers a high-priority interrupt. This interrupt service routine suspends the current broadcast transmission process and instructs the system to re-execute the adaptive transmission strategy generation module to generate a new transmission strategy that conforms to the courtesy principle, thereby achieving real-time degradation or complete interruption of the Auracast audio broadcast stream.

[0077] For example, the broadcast source DEV-GATE01-AURA-001 at Gate 1 currently holds a priority broadcast token, and its adaptive transmission strategy is a transmission power of +10dBm and a broadcast interval of 100ms. The system loads PCM audio payload data containing the message "Flight CZ3101 Last Call". The baseband processing module uses the LC3 codec to encode the audio data into a series of BIS data packets at 100ms intervals, embedding a high-priority identifier in the metadata of each data packet. The RF control unit configures the power amplifier to continuously transmit these data packets on the target channel at a power of +10dBm, forming a strong signal, low-latency Auracast audio broadcast stream.

[0078] During the broadcast, assuming a higher-priority airport-wide emergency notification begins broadcasting, and its broadcast source wins in the next round of arbitration, the arbitration calculation result of DEV-GATE01-AURA-001 becomes a failure, and its state machine switches from "holder" to "acquirer". The state machine state change is captured by the monitoring thread and triggers an interrupt. The interrupt service routine then instructs the system to perform a degradation operation, that is, to regenerate the courtesy transmission strategy, such as reducing the transmission power to -5dBm and extending the broadcast interval to 800ms. DEV-GATE01-AURA-001's broadcast of "Flight CZ3101" does not completely stop, but continues in a much weaker signal and at a much lower frequency, thereby actively giving up spectrum resources to a more important emergency notification.

[0079] See attached document Figure 2 The Auracast broadcast source collaborative management method based on dynamic priority includes the following steps: S1. Receive the service event data packet sent by the network side, and verify the service event data packet using digital signature technology. After successful verification, generate a context credential. S2. Scan the signals of neighboring nodes in the wireless spectrum environment and construct an opportunistic broadcast cluster based on the signal coverage overlap; S3. Construct an election message containing business priority parameters based on context credentials and distribute it within the opportunistic broadcast cluster; S4: Receive campaign messages from other member nodes in the opportunistic broadcast cluster, perform distributed credential verification, and output a list of valid competitors; S5. Perform broadcast right arbitration calculation based on the local context credentials and the list of valid competitors to determine the dynamic ownership of the priority broadcast token; S6. In response to the ownership status of the priority broadcast token, generate an adaptive transmission strategy for the physical layer of the Auracast protocol; S7. Execute the adaptive transmission strategy, modulate and transmit the Auracast audio broadcast stream using the configured RF parameters.

[0080] Each of the modules can be implemented in whole or in part through software, hardware, or a combination thereof. It supports hardware embedded in or independent of the processor in the computer device, and also supports software stored in the memory of the computer device, so that the processor can call and execute the operations corresponding to each of the above modules.

[0081] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. An Auracast broadcast source collaborative management system based on dynamic priority, characterized in that, Includes the following modules: The context credential generation module receives business event data packets sent from the network side, verifies the business event data packets using digital signature technology, and generates context credentials after successful verification. The opportunistic broadcast cluster building module scans the signals of neighboring nodes in the wireless spectrum environment and builds opportunistic broadcast clusters based on signal coverage overlap. The campaign message generation and distribution module constructs campaign messages containing business priority parameters based on context credentials and distributes them within the opportunistic broadcast cluster. The distributed credential verification module receives campaign messages from other member nodes in the opportunistic broadcast cluster, performs distributed credential verification, and outputs a list of valid competitors. The broadcast right arbitration calculation module performs broadcast right arbitration calculation based on the local context credentials and the list of valid competitors to determine the dynamic ownership of the priority broadcast token; The adaptive transmission strategy generation module generates an adaptive transmission strategy for the physical layer of the Auracast protocol in response to the ownership status of the priority broadcast token. The broadcast stream transmission execution module executes an adaptive transmission strategy, modulating and transmitting the Auracast audio broadcast stream using the configured RF parameters.

2. The Auracast broadcast source collaborative management system based on dynamic priority according to claim 1, characterized in that, The context credential generation module is used to perform the following operations: The digital signature field is decrypted using a pre-configured public key certificate to restore the original message digest, and a hash operation is performed on the business event data payload to generate a local message digest; When the local message digest matches the original message digest, the business event data payload and local device status information are encapsulated to generate a context credential.

3. The Auracast broadcast source collaborative management system based on dynamic priority according to claim 1, characterized in that, The opportunistic broadcast cluster construction module is used to perform the following operations: Analyze the captured beacon frames to obtain the received signal strength indication, physical location parameters, and signal coverage radius of neighboring nodes; If the received signal strength indication is higher than the preset signal strength threshold, the Euclidean distance between the local machine and the neighboring node is calculated. When the Euclidean distance is less than the sum of the local signal coverage radius and the signal coverage radius of the neighboring nodes, the neighboring nodes are added to the opportunistic broadcast cluster.

4. The Auracast broadcast source collaborative management system based on dynamic priority according to claim 1, characterized in that, Constructing an election message that includes business priority parameters involves the following steps: Extract the business type field from the context credential and convert it into a numerical business priority parameter based on a preset mapping table; Obtain the device's unique identifier and monotonically increasing anti-replay serial number; The business priority parameters, context credential timestamp information, device unique identifier, and anti-replay serial number are encapsulated into a campaign message according to the collaborative protocol format.

5. The Auracast broadcast source collaborative management system based on dynamic priority according to claim 1, characterized in that, The distributed credential verification module is used to perform the following operations: Parse campaign messages from other member nodes and extract their context credentials and digital signatures; Verify the validity of the digital signature field using a pre-installed public key certificate; Get the current system time and determine whether the current system time is within the closed interval defined by the event effective timestamp of the other party's context credential; Nodes that have passed signature verification and are within their validity period will be added to the list of valid competitors.

6. The Auracast broadcast source collaborative management system based on dynamic priority according to claim 1, characterized in that, Performing distributed credential verification includes the following steps: Extract the event timestamps of the context credentials from the campaign message; Get the current system time and compare it with the event's effective timestamp; Filter out campaign messages whose current system time is outside the range of the event's effective timestamp.

7. The Auracast broadcast source collaborative management system based on dynamic priority according to claim 1, characterized in that, The broadcast rights arbitration calculation module is used to perform the following operations: Compare the local business priority parameters with the highest business priority parameters in the list of valid competitors; If the service priority parameter of this machine is equal to the highest service priority parameter, then the random backoff counter value of this machine is further compared with the random backoff counter value of a competitor with the same service priority parameter. If the random backoff counter value of this machine is the minimum value among all the values ​​participating in the comparison, then the ownership status of the priority broadcast token is determined to be held by this machine.

8. The Auracast broadcast source collaborative management system based on dynamic priority according to claim 1, characterized in that, The adaptive launch strategy generation module is used to perform the following steps: If the priority broadcast token is held by the local machine, a dominant transmission policy is generated, and the policy is configured with transmission power parameters and broadcast interval parameters. If the priority broadcast token is not held by the local machine, a courtesy broadcasting policy is generated. The policy configuration reduces the transmission power to below a preset power threshold or increases the broadcast interval parameter through a power backoff operation.

9. The Auracast broadcast source collaborative management system based on dynamic priority according to claim 1, characterized in that, The broadcast stream transmission execution module is used to perform the following operations: Load the audio payload data to be broadcast, and encode the audio payload data into broadcast isochronous stream data packets using the broadcast interval parameters and metadata identifiers determined in the adaptive transmission strategy; The RF front-end circuit is driven to transmit broadcast time stream data packets on the target broadcast channel using the transmit power parameters determined in the adaptive transmit strategy.

10. The Auracast broadcast source collaborative management system based on dynamic priority according to claim 9, characterized in that, Sending broadcast stream data packets on the target broadcast channel includes the following steps: During the transmission of broadcast and other time-stream data packets, the dynamic ownership status of the priority broadcast token is monitored in real time. In response to an event of lost priority broadcast token, an interrupt service routine is triggered to either abort the current broadcast process or switch to a courtesy broadcast strategy to degrade the Auracast audio broadcast stream.

Images