Managing acknowledgment transmissions from multicast group members of a multicast group within a wireless communications network
51 claims: 7 independent, 44 dependent
- 1無線通信ネットワークにおいて、マルチキャスト・メッセージに応答する方法であって、 複数のアクセス端末を含むマルチキャスト・グループに対して指定された対話型マルチキャスト・メッセージを受信することであって、前記対話型マルチキャスト・メッセージが前記複数のアクセス端末からの応答を要求している、受信することと、 前記マルチキャスト・グループに対してアクセス制御メッセージ(ACM)を受信することであって、前記対話型マルチキャスト・メッセージに応答すべく、前記アクセス制御メッセージ(ACM)が前記複数のアクセス端末に対するメッセージ固有のフィードバック命令を示唆している、受信することと、 前記アクセス制御メッセージによって示された前記複数のアクセス端末に対する前記メッセージ固有のフィードバック命令に基づいて、前記対話型マルチキャスト・メッセージに応答することと、 この応答後に、前記アクセス制御メッセージに含まれる前記メッセージ固有のフィードバック命令から前セットのフィードバック命令に移行することと、 を備える方法。
- 2前記メッセージ固有のフィードバック命令が、(i)1またはそれ以上の複数アクセス端末の順序及び/又は(ii)前記多数のアクセス端子の少なくとも1つが、前記対話型マルチキャスト・メッセージに応答するための確率的応答プロトコルを決定することができる情報の少なくとも1つを含む請求項1に記載の方法。
- 3所与のアクセス端末に対する前記対話型マルチキャスト・メッセージへの前記応答を、前記順序内での前記所与のアクセス端末の位置に基づいて遅延させることをさらに備える、請求項2に記載の方法。
- 4所与のアクセス端末が前記順序内に存在しない場合、前記所与のアクセス端末に対する前記対話型マルチキャスト・メッセージへの前記応答を前記複数のアクセス端末の数に基づいて遅延させることをさらに備える、請求項2に記載の方法。
- 5後続のタイムスロットにおいて、前記確率的応答プロトコルに基づいて前記対話型マルチキャスト・メッセージに応答していることをさらに備える、請求項4に記載の方法。
- 6前記確率的応答プロトコルがAPersistence機能であり、前記情報が、前記APersistence機能の持続確率であるAPersistence値、または前記応答を遅延させるタイムスロットの数を前記多数のアクセス端子中の各アクセス端子が確率的に決定することができる少なくとも1つの数のいずれかを含む、請求項2に記載の方法。
- 7前記少なくとも1つの数がNを含み、Nが、あるサービング領域における前記対話型マルチキャスト・メッセージの送信先である前記複数のアクセス端末の数である、請求項6に記載の方法。
- 8前記APersistence機能の前記持続確率が1/Nである、請求項7に記載の方法。
- 9前記確率的に決定される遅延が、0から(N-1)までの範囲でランダムに決定される、請求項7に記載の方法。
- 10前記あるサービング領域における前記対話型マルチキャスト・メッセージの送信先である前記複数のアクセス端末の数がNであり、前記あるサービング領域内の前記複数のアクセス端末の数がXであり、前記少なくとも1つの数がNとXの両方を含む、請求項7に記載の方法。
- 11前記APersistence機能の前記持続確率が1/(N-X)である、請求項10に記載の方法。
- 12前記順序が、少なくとも1つの前記アクセス端末に関するある基準に基づいて決定される、請求項2に記載の方法。
- 13前記少なくとも1つの前記アクセス端末に関するある基準は、応答する可能性が高いと予想される所与のアクセス端末の可能性を含む、請求項12に記載の方法。
- 14前記可能性が、前記所与のアクセス端末が利用可能であるとする利用可能の報告(レポート)を介して最後に報告したときに基づいている、請求項13に記載の方法。
- 15前記所与のアクセス端末が、距離ベース登録(DBR)プロトコルに基づいて端末が利用可能である報告を送信する、請求項14に記載の方法。
- 16前記所与のアクセス端末が周期的に端末が利用可能である報告を送信する、請求項14に記載の方法。
- 17前記所与のアクセス端末が、基地局からの問合せに応答して端末が利用可能である報告を送信する、請求項14に記載の方法。
- 18前記利用可能性報告が、前記所与のアクセス端末に対して要求されるマルチキャスト・グループメンバーシップを示すマルチキャスト・グループ報告である、請求項14に記載の方法。
- 19前記マルチキャスト・グループ報告が、1xEV-DO規格によるBCMCSFlowRegistrationメッセージまたはStorageBLOBNotificationメッセージの1つ内で提供される、請求項18に記載の方法。
- 20前記利用可能性報告が、前記所与のアクセス端末に対して要求されるマルチキャスト・グループメンバーシップを示す位置更新報告である、請求項14に記載の方法。
- 21前記順序が、マルチキャストアクセス端末識別子(MATI)にアドレス指定された制御メッセージ内で提供され、複数のユニキャストアクセス端末識別子(UATI)を含み、前記UATIの各々が、前記順序中で示された前記アクセス端末の中の異なるアクセス端末にアドレス指定される、請求項2に記載の方法。
- 22UATIを有する各アクセス端末が応答している機会を最初に与えられた後、前記複数のアクセス端末の中の、前記制御メッセージ内で対応するUATIによって指定されないアクセス端末が、前記確率的応答プロトコルを介して応答しているようにスケジュールされる、請求項19に記載の方法。
- 23フィードバック命令の前記前セットが、AccessParametersメッセージによって示されるAPersistence機能に対応する、請求項1に記載の方法。
- 24前記受信したアクセス制御メッセージがダウンリンク制御チャネルを介して受信される、請求項1に記載の方法。
- 25前記受信したアクセス制御メッセージが前記マルチキャスト・グループのマルチキャスト・アクセス端末識別子(MATI)にアドレス指定される、請求項1に記載の方法。
- 26前記受信したアクセス制御メッセージがStorageBLOBAssignmentメッセージ内に含まれる、請求項1に記載の方法。
- 27無線通信ネットワークにおいて、マルチキャスト・メッセージへの応答をスケジュールする方法であって、 対話型マルチキャスト・メッセージに関連するアクセス制御メッセージを生成することであって、前記アクセス制御メッセージが、所与のマルチキャスト・グループに属する複数のアクセス端末に対するメッセージ固有のフィードバック命令を示唆し、前記メッセージ固有のフィードバック命令が、前記複数のアクセス端末が前記対話型マルチキャスト・メッセージに応答 し、この応答の後に、前記アクセス制御メッセージに含まれる前記メッセージ固有のフィードバック命令から前セットのフィードバック命令に移行 する一時的な方法を指定している、生成することと、 前記アクセス制御メッセージを前記複数のアクセス端末に送信することと、 前記複数のアクセス端末に対話型マルチキャスト・メッセージを送信することであって、前記対話型マルチキャスト・メッセージが、前記複数のアクセス端末を含む前記所与のマルチキャスト・グループに対して指定されている、送信することと、 前記フィードバック命令に基づいて前記所与のマルチキャスト・グループから前記対話型マルチキャスト・メッセージに対する前記応答を受信することと、 から構成される方法。
- 28前記メッセージ固有のフィードバック命令が、前記アクセス制御メッセージに関連する前記対話型マルチキャスト・メッセージに応答しているために従うことを意図された、請求項27に記載の方法。
- 29前記メッセージ固有のフィードバック命令が、(i)1またはそれ以上の複数のアクセス端末の順序(ii)前記多数のアクセス端子の少なくとも1つが、前記対話型マルチキャスト・メッセージに応答しているための確率的応答プロトコルを決定することができる情報との少なくとも1つを含む請求項27に記載の方法。
- 30前記生成することがアプリケーション・サーバにおいて実行され、前記両送信するステップが無線アクセス・ネットワーク(RAN)において実行される、請求項27に記載の方法。
- 31両方の送信するステップが無線アクセス・ネットワーク(RAN)において実行される、請求項27に記載の方法。
- 32前記アクセス制御メッセージが前記対話型マルチキャスト・メッセージ内に含まれ、両方の送信するステップが同時に実行される、請求項27に記載の方法。
- 33前記アクセス制御メッセージがダウンリンク制御チャネルを介して送信される、請求項27に記載の方法。
- 34前記生成されたアクセス制御メッセージが前記マルチキャスト・グループのマルチキャスト・アクセス端末識別子(MATI)にアドレス指定される、請求項27に記載の方法。
- 35前記アクセス制御メッセージがStorageBLOBAssignmentメッセージ内で送信される、請求項27に記載の方法。
- 36複数のアクセス端末を含むマルチキャスト・グループに対して指定された対話型マルチキャスト・メッセージを受信するための手段であって、前記対話型マルチキャスト・メッセージが前記複数アクセス端末に応答を要求する、受信するための手段と、 前記マルチキャスト・グループに対するアクセス制御メッセージ(ACM)を受信するための手段であって、前記対話型マルチキャスト・メッセージに応答すべく、前記アクセス制御メッセージ(ACM)が前記複数のアクセス端末に対するメッセージ固有のフィードバック命令を示唆している、受信するための手段と、 前記アクセス制御メッセージによって示された、前記複数のアクセス端末に対する前記メッセージ固有のフィードバック命令に基づいて、前記対話型マルチキャスト・メッセジに応答しているための手段と、 前記応答手段が前記対話型マルチキャスト・メッセージに応答した後に、前記アクセス制御メッセージに含まれる前記メッセージ固有のフィードバック命令から前セットのフィードバック命令に移行するための手段と、 を備えるワイヤレス通信システム。
- 37前記メッセージ固有のフィードバック命令が、(i)1またはそれ以上の複数アクセス端末の順序及び/又は(ii)前記多数のアクセス端子の少なくとも1つが、前記対話型マルチキャスト・メッセージに応答しているための確率的応答プロトコルを決定することができる情報との少なくとも1つを含む、請求項36に記載のワイヤレス通信システム。
- 38前記受信したアクセス制御メッセージがダウンリンク制御チャネルを介して受信される、請求項36に記載のワイヤレス通信システム。
- 39前記受信したアクセス制御メッセージが前記マルチキャスト・グループのマルチキャスト・アクセス端末識別子(MATI)にアドレス指定される、請求項36に記載のワイヤレス通信システム。
- 40前記受信したアクセス制御メッセージがStorageBLOBAssignmentメッセージ内に含まれる、請求項36に記載のワイヤレス通信システム。
- 41アクセス制御メッセージを生成するための手段を備え、前記アクセス制御メッセージが、所与のマルチキャスト・グループに属する複数のアクセス端末に対するメッセージ固有のフィードバック命令を示唆し、前記メッセージ固有のフィードバック命令が、前記複数のアクセス端末が対話型マルチキャスト・メッセージに応答 し、この応答の後に、前記アクセス制御メッセージに含まれる前記メッセージ固有のフィードバック命令から前セットのフィードバック命令に移行 する一時的な方法を指定している生成するための手段と、 前記アクセス制御メッセージを前記複数のアクセス端末に送信するための手段と、 前記複数のアクセス端末に対話型マルチキャスト・メッセージを送信するための手段であって、前記対話型マルチキャスト・メッセージが、前記複数のアクセス端末を含む前記所与のマルチキャスト・グループに対して指定される、送信するための手段と、 前記フィードバック命令に基づいて前記所与のマルチキャスト・グループから前記対話型マルチキャスト・メッセージに対する前記応答を受信する手段と、 を具備するワイヤレス通信システム。
- 42前記メッセージ固有のフィードバック命令が、前記アクセス制御メッセージに関連する前記対話型マルチキャスト・メッセージに応答しているために従うことを意図された、請求項41に記載のワイヤレス通信システム。
- 43前記メッセージ固有のフィードバック命令が、(i)1またはそれ以上の複数アクセス端末の順序及び/又は(ii)前記多数のアクセス端子の少なくとも1つが、前記対話型マルチキャスト・メッセージに応答しているための確率的応答プロトコルを決定することができる情報との少なくとも1つを含む請求項41に記載のワイヤレス通信システム。
- 44前記生成されたアクセス制御メッセージが前記マルチキャスト・グループのマルチキャスト・アクセス端末識別子(MATI)にアドレス指定される、請求項41に記載のワイヤレス通信システム。
- 45前記アクセス制御メッセージがStorageBLOBAssignmentメッセージ内で送信される、請求項41に記載のワイヤレス通信システム。
- 46プログラムコードを記憶したコンピュータ可読記憶媒体であって、 複数のアクセス端末を含むマルチキャスト・グループに対して指定された対話型マルチキャスト・メッセージを受信するためのプログラムコードであって、前記対話型マルチキャスト・メッセージが前記複数のアクセス端末からの応答を要求している、受信するためのプログラムコードと、 前記マルチキャスト・グループに対するアクセス制御メッセージ(ACM)を受信するためのプログラムコードであって、前記対話型マルチキャスト・メッセージに応答すべく、前記アクセス制御メッセージが前記複数のアクセス端末に対するメッセージ固有のフィードバック命令を示唆している、受信するためのプログラムコードと、 前記アクセス制御メッセージによって示された前記複数のアクセス端末に対する前記メッセージ固有のフィードバック命令に基づいて、前記対話型マルチキャスト・メッセージに応答するためのプログラムコードと、 前記応答しているプログラムコードが前記対話型マルチキャスト・メッセージに応答した後に、前記アクセス制御メッセージに含まれる前記メッセージ固有のフィードバック命令から前セットのフィードバック命令に移行するためのプログラムコードと、 を備えるコンピュータ可読記憶媒体。
- 47前記メッセージ固有のフィードバック命令が、(i)1またはそれ以上の複数アクセス端末の順序及び/又は(ii)前記多数のアクセス端子の少なくとも1つが、前記対話型マルチキャスト・メッセージに応答しているための確率的応答プロトコルを決定することができる情報との少なくとも1つを含む請求項46に記載のコンピュータ可読記憶媒体。
- 48プログラムコードを記憶したコンピュータ可読記憶媒体であって、 アクセス制御メッセージを生成するためのプログラムコードを備え、前記アクセス制御メッセージが、所与のマルチキャスト・グループに属する複数のアクセス端末に対するメッセージ固有のフィードバック命令を示唆し、前記メッセージ固有のフィードバック命令が、前記複数のアクセス端末が対話型マルチキャスト・メッセージに応答 し、この応答の後に、前記アクセス制御メッセージに含まれる前記メッセージ固有のフィードバック命令から前セットのフィードバック命令に移行 する一時的な方法を指定している、生成するためのプログラムコードと、 前記アクセス制御メッセージを前記複数のアクセス端末に送信することと、 前記複数のアクセス端末に対話型マルチキャスト・メッセージを送信するプログラムコードであって、前記対話型マルチキャスト・メッセージが、前記複数のアクセス端末を含む前記所与のマルチキャスト・グループに対して指定されている、送信するプログラムコードと、 前記フィードバック命令に基づいて前記所与のマルチキャスト・グループから前記対話型マルチキャスト・メッセージに対する前記応答を受信するプログラムコードと、 を具備するコンピュータ可読記憶媒体。
- 49前記アクセス制御メッセージが、(i)1またはそれ以上の複数アクセス端末の順序及び/又は(ii)前記多数のアクセス端子の少なくとも1つが、前記対話型マルチキャスト・メッセージに応答しているための確率的応答プロトコルを決定することができる情報との少なくとも1つを含む請求項48に記載のコンピュータ可読記憶媒体。
- 50前記アクセス制御メッセージが前記マルチキャスト・グループのマルチキャスト・アクセス端末識別子(MATI)にアドレス指定される、請求項48に記載のコンピュータ可読記憶媒体。
- 51前記アクセス制御メッセージがStorageBLOBAssignmentメッセージ内で送信される、請求項48に記載のコンピュータ可読記憶媒体。
Independent claims51
91 paragraphs, as filed
Claiming priority under 35 USC 119 Each of these patent applications is transferred to the transferee of this application and is expressly incorporated herein by reference in the "METHODS OF RESPONDING TO AN INTERACTIVE MULTICAST MESSAGE WITHIN A WIRELESS COMMUNICATION SYSTEM" filed on September 24, 2007. Provisional application No. 60 / 974,796 entitled "METHODS OF MANAGING ACKNOWLEDGMENT TRANSMISSIONS FROM MULTICAST GROUP MEMBERS OF A MULTICAST GROUP WITHIN A WIRELESS COMMUNICATIONS NETWORK" Claim the priority of the issue.
The present invention relates to communication in a wireless communication system, and more particularly to a method of responding to an interactive multicast message within a wireless communication system.
Wireless communication systems include 1st generation analog wireless telephone services (1G), 2nd generation (2G) digital wireless telephone services (including intermediate 2.5G and 2.75G networks), and 3rd generation (3G) high-speed data / It has evolved through various generations, including Internet-enabled wireless services. Currently, there are many different types of wireless communication systems, including cellular systems and personal communications services (PCS) systems. Examples of known cellular systems are the Cellular Analog Advanced Mobile Phone System (AMPS), and Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), There are digital cellular systems based on the TDMA Wide Area Mobile Communication System (GSM) variant, and newer hybrid digital communication systems that use both TDMA and CDMA technologies.
A method for providing CDMA mobile communication is described in TIA / EIA / IS-95-A entitled "Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System" referred to herein as IS-95. , Standardized in the United States by the Telecommunications Industry Association / Electronic Industries Association. Composite AMPS & CDMA systems are described in TIA / EIA standard IS-98. Other communication systems are IMT-2000 / UM, or International Mobile Telecommunications System 2000 /, a standard that covers what is called wideband CDMA (WCDMA), CDMA2000 (eg CDMA2000 1xEV-DO standard), or TD-SCDMA. Universal Mobile Telecommunications Described in System.
In wireless communication systems, a mobile station, handset, or access terminal (AT) supports a communication link or service within a specific geographic area adjacent to or surrounding a base station (a fixed location base station). Receives signals from (also called cell sites or cells). Base stations are generally access networks, which are packet data networks that use standard Internet Engineering Task Force (IETF) -based protocols that support methods for distinguishing traffic based on quality of service (QoS) requirements. Gives an entry point to the AN) / Radio Access Network (RAN). Therefore, base stations typically interact with AT through wireless interfaces and with AN via Internet Protocol (IP) network data packets.
In wireless power transfer, push-to-talk (PTT) capabilities are widespread in the service sector and consumers. PTT can support "dispatch" voice services running on standard commercial wireless infrastructure such as CDMA, FDMA, TDMA, and GSM. In the dispatch model, communication between endpoints (ATs) takes place within a virtual group, where the voice of one "speaker" is sent to one or more "listeners". Will be done. A single instance of this type of communication is commonly referred to as a dispatch call, or simply a PTT call. A PTT call is a group instantiation that defines the characteristics of the call. A group is essentially defined by a member list and related information, such as a group name or group ID.
Traditionally, data packets within a wireless communication network have been configured to be sent to a single destination or access terminal. Sending data to a single destination is called "unicast". As mobile communications have increased, the ability to send given data to multiple access terminals at the same time has become more important. Therefore, a protocol was adopted to support simultaneous data transmission of the same packet or message to multiple destinations or target access terminals. "Broadcast" refers to the transmission of data packets to all destinations or access terminals (for example, those in a given cell, serviced by a given service provider), and "multicast" refers to the destination or Refers to the transmission of data packets to a given group of access terminals. In one example, a given group or "multicast group" of destinations is two of the possible destinations or access terminals (for example, those in a given cell, serviced by a given service provider). It can contain more than one and less than all. However, in at least some situations, the multicast group may have only one access terminal, similar to unicast, or, alternative, the multicast group, similar to broadcast (eg, given). It is possible to have all access terminals (such as in a cell).
Broadcast and / or multicast includes performing multiple consecutive unicast operations to accommodate multicast groups, assigning a unique broadcast / multicast channel (BCH) to handle multiple data transmissions simultaneously, and so on. It can be executed in the wireless communication system by the above method. "Push-To-Talk Group Call System Using CDMA 1x-EVDO Cellular," a traditional system that uses broadcast channels for push-to-talk communication, is incorporated herein by reference in its entirety. It is described in US Patent Application Publication No. 2007/0049314 dated March 1, 2007, entitled "Network". Broadcast channels can be used for push-to-talk calls using traditional signaling techniques, as described in Publication No. 2007/0049314. Although the use of broadcast channels can improve bandwidth requirements over traditional unicast techniques, traditional signaling on broadcast channels can still incur additional overhead and / or delays, resulting in system performance. May deteriorate.
The 3rd Generation Partnership Project 2 (3GPP2) defines the Broadcast Multicast Services (BCMCS) standard to support multicast communication in CDMA2000 networks. Therefore, version 1.0 C.S0054-A, a version of the 3GPP2 BMCCS standard dated February 14, 2006, entitled "CDMA2000 High Rate Broadcast-Multicast Packet Data Air Interface Specification," is a complete reference. Incorporated into the specification.
Embodiments of the present invention target wireless communication systems and provide a method of scheduling access terminal responses to interactive multicast messages. The Radio Access Network (RAN) generates an access control message (ACM), which provides feedback instructions for multiple access terminals (ATs) belonging to a given multicast group. ACM feedback instructions provide a temporary way for multiple access terminals to respond to interactive multicast messages. The target AT receives interactive multicast messages as well as ACM. The target AT or multicast group member responds to the interactive multicast message based on the feedback instructions for multiple access terminals indicated by the ACM.
Many more complete comprehensions of embodiments of the invention and its associated benefits are to be considered with reference to the detailed description below and with the accompanying drawings presented for illustration purposes only, not to limit the invention. It will be easier to obtain if better understood by.
<figref num="1">The figure which shows the wireless network architecture which supports the access terminal and access network by at least one embodiment of this invention.</figref><figref num="2">The figure which shows the carrier network by one Embodiment of this invention.</figref><figref num="3">The figure which shows the access terminal by at least one embodiment of this invention.</figref><figref num="4">Diagram showing a traditional multicast messaging process using the Broadcast Multicast Server (BCMCS) framework.</figref><figref num="5">The figure which shows the conventional cycle of a downlink control channel.</figref><figref num="6">The figure which shows the multicast messaging process by one Embodiment of this invention.</figref><figref num="7">The figure which shows the conventional access terminal response to an interactive multicast message.</figref><figref num="8">The figure which shows the interactive multicast messaging generation and transmission process by one Embodiment of this invention.</figref><figref num="9">The figure which shows the ACM generation process by one Embodiment of this invention.</figref><figref num="10">The figure which shows the interactive multicast messaging response process by one Embodiment of this invention.</figref><figref num="11">The figure which shows the multicast group member report and the position update process by one Embodiment of this invention.</figref>
The following description and related drawings for a particular embodiment of the invention disclose aspects of the invention. Alternative embodiments can be devised without departing from the scope of the invention. Moreover, the well-known elements of the invention will not be described or omitted in detail so as not to obscure the important details of the invention.
The terms "exemplary" and / or "example" are used herein to mean "act as an example, case, or example." Any embodiment described herein as "exemplary" and / or "example" should not necessarily be construed as preferred or advantageous over other embodiments. Similarly, the term "embodiment of the invention" does not need to include all the features, advantages or modes of operation discussed in all embodiments of the invention.
In addition, many embodiments describe, for example, a set of actions to be performed by an element of a computing device. The various operations described herein can be performed by a particular circuit (eg, an application specific integrated circuit (ASIC)), by program instructions executed by one or more processors, or by a combination of both. Will be recognized. In addition, these series of operations described herein are in any form of computer-readable storage medium that stores the corresponding set of computer instructions that cause the associated processor to perform the functions described herein at run time. Can be regarded as something that should be implemented as a whole. Thus, various aspects of the invention can be practiced in several different forms, all of which are intended to fall within the scope of the claimed subject matter. Further, for each embodiment described herein, the corresponding form of such an embodiment may be described herein as, for example, "logic configured to perform the described operation". ..
The high data rate (HDR) subscriber station referred to herein as an access terminal (AT) may be mobile or fixed, and may be one or one referred to herein as a modem pool transceiver (MPT) or base station (BS). It can communicate with multiple HDR base stations. The access terminal communicates with the HDR base station controller, called the modem pool controller (MPC), base station controller (BSC) and / or packet control function (PCF), via one or more modem pool transceivers. Send and receive data packets. Modem pool transceivers and modem pool controllers are part of a network called an access network. The access network transports data packets between multiple access terminals.
The access network can further connect to additional networks outside the access network, such as the corporate intranet or the Internet, and can transport data packets between each access terminal and such an external network. An access terminal that has established an active traffic channel connection with one or more modem pool transceivers is called an active access terminal and is said to be in a traffic state. An access terminal that is establishing an active traffic channel connection with one or more modem pool transceivers is said to be in a connection setup state. The access terminal can be any data device that communicates over wireless channels or, for example, over wired channels using fiber optics or coaxial cables. The access terminal can be any of several types of devices, including, but not limited to, PC cards, CompactFlash®, external or internal modems, or wireless or wired telephones. A communication link for an access terminal to send a signal to a modem pool transceiver is called a reverse link or reverse traffic channel. A communication link for a modem pool transceiver to send a signal to an access terminal is called a forward link or forward traffic channel. As used herein, the term traffic channel can refer to either a forward traffic channel or a reverse traffic channel.
FIG. 1 shows a block diagram of an exemplary embodiment of the wireless system 100 according to at least one embodiment of the present invention. System 100 connects the access terminal 102 to a network device to connect data between the packet-switched data network (eg, intranet, Internet, and / or carrier network 126) and the access terminals 102, 108, 110, 112. It can include an access terminal such as a cellular telephone 102 that is communicating with an access network or wireless access network (RAN) 120 via an air interface 104 that can provide sex. As shown herein, the access terminal shall be a cellular phone 102, a personal digital assistant 108, a pager 110 referred to herein as a bidirectional text pager, and a separate computer platform 112 with a wireless communication portal. Can be done. Accordingly, embodiments of the present invention include wireless communication portals, including, without limitation, wireless modems, PCMCIA cards, personal computers, telephones, or any combination or partial combination thereof, or have wireless communication capabilities. It can be realized on any type of access terminal. In addition, the terms "access terminal," "wireless device," "client device," "mobile terminal," and variants thereof as used herein may be used interchangeably.
With reference to FIG. 1 again, the interrelationships between the components of the wireless network 100 and the elements of the exemplary embodiments of the invention are not limited to the configurations shown. System 100 is only exemplary, with remote access terminals such as wireless client computing devices 102, 108, 110, 112 to each other and / or carrier network 126, the Internet and / or others. It can include any system that allows wireless communication to and from components connected via air interface 104 and RAN120, including an unlimited number of remote servers.
The RAN120 controls messages sent (generally sent as data packets) to the base station controller / packet control function (BSC / PCF) 122. BSC / PCF122 is responsible for signaling, establishing and decomposing bearer channels (ie, data channels) between packet data service node 100 (PDSN) and access terminals 102/108/110/112. If link layer encryption is enabled, the BSC / PCF122 also encrypts the content before transferring it over the air interface 104. The features of BSC / PCF122 are well known in the art and will not be discussed further for brevity. The carrier network 126 can communicate with the BSC / PCF122 via the network, the Internet and / or the Public Switched Telephone Network (PSTN). Alternatively, the BSC / PCF122 can connect directly to the Internet or an external network. Generally, the network or internet connection between the carrier network 126 and the BSC / PCF122 transfers data, and the PSTN transfers voice information. The BSC / PCF122 can connect to multiple base stations (BS) or modem pool transceivers (MPT) 124. In a manner similar to a carrier network, the BSC / PCF122 is generally connected to the MPT / BS124 by network, internet and / or PSTN for data transfer and / or voice information. The MPT / BS124 can wirelessly broadcast data messages to access terminals such as cellular phones 102. MPT / BS124, BSC / PCF122 and other components can form RAN120, as is known in the art. However, alternative configurations can also be used, and the present invention is not limited to the illustrated configurations. For example, in another embodiment, the function of BSC / PCF122 and one of MPT / BS124 or
FIG. 2 shows a carrier network 126 according to an embodiment of the present invention. In the embodiment of FIG. 2, carrier network 126 includes a packet data serving node (PDSN) 160, a broadcast serving node (BSN) 165, an application server 170, and the Internet 175. However, in alternative embodiments, the application server 170 and other components may be located outside the carrier network. The PDSN160 utilizes, for example, cdma2000's radio access network (RAN) (eg, RAN120 in Figure 1) to move access to Internet 175, an intranet and / or a remote server (eg, application server 170). Provide to stations (eg, access terminals such as 102, 108, 110, 112 in Figure 1). Acting as an access gateway, the PDSN160 can provide simple IP and Mobile IP access, external agent support, and packet transport. The PDSN160 can act as a client for Authentication, Authorization, and Accounting (AAA) servers and other support infrastructures, and as is known in the art, to IP networks. Provide a gateway to mobile stations. As shown in Figure 2, the PDSN160 can communicate with the RAN120 (eg, BSC / PCF122) over a conventional A10 connection. A10 connections are well known in the art and will not be discussed further for brevity.
With reference to Figure 2, the broadcast serving node (BSN) 165 can be configured to support multicast and broadcast services. The BSN165 will be described in more detail below. The BSN165 communicates with the RAN120 (eg, BSC / PCF122) over a broadcast (BC) A10 connection and with the application server 170 over the Internet 175. BCA10 connections are used to forward multicast or broadcast messaging. Therefore, the application server 170 sends unicast messaging to the PDSN160 over the Internet 175 and multicast messaging to the BSN165 over the Internet 175.
In general, as described in more detail below, the RAN120 sends multicast messages received from the BSN165 over the BCA10 connection over the broadcast channel (BCH) of air interface 104 to one or more access terminals 200. Send to.
Referring to FIG. 3, the access terminal 200 (wireless device herein), such as a cellular phone, may eventually originate from the carrier network 126, the Internet and / or other remote servers and networks. It has a platform 202 capable of receiving and executing software applications, data and / or commands transmitted from the RAN 120. Platform 202 can include application specific integrated circuits (ASIC 208) or transceivers 206 operably coupled to other processors, microprocessors, logic circuits, or other data processing devices. The ASIC208 or other processor performs 210 layers of application programming interfaces (APIs) that interface with any resident program in memory 212 of the wireless device. Memory 212 can consist of read-only memory or random access memory (RAM and ROM), EPROM, flash card, or any memory common to computer platforms. Platform 202 can also include a local database 214 that can hold applications that are not actively used in memory 212. The local database 214 is generally a flash memory cell, but can be any secondary storage device known in the art, such as magnetic media, EEPROM, optical media, tape, software or hard disks. The components of the internal platform 202 are operably coupled to external devices such as antenna 222, display 224, push-to-talk button 228 and keypad 226, among other components, as is known in the art. You can also do it.
Accordingly, one embodiment of the present invention may include an access terminal that includes the ability to perform the functions described herein. As will be appreciated by those skilled in the art, various logical elements may be individual elements, software modules running on a processor, or any combination of software and hardware to achieve the functionality disclosed herein. Can be carried out at. For example, ASIC208, memory 212, API210, and local database 214 can all be used collaboratively to load, store, and perform the various functions disclosed herein, and thus the logic to perform these functions. Can be distributed to various elements. Alternatively, the functionality can be incorporated into a single individual component. Therefore, the features of the access terminal of FIG. 3 should be considered to be merely exemplary, and the present invention is not limited to the features or configurations exemplified.
Wireless communication between the access terminal 102 and RAN120 is code division multiple access (CDMA), WCDMA, time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal frequency division multiple access (OFDM), wide area mobile communication. It can be based on a variety of technologies, such as systems (GSM), or other protocols that can be used in wireless or data communication networks. Data communication typically takes place between the client device 102 and the MPT / BS124 and BSC / PCF122. The BSC / PCF122 can connect to multiple data networks such as carrier network 126, PSTN, Internet, and virtual private networks, thus allowing access terminal 102 to access a wider range of communication networks. As mentioned above, and as is known in the art, various networks and configurations can be used to transmit voice and / or data from the RAN to the access terminal. Therefore, the examples provided herein do not limit the embodiments of the present invention, but merely assist in explaining aspects of the embodiments of the present invention.
As discussed in the Background Technology section, multicast messaging can be performed in several ways. In order to better understand the embodiments of the present invention, the conventional multicast messaging process will be described with reference to FIGS. 4 and 5, respectively. Next, the multicast messaging process according to the embodiment of the present invention will be described in more detail.
Figure 4 shows a traditional multicast messaging process that uses the Broadcast Multicast Server (BCMCS) framework. The multicast messaging process of FIG. 4 running within the wireless system 100 of FIGS. 1 and 2 is described below. Referring to FIG. 4, at 400, the application server (or other initiator) requires that multicast messages be sent to a multicast group that includes ATs (eg, A, B, and C). 400 multicast messages are routed to BSN165. At 405, the BSN 165 forwards the multicast message over the BCA10 connection to the RAN 120 with the target destination of the multicast message or the associated multicast group including the AT. For example, a multicast message is first forwarded to BSC / PCF122, which analyzes the multicast group members of the multicast message and multicasts to each MPT / BS124 that serves one or more multicast group members. -Forward messages.
After receiving the forwarded multicast message, the RAN120 waits for the next available control channel capsule at 410. The control channels referred to herein are downlink control channels that are assigned different frequencies, coding and / or bandwidth than broadcast channels (BCHs). In general, control channels that traditionally contain only control messaging will be allocated less bandwidth, and broadcast channels (BCH) that traditionally contain data will have more bandwidth. Allocate.
With reference to Figure 5, each control channel cycle contains a total of 256 slots. Each control channel cycle includes a synchronous control channel capsule (SC), an asynchronous control channel capsule (AC), and several subsynchronous control channels (SSC). One SC is transmitted periodically or periodically in a given time slot of each control channel cycle with a period of 256 slots, and AC is transmitted "randomly" or in an asynchronous time slot within the control channel cycle. To. The SC is first sent in the time slot corresponding to "T mod 256 = offset", then "T mod" Retransmitted in the time slot corresponding to "4 = offset", T indicates the system time, and the offset indicates the time value deferred from the fixed time contained in the control channel header. Each SC can contain multiple control channel MAC layer packets, and each AC contains only one control channel MAC layer packet. Since each MPT / BS124 periodically transmits one or more control channel MAC layer packets, interference (eg, cell-to-cell interference) can occur if each MPT / BS124 transmits at the same time. Therefore, different offsets are applied to the SC of each MPT / BS124 to avoid collisions. MPT / BS can transmit three SSC capsules within one control channel cycle or 256 slot cycle. Each SSC generally sends only one control channel MAC layer packet. For an offset value of 2, the SSC is transmitted in time slots 66, 130 and 194. Control channel capsules (eg, SC, AC, SSC, etc.) are generally well known in the technical field of BCMCS systems, so further description thereof is omitted for brevity.
Returning to FIG. 4, at 410, the RAN120 is a synchronous control channel capsule (SC) (for example, at offset 2, time slot 2 during the next control channel cycle) or, instead, periodically for the BOM. You can wait for one of the reserved subsynchronous control channel capsules (SSCs) (for example, for offset 2, one of control channel cycle time slots 66, 130, 194). For example, one particular control channel capsule within each control channel cycle can be reserved for a particular BOM. Multiple cycle delays can occur because other applications are trying to access the control channel and other messages may be scheduled.
At 415, after waiting for the next available SC or SSC, the RAN120 broadcasts a broadcast overhead message (BOM) over the air interface to one or more multicast group members (eg, AT). Send to A, B, C). BOM is a forward link control message defined by the EV-DO standard. The BOM is used to inform each multicast group member about the BMCCS flow currently being carried in the sector. The BOM also provides information about the forward link physical layer time slots that should be decrypted to receive the desired packet flow, as well as the number of physical layer slots per broadcast physical layer packet, and the physical used to transmit the flow. Provides interlaced multiple pair (IM pair) information, which is information about the layer rate. At 420, the RAN 120 waits for a predetermined number of slots (eg, 8-16 slots) for the BOM to be decrypted at the target AT. After delay 420, RAN120 waits at 425 for the BCH slot indicated by the decrypted BOM. This creates another delay that can be exacerbated based on the traffic on the broadcast channel. At 430, the RAN120 sends an announcement message to each multicast group member or target AT servicing on the designated BCH slot via the broadcast channel (BCH).
As mentioned above with respect to Figure 4, traditional BMCCS multicast messaging generally involves each target AT or multicast before the multicast message is sent over the broadcast channel (BCH) to each member of the multicast group. -Requires group members to decrypt broadcast overhead messages (BOMs). This causes both a delay for scheduling the BOM and a delay for decoding, resulting in a potential subsequent delay for scheduling the announcement message.
In the embodiment of FIG. 6, at 600, application server 170 requires that multicast messages be sent to a multicast group that includes AT A, B, and C. 600 multicast messages are routed to BSN165. At 605, the BSN165 forwards the multicast message over the BCA10 connection to the RAN120 with the target destination of the multicast message or the associated multicast group containing the AT. For example, BSN165 forwards a multicast message to BSC / PCF122, which analyzes the multicast group members associated with the multicast message and serves the multicast message to one or more multicast group members. Transfer to each MPT / BS124.
After receiving the forwarded multicast message, the RAN120 analyzes the received multicast message at 610. Based on the analysis at 610, RAN120 determines at 615 whether special processing instructions or processing should be applied to the multicast message. For example, the analysis at 610 can evaluate the Internet Protocol (IP) header of multicast messages. If it is determined that a "flag", for example, the Differentiated Services Code Point (DSCP) value in the IP header exists in the IP header, the flag can be interpreted as a trigger requiring special processing for multicast messages. Alternatively, it can be flagged within the well-known BCA10 identifier (ID) or BCMCS flow ID (eg, separate from the IP header). For example, prior to a multicast session, application server 170 should have one or more BCMCS flow IDs that should be "reserved" or associated with special processing (for example, a multicast session reserved for emergency communications). Can be selected. The application server 170 can then share the selected or reserved BCMCS flow ID with the RAN 120. Therefore, during a multicast session, the RAN120 can then check at 610 whether the multicast message received corresponds to one of the reserved BCMCS flow IDs, and if so, 615. Determines to apply special processing to the received multicast message.
In another alternative, flags can be set by both the IP header and the BCA10ID. In general, flags in the IP header (for example, multicast IP address and / or port number) can be recognized / decrypted by the BSC part of BSC / PCF122 in RAN120, and flags in DSCP can be recognized / decrypted by the PCF part of BSC / PCF12 in RAN120. Can be recognized / decrypted. BCA10 identifiers and DSCP values are well known in the art and will not be further described for brevity.
For example, a "flag" can be inserted into a multicast message at any higher level location within the network architecture associated with RAN120 (for example, by IP header, BCMCS flow ID or BCA10ID). The flag can be inserted in the IP header by application server 170, BSN165, etc. In another example, the flag can be used to indicate a "higher priority" multicast message. For example, multicast messages related to emergency alerts may be "flagged", but multicast messages related to product advertising are not necessarily "flagged".
At 615, if RAN120 decides not to apply any special processing to the multicast message, the process proceeds to block 410 in Figure 4 and uses the traditional BCMCS multicast message protocol to multicast the multicast message. Can be sent to a group. Alternatively, at 615, if RAN120 determines that special processing is required for the multicast message, the process proceeds to 620.
At 620, the RAN 120 generates a data oversignaling (DOS) message, including a multicast message. DOS messages are well known in the technical field of the EV-DO protocol. DOS messages are defined by the EV-DO standard as unicast messages and are not related to EV-DO standard multicast messaging. However, embodiments of the present invention generate DOS messages, including multicast messages. DOS messages can be reconfigured to support the multicast messaging protocol, as described below.
CDMA2000 1xEV-DO defines access terminal identifiers (ATIs), broadcast ATIs (BATIs), multicast ATIs (MATIs), unicast ATIs (UATIs), and random ATIs (RATIs) to identify access terminals. BATI is defined as "00", MATI is defined as "01", UATI is defined as "10", and RATI is defined as "11". All three ATI types except BATI have a 32-bit field to represent ATI. UATI is used in one-to-one call processing procedures.
As mentioned above, DOS messages are defined by the EV-DO standard as related to unicast messaging and not to multicast messaging. However, the DOS message generated at 620 is addressed to the Multicast Access Terminal Identifier (MATI), which is set to the BMCCSFlowID associated with the multicast message. BCMCSFlowID allows the AT to identify the appropriate stream on the broadcast channel for group calls. Generally, the BMCCSFlowID is known at each AT monitoring a particular BMCCS flow (for example, the BMCCSFlowID is indicated by the BOM). Therefore, by tagging a 620 DOS message or addressing it to MATI, the target AT receiving the DOS message will direct the DOS message to a particular BMCCS flow, as described in more detail below. It can be interpreted as a related multicast message and directly receive the information needed to initiate a group call. However, it should be noted that, in the alternative, other embodiments do not have to be limited to setting MATI to BCMCSFlowID to distinguish DOS as a multicast message. For example, a multicast group member or AT can set MATI to any value that can be interpreted to identify MATI as a multicast message for a particular multicast group.
At 625, RAN120 waits for the next available control channel capsule on the control channel. At 630, the RAN120 sends DOS messages over the control channel to multicast group members within the next available control channel capsule. As mentioned above, each sync channel (SC) of the control channel capsule (eg, or alternative, each sub-sync channel) can contain multiple MAC layer packets. Thus, in one example, a DOS message can be included in the first MAC layer packet of a given control channel capsule.
At 635, each target AT receives a DOS message transmitted over the control channel at 630. Since the DOS message is addressed to MATI, each target AT determines that the DOS message contains an associated multicast message (for example, as opposed to a unicast message). Please understand that a DOS message addressed to MATI will probably be interpreted as an error by a traditional handset or AT. In this embodiment, however, each target AT is addressed to MATI (eg, or multicast) so that ATs configured according to this embodiment extract multicast messages from received DOS messages at 635. Control messages (identified as messages) can be configured to be recognized as multicast messages. Each target AT can confirm receipt of the multicast message after successful reception or "extraction" of the multicast message contained within the DOS message. In another aspect of the invention, in order to ensure that DOS multicast messages are correctly interpreted by the recipient AT, the RAN120 is a DOS message in which one or more given target ATs use, for example, MATI. Can be first confirmed that can be interpreted as a multicast message. In one example, each AT that receives a DOS message can decrypt / extract the multicast message at 635, regardless of whether the AT is actually one of the scheduled recipients of the multicast message. In another example, only the "target" AT, or the AT involved in the multicast session, can decrypt / extract the multicast message from the DOS message at 635.
As you can see from the above description of the exemplary multicast messaging process in Figure 6, it is related to sending a BOM to a multicast group member, waiting for a BOM decryption, and sending an announcement message. Avoid delays and potential data loss by assigning higher priority status for DOS multicast messages with IP header flags and sending higher priority multicast messages with control channels. Can be done.
In addition, the process of FIG. 6, described as being performed in RAN120 and / or MPT / BS124, can be performed simultaneously in one or more RANs and / or MPT / BS in other embodiments of the invention. It will be appreciated that the description in Figure 6 is intended for a single RAN and MPT / BS implementation for convenience of explanation only. In another example, if the multicast group members are distributed among the various MPT / BS124, steps 610-635 can be performed independently among the various MPT / BS124.
Further, the embodiment of Figure 6 targets 1xEVDO DOS messages configured for MATI addresses or multicast bit signatures as opposed to UATI addresses or unicast bit signatures, but for multicast messages on the control channel. It will be appreciated that any control channel message adapted to comply with the MATI type message can be used as an alternative for forwarding.
The embodiment of FIG. 6 is generally intended for multicast messaging, not particularly "interactive" multicast messaging. An interactive multicast message is a multicast message that requests a response or feedback from each or part of a target AT or multicast group member within a multicast group. For example, an interactive multicast message is when a mobile subscriber who chooses Push-to-Talk (PTT) wants to establish communication with one or more multicast group members within a given multicast group. , Can handle PTT messages.
In order to better understand the present invention, the conventional method in which the AT responds to the interactive multicast message will be described below, and then the interactive multicast message response protocol according to the embodiment of the present invention will be described.
Figure 7 shows the traditional access terminal response to an interactive multicast message. In particular, FIG. 7 shows the continuation of the process of FIG. 4 described above. Therefore, the process in Figure 4 runs as described above, and it is assumed that the multicast messages sent to each target AT A, B, and C over the broadcast channel (BCH) are interactive multicast messages. .. Under these assumptions, interactive multicast messages are received by AT A, B and C at 700, respectively. At 705, each of AT A, B, and C determines that the multicast message received is interactive (eg, based on the evaluation of the data contained therein). Then, at 710, each target AT A, B, and C responds to an interactive multicast message by sending a message over a reverse link to RAN120. In particular, AT using traditional techniques A, B, and C, respectively, follow the access procedure specified by the traditional broadcast AccessParameters message (assuming the AT does not exclude or delete interactive multicast messages), respectively, for reverse link or uplink. Can respond to interactive multicast messages on the access channel. The parameters in the AccessParameters message are adapted to the main use cases (eg call and page response), and the AT has a relatively small amount due to the "A Persistence feature" so that there are many simultaneous or parallel responses from different ATs. Allows the response to be sent to an interactive multicast message with a delay. The AccessParameters message and APersistence features are described in more detail below.
Therefore, as the number of target ATs increases, so does the number of target ATs transmitting to the RAN120 on the reverse link access channel at the same time, which increases interference and the potential for each AT to successfully reach the RAN120. It will be understood that it will be lower.
As mentioned above, parallel responses on a reverse link access channel with multiple ATs can degrade system performance. 8 to 11 described below cover a set of interactive multicast message response protocols to improve system performance by more efficiently allocating access channels for interactive multicast message response.
FIG. 8 shows an interactive multicast messaging generation and transmission process according to an embodiment of the present invention. In the embodiment of FIG. 8, at 800, the application server 170 has an interactive multicast message AT. Requests to be sent to a multicast group that includes A, B and C. For example, although not shown in Figure 8, an interactive multicast message can be generated in response to a Push-to-Talk (PTT) message received from a given AT in a given multicast group. 800 multicast messages are routed to BSN165. At 605, the BSN165 forwards the multicast message over the BCA10 connection to the RAN120 with the target destination of the interactive multicast message or the associated multicast group containing the AT. For example, BSN165 forwards a multicast message to BSC / PCF122, which analyzes the multicast group members associated with the multicast message and serves the multicast message to one or more multicast group members. Transfer to each MPT / BS124.
After receiving the forwarded multicast message, the RAN120 analyzes the received multicast message at 810. Based on the analysis in 810, RAN120 determines in 815 whether the multicast message received is interactive (whether the multicast message requests a response from one or more of its multicast group members). To judge. If RAN120 determines at 815 that the multicast message received is not interactive, the process proceeds to 615 in Figure 6 and uses the non-interactive multicast message protocol to make the multicast message a member of the multicast group. Forward. Alternatively, if RAN120 determines at 815 that the multicast message received is interactive, the process proceeds to 820.
In the 820, the RAN 120 generates one or more access control messages (ACMs) to schedule AT responses to interactive multicast messages. An example of ACM generation, such as the 820, will now be described in more detail with reference to FIG.
FIG. 9 shows an ACM generation process 820 according to an embodiment of the present invention. Referring to FIG. 9, at 900, the RAN120 determines the number of sectors in which the interactive multicast message has at least one target AT or multicast group member addressed within the wireless system 100. For example, RAN120 can perform decision 900 based on group member and location update reports received from multicast group members, as described in more detail below with respect to FIG. Generally, a group member report is received from a multicast group member and contains a list of associated groups (group membership information) for each multicast group member.
In 905 of FIG. 9, RAN120 selects one of a plurality of sectors from 900 determined sectors (for example, random selection). At 910, RAN120 initializes the multicast member set for the selected sector. The initialized multicast member set contains each target AT or multicast group member belonging to the multicast group associated with the interactive multicast message in the selected sector.
At 915, RAN120 deletes all ATs in the multicast member set that have an active traffic channel. For example, an AT with the currently active traffic channel (for example, commonly known as RAN120 because RAN120 monitors / supports the traffic channel) responds through the traffic channel and is therefore excluded from the ACM. it can. Then, at 920, the RAN selects a given number of target ATs that are expected to be likely to respond to interactive multicast messages.
The decision of selection process 920 can be made in many ways. For example, RAN120 can select the set of ATs that most recently provided location update reports to RAN120 (see, for example, 900 above and the description in Figure 11 below). In another example, the RAN 120 can perform the selection process 920 based on channel quality criteria. In this example, RAN120 is one based on current or past criteria for the channel quality of AT on a given channel (eg, uplink channels measured in RAN120, downlink channels reported by AT, etc.). Or select multiple ATs. However, it will be appreciated that the selection process 920 can be performed on the basis of any well-known criteria and need not be limited to the criteria disclosed above. In addition, the RAN 120 can perform the selection process 920 based on any combination of criteria contained above and / or among the criteria well known in the art.
In 925 of FIG. 9, RAN120 arranges 920 selected ATs in a given order to generate an ACM. Given, for example, the AT that is expected to respond to interactive multicast messages in a timely manner is placed first, followed by the next AT that is expected to respond. The order of can be arranged. In one example, the ACM can be constructed so that the control message is addressed to MATI, similar to the DOS message described above for Figure 6. In another example, by giving a unicast ATI (UATI) within the ACM, the given order can be specified by the ACM, and each UATI specifies one of the 920 selected ATs. Or be addressed to it. Thus, the first UATI in the ACM corresponds to the first AT in a given order, the second UATI in the ACM corresponds to the second AT in a given order, and so on. .. It will be appreciated that less than all multicast group members located within a given sector can be specified by UATI within the ACM to reduce channel load. Therefore, the 925 will generate an ACM for the sector selected in the 905.
In 930 of FIG. 9, RAN120 determines whether an ACM has been generated for each sector determined in 900. If RAN120 determines that not all ACMs have been generated yet, the ACM generation process will return to 905 and the process can be repeated for the new sector. Alternatively, if RAN120 determines that all ACMs have been generated, the process terminates at 935.
Further, although steps 900-930 have been described above as being "sector" based, these steps can be performed alternative at the location area (LA) level or the multicast area (MA) level (for example, 900 is at least 900). Determine the number of MAs or LAs that have one target AT, such as 905 selecting one of the determined MAs or LAs). MA and LA will be described in more detail below with respect to FIG.
Returning to the embodiment of FIG. 8, FIG. 9 shows an example of ACM generation, but it can be understood that ACM can be generated by other methods as an alternative. For example, an ACM can be configured to include an APersistence value without initially including the UATI ordering. For example, as mentioned above, the AccessParameters message typically contains the APersistence value that is broadcast to all ATs and used by each AT. In one example, the ACM can accommodate broadcast AccessParameter messages, but in one embodiment of the invention it can be configured to be associated with a multicast message (eg, addressed to MATI). Therefore, the "multicast" AccessParameter message can determine the temporary APersistence for the multicast group to respond to the interactive multicast message. Alternatively, the temporary APersistence value is Storage (for example, on the downlink control channel). Can be sent as a BLOB allocation message. Generally, the above APersistence value is "temporary" in the sense that it is used to respond to interactive multicast messages, and then "reset" to the default APersistence value established by traditional AccessParameter messages. The default. APersitence values are well known in the art and are discussed in more detail below with respect to 1040 in Figure 10.
In another alternative ACM example, the ACM does not have to contain the actual APersistence value, but rather each AT can contain a given value from which their own temporary APersistence value can be derived. Thus, in one example, the ACM can be configured to include a value N that indicates the number of ATs in the multicast group. Each AT can then use the value N to calculate a temporary APersistence value, as described in more detail below for 1040 in FIG.
The RAN120 then determines at 825 whether a special processing instruction or processing should be applied to the multicast message. In general, the judgment of 825 is carried out as in 615 of Figure 6, and therefore will not be further explained for brevity. If the RAN120 decides not to apply any special processing, the ACM is sent with the BOM to the multicast group member or AT in the next available slot designated for the BOM (see, eg, Figure 4). See the brief description of the BOM transmission you made). For simplicity, the following description related to ACM processing is described as if the ACM was sent on the control channel with a multicast message contained within a DOS message. However, it will be appreciated that the ACM can instead be sent in response to the ACM described below, along with a BOM for the response behavior in the AT.
Steps 830 and 835 then correspond to steps S620 and S625 described above with respect to FIG. 6, therefore further description thereof is omitted for brevity.
At 840 in Figure 8, the RAN120 sends a DOS message containing an interactive multicast message and the generated ACM to each target AT in each sector containing two or more target ATs or multicast group members. The ACMs contained during the transmission of the 840 are sector by sector (or, or by LA, by MA, etc.) based on which ACM corresponds to which sector, as determined by the process in Figure 9 above. It will be understood that it will change. In one example, both DOS messages and ACMs are sent over the downlink control channel at the 840 (eg, in the first MAC layer packet of the next available control channel capsule). In one example, the ACM can be sent as a Storage BLOB Assignment message over the downlink.
Then, in 845 of Figure 8, the target AT (eg, AT A, AT B, and ATC) receives a DOS message containing an interactive multicast message and an ACM on the downlink control channel (eg, ACM). Extract interactive multicast messages from DOS messages (as in 635 in Figure 6).
FIG. 10 shows an interactive multicast messaging response process according to an embodiment of the present invention. Figure 10 is a continuation of Figure 8 and represents the process that runs at each target AT in the multicast group after 845 in Figure 8.
In the embodiment of FIG. 10, at 1000, a given target AT analyzes the multicast message extracted in 845 of FIG. 8, and the multicast message responds or feeds back (eg, one or more group members). Determine if the message is an "interactive" multicast message that requires a PTT call) requesting a dialog with. If a given target AT determines that the multicast message is not interactive, the process terminates at 1005 and the given target AT does not require any further action to support the multicast message. Alternatively, if a given target AT determines that the multicast message is interactive, the process proceeds to 1010.
At 1010, a given target AT determines if an ACM associated with an interactive multicast message has been received. If a given target AT determines that no associated ACM has been received, the process proceeds to 1030, and the given target AT sends a response to RAN120 over the uplink access channel without delay. To do. In other words, a given target AT does not wait before responding, but rather responds as soon as possible (eg, based on the default APersistence value).
Alternatively, at 1010, if a given target AT determines that an associated ACM has been received, the process proceeds to 1015. At 1015, a given target AT determines the AT sequence information stored in the associated ACM. The AT sequence information is the sequence or list of ATs that each target AT can interpret as the sequence in which each target AT is allowed access to the uplink access channel (for example, the "slot" sequence). Including. For example, as described above for 925 in FIG. 9, the AT sequence information can be stored as a sequential list of UATIs addressed to each different AT, and the UATI sequence corresponds to the AT sequence information.
At 1020 in FIG. 10, a given target AT determines whether the AT sequence information specifies a given target AT in the sequential list of ATs. Next, an example of this judgment is given with respect to Table 1 (below).<tables num="1"><img id="000002" he="86" wi="157" file="JP5301550B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
At 1020, if a given target AT determines that the AT sequence information specifies a given target AT in the sequential list of ATs, the process proceeds to 1025, otherwise the process proceeds to 1035. .. For example, if the given target AT is AT B and the ACM corresponds to ACM Example 1 in Table 1, 1020 determines that AT B exists as UAT I2 in the sequential list of ATs. In an alternative example, if a given target AT is AT B and the ACM corresponds to ACM Example 2 in Table 1, 1020 determines that AT B is not in the sequential list of ATs.
At 1025, a given target AT waits for some slots based on the AT sequence information of the ACM or the given target AT position in the sequential list of ATs. For example, if the given target AT is ATA and the ACM corresponds to ACM Example 1 in Table 1, then ATA is the AT first listed in the ACM's sequential list of ATs. The given target AT waits for 0 slots and responds without delay (for example, in the next or first slot of the uplink access channel). In the alternative example, if the given target AT is ATA and the ACM corresponds to ACM Example 2 in Table 1, then ATA is the AT second listed in the sequential list of ACM ATs. , A given target AT waits for one slot and responds only after a delay of one slot (for example, after the first available slot is reserved for another target AT). After waiting according to 1025, a given target AT responds to RAN120 at 1030.
At 1035, if a given target AT is not in the sequential list of ATs in the ACM, the given target AT waits for some slots based on the total number of ATs listed in the ACM. For example, if three ACMs are listed in an ACM by three different UATIs and a given target AT is not addressed by one of three different UATIs, then a given target AT will be (eg, by ACM). Each of the ATs given the access channel priority waits for three slots at 1035 (to allow access to be attempted before the unlisted or unpriority AT).
Then, at 1040, a given target AT determines whether to respond to RAN120 in the next slot (eg, after waiting for 1035). For example, a given target AT can run a probabilistic or APersistence process that determines whether to access the uplink access channel in order to respond to interactive multicast messages. APersistence is defined by the 1xEV-DO standard and is commonly given in Access Parameters messages. As mentioned earlier for 820 in Figure 8, AccessParameters messages are broadcast to all ATs (eg, via broadcast channel BCH) and contain APersistance values or features that each AT should use. For example, the commonly used APersistence value is 0.85. Therefore, if a mobile subscriber is attempting to initiate a call, the chance of making a call to a given slot is 0.85 or 85%. If the call is not made in the first slot, the mobile subscriber will retry in the next slot with another 85% chance. Therefore, a call can be made for each time slot, and the interfering mobile subscriber will not interfere with the mobile subscriber at some point, resulting in a permanent call failure (eg, "worst case". "Scenario) is unlikely.
However, this "default" form of APersistence may not be sufficient to avoid conflicting parallel responses from multiple ATs, so ACMs are used for interactive multicast messages sent to a relatively large number of ATs. It can be configured to include APersistence specifically configured to handle concurrent / concurrent responses that may be expected in response. For example, if N is the total number or estimated total number of target ATs in a given cluster (eg, a physical area that corresponds to or does not correspond to one or more sectors) or a sector (for example, given). In the 910 initialized multicast member set for the sector of the target AT, the number of target ATs can be included with the AT sequence information in the ACM), given target AT is based on N at 1040. Probability can be used to determine access to the uplink access channel. For example, the probabilities are 1 / N, 1 / (NX), where X is the number of ATs specified in the AT sequence information such as ACM. In general, the 1040 will have a relatively small number of ATs (eg, one, two, etc.) per slot on average according to the "reserved" slots for ATs listed in the ACM. Attempts to ensure access to the channel.
Therefore, the ACM is (i) the specified order or slot sequence shown in ACM Examples 1 and 2 (eg, based on the UATI order in the ACM), (ii) no associated "deterministic" function or specified order. APersistence value based on an estimate N of the total number of ATs in a sector or cluster that may potentially interfere with each other, or (iii) an estimate N for which each AT can calculate its own APersistence value. You can instruct the AT to respond to interactive multicast messages based on any of the above: It will be appreciated that (ii) and (iii) can be used together with (i) respectively (for example, the specified order can be followed by the APersistence function for unspecified ATs that do not exist in the order). Further, the process of FIG. 10 covers embodiments in which (i) is used with (ii) or (iii), whereas (ii) or (iii) can be used independently of (i). Let's be understood. For example, if the specified order contains 0 ATs, then according to (ii) or (iii), interactive multicast message feedback can be established using only the APersistence feature.
At 1045, a given target AT determines whether a stochastic process has made a decision to access the uplink access channel. Given target AT is up when not decide to access the Uplink access channel, the process returns to 1040 to repeat for the next slot. Alternatively, if a given target AT decides to access the uplink access channel, the process proceeds to 1030 and responds to the uplink access channel RAN120 in the specified slot. After 1030, a given target AT "resets" the response protocol indicated by ACM in 1032 and resumes normal operation in 1010. In other words, when a given target AT returns to 1010, the APersistence value shown in the ACM is no longer used, but rather a given target AT receives an ACM that specifies a new "temporary" APersistence value. Until then, it reverts to using the APersistence value specified by the Broadcast Access Parameters message as in the prior art.
As mentioned earlier for steps 900 and 920 in Figure 9, the information related to the group members of a given multicast group can be based on the "group member report" provided to RAN120 by each multicast group member. .. Therefore, FIG. 11 described below shows a multicast group member reporting process according to an embodiment of the present invention.
In the embodiment of FIG. 11, at 1100, a given AT belonging to one or more multicast groups is powered on. After powering up a given AT (for example, after identifying the pilot signal transmitted by one or more base stations in the RAN120, and / or after performing any other initial power-up procedure). , 1105, given AT sends group membership information (Group Member Report) to RAN120. For example, the group membership information provided by a given AT can include the name of each group to which the given AT wants to belong. In one example, group member reports can be included within standard BMCCSFlowRegistration messages, or alternative, such as proprietary or non-proprietary or non-proprietary group membership notification (GMN) messages encapsulated in StorageBLOBNotification messages on the uplink. Can be included in standard messages. For example, a GMN can include a list of multicast IP addresses and port numbers.
At 1110, after reporting group membership information, a given AT resumes normal operation (eg, entering idle mode, making a voice call, etc.). In 1115, a given AT should use a supplementary "route update" or report to update its location, or, alternative, its group members using a supplementary group membership report. Determine if the ship information should be updated. The 1115 decision can be made in one of several ways. For example, a given AT can be based on a distance-based registration (DBR) protocol, so that after a given distance has passed (for example, which (one or more) a given AT is). Update its location information (based on whether it has passed a sector, etc.). A given distance can be based on which base station a given AT was handed off to, which base station a given AT was monitoring while idle, and so on. In an alternative example, a given AT provides a report to RAN120 once per cycle, since 1115's judgment can be based on a given cycle. In another alternative, a given AT can send a location update report (and group member report) to RAN120 each time it enters a new location area (LA), and each LA is defined by (eg, RAN120). Corresponds to a subnet or part of a PCF area. In another alternative example, Judgment 1115 (for example, a given AT attempts to monitor new multicast group communications, stops monitoring previously requested multicast group communications, etc.). It can be based on whether a given AT wants to change its group membership information.
At 1115, if a given AT decides not to update its location and / or its group membership information, the process returns to 1110 and the given AT resumes normal operation. Otherwise, at 1120, a given AT sends a supplementary report (eg, one or more of a location report or a supplementary group membership report) to RAN120 before returning to 1110.
While a multicast group member or AT provides a group member report to RAN120, RAN120 monitors the report. The RAN120 has a number of ATs that belong to any particular group, which AT belongs to which group, recently when each group member provided a location update report, each group member's location (eg sector), etc. Maintain a database that contains. The location of each group member can be stored in RAN120 as being within a particular multicast area (MA), and each MA corresponds to a group of contiguous sectors that potentially serve one or more group members ( For example, "potentially" is due to the fact that the group member's location may not be in the granularity of the sector, the group member may not respond to interactive multicast messages, and so on). In one example, two or more MAs can be identified for a group if the group members are geographically dispersed.
The embodiments of FIGS. 8 to 11 have been described as intended to schedule a response to an interactive multicast message in cooperation with the previously described embodiment of FIG. 6, although FIGS. 8 to 11 have been described. It will be appreciated that the embodiments of are not required to be so limited. For example, ACM can also be used to schedule interactive multicast message feedback or responses to "traditional" interactive multicast messages, where the multicast messages are encapsulated within DOS messages and on the control channel. You don't have to be limited to the examples sent in. In other words, the scope of the embodiments of the present invention includes any type of multicast or broadcast message that receives feedback from the AT. In addition, multicast feedback can be encapsulated in the initial response (eg, within the access probe) or included in the tracking message after the traffic channel has been established. However, in any situation, embodiments of the present invention reduce potential collision problems and for ATs with designated or reserved slots (eg, ATs "listed" in the ACM). You can increase the probability that a response will be received.
Those skilled in the art will appreciate that information and signals can be represented using any of a wide variety of techniques and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be mentioned throughout the above description are voltages, currents, electromagnetic waves, magnetic or magnetic particles, light fields or optical particles, or them. It can be expressed by any combination of.
Moreover, it is noted that the various exemplary logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. The trader will be understood. To articulate this compatibility of hardware and software, various exemplary components, blocks, modules, circuits, and steps have been described above in general with respect to their functionality. Whether such functionality is implemented in hardware or software depends on specific application examples and design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in various ways for each particular application, but such implementation decisions should not be construed as causing a deviation from the scope of the invention.
The various exemplary logic blocks, modules, and circuits described in connection with the embodiments disclosed herein are general purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), and field programmables. Implemented using a gate array (FPGA) or other programmable logic device, individual gate or transistor logic, individual hardware components, or any combination thereof designed to perform the functions described herein. Or you can do it. The general purpose processor can be a microprocessor, but in alternative forms the processor can be a conventional processor, controller, microcontroller, or state machine. Processors can be implemented in a combination of computing devices, such as a combination of DSP and microprocessor, multiple microprocessors, one or more microprocessors working with a DSP core, or any other such configuration. ..
The methods, sequences, and / or algorithms described in connection with the embodiments disclosed herein can be implemented directly in hardware, in software modules executed by a processor, or in combination of the two. The software module resides in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the art. can do. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write the information to the storage medium. Alternatively, the storage medium can be integrated into the processor. Processors and storage media can reside in the ASIC. The ASIC can reside on a user terminal (eg, an access terminal). Alternatively, the processor and storage medium can reside as individual components within the user terminal.
In one or more exemplary embodiments, the features described may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the function is stored on a computer-readable medium as one or more instructions or codes.<u style="single">can do. The storage medium is</u>, Can be any available medium accessible by the computer. By way of example, but not limited to, such computer readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage, or the desired program. It may be equipped with any other medium that can be used to carry or store the code in the form of instructions or data structures and is accessible by a computer.<u style="single">it can. This specification</u>The discs and discs used in are compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), and floppy®. Including discs and Blu-ray discs®, discs typically reproduce data magnetically, and discs optically reproduce data with a laser. The above combinations should also be included within the scope of computer-readable media.
Although the above disclosure shows exemplary embodiments of the invention, various modifications and modifications can be made herein without departing from the scope of the invention as defined by the appended claims. Please note. It is not necessary to perform the functions, steps and / or operations of the method claims according to the embodiments of the invention described herein in a particular order. Further, although the elements of embodiments of the invention may be described or claimed in the singular, the plural is contemplated unless explicitly stated to limit it to the singular.<u style="single">The inventions described in the claims at the time of filing the present application are described below.</u><u style="single"> [1] A method of responding to multicast messages,</u><u style="single"> Receiving a specified interactive multicast message for a multicast group that includes a plurality of multicast group members, the interactive multicast message requests the plurality of multicast group members to respond. To receive and</u><u style="single"> Receiving an access control message (ACM) for the multicast group, wherein the access control message indicates a feedback instruction for the multicast group.</u><u style="single"> Responding to the interactive multicast message based on the feedback instruction to the plurality of access terminals indicated by the access control message.</u><u style="single"> How to prepare.</u><u style="single"> [2] The feedback instruction determines (i) the order of a given plurality of access terminals and (ii) a stochastic response protocol for the multicast group member to respond to the interactive multicast message. The method according to [1], wherein the given plurality of access terminals belong to the multicast group, including at least one with information capable.</u><u style="single"> [3] Further comprises delaying the response to the interactive multicast message to a given access terminal based on the position of the given access terminal in the order of the plurality of access terminals. The method described in [2].</u><u style="single"> [4] Further delaying the response to the interactive multicast message to the given access terminal based on the number of the plurality of access terminals if the given access terminals are not present in the order. The method described in [2].</u><u style="single"> [5] The method of [4], further comprising responding to the interactive multicast message based on the stochastic response protocol in a subsequent time slot.</u><u style="single"> [6] The stochastic response protocol is the APersistence function, and each AT probabilistically determines the APersistence value, which is the persistence probability of the APersistence function, or the number of time slots for delaying the response. The method according to [2], which comprises at least one of the possible numbers.</u><u style="single"> [7] The method according to [6], wherein the at least one number includes N, where N is the number of the plurality of access terminals to which the interactive multicast message is sent.</u><u style="single"> [8] The method according to [7], wherein the duration probability of the APersistence function is 1 / N.</u><u style="single"> [9] The method according to [7], wherein the stochastically determined delay is randomly determined in the range 0 to (N-1).</u><u style="single"> [10] The number of the plurality of access terminals to which the interactive multicast message is sent is N, the number of the plurality of access terminals in the event response sequence is X, and at least one of the numbers is N. The method described in [7], which includes both and X.</u><u style="single"> [11] The method according to [10], wherein the duration probability of the APersistence function is 1 / (NX).</u><u style="single"> [12] The method according to [2], wherein the order of the plurality of access terminals is determined based on at least one access terminal criterion.</u><u style="single"> [13] The method of [12], wherein the at least one access terminal criterion comprises the expected availability of a given access terminal in response.</u><u style="single"> [14] The method according to [13], wherein the expected availability is based on the last time the given access terminal was reported to be available.</u><u style="single"> [15] The method of [14], wherein the given access terminal reports availability based on a distance-based registration (DBR) protocol.</u><u style="single"> [16] The method of [14], wherein the given access terminal periodically reports availability.</u><u style="single"> [17] The method according to [14], wherein the given access terminal responds to an inquiry from a base station and reports availability.</u><u style="single"> [18] The method of [14], wherein the availability report is a multicast group report indicating the multicast group membership required for the given access terminal.</u><u style="single"> [19] The method according to [18], wherein the multicast group report is provided within one of the BCMCSFlowRegistration or StorageBLOBNotification messages according to the 1xEV-DO standard.</u><u style="single"> [20] The method of [14], wherein the availability report is a location update report indicating the multicast group membership required for the given access terminal.</u><u style="single"> [21] The order of the plurality of access terminals is provided in a control message addressed to a multicast ATI (MATI) and includes a plurality of unicast ATIs (UATIs), each of which has the order. The method according to [2], wherein the address is specified to a different access terminal among the plurality of access terminals to indicate.</u><u style="single"> [22] After each access terminal having a UATI is first given the opportunity to respond, the access terminal among the plurality of access terminals not specified by the corresponding UATI in the control message is the stochastic response protocol. The method described in [19], which is scheduled to respond via.</u><u style="single"> [23] The method of [1], further comprising transitioning from the feedback instruction contained in the access control message to a previous set of feedback instructions after the response step.</u><u style="single"> [24] The method of [23], wherein the previous set of feedback instructions corresponds to the APersistence function indicated by the AccessParameters message.</u><u style="single"> [25] The method according to [1], wherein the received access control message is received via a downlink control channel.</u><u style="single"> [26] The method according to [1], wherein the received access control message is addressed to the multicast access terminal identifier (MATI) of the multicast group.</u><u style="single"> [27] The method according to [1], wherein the received access control message is included in the Storage BLOB Assignment message.</u><u style="single"> [28] A method of scheduling responses to multicast messages,</u><u style="single"> The access control message comprises generating an access control message, the access control message indicates a feedback instruction to a plurality of access terminals belonging to a given multicast group, and the feedback instruction is an interactive multicast message by the plurality of access terminals. A method that shows a temporary way to respond to.</u><u style="single"> [29] Sending the access control message to the plurality of access terminals and</u><u style="single"> Sending an interactive multicast message to the plurality of access terminals, wherein the interactive multicast message is specified for the given multicast group including the plurality of access terminals. That and</u><u style="single"> The method according to [28], further comprising.</u><u style="single"> [30] The method of [28], wherein the feedback instruction is intended to be followed in order to respond to the interactive multicast message associated with the access control message.</u><u style="single"> [31] The feedback instruction determines (i) the order of a given plurality of access terminals and (ii) a stochastic response protocol for the multicast group member to respond to the interactive multicast message. 28. The method of [28], wherein the given plurality of access terminals belong to the multicast group, including at least one with information capable.</u><u style="single"> [32] The method of [29], wherein the generating step is performed on an application server and the first and second transmitting steps are performed on a radio access network (RAN).</u><u style="single"> [33] The method of [29], wherein both transmitting steps are performed in a radio access network (RAN).</u><u style="single"> [34] The method of [29], wherein the access control message is contained within the multicast message and both transmitting steps are performed simultaneously.</u><u style="single"> [35] The method of [29], wherein the access control message is transmitted over a downlink control channel.</u><u style="single"> [36] The method according to [28], wherein the generated access control message is addressed to the multicast access terminal identifier (MATI) of the multicast group.</u><u style="single"> [37] The method according to [29], wherein the access control message is transmitted within a Storage BLOB Assignment message.</u><u style="single"> [38] A method of scheduling access terminal responses to interactive multicast messages.</u><u style="single"> Populating a list of target access terminals, wherein the popular list of target access terminals corresponds to a multicast group that is the subject of the interactive multicast message.</u><u style="single"> Selecting less than all of the access terminals in the popularized list of target access terminals means that the selected access terminals are not selected in the popularized list of target access terminals. Choosing to include a given number of access terminals that are expected to respond to the interactive multicast message more than one or more access terminals.</u><u style="single"> Determining the sequence of the selected access terminals and</u><u style="single"> To generate an access control message (ACM) indicating the determined sequence,</u><u style="single"> How to prepare.</u><u style="single"> [39] Sending the ACM to each of the target access terminals in the popularized list, and</u><u style="single"> Receiving feedback from one or more of the target access terminals in the popularized list based on the sequence indicated by the ACM.</u><u style="single"> The method according to [38], further comprising.</u><u style="single"> [40] The method of [38], wherein the ACM is transmitted over a downlink control channel and the ACM is addressed to the Multicast Access Terminal Identifier (MATI) of the multicast group.</u><u style="single"> [41] The populating step is (i) a group member report that requests a given multicast group to be associated with a multicast message received from the target access terminal, or (ii) the group. Populate the list of target access terminals based on the location update report that updates the location of one or more target access terminals sent by the target access terminal after the member report, [38]. The method described.</u><u style="single"> [42] The method of [38], wherein the selected step selects the target access terminal that is likely to respond to the interactive multicast message.</u><u style="single"> [43] The target access terminal, which is likely to respond, (i) requests a given multicast group received from the target access terminal to be associated with a multicast message. Described in [42], based on a group member report, or (ii) a location update report that updates the location of one or more of the target access terminals sent by the target access terminal after the group member report. the method of.</u><u style="single"> [44] The method of [43], wherein the target access terminal that most recently reported (i) or (ii) is selected as the selected target access terminal.</u><u style="single"> [45] The method of [38], wherein the determining step determines the sequence based on the relative expectations of each of the selected target access terminals in response to the interactive multicast message.</u><u style="single"> [46] The sequence is configured to correspond to a target access terminal that is more likely to respond to a target access terminal earlier in the sequence, according to [45]. Method.</u><u style="single"> [47] The generating step generates the ACM so that the sequence is indicated by at least one unicast access terminal identifier (UATI) corresponding to one of the selected target access terminals. , [38].</u><u style="single"> [48] The method of [47], wherein the ACM comprises a plurality of UATIs configured according to the determined sequence, the plurality of UATIs corresponding to the selected target access terminal.</u><u style="single"> [49] The popularized list of target access terminals includes each target access terminal that is the subject of the interactive multicast message within a given sector and a given cluster of sectors. , [38].</u><u style="single"> [50] The method of [38], wherein the ACM commands the unselected target access terminal from the popularized list to perform an APersistence function.</u><u style="single"> [51] The method according to [50], wherein the APersistence function is based on the APersistence value contained in the ACM, or one of the numbers included in the ACM from which the APersistence value can be derived.</u><u style="single"> [52] A means for receiving an interactive multicast message specified for a multicast group containing multiple multicast group members, the interactive multicast message being sent to the plurality of multicast group members. Means for requesting and receiving a response,</u><u style="single"> Means for receiving an access control message (ACM) for the multicast group, wherein the access control message indicates a feedback instruction for the multicast group, and means for receiving.</u><u style="single"> Means for responding to the interactive multicast message based on the feedback instructions to the plurality of access terminals indicated by the access control message.</u><u style="single"> Wireless communication system with.</u><u style="single"> [53] The feedback instruction determines (i) the order of a given plurality of access terminals and (ii) a stochastic response protocol for the multicast group member to respond to the interactive multicast message. The wireless communication system according to [52], wherein the given plurality of access terminals belong to the multicast group, including at least one with information capable.</u><u style="single"> [54] The wireless communication system according to [52], further comprising means for transitioning from the feedback instruction included in the access control message to a previous set of feedback instructions after the response step.</u><u style="single"> [55] The wireless communication system according to [52], wherein the received access control message is received via a downlink control channel.</u><u style="single"> [56] The wireless communication system according to [52], wherein the received access control message is addressed to the multicast access terminal identifier (MATI) of the multicast group.</u><u style="single"> [57] The wireless communication system according to [52], wherein the received access control message is included in a Storage BLOB Assignment message.</u><u style="single"> [58] A means for generating an access control message is provided, the access control message indicates a feedback instruction to a plurality of access terminals belonging to a given multicast group, and the feedback instruction is a feedback instruction by the plurality of access terminals. A wireless communication system that provides a temporary way to respond to interactive multicast messages.</u><u style="single"> [59] A means for transmitting the access control message to the plurality of access terminals, and</u><u style="single"> A means for transmitting an interactive multicast message to the plurality of access terminals, wherein the interactive multicast message is specified for the given multicast group including the plurality of access terminals. Means for sending and</u><u style="single"> The wireless communication system according to [58].</u><u style="single"> [60] The wireless communication system according to [58], wherein the feedback instruction is intended to be followed in order to respond to the interactive multicast message associated with the access control message.</u><u style="single"> [61] The feedback instruction determines (i) the order of a given access terminal and (ii) a stochastic response protocol for the multicast group member to respond to the interactive multicast message. The wireless communication system according to [58], wherein the given plurality of access terminals belong to the multicast group, including at least one with information capable.</u><u style="single"> [62] The wireless communication system according to [58], wherein the generated access control message is addressed to the multicast access terminal identifier (MATI) of the multicast group.</u><u style="single"> [63] The wireless communication system according to [59], wherein the access control message is transmitted within a Storage BLOB Assignment message.</u><u style="single"> [64] A means for populating a list of target access terminals so that the populated list of target access terminals corresponds to a multicast group that is the subject of an interactive multicast message. Means and</u><u style="single"> A means for selecting less than all of the access terminals in the populated list of target access terminals, wherein the selected access terminal is the selection in the popular list of target access terminals. A means for selection, including a given number of access terminals that are expected to respond to the interactive multicast message more than one or more access terminals that were not.</u><u style="single"> Means for determining the sequence of the selected access terminals and</u><u style="single"> Means for generating an access control message (ACM) indicating the determined sequence, and</u><u style="single"> Wireless communication system with.</u><u style="single"> [65] A means for transmitting the ACM to each of the target access terminals in the popularized list, and</u><u style="single"> As a means for receiving feedback from one or more of the target access terminals in the popularized list based on the sequence indicated by the ACM.</u><u style="single">The wireless communication system according to [64].</u><u style="single"> [66] The means for populating is (i) a group member report received from the target access terminal requesting a given multicast group to be associated with a multicast message, or (ii). Populate the list of target access terminals based on a location update report that updates the location of one or more target access terminals sent by the target access terminal after the group member report, [64] ] The wireless communication system described in.</u><u style="single"> [67] A group member report requesting that the means for populating be associated with a multicast message for a given multicast group received from the target access terminal, or (ii) the group. Populate the list of target access terminals based on the location update report that updates the location of one or more target access terminals sent by the target access terminal after the member report, [64]. The wireless communication system described.</u><u style="single"> [68] The means for determining said sequence is determined based on the relative expectations of each of the selected target access terminals responding to the interactive multicast message, [64]. Wireless communication system.</u><u style="single"> [69] The ACM is generated, as indicated by at least one unicast access terminal identifier (UATI) corresponding to one of the selected target access terminals. The wireless communication system described.</u><u style="single"> [70] The popularized list of target access terminals includes each target access terminal that is the subject of the interactive multicast message within a given sector and a given cluster of sectors. , [64].</u><u style="single"> [71] The wireless communication system according to [64], wherein the ACM is configured to instruct the non-selected target access terminal from the popularized list to perform an APersistence function.</u><u style="single"> [72] A computer-readable medium that stores program code.</u><u style="single"> A program code for receiving an interactive multicast message specified for a multicast group containing a plurality of multicast group members, and the interactive multicast message responds to the plurality of multicast group members. The program code to request and receive,</u><u style="single"> A program code for receiving an access control message (ACM) for the multicast group, wherein the access control message indicates a feedback instruction for the multicast group, and a program code for receiving the access control message (ACM).</u><u style="single"> A program code for responding to the interactive multicast message based on the feedback instruction to the plurality of access terminals indicated by the access control message.</u><u style="single"> A computer-readable medium equipped with.</u><u style="single"> [73] The feedback instruction determines (i) the order of a given plurality of access terminals and (ii) a stochastic response protocol for the multicast group member to respond to the interactive multicast message. The computer-readable medium according to [72], wherein the given plurality of access terminals belong to the multicast group, including at least one with information capable.</u><u style="single"> [74] The computer-readable medium of [72], further comprising program code for transitioning from the feedback instruction contained in the access control message to a previous set of feedback instructions after the response step.</u><u style="single"> [75] A computer-readable medium that stores program code.</u><u style="single"> A program code for generating an access control message is provided, the access control message indicates a feedback instruction to a plurality of access terminals belonging to a given multicast group, and the feedback instruction is an interactive operation of the plurality of access terminals. A computer-readable medium that provides a temporary way to respond to multicast messages.</u><u style="single"> [76] A program code for transmitting the access control message to the plurality of access terminals, and</u><u style="single"> Program code for sending an interactive multicast message to the plurality of access terminals, wherein the interactive multicast message is specified for the given multicast group including the plurality of access terminals. , Program code to send, and</u><u style="single"> The computer-readable medium described in [75], further comprising.</u><u style="single"> [77] The access control message determines (i) the order of a given plurality of access terminals and (ii) the stochastic response protocol for the multicast group member to respond to the interactive multicast message. The computer-readable medium according to [76], wherein the given plurality of access terminals belong to the multicast group, including at least one of the information that can be made.</u><u style="single"> [78] The computer-readable medium according to [76], wherein the access control message is addressed to the multicast access terminal identifier (MATI) of the multicast group.</u><u style="single"> [79] The computer-readable medium according to [76], wherein the access control message is transmitted within a StorageBLOB Assignment message.</u><u style="single"> [80] A computer-readable medium that stores program code.</u><u style="single"> A program code for populating a list of target access terminals, wherein the populated list of target access terminals corresponds to a multicast group that is the subject of an interactive multicast message. Code and</u><u style="single"> Program code for selecting less than all of the access terminals in the populated list of target access terminals, wherein the selected access terminals are said in the populated list of target access terminals. Program code for selection, including a given number of access terminals that are expected to respond to the interactive multicast message more than one or more access terminals that were not selected.</u><u style="single"> The program code for determining the sequence of the selected access terminal and</u><u style="single"> The program code for generating an access control message (ACM) indicating the determined sequence, and</u><u style="single"> A computer-readable medium equipped with.</u>
12 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| EP01770903A1 | Cites | European Patent Office (EPO) |
| EP01624610A1 | Cites | European Patent Office (EPO) |
37 members in 9 offices
Priority claims19
| Document | Office | Kind | Date |
|---|---|---|---|
| 60974796 | United States of America | – | |
| 60974831 | United States of America | – | |
| 97479607 | United States of America | P | |
| 97479607 | United States of America | P | |
| 97483107 | United States of America | P | |
| 97483107 | United States of America | P | |
| 12212390 | United States of America | – | |
| 21239008 | United States of America | A | |
| 21239008 | United States of America | A | |
| 2008076990 | United States of America | W | |
| 2008076990 | United States of America | W | |
| 2007974796 | – | – | – |
| 2007974831 | – | – | – |
| 2008212390 | – | – | – |
| 2008076990 | – | – | – |
| US20070974796P | – | – | – |
| US20070974831P | – | – | – |
| US20080212390 | – | – | – |
| WO2008US76990 | – | – | – |
Members37
| Document | Office | Kind | |
|---|---|---|---|
| US2009080355A1 | United States of America | A1 | |
| US2009080356A1 | United States of America | A1 | |
| CA2699340A1 | Canada | A1 | |
| WO2009042513A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2009042518A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2009042513A3 | World Intellectual Property Organization (WIPO) | A3 | |
| WO2009042518A3 | World Intellectual Property Organization (WIPO) | A3 | |
| KR20100057914A | Republic of Korea | A | |
| KR20100072301A | Republic of Korea | A | |
| EP2204009A2 | European Patent Office (EPO) | A2 | |
| EP2206288A2 | European Patent Office (EPO) | A2 | |
| CN101803277A | China | A | |
| CN101809932A | China | A | |
| JP2010541389A | Japan | A | |
| JP2010541392A | Japan | A | |
| RU2010116277A | Russian Federation | A | |
| KR101082664B1 | Republic of Korea | B1 | |
| EP2206288B1 | European Patent Office (EPO) | B1 | |
| KR101155168B1 | Republic of Korea | B1 | |
| EP2472777A1 | European Patent Office (EPO) | A1 | |
| RU2466504C2 | Russian Federation | C2 | |
| CN102833687A | China | A | |
| JP2013013117A | Japan | A | |
| JP5134086B2 | Japan | B2 | |
| CN103002403A | China | A | |
| RU2011140526A | Russian Federation | A | |
| EP2634963A1 | European Patent Office (EPO) | A1 | |
| JP5301550B2This record | Japan | B2 | |
| EP2472777B1 | European Patent Office (EPO) | B1 | |
| US8625475B2 | United States of America | B2 | |
| US2014050088A1 | United States of America | A1 | |
| US2014050142A1 | United States of America | A1 | |
| JP5670395B2 | Japan | B2 | |
| BRPI0817950A2 | Brazil | A2 | |
| US9185593B2 | United States of America | B2 | |
| US9294955B2 | United States of America | B2 | |
| CN103002403B | China | B |
16 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Transfer to examiner for re-examination before appeal (zenchi)AppealJAPANESE INTERMEDIATE CODE: A911A911 | A911 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Decision of refusalJAPANESE INTERMEDIATE CODE: A02A02 | A02 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 |
Numbers
- Publication
- 5301550
- Publication, DOCDB
- 5301550
- Publication, EPODOC
- JP5301550B
- Application
- 2010527050
- Application, DOCDB
- 2010527050
- Application, EPODOC
- JP20100527050
Titles2
- Japanese
- ワイヤレス通信システム内での対話型マルチキャスト・メッセージへの応答
- English
- Responding to interactive multicast messages within a wireless communication system
Classification
- CPC, 14
- H04W28/02
- H04L12/189
- H04L47/32
- H04L47/323
- H04L12/1872
- H04W76/40
- H04L47/15
- H04W4/06
- H04W4/10
- H04W72/30
- H04W60/00
- H04L47/10
- H04L47/12
- H04W8/04
- IPC, 4
- H04W4 06
- H04W68 00
- H04W4 08
- H04L47 32
