Setting up a multicast group communication session within a wireless communications system

The present invention relates to communication in a wireless telecommunications system, and more particularly to setting up a multicast group communication session within a wireless communication system.

Wireless communication systems include first-generation analog wireless telephone services (1G), second-generation (2G) digital wireless telephone services (including intermediate 2.5G and 2.75G), and third-generation (3G) high-speed data. / Has evolved through various generations, including internet-enabled wireless services. There are many different types of wireless communications currently in use, including cellular and personal communication services (PCS) systems. Examples of known cellular systems are Cellular Analog Advanced Mobile Phone Systems (AMPS), Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), Global for Mobile Connections. Includes a digital cellular system based on a TDMA variant of the system (GSM®) and a newer hybrid digital communication system that uses both TDMA and CDMA technologies.

The method for providing CDMA mobile communication is described in TIA / EIA / IS-95-A, "Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System", which is referred to as IS-95 in this specification. It has been standardized in the United States by the American Telecommunications Industry Association / American Electronic Industries Alliance. The AMPS and CDMA composite system is described in TIA / EIA standard IS-98. Other communication systems are broadband CDMA (WCDMA), a standard corresponding to what is called CDMA2000 or TD-SCDMA (such as the CDMA2000 1xEV-DO standard), IMT-2000 / UM, or the International Mobile Telecommunications System 2000. / Described in Universal Mobile Telecommunications Systems.

In wireless communication, a mobile station, handset or access terminal (AT) supports a communication link or service within a specific geographic area adjacent to or around the base station (also known as a cell site or cell). Receives a signal from a fixed-position base station (called). Base stations are generally access networks (ANs), which are packet data networks that use standard Internet Engineering Task Force (IETF) -based protocols that support how to distinguish traffic based on quality of service (QoS) requirements. ) / Provide item points to the Radio Access Network (RAN). Therefore, base stations generally interact with AT over wireless interfaces and with AN over Internet Protocol (IP) network data packets.

In wireless power transfer, push-to-talk (PTT) capabilities are becoming more prevalent in service sectors and consumers. PTT can support "dispatch" of voice services operating on standard commercial wireless infrastructures such as CDMA, FDMA, TDMA, and GSM®. In the dispatch model, communication between endpoints (ATs) occurs within a virtual group, where the voice of one "speaker" is transmitted to one or more "receivers". A single instance of this type of communication is usually called a dispatch call, or simply a PTT call. A PTT call is an instantiation of a group that defines the characteristics of the call. A group is essentially defined by a member list and related information such as group name or group identification information.

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". Mobile communication is increasing, and the ability to send given data to a large number of access terminals at the same time is becoming more important. Therefore, the protocol has been adopted to support simultaneous data communication of the same packet or message to multiple destinations or target access terminals. "Broadcast" refers to sending a data packet to all destinations or access terminals (eg, within a given cell serviced by a given service provider, etc.), while "multicast" refers to destinations. Or it refers to sending a data packet to a given group of access terminals. In one example, a given group of destinations or a "multicast group" can be on two or more and all of the possible destinations or access terminals (within a given group served, for example by a given service provider). Can include less than. However, in some situations, the multicast group may contain only one access terminal, similar to unicast, or, instead, the multicast group, like broadcast (eg, in a given cell, etc.). It is at least possible to include all access terminals.

Broadcast and / or multicast is to perform multiple consecutive unicast operations, for example to adapt a multicast group, and to allocate a unique broadcast / multicast channel (BCH) to handle a large number of data transmissions at the same time. It can be performed within a wireless communication system in several ways, such as. Traditional systems that use broadcast channels for push-to-talk communication are incorporated herein by reference in their entirety, US Patent Application Publication No. 2007/0049314, dated March 1, 2007, " Push-To-Talk Group Call System Using CDMA 1x-EVDO Cellular It is described in "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 the bandwidth requirements of traditional unicast techniques, traditional broadcast channel signaling can still lead to additional overhead and / or delay, degrading system performance. May cause you to.

The 3rd Generation Partnership Project 2 (3GPP2) defines the Broadcast Multicast Service (BCMCS) standard for supporting multicast communication in CDMA2000 networks. Therefore, a version of the 3GPP2 BCMCS standard, version 1.0C, S0054_A, dated February 14, 2006, "CDMA2000 High Speed Broadcast Multicast Packet Data Air Interface Standard," is incorporated herein by reference in its entirety.

<p> In one embodiment, a multicast communication session is set up on an access network within a wireless communication system, whereby the access network sends an announcement message announcing the current multicast communication session to a given access terminal group within the initial cluster of sectors. Send to. The access network receives a registration request for the current multicast communication session from the access terminal and selectively loads a cluster of stored sectors that support the previous multicast communication session into a given group. The access network then turns on the multicast flow for the current multicast communication session within each sector of the stored cluster. In another embodiment, the multicast communication session is terminated, thereby causing the access network to remember the configuration of clusters in use at or near the end of the current multicast communication session, which later follows: Can be used during the setup of a multicast communication session.</p><p> A more complete recognition of the embodiments of the present invention and many of the benefits that accompany them, given the following detailed description when considered in conjunction with the accompanying drawings provided solely for illustration purposes, rather than to limit the invention. By reference, it is as easily acquired as it is better understood.</p>

<figref num="1">FIG. 5 is a diagram of a wireless network architecture that supports access terminals and access networks according to at least one embodiment of the present invention.</figref><figref num="2A">It is a figure which shows the carrier network by one Embodiment of this invention.</figref><figref num="2B">It is a figure which shows the wireless communication example of FIG. 1 by at least one Embodiment of this invention in more detail.</figref><figref num="3">It is a figure of the access terminal by at least one embodiment of this invention.</figref><figref num="4">FIG. 5 illustrates a traditional multicast messaging process using the Broadcast Multicast Services (BCMCS) framework.</figref><figref num="5">It is a figure which shows the conventional cycle of a downlink control channel.</figref><figref num="6">It is a figure which shows the group membership report and the location update process by one Embodiment of this invention.</figref><figref num="7">It is a figure which shows the setup process of the multicast communication session by one Embodiment of this invention.</figref><figref num="8A">It is a figure which shows the example of the initial cluster established during the process of FIG. 7 by one Embodiment of this invention.</figref><figref num="8B">Figure 8B shows a reduced or pruned version of the initial cluster.</figref><figref num="9A">It is a figure which shows the setup process of the multicast communication session by one Embodiment of this invention.</figref><figref num="9B">It is a figure which shows the setup process of the multicast communication session based on the setting related to the previous multicast communication session by one Embodiment of this invention.</figref><figref num="10A">It is a figure which shows the example of the in-use cluster established during the process of FIG. 9A by one Embodiment of this invention.</figref><figref num="10B">It is a figure which shows the example of the memory cluster from the previous multicast communication session by one Embodiment of this invention.</figref><figref num="10C">It is a figure which shows the example of the cluster which changed from the stored cluster of FIG. 10B based on the registration from the sector outside the cluster in the current multicast communication session by one Embodiment of this invention.</figref>

Aspects of the invention are disclosed in the following description and related drawings for a particular embodiment of the invention. Alternative embodiments can be devised without departing from the scope of the invention. Moreover, well-known elements of the invention are not described or omitted in detail in order not to obscure the appropriate details of the invention.

The terms "exemplary" and / or "example" are used herein to mean "as an example, example or example". The embodiments described herein as "exemplary" and / or "examples" are not necessarily construed as preferred or advantageous over other embodiments. Similarly, the term "embodiment of the invention" does not require that all embodiments of the invention include the features, advantages or modes of operation discussed.

In addition, many embodiments are described, for example, with respect to a series of actions performed by elements of a computing device. The various actions described herein are performed by a particular circuit (such as an application specific integrated circuit (ASIC)), by program instructions executed by one or more processors, or by a combination of both. It will be recognized that it can be done. In addition, the sequence of actions described herein is in any form of computer-readable storage medium that stores a set of corresponding computer instructions that, at runtime, causes the associated processor to perform the functions described herein. It can be considered to be fully embodied. Thus, various aspects of the invention may be embodied in several different forms, all of which are intended to fall within the scope of the claimed subject matter. In addition, for each of the embodiments described herein, the corresponding embodiment of any such embodiment is described herein as, for example, "logic configured" to perform the described actions. May be done.

The high data rate (HDR) subscriber station referred to herein as an access terminal (AT) may be mobile or fixed and is referred to herein as a modem pool transceiver (MPT) or base station (BS) 1 It can communicate with one or more HDR base stations. The access terminal sends and receives data packets to and from 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. To do. Modem pool transceivers and modem pool controllers are part of a network called an access network. The access network transports data packets between a large number of access terminals.

The access network may be further connected to additional networks outside the access network, such as the corporate intranet or the Internet, and may transport data packets between each access terminal and such an external network. An access terminal that has established an active traffic channel with one or more modem pool transceivers is called an active access terminal and is said to be in traffic. An access terminal in the process of 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 may be any data device that communicates via a wireless channel or, for example, a wired channel using an optical fiber or coaxial cable. The access terminal may further be any of several types of devices, including but not limited to PC cards, CompactFlash®, external or internal modems, or wireless or wireline telephones. .. A communication link through which an access terminal sends a signal to a modem pool transceiver is called a reverse link or traffic channel. A communication link through which a modem pool transceiver sends a signal to an access terminal is called a forward link or traffic channel. As used herein, the term traffic channel may refer to either forward or reverse traffic channel.

FIG. 1 shows a block diagram of an exemplary embodiment of a wireless system 100 according to at least one embodiment of the present invention. System 100 connects access terminal 102 to a network device that provides data connectivity between packet-switched data networks (such as intranet, Internet and / or carrier network 126) and access terminals 102, 108, 110, 112. It can include an access terminal such as a cellular telephone 102 that communicates with an accessible network or wireless access network (RAN) 120 via an air interface 104. As shown herein, the access terminal can be a cellular phone 102, a mobile information terminal 108, a pager 110 referred to herein as a bidirectional text pager, or a separate computer platform 112 with a wireless communication portal. .. Accordingly, embodiments of the present invention include, but are not limited to, wireless modems, PCMCIA cards, personal computers, telephones, or any combination or secondary combinations thereof, including wireless communication portals, or wireless communication. It can be realized on any form of access terminal having a function. Further, the terms "access terminal", "wireless device", "client device", "mobile terminal" as used herein, and variants thereof 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 present invention are not limited to the configurations shown. System 100 is just an example, with remote access terminals such as wireless client computing devices 102, 108, 110, 112, between and / or carrier networks 126, the Internet and / or without limitation. Alternatively, it can include any system that allows wireless communication between and within components connected via air interfaces 104 and RAN 102, including other remote servers.

The RAN120 controls the messages sent (typically sent as data packets) to the base station controller / packet control function (BSC / PCF) 122. The BCS / PCF122 is responsible for signaling, establishing and tearing down the bearer channel (ie, the data channel) between the packet data service node 100 (PDSN) and the access terminals 102/108/110/112. If link layer encryption is possible, the BSC / PCF122 also encrypts the content before it is transferred by the air interface 104. The features of BSC / PCF122 are well known in the art and are not discussed further due to their simplicity. The carrier network 126 may communicate with the BSC / PCF122 via a network, the Internet and / or the Public Switched Telephone Network (PSTN). Alternatively, the BSC / PCF122 may connect directly to the Internet or an external network. Typically, 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 be connected to a number of base stations (BS) or modem pool transceivers (MPT) 124. The BSC / PCF122 is typically connected to the MPT / BS124 by a network for data transfer and / or voice information, the Internet and / or also the PSTN, in a manner similar to a carrier network. The MPT / BS124 can wirelessly broadcast data messages to access terminals such as cellular phones 102. As is known in the art, MPT / BS124, BSC / PCF122 and other components form RAN120. However, alternative configurations may also be used and the present invention is not limited to the configurations shown in the drawings. For example, in another embodiment, the BSC / PCF122 and one or more MPT / BS124 machines.

FIG. 2A shows a carrier network 126 according to an embodiment of the present invention. In the embodiment of FIG. 2A, 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. The PDSN160 utilizes, for example, cdma2000, a radio access network (RAN) (such as RAN120 in Figure 1) for mobile stations (such as access terminals such as 102, 108, 110, 112 in Figure 1). Provides access to Internet 175, Intranet and / or remote servers (such as Application Server 170). The PDSN160 may act as an access gateway to provide simple IP and mobile IP access, external agent support, and packet transport. The PDSN160 acts as a client for authentication, authorization, and accounting (AAA) servers and other support infrastructure, and provides mobile stations with a gateway to IP networks, as is known in the art. Can be done. As shown in Figure 2A, the PDSN160 may communicate with the RAN over a traditional A10 connection (eg, BSC / PCF122). The A10 connection is well known in the art and is not discussed further due to its simplicity.

With reference to Figure 2A, the broadcast serving (BSN) 165 may be configured to support multicast and broadcast services. The BSN165 will be described in more detail below. The BSN165 communicates with the RAN120 over a broadcast (BC) A10 connection (for example, BSC / PCF122) and with the application server 170 over the Internet 175. BCA10 connections are used to forward multicast and / or broadcast messaging. Therefore, application server 170 sends unicast messaging to PDSN160 over internet 175 and multicast messaging to BSN165 over internet 175.

In general, as described in more detail below, the RAN120 sends a multicast message received from the BSN165 over the BCA10 connection over the broadcast channel (BCH) of air interface 104 to one or more access terminals. Send to 200.

FIG. 2B shows in more detail an example of the wireless communication 100 of FIG. Specifically, with reference to FIG. 2B, AT1 ~ N are shown connected to RAN120 at locations serviced by endpoints of different packet data networks. Therefore, ATs 1 and 3 connect to RAN120 at the portion serviced by the first packet data network endpoint 162 (which may be PDSN160, BSN165, home agent (HA), external agent (FA), etc.). The first packet data network endpoint 162 then goes through the routing unit 188 to the Internet 175 and / or the Authentication, Authorization, and Accounting (AAA) Server 182, Provisioning Server 184, Internet Protocol (IP) Multimedia Subsystem. Connect to one or more of System (IMS) / Session Initiation Protocol (SIP) Registration Server 186 and / or Application Server 170. AT2 and 5 connect to RAN120 at the portion serviced by the second packet data network endpoint 164 (which may be PDSN160, BSN165FA, HA, etc., for example). Like the first packet data network endpoint 162, the second packet data network endpoint 164 then goes through the routing unit 188 to the Internet 175 and / or AAA server 182, provisioning server 184, IMS / SIP registration. Connect to one or more of Server 186 and / or Application Server 170. The AT4 can connect directly to the Internet 175 and then to any of the system components described above via the Internet 175.

Referring to FIG. 2B, AT1, 3 and 5 ~ N are shown as wireless mobile phones, AT2 is shown as a wireless tablet PC, and AT4 is shown as a wired desktop station. However, in other embodiments, the wireless communication system 100 can be connected to any type of AT, and the example shown in FIG. 2B aims to limit the types of AT that can be implemented in the system. It will be understood that this is not the case. Also, AAA182, provisioning server 184, IMS / SIP registration server 186, and application server 170 are each shown as structurally separate servers, but one or more of these servers is at least one of the present invention. It may be combined in one embodiment.

Further, referring to FIG. 2B, the application server 170 is shown as including multiple media control complexes (MCC) 170B from 1 to N, and multiple regional dispatchers 170A from 1 to N. The regional dispatchers 170A and MCC170B collectively, in at least one embodiment, have a communication session within the wireless communication system 100 (for example, a half-duplex group communication session over an IP unicasting and / or IP multicasting protocol). It is included in the application server 170, which can support a distributed network of servers that function collectively to arbitrate. For example, a communication session arbitrated by application server 170 can theoretically occur between ATs located anywhere in system 100 (for example, between session participants whose North American MCC is located in China). A large number of regional dispatchers 170A and MCCs are distributed to reduce the latency of arbitrated communication sessions (so that the media is not relayed here and there). Therefore, referring to the application server 170, it will be appreciated that the relevant functions can be performed by one or more regional dispatchers 170A and / or one or more MCC170Bs. The regional dispatcher 170A is generally responsible for any function related to establishing a communication session (for example, handling signaling messaging between ATs, scheduling and / or sending announcement messages), while the MCC170B Responsible for hosting communication sessions during the duration of a call instance, including signaling during a call and performing the actual exchange of media between arbitrated communication sessions.

Referring to FIG. 3, the access terminal 200 (here a wireless device), such as a cellular phone, may eventually come from carrier network 126, the Internet and / or other remote servers and networks, software transmitted from RAN120. It has a platform 202 capable of receiving and executing applications, data and / or commands. Platform 202 may 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 or random access memory (RAM and ROM), EEPROM, 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 typically flash memory, but can be any secondary storage device known in the art such as magnetic media, EEPROM, optical media, tape, software or hard disks. The internal platform 202 is also 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. Can be done.

Accordingly, one embodiment of the present invention may include an access terminal that includes the ability to perform the functions described herein. As those skilled in the art will appreciate, various logical elements are individual elements, software modules running on a processor, or any combination of software and hardware to achieve the functionality disclosed herein. It can be embodied in. For example, the ASIC 208, memory 202, API 210, and local database 214 may all be used collaboratively to load, store, and perform the various functions disclosed herein, and thus perform these functions. The logic for doing so may be distributed among various elements. Alternatively, this feature can be incorporated into a single individual component. Therefore, the features of the access terminal of FIG. 3 should be considered merely exemplary, and the present invention is not limited to the features or arrangements shown.

Wireless communication between access terminal 102 and RAN120 is for code division multiple access (CDMA), WCDMA, time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal frequency division multiple access (OFDM), and mobile communication. It can be based on different technologies such as Global 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, MPT / BS124 and BSC / PCF122. The BSC / PCF122 can connect to a large number of data networks such as the carrier network 126, PSTN, the Internet, and virtual private networks, which allows the access terminal 102 to access a wider range of communication networks. As mentioned above and as is known in the art, voice transmission and / or data can be transmitted from the RAN to the access terminal using various networks and configurations. Therefore, the examples provided herein are not intended to limit embodiments of the invention, but merely to assist in explaining aspects of embodiments of the invention.

As discussed in the Background Techniques section, multicast messaging may be performed in several ways. To better understand the embodiments of the present invention, conventional multicast messaging processes will be described with reference to FIGS. 4 and 5, respectively. Next, a multicast messaging process according to an embodiment of the present invention will be described in which a set of expected sectors that may contain one or more multicast members is established prior to the initiation of a multicast session.

Figure 4 shows a traditional multicast messaging process using the Broadcast Multicast Server (BCMCS) framework. Note that while FIG. 4 shows prior art known to the inventor, FIG. 4 does not necessarily represent prior art and therefore such approval is not intended unless otherwise specified. I want to be. The multicast messaging process of FIG. 4 is described below assuming that it runs 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 sent to a multicast group containing ATs (eg, A, B and C, for example). Multicast messages from 400 are sent to BSN165. At 405, BSN165 forwards the multicast message to RAN120 over the BCA10 connection. For example, a multicast message is first forwarded to BSC / PCF122, which analyzes the multicast group for the multicast message and forwards the multicast message to each MPT / BS124 that serves one or more multicast members. ..

After receiving the forwarded multicast message, the RAN120 waits for the next available control channel capsule at 410 and then announces the message on the control channel (eg packaged in a data oversignaling (DoS) message). To send. For example, the control channel referred to herein is a broadcast channel (BCH, eg, in an EV-DO in which BCH and CCH are time-multiplexed to occupy different time slots in the downlink frequency of the base station). ), Not a timed downlink control channel. In general, control channels intended to contain traditional control messages only are allocated less bandwidth (for example, less time slots), while broadcast channels (BCH) intended to contain traditional data. Is allocated more bandwidth (for example, more time slots).

Referring to FIG. 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 quasi-synchronous control channels (SSC). One SC is transmitted periodically or periodically in a given time slot for each control channel cycle with a duration of 256 slots, while AC is "randomly" or asynchronous within the control channel cycle. Sent in the time slot of. The SC is first sent in the time slot corresponding to "T mod256 = Offset", then optionally "T" It is transmitted in the time slot corresponding to "mod4 = Offset", where T indicates the system time, Offset indicates the time value delayed from a certain time, and these are included in the header of the control channel. Each SC may contain multiple control channel MAC layer packets, while each AC contains only one control channel MAC layer packet. When each MPT / BS124 periodically transmits one or more control channel MAC layer packets, interference can occur if each MPT / BS124 transmits simultaneously (for example, cell-to-cell interference). Therefore, different offsets are applied to the SC for each MPT / BS124 to avoid collisions. MPT / BS can transmit as many as three SSC capsules in one control channel period or 256 slot cycle. Each SSC typically sends only one control channel MAC layer packet. Assuming an offset value of 2, SSCs are transmitted in time slots 66, 130 and 194. Control channel capsules (eg SC, AC, SSC, etc.) are generally well known in the art in BCMCS systems and their further description is omitted for brevity.

Seeing Figure 4 again, upon receiving the announcement message at AT A, B and C, each of AT A, B and C determines to participate in the announced communication session, thereby each with RAN120. Send a BCMCS flow registration message to RAN120, 145 to register for the session. Also at 415, AT A, B and C send an acknowledgment ACK message to RAN 120, which is forwarded to the application server 170. At 420, AT Upon receiving a BCMCS flow registration message from A, B, and C, the RAN120 is either a synchronous control channel capsule (SC) (for example, time slot 2 in the next control channel cycle assuming an offset of 2) or an alternative. You may wait for a quasi-synchronous control channel capsule (SSC) (for example, one of control channel cycles 66, 130, 194 assuming an offset of 2), where the periodic BOM message is Scheduled. For example, within each control channel cycle, other applications may be trying to access the control channel, and other messages may be scheduled to result in a large number of cycle delays. One particular control channel capsule may be reserved for a particular BOM.

After waiting for the next available SC or SSC at 425, the RAN120 will include an AT that sends a BMCCS flow registration message at 415, at least within the sector of the wireless communication system 100 (eg AT A, B, C, etc.) ) Send a broadcast overhead message (BOM) over the air interface to one or more multicast group members. A BOM is a forward link control message defined by the EV-DO standard. The BOM is used to notify each multicast group member of the BMCCS flow currently running in the sector. The BOM is also used to transmit information about the forward link physical layer time slots that must be decrypted to receive the desired packet flow, as well as the number and flow of physical layer slots per broadcast physical layer packet. Provides interlaced multiple pair (IM-pair) information, which is information about the speed of the physical layer. At 430, AT Upon receiving the first notification ACK from A, B or C, the application server 170 begins transferring media to the RAN 120 for transmission to the target AT. AT A, B and C receive and decode the BOM (435), and RAN120 is where (for example, slots 8-16) after sending the BOM from 425 for the BOM to be decrypted at the target AT. Wait for a given slot. After the BOM decryption delay, the RAN 120 waits for the BCH slot indicated by the decrypted BOM before transmitting the media to the target AT received at 430,440. This creates another delay, which can be exacerbated based on the traffic on the broadcast channel (BCH). After a delay of 440, RAN120 can start sending media to group members registered on BCH (445). As described above with respect to Figure 4, traditional BMCCS multicast messaging typically decrypts the broadcast overhead message (BOM) before the media is sent on the broadcast channel (BCH) to each member of the multicast group. Requires each target AT or multicast group member. This creates a delay both for scheduling the BOM and for decrypting the BOM. Also, the 410 announcement message is transmitted within all possible sectors within the wireless communication system 100 because the location of the call target is known by application 170. However, it will be appreciated that multicast group members do not necessarily exist within each sector. Therefore, a certain number of transmissions are wasted each time a multicast session is started.

Hereinafter, an embodiment of the present invention in which the access terminal pre-registers with the RAN 120 for a later multicast session will be described. Then, when a given multicast session begins, the access terminals periodically have their location and so that the RAN120 has at least some knowledge of where the multicast group members for a given multicast session are located. / Or update their group membership information. Therefore, the RAN120 can reduce the number of transmissions required to establish and / or maintain a given multicast session.

FIG. 6 shows a group membership reporting and location update process according to an embodiment of the present invention. In the embodiment of FIG. 6, at 600, a given AT that wants to belong to one or more multicast groups is powered on. After the given AT is powered on, the given AT at 605 (for example, locating the pilot signal transmitted by one or more base stations in the RAN120 and / or any other initial power supply. Send a Group Membership Notification (GMN) message to RAN120 (after performing the submission procedure). The GMN message contains a list of multicast groups for which a given AT is currently a member of a multicast group or will become a member of a multicast group in the future.

In one example, the GMN message may be included within a standard BCMCS flow registration message. BCMCS flow registration messages are well known in the art and are defined in the 1xEV-DO standard. Typically, an AT receives a BOM with a set of registers to prompt a BCMCS flow registration message (for example, a register (RFDB) field for dynamic broadcasting equal to 1 or a register (RFP) field for paging). After that, send the BCMCS flow registration message. The BCMCS flow registration message contains a list of IDs of the BCMCS flow that the AT wants to monitor. The BCMCS flow ID can be dynamically assigned (for example, by a BCMCS controller (not shown)) or preset. If the BCMCS flow ID is dynamically assigned by the BCMCS controller, the AT can obtain the BCMCS flow ID through the BCMCS flow discovery process before sending the BCMCS flow registration message. On the other hand, in another embodiment of the invention, some blocks of BCMCS flow IDs may be preconfigured to be reserved regardless of whether the multicast session is actually active. In this example, each "allocated" BCMCS flow ID may be mapped to its own IP group ID (ie, a multicast IP address and port number pair). In one example, the mapping of "secured" BCMCS flow IDs is transferred to the assignee of this application, the agent reference number filed on September 24, 2007, which is hereby incorporated by reference in its entirety. 017365 P1 US Provisional Patent Application No. 60/974, Preconfigured with each multicast group member and RAN120 and / or BSN165, as discussed in more detail in issue 827, "METHODS OF GENERATING MULTICAST FLOW IDENTIFIERS". Therefore, in this example, the BCMCS flow ID contained in the 605 GMN message may correspond to one or more of the "allocated" BCMCS flow IDs.

In an alternative example, the GMN message may be contained within a proprietary or non-standard message, such as an uplink StorageBLOBNotification message. In this example, the GMN message may include a list of BCMCS flow IDs. Alternatively, the GMN message may include a list of multicast IP addresses and port numbers for the requested multicast session.

600 and 605 in Figure 6 are intended for AT "power-on", but in an alternative embodiment, each time a given AT makes a handoff (eg to a new base station, new subnet, etc.), it assists. GMN message may be sent to RAN120.

RAN120 receives a GMN message (605) and populates the group member list at 610. The items in each group member list are (i) a list of ATs with GMN messages sent to RAN120 (AT list fields), (ii) (for example, if the BCMCS flow ID is reported in 605). Relevant multicast group for each AT in the group member list (remembered as a BCMCS flow ID entry and if a proprietary message is reported at 605, as a multicast IP address / port number pair) ("Multicast group" Fields), (iii) The latest known location (Location Field) for each AT (indicating sector identification information, base station identification information, etc.) and (iv) The latest known location of the AT are reported. Includes a time stamp (timestamp field) that indicates the time spent. An example of the items in the group member list is shown below as Table 1.

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

Therefore, as illustrated in the example in Table 1, a given AT is labeled "AT1" and the given AT is a member of the multicast groups T_Flow, U_Flow and V_Flow. The latest known location for a given AT is within sector Y of wireless communication system 100, and the latest known location was reported at 7:06 EST.

In another example, the group member list may be grouped based on the multicast group field, as shown in Table 2 below.

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

Therefore, AT1-4 are registered for the multicast group T_Flow, as illustrated in the example in Table 2. Position fields and timestamp fields are not included in Table 2 for convenience of illustration, as these fields are unique to each of AT1-4.

It will be appreciated that the group member list shown above is provided solely for illustration purposes and that other embodiments of the present invention may construct the items of the group member list in any well-known manner. .. For example, the position field may instead store the base station identifier instead of the sector identifier. In another example, the location field is a location area (LA) identifier where each LA corresponds to a subnet or part of a PCF area (eg defined by RAN120), or each MA is by RAN for multicasting purposes only. An identifier that identifies multiple sectors, such as a multicast area (MA) identifier that corresponds to a portion of the identified subnet or PCF area, may be stored.

After updating the group member list based on the GMN message on the 610, the RAN120 on the 615 decides whether to dynamically configure the location update rule or protocol for the AT. The location update rule corresponds to how the AT schedules the route update message to be sent to RAN120. The route update message updates the position and timestamp fields (see above) for a particular AT. In general, at 615, the RAN120 may set a relatively aggressive location update rule if the RAN120 wants to keep a route closer to the location of the multicast group members of a particular multicast group. Otherwise, at 615, if RAN120 wants to reduce reverse link traffic, RAN120 may set relatively careful relocation rules. In another alternative, the RAN120 does not have to set a position update rule and may rely on the default value at a given AT or a manually entered position update rule. An example of the position update rule is shown below.

At 620, a given AT establishes a position update rule. For example, if RAN120 decides not to dynamically set the position update rule on 615, the default position update rule may be established on 620. Alternatively, if RAN120 decides to dynamically set the position update rule on 615, the dynamically set position update rule may be activated on 620. In another alternative, the user of a given AT may manually select and enter a custom location update rule.

In one example, a position update is made so that a given AT sends a route update message after passing a given distance (for example, based on which sector a given AT has passed through). The rule may be a distance-based registration (DBR) protocol. A given distance is based, for example, on which base station a given AT handed off, and which base station a given AT was monitoring while idle. You may be. Changes to location update rules in the distance-based registration protocol can be communicated to the AT via the EV-DO system's General Attribute Update (GAUP) protocol. In another example, the location update rule updates the route each time a given AT enters a new LA where each location area (LA) corresponds to a subnet or part of the PCF area (as defined by RAN120, for example). It may be the one that sends the message.

In another example, the location update rule may correspond to any of several possible location update strategies. For example, the position update rule may be timer-based in which a given AT maintains timers with a predetermined or custom period and sends a route update message once for each timer period. In this example, the smaller timer period corresponds to a more aggressive position update rule to keep the position item more up-to-date for the group member list. However, smaller periods are also associated with higher levels of traffic on the reverse link.

After setting the position update rule on the 620, a given AT resumes normal operation (eg entering idle mode, making a voice call, etc.). At 630, the predetermined AT decides whether to update the location information along with the route update message based on the location update rule established at 620. If the location update rule requires a route update message, the route update message is sent to RAN120 at 635. At 640, RAN120 updates the group member list parameters based on the route update message. For example, RAN120 updates the position and timestamp fields of the group member list for a given AT based on the route update message. Otherwise, if the location update rule indicates that the route update message does not have to be sent, the process proceeds to 645.

At 645, a given AT determines whether to update its group membership information with a supplemental GMN message. For example, if a given AT wants to join a new multicast group, a given AT will contain a supplemental GMN message (ie, a BMCCS flow ID and / or multicast IP address and port number pair for the new multicast group). ) May be determined to be transmitted. In another example, if a given AT wants to cancel its membership in an already registered multicast group, a given AT will have a supplemental GMN message (ie, BCMCS for the multicast group being canceled). You may decide to send the flow ID and / or delete the multicast IP address and port number pair). In one example, each supplemental GMN message discards any previously sent GMN message. If a given AT decides not to update its group membership information, the process returns to 625 and the given AT resumes normal operation. Otherwise, if a given AT determines to update its group membership information, the given AT sends a supplemental GMN message at 650.

At 655, RAN120 updates the group member list parameters based on the supplemental GMN message. If the supplemental GMN message requires a different multicast group than the previously sent GMN message, the multicast group field that maintains the list of multicast groups to which a given AT belongs will be placed in the multicast group listed in the supplementary GMN message. Updated to add. Alternatively, if group deletion is indicated in the GMN message, the multicast group field is updated to delete the multicast group mentioned in the supplemental GMN message. As it is understood, this is to remove the previously mentioned multicast group, add a new multicast group, and / or for a given AT, some from the relevant multicast group fields. It may be necessary to both add and remove multicast groups for. In addition, the RAN120 updates the position and timestamp fields of the group member list for a given AT that sends a supplemental GMN message.

In another example, if the supplemental GMN message does not contain a multicast group containing it, the supplementary GMN message is interpreted as a request to permanently remove or cancel a given AT from the group member list. Therefore, if the supplemental GMN message does not contain a multicast group, RAN120 deletes each of the AT list field, multicast group field, position field and timestamp field for a given AT.

At a given time, the group member list (for example, "potentially" because the group member list may not always be completely accurate), as understood in light of the description in Figure 6 above). Contains information about where multicast group members are "potentially" located before the active multicast session for the multicast group is actually started.

In addition, although not explicitly illustrated in Figure 6, the RAN120 voluntarily (ie, rather than responding to route update messages and / or GMN messages received from one or more ATs) is a group member list. May be updated periodically. For example, if the position field for a particular AT becomes "old" or exceeds the lifetime threshold, RAN120 interprets the old position field as out-of-date and removes the associated AT from the group member list altogether. May be good.

FIG. 7 shows a multicast messaging process according to an embodiment of the present invention. With respect to Figure 7, the group member list maintained by RAN120 is assumed to contain multiple ATs registered on both RAN120 and application server 170 for multicast group T_Flow, and multicast group T_Flow is currently participating in a multicast communication session. Suppose you haven't. Therefore, as an example, the group member list for AT registered for T_Flow may include the items in Table 3 (Table 3) (below) below.

<tables num="3"><img file="JP2013518525A_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. As an example, the multicast flow is the AT in Table 3 (above). Suppose it corresponds to T_Flow, like the multicast group fields for each of A ~ G. For example, the multicast flow T_Flow generated at 700 in Figure 7 may respond to requests that speak to a given multicast group (not shown) on a given access terminal. After the application server 170 decides to accept the AT request, the server 170 can generate a multicast flow announcement message sent to the group members via IP multicasting. At 705, application server 170 forwards the multicast flow to BSN165, BSN165 forwards BCMCS flow to RAN120 with a BCA10 connection, RAN120 is 710, via air interface 104 in one or more sectors, BCMCS. It is responsible for sending the flow's multicast message to the multicast group members.

At 710 in Figure 7, RAN120 determines the set of target sectors for the initial "cluster". The target sector used herein is any sector in a wireless communication system that has, or "potentially" has, at least one multicast group member. As used herein, "cluster" corresponds to a set of sectors (for example, one or more sectors) in which BCH carries BCMCS flows for a particular multicast group. As described in more detail below, a cluster contains both target and supporting sectors for a particular multicast group or BMCCS flow.

Still referring to 710 in Figure 7, RAN120 determines the set of target sectors for the initial cluster based on the group member list maintained by RAN120 (see, eg, Table 3). Therefore, in the example of Table 3, the initial set of target sectors may correspond to sectors T1 to T4. More generally (for example, if the latest known position for AT maintained at RAN120 in a group member list item is not always accurate, but the timestamp field is relatively recent, then AT The initial set of target sectors (because it may be close to the actual current position of) may correspond to all sectors that meet specific proximity metrics for any of sectors T1 through T4. ..

Then at 715 in Figure 7, RAN120 determines the set of supported sectors for the initial cluster for the BCMCS flow T_Flow. In one example, the set of supported sectors may be based on the set of target sectors determined by 710. For example, the supporting sector may correspond to any sector adjacent to one or more target sectors that are not themselves target sectors. Alternatively, the supporting sector may correspond to a sector with a given proximity to the target sector (eg distance proximity, signal strength proximity, etc.) rather than actually adjacent to the target sector. Good. RAN120 is 710, which determines the target and supported sectors for the initial cluster, at which point the initial cluster also carries the BCH flow (ie, multicast messages for group members belonging to T_Flow) on the downlink BCH. There is nothing to do.

At 720 in Figure 7, RAN120 determines the initial set of unsupported sectors for the BCMCS flow. The initial set of unsupported sectors for the BCMCS flow includes any sector in the wireless system 100 that is neither the target sector determined by 710 in Figure 7 nor the supported sector determined by 715 in Figure 7. Unsupported sectors are not considered part of a cluster, so when a sector belonging to a particular cluster is referenced, that sector is referred to as the cluster's target and / or supported sector.

At 725 in Figure 7, RAN120 announces a multicast communication session for T_Flow, at least within the target sector of the initial cluster. Figure 8A shows an example of an initial cluster established between 710 and 720 and sending an announcement message at 720. As shown in 720, the initial cluster contains target sectors T1 to T4 and support sectors N1 to N11. For example, within the initial cluster, the announcement message is packaged and downlinked within a data oversignaling (DoS) message to communicate the announcement message to the AT (AT1 ~ N) in the initial cluster more quickly. The notification message may be sent over the control channel (CCH), while the notification message may be sent to an AT outside the initial cluster using slower standard paging techniques to reduce the load on the CCH of the entire system 100. Good.

After sending the announcement message on 725, RAN120 waits to receive one or more BMCCS flow registration messages from AT1 ~ N, at least within the initial cluster. At 730, assume that the first of AT1 ~ N sends a BCMCS flow registration message to RAN120 to register for the announced multicast session. After receiving the 1st BCMCS flow registration message in the initial cluster at 730, RAN120 turns on BCH flow for each of the target and support sectors for the initial cluster as determined by 710 and 715, respectively (735). Therefore, at 730, the BMCCS flow registration message is received from only one of AT1 ~ N, so RAN120, even though at this point only one sector in the initial cluster is truly the target sector, Other than that, it carries the BCH-flow within any additional sector of the initial cluster that is not considered a target or support sector based on the registration received at the 730. Therefore, the set of sectors carrying the BCH-flow is based on the route update message from AT and the corresponding data stored in the group member list on RAN120, not on the BCMCS flow registration message. That is, the RAN120 does not have to wait for a BCMCS flow registration message within sectors that are expected to contain ATs based on previous route update messages before turning on multicast flows for those sectors, and at the same time System 100 Less than all of the sectors need to preemptively carry the multicast flow in this way. As you can see, this can reduce the setup time for ATs that are in the initial cluster but have not yet sent the BMCCS flow registration message. However, this also means that the BCH-flow is potentially carried in sectors that do not require the BCH-flow, so the forward direction of system 100.

After sending the BCH-flow to the initial cluster, the RAN120 runs the target and supported sector processes on each of the target and supported sectors. In general, each target sector and each support sector carries the BMCCS flow on the downlink broadcast channel BCH, so the RAN120 forwards the multicast message to the base stations serving the target sectors T1 through T4 and the support sectors. However, in order to reduce excessive AT feedback, the support sector is provided with (eg RFDB = 1 or RFP = 1) at each BOM period (eg, to encourage feedback from ATs that "enter" the support sector). While sending a BOM configured to prompt AT feedback, the target sector does not send a BOM prompting AT feedback very often (for example, the target sector is already carrying the BCMCS flow). In some cases, send BOMs more often to suppress AT feedback (with, for example, RFDB = 0 or RFP = 0) in an attempt to stop AT registration. The unsupported sector does not carry the BCMCS flow T_Flow, and the RAN120 does not need to forward the multicast message for T_Flow to the unsupported sector. A more detailed description of the nature of the target sector, the nature of the supported sector and the nature of the unsupported sector is transferred to the assignee of this application, which is hereby incorporated by reference in its entirety, September 24, 2007. It is found in US Provisional Patent Application No. 60 / 974,808, "METHODS OF SUPPORTING MULTICAST COMMUNICATIONS ASSOCIATED WITH OVERLAPPING EXPRESSCLUSTERS WITHIN A WIRELESS COMMUNICATIONS NETWORK", which is assigned to the assignment number 072340P1.

As you can see, if the initial cluster overestimates the number of sectors that BCH-flow is required to support a multicast communication session, then a certain number of target sectors will eventually (eg RFDB = 1). Attempts to see if one or more target ATs are being serviced inside their respective sectors (by configuring the provided BOM). When this happens, these target sectors discover that the target AT does not actually exist within them. Therefore, in the 740 the initial cluster is "pruned" or reduced based on AT feedback (for example, in this case AT feedback is the lack of BCMCS flow registration messages after the BOM with RFDB = 1). ).

In one example, as mentioned above, FIG. 8A shows an example of an initial cluster established between 710 and 720 in FIG. Then at 730, assume that the BCMCS flow registration message is only received from target AT A and / or target AT B within target sector T1. Therefore, AT C ~ G responds to the 725 announcement message even though it has previously registered with the multicast group T_Flow and is updating its position in the group member list maintained by RAN120. And does not send the BCMCS flow registration message. In this case, the "pruned" cluster may be shown as shown in Figure 8B. In FIG. 8B, the target sectors T2 to T4 are migrated to either supported or unsupported sectors, and any supported sector from T2 to T4 is migrated to the unsupported sector. The only sector among those supported sectors that remain as supported sectors after the previous target sectors T2 to T4 and the pruning step is the sector that is the supported sector of T1 in this example.

Then, at 745 in Figure 7, RAN120 updates the sector allocation of the pruned cluster during the multicast communication session (for example, adding new target / supported sectors, removing target / supported sectors, etc.) ). Again, a more detailed description of sector allocation updates is given in the co-pending application referenced above. Also, although not explicitly shown in Figure 7, during an active multicast session, RAN120 maintains / updates the group member list based on GMN and route update messages received from multicast group members. continue.

In an alternative embodiment of the invention, as discussed above with respect to 710 in FIG. 7, the target sector is (i) the sector stored in the latest known position field of each AT maintained in Table 3 (Table 3). That is, sectors T1 to T4) and (ii) (i) may be configured to include sectors that meet a given proximity metric. For example, if a given proximity metric corresponds to adjacent sectors, support sectors N1 to N11 will also be the initial target sectors, and sectors adjacent to the new set of target sectors will be the support sectors, and so on. The wireless communication system 800A is modified as another example, if a given proximity metric corresponds to all sectors within the distance from the latest registered sector for performing distance-based registration, then within the distance. All sectors of are also target sectors. Therefore, the group of initial target sectors of the initial cluster 800A is not necessarily limited to the latest known position of AT maintained in RAN120 for a given multicast group.

In another example, a group member list is a multicast message regarding how to respond to "interactive" multicast messages, such as announcement messages, which are multicast messages that request or require feedback from one or more multicast group members. Scheduling instructions that direct group members may be used by RAN120 to provide multicast group members. For example, if a large number of multicast group members are expected to exist in a particular sector and an announcement message for a multicast session is sent within the sector, a relatively large number of multicast group members will respond to the announcement message and multicast. You may try to access the reverse link channel at the same time to subscribe to the session. However, the RAN120 uses the information present in the group member list to use "access control messages" (ACMs) (for example, ACMs are instructions on how individual ATs contend for reverse link access channels. A response sequence for the access terminal can be scheduled to respond to the announcement message via (corresponding to any downlink control message from RAN120). For example, the RAN120 may send an ACM with an announcement message, which specifies a preferred response order with feedback slots for some access terminals based on the group member list. For example, in the group member list maintained by RAN120, the access terminal with the latest update for that position field (updated via, for example, GMN message, route update message, etc.) is granted the first response slot by ACM. The AT with the next updated position field may then be granted a second response slot by the ACM, and so on. ACM, and interactive multicast message feedback scheduling on reverse links, are transferred to the assignee of this application, which is hereby incorporated by reference in its entirety. US Provisional Patent Application No. 60 / 974,796, No. 071246P1, "METHODS OF RESPONDING TO AN IN" It is discussed in more detail in "TERACTIVE MULTICAST MESSAGE WITHIN A WIRELESS COMMUNICATION SYSTEM".

As described above for Figures 7, 8A and 8B, the initial cluster is established based in part on the expected position of the AT stored in the group member list in RAN120 for a particular multicast group, and the entire initial cluster. Each target sector and support sector of the BCH-flow for a group session after the 1st BCMCS flow registration message is received on RAN120 from any target AT in any sector of the initial cluster. Carry. As one of ordinary skill in the art would understand, if less than all sectors of the initial cluster actually need to be given BCH-flow for the target AT contained therein, then each sector of the initial cluster needs to be given BCH-flow. By giving, the forward capability of the system 100 may be reduced more than necessary. In the following, the initial cluster is used to determine where the multicast session should be announced (eg in a DoS message on the CCH), while the BCH-flow is the actual registration from the target AT. Embodiments of the invention that are simply transported based on where the request is received (eg Figure 9A) or based on the time-related cluster information at the end of the previous multicast session for the group (eg Figure 9B). explain.

FIG. 9A shows a multicast messaging process according to another embodiment of the invention. In particular, FIG. 9A shows an alternative embodiment to support either a first session involving a particular multicast group, or at least the next session starting in a threshold time period after a previous session. For example, if the time threshold is 2 (2) hours and the latest session involving the multicast group is 4 (4) hours of the current session, then the process in Figure 9A also had a previous multicast session. It may be executed regardless. Also, at least the time threshold at which the process in Figure 9A can be used can be set very low, even if there is another session involving the multicast group for a short time before the new session is started. possible.

For Figure 9A, as shown in Figure 7, the group member list maintained by RAN120 is assumed to contain multiple ATs registered on both RAN120 and application server 170 for the multicast group T_Flow, and the multicast group T_Flow is Suppose you are not currently participating in a multicast communication session. Therefore, as an example, the group member list for AT registered for T_Flow may include the items in Table 3 (above).

Referring to FIG. 9A, blocks 900A to 930A correspond to blocks 700 to 730 of FIG. 7, respectively. Therefore, the sector of the initial cluster is determined (910A, 915A, 920A), RAN120 announces a multicast communication session at least within the target sector of the initial cluster (925A), and at least one target AT in the initial cluster calls. Accept the announcement and request registration for the announced multicast session (930A).

At this point, in Figure 7, RAN120 simply flows the BCH-flow within the initial cluster, which essentially means that the initial cluster is activated, target or supporting sectors at 710 and 715, respectively. Each sector determined to be migrated to either the target sector or the supported sector However, in Figure 9A, when a registration is received from an individual target AT in the sector of the initial cluster at 930A, the RAN120 is 935A and the registration is Only the received sectors are migrated to the target sectors, and then the supported sectors associated with these target sectors are populated. The resulting group of target and supported sectors is collectively referred to as the "in-use cluster." Therefore, the in-use cluster formed at 935A corresponds to a subset (eg, less or equal) of the initial cluster in which the multicast session was announced at 925A.

For example, it is assumed that the initial cluster is formed as shown in FIG. 8A, so block 910A determines sectors T1 to T4 as target sectors and block 915A determines sectors N1 to N11 as supported sectors. In this case, the announcement of 925A announces the multicast session at least inside sectors T1 to T4 and N1 to N11. However, in Figure 9A, the initial cluster is not used directly with respect to where the BCH-flow is carried. Therefore, assume that only one or more target ATs in sector T1 actually send the BMCCS flow registration message within the threshold time period in response to the announcement message at 930A. In this case, the in-use cluster may be formed as shown in FIG. 10A, so T1 from the initial cluster migrates to the target sector T1 in the in-use cluster, and sectors N1, N2, T2, from the initial sector, T3, N10 and N11 move to support sectors N1 to N6 in the cluster in use, respectively. In this case, the in-use cluster essentially starts from a "blank state", so additional support and target sectors from the initial cluster will default to the in-use sector until a registration message is received from the target AT during 930A. There is no need to actively migrate to unsupported sectors in the cluster in use to set the sector as unsupported sector.

Then, after forming a in-use cluster at 935A, the RAN120 flows a BCH-flow at 940A for a multicast communication session in the in-use cluster and belongs to the initial cluster but is in use (if any). Do not run BCH-flow in sectors that do not belong to the cluster. After flowing the BCH-flow to the in-use cluster, the RAN120 runs the target-sector and support-sector processes on each of the target and support sectors in the in-use cluster. In general, each target sector and each supporting sector of the cluster in use carries the BMCCS flow on the downlink broadcast channel BCH, so the RAN120 forwards the multicast message to the base stations serving the target sectors T1 and supporting sectors N1 through N6. To do.

As you can see, even if the initial cluster overestimates the number of sectors that BCH-flow is required to support a multicast communication session, the in-use cluster will still be from the target AT for its formation. Relying on the actual registration message of the RAN120, therefore, carrying the multicast flow within the in-use cluster does not overload the forward link of the RAN120. Also, the in-use cluster does not need to be "pruned" or reduced as in 740 in Figure 7, but the in-use cluster may move or drop the call during the multicast session. The configuration of the target and supported sectors of is still changeable after its formation.

Then, at 945A in Figure 9A, the RAN120 updates the sector allocation of the cluster in use during the multicast communication session (for example, adding a new target / supported sector, removing the target / supported sector, etc.). .. Again, a more detailed description of sector allocation updates is given in the co-pending application referenced above. Also, although not explicitly shown in Figure 9A, during an active multicast session, RAN120 maintains / updates the group member list based on GMN and route update messages received from multicast group members. continue.

At 950A, RAN120 determines whether to end the multicast session. For example, the 950A's decision can be based on whether the END message was sent from the application server 170. If RAN120 determines that the multicast session can continue at 950A, the process returns to 945A. Otherwise, if RAN120A determines to terminate the multicast session at 950A, then RAN120 is 955A and remembers the current sector formation of the cluster when the multicast session is terminated. As described below with respect to Figure 9B, the stored cluster from 955A can be used to more accurately determine how to establish an "initial in-use cluster" for subsequent multicast sessions, so initial The in-use cluster does not automatically have to be the same size as the initial cluster or as small as the in-use cluster before the first registration is received. (That is, in the case of Figure 9A, the cluster in use at 935A contains zero (0) sectors before the first registration is received).

FIG. 9B shows either the process continuation of FIG. 9A or the recursive continuation of the previous iteration of FIG. 9B. If Figure 9B is a continuation of the process in Figure 9A, at some point after the multicast session ends after 950A in Figure 9A and the cluster at the end of the multicast session is remembered by RAN120 at 955A, the application server 170 Requests notification of the next multicast session involving the same multicast group at 900B. Therefore, blocks 900B to 930B correspond to blocks 700 to 730 and / or blocks 900A to 930A of FIG. 9A, respectively. Therefore, the sector of the initial cluster is determined (910B, 915B, 920B), RAN120 announces a multicast communication session at least within the target sector of the initial cluster (925B), and at least one target AT in the initial cluster calls. Accept the announcement and request registration for the announced multicast session (930B). The location and / or group membership association of the multicast group AT may have changed from the previous multicast session in Figure 9A, so the initial cluster formed by 915B, 920B and 925B is 915A, Figure 9A, It will be appreciated that it does not have to be the same as the initial cluster formed by 920A and 925A. That is, the process of FIG. 6 continues to run during and / or during and / or during the multicast session of FIG. 9A and the multicast session of FIG. 9B, which can lead to the coordination of the group member list maintained by RAN120.

Upon receiving the first registration to the multicast session on the 930B, the RAN120 is the 935B, the previous multicast session for the multicast group (ie, the session described above for Figure 9A, or the previous iteration of the process in Figure 9B). Determines if has occurred within the threshold time period of the current multicast session. In one example, the RAN120 is the time the request was received from the application server 170 on the 905B for a threshold time period from the time the previous multicast session ended (for example, 950A in Figure 9A, 960B in Figure 9B, etc.). Or, in another example, the 930B can measure the time difference to compare the time the first registration message was received from one of AT1 ~ N. The 935B time determination may be performed to ensure that the cluster at the end of the previous multicast session may resemble the cluster in use for the current multicast session. For example, if the previous multicast session unexpectedly drops for 60 seconds before the current multicast session, the clusters for the previous session are still relevant because the participating ATs are in about the same position. Very likely to be. In another example, for example, if the previous multicast session occurred 5 weeks before the current multicast session, the participating ATs may not necessarily be in approximately the same position, so the previous session. Clusters for are still very unlikely to be related.

If RAN120 determines on 935B that the previous multicast session is not within the threshold time period of the current multicast session, the process proceeds to block 935A and RAN120 is received from the target AT for the current multicast session. Build a in-use cluster based solely on actual registration. Otherwise, RAN120 determines at 935B that the previous multicast session is within the threshold time period of the current multicast session and the process proceeds to block 940B in Figure 9B. At 940B, RAN120 was remembered for the previous multicast session (for example, if the process in Figure 9A corresponded to the previous multicast session, it was remembered at 955A, the previous iteration of the process in Figure 9B was earlier. Load the cluster (stored in 956B if it supports multicast sessions).

At 945B, clusters loaded from 940B are used to form the initial in-use cluster. The initial in-use clusters used herein are based on (i) the group member list maintained by RAN120, for the initial clusters formed by 915B-925B and (ii) for actual registration from the target AT. Based on a hybrid cluster of in-use clusters. In other words, the initial in-use cluster is somewhat speculative, as there is no guarantee that the cluster for the previous session will be equal to the cluster for the current session. However, initial in-use clusters can generally be considered less speculative than initial clusters. The initial in-use cluster can be at least somewhat larger than the in-use cluster and can be smaller than the initial cluster formed by 915B-925B. Also on the 945B, the RAN120 migrates the sectors for which registration was received on the 930B to target and supported sectors as needed. For example, if the 930B registration is received only from the target sector in the initial in-use cluster, no further migration is needed. Alternatively, if the 930B registration is received from a non-target sector in the initial in-use cluster, the initial in-use cluster will be modified to migrate the non-target sector to the target sector, and if necessary. , Populate the supporting sector of the migrated target sector.

For example, FIG. 10B shows an example of an initial in-use cluster of target sectors T1 and support sectors N1 to N6 formed by 945B. In this example, further registration messages are assumed to be received from the target ATC in the unsupported sector X32 in Figure 10B. In this case, the resulting cluster or modified initial in-use cluster may be shown in Figure 10, where unsupported sector X32 migrates to target sector T2 and unsupported sectors X29-X31 also T2. Move to support sectors N7 and N8. In the following, the initial in-use cluster is generally referenced as if it corresponds to a cluster loaded from a previous session. However, the initial in-use cluster can also be expanded as shown in Figure 10 with the addition of sectors T2, N7 and N8, or alternative, of the target or supported sectors from the loaded cluster in the previous session. If one or more of these are removed, they can also be "plunged" as in Figure 8B (not explicitly shown in Figure 10C, but how this is achieved is immediately from the above disclosure. Will be clear).

Then, after forming a in-use cluster on the 945B, the RAN120 runs a BCH-flow on the 950B for a multicast communication session in the initial in-use cluster and belongs to the initial cluster but to the initial in-use cluster. No BCH-flow in non-affiliated sectors. After flowing the BCH-flow to the initial in-use cluster, the RAN120 runs the target and supported sector processes on each of the target and supported sectors. In general, each target sector and each support sector of the in-use cluster carries the BMCCS flow on the downlink broadcast channel BCH, so for Figure 10C, the RAN120 serves target sectors T1 to t2 and support sectors N1 to N8. Forward the multicast message to the base station.

As you can see, even if the initial use cluster overestimates the number of sectors that BCH-flow is required to support a multicast communication session, the initial use cluster is due to its formation. , Depends on the actual registration message from the target AT of the previous multicast session. Thus, carrying the multicast flow within the initial in-use cluster combines the benefits of Figures 9A and 7, so the forward capabilities of the RAN 120 are unlikely to be wasted as shown in Figure 7. On final registration, to the target AT in those sectors, apparently by preempting the BCH-flow among the sectors for which registration requests have not yet been received for the current session. Multicast messages can be served more quickly.

Then, in 955B of Figure 9B, the RAN120 updates the sector allocation of the initial in-use cluster during the multicast communication session (for example, adding a new target / supported sector, removing the target / supported sector, etc.) ). Again, a more detailed description of sector allocation updates is given in the co-pending application referenced above. Also, although not explicitly shown in Figure 9B, during an active multicast session, RAN120 maintains / updates the group member list based on GMN and route update messages received from multicast group members. continue.

At 960B, RAN120 determines whether to end the multicast session. For example, the 955B's decision can be based on whether the END message was sent from the application server 170. If RAN120 determines that the multicast session can continue at 960B, the process returns to 955B. Otherwise, if RAN120A determines to terminate the multicast session at 960B, then RAN120 is 965B and remembers the current sector formation of the cluster when the multicast session is terminated. The 965B's storage step can overwrite the stored cluster from the previous multicast session, so the newly stored cluster on the 965B will be the new previous session's cluster for this particular multicast group. Represent. As you can see, the cluster stored in the 965B can be used to generate an initial in-use cluster for the next multicast session, etc.

Also, as mentioned above with respect to Figure 7, in another example, in Figures 9A and / or 9B, the group member list requests or requires feedback from one or more multicast group members. RAN120 provides multicast group members with scheduling instructions that instruct multicast group members on how to respond to "interactive" multicast messages, such as announcement messages sent in 930A in Figure 9A or 930B in Figure 9B. May be used to For example, if a large number of multicast group members are expected to exist in a particular sector and an announcement message for a multicast session is sent within the sector, a relatively large number of multicast group members will respond to the announcement message and multicast. You may try to access the reverse link channel at the same time to subscribe to the session. However, with the information present in the group member list, the RAN120 can schedule a response sequence for the access terminal to respond to the announcement message via an "access control message" (ACM). For example, the RAN120 may send an ACM with an announcement message, which specifies a preferred response order with feedback slots for some access terminals based on the group member list. For example, in the group member list maintained by RAN120, the access terminal with the latest update for that position field (updated via, for example, GMN message, route update message, etc.) is granted the first response slot by ACM. The AT with the next updated position field may then be granted a second response slot by the ACM, and so on. ACM, and interactive multicast message feedback scheduling on reverse links, is available to the assignee of this application.

Those skilled in the art will appreciate that information and signals may be represented using any variety of different techniques and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description are voltages, currents, electromagnetic waves, magnetic fields or particles, light fields or particles, or any of them. It can be represented by a combination.

Moreover, one of ordinary skill in the art may implement the various exemplary logical blocks, modules, circuits, algorithmic steps described with respect to the embodiments disclosed herein as electronic hardware, computer software, or a combination of both. Good things will be understood. To articulate this hardware-software compatibility, various exemplary components, blocks, modules, circuits and steps have been generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the design constraints imposed on the particular application and the overall system. One of ordinary skill in the art may implement features described in different ways for each particular application, but judgment of such implementation should not be construed as deviating from the scope of the invention.

The logic blocks, modules and circuits described with respect to the embodiments disclosed herein are general purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or other programmable logic. It may be implemented or implemented with devices, individual gate or transistor logic, individual hardware components, or any combination thereof designed to perform the functions described herein. The general purpose processor may be a microprocessor, but as an alternative, the processor may be any conventional processor, controller, microcontroller or state machine. Processors are also implemented as 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. May be good.

The methods, sequences and / or algorithms described with respect to the embodiments disclosed herein may be embodied directly in hardware, in software modules executed by a processor, or in combination of the two. Software modules reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPRO memory, registers, hard disks, removable disks, CD-ROMs, or any other form of storage media known in the art. You may. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage media and write information to the storage media. Alternatively, the storage media may be integrated with the processor. Processors and storage media may reside in the ASIC. The ASIC may reside on a user terminal (such as an access terminal). Alternatively, the processor and storage media may 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 a combination thereof. When implemented in software, this feature may be stored or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable media include both computer storage and communication media, including any medium that facilitates the transfer of computer programs from one location to another. The storage medium may be any usable medium that can be accessed by a computer. By way of example, such computer-readable media are RAM, ROM, EEPROM, CD-ROM, or other optical disc storage device, magnetic disk storage device or other magnetic storage device, or format of instruction or data structure. Can be used to carry or store the desired program code in, and can include any other medium accessible by a computer. Also, any connection is strictly referred to as a computer-readable medium. For example, software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technology, such as infrared, wireless, and microwave. If so, coaxial cables such as infrared, wireless, and microwave, fiber optic cables, twisted pair, DSL, or wireless technology are included within the definition of medium. As used herein, discs and discs are compact discs (CDs), laser discs (registered trademarks), optical discs, digital versatile discs (DVDs), floppy (registered trademarks) discs, and Including Blu-ray discs, discs usually play data magnetically, and discs play data optically with a laser. The above combinations are also included within the scope of computer-readable media.

Although the above disclosure illustrates exemplary embodiments of the invention, various modifications and amendments have been made herein without departing from the scope of the invention as defined by the appended claims. obtain. The functions, steps and / or actions of the method claims according to embodiments of the present invention need not be performed in any particular order. Further, although the elements of the invention are described or claimed in the singular, the plural is contemplated unless a limitation to the singular is explicitly stated.

200 access terminal AT1,3,5 ~ N wireless mobile phone AT2 wireless tablet PC AT4 Wired Desktop Station 202 platform 206 transceiver 208 Application Specific Integrated Circuits (ASIC) 210 Application Programming Interface (API) 212 memory 214 local database 222 antenna 224 display 226 keypad 228 Push-to-talk button