Selecting a packet data serving node for multi-cast/broadcast services

ES 2 316 624 T3

DESCRIPTION

Selecting a packet data service node for multicast / broadcast services.

Background

Field

The present invention relates to wireless communication systems in general and specifically, to methods and apparatus for transmitting messages in a wireless communication system.

Background

There is an increasing demand for packet data services over wireless communication systems. Since traditional wireless communication systems are designed for voice communications, expanding to support data services introduces many challenges. Conserving bandwidth is the overwhelming concern of most designers. In one-way transmissions, such as broadcast transmissions, a single broadcast content is provided to multiple users. Users are identified by a unique identifier, which is then included in the addressing information. In such a system, multiple infrastructure elements may be required to duplicate broadcast packets to identify each of the multiple intended recipients. Duplication of transmission signals consumes valuable bandwidth thereby reducing the efficiency of the communication system, and increases the processing requirements of intermediate infrastructure elements. For a particular broadcast service, the number of target recipients can be prohibitively large, thus creating resource allocation problems and loss of available bandwidth.

There is a need, therefore, for an efficient and accurate method of transmitting data to multiple recipients in a wireless communication system. In addition, there is a need for a multi-user broadcast data routing method, in which each user is uniquely identified as a target recipient. Attention is further drawn to WO 01/78322, which discloses a method for initial assignment and reselection of packet data serving nodes in a wireless communication system. The method is implemented in a packet control function within a third generation CDMA radio access network. The methodology reduces the number of point-to-point re-establishments when a mobile station roams to a different packet area / packet control function. The procedure generates a table of packet data service node identification numbers cross-referenced to Internet protocol addresses, which resides in each packet control function. A packet data serving node id number is selected from the table using the international mobile station identifier of the mobile station as the key to effect the selection.

Furthermore, attention is drawn to the document by Garcia-Luna-Aceves et al: “Multi-cast routing protocol for ad-hoc networks”, proceedings IEEE infocom '99. Conference on computer communications, 18th annual joint conference of the IEEE computer and communications societies. New York, March 21-25, 1999, proceedings IEEE infocom, Conference on Computer Communications, Volume 2, March 21, 1999, pages 784-792, XP010323814. The document describes a Core Assisted Mesh Protocol (CAMP) for multicast routing in ad hoc networks. CAMP generalizes the notion of core-based trees introduced for Internet multicasting into multicast meshes that have much richer connectivity than trees. A shared multicast mesh is defined for each multicast group; The main objective of using such meshes is to maintain the connectivity of the multicast groups even when the network routers are frequently moving. Within a group's multicast mesh, packets from any source in the group are forwarded following the shortest reverse path to the source, just like in traditional source-based tree-based multicast protocols. CAMP guarantees that, within a finite time, each receiver in a multicast group has a shorter reverse path to each source in the multicast group. Multicast packets for a group are forwarded following the shortest paths from the sources to the receivers defined in the group mesh. CAMP uses cores only to limit the traffic necessary for a router to join a multicast group; kernel failure does not interrupt packet forwarding or multicast mesh maintenance.

According to the present invention, there is provided a method for establishing transmission paths, as set forth in claims 1 and 6, and an infrastructure element, as set forth in claims 9 and 10. Preferred embodiments of the invention are disclosed in dependent claims.

Summary

The invention is defined by the independent claims.

Brief description of the drawings

Figure 1 is a diagram of a spread spectrum communication system supporting a number of users.

ES 2 316 624 T3

Figure 2 is a block diagram of the communication system that supports broadcast transmissions.

Figure 3 is a model of the protocol stack for a broadcast service option in a wireless communication system.

Figure 4 is a flow chart for a message flow for broadcast service in a wireless communication system topology.

Figure 5 is a functional diagram of a wireless communication system that supports broadcast transmission with broadcast content multicast Internet Protocol transmission.

Figure 6 is a wireless communication system that has multiple PDSNs that can communicate with a given PCF.

Figure 7 is a flow chart for selecting one of multiple PDSNs that can communicate with a given PCF.

Detailed description

The term "exemplary" is used exclusively herein to indicate "by way of example, case, or illustration." Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

Efficient use of available bandwidth affects system performance and breadth. To this end, various techniques have been applied to reduce the size of overhead information transmitted along with the data or content information. For example, in a digital transmission, the data is transmitted in frames. An information frame typically includes header information, payload data information, and a tail portion. The frames can be part of a data packet, part of a data message, or be continuous frames in a continuous stream of information, such as audio and / or video streams. Attached to each data frame (and to each packet or message) is a header that contains processing information that allows the receiver to understand the information contained in the frame (s). This header information is considered overhead, that is, processing information transmitted together with information content. The information content is called the payload.

The data frames are transmitted throughout the communication system through various infrastructure elements. In a conventional system, the transmission of information to multiple users requires duplication of the information at a central packet data control point, such as a packet data service node (PDSN). Duplication increases the processing requirements of the PDSN and wastes valuable bandwidth. For example, expanding a given system may require sizing routers and trunks near a PDSN sufficiently to handle duplicate traffic. The PDSN transmits the multiple copies to the base stations, which forward the information to each user. The conventional approach is particularly disadvantageous in a one-way broadcast service, where many users receive the broadcast transmission. The PDSN in this case must make a large number of copies, apply a specific address to each copy, and transmit the copies individually.

The PDSN is normally required to provide additional header information that identifies each target recipient. For a broadcast service, the number of target recipients can be prohibitively large, thus creating resource allocation problems and loss of available bandwidth.

An exemplary embodiment of a wireless communication system employs a data transport method that reduces the bandwidth used by infrastructure elements while meeting the accuracy and transmission requirements of the system. In the exemplary embodiment, mirroring is performed at the BS or at the packet control function node (PCF), releasing the central PDSN or packet data router to send the message with a multicast header to each BS. or PCF involved in broadcasting. For example, a message can process through an MC tree to a PCF, in which the PCF duplicates the message for each BSC and then transmits each message through a different unicast connection (UC), that is, connection or tunnel. insurance created between the PCF and a specific BSC. Note that a UC connection can be considered a point-to-point connection. The exemplary embodiment supports a one-way broadcast service. The broadcast service provides streaming video and / or audio to multiple users. Subscribers to the broadcast service "tune in" to a designated channel to access the broadcast transmission. Since the bandwidth requirement for high speed video transmission broadcasts is great, it is desirable to reduce the amount of duplication and duplicate packet transmission over hops in the network.

The following explanation develops the exemplary embodiment by first introducing a general spread spectrum wireless communication system. Next, the broadcast service is entered; wherein the service is referred to as a high speed broadcast service (HSBS), and the explanation includes channel assignments of the exemplary embodiment. A subscription model is then presented that includes options for paid subscriptions, free subscriptions, and mixed subscription plans, similar to those currently available for

ES 2 316 624 T3 television broadcasts. The particularities of access to the broadcast service are detailed below, presenting the use of a service option to define the particularities of a given transmission. The flow of messages in the broadcast system is explained with respect to the topology of the system, that is, infrastructure elements. Finally, the header compression used in the exemplary embodiment is explained.

Note that the exemplary embodiment is provided by way of example throughout this discussion; however, alternative embodiments may incorporate various aspects without departing from the scope of the present invention. Specifically, the present invention can be applied to a data processing system, a wireless communication system; a one-way broadcast system, and any other system that wants efficient information transmission.

Wireless communication system

The exemplary embodiment employs a spread spectrum wireless communication system, which supports a broadcast service. Wireless communication systems are widely implemented to provide various types of communication such as voice, data, etc. These systems can be based on code division multiple access (CDMA), time division multiple access (TDMA), or any other modulation technique. A CDMA system provides certain advantages over other types of systems, including increased system capacity.

A system may be designed to support one or more standards such as the "TIA / EIA / IS-95-B standard for compatibility mobile station - base station for dual mode broadband spread spectrum cellular system" to which it is made referenced herein as the IS-95 standard, the standard provided by a consortium called the "3rd Generation Partnership Project" referred to herein as 3GPP, and embodied in a set of documents including documents Nos. 3G TS 25.211, 3G TS 25.212, 3G TS 25.213, and 3G TS 25.214, 3G TS 25.302, which is referred to herein as the WCDMA standard , the standard provided by a consortium called "3rd Generation Partnership Project 2" referred to herein as 3GPP2, and T R-45.5 referred to herein as the cdma2000 standard, previously referred to as IS-2000 MC. The standards just cited are hereby expressly incorporated herein by reference.

Each standard specifically defines the data processing for transmission from base station to mobile, and vice versa. As an exemplary embodiment, the following explanation considers a spread spectrum communication system compatible with the cdma200 standard of protocols. Alternative embodiments may incorporate another standard. Still other embodiments may apply the compression procedures described herein to other types of data processing systems.

Figure 1 serves as an example of a communication system 100 that supports multiple users and may implement at least some aspects and embodiments of the invention. Any of a variety of algorithms and procedures can be used to schedule transmissions in system 100. System 100 provides communication to a number of cells 102A through 102G, each of which is served by a corresponding base station 104A through 104G, respectively. In the exemplary embodiment, some of the base stations 104 have multiple receive antennas and others have only one receive antenna. Similarly, some of the base stations 104 have multiple transmitting antennas and others have single transmitting antennas. There are no restrictions on the combinations of transmitting and receiving antennas. Thus, it is possible for a base station 104 to have multiple transmitting antennas and a single receiving antenna, or having multiple receiving antennas and a single transmitting antenna, or having both single or multiple transmitting and receiving antennas.

Terminals 106 in the coverage area can be fixed (ie stationary) or mobile. As shown in Figure 1, several terminals 106 are scattered throughout the system. Each terminal 106 communicates with at least one and possibly more base stations 104 on the downlink and uplink at any given time depending on, for example, whether soft handoff is employed or whether the terminal is designed and operated (simultaneously or sequentially) to receive multiple transmissions from multiple base stations. Soft handover in CDMA communication systems is widely known in the art and is described in detail in US Patent No. 5,101,501, entitled "Method and System for Providing Soft Handover in a CDMA Cellular Telephone System", assigned to the assignee of the present invention.

The downlink refers to the transmission from the base station to the terminal, and the uplink refers to the transmission from the terminal to the base station. In the exemplary embodiment, some of the terminals 106 have multiple receive antennas and others have only one receive antenna. In FIG. 1, base station 104A transmits data to terminals 106A and 106J on the downlink, base station 104B transmits data to terminals 106B and 106J, base station 104c transmits data to terminal 106C, and so on.

The increasing demand for wireless data transmission and the expansion of services available through wireless communication technology have led to the development of specific data services. Such a service is called high data rate (HDR). An exemplary HDR service is proposed in the "EIA / TIA-IS856 cdma2000 high packet data rate air interface specification" referred to as "the HDR specification". The HDR service is generally an overlay with a system of

ES 2 316 624 T3 voice communication that provides an efficient method of transmitting data packets in a wireless communication system. As the amount of data transmitted and the number of transmissions increases, the limited bandwidth available for radio transmissions becomes a critical resource. There is a need, therefore, for an efficient and equitable transmission scheduling procedure in a communication system that optimizes the use of available bandwidth. In the exemplary embodiment, the system 100 illustrated in FIG. 1 is compatible with a CDMA type system having HDR service.

High Speed ​​Broadcast System (HSBS)

A wireless communication system 200 is illustrated in FIG. 2, in which video and audio information is provided to packet data serving node (PDSN) 202. The video and audio information can be from television programming or a radio broadcast. The information is provided as packet data, such as IP packets. The PDSN 202 processes the IP packets for distribution in an access network (AN). As illustrated, an AN is defined as the parts of the system that include a BS 204 in communication with multiple MS 206s. PDSN 202 is coupled to BS 204. For HSBS service, BS 204 receives the continuous stream of information from the PDSN 202 and provides the information about a designated channel to the subscribers in the system 200.

In a given industry, there are various ways in which the broadcast HSBS service can be deployed. Factors involved in the design of a system include, but are not limited to, the number of HSBS sessions supported, the number of frequency assignments, and the number of physical broadcast channels supported.

HSBS is a continuous stream of information provided over an air interface in a wireless communication system. The "HSBS channel" refers to a single logical HSBS broadcast session as defined in the broadcast content. Note that the content of a given HSBS channel may change over time, for example, 7am News, 8am Weather, 9am Movies, etc. Time-based programming is analogous to a single TV channel. The "broadcast channel" refers to a single physical direct link channel, ie, a given Walsh code that carries broadcast traffic. The broadcast channel, BCH, corresponds to a single code division multiplex (CDM) channel.

A single broadcast channel can carry one or more HSBS channels; in this case, the HSBS channels will be multiplexed in time division multiplexing (TDM) on the single broadcast channel. In one embodiment, a single HSBS channel is provided over more than one broadcast channel in a sector. In another embodiment, a single HSBS channel is provided on different frequencies to serve subscribers on those frequencies.

According to the exemplary embodiment, the system 100 illustrated in FIG. 1 supports a high-speed multimedia broadcast service called a high-speed broadcast service (HSBS). The broadcast capabilities of the service are intended to provide programming at a data rate sufficient to support video and audio communications. As an example, HSBS applications may include video streaming of movies, sporting events, etc. The HSBS service is an Internet Protocol (IP) -based packet data service.

According to the exemplary embodiment, a content server (CS) advertises the capability of such a high-speed broadcast service to the users of the system. Any user who wishes to receive the HSBS service can subscribe to the CS. The subscriber can then examine the broadcast service scheduling in various ways that the CS can provide. For example, the broadcast program may communicate via banner advertisements, short management system (SMS) messages, wireless application protocol (WAP), and / or some other generally compatible and convenient means for mobile wireless communications. Mobile users are referred to as mobile stations (MS). Base stations (BS) transmit HSBS-related parameters in overload messages, such as those transmitted on designated channels and / or frequencies for control and information, that is, messages that are not payload. Payload refers to the information content of the stream, where the payload for a broadcast session is the broadcast content, i.e. the video program, etc. When a broadcast service subscriber wishes to receive a broadcast session, that is, a particular scheduled broadcast program, the MS reads the overload messages and learns the appropriate settings. The MS then tunes to the frequency containing the HSBS channel, and receives the content from the broadcast service.

The channel structure of the exemplary embodiment is compatible with the cdma2000 standard, in which the direct complementary channel (F-SCH) supports data transmissions. One embodiment groups a large number of the direct fundamental channels (F-FCH) or the direct dedicated control channels (F-DCCH) to achieve the higher data service data rate requirements. The exemplary embodiment uses an F-SCH as the basis for the F-BSCH to support a 64 kbps payload (excluding RTP overhead). The F-BSCH can be modified to support other payload rates, for example by subdividing the 64 kbps payload rate into continuous sub-streams of lower rates.

One embodiment also supports group calls in various ways. For example, using existing unicast channels, ie an unshared MS forward link channel, of F-FCH (or the F-DCCH) on both forward and reverse links. In another example, the F-SCH (shared by group members in the same sector) and the FDCCH (with no other frames than the forward power control subchannel most of the time) are applied on the forward link and the R- DCCH on the reverse link. In yet another example, the high rate F-BSCH is used.

ES 2 316 624 T3 transmission on the forward link and the access channel (or the combination of enhanced access channel / reverse common control channel) on the reverse link.

By having a high data rate, the forward broadcast complementary channel (F-BSCH) of the exemplary embodiment can use a very large part of a base station forward link power to provide adequate coverage. HSBC's physical layer design then focuses on efficiency improvements in a broadcast environment.

To provide adequate support for video services, the system design considers the base station power required for various ways of transmitting the channel as well as the corresponding video quality. One aspect of the design is a subjective balance between perceived video quality at the edge of coverage and near the cell site. As the payload transmission rate decreases, the effective error correction code transmission rate increases, a given level of base station transmission power would provide better coverage at the edge of the cell. For mobile stations located closer to the base stations, the channel reception remains error-free and the video quality would decrease due to the reduced transmission rate of the source. This same trade-off also applies to other non-video applications that the F-BSCH can support. Decreasing the payload transmission rate supported by the channel increases coverage at the expense of reduced download speed for these applications. This trade-off of the relative importance between video quality and overall data throughput versus coverage is objective. The chosen configuration looks for an optimized configuration specific to the application, and a good compromise between all the possibilities.

The payload transmission rate for the F-BSCH is an important design parameter. The following assumptions can be used when designing a system that supports broadcast transmissions in accordance with the exemplary embodiment: (1) the target payload transmission rate is 64 kbps, which provides acceptable video quality; (2) for streaming video services, the payload transmission rate is assumed to include 12 8-bit bytes per packet overhead of RTP packets; (3) the average overhead for all layers between RTP and the physical layer is approximately 64 bytes of 8 bits per packet plus 8 bits per F-SCH frame overhead used by the MUXPDU header.

In the exemplary embodiment, for non-video broadcast services, the maximum supported transmission rate is 64 kbps. However, many other possible payload transmission rates of less than 64 kbps can also be achieved.

Subscription models

There are several possible subscription / payment models for the HSBS service, including free access, controlled access, and partially controlled access. For free access, a subscription is not necessary to receive the service. The BS broadcasts the content without encryption and interested mobiles can receive the content. Profits for the service provider can be generated by advertisements that can also be broadcast on the broadcast channel. For example, clips of upcoming movie releases may be streamed for which studios will pay the service provider.

For controlled access, MS users subscribe to the service and pay the corresponding fee to receive the broadcast service. Non-subscribing users cannot receive HSBS service. Controlled access can be achieved by encrypting the HSBS transmission / content so that only subscribed users can decrypt the content. Over-the-air encryption key exchange procedures can be used. This scheme provides great security and prevents theft of the service.

A hybrid access scheme, called Partial Controlled Access, provides the HSBS service as a subscription-based service that is encrypted with intermittent unencrypted ad streams. These announcements may be expected to encourage you to subscribe to the encrypted HSBS service. The MS could learn the scheduling of these unencrypted segments through external means.

HSBS service option

The HSBS service option is defined by: (1) a protocol stack; (2) options in the protocol stack; and (3) procedures to establish and synchronize the service. The protocol stack according to the exemplary embodiment is illustrated in Figures 3 and 4. As illustrated in Figure 3, the protocol stack is specific to the infrastructure element, ie, MS, BS, PDSN and CS in the exemplary embodiment. .

Continuing with figure 3, for the MS application layer, the protocol specifies audio codec, visual codec, as well as any visual profile. Additionally, the protocol specifies Radio Transport Protocol (RTP) payload types when using RTP. For the MS transport layer, the protocol specifies a User Datagram Protocol (UDP) port. The security layer of the MS is specified by the protocol, in which the security parameters are provided over out-of-band channels when security is initially associated with the CS. The network layer specifies the IP header compression parameters. According to one embodiment, data packets are compressed at the link layer and a suitable framing protocol is then applied to the compressed data.

ES 2 316 624 T3

Message flow

Figure 4 illustrates the call flow of one embodiment for a given system topology. The system includes an MS, BS, PDSN, and CS, as listed on the horizontal axis. The vertical axis represents time. The user or MS is a subscriber to the HSBS service. At time t1 the MS and CS negotiate subscription security for the broadcast service. Negotiation involves the exchange and maintenance of encryption keys, etc., used to receive broadcast content on the broadcast channel. The user establishes a security association with the CS upon receipt of the encryption information. The encryption information may include a broadcast access key (BAK) or combination of keys, etc., from the CS. According to one embodiment, the CS provides the encryption information on a dedicated channel during a packet data session, such as through PPP, WAP, or other out-of-band procedures.

At time t2 the MS tunes into the broadcast channel and begins to receive packets. At this point in time, the MS cannot process the received packets because the IP / ESP header is ROHC compressed, and the MS decompressor has not been initialized. The PdSn provides header compression information (detailed hereinafter) at time t3. From the ROHC packet header, the MS detects and obtains a ROHC initialization and refresh (IR) packet periodically sent from the PDSN to the broadcast channel. The ROHC IR packet is used to initialize the state of the decompressor in the MS, allowing it to decompress the IP / ESP header of the received packets. The MS can then process the IP / ESP header of the received packets, however the mS needs more information to process the ESP payload since the payload has been encrypted with a short-lived key (SK) in the CS. The SK acts in coordination with the BAK, in which the SK is decrypted at the receiver using the BAK. The CS provides additional encryption information, such as updated key information or a current SK at time t4. Note that the CS provides this information periodically to the MS to ensure continued security of the broadcast. At time t5 the MS receives the broadcast content from the CS. Note that alternative embodiments may incorporate alternative compression and decompression procedures that provide efficient transmission of the header information. Additionally, alternative embodiments may implement a variety of security schemes to protect broadcast content. More alternative embodiments can provide an insecure broadcast service. The MS uses the encryption information, such as the SK, to decrypt and display broadcast content.

Access network

Figure 5 illustrates a general access network topology for a system 300 that has one CS 326, two PDSN 320, 322, one PCF 310, one PCF and BSC 312 located in the same location, and three BSCs 302, 304, 306. The CS 326 is coupled to the PDSN 320, 322 via an IP cloud 324. The IP cloud 324, as well as the IP clouds 314 and 308 are basically a configuration of interconnected routers that form an IP path from the CS to various data recipients from the CS. In the IP cloud 308 a virtual tunnel, called tunnel A8, is formed to transmit information from PCF 310 to BSC 302 and BSC 304. The tunnel may be a GRE tunnel. A protocol called A9 is used to establish the A8 tunnel. The IP cloud 308 can be labeled as an A8 / A9 cloud. In the IP cloud 314 a virtual tunnel, called tunnel A10, is formed to transmit information from the PDSN 320 to each of the PCF 310 and PCF / BSC 312. Note that an A10 tunnel is formed from PDSN 320 to PCF 310 and a second A10 tunnel is formed from PDSN 320 to PCF / BSC 312. The tunnels may be GRE tunnels. A protocol called A11 is used to establish the A10 tunnel. The IP cloud 314 can be labeled as an A10 / A11 cloud. One embodiment is compatible with that specified in the cdma2000 and HDR standards, previously described. The access network (AN) is defined as the elements and connections from the PDSN to the end user, eg MS.

According to one embodiment, the broadcast CS 326 sends IP packets containing encrypted broadcast content to a multicast group identified by a class D multicast IP address. This address is used in the destination address field of IP packets. A given PDSN 320 participates in the multicast routing of these packets. After compression, the PDSN 320 places each packet in an HDLC frame for transmission. The HDLC frame is encapsulated by a Generic Routing Encapsulation (GRE) packet. Note that GRE encapsulation forms the A10 tunnel described hereinabove. The key field in the GRE packet header uses a special value to indicate a broadcast bearer connection. The GRE packet has attached the 20-byte IP packet header which has a source address field that identifies the IP address of the PDSN 320, and the destination address field uses a class D multicast IP address. The multicast IP address it is the same as that used by the original IP packet from the CS 326. The packets delivered on the broadcast connection are provided in sequence; in one embodiment the GRE sequencing property is enabled. Duplication of IP multicast packets is performed on multicast capable routers. Note that according to an alternative embodiment, the IP cloud 314 implements point-to-point or unicast tunnels, towards individual recipient PCF (s). The decision to use a multicast link or a unicast link for this connection point is made at a higher layer, where the UC tunnels provide increased security, and the MC tree provides efficiency.

According to an exemplary embodiment, CS 326 transmits data to PDSN 320 via multicast IP address, wherein PDSN 320 further transmits data to PCF 310 and PCF / BSC 312 also via multicast IP address. PCF 310, for example, then determines the number of individual users in the active set that are in the target subscription group and duplicates the frame received from CS 326 for each

ES 2 316 624 T3 one of these users. The PDSN PCF 310 determines the BSC (s) corresponding to each of the users in the subscription group.

In one embodiment, BSC 304 is adapted to transmit to neighboring BSC (s), wherein BSC 304 can duplicate received packets and send them to one or more of the neighboring BSC (s). BSC chaining results in better soft handoff performance. The "anchor" BSC procedure results in better soft handoff performance. The anchor BSC 304 duplicates the transmission frame and sends it with the same timestamp to its neighboring BSCs. The timestamp information is critical for the soft handoff operation since the mobile station receives transmission frames from different BSCs.

Multicast service

One type of broadcast service is called a multicast service (MC) or "Group Call (GC)" in which a "GC group" includes those users who will participate in the GC, in which a group of users is identified to a given MC content. The user group can be called the MC group. MC content is intended for MC group members only. Each active user in the MC group registers with the AN. The AN then tracks the location of each registered user and directs the transmission of the MC message to those locations. Specifically, the AN determines a cell, sector and / or geographical area within which each of the users of the MC group is located, and then transmits the message to the PCFs associated with these cells, sectors and / or geographical areas.

Unlike some other types of broadcast services in which the BC message is transmitted without knowing the location and activity of the recipients or subscribers, the MC service operates using knowledge of the active users, specifically the location of each active user. Additionally, users provide location information to the AN. In one embodiment users active in an MC group register with the AN through IP communications, specifically using an Internet Group Management Protocol (IGMP) message. Since the MC service can identify the location of each user, and transmit the MC targets to these locations, the MC service uses a router between the PCF (s) and the PDSN (s). The MC service builds a connection tree that provides a path from the CS to each PCF that is communicating with an active user in the MC group. The tree is called an MC tree.

In a conventional IP network or system, such as a computer network coupled to the Internet, if a user wishes to receive MC-type information, called MC content, the user registers with the nearest router using the group management protocol. Internet (IGMP). The router then begins the process of building an MC tree by registering with the next adjacent router. The CS then sends MC content in the form of an IP MC packet. The MC IP packet is then routed through the MC tree to the original router. This router duplicates the data for each user who wants MC content. A common broadcast medium on a computer network is an Ethernet hub that connects multiple users to the same continuous flow of information.

The combination of Internet and IP networks with wireless communication systems introduces several different problems. One problem is routing the information from the IP network through the wireless network. In a wireless system, several of the interconnections are predefined. For example, as discussed earlier herein, the interface between the BSC and the PCF is defined by the A8 / A9 connection. Similarly, the PCF to PDSN connection is defined by the A10 / A11 connection. One embodiment forms an internal MC tree between the PDSN and the PCF and forms an external MC tree between the PDSN and the CS. The PCF then forms specific tunnels to the various BSCs requesting the MC content. This embodiment, discussed later herein, provides operational efficiency. Another embodiment forms the external MC tree between the PDSN and the CS, while establishing tunnels from the PDSN to each individual PCF that is to receive the MC content. This embodiment provides secure communications.

Generally, the MC path is considered end-to-end, where the MC content originates from one source and is transmitted to the end user. The end user can be MS. Alternatively, the MS can be a mobile router that routes MC content to a network. The end user does not forward the MC content. Note that an MC path can include a plurality of different types of interconnections. For example, one embodiment may incorporate the internal MC tree discussed earlier herein that has a termination point at the PCF, and the external MC tree that has a termination point at the PDSN. Similarly, the MC path can include point-to-point tunnels, where each tunnel is formed between a node and a separate individual node.

According to an exemplary embodiment illustrated in FIG. 5, a communication system 300 includes a CS 326 in communication with PDSNs 320 and 322 through an IP cloud 324. Note that the CS 326 also communicates with other PDSNs not shown. The IP cloud 324 includes a configuration of routers, such as multicast routers (as previously described herein) and other routers for passing data transmissions through the cloud 324. Transmissions over the IP 324 cloud are IP communications. Routers in the IP cloud 324 access communications, such as BC messages and MC messages, to target recipients that are compliant with Internet Engineering Working Group (IETF) protocols.

ES 2 316 624 T3

Continuing with Figure 5, PDSNs 320 and 322 communicate with PCFs 310 and 312, as well as other PCFs not shown, through another IP cloud 314. The IP cloud 314 includes a configuration of routers, such as multicast routers and other routers for passing data transmissions through the cloud 314. The transmissions through the IP cloud 314 are IP communications. Routers in the IP cloud 314 access communications, such as BC messages and MC messages, to target recipients that are compliant with Internet Engineering Working Group (IETF) protocols. In addition, PCF 310 communicates with BSC 304 through yet another IP cloud 308. The IP cloud 314 includes a configuration of routers, such as multicast routers and other routers to pass data transmissions through the cloud 314. Transmissions through the IP cloud 314 are IP communications. PCF 312 also operates as a BSC and communicates with any of the users in system 300 (not shown). Note that, for clarity, three BSCs are illustrated, specifically, BSCs 302, 304, and 306. System 300 may include any number of additional BSCs (not shown). Note that alternative embodiments may incorporate alternative configurations, in which any one or more connections indicated by the multiple IP clouds, such as IP clouds 308, 314, 324, can be substituted for point-to-point connections. A point-to-point connection can be a secure connection made between appliances at one point, such as a PCF, with another point, such as a BSC. The point-to-point connection is achieved over an IP cloud, such as IP cloud 308, using a procedure called tunneling. The basic idea of ​​tunneling is to take an IP packet, encapsulate the packet in GRE / IP, and send the resulting packet to a destination point. If the destination address of the external IP header is a unicast IP address, the process achieves a point-to-point tunnel. If the destination address is a multicast IP address, the process achieves a point-to-multipoint tunnel. Note that all of this is done in the same IP cloud. For example, in IP cloud 314, there are several different applicable procedures. One procedure forms a point-to-point tunnel and a second procedure forms a point-to-multipoint tunnel. This is in contrast to the connection procedure used in cloud 324, where GRE tunneling is not used and the original multicast IP packet is transmitted.

In the exemplary embodiment, the CS 326 configures an HSBS channel by knowing the multicast IP address to be used in the IP cloud 324. The CS uses the MC IP address to send HSBS content information, called a payload.

To form a tunnel, the message is encapsulated in an external IP packet. As the encapsulated message is transmitted through the tunnel, the internal IP address, that is, the IP address of the original IP packet, is ignored. Encapsulation changes the Internet routing of the original IP packet. In the exemplary embodiment, the MC tunnel routes the BC or MC message through the MC tree between PDSN and PCF.

In the exemplary embodiment, the PDSN 320 and PCFs 310 and 312 are associated with an MC group. In other words, MC group members are located in cells, sectors and / or geographic areas served by PCF 310 and 312. System 300 builds an external MC tree from CS 326 to PDSN 320 and a tree internal from PDSN 320 to PCF 310 and 312. The PDSN 320 builds the external MC tree by successively registering with neighboring multicast routers in the IP cloud 324. The external MC tree is built from PDSN 320 to CS 326 over the IP network. The PDSN 320 receives the MC message (s) for the MC group members through the external MC tree. In other words, MC messages are sent through the external MC tunnel structured by the external MC tree. Each of the PCFs 310 and 312 builds an internal MC tree to the PDSN 320 through the IP cloud 314. MC messages from PDSN 320 are sent over an internal MC tree in a GRE / IP tunnel.

Alternative embodiments may apply the procedures discussed hereinabove to alternate BC services, in which point-to-multipoint transmission is used. The use of MC trees formed by the leaves or termination points that are registered in successive routers provides a convenient and dynamic procedure to avoid redundancies in the communication system. Additionally, the use of MC trees provides greater scalability by reducing the amount of infrastructure required to expand the network.

Selecting a PDSN

A packet control function (PCF) and a packet data service node (PDSN) are network entities defined in a cdma2000 access network, and are adapted to support multicast / broadcast services. In general, a PCF may be able to communicate with multiple PDSNs. In turn, a PDSN may be capable of communicating with multiple PCFs. The transport path of data traffic for a given communication is called "carrier transport". The carrier transport for a multicast / broadcast service in the forward direction typically flows through a PDSN, PCF, and base station, before being received by mobile stations subscribed to that multicast / broadcast service. To save on transmission resources, mobile stations tune to a shared radio channel for multicast / broadcast service. The network uses an Internet Protocol (IP) to send the messages to the PCFs, where in one embodiment a multicast / broadcast service is defined by a 32-bit IP multicast address.

When more than one mobile station, served by a given PCF, wants to receive a multicast / broadcast service identified by an IP multicast address X, the PCF needs to establish a bearer path with a PDSN to carry the multicast service /diffusion. Since multiple PDSNs can establish a connection with the PCF, the PCF needs to select a PDSN to provide the carrier transport.

ES 2 316 624 T3

According to one embodiment, a method automatically selects a PDSN for a multicast / broadcast message, wherein the message is identified by the IP multicast address X. The procedure effectively performs balancing loading on multiple PDSNs. In other words, if a given PCF can communicate with N PDSNs and there are M messages or multicast / broadcast services that need to go through that PCF, using a method of the present embodiment, each PDSN will handle on average M / N multicast services. /diffusion.

Figure 6 illustrates a communication system 400 having an MS 402 that communicates with a BSC 404 via radio transmissions, ie, air interface. Note that alternative embodiments can include any number of other controllers or transmitters coupled between the MS 402 and the BSC 404. As illustrated in Figure 6, the BSC 404 communicates with the PCF 406, which in turn can communicate with any of PDSNs 408, 410, and / or 412. As discussed earlier herein, a decision is made to select a PDSN from those available for a given communication through PCF 406. The decision is made according to specific criteria of system 400.

According to the exemplary embodiment, the system 400 assigns each PDSN an identifier, such as an integer. As illustrated in Figure 6, PDSNs 408, 410, 412 are assigned identifiers 1, 2, and 3, respectively. System 400 selects a PDSN for a given communication by applying the following formula:

L = (Y) modulo N (1) in which L corresponds to the PDSN identifier, and N is the total number of PDSNs that can reach, that is, that can communicate with, the PCF 406. Note that in the exemplary embodiment the PCF 406 performs the selection of a PDSN according to equation (1), in which the PCF internally associates each reachable PDSN with a number in the range 0 to N-1. The variable Y is a function of a multicast address X associated with the communication. Specifically, the variable Y is defined in terms of the direction generally as:

Y = f (X). (2)

In the exemplary embodiment, the multicast address X is a 32-bit IP multicast address that identifies a multicast / broadcast service. Alternative embodiments may apply other addressing schemes. The system obtains the multicast X address from a configuration message sent by the BSC 404. Specifically, receipt of the configuration message triggers the PCF 406 to make the selection of the PDSN for the multicast / broadcast service.

In the exemplary embodiment, the IP multicast X address can be represented by a binary representation that is given as:

HIOX27X26X25X24 X23X22X21X2OX19X18X17X16 X15X14X13X12X11X1OX9X8 X7X6X5X4X3X2X1XO (3) where x¡ is either 0 or 1 for i = 0, 1, ..., 27.

As given by equation (2), Y is a function of X, the function f () being a mathematical function that converts the multicast address to an integer value. For example, a straightforward simple function converts the IP multicast address to an integer representation using the following equation:

Y = 2³¹ + 2³⁰ + 2²⁹ + (X27) (2²⁷) + (X26) (2²⁶) + - .. + (Xo) (2 °) (4)

An alternative example is generated by simplifying the function of equation (4), (specifically eliminating the first three constant terms) and is given as:

Y = (x₂₇) (2²⁷) + (x₂₆) (2²⁶) + ... + (xo) (2 °) (5)

In the exemplary embodiment, L is the result of the modulo N operation performed on Y. Specifically, L is the remainder of the Y operation divided by N. The value of L varies between 0 and N-1. For example, if Y = 131 and N = 7, then L = 5. Therefore, PCF 406 will select the PDSN identified by 5. The method allows dynamic transmission path selection avoiding human intervention.

Figure 7 illustrates a procedure 500 for selecting a PDSN. In step 502 the PCF determines the number N of reachable PDSNs. The PCF then assigns each of the reachable PDSNs a unique identifier in step 504. When the PCF receives a configuration message for a given communication, at decision diamond 506,

ES 2 316 624 T3 the PCF proceeds to step 508 to receive the multicast address X for the given communication. The PCF then calculates Y as a function of the multicast address X in step 510. In step 512 the PCF determines a value L according to equation (1) and determines the corresponding PDSN in step 514. The selected PDSN is used then for the given communication. The transmission path from the content server to the end user can be established in a variety of procedures, such as the IP procedures discussed hereinabove. The procedure 500 of Figure 7 determines the PDSN as a function of the multicast address and effectively results in an average probability to select any of the reachable PDSNs, since the probability of selecting any of the PDSNs is 1 / N, since modulo N operation on the integer value of a multicast address is uniformly distributed between 0 and N-1. The multicast traffics are therefore evenly balanced among the N PDSNs.

The present invention can be applied to a point-to-multipoint transmission service, such as a broadcast, as well as a one-to-many type service, such as multicast. Alternative embodiments may implement the PDSN selection procedure in an alternative infrastructure element. The procedure illustrated in Figure 7 can be extended to the selection of any part of a transmission path, in which multiple connections are possible but only one will be used for transmission. Using a multicast address, or other type of address, associated with a given communication, the selection process balances the potential connections and provides the same probability of selecting any one. Additionally, although the calculation of L as given by equation (1) provides a straightforward simple calculation, alternative functions can be implemented to determine the value of L.

Those skilled in the art would understand that information and signals can be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols and code elements that may be named throughout the above description may be represented by voltages, intensities, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

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

The various illustrative logic blocks, modules and circuits described in connection with the embodiments disclosed herein may be implemented or realized with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC ), a field programmable gate arrangement (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor can be a microprocessor, but alternatively, the processor can be any conventional processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors together with a DSP core, or any other such configuration.

The steps of a method or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of storage known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from, and write information to, the storage medium. Alternatively, the storage medium can be integrated into the processor. The processor and storage medium can reside in an ASIC. The ASIC can reside in a user terminal. Alternatively, the processor and storage medium can reside as discrete components in a user terminal.

The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications of these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein can be applied to other embodiments without departing from the scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein, but is to be granted the broadest scope consistent with the principles and new features disclosed herein.