Method and apparatus for broadcast signaling in a wireless communication system

Method and device for broadcasting signal in wireless communication system

Background of the invention

Priority Statement 35 USC § 120 This application claims the benefits of the US provisional patent application serial number 60/279,970 filed on March 28, 2001, and is hereby incorporated by reference.

The present invention is related to the following US Patent and Trademark Office patent applications: "Method and Apparatus for Security in a Data Processing System" proposed by Philip Hawkes et al., entrusted file number 010497, which is proposed and assigned together with the present invention The present invention is the assignee, and it is expressly stated here that it is incorporated herein by reference; "Method and Apparatus for Out-of-Band Transmission of Broadcast Service Option in a Wireless Communication System" proposed by Nikolai Leung, entrusted File No. 010437, which is proposed together with the present invention and assigns the present invention as the assignee, and hereby expressly states that it is incorporated herein by reference; "Method and Apparatus for Overhead Messaging in a Wireless Communication" proposed by Nikolai Leung System, entrusted file number 010439, which is proposed together with the present invention and assigns the present invention as the assignee, and hereby expressly indicates that it is incorporated into this article by reference; "Method and Apparatus for Transmission Framing proposed by Raymond Hsu in a Wireless Communication System", entrusted file number 010498, proposed together with the present invention And assign the present invention as the assignee, and hereby expressly indicate that it is incorporated into this article by reference; "Method and Apparatus for Data Transport in a Wireless Communication System" proposed by Raymond Hsu, entrusted file number 010499, and this The invention is proposed and assigned as the assignee, and it is clearly stated here that it is incorporated into this article by reference; "Method and Apparatus for Header Compression in a Wireless Communication System" proposed by Raymond Hsu, entrusted file number 010500, which is proposed together with the present invention and assigns the present invention as the assignee, and hereby expressly indicates that it is incorporated herein by reference.

Field of invention

The present invention is related to wireless communication systems, and more particularly to methods and devices for compressing messages for transmission in wireless communication systems.

Background of the invention

The demand for packet data services through wireless communication systems has been increasing in recent years. For traditional wireless communication systems designed for voice communication, it is a challenge to expand and support the introduction of data services. In particular, it provides non-directional services with unique needs and goals, such as broadcast services that stream video and audio data to users. This kind of service has huge bandwidth requirements, which allows system designers to seek to minimize the transmission of frequent information. In addition, users also need specific information to access the broadcast transmission, such as processing parameters and communication protocols. When the available bandwidth is optimized for use, it transmits and broadcasts designated information There was a problem.

Therefore, there is a need for an effective and reliable method of transmitting data in a wireless communication system. Further, there is a need for an effective and reliable method of providing service-specific information to users.

Summary of the invention

The specific embodiment disclosed herein addresses the above stated requirements by providing a method for providing service-specific parameters and communication protocols to users in a wireless communication system supporting broadcast services or other non-directional transmission services.

According to one aspect, in a wireless communication system supporting broadcast services, there is a method that includes transmitting broadcast operations on broadcast transmission channels and transmitting broadcast regular information with broadcast operations on broadcast transmission channels.

In other aspects, a communication signal transmitted on a carrier includes a broadcast operation part, and a job description protocol message (SDP message) interspersed with the broadcast operation part, wherein the SDP provides information for the broadcast operation.

In still other aspects, a wireless device includes a device for receiving a broadcast service parameter message corresponding to a broadcast operation, a device for receiving an SDP corresponding to the broadcast operation, and a device for processing the broadcast operation using the SDP . In a specific embodiment, the device includes a memory storage device adapted to store the SDP corresponding to the plural broadcast operation, wherein each SDP of the plural broadcast operation is updated when the corresponding broadcast operation is received.

Figure 1 is a diagram of a spread spectrum communication system that supports multiple users.

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

Figure 3 shows a protocol stacking model corresponding to the broadcast service options in the wireless communication system.

Fig. 4 is a protocol table applied to the protocol stack layer supporting the broadcast service option in the wireless communication system.

Figure 5 is a flow chart for accessing broadcast services in a wireless communication system topology.

Figure 6 shows the broadcast stream in the wireless communication system.

Figure 7 shows the title compression mapping in the wireless communication system.

Figure 8 shows the regular title compressed information broadcast.

Figure 9 shows the title compression protocol.

Figure 10 shows the header compression protocol of the broadcast service in the wireless communication system.

Figure 11 is a flow chart of title compression for broadcast services in a wireless communication system.

Figure 12 is a flow chart of decompressing titles of broadcast services in a wireless communication system.

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

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

Figure 16 shows the system's frequent parameter information configuration.

Figure 17 shows the bit block of the system's regular parameter message configuration.

Figure 18 is the preparation process of the broadcast communication protocol and parameters in the wireless communication system picture.

Figure 19 shows the mapping of the number of service options to the parameter set.

Figure 20 illustrates the parameter definitions in the wireless communication system.

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

Figure 22 shows a broadcast stream with regular information and broadcast content interleaved.

Figure 23 shows a method of accessing broadcast services in a wireless communication system.

Figure 24 shows the memory element for storing the broadcast frequent information.

Detailed description of the invention

The word "model" is used here exclusively to mean "as an example, instance, or illustration". Any specific embodiment referred to as "demonstration" herein does not need to be construed as better or superior to other specific embodiments. Although many aspects of the present invention are presented in the drawings, unless otherwise indicated, the drawings are not required to be drawn to scale.

The exemplary embodiment of the wireless communication system uses a header compression method, which can reduce the size of each header while still meeting the accuracy and transmission requirements of the system. The exemplary embodiment supports a non-directional broadcast service that provides video and/or audio streaming to multiple users. To enter the broadcast service, the user needs to "adjust" the designated channel to receive the broadcast transmission. And because high-speed video broadcast transmission has a very large demand for bandwidth, it is best to reduce the size of any regular information accompanying such broadcast transmission.

The following discussion first presents a common spread spectrum wireless communication system to explain the exemplary embodiments in detail. Next, a broadcast service will be introduced, which is called "High Speed Broadcast Service (HSBS)", and a discussion of channel configuration of exemplary specific embodiments will be conducted. Then, a subscription model including paid subscription, free subscription, and multiple subscription plan options (similar to current TV transmissions) is presented. It then elaborates on the rules for accessing broadcast services, showing the use of service options to define the rules for known transmissions. The message flow in the broadcast system will be discussed along with the system topology (that is, the infrastructure components). Finally, we will discuss the application of title compression in the exemplary embodiment.

Please note that the exemplary specific embodiments provided are used as the Exemplary, but other specific embodiments can be incorporated into many fields without departing from the field of the invention. In particular, the present invention is used in data processing systems, wireless communication systems, non-directional broadcasting systems, and other systems for effective information transmission.

Wireless communication system

This exemplary embodiment uses a spread spectrum wireless communication system to support broadcast services. After extensive development, wireless communication systems can be used for many types of communications, such as voice, data, and so on. These systems are all based on code division multiple access (CDMA), time division multiple access (TDMA) or other modulation techniques. CDMA systems offer some advantages over other systems, including increased system capacity.

A system can be designed to support one or more standards, such as "TIA/EIA/IS-95-B Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System" called IS-95 standard here, Standards established by an international organization called "3rd Generation Partnership Project", here called 3GPP, a set of standards implemented by a set of documents, including document numbers 3G TS 25.211, 3G TS 25.212, 3G TS 25.213, and 3G TS 25.214, 3G TS 25.302, referred to here as the W-CDMA standard, is a standard established by an international organization named "3rd Generation Partnership Project 2", referred to here as 3GPP2, and referred to as the cdma2000 standard here, the official name is IS -2000 MCs TR-45.5 standard. The standards cited above will be expressly incorporated into this article by reference.

Each standard specifically defines the data transmission from the base station to the mobile Phone handling and vice versa. For the exemplary embodiment, the following discussion considers a spread spectrum communication system in accordance with the cdma2000 communication protocol standard. Other specific embodiments may incorporate other standards. In other specific embodiments, the compression method disclosed herein can be applied to other types of data processing systems.

FIG. 1 is used as an example of a communication system 100 that supports most users and can implement at least some aspects and specific embodiments of the present invention. Any algorithm and method can be used to schedule the transmission within the system 100. The system 100 provides communication for many units from 102A to 102G, and each unit is served by base stations 104A to 104G, respectively. In the exemplary embodiment, some base stations 104 have multiple receiving antennas while others have only one receiving antenna. Similarly, some base stations 104 have multiple transmission antennas while others have only one transmission antenna. There is no restriction on the combination of transmitting antennas and receiving antennas. Therefore, it is possible that the base station 104 has multiple transmitting antennas and a single receiving antenna, or multiple receiving antennas and a single transmitting antenna, or a single or multiple transmitting and receiving antennas.

The terminals 106 in the coverage area can be fixed (ie, stationary) or mobile. As shown in FIG. 1, many terminal machines 106 are scattered throughout the system. At any known moment, depending on whether soft handover is used or whether the terminal is designed and operated to (simultaneously or sequentially) to receive multiple transmissions from multiple base stations, each terminal 106 is in the downlink and uplink It communicates with at least one and possibly multiple base stations 104 at all times. The soft handoff in the CDMA communication system is well known in the industry, and it was published in detail in the US Patent Application No. 5,101,501 called "Method and system for providing a Soft Handoff in a CDMA Cellular Telephone System" is hereby designated as the assignee of the present invention.

The downlink is transmitted from the base station to the terminal, and the uplink is transmitted from the terminal to the base station. In the exemplary embodiment, some terminals 106 have multiple receiving antennas while others have only one receiving 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 demand for wireless data transmission has gradually increased and the services that can be provided through wireless communication technology have expanded, which has led to the development of specific data services. There is one such service called "High Speed Data Rate (HDR)". The "EIA/TIA-IS856 cdma2000 High Rate Packet Data Air Interface Specification" called "HDR Specification" proposes a demonstration HDR service. HDR services usually overlap with voice communication systems, and can provide an effective data packet transmission method in wireless communication systems. When the amount of data transmission and the number of transmissions increase, the limited bandwidth available for radio transmission becomes a key resource. Therefore, an effective and reasonable method is needed to arrange the transmission in the communication system to optimize the use of the available bandwidth. In an exemplary embodiment, the system 100 illustrated in FIG. 1 is consistent with a CDMA type system with HDR service.

High Speed Broadcasting System (HSBS)

2 illustrates a wireless communication system 200 in which video and audio information are provided to the "Packet Data Service Network (PDSN) 202". The video and audio information can come from television programs or radio transmissions. The information provided is treated as packetized data, as if in an IP packet. PDSN 202 processes IP packets for distribution In the access network (AN). As shown in the figure, AN is defined as a part of a system that includes a BS 204 that communicates with multiple MS 206. The PDSN 202 will be coupled to the BS 204. For the HSBS service, the BS 204 receives the information stream from the PDSN 202 and provides the information to users in the system 200 on a designated channel.

In the known field, there are many ways in which HSBS broadcast services can be developed. The factors involved in designing the system include but are not limited to the number of HSBS operations supported, the number of frequency assignments, and the number of broadcast physical channels supported.

HSBS is a stream of information provided through an air interface in a wireless communication system. The "HSBS channel" called the single logical HSBS broadcast operation is defined by the broadcast content. Please note that the content of the HSBS channel is known to change over time, such as news on demand at 7 in the morning, weather on demand at 8 in the morning, movies on demand at 9 in the morning, and so on. The content scheduled according to the time is similar to a single TV channel. The "broadcast channel" is called a single forwarding link entity channel, which is a known Walsh Code that carries broadcast traffic. The broadcast channel BCH corresponds to a single CDM channel.

A single broadcast channel can carry one or more HSBS channels. In this case, the HSBS channel can be multiplexed in a single broadcast channel in a time division multiplexing (TDM) manner. In a specific embodiment, a single HSBS channel will be provided in more than one broadcast channel in a domain. In another specific embodiment, a single HSBS channel will be provided on different frequencies to serve users in these frequencies.

According to an exemplary embodiment, the system 100 illustrated in FIG. 1 supports a high-speed multimedia broadcasting service called a high-speed broadcasting service (HSBS). The broadcast capability of the service is to provide a network at a data rate sufficient to support video and audio communications. Item. For example, HSBS applications may include video streaming of movies, sports games, and so on. HSBS service is a packet data service based on Internet Protocol (IP).

According to the exemplary embodiment, the service provider calls it a content server (CS), where the CS promotes the initial use of such high-speed broadcast services to system users. Any user who wants to receive HSBS service can subscribe to CS. Then the user can scan the broadcasting service program list in many ways provided by CS. For example, advertisements, short messaging system (SMS) messages, wireless application communication protocol (WAP), and/or other generally consistent and convenient mobile wireless communication methods can be used to inform broadcast content. Mobile users are called mobile stations (MS). The base station (BS) transmits HSBS-related parameters in regular messages, such as regular messages transmitted on a channel and/or frequency designated for control and information, that is, non-payload messages. The payload is the content of the information to be transmitted. For broadcasting operations, the payload is the content of the broadcast, and the video program, etc. When a broadcast service user wants to receive a broadcast operation, that is, a specific broadcast program, the MS will read the regular information and learn the appropriate configuration. Then the MS will adjust to the frequency that contains the HSBS channel and receive the broadcast service content.

The channel structure of the exemplary embodiment is consistent with the cdma2000 standard, in which the forwarding supply channel (F-SCH) supports data transmission. A specific embodiment combines a large number of forwarding basic channels (F-FCH) or forwarding dedicated control channels (F-DCCH) to meet the higher data rate requirements of data services. This exemplary embodiment uses F-SCH as the basis for F-BSCH to support 64 kbps payloads (except for RTP regular information). The F-BSCH can also be modified to support other payload rates, such as subdividing the 64-kbps payload rate into lower rate sub-streams.

A specific embodiment also supports group calls in many different ways. For example, by using F-FCH (or F-DCCH) existing cost-free channels on the forwarding and reverse links, there is one forwarding link channel for each MS that does not share. In other examples, F-SCH (shared by group members in the same area) and F-DCCH (there is no frame at most of the time, but there is a transmission power control sub-channel) on the forwarding link, and R-DCCH on the reverse link. In still other examples, the high-rate F-BSCH on the forwarding link and the access channel on the reverse link (or enhanced access channel/reverse shared control channel combination) will be used.

In the exemplary embodiment, the F-BSCH with a high data rate may occupy most of the transmission link power of the base station to provide sufficient coverage. In this way, the physical layer design of HSBC will focus on the improvement of efficiency in the broadcast environment.

To provide adequate support for video services, system design must take into account the required base station power to transmit channels and corresponding video quality. One aspect of the design should take into account the ebb and flow of video quality between the coverage edge and the location close to the cell. When the payload rate decreases, the effective error correction code rate increases, and the known base station transmit power can provide better coverage at the edge of the cell. For mobile stations close to the base station, the channel reception is still error-free, and the video quality will be reduced due to the lower resource rate. The same ups and downs also apply to other non-video applications that F-BSCH can support. In reducing the download speed of these applications, reducing the payload rate supported by the channel will increase coverage. The balance of relative focus between the video quality and the coverage of the total amount of data is the goal. Its configuration selection should seek to optimize the configuration according to the application, and a good compromise between all possibilities.

The payload rate of F-BSCH is an important design parameter. The following assumptions can be used to design a system that supports broadcast transmission in accordance with the exemplary embodiment: (1) the target payload rate is 64 kbps, (2) for streaming video services, the payload rate is assumed to be each packet of RTP packet The regular information contains 12 8-bit bytes. (3) The average regular information of all layers between RTP and the physical layer is about 64. Each packet has 8 bits plus the F-SCH signal used by each MUXPDU header. The frame information is 8 bits.

In the exemplary embodiment, for non-video broadcast services, the highest supported rate is 64 kbps. However, other payload rates below 64 kbps can also be achieved.

Subscription model

There are many possible subscription/revenue models for HSBS services, including free access, controlled access, and partially controlled access. For free access, users do not need to subscribe to receive services. BS broadcasts unencrypted content, and interested mobile stations can receive the content. And service providers can generate revenue through advertisements that can also be delivered in broadcast channels. For example, a movie company pays a service provider to transmit a trailer for a movie to be released.

For controlled access, MS users subscribe to the service and pay to receive the broadcast service. Users who have not subscribed will not be able to receive HSBS services. The use of HSBS transmission/content encryption can achieve controlled access, so that only subscribed users can decrypt the content. This can be done using an over-the-air encryption key exchange procedure. This law provides extremely high security and prevents services from being stolen.

The compound access rule called partial control access provides HSBS service as an encrypted subscription service interspersed with unencrypted broadcast transmission. These ads can Used to encourage subscription to encrypted HSBS services. MS can know the schedule of these unencrypted sections through external means.

HSBS service selection

The HSBS service selection is defined as follows: (1) protocol stack; (2) selection within the protocol stack; and (3) procedures for setting and synchronizing services. 3 and 4 illustrate the stacking of communication protocols according to the exemplary embodiment. As illustrated in FIG. 3, the protocol stack will be assigned to the infrastructure components, that is, the MS, BS, PDSN, and CS in the exemplary embodiment.

Continuing to look at Figure 3, for the MS application layer, the communication protocol specifies the audio codec, visual codec, and any visual profile. In addition, when using RTP, the communication protocol specifies the radio transmission protocol (RTP) payload type. For the MS transport layer, the communication protocol specifies the user datagram protocol (UDP) port used to carry RTP packets. The security layer of the MS is specified by the communication protocol. When the CS is used to establish the security protocol for the first time, the security parameters will be provided through the out-of-band channel. The link layer will specify the IP header compression parameters.

In order for mobile stations to successfully discover and listen to broadcast channels, many broadcast service-related parameters will be transmitted through the air interface. Here, the broadcast service is designed to support different protocol selections in the protocol stack. This requires notification of the selected protocol option to the receiver of the broadcast service so that the broadcast can be decoded and processed correctly. In a specific embodiment, the CS will provide this information to the receiver as a regular system parameter message in accordance with the cdma200 standard. The advantage of this for the receiver is the ability to immediately receive information from regular messages. In this way, the receiver can immediately determine whether the receiver has enough Enough resources to receive broadcast jobs. The receiver will monitor regular system parameter messages. The system can implement service option numbers corresponding to a set of parameters and communication protocols, and the service option numbers will be provided in regular messages. In addition, the system can provide a set of bits or flags to indicate the different communication protocol options selected. The receiver then determines the protocol options used to correctly decode the broadcast job.

A broadcast channel is a physical channel defined to carry broadcast traffic. There are many possible physical layer formats that can be used for known broadcast channels, so mobile station receivers need information about these parameters in order to be able to successfully decode the physical transmission of the broadcast channel. In particular, each broadcast channel, HSBS channel has a unique identification code in the system. In addition, for each HSBS channel, the BS will assign a broadcast service reference identifier, and the base station will set a field corresponding to the current broadcast service operation. Then the broadcast service will transmit the information of each HSBS channel, including: broadcast channel identification code and broadcast service reference identification code.

Further, according to the type of content delivered, the broadcast channel can be added to a combination of many upper-layer communication protocols. Mobile receivers also need information about these upper-layer communication protocols to analyze broadcast transmissions. According to a specific embodiment, the communication protocol stack will communicate through an out-of-band method, where the out-of-band method is to transmit information through an individual channel at a distance from the broadcast channel. After using this method, there is no need to transmit the description of the upper layer protocol stack through the broadcast channel or the regular system parameter channel.

As discussed above, service options define protocol stacks and procedures for operating broadcast services. Like non-directional services, broadcast services The feature is that multiple broadcast receivers share communication protocol options. In the exemplary embodiment, the communication protocol options of the broadcast service are not negotiated between the mobile station and the network. This option is reserved by the network and provided to the mobile station. When the broadcast service is a non-directional service, the broadcast service does not support requests from mobile stations. The concept of broadcast service is quite similar to TV transmission, in which the receiver adjusts to the broadcast channel and uses the parameters specified by the CS to receive the broadcast transmission.

To avoid the required coordination between the wireless network and CS, the service can use out-of-band channels to transmit information to the mobile station regardless of the protocol options on the IP network layer. Figure 15 illustrates a broadcast flow according to a specific embodiment. The horizontal axis represents the extension of the system, which is the infrastructure component. The vertical axis represents the timeline. At time t1, the MS accesses the out-of-band channel through the BS. Please note that the MS can access the network by selecting the packet data service option (such as using the dedicated packet data service option channel marked SO 33). Effectively, the MS selects a packet data service option to establish a real-time streaming protocol (RTSP) operation containing CS. At time t3, the MS requests an explanation of the application and transmission protocol used for the broadcast stream from the CS. Please note that in addition to using RTSP, you can also use the Job Initiation Protocol (SIP) to request the description of the application and transmission protocol. At time t4, the description will be carried through the operation description protocol (SDP). When the user receives the broadcast service, it can also perform the transmission of the communication protocol. Please note that RTSP and SDP are standardized methods for establishing non-directional streaming services within IETF and 3GPP2. The mobile station can also use the packet data service to request the PDSN to recognize the broadcast service header compression protocol and relay any compressed initial information to the mobile station at time t2. In a specific embodiment, the Internet protocol will be used to control the protocol IPCP exchanges header compression information with the mobile station. Similarly, this same mechanism can also be extended to provide information to the broadcast stream.

If the broadcast service protocol option changes the mobile station, a notification is required. When the communication protocol option is changed, a specific embodiment will apply the security parameter index (SPI) to indicate. If the communication protocol options are changed due to the use of different CSs in the system, or the mobile station is handed over to a different system, the SPI will automatically change due to the change of the source IP address of the CS. Furthermore, if CS has not changed and a different communication protocol option is used, CS will need to change SPI to indicate that the parameter has changed. When the mobile station detects this new SPI, it will use the set packet data service call to obtain the new protocol description, and contact the PDSN and CS whose IP address is included in the SPI.

In a specific embodiment, the SPI method applies many criteria. First, a single CS uses the same protocol options for continuous streaming operations, and when the protocol changes, the CS will modify the SPI. Second, PDSN does not change the header compression algorithm or the parameters between streaming operations with the same SPI.

Changes in protocol options in known systems will trigger multiple mobile stations to set up packet data service calls to obtain updated protocol descriptions. Here, random calls should be introduced to set delays to avoid overloading the system due to these calls. The content server can introduce some delay between the time the SPI is changed, and the content stream starts to allow all users to retrieve the protocol options.

In contrast, the broadcast channel communication protocol and parameters can be transmitted to the mobile station. In 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. Derived from this, the parameter information will be directly transmitted to multiple receivers as a complex Several code fields. The aforementioned method of using SO numbers to identify broadcast communication protocols and parameters will be incorporated into the Broadcast Service Parameter Message (BSPM). This BSPM is a regular message designated for broadcast services. Any mobile station that wants to receive HSBS services will monitor the BSPM. BSPM is periodically and continuously transmitted by each area where one or more broadcast channels are set.

The BSPM format of the exemplary embodiment is illustrated in FIG. 16. Many parameters indicated in the message are listed with the number of bits configured in each message. The leading PN sequence offset index is identified as PILOT_PN. The BS sets the PILOT_PN field to the preamble PN sequence offset of the base station in units of 64 PN segments. BSPM_MSG_SEQ is the number of broadcast service parameter messages. When any parameter identified in the current BSPM is changed due to the previous BSPM transmission, the BS will increment BSSPM_CONFIG_SEQ. HSBS_REG_USED is a registered usage indicator for broadcast services. This field indicates the frequency used to paging MS users to the broadcast service. HSBS_REG_TIME registers the timer value for the broadcast service. If the field HSBS_REG_USED is set to '0', the base station will omit this field. Otherwise, the base station that contains this field has the following meanings: the BS sets this field to the length of the registration period of the broadcast service channel; or if the MS needs to record it every time the HSBS channel starts to monitor the HSBS channel, the base station will set this The field is set to '00000'.

Continuing with Figure 16, NUM_FBSCH is the number of broadcast supply channels that are forwarded. The BS sets this field to the number of forwarding broadcast supply channels transmitted by the corresponding BS. NUM_HSBS_SESSION is the number of broadcast service operations. The BS sets this field as the number of broadcast service operations transmitted by the corresponding BS. NUM_LPM_ENTRIES is the number of logical to actual mapping entities. BS will This field is set to the number of mapping entities from the logic (that is, broadcast service operation) carried in the message to the actual (that is, to forward the broadcast supply channel). The BS will set the forwarding broadcast supply channel identification code FBSCH_ID corresponding to the forwarding broadcast supply channel. If the CDMA_FREQ field is included in this record, the base station will set the frequency inclusion indicator FREQ_INCL bit to '1', otherwise the base station will set this bit to '0'.

FBSCH_CDMA_FREQ is the frequency assignment for forwarding the broadcast supply channel. If the FREQ_INCL bit is set to '0', the base station should omit this field, otherwise the base station should set this field as follows: the base station should set this field to the number of CDMA channels, and this number corresponds to including forwarding broadcast supply The CDMA frequency assignment of the CDMA channel of the channel.

FBSCH_CODE_CHAN is the code channel index of the forwarding broadcast supply channel, and the base station will set this field as the code channel index that the mobile station will use on the forwarding broadcast supply channel. FBSCH_RC is the radio configuration of the forwarding broadcast supply channel. The BS will set this field to the radio configuration used by the mobile station on the forwarding broadcast supply channel.

FBSCH_RATE is the data rate of the forwarding broadcast supply channel, and the base station will set this field to the data rate used on the forwarding broadcast supply channel. FBSCH_FRAME_SIZE is the frame size of the forwarding broadcast supply channel, and the base station will set this field as the frame size on the forwarding broadcast supply channel. FBSCH_FRAME_REPEAT_IND is the frame repeat indicator for the forwarding broadcast supply channel. If frame repeat is used on the forwarding broadcast supply channel, the base station will set this field to '1', otherwise the base station will set this field to '0' '.

FBSCH_SHO_SUPPORTED is the soft handover support indicator for the forwarding broadcast supply channel. If the base station supports soft handover on the forwarding broadcast supply channel of one or more neighboring base stations, the base station will set this field to '1' , Otherwise the base station will set this field to '0'.

NUM_NGHBR is the number of neighbors that support the soft handover of the broadcast supply channel. If the field FBSCH_SHO_SUPPORTED is set to '1', then the base station will set this field to the number of neighbors supporting soft handover on the forwarding broadcast supply channel. NGHBR_PN is the sequence offset index of the adjacent leading PN. The base station sets this field to the preamble PN sequence offset of adjacent base stations in units of 64 PN segments. NGHBR_FBSCH_CODE_CHAN_INCL is the adjacent preamble forwarding broadcast supply channel code channel index including the indicator. If the adjacent preamble forwarding broadcast supply channel code channel index is included in this message, the base station will set this field to '1', otherwise the base station will set this field to '0'. NGHBR_FBSCH_CODE_CHAN provides the channel code channel index for the adjacent preamble forwarding broadcast. If the NGHBR_FBSCH_CODE_CHAN_INCL field is set to '0', the base station will omit this field, otherwise the base station will include this field, and the BS will set this field as the mobile station will be used for this forwarding broadcast on the adjacent station The code channel index of the supply channel.

HSBS_ID is the identification code of the broadcast service operation, and the base station will set this field to the identification code corresponding to this broadcast service operation. BSR_ID is the broadcast service reference identification code, and the base station will set this field to the broadcast service reference identification code corresponding to this broadcast service operation. HSBS_ID is the broadcast service operation identification code, and the BS will set this field to the identification code corresponding to the broadcast service operation.

FBSCH_ID is the identification code of the forwarding broadcast supply channel, and the base station will set this field to the identification code corresponding to the forwarding broadcast supply channel, which carries the above-mentioned broadcast service operation.

Here, the communication protocol options that need to be negotiated between the transmitter and the receiver are selected and defined in the service option description. The MS uses the number of SOs to pass in the BSPM to discover the communication protocol options of the broadcast service. Compared with the non-directional packet data service, SO specifies the communication protocol up to the IP network layer, and the broadcast service specifies the communication protocol up to the application layer. During the establishment of a security protocol, for example, through an out-of-band method, the security layer uses encryption and authentication algorithms to communicate.

In the exemplary embodiment, the designated transport layer is regarded as the applied transport protocol in the SO, such as RTP, so that the payload of the UDP packet cannot be quickly identified. SO will also specify the number of UDP ports used for RTP payloads to distribute payloads from other types of UDP traffic that may be transmitted through broadcast channels.

The application layer is also specified in SO, so many video and audio codecs (such as MPEG-4 and EVRC) will not have static RTP payload types that can be quickly identified by mobile stations. In non-directional broadcast applications, the RTP payload types of these codecs must be dynamically assigned through call setting protocols (for example, using SIP, RTSP, etc.). Because the broadcast service intends to avoid this protocol, the media codec is pre-selected by the SO. Furthermore, because audio and video data can be carried in separate RTP packets, the type of RTP payload to be used for each media stream can be specified.

In the exemplary embodiment, the logical-to-actual mapping specifies that it is carried in F- HSBS channel (HSBS_ID/BSR_ID) in BSCH (FBSCH_ID). The set {HSBS_ID, BSR_ID, FBSCH_ID} completely indicates (for MS) where to find and listen to known broadcast services. In this way, the logical to actual mapping information will be transmitted to the MS through the air, so that the MS that wants to access the known HSBS channel can determine the F-BSCH channel to be monitored. Therefore, the following information will be transmitted to the mobile station through the air interface: broadcast actual channel parameters, broadcast logical channel parameters, logic to actual mapping, and an option for the signal. These broadcast service parameters are used to define new information in the cdma2000 assigned to the broadcast service. S regular information.

Another specific embodiment applies BSPM, in which independent parameters are transmitted in a block of bits (Block Of Bits, referred to as BLOB containing selectable program options). Different from using the SO number to identify a set of parameters, the communication protocol options on the application layer often change, so it needs to be redefined, while using BLOB allows changes on the application layer without the need to redefine the entire set of parameters. In particular, BLOB allows to redefine a single parameter without changing the entire set of parameters. If the broadcast service needs to support many different communication protocol options, by defining the broadcast service BLOB, the aforementioned problem of defining multiple service options can be alleviated. This BLOB will be sent as part of the BSPM and will identify the protocol options used for the broadcast service. Figure 17 illustrates the protocol stacking and the application of BLOB. Preparing the BLOB can provide the advantage that the mobile station can use BSPM to identify the protocol stack, so there is no need to use other out-of-band channels in order to transmit this information. In addition, the mobile station can immediately determine the ability to receive and decode the broadcast stream without registering for the service.

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

Providing coordination means that the client located in the wireless infrastructure (such as BSC) must request information from the CS and PDSN communication protocol options. The BSC then translates this information into the corresponding broadcast service that the BLOB transmits in the BSPM. The communication protocol used between the BSC client and the content server and the PDSN will be based on standard communication protocols, such as those specified in cdma2000. The application and transport layer description of CS using SDP is required for the user side within the BSC to use RTSP. The client also uses IPCP to request header compression information from PDSN. If you want to limit the number of protocols that the mobile station must support, you should define broadcast service obligations and optional protocol options.

FIG. 18 illustrates a method 2000 for using BSPM to provide broadcast service parameters and communication protocol information. At step 2002, the MS receives the BSPM from the CS. BSPM is as described above. In step 2004, the MS takes out the SO quantity from the BSPM. Then the number of SOs is mapped to a set of parameters and communication protocols that are sufficient for the MS to receive the broadcast. Then in step 2008, the MS initializes the protocol stack corresponding to the selected SO quantity. In step 2010, once the communication protocol stack is initialized, the MS can receive and decode the information received on the broadcast channel. Please note that BSPM will be transmitted on individual Walsh channels known to users.

Figure 19 illustrates the mapping 2020 of each SO quantity to a set of parameters and communication protocols. When CS is scheduled to broadcast for the first time, like a football match on a specific day, CS will The parameters and communication protocol used for broadcast transmission will be determined from a set of previously standardized options.

In a specific embodiment, the number of SOs corresponds to a fixed set of communication protocols and parameters, where the mapping is known to be located on CS and MS. The previous understanding of mapping eliminates the need for information transmission, which can reduce the transmission burden, that is, save bandwidth. The mappings stored on the MS will be sorted, so it is not easy to change or update. If CS wants to use a parameter combination that has not previously been standardized as the number of SOs, the standards organization must define a new parameter description file before this parameter combination can be used for broadcasting.

Figure 20 illustrates the use of information BLOB, where a set of parameters is assigned to the broadcast operation. Each parameter can be one of multiple options. The transmission of parameters is more flexible than the use of a fixed set of parameters accompanying the number of SOs. The CS can select any available options and send the information to the MS. As shown in the figure, the FIELD 2 of the BLOB can be specified as any option: OPTION 1 to OPTION K, and each BLOB field has a different number of available options.

Another specific embodiment provides broadcast communication protocols and parameters through out-of-band signals in the broadcast stream. In the discussion of the present invention, the out-of-band is the individual channel used for frequent information communication. Individual channels can be different frequencies or spread spectrum channels, such as channels defined by different Walsh codes. When the user makes a packet data call for the first time, the system will provide the user with broadcast parameters and communication protocol information. First, the user or MS will request the header compression information from the PDSN. After the MS uses the information received from the PDSN, it can receive the broadcast regular information. The MS contacts the CS through an IP-based communication protocol (that is, RTSP or SIP) to receive instructions from the transmission and application layers. MS uses this information to receive, Decoding and processing broadcast operations.

Figure 21 illustrates the many channels used to transmit a lot of information in the broadcasting system. As shown in the figure, the system 3000 includes CS 3002 and MS 3004 communicating through a broadcast channel 3010, a regular channel 3012, and a traffic channel 3014. The broadcast content of the known broadcast operation will be transmitted on the broadcast channel 3010, which can be a uniquely assigned frequency or a uniquely assigned Walsh channel. The transmission of BSPM messages is provided on the regular channel 3012. The traffic channel 3014 is used for the transmission of out-of-band signals, such as communication between CS and MS, and communication between PDSN (not shown) and MS.

MS can use out-of-band signals to directly contact CS and PDSN through the packet data service option. The out-of-band communication allows the CS to update information without transmitting through the BS, so that the out-of-band communication is directly between the MS and the PDSN or between the MS and the CS. Please note that when the packet data service is used as an out-of-band device, the communication between the MS and the CS still needs to go through the BS. However, the BS does not need to know the payload, so it does not need to coordinate the communication protocol between CS and BS.

To avoid the shortcomings of the out-of-band method that the communication protocol and parameters are transmitted to the receiver, the SDP description from CS can be multiplexed into the broadcast stream. This allows the mobile station to determine the protocol options used by the CS without having to configure the packet data call.

SDP descriptions are often transmitted as short-term encryption keys (SK) in the broadcast stream. The rate at which these updates are transmitted is limited by the bandwidth available for such updates. For example, if the SDP description is 300 bytes and is transmitted every 3 seconds, the required bandwidth is 800 bps. Please note that because the SDP description originates from the content server, when the media bandwidth is low enough to accommodate the SDP message, the content server It will be multiplexed into the broadcast stream to improve media quality. Effectively, SDP information can be changed according to bandwidth conditions. Therefore, when the channel conditions and/or the stress of the system bandwidth change, the frequency of SDP transmission will also change. Similarly, the size of the SDP can also be changed by adjusting the information assigned to the known system.

SDP instructions are usually transmitted in RTSP, SAP or SIP messages. To avoid the burden of this communication protocol, it is recommended to use the number of well-known UDP ports to carry SDP messages, so that SDP descriptions can be directly transmitted through UDP. This number of ports does not need to be used to carry RTP or other types of UDP traffic sent through the broadcast channel. The UDP check sum will provide error detection for SDP payloads.

According to a specific embodiment illustrated in FIG. 22, the system provides broadcast communication protocols and parameters through in-band signals in the broadcast stream. The broadcast stream 4000 contains broadcast content and is transmitted on a broadcast channel (such as the broadcast channel 3010 in FIG. 21), and the SDP 4002 is scattered throughout the broadcast stream 4000.

FIG. 23 illustrates a method 5000 for providing broadcast service parameters and communication protocols using an in-band method, in which regular information accompanying broadcast content is provided on a broadcast channel. The term in-band is used to describe that regular information is provided on the same channel as the broadcast content, so that no separate transmission mechanism is required, that is, the channel. Method 5000 first accesses BPSM at step 5002. The MS obtains broadcast channel information, actual layer information, and MAC layer information from the BSPM. At step 5004, the header compression information is directly received from the PDSN. The MS directly contacts the PDSN through the packet data service option (out-of-band), or the PDSN will mark The problem of compressed configuration information is inserted into the broadcast stream arriving at the MS, which can achieve the above-mentioned purpose. At step 5006, the MS receives the broadcast content (BC). In response to receiving the header compression information, in step 5008, the MS can receive the SDP that is transmitted on the broadcast channel and has broadcast content. SDP contains parameters and communication protocols for receiving accompanying broadcast operations. MS will apply the information contained in the SDP to receive, decode and process the broadcast content received on the broadcast channel.

When the user of the broadcast service wants to change to another broadcast job, the setting and/or initialization of the new broadcast job may introduce an unacceptable delay to the user. A specific embodiment provides a memory storage device located on the receiver, in which at least part of the information is stored in the receiver, and can be quickly changed from one broadcast operation (that is, a program) to another, or can be used to call back the previous connection Broadcast job fetched. FIG. 23 illustrates the memory storage device 6000, which can store the SPI and SDP corresponding to each received broadcast operation. The regular information corresponding to the current broadcast operation will be stored in the memory 6000, and the stored information is the latest received information. In a specific embodiment, the memory storage device 6000 is a first-in first-out (FIFO) memory storage device. In another embodiment, cache memory will be used. Still in other specific embodiments, a look-up table (LUT) will be used to store information about received broadcast operations.

In specific embodiments using mechanisms such as cache memory and/or LUT, the MS uses a sampling timestamp algorithm to maintain a copy of the latest SPI-SDP configuration in the memory. For each SPI-SDP pair, a time stamp will be kept when the MS receives the latest description. If the MS detects the SPI that already exists in the memory, it will use the stored configuration and set the time The stamp is updated to the current time. If the detected SPI is not in the MS memory, the MS will replace the oldest SPI-SDP record in its memory with the newly detected SPI-SDP pair. At this moment, the MS uses the new configuration to decode the broadcast stream.

Message flow

Figure 5 illustrates the call flow of a broadcast operation in an exemplary embodiment for receiving a known system topology. The system includes MS, BS, PDSN and CS listed on the horizontal axis. The vertical axis represents time. The user or MS serves the user of HSBS. At time t1, the MS and CS will negotiate the subscription security of the broadcast service. Negotiation involves the exchange and maintenance of encryption keys, etc. used to receive broadcast content on broadcast channels. The user establishes a security agreement with CS on receiving encrypted information. The encrypted information may include the broadcast access key (BAK) or key combination from CS. According to an exemplary embodiment, the CS provides encrypted information on a dedicated channel during the packet data operation, such as through PFP, WAP, or other out-of-band methods.

At time t2, the MS will adjust to the broadcast channel and start receiving packets. At this point, because the IP/ESP header is compressed through ROHC and the MS's decompressor has not yet been initialized, the MS can process the received packet. PDSN will provide header compression information at time t3 (details will be described below). From the ROHC packet header, the MS can detect and obtain ROHC initialization and update (IR) packets that are periodically transmitted from the PDSN to the broadcast channel. The ROHC IR 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. Then the MS can process the IP/ESP header of the received packet, but the MS needs further information to process the ESP payload because the Loaded on the CS using a short-term key (SK) for encryption. SK and BAK are in a peer-to-peer relationship, where SK uses BAK to decrypt on the receiver. CS will provide further encryption information, such as update key information or current SK at time t4. Please note that CS will provide this information to MS regularly to ensure the security of ongoing broadcasts. At time t5, the MS receives the broadcast content from the CS. Please note that another specific embodiment can incorporate other compression and decompression methods that can provide effective title information transmission. In addition, other specific embodiments can also implement many security laws to protect broadcast content. Still other specific embodiments can also provide unprotected broadcast services. MS uses encrypted information such as SK to decrypt and display broadcast content.

compression

According to the exemplary embodiment, the broadcast content will be transmitted on a dedicated broadcast channel. The transport layer provides the encrypted regular information used to carry the broadcast content in the IP packet. The system supports data compression, especially title compression. The decision to compress data depends on the average total required (including transmission/encryption burden, data link layer burden, and actual layer burden) and the broadcast quality received by the user. Carrying more broadcast content in each IP packet can reduce the burden, so the bandwidth of the broadcast channel can be reduced. In contrast, compression increases the packet error rate (PER) and affects user reception. This is because the transmission of each long IP packet spans multiple actual layer frames, so the frame error rate (FER) will increase accordingly. If the telecommunications company decides to use smaller IP packets to improve the broadcast quality, the telecommunications company can choose header compression to reduce the burden of IP packet transmission and encryption.

The RTP/UDP/IP communication protocol is used to transmit broadcast content from CS to MS, And the content is protected by ESP in the delivery mode. The transmission burden is RTP/UDP/IP header and 40 bytes of each IP packet data. The encryption burden is in the form of the ESP header, initialization vector (IV), and ESP suffix. The ESP header and IV are inserted between the IP header and the UDP header. The ESP header is composed of SPI (4 bytes) and sequence number (4 bytes). The length of IV depends on the encryption algorithm used. For the AES Cipher algorithm, the length of the IV is 16 bytes. The ESP suffix is appended to the end of the UDP datagram and consists of a filler code, the next header (1 byte), and the length of the filler code (1 byte). Because the cipher block size of the AES algorithm is 16 bytes, the size of the padding code ranges from 0 to 15 bytes. Talking about the top function of the average pad size will produce 8 bytes. For IP packets, the total burden due to transmission and encryption ranges from 66 to 81 bytes, with an average of 74 bytes, excluding the burden of the data link layer from PDSN to MS.

Header compression such as Robust Header Compression (ROHC) can be used to reduce the SPI field of IP headers and ESP headers from 24 bytes to 2 bytes. Because it is used for the ordering of compressed packets, the sequence number of the ESP header is not compressed. Because the IV changes randomly with each packet, it is not compressed. Because the UDP/RTP header and ESP suffix are encrypted, they cannot be compressed. Therefore, if ROHC is used to compress IP/ESP headers, the average burden of each IP packet due to transmission and encryption will be reduced from 74 bytes to 52 bytes.

According to the exemplary embodiment, title compression such as Robust Title Compression (ROHC) is applied, so as to avoid the propagation of uncompressed errors. As shown in Figure 7, the header information is compressed from 24 bytes to 2 bytes. Heading 500 contains a IP header 502 and an SPI part 504. The compression algorithm can leave the information with 2 bytes after compression. Compared with the traditional header compression, in which some negotiation is required between the MS and the PDSN or other infrastructure components, the exemplary embodiment provides a non-directional compressed information transmission. The MS needs to request compressed information, that is, the header compression parameters are sufficient for decompressing the information received on the MS. Otherwise, the PDSN periodically provides compressed information as shown in Figure 8. PDSN provides compressed information scattered in broadcast content on broadcast channels. In this way, it does not need to be called "in-band", as the control information provided in the data stream of an individual channel. As shown in the figure, the broadcast stream 600 includes a broadcast content part 604 and decompressed information 602, that is, compressed information. Here will be T_{DECOMPRESSION}The period of time provides decompression information. Other specific embodiments may provide decompression information when a predetermined event occurs, rather than periodically. When the MS does not request to decompress the information, the PDSN provides information with frequency to avoid delays in accessing the broadcast content. In other words, the PDSN should always provide the information so that the MS can receive the broadcast at any time without waiting to decompress the information.

Please note that ROHC can operate in non-directional mode, where packets are only transmitted in one direction: from compressor to decompressor. Therefore, in this mode, the ROHC can be used on the link, where the return path from the decompressor to the compressor is unavailable or undesired. Before the MS can decompress the packets received from the broadcast channel, the state of the decompressor must be initialized. This is the purpose of the initialization and update (IR) packet. There are two different ROHC initializations here.

The user "adjusts" to the broadcast channel and waits for the ROHC IR packet periodically transmitted by the ROHC compressor in the PDSN. MS often needs ROHC IR packets, In order to quickly decompress the received packet. Frequent transmission of ROHC IR packets will consume too much broadcast channel bandwidth. An IR packet has about 30 bytes for the IP/ESP compression profile. If IR packets are transmitted every 250 ms., this processing will consume approximately 1 kbps of bandwidth in the broadcast channel. Loss of IR packets in the air will further delay the time for the MS to obtain ROHC initialization.

If the decompression is out of synchronization or error due to packet loss or residual errors or errors in the received compressed header, etc., the resulting decompression error will be propagated until the decompression is resynchronized or reinitialized. ROHC compressed headers include Cyclic-Redundant Check (CRC), which calculates the entire header before compression. This CRC allows decompression to perform local text repair (occurring in the event of packet loss and residual errors) that synchronizes the text. When decompression recovers from errors, periodic IR packets will effectively reinitialize the decompression process.

Transport layer

The data link layer frame communication protocol or the transport layer communication protocol will be applied between the PDSN and the MS to describe the packets received from the broadcast channel. Please refer to Figure 3 to provide information in the transport layer (labeled as LINK LAYER) between the PDSN and the MS. The frame information will be generated on the PDSN and provided to the MS through the BS. The PDSN receives the IP stream from the CS, and frames the IP stream according to a predetermined frame communication protocol. As explained in the exemplary embodiment, the PDSN will provide a high-level data link control (HDLC) frame communication protocol version. HDLC is specified in the ISO standard corresponding to the second layer of the International Standards Organization (ISO) 7-layer architecture, where the second layer is called the data link layer. The HDLC protocol attempts to provide error-free movement between network nodes. For this purpose, The design of the HDLC layer is to ensure the integrity of the data passing to the next layer. In other words, the frame communication protocol is used to indeed regenerate the received data into the original data sent out without errors, no information loss, and correct sequence.

The exemplary embodiment provides a framed version of HDLC that provides a subset of HDLC defined parameters. FIG. 9 illustrates a specific embodiment of HDLS framing, where the frame 700 includes a plurality of fields defined by the HDLC protocol described in RFC 1662. The field 702 defines the FLAG or the indication of the beginning of the frame. FLAG has a specified bit length and is defined by a predetermined bit pattern. Because HDLC is a commonly used standardized communication protocol, it is most convenient to supply HDLC. The disadvantage of the full HDLC frame communication protocol is the processing time required to generate a frame on the transmitter and obtain the frame on the receiver.

Specifically, the HDLC communication protocol is used for further processing by the processor to ensure that the payload does not contain the same bit sequence as FLAG. On the transmitter, if the FLAG bit sequence is detected in the payload, an escape character will be inserted in the payload, FLAG will be recognized as a part of the payload and the start of the frame will not be indicated. The processing of the newly added skip characters is called the "trip" hexadecimal pattern of 0×7E and 0×7D in the frame payload. Another method is called "efficiency frame communication protocol", which is less than the number of processors required for HDLC-style framing described below. Figure 9 illustrates the options for using HDLC framing to support PPP frames. For HSBS operations, the burden of HDLC-style framing can be reduced by eliminating unnecessary fields for non-directional broadcasting, or using a little method and/or providing a little less information. As explained above , FLAG is the predetermined bit sequence indicating the beginning of the HDLC frame. The exemplary embodiment incorporates the beginning of a FLAG or other frame indicator code 802, as shown in the format 800 of FIG. 10. Compared with the format of FIG. 9, the end of the frame does not indicate the regular information in the exemplary embodiment. For the address and control field of the format 700 with static values, they are not included in the format 800.

Continuing to refer to Figure 10, the purpose of the protocol field 708 (Figure 9) is to identify the type of payload (such as LCP control packet, ROHC packet, IP packet, etc.), because all packets in the broadcast channel belong to the same Type, so this discriminator is not needed for broadcast operations. For example, if ROHC compression is used for packet transmission, all packets in the broadcast channel will be treated as ROHC packets. The packet type field in the ROHC packet header can respectively indicate the type of ROHC packet (such as IR packet, compressed packet, etc.). Therefore, the format 800 does not include the communication protocol field. Further, the format 800 includes an error check field 806 located after the payload 804. The error check field 806 provides information to the receiver to allow the receiver to check whether there is an error in the received payload. The exemplary embodiment incorporates a frame check sum (FCS) that can be specified as blank, 16-bit, or 32-bit. Because the HDLC frame may span multiple actual layer frames in the broadcast channel, 16-bit FCS is recommended.

The eight-fold filling procedure defined in RFC 1662 is also suitable for the exemplary embodiment. After the FCS calculation is completed, the HDLC transmitter in the PDSN will test each bit in the HDLC frame with 0×7E and 0×7D patterns ( In addition to the flag (Flag)). The pattern 0×7E will be coded into 0×7D and 0×5E, and the pattern 0×7D will be coded into 0×7D and 0×5D. The HDLC transmitter does not encode any other patterns. This implies that the asynchronous control as defined in RFC 1662 The character map (Async-Control-Character-Map, ACCM) will all be set to zero.

The HDLC frame burden is 3 bytes plus eight layers of filling burden. Assuming that the byte pattern has been evenly distributed, each 128-byte HDLC frame is an average eight-fold filling burden. For example, if the payload is 256 bytes, the average HDLC framing burden is 5 bytes.

FIG. 11 is a flowchart of a method 900 for framing performed on the transmitter. At step 902, the transmitter forms a broadcast frame by determining the payload portion of the packet data and generating a start of flag (SOF). The transmitter then checks the frame of any SOF sequence contained in the payload 904. If the SOF sequence is found in the payload, the transmitter will add escape characters in step 912. Otherwise, the transmitter will add SOF to the payload at step 906 and provide an error checking mechanism at step 908. In step 910, the frame will be transmitted. The transmitted frame has the format 800 of FIG. 10. Another specific embodiment can implement other fields in the framed format, and can incorporate any form of distinguishing code to locate the SOF sequence in the payload.

FIG. 12 is a flowchart of a deframing method 920 executed on the receiver. The process starts with the reception of the broadcast frame in step 922. At step 924, the receiver recognizes the SOF, and at decision block 926 checks whether there are escape characters in the payload. If a skip character or other SOF sequence identification code is found in the payload, the receiver will remove the skip character in step 932. Otherwise, the receiver will perform error checking in step 928 and process the frame in step 930.

Those who are familiar with this art will understand that the use of any of many different technologies and techniques can represent information and signals. For example, using voltage, current, electromagnetic Waves, magnetic fields or particles, light fields or particles, or combinations of the above can be used to replace the data, instructions, commands, information, signals, bits, symbols, and chips mentioned in the entire article above.

Those who are familiar with this technique can further understand that the logic blocks, modules, circuits, and calculation steps disclosed in the specific embodiments can be implemented as electrical hardware, computer software, or a combination of the two. To clearly describe these interchangeable hardware and software, many description components, blocks, modules, circuits, and steps will be described in a function-oriented manner. Regardless of whether these functionalities are implemented as hardware or software, it all depends on the specific application and design constraints imposed on the entire system. A skilled artisan can implement the above-mentioned functionality in many ways for each specific application, but this implementation decision cannot be construed as a departure from the field of the invention.

Many descriptive logic blocks, modules, and circuits that accompany the description of the specific embodiments disclosed herein can be used with general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), and field programmable gate arrays. (FPGA) or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination designed to perform the above functions. The general purpose processor may be a microprocessor, but on the other hand, the processor may be any conventional processor, controller, microcontroller, or static machine. The processor can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a DSP core, or other such configurations.

The methods or calculation steps described here together with the disclosed embodiments can be directly implemented in hardware, implemented by a processor in a software module, or Implemented in a combination of the two. The software module can be located in RAM memory, cache memory, ROM memory, EPROM memory, EEPROM memory, scratchpad, hard disk, removable disk, CD-ROM or any other known in the industry Storage media format. An exemplary storage medium is coupled to the processor so that the processor can read and write information from the storage medium. In addition, the storage medium can be integrated into the processor. The processor and storage medium can be located in the ASIC. The ASIC can be located in the user terminal. In addition, the processor and the storage medium can be used as discrete components in the user terminal.

A description of the specific embodiments disclosed before will be provided here, so that anyone who is familiar with the art can make or use the present invention. Those skilled in the art can quickly understand many modifications made to these specific embodiments, and the general principles defined here can be applied to other specific embodiments that do not depart from the spirit or field of the present invention. In this way, the present invention is not limited to the specific embodiments shown here, but conforms to the broad field of principles and innovative features disclosed herein.

Schematic element symbol description

100. . . Communication system

102. . . unit

104. . . Base station

106. . . Terminal

200. . . Wireless communication system

202. . . Packetized Data Service Network (PDSN)

204. . . BS

206. . . MS

400. . . Broadcast streaming

402. . . Control part of title

404. . . The length of the title

406. . . Payload

408. . . Control part of title

410. . . The length of the title

412. . . Payload

414. . . pad

500. . . title

502. . . IP title

504. . . SPI part

506. . . Compress IP header bits

508. . . Compress SPI field bits

600. . . Broadcast streaming

602. . . Unzip information

604. . . Broadcast content section

700. . . Frame

702. . . Field

704. . . Address field

706. . . Control field

708. . . Protocol field

710. . . Data field

712. . . Frame Check Sum (FCS) field

800. . . Format

802. . . Frame indicator

804. . . Payload

806. . . Error check field

1000. . . Wireless communication system

1002. . . Content Server (CS)

1004. . . Packet Data Service Node (PDSN)

1006. . . Packet Control Function (PCF)

1008. . . Packet Control Function (PCF)

1020. . . Wireless communication system

1022. . . Content Server (CS)

1024. . . Packet Data Service Node (PDSN)

1026. . . Packet Control Function (PCF)

1028. . . Packet Control Function (PCF)

2020. . . Mapping

2040. . . Cube field marked as an option

3000. . . system

3002. . . CS

3004. . . MS

3010. . . Broadcast channel

3012. . . Regular channel

3014. . . Traffic channel

4000. . . Broadcast streaming

4002. . . SDP

6000. . . Memory