Patent Application
20250142296
The Mobile User Object System (MUOS) is a satellite-based communication system that was developed by Joint Department of Defense (DoD) services (Navy, Air Force and Army). MUOS provides global coverage for terminals to exchange voice and Internet Protocol (IP) data in tactical environments. It provides three methods, referred to as services, to pass voice and/or data between the terminals. Each service is unique in operation and capabilities.
Once such service is referred to as “group service.” This service establishes a “party bus”-like channel for all members to communicate. The MUOS Group service may allow terminals to pass voice and host data on the same channel. However, the group service may have limited capabilities (e.g., data rate, which may be limited to 9600 bits per second) and may be half-duplexed, meaning only one terminal may send host data at a time and all other terminals are automatically put into receive-only mode.
Methods performed by a host platform operable in a Mobile User Objective System (MUOS) network are provided herein. A method according to some examples may include monitoring for outgoing data from a client, parsing the outgoing data to determine a priority level associated with the outgoing data, and queuing the outgoing data based on the priority level. Some methods may include monitoring for Secure Network Management Protocol (SNMP) traps to determine a floor status associated with an over-the-air interface. In some methods, if an SNMP trap is received indicating that the floor status associated with the over-the air interface is ‘available, the queued outgoing data may be forwarded to a terminal for attempted transmission via the over-the-air interface.
Though not depicted in the illustration of
A description of the host platform (i.e., the host platform 110) is provided herein. The term “host platform” as used herein may refer to a logical implementation of communication and/or processing capabilities for performing steps or procedures described herein. For example, a host platform may refer to software (e.g., an application, a plug-in, an extension, or an add-on) executed by a computing device or may refer to a physical device implementing means for carrying out functionality described herein. In some examples, the term “host platform” may be used to refer to a physical implementation, i.e., hardware responsible for executing software to carry out functionalities described herein. In a hardware implementation, the host platform may be integrated within other physical nodes of the MUOS network, such as the terminal. Alternatively, the host platform may be implemented in hardware separate from other nodes of the MUOS networks. For instance, the host platform may refer to software executed by a computer processing unit (CPU) that is connected with one or more interfaces (e.g., wired and/or wireless interfaces). Examples of devices at which the host platform software may be executed, or which may be referred to as host devices themselves, may include: a handheld device, a mobile phone, a tablet computer, a laptop computer or other computing device, a network server, a server blade, radio infrastructure equipment such as a base station, access point, a modem, or specialized hardware for computing and/or communication in military contexts, such as devices of the Mounted Family of Computing Systems (MFoCS), Command Post Computing Environment (CPCE), Advanced Field Artillery Tactical Data System (AFATDS), and dismount soldier end-user devices.
A description of the terminals 120a, 120b, 120c, and 120d as illustrated in
A terminal 120 as illustrated in the example of
A processor as described herein (such as the processor 111 of the host platform 110, introduced and described in the context of
A processor as described herein (such as the processor 111 of the host platform 110, introduced and described in the context of
A memory (such as the memory 113 of the host platform 110 described in
The transceiver 123 of the terminal 120 is a bidirectional module responsible for transmitting and receiving signals to and from nodes within the MUOS system. It interfaces with both the processor, which provides data and command signals, and the antenna system, which facilitates over-the-air communication. The processor 121 and the transceiver 123 may, for example, be configured to utilize one or more modulation schemes or over-the-air communication such as code division multiple access (CDMA), or wideband CDMA (WCDMA), though those of ordinary skill in the art will appreciate that other types of modulation schemes may be utilized and remain consistent with examples described herein.
One or more antennas 125 are connected to the transceiver 122. The antenna 125 may be configured to operate in the Ultra-High-Frequency (UHF) band, optimizing communication with the MUOS satellite system. The antenna 125 may be part of an antenna system that includes fixed or steerable antennas, which may operate to ensure optimal signal reception and transmission, regardless of the terminal's orientation or location. The antenna 125 may include, for example, omnidirectional antennas, directional antennas, and/or antenna panels.
Before transmission, voice signals (which may be analog in nature) may be converted into digital signals using an Analog-to-Digital Converter (ADC), as digital signals may be more suitable for processing and transmission in a digital communication system. The terminal may process raw voice and/or raw data signals through encoding and compression to add redundancy to the data, for error detection and correction by a receiving terminal, while reducing the size of the data for efficiency. The processor may modulate the digital signals using a specific waveform suitable for communication in the MUOS network. This may involve adjusting properties (e.g., amplitude, frequency, or phase) of a carrier wave according to the data being sent. This prepares the data for transmission over the radio frequency (RF) medium. Once modulated, the signals may be passed through a power amplifier, boosting their strength for long-distance transmission. Amplified signals may then be transmitted via the terminal's antenna, radiating them as electromagnetic waves towards the satellite, depending on the communication architecture.
A receiving terminal may perform the above-referenced steps in a reversed sequence. For example, the receiving terminal may capture the RF signals using its antenna(s), demodulate the captured signals to retrieve the digital data, and then decode and decompress the digital data. In the case of voice data, the data may be converted back into analog form using a Digital-to-Analog Converter (DAC) for playback.
Methods proposed herein may provide means for applications to leverage the MUOS group service without requiring any modifications or even awareness of the fact that the MUOS group service is being used. This may be accomplished using software (which may be referred to herein as a middleware) that receives the data to be sent to members of the MUOS group and provides a prioritized queuing scheme to hold data until it is sent. Additionally, the middleware may monitor the terminal for channel availability to avoid collisions, prioritizes traffic to be sent, prevents undesirable channel conditions, provide voice override protection, message acknowledgement, and package data to be sent in an efficient manner to maximize network capacity. When an application sends data to the middleware, the middleware may handle all the interactions with the terminal to include packaging and sending the data to the terminal for transmission and receiving MUOS delivered data and providing it to receiving applications for their use. A middleware referred to herein may be executed by a computer, a processor, processing device, or a circuit (e.g., a general purpose or specialized circuit), for example, illustrated by the processor 111 of the host platform 110 in
It should be noted that an existing MUOS system may not have any built-in mechanisms to support coordinated multi-user channel access for this group service. In other words, a terminal's ability to send voice or data from a host may be a matter of which terminal accesses the channel first. In some methods for collision avoidance, when a terminal ceases to send voice/host data for a specific amount of time (e.g., 1 second), the terminal may be blocked from being able to transmit again for a given blocked period (e.g., 7 seconds). At that point, any other terminal may contend for the channel and send voice/data. Without the functionality for preventing a connected host platform from continuously sending data to its terminal, without (for example) at least a 1-second delay between packets, the terminal may never release the shared group channel, effectively blocking all other terminals from sending voice/data and resulting in a condition referred to as a “hot mic.” In addition, without any functionality supporting coordinated multi-user channel access, when a terminal is in receive-only mode, or when it is in the 7-second blocked period, host application data that is sent to the terminal may be simply dropped without any queuing for resend by the terminal, and without a notification to the application attempting to send data. This behavior may require applications to be aware of these MUOS-specific behaviors and to address them on their own.
In some examples, the MUOS group service may provide a voice override capability that enables any terminal to be able to interrupt an ongoing data transmission for the purpose of passing voice. In such cases, without the functionality of the middleware described herein, the interrupted transmitting terminal may receive no notification that an override has occurred, leaving part of all its data unsent and dropped. Current message-based applications typically deployed in broadcast, tactical networks may not be equipped to address this unique channel access scheme, resulting in their inability to leverage the MUOS group service.
If the channel is unavailable or busy, data carried by the transmission may be dropped. Because one or more of the group members may fail to receive or decode the transmission, the host platform 110 may fail to receive any notification, feedback, or other indication that the data was dropped. Without any notification or feedback, the host platform may not have any mechanism for retransmission of the dropped data.
As described substantially in paragraphs above, the host platform 110 operating within the MUOS network is configured to interface with the terminal 120 via at least one internet protocol (IP)-based connection. The interfaces 112 and 122 may permit the exchange of IP data between the host platform 110 and the terminal 120, including incoming IP data received over-the-air by the terminal 120 and/or outgoing IP data to be transmitted by the terminal 120 via the radio interface. The interfaces 112 and 122 also enable the host platform to assess the status of the radio channel and/or waveform being transmitted or received by the terminal 120.
As is further shown in
In some examples, a single physical interface between the host platform and the terminal may be configured to carry the user data traffic and the radio/waveform control information. Alternatively, multiple physical interfaces may be configured to separately carry the user data and the radio/waveform control information. In some examples, separate physical interfaces may be used to carry different user data traffic flows.
As is further shown in
The middleware 114 introduced in paragraphs above is described in greater detail herein. The middleware 114 may be a software (e.g., executed by a processor such as processor 111 shown of the host platform 110 of
As shown in
The core module 114a may use information from the trap module 114d to make decisions on data queuing, transmissions, or other aspects relating to communication via the over-the-air interface. The trap module 114d monitors the state of the terminal 120 according to one or more methods described in paragraphs below. In some examples, the trap module 114d may employ a network management protocol, such as Simple Network Management Protocol (SNMP).
SNMP is an open-source application layer protocol that provides functionality for monitoring and management of network elements. The SNMP architecture includes a manager, an agent, and one or more managed objects. The manager (represented by way of example in
SNMP messages are packet-based. Each packet may include, for example, a header, data, and checksum bytes. A packet may specify a message type or operation to be carried out (this is described in further detail in paragraphs below). SNMP devices utilize a Management Information Base (MIB), which acts as a codebook or dictionary for handling incoming messages correctly. A MIB is typically provided by a device manufacturer and provides definitions and info about the properties of managed resources and the services that the agents support. The MIB is organized in a tree structure with variables associated with unique object identifiers (OIDs), which correspond to the managed objects.
SNMP uses several key operations to manage and monitor network objects. Of particular note, SNMP uses the TRAP message (referred to interchangeably herein as a “trap,” or an “SNMP trap”) to inform an SNMP manager when an important event happens at the agent level. Agents may send system level notifications to the manager unilaterally when significant events occur. Traps may be asynchronous in nature, meaning they need only be sent when the agent has information to report. This may be beneficial when monitoring and managing alarms since traps may trigger instantaneously, rather than requiring a status request to be sent by the manager.
In some cases, the manager may also query an agent to ascertain the status of the managed network elements. For example, the GET message may be used by a manager to retrieve a value for a OID, while the GETNEXT message allows the manager to retrieve the next OID in the MIB tree, facilitating sequential data collection. GETBULK allows the manager to retrieve large data blocks, reducing the number of GETNEXT requests, and the SET operation modifies or sets the value of an object on a network device. The INFORM message is similar to the TRAP operation but requires the manager to send acknowledgment confirming receipt. The RESPONSE message is sent by an SNMP agent to reply to GET, SET, GETNEXT, GETBULK, or INFORM requests, providing requested data or operation status.
Although the description of examples provided herein may make specific reference to SNMP, it should be understood that other protocols for managing and monitoring network elements could be used interchangeably.
In the example shown in
The core module 114a may include functionality for sending data to the terminal 120 for transmission on the over-the-air interface. As shown in
The structure of incoming and outgoing data traffic is described herein. Data traffic may be organized into payloads, each of which may include one or multiple packets containing multiple messages. Packets to be sent are queued and transmitted according to their message type. For example, packets may be sent once or regularly (i.e., at periodic intervals). A packet sent in each payload may include acknowledgement (ACK) information associated with transmissions previously sent by other terminals. In some examples, the first packet sent in each payload may include a header (i.e., a ‘MsgRcvdAck’ header packet) used to acknowledge successful receipt of a previously received message (e.g., the last message received). In some examples, the last packet sent for each payload includes a trailer (i.e., an End-of-Message (EOM) trailer), which may indicate the end of all traffic flows for a session.
The inclusion of the ACK, or the type of ACK information included, may be dependent upon whether data is successfully decoded. The ACK information may include, for example, a positive acknowledgement if a header and trailer are received no errors are detected. In some examples, ACK information may include a negative acknowledgement (NACK) indicating that a header and/or trailer were not received or not decoded, or that errors were detected. For instance, a NACK may be issued in the event a data transmission was received and an attempt was made to decode the data, but was unsuccessful.
In some examples the outgoing data may include information that signals an end-of-message (EOM), or the completion of an outgoing transmission.
Further describing the architecture of
The core module 114a may include functionality for sending and/or receiving data to or from a client (e.g., an application). For example, the core module 114a may logically interface with clients 130 via a client module 114e, which may deliver IP application data to be queued and transmitted by the terminal 120 via over-the-air interface. By the same token, the core module 114a may attempt to parse data received via the listening module 114b and determine if the data is destined for a client 130. If so, it may route and deliver the data to the client via an API, shown in
The core module 114a may further include functionality for determining a priority associated with outgoing data. Data may be given or assigned one of three different priority levels. Each priority level may correspond to a backoff period, or a length of time that must elapse before channel access re-attempted. For example, for a medium priority level, if the channel cannot be access, the core module 114a may reattempt transmission after a medium period of time (e.g., applying a default backoff period). For a high priority data, if the channel cannot be accessed, the core module 114a may reattempt transmission after a relatively shorter period of time. For low priority data, a longer or less aggressive backoff period may be used. The priority determined for the outgoing data may depend upon whether a message carried in the data can be parsed or not. For instance, if a message cannot be parsed, the core module 114a may assign a default priority.
In addition, the priority determined for outgoing data may depend upon the content or nature of the message itself. For instance, a periodic broadcasting of position information may in some contexts be assigned a lower priority in comparison to a time-sensitive command and control messages issued to ground forces involved in a firefight. The core module 114a may be configured with a mapping between different types of messages and various priority levels.
Furthermore, the core module 114a may maintain multiple separate queues corresponding to the different priority levels. For instance, high priority data, medium priority data, and low priority data may each be stored in different queues. The core module 114a may negotiate access to the over-the-air interface to transmit queued data based on the priorities determined for the pending data. For example, the core module 114a may attempt to transmit data of the high priority queue more frequently that it does for data of the medium or low priority queues.
The core module 114a may include functionality for assessing and updating the priority of data present in a queue over time. For example, data may initially enter a low priority data queue or a medium priority data queue. Each data queue may operate in accordance with a first-in-first-out rule. The core module 114a may monitor how long data has been held within the queue. If the core module 114a determines that data has been present in a particular queue for an extended period of time (e.g., an amount of time that exceeds a threshold), the core module 114a may increase the priority of the data by moving the data e.g., from a low priority data queue to a medium priority data queue, or from the medium priority data queue to a high priority data queue. In other examples, the core module 114a may be configured to update the priority of data from a higher priority level to a lower priority level, or remove data from a queue entirely. For example, if retransmission has been attempted for data too many times (i.e., a number of times that exceeds a configured threshold), the core module 114a may determine to move the data to a lower priority queue or outright remove the data from the queue.
As described in further detail below, the middleware 114 may be configured to manage access to the network using the group service. The middleware 114 may do so by leveraging its functionality to assess the current network state and MUOS group floor status. To determine the group floor status, the trap module 114d may query terminal 120 in
One type of notification may be a ‘GRANTED’ notification. In this instance, the notification may be issued when the terminal 120 has successfully accessed the channel.
One type of notification may be a ‘RELEASED’ notification. In this case, this notification may be issued when a transmitting terminal stops transmitting for a given amount of time (e.g., at least 1 second).
One type of notification may be a ‘TAKEN’ notification. In this case, the notification is sent to indicate a type of traffic (voice or data) being transmitted to the group. This notification may or may not include an indication of which user is transmitting.
One type of notification may be a ‘DENIED’ notification. This notification may be generated at a transmitter terminal to indicate that the transmitting terminal is not permitted to access the group channel. The notification may or may not include an indication of a possible reason why the transmitting terminal could not take the floor to transmit.
One type of notification may be a ‘Push-to-talk enabled’ notification. This notification may be generated at the local terminal when an operator squeezes the hand-mic on the radio to initiate a voice transmission.
The middleware 114 may queue data and receive notifications and/or query the radio for the current status of the floor via SNMP. If the radio's group floor is available, the core module 114a and the multicasting module 114c may send the queued data to the terminal 120 to transmit across the MUOS group. If the group floor is not available, the core module 114a may intelligently cache the data until the floor is available. The trap module 114d may again query the terminal 120 for the current status of the floor, applying an appropriate backoff period in accordance with a priority level of the queued data, substantially as described in paragraphs above.
Further describing the floor brokering functionality introduced above, the middleware 114 may leverage the floor broker to prevent any instance of the middleware 114 causing the terminal 120 to endlessly transmit, thereby hogging the group floor. The floor broker functionality may track source addresses of host platforms that send data in the MUOS group and may implement a round robin approach for each host platform to have a turn at grabbing the group floor. For instance, a transmitting middleware 114 instance may include its own IP address within ACK information. Receiving middleware instances may then receive the transmitting instance's IP address and maintain the IP address in a cache. Each middleware instance may sort the cache in descending order. In this way, all middleware instances may be aware of each other's status within the cache. By tracking the source addresses of nodes in a running cache of known senders and indexing itself in the order of the cache, the middleware 114 may determine an order of host platforms that are permitted to attempt to transmit, and may know when its next opportunity to transmit may occur. The host platforms that are permitted to transmit within the round robin approach may or may not be fixed. For example, new nodes may be added or removed from the cache, which may avoid the scenario where host platforms that have data queued for transmission needlessly sit idle while other host platforms, which may not have data queued for transmission, remain silent.
At a defined, configurable interval, the middleware senders' IP addresses may be evicted from the cache, which may reduce the presence of “stale” nodes that have not transmitted recently. In addition, a maximum transmission duration may be configured at each middleware instance. The enforcement of the maximum transmission duration and the maintenance of the cache may ensure each middleware instance is provided with an opportunity to transmit and may help avoid the scenario where one middleware instance hogs the floor.
The core module 114a may queue data based on (1) a network connectivity status, (2) based on whether a data call is active, and/or (3) based on a status of the group floor. For example, for the terminal 120 to establish and maintain connectivity with the network, the terminal may need to be registered with the network (e.g. with satellite and/or ground infrastructure) and within a coverage area of the network infrastructure. The network may authenticate the identity of the terminal and authorize the terminal for communication with the network.
For a data call to be active, a MUOS group service must be established with terminals managed by the ground segment. A group may be formed by using access control mechanisms that restrict unauthorized users from joining or listening to group transmissions. In order for a terminal 120 to broadcast data to other members of the group, the terminal 120 must be a member of the group service.
If the core module 114a determines the network is unavailable or the data call is down, it may queue all data while simultaneously attempting to restore the data call, assuming the network is still active. If the network is unavailable (e.g., the terminal is outside of a coverage area of the network), the core module 114a may queue data to be transmitted when connectivity is reestablished and the terminal has an active data call.
If the terminal 120 has network connectivity and has an active data call, the floor must still be clear before the terminal 120 can broadcast queued data to other member terminals of the group service. If the floor is not clear, the core module 114a may cache and prioritize data according to one or more methods described herein.
Over time, the queue may accumulate various different repetitive or low-priority data. The middleware 114 may periodically refresh its queue to prioritize data for which transmissions were previously attempted but blocked. The middleware 114 may separately prioritize queued high priority data from queued repetitive or low-priority data. The periodic refreshing of queue(s) may be carried out in accordance with a backoff period corresponding to the priority of each queue, substantially as described in paragraphs above.
If, upon attempting a transmission, the channel is idle and data is queued for transmission, the middleware may move to a ‘TX’ state as shown at 940 and move the queued data via its logical/physical interface to the terminal 120 for transmission over-the-air. The middleware 114 may then, in some examples, monitor for an ACK confirming that the transmitted data was successfully received. It may only be necessary that a single node transmit an ACK, as it may be assumed in such case that all nodes operating on the group channel should have received the transmitted data.
If, while operating in the ‘IDLE/LISTEN state’ shown at 910, the middleware 114 detects the reception of a data transmission, the middleware 114 may move to an ‘RX’ state, shown in
In some examples, if an SNMP trap is issued indicating that the floor status associated with the over-the-air interface is ‘taken’ (i.e., in response to determining that the floor status is “taken”), the host platform 110 maintains the outgoing data within the queue for transmission at a subsequent time and/or sends a signal to the terminal 120 to prevent the terminal from transmitting via the over-the-air interface.
In some examples, the outgoing data is maintained within the queue in accordance with a backoff period corresponding to the priority level associated with the outgoing data.
In some examples, the host platform 110 may monitor for incoming data received via the over-the-air interface, parse the incoming data, and issue an SNMP trap including an acknowledgment of the incoming data.
In some examples, the host platform 110 stores information indicating a plurality of nodes that have transmitted using the over-the-air interface.
In some examples, the forwarded outgoing data include a packet including a header indicating an acknowledgement of a previously-received payload.
In some examples, the header includes an indication of an internet protocol (IP) address associated with a sender of the previously-received message and an identifier associated with the previously-received payload.
In some examples the forwarded outgoing data comprises a packet includes a trailer including an end-of-message (EOM) indication.
In some examples, the host platform 110 stores at least one internet protocol (IP) addresses associated with another host platform in a cache, determines an order of other host platforms that are permitted to transmit, and determines, based on the order of other host platforms that are permitted to transmit, a next opportunity when the host platform may transmit.
Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
This application claims the benefit of U.S. Provisional Application No. 63/546,596, filed Oct. 31, 2023, which is incorporated by reference as if fully set forth.
| Number | Date | Country | |
|---|---|---|---|
| 63546596 | Oct 2023 | US |
