HK1075152B - Method and apparatus for out-of-band transmission of broadcast service option in a wireless communication system - Google Patents

Description

Method and apparatus for out-of-band transmission of broadcast service options in a radio communication system

Technical Field

The present invention relates generally to wireless communication systems, and more particularly to methods and apparatus for preparing information for transmission in a wireless communication system for compression.

Background

There is an increasing demand for packetized data services within the confines of wireless communication systems. Since conventional wireless communication systems are designed for voice communications, the expansion to support data services introduces a number of challenges. In particular, the provision of unidirectional services, such as broadcast services where video and audio information is streamed to users, has a number of unique requirements and goals. Such services may have a large bandwidth requirement where system designers seek to minimize the transmission of ancillary information. In addition, the user needs to access specific information of the broadcast transmission, such as processing parameters and protocols. There is a problem of optimizing the use of available bandwidth while transmitting broadcast specific information.

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

Disclosure of Invention

The embodiments disclosed herein address the above stated needs by providing a security method in a data processing system.

In one aspect, in a wireless communication system supporting a broadcast service, a method includes transmitting a broadcast session on a variable transmission channel and transmitting broadcast side information corresponding to the broadcast session on a side transmission channel. The broadcast service is transmitted by a content server. The broadcast service has a corresponding protocol stack with an application layer and a transport layer, wherein the content server controls the application layer and transport layer protocols independently.

In another aspect, in a wireless communication system supporting a broadcast service, a method includes receiving broadcast assistance information corresponding to a broadcast session on an assistance transport channel, accessing the broadcast session on the broadcast transport channel, and processing broadcast content of the broadcast session using the broadcast assistance information.

Drawings

Fig. 1 is a schematic diagram 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 model of a protocol stack corresponding to a broadcast service option in a wireless communication system.

Fig. 4 is a protocol table applied to layers of a protocol stack supporting broadcast service options in a wireless communication system.

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

Fig. 6 is a broadcast flow in a wireless communication system.

Fig. 7 is a map of header compression in a wireless communication system.

Fig. 8 is a periodic broadcast of header compression information.

Fig. 9 is a header compression protocol.

Fig. 10 is a header compression protocol for a broadcast service in a wireless communication system.

Fig. 11 is a flow chart of header compression for broadcast services in a wireless communication system.

Fig. 12 is a flow chart of header compression for broadcast services in a wireless communication system.

Fig. 13 and 14 illustrate data transmission in a wireless communication system.

Fig. 15 is a timing diagram of message flow in a wireless communication system.

Fig. 16 is a system assistance parameters message structure.

Fig. 17 is a block diagram of a bit (BLOB) system auxiliary parameter message structure.

Fig. 18 is a flow diagram of broadcast protocol and parameter provisioning in a wireless communication system.

Figure 19 is a mapping of service option numbers to parameter sets.

Fig. 20 shows parameter definition in a wireless communication system.

Fig. 21 is a block diagram of channels of a wireless communication system for supporting a broadcast service.

Fig. 22 is a broadcast stream with auxiliary information interleaved with broadcast content.

Fig. 23 is a method of accessing a broadcast service in a wireless communication system.

Fig.24 shows a memory device for storing broadcast auxiliary information.

Detailed Description

The word "exemplary" is used herein to mean "serving as an example, instance, or illustration. Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments. Although the various aspects of the present invention are illustrated in the accompanying drawings, the drawings are not required to be drawn to scale unless otherwise indicated.

An exemplary embodiment of a wireless communication system employs header compression to reduce the size of each header while meeting the accuracy and transmission requirements of the system. The exemplary embodiment supports a one-way broadcast service. The broadcast service provides video and/or audio streams to a plurality of users. Subscribers to a broadcast service "tune" to a designated channel to access the broadcast transmission. Because of the high bandwidth requirements of high speed transmission of video broadcasts, it is desirable to reduce the size of any overhead associated with such broadcast transmissions.

The following discussion improves upon 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 High Speed Broadcast Service (HSBS), and the discussion includes channel allocation of the exemplary embodiments. Subsequently, subscription modes are introduced, including the selection of pay subscriptions, free subscriptions and hybrid subscription plans, as is now used for television transmission. The details of accessing the broadcast service are then detailed, introducing the details of using the service options to define a given transmission. The flow of information in a broadcast system is discussed in terms of the layout of the system, i.e. the infrastructure elements. Finally, header compression used in exemplary embodiments is discussed.

Note that the exemplary embodiment is provided as an example throughout this discussion. However, other embodiments may include various aspects without departing from the scope of the invention. In particular, the present invention is applicable to data processing systems, wireless communication systems, one-way broadcast systems, and any other system requiring efficient transmission of information.

Wireless communication system

The exemplary embodiments employ a spread spectrum wireless communication system that supports broadcast services. 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 (CDMA), Time Division Multiple Access (TDMA), or some other modulation technique. CDMA systems provide certain advantages over other types of systems, including increased system capacity.

The system may be designed to support one or more standards such as the dual mode wideband spread spectrum cellular system referred to herein as the IS-95 standard with the TIA/EIA/IS-95-B mobile station-base station compatibility standard, referred to herein as the "third generation partnership" standard set forth by the consortium referred to as 3GPP, the W-CDMA standard embodied herein by a set of documents including the documents 3G TS 25.211, 3G TS 25.212, 3G TS 25.213 and 3G TS 25.214, 3G TS 25.302, the TR-45.5 referred to herein as the "third generation partnership 2" standard set forth by the consortium referred to herein as 3GPP2, and the CDMA2000 standard referred to herein, the IS-2000MC standard in the past. The standards cited above are hereby specifically incorporated by reference herein.

Each standard specifically defines the processing of transmission data from a base station to a mobile station and the processing of transmission data from a mobile station to a base station. As an exemplary embodiment, the following discussion considers a spread spectrum communication system to conform to the cdma2000 standard of the protocol. Other embodiments may incorporate another standard. Another embodiment may apply the compression method disclosed herein to other types of data processing systems.

Fig. 1 is intended as an example of a communication system 100 that supports a number of users and is capable of implementing at least some aspects and embodiments of the present invention. Any type of algorithm and method may be used to schedule transmissions in system 100. System 100 provides communication for a number of cells 102A through 102G, each of which is serviced by a corresponding base station 104A through 104G, respectively, it should be understood that the term "base station 104" as used throughout this specification refers to "base stations 104A, 104B, 104C, 104D, 104E, 104F, and 104G". The term "base station 104A" is used for the sake of brevity only. In the exemplary embodiment, some base stations 104 have multiple receive antennas, and other base stations have only one receive antenna. Similarly, some base stations 104 have multiple transmit antennas, and others have only one transmit antenna. There is no limitation on the combination of the transmit antennas and the receive antennas. Thus, it is possible for the base station 104 to have multiple receive antennas and a single transmit antenna, or multiple receive antennas and a single receive antenna, or one or more transmit antennas and receive antennas.

Terminals 106 in the coverage area may be fixed or mobile. As shown in fig. 1, various terminals 106 are dispersed throughout the system. It should be understood that the term "terminal 106" as used throughout this specification refers to "terminals 106A, 106B, 106C, 106D, 106E, 106F, and 106G". The term "terminal 106A" is used for the sake of brevity only. Each terminal 106 may communicate with at least one and possibly multiple base stations 104 on the uplink and downlink at any given moment, depending on, for example, whether soft handoff (handoff) is employed or whether the terminal is designed and operated to receive multiple transmissions (simultaneously or sequentially) from multiple base stations. Soft handoff in CDMA communication systems is well known in the art and is described in detail in U.S. patent No. 5,101,501 entitled "method and system for providing soft handoff in a CDMA cellular telephone system," which is assigned to the assignee of the present invention.

The downlink or FL refers to transmission from the base station to the terminal, and the uplink or RL refers to transmission from the terminal to the base station. In the exemplary embodiment, some terminals 104 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 provided by wireless communication technologies has led to the development of dedicated data services. One such service IS referred to as High Data Rate (HDR) — an exemplary HDR service IS set forth in the "EIA/TIA-IS 856cdma2000 high rate packet data air interface specification," referred to as the "HDR specification. HDR service is generally an overlay to a voice communication system that provides an efficient method for transmitting data packets in a wireless communication system. As the amount of data transmitted and the number of transmissions increase, the limited bandwidth available for radio frequency transmissions becomes a critical resource. Therefore, there is a need for an efficient and rational method for scheduling transmissions in a communication system that optimally uses the available bandwidth. In an exemplary embodiment, the system 100 shown in fig. 1 is consistent with a CDMA type system with HDR service.

High Speed Broadcasting System (HSBS)

A wireless communication system 200 is shown in fig.2 in which video and audio information is supplied to a Packetized Data Service Network (PDSN) 202. The video and audio information may come from television programming or from a radio transmission. The information is provided in packetized data, such as in IP packets. The PDSN202 handles IP packets distributed within the Access Network (AN). As shown, AN is defined as those portions of a system that include a BS 204 in communication with a plurality of MSs 206. The PDSN202 is coupled to the BS 204. For HSBS service, BS 204 receives the information stream from PDSN202 and provides information on the designated channels to subscribers within system 200.

There are several ways in which HSBS broadcast service can be performed in a given sector. Factors involved in designing a system include, but are not limited to, the number of HSBS sessions supported, the number of frequency allocations, and the number of broadcast physical channels supported.

An HSBS is a stream of information provided over an air interface in a wireless communication system. An "HSBS channel" refers to a single logical HSBS broadcast session defined by broadcast content. Note that the content of a given HSBS channel may change over time, e.g., 7 am news, 8 am weather, 9 am movie, etc. Time-based scheduling is analogous to a single television channel. A "broadcast channel" refers to a single forward link physical channel that carries broadcast traffic, i.e., a given walsh code. The broadcast channel, BCH, corresponds to a single CDM channel.

A single broadcast channel can carry one or more HSBS channels, which in this example would be multiplexed within the single broadcast channel in a Time Division Multiplexed (TDM) fashion. In one embodiment, a single HSBS channel is configured on more than one broadcast channel within a sector. In another embodiment, a single HSBS channel is configured on different frequencies, serving subscribers on those frequencies.

According to an exemplary embodiment, the system 100 shown in fig. 1 supports a high speed multimedia broadcast service called High Speed Broadcast Service (HSBS). The broadcast capability of the service is intended to provide programming at a data rate sufficient to support video and audio communications. For example, applications for HSBS may include video streaming of movies, sporting events, and the like. The HSBS service is a data service based on Internet Protocol (IP).

According to an exemplary embodiment, the service provider is referred to as a Content Server (CS), where the CS advertises the availability of such high speed broadcast services to system users. Any user desiring an HSBS cell may subscribe to the CS. The subscriber can then scan the broadcast service schedule in various ways provided by the CS. For example, broadcast content may be disseminated via advertisements, Short Management System (SMS) messages, Wireless Application Protocol (WAP), and/or some other means generally compatible and convenient with predetermined wireless communications. Mobile users are called Mobile Stations (MSs). Base Station (BSs) assistance information includes parameters associated with the HSBS, such as messages transmitted on a channel and/or at a frequency used for control and information, i.e., non-payload messages. Payload refers to the content of the transmission, 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. specifically to broadcast a predetermined program, the MS reads the assistance information and learns the appropriate configuration. The MS then tunes to the frequency containing the HSBS channel and receives the broadcast service content.

The channel structure of the exemplary embodiment is compatible with the cdma2000 standard, in which a forward supplemental channel (F-SCH) supports data transmission. One embodiment bundles a number of forward fundamental channels (F-FCHs) or forward dedicated control channels (F-DCCHs) together to meet the higher data rate requirements of the data service. The exemplary embodiment utilizes an F-SCH as the basis for an F-BSCH that supports a 64 kilobits per second (kbps) payload (not including RTP overhead). The F-BSCH may also be modified to support other payloads such as subdividing the 64kbps payload rate into lower rate substreams.

One embodiment also supports group calls in different ways. For example, by using existing unicast (uni) channels, i.e., one forward link channel per MS that does not share the F-FCH or (F-DCCH) on both the forward and reverse links. In another example, F-SCH (shared by group members in the same sector) and F-DCCH on the forward link (most of the time without frames except for the forward power control subchannel) and R-DCCH on the reverse link are applied. In yet another example, a high-rate F-BSCH on the forward link and an access channel (or a combination enhanced access channel/reverse common control channel) on the reverse link are applied.

With high data rates, the exemplary embodiment can use a significant portion of the base station forward link power to provide adequate coverage. Accordingly, the design of the physical layer of HSBC focuses on the improvement of the efficiency of the broadcasting environment.

To provide adequate support for video services, system design takes into account the base station power required to transmit the channel in various ways and the corresponding video quality. One aspect of the design is the subjective tradeoff between perceived video quality covering the edges and perceived video quality near the cell. As the effective load rate decreases, the effective error correction code rate increases and a given base station transmit power will provide better coverage at the cell edge. For mobile stations located close to the base station, the reception of the channel remains error-free and the video quality is degraded due to the reduced source rate. This same tradeoff applies to other non-video applications that the F-BSCH can support. Reducing the payload rate supported by the channel increases coverage at the expense of reducing download speed in these applications. A balance between video quality and the relative importance between data overall throughput and coverage is a goal. The selected configuration seeks to apply a specific optimal configuration and a good balance of all possibilities.

The effective rate of the F-BSCH is an important design parameter. According to an exemplary embodiment, the following assumptions may be used in designing a system that supports broadcast transmissions: (1) the target payload is 64 kbps; (2) for streaming video services, the payload rate setting includes 128 bits per packet overhead of RTP packets; (3) the average overhead for all layers between RTP and physical layers is 64 bits per packet plus 8 bits per F-SCH frame overhead used by the MUXPDU header.

In an exemplary embodiment, for non-video broadcast services, the maximum rate supported is 64 kbps. However, many other possible payload rates below 64kbps may be obtained.

Subscription mode

For HSBS services, there are several possible subscription/revenue models, including free access, controlled access, and partially controlled access. For free access, the receiving service does not require a user subscription. The BS broadcasts the unencrypted content that the interested mobile devices can receive. The revenue for the service provider may be generated by advertisements that may also be transmitted in the broadcast channel. For example, a movie clip to be played may be sent for which the movie studio will pay the service provider.

For controlling access, the MS user subscribes to the service, paying a corresponding fee to receive the broadcast service. The non-subscribed users cannot receive the HSBS service. Controlling access may be achieved by encrypting HSBS transmissions/content so that only subscribers can decrypt the content. This option provides a high level of security against theft of the service.

A hybrid access option, referred to as partial control access, uses HSBS service as a subscription-based service, with intermittent unencrypted advertisement transmissions for encrypted services. These advertisements are intended to encourage subscription to the encrypted HSBS service. The arrangement of these unencrypted portions may be communicated to the BS by external means.

HSBS service selection

HSBS service selection may be defined as: (1) protocol stack; (2) an option in a protocol stack; (3) procedure for establishing and synchronizing services. Protocol stacks according to exemplary embodiments are shown in fig. 3 and 4. As shown in fig. 3, the protocol stack is specific to the elements of the infrastructure, i.e., MS, BS, PDSN, and CS in the exemplary embodiment.

Continuing with fig. 3, for the application layer of the MS, the protocol specifies the audio codec, the video codec, and any video profiles. Further, the protocol specifies the Radio Transport Protocol (RTP) payload type when RTP is used. For the MS transport layer, the protocol specifies a User Datagram Protocol (UDP) port that is used to carry RTP packets. The security layer of the MS is specified by the protocol (IPSec), where the security parameters are provided via an out-of-band channel when security correlation is initially established by the CS. The link layer specifies IP header compression parameters.

In order for a mobile station to successfully discover and listen to a broadcast channel, various parameter-related broadcast services are transmitted over the air interface. Broadcast services are designed to support different protocol options in the protocol stack. This requires that the broadcast access receiver be informed of the selected protocol options to facilitate correct decoding and processing of the broadcast. In one embodiment, the CS provides this information to the receiver as an auxiliary system parameters message, compatible with cdma 2000. The benefit of the receiver is that it can receive information immediately from the assistance message. In this way, the receiver can immediately determine whether the receiver has sufficient resources to receive the broadcast session. The receiver monitors the secondary system parameter message. The system may execute a service option number corresponding to a set of parameters and protocols, wherein the service option number is provided in the secondary message. Alternatively, the system may provide a set of bins or flags indicating the different protocol options selected. The receiver then determines the protocol options for correctly decoding the broadcast session.

A broadcast channel is a physical channel defined to carry broadcast traffic. There are several possible physical layer formats that may be used for a given broadcast channel, and therefore, the mobile station receiver needs information about these parameters in order to successfully decode the broadcast channel transmission. In particular, each broadcast channel, HSBS channel, has a unique identifier in the system. Further, for each HSBS channel, the BS assigns a broadcast service reference identifier, wherein the base station sets a field corresponding to the current broadcast service session. The broadcast service will then send information for each HSBS channel, including a channel identifier and a broadcast service reference identifier.

Also, the broadcast channel may include various combinations of upper layer protocols based on the type of content being transmitted. The mobile receiver also needs information about these upper layer protocols for interpreting the broadcast transmission. According to one embodiment, the protocol stack is transmitted via an out-of-band method, wherein the plurality of out-of-band methods indicate that the information transmission is via a separate channel than the broadcast channel. With this approach, the description of the upper layer protocol stack is not transmitted on the broadcast channel or the auxiliary system parameter channel.

As discussed above, the service options define the protocol stacks and procedures used for operating the broadcast service. The broadcast service is characterized by a protocol option that is common among a plurality of broadcast receivers, consistent with a unidirectional service. In an exemplary embodiment, the protocol options for the broadcast service are not negotiated between the mobile station and the network. The options are predetermined by the network and provided to the mobile station. Since the broadcast service is a unidirectional service, the broadcast service does not support a request from a mobile station. In contrast, the concept of broadcast services is similar to television transmissions, where the receiver tunes to a broadcast channel and accesses the broadcast transmission using parameters specified by the CS.

To avoid the required coordination between the wireless network and the CS, the service can use an out-of-band channel to transmit information to the mobile station regarding protocol options above the IP network layer. Fig. 15 shows a broadcast stream according to an embodiment. The horizontal axis represents the layout of the system, i.e. the infrastructure elements. The vertical axis represents a timeline. At time t1, the MS accesses the out-of-band channel via the BS. Note that the MS may access the network by selecting a packet data service option, for example, using a dedicated packet data service option designed as SO 33. In effect, the MS selects a packet data service option to establish a real-time streaming protocol (RTSP) session with the CS. In this example, RTSP commands are used, specifically "RTSP: description ". The MS requests at time t3 a specification of the application and transport protocol for the broadcast stream from the CS. Note that instead of RTSP applications, Session Initiation Protocol (SIP) can be used, requesting specification of application and transport protocols. At time t4, the description is via Session Description Protocol (SDP). The protocol may be transmitted when the user accesses the broadcast service. Note that RTSP and SDP are standardized methods to establish unidirectional streaming services in IETF and 3GPP 2. The mobile station may also use the packet data service to request the PDSN to identify a broadcast service header compression protocol. The PDSN then conveys any compression initialization information to the mobile station at time t 2. In one embodiment, the header compression information is exchanged with the mobile station using an internet protocol control protocol IPCP. Also, the same mechanism can be extended to provide information for broadcast streams.

If the broadcast service agreement option changes, the mobile station needs to advertise. One embodiment applies a Security Parameter Index (SPI) to indicate when protocol options may have changed. If the protocol options change due to the use of a different CS for the system or the mobile station transmitting to a different system, the SPI will automatically change because the source IP address of the CS changes. Also, if the CS does not change and applies to a different protocol option, the CS will need to modify the SPI to indicate that the parameter has changed. When the mobile station detects this new SPI, it obtains a new protocol description by setting up a packet data service call and contacting the PDSN and CS whose IP addresses are included in the SPI.

In one embodiment, the SPI method applies several criteria. First, a single CS uses the same protocol options for successive streaming sessions, otherwise, the CS modifies the SPI as the protocol options change. Second, the PDSN does not modify the header compression algorithm or parameters between streaming sessions with the same SPI.

A change in protocol options in a given system triggers multiple mobile stations to place a packet data service call to retrieve updated protocol specifications. A randomized call setup delay should be introduced to prevent the system from being overloaded due to the calls. The content server may introduce some delay between the time the SPI changes and the start of the content stream allowing all users to retrieve protocol options.

Instead, the broadcast channel protocols and parameters may be communicated to the mobile station. In another embodiment, Service Option (SO) numbers are assigned to each set of broadcast protocols and parameters, wherein the SO numbers are transmitted to a plurality of receivers. In SO number derivation, parameter information is directly transmitted as a plurality of encoded fields to a plurality of receivers. Past methods of identifying broadcast protocols and parameters with SO numbers have introduced Broadcast Service Parameter Messages (BSPM). This BSPM is an assistance message dedicated to the broadcast service. Those mobile stations that need to retrieve HSBS service will supervise the BSPM. The BSPM is continuously transmitted periodically by each sector configured with one or more broadcast channels.

The format of the BSPM of the exemplary embodiment is shown in fig. 16. The various parameters indicated in the message are tabulated with the number of bits allocated to each parameter in the message. The PILOT PN sequence offset index is identified as PILOT _ PN. The BS sets the PILOT _ PN field to the PILOT PN sequence offset for the corresponding base station in units of 64PN chips. BSPM _ MSG _ SEQ refers to a broadcast service parameter message sequence number. When any of the parameters identified in the current BSPM has changed since the BSPM's previous transmission, the BS adds 1 to the BSPM _ MSG _ SEQ. The HSBS _ REG _ USED is an indicator for broadcast service registration. This field indicates the frequencies available to the MS for subscribers to the broadcast service. The HSBS _ REG _ TIMER is a broadcast service registration timestamp value. If the field HSBS REG USED is set to '0', the base station will omit this field. Otherwise, the base station includes this field HSBS _ REG _ TIMER, whose meaning is set to: the BS sets this field HSBS _ REF _ TIMER to the length of the registration period of the broadcast service channel; or the base station sets this field HSBS _ REF _ TIMER to '00000' if the MS needs to register the time each time the HSBS channel starts to supervise the HSBS channel.

Continuing with fig. 16, NUM FBSCH is the number of the forward broadcast supplemental channel. The BS sets this field to the number of the forward broadcast supplemental channel transmitted by the corresponding BS. NUM _ HSBS _ SESSION is the number of the broadcast service SESSION. The BS sets this field to the number of the broadcast service session transmitted by the corresponding BS. NUM _ LPM _ ENTRIES is a logical-to-physical image entry. The BS sets this field to the number of the logical (i.e., broadcast service session) to physical (i.e., forward broadcast supplemental channel) map entry carried in this message. The BS sets a forward broadcast supplemental channel identifier, FBSCH _ ID, corresponding to the forward broadcast supplemental channel. If the FBSCH _ CDMA _ FREQ field is included in this record, the base station will set the identifier FREQ _ INCL containing the frequency to '1' and otherwise, the base station will set the binary to '0'.

FBSCH _ CODE _ FREQ is the frequency allocation of the forward broadcast supplemental channel. If the FREQ _ INCL binary is set to '0', the base station will omit this field. Otherwise, the base station sets this field as follows: the base station will set this field to the CDMA channel number corresponding to the CDMA frequency assignment for the CDMA channel containing the forward broadcast supplemental channel.

FBSCH _ CODE _ CHAN is the CODE channel index of the forward broadcast supplemental channel, where the base station sets this field to the CODE channel index that the mobile station is ready to use on the forward broadcast supplemental channel. The FBSCH _ RC forwards broadcasts the radio configuration of the supplemental channel, where the BS sets this field to the radio configuration that the mobile station is ready to use on the forward broadcast supplemental channel.

FBSCH _ RATE is the data RATE of the forward broadcast supplemental channel, where the base station sets this field to the data RATE used on the forward broadcast supplemental channel. FBSCH FRAME SIZE is the SIZE of the FRAME of the forward broadcast supplemental channel, where the base station sets this field to the SIZE of the FRAME on the forward broadcast supplemental channel. FBSCH FRAME REPEAT IND is a forward broadcast supplemental channel FRAME repetition indicator, wherein the base station sets this field to '1' if FRAME repetition is used on the forward broadcast supplemental channel, and otherwise sets this field to '0'.

Fbschsho SUPPORTED is a forward broadcast supplemental channel soft handover support indicator in which the base station sets this field to '1' if it supports soft handover on the forward broadcast supplemental channel with its one or more neighbors, otherwise, the base station sets this field to '0'.

NUM _ NGHBR is a neighbor number that supports forward broadcast supplemental channel soft handoff. If the field FBSCH SHO SUPPORTED is set to '1', the base station will set the NUM NGHBR field to a neighbor number that supports soft handoff on the forward broadcast supplemental channel. NGHBR _ PN is the neighbor pilot PN sequence offset index. The base station sets this field to the pilot PN sequence offset index of that neighbor in units of 64PN chips. Nghbrfbsch CODE CHAN INCL is an indicator that includes the neighbor pilot forward broadcast supplemental channel CODE channel index. The base station sets this field to '1' if the neighbor pilot forward broadcast supplemental channel code channel index is included in this message, otherwise, the base station sets this field to '0'. Nghbrfbsch CODE CHAN is the neighbor pilot forward broadcast supplemental channel CODE channel index. If the NGHBR _ FBSCH _ CODE _ CHAN _ INCL field is set to '0', the base station will omit the NGHBR _ FBSCH _ CODE _ CHAN _ NCL field. Otherwise, the base station includes the nghbrfbsch CODE CHAN INCL field and the BS sets the nghbrfbsch CODE CHAN INCL field to the CODE channel index, which the mobile station prepares to use on the forward broadcast supplemental channel on this neighbor.

HSBS _ ID is a broadcast service session identifier, where the base station sets this field to the identifier corresponding to the slave broadcast service session. Bsrid is a broadcast service reference identifier, where the base station sets this field to the broadcast service reference identifier corresponding to the slave broadcast service session. HSBS _ ID is a broadcast service session identifier, where the BS sets this field to the identifier corresponding to the slave broadcast service session.

FBSCH _ ID is an identifier of the forward broadcast supplemental channel on which the base station sets this field to the identifier corresponding to the forward broadcast supplemental channel on which the broadcast service session is carried.

Protocol options that need to be coordinated between the sender and the receiver are selected and defined in the service option description. The MS uses the SO number transmitted in the BSPM to discover protocol options for the broadcast service. In contrast to a unidirectional packet data service, where the SO specifies protocols up to the IP network layer, the broadcast service specifies protocols up to the application layer. The security layer uses an authentication algorithm that is transmitted during encryption and security related establishment, such as via out-of-band means.

In an exemplary embodiment, the transport layer is specified in the SO because application transport protocols, such as RTP, may not be easily identified as the payload of a UDP packet. The SO also specifies the number of UDP ports for RTP payloads, distinguishing this from other types of UDP traffic that may be sent on the broadcast channel.

The application layer is also specified in the SO because many audio and video codecs (such as MPEG-4 and EVRC) do not have a static RTP payload type that can be easily identified by the mobile station. In one-way broadcast applications, the RTP payload types of these codecs must be dynamically allocated via call setup negotiations (e.g., using SIP, RTSP, etc.) since broadcast services want to avoid such negotiations, the media decoder is pre-selected by the SO. Furthermore, because audio and video data may be carried in separate RTRP packets, it is desirable to specify the type of RTP payload that each media stream is prepared to use.

In an exemplary embodiment, the logical-to-physical mapping specifies the HSBS channels (HSBS _ ID/BSR _ ID) carried in the corresponding F-BSCH (FBSCH _ ID). The set HSBS ID, BSR ID, fbscid (for the MS) all specifies where to discover and listen to a given broadcast service. As such, the logical-to-physical mapping messages are transmitted over the air to the MSs so that an MS wishing to access a given HSBS channel can determine the F-BSCH that needs supervision. Thus, the following information is sent to the mobile station over the air interface, i.e. the physical channel parameters are broadcast; broadcasting the logical channel parameters; logical-physical mapping. One option for characterizing these broadcast service parameters is to define a new assistance message in cdma2000 dedicated to broadcast services.

Another embodiment applies BSPM, where the individual parameters are transmitted in binary blocks, called BLOBs, which contain selectable program options. Unlike the way in which SO numbers are used to identify a set of parameters, where protocol options at the application layer change often and require redefinition, the use of BLOBs allows changes at the application layer without requiring redefinition of the entire set of parameters. In particular, BLOB allows a single parameter to be redefined without changing the entire set of parameters. The problem of multiple protocol options as defined in the previous section can be alleviated by defining a broadcast service BLOB if the broadcast service is to support many different protocol options. This BLOB is sent as part of the BSPF and identifies the protocol options for the broadcast service. Fig. 17 shows the application of the protocol stack and BLOB. The provision of a BLOB provides the advantage that the mobile station uses the BSPM to identify the protocol stack, and therefore no other out-of-band channel is required to transmit this information. Furthermore, the mobile station can immediately determine the ability to access and decode the broadcast stream without registering for service.

The disadvantage described using SO and/or BLOB is the use of the wireless infrastructure to coordinate the protocols used above the IP network layer. The protocols used by the CS and PDSN must match the protocol defined in the BLOB sent by the base station.

One means of providing coordination is for a client in the wireless infrastructure (e.g., BSC) to request protocol option information from the CS and PDSN. The BSC then translates this information into the corresponding broadcast service BLOB sent in the BSPM. The protocol used between the BSC client and the content server and PDSN will be based on a standard protocol, such as the standard protocol specified in cdma 2000. The client in the BSC uses RTSP to request the SDP to specify the application and transport layers from the CS. The client also uses IPCP to request header compression information from the PDSN. In order to limit the number of protocols that a mobile station must support, mandatory and optional protocol options should be defined for broadcast services.

Fig. 18 illustrates a method 2000 for providing broadcast service parameters and protocol information using a BSPM. At step 2002, the MS receives the BSPM from the CS. The BSPM is as described above. At step 2004, the MS extracts the SO number from the BSPM. The SO number is mapped as a set of parameters and protocols sufficient for the MS to receive the desired broadcast. Then, at step 2008, the MS initializes the protocol stack corresponding to the selected SO number. Once the protocol stack is initialized, the MS can receive and decode the information received on the broadcast channel at step 2010. Note that BSPM is transmitted on separate walsh channels known to the subscriber.

Figure 19 shows an image 2020 of each SO number against a set of parameters and protocols. When the CS initially schedules a broadcast, such as a certain football game, the CS determines the parameters and protocols used to transmit the broadcast from a set of previously standardized options.

In one embodiment, the SO number corresponds to a fixed set of protocols and parameters, with the mapping known at the CS and at the MS. The a priori knowledge of the map avoids the need to send information, thereby reducing the overhead of transmission, i.e., conserving bandwidth. The maps are stored at the MS and therefore are not easily changed and updated. If the CS were to use a combination of parameters that had not been previously standardized as an SO number, the standards organization would have to correspond to a new parameter profile before such a combination of parameters could be used for broadcasting.

Fig. 20 shows the application of BLOB information, where a broadcast session is assigned a set of parameters. Each parameter may be one defined among a plurality of options. The transmission of parameters provides a certain flexibility compared to the use of a fixed set of parameters associated with SO numbers. The CS may select any available option and send the information to the MS. As shown, the FIELD2 of BLOB may be specified as either option: OPTION 1 through OPTION K, where each field of the BLOB may have a different number of available OPTIONs.

Another embodiment provides the broadcast protocol and parameters via out-of-band signaling in the broadcast stream. In the present discussion, out-of-band represents a separate channel for transmitting the aiding information. The separate channels may be different frequencies or spread spectrum channels, such as channels defined by different walsh codes. When a subscriber initiates a packet data call, the system provides them with broadcast parameter and protocol information. The subscriber or MS first requests header compression information from the PDSN. Using the information received from the PDSN, the MS can receive broadcast assistance information. The MS contacts the CS via an IP type protocol, such as RTSP or SIP, to receive the transport and application layer specification. The MS uses this information to receive, decode and process the broadcast session.

Fig. 21 shows various channels for transmitting various information in a broadcast system. As shown, system 3000 includes a CS 3003 and an MS 3004, a supplemental channel 3012 and traffic channel 3014 that communicate via broadcast channel 3010. The broadcast content for a given broadcast session is transmitted on a broadcast channel 3010, which may be individually assigned frequencies or may be a uniquely assigned walsh channel. Transmission of the BSPM is provided over the supplemental channel 3012. The traffic channel 3014 is used to transport out-of-band signaling, such as communications between the CS and the MS and communications between the PDSN (not shown) and the MS.

The MS may directly contact the CS and PDSN using out-of-band signaling within the packet data service option. The out-of-band communication allows the CS to update information without being conveyed via the BS, since the out-of-band communication is directly between the MS and the PDSN or the MS and the CS. Note that when using packet data services as an out-of-band means, communication between the MS and the CS still passes through the BS. However, the BS does not need knowledge about the payload, thus making it unnecessary to coordinate the CS and BS protocols.

To avoid the disadvantages of the out-of-band method of sending protocols and parameters to the receiver, the SDP description from the CS can be multiplexed to the broadcast stream. This allows the mobile station to determine the protocol options used by the CS without having to establish a packet data call.

The SDP description is often sent in the broadcast stream as a short-term encryption key (SK). The rate at which these updates are sent will be limited by the amount of bandwidth available for such updates. For example, if the SDP specification is 300 bytes in size and is sent every 3 seconds, the required bandwidth is 800 bps. Note that since the SDP description originates from the content server, the content server can improve the quality of the media when the media bandwidth is low enough to accommodate it by multiplexing the SDP information into the broadcast stream. In practice, the SDP information may be adaptively based on bandwidth conditions. Thus, the frequency of SDP transmissions may also vary due to channel conditions and/or pressure changes over the system bandwidth. Also, by adjusting the information specific to inclusion in a given system, it is possible to vary the size of the SDP.

The SDP description is typically transmitted in RTSP, SAP, or SIP messages. To avoid the overhead of such a protocol, it is recommended to transmit the SDP description directly over UDP by identifying the well-known UDP port number carrying the SDP message. This port number must not be used to carry RTP or other types of UDP traffic sent on the broadcast channel. The UDP checksum will provide error detection for the SDP payload.

According to one embodiment shown in fig. 22, the system provides the broadcast protocols and parameters via out-of-band signaling in the broadcast stream. The broadcast stream 4000 contains broadcast content and is transmitted on a broadcast channel, such as the broadcast channel 3010 of fig. 21. Interspersed throughout broadcast stream 4000 is SDP 4002.

Fig. 23 illustrates a method 5000 for providing broadcast service parameters and protocol information using an in-band approach, wherein overhead information is provided with broadcast content on a broadcast channel. The term in-band is intended to mean that the overhead type information is configured as broadcast content on the same channel, thus not requiring a separate transmission mechanism, i.e., channel. At step 5002, the method 5000 first accesses the BSPM. The MS extracts broadcast channel information, physical layer information, and MAC layer information from the BSPM. At step 5004, header compression information is received directly from the PDSN. This can be done either by having the MS directly contact the PDSN via the packet data service option (out-of-band), or by inserting PDSN header compression structure information into the broadcast stream to the MS. At step 5006, the MS accesses Broadcast Content (BC). In response to the received header compression information, the MS can receive the SDP with broadcast content sent over the broadcast channel at step 5008. SDP contains parameters and protocols for receiving the relevant broadcast sessions. At step 5010, the MS application receives, decodes and processes the broadcast content received on the broadcast channel using the information contained in the SDP.

When a subscriber to a broadcast service wishes to switch to another broadcast session, the establishment and/or initialization of a new broadcast session may cause unacceptable delays to the subscriber. One embodiment provides a memory storage component at the receiver, wherein at least a portion of the information is stored in the receiver and can be used to quickly switch from one broadcast session, i.e., program, to another broadcast session, or alternatively, can be used to invoke a previously accessed broadcast session. Fig.24 shows a memory 6000 that stores the SPI and SDP corresponding to each broadcast session accessed. The auxiliary information corresponding to the existing broadcast session is stored in the memory 6000, wherein the stored information is the last received information. In one embodiment, the memory 6000 is a first-in-first-out (FIFO) memory device. In another embodiment, a cache is used. In yet another embodiment, a look-up table (LUT) stores information about visited broadcast sessions.

In embodiments using such means as a cache and/or look-up table, the MS uses a simple time stamp algorithm to keep only a single current SPI-SDP configuration in memory. For each SPI-SDP pair, the MS retains a timestamp of when the MS last received the description. If the MS detects that the SPI already exists in its memory, it uses the stored configuration and updates the timestamp to the current time. If the detected SPI is not in the MSs memory, the MS replaces the oldest SPI-SDP entry in its memory with the newly detected SPI-SDP pair. The MS now decodes the broadcast stream using this new configuration.

Message flow

Fig. 5 shows a call flow for accessing a broadcast session in an exemplary embodiment for a given system layout. The system includes the 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 HSBB service. At time t1, the MS and the CS negotiate subscription security for the broadcast service. The negotiation involves the exchange and maintenance of encryption keys and the like for receiving broadcast content over the broadcast channel. The user establishes security in relation to the CS for receiving the encryption information. The encryption information may include a Broadcast Access Key (BAK) or a combination of keys from the CS, etc. According to an exemplary embodiment, the CS provides encryption information on a dedicated channel during a packet data session, for example, via PPP, WAP, or other out-of-band methods.

At time t2, the MS tunes to the broadcast channel and begins receiving packets. At this point in time, the MS can process the received packet because the IP/ESP header is compressed via ROHC, while the MS's decompressor has not yet started. At time t3, the PDSN provides header compression information (described in detail below). From the ROHC packet header, the MS detects and obtains ROHC initialization and update (IR) packets periodically sent from the PDSN to the broadcast channel. The rohci packet is used to initialize the state of the decompressor in the MS so that it can decompress the IP/ESP header of the received packet. The MS can then process the IP/ESP header of the received packet, however, the MS needs more information to process the ESP payload because the payload is encrypted with the short-term key at the CS. The SK acts in coordination with the BAK, where the SK is decrypted at the receiver using the BAK. At time s4, CS provides more encryption information, such as updated key information or current SK. Note that the CS provides information to the MS periodically to ensure that the broadcast is ongoing for security. At time t5, the MS receives broadcast content from the CS. Note that alternative embodiments introduce another method of compression and decompression to provide efficient transmission of header information. Further, still another embodiment may implement various security options to protect the broadcast content. Still another embodiment may provide non-secure broadcast services. The MS decrypts and displays the broadcast content using encryption information, such as SK.

Compression

According to an exemplary embodiment, the broadcast content is transmitted on a dedicated broadcast channel. The transport layer provides encryption overhead for carrying broadcast content in IP packets. The system supports data compression, particularly header compression. The decision to compress the data depends on the average throughput required (including transport/encryption overhead, data link layer overhead and physical layer overhead) and the user's perception of broadcast quality. Carrying more broadcast content in each IP packet reduces overhead, thereby reducing broadcast channel bandwidth. In contrast, compression increases the Packet Error Rate (PER) that affects the user perception. This is due to the transmission of each long IP packet covering multiple physical layer frames and is thus associated with an increase in the Frame Error Rate (FER). If a carrier decides to use small IP packets to improve broadcast quality, the carrier may choose header compression to reduce the transmission and encryption overhead of the IP packets.

The RTP/UPD/IP protocol is used to transport broadcast content from the CS to the MS, the content being protected by the ESP in transport mode. The transport overhead is an RTP/UPD/IP header, 40 bytes per IP packet data. The encryption overhead is in the form of an ESP header, an Initialization Vector (IV), and an ESP trailer. The ESP header and the IV are inserted between the IP header and the UDP header. The ESP header consists of SPI (4 bytes) and sequence number (4 bytes). The IV length is specific to which encryption algorithm is used. For the AES cipher algorithm, the IV length is 16 bytes. The ESP trailer is appended to the end of the UDP datagram and consists of a padding, a next header (1 byte) and a padding length (1 byte). Since the cipher block size of the AES algorithm is 16 bytes, the padding size is from 0 to 15 bytes. The rounding-up function of the average padding size may yield 8 bytes. For IP packets, the total overhead due to transmission and encryption is from 66 to 81 bytes, which averages 74 bytes, excluding the data link layer overhead from the PDSN to the MS.

Header compression, such as Robust (Robust) header compression (ROHC), may be used to reduce the SPI fields of the IP header and the ESP header from 24 bytes to 2 bytes. The sequence number of the ESP header is not compressed because it is used to count the compression assistance sequence. The IV is not compressed because it varies randomly for each packet. The UDP/RTP header and the ESP trailer cannot be compressed because they are encrypted. Thus, if ROHC is used to compress the IP/ESP header, the average overhead is reduced from each packet 74 to 52 bytes for transport and encryption reasons.

According to an exemplary embodiment, header compression, such as robust header compression (ROHC), is applied to avoid propagating decompression errors. As shown in fig. 7, the header information is compressed from 24 bytes to 2 bytes. The header 500 includes an IP header 502 and an SPI portion 504. The compression algorithm results in a compressed 2 byte result. In contrast to conventional header compression, which requires some coordination between the MS and PDSN or other infrastructure elements, the exemplary embodiments provide for unidirectional transmission of compressed information. The MS does need to request compressed information, i.e., header compression parameters sufficient to decompress information received at the MS. Instead, the PDSN periodically provides the compression information as shown in fig. 8. The PDSN provides compressed information alternating with broadcast content on the broadcast channel. Providing control information within a data stream is referred to as "in-band" because a separate channel is not required. As shown, the broadcast stream 600 includes a broadcast content portion 604 and decompression information, i.e., compression information 602. Providing a light source having T_COMPRESSIONPeriodic data compression. Another embodiment provides the decompression information when the predetermined data occurs, rather than periodically. Because the MS does not need to decompress the information, the PDSN supplies the information at a frequency that prevents delays in accessing broadcast content. In other words, the PDSN should provide information so often that the MS can access the broadcast at any time without waiting for the decompressed information.

Note that ROHC may operate in a unidirectional mode, where packets are sent in only one direction: from the compressor to the decompressor. Thus, ROHC is made available over a link in this mode, where the return path from decompressor to compressor is not available or desirable. The state of the decompressor is initialized before the MS can decompress packets received from the broadcast channel. Initialization and update (IR) packets are used for this purpose. There are two options for ROHC initialization.

The subscriber "tunes" to the broadcast channel, waiting for ROHC IR packets to be periodically sent by the ROHC compressor in the PDSN. The MS needs frequent ROHC IR packets to start compressing the received packets quickly. Frequent ROHC IR may use too much bandwidth in the broadcast channel. For the IP/ESP compression profile, the IR packet is approximately 30 bytes. If an IR packet is sent every 250 milliseconds, the process consumes approximately 1kbps in the broadcast channel. Losing IR packets over the air may further delay the MS from obtaining ROHC initialization.

If decompression is not in sync due to packet loss, or residual error in the received compressed header, or failure, etc., the resulting decompression error may propagate until decompression resynchronizes or reinitializes. The ROHC compressed header contains a Cyclic Redundancy Check (CRC), which is calculated before the entire header is compressed. This CRC allows decompression to perform local context repair, synchronizing the context (in case of packet loss and residual error). The periodic IR packets effectively reinitialize the decompression process when decompression recovers from the failure.

Transport layer

A data link layer framing protocol or transport layer protocol is applied between the PDSN and the MS to describe packets received from the broadcast channel. Referring to fig. 3, information in the transport layer, identified as LINK LAYER, is configured between the PDSN and the MS. Framing information is generated at the PDSN and provided to the MS via the BS. The PDSN receives and frames IP flows from the CS according to a predetermined framing protocol. As shown in the exemplary embodiment, the PDSN applies a framing protocol version of high-level data link control (HDLC). The HDLC specified in the ISO standard corresponds to layer 2 of the international organization for standardization (ISO)7 layer structure, where layer 2 is referred to as the data link layer. The HDLC protocol seeks to provide error-free movement of data between nodes. To achieve this, the HDLC layer is designed to pass the integrity of the data to the next layer. In other words, the framing protocol seeks to reproduce the received data exactly again, in the correct order, without errors, without loss of information, as the data was originally sent.

The exemplary embodiment applies a HDLC framing version that uses a subset of the parameters defined by the HDLC. Fig. 9 illustrates an embodiment of HDLC framing in which frame 700 includes a number of fields defined by the HDLC protocol outlined in RFC 1662. The field 702 defines a FLAG or indication of the start of a frame. FLAG specifies the length of the bin and is defined by a predetermined pattern of bins. HDLC is convenient to use because HDLC is a commonly used standardized protocol. A drawback of the HDLC full frame protocol is the time required to generate frames at the transmitter and retrieve frames at the receiver.

In particular, HDLC is considered a processor enhancer when further processing is performed to ensure that the payload does not include the same binary sequence as FLAG. At the transmitter, if a FLAG binary sequence is detected in the payload, inserting an escape character into the payload identifies the FLAG as part of the payload and does not include the start of the frame. The process of adding escape characters is referred to as "escape" 0 × 7E and 0 × 7D hexadecimal patterns in the frame payload. Another approach, referred to as an active framing protocol, is described below, which is a processor enhancer that is smaller than HDLC-like framing. Fig. 9 shows the option of using DHLC framing to transmit PPP frames. For HSBS operation, HDLC-like framing overhead can be reduced by eliminating fields that do not require or have little meaning and/or provide little information for unidirectional broadcast. As described above, FLAG is a predetermined binary sequence indicating the start of HDLC. The exemplary embodiment adds a FLAG or other frame start indicator 802 as shown in format 800 of fig. 10. In contrast to the format of fig. 9, in an exemplary embodiment, the end of the frame is not identified with the side information. Because address field 704 and control field 706 of format 700 have static values, these are not included in format 800.

Continuing with fig. 10, since the protocol field 708 (fig. 7) is used to identify the payload type, e.g., LCP control packets, ROHC packets, IP packets, etc., this discriminator is not needed for broadcast operations because all packets in the broadcast channel are of the same type. For example, if ROHC compression is used for packet transmission, all packets in the broadcast channel are processed into ROHC packets. The type of ROHC packet, e.g., IR packet, compressed packet, etc., is distinguished by a packet type field in the ROHC packet header. Thus, protocol fields are not included in format 800. Further, format 800 includes an error check field 806 following payload 804. The error check field 806 provides information to the receiver to enable the receiver to check for errors in the received payload. The exemplary embodiment introduces a Frame Checksum (FCS)712 that may be specified as a null, 16-bit, or 32-bit binary. Since HDLC frames may span multiple physical layer frames in a broadcast channel, all 16-bit binary FCS is recommended.

The octet padding procedure defined in RFC1662 may also be applied to the exemplary embodiment, where, after FCS calculations, the HDLC transmitter in the PDSN checks each byte in the HDLC frame (not including the flag) for the 0 x 7E and 0 x 7D modes. The 0 × 7E mode will encode 0 × 7D and 0 × 5E, and the 0 × 7D mode will encode 0 × 7D and 0 × 5D. The HDLC transmitter does not encode any other modes. This means that the Asynchronous Control Character Map (ACCM) defined in RFC1662 is set to all 0's.

The HDLC framing overhead is 3 bytes plus an octet padding overhead. Assuming the byte pattern is evenly distributed, the average octet stuffing overhead is 1 byte per 128 byte HDLC frame. For example, if the payload is 256 bytes, the average value of the HDLC framing overhead is 5 bytes.

Fig. 11 is a flow diagram of a framing method 900 performed at a transmitter. The transmitter forms a broadcast frame at step 902 by determining the payload portion of the packetized data and generating a start of mark (SOF). The transmitter then checks for frames in the payload 904 that contain any SOF sequences. If the SOF sequence is found in the payload, the transmitter adds an escape character at step 912. Otherwise, the transmitter adds the SOF to the payload at step 906 and provides an error checking mechanism at step 908. The frame is transmitted at step 910. The transmitted frame has the format 800 of fig. 10. Another embodiment may implement other fields within the framing format and may introduce any form of classifier to locate SOF sequences in the payload.

Fig. 12 is a flow diagram of a de-framing method 920 performed at a receiver. The process begins with receiving a broadcast frame at step 922. The receiver identifies the SOF at step 924 and checks the payload for escape characters at decision block 926. If an escape character or other SOF sequence identifier is found in the payload, the receiver strips the escape character at step 932. Otherwise, the receiver performs error checking at step 928 and processes the frame at step 930.

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, bins, symbols, and chips that may be referenced throughout the description may include voltages, currents, and so on. Electromagnetic waves, magnetic fields or photons, optical fields or photons, or any combination thereof.

Those of skill would further appreciate that the various illustrative logical components, 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, 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 any 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 components, 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, microprocessor, 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 executable 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 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 reside as discrete components in a user terminal.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Those skilled in the art will readily understand that: various modifications to these embodiments may be made, 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 (16)

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

transmitting broadcast assistance information corresponding to a broadcast session from a first device on an assistance transport channel, wherein the broadcast assistance information comprises a protocol stack, options in the protocol stack, and information to establish and synchronize a broadcast service;

scanning, using a second device, for broadcast assistance information corresponding to the broadcast session on the assistance transmission channel;

receiving the broadcast assistance information on the second device;

tuning the second device using the received broadcast assistance information; and

receiving the broadcast session on a broadcast transmission channel on the second device.

2. The method of claim 1,

the broadcast service is delivered by a content server;

the broadcast service has a corresponding protocol stack with an application layer and a transport layer; and

the content server independently controls the protocols of the application layer and the transport layer.

3. The method of claim 1, wherein the broadcast service is transmitted as an internet protocol data packet.

4. The method of claim 1, wherein the method further comprises:

updating a portion of the broadcast assistance information during the broadcast transmission; and

the broadcast assistance information is transmitted with the update portion.

5. The method of claim 1, wherein the system further comprises a packetized data service network, the method further comprising:

the packetized data service network updates header compression information; and

the packetized data service network transmits updated header compression information on the supplemental transmission channel.

6. A method of supporting a broadcast service in a cellular wireless communication system, comprising:

transmitting broadcast assistance information from a first device;

receiving the broadcast assistance information on a second device, the broadcast assistance information corresponding to a broadcast session on an auxiliary transport channel, wherein the broadcast assistance information includes a protocol stack, options in the protocol stack, and information to establish and synchronize a broadcast service;

accessing the broadcast session over a broadcast transmission channel; and

broadcast content of the broadcast session is received using broadcast assistance information.

7. The method of claim 6,

the broadcast service is delivered by a content server;

the broadcast service has a corresponding protocol stack with an application layer and a transport layer; and

the content server independently controls the protocols of the application layer and the transport layer.

8. The method of claim 6, wherein the broadcast service is transmitted as an internet protocol data packet.

9. The method of claim 6, wherein the method further comprises:

receiving updated broadcast assistance information updated on an assistance transmission channel during a broadcast transmission; and

broadcast content received on the broadcast transmission channel is processed using the updated broadcast assistance information.

10. The method of claim 6, wherein the system further comprises a packetized data service network, the method further comprising:

receiving updated header compression information from the packetized data service network on a supplemental transport channel; and

the broadcast content is received using the updated header compression information.

11. A wireless device for use in a cellular wireless communication system, the device comprising:

means for receiving broadcast assistance information corresponding to a broadcast session on an assistance transmission channel of a cellular wireless communication system, wherein the broadcast assistance information comprises a protocol stack, options in the protocol stack, and information to establish and synchronize a broadcast service;

means for accessing a broadcast session on a broadcast transmission channel; and

means for receiving broadcast content of a broadcast session using broadcast assistance information.

12. The apparatus of claim 11,

the broadcast service is delivered by a content server;

the broadcast service has a corresponding protocol stack with an application layer and a transport layer; and

the content server independently controls the protocols of the application layer and the transport layer.

13. The apparatus of claim 11, wherein the broadcast service is transmitted as an internet protocol data packet.

14. The apparatus of claim 11, wherein the system further comprises a packetized data service network, and:

means for receiving updated header compression information from the packetized data service network on a supplemental transport channel; and

and means for receiving the broadcast content using the updated header compression information.

15. A method for supporting a broadcast service in a wireless communication system, the wireless communication system including a plurality of cells, each cell having a base station for communicating with a plurality of mobile stations, a packetized data service network coupled to at least one of the base stations, the method comprising:

communicating a broadcast session from at least one of the base stations to the mobile station on a broadcast transmission channel;

communicating broadcast assistance information corresponding to a broadcast session from the at least one of the base stations to a mobile station on an assistance transport channel, wherein the broadcast assistance information includes a protocol stack, options in the protocol stack, and information to establish and synchronize a broadcast service;

the packetized data service network updates header compression information; and

the packetized data service network transmits updated header compression information on the supplemental transmission channel.

16. A method of supporting a broadcast service in a cellular wireless communication system, comprising:

requesting broadcast assistance information corresponding to a broadcast session, wherein the broadcast assistance information includes a protocol stack, options in the protocol stack, and information to establish and synchronize a broadcast service;

receiving broadcast assistance information on an assistance transmission channel;

accessing a broadcast session on a broadcast transmission channel;

the broadcast assistance information is processed to receive broadcast content for the broadcast session.