KR100801870B1 - Method and apparatus for sending a multicast message - Google Patents

Abstract

The access point 102 conveys (202) a first indication to the communication units 104 of the plurality of multicast groups that the access point supports a method of transmitting a multicast message. The access point receives 204 a multicast message sent to a receiving group of the plurality of multicast groups, and determines that communication units belonging to the receiving group of the plurality of multicast groups support the method (206). . The access point signals a second indication for selectively awakening communication units belonging to the receiving group of the plurality of multicast groups (208), wherein at least one communication unit belonging to the receiving group of the plurality of multicast groups is The multicast message is transmitted 210 to a receiving group of the plurality of multicast groups in a way to remain dormant during transmission (212).

Multicast messages, multicast groups, access points, communication units, traffic specifications

Description

Method and apparatus for sending a multicast message

The present invention relates generally to communication systems, and more particularly, to a method and apparatus for transmitting a multicast message.

Prior art communication systems operating in accordance with the IEEE 802.11 standard handle broadcast (BC) and multicast (MC) messages differently from unicast messages. For unicast messages, an Association Identifier (AID) for a Communication Unit (CU) is mapped to a unicast medium access control (MAC) address and uniquely buffers the buffered unicast message. Used in Traffic Information (TIM) to identify. An AID of zero is used for BC and MC frames because they are addressed in a multicast group. This particular way of delivering MC / BC messages to the CU reduces the battery life of the CU. Typical examples of multicast groups are groups of devices receiving a common video stream, a group of devices in a conference call, or a group of devices in a multicast session, such as a dispatch group call. If multicast is used for CUs in one of the multicast groups using the currently defined MC / BC delivery mechanism of 802.11, the battery life of the other CUs in the other multicast groups is different even if the other groups are random multicast. Even without receiving traffic, it can be significantly affected.

The main cause of battery life loss is when an access point delivers an MC message with an AID of zero, all dormant CUs (i.e., CUs operating in battery saver mode) are placed in the particular multicast group where the MC message is present. Are awake until the CUs determine from the message content whether they belong. CUs that do not belong to a particular multicast group are awakened for undesirable reasons and will waste power unnecessarily.

Thus, a need exists for a method and apparatus for transmitting a multicast message. The method and apparatus will preferably solve the power wastage problem described above.

The accompanying drawings, in which like reference numerals refer to the same or functionally similar elements throughout the drawings and which are incorporated into and form a part of the specification, together with the following detailed description, further illustrate various embodiments and illustrate various embodiments in accordance with the invention Used to explain the principles and advantages.

1 is an electrical block diagram of an exemplary communication system.

2 is a flow diagram illustrating a method for sending a multicast message in a communication system.

3 is an electrical block diagram of an example access point supporting the method.

4 is an electrical block diagram of an exemplary communication unit supporting the method.

In general, the present disclosure relates to communication units, and more particularly to a communication system that uses receivers to provide services to a user operating therein. In particular, various inventive concepts and principles implemented as a method and apparatus for transmitting a multicast message for use in equipment with the communication system will be discussed and disclosed. Communication systems of a particular aspect have been developed and developed to operate on IEEE standards 802.11 and advances such as Wireless Multimedia Enhancement (WME), although the concepts and principles have been applied to other systems and devices.

This specification is provided to further explain in an implementation manner the best modes of making and using various embodiments in accordance with the present invention. The present disclosure is further provided to enhance the understanding and understanding of the principles and advantages of the present invention, rather than limiting it in any way. The present invention is limited only by the appended claims and equivalents thereof, including any corrections made while pending this application.

Use of related terms such as first and second, top and bottom, and so forth to distinguish one from another being or action without necessarily requiring or implying any actual relationship or order between the beings or actions It is further understood. Many inventive functions and many inventive principles may best be implemented in one or more conventional digital signal processors (DSP), or integrated circuits (ICs) such as application specific ICs. Guided by the concepts and principles disclosed herein, one of ordinary skill in the art, despite the considerable effort and many design choices caused by, for example, the time available, current technology, and economic considerations, It is expected that ICs can be formed with minimal experimentation. Therefore, in view of reducing and minimizing any risk of obscuring the principles and concepts according to the present invention, further discussion of the DSPs and ICs is essential to the principles and concepts implemented by the preferred embodiments. Will be limited.

Referring to FIG. 1, an electrical block diagram includes a plurality of access points (APs) 102 providing wireless communication with communication units (CUs) 104 in corresponding plurality of coverage areas 106. An example communication system 100 is shown. The APs 102 are coupled to each other and optionally to an intranet or the Internet 112 via a communication path 114, eg, an Ethernet link coupled via a router 110. Some embodiments may include a gateway 108 capable of handling some of the functionality generally present in APs of embodiments that do not use the gateway 108. Wireless communication between the APs 102 and the CUs 104 preferably uses a protocol similar to that described in the well-known IEEE 802.11 specification, modified according to the present invention.

2 illustrates a new method of sending a multicast message to communication system 100. The multicast message is defined here as the message to be received by the selected CUs 104 assigned to the multicast group address to which the multicast message is sent. The multicast message is distinguished from the broadcast message to be received by all CUs 104. The communication system 100 supports sending multicast messages from the AP 102 to CUs 104 belonging to a plurality of multicast groups each having a multicast address. The method selectively awakes dormant (ie, power saving) CUs 104 belonging to a particular multicast group.

The flow chart begins by delivering 202 a first indication to a plurality of multicast groups of CUs that an AP supports the method. In one embodiment, the delivery is accomplished by potentially receiving a response by the AP from a particular command sent by a CU belonging to a multicast group. The command is preferably one of (a) join request, (b) rejoin request, and (c) traffic specification (TSPEC) for the multicast group sent by a CU belonging to the multicast group. The AP 102 receives, from a CU belonging to a multicast group, a first command for assigning a multicast group a private address associated with the CU for transmitting a unicast message, ie a message intended only for the CU. When the first command is one of a recombination request and a join request all defined in the IEEE standard 802.11, the AP combines the multicast group with a private address. This double / multiple combined identifier (DAID / MAID) preferably awakens selectively, CUs belonging to a multicast group, as further described below.

When an AP receives a multicast message sent to a receiving group of a plurality of multicast groups (204), the AP preferably determines whether CUs belonging to the receiving group of the plurality of multicast groups support the method ( 206). This may be accomplished by the AP in various ways, such as receiving, snooping, or observing a message from a CU belonging to a receiving group of a plurality of multicast groups, where the message is an Internet Group Multicast Protocol (IGMP) connection. One of the recombination request, which includes a command, a traffic specification, a placeholder for additional instructions, a join request, and information indicating that the CU supports the method. Optionally, this may be achieved by verifying, by the AP, receiving, snooping or observing a command from a CU belonging to a receiving group of the plurality of multicast groups, i.e., including a protocol version indication, and supporting the method. have. In addition, this may be accomplished by determining whether the multicast address of the receiving group of the plurality of multicast groups is included in the configured set of multicast addresses of known multicast groups to support the method.

The AP then sends a second indication indicating, for example, the private address of each of the CUs belonging to the multicast group, thereby providing a second to selectively awake all CUs belonging to the receiving group of the plurality of multicast groups. Signal an indication (208). The AP then transmits the multicast message to the receiving group of the plurality of multicast groups using the MC address of the receiving group of the plurality of multicast groups (210). In this way, any of the plurality of multicast groups that do not belong to the receiving group are put to sleep 212 during transmission. In another embodiment, the AP 102 sends a second indication to a multicast address of a receiving group of the plurality of multicast groups, received by one or more groups, or by a receiving group of a plurality of multicast groups. The second indication is signaled (208) by sending it to another known multicast address.

Optionally awakened CUs are programmed to awake long enough, for example to receive a plurality of closely spaced MC messages. This may be accomplished by the use of a timer and / or a counter. These awakened CUs can be programmed to remain awake until the detection of the next DTIM beacon or the end of the session.

Prior art 802.11 systems set the traffic indicator bit corresponding to the association ID (0) to 1 when sending a multicast message. This allows all dormant CUs, used by the AP sending the multicast message to determine if the CUs belong to the multicast group to which the message is sent, awake and listen to the contents of the message frames later. The communication system according to the present invention leaves a traffic indicator bit corresponding to the association ID (0) set to zero when transmitting the multicast message. This preferably extends battery life by allowing all dormant CUs to sleep, except for CUs to which a multicast message is sent.

When the CU 104 determines that a session with a multicast group has ended, for example by receiving a session indication end, the CU responds to the AP 102 to detach the multicast group from the CU's private address. 2 Commands can be sent. The second command is preferably a separation request as defined by the IEEE standard 802.11. In response to receiving the second command, the AP 102 separates the multicast group from the private address, for example by removing the corresponding cross reference from the lookup table of the AP.

In another embodiment, passing the first indication that the AP supports the method to a plurality of CUs of the multicast groups is informed by the AP to all CUs in the communication system to specifically inform the CUs for which the method is supported. It includes broadcasting. This may obviously be an optional awake support indication message that repeatedly broadcasts to all CUs that support the messages. It may also be an indication, such as a flag or value, inserted into the generic or DTIM beacons broadcasted by the AP regularly. CUs supporting the method are programmed to correctly interpret the support message of the beacon indication as indicating that the AP supports the optional awake method. The AP further conveys the indication by broadcasting or multicasting a specific system name, service configuration identifier (SSID), protocol version, or protocol variant, and CUs supporting the method indicate that the AP supports an optional awake method. It is programmed or configured to correctly interpret the indication as an indication.

In another embodiment, APs 102 and CUs 104 are statically configured to support the method. This may be done during initial installation of communication system 100, or during initial operation of CUs 104. For example, multicast group addresses may be assigned to fixed and reserved bit positions of the bit map.

In another embodiment, the APs 102 may send a unicast message to each CU of the MC group indicated by the form or message content in which the AP supports the method.

In another embodiment, signaling a second indication by the AP to selectively awaken CUs belonging to a receiving group of a plurality of multicast groups is such that the receiving group of the plurality of multicast groups to which a multicast message is sent. Encoding the multicast address of. The encoding of the multicast address may include setting the bit position of the bitmap. The set bit position must be different from the bit position awakening all the CUs, all the CUs interested in broadcasting, or all the CUs belonging to any multicast group. In another variation, the encoding of the multicast address may include forming a compressed representation of the multicast address through well known techniques.

It is noted that prior art 802.11 systems do not support sending and receiving traffic specification (TSPEC) requests for multicast addresses. When the AP 102 receives a TSPEC request for at least one of the plurality of multicast groups from a CU belonging to at least one of the plurality of multicast groups and approves the TSPEC, the transmission of the multicast message is performed as follows. . The AP sends the multicast message as an unbuffered multicast message when the TSPEC for the multicast group to which the multicast message is sent is approved; And send the multicast message as a buffered multicast message when the TSPEC is not approved for the multicast group to which the multicast message is sent. When sending messages in unbuffered mode, the AP will send messages at the same rate as the receive rate, rather than storing for later transmission (while allowing proper priority for QoS). For example, when the multicast messages are vocoder packets received by the AP at 20 ms rate, the AP will send vocoder packets to the multicast group at the same rate. In addition, when the AP receives a TSPEC request for one of the plurality of multicast groups, the AP retransmits the TSPEC to one of the plurality of multicast groups. This informs the rest of the CUs to the multicast group where the TSPEC is in place and the rest of the CUs do not require TSPEC.

3 is an electrical block diagram of an exemplary AP 102 supporting the method described herein. The AP 102 includes a communication interface 302 for handling communications with other portions of the communication system 100 via the communication path 114. The AP 102 further includes a processor 304 coupled to the communication interface 302 to process communication and control the AP 102. In addition, the AP 102 includes a transceiver 306 coupled to the processor 304 to communicate with the CUs. The AP 102 includes a memory 308 that contains instructions and data executable for programming the processor 304 in accordance with the present invention. Optionally, it will be appreciated that the communication interface 302, the processor 304, the transceiver 306, and the memory 308 may be combined in whole or in part as an integrated circuit.

Memory 308 includes a communication control program 310 for programming the processor 304 to control the communication of the AP 102 in accordance with the present invention. The memory 308 further includes a DAID / MAID processing program 312 for programming the processor 304 to perform dual / multiple combined identifier (DAID / MAID) processing for multicast messages as disclosed herein. . In addition, the memory 308 includes a multicast address encoding program 314 for programming the processor 304 to encode a multicast address in accordance with some embodiments of the present invention. The memory 308 preferably includes a traffic specification (TSPEC) processing program 316 for programming the processor 304 to process TSPEC requests in accordance with the present invention.

4 is an electrical block diagram of an exemplary CU 104 supporting the method. The CU 104 includes a processor 404 for controlling the CU 104. The CU 104 further includes a transceiver 406 coupled to the processor 404 to communicate with the AP 102. In some embodiments, CU 104 includes a user interface 402 that includes some known elements, such as a keypad, display, and audio transducers. In addition, the CU 104 includes a memory 408 coupled to the processor 404 that includes executable instructions and data for programming the processor 404 according to the present invention. In the alternative, it will be appreciated that the processor 404, the transceiver 406, and the memory 408 may be manufactured and combined in whole or in part as an integrated circuit.

The memory 408 includes a communication control program 410 for programming the processor 404 to control the communications of the CU 104 in accordance with the present invention. The memory 408 preferably further comprises a DAID / MAID processing program 412 for programming the processor 404 to perform double / multiple combined identifier (DAID / MAID) processing for multicast messages as disclosed herein. Include. In addition, memory 408 includes multicast address decoding programming 414 for programming processor 404 to decode multicast addresses in accordance with some embodiments of the present invention. The memory 408 includes a traffic specification (TSPEC) processing program 416 for programming the processor 404 to process TSPEC requests in accordance with the present invention.

In more detail, a DAID / MAID embodiment for sending multicast messages uses some aspects of the IEEE 802.11 specification. It is now appropriate to discuss some acronyms, terms and definitions of the 802.11 specification. One term is binding. The 802.11 specification requires that once a mobile station identifies and authenticates a compatible network, it attempts to connect the network identified by the service set identifier (SSID) by sending a join request frame. Another term is the association ID (AID). As part of the association request, the AP assigns an AID to the requesting CU. For buffered frames, the destination node (CU) AID provides a logical link between the AP and the CU. In prior art 802.11 systems, both BC and MC frames are forwarded with AID = 0. Another term is separation. The 802.11 specification specifies that mobile stations moving between basic service areas within some extended service areas need to rejoin the network before using the distribution system. Mobile stations need to rejoin if they temporarily leave the access point's coverage area and later reconnect.

The AP, having received the MC packet and determined that there are double / multiple combinations of the MC group address (MC MAC address) and a combination of the stored AID and the MC MAC address of the CU, sets the appropriate AID bit in the traffic information (TIM) frame and The process of delivering standard 802.11 specific unicast for delivering packets to the combined CU.

Data Coupling ID (DAID) / Multiple Coupling ID (MAID): In one embodiment of the present invention, the modified behavior of an AP may provide multiple bonds to the AID mapped to the unicast MAC address of the CU after combining with the AP. will be. DAID / MAID preferably allows MC frames to be clearly communicated to the CU in a similar manner to unicast frames using the same AID. When a CU is supplied with a multicast group address (eg, corresponding to a dispatch group call ID) of a message sent by a system call control function (CCF), the CU is multiplied in the "Current MAC Address" field of the reassociation request frame. It will rejoin with the same AP by supplying a cast MAC address.

After receiving a recombination frame having a destination address (MAC address of the AP), a source address (MAC address of the CU), and the AP's current MAC address (including a multicast group address), the AP is between this MC group address and the conventional joint ID of the CU. Will form a bond. After completion of the dispatch group call, the CU may detach the multicast MAC address from the AID by sending a detach request frame. It is noted that the standard detach request frame with 802.11 defined reason codes (0-9) will detach the unicast MAC address of the CU with the removed AID. Optionally, the AP may perform MAID combining based on the destination MAC address of the received MC message frame. This can be used as a double check for the AP.

This disclosure relates to multicast group addresses assigned to CUs in a group for a limited period of time as transient multicast group addresses. Providing a second combination of transient multicast group addresses for the AP is called a double bond; The double bond ID (DAID) is called an AID. Similarly, a CU may send multiple recombination requests to combine multiple multicast MAC addresses with an AID. Using AIDs and multiple combinations to dynamically combine multiple multicast group addresses (permanent and permanent multicast groups as well as transient multicast groups such as those used for sports, news, securities and other information delivery). It is possible. In general, broadcast (emergency, etc.) multicast group addresses will be pre-allocated and not part of semi-permanent multicast group addresses.

Multicast Group (MCG) Recombination: A CU will be reassigned with an AP defined according to the 802.11 specification. There is no change in CU or AP behavior when the CU recombines with the AP according to the 802.11 specification. However, the CU needs to recombine with the same AP when one request is received to associate the MC group address. The MC group address may be sent by the session controller before the start of the dispatch group session (or some multicast group addresses may be pre-assigned if a sports / news / stock or other location based services is ordered and used). . The CU will rejoin the currently joined AP using the 'current MAC address' set to the multicast MAC address (formed using the multicast group address). After receiving the recombination request, the AP will recombine the multicast group address to the CU's assigned AID and form a double bond. In a similar manner, "semi-permanent" multicast group addresses can be combined with the AID of the CU and form multiple bonds with the AID. Therefore, by simply sending a reassignment request to the same AP, the CU can form multiple bonds with the unicast AID.

Multicast Group (MCG) Separation: Separation frames are used to terminate the association relationship. It contains a 16-bit reason code field that provides arguments for separating these frames. Codes 0-9 have already been assigned and defined. Codes 10-65535 are not used. Separation of MAC address (standard as defined by 802.11) will terminate all associations with AID with termination of the AID assignment itself. However, multicast group MAC address separation is achieved by the CU by sending a separation request frame to an AP with a predetermined one of currently unused reason codes (range 10-65535). Multiple multicast combinations can be similarly separated by sending different separation frames (different reason code) and the AP will first remove the final combination (semi-permanent MC group). However, semipermanent multicast MAC addresses will typically not be required to be segregated due to the previously mentioned argument. If these multicast addresses are preconfigured, the corresponding multicast MAC address combination with the AID may be semi-permanent within the AP.

BC forwarding remains the same as currently forwarded for the MC / BC forwarding mechanism using a forwarding traffic information frame (DTIM) beacon frame. AID = 0 will indicate the broadcast address for broadcasting only frame delivery. Therefore, the DTIM Beacon frame can now be adjusted to any number of fixed beacon frames according to the requirements for application to broadcast dispatch services without affecting the battery life of the CU. Typically, because broadcast services are rarely used; The battery life of the CU will not be affected. The selective awake method has the additional advantage that once selective awake is made, multicast messages for CUs supporting the method can be initiated after any beacon frame. Therefore, there is no need to delay startup until after DTIM beacons, thus improving system response to multicast.

When the CU enters WLAN coverage, it begins to associate with the AP after authentication. As an AP combining portion, receives an AID mapping corresponding to the MAC (logical bit mapping) address of the association request response frame.

In this embodiment, the behavior of the AP and the CU is slightly changed to perform two combinations (by recombination). The second join will occur when the CU obtains a session control message for joining the multicast group as part of a group session (such as a dispatch group call) or learns the MC group address in another conventional manner. At this point the CU will rejoin the current AP using the MC MAC address in the Current AP MAC Address field. After this recombination, the AP maps the MAC address / MC group address to the AID mapping of the CU. Thus, a CU may be in a group session and a unicast session, and the same AID may send MC and unicast frames to the CU (e.g., a user of the CU may continue to watch multicast sports while making a unicast voice call). Can be used to deliver. The AP sets the AID bit of the TIM frame when the corresponding MAC group address message is received for downlink transmission. This can be repeated for as many CUs as the CUs are included in the MC group session with which the AP has completed reestablishment using the MC MAC group address. It is noted that because the AP awakens the MC MAC address binding of all CUs associated with the AP, how many groups of CUs exist; Downlink retransmission of uplink transmission MC messages can be completely avoided, for example, if only one CU exists. It is also important that the CU performs separation with the AP for the MC group address after the group session is terminated.

The AP will send an MC group message (received in the uplink message) on the downlink only when there are other MC group combinations found in the AID list. These MC messages are transmitted unicast to the group's multicast address, setting the AID bits of all CUs with group members in unicast fashion.

After authentication, the CU completes association with the AP and obtains an AID mapping from the AP in the general manner as specified by 802.11. After receiving a simple group session preset message (including the MC group address mapped to the dispatch group call ID) from the call control function (CCF) or otherwise learning the multicast group address, the CU is configured to use the Internet Group Multicast Protocol (IGMP). The MC group (identified group session identification in the message) is connected by advertising to the edge router through the < RTI ID = 0.0 > All CUs belonging to a specific MC group address connect the MC group by the IGMP protocol.

The CU sends a recombination frame to the AP to create an assigned AID and DAID / MAID combination. Typical group session operation proceeds with the original CU sending a multicast message (audio packets) to the AP. The AP, knowing the association with the multicast MAC address of the received MC packet, will forward this message in the downlink direction using the multicast address while setting the individual AID bits of the CUs that are DAID / MAID associated with the AP. After completion of the session, all CUs belonging to the corresponding MC group session will send a detach request as previously specified to remove the DAID / MAID combination.

For embodiments using the traffic specification (TSPEC), some other details are provided below. TSPEC is a specification maintained at the AP of packets forwarding requests belonging to a particular uplink or downlink connection. Typical TSPECs include normal mobile station data unit (MSDU) sizes; Maximum MSDU size; Minimum service interval; Maximum service interval; Inactivity intervals; Minimum data rate; Average data rate; Maximum burst size; Minimum PHY speed; Peak data rate; Delay limit; And the remaining bandwidth allowance. In addition, the TSPEC may use a traffic classification (TCLAS) element that describes which packets should obtain preferential TSPEC processing (802.11e, Annex I). For IP, TCLAS can include source and destination IP addresses and ports indicating Layer 3 quality of service (QoS); Protocol (UPD / TCP); Version; Diffserv code point (DSCP) values and TOS values are included (layer 3).

Operation according to the present invention is as follows. The CU detects the need to receive multicast packets with high QoS. By way of example, a CU may receive a Session Initiation Protocol (SIP) invitation or Session Ad Protocol (SAP) that initiates a voice session or other form of session. The message specifies that session packets are sent to a particular multicast address. As another example of an integrated enhanced digital network (iDEN) context, the CU receives an iDEN group call page request indicating the use of a multicast address. It is assumed that all CUs that receive the advertisement message are awake during the session and that other dormant CUs that do not belong to the group are still dormant.

The CU sends a TSPEC (ADDTS) request added to the AP to add TSPEC for real-time protocol (RTP) voice packets of the session with TCLAS describing the multicast and DSCP / TOS to be used. The AP allows TSPEC requests. If the AP has the bandwidth available for the session, it will allow TSPEC.

Preferably, the AP resends the request on the downlink to the (layer 2) multicast address. In this way the request will be received by other CUs describing the session multicast address. Stations implementing the present invention that detect the same ADDTS request as the ADDTS need to send themselves will no longer send the request. This preferably prevents the remaining TSPEC traffic. In contrast to typical uplink multicast packets, the AP does not distribute ADDTS to an extended set of services (ESS). In this way TSPEC requests will be generated independently at the individual APs.

The AP responds to the ADDTS request with an ADDTS response to indicate that it allowed the TSPEC request. Again, preferably the response is sent to a layer 2 multicast address so that all the number of CUs will know that the TSPEC has been approved.

When the AP receives the multicast packets for the downlink transmission, transmits the multicast according to the TSPEC; Although CUs (not members) can sleep, the AP does not buffer packets. Instead, the AP transmits the retained packets as a regular stream of suitable (eg 20 ms) intervals. In this way, CUs that are group members will receive sessions with high QoS. If there are any dormant (nonmember) CUs, the AP keeps them dormant. In particular, in 802.11 compliant systems, even though sending multicast packets (of course, the AP does not need to set the traffic indicator bit to 1 for related reasons such as the need to broadcast a message to all CUs), the AP goes to zero. Is set and the traffic indicator bit corresponds to association ID 0.

When a member CU learns that a group session has elapsed (prior art means such as a BYE message), the CU must remove the TSPEC with the DELTS request. Again, preferably the CU sends the request to a layer 2 multicast address, and the AP echoes the request to that address. Preferably the AP sends a good response to the multicast address.

Another way for an AP not to buffer multicast packets in the presence of dormant CUs is to use a set of reserved multicast addresses. The AP consists of one or more (IP or Layer 2) multicast addresses that must be handled differently. When the AP receives a downlink packet with a destination address that is the same as one of the reserved multicast addresses, the AP does not buffer the packet but transmits with proper priority to the QoS indications of the packet.

It is assumed that CUs are awake when notified of an incoming session. Thus, member CUs will be surprised to know that retained packets determine high QoS in an unbuffered mode, for example in bursts buffered every 300ms.

It should be noted that the initial advertising message (invitation, SAP, iDEN page) should not be missed by dormant member CUs. Thus some variations are:

In a first variant, the system uses different multicast addresses for initial advertisement and retention. The multicast address used for the advertisement is not reserved. Thus, the AP will properly buffer the advertisement if there are any dormant CUs. In a variant of this variant, all future signaling messages (free channel, grant) will be sent on the reserved multicast address used for the holder.

In another variation on this implementation, the AP behavior is based on a combination of reserved multicast addresses and QoS indications. The AP does not buffer multicast packets with high priority (streaming and conversation). The AP will buffer signaling messages such as session advertisement messages (invitation, SAP, iDEN page) on the multicast address. However, these messages have lower, interactive or best effort QoS.

For embodiments that encode and decode a multicast address, the following additional information is provided. One solution is to list all group addresses and compress each multicast address to limit the number of bits used. Obviously some information will be lost if the number of bits is less than the number of most significant bits of the original multicast address. As a result of this loss of information, several groups may share the same compressed multicast address. Undesirably, the CU decodes and awakes one or more compressed multicast addresses. The CU even exits sleep mode in less time than this, resulting in reduced overall power consumption and increased battery life.

AP and CU should use the same compression method. The AP compresses the original group addresses; List the results; The results are sent over the air. The CU compresses the addresses of the groups that are members and checks if they are in the transmitted list. If in the list, the CU is awake to check for future transmitted multicast frames; If not, you can go back to sleep.

There are many compression methods that can be used. For example, to obtain an 8 bit compressed address, one may take the 8 least significant bits of the original address. To get better hashing, MOD (original multicast address / 7, 256) can be used.

The number of compressed address bits can be fixed by the protocol. A better solution is to allow the AP to dynamically determine the number of bits. The AP can do this by determining the "object density" in the list. If N bits are used, there are 2 ^ N compressed addresses. Density is the number of compressed addresses in the list divided by 2 ^ N. Must be << 1 because, when there are no packets, too many CUs will match the (compressed) multicast address to the (compressed) address of the list, so that the AP should have a density of <0.01, preferably Will select N. When calculating 'N', the AP will preferably take into account the average number of groups per CU, when the CU has many group addresses, it is more likely to match the compressed addresses in the list, and the AP will High value N should be used.

The preferred implementation of this embodiment adds additional virtual bitmaps for multicast to those already used for unicast. The multicast bitmap has M bits. The AP and CUs use a common algorithm to map the original (layer 2 or layer 3) multicast addresses to the number 'b' in the range [0, (M-1)]. Many algorithms can be used, for example b = MOD (original multicast address, M) and b = MOD (original multicast address / 7, M). The AP will set the bits of the virtual multicast bitmap corresponding to the multicast addresses to which data will soon be sent. The CU must check whether the bit of the map is set and corresponds to any multicast addresses. If applicable, awake and find multicast data for one or more multicast addresses.

Again, for a small value of M, there are many opportunities for the CU to awake because there are packets for other multicast addresses that map to the same bit 'b' as one of the CU's multicast addresses. The AP should use M to make this opportunity small. The AP may determine this by finding the 'density' of the virtual multicast bitmap (part of the set bits). The AP may adjust M and inform the CUs of the new value. In determining M, the AP may use knowledge about a typical number of groups of CUs.

In 802.11, a CU will move from one AP to another. The CU must know whether or not the AP uses the present invention, since if the AP does not use the present invention, the CU must go back to the previous method leading to reduced battery life. Therefore, the AP must broadcast the information using the present invention. This information needs to be sent in beacon frames where there is an uncompressed address bit or virtual multicast bitmap.

The list or bitmap needs to be displayed in beacon frames following actual multicast frames. An independent method should be used to ensure that destination CUs are awake at the time of display. One such independent method is the DTIM counter already defined in 802.11. The other is to use TSPEC for multicast. The AP may use a mechanism to compress the virtual bitmap if it is rare. Many algorithms use to compress long strings of 'zero' bits.

With regard to handover, when the CU moves from the coverage area of one AP to the coverage area to the next AP, the multicast setup process, which is preferably suitable for the embodiment described above, will be repeated entirely in the new AP. Optionally, when a CU moves from one AP coverage area to a coverage area of the next AP, a call setup context can be sent from one AP to the next AP.

Thus, this is evident from the previous disclosure in which the present invention provides methods and apparatuses for transmitting multicast messages. The methods and apparatuses preferably solve the power waste problem associated with transmitting multicast messages in prior art communication systems.

This disclosure is intended to explain how to fashion and use various embodiments in accordance with the invention rather than being true, intended, and limiting in many scope and spirit. The above description is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications or variations are possible due to the above teachings. The embodiments have been selected and described in order to provide the best illustration of the principles and practical application of the invention, and enable those skilled in the art to use the invention in various embodiments and various modifications suitable for the particular application contemplated. All such modifications and variations are within the scope of the invention as determined by the appended claims, which may be amended during patent application, and all equivalents when interpreted according to the fair, logical, and equivalent scope included. have.

Claims (10)

In a communication system, a method for supporting transmission of multicast messages from an access point (AP) to communication units (CUs) belonging to a plurality of multicast groups each having a multicast address, the method comprising: In the method for supporting multicast message transmission, which selectively awakes CUs belonging to a specific multicast group: Conveying a first indication to the CUs of the plurality of multicast groups that the AP supports the method; Receiving, by the AP, a multicast message directed to a receiving group of the plurality of multicast groups; Determining, by the AP, CUs belonging to the receiving group of the plurality of multicast groups also support the method; Signaling, by the AP, a second indication to selectively awaken CUs belonging to the receiving group of the plurality of multicast groups; Sending, by the AP, the multicast message to the receiving group of the plurality of multicast groups; And And causing at least one CU not belonging to the receiving group of the plurality of multicast groups to remain asleep during the transmission. The method of claim 1 wherein said delivering step is: A specific command sent by a CU belonging to a multicast group specification among the traffic specifications for a multicast group, an association request and a reassembly sent by a CU belonging to the multicast group by the AP; Positively acknowledging a Reassociation Request; Broadcasting, by the AP, information to all CUs of the communication system; And And statically configuring the AP and the CUs to support the method. The method of claim 1, Receiving, by the AP, a first command for combining the multicast group with a private address associated with the CU to send a unicast message from a CU belonging to a multicast group; Combining, by the AP, the private address and the multicast group in response to receiving the first command; Determining, by the CU, that the session with the multicast group has ended; Sending, by the CU, a second command to the AP to detach the multicast group from the private address in response to determining that the session has ended; And In response to receiving, by the AP, the second command, separating the multicast group from the private address; And the signaling step includes transmitting a second indication indicative of the private address. The method of claim 1, Receiving, by the AP, a traffic specification (TSPEC) request, and Approving the TSPEC in response to the request; The transmitting step is: When the TSPEC is approved for the multicast group to which the multicast message was sent, sending the multicast message as an unbuffered multicast; When the TSPEC is not granted for the multicast group to which the multicast message was sent, sending the multicast message as a buffered multicast; And Retransmitting, by the AP, a received TSPEC request for one of the plurality of multicast groups to the one of the plurality of multicast groups. A specific multi multi access point (AP) that supports transmission of multicast messages from an access point (AP) in a communication system to communication units (CU) belonging to a plurality of multicast groups each having a multicast address. In the access point (AP), which supports a method of selectively awakening CUs belonging to a cast group: A communication interface for handling communication with other parts of the communication system; A processor coupled with the communication interface to process the communications and to control the AP; And A transceiver coupled to the processor for communicating with the CUs, The processor is: Convey a first indication to the CUs of the plurality of multicast groups that the AP supports a method for selectively awakening CUs belonging to the specific multicast group; Receive a multicast message sent to a receiving group of the plurality of multicast groups; Determine that CUs belonging to the receiving group of the plurality of multicast groups also support the method; Signal a second indication for selectively awakening CUs belonging to the receiving group of the plurality of multicast groups; Send the multicast message to the receiving group of the plurality of multicast groups; And be programmed to cooperate with the transceiver to cause at least one CU not belonging to the receiving group of the plurality of multicast groups to remain dormant during the transmission. The processor of claim 5, wherein the processor is: Receive, from a CU belonging to a multicast group, a first command to join the multicast group with a private address associated with the CU to send a unicast message; Combine the private address and the multicast group in response to receiving the first command; Send a second indication indicative of the private address; Receive a second command from the CU for separating the multicast group from the private address; And further programmed to detach the multicast group from the private address in response to receiving the second command. The processor of claim 5, wherein the processor is: Encode a multicast address of the receiving group of the plurality of multicast groups to which the multicast message is sent; Set a bit position of a bitmap to encode the multicast address; An access point (AP) further programmed to form a compressed representation of the multicast address to encode the multicast address. The processor of claim 5, wherein the processor is: Receive a traffic specification TSPEC request for the at least one of the plurality of multicast groups from a CU belonging to at least one of the plurality of multicast groups; Approving the TSPEC in response to the request; When the TSPEC is approved for the multicast group to which the multicast message is sent, sending the multicast message as an unbuffered multicast; When the TSPEC is not granted for the multicast group to which the multicast message is sent, sending the multicast message as a buffered multicast; An access point (AP) further programmed to retransmit a received TSPEC request for one of the plurality of multicast groups to the one of the plurality of multicast groups. A communication unit (CU) that supports sending multicast messages from an access point (AP) in a communication system to communication units (CU) belonging to a plurality of multicast groups each having a multicast address, the multicast group In the communication unit (CU), which supports a method for selectively awakening CUs belonging to: A processor for controlling the CU; And A transceiver coupled to the processor for communicating with the AP, The processor: when the CU belongs to the multicast group, A traffic specification for the multicast group; Coupling requirements; And A communication unit (CU) programmed to cooperate with the transceiver to send one of a reassociation request to the AP. 10. The system of claim 9, wherein the processor is: Send a first command to the AP to join the multicast group with a private address associated with the CU to send a unicast message; Determine that a session with the multicast group has ended; In response to determining that the session has ended, further programmed to send a second command to the AP to detach the multicast group from the private address.

Images