HK1076212B - Method and apparatus for flow treatment and mapping on multicast/broadcast services - Google Patents

Description

Stream processing and mapping method and apparatus for multicast/broadcast service

Technical Field

The present invention relates generally to wireless communication systems, and more particularly to methods and apparatus for stream processing and stream mapping for broadcast/multicast services.

Background

There is an increasing demand for packet data services over wireless communication systems. The extension to support data services poses a number of challenges as conventional wireless communication systems are designed for voice communications. In particular, the provision of unidirectional services, such as broadcast services, in which video and audio information is streamed to be delivered to subscribers, has a unique set of requirements and goals. Such services may have large bandwidth requirements where system designers seek to minimize the transmission of overhead (overhead) information. In addition, specific information is needed to transfer and/or access the broadcast transmission, such as processing parameters and protocols. There is a problem in transmitting broadcast-specific (broadcast-specific) information while optimizing the use of available bandwidth.

Accordingly, there is a need for an efficient and accurate method of transmitting data in a wireless communication system. Furthermore, there is a need for an efficient and accurate method of providing service-specific (service-specific) information.

Drawings

Fig. 1 is an illustration of a spread spectrum communication system supporting several users.

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

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

Fig. 4 is a block diagram illustrating a connection between a packet data serving node and a base station.

Fig. 5 is a flow diagram for accessing broadcast services in a wireless communication system topology.

FIG. 6 is a block diagram of an embodiment of stream processing and mapping data.

Fig. 7 is a block diagram of flow processing and mapping data attached to an a11 registration request message.

Fig. 8 is a block diagram illustrating stream processing and mapping data as part of an a11 registration request message.

Fig. 9 is a flowchart for accessing a broadcast service in a wireless communication system topology, illustrating stream processing and mapping data transmitted together with an a11 registration request message.

Fig. 10 is a flowchart for accessing a broadcast service in a wireless communication system topology, illustrating stream processing and mapping data transmitted after an a11 registration request message.

Fig. 11 is a system overhead parameter message configuration.

Fig. 12 is a block diagram of a packet data serving node.

Fig. 13 is a flowchart of flow processing and flow mapping for a multicast/broadcast service in a wireless communication system.

Fig. 14 is a block diagram of a communication system supporting multicast/broadcast illustrating two packet data serving nodes and two mobile stations.

Fig. 15 is a block diagram of a communication system supporting multicast/broadcast illustrating a PDSN to PDSN handoff.

Detailed Description

The word "exemplary" is used exclusively herein to refer to "as an example, instance, or illustration.

Exemplary embodiments of the wireless communication system employ a header compression method that reduces the size of the header while meeting the accuracy and transmission requirements of the system. 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 the broadcast service "tune in" to the designated channel to access the broadcast transmission. Because of the large bandwidth requirements of high-speed transmission of video broadcasts, it is desirable to reduce the size of any overhead (overhead) associated with such broadcast transmissions.

Sometimes, a broadcast service may be used as a service that sends information to a group of users according to their geographical locations. This may also be referred to as "unaddressed" messaging. An example could be to broadcast local information such as traffic or weather alerts based on cell/sector or specific paging area. All users in the area that are able to receive the broadcast information will receive the information.

Broadcast services may also be used for multicasting. Multicasting may involve broadcasting information to a particular group of users based on their subscription to a group of users. The user group may be maintained by an administrator. Further, the user group may be publicly bookable (e.g., signed up for advertisements, stock quotes, etc.), or it may be close to public subscription (e.g., a group list). The multicast list may also be configured to cause the mobile device to acknowledge receipt of the message as specified by the user group administrator. This may be considered addressable messaging.

Multicast user groups are generally considered to be groups limited to a few people. In these groups, members typically subscribe to a service (a common multicast group) by sending a request to the administrator via some web interface or other mechanism. Private multicast groups are limited to membership that is explicit by an administrator adding members manually.

Broadcast services may also be divided into public and private groups. The public broadcast group uses sending geographic-specific (geographic-specific) information. All devices with broadcast capability in a particular geographic area are in a common group and will receive the information. Examples of broadcast information for such public address types are emergency weather alerts, traffic conditions, etc. A private broadcast group is directed to sending specific information to a specific group of devices in a certain area. An example of this type of service may be location-based advertising. One possible scenario for this example is when the user is in a mall, he or she may choose to receive a particular advertisement, but not at other times.

The following discussion expands the exemplary embodiments by first generally presenting a spread spectrum wireless communication system. Next, a broadcast service is introduced, wherein the service is referred to as a High Speed Broadcast Service (HSBS). For user traffic and signaling, an interface between a base station and a packet data serving node is introduced. Messages for establishing an a10 connection for user traffic are discussed. Flow processing and mapping data for communicating processing and mapping information to a packet data 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, giving details of the use of service option parameters to define the compression algorithm are shown. Finally, several benefits of using stream processing and mapping data to convey processing and mapping information are presented.

Note that throughout this discussion, exemplary embodiments are provided as exemplary; however, other alternative embodiments may incorporate various aspects without departing from the scope of the invention. In particular, the invention is applicable to data processing systems, wireless communication systems, one-way broadcast systems, and any other system in which efficient transmission of information is desired.

Wireless communication system

The exemplary embodiments employ spread spectrum communication systems to support broadcast services, and wireless communication systems are widely deployed to provide various types of communication such as voice, data, and so on.

The System may be designed to support one or more standards such as "TIA/EIA/IS-95-B Mobile Station-Base Station Compatibility Standard for Dual-Mode Wireless Spread Spectrum Cellular System," referred to herein as the IS-95 Standard, the Standard referred to herein as the W-CDMA Standard, which IS provided by a consortium referred to herein as the 3rd Generation Partnership Proc, and which IS embodied in a set of documents including document numbers 3G TS 25.211, 3G TS 25.212, 3G TS 25.213, 3G TS 25.214, 3G TS 25.302, the Standard referred to herein as the W-CDMA Standard, the Standard provided by a consortium referred to herein as the 3GPP2, 3G Partnership Proc 2, and the TR-45.5, referred to herein as the CD 2000 Standard, referred to herein as the IS-2000 MC.

Each standard explicitly defines the processing of data for transmission 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 standard of protocols. Alternative embodiments may incorporate other criteria. Other embodiments may apply the compression methods disclosed herein to other types of data processing systems.

Fig. 1 serves as an example of a communication system 100 that supports a number of users and is capable of implementing at least some aspects of the embodiments disclosed herein. Any of a variety of algorithms and methods may be used to schedule transmissions in system 100. System 100 provides communication for a number of cells 102A-102G, each of which is serviced by a corresponding base station 104A-104G, respectively. In the exemplary embodiment, some base stations 104 have multiple receive antennas, while other base stations have only one receive antenna. Similarly, some base stations 104 have multiple transmit antennas, while other base stations have a single transmit antenna. There is no limitation on the combination of the transmit and receive antennas. Thus, the base station 104 may have multiple transmit antennas and only one receive antenna, or the base station may have multiple receive antennas and only one transmit antenna, or the base station may have single or multiple transmit and receive antennas.

Terminals 106 in the coverage area may be fixed (i.e., stationary) or mobile. Each terminal 106 communicates with at least one and possibly multiple base stations 104 on the downlink or uplink at any given moment, depending on, for example, whether soft handoff is employed or whether the terminal is designed and operated to receive multiple transmissions (simultaneously or sequentially) from multiple base stations. Soft handoffs in CDMA communication systems are known in the art and are described in detail in U.S. Pat. No. 5101501 entitled "Method and System for providing a software handoff in a CDMA Cellular Telephone System", assigned to the assignee of the present invention.

The downlink refers to transmission from the base station 104 to the terminal 106, and the uplink refers to transmission from the terminal 106 to the base station 104. In the exemplary embodiment, some terminals 106 have multiple receive antennas, while other terminals 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.

High Speed Broadcasting System (HSBS)

A wireless communication system 200 is illustrated in fig. 2, wherein one or more Content Servers (CS)202 provide IP packets to one or more Packet Data Serving Nodes (PDSN)206 over an IP network. The CS 202 provides data that is communicated as internet protocol data packets ("IP packets") over the IP network 204. The CS 202 may transmit many different kinds of data. For example, audio data, video data, text data, electronic files, etc. may be transmitted by the CS 202 over the IP network 204. The video and audio information may be from a televised program or a radio broadcast. Thus, the CS 202 may be a server configured to serve video data, audio data, and the like. In one embodiment, the CS 202 may be a web server connected to the Internet and used to provide data to users browsing the world Wide Web. The IP network 204 may be the internet, an intranet, a private IP network, or the like.

The PDSN206 receives and processes the IP packets to communicate them to one or more base stations 208 (BSs). As shown, each PDSN206 is in electronic communication with one or more BSs 208. Once the BS 208 receives the data, it then transmits the data to one or more mobile stations 210 (MSs). The MS210 corresponds to the terminal 106 of fig. 1. Each BS 208 may serve one or more MSs 210. In general, the BS 208 serves many MSs 210.

Referring now to fig. 3, as described, information from the CS 202 is provided in packet data, such as IP packets. The PDSN206 processes IP packets for distribution within AN Access Network (AN) 300. As illustrated, AN 300 is defined as part of a system 200 that includes a BS 208 in communication with a plurality of Mobile Stations (MSs) 210. The PDSN206 is coupled to the BS 208. For HSBS service, BS 208 receives the information stream from PDSN206 and provides the information to subscribers in system 200 on designated channels. Note that alternative embodiments may implement a Packet Control Function (PCF) mode between the PSDN and the BS. Other embodiments may implement the PCF and the BS in one mode and/or cell.

An HSBS is a stream of information provided over the air interface in a wireless communication system. An "HSBS channel" refers to a single logical HSBS broadcast session as defined by the broadcast content. Note that the content of a given HSBS channel may change over time, such as 7 a.m. news, 8 a.m. weather forecast, 9 a.m. movie, etc. The time-based scheduling is similar to a single TV channel. A "broadcast channel" refers to a single forward link actual 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 will be multiplexed in a Time Division Multiplexing (TDM) fashion in a single broadcast channel. 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 in those frequencies.

According to an exemplary embodiment, the system 100 illustrated in fig. 1 supports a high speed multimedia broadcast service called High Speed Broadcast Service (HSBS). Any user wishing to receive HSBS services may subscribe to the CS 202. The subscriber can then scan for broadcast service plans that may be provided by the CS 202 in various ways. For example, broadcast content may be disseminated via advertisements, Short Message System (SMS) messages, Wireless Application Protocol (WAP), and/or some other means that generally conforms and facilitates use of mobile wireless communications. The base station 208(BS) transmits parameters related to the HSBS in overhead messages, e.g., those transmitted 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. a video program or the like. When a broadcast service subscriber wishes to receive a broadcast session, i.e., a certain broadcast scheduled program, MS210 then tunes to the frequency containing the HSBS channel and then receives the broadcast service content.

In order for the MS210 to successfully discover and listen to the broadcast channel, various broadcast service related parameters are conveyed over the air interface. Broadcast services are designed to support different protocol options in the protocol stack. This requires that the recipients of the broadcast service be informed of protocol options to facilitate proper decoding and processing of the broadcast. In one embodiment, the CS 202 provides this information to the receiver as an overhead system parameter message, consistent with cdma 2000. The receiver has the advantage 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 overhead system parameter messages. The system may implement a service option number corresponding to a set of parameters and protocols, where the service option number is provided in an overhead message. Optionally, 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.

Referring now to fig. 4, the PDSN206 has multiple interfaces to interface with one or more BSs 208. In the embodiment described herein, the PDSN206 has a signaling connection to the BS 208, which will be referred to as the a11 interface. In addition, there is a connection for user traffic between the PDSN206 and the BS 208, which will be referred to herein as the a10 interface. The a10 interface is used to provide a path for user traffic between the BS 208 and the PDSN206 for packet data services. Typically, the BS 208 initiates an a10 connection, but the PDSN206 or BS 208 may revoke it. The a11 interface is used to provide a signaling connection between the BS 208 and the PDSN206 for packet data services.

Fig. 5 is a flow diagram illustrating an embodiment for establishment of a connection to be used to transmit data from the CS 202 to the MS 210. The horizontal axis represents the topology of the system, i.e. the infrastructure elements. The vertical axis represents a timeline. Those skilled in the art will appreciate that other steps are not shown here in order to focus on the inventive aspects of the embodiments. At time t1, the BS 208 attempts to establish an a10 connection with the PDSN206 by using the a11 signaling connection. According to the exemplary procedure shown, BS 208 sends an a11 registration request message to PDSN 206. The BS 208 sends an a11 registration request message to the same PDSN206 currently in use to establish a new a10 (bearer) connection between the BS 208 and the PDSN 206. The a11 message contains a service option number (HSG) and a SR _ ID parameter.

At time t2, the PDSN206 sends an a11 registration response message to the BS 208 to establish an a10 connection at time t 3. Once the a10 connection is established, at time t4, a connection is established between the PDSN206 and the MS210 using the newly established a10 connection. The CS 202 may then transmit data to the PDSN206 at time t5, at time t6, the PDSN206 sends the data to the MS210 through the BS 208. Note that in IETF and 3GPP2, RTSP and SDP are standardized methods for establishing unidirectional streaming services.

In one embodiment, the broadcast channel protocol and parameters may be conveyed to the MS 210. In another embodiment, each set of broadcast protocols and parameters may be assigned a Service Option (SO) number, where the SO number is transmitted to multiple receivers. The MS210 may use the transmitted SO number to discover protocol options for the broadcast service. In contrast to unidirectional packet data services, where the SO specifies protocols up to the IP network layer, broadcast services specify protocols up to the application layer.

The SO number maps to a set of parameters and protocols sufficient for the MS210 to receive the desired broadcast. MS210 then initiates the protocol stack corresponding to the selected SO number. Once the protocol stack is initiated, the MS210 is able to receive and decode information received on the broadcast channel.

The PDSN206 may support and effectuate various types of compression to reduce the traffic sent to the BS 208. The PDSN206 may support the following header compression algorithms: van Jacobson TCP/IP header compression (RFC 1144), header compression (RFC 2507), compressed RTP/UDP/IP headers (RFC 2508), header stripping/generation techniques (wireless IP network standard, document identification number 3gpp2p.s 0001-B).

When the PDSN206 receives the IP packets, it determines where to send the IP packets and how to compress the packets. The mapping (forward transport type function) of the IP packets by the PDSN206 to the a10 connection may be referred to as flow mapping. The manner in which the PDSN206 compresses the IP packets may be referred to as flow processing. As used herein, a flow is a series of packets that may share a particular instance of an IETF protocol layer. For example, an RTP stream may consist of packets of IP/UDP/RTP instances, all sharing the same source and destination IP addresses and UDP port numbers.

With respect to flow mapping, in order to send IP packets to the correct MS210, the PDSN206 accurately maps the incoming IP packets to the a10 connection so that the packets can be delivered to the correct MS 210. The IP packet is then sent to BS 208 over an a10 connection. BS 208 then sends the IP packet to MS 210.

With respect to flow processing, the PDSN206 compresses the IP packets using the determined compression method and then transmits the packets to the BS 208. As depicted, BS 208 transmits the IP packet to MS 210. The MS210 may then decompress the IP packets.

BS 208 may provide flow processing and flow mapping information to PDSN206 by sending flow processing and mapping data 602 to PDSN206 at the a10 connection establishment means. Another method that may be used to provide flow processing and flow mapping information to the PDSN206 is to use the multi-channel flow processing protocol (MCFTP), which was developed by 3GPP2 and is described in the 3GPP2 document p.s0001-B, "Wireless IP networks standards," incorporated herein by reference. The apparatus and method disclosed herein for providing flow processing and flow mapping information to the PDSN206 is an alternative to MCFTP and provides certain benefits over MCFTP.

An embodiment of stream processing and mapping data 602 is illustrated in FIG. 6. As shown, this embodiment of the stream processing and mapping data 602 includes an IP multicast address 604 and a service option parameter 606. The IP multicast address 604 is used to map the broadcast/multicast packet stream (identified by the address in the IP packet header) to the appropriate a10 connection. The service option parameter 606 is used to indicate whether header compression should be allowed and, if so, which header compression algorithm should be used.

The BS 208 provides flow processing and mapping data 602 to the PDSN 206. Those skilled in the art will appreciate various ways of providing the flow processing and mapping data 602 to the PDSN 206. In one embodiment and as shown in fig. 7, the flow processing and mapping data 602 may be appended to an a11 registration request message 702 sent by the BS 208 to the PDSN206 in the establishment of an a10 connection (illustrated in fig. 5). Alternatively, as shown in fig. 8, the stream processing and mapping data 602 may be sent as part of an a11 registration request message 702.

Fig. 9 is a flowchart illustrating the BS 208 transmitting flow processing and mapping data 602 in the establishment of a connection to transmit data from the CS 202 to the MS 210. As shown at time t1, an a11 registration request message including flow processing and mapping data 602 may be sent from BS 208 to PDSN 206. Alternatively, as shown in fig. 10, the stream processing and mapping data 602 may be sent immediately after the successor a11 registration request message 702 at time t1 a. Those skilled in the art will appreciate that various means may be used to convey the flow processing and mapping data 602 from the BS 208 to the PDSN 206.

BS 208 may obtain stream processing and mapping data 602 in various ways. For example, MS210 may send flow processing and mapping data 602 to BS 208. Alternatively, BS 208 may pre-configure stream processing and mapping data 602.

As described above with respect to fig. 6, the service option parameter 606 is part of the stream processing and mapping data 602. The service option parameter 606 indicates to the PDSN206 what header compression is to be used for IP packets being sent to the corresponding IP multicast address 604. FIG. 11 illustrates a mapping 1102 of different service option ("SO") parameters to a set of parameters and protocols. The PDSN206 pre-configures knowledge of various service option parameter numbers (SO m.. SO N) SO that once the service option parameters 606 are known, the PDSN206 can obtain the required parameters and protocols.

Fig. 12 is a block diagram of an embodiment of the PDSN206 illustrating flow processing and flow mapping. In the embodiment of fig. 12, the PDSN206 stores any flow processing and mapping data 602 so that each segment of the data 602 can be accessed according to an IP multicast address 604. Based on the IP multicast address 604, the PDSN206 may determine which a10 connection to map the flow to, and which service option parameters 606 to use in determining how to compress and process the flow.

Fig. 13 illustrates an embodiment of a method of transmitting IP packets from CS 202 to MS210 using flow processing and mapping data 602. The flow chart of fig. 13 assumes that flow processing and mapping data 602 has been transferred by BS 208 to PDSN 206. The CS 202 sends 1302 the IP packet to the PDSN 206. Typically, the IP packets are sent over IP network 204. The PDSN206 receives 1304 the IP packet and determines 1304 an IP multicast address. The PDSN206 identifies the IP multicast address from the address of the packet header. The PDSN206 then performs (1306) a lookup of the IP multicast address to identify the corresponding flow processing and mapping data 602. By looking up the IP multicast address, the PDSN206 finds which a10 connection to map the IP packet to, and how to process the IP packet. The PDSN206 then compresses 1308 the header according to the service option parameters 606. After performing the required compression, the PDSN206 sends down 1310 the processed IP packets to the appropriate a10 connection (i.e., the a10 connection corresponding to the IP multicast address).

BS 208 receives (1312) the IP packets from PDSN206 and conveys (1314) the IP packets to MS210 via the service instance. The MS210 then receives (1316) the packet and decompresses the header as needed. The MS210 is then able to access and use the data sent over the IP packets.

A service instance is an abstraction for supporting the transport of one or more communication classes over the air interface. For example, cdma2000 wireless IP networks support three types of service instances: SI-TYPE _1, SI-TYPE _2, and SI-TYPE _ 3. The first TYPE, SI-TYPE _1, identifies a service instance that provides low-error air interface transmission based on an octet stream for delay-insensitive and error-sensitive communications. The second TYPE, SI-TYPE _2, identifies a service instance that provides frame-based air interface transmission for a cdma2000 voice codec operating in synchronization with cdma2000 radio framing. Finally, the SI-TYPE _3 TYPE identifies a service instance that provides an octet stream based air interface transmission for delay sensitive and error insensitive communications.

In the embodiment discussed herein, the PDSN206 is configured to support a single PPP session over multiple a10 connections for the same MS 210. Each a10 connection corresponds to a service instance.

As described above, one alternative method for providing flow processing and flow mapping information to the PDSN206 is through the use of MCFTP. However, the apparatus and method disclosed herein overcome the disadvantages of MCFTP for supporting broadcast/multicast services. Fig. 14 and 15 illustrate the disadvantages of MCFTP, and how embodiments disclosed herein overcome these disadvantages.

In a particular network topology, it is possible that the MS210 receives a broadcast/multicast packet stream from one PDSN206, but has established a PPP session with another PDSN 206. For example, in fig. 14, a first MS 1410A has established a PPP session with a first PDSN 1406A. The second MS 1410B establishes a PPP session with the second PDSN1406B but the broadcast/multicast packet stream is sent from the first PDSN a. If MCFTP is used, the flow processing and flow mapping information sent by the second MS 1410B to the second PDSN1406B via MCFTP over a PPP session is not used because the broadcast/multicast packet flow does not pass through the second PDSN 1406B. As a result, unnecessary information is maintained in the second PDSN1406B, thereby unnecessarily using internal resources of the second PDSN 1406B. Another disadvantage is that unnecessary MCFTP messages are exchanged, wasting air resources. By using the apparatus and methods disclosed herein, the second MS 1410B need not send flow processing and mapping information to the second PDSN 1406B.

Fig. 15 illustrates a PDSN to PDSN handoff. During a PDSN-to-PDSN handoff, MS 1510 moves from a first PDSN 1506A to a second PDSN1506B as shown. If MCFTP is used. The MS 1510 needs to establish a PPP session with the second PDSN1506B and send flow processing and mapping information to the second PDSN1506B via MCFTP before the MS 1510 can receive the broadcast/multicast flow from the second PDSN 1506B. As a result, there is a delay associated with the establishment of the PPP session and MCFTP messages are exchanged during the PDSN-to-PDSN handoff. By using the apparatus and methods disclosed herein, the MS 1510 need not establish a PPP session with the second PDSN1506B, nor send MCFTP messages. Without the additional delay incurred by the PPP session setup and MCFTP message exchange, MS 1510 is able to view the broadcast/multicast service quickly after handoff with a small service interruption.

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, currents, 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, certain 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), 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 designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also 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 storage medium is 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 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 description of the disclosed 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 departing from the spirit or scope of the invention. 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 (33)

1. A method in a wireless communication system supporting a broadcast service, the method comprising:

receiving an IP multicast address and a service option parameter for a broadcast service from a base station during establishment of a user traffic channel between a packet data serving node and the base station;

receiving a broadcast packet stream transmitted via an IP network;

determining header compression using the service option parameter;

compressing a packet header of a broadcast packet stream; and

the broadcast packet stream identified by the address in the packet header is mapped to a user traffic channel using an IP multicast address.

2. The method of claim 1, wherein the broadcast service is transmitted by a content server.

3. The method of claim 1, wherein the broadcast service is transmitted in internet protocol data packets.

4. The method of claim 2, wherein the content server provides the broadcast packet stream to a packet data serving node over an IP network.

5. The method of claim 1, wherein the broadcast packet stream comprises video data.

6. The method of claim 1, wherein the broadcast packet stream includes audio data.

7. The method of claim 1, wherein the user traffic channel is an a10 connection.

8. The method of claim 1, wherein the IP multicast address and the service option parameter are received via a signaling connection between the packet data serving node and the base station.

9. The method of claim 8, wherein the signaling connection is an a11 connection.

10. The method of claim 9, wherein the IP multicast address and service option parameters are sent in conjunction with an a11 registration request message.

11. A method in a packet data serving node, comprising:

receiving stream processing and mapping data from a base station during establishment of a user traffic channel with the base station;

receiving a broadcast packet stream;

determining header compression using service option parameters from streaming and mapping data;

compressing a packet header of a broadcast packet stream; and

the broadcast packet stream identified by the address in the packet header is mapped to a user traffic channel using an IP multicast address from the streaming and mapping data.

12. The method of claim 11, wherein the broadcast packet stream is transmitted by a content server.

13. The method of claim 11, wherein the broadcast packet stream is transmitted in internet protocol data packets.

14. The method of claim 11, wherein the content server provides the broadcast packet stream to the packet data serving node through an IP network.

15. The method of claim 11, wherein the broadcast packet stream comprises video data.

16. The method of claim 11, wherein the broadcast packet stream includes audio data.

17. The method of claim 11, wherein said user traffic channel is an a10 connection.

18. The method of claim 11, wherein the IP multicast address and the service option parameter are received via a signaling connection between the packet data serving node and the base station.

19. The method of claim 18, wherein the signaling connection is an a11 connection.

20. The method of claim 19, wherein the IP multicast address and service option parameters are sent in conjunction with an a11 registration request message.

21. A packet data serving node for receiving IP packets from an IP network and transmitting the IP packets to a base station, the packet data serving node comprising:

an a10 connection for conveying user traffic to the base station;

an a11 connection for conveying signaling information to the base station;

an IP network connection for connecting the packet data serving node to an IP network;

means for receiving stream processing and mapping data including an IP multicast address and service option parameters from a base station via an a11 connection during establishment of an a10 connection;

means for storing the stream processing and mapping data;

means for mapping the IP packets to the a10 connection according to their multicast address and using the stream processing and mapping data; and

means for compressing the IP header according to the service option parameter.

22. The packet data serving node of claim 21, wherein the IP packet is sent by a content server.

23. The packet data serving node of claim 22, wherein the content server provisions the packet data serving node with IP packets over an IP network.

24. The packet data serving node of claim 21, wherein the IP packet includes video data.

25. The packet data serving node of claim 21, wherein the IP packet includes audio data.

26. The packet data serving node of claim 21, wherein the flow processing and mapping data is parsed from an a11 registration request message.

27. A method in a base station for supporting a broadcast service in a wireless communication system, comprising:

configuring stream processing and mapping data comprising an IP multicast address and service option parameters;

establishing a signaling connection with a packet data serving node;

requesting a user traffic channel with a packet data serving node through the signaling connection;

during the establishment of a user traffic channel, sending stream processing and mapping data to a packet data serving node;

establishing a user traffic channel with a packet data service node; and

receiving an IP packet on a user traffic channel, wherein the IP packet is addressed to an IP multicast address, wherein a packet header of the IP packet is compressed according to a service option parameter.

28. The method of claim 27, wherein the IP packets comprise video data.

29. The method of claim 27, wherein the IP packet comprises audio data.

30. The method of claim 27, wherein the user traffic channel is an a10 connection.

31. The method of claim 27, wherein the signaling connection is an a11 connection.

32. The method of claim 27, wherein the flow processing and mapping data is sent to a packet data serving node as part of an a11 registration request message.

33. An apparatus in a wireless communication system supporting a broadcast service, comprising:

means for receiving an IP multicast address and service option parameters for a broadcast service from a base station during establishment of a user traffic channel between a packet data serving node and the base station;

means for receiving a broadcast packet stream transmitted over an IP network;

means for determining header compression according to a service option parameter;

means for compressing packet headers of a broadcast packet stream; and

means for mapping a broadcast packet stream identified by an address in a packet header to a user traffic channel using an IP multicast address.