Tracking locations of multicast group members within a wireless communication system

TRACKING LOCATIONS OF MULTICAST GROUP MEMBERS WITHIN A WIRELESS COMMUNICATION SYSTEM

This patent application is a provisional application number filed on September 24, 2007 under the title "METHODS OF TRACKING LOCATIONS OF MULTICAST GROUP MEMBERS WITHIN A WIRELESS COMMUNICATION SYSTEM," which is assigned to the present applicant and is hereby intentionally incorporated by reference in its entirety. 60/974,830 claims priority.

The present invention relates to a wireless communication system, and more particularly, to methods of tracking the locations of multicast group members within a wireless communication system.

Wireless communication systems provide first-generation analog radiotelephone service (1G), second-generation (2G) digital radiotelephone service (including intermediate 2.5G and 2.75G networks), and third-generation (3G) high-speed data/Internet enabled radio service. It has been developed over a number of generations, including Many different types of wireless communication systems are currently in use, including cellular and personal communication service (PCS) systems. Examples of known cellular systems include code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), the Global System for Mobile Access (GSM) variant of TDMA, and more using TDMA and CDMA techniques. digital cellular systems based on new hybrid digital communication systems, and Cellular Analog Advanced Mobile Phone System (AMPS).

A method for providing CDMA mobile communications is described in Telecommunications in TIA/EIA/IS-95-A entitled "Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System", which is referenced herein as IS-95. Standardized in the United States by the Industry Association/Electronic Industries Association. Combined AMPS & CDMA systems are presented in the TIA/EIA standard IS-98. Other communication systems are IMT-2000/UM or International Mobile Telecommunications System 2000/Universal Mobile Telecommunications, covering what is referred to as Wideband CDMA (WCDMA), CDMA2000 (such as the CDMA2000 1xEV-DO standards for example) or TD-SCDMA. It is presented in System standards.

In wireless communication systems, mobile stations, handsets, or access terminals (AT) are fixed location base stations ( or from cell sites or cells). Base stations are commonly referred to as an Access Network (AN)/Radio Access Network (AN), which is a packet data network that uses standard Internet Engineering Task Force (IETF) based protocols that support methods for identifying traffic based on quality of service (QoS) requirements. RAN) to provide entry points. Thus, base stations typically interact with ATs over an over the air interface and with ANs over Internet Protocol (IP) network data packets.

In wireless communication systems, push-to-talk (PTT) capabilities are becoming increasingly prevalent in service sectors and consumers. PTT may support "dispatch" voice service operating over standard commercial wireless infrastructures such as CDMA, FDMA, TDMA, GSM, and the like. In the dispatch model, communication between endpoints (ATs) occurs within virtual groups, and the voice of one "talker" is transmitted to one or more "listeners". An example of this type of communication is commonly referred to as a dispatch call, or simply a PTT call. A PTT call is an instantiation group that defines the characteristics of a call. A group is essentially defined by a list of members and associated information such as a group name or group identification.

Conventionally, data packets within a wireless communication network have been configured to be transmitted to a single destination or access terminal. The transmission of data to a single recipient is referred to as "unicast". As mobile communications increase, the ability to simultaneously transmit given data to multiple access terminals has become more important. Accordingly, protocols have been adopted to support simultaneous data transmissions of the same packet or message to multiple recipients or target access terminals. "Broadcast" refers to the transmission of data packets to all recipients or access terminals (eg, within a given cell served by a given service provider, etc.), whereas "multicast" )" refers to the transmission of data packets to a given group of recipients or access terminals. As an example, a given group of recipients or "multicast group" may include one or more and less than all of all possible recipients or access terminals (eg, by a given service provider). within a given group served, etc.). However, at least in certain circumstances, a multicast group may include only one access terminal, similar to unicast, or alternatively, a multicast group may include all access terminals, similar to broadcast (eg, within a given cell). , etc.) may be possible.

Broadcasts and/or multicasts perform multiple sequential unicast operations to accommodate a multicast group, allocate a unique broadcast/multicast channel (BCH) to simultaneously handle multiple data transmissions, etc. The same may be performed within wireless communication systems in a number of ways. A conventional system using a broadcast channel for push-to-talk communications is disclosed in U.S. Patent Application Publication No. March 1, 2007, entitled "Push-To-Talk Group Call System Using CDMA 1x-EVDO Cellular Network." 2007/0049314, the contents of which are incorporated herein by reference in their entirety. As presented in Publication No. 2007/0049314, a broadcast channel can be used for push-to-talk calls using conventional signaling techniques. Although the use of a broadcast channel may improve bandwidth requirements over conventional unicast techniques, conventional signaling of a broadcast channel may still incur additional overhead and/or delay and may result in system performance may be degraded.

3rd Generation Partnership Project 2 ("3GPP2") defines a Broadcast-Multicast Service (BCMCS) specification for supporting multicast communications in CDMA2000 networks. Accordingly, the version of the BCMCS specification of 3GPP2 entitled "CDMA2000 High Rate Broadcast-Multicast Packet Data Air Interface Specification" dated February 14, 2006, Version 1.0 C.S0054-A, is hereby incorporated by reference in its entirety.

Embodiments of the present invention relate to systems and methods for tracking the locations of multicast group members within a wireless communication system. The access terminal sends a group member report to the access network, and ? The group member report indicates the location of at least one multicast group and the access terminal, and the group member report is sent before a multicast session associated with the multicast group is initiated ?, determines the location update rule, and ? The location update rule is a manner of reporting location updates of the access terminal to the access network?, and reports location updates of the access terminal to the access network based on the determined location update rule. The access network receives a group member report and one or more sequential location update reports from the access terminal. The access network includes a list of access terminals, at least one multicast group associated with each of the listed access terminals, a location associated with each of the listed access terminals, and an indication to the access network when each location was last reported. Forms a group member list containing a time-stamp. The access network updates the group member list based on location update reports and/or supplemental group member reports sent from one or more access terminals.

A more complete understanding of embodiments of the present invention and its attendant advantages will be clearly attained as better understood by reference to the following detailed description when considered in conjunction with the accompanying drawings, in which the accompanying drawings It is not intended to be limiting of the invention and is presented for purposes of illustration only. 1 is a diagram of a wireless network architecture supporting access terminals and access networks in accordance with at least one embodiment of the present invention. 2 shows a carrier network according to an embodiment of the present invention. 3 is a diagram of an access terminal in accordance with at least one embodiment of the present invention; 4 shows a conventional multicast messaging process using the Broadcast Multicast Service (BCMCS) framework. 5 shows a conventional cycle of a downlink control channel. 6 illustrates a process for group membership reporting and location update in accordance with an embodiment of the present invention. 7 illustrates a multicast messaging process according to an embodiment of the present invention. 8 illustrates a wireless communication system according to an embodiment of the present invention.

Aspects of the present invention are set forth in the accompanying drawings and the description below relating to specific embodiments of the present invention. Alternative embodiments may be devised without departing from the scope of the present invention. Additionally, well-known elements of the present invention will be omitted so as not to be described in detail or to obscure the relevant details of the present invention.

The terms "exemplary" and/or "example" are used herein to mean "serving as an example, instance, or illustration." Any embodiment described herein as "exemplary" and/or "example" is not necessarily to be construed as preferred or advantageous over other embodiments. Likewise, the term "embodiments of the invention" does not require that all embodiments of the invention include the discussed feature, advantage, or mode of operation.

Additionally, many embodiments are described, for example, in terms of sequences of actions performed by elements of a computing device. It is recognized that the various operations described herein may be performed by specific circuits (eg, application specific integrated circuits (ASICs)), program instructions executed by one or more processors, or a combination of the two. something to do. Additionally, such sequences of operations described herein may be entirely embodied in any form of computer-readable storage medium having stored thereon a set of corresponding computer instructions that, when executed, cause an associated processor to perform the functions described herein. can be considered to be Accordingly, the various aspects of the invention may be embodied in many different forms, all of which are contemplated to be within the scope of claimed subject matter. Also, in each of the embodiments described herein, any such embodiments of a corresponding form may be described herein as, for example, "logic configured" to perform the described operation.

A high data rate (HDR) subscriber station, referred to herein as an access terminal (AT), may be mobile or stationary, one referred to herein as modem pool transceivers (MPTs) or base stations (BS). It can communicate with more than one HDR base station. The access terminal transmits and receives data packets via one or more modem pool transceivers to an HDR base station controller, referred to as a modem pool controller (MPC), base station controller (BSC), and/or packet control function (PCF). Modem pool transceivers and modem pool controllers are parts of a network called an access network. An access network conveys data packets between multiple access terminals.

The access network may additionally be connected to additional networks outside the access network, such as a corporate intranet or the Internet, and may pass data packets between each access terminal and those external networks. An access terminal that has established an active traffic channel connection with one or more modem pool transceivers is referred to as an active access terminal and is said to be in a traffic state. An access terminal in the process of establishing an active traffic channel connection with one or more modem pool transceivers is referred to as a connection setup state. An access terminal may be any data device that communicates over a wireless channel or a wired channel using, for example, fiber optic or coaxial cables. An access terminal may be any of a number of types of devices including, but not limited to, a PC card, a compact flash, an external or internal modem, or a wireless or wireline telephone. The communication link through which the access terminal sends signals to the modem pool transceiver is referred to as the reverse link or traffic channel. The communication link through which the modem pool transceiver transmits signals to the access terminal is referred to as a forward link or traffic channel. The term traffic channel as used herein may refer to a forward or reverse traffic channel.

1 shows a block diagram of one exemplary embodiment of a wireless system 100 in accordance with at least one embodiment of the present invention. System 100 is a network that provides data connectivity between a packet switched data network (eg, intranet, Internet, and/or carrier network 126 ) and access terminals 102 , 108 , 110 , 112 . may include access terminals such as cellular telephone 102 that communicate via an air interface 104 with an access network or radio access network (RAN) 120 capable of connecting the access terminal 102 to equipment. have. As shown in the figure, the access terminal is a cellular phone 102 , a personal digital assistant 108 , a pager 110 shown in the figure as an interactive text pager, or even a separate computer platform 112 having a wireless communication portal. ) may be Embodiments of the present invention may have wireless communication capabilities including, without limitation, wireless modems, PCMCIA cards, personal computers, telephones, or any combination or sub-combination thereof, or wireless communication portals. It can be implemented in any type of access terminal including Additionally, as used herein, the terms "access terminal," "wireless device," "client device," "mobile terminal," and variations thereof, may be used interchangeably.

Referring again to FIG. 1 , the correlation of the components of the wireless network 100 and the components of the exemplary embodiments of the present invention is not limited to the illustrated configuration. System 100 is exemplary only, and remote access terminals, such as wireless client computing devices 102 , 108 , 110 , 112 , communicate with each other and over-the-air. and/or any system that enables wireless communication between and between components connected via the air interface 104 and the RAN 120, including without limitation the carrier network 126; Internet and/or other remote servers.

The RAN 120 controls messages (typically sent as data packets) that are sent to a base station controller/packet control function (BSC/PCF) 122 . BSC/PCF 122 provides signaling of bearer channels (ie, data channels) between packet data service node 100 ("PDSN") and access terminals 102 , 108 , 110 , 112 , Responsible for setting, and tearing down. When link layer encryption is enabled, the BSC/PCF 122 also encrypts the content prior to delivering it over the air interface 104 . The functionality of the BSC/PCF 122 is known in the art and will not be discussed further for the sake of brevity. The carrier network 126 may communicate with the BSC/PCF 122 by a network, the Internet, and/or a public switched telephone network (PSTN). Alternatively, the BSC/PCF 122 may connect directly to the Internet or an external network. Typically, the Internet connection or network between the carrier network 126 and the BSC/PCF 122 carries data and the PSTN carries voice information. BSC/PCF 122 may be connected to multiple base stations (BS) or modem pool transceivers (MPT) 124 . In a manner similar to a carrier network, the BSC/PCF 122 is typically connected to the MPT/BS 124 by the network, the Internet and/or the PSTN for data transfer and/or voice information. MPT/BS 124 may broadcast data messages over the air to access terminals, such as cellular phone 102 . MPT/BS 124 , BSC/PCF 122 and other components may form RAN 120 , as is known in the art. However, alternative configurations may be used, and the invention is not limited to the illustrated configuration. For example, in another embodiment, the functionality of one or more MPT/BS 124 and BSC/PCF 122 is combined in a single "hybrid" module with the functionality of both BSC/PCF 122 and MPT/BS 124 . It can be collapsed in

2 illustrates a carrier network 126 in accordance with an embodiment of the present invention. In the embodiment of FIG. 2 , the 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, the application server 170 and other components may be located outside the carrier network in alternative embodiments. PDSN 160 is, for example, mobile stations (eg, access terminals 102 , 108 , 110 , 112 in FIG. 1 ) using a cdma2000 radio access network (RAN) (eg, RAN 120 in FIG. 1 ). For this purpose, it provides access to the Internet 175 , intranets, and/or remote servers (eg, application server 170 ). When acting as an access gateway, PDSN 160 can provide simple IP and mobile IP access, foreign agent support, and packet forwarding. PDSN 160 may act as a client for Authentication, Authorization, and Accounting (AAA) servers and other supporting infrastructure, and as is known in the prior art to an IP network. A gateway is provided to mobile stations. As shown in FIG. 2 , the PDSN 160 may communicate with the RAN 120 (eg, BSC/PCF 122 ) via a conventional A10 connection. The A10 connection is known in the prior art and will not be described further for the sake of brevity.

Referring to FIG. 2 , a broadcast serving node (BSN) 165 may be configured to support multicast and broadcast services. BSN 165 will be described in more detail below. BSN 165 communicates with RAN 120 (eg, BSC/PCF 122 ) via a broadcast (BC)A10 connection, and with application server 170 via Internet 175 . BCA10 connections are used to carry multicast and/or broadcast messaging. Accordingly, application server 170 sends unicast messaging to PDSN 160 via Internet 175 and multicast messaging to BSN 165 via Internet 175 .

Generally, as described in more detail below, the RAN 120 transmits multicast messages received from the BSN 165 via a BCA10 connection to one or more access terminals via a broadcast channel (BCH) of the air interface 104 . send to (200).

Referring to FIG. 3 , an access terminal 200 (here, a wireless device), such as a cellular phone, has a platform 202 capable of receiving and executing software applications, data and/or instructions transmitted from a RAN 120 , , software applications, data and/or instructions may ultimately arrive from the carrier network 126 , the Internet, and/or other remote servers and networks. The platform 202 may include an application specific integrated circuit ("ASIC" 208), or a transceiver 206 that is operatively coupled to another processor, microprocessor, logic circuit, or other data processing device. The ASIC 208 or other processor executes an application programming interface ("API") 210 layer that interfaces with any resident programs in the memory 212 of the wireless device. Memory 212 may be comprised of read-only or random-access memory (RAM and ROM), EEPROM, flash cards, or any memory common to computer platforms. Platform 202 may also include a local database 214 that may hold applications that are not actively used in memory 212 . Local database 214 is typically a flash memory cell, but may be any secondary storage device known in the art, such as magnetic media, EEPROM, optical media, tape, soft or hard disk, and the like. Internal platform 202 components are also connected 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. It can be connected and operated.

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 one of ordinary skill in the art, the various logic elements may be embodied in separate elements, software modules executing on a processor, or any combination of software and hardware to achieve the functionality presented herein. For example, ASIC 208, memory 212, API 210, and local database 214 may all be used cooperatively to load, store, and execute the various functions presented herein; Accordingly, logic for performing these functions may be distributed across various elements. Alternatively, the functionality may be contained within one separate component. Accordingly, the features of the access terminal of FIG. 3 are to be considered as exemplary only, and the present invention is not limited to the illustrated features or arrangement.

The wireless communication between the access terminal 102 and the RAN 120 is code division multiple access (CDMA), WCDMA, time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal frequency division multiplexing (OFDM), global for mobile communication. It may be based on different technologies, such as system (GSM), or other protocols that may be used in a wireless communication network or data communication network. Data communication typically occurs between client device 102 , MPT/BS 124 , and BSC/PCF 122 . BSC/PCF 122 may be connected to multiple data networks, such as carrier network 126, PSTN, Internet, virtual private network, etc., so that access terminal 102 can access a wider area communication network. do. As discussed above and known in the prior art, voice transmission and/or data may be transmitted from the RAN to the access terminals using various networks and configurations. Accordingly, the examples provided herein are not intended to limit the embodiments of the present invention, but merely to aid in the description of aspects of the embodiments of the present invention.

As discussed in the background section, multicast messaging can be performed in a number of ways. In order to better understand the embodiments of the present invention, a conventional multicast messaging process will be described with reference to Figs. 4 and 5, respectively. Next, a multicast messaging process in which a set of prospective sectors, possibly including one or more multicast members, is established prior to initiation of a multicast session will be described in accordance with an embodiment of the present invention.

4 shows a conventional multicast messaging process using the Broadcast Multicast Server (BCMCS) framework. The multicast messaging process of FIG. 4 is described below as performed within the wireless system 100 of FIGS. 1 and 2 . Referring to FIG. 4 , at 400 , application server 170 (or other initiator) requests a multicast message to be transmitted to a multicast group comprising ATs (eg, A, B and C). . Multicast messages from 400 are routed to BSN 165 . At 405 , the BSN 165 forwards the multicast message to the RAN 120 over the BCA10 connection. For example, a multicast message is first delivered to the BSC/PCF 122, which analyzes the multicast group members for the multicast message and each MPT serving one or more multicast group members. /Delivers a multicast message to BS 124.

After receiving the forwarded multicast message, the RAN 120 waits at 410 for the next available control channel capsule. The control channel referred to herein is assigned a different frequency, coding and/or bandwidth than the broadcast channel (BCH). In general, less bandwidth is allocated to a control channel that is typically intended to contain only control messaging, while more bandwidth is allocated to a broadcast channel (BCH), which is typically intended to contain data.

Referring to FIG. 5 , each control channel cycle includes a total of 256 slots. Each control channel cycle includes a synchronous control channel capsule (SC), an asynchronous control channel capsule (AC), and a number of sub-synchronous control channels (SSCs). One SC is transmitted regularly or periodically in a given timeslot during each control channel cycle with a period of 256 slots, whereas AC is transmitted "randomly" or within a control channel cycle. Transmitted in asynchronous timeslots. SC is transmitted in a timeslot corresponding to "T mod 256=Offset" and then retransmitted in a timeslot corresponding to "T mod 4=Offset", where T refers to the system time, and Offset is from a fixed time Refers to the delayed time value, which is included in the control channel header. Each SC may contain multiple control channel MAC layer packets, while each AC contains only one control channel MAC layer packet. As each MPT/BS 124 periodically transmits one or more control channel MAC layer packets, interference (eg, inter-cell interference) may occur when each MPT/BS 124 transmits simultaneously. Thus, a different offset is applied to the SC for each MPT/BS 124 to avoid collisions. The MPT/BS may transmit a number of SSC capsules equal to three within one control channel period or 256 slot cycle. Each SSC typically transmits only one control channel MAC layer packet. Assuming an offset value of 2, SSCs are transmitted in time slots 66 , 130 , 194 . Control channel capsules (eg, SCs, ACs, SSCs, etc.) are generally known in the art within BCMCS systems, and thus further description thereof has been omitted for the sake of brevity.

Referring back to FIG. 4 , the RAN 120 is a synchronous control channel capsule (SC) (eg, timeslot 2 of the next control channel cycle assuming an offset of 2) or, alternatively, a sub-synchronous control channel capsule (SSC). ) (eg, one of timeslots 66, 130, 194 of the control channel cycle assuming an offset of 2), where a periodic BOM message is scheduled. For example, one specific control channel capsule within each control channel cycle can be used for a specific BOM because different applications may attempt to access the control channel and other messages may be scheduled resulting in a delay of multiple cycles. may be reserved.

At 415 , after waiting for the next available SC or SSC, since the locations of the multicast group members during the multicast session are not precisely known to the RAN 120 , the RAN 120 Sends a broadcast overhead message (BOM) to one or more multicast group members (eg, ATs A, B, C) over the air interface across sectors. The BOM is a forward link control message defined by the EV-DO standards. The BOM is used to notify each multicast group member of the currently delivered BCMCS flows in the sector. The BOM also contains information about the physical layer rate used to transmit the flow and the number of physical layer slots per broadcast physical layer packet, and information about the forward link physical layer that must be decoded to receive the desired packet flows. Provides raced multiplexing pair (IM-Pair) information. At 420 , the RAN 120 waits for a predetermined number of slots (eg, 8-16 slots) for the BOM to be decoded at the target ATs. After the delay 420, the RAN 120 waits for the BCH slot designated by the decoded BOM (425). This creates another delay that can be further exacerbated based on the traffic on the broadcast channel (BCH). At 430, the RAN 120 sends an announce message to each multicast group member or target AT serving over a broadcast channel (BCH) on the designated BCH slot of all possible sectors. Then, at 435 , each of ATs A, B and C wishing to monitor the multicast session responds to the RAN 120 via a BCMCSFlowRegistration message, as defined by the 1×EV-DO standards.

As described above with respect to Figure 4, conventional BCMCS multicast messaging typically involves each target AT or multicast group before a multicast message is sent to each member of the multicast group over a broadcast channel (BCH). Requires a member to decode a broadcast overhead message (BOM). This creates delays for scheduling the BOM, delays for decoding, and potential subsequent delays for scheduling the announcement message. Also, BOMs and announcement messages are transmitted in all possible sectors within the wireless communication system 100 . It will be appreciated, however, that multicast group members need not necessarily be present within each sector. Thus, a certain number of transmissions are wasted each time a multicast session is initiated.

Embodiments of the present invention will be described below, in which access terminals "pre-register" with the RAN 120 for future multicast sessions. Thereafter, the access terminals periodically update their location and/or their group membership information so that upon initiation of a given multicast session, the RAN 120 determines where multicast group members are located during the given multicast session. have at least some knowledge about it. Accordingly, the RAN 120 may reduce the number of transmissions required to establish and/or maintain a given multicast session.

6 illustrates a process for group membership reporting and location update in accordance with an embodiment of the present invention. 6, at 600, a given AT wishing to belong to one or more multicast groups is powered on. After the given AT is powered up, the given AT sends a Group Membership Notification (GMN) message to the RAN 120 at 605 (eg, a pilot signal transmitted by one or more base stations in the RAN 120 ). locating, and/or after performing any other initial power-up procedures). The GMN message contains a list of multicast groups for which a given AT is a current or prospective multicast group member.

In one example, the GMN message may be included in a standard BCMCSFlowRegistration message. The BCMCSFlowRegistration message is known in the prior art and is defined within the 1xEV-DO standards. Typically, after the AT receives a BOM with a set of registers to prompt for a BCMCSFlowRegistration message (eg, a Register for Dynamic Broadcast (RFDB) field or a Register for Paging (RFP) field equal to 1) Send BCMCSFlowRegistration message. The BCMCSFlowRegistration message contains a list of BCMCSFlowIDs that the AT wants to monitor. BCMCSFlowIDs may be dynamically assigned (eg, by a BCMCS controller (not shown)) or pre-configured. If the BCMCSFlowIDs are dynamically allocated by the BCMCS controller, the AT may obtain the BCMCSFlowIDs through the BCMCS flow discovery process before sending the BCMCSFlowRegistration message. On the other hand, in another embodiment of the present invention, BCMCSFlowIDs of a specific block may be pre-configured and reserved regardless of whether a multicast session is actually active. In this example, each "reserved" BCMCSFlowID may be mapped to a respective IP group ID (ie, a multicast IP address and port number pair). In one example, the mapping of "reserved" BCMCSFlowIDs is assigned to Applicants and is "METHODS OF GENERATING MULTICAST FLOW IDENTIFIERS" (Attorney docket number), filed September 24, 2007, which is hereby intentionally incorporated by reference in its entirety. 071365P1), pre-configured at each multicast group member and at RAN 120 and/or BSN 165, as discussed in greater detail in US Provisional Application Serial No. 60/974,827. Thus, in this example, the BCMCSFlowIDs included in the GMN message of 605 may correspond to one or more "reserved" BCMCSFlowIDs.

In an alternative example, the GMN message may be included in a proprietary or non-standard message, such as, for example, in a StorageBLOBNotification message on the uplink. In this example, the GMN message may include a list of BCMCSFlowIDs. Alternatively, the GMN message may include a list of multicast IP addresses and port numbers for the requested multicast sessions.

Although 600 and 605 in FIG. 6 relate to AT "power-up", in an alternative embodiment, a supplemental GMN message indicates that a given AT is to be handed off (eg, handed off to a new base station, new subnet, etc.). may be transmitted to the RAN 120 each time.

The RAN 120 receives the GMN message (605) and populates the group member list (610). Each group member list entry includes (i) a list of ATs that sent GMN messages to the RAN 120 ("AT List Field"), and (ii) an associated multicast for each AT within the group member list. Groups ("Multicast Group Field") (eg, stored as a BCMCS Flow ID entry when BCMCSFlowID is reported at 605 , and multicast IP address and port when proprietary message is reported at 605 ) stored as a pair of numbers, etc.), (iii) the last-known location for each AT ("Location Field") (eg indicating sector identification, base station identity, etc.) and (iv) AT contains a time-stamp ("Time-Stamp Field") indicating the time at which the last-known location of ' was reported. An example of a group member list entry is provided as Table 1 below.

<tables num="1"><img file="KR101166301B1_D0001.tif" /></tables>

Thus, as shown in the example of Table 1, a given AT is labeled as "AT 1", and the given AT is a member of the multicast groups T_Flow, U_Flow and V_Flow. The last-known location of a given AT is within sector Y of the wireless communication system 100, and the last-known location was reported at 7:06 PM Eastern Standard Time (EST).

In another example, group member list entries may be grouped based on a multicast group field, as provided as Table 2 below.

<tables num="2"><img file="KR101166301B1_D0002.tif" /></tables>

Accordingly, as shown in the example of Table 2, ATs 1 to 4 are registered in the multicast group T_Flow. The location field and time-stamp field are not included in Table 2 for convenience of illustration, as these fields are specific to each of ATs 1-4.

It will be appreciated that the group member list entries provided above are given for illustrative purposes only and that other embodiments of the present invention may construct group member list entries in any known manner. For example, the location field may alternatively store a base station identifier and may not store a sector identifier. As another example, the location field may include a location area (LA) identifier where each location area (LA) corresponds to a subnet or portion of a PCF area (eg, as defined by RAN 120 ), or a location area (LA) identifier where each MA is An identifier identifying multiple sectors may be stored, such as a multicast area (MA) identifier corresponding to a portion of a subnet or PCF area identified by RAN 120 for multicasting purposes only.

At 615 , after updating the group member list based on the GMN message of 610 , the RAN 120 determines whether to periodically set a location update rule or protocol for the AT. The location update rule corresponds to the manner in which the AT schedules the transmission of RouteUpdate messages to the RAN 120 . The RouteUpdate message updates the location field and time-stamp field (see above) for a specific AT. In general, if the RAN 120 wishes to maintain a closer tracking of the locations of multicast group members for a particular multicast group, the RAN 120 may set a relatively aggressive location update rule at 615 . have. Otherwise, if the RAN 120 desires to reduce the reverse link traffic, the RAN 120 may set a relatively conservative location update rule at 615 . In another alternative example, the RAN 120 may not set location update rules, and may rely on default or manually entered location update rules at a given AT. Examples of location update rules are provided below.

At 620, the given AT establishes a location update rule. For example, if the RAN 120 determines not to dynamically set the location update rule at 615 , a default location update rule may be set at 620 . Alternatively, if the RAN 120 determines to dynamically set the location update rule at 615 , the dynamically set location update rule is operated at 620 . In another alternative example, the user of a given AT may manually select and enter custom location update rules.

In one example, the location update rule is a distance-for causing a given AT to send a RouteUpdate message after traversing a given distance (eg, based on the sector(s) the given AT has traversed, etc.) It may be a registration-based (DBR) protocol. The given distance may be based on the base stations to which the given AT was handed off, the base stations to which the given AT was monitored during an idle state, and the like. Changes in location update rules in the distance-based registration protocol may be communicated to the AT via Generic Attribute Update Protocol (GAUP) in the EV-DO system. In another example, a location update rule may send a RouteUpdate message whenever a given AT enters a new location area (LA), where each LA is a PCF zone or part of a subnet (eg, by RAN 120 ). as defined).

In another example, the location update rule may correspond to any of a number of possible location update strategies. For example, a location update rule may be timer-based, where a given AT maintains a timer with a predetermined or on-demand period and sends a RouteUpdate message once during each timer period. In this example, fewer timer periods correspond to a more aggressive location update rule for maintaining more up-to-date location entries for the group member list. However, fewer timer periods are also associated with higher traffic levels on the reverse link.

After setting the location update rule at 620 , the given AT resumes normal operation ( 625 ). In 630, the given AT determines whether to update its own location information with a RouteUpdate message based on the set location update rule (620). If the location update rule requires a RouteUpdate message, a RouteUpdate message is sent to the RAN 120 (635). At 640 , the RAN 120 updates the group member list parameters based on the RouteUpdate message. For example, the RAN 120 updates the location field and the time-stamp field of the group member list for a given AT based on the RouteUpdate message. Otherwise, if the location update rule indicates that a RouteUpdate message does not need to be sent, the process proceeds to 645 .

At 645 , the given AT determines whether to update its group membership information with an additional GMN message. For example, if a given AT wants to join a new multicast group, the given AT contains an additional GMN message (ie, a multicast IP address and port number pair for the new multicast group and/or BCMCSFlowID) ) can be determined to be transmitted. In another example, if a given AT wishes to revoke its membership to a multicast group it has already registered, the given AT sends an additional GMN message (ie, a multicast IP address and port number pair for the revoked multicast group and/or or omitting BCMCSFlowID). In one example, each additional GMN message replaces any previously transmitted GMN message. If the given AT determines that it does not update its group membership information, the process returns to 625 and the given AT resumes normal operation. Otherwise, if the given AT decides to update its group membership information, the given AT sends an additional GMN message at 650 .

At 655 , the RAN 120 updates the group member list parameters based on the additional GMN message. If an additional GMN message requests different multicast groups than a previously transmitted GMN message, the Multicast Group field, which maintains a list of multicast groups to which a given AT belongs, is updated to add the multicast groups listed in the additional GMN message. do. Alternatively, if group removal is indicated in the GMN message, the Multicast Group field is updated to remove the multicast groups listed in the additional GMN message. As will be appreciated, this may require removal of previously listed multicast groups, addition of new multicast groups, and/or both removal and addition of specific multicast groups in the Associated Multicast Group field for a given AT. Additionally, the RAN 120 updates the location field and time-stamp field of the group member list for a given AT sending additional GMN messages.

In another example, if the additional GMN message does not include the multicast groups listed, the additional GMN message is interpreted as a request to completely drop or cancel the given AT from the group member list. Accordingly, if the additional GMN message does not contain multicast groups, the RAN 120 removes each of the AT list field, the multicast group field, the location field, and the time-stamp field for a given AT.

As will be appreciated in view of the foregoing description of Figure 6, at any given time, the group member list may contain information about where multicast group members are "potentially" located before an active multicast session for the multicast group is actually initiated. Include information ("potentially" because the group member list may not need to be completely accurate).

Additionally, although not explicitly shown in FIG. 6 , the RAN 120 does not respond to its own initiative (ie, GMN messages and/or RouteUpdate messages received from one or more ATs). ) to periodically update the group member list. For example, if the location field for a particular AT becomes "stale" or exceeds an age threshold, the RAN 120 may interpret the stale location field as out of date, and the associated The AT can be completely removed from the group member list.

7 illustrates a multicast messaging process according to an embodiment of the present invention. 7 , it is assumed that the group member list maintained by the RAN 120 includes multiple ATs that have been registered for the multicast group T_Flow. Thus, as an example, the group member list for ATs that have been registered for T_Flow may include entries in Table 3 below.

<tables num="3"><img file="KR101166301B1_D0003.tif" /></tables>

Referring to FIG. 7 , at 700 , application server 170 issues a request to initiate a multicast flow for a given multicast group. For example purposes, it is assumed that a multicast flow corresponds to T_Flow, as in the multicast group field for each of ATs A to G in Table 3 above. For example, the multicast flow T_Flow generated in 700 of FIG. 7 may respond to a request of a given access terminal to speak to a given multicast group (not shown). After the application server 170 decides to accept the AT's request, the server 170 may generate a multicast flow announcement message that is sent to group members via IP multicasting. The application server 170 forwards the multicast flow to the BSN 165 at 700 , and at 705 , the BSN 165 forwards the multicast messages of the BCMCS flow over the air interface 104 in one or more sectors to a multicast group. It delivers the BCMCS flow through the BCA10 connection to the RAN 120 responsible for transmitting to the members.

At 710 of FIG. 7 , the RAN 120 determines an initial set of target sectors for an initial "cluster". A target sector, as used herein, is any sector within a wireless communication system that has or "potentially" has at least one multicast group member. A "cluster," as used herein, corresponds to a set of sectors (eg, one or more sectors) through which the BCH carries the BCMCS flow for a particular multicast group. As described in more detail below, a cluster includes both target sectors and support sectors for a particular multicast group or BCMCS flow.

Referring to 710 of FIG. 7 , the RAN 120 determines an initial set of target sectors based on a group member list (eg, see Table 3) maintained in the RAN 120 . Thus, in the example of Table 3, the initial set of target sectors may correspond to sectors T1 through T4. More generally, the initial set of target sectors may correspond to all sectors that satisfy a particular proximity metric associated with any sector T1 to T4 (eg, RAN 120 within a group member list entry). The last-known position for the AT maintained in ? does not need to be exact, since it is likely close to the AT's actual current position if the time-stamp field is relatively recent).

Then, at 715 of FIG. 7 , the RAN 120 determines an initial set of support sectors for the BCMCS flow T_Flow. In one example, the initial set of support sectors may be based on the initial set of target sectors. For example, the supporting sectors may correspond to any sector adjacent to one or more target sectors that is not the target sector. Alternatively, the support sector may correspond to a sector having a given proximity to the target sector (eg, distance proximity, signal strength proximity, etc.) without actually being adjacent to the target sector.

At 720 of FIG. 7 , the RAN 120 determines an initial set of non-supporting sectors for the BCMCS flow. The initial set of non-supporting sectors for a BCMCS flow is any sector in the wireless system 100 that is not a target sector as determined at 710 in FIG. 4 or a support sector as determined at 715 in FIG. 7 . include

At 725 of FIG. 7 , the RAN 120 executes target sector and support sector processes in respective target and support sectors. In general, each target sector and each support sector carries a BCMCS flow on a downlink broadcast channel (BCH), so that the RAN 120 provides target sectors T1 to T4 and base stations serving the support sectors. forward the multicast message to However, to reduce excessive AT feedback, the supporting sectors have BOMs configured to prompt for AT feedback at each BOM period (eg, to prompt for feedback from an AT "wandering" within the supporting sectors) ( Yes, while transmitting RFDB = 1 or RFP = 1), target sectors less frequently transmit BOMs for prompting AT feedback and suppressing AT feedback (e.g., target sector with BCMCS flow Send BOMs (eg with RFDB = 0 or RFP = 0) more frequently (to prevent AT registration when already forwarding). Non-supporting sectors do not forward the BCMCS flow T_Flow, and the RAN 120 does not need to forward multicast messages for T_Flow to non-supporting sectors. A more detailed discussion of target sector behavior, support sector operation, and non-support sector operation is assigned to Applicants in "METHODS," filed September 24, 2007, and is hereby intentionally incorporated by reference in its entirety. OF SUPPORTING MULTICAST COMMUNICATIONS ASSOCIATED WITH OVERLAPPING CLUSTERS WITHIN A WIRELESS COMMUNICATIONS NETWORK."

Then, at 730 of FIG. 7 , the RAN 120 updates the cluster's sector assignments (eg, adding new target/support sectors, removing target/support sectors, etc.). A more detailed description of sector allocation updates is also provided in the co-pending application cited above. Also, although not explicitly shown in FIG. 7 , during an active multicast session, the RAN 120 continuously maintains/updates the group member list based on RouteUpdate messages and GMN messages received from multicast group members. do.

8 shows a wireless communication system 800 configured based on the process of FIG. 7 and the assumptions provided in Table 3 above. As shown in FIG. 8 , the wireless communication system 800 includes a number of sectors 805 including target sectors T1 through T4, supported sectors N1 through N11, and non-supported sectors X1 through X17. As discussed above, the multicast or BCMCS flow T_Flow is announced/delivered within target sectors T1 through T4 and supporting sectors N1 through N11, and the RAN 120 provides multicast support for T_Flow to base stations in non-supporting sectors. Do not advertise or send messaging. Accordingly, the system-wide multicast communication traffic level is reduced compared to the prior art in which the multicast flow T_Flow is delivered to all sectors.

In an alternative embodiment of the present invention, as discussed above with respect to 710 of FIG. 7 , target sectors are (i) sectors stored in each AT's Last Known Location field maintained in Table 3 (ie, sector T1). through T4), and (ii) sectors satisfying the given proximity metric associated with (i). For example, if the given proximity metric corresponds to adjacent sectors, the wireless communication system 800 may cause support sectors N1 to N11 to also be target sectors, such that sectors adjacent to the new set of target sectors are support sectors. transformed into, etc. As another example, if a given proximity metric corresponds to all sectors within a distance from the last registered sector for performing distance-based registration, then all sectors within the distance also become target sectors. Accordingly, it will be appreciated that the initial target sector group need not be limited to the last-known locations of ATs as maintained in the RAN 120 for a given multicast group.

In another example, the group member list can be used to provide scheduling commands from the RAN 120 to multicast group members, which are in response to "interactive" multicast messages, such as announcement messages. Instruct multicast group members on a method, wherein a bidirectional multicast message is a multicast message that solicits or solicits feedback from one or more multicast group members. For example, if a large number of multicast group members are expected to exist within a particular sector, and if an announcement message is sent within a sector during a multicast session, a relatively large number of multicast group members may be present during the multicast session. It may attempt to concurrently access the reverse link channel to register in response to the announcement message. However, the information present in the group member list allows the RAN 120 to schedule a response sequence for the access terminals to respond to announcement messages via "Access Channel Messages" (ACMs). For example, the RAN 120 may transmit an ACM with an announcement message, and the ACM specifies a prioritized response order that reserves feedback slots for multiple access terminals based on a group member list. For example, an access terminal that has the most recent update to its location field in a group member list maintained by the RAN 120 (eg, updated via a GMN message, RouteUpdate message, etc.) may be granted in the reply slot, the AT with the next most recently updated location field may be granted in the second reply slot by the ACM, and so on. Scheduling and ACMs of Bidirectional Multicast Message Feedback on the Reverse Link "METHODS OF RESPONDING TO AN INTERACTIVE MULTICAST MESSAGE WITHIN A", filed Sep. 24, 2007, assigned to the applicant and hereby intentionally incorporated by reference in its entirety. WIRELESS COMMUNICATION SYSTEM" (Attorney docket no. 071246P1) is discussed in more detail in U.S. Provisional Patent Application Serial No. 60/974,796.

Those of ordinary skill in the art will recognize that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, instructions, information, signals, bits, symbols, and chips that may be referenced throughout the description include voltages, currents, electromagnetic waves, magnetic fields or particles, optical may be represented by fields or particles, or any combination thereof.

Additionally, those skilled in the art will appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosed embodiments herein may be implemented as electronic hardware, computer hardware, or combinations of both. It will be further recognized that To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The various illustrative logic blocks, modules, and circuits described in connection with the embodiments disclosed herein may be used as general purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or It may be implemented or performed in other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented in a combination of computing devices, eg, a combination of a DSP and a microprocessor, a combination of multiple microprocessors, one or more microprocessors in association with a DSP core, or any other such configuration.

The methods, sequences and/or algorithms described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. can be embedded. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. Alternatively, the storage medium may be integrated into the processor. The processor and storage medium may reside within the ASIC. The ASIC may reside within a user terminal (eg, an access terminal). Alternatively, the processor and storage medium may reside as separate components within the user terminal.

In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage medium may be any available medium that can be accessed by a computer. By way of example and not limitation, such computer-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or that can be accessed by a computer and contains instructions or It may include any other medium that can be used to hold or store desired program code in the form of data structures. Any connection is also properly termed a computer-readable medium. The software transmits from a website, server, or other remote source using, for example, coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio and microwave. Where applicable, coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio and microwave are included within the definition of medium. Disk and disc as used herein include compact disk (CD), laser disk, optical disk, digital versatile disk (DVD), floppy disk, and Blu-ray disk, wherein the disks Disks generally reproduce data magnetically, while disks optically reproduce data via lasers. Combinations of the above should also be included within the scope of computer-readable media.

While the foregoing disclosure shows exemplary embodiments of the invention, it should be noted that various changes and modifications may be made therein without departing from the scope of the invention as defined by the appended claims. . The functions, steps and/or actions of the method claims according to the embodiments of the invention described herein need not be performed in any particular order. Moreover, although elements of the invention may be described or claimed in the singular, the plural is contemplated unless limitations to the singular are explicitly stated.