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

Method and device for out-of-band transmission for broadcast service selection 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.

Refer to the joint pending patent application

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 invention is the assignee, and it is expressly stated here that it is incorporated by reference; "Method and Apparatus for Overhead Messaging in a Wireless Communication System" proposed by Nikolai Leung, entrusted with file number 010439, is in conjunction with the present invention The present invention is proposed and assigned as the assignee, and it is hereby expressly stated that it is incorporated herein by reference; "Method and Apparatus for Broadcast Signaling in a Wireless Communication System" proposed by Nikolai Leung, entrusted file number 010438, and The present invention is proposed and assigned as the assignee, and it is expressly stated here that it is incorporated herein by reference; "Method and Apparatus for Transmission Framing 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, 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 one-way services with unique needs and goals, such as broadcast services that stream video and audio data to users. This kind of service has a huge bandwidth demand, which makes system designers seek to minimize the transmission of burdened information. In addition, users also need specific information to access the broadcast transmission, such as processing parameters and communication protocols. When optimizing the available bandwidth, when transmitting broadcast designated information There is 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 embodiments disclosed herein point out the above stated requirements by providing an extremely secure method in a data processing system.

On the one hand, in a wireless communication system supporting broadcast services, there is a method of transmitting a broadcast dialogue on a broadcast transmission channel and transmitting broadcast burden information corresponding to the broadcast dialogue on a burden transmission channel. Broadcast services use content servers for transmission. The broadcast service has a corresponding communication protocol stack (with an application layer and a transport layer), in which the content server controls the communication protocol of the application layer and the transport layer respectively.

On the other hand, in a wireless communication system supporting broadcast services, there is a method that includes receiving broadcast burden information corresponding to the broadcast dialogue on the burden transmission channel, accessing the broadcast dialogue on the broadcast transmission channel, and using the broadcast burden information to The method of handling the broadcast content of the broadcast dialogue.

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

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

Fig. 3 is a communication protocol stacking model corresponding to the broadcast service selection in the wireless communication system.

FIG. 4 is a table of communication protocols applied to the protocol stack layer supporting broadcast service options in the wireless communication system.

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

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

Figure 7 is a header compression map in a wireless communication system.

Figure 8 shows the periodic header compression information broadcast.

Figure 9 shows the header compression communication protocol.

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

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

Figure 12 is a flow chart of header decompression of broadcast services in a wireless communication system.

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

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

Figure 16 shows the system burden parameter message configuration.

Figure 17 shows the bit block of the system burden parameter message configuration.

Figure 18 is a flow chart of providing broadcast communication protocols and parameters in a wireless communication system.

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

Fig. 20 illustrates the definition of parameters in the wireless communication system.

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

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

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

Figure 24 is a memory element storing broadcast burden 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 it appears in the schema In many aspects of the invention, unless otherwise specified, the drawings are not 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 one-way broadcast service that provides video and/or audio streaming to multiple users. To enter the broadcast service, users need to "adjust" to the designated channel to access 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 burdened 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 currently available 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 information flow in the broadcast system will be discussed along with the system topology (that is, the infrastructure components). Finally, the header compression applied in the exemplary embodiment will be discussed.

Please note that the exemplary embodiments provided are used as examples in this discussion, but other specific embodiments can be incorporated into many fields without departing from the field of the present invention. In particular, the present invention is used in data processing systems, wireless communication systems, one-way broadcast 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 processing used to transmit data from the base station to the mobile phone, 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.

The example shown in FIG. 1 is a communication system 100, which is used to support most users and can implement at least some aspects and embodiments of the present invention to communicate. Any algorithm and method can be used to schedule the transmission within the system 100. The system 100 provides communication for many units 102A to 102G, and each unit is serviced 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 may be fixed (ie, immobile) or mobile. As shown in FIG. 1, many terminals 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. All communicate with at least one and possibly multiple base stations 104. The soft handoff in the CDMA communication system is well known in the industry, and it was published in detail in US Patent Application No. 5,101,501 called "Method and system for providing a Soft Handoff in a CDMA Cellular Telephone System", which is designated as the present invention here. The assignee.

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 figure 1 The base station 104A transmits data to the terminals 106A and 106J on the downlink, the base station 104B transmits data to the terminals 106B and 106J, the base station 104C transmits data to the terminal 106C, and so on.

The increasing demand for wireless data transmission and the effective service expansion through wireless communication technologies have resulted in the development of specific data services. There is a 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 is 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. The 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 MSs 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 that HSBS broadcast services can be developed . The factors involved in designing the system include, but are not limited to, the number of HSBS dialogues 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 dialogue 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 forward link physical 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 programs at a data rate sufficient to support video and audio communications. For example, HSBS applications may include video streaming of movies, sports games, and so on. The HSBS service is a packet data service based on the 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 this high-speed broadcast service to the system user. 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 protocols (WAP), and/or other methods that are generally consistent and convenient for mobile wireless communication can be used to inform the broadcast content. Mobile users are called mobile stations (MS). The base station (BS) transmits HSBS related parameters in the burden message, such as the burden message transmitted on the channel and/or frequency designated for control and information, that is, the non-effective load message. The effective load is the content of the transmitted information. For broadcast dialogue, the effective load is the broadcast content, video programs, and so on. When a broadcast service user wants to receive a broadcast conversation, that is, a specific broadcast program, the MS will read the burden message 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 forward supply channel (F-SCH) supports data transmission. A specific embodiment combines a large number of forward basic channels (F-FCH) or forward dedicated control channels (F-DCCH) to achieve higher data rate requirements for data services. This exemplary embodiment uses F-SCH as the basis for F-BSCH to support 64 kbps payload (except for RTP burden information). The F-BSCH can also be modified to support other effective load rates, such as subdividing the 64-kbps effective load rate into lower rate sub-streams.

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

In the exemplary embodiment, the F-BSCH with a high data rate may occupy most of the forward 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 is to consider the trade-off between the coverage edge and the video quality at the location close to the unit. When the effective load rate decreases, the effective error correction code rate will increase, 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. This same trade-off also applies to other non-video applications that F-BSCH can support. In reducing the download speed of these applications, reducing the effective load rate supported by the channel will increase the 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 effective load capacity 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 exemplary embodiments: (1) The standard effective load rate is 64 kbps. (2) For streaming video services, the effective load rate is assumed to be that the burden information of each RTP packet contains 12 8-bit bytes, (3) RTP and physical The average burden information of all layers between layers is about 64, 8 bits per packet plus 8 bits of F-SCH frame burden information used by each MUXPDU header.

In the exemplary embodiment, for non-video broadcast services, the highest supported rate is 64 kbps. However, other effective load 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. Controlled access can be achieved by encrypting HSBS transmission/content, so that only subscribers 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 law called partial control access provides HSBS service as a subscription-based service with intermittent unencrypted advertisement transmission encryption. These advertisements can be used to encourage subscription to encrypted HSBS services. MS can know the schedule of these unencrypted sections through external means.

HSBS service selection

HSBS service selection is defined as follows: (1) communication protocol stack; (2) selection within the communication protocol stack; and (3) procedures for setting and synchronizing services. Figures 3 and 4 illustrate stacking of communication protocols according to exemplary embodiments. As illustrated in FIG. 3, the communication protocol stack will be assigned to the infrastructure elements, 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 an audio codec, a visual codec, and any visual profile. In addition, when using RTP, the communication protocol specifies the radio transmission communication protocol (RTP) payload type. For the MS transport layer, the communication protocol will specify the User Datagram communication 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 communication protocol selections in the communication protocol stack. This requires that the selected communication protocol option is notified 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 according to the cdma200 standard as a burden system parameter message. The advantage of this for the receiver is the ability to immediately receive information from the burden message. In this way, the receiver can immediately determine whether the receiver has enough resources to receive the broadcast conversation. The receiver will monitor the burden system parameter information. The system can implement service options corresponding to a set of parameters and communication protocols Numbers, where the number of service options will be provided in the burden message. In addition, the system can provide a set of bits or flags to indicate the different communication protocol options selected. The receiver then decides the communication protocol options used to correctly decode the broadcast conversation.

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 dialogue. 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 that is a distance from the broadcast channel. After using this method, there is no need to transmit the description of the upper layer communication protocol stack through the broadcast channel or the burden system parameter channel.

As discussed above, service options define a stack of communication protocols and procedures for operating broadcast services. Like one-way services, broadcast services are characterized by sharing communication protocol options among multiple broadcast receivers. In the exemplary embodiment, there is no negotiation between the mobile station and the network regarding the communication of broadcast services. Letter agreement option. This option is reserved 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 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 CS to access 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 communication 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 MS can select packet data service options (such as using the SO 33 dedicated packet data service option channel) to access the network. Effectively, the MS selects a packet data service option to establish a real-time streaming protocol (RTSP) dialogue containing CS. At time t3, the MS requests a description 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 dialog initial communication protocol (SIP) to request the application and transfer of the communication protocol description. At time t4, the description will be carried through the dialogue description protocol (SDP). The user can also perform the transmission of the communication protocol when accessing the broadcast service. Please note that RTSP and SDP are standardized methods for establishing unidirectional streaming services within IETF and 3GPP2. The mobile station can also use the packet data service to request the PDSN to identify 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 Control Protocol IPCP will be used to exchange 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 communication 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 communication 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 communication protocol options for continuous streaming conversations, and when the communication protocol changes, the CS will modify the SPI. Second, the PDSN has not changed the header compression algorithm or the parameters between streaming sessions with the same SPI.

The change of the communication protocol option in the known system will trigger multiple mobile stations to set up a packet data service call to obtain the updated communication protocol description. 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 communication protocol options.

In contrast, the broadcast channel communication protocol and parameters can be transmitted to the mobile station. In another specific embodiment, a service option (SO) number is assigned to each set of broadcast communication 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 multiple 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 The burden message assigned to the broadcast service. 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 boot PN sequence offset index is identified as PILOT_PN. The BS sets the PILOT_PN field to the guide 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 forward broadcast supply channels. The BS sets this field to the number of forward broadcast supply channels transmitted by the corresponding BS. NUM_HSBS_SESSION is the number of broadcast service conversations. The BS sets this field as the number of broadcast service conversations transmitted by the corresponding BS. NUM_LPM_ENTRIES is the number of logical to actual mapping entities. The BS sets this field to the number of mapping entities from the logic (that is, the broadcast service dialogue) carried in the message to the actual (that is, the forward broadcast supply channel). BS will set up Set the forward broadcast supply channel identification code FBSCH_ID corresponding to the forward 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 of the forward 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, which corresponds to the forward broadcast The CDMA frequency assignment of the CDMA channel of the supply channel.

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

FBSCH_RATE is the data rate of the forward broadcast supply channel, and the base station will set this field to the data rate used on the forward broadcast supply channel. FBSCH_FRAME_SIZE is the frame size of the forward broadcast supply channel, and the base station will set this field to the frame size on the forward broadcast supply channel. FBSCH_FRAME_REPEAT_IND is the forward broadcast supply channel frame repeat indicator. If frame repeat is used on the forward 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 forward broadcast supply channel soft handover support indicator, where if the base station supports one or more adjacent base stations The base station will set this field to '1' for the soft handover on the forward broadcast supply channel of the base station, otherwise the base station will set this field to '0'.

NUM_NGHBR is the number of neighbors that support the soft handover of the forward 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 forward broadcast supply channel. NGHBR_PN is the sequence offset index of the adjacent leading PN. The base station sets this field to the leading PN sequence offset of adjacent base stations in 64 PN segment units. NGHBR_FBSCH_CODE_CHAN_INCL is the adjacent preamble forward broadcast supply channel code channel index containing the indicator. If the adjacent guide forward 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 guide forward 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 forward direction on the adjacent station The code channel index of the broadcast supply channel.

HSBS_ID is the identification code of the broadcast service dialogue, and the base station will set this field to the identification code corresponding to this broadcast service dialogue. 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 dialog. HSBS_ID is the identification code of the broadcast service dialogue, and the BS will set this field to the identification code corresponding to the broadcast service dialogue.

FBSCH_ID is the forward broadcast supply channel identification code, where the base station will This field is set to correspond to the identification code of the forward broadcast supply channel, which carries the above-mentioned broadcast service dialogue.

Here, the communication protocol options that need to be negotiated between the transmitter and the receiver will be selected and defined in the service option description. The MS uses the SO number to pass into the BSPM to discover the communication protocol options of the broadcast service. Compared with the unidirectional 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 specified transport layer is regarded as the applied transport communication protocol in the SO, such as RTP, so that the effective load of the UDP packet cannot be quickly identified. SO will also specify the number of UDP ports used for RTP payload to allocate 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 unidirectional broadcast applications, the RTP payload types of these codecs must be dynamically assigned through a call setting protocol (for example, using SIP, RTSP, etc.). Because the broadcast service intends to avoid this protocol, the SO pre-selects the media decoder. Furthermore, because audio and video data can be carried in separate RTP packets, the RTP payload type to be used for each media stream can be specified.

In the exemplary embodiment, the logical to actual mapping specifies the HSBS channel (HSBS_ID/BSR_ID) carried in the F-BSCH (FBSCH_ID). set Together {HSBS_ID, BSR_ID, FBSCH_ID} fully indicate (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 over 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. Burden 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 option burden on the application layer changes, so it needs to be redefined, while the use of BLOB allows changes at 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 transmitted as part of the BSPM and identify the communication protocol options used for the broadcast service. Figure 17 illustrates the stacking of communication protocols and the application of BLOB. Preparing the BLOB can provide the advantage that the mobile station can use BSPM to identify the communication 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 instructions is the use of wireless infrastructure to Coordinate the communication protocol 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 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 communication protocols that the mobile station must support, you should define broadcast service obligations and optional communication protocol options.

FIG. 18 illustrates a method 2000 of 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 communication 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 number to a set of parameters and communication protocols. When CS schedules a broadcast for the first time, such as a football match on a specific day, CS will determine the parameters for broadcast transmission from a set of previously standardized options. Communication agreement.

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 dialog. 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, FIELD 2 of the BLOB can be specified as any option: OPTION 1 to OPTIONK, and each BLOB field has a different number of options available.

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 burdening information communication. Individual channels can be different frequencies or spread spectrum channels, such as channels defined by different Walsh codes. When a 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 header compression information from the PDSN. After the MS uses the information received from the PDSN, it can receive the broadcast burden 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, decode and process broadcast conversations.

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 burden channel 3012, and a traffic channel 3014. It is known that the broadcast content of the broadcast dialogue 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 burden channel 3012. The traffic channel 3014 is used for the transmission of out-of-band signals, such as the communication between the CS and the MS, and the communication between the PDSN (not shown) and the 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 effective load, 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 communication protocol options used by the CS without setting up a packet data call.

SDP instructions will be transmitted as a short-term encryption key (SK) burden 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 will multiplex it into the broadcast stream to improve media quality. Effective Yes, 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 transmitted through the broadcast channel. The UDP checksum will provide error detection for the SDP payload.

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 SDP4002 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 burden-based information accompanying broadcast content is provided on a broadcast channel. The term in-band is used to describe the provision of affordable information on the same channel as the broadcast content, so that no separate transmission mechanism is required, that is, the channel. The method 5000 first accesses the BSPM 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 inserts the header compression configuration information into the broadcast stream arriving at the MS, which can achieve the above purpose. At step 5006, the MS accesses the broadcast content (BC). In response Upon receiving the header compression information, at 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 the accompanying broadcast dialogue. MS will apply the information contained in the SDP to receive, decode and process the broadcast content received on the broadcast channel.

When a user of a broadcast service wants to change to another broadcast conversation, the setting and/or initialization of the new broadcast conversation may introduce an unacceptable delay to the user. A specific embodiment provides a memory storage unit 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 conversation (that is, a program) to another, or can be used to recall previous memories Take the broadcast dialogue. FIG. 24 illustrates that the memory storage 6000 can store the SPI and SDP corresponding to each received broadcast session. The burden information corresponding to the current broadcast dialogue is stored in the memory 6000, and the stored information is the latest received information. In a specific embodiment, the memory storage 6000 is a first-in first-out (FIFO) memory storage unit. 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 conversations.

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 an SPI that already exists in the memory, it will use the stored configuration and update the time stamp to the current time. If the detected SPI is not in the MS memory, the MS will replace it in its memory with the newly detected SPI-SDP pair The oldest SPI-SDP record. 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 dialogue in an exemplary embodiment for accessing 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, etc. According to an exemplary embodiment, the CS provides encrypted information on a dedicated channel during the packet data session, such as through PPP, 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 been initialized, the MS can process the received packet. PDSN will provide header compression information at time t3 (described in detail 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. The MS can then process the IP/ESP header of the received packet, but the MS needs further information to process the ESP payload, because the payload is encrypted using the short-term key (SK) on the CS. 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 header 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 encryption burden information used to carry the broadcast content in the IP packet. The system supports data compression, especially header 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 a telecommunications company decides to use smaller IP packets to improve 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 transfer broadcast content from CS to MS, and the content is protected by ESP in the transfer mode. The transmission burden is RTP/UDP/IP header and 40 bytes of each IP packet data. Encryption burden It is in the form of 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 code 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 the IP header and ESP header 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 the IP/ESP header, 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, header compression such as Robust Header Compression (ROHC) is applied, so that the propagation of uncompressed errors can be avoided. As shown in Figure 7, the header information is compressed from 24 bytes to 2 bytes. The header 500 includes an 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, where the MS and Some negotiation is required between PDSN or other infrastructure components. The exemplary embodiment provides a unidirectional 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 be responsible for providing 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 a one-way 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. The MS burden needs ROHC IR packets in order to quickly decompress the received packets. Burdened to transmit ROHC IR packets will use too much broadcast channel bandwidth. An IR packet is about 30 bytes Used for 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 compression header, etc., the resulting decompression error will be propagated until the decompression is resynchronized or reinitialized. The ROHC compressed header includes a 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 communication protocol attempts to provide error-free movement between network nodes. For this purpose, the HDLC layer is designed 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 digital According to the original form, there are no errors, no information missing, and the order is correct.

The exemplary embodiment provides a framed version of HDLC that provides a subset of HDLC defined parameters. FIG. 9 illustrates a specific embodiment of HDLC framing, where the frame 700 includes a plurality of fields defined by the HDLC communication 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 a processor used for further processing to ensure that the payload does not include the same bit sequence as FLAG. On the transmitter, if the FLAG bit sequence is detected within the effective load, a jump character will be inserted in the effective load, FLAG will be recognized as a part of the effective load and the beginning of the frame will not be indicated. The processing of 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 framed as 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 unidirectional 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 FLAG or other frame indicator codes The beginning of 802 is shown in the format 800 of FIG. 10. Compared with the format of FIG. 9, the end of the frame does not indicate the burden 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 communication protocol field 708 (Figure 9) is to identify the type of payload (such as LCP control packets, ROHC packets, IP packets, etc.), because all packets in the broadcast channel belong to The same type, so the 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 effective load 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 effective load 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. In 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 within the effective load, 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 within the effective load.

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 any escape characters in the payload. If a skip character or other SOF sequence identification code is found in the effective load, 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 skill will learn that using any of the many different disciplines Technology and technology can represent information and signals. For example, the use of voltage, current, electromagnetic waves, magnetic fields or particles, light fields or particles, or a combination 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 specific embodiments disclosed It can be implemented directly in the hardware, implemented in the software module by the processor, 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 Systems

102A-102G. . . unit

104A-104G. . . Base station

106A-106J. . . terminal

200. . . Wireless communication system

202. . . Packetized Data Service Node

204. . . Base station

206. . . Action station

402. . . content

404. . . length

406. . . Effective load

408. . . content

410. . . length

412. . . Effective load

414. . . PAD

500. . . Header

502. . . Internet Protocol (IP) header

504. . . Security Parameters Index (SPI) section

600. . . Broadcast streaming

602. . . Compress information

604. . . Broadcast content section

700. . . Frame

702. . . Field

704. . . Address

706. . . control

708. . . Agreement field

710. . . material

712. . . Frame check sum

800. . . Format

802. . . Frame indicator

804. . . Effective load

806. . . Error check field

1002. . . Content server

1004. . . Packetized Data Service Node

1006. . . Packet Control Function (PCF)

1008. . . Packet Control Function (PCF)

1022. . . Content server

1024. . . Packetized Data Service Node

1026. . . Packet Control Function (PCF)

1028. . . Packet Control Function (PCF)

2020. . . Mapping

2040. . . Mapping

3000. . . system

3002. . . Content server

3004. . . Action station

3010. . . Broadcast channel

3012. . . Burden channel

3014. . . Traffic channel

4000. . . Broadcast streaming

4002. . . Dialogue Description Communication Agreement

6000. . . Memory storage