KR20030088052A - Method and apparatus for overhead messaging in a wireless communication system - Google Patents

Abstract

The present invention is a method and apparatus for providing a broadcast system parameter message in a wireless communication system supporting a broadcast service. In one embodiment, the message identifies a service option number corresponding to a series of broadcast parameters. In yet another embodiment, the message identifies a block of bytes corresponding to the broadcast parameters. A message is sent on the channel to send overhead information. In a system supporting broadcast services, the message identifies a protocol stack that processes the broadcast service and a protocol stack that processes the broadcast content.

Description

METHOD AND APPARATUS FOR OVERHEAD MESSAGING IN A WIRELESS COMMUNICATION SYSTEM}

Background technology

Claims of Priority under 35 U.S.C §120

This patent application was filed on March 28, 2001 and was assigned to the assignee of the present invention, and claims priority to US Provisional Application No. 60 / 279,970, which is specifically incorporated herein.

References to Joint-Patent Patent Applications

The present invention is associated with the following patent applications of the US Patent and Trademark Office:

"Method and Apparatus for Security in a Data Processing System" by Agent Hawk No. 010497, filed on the same date and assigned to the assignee of the present invention and referred to herein;

"Method and Apparatus for Out-of-Band Transmission of Broadcast Service Option in a Wireless Communication System", filed on the same day and assigned to the assignee of the present invention and referred to herein by the agent, reference number 010437;

"Method and Apparatus for Broadcast Signaling in a Wireless Communication System", filed under the same application and assigned to the assignee of the present invention and referred to herein by the agent reference number 010438;

"Method and Apparatus for Transmission Framing in a Wireless Communication System" of agent No. 010498, filed on the same date and assigned to the assignee of the present invention and referred to herein by Raymond Hsu;

"Method and Apparatus for Data Transport in a Wireless Communication System" of Agent No. 010499, filed on the same date and assigned to the assignee of the present invention and referred to herein by Raymond Hsu;

"Method and Apparatus for Header Compression in a Wireless Communication System" of Agent No. 010500, filed on the same day and assigned to the assignee of the present invention and referred to herein by Raymond Hsu;

Technical field

The present invention relates generally to wireless communication systems, and more particularly, to a method and apparatus for compressing messages in preparation for transmission in a wireless communication system.

Background technology

There is an increasing demand for packet data services through wireless communication systems. Conventional wireless communication systems are designed for voice communication, which makes it difficult to expand to support data services. More specifically, the provision of one-way services, such as broadcast services that stream video and audio information to subscribers, has a set of unique requirements and objectives. Such services may have wide bandwidth requirements, so system designers try to minimize the transmission of overhead information. In addition, the subscriber requires specific information to access the broadcast transmission, such as processing parameters and protocols. There is a problem in transmitting broadcast-specific information while optimizing the use of available bandwidth.

Thus, there is a need for an efficient and accurate method of transmitting data in a wireless communication system. There is also a need for an efficient and accurate way of providing service-specific information to a user.

summary

Embodiments disclosed herein provide a method of providing service-specific parameters and protocols to a user in a wireless communication system that supports a broadcast service or other one-way transmission service, thereby addressing the aforementioned needs.

According to one aspect, in a wireless communication system supporting a broadcast service, one method includes generating a broadcast service protocol message and transmitting a broadcast service protocol message to multiple mobile receivers, the broadcast service protocol message being broadcast. A service option number that identifies a set of parameters describing the processing of the content.

In another aspect, in a wireless device supporting a broadcast service, one method includes receiving a broadcast service parameter message, extracting a service option number from the broadcast service parameter message, and initializing a protocol stack corresponding to the service option number. It includes a step.

In another aspect, the wireless device includes means for receiving a broadcast service parameter message, means for extracting a service option number from the broadcast service parameter message, and means for initializing a protocol stack corresponding to the service option number.

Brief description of the drawings

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

2 is a block diagram of a communication system supporting broadcast transmission.

3 is a model of a protocol stack corresponding to a broadcast service option in a wireless communication service.

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

5 is a flowchart for accessing a broadcast service in a wireless communication system topology.

6 is a broadcast stream in a wireless communication system.

7 is header compression mapping in a wireless communication system.

8 is a periodic broadcast of header compression information.

9 is a header compression protocol.

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

11 is a flowchart for header compression for broadcast service in a wireless communication system.

12 is a flowchart of header decompression for a broadcast service in a wireless communication system.

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

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

16 is a system overhead parameter message configuration.

17 is a block of bit system overhead parameter message configuration.

18 is a flow chart for providing broadcast protocols and parameters to a wireless communication system.

19 is a diagram for mapping service option numbers to parameter sets.

20 shows parameter definitions in a wireless communication system.

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

22 is a broadcast stream having overhead information interleaved with broadcast content.

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

24 is a memory element that stores broadcast overhead information.

Detailed description of the invention

The word "exemplary" is used here only to mean "provided by way of example, example, or illustration." Embodiments disclosed herein as "exemplary" are not necessarily described as being preferred or advantageous over other embodiments. Various aspects of the invention are provided in the drawings, but, except where expressly indicated, the drawings are not necessarily drawn to scale.

Exemplary embodiments of a wireless communication system utilize a header compression method that reduces the size of each header while meeting the accuracy and transmission requirements of the system. The exemplary embodiment supports one-way broadcast service. Broadcast services provide video and / or audio streams to multiple users. Subscribers of the broadcast service "tune in" to the designated channel to access the broadcast transmission. As bandwidth requirements for high speed transmission of video broadcasts increase, there is a need to reduce the size of the overhead associated with such broadcast transmissions.

In the following, an exemplary embodiment is first described by a spread-spectrum wireless communication system. Next, a broadcast service, also referred to as a high speed broadcast service (HSBS), will be introduced and described, including channel allocation in the exemplary embodiment. Thereafter, a subscription model is provided that includes options for paid subscriptions, free subscriptions, and hybrid subscription methods, similar to those currently available for television transmission. The standard for accessing broadcast services is then described in detail by providing the use of a service option that defines certain transmission specifications. The message flow in the broadcast system is described with reference to the topology of the system, i.e., the infrastructure elements. Finally, the header compression used in the exemplary embodiment is described.

Exemplary embodiments are provided as representative examples throughout this description; However, still other embodiments may include various aspects without departing from the scope of the present invention. More specifically, the present invention can be applied to data processing systems, wireless communication systems, unidirectional broadcast systems, and other systems for efficient information transmission.

Wireless communication system

Example embodiments use a spread-spectrum wireless communication system that supports broadcast services. Wireless communication systems are widely used to provide various types of communication such as voice, data, and the like. Such systems may be based on code division multiple access (CDMA), time division multiple access (TDMA), or other modulation techniques. CDMA systems offer some advantages over other types of systems, including increased system capacity.

One system is referred to herein as the "TIA / EIA / IS-95-B Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System", here called "3rd Generation Partnership Project". 3G TS 25.211, 3G TS 25.212, 3G TS 25.213, 3G TS 25.214, and 3G TS 25.302, which are referred to herein as the W-CDMA standard, here referred to as the W-CDMA standard. It may be designed to support a standard proposed by a consortium named "3rd Generation Partnership Project 2" and one or more standards such as TR-45.5, referred to herein as cdma2000 and officially called IS-2000 MC. The aforementioned standards are specifically referred to here.

Each standard specifically defines data processing for transmission from the base station to the mobile station and from the mobile station to the base station. As an exemplary embodiment, the following description considers protocols of a spread-spectrum communication system that are compatible with the cdma2000 standard. Still other embodiments may include other standards. Still other embodiments may apply the compression methods disclosed herein to other types of data processing systems.

1 is provided as an example of a communication system 100 that may support multiple users and implement at least some aspects and embodiments of the present invention. Various algorithms and methods may be used to schedule transmissions in the system 100. System 100 provides communication to multiple cells 102A-102G, each cell being serviced by a corresponding base station 104A-104G, respectively. In an exemplary embodiment, some of the base stations 104 have multiple receive antennas, while other base stations have only one receive antenna. Similarly, some of the base stations 104 have multiple transmit antennas, while other base stations have a single transmit antenna. There is no restriction on the combination of the transmitting antenna and the receiving antenna. Thus, base station 104 may have multiple transmit antennas and a single receive antenna, multiple receive antennas and a single transmit antenna, or both may have a single or multiple transmit and receive antennas.

Terminals 106 in the coverage area may be fixed (ie, stationary) or mobile. As shown in FIG. 1, various terminal devices 106 are distributed throughout the system. For example, downlink depends on whether to use soft handoff or whether the terminal is designed and operated to receive multiple transmissions (simultaneously or sequentially) from multiple base stations. And on the uplink each terminal 106 communicates with one or more base stations 104 at a given moment. Soft handoff in CDMA communication systems is well known in the art and is described in detail in "Method and system for providing a Soft Handoff in a CDMA Cellular Telephone System", assigned to the assignee of the present invention.

The downlink refers to transmission from the base station to the terminal equipment, and the uplink refers to transmission from the terminal equipment to the base station. In an exemplary embodiment, some of the terminal devices 106 have multiple receive antennas, while other terminal devices have only one receive antenna. In FIG. 1, base station 104A transmits data to terminal devices 106A and 106J via the downlink, base station 104B transmits data to terminal devices 106B and 106J, and base station 104C. Transmits data to the terminal device 106C.

The increasing demand for wireless data transmission and the expansion of available services by wireless communication technology have led to the development of specific data services. One such service is called High Data Rate (HDR). An exemplary HDR service is proposed in the "EIA / TIA-IS856 cdma2000 High Rate Packet Data Air Interface Specification" called "HDR Standard". In general, HDR services are overlayed on a voice communication system to provide an efficient way of transmitting data packets in a wireless communication system. As the amount of transmission data and the number of transmissions increase, the limited available bandwidth for wireless transmission becomes a very important resource. Thus, there is a need for an efficient and fair method of scheduling transmissions in a communication system to optimize the use of available bandwidth. In an exemplary embodiment, the system 100 shown in FIG. 1 is compatible with a CDMA type system having an HDR service.

High Speed Broadcast System (HSBS)

The wireless communication system 200 is shown in FIG. 2, wherein video and audio information is provided to a Packetized Data Service Network (PDSN) 202. Video and audio information can be broadcast from television programming or wireless transmission. The information is packetized data such as IP packets. The PDSN 202 processes the IP packet for distribution within the access network (AN). As shown, AN is defined as part of a system that includes a BS 204 in communication with multiple MSs 206. PSDN 202 couples with BS 204. For HSBS service, BS 204 receives an information stream from PDSN 202 and provides information on a designated channel to subscribers in system 200.

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

HSBS is a stream of information provided over an air interface in a wireless communication system. "HSBS Channel" refers to a single logical HSBS broadcast session as defined by broadcast content. The content of the provided HSBS channel may change over time, for example, news at 7 am, weather at 8 am, movie at 9 am, and the like. Time-based scheduling is similar to a single TV channel. A "broadcast channel" is a single forward link physical channel, i.e., a predetermined Walsh Code that carries broadcast traffic. The broadcast channel (BCH) corresponds to a single CDM channel.

A single broadcast channel can carry more than one HSBS channel, in which case the HSBS channel is multiplexed in a time-division multiplex (TDM) type within a single broadcast channel. In one embodiment, a single HSBS channel is provided on one or more broadcast channels in a sector. In another embodiment, a single HSBS channel is provided on different frequencies to serve subscribers at these frequencies.

According to an exemplary embodiment, the system 100 shown in FIG. 1 supports a high speed multimedia broadcast service called a 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. In one example, the application of HSBS may include video streaming of movies, sporting events, and the like. The HSBS service is a packet data service based on the Internet Protocol (IP).

According to an exemplary embodiment, a service provider is called a content server (CS), and the CS advertises the availability of such a high speed broadcast service to system users. Any subscriber who wishes to receive HSBS services can apply for CS. The subscriber can then scan the broadcast service schedule in various ways that can be provided by the CS. For example, broadcast content may be communicated through advertisements, Short Management System (SMS) messages, Wireless Application Protocol (WAP), and / or other means that are generally compatible with and convenient for mobile wireless communications. Mobile users are called mobile stations (MSs). Base stations (BSs) transmit HSBS related parameters in overhead messages, ie non-payload messages, transmitted on the channel and / or frequency designated for control and information. The payload refers to the information content of the transmission, and the payload for the broadcast session is broadcast content, that is, a video program or the like. If a broadcast service subscriber wants to receive a broadcast session, i.e. a particular broadcast scheduled program, the MS reads the overhead message to detect the appropriate configuration. Thereafter, the MS tunes to a frequency including the HSBS channel to receive broadcast service content.

The channel structure of the exemplary embodiment is compatible with the cdma2000 standard, and the F-SCH (Forward Supplemental Channel) supports data transmission. One embodiment bundles multiple Forward Fundamental Channels (F-FCHs) or Forward Dedicated Control Channels (F-DCCHs) to achieve higher data rate requirements of data services. The exemplary embodiment uses the F-SCH as a basis for the F-BSCH supporting 64 kbps payload (except for RTP overhead). In addition, the F-BSCH may be modified to support other payload rates, for example, by subdividing the 64-kbps payload rate into lower-rate sub-streams.

In addition, one embodiment supports group calls in a number of different ways. For example, by using an existing unicast channel, i.e., one forward link channel, the MS does not share F-FCH (or F-DCCH) on the forward and reverse links. In another example, an F-SCH (shared by a group member in the same sector) and an F-DCCH on the forward link (forward most power control subchannels, not frames at most times) and an R-DCCH on the reverse link are used. . In another example, fast-rate F-BSCH on the forward link and access channel (or enhanced access channel / reverse common control channel combination) on the reverse link are used.

In the case of a high data rate, the F-BSCH of the exemplary embodiment can use a very large portion of the forward link power of the base station to provide sufficient coverage. Therefore, the physical layer design of HSBC is focused on improving efficiency in a broadcast environment.

To provide sufficient support for video services, the system design takes into account the corresponding video quality as well as the base station power required for the various ways to transmit the channel. One aspect of the design is a subjective trade-off between perceived video quality at the edge of coverage and video quality close to the cell site. As the payload rate decreases, the efficient error correction code raid increases, and a given level of base station transmit power provides better coverage at the edge of the cell. For mobile stations located closer to the base station, the reception of the channel remains error-free, but the video quality is degraded due to the lower source rate. This same trade-off also applies to other, non-video applications that the F-BSCH can support. Lowering the payload rate supported by the channel increases coverage at the expense of reduced download speed for these applications. The goal is to balance the relative importance between video quality and data yield versus coverage. The chosen configuration finds a good compromise between the application-specific optimization configuration, and all possibilities.

Payload rate for F-BSCH is an important design parameter. The following assumptions: namely, (1) the target payload rate is 64 kbps, (2) in order to stream the video service, the payload rate is assumed to include 128-bit bytes per packet overhead of RTP packets, ( 3) Assuming that the average overhead for all layers between the RTP and physical layers is approximately 64, i.e. 8 bits per packet plus 8 bits per F-SCH frame overhead used by the MUXPDU header in the exemplary embodiment. Can be used to design a system that supports broadcast transmission accordingly.

In an exemplary embodiment, for a non-video broadcast service, the maximum rate supported is 64 kbps. However, many other possible payload rates of up to 64 kbps can also be achieved.

Application model

There are various subscription / revenue models available for HSBS services, including free access, controlled access, and partially controlled access. In free access, no application is required to receive the service. The BS broadcasts unencrypted content and interested mobile stations can receive the content. In addition, revenue for the service provider may be generated through advertisements that may be transmitted on broadcast channels. For example, a studio may send movie-clips to be released that the service provider pays.

In controlled access, MS users subscribe to the service and pay the corresponding fee to receive the broadcast service. Unsubscribed users cannot receive HSBS services. Controlled access can be achieved by encrypting the HSBS transmissions / content so that the subscribed user can decrypt the content. This may use an over-the-air encryption key exchange procedure. This approach provides strict security and prevents theft-of-service.

Hybrid schemes, called partially controlled access, provide HSBS services as encrypted subscription-based services with intermittent unencrypted advertisement transmissions. These advertisements may be intended to encourage subscription to encrypted HSBS services. The schedule of these unencrypted parts can be known to the MS via external means.

HSBS Service Options

HSBS service options include: (1) protocol stack; (2) options in the protocol stack; And (3) a procedure for setting up and synchronizing services. Protocol stacks according to exemplary embodiments are shown in FIGS. 3 and 4. As shown in FIG. 3, the protocol stack is specified with an infrastructure element, ie MS, BS, PDSN and CS in the exemplary embodiment.

With continued reference to FIG. 3, for the application layer of the MS, the protocol specifies audio visual codec, visual codec as well as various visual profiles. The protocol also specifies the RTP payload when the RTP (Radio Transport Protocol) is used. For the transport layer of the MS, the protocol specifies the User Datagram Protocol (UDP) used to carry RTP packets. The security layer of the MS is specified by the protocol, and the security parameters are provided over out-of-band channels when the security association is initially established with the CS. The link layer specifies the IP header compression parameter.

Various broadcast service related parameters are transmitted over the air interface so that the mobile station can successfully discover and receive the broadcast channel. The broadcast service is designed to support different protocol options in the protocol stack. This requires the receiver of the broadcast service to notify the selected protocol option to properly facilitate decoding and processing of the broadcast. In one embodiment, the CS provides this information to the receiver as an overhead system parameter message compatible with the cdma2000 standard. The advantage at the receiver is that it can immediately receive information from the overhead message. In this way, the receiver may immediately determine whether the receiver has sufficient resources to receive the broadcast session. The receiver monitors the overhead system parameter message. The system may implement a service option number corresponding to a set of parameters and protocols, and provide the service option number in an overhead message. Alternatively, the system may provide a series of bits or flags to indicate the different protocol option selected. The receiver then determines a protocol option to correctly decode the broadcast session.

A broadcast channel is a physical channel defined for carrying broadcast traffic. Because there are various possible physical channel formats that can be used for a given broadcast channel, the mobile station receiver requests information about these parameters in order to successfully decode the physical transmission of the broadcast channel. In particular, each broadcast channel, HSBS channel, has a unique identifier in the system. In addition, for each HSBS channel, the BS assigns a broadcast service reference identifier, and the base station sets a field corresponding to the current broadcast session. Next, the broadcast service transmits information on each HSBS channel including the broadcast channel identifier and the broadcast service reference identifier.

The broadcast channel may also include several combinations of higher layer protocols, based on the type of content delivered. The mobile station receiver also requests information about these higher layer protocols for interpretation of broadcast transmissions. According to one embodiment, the protocol stack communicates via an out-of-band method, where the out-of-band method represents the transmission of information on a separate channel that is different from the broadcast channel. With this approach, the description of the higher layer protocol stack is not transmitted over the broadcast channel or overhead system parameter channel.

As mentioned above, the service option defines the protocols and procedures used to operate the broadcast service. Consistent with the unidirectional service, the broadcast service is characterized by including protocol options common among multiple broadcast receivers. In an exemplary embodiment, protocol options for broadcast services are not negotiated between the mobile station and the network. The options are predetermined by the network and provided to the mobile station. When the broadcast service is a one-way service, the broadcast service does not support requests from the mobile station. The concept of broadcast service is somewhat similar to television transmission, with the receiver tuning to the broadcast channel and accessing the broadcast transmission using the parameters specified by the CS.

To avoid coordination requests between the wireless network and the CS, the service may use an out-of-band channel that transmits information to the mobile station with respect to protocol options beyond the IP network layer. 15 illustrates a broadcast flow according to an embodiment. The horizontal axis represents the topology of the system, ie the infrastructure elements. The vertical axis represents the time line. At time t1, the MS accesses the out-of-band channel through the BS. The MS accesses the network by selecting a packet data service option, such as using a dedicated packet data service option channel designated SO 33. In practice, the MS selects a packet data service option to establish a Real Time Streaming Protocol (RTSP) session with the CS. The MS requests a description of the application and sends the protocol used for the broadcast stream from the CS at t3. In addition to using RTSP, Session Initiation Protocol (SIP) can be used to request a description of the application and to send the protocol. The description is carried over the Session Description Protocol (SDP) at t4. The session description protocol is a format defined to convey enough information to discover and participate in a multimedia or other broadcast type session. In one example, the SDP is specified in RFC 2327, titled "SDP: Session Description Protocol" by M. Handley and V. Jacobson, April 1998, which is incorporated herein by reference. The transmission of the protocol may be performed while the user accesses the broadcast service. RTSP and SDP are standardized approaches for establishing unidirectional streaming services in IETF and 3GPP2. The mobile station also uses the packet data service to request the PDSN for broadcast service header compression protocol identification and relay some compression initialization information to the mobile station at t2. In one embodiment, Internet Protocol Control Protocol (IPCP) is used to exchange header compression information with the mobile station. Similarly, this same mechanism may be extended to provide information to the broadcast stream.

If the broadcast service protocol option changes, the mobile station requests a notification. One embodiment uses a Security Parameters Index (SPI) to indicate when a protocol option has changed. If the protocol option changes as a result of using a different CS for a mobile station or system handing off to a different system, the SPI changes automatically because the source IP address of the CS changes. Also, if the CS does not change and the same CS is used with different protocol options, the CS is asked to change the SPI to indicate that the parameter has changed. When the mobile detects this new SPI, it establishes a packet data service call and obtains a new protocol description by communicating with PDSNs and CSs whose IP addresses are included in the SPI.

In one embodiment, the SPI approach uses various criteria. First, a single CS uses the same protocol option for successive streaming sessions, while the other CS transforms the SPI when the protocol option changes. Secondly, the PDSN does not change the parameters between the header compression algorithm or streaming sessions with the same SPI.

Changes in protocol options in certain systems trigger multiple mobile stations to retrieve packet data service calls and retrieve updated protocol descriptions. Randomized call set-up delays are introduced to prevent the system from being overloaded by these call occurrences. The content server may incur some delay between the times when the SPI initiates a changing content stream to retrieve protocol options for all users.

On the other hand, broadcast channel protocols and parameters may be transmitted to the mobile station. In yet another embodiment, a service option (SO) number is assigned to each set of broadcast protocols and parameters, and the SO number is transmitted to multiple receivers. In its derivation, parameter information is transmitted directly to multiple receivers as a plurality of coded fields. The former method of identifying broadcast protocols and parameters by SO number includes a broadcast service parameter message (BSPM). This BSPM is an overhead message unique to the broadcast service. These mobile stations that wish to receive HSBS service monitor the BSPM. The BSPM is transmitted continuously and periodically by each sector constituting one or more broadcast channels.

The format of the BSPM of the exemplary embodiment is shown in FIG. 16. The various parameters that appear in the message are listed with the number of bits assigned to each message. The pilot PN sequence offset index is identified as PILOT_PN. The BS sets the PILOT_PN field at the pilot PN sequence offset for the corresponding base station in units of 64 PN chips. BSPM_MSG_SEQ refers to a broadcast service parameter message number. Since any of the parameters identified in the current BSPM change due to previous transmissions of the BSPM, the BS increments BSSPM_CONFIG_SEQ. HSBS_REG_USED is an indicator for broadcasting service registration. This field indicates the frequency used to page the MS subscriber to the broadcast service. HSBS_REG_TIME is a broadcast service registration timer value. If HSBS_REG_USED is set to '0', the base station omits this field. Otherwise, the base station sets the field to the length of the registration duration for the broadcast service channel; Include this field with the significance provided by the base station setting this field to '00000' when the MS is requested to register the HSBS channel at each time the MS starts to monitor the HSBS channel.

With continued reference to FIG. 16, NUM_FBSCH is the number of forward broadcast supplemental channels. 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 broadcast service sessions. The BS sets this field to the number of broadcast service sessions sent by the corresponding BS. NUM_LPM_ENTRIES is the number of logical-physical mapping entries. The BS sets this field to the number of logical, ie, broadcast service sessions, and physical, ie, forward broadcast supplemental channels, that map the entries carried in this message. The BS sets a forward broadcast supplemental channel identifier (FBSCH_ID) corresponding to the forward broadcast supplemental channel. When the CDMA FREQ field is included in this record, the base station sets the frequency (FREQ_INCL) bit included in the identifier to '1', otherwise the base station sets the bit to '0'.

FBSCH_CDMA_FREQ is the frequency allocation of the forward broadcast supplemental channel. If the FREQ_INCL bit is set to '0', the base station omits this field; otherwise, the base station sets this field to the CDMA channel number corresponding to the CDMA frequency assignment for the CDMA channel containing the forward broadcast supplemental channel. do.

FBSCH_CODE_CHAN is the code channel index of the forward broadcast supplemental channel, and the base station sets this field to the code channel index for the mobile station to use on the forward broadcast supplemental channel. FBSCH_RC is the radio configuration of the forward broadcast supplemental channel, and the BS sets this field to the radio configuration used by the base station on the forward broadcast supplemental channel.

FBSCH_RATE is the data rate of the forward broadcast supplemental channel, and the base station sets this field to the data rate used on the forward broadcast supplemental channel. FBSCH_FRAME_SIZE is the frame size of the forward broadcast supplemental channel, and the base station sets this field to the frame size for the forward broadcast supplemental channel. In this case, the base station sets this field to '1', otherwise the base station sets this field to '0'.

FBSCH_SHO_SUPPORTED is a forward broadcast supplemental channel soft handoff support indicator, and if the base station supports soft handoff for a forward broadcast supplemental channel having one or more neighboring stations, the base station sets this field to '1', otherwise The base station sets this field to '0'.

NUM_NGHBR is the number of neighbor stations supporting forward broadcast supplemental channel soft handoff. If the field FBSCH_SHO_SUPPORTED is set to '1', the base station sets this field to the number of the neighboring station that supports soft handoff for this forward broadcast supplemental channel. NGHBR_PN is a neighbor station pilot PN sequence offset index. The base station sets this field in pilot PN sequence offsets for this neighboring station in units of 64 PN chips. NGHBR_FBSCH_CODE_CHAN_INCL is a neighbor station pilot forward broadcast supplemental channel code channel index included in the indicator. If the neighbor station pilot forward broadcast supplemental channel code channel index is included in this message, the base station sets this field to '1', otherwise the base station sets this field to '0'. NGHBR_FBSCH_CODE_CHAN is an adjacent station pilot forward broadcast supplemental channel code channel index. If NGHBR_FBSCH_CODE_CHAN_INCL is set to '0', the base station omits this field; otherwise, the base station includes this field and the BS assigns a code channel index for the mobile station to use on this forward broadcast supplemental channel for this neighboring station. Set this field.

HSBS_ID is a broadcast service session identifier, and the base station sets this field to an identifier corresponding to the broadcast service session. BSR_ID is a broadcast service reference identifier, and the base station sets this field to a broadcast service reference identifier corresponding to the broadcast service session. HSBS_ID is a broadcast service session identifier, and the BS sets this field in an identifier corresponding to the broadcast service session.

FBSCH_ID is a forward broadcast supplemental channel identifier, and the base station sets this field to an identifier corresponding to the forward broadcast supplemental channel to which the broadcast service session is carried.

Protocol options for requesting negotiation between the transmitter and receiver are selected and defined in the service option description. The MS uses the SO number sent to the BSPM to find the protocol option of 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 security layer uses encryption and authentication algorithms that are communicated via, for example, out-of-band means while establishing a security association.

In an exemplary embodiment, the transport layer is specific to the SO as the applied transport protocol, such as RTP, which cannot be easily identified as the payload of the UDP packet. The SO also specifies a UDP port number for the RTP payload to distinguish other types of UDP traffic that can be transmitted over the broadcast channel.

The application layer is also specific to the SO with many video and audio codecs (eg, MPEG-4 and EVRC) that do not have a static RTP payload type that is easily identified by the mobile station. In unidirectional broadcast applications, the RTP payload types for these codecs must be dynamically assigned through call setup negotiation (eg, using SIP, RTSP, etc.). Since the broadcast service wants to avoid this negotiation, the media decoder is preselected by the SO. In addition, since audio and visual data can be carried in separate RTP packets, it is desirable to specify the type of RTP payload to be used by each media stream.

In an exemplary embodiment, logical-to-physical mapping specifies the HSBS channel (HSBS_ID / BSR_ID) carried in the corresponding F_BSCH (FVSCH_ID). The set {HSBS_ID, BSR_ID, FBSCH_ID} completely specifies where (the MS) finds and receives a given broadcast service. As such, logical band physical mapping information is transmitted to the MSs over the air so that an MS wishing to access a given HSBS channel can determine the F-BSCH channel to monitor. Thus, broadcast physical channel parameters; Broadcast logical channel parameters; Logical band physical mapping information is transmitted to the mobile station over the air interface, and one option for signaling these broadcast service parameters is to define a new overhead message in cdma2000 that specifies a broadcast service.

Another embodiment applies BSPM, where individual parameters are transmitted in blocks of bits called BLOBs that include selectable program options. Unlike using SO numbers to identify sets of parameters, protocols at the application layer change frequently, so redefinition is required, and the use of BLOBs allows changes at the application layer without redefining the entire set of parameters. . In particular, a BLOB allows the redefinition of a single parameter without changing the entire set of parameters. In the case where a broadcast service supports many different protocol options, the problem of defining multiple service options in the previous section can be mitigated by defining a broadcast service BLOB. This BLOB is sent as part of the BSPM and identifies the protocol option used for the broadcast service. 17 illustrates the protocol stack and application of a BLOB. The provision of BLOBs provides the advantage that other out-of-band channels do not require the transmission of this information since the mobile station uses the BSPM to identify the protocol stack. In addition, the mobile station can immediately determine the ability to access and decode the broadcast stream without registering for the service.

The disadvantage of using SO and / or BLOB descriptions is the use of a wireless infrastructure to coordinate the protocol used on the IP network layer. The protocol 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 to have a customer in a wireless infrastructure (eg, BSC) that requests protocol option information from the CS and PDSN. The BSC then translates this information into the corresponding broadcast service BLOB sent to the BSPM. The protocol used between the BSC customer and the content server and the PDSN is based on standard protocols such as those specified in cdma2000. The customer at the BSC uses the RTSP to request an application and transport layer description from the CS using the SDP. The customer also uses IPCP to request header compression information from the PDSN. To limit the number of protocols, the mobile station must support mandatory additional protocol options that must be defined for the broadcast service.

18 illustrates a method 2000 for providing broadcast service parameter and protocol information using a BSPM. In step 2002, the MS receives a BSPM from the CS. BSPM was described above. In step 2004, the MS extracts the SO number from the BSPM. The SO number is mapped to a protocol and a sufficient set of parameters for the MS to receive the desired broadcast. Next, in step 2008, the MS initiates a protocol stack corresponding to the selected SO number. Once the protocol stack is initiated, the MS can receive and decode the information received on the broadcast channel in step 2010. The BSPM is transmitted on a separate Walsh channel known to the subscriber.

19 illustrates mapping 2020 to each set of parameters and protocols. When the CS initially schedules a broadcast, such as a football match for a given date, the CS determines the parameters and protocols to be used for transmission of the broadcast from a set of previous standardized options.

In one embodiment, the SO number corresponds to a fixed set of protocols and parameters, and mappings are known in CS and MS. Conventional mapping knowledge avoids the need to transmit information, thus reducing transmission overhead, i.e., conservation bandwidth. Because the mapping is stored in the MS, it is not easily changed or updated. If the CS uses a combination of previously unstandardized parameters, such as SO number, the standard structure must define a new profile of parameters before this combination of parameters can be used for broadcast.

Using a BLOB of information is shown in FIG. 20, where a broadcast session is assigned to a set of parameters. Each parameter may be one of multiple options. The transmission of parameters provides a level of flexibility compared to using a fixed set of parameters associated with the SO number. The CS can select any available option and send the information to the MS. As shown, field 2 of the BLOB can be specified as any option: option 1-option K, and each field of the BLOB can have a different number of available options.

Another embodiment provides broadcast protocols and parameters via out-of-band signaling in the broadcast stream. Here, out-of-band represents an individual channel used for communication of overhead information. Individual channels may be different frequencies or may be spread-spectrum channels, such as those defined by different Walsh codes. The system provides the broadcast parameters and protocol to the subscriber when the subscriber initiates the packet data call. First, the subscriber or MS requests header compression information from the PDSN. Using the information received from the PDSN, the MS can receive broadcast overhead information. The MS contacts the CS via an IP type protocol, for example RTSP or SIP, to receive a description of the transport and application layers. The MS uses this information to receive, decode and process the broadcast session.

21 illustrates various channels used for transmission of various information in a broadcasting system. As shown, the system 3000 includes a CS 3002 and an MS 3004 in communication over a broadcast channel 3010, an overhead channel 3012, and a traffic channel 3014. The broadcast content of a given broadcast session is transmitted on broadcast channel 3010, which may be the only assigned frequency or the only assigned Walsh channel. Transmission of the BSPM message is provided on the overhead channel 3012. Traffic channel 3014 is used for transmission of out-of-band signaling, such as communication between CS and MS, and communication between PDSN (not shown) and MS.

The MS makes direct contact with the CS and PDSN using out-of-band signaling through the packet data service option. When out-of-band communication is between MS and PDSN or MS and CS, out-of-band communication allows CS to update information without transmission over BS. When using a packet data service as out-of-band means, communication between the MS and the CS passes through the BS. However, since the BS does not require knowledge of the payload, there is no need to adjust the CS and BS protocols.

To avoid the shortcomings of the out of band method of transmitting protocols and parameters to the receiver, the SDP description from the CS is multiplexed into the broadcast stream. This allows the mobile station to determine the protocol options used by the CS without setting up packet data calls.

SDP descriptions are frequently transmitted as short-term encryption keys (SK) in broadcast streams. These updated transmission rates are limited by the amount of bandwidth available for this update. For example, if the SDP description is 300 bytes in size and is sent every 3 seconds, the required bandwidth is 800 bps. Since the SDP description originates from the content server, the content server can improve media quality by multiplexing SDP messages into the broadcast stream when the media bandwidth is low enough to accommodate it. In practice, the SDP information may be based on bandwidth conditions. Thus, as the stress on the channel conditions and / or bandwidth of the system changes, the frequency of the SDP transmission may also change. Similarly, the size of the SDP may be changed by adjusting the information included in specifying a given system.

In general, the SDP description is sent in an RTSP, SAP, or SIP message. To avoid the overhead of this protocol, it is recommended that the SDP description be sent directly over UDP by identifying a well-known UDP port number for carrying SDP messages. This port number should not be used to carry RTP or other types of UDP traffic sent over broadcast channels. UDP checksum provides error detection for the SDP payload.

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

23 illustrates a method 5000 for providing broadcast service parameter and protocol information using an in-band method, where overhead type information having broadcast content on a broadcast channel is provided. The term in-band indicates that overhead type information is provided on the same channel as broadcast content so that no separate transmission mechanism is needed, i.e., no channel. First, the method 5000 accesses the BPSM in step 5002. The MS extracts broadcast channel information, physical layer information, and MAC layer information from the BSPM. Header compression information is received at step 5004 directly from the PDSN. This can be done by the MS in direct contact with the PSDN via a packet data service option (out of band) or by the PDSN inserting header compression configuration information into the broadcast stream for the MS. In step 5006, the MS accesses broadcast content (BS). In response to the header compression information, the MS may receive the SDP transmitted on the broadcast channel with the broadcast content in step 5008. The SDP includes parameters and protocols for receiving related broadcast sessions. The MS uses the information contained in the SDP to receive, decode, and process the broadcast content received by the broadcast channel company.

When a subscriber to a broadcast service wants to change for another broadcast session, the establishment and / or initiation of a new broadcast session may result in an unacceptable delay for the subscriber. One embodiment provides a memory storage unit at a receiver wherein at least a portion of the information is stored at the receiver and can be used for rapid change from one broadcast session, ie a program to another broadcast session, or in another method. May be used to recall a previously accessed broadcast session. FIG. 23 illustrates a memory storage 6000 for storing SPIs and SDPs corresponding to each broadcast session accessed. Overhead information corresponding to the current broadcast session is stored in the memory 6000, where the stored information is the last received information. In one embodiment, memory storage 6000 is a first-in first-out (FIFO) memory storage unit. In another embodiment, cache memory is used. In yet another embodiment, a Look Up Table (LUT) stores information about accessed broadcast sessions.

In embodiments that use mechanisms such as cache memory and / or LUT, the MS uses a simple time-stamp algorithm to keep only one copy of the most recent SPI-SDP configuration in memory. For each SPI-SDP pair, the MS maintains a time stamp when the MS last received the description. If the MS detects an SPI that already exists in memory, it uses the stored configuration and updates the time stamp with the current time. If the detected SPI is not in MSs memory, the MS replaces the oldest SPI-SDP entry in memory with the newly detected SPI-SDP pair. The MS uses this new configuration to decode the broadcast stream.

Message flow

5 shows a call flow for accessing a broadcast session in an example embodiment for a given system topology. As listed on the horizontal axis, the system includes the MS, BS, PDSN, and CS. The vertical axis represents time. The user or MS is a subscriber to the HSBS service. At t1, the MS and CS negotiate an application security for the broadcast service. Negotiation involves the exchange and maintenance of an encryption key used to receive broadcast content on a broadcast channel. The user establishes security associated with the CS upon receipt of encrypted information. The encryption information may include a broadcast access key (BAK) or key combination from the CS. According to an exemplary embodiment, the CS provides encryption information over a dedicated channel, such as a PPP, WAP, or other out-of-band method, during a packet data session.

At t2, the MS tunes to the broadcast channel and starts receiving packets. At this time, the MS can process the received packet because the IP / ESP header is compressed via ROHC and the decompressor of the MS is not initialized. At t3, the PDSN provides header compression information (described in detail below). From the ROHC packet header, the MS detects and acquires ROHC initialization & playback (IR) packets periodically sent from the PDSN to the broadcast channel. The ROHC IR packet is used to initialize the state of the decompressor, which decompresses the IP / ESP header of the packet received at the MS. The MS can then process the IP / ESP header of the received packet, but since the payload is encrypted with the short-term (SK) in the CS, the MS can use other information to process the ESP payload. Require. SK acts according to BAK, and SK decompresses at the receiver using BAK. At t4, the CS further provides updated key information or encryption information such as the current BK. CS periodically provides this information to the MS in order to ensure the continued security of the broadcast. At t5, the MS receives broadcast content from the CS. Another embodiment provides another compression / decompression method that provides for efficient transmission of header information. In addition, other embodiments may implement various security schemes to protect broadcast content. Another embodiment may provide an insecure broadcast service. The MS uses encryption information such as SK to decompress and display the broadcast content.

compression

In accordance with the exemplary embodiment, the broadcast content is transmitted on a dedicated broadcast channel. The transmission layer provides cryptographic overhead for transmitting the broadcast content of the IP packets. The system supports data compression, in particular header compression. The decision to compress the data depends on the user's perception of the required average throughput (including transmit / encryption overhead, data link layer overhead, physical layer overhead) and broadcast quality. The transmission of broadcast content of each IP packet reduces overhead, thus reducing broadcast channel bandwidth. In contrast, compression increases the packet error rate (PER), which affects user perception. This is due to the transmission of each long IP packet that spans multiple physical layer frames, thereby increasing the frame error rate (FER). If the carrier uses small IP packets to improve broadcast quality, the carrier may choose header compression to reduce the transmission / encryption overhead of the IP packets.

The RTP / UDP / IP protocol is used to transmit broadcast content from the CS to the MS, and the content is protected by the ESP in transmission mode. The transmission overhead is an RTP / UDP / IP header, 40 bytes per IP packet data. Cryptographic overhead is in the form of an ESP header, an initialization vector (IV), and an ESP trailer. ESP header and 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 length of the IV is specific to the length in which the encryption algorithm is used. For the AES encryption algorithm, the length of IV is 16 bytes. The ESP trailer is attached to the end of the UDP datagram and consists of padding, the next header (1 byte), and the padding length (1 byte). The cipher block size of the AES algorithm is 16 bytes, and the padding size is in the range of 0 to 15 bytes. If we take the ceiling function of the average padding size, it is 8 bytes. For IP packets, the total overhead due to transmission and encryption is in the range of 66 to 81 bytes, with an average of 74 bytes, without including the data link layer overhead from PDSN to MS.

Header compression, such as 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. Since it is not used to sequence compressed packets, the sequence number of the ESP header is not compressed. The IV is not compressed because it does not change randomly for every packet. UDP / RTP headers and ESP trailers cannot be compressed because they are not encrypted. Therefore, when ROHC is used to compress the IP / ESP header, the average overhead due to transmission and encryption is reduced from 74 bytes to 52 bytes per IP packet.

According to an exemplary embodiment, header compression such as robust header compression (ROHC) is applied to avoid transmission of decompression errors. As shown in Fig. 7, the header information is compressed from 24 bytes to 2 bytes. Header 500 includes an IP header 502 and an SPI portion 504. The compression algorithm shows two bytes of results after compression. In contrast to conventional header compression, a form of negotiation is required between the MS and the PDSN or other infrastructure elements, and an exemplary embodiment provides one-way transmission of compression information. The MS needs a request for header compression parameters sufficient to decompress the compression information, ie the information received at the MS. Rather, the PDSN provides compressed information periodically as shown in FIG. PDSN provides compressed information on a broadcast channel that is transformed into broadcast content. The provision of control information in the data stream is referred to as "in-band" where no separate channel is required. As shown, the broadcast stream 600 includes a broadcast content portion 604 and decompression information, ie, compression information 602. The decompression information has a period of T _{decompression} . Other embodiments may provide decompression information on certain events rather than periodically. Since the MS does not require decompression information, the PDSN provides the information with a frequency that prevents delays in accessing broadcast content. That is, the PDSN must provide the information so that the MS can access the broadcast at any time without waiting for decompression information.

ROHC may operate in unidirectional mode and packets are sent in only one direction from the compressor to the decompressor. Therefore, this mode renders the ROHC unavailable over a link where the return path from the decompressor to the compressor is unavailable or undesirable. The state of the decompressor is initialized before the MS can decompress the packet received from the broadcast channel. Initialization / playback (IR) packets are used for this purpose. There are two methods for ROHC initialization.

The subscriber tunes to the broadcast channel and waits for ROHC IR packets periodically sent by the ROHC compressor of the PDSN. Periodic ROHC IR packets may be required of the MS to quickly decompress the received packets. Periodic ROHC IP packets may use much bandwidth of the broadcast channel. The IR packet for the IP / ESP compression profile is about 30 bytes. If an IR packet is sent every 250 ms, the process consumes about 1 kbps on the broadcast channel. Loss of IR packets over the air further delays the MS to obtain ROHC initialization.

If decompression is not synchronized due to packet loss, or residual errors in the received and compressed headers, or failure, the resulting decompression error may be transmitted until decompression is resynchronized or reinitialized. The ROHC compression header includes a cyclic redundancy check (CRC), calculated over the entire header before compression. This CRC allows decompression to perform partial context correction to synchronize the context (in case of packet loss and residual error). When decompression recovers from failure, periodic IR packets effectively reinitialize the decompression process.

Transport layer

A data link layer framing protocol or transmission layer protocol is applied between the PDSN and the MS to represent packets received from the broadcast channel. Referring to FIG. 3, information of the transmission layer identified as the link layer is provided between the PDSN and the MS. Framing information is generated in the PDSN and provided to the MS via the BS. The PDSN receives the IP stream from the CS and frames the IP stream in accordance with 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 Standards Institute (ISO) 7-layer structure, which is called a data link layer. The HDLC protocol allows for providing error free data movement between network nodes. For this purpose, the HDLC layer is designed to ensure the integrity of the data passed to the next layer. In other words, the framing protocol allows the data to be reconstructed so that the data is transmitted correctly without errors or without loss of information.

An exemplary embodiment applies a version of HDLC framing that provides a subset of HDLC defined parameters. 9 illustrates one embodiment of HDLS framing, and frame 700 includes a plurality of fields, as defined by the HDLC protocol shown in RFC 1662. Field 702 defines a flag indicating the start of the frame. The flag is a specified bit length and is defined by a predetermined bit pattern. If HDLC is a commonly available standardized protocol, it is convenient to apply. A disadvantage of the full HDLC framing protocol is the processing time required to generate the frame at the transmitter and recover the frame at the receiver.

In particular, the HDLC protocol is considered a robust process when used to ensure that further processing does not include the same sequence of bits as a flag. At the transmitter, when a flag sequence bit is detected in the payload, an escape character is inserted into the payload to identify a flag that does not indicate the start of the frame as part of the payload. The addition process of the escape character is called the "escape" hexadecimal pattern of 0x7E and 0x7D of the frame payload. Another method called Efficient Framing Protocol, which is a less powerful process than framing such as HDLC, is described below. 9 shows an option for using HDLC framing to transmit a PPP frame. In HSBS operation, framing overhead such as HDLC can be reduced by eliminating fields that are not required, meaningless or have no information for unidirectional broadcast. As mentioned above, the flag is a predetermined sequence bit that indicates the start of the HDLC frame. The example embodiment implements another disclosure of the flag or frame indicator 802, as shown in the format 8000 of FIG. 10. In contrast to the format of FIG. 9, the ends of the frames are not represented as overhead information in the exemplary embodiment. The address and control fields of format 700 have static values and they are not included in format 800.

Referring to Fig. 10, since the purpose of the protocol field (Fig. 9) is to identify payload types such as LCP control packets, ROHC packets, IP packets, etc., this identifier indicates that all packets of the broadcast channel have the same type. Is not required for the broadcast operation. For example, if ROHC compression is used for packet transmission, all packets of the broadcast channel are processed as ROHC packets. Types of ROHC packets, such as IP packets, compressed packets, and the like, are identified by the packet type field of the ROHC packet header. Therefore, the protocol field is not included in the format 800. In addition, the format 800 includes an error check field 806 after the payload 804. The error check field 806 provides information to the receiver for the receiver to check for errors in the received payload. The example embodiment implements Frame Check Sum (FCS), which can be specified as null of 16 bits or 32 bits. Since HDLC frames may extend multiple physical layer frames of the broadcast channel, it is desirable to use 16-bit FCS.

The octet stuffing procedure defined in RFC 1662 is applied to the exemplary embodiment, and after the FCS calculation, the HDLC transmitter of the PDSN receives each byte of the HDLC frame (excluding the flag) for a pattern of 0x7E and 0x7D. Check Pattern (0x7E) is encoded with 0x7D and 0x5E, and pattern (0x7D) is encoded with Ox7D and 0x5D. HDLC transmitters do not encode any other pattern. This means that the Async-Control-Character-Map (ACCM) defined in RFC 1662 is all set to zero.

The HDLC framing overhead is 3 bytes plus octet stuffing overhead. Assuming that the byte patterns are uniformly distributed, the average octet stuffing overhead is 1 byte per 128 bytes of the HDLC frame. For example, if the payload is 256 bytes, the HDLC framing overhead is 5 bytes on average.

11 is a flow diagram for a framing method 900 performed at a transmitter. In step 902, the transmitter forms a broadcast frame by determining the payload portion of the packetized data and generating a Start Of Flag (SOF). The transmitter then checks the frame for any SOF sequence included in payload 904. If the SOF sequence is found in the payload, then at step 912 the transmitter adds an escape character. Otherwise, the transmitter adds the SOF to the payload in step 906 and provides an error check mechanism in step 908. The frame is transmitted in step 910. The transmitted frame has the format 800 of FIG. 10. Other embodiments may implement other fields in the framing format, and may implement a classifier form to place SOF sequences in the payload.

12 is a flowchart of a deframing method 920 performed at a receiver. This process initiates reception of a broadcast frame at step 922. At step 924, the receiver identifies the SOF and checks for escape characters in the payload at decision diamond 926. If an escape character or other SOF sequence identifier is found in the payload, then at step 932, the receiver removes the escape character. Otherwise, the receiver performs an error check in step 928 and processes the frame in step 930.

Those skilled in the art understand that information and signals may be displayed using a variety of different techniques. For example, data, directives, instructions, information, signals, bits, symbols, chips referenced through the detailed description may be represented by voltage, current, electromagnetic waves, magnetic fields or particles, optical fields or particles, or combinations thereof.

Those skilled in the art may, however, be aware that the logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, various illustrative elements, blocks, modules, circuits, and steps are generally described 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 by varying the methods of specific applications, and such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The various illustrative logic blocks, modules, and circuits described in connection with the embodiments disclosed herein may be general purpose processors, digital signal processors (DSPs), application specific semiconductors (ASICs), field programs, to perform the functions described herein. It may be implemented or performed in a possible gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware elements, or a combination thereof. A general purpose processor may be a microprocessor or the process may be a conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, eg, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or other configuration.

The methods or methods of algorithms described in connection with the embodiments disclosed herein may be implemented directly in hardware, in a software module executed by a processor, or in a combination of the two. The software module may be present in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disks, removable disks, CD-ROMs, or other forms of storage media known in the art. An exemplary storage medium is coupled to the processor such that the processor reads information from and writes information to the storage medium. Alternatively, the storage medium may be integrated into the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In addition, the processor and the storage medium may reside as discrete components in a user terminal.

The detailed description of the disclosed embodiments is provided to enable any person skilled in the art to practice the invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the scope of the present 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 (10)

In a wireless communication system supporting a broadcast service, Generating a broadcast service protocol message; And Transmitting the broadcast service protocol message to multiple mobile receivers. The method of claim 1, The broadcast service protocol message includes a service option number identifying a series of parameters describing the processing of broadcast content. The method of claim 2, The service option number corresponding to a protocol stack for processing broadcast content. The method of claim 1, And the broadcast service protocol message is transmitted on an overhead channel. The method of claim 1, Wherein the broadcast service protocol message comprises a block of bits identifying parameter options for processing broadcast content. In a wireless device that supports broadcast services, Receiving a broadcast service parameter message; Extracting a service option number from the broadcast service parameter message; And Initiating a protocol option corresponding to the service option number. The method of claim 6, The broadcast service is a video stream of information. The method of claim 6, The broadcast service parameter message defines a video codec of the broadcast session. Means for receiving a broadcast service parameter message; Means for extracting a service option number from the broadcast service parameter message; And Means for initializing a protocol stack corresponding to the service option number. The method of claim 9, And means for receiving header compression information.