Title of Invention

METHOD AND SYSTEM FOR MULTICASTING MESSAGES TO SELECT MOBILE RECIPIENTS

Abstract An improved mechanism for transmitting data to multiple mobile stations in a cellular wireless communication network is disclosed. In an exemplary embodiment of the invention, a network entity (26) maintains a record of which mobile stations are in a given multicast group and a record of which sectors (“sectors of interest”) are currently serving one or more mobile stations of the multicast group. Each such mobile station receives a key to facilitate receipt of a multicast or broadcast message. A message is then multicast or broadcast to only the sectors of interest. (FIG. 2)
Full Text METHOD AND SYSTEM FOR MULTICASTING
MESSAGES TO SELECT MOBILE RECIPIENTS
BACKGROUND
1. Field of the Invention
The present invention relates to telecommunications and, more particularly, to a
method and system for broadcasting or multicasting a message to a specific group of mobile
stations in a cellular wireless communications system.
2. Description of Related Art
The advent of wireless telecommunications, such as cellular telephony, has extended
the functionality available to wireless users: Just as a user can operate a cellular telephone
or other mobile station (MS) to place a voice call to virtually any telephone number, a user
can also operate a suitably equipped MS (such as, for example, a web-enabled wireless
telephone) to place a data call to virtually any remote computer. Once such a connection is
established, a remote computer can send data to the MS, much as a remote computer might
send data to any personal computer connected to the Internet.
In a typical cellular radio communications system (i.e., a wireless
telecommunications network), an area is divided geographically into a number of cell
sectors, each defined by a radio frequency (RF) radiation pattern or air interface from a
respective base transceiver station (BTS) antenna. A number of MSs (such as cellular
telephones, personal digital assistants (PDAs) and/or other devices) may operate
concurrently in a given cell sector, all communicating via the air interface with a common
BTS. In turn, the BTSs from a number of cell sectors may communicate concurrently with a
common base station controller (BSC), which may function to aggregate and control traffic
for the multiple BTSs. A number of BSCs may then communicate concurrently with a
common gateway, such as a packet data serving node (PDSN) or mobile switching center
(MSC), which may function to set up and connect communications to or from other entities.
The BTS, BSC and gateway, in combination, comprise a radio network that provides
network connectivity for an MS.
Generally, a user"s MS is allocated a dedicated channel over which data may be sent
and received. However, there are a number of specialized services that multiple wireless
customers may find desirable. Examples of services that may be sent to multiple users
could include:
• Location-based advertising;
• Vertical services, maintenance, and administrative messages
• Public information services, such as sports scores, traffic conditions, weather
alerts, etc.;
• Video clips of newsworthy events; and
• Audio and video streaming.
In some specialized services, a number of MSs in a cell sector (or even all customers
in the cell sector) would receive the same message. This does not present much of a
problem when only a few users are to receive the data, but can tax a network"s capacity as
more users receive the same message. One resource that can be taxed is the air interface.
The air interface between MSs and the radio network is a scarce resource, and its use should
be conserved whenever possible. In addition, as high-bandwidth applications become more
commonplace, the capacity between other entities and links in wireless communications
networks may also be taxed. As an example, if a BTS is to support a number of concurrent
high-bandwidth communications with multiple MSs, the link between the BTS and the BSC
must support all of that traffic at once.
The link between a BTS and BSC, though, is typically a transmission line with a
finite bandwidth. Similarly, the link between the BSC and a gateway such as a PDSN or
MSC is typically a transmission line with finite bandwidth. Of course, it is possible to
increase traffic capacity between various network elements by simply adding more
transmission lines. Adding transmission lines, though, can be very expensive, since it
requires a provider to either physically add the lines, or to lease additional lines from a local
exchange carrier (LEC). Leasing lines from LECs to increase the traffic capacity between
network elements can, in fact, be a significant portion of a cellular provider"s total operating
cost.
Thus, when a particular message (especially, but not necessarily, one requiring a
significant amount of available bandwidth) is to be sent to a relatively large number of MSs
within a cell sector (or to multiple cell sectors), a system for transmitting the message that
conserves the cellular system"s bandwidth is a significant improvement over a multicast
system that transmits messages to cell sectors indiscriminately. Moreover, it would also be
desirable to control which users have access to specialized services so that users who want
such services can be required to pay for them, and also so that users who do not want the
services are not bothered by unwanted messages.
SUMMARY
The present invention is directed to an improved mechanism for transmitting data to
multiple MSs in a cellular wireless communication network. The invention generally does
this by (i) maintaining in a network entity a record of which MSs are in a given multicast
group, (ii) maintaining in a network entity a record of which sectors are currently serving
one or more members of the multicast group (which can be referred to as "sectors of
interest"), (iii) providing each such MS with a key to facilitate receipt of a multicast or
broadcast message, and (iv) multicasting or broadcasting the message to only the sectors of
interest. Various network arrangements and processes can be employed to carry out these
functions.
In an exemplary embodiment, each message that is to be sent can be an IP message,
sent over a PPP channel to a 3G MS. The PPP channel could be established between a
PDSN and the 3G MS. In this regard, the basic network architecture can include multiple
BTSs coupled to a BSC. The BSC may then be coupled to the PDSN, which in turn is
coupled to a packet-switched network such as the Internet. (The BSC may also be
conventionally coupled to an MSC, which provides circuit-switched connectivity with the
public-switched telephone network (PSTN) as well).
In the exemplary embodiment, to achieve the functions described above, the basic
architecture of a cellular communications network can be modified to include the following:
(a) a Radio Network Multicast Server (RNMS) communicatively coupled with, or integrated
into, the BSC, (b) a Multicast Session Manager (MSM) communicatively coupled with the
PDSN, (c) a Multicast Application Server (MAS) communicatively coupled with the PDSN;
and (d) an MS client, for filtering (for example, at the radio link layer) incoming messages
on a broadcast channel, so that higher levels of the protocol stack receive a given broadcast
message only if the filter allows it. In the exemplary embodiment, valuable network
resources can be conserved by transmitting multicast or broadcast messages only to BTSs
that serve cell sectors with MSs of the multicast groups present in those cell sectors. For
example, if MSs authorized to receive a particular multicast service are present in a first cell
sector, but no such MSs are present in a second cell sector, the message will only be sent to
the first cell sector. Thus, all of the entities and communication links between at least the
BSC and the BTS of the second cell sector will not experience any increase in traffic due to
the messages sent to MSs in the first cell sector.
These as well as other aspects and advantages of the present invention will become
apparent to those of ordinary skill in the art by reading the following detailed description,
with appropriate reference to the accompanying drawings.
Accordingly, the present invention provides a method comprising the steps
of: maintaining, in a first network entity, a first record of multicast addresses, the
first record comprising at least one multicast address ; maintaining, in a second
network entity, a second record of cell sectors that are currently serving one or
more mobile stations that are associated with at least one multicast address in the
first record ; and transmitting at least one multicast message to the cell sectors
that are included in the second record ; whereby the at least one multicast
message is transmitted from each cell sector included in the second record to
mobile stations within those cell sectors.
The present invention also provides in a network of the type comprising a
packet-switched network and a radio network having multiple cell sectors serving
mobile stations, a method comprising the steps of : maintaining, in a network
entity, a first record of multicast addresses, the first record comprising at least one
multicast address ; maintaining, in a network entity, a second record of cell sectors
that are currently serving one or more mobile stations that are associated with at
least one multicast address in the first record ; updating the second record as the
one or more mobile stations move into and out of cell sectors ; and transmitting at
least one IP multicast message to only the cell sectors that are included in the
second record.
The present invention further provides a communications device for use in
a communications network of the type comprising a radio network that has at least
one cell sector that serves mobile stations, the device comprising : a processor; a
memory ; at least one multicast address stored in the memory ; at least one cell
sector identifier stored in the memory, the at least one cell sector identifier
corresponding to a multicast address stored in the memory ; and a set of logic
stored in the memory and executable by the processor to cause the device to
forward multicast packets having a multicast address that is the same as a stored
muticast address to each cell sector that is identified by a cell sector identifier that
corresponds to the stored multicast address.
The present invention still further provides a radio network multicast server,
comprising : a processor; a memory ; the at least one multicast address stored in
the memory ; at least one cell sector identifier stored in the memory, the at least
one cell sector identifier corresponding to a multicast address stored in the
memory ; a set of logic stored in the memory and executable by the processor to
cause the radio network multicast server to forward multicast packets having a
multicast address that is the same as a
stored muticast address to each cell sector that is identified by a cell sector
identifier that corresponds to the stored multicast address ; a network interface ;
and a set of logic stored in the memory and executable by the processor to cause
the radio network multicast server to communicate with other entities via the
network interface and to responsively update the at least one multicast address
stored in the memory and to responsively update any cell sector identifiers stored
in the memory that correspond to the at least one multicast address ; wherein the
radio network multicast server transmits messages to cell sectors according to the
cell sector identifiers stored in the memory.
The present invention still further provides a wireless multicast system of the
type comprising a radio access network and a packet-switched network, the
system comprising : a radio network multicast server, the radio network multicast
server having a first record of multicast addresses, the first record comprising at
least one multicast address ; the radio network multicast server having a second
record of cell sectors that are currently serving one or more mobile stations that
are associated with the at least one multicast address in the first record, the
second record linking cell sectors to specific multicast addresses in the first
record ; and the at least one mobile station that is served by a cell sector that is
included in a second record in the radio network multicast server; wherein at least
one multicast message is transmitted to the at least one mobile station in
accordance with the first record and the second record.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
An exemplary embodiment of the present invention is described herein with reference
to the drawings, in which:
Figure 1 is a simplified block diagram of a communication system for carrying
communications between a mobile station and remote network entities in which the
exemplary embodiment can be implemented;
Figure 2 is a block diagram of a radio network multicast server for use in accordance
with the exemplary embodiment;
Figure 3 is a simplified block diagram of a mobile station suitable for use with the
exemplary embodiment;
Figure 4 is a flow chart depicting functions performed in accordance with the
exemplary embodiment;
Figure 5 is a block diagram of database table that may be used in the exemplary
embodiment; and
Figures 6 through 8 are flow charts depicting functions performed in accordance
with the exemplary embodiment.
DETAILED DESCRIPTION OF
AN EXEMPLARY EMBODIMENT
Preferring to the drawings, Fig. 1 is a generalized block diagram of a communication
network 10 suitable for communications between one or more MSs and various network
entities. As shown in Fig. 1, the network 10 may include a radio network that comprises
various network entities, such as: base transceiver stations (BTSs) 20, 22, and 24; radio
network multicast router/server (RNMS) 26; base station controller (BSC) 28; and packet
data serving node (PDSN) 30, such as a CommWorks® Total Control® 2000 or the like. In
addition, BSC 28 may be coupled to a mobile switching center (MSC) such as MSC 40, as
in conventional cellular networks. Because BTSs 20, 22, 24, BSC 28, PDSN 30, and MSC
40 can be conventional components of a radio network, they are not described in detail here.
PDSN 30 serves as an interface between the radio network and a packet-switched
network such as packet-switched network 36 (which may be the Internet). In the exemplary
embodiment, a multicast application server (MAS) such as MAS 38, an authentication,
authorization, accounting (AAA) server such as AAA server 34, and a multicast session
manager such as MSM 32 may be communicatively coupled to packet-switched network 36
(and thus ultimately to the radio network via PDSN 30). It should be noted that MSM 32,
AAA server 34, and MAS 38 are functional entities, and any or all of the functions
performed by these entities could be integrated into a single entity (or other, multiple
entities that perform one or more of the functions in combination). Furthermore, any or all
of MSM 32, AAA server 34, and MAS 38 could be directly coupled rather than via
packet-switched network 36.
For clarity only, multiple network entities, such as RNMSs, PDSNs, BSCs, MSMs,
and MASs have been omitted from the drawings, although a network in which the invention
may be implemented could include more than one RNMS, PDSN, BSC, MSM, and MAS.
MAS 38 may generally store and periodically transmit a range of multicast content
for reception by MSs that belong to a multicast group, each multicast being associated with
a particular IP multicast address. MAS 38 may be a server on the IP core network (i.e., the
Internet). In the exemplary embodiment, MAS 38 may not be co-located with a particular
RNMS, although it could be. Instead, MAS 38 would be regionally placed and could thus
be more readily accessed by multiple RNMSs via conventional network routers (not shown)
within packet-switched network 36.
MSM 32 can provide, upon request from MSs, keys, filters, or masks needed by MSs
to enable them to receive multicasts. MSM 32 may be in communication with AAA server
34 and can thus verify that any mobile station requesting to join a multicast group is
authorized to join the group by communicating with AAA server 34
RNMS 26 may access a record or records that correlate radio network cell sectors of
interest with particular multicast addresses. RNMS 26 signals the packet-switched network
to receive multicast data packets sent from MAS 38 that have multicast addresses that
correspond to sectors of interest, as indicated by the record or records. Upon receipt of such
multicast packets, RNMS 26 may forward copies of the multicast packets to sectors of
interest.
AAA server 34 may be a conventional component as described for a third-generation
wireless system in ITU IMT-2000 requirements document Q.I701. AAA server 34
generally maintains account and authorization information as well as user profiles for MSs
served by the radio network. For example, AAA server 34 could maintain a record of
which, if any, multicasts an MS is authorized to receive, as well as for how long. Thus, if a
user wished to terminate a multicast service at the end of a given billing period, AAA server
34 could update its record at the end of the period and the MS"s request for multicasts
beyond the billing period would not be authorized.
MSs 12, 14, 16, and 18 may access the packet-switched network 36 or another
network, such as the PSTN (not shown), via the radio network. In operation, an MS may
send, via a BTS or BSC, a "join" message to RNMS 26, indicating a request to join a
particular multicast group. The join message may be an IP message transmitted via a
common channel in the radio network. When a BTS or BSC receives such a join message,
the BTS or BSC may programmatically add to the IP message an indication of the MS"s
current cell sector; the join message may then be forwarded to RNMS 26. As MSs join a
given multicast group, RNMS 26 could thus get an indication of which cell sectors currently
serve those MSs. RNMS 26 can maintain this information in the form of a database table
that lists, for each multicast group, the cell sectors currently serving MSs that are in the
multicast group. RNMS 26 could be updated in real time (described in detail below) as
multicast group MSs move through the network, ensuring efficient use of the radio network.
The connections of all the entities shown in Fig. 1 are logical rather than physical; as
just one example, RNMS 26 could be physically connected between BSC 28 and PDSN 30
without affecting the functionality of the present invention.
Within network 10, multiple communications devices, such as MSs 12, 14, 16,
(wireless telephones) and 18 (a web-enabled PDA), may be communicatively coupled with
BTS 20, 22, and 24 as shown. Although MSs 12, 14, and 16 are illustrated as wireless
telephones, they may take any suitable form, such as (without limitation) wireless modems,
wireless PDAs (like MS 18), or two-way pagers. MSs 12-18 may communicate with BTS
20-24 using an air interface as set forth in TIA/EIA/IS-2000. Further, MSs 12-18 could be
part of a cellular system that uses another technology, such as AMPS, TDMA, DECT,
GSM, PCS, or PWT; the cellular technology used is not necessarily critical to all
embodiments of the present invention. Although MSs 12-18 are capable of normal voice
communications via BSC 28 and MSC 40, this description will focus primarily on data
communications using the network entities of network 10.
In the exemplary embodiment, MSs could join multicast groups as follows. A user
with an MS, such as MS 12, might initiate a request to receive a multicast by, for example,
turning on the MS or selecting a menu item on the MS"s display. The request may include
an option service code or other indicator that indicates packet-data. The request could first
be forwarded from BSC 28 to MSC 40. MSC 40 may detect the option service code (or
otherwise detect a data call) and responsively signal BSC 28 to send the message to PDSN
30 (rather than to MSC 40 as in a voice call). A PPP session could then be established
between MS 12 and PDSN 30.
Next, a client (i.e., a set of software instructions) on MS 12 could set up a data
communication session with MSM 32 via BTS 20, BSC 28, PDSN 30 and packet-switched
network 36. MSM 32 could then authorize the user for access to private (or other) group
multicasts, and transmit (using TCP/IP or a standard internet key exchange protocol, for
example) a key or filtering mask to MS 12 during the data communication session to enable
MS 12 to receive multicast or broadcast packets. MSM 32 could implement the
authorization process by communicating with a registrar, such as AAA server 34, which
may maintain records of which users are authorized to receive multicasts, among other
records (e.g., subscriber profiles). MS registration could also occur with other types of
registrars, such as a home location register or a service agent (not shown). As an alternative
to "on-the-fly" MS registration, an MS could be pre-provisioned by a service provider-that
is, the MS could have a key or mask installed at a facility rather than over a communication
channel.
Multicast messages may originate as follows. Periodically, or based on triggers from
other network entities or MSs, MAS 38 may transmit multicast content to a conventional
router (not shown) within packet-switched network 36. As an illustration, assume that only
MS 12 and MS 18 are authorized to receive private group multicasts with a particular
multicast address. RNMS 26 could receive the multicast content transmitted from MAS 38
via packet-switched network 36. When RNMS 26 receives an IP multicast packet from
packet-switched network 36, it may send duplicates of the packet to each cell sector that is
bound to the particular IP multicast address, as indicated in a database table, in this case, the
cell sectors serving MS 12 and MS 18. Thus, multicast packets may be sent from BSC 28 to
BTS 20 and BTS 24 (and received by MS 12 and 18, within those sectors), but none are sent
from BSC 28 to BTS 22, because BTS 22 is not serving any multicast group members.
A simplified block diagram of RNMS 26 is shown in Fig. 2. The exemplary
embodiment of RNMS 26 shown in Fig. 2 may have a processor 44 (e.g., an integrated
circuit microprocessor), a memory 46 (e.g., memory module, ROM, RAM, flash memory,
hard disk), a radio network data link interface 48, and a packet-switched network interface
42, all of which may or may not be interconnected by a system bus. Memory 46 may
include more than one physical element, such as built-in ROM, RAM, a hard disk, an
optical drive, a removable memory device, etc., and may also include as stored content: one
or more multicast addresses, one or more cell sector identifiers; a set of stored logic by (e.g.,
computer instructions) executable by processor 44 to accept inputs via radio network data
link interface 48 to update the information stored in memory 46 and to carry out various
other functions described herein. The multicast addresses and cell sector identifiers may or
may not be stored in the form of a database table, where each multicast address has one or
more cell sector identifiers associated with it in the table. Provided with the present
disclosure, those skilled in the art can readily prepare appropriate computer instructions to
perform the functions described herein.
The radio network data link interface 48 may include input and output ports and
individual links for each cell sector associated with RNMS 26. The individual links may be
either logical or physical.
RNMS 26 may send multicast routing control packets to PDSN 30 and to packet-
switched network 36 via packet-switched network interface 42. The multicast routing
control packets may then be received by MAS 38, in order to establish multicast paths from
MAS 38 to RNMS 26 via packet switched network 36 and PDSN 30. RNMS 26 may then
receive (at packet-switched network interface 42) IP multicast packets transmitted from
MAS 38. The packet-switched network interface 42 may also be connected directly to the
packet-switched network, bypassing PDSN 30.
The particular configuration shown in Fig. 2 is not necessarily critical to the
functioning of all embodiments of the present invention. For example, a device without a ,
system bus that has a memory and processor contained in one integrated circuit could be
used instead of a separate processor and memory.
Referring now to Figure 3, a functional block diagram of an exemplary MS, such as
MS 12 or MS 18, is shown. As illustrated, the MS may include a processor 50, memory 52,
a wireless communications interface 54, and a local communications interface 56, all of
which may be coupled together via a system bus 58. Each of these functional components
may take any of a variety of forms.
Memory 52, for instance, may include a set of machine language instructions
executable by processor 50 to carry out various functions described herein. (Alternatively
or additionally, the MS can embody various combinations of hardware, firmware and/or
software to carry out the functions described). Further, memory 52 may include other
elements, such as a multicast client that processes IP multicast or broadcast data and
presents it to a user. Memory 52 may comprise one or more volatile or non-volatile
elements, such as flash memory, optical memory, or magnetic storage.
Wireless communications interface 54 may establish communications with the radio
network via an air interface. As such, wireless interface 54 may comprise software logic
(e.g., CDMA encoding logic) and/or may comprise a transceiver suitable for interfacing
between processor 50 and a radio frequency antenna (not shown).
For use in an alternative exemplary embodiment, local interface 56 may function as
a port for sending and receiving communications with a service provider"s computer (not
shown). Local interface 56 may comprise a conventional pin-out port, an infrared port, an
Ethernet (RJ-45) port, or any other suitable interface. Software keys, masks, or filters that
enable the MS to receive and process multicast messages may be installed in the MS via
local interface 56.
In the exemplary embodiment, the MS may be at least a 3G (or, more generally, a
broadband) MS. A 3G MS has the capability of establishing, maintaining, and terminating
packet data sessions with PDSNs. An MS that is less than a 3G MS could also be used in
the exemplary embodiment, although data throughput may be lower.
Figure 3a illustrates a mobile IP protocol reference model that may be used with the
exemplary MS to communicate with the PDSN 30. A similar protocol model could be used
by the exemplary MS to communicate with the RNMS 26, except the PPP layer might not
be used or may be replaced with a multicast data link layer protocol specific to the radio
network used. As described, the exemplary MS may have a client or another component
that enables it to establish, maintain, and terminate a PPP session with PDSN 30; the client
may also enable the MS to receive (via the PDSN 30) and store a transmitted key or mask
that allows the MS to receive and process multicast and/or broadcast data sent to it via
RNMS 26. Specifically, a transmitted "key" could activate a process in the MS to cause it
to recognize, at the MS"s IP layer, datagrams with a particular multicast address. In such an
implementation, the MS may have a fixed, relatively small number of multicast addresses
that it may selectively listen for based on keys it may receive. Once activated to listen for
certain multicast packets, multicast packets with the particular multicast address could be
received by the client in the MS (i.e., the packets could be passed up the protocol stack to
the client for further processing). In MSs that have not received a key, multicast packets
could simply be discarded at the IP layer.
The application of a key or mask to pass authorized multicast data to the MS
application may alternatively be performed at the data link protocol layer instead of at the IP
protocol layer. In order for the radio network to transmit a multicast packet from the RNMS
26 to the MS, the radio network may require the use of a multicast group identifier at the
data link layer. In that case, this multicast link layer identifier could be used instead of the
multicast IP address in the filtering mechanism. Each IP multicast group address could have
a corresponding link layer identifier, with each determinable from the other based on a
simple translation algorithm.
As an alternative to pre-configured multicast addresses, a multicast address could be
transmitted to, and stored in, the MS as a result of a registration and authorization from a
network entity such as MSM 32 or AAA server 34. Once a multicast address is stored in the
MS, the filtering of messages could proceed as described above. As yet another alternative
to software filtering, multicast or broadcast packets could be filtered by a hardware device
(such as a digital signal processor, or DSP) in the MS. As is known to skilled persons, such
filtering can be performed at various different protocol layers; thus, filtering techniques
other than those described here could also be implemented in the exemplary embodiment.
Figure 4 illustrates generally a set of functions that may be involved in an exemplary
embodiment of the present invention. At step 60, MSs, such as MS 12 and MS 18 may
request authorization to participate in a particular multicast group. A network entity, such
as MSM 32, may receive the authorization request via PDSN 30 and packet-switched
network 36. MSM 32 may verify, by communicating with AAA server 34, that MS 12 and
18 are authorized to receive the requested multicast messages, step 62. Once MS 12 and 18
are recognized by MSM 32, MSM 32 can send a filtering key or mask to MS 12 and MS 18,
as shown at step 64 and described in detail above, to allow those MSs to further process
multicast messages.
Then, at step 66, MS 12 and 18 may send "JOIN" messages to RNMS 26. As
illustrated by step 68, MAS 38 may, based on either time or an event trigger (such as receipt
of new data via packet-switched network 36), transmit multicast data to RNMS 26 via
packet-switched network 36 and PDSN 30. At step 70, when RNMS 26 receives multicast
data, it may route the data to only those cell sectors currently serving MSs that have
requested (by sending "join" messages) to receive the multicasts. RNMS 26 is capable of
making such routing decisions because it maintains (or has access to, via another network
entity) a record that correlates particular multicast groups (by multicast address) to sectors
of interest. A simplified example of such a record is shown in Table 1 of Fig. 5. Further,
RNMS 26 may be a multicast-aware router/server, i.e., a router/server that can actively
signal a packet network to receive multicast packets with destination addresses within the IP
multicast range of 224.0.0.1 through 239.255.255.255.
In the exemplary embodiment, multicast data could be sent to BTS 20 and 24, which
serve sectors of interest, but not to BTS 22, since MS 14, served by BTS 22, has not
requested the multicast via a "join" message. Once BTS 20 and BTS 24 receive multicast
packets, the packets may be forwarded to MS 12 and MS 18, respectively, and MS 12 and
18 may receive and further process the multicast packets (for example, by formatting and
displaying, on MS 12 and 18, information contained in the packets in human-readable
form), as shown at step 72.
Fig. 6 illustrates a set of functions that may be involved in enabling an MS to receive
and process multicast messages. At step 80, an MS may send an origination (or registration)
message, via air an interface, to BSC 28, which can then forward the message to an MSC
40. More specifically, to initiate registration in a multicast group, a user could, for example,
select a menu item on the MS, causing a registration message to be sent to MSC 40 via BSC
28. The origination/registration message may include information in a service option as
defined by TIA/EIA-95, TIA/EIA-2000, or an equivalent standard, to determine that the call
is a data call, rather than a voice call, as shown at step 82. MSC 40 can be configured to use
this information and responsively send a message to BSC 28 to cause BSC 28 to transmit
the data call to PDSN 30, as shown at step 84, rather than routing the call into the PSTN.
Alternatively, MSC 40 could detect a data call using information other than that contained
in a service option. For example, MSC 40 could recognize a data call based on the contents
of OSI layer 4 (the transport layer). The method used to determine that a call is a data call is
not necessarily critical to all embodiments of the present invention. PDSN 30 and the
registering MS can then set up a PPP session, at step 86, and a client on the MS can set up a
TCP/IP session with MSM 32, via PDSN 30 (step 88).
Next, as shown at step 90, MSM 32 can communicate with a registrar such as AAA
server 34 (either via packet-switched network 36, another suitable data link, or direct
connection) to determine that the MS is authorized to join the multicast group. AAA server
34 can maintain, separately or as part of a subscriber profile, a record of MSs that are
authorized members of particular multicast groups. This information can be passed from the
AAA server to MSM 32, making MSM 32 aware that a particular MS or group of MSs are
authorized to receive multicast messages. Alternatively, the registrar function of AAA
server 34 could be incorporated into MSM 32. Once MSM 32 recognizes an MS as an
authorized group member, MSM 32 can transmit to the MS a filtering key/mask to the MS
to enable it to receive and process multicast messages, as shown at step 92. If a multicast
message reaches an MS in a sector of interest and the MS does not have a filtering
key/mask, the MS will be unable to further process the message. In other words, the
message will not effectively be received at an unauthorized MS.
The architecture of the present invention also supports data broadcasting as well as
cell-specific multicasting. For example, RNMS 26 can interpret a broadcast-specific IP
address as an address whose data is to be forwarded to all cell sectors. For filtering at the
MS at the data link layer, a common link-layer broadcast identifier that would pass through
all MS filters can be used by RNMS 26 when it forwards broadcast packets, enabling all
MSs to further process the broadcast data. As another example, multicasts may be
designated for all MSs at particular cell sectors—e.g., for public announcements on traffic
conditions. For cell-specific multicasts, RNMS 26 may recognize that packets with certain
IP multicast addresses are to be forwarded to specific cell sectors only. In that case, sectors
20 and 24 in Table 1 would be sectors of interest not due to the presence of MSs that are
multicast group members, but because the multicast address 224.1.2.3 is "linked" to those
sectors. Thus, multicast information that is only pertinent to a particular geographic area
will not follow users as they move out of the area.
To facilitate the routing of multicast messages, RNMS 26 may use IETF
Protocol-Independent Multicast to advertise to IP core routers the presence of multicast
group members on the radio network.
Some steps that may be involved in the process of an MS joining a multicast group
are illustrated in Fig. 7. First, an MS may send a "Join" message to RNMS 26 to indicate
that it is ready and authorized to receive multicast messages (step 100). More specifically,
the MS may send an IP-encapsulated IETF Internet Group Membership Protocol format
message in radio network link layer framing to a BTS or BSC 28 over an access channel (or
other common channel) in the radio network. When a BTS or BSC 28 receives the join
message, either the BTS or BSC 28 may modify or encapsulate the message (e.g., add
additional data in the link layer framing of the packet data being sent) with an indicator or
identifier defining the MS"s current cell sector. The message can then be forwarded to
RNMS 26, as shown at step 102. Next, RNMS 26 can update its database table to include
the MS"s current sector as a sector of interest so that multicasts intended for the MS will be
routed to that sector, as shown at step 104. The database table update could also include
adding or deleting multicast addresses as necessary to maintain accuracy.
Figure 8 illustrates some functions that may be used to ensure that the multicast
database is current even after MSs leave and enter sectors of interest. As shown at step 110,
a network entity such as RNMS 26 (or another entity, via the BTS), can periodically
multicast queries, such as internet group management protocol (IGMP) queries, to a cell
sector or sectors to determine if there is still at least one MS in a sector that is a multicast
group member. If there is no such MS in the sector, the RNMS will be "aware" that the
sector is no longer a sector of interest, as shown at step 112. If the sector is no longer a
sector of interest, RNMS 26 could update its database table to remove the cell sector and
stop routing multicast messages to the associated BTS, as shown at step 114. Conversely, if
there is at least one MS in a queried sector that is a multicast group member, RNMS 26
could update its database table to add the sector as a sector of interest if the sector was not a
sector of interest prior to the query, as shown at step 116.
Thus, RNMS 26 could maintain the accuracy of a database table in substantially
real-time as MSs move through the network.
An exemplary embodiment of the present invention has been described above.
Those skilled in the art will understand, however, that changes and modifications may be
made to this embodiment without departing from the true scope and spirit of the present
invention, which is defined by the claims.
WE CLAIM :
1. A method comprising the steps of:
maintaining, in a first network entity, a first record of multicast addresses,
the first record comprising at least one multicast address ;
maintaining, in a second network entity, a second record of cell sectors that
are currently serving one or more mobile stations that are associated with at least
one multicast address in the first record ; and
transmitting at least one multicast message to the cell sectors that are
included in the second record ;
whereby the at least one multicast message is transmitted from each cell
sector included in the second record to mobile stations within those cell sectors.
2. The method as claimed in claim 1, comprising the steps of:
providing each of the one or more mobile stations with a key that enables a
mobile station to receive and to further process multicast messages ; and
receiving and further processing, at the mobile stations that have been
provided with a key, the at least one multicast message.
3. The method as claimed in claim 1, wherein the at least one multicast
message is an IP message.
4. The method as claimed in claim 1, wherein at least one of the mobile
stations in the multicast group is a 3G mobile station.
5. The method as claimed in claim 1, wherein the step of maintaining the
second record comprises periodically querying cell sectors to determine the
current location of mobile stations associated with multicast addresses that are
included in the first record.
6. The method as claimed in claim 1, comprising the steps of :
sending, from a mobile network to a network entity, an indication that
represents a user"s request to join a multicast group, the indication being sent to a
network entity; and
using the indication to update the first record and the second record.
7. The method as claimed in claim 1, wherein the first network entity is the
second network entity.
8. In a network of the type comprising a packet-switched network and a radio
network having multiple cell sectors serving mobile stations, a method comprising
the steps of:
maintaining, in a network entity, a first record of multicast addresses, the
first record comprising at least one multicast address ;
maintaining, in a network entity, a second record of cell sectors that are
currently serving one or more mobile stations that are associated with at least one
multicast address in the first record ;
updating the second record as the one or more mobile stations move into
and out of cell sectors ; and
transmitting at least one IP multicast message to only the cell sectors that
are included in the second record.
9. The method as claimed in claim 8, wherein updating the second record
comprises periodically querying cell sectors to determine the current location of
mobile stations that are associated with the multicast addresses that are included
in the first record.
10. The method as claimed in claim 8, comprising the steps of :
sending, from a mobile network to a network entity, an indication that
represents a user"s request to join a multicast group ; and
using the indication to update the second record.
11. The method as claimed in claim 8, comprising the steps of :
transmitting, from a network entity to each mobile station associated with a
multicast address in the first record, a key that enables the mobile station to
receive and further process multicast messages ;
whereby the at least one IP multicast message from each cell sector
included in the second record to mobile stations within those cell sectors, and
whereby mobile stations that have received the key receive and further process
the at least one IP multicast message.
12. A communications device for a communications network of the type
comprising a radio network that has at least one cell sector that serves mobile
stations, the device comprising :
a processor;
a memory;
at least one multicast address stored in the memory ;
at least one cell sector identifier stored in the memory, the at least one cell
sector identifier corresponding to a multicast address stored in the memory ; and
a set of logic stored in the memory and executable by the processor to
cause the device to forward multicast packets having a multicast address that is
the same as a stored muticast address to each cell sector that is identified by a
cell sector identifier that corresponds to the stored multicast address.
13. The communications device as claimed in claim 12, comprising :
a network interface ; and
a set of logic stored in the memory and executable by the processor to
cause the device to communicate with other entities via the network interface and
to responsively update the at least one multicast address stored in the memory
and to update any cell sector identifiers stored in the memory that correspond to
the at least one multicast address.
14. A radio network multicast server, comprising :
a processor;
a memory;
the at least one multicast address stored in the memory ;
at least one cell sector identifier stored in the memory, the at least one cell
sector identifier corresponding to a multicast address stored in the memory ;
a set of logic stored in the memory and executable by the processor to
cause the radio network multicast server to forward multicast packets having a
multicast address that is the same as a stored muticast address to each cell sector
that is identified by a cell sector identifier that corresponds to the stored multicast
address ;
a network interface ; and
a set of logic stored in the memory and executable by the processor to
cause the radio network multicast server to communicate with other entities via the
network interface and to responsively update the at least one multicast address
stored in the memory and to responsively update any cell sector identifiers stored
in the memory that correspond to the at least one multicast address ;
wherein the radio network multicast server transmits messages to cell
sectors according to the cell sector identifiers stored in the memory.
15. A wireless multicast system of the type comprising a radio access network
and a packet-switched network, the system comprising :
a radio network multicast server, the radio network multicast server having a
first record of multicast addresses, the first record comprising at least one
multicast address ;
the radio network multicast server having a second record of cell sectors
that are currently serving one or more mobile stations that are associated with the
at least one multicast address in the first record, the second record linking cell
sectors to specific multicast addresses in the first record ; and
the at least one mobile station that is served by a cell sector that is included
in a second record in the radio network multicast server;
wherein at least one multicast message is transmitted to the at least one
mobile station in accordance with the first record and the second record.
16. The system as claimed in claim 15, comprising a multicast application
server communicatively coupled to the radio network multicast server;
wherein the at least one multicast message is transmitted from the multicast
application server.
17. The system as claimed in claim 15, wherein the at least one mobile station
sends an indicator to network entity, the indicator causing the radio network
multicast server to add the at least one mobile station"s cell sector to the second
record.
18. The system as claimed in claim 15, wherein a multicast session manager
communicatively coupled to the at least one mobile station, the multicast session
manager transmitting to the at least one mobile station a key that enables the at
least one mobile station to receive and further process multicast messages.
19. The system as claimed in claim 18, comprising a AAA Server
communicatively coupled with the multicast session manager, the AAA server
providing a multicast authorization status indicator associates with the at least one
mobile station to the multicast session manager;
wherein the key is only transmitted to those mobile stations authorized by
the AAA server to receive multicast messages.
An improved mechanism for transmitting data to multiple mobile stations
in a cellular wireless communication network is disclosed. In an exemplary
embodiment of the invention, a network entity (26) maintains a record of which
mobile stations are in a given multicast group and a record of which sectors
("sectors of interest") are currently serving one or more mobile stations of the
multicast group. Each such mobile station receives a key to facilitate receipt of a
multicast or broadcast message. A message is then multicast or broadcast to
only the sectors of interest.

Documents:

427-kolnp-2004-granted-abstract.pdf

427-kolnp-2004-granted-assignment.pdf

427-kolnp-2004-granted-claims.pdf

427-kolnp-2004-granted-correspondence.pdf

427-kolnp-2004-granted-description (complete).pdf

427-kolnp-2004-granted-drawings.pdf

427-kolnp-2004-granted-examination report.pdf

427-kolnp-2004-granted-form 1.pdf

427-kolnp-2004-granted-form 18.pdf

427-kolnp-2004-granted-form 3.pdf

427-kolnp-2004-granted-form 5.pdf

427-kolnp-2004-granted-gpa.pdf

427-kolnp-2004-granted-letter patent.pdf

427-kolnp-2004-granted-reply to examination report.pdf

427-kolnp-2004-granted-specification.pdf


Patent Number 214988
Indian Patent Application Number 00427/KOLNP/2004
PG Journal Number 08/2008
Publication Date 22-Feb-2008
Grant Date 20-Feb-2008
Date of Filing 31-Mar-2004
Name of Patentee SPRINT SPECTRUM L.P.
Applicant Address 6450, SPRINT PARIWAY, OVERLAND PARK KS 66251 USA.
Inventors:
# Inventor's Name Inventor's Address
1 MANGAL NAN ISH 13170 HADLEY 2828 OVERLAND PARK USA
2 O! CONNOR KEVN R 11725 SOUTH SHANNAN STREET APT 817 OLATHE KS 66062 USA
PCT International Classification Number H04B7/00
PCT International Application Number PCT/US02/30131
PCT International Filing date 2002-09-19
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 09/993, 213 2001-11-16 U.S.A.