Patent Application
20100082829
The present disclosure relates generally to wireless communication systems and more particularly to fast group communication between subscribers in peer-to-peer wide area networks within a wireless communication system.
A wide area network (WAN) is a network which covers a large geographical area, and uses communications circuits and systems to connect participating network nodes. “Wide area” coverage is defined by a number of fixed base stations which are typically distributed geographically over a large area and are connected over a wired network. Often these stations are distributed in such a way that no one station could cover the same geographic area by itself (however this isn't always the reason for such a wide area network). This enables a first mobile wireless radio within the coverage of a first fixed base station to communicate with other (second, third, etc.) mobile wireless radios within the coverage of remote fixed (second, third, etc.) base stations. Other types of units which can be on the wide area network (WAN) are console units—these are units where users can communicate to other console users as well as mobile radio users; however the console connects to the network over a wire rather than wirelessly.
Wireless wide area networks utilize communication technologies such as WIMAX (Worldwide Interoperability for Microwave Access), UMTS (Universal Mobile Telecommunications Service), GPRS (General Packet Radio Service), CDMA (Code division multiple access), GSM (Global System for Mobile communications), CDPD (Cellular Digital Packet Data), HSDPA (High-Speed Downlink Packet Access), 3G (third generation), 4G (fourth generation), and the like, to transfer data.
Within a wide area network, a variety of communication scenarios can co-exist. For example, one use of the wide area network is to enable a group call that allows one mobile radio user to transmit to many mobile radio users who are listening. Other examples of communication scenarios within a wide area network are a private call (e.g., a private call from one mobile radio to another mobile radio), a short data call (e.g. text messaging), and an emergency call. Conventional wide area network topologies use a centralized infrastructure such as a centralized controller within a wide area network to maintain and distribute mobility information of mobile radio users to intended stations. Such distribution of mobility information of a mobile radio user may either occur periodically after the establishment of a group call or a private call or an emergency call. Detrimentally, distributing such mobility information during such calls maximizes the media delay. Further, having a centralized controller to perform the functions of maintaining and distributing mobility information to stations affects the scalability of the wide area network and is susceptible to a single point of failure thereby affecting the entire system.
In addition, in such wide area networks utilizing a centralized controller, a mobile radio user wishing to establish a group call with other mobile radio users within the group must send the media to all the stations within the wide area network, irrespective of whether that particular station is serving a mobile radio user belonging to the group. In this case, the bandwidth is not efficiently utilized as the media is sent to all the stations including those stations which are not serving any mobile radio users belonging to the group. Accordingly, there is a need for a system and method for wide area network (WAN) communication that reduces media delay, eliminates single points of failure, and reduces bandwidth consumption associated with communication between stations as well as from stations to subscribers.
The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views, together with the detailed description below, are incorporated in and form part of the specification, and serve to further illustrate embodiments of concepts that include the claimed invention, and explain various principles and advantages of those embodiments.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the disclosure.
The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the disclosure so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.
Disclosed is a method of operating a peer to facilitate fast group communication between subscribers in a peer-to-peer wide area network. In the peer-to-peer wide area network, each of the subscribers are affiliated to a talkgroup, and further registered to at least one peer within the peer-to-peer wide area network. In operation, the peer exchanges messages with other peers to determine that one or more peers listed in a talkgroup topology is still active. When the peer receives a media for a talkgroup from a subscriber affiliated to the talkgroup, the peer duplicates the media for the talkgroup, and unicasts the duplicate media to the one or more peers that are listed as active in the talkgroup topology to enable the one or more peers to deliver the media to the respectively registered subscribers affiliated to the talkgroup.
Further, a Subscriber Steward configured within a peer maintains a master subscriber topology database including information related to at least one subscriber assigned to the Subscriber Steward, a peer to which each of the at least one subscriber is registered, and a talkgroup to which each of the at least one subscriber is affiliated. The Subscriber Steward sends an update to a Talkgroup Steward that controls a talkgroup about information related to one or more of the at least one subscriber that are affiliated to the talkgroup. The Talkgroup Steward which is configured within a peer updates a master talkgroup topology database based on the update received from the Subscriber Steward, the master talkgroup topology database including information related to the one or more of the at least one subscriber affiliated to the talkgroup controlled by the Talkgroup Steward, and a peer to which each of the one or more of the at least one subscriber is registered. The Talkgroup Steward also generates a talkgroup topology including information related to one or more peers with which the one or more of the at least one subscriber affiliated to the talkgroup are still registered and sends the talkgroup topology to each of the one or more peers, such that, when a subscriber of the one or more of the at least one subscriber registered with one of the one or more peers initiates a group communication for the talkgroup, the one of the one or more peers duplicates media associated with the group communication and sends the duplicated media to only those peers which information is included in the talkgroup topology, for delivery of the media to the respectively registered subscribers affiliated to the talkgroup.
A base station 110-n can be located at each network location 105-n. Each base station 110-n is a base station that is a fixed (non-mobile), full-duplex, radio frequency (RF) (wireless) modem (capable of having both a transmit and a receive frequency pair) which receives control and media (data/voice) from one or more mobile radios and presents the control/media to an entity (the Peer) which typically coincides within the base station. The Peer sends the control/media to other Peers on the WAN. In turn, when the base station's Peer receives control/media from other Peers on the wire, the Peer forwards the control/media to the base station so that the base station may transmit the media wirelessly to the one or more mobile radios.
A Peer 120-n, in accordance with some embodiments, is a functional unit located within each base station 110-n or console unit. For example, as illustrated in
In accordance with some embodiments, the Peers 120-n are behind a firewall (not shown) which serves to provide a means of protection for the associated base station which operates within the communication network 125. For example, firewalls do not allow packets to be received unsolicited from other hosts, computers, devices, and the like on the communication network 125.
Note that the WAN topology of
Within each network location 105-n, one or more subscribers 130-n can communicate through the respective base stations 110 to other devices within the P2P WAN 100. For example, as illustrated in
The Peer 120 optionally includes a display, an input device, and a buffer memory. Although not shown, the Peer 120 also includes an antenna switch, duplexer, circulator, or other highly isolative means (not shown) for intermittently providing information packets from the transmitter circuitry 203 of the transceiver 202 to the antenna 205 and from the antenna 205 to the receiver circuitry 204 of the transceiver 202. The Peer 120 can be an integrated unit containing at least all the elements depicted in
The processor 201 includes one or more microprocessors, microcontrollers, DSPs (digital signal processors), state machines, logic circuitry, or any other device or devices that process information based on operational or programming instructions. Such operational or programming instructions are, for example, stored in the memory 206. The memory 206 may be an IC (integrated circuit) memory chip containing any form of RAM (random-access memory) or ROM (read-only memory), a floppy disk, a CD-ROM (compact disk read-only memory), a hard disk drive, a DVD (digital video disc), a flash memory card or any other medium for storing digital information. One of ordinary skill in the art will recognize that when the processor 201 has one or more of its functions performed by a state machine or logic circuitry, the memory 206 containing the corresponding operational instructions may be embedded within the state machine or logic circuitry. The operations performed by the processor 201 and the rest of the components of Peer 120 are described in detail below.
The transmitter circuitry 203 and the receiver circuitry 204 enable the Peers 120-n to communicate information packets to and acquire information packets from subscribers 130-n. In this regard, the transmitter circuitry 203 and the receiver circuitry 204 include conventional circuitry to enable digital or analog transmissions over a wireless communication channel. The transmitter circuitry 203 and the receiver circuitry 204 are designed to operate over both a cellular air interface (e.g., Global System for Mobile communication (GSM), Code Division Multiple Access (CDMA), Wide-band CDMA (WCDMA), Universal Mobile Telecommunications System (UMTS), and the like) and an ad hoc networking air interface (e.g., BLUETOOTH, 802.11 WLAN (wireless local area network), 802.16 WiMax, and the like).
The implementations of the transmitter circuitry 203 and the receiver circuitry 204 depend on the implementation of the Peers 120. For example, the transmitter circuitry 203 and the receiver circuitry 204 can be implemented as an appropriate wireless modem, or as conventional transmitting and receiving components of two-way wireless communication devices. In the event that the transmitter circuitry 203 and the receiver circuitry 204 are implemented as a wireless modem, the modem can be internal to the Peers 120 or insertable into the Peers 120 (e.g., embodied in a wireless radio frequency (RF) modem implemented on a Personal Computer Memory Card International Association (PCMCIA) card). For a wireless communication device, the transmitter circuitry 203 and the receiver circuitry 204 can be implemented as part of the wireless device hardware and software architecture in accordance with known techniques. Most, if not all, of the functions of the transmitter circuitry 203 and/or the receiver circuitry 204 can be implemented in a processor, such as the processor 201. However, the processor 201, the transmitter circuitry 203, and the receiver circuitry 204 have been artificially partitioned herein to facilitate a better understanding.
The antenna 205 comprises any known or developed structure for radiating and receiving electromagnetic energy in the frequency range containing the wireless carrier frequencies.
The memory 206 includes a Subscriber Steward (SS) 208 and a Talkgroup Steward (TS) 210. In accordance with some embodiments, the Peer 120 can have more than one Subscriber Steward 208 or Talkgroup Steward 210 resident on it. The Subscriber Steward 208 is an entity within the Peer 120 that keeps track of all the subscribers 130 that are assigned to the Subscriber Steward 208. In other words, the Subscriber Steward 208 regulates the state of each of the subscribers 130 that are assigned to the Subscriber Steward 208. In accordance with some embodiments, the Subscriber Steward 208 ensures registration of a subscriber 130 that is assigned to the Subscriber Steward 208 to at most one Peer 120 within the P2P WAN 100. As used herein, the registration of subscriber 130 to a Peer 120 requires that all media pertinent and available on the P2P WAN 100 be routed to Peer 120 so that the Peer120 can deliver the media to the subscriber 130. In accordance with some embodiments, the Subscriber Steward 208 further ensures affiliation of a subscriber 130 to at most one talkgroup. As used herein, the affiliation of a subscriber 130 to a talkgroup requires that all media pertinent to that talkgroup be routed to the subscriber 130. The Subscriber Steward 208 may also ensure that each of its subscribers is registered maximally to one communication slot.
The Subscriber Steward 208 maintains a Master Subscriber Topology Database 209 (also referred to as “masterSubTopology” table). The Master Subscriber Topology Database 209 is a database that includes information related to one or more of the subscribers 130 within the P2P WAN 100 that are assigned to the Subscriber Steward 208. The table masterSubTopology 209 contains state for many subscribers. Each row of the masterSubTopology table 209 contains state for a given subscriber. The structure and content of masterSubTopology 209 is described in
Each Subscriber 130 that is assigned to the Subscriber Steward 208 periodically sends inbound registration and affiliation messages over the air (OTA) to the Subscriber Steward 208 to establish and maintain its presence (registration) at a Peer 120 (e.g., base station 110). If the Subscriber Steward 208 does not receive registration/affiliation messages from its subscriber for a predefined time period, for example, at approximately twice a periodic rate, the Subscriber Steward 208 notifies a Talkgroup Steward (TS) 210 to inform that the subscriber should no longer be affiliated to the talkgroup controlled by the Talkgroup Steward 210, removes information related to a Peer 120 (Peer ID) to which the registration message was received from the Master Subscriber Topology Database 209 on the Subscriber Steward 208, removes the communication slot information to which the registration was received from the Master Subscriber Topology Database 209 on the Subscriber Steward 208, and notifies any other processes that need to be informed that the subscriber 130 is no longer registered.
In accordance with some embodiments, each subscriber 130 within the WAN 100 is assigned to one Subscriber Steward (SS) 208. More than one Subscriber Steward 208 can be resident on a Peer 120 (e.g. an SS 208 can be responsible for multiple subscribers 130). Although
The Talkgroup Steward 210 is an entity within the peer 120 that keeps track of all the subscribers who are members of a given talkgroup. As used herein, the term “talkgroup” identifies a predefined group of subscribers who can participate in a group communication using the talkgroup. Any subscriber on the talkgroup can initiate and participate in talkgroup calls, as long as they are affiliated to the talkgroup. Each talkgroup has one Talkgroup Steward 210. The Talkgroup Steward 210 regulates the state of each of the subscribers that are members of its talkgroup. The Talkgroup Steward 210 maintains a Master Talkgroup Topology Database 211 (also referred to as masterTgTopology(Tg)). The Master Talkgroup Topology Database 211 is a database that includes information related to one or more of the subscribers 130 within the WAN 100 that are affiliated to a corresponding talkgroup. Each Talkgroup Steward 210 maintains one such table. The structure and content of masterTgTopology(Tg) table 211 is described in relation to
According to some embodiments, when a Peer 120 receives media (e.g., audio) for a given talkgroup from a subscriber 130, the Talkgroup Steward 210 ensures that the Peer 120 routes that talkgroup media only to the other Peers 120 which has registered subscribers affiliated to the given talkgroup. In some embodiments, each talkgroup can have an additional Talkgroup Steward. In this case, the initial talkgroup Steward is referred to as a “Primary Role Provider (PRP),” and the additional Talkgroup Steward is referred to as a “Subsidiary Role Provider (SRP).” The SRP functions as a backup to the PRP, and maintains a backup Master Takgroup Topology Database (also referred to as “backupMasterTgTopology(Tg)”). The SRP periodically receives information from the PRP, and updates the backupMasterTgTopology(Tg) table. The SRP can promote itself to take the role of PRP in case of a failure in PRP.
Further,
As shown in
As shown in
In accordance with some embodiments, as shown in block 615, the Subscriber Steward 208 determines whether the information peerToWhichSubscriberRegistered contained in the received subscriberRegistrationAffiliationMsgToSS signal is different than the peerToWhichSubscriberRegistered information contained in the masterSubTopology(subscriberID). Further, at block 615, the Subscriber Steward determines whether the slotOnWhichAffiliationRxed information contained in the subscriberRegistrationAffiliationMsgToSS signal is different than the slotOnWhichAffiliationRxed information contained in the masterSubTopology(subscriberID). If it is determined that either the peerToWhichSubscriberRegistered field or slotOnWhichAffiliationRxed field in the masterSubTopology(subscriberID) is different than the corresponding fields in the subscriberRegistrationAffiliationMsgToSS signal received by the Subscriber Steward 208, then as shown in block 620, the Subscriber Steward 208 determines that a first type of state change “SignalTSStateChangeA” has occurred to the masterSubTopology table and sets SignalTSStateChangeA flag. Returning to block 615, if both the peerToWhichSubscriberRegistered and slotOnWhichAffiliationRxed fields in the masterSubTopology(subscriberID) are same as the corresponding fields in the subscriberRegistrationAffiliationMsgToSS signal received by the Subscriber Steward 208, then the Subscriber Steward 208 determines that no state change has occurred upon receiving the subscriberRegistrationAffiliationMsgToSS signal and clears the SignalTSStateChangeA flag at block 625. Next, at block 630, the Subscriber Steward 208 determines whether TGToWhichSubscriberAffiliated field in the masterSubTopology(subscriberID) is different than the field TGToWhichSubscriberAffiliated in the subscriberRegistrationAffiliationMsgToSS signal received by the Subscriber Steward 208. If it is determined that the TGToWhichSubscriberAffiliated field in the masterSubTopology(subscriberID) is different than the field TGToWhichSubscriberAffiliated in the received subscriberRegistrationAffiliationMsgToSS signal, then the Subscriber Steward 208 detects that a second type of state change “SignalTSStateChangeB” has occurred in the masterSubTopology table and sets the SignalTSStateChangeB flag as shown in block 635. On the other hand, if the TGToWhichSubscriberAffiliated field in the masterSubTopology(subscriberID) is same as the field TGToWhichSubscriberAffiliated in the received subscriberRegistrationAffiliationMsgToSS signal, then the Subscriber Steward 208 clears the SignalTSStateChangeB flag at block 640.
Next, at block 645, the Subscriber Steward 208 determines if the tableModType in the signal subscriberRegistrationAffiliationMsgToSS is set to ‘add’ and either of the SignalTSStateChangeA flag or SignalTSStateChangeB flag is set. If the Subscriber Steward 208 determines that the tableModType in the signal subscriberRegistrationAffiliationMsgToSS is set to ‘add’ and at least one of the flags SignalTSStateChangeA or SignalTSStateChangeB is set, then at block 650, the Subscriber Steward 208 sends a subscriberAffiliationMsgToTS(add) (also referred to as subscriber affiliation message) to the TS(Tg) 210 named in the TGToWhichSubscriberAffiliated field of the subscriberRegistrationAffiliationMsgToSS signal received by the SS. In other words, the SS 208 sends a signal subscriberAffiliationMsgToTS(add) to the TS 210 when the tableModType was set to ‘add’ and either the state change SignalTSStateChangeA or the state change SignalTSStateChangeB has been detected. The fields in the subscriberAffiliationMsgToTS(add) are set to equivalent values in the subscriberRegistrationAffiliationMsgToSS as described in TABLE 1:
Returning to block 645, when the Subscriber Steward 208 determines that both the flags SignalTSStateChangeA and SignalTSStateChangeB are not set, or the tableModType was not set to ‘add’ in the subscriberRegistrationAffiliationMsgToSS, or upon completion of the processing in block 650, the Subscriber Steward 208 proceeds to block 655 to determine if either the signal subscriberRegistrationAffiliationMsgToSS is set to ‘add’ and the flag SignalTSStateChangeB is set, or the signal subscriberRegistrationAffiliationMsgToSS is set to ‘delete’ and either the flag SignalTSStateChangeA or the flag SignalTSStateChangeB is set. When the Subscriber Steward 208 determines that either the subscriberRegistrationAffiliationMsgToSS is set to ‘add’ and if SignalTSStateChangeB flag is set, or subscriberRegistrationAffiliationMsgToSS is set to ‘delete’ and if either SignalTSStateChangeA flag or SignalTSStateChangeB flag is set, then the Subscriber Steward 208 proceeds to block 660 to send a subscriberAffiliationMsgToTS(delete) to the TS(Tg) 210 named in the TGToWhichSubscriberAffiliated field of the masterSubTopology(subscriberID), for example, the signal is sent to the TS 210 logged in the masterSubTopology table 209 before the signal subscriberRegistrationAffiliationMsgToSS was received. In one embodiment, the subscriberAffiliationMsgToTS(delete) is sent to a Talkgroup Steward 210 controlling a talkgroup to indicate that a subscriber has de-affiliated from the talkgroup. The fields in the subscriberAffiliationMsgToTS(delete) are set to equivalent values in the row masterSubTopology(subscriberID) as illustrated in TABLE 2 and sent to TS(TGToWhichSubscriberAffiliated) 210.
Next, at block 665, the SS 208 determines if the tableModType in the signal subscriberRegistrationAffiliationMsgToSS is set to ‘add’. If the Subscriber Steward 208 determines that the tableModType in the signal subscriberRegistrationAffiliationMsgToSS is set to ‘add’, then the Subscriber Steward 208 proceeds to block 670 to update (set equal) the masterSubTopology(subscriberID) fields with the fields in the received subscriberRegistrationAffiliationMsgToSS signal. Otherwise, if the tableModType is set to ‘delete’ then, at block 675, the subscriberID row of the masterSubTopology table is filled with ‘not applicable’ (N/A) (except for the subscriberID field itself). Further, in accordance with some embodiments, when the SS 208 receives an subscriberRegistrationAffiliationMsgToSS(add), the SS 208 also sets (or resets if the row was already populated) the registrationExpirationTime to the internal time of reception of the subscriberRegistrationAffiliationMsgToSS plus subscriberRegistrationShelflife (as shown at block 680), where the subscriberRegistrationShelflife refers to the maximum time allowed before the row is deleted unless a refresh subscriberRegistrationAffiliationMsgToSS is received from the Peer 120 logged in the peerToWhichSubscriberRegistered field of the masterSubTopology(subscriberID). For example, the maximum time to go without a refresh can be set to twice the subscriberRegistrationAffiliationPeriod (the frequency at which registrations/affiliations come from the subscriber to the station). For example, when the subscriberRegistrationAffiliationPeriod is equal to fifteen (15) minutes, a refresh message needs to be received within thirty (30) minutes. In this case, the subscriberRegistrationShelflife is equal to thirty (30) minutes. In case, if the refresh message is not received within thirty (30) minutes, the subscriber's row in the masterSubTopology(subscriberID) may be set to N/A.
In accordance with some embodiments, when the registrationExpirationTime for any subscriberID expires, a signal subscriberAffiliationMsgToTS(delete) is generated. The signal subscriberAffiliationMsgToTS(delete) is sent to the Peer 120 whose peerID=TG field of the subscriberAffiliationMsgToTS(delete). Further, the subscriberID row of the masterSubTopology table is filled with ‘N/A’ (except for the subscriberID field itself).
In accordance with some embodiments, the Subscriber Steward 208 informs all other base stations 110 that it is the Steward for a particular subscriber 130. The Subscriber Steward 208 is only required to do this once as new base station 110 joins the P2P WAN 100. Therefore, if a private call is initiated, from a subscriber on some Peer, for example PeerX, only one message is communicated over the P2P WAN 100 to the subscriber's 130 specific Subscriber Steward 208 to find where a destination subscriber 130 is registered. In turn, the Subscriber Steward 208 responds with a message that indicate to which specific base station the subscriber 130 is registered. Now, PeerX knows to which one specific Peer to route the media. This is a scalable way with minimal messaging to locate mobile subscribers which can register at various base stations throughout the P2P WAN 100.
Next at block 710, the Talkgroup Steward 210 determines whether the received subscriberAffiliationMsgToTS includes a tableModType set to ‘add’. When the received subscriberAffiliationMsgToTS includes a tableModType set to ‘add’, the TS 210 determines whether a row for subscriberID is already represented in the masterTgTopology(Tg) 211 as shown in block 715. If it is determined that the subscriberID isn't already represented in the masterTgTopology(Tg) 211, then at block 720, the TS 210 adds a row for that subscriberID in masterTgTopology(Tg) 211. On the other hand, if the subscriberID is already represented in the masterTgTopology(Tg) 211, then at block 725, the TS 210 updates the row for that subscriberID in masterTgTopology(Tg) 211 with the information contained in the received subscriberAffiliationMsgToTS signal.
Returning to block 710, when the received subscriberAffiliationMsgToTS includes a tableModType set to ‘delete’, the TS 210 assumes that the subscriberID is already represented in the masterTgTopology(Tg) 211 and deletes that row from the masterTgTopology(Tg) 211 for that subscriberID. In one example, the subscriber affiliation message subscriberAffiliationMsgToTS(delete) received by a Talkgroup Steward 210 controlling a talkgroup indicates that a subscriber has de-affiliated from the talkgroup.
In one embodiment, there is at most, one row in the masterTgTopology(Tg) 211 per subscriberID. In this embodiment, the TS 210 adds a row in the masterTgTopology(Tg) 211 for a given subscriber only if the TS 210 receives a subscriberAffiliationMsgToTS for the given subscriber and the tableModType is set to ‘add’ and the subscriberID didn't previously exist in the masterTgTopology(Tg) 211. If a row previously existed for a given subscriber, then the row is updated based on the previously received subscriberAffiliationMsgToTS signal pertaining to that subscriber. Further, regardless if a row for the subscriberID preexisted or not, the TS 210 also sets (or reset if the row already existed) the affiliationExpirationTime to the internal time of reception of the subscriberAffiliationMsgToTS plus subscriberAffiliationShelflife, where subscriberAffiliationShelflife refers to the maximum time allowed before a “TG Topology Delete Event” is triggered unless a refresh subscriberAffiliationMsgToTS is received from the SS 208. The “TG Topology Delete Event” causes the execution of the Talkgroup Steward 210 to start at the process which starts at block 740 where the subscriberID in block 740 is the subscriberID for the row whose affiliationExpirationTime has expired. For example, the maximum time to go without a refresh is set to twice the subscriberRegistrationAffiliationPeriod (the frequency at which registrations/affiliations come from the subscriber to the station). In one example, when the subscriberRegistrationAffiliationPeriod is equal to fifteen (15) minutes, a refresh signal needs to be received within thirty (30) minutes. In this case, the subscriberAffiliationShelflife is equal to thirty (30) minutes. In case, if the refresh message is not received within thirty (30) minutes, the “TG Topology Delete Event” at block 740 is triggered.
After adding a new row for that subscriberID in masterTgTopology(Tg) 211 as shown in block 720 or updating the corresponding row for that subscriberID in masterTgTopology(Tg) 211 as shown in block 725, the TS 210 proceeds to block 730, where the TS 210 determines whether the field peerToWhichSubscriberRegistered in the subscriberAffiliationMsgToTS signal is a peerID which doesn't currently exist in the masterTgTopology(Tg) 211. If it is determined that the peerID (call this peerID Peer2) doesn't currently exist in the masterTgTopology(Tg) 211, then at block 735, the TS 210 sends one talkgroup topology (TgTopology(Tg) to each Peer 120 named in the peerToWhichSubscriberRegistered column of the masterTgTopology(Tg) 211 (including Peer2). In this case, the TgTopology(Tg) contains peerID Peer2.
Referring to
For example, when the TS 210 (Peer4120-4) receives a subscriberAffiliationMsgToTS signal including subscriberID S25 130-2, Peer2120-2 to which the subscriber S25 130-2 is registered, a slot value of two (2) on which the Peer2120-2 received affiliation message from the subscriber S25 130-2, and an affiliation expiration time of 12:35:24 at which the affiliation will expire for the subscriber S25 130-2, the TS 210 (Peer4120-4) determines that Peer 2120-2 doesn't currently exist in the masterTgTopology(Tg) table 211, and therefore generates a TgTopology(TgA) table 800 including a new row for Peer 2120-2 and the corresponding slot information. The generated TgTopology(TgA) table 800, for example, includes a row 830 including Peer1120-1 and a slot value of one (1), row 840 including Peer5120-5 and a slot value of one (1), row 850 including Peer3120-3 and a slot value of one (1), and a new row 860 including Peer2120-2 and a slot value of two (2). The generated TgTopology(TgA) is then sent to each peer 120 in the peerToWhichSubscriberRegistered column (Peer 1120-1, Peer5120-5, Peer3120-3) of the masterTgTopology(TgA) table 211 (including Peer2120-2).
Now returning to block 710 of
Next at block 755, the TS 210 deletes the row in the masterTgTopology(Tg) 211 for the particular subscriberID in the subscriberAffiliationMsgToTS (assuming a row in the masterTgTopology(Tg) already exists for the particular subscriberID). In accordance with some embodiments, this “deletion” event is not only triggered by the signal subscriberAffiliationMsgToTS with the tableModType set to ‘delete’, but also if the affiliationExpirationTime expires without a refresh to keep the row alive in the masterTgTopology(Tg) table 211.
For example, referring to
When the Subscriber Steward 208 residing within Peer5120-5 receives the signal 1005, the Subscriber Steward 208 residing within Peer5120-5 sends a subscriberAffiliationMsgToTS(add) signal 1015 to the Talkgroup Steward 210 controlling a talkgroup TgA with which the subscriber S11 130-1 is affiliated. In this example, the Talkgroup Steward controlling the talkgroup TgA resides within the Peer4120-4. After sending the 1015 signal, the Peer5120-5 initiates a timer “subscriberAffiliationMsgToTSTimer( )” 1020. The timer 1020 specifies a predefined time period within which the Peer5120-5 expects a response to the signal 1015. If the predefined time period lapses, the Peer5120-5 again initiates sending the signal 1015 to the Talkgroup Steward 210 residing within Peer4120-4. When the Talkgroup Steward 210 residing within Peer4120-4 receives the subscriberAffiliationMsgToTS(add) signal 1015, the Peer4120-4 sends an acknowledgment subscriberAffliationMsgToTSAck( ) signal 1025 to the Subscriber Steward 208 residing within Peer5120-5. After receiving the acknowledgment signal 1025 from the Talkgroup Steward 210 residing within Peer4120-4, the Subscriber Steward 208 residing within Peer5120-5 cancels the initiated timer 1020 by issuing “subscriberAffiliationMsgToTSTimerCancel( )” 1030.
The Subscriber Steward 208 then updates its masterSubTopology table 209 shown in
When the Subscriber Steward 208 residing within Peer5120-5 receives the subscriberRegistrationAffiliationMsgToSS signal 1205, the Subscriber Steward 208 residing within Peer5120-5 generates a signal subscriberAffiliationMsgToTS(add) 1215 and sends the generated signal 1215 to Talkgroup Steward 210 residing within Peer2120-2 that controls the talkgroup TgB. The subscriberAffiliationMsgToTS signal 1215 includes information such as subscriberID=S11, peerToWhichSubscriberRegistered=Peer1, slotOnWhichAffiliationRxed=1, TG=TgB, and tableModType=add. The Peer5120-5 then initiates a timer “subscriberAffiliationMsgToTSTimer( )” 1220. The timer 1220 specifies a predefined time period within which the Peer5120-5 expects a response to the signal 1215. If the predefined time period lapses, the Peer5120-5 again sends the signal 1215 to the Talkgroup Steward 210 residing within Peer2120-2 of TgB. The Peer2120-2 then sends a subscriberAffiliationToTSAck( ) signal 1225 to the Subscriber Steward 208 residing within Peer5120-5. Upon receiving this signal 1225, the Peer5120-5 cancels the timer 1220 by issuing “subscriberAffiliationMsgToTSTimerCancel( )” 1230.
A signal subscriberAffiliationMsgToTS(delete) 1235 is also generated and sent to Talkgroup Steward 210 residing within Peer4120-4 that controls the talkgroup TgA. The signal subscriberAffiliationMsgToTS 1235 includes information such as subscriberID=S11, peerToWhichSubscriberRegistered=Peer1, slotOnWhichAffiliationRxed=1, TG=TgA, and tableModType=delete. The Peer5120-5 then initiates a timer “subscriberAffiliationMsgToTSTimer( )” 1240 which defines a time period within which the Peer5120-5 expects an acknowledgment from Peer4120-4. Further, the masterSubTopology table 209 (maintained by the Subscriber Steward 208 residing within Peer5120-5) shown in
When the Subscriber Steward 208 residing within Peer5120-5 receives the acknowledgment from the Talkgroup Steward 210 residing within Peer2120-2 of TgB, the Subscriber Steward 208 residing within Peer5120-5 generates a backup of masterSubTopology 209 for subscriber S11 130-1 to reflect the change of affiliation of TgA to TgB. In accordance with some embodiments, the new masterSubTopology table contains only one altered row corresponding to the change of affiliation for subscriber S11 130-1. A signal deltaMasterSubTopology(backupindex) 1255 including only the altered row of the masterSubTopology which has the change of affiliation for subscriber S11 130-1 is sent to the Subscriber Steward 208 residing within Peer3120-3 which acts as a secondary role provider (SRP). The variable backupindex is a large integer (e.g. 48 bits or more) that represents the “nth” alteration to the masterSubTopology table. Upon receiving the deltaMasterSubTopology(backupindex), the SRP updates its own copy of the masterSubTopology, which is termed as the backupMasterSubTopology table, to match Peer5's copy of the masterSubTopology. Further, the Peer5120-5 initiates a timer “deltaMasterSubTopologyTimer( )” 1260 which defines a time period within which the Peer5120-5 expects an acknowledgment from Peer3130-3. The Peer3120-3 sends the acknowledgement after updating the backupMasterSubTopology table to match the Subscriber Steward Peer5's masterSubTopology table. When the Peer5120-5 receives the acknowledgment deltaMasterSubTopologyTimerAck(backupindex) 1265, the Peer5120-5 cancels the timer 1260 by issuing a signal “deltaMasterSubTopologyTimerCancel( )” 1270. Finally, the Peer5120-5 sends a subscriberRegistrationAffiliationMsgToSSAck( ) signal 1275 to Peer1120-1 with which the subscriber S11 is registered. The Peer1120-1 then cancels the timer 1210 by issuing a signal “subscriberRegistrationAffiliationMsgToSSTimerCancel( )” 1280.
When the Subscriber Steward 208 residing within Peer5120-5 receives the subscriberRegistrationAffiliationMsgToSS(delete) signal 1405, the Subscriber Steward 208 generates a signal subscriberAffiliationMsgToTS(delete) 1415 and sends the generated signal 1415 to Talkgroup Steward 210 residing within Peer2120-2 of TgB. The subscriberAffiliationMsgToTS(delete) signal 1415 includes information such as subscriberID=S11, peerToWhichSubscriberRegistered=Peer1, slotOnWhichAffiliationRxed=1, TG=TgB, and tableModType=delete. The Peer5120-5 then initiates a timer “subscriberAffiliationMsgToTSTimer( )” 1420. The timer 1420 specifies a predefined time period within which the Peer5120-5 expects a response to the signal 1415. If the predefined time period lapses, the Peer5120-5 again sends the signal 1415 to the Talkgroup Steward 210 residing within Peer2120-2 of TgB. The Peer2120-2, after processing the subscriberAffiliationMsgToTS(delete) signal 1415 sends a subscriberAffiliationMsgToTSAck( ) signal 1425 to the Subscriber Steward 208 residing within Peer5120-5. Upon receiving the signal 1425, the Peer5120-5 cancels the timer 1420 by issuing a signal “subscriberAffiliationMsgToTSTimerCancel( )” 1430. Further, the Subscriber Steward 208 residing within Peer5120-5 updates its masterSubTopology 209 shown in
The Subscriber Steward 208 then sends a deltaMasterSubTopology(backupindex) signal 1435 to another Subscriber Steward acting as a secondary role provider (SRP) which updates its local copy of the masterSubTopology table, which is termed as backupMasterSubTopology table The deltaMasterSubTopology(backupindex) signal 1435 contains only the updated row of the masterSubTopology table which concerns subscriber S11. The variable backupindex is a large integer (e.g. 48 bits or more) that represents the “nth” alteration to the masterSubTopology table. In this example, the backup Subscriber Steward resides within the Peer3120-3. Subsequently, the Subscriber Steward 208 residing within Peer5120-5 initiates a timer “deltaMasterSubTopologyTimer( )” 1440 which defines a time period within which the Subscriber Steward 208 expects an acknowledgment from the backup Subscriber Steward residing within Peer3120-3. The backup Subscriber Steward residing within Peer3130-3, after updating the backupMasterSubTopology table to match the masterSubTopology table maintained by the Subscriber Steward 208 residing at Peer5120-5, sends an acknowledgment deltaMasterSubTopologyAck(backupindex) 1445 to the Subscriber Steward 208 residing within Peer5120-5. Upon receiving the acknowledgment deltaMasterSubTopologyAck(backupindex) 1445, the Subscriber Steward 208 residing at Peer5120-5 cancels the timer by issuing a signal “deltaMasterSubTopologyTimerCancel( )” 1450, and sends a subscriberRegistrationAffiliationMsgToSSAck( ) signal 1455 to the Peer1120-1. The Peer1120-1 then cancels the timer 1410 by issuing a signal “subscriberRegistrationAffiliationMsgToSSTimerCancel( )” 1460.
In accordance with some embodiments, the deletion event depicted in
The Talkgroup Steward 210 residing within Peer4120-4 then sends a deltaMasterTgTopology(backupindex) signal 1670 to another Talkgroup Steward acting as a secondary role provider (SRP) which then updates its local backupMasterTgTopology database based on the information received in the deltaMasterTgTopology(backupindex) signal 1670. In accordance with some embodiments, the signal deltaMasterTgTopology(backupindex) 1670 contains only one row of the masterTgTopology table maintained by the TS(TgA) 210 residing at Peer4120-4. As used herein, it is to be understood that a signal defined as “deltaMasterTgTopology(backupindex)”, employed in embodiments of the disclosure, implies a signal which carries a difference in information between an updated version of the masterTgTopology table maintained by a Talkgroup Steward 210 acting as an PRP and a version of the masterTgTopology table maintained by another Talkgroup Steward acting as an SRP. In this example, the difference corresponds to the row containing the first appearance of Peer1 in the masterTgTopology table maintained by TS(TgA) 210 residing at Peer4120-4. In accordance with some embodiments, the backupindex is a large integer (e.g. 48 bits or more) which corresponds to the “nth” version of the masterTgTopology table maintained in TS(TgA) 210 residing at Peer4120-4. In this example, the backup Talkgroup Steward resides within the Peer5120-5. Subsequently, the Talkgroup Steward 210 residing within Peer4120-4 initiates a timer “deltaMasterTgTopologyTimer( )” 1675 which defines a time period within which the Subscriber Steward 208 expects an acknowledgment from the backup Talkgroup Steward residing within Peer2120-2. The backup Talkgroup Steward residing within Peer5120-5, upon updating its own resident copy of the backupMasterTgTopology table to match the masterTgTopology maintained by the TS(TgA) 210, sends an acknowledgment deltaMasterTgTopologyAck(backupindex) 1680 to the Talkgroup Steward 210 residing within Peer4120-4. Upon receiving the acknowledgment deltaMasterTgTopologyAck(backupindex) 1680, the Talkgroup Steward 210 residing within Peer4120-4 cancels the timer 1675 by issuing a signal “deltaMasterTgTopologyTimerCancel( )” 1685, and sends an acknowledgment subscriberAffiliationMsgAck( ) signal 1690 to the Subscriber Steward 208 residing within Peer5120-5.
The Talkgroup Steward 210 residing within Peer4120-4 then sends a deltaMasterTgTopology(backupindex) signal 1770 to another Talkgroup Steward acting as a secondary role provider (SRP) which updates its local backupMasterTgTopology database based on the information received in the deltaMasterTgTopology(backupindex) signal 1770. In accordance with some embodiments, the signal deltaMasterTgTopology(backupindex) 1770 contains only one row of the masterTgTopology table maintained by the TS(TgA) 210 residing at Peer4120-4. As used herein, it is to be understood that a signal defined as “deltaMasterTgTopology(backupindex)”, employed in embodiments of the disclosure, implies a signal which carries a difference in information between an updated version of the masterTgTopology table maintained by a Talkgroup Steward 210 acting as an PRP and a version of the masterTgTopology table maintained by another Talkgroup Steward acting as an SRP. In this example, the difference corresponds to the deletion of the occurrence of Peer1120-1 in the masterTgTopology table maintained by TS(TgA) 210 residing at Peer4120-4 due to change of talkgroup affiliation of the subscriber S11 130-1 associated with the Peer1120-1. In accordance with some embodiments, the backupindex is a large integer (e.g. 48 bits or more) which corresponds to the “nth” version of the masterTgTopology table maintained in TS(TgA) 210 residing at Peer4120-4. In this example, the backup Talkgroup Steward resides within the Peer5120-5. Subsequently, the Talkgroup Steward 210 residing within Peer4120-4 initiates a timer “deltaMasterTgTopologyTimer( )” 1775 which defines a time period within which the Talkgroup Steward 210 expects an acknowledgment from the backup Talkgroup Steward residing within Peer5120-5. The backup Talkgroup Steward residing within Peer5120-5 sends an acknowledgment deltaMasterTgTopologyAck(backupindex) 1780 to the Talkgroup Steward 210 residing within Peer4120-4. Upon receiving the acknowledgment deltaMasterTgTopologyAck(backupindex) 1780, the Talkgroup Steward 210 residing within Peer4120-4 cancels the timer 1775 by issuing a “deltaMasterTgTopologyTimerCancel( )” 1585, and sends an acknowledgment subscriberAffiliationMsgAck( ) signal 1790 to the Subscriber Steward 208 residing within Peer5120-5.
Consider that there is a network of peers of which several peers 120 (Peer1120-1, Peer2120-2, Peer3120-3, and Peer4120-4) have at least one subscriber 130 affiliated to the respective base station 110 on talkgroup Tg. Consider that the Talkgroup Steward 210 (TS) for Tg is on Peer5120-5 that at least Peer1120-1 has received a TgTopology(Tg) table from the TS 210. Considering that all the links are viable, the peers Peer1120-1, Peer2120-1, Peer3120-3, and Peer4120-4 need to be listed in the TgTopology table. Further consider that Peer1 has maintained at least one active port with Peer2120-1, Peer3120-3, and Peer4120-4 as they are listed on the TgTopology(Tg) table.
When Peer1120-1 receives a fast group communication media, for example, a fast start group call audio from a subscriber 130 (for example, a mobile radio) over the air whose destination is talkgroup Tg, Peer1120-1 checks to see if the links to Peer2120-2, Peer3120-3, and Peer4120-4 listed in the TgTopology table are still active. In one example, Peers 120 can exchange messages periodically to check if other Peers 120 are still active and accordingly update the TgTopology table to reflect the changes. The Peer1 then dereferences each active peerID (Peer2, Peer3, and Peer4) listed in the TgTopology table to a destination Internet Protocol (IP) address and User Datagram Protocol (UDP) port, and further packet duplicates the media (audio) for peers Peer2120-2, Peer3120-3 and Peer4120-4. Next, the Peer1120-1 unicasts the duplicated media packet to Peer2120-2, Peer3120-3, and Peer4120-4 assuming that the link to each peer is still active. When Peer2120-2, Peer3120-3, and Peer4120-4 receives the unicasted media packet, each peer extracts information related to the destination talkgroup and audio from the IP/UDP packet, applies appropriate floor control to the audio packet, and further formats the talkgroup ID and audio into the appropriate layer 2 (OSI link layer) signaling required for the specific outbound OTA protocol. Each of Peer2120-2, Peer3120-3, and Peer4120-4 then transmits OTA the entire signal (talkgroup id and audio) to the designated subscribers 130 who are affiliated to talkgroup Tg.
Therefore, a packet of media (audio) is sent unicast directly to each Peer on the TgTopology table to which Peer1120-1 still has an active connection (the audio is not sent to TS=Peer5120-5). The destinations have been pre-established before a group call to talkgroup Tg has arrived OTA from a subscriber 130 to Peer1120-1. Because only the necessary destination stations (Peer2120-2, Peer3120-3, and Peer4120-4) in the P2P WAN 100 receive the media (audio) from Peer1120-1 and transmit media (audio) OTA, both RF channel and wired network bandwidth resources for the entire P2P WAN 100 are conserved. Note, upon receiving audio from a subscriber 130, Peer1120-1 need only packet duplicate media (audio) and send the media (audio) without waiting for acknowledgments from the downstream peers or a centralized controller, thereby enabling a group communication (call) faster with low access/throughput delay while maximizing the radio frequency channel capacity of the P2P WAN 100.
In accordance with embodiments described above, the implementation of the disclosure produces a fault tolerant system by having the processes located on more than one Peer 120, such that if one Talkgroup Steward 210 faults, a group call for the particular Talkgroup can still remain operational without compromise. Further, the implementation of the disclosure reduces bandwidth consumption by having control signaling for a given talkgroup forwarded to only one process that handles that talkgroup for the entire WAN instead of flooding the talkgroup affiliation information to all of the Peers 120 unnecessarily. Further, the OTA channel resource consumption is kept minimal by listing only the Peers 120 which have at least one subscriber 130 affiliated to the talkgroup Tg in the masterTgTopology table 211. Further, routing a derived TgTopology table to all such Peers enables only the necessary Peers to transmit audio for a specified talkgroup, thereby conserving system resources. Further, the Talkgroup Steward 210 entity which establishes paths between all of the Peers 120 for a given talkgroup is located in one place, thereby making the state maintenance of the subscribers and the talkgroups significantly simpler. Finally, the implementations of the disclosure enables fast group call setup by pre-establishing the routes, such that, upon receiving an OTA call, the Peer 120 simply packet duplicates the audio and sends according to the pre-established routes to each destination station, thereby eliminating the delay incurred by routing control between station endpoints or a central controller.
In the foregoing specification, specific embodiments have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present teachings. The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued.
Moreover in this document, relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” “has”, “having,” “includes”, “including,” “contains”, “containing” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by “comprises . . . a”, “has . . . a”, “includes . . . a”, “contains . . . a” does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, contains the element. The terms “a” and “an” are defined as one or more unless explicitly stated otherwise herein. The terms “substantially”, “essentially”, “approximately”, “about” or any other version thereof, are defined as being close to as understood by one of ordinary skill in the art, and in one non-limiting embodiment the term is defined to be within 10%, in another embodiment within 5%, in another embodiment within 1% and in another embodiment within 0.5%. The term “coupled” as used herein is defined as connected, although not necessarily directly and not necessarily mechanically. A device or structure that is “configured” in a certain way is configured in at least that way, but may also be configured in ways that are not listed.
It will be appreciated that some embodiments may be comprised of one or more generic or specialized processors (or “processing devices”) such as microprocessors, digital signal processors, customized processors and field programmable gate arrays (FPGAs) and unique stored program instructions (including both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the method and/or apparatus described herein. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used.
Moreover, an embodiment can be implemented as a computer-readable storage medium having computer readable code stored thereon for programming a computer (e.g., comprising a processor) to perform a method as described and claimed herein. Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory) and a Flash memory. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.
The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.
