HK1078201A - Method and apparatus for negotiation of transmission parameters for broadcast/multicast services - Google Patents

Description

Method and apparatus for broadcast/multicast service transmission parameter negotiation

FIELD

The present invention relates generally to wireless communication systems, and more particularly, to a method and apparatus for transmission parameter negotiation for broadcast/multicast services.

Background

There is an increasing need for packetized data services over wireless communication systems. Since conventional wireless communication systems are designed for voice communications, extension to support data services introduces a number of challenges. In particular, the unidirectional services provided (such as broadcast services streaming video and audio information to subscribers) have a unique set of requirements and objectives. Such services have significant bandwidth requirements where system designers seek to minimize the transmission of overhead information. In addition, special information is needed to forward and/or access the broadcast transmission, such as processing parameters and protocols. There is a problem in transmitting specific broadcast information and optimizing the use of available bandwidth.

Accordingly, there is a need for a method for efficiently and accurately transmitting data within a wireless communication system. In addition, there is a need for an efficient and accurate method of providing specific service information.

Brief description of the drawings

Fig. 1 is a diagram of a wireless communication system supporting broadcast transmissions.

Fig. 2 is a flow diagram for negotiating transmission parameters in a communication system supporting broadcast transmissions.

Fig. 3 is a block diagram of a portion of a communication system supporting broadcast transmissions.

Fig. 4 is a flow diagram for negotiating transmission parameters in a communication system supporting broadcast transmissions.

Fig. 5 is a block diagram of a portion of a communication system supporting broadcast transmissions.

Fig. 6 is a flow diagram of negotiating transmission parameters in a communication system supporting broadcast transmissions.

Fig. 7 is a block diagram of a portion of a communication system supporting broadcast transmissions.

Fig. 8 is a block diagram of a communication system supporting broadcast transmissions.

Fig. 9 is a flow diagram for negotiating transmission parameters in a communication system supporting broadcast transmissions.

Detailed Description

The word "exemplary" is used herein to mean "serving as an example, instance, or illustration. Any embodiment described herein is not necessarily to be considered optimal or advantageous over other embodiments. While the various aspects of the various embodiments are illustrated in the accompanying drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

An exemplary embodiment of a wireless communication system uses a method of header compression that reduces the size of each header while meeting the system's requirements for accuracy and transmission. The exemplary embodiment supports a one-way broadcast service. The broadcast service provides IP packets to a plurality of users. Typically, the IP packets comprise video and/or audio streams. Subscribers to a broadcast service may "tune in" to a specified channel to access the broadcast transmission. Since high speed transmission of video broadcasts has a high bandwidth requirement, it is desirable to reduce the amount of any overhead associated with such broadcast transmissions.

Sometimes a broadcast service may be used as a service that sends information to a group of users based on their geographical location. This may also be considered as a "no address" message. Examples are broadcast local information based on traffic of a cell/sector or a specific paging area or weather alerts etc. All users in the area that are able to receive the broadcast information are able to receive it.

Broadcast services may also be used for multicasting. Multicasting may refer to the ability to broadcast information to a particular group of users based on subscriptions to the group of users. The user group may be maintained by an administrator. In addition, a group of users may be publicly bookable (e.g., booking advertisements, stock quotes, etc.), or may be closed to public bookings (e.g., a company list). The multicast list may also enable the mobile device to acknowledge receipt of a message as defined by a user group administrator. This may be considered an addressable message.

Multiple user groups are generally considered to be closed groups. Within these groups, members typically subscribe to a service (common multicast group) by sending a request to the administrator, by some web interface, or other mechanism. Private multicast groups are limited to membership explicitly joined by an administrator manually to a member.

Broadcast services may also be divided into public and private groups. The public broadcast group is used to transmit geographical specific information. All broadcast-capable devices within a particular geographic area are in a common group and can receive this information. Examples of the broadcast information of the common broadcast type are an emergency antenna alert, traffic conditions, and the like. The private broadcast group is targeted to send specific information to a specific group of devices within a specific area. An example of one such type of service is location-based advertising. One possible scenario for this example is that the user may choose to receive a particular advertisement when at the store, but not at other times.

The following discussion develops the exemplary embodiments by first introducing a general spread spectrum wireless communication system. Next, a broadcast service is introduced, wherein the service is referred to as a High Speed Broadcast Service (HSBS). An interface between packet data at a base station and a serving node is introduced for user traffic and signaling. Messages to establish an a10 connection for user traffic are discussed. Flow processing and mapping data for packet data used to communicate processing and mapping information to a serving node is illustrated and explained. An example of sending flow processing and mapping data from a base station to a packet data serving node is shown. Details of mapping the flow to the correct interface and use of proposed service option parameters to define the characteristics of the compression algorithm are shown. Finally, the benefits of using stream processing and mapping data to convey processing and mapping information are addressed.

It is noted that embodiments are discussed as examples throughout the discussion; however, other embodiments may include various aspects without departing from the scope of the invention. In particular, the present invention may be applied to data processing systems, wireless communication systems, one-way broadcasting systems, and any system in which efficient transmission of information is desired.

Wireless communication system

Example embodiments enable support of broadcast services using a spread spectrum wireless communication system. Wireless communication systems are widely deployed to provide various types of communication such as voice data and so on. These systems may be based on code division multiple access (CMDA), Time Division Multiple Access (TDMA), or some other modulation technique. CDMA systems offer certain advantages over other types of systems, including increased system capacity.

The System may be used to support one or more standards such as "TIA/EIA-95-B Mobile Station-Bse Station Compatibility Standard for Dual-Mode Wireless spread Spectrum Cellular System", referred to herein as the IS-95 Standard, by the name "3^rdThe organization of Generation Partnership Project, "referred to herein as 3GPP, and included in document Nos. 3G TS 25.211, 3G TS 25.212, 3G TS 25.213, 3G TS 25.214, and 3G TS 25.302, referred to herein as the W-CDMA standard, by the name" 3G TS 25.302^rdThe organization of Generation PartnershipProject 2 "provides a standard referred to herein as 3GPP2 and TR-45.5 referred to herein as the cdma2000 standard, previously referred to as IS-2000 MC. The above standards are incorporated herein by reference.

Each standard specifically defines the processing of data transmissions from a base station to a mobile station and vice versa. As an exemplary embodiment, the following discussion considers a spread spectrum communication system consistent with the cdma2000 protocol standard. Other embodiments may include other criteria. Other embodiments may apply the compression methods disclosed herein to other types of data processing systems.

High Speed Broadcasting System (HSBS)

A wireless communication system 100 is illustrated in fig. 1, wherein IP packets are provided by a Content Server (CS)116 to at least one or more Packet Data Serving Nodes (PDSNs) 110 via an IP network 114. The CS 116 provides data that is transmitted as internet protocol data packets (IP packets) over the IP network 114. Many different data may be sent by CS 116. Such as audio data, video data, text data, electronic files, etc., may be transmitted by the CS 116 over the IP network 114. The video and audio information may be from a television program or a radio transmission. Thus, the CS 116 may be a server for serving video data, audio data, and the like. In one embodiment, the CS 116 may be a web server connected to the Internet and used to provide data to users browsing the world Wide Web. The IP interface 114 may be the internet, an intranet, a personal IP network, or the like.

PDSN110 receives and processes the IP packets for transmission to Packet Control Function (PCF) node 108. The PCF108 then communicates with a Base Station Controller (BSC)104 via an IP interface 106. It is noted that the PCF108 may communicate with multiple BSCs (not shown) or with one or more Base Stations (BSs). Once the BS 104 receives the data, it transmits the data to one or more Mobile Stations (MSs), such as MS 102. The PCF108 also communicates with a PDSN 112, and the PDSN 112 communicates with an IP interface 118. In the exemplary embodiment, the communication from the BSC104 to the PCF108 is a wireline communication, wherein the communication from the BSC104 to the MS 102 is a wireless communication. Wireless communication is effectuated over a network referred to as AN Access Network (AN)130, while MS 102 is referred to as AN Access Terminal (AT) 140.

Information from the CS 116 is provided as packetized data, such as within IP packets. PDSN110 processes IP packets for distribution within Access Network (AN) 130. As illustrated, AN 130 is defined as part of a system 100 that includes BSC104, IP interfaces 106, 114, 118, PCF108, PDSNs 110, 112, and CS 116. For HSBS service, the BSC104 receives the information stream from the PDSN110 and provides the information on designated channels to subscribers within the system 100.

An HSBS is a stream of information provided over the air interface within a wireless communication system. An "HSBS channel" refers to a single logical HSBS broadcast session defined by broadcast content. It is noted that the content of a given HSBS channel may change over time, e.g., 7am news, 8am weather, 9am movies, etc. The schedule-based time is similar to a single TV channel. A "broadcast channel" refers to a single forward link physical channel, i.e., a given Walsh code that carries broadcast traffic. The broadcast channel BCH corresponds to a single CDM channel.

A single broadcast channel may carry one or more HSBS channels; in this case, the HSBS channels may be multiplexed within a single broadcast channel in a Time Division Multiplexing (TDM) manner. In one embodiment, a single HSBS channel is provided on more than one broadcast channel within a sector. In another embodiment, a single HSBS channel is provided on different frequencies to serve subscribers on those frequencies.

According to an example embodiment, the system 100 illustrated in fig. 1 supports a high speed multimedia broadcast service referred to as a High Speed Broadcast Service (HSBS). The broadcast capabilities of the service are used to provide programming at a data rate sufficient to support video and audio communications. As an example, applications for HSBS may include movies, video streams of sporting events, and the like. The HSBS service is an Internet Protocol (IP) based packet data service.

According to an exemplary embodiment, the service provider is referred to as the CS 116, where the CS 116 advertises to system users regarding the availability of such high speed broadcast services. Any user desiring to receive HSBS services may subscribe with the CS 116. The subscriber can then scan for broadcast service schedules in a variety of ways that the CS 116 may provide. For example, broadcast content may be transmitted via advertisements, Short Management System (SMS) messages, Wireless Application Protocol (WAP), and/or some other means that conforms to and facilitates mobile wireless communications. The BSC104 sends parameters related to the HSBS within overhead messages, such as those sent on channels and/or frequencies designated for control and information, i.e., non-payload messages. Payload refers to the transmitted information content, wherein for a broadcast session, the payload is the broadcast content, i.e. the video program, etc. When a broadcast service subscriber desires to receive a broadcast session, i.e., a particular broadcast scheduled program, MS 102 reads the overhead message and knows the appropriate configuration. MS 102 then tunes to the frequency containing the HSBS channel and receives the broadcast service content.

In order for the MS 102 to discover and successfully listen to the broadcast channel, various broadcast service related parameters are transmitted over the air interface. Broadcast services are designed to support different protocol options within the protocol stack. This requires that the receivers of the broadcast service are informed about the selected protocol options that facilitate decoding and preprocessing of the appropriate broadcast. In one embodiment, CS 102 provides this information to the receiver as an overhead system parameters message that conforms to the cdma2000 standard. The receiver has the benefit of being able to receive information immediately from the overhead message. In this way, the receiver can immediately determine whether the receiver has sufficient resources to receive the broadcast session. The receiver monitors the overhead system parameter message. The system may implement a service option number corresponding to the parameter and protocol set, where the service option number is provided within the overhead message. Alternatively, the system may provide a set of bits or flags to indicate the different protocol options selected. The receiver then determines the protocol options for correctly decoding the broadcast session.

There are multiple interconnects or interfaces within the AN. In the embodiment described herein, the PCF108 has a signaling connection with the PDSN 104, referred to herein as the a11 interface. In addition, there is one for the traffic connection, referred to herein as the a10 interface. The a10 interface is used to provide a path for user traffic between PDSN 104 and PCF108 for packet data services. The BSC has a signaling connection with the PCF, referred to as the a9 interface. In addition, the connection with user traffic is referred to as the A8 interface. The A8 interface is used to provide a path for user traffic between the BSC and the PCF for packet data services.

Illustrated below are method and apparatus embodiments for negotiating transmission parameters for a BC service. The transmission parameter is referred to as the general capacity of the BC service. The capacity may include the type of header compression used, such as specifying algorithm parameters, or may include any parameters used by PDSN110 and MS 102, which are not necessarily used by intervening system elements. For example, MS 102 and PDSN110 may use header compression to process the transmission. PDSN110 applies a header compression algorithm to compress the data prior to transmission. The MS 102 uses information about the header compression algorithm to extract the original information from the received information sent by the PDSN110, and the BSC104 does not need to know the type of header compression applied. Header compression is provided as a general capacity example; however, the general capacity is not limited to header compression. The general capacity may be any parameter required for at least two system elements to perform the appropriate processing for transmission.

As in unicast services, the MS 102 and PDSN110 require a procedure to specify or negotiate broadcast/multicast services. As described above, these capacities may include header compression algorithms, as well as algorithms and methods for directing the flow of data packets to the appropriate a10 connection. The method by which the PDSN compresses the IP packets may be referred to as flow processing. As used herein, a flow is a sequence of packets that share a particular instantiation of an IETF protocol layer. For example, an RTP stream may include IP/UDP/RTP protocol instantiation packets, all of which share the same source and destination IP addresses and UDP port numbers. When the PDSN receives IP packets, it determines where to send the IP packets and how the packets are compressed. The mapping of IP packets to a10 connections (forwarding type function) by the PDSN may be referred to as flow mapping.

According to one method used within unicast service, the MS negotiates the capacity with the corresponding PDSN during a point-to-point protocol (PPP) Internet Protocol Control Protocol (IPCP) procedure. The MS then uses the multi-channel stream processing protocol (MCFTP) to indicate stream processing information to the PDSN. MCFTP is proposed in 3GPP2 and described in 3GPP2 document p.s001-B entitled "Wireless IP Network Standards," which is incorporated herein by reference. The apparatus and methods disclosed herein are for providing flow processing and flow mapping information to the PDSN206, which are variants of MCFTP that provide certain benefits over MCFTP. The method is not directly applicable to broadcast/multicast services because the MS may have a PPP session established with a first PDSN that is different from a second PDSN that provides broadcast/multicast content to the MS. In addition, the flow processing indicated by the MS to the PDSN is not applicable because the first PDSN is not involved in the broadcast/multicast transmission.

As illustrated in FIG. 1, the BSC104 communicates with the PCF108 via an A8/A9 interface. The PCF108 may connect to one or more PDSNs, such as PDSNs 110 and 112, through interface A10/A11, which IS described in TIA/EIA/IS-2001-A, which IS the Specification for interoperability of the cdma2000 Access network Interface (IOS) August 2001. The broadcast/multicast content server CS 116 sends the media to the PDSN110 as IP packets. It is worth noting that the MS 102 may have IP connectivity to more than one PDSN at any given time.

Notably, each broadcast/multicast service instance within the carrier network is identified by a unique broadcast/multicast service identifier ID and an IP multicast address. When MS 102 desires to subscribe to a particular broadcast/multicast service, MS 102 retrieves the service description from CS 116. The Service description may be provided by an Out-of-band type mechanism, such as described in U.S. patent application No. 09/934021, entitled "Method and Apparatus for Out of BandTransmission of Broadcast Service operation in a Wireless communication System," by Nikolai Leung, filed 2001, 8/20, assigned to the assignee of the present invention and incorporated herein by reference. The MS 102 extracts the ID and IP MC address from the service description and is therefore able to receive the service.

Notably, the PDSN110 may support and implement various types of compression to reduce the amount of traffic sent to the MS 102. For example, PDSN110 may support the following header compression algorithms: van Jacobson TCP/IP header compression (RFC 114), header compression (RFC 2507), compressed RTP/UDP/IP headers (RFC 2508), header stripping/generation techniques, and robust header compression (RFC 3095) (wireless IP network standard, document identification number 3GPP2 p.s 001-B).

When the PDSN110 receives IP packets, it determines where to send the IP packets and how to compress the packets. The mapping of IP packets (forward type function) by PDSN110 to a10 connections may be referred to as flow mapping.

With respect to flow mapping to send IP packets to the correct MS 102, the PDSN110 accurately maps incoming IP packets to connections so that the packets can be sent to the correct MS 102. The IP packets are then sent to the BSC104 through the PCF 108. The BSC104 then sends the IP packets to the MS 102. In consideration of the flow processing, the PDSN110 compresses the IP packet using the determined compression method and transmits the packet to the MS 102. MS 102 then decompresses the IP packets.

Shown herein are various embodiments of general capability negotiation and indication for broadcast/multicast services. According to a first embodiment, generic capabilities are preconfigured in the BSC104, wherein the BSC104 provides the MS 102 and PDSN110 with generic capability information based on a list of available BC services and corresponding capabilities upon request for a particular BC service. Similar to the second embodiment of the first embodiment, the PDSN110 is pre-configured with generic capability information, wherein the BSC104 queries the PDSN110 for generic capability information upon request for a particular BC service. According to a third embodiment, PDSN110 is pre-configured with generic capability information, wherein MS 102 queries PDSN110 directly for generic capability information over a PPP connection. In a fourth embodiment, MS 102 queries PCF108, which PCF108 then queries all PDSNs in the system. The PDSN responsible for the BC responds to the query. In the case where multiple PDSNs may support the BSC, the first response using multicast addressing avoids the other responses.

As described above, in the first embodiment, the general capacity is previously configured in the BSC 104. When the MS 102 requests a particular BC service, the BSC104 provides the MS 102 with general capability information. In addition, the BSC104 also provides general capability information to the PDSN 110. The BSC104 stores and/or accesses BC list information. The BC list information is a list of available BC services and corresponding capacities of each.

For each broadcast/multicast service within a carrier network, the general capacity of a PDSN, such as PDSN110, to handle the broadcast/multicast service is pre-configured at the BSC, such as BSC 104. The MS 102 may know the PDSN110 capabilities by listening for periodic overhead messages sent by the BSC 104; however, the overhead message contains capability information for those broadcast/multicast services that have been set. There are several mechanisms that can trigger the setup of a broadcast/multicast service. According to a first mechanism, the MS 102 sends a registration message to the BSC104, where the registration request dynamically triggers the setup. The second mechanism is for the operator to set up service at the BSC 104.

Fig. 2 is a flow diagram illustrating a first embodiment of capacity negotiation within a communication system supporting BC services. The horizontal axis identifies the topology of the system, i.e. the infrastructure elements. The vertical axis represents a time line. Any number of additional steps (not shown) may be included in the process. At time t1, the MS 102 sends a BC registration request to the BSC104 to establish communication with the PDSN 110. The registration message includes an ID (service identifier) and/or MC IP address. MS 102 may contain the ID and MC IP address of the service description from CS 116, such as by out-of-band transmission. The BSC104 is pre-configured to access the BC list database with general capacity information for the BC. As illustrated in fig. 3, BSC104 may be coupled to configuration database 150 or configuration database 150 may be stored in a memory storage device within BSC 104. The configuration database 150 is actually a list of each BC supported by the CS 116. Each BC is then mapped to a corresponding capacity. In one embodiment, the configuration database 150 is maintained by an operator. In another embodiment, the configuration database 150 is a database downloaded to the BSC 104.

Upon receiving the registration message, the BSC104 confirms that the generic capability information of the PDSN110 (or PDSN associated with the BC) is available for the requested broadcast/multicast service. If the BSC104 is pre-configured with the information, the BSC104 may broadcast the capabilities of the PDSN110 in an overhead message over the air interface. Thus, at time t2, the BSC104 sends the capability information to the MS 102. In addition, at time t3, the BSC104 implements an a9 connection-a 8 setup procedure with the PCF 108. The BSC104 informs the PCF108 of the general capacity of the broadcast/multicast service via an a 9-setup-A8 message. At time t4, the PCF108 relays this information to the PDSN110 via an A11-registration-request message. Based on this information, the PDSN applies the appropriate processing to the broadcast/multicast service. At time t5, the PDSN 108 begins sending data to the MS 102 through the BSC104 as received from the CS. Based on the IP multicast address of the received packet, the PDSN forwards the packet to the PCF via the appropriate a10 connection corresponding to the IP multicast address. The PCF forwards the data received from the a10 connection to its corresponding A8 connection to the BSC.

The second embodiment discussed herein is illustrated in fig. 4 and 5. According to the second embodiment, the MS 102 dynamically triggers BC service setup because the BSC104 is not preconfigured with capability information. The MS 102 sends a BC registration request to the BSC104 at time t 1. The BC registration request identifies a particular desired BC service, such as a stock quote, a news service, a sporting event, and the like. The BSC104 receives the request and identifies the PDSN110 supporting the BC service. The BSC104 then sends the query (through the PCF 108) to the PDSN110 at time t 2. The BSC104 initiates an a 9-setup-A8 connection with the PCF108 by sending an a 9-setup-A8 message to the PCF 108. The PCF forwards the query to PDSN110 using an a 11-registration-request message. The PCF108 establishes an a11 connection with the PDSN110 at times t3 and t 4. The PCF108 forwards the PDSN110 to the BSC104 accordingly, via a 9-connection-A8. The BSC104 broadcasts the information in an overhead message over the air interface, knowing the PDSN 100 capabilities to handle the requested broadcast/multicast service. Thus, as illustrated, PCF108 receives the capacity information from PDSN110 at time t5, and the information is sent to MS 102 at time t 6. As illustrated in fig. 5, PDSN stores and/or accesses configuration database 150. In one embodiment, there are several options that enable the BSC to identify the PDSN associated with the BC, including but not limited to: (1) the BSC determines which PDSN (described in U.S. patent application No. XXXX, entitled "Method and Apparatus for Selecting a packet data Serving Node for Multi cast/Broadcast Services", Raymond Hsu, attorney number 020063, filed on 5/11/2001, (2) the BSC is provided with information of which PDSN serves which BC service identified by the IP Multicast address.

In the first and second embodiments, the capacity of the BC service may be broadcast periodically, even without a specific request from the MS. This feature is useful (e.g., plus or minus 10 minutes) when a BC service (such as a certain sporting event) starts a window around, and many people watch the event. In this case, the use of requests/queries can overload the reverse and forward common signaling channels. Thus, advertising the capacity of the BC service using the broadcast feature saves air resources. The capacity of the BC service includes, but is not limited to, a header compression capacity, a mapping between an IP multicast address and a bcmcsid, and the like.

The first and second embodiments provide the ability for the network to inform the MSPDSN of general capability information for a particular broadcast/multicast service without requiring the MS to establish a PPP session. However, this comes at the cost of negotiating a reduction in flexibility for different sets of capacity (e.g., header compression algorithms) in addition to broadcasting/multicasting services within overhead messages.

According to the third embodiment illustrated in fig. 6 and 7, the general capacity of the BC service is pre-configured at each PDSN within the network or system. In particular, for each broadcast/multicast service instance within the carrier network, the corresponding generic capabilities (for handling broadcast/multicast services) are pre-configured at all PDSNs of the carrier access network. To determine the capacity for which broadcast/multicast service is desired, the MS 102 first establishes a PPP session to the PDSN110 as shown at time t1 of fig. 6. The PDSN110 is not necessarily a PDSN that supports broadcast/multicast media from the CS 116. Once the PPP session is established, the MS uses the multi-channel streaming protocol (MCFTP) to discover the PDSN capabilities to support the desired broadcast/multicast service at time t 2. MS 102 sends a query requesting the capacity information using MCFTP over PPP. As illustrated in fig. 7, a plurality of PDSNs store and/or access configuration database 150.

The third embodiment provides a process that is transparent to the BSC104 and PCF108, as well as other involved elements (not shown). The MS 102 knows the general capabilities of the broadcast/multicast service regardless of which PDSN within the network is its MCFTP peer. In other words, the MS is not necessarily required to establish a PPP connection with the PDSN supporting the broadcast session, since all PDSNs are pre-configured with the capability information. MS 102 then knows the capability information from the first PDSN and then receives a broadcast session through a different PDSN. Also, since the capacity information is not periodically broadcast within overhead messages over the air interface, air link resources are not wasted.

In another aspect, the third embodiment application may require each PDSN within a carrier access network to be pre-configured with the capability of all broadcast/multicast services, even though some PDSNs may not be able to support all broadcast/multicast services. It is possible that only a subset of PDSNs within the carrier access network can support the broadcast/multicast service. Overhead is introduced in the process by making all PDSNs within the network broadcast/multicast service aware. For example, when changed, the change is updated for each PDSN within the network. In addition, the MS establishes a PPP session with the normal data call with the selected service option 33 to run MCFTP. The disadvantage of using MCFTP is that capacity is discovered for BC services, a unicast method that requires traffic channels to be established over the air. It is not efficient to use the traffic channel over the air for this purpose. In another aspect, the first and second embodiments may use a common signaling channel, which is more efficient than using a traffic channel to transmit the same information to the MS. Moreover, the first and second embodiments may broadcast the capacity of the BC service on a broadcast common channel, which is even more efficient over the air.

In a fourth embodiment, the MS 102 knows general capability information for broadcast/multicast services using MCFTP, where the PDSN is pre-configured with capability information. In contrast to the third embodiment, only the PDSN supporting the broadcast is configured with the capability information. In addition, unlike the third embodiment, the MS does not necessarily need to establish a PPP session to an ODSN supporting a broadcast/multicast flow. As illustrated in fig. 8, the CS 214 communicates with the PDSNs 202 and 204 via the IP interface 208. And within system 200 are PDSNs 206 and 212 in communication with resources (not shown) via IP interface 210. The PDSNs 206 and 212 may communicate with any of a variety of other data resources. An MS, such as MS 102, may communicate with any of PDSNs 202, 204, 206, and 212. Notably, multiple PDSNs may communicate with the MS through a common PCF (not shown).

The MS (not shown) may establish a PPP session to the PDSN206 that does not receive broadcast content from the CS 216. The MS uses MCFTP to query the PDSN206 for the general capacity of the desired broadcast/multicast service. Upon receiving the request, the PDSN206 uses an inter-PDSN protocol to request capacity information from the PDSN202 and/or the PDSN 204, each of which receives broadcast content from the CS 216. For example, the PDSN206 sends the query to a multicast group, where the group members are PDSNs within a carrier network, such as system 200. The query requests capability information (identified by ID and MC IP address) related to the broadcast/multicast service. The query is then sent in the form of an IP MC packet to the multicast group of PDSN members. In one embodiment, the group is identified by a reserved IP multicast address with administrative scope so that packets are not forwarded outside the carrier network for security reasons.

Upon receiving the query, these PDSNs supporting the specified broadcast/multicast service respond with capability information. Other PDSNs may discard queries that are not active. The capacity response is then sent to the same multicast group of PDSN members. As a way to reduce the flow of responses from multiple PDSNs to the same query, if a PDSN has sent a response, other PDSNs can see and do not send the same response. Upon receiving the response, the PDSN206 uses MCFTP to provide the requested MS with capability information. Likewise, other PDSNs may discard responses that are not active (i.e., silent).

The fourth embodiment is further illustrated in fig. 9 by process 300. The process waits for an MS query for PDSN capability information at decision diamond 302. Based on the MS query, the process continues to step 304 to send a multicast query requesting the capability information. The multicast query may be sent to all PDSNs within the network, or may be sent to a subset thereof. Each PDSN determines at decision diamond 312 whether BC is supported, and if the PDSN supports the specified BC, the process continues to decision diamond 312. To determine whether a reply is sent by another PDSN. If no reply is sent, the PDSN sends a reply at step 310, and if a reply is sent, the process returns to waiting for the next query from the MS. If the PDSN does not support the specified BC at decision diamond, the process returns to waiting for the next query from the MS.

According to the fourth embodiment, the MS does not necessarily need to be connected to a PDSN supporting broadcast/multicast content. The general capacity of a given broadcast session may be obtained without the need for that particular connection. Yet another inter-PDSN protocol may be used to exchange information regarding serving PDSN capabilities for broadcast/multicast services.

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

Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, 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 upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with: a general purpose processor, a Digital Signal Processor (DSP) or other processor, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, to implement the functions described herein. A general purpose processor is preferably a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

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

The previous description of the preferred embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without the use of the inventive faculty. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (31)

1. In a communication system supporting a broadcast service, a method comprising:

preconfiguring a first infrastructure element with capability information of a first broadcast service;

the first infrastructure element provides the capability information to the mobile station in accordance with the request for the first broadcast service.

2. The method of claim 1, wherein the capability information includes header compression information and a mapping between bcmcsid and IP multicast address.

3. The method of claim 1, further comprising:

the first infrastructure element is reconfigured to update the capacity information.

4. The method of claim 1, wherein the first infrastructure element providing capability information further comprises:

providing the capacity information to the second infrastructure element.

5. The method of claim 1, wherein the first infrastructure element is a base station controller.

6. The method of claim 5, wherein the second infrastructure element is a packet data serving node.

7. The method of claim 1, wherein reconfiguring the first infrastructure element comprises establishing capacity information access to the first broadcast service for the purpose of from a configuration database.

8. The method of claim 7, wherein pre-configuring the first infrastructure element comprises establishing capacity information access to other broadcast services from a configuration database.

9. An apparatus in a communication system, the communication system supporting a broadcast service, comprising:

means for pre-configuring a first infrastructure element with capability information for a first broadcast service;

means for providing the capability information to the mobile station by the first infrastructure element in response to the request for the first broadcast service.

10. An infrastructure element in a wireless communication system, wherein the infrastructure element is configured to implement a method comprising:

accessing a configuration database, the configuration database including a broadcast service list and corresponding capacity information; and

corresponding capability information is provided to elements within the wireless communication system in accordance with a request for a first broadcast service within the list of broadcast services.

11. The infrastructure element of claim 10, wherein the capability information comprises header compression information.

12. The infrastructure element of claim 10, further adapted to:

the infrastructure elements are reconfigured to update the capacity information.

13. The infrastructure element of claim 10, further adapted to:

providing the capacity information to the second infrastructure element.

14. The method of claim 13, wherein the infrastructure element is a base station controller.

15. The infrastructure element of claim 14, wherein the second infrastructure element is a packet data serving node.

16. In a communication system supporting a broadcast service, a method comprising:

establishing a point-to-point protocol (PPP) connection from the mobile station to the infrastructure element;

requesting capacity information for the first broadcast service through the PPP connection; and

in accordance with the request, the infrastructure element provides the mobile station with capability information.

17. A mobile station in a wireless communication system supporting a broadcast service, wherein the mobile station is configured to implement:

establishing a point-to-point protocol (PPP) connection to an infrastructure element;

requesting capacity information of the first broadcast service through the PPP connection;

receiving capacity information; and

the capacity information is applied to the broadcast service data.

18. A packet data serving node in a wireless communication system supporting broadcast services, the packet data serving node being configured to implement:

establishing a point-to-point protocol (PPP) connection to the mobile station;

receiving a request for capacity information for a first broadcast service over a PPP connection;

providing the capability information to the mobile station; and

the capacity information is applied to the broadcast service data.

19. The method of claim 1, wherein the first infrastructure element providing the capacity information further comprises:

the capacity information is provided to the second infrastructure element.

20. An apparatus in a communication system, the communication system supporting broadcast services, the apparatus comprising:

means for pre-configuring a first infrastructure element with capability information for a first broadcast service;

means for providing the capability information to the mobile station by the first infrastructure element in response to the request for the first broadcast service.

21. An infrastructure element within a wireless communication system, the infrastructure element configured to implement a method, the method comprising:

accessing a configuration database, the configuration database including a broadcast service list and corresponding capacity information; and

corresponding capability information is provided to elements within the wireless communication system based on a first broadcast service request within the list of broadcast services.

22. The infrastructure element of claim 21, wherein the capability information comprises header compression information.

23. The infrastructure element of claim 21, further adapted to:

the infrastructure elements are reconfigured to update the capacity information.

24. The infrastructure element of claim 21, further adapted to:

the capacity information is provided to the second infrastructure element.

25. The infrastructure element of claim 24, wherein the infrastructure element is a base station controller.

26. The infrastructure element of claim 25, wherein the second infrastructure element is a packet data serving node.

27. In a communication system supporting a broadcast service, a method comprising:

establishing a PPP session between the mobile station and the first infrastructure element;

the first infrastructure element sending a capability information query for the first broadcast service to a first group of infrastructure elements;

the first infrastructure element receiving a response from at least one infrastructure element of the first group; and

the first infrastructure element sends the capability information to the mobile station.

28. The method of claim 27, wherein the infrastructure elements of the first group support a first broadcast service.

29. The method of claim 28, wherein the first infrastructure element is not within the first group.

30. An infrastructure element within a wireless communication system, the infrastructure element configured to implement a method, the method comprising:

receiving a capability information query for a first broadcast service, the query having a multicast address; and

responding to the query.

31. The infrastructure element of claim 30, wherein responding to the query comprises:

receiving a response to the query from another infrastructure element, the response with the multicast address; and

the query is ignored.