Method and apparatus for data packet transport in wireless communication system using internet protocol (ip)
Abstract
Problem to be solved.To provide a method and an apparatus for transporting a data packet in a wireless communication system using an Internet Protocol (IP). A method and apparatus for data packet transport in a wireless transmission system that supports broadcast transmission. A multicast tree is built between nodes through neighboring routers. The multicast tree forms a tunnel through which broadcast content is transmitted. Broadcast messages are encapsulated within IP packets for transmission through the multicast tree. At least one multicast tree is formed between the Internet part of the system, such as an access network, and the wireless part of the system. In one embodiment, the external multicast tree is formed between the content source and the packet data service node, and the internal multicast tree is formed between the packet data service node and the packet control function node. [Selection diagram] Fig. 9A

Term
Projected expiry 20 February 2032.
- Priority
- Filed
- Published
- Today
- Projected expiry
21 claims: 7 independent, 14 dependent
- 1放送伝送をサポートする無線通信システムにおいて、前記システムは放送ソースノードと少なくとも1つの成端ノード、該ソースノードと該少なくとも1つの成端ノードの間で結合される少なくとも1つのルータとを有し、 前記システム内での放送伝送のための伝送範囲を決定することと、 第1の成端ノードから前記放送ソースノードへのマルチキャストツリーを構築することであって、該マルチキャストツリーが前記少なくとも1つのルータを含むことと、 前記伝送範囲上で前記マルチキャストツリーを通して放送メッセージを送信することと、を備える、伝送経路をセットアップする方法。
- 2前記マルチキャストツリーを構築することは、 前記第1の成端ノードと前記放送ソースノードの間で近接するマルチキャスト通信ルータと連続的に登録することと、を備える、請求項1に記載の方法。
- 3前記放送メッセージを送信することは、 前記放送ソースで前記放送メッセージを受信することと、 放送メッセージを受信することに応えて、マルチキャスト通信IPパケットを形成するために、前記放送ソースがIPパケット内に前記放送メッセージをカプセル化することと、をさらに具備する、請求項1に記載の方法。
- 4前記マルチキャストIPパケットは、ソースとして前記放送ソースを識別し、宛て先としてマルチキャスト通信IPアドレスを識別する、請求項3に記載の方法。
- 5前記放送メッセージを送信することは、 前記第1の成端ポイントで前記マルチキャスト通信IPパケットを受信することと、 前記マルチキャスト通信IPパケットを受信することに応えて、圧縮されたパケットを形成するために、前記第1の成端ポイントが前記マルチキャスト通信IPパケットを圧縮することと、 圧縮パケットを形成するためにIPパケットに前記圧縮パケットをカプセル化することであって、該圧縮パケットがソースとして前記第1の成端ポイントを識別することと、をさらに備える、請求項4の方法。
- 6放送伝送をサポートする無線伝送システムにおいてIPパケットを処理する方法であって、 放送メッセージをカプセル化するIPパケットを受信することと、 放送メッセージをカプセル化することと、 前記放送メッセージを抽出することと、 伝送のために前記抽出された放送メッセージをカプセル化することと、を備える方法。
- 7前記放送メッセージを解凍することと、をさらに備える請求項6に記載の方法。
- 8前記抽出された放送メッセージをカプセル化することは、 該放送メッセージのマルチキャスト通信IP宛て先を識別することと、を具備する、請求項6に記載の方法。
- 9放送伝送をサポートする無線伝送システムにおいてIPパケットを生成するためのインフラストラクチャ要素であって、 放送伝送範囲を決定する手段と、 マルチキャスト通信アドレスを有するIPパケットを生成する手段と、IPパケットを送信する手段と、を備える、インフラストラクチャ要素。
- 10無線通信システム内で放送伝送を処理するための無線通信システムであって、 放送メッセージを受信するように適応されたパケットサービスデータノードと、 マルチキャスト通信アドレスにアドレス指定されるIPパケットパケットにカプセル化される放送メッセージを受信するように適応されたパケット制御機能ノードと、を備える、システム。
- 11前記パケットサービスデータノードは、前記放送メッセージを圧縮し、該圧縮放送メッセージをフレーミングする、請求項10に記載のシステム。
- 12前記パケット制御機能ノードは、前記放送メッセージを処理し、意図されている受信者に該放送メッセージを転送する、請求項10に記載のシステム。
- 13無線通信システム内で放送伝送を処理するためのインフラストラクチャ要素であって、 マルチキャストアドレスにアドレス指定されるIPパケットにカプセル化される放送メッセージを受信する手段と、 前記IPパケットを処理する手段と、および 意図されている受信者に前記放送メッセージをアドレス指定する手段と、を備える、インフラストラクチャ要素。
- 14前記インフラストラクチャ要素は、パケット制御機能ノードである、請求項13に記載のインフラストラクチャ要素。
- 15前記マルチキャスト通信アドレスは、前記放送メッセージの意図された受信者に対応する、請求項13に記載のインフラストラクチャ要素。
- 16意図された受信者に前記放送メッセージを送信する手段と、をさらに備える、請求項13に記載のインフラストラクチャ要素。
- 17無線通信システム内で放送伝送を処理するためのインフラストラクチャ要素であって、 マルチキャスト通信アドレスにアドレス指定されるインターネットプロトコルパケットにカプセル化される放送メッセージを受信する手段と、 マルチキャストアドレスにアドレス指定されたパケットと、 前記IPパケットを処理する手段と、および 前記放送メッセージをカプセル化し、マルチキャスト通信アドレスにアドレス指定される第2のIPパケットを作成する手段と、を備える、インフラストラクチャ要素。
- 18前記インフラストラクチャ要素は、パケットデータサービスノードである、請求項17に記載のインフラストラクチャ要素。
- 19前記マルチキャスト通信アドレスは、前記放送メッセージの意図された受信者に対応する、請求項17に記載のインフラストラクチャ要素。
- 20無線通信システム内で放送伝送を処理するための通信経路であって、 前記放送メッセージがマルチキャスト通信IPアドレスにアドレス指定され、送信される第1のマルチキャストツリー部分と、 前記放送メッセージがマルチキャスト通信IPアドレスにアドレス指定され、送信される第2のマルチキャストツリー部分と、 前記放送メッセージが少なくとも1つのユニキャストアドレスにアドレス指定され、送信される第3の部分と、を備える、通信経路。
- 21前記第1のマルチキャストツリー部分はコンテンツソースとパケットデータサービスノードの間に形成され、前記第2のマルチキャストツリー部分は該パケットデータサービスノードとパケット制御機能ノードの間に形成され、前記第3の部分は該パケット制御機能ノードから基地局に形成される、請求項20に記載の通信経路。
Independent claims21
84 paragraphs, as filed
The present invention relates to wireless communication systems, and generally and in detail, relates to message compression methods and devices for transmission in wireless communication systems.
There is an increasing demand for packetized data services on wireless communication systems. Since traditional wireless communication systems are designed for voice communication, extensions to support data services pose many challenges. Bandwidth conservation is an overwhelming concern for most designers. In unidirectional transmission such as broadcast transmission, a single broadcast content is provided to a plurality of users. The user is then identified by a unique identifier contained in the addressing information. In such a system, multiple infrastructure elements may be required to replicate broadcast packets so that each of the multiple intended receivers can be identified. Replication of transmitted signals runs out of valuable bandwidth, thus reducing the efficiency of the communication system and increasing the processing requirements of intermediate infrastructure elements. Especially for broadcast services, the number of target recipients is exorbitant, causing resource allocation problems and loss of available bandwidth.
Therefore, there is a need for an efficient and accurate method of transmitting data to a plurality of recipients in a wireless communication system. Further, there is a need for a method of transferring broadcast data to a plurality of users in which each user is uniquely identified as a target recipient.
The embodiments disclosed herein address the above-mentioned needs by providing a method of routing IP packets in a wireless communication system in which packets are forwarded to an access network using multicast addresses.
In one aspect, the communication path for processing the broadcast message in the wireless communication system is the first multicast tree part in which the broadcast message is addressed and transmitted to the multicast communication IP address, and the broadcast message is the multicast communication IP address. Includes a second multicast tree portion addressed to and transmitted to, and a third portion to which broadcast messages are addressed and transmitted to at least one unicast address.
In another aspect, a radio communication system that supports broadcast transmission, with one broadcast source node and at least one termination node, and at least one coupled between the source node and the at least one termination node. In the system having a router, the method of setting up the transmission path is to determine the transmission range for broadcast transmission in the system and the at least one router from the first termination node to the broadcast source node. It includes constructing a multicast tree including the above and transmitting broadcast messages through the multicast tree in the transmission range.
In yet another aspect, the infrastructure elements for generating Internet Protocol packets within a wireless transmission system that supports broadcast transmission include means for determining broadcast transmission range and means for generating IP packets with multicast addresses. Includes means for sending IP packets.
<figref num="1">FIG. 1 is a diagram of a spectral diffusion communication system that supports many users.</figref><figref num="2">FIG. 2 is a block diagram of a communication system that supports broadcast transmission.</figref><figref num="3">Figure 3 shows a model of the protocol stack that corresponds to the broadcast service option of the wireless communication system.</figref><figref num="4">FIG. 4 is a flow chart of a message service for a broadcasting service in a wireless communication system topology.</figref><figref num="5">FIG. 5 is a functional diagram of a wireless communication system that supports broadcast transmission by multicast communication IP transmission of broadcast contents.</figref><figref num="6">FIG. 6 is an architectural diagram of a multicast tree structure applicable to a communication system.</figref><figref num="7">FIG. 7 is a flow chart of broadcasting processing in a wireless communication system incorporating multicast communication IP transmission.</figref><figref num="8">FIG. 8 is a flow chart of the process of constructing a multicast tree in the communication system.</figref><figref num="9A">FIG. 9A is a flow chart of multicast communication processing of broadcast messages in a wireless communication system.</figref><figref num="9B">FIG. 9B is a signal flow diagram for setting up a data path in a wireless communication system that uses multicast communication IP.</figref><figref num="10">FIG. 10 is a flow chart of multicast communication processing of broadcast messages in a wireless communication system.</figref><figref num="11A">FIG. 11A is a flow chart of multicast communication processing of broadcast messages in a wireless communication system.</figref><figref num="11B">FIG. 11B is a signal flow diagram of broadcasting processing in a wireless communication system using a multicast communication IP.</figref><figref num="12">FIG. 12 is a flow chart of a message flow for a group call service in a wireless communication system topology.</figref>
The term "exemplary" is used exclusively herein to mean "act as an example, instance, or illustration." Any embodiment described herein as "exemplary" is not necessarily construed as preferred or advantageous over other embodiments.
Efficient use of available bandwidth affects the performance and size of the system. To that end, various techniques are applied to reduce the size of the overhead information transmitted with the data or content information. For example, in digital transmission, data is transmitted in frames. The information frame typically includes header information, data payload information and a tail portion. The frame may be part of a packet of data, part of a data message, or a continuous frame within a stream of information such as a voice and / or video stream. Attached to each frame (and each packet or message) of data is a header that contains processing information that allows the receiver to understand the information contained in the frame (s). This header information is regarded as overhead, that is, processing information transmitted together with the information content. Information content is called the payload.
Data frames are transmitted throughout the communication system via various infrastructure elements. In traditional systems, sending information to multiple users requires duplication of information at a central packet data control point, such as a packet data service node (PDSN). The replication increases the processing requirements of the PDSN and wastes valuable bandwidth. For example, the expansion of designated systems may require routers and trunks close to the PDSN to be made large enough to handle replicated traffic. The PDSN sends multiple copies to the base station that transfers the information to each user. The conventional approach is particularly disadvantageous for unidirectional broadcast services where many users are receiving broadcast transmissions. The PDSN in this case must make a significant number of copies, apply a specific address to each copy, and send the copies individually.
It is usually required that the PDSN provide additional header information that identifies each target recipient. For broadcast services, the number of target recipients is exorbitant, causing resource allocation issues and loss of available bandwidth.
An exemplary embodiment of a wireless communication system utilizes a method of data transport that reduces the bandwidth used by infrastructure elements while meeting the accuracy and transmission requirements of the system. In an exemplary embodiment, replication is performed on a BS or Packet Control Function (PCF) node to send a message with a multicast header to each BS or PCF required for broadcasting, PDSN or central packet data. Release the router. For example, a message is processed to a PCF through an MC tree, which replicates the message to each BSC, and then a separate unicast (UC) connection, that is, a connection or secure connection between the PCF and a particular BSC. Send each message through the tunnel. Note that a UC connection may be considered a point-to-point connection. An exemplary embodiment supports a unidirectional broadcast service. Broadcast services provide video streams and / or audio streams to multiple users. Broadcast service subscribers "tune in" to the designated channel to access the broadcast transmission. Due to the high bandwidth requirements for high-speed transmission of video broadcasts, it is desirable to reduce the amount of replication and replication packets transmitted at network hops.
The following description creates an exemplary embodiment by first generally presenting a spectral diffusion radio communication system. Broadcasting services are then introduced, where the services are referred to as High Speed Broadcasting Services (HSBS), the description of which includes channel allocation of exemplary embodiments. Next, a subscription model is presented that includes options for prepaid, free, and hybrid subscription plans similar to the plans currently available for television transmission. The details of accessing the broadcast service are then detailed and present the use of service options to define the details of the designated transmission. Message flow in a broadcast system is described in terms of system topology, or infrastructure elements. Finally, the header compression used in the exemplary embodiments will be described.
Although exemplary embodiments are provided as examples throughout this description, it should be noted that alternative embodiments may incorporate a variety of embodiments without departing from the scope of the invention. Specifically, the present invention can be applied to data processing systems, wireless communication systems, unidirectional broadcasting systems, and any other system that desires efficient transmission of information.
[Wireless communication system] An exemplary embodiment utilizes a spectral diffusion wireless communication system that supports broadcasting services. Wireless communication systems are widely deployed to provide various types of communication such as voice and data. These systems may be based on code division multiple access (CDMA), time division multiple access (TDMA), or some other modulation technique. CDMA systems offer certain advantages over other types of systems, including increased system capacity.
The system is provided by a consortium here named "3rd Generation Partnership Project" called 3GPP, document numbers 3G TS 25.211, 3GTS 25.212, here called W-CDMA Standards. , 3G TS 25.213, and 3G TS 25.214, 3G TS 25.302, a standard integrated into a set of documents, here referred to as the IS-95 standard, "TIA / IS- for dual-mode wideband spectral diffusion cellular systems. 95-B Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System (TIA / EIA / IS-95-B Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System) Standards provided by a consortium named "Mobile Communication Standards Project 2", and formerly IS-2000 It may be designed to support one or more standards, such as TR-45.5, which is referred to here as cdma2000, which was called MC. The standards cited above are thereby explicitly referenced and incorporated herein by reference.
Each standard specifically defines the processing of data for transmission from base stations to mobile stations and vice versa. As an exemplary embodiment, the following description considers a spectral diffusion communication system that is consistent with the cdma200 standard of protocol. Alternative embodiments may incorporate different standards. Still other embodiments may apply the compression methods disclosed herein to other types of data processing systems.
FIG. 1 serves as an example of a communication system 100 that can support many users and realize at least some viewpoints and embodiments of the present invention. Any of a wide variety of algorithms and methods may be used to schedule transmission in System 100. System 100 provides communications to many cells 102A-102G, each of which is serviced by its corresponding base stations 104A-104G. In an exemplary embodiment, some of the base stations 104 have multiple receiving antennas and others have only one receiving antenna. Similarly, some of the base stations 104 have a plurality of transmitting antennas and others have a single transmitting antenna. There are no restrictions on the combination of transmit and receive antennas. Thus, base station 104 may have multiple transmit antennas and a single receive antenna, or may have multiple receive antennas and a single transmit antenna, or both may have a single or multiple transmit antenna and receive antenna. It is possible.
Terminal 106 in the service area may be fixed (ie stationary) or mobile. As illustrated in FIG. 1, the various terminals 106 are distributed throughout the system. Each terminal 106 is arbitrary, depending on, for example, whether soft handoff is utilized, or whether the terminal is designed and operated to receive multiple transmissions (simultaneously or sequentially) from multiple base stations. Communicate with at least one, and perhaps multiple, base stations 104 on the downlink and uplink at the specified moment. Soft handoffs in CDMA communication systems are well known in the art and are transferred to the transferee of the invention "Method and system for providing a Soft Handoff in a". It is explained in detail in US Pat. No. 5,101,501 entitled "CDMA Cellular Telephone System)".
Downlink refers to transmission from the base station to the terminal, and uplink refers to transmission from the terminal to the base station. In an exemplary embodiment, some of terminals 106 have multiple receiving antennas and others have only one receiving antenna. In FIG. 1, base station 104A transmits data to downlink terminals 106A and 106J, base station 104B transmits data to terminals 106B and 106J, base station 104C transmits data to terminals 106C, and so on.
The growing demand for the expansion of services available through wireless data transmission and wireless communication technologies has led to the development of specific data services. One such service is called High Speed Data Rate (HDR). An exemplary HDR service is proposed in the EIA / TIA-IS856 cdma2000 High Rate Packet Data Air Interface Specification, which is called the "HDR Specification". There is. HDR services are typically overlays on voice communication systems that provide an efficient way to send packets of data in wireless communication systems. As the amount and number of data transmitted increases, the limited bandwidth available for wireless transmission becomes a significant resource. Therefore, there is a need for an efficient and equitable method of scheduling transmission in communication systems that optimize the available bandwidth. In an exemplary embodiment, the system 100 depicted in FIG. 1 is consistent with a CDMA system with HDR service.
[High Speed Broadcasting System (HSBS)] A wireless communication system 200 in which video information and audio information are provided to the packet data service node (PDSN) 202 is depicted in FIG. Video and audio information may come from television programming or wireless transmission. The information is provided as packetized data, such as in an IP packet. PDSN202 processes IP packets for distribution within an access network (AN). As depicted, the AN is defined as part of the system that includes the BS204 communicating with multiple MS206s. PDSN202 is bound to BS204. For the HSBS service, the BS204 receives a stream of information from the PDSN202 and provides the information to the subscribers in the system 200 on a designated channel.
There are multiple ways in which HSBS broadcast services can be deployed in a given sector. Factors involved in designing the system include, but are not limited to, the number of HSBS sessions supported, the number of frequency allocations, and the number of physical broadcast channels supported.
HSBS is a stream of information provided on an air interface within a wireless communication system. "HSBS channel" refers to a single logical HSBS broadcast session as defined by the broadcast content. Note that the content of the designated HSBS channel may change over time, for example 7am news, 8am weather, 9am movies, etc. Time-based scheduling is similar to a single television channel. "Broadcast channel" refers to a single forward link physical channel, the designated Walsh code that carries broadcast traffic. The broadcast channel, BCH, corresponds to a single code division multiple access (CDM) channel.
A single broadcast channel can carry one or more HSBS channels. In this case, the HSBS channel will be multiplexed in a time division multiplexing (TDM) fashion within a single broadcast channel. In one embodiment, a single HSBS channel is provided by multiple broadcast channels within a sector. In another embodiment, a single HSBS channel is provided at various frequencies, servicing subscribers at those frequencies.
According to an exemplary embodiment, the system 100 depicted in FIG. 1 supports a high speed multimedia broadcasting service called High Speed Broadcasting Service (HSBS). The broadcast function of the service aims to provide programming at a data rate sufficient to support video and voice communications. As an example, HSBS applications may include video streaming for movies, sporting events, etc. The HSBS service is a packet data service based on the Internet Protocol (IP).
According to an exemplary embodiment, the content server (CS) advertises the availability of such high speed broadcast services to system users. Users who wish to receive HSBS services may subscribe to CS. The subscriber can then scan the broadcast service schedule in a variety of ways that may be provided by CS. For example, broadcast schedules may be communicated through advertising, short management system (SMS) messages, wireless application protocols (WAP) and / or some other means that are generally consistent with mobile radio communications and are convenient for mobile radio communications. .. Mobile users are called mobile stations (MS). The base station (BS) transmits HSBS-related parameters in messages transmitted on the channels and / or frequencies specified for control and information, that is, overhead messages such as non-payload messages. The payload refers to information content of transmission, and in the case of a broadcast session, the payload is broadcast content, that is, a video program or the like. When a broadcast service subscriber wants to receive a broadcast session, that is, a particular scheduled broadcast program, the MS reads the overhead message and learns the proper configuration. The MS then tunes to the frequency including the HSBS channel and receives the broadcast service content.
The channel structure of the exemplary embodiment is consistent with the cdma2000 standard in which forward supplemental channels (F-SCH) support data transmission. One embodiment bundles a number of forward basic channels (F-FCH) or forward dedicated control channels (F-DCCH) to meet the faster data velocity requirements of data services. An exemplary embodiment utilizes F-SCH as the basis for F-BSCH supporting a payload of 64 kbps (excluding RTP overhead). F-BSCH may be modified to support other payload rates, for example by subdividing the 64kbps payload rate into lower speed substreams.
Also, one embodiment supports group calls in a number of different ways. For example, by using the existing unicast channel of F-FCH (or F-DCCH) for both forward and reverse links, that is, one forward link channel per MS that is not shared. Another example is the F-SCH and F-DCCH (no frames but most time forward power control subchannels) on the forward link (shared by group members in the same sector) and the reverse link. The above R-DCCH applies. Yet another example leverages high-speed F-BSCH on forward links and access channels on reverse links (or a combination of enhanced access channels / reverse common control channels).
The forward broadcast supplemental channel (F-BSHC) of the exemplary embodiment, which has a high data rate, uses a very large portion of the base station's forward link power to provide a suitable service area. Good. HSBC's physical layer design is thus focused on improving the efficiency of the broadcast environment.
To provide adequate support for video services, the system design considers not only the corresponding video quality, but also the base station power required for the various methods for transmitting the channel. One aspect of the design is the subjective trade-off between perceived video quality at the edge of the service area and perceived video quality close to cell sites. As the payload rate is reduced, the effective error correction code rate will increase, and the specified level of base station transmit power will provide a better service area at the edge of the cell. For mobile stations closer to the base station, channel reception will remain error-free and video quality will be degraded due to reduced source rates. The same trade-off applies to other non-video applications that F-BSCH can support. As the payload rate supported by the channel decreases, the service area expands at the expense of slower download speeds for these applications. It is objective to balance the relative importance between video quality and data throughput vs. service area. The configuration chosen requires the application to have a special optimized configuration and a good compromise among all possibilities.
The F-BSCH payload rate is an important design parameter. The following assumptions may be used in designing a system that supports broadcast transmission according to exemplary embodiments. That is, (1) the target payload rate is 64 kbps, which provides acceptable video quality, and (2) to stream the video service, the payload rate includes 12 8-bit bytes per packet overhead of the RTP packet. Is assumed. (3) The average overhead of all layers between RTP and the physical layer is about 64 8-bit bytes per packet plus 8 bits per F-SCH frame overhead used by the MUXPDU header.
In an exemplary embodiment, for non-video broadcast services, the maximum speed supported is 64 kbps. However, many other possible payload rates below 64 kbps are also achievable.
[Subscription model] HSBS services have multiple possible subscription / revenue models, including free access, controlled access, and partially controlled access. For free access, no subscription by the is required to receive the service. BS broadcasts the content without encryption, and the mobile phone of interest can receive the content. Revenue for service providers can be generated through advertisements that can also be sent over broadcast channels. For example, you can send an upcoming movie clip that the studio pays to your service provider.
For controlled access, the MS user subscribes to the service and pays the corresponding fee to receive the broadcast service. Unsubscribed users will not be able to receive the HSBS service. Controlled access can be achieved by encrypting the HSBS transmission / content so that only the subscribing user can decrypt the content. This may use a wireless cryptographic key exchange procedure. This method provides strong security and prevents theft of services.
A hybrid access scheme called partial control access provides the HSBS service as a subscription-based service that is encrypted with unencrypted intermittent ad transmission. These advertisements may be intended to encourage subscriptions to encrypted HSBS services. The schedule for these unencrypted segments could be communicated to MS through external means.
[HSBS Service Options] HSBS service options are defined by (1) a protocol stack, (2) options for that protocol stack, and (3) procedures for setting up and synchronizing services. The protocol stack according to the exemplary embodiment is depicted in FIGS. 3 and 4. As depicted in Figure 3, the protocol stack is specific to the infrastructure elements, the MS, BS, PDSN and CS of the exemplary embodiments.
Continuing with Figure 3, for the MS application layer, the protocol specifies not only any visual profile, but also audio and visual codecs. In addition, the protocol also specifies the type of Radio Transport Protocol (RTP) payload when RTP is used. For the MS transport layer, the protocol specifies the User Datagram Protocol (UDP) port. The security layer of the MS is specified by the protocol, and security parameters are provided via the out-of-band channel when security is first associated with CS. The network layer specifies IP header compression parameters. In one embodiment, at the link layer, the data packet is compressed and then the appropriate framing protocol is applied to the compressed data.
[Message flow] Figure 4 depicts the call flow for one embodiment of the specified system topology. The system includes MS, BS, PSN and CS as shown on the horizontal axis. The vertical axis represents time. The user, or MS, is a subscriber to the HSBS service. At time t1, MS and CS negotiate subscription security for broadcast services. Negotiations include the exchange and maintenance of cryptographic keys used to receive broadcast content on broadcast channels. The user establishes a security relationship with CS when receiving encrypted information. The encrypted information may include a broadcast access key (BAK) from CS, a key combination, and the like. According to one embodiment, CS provides encrypted information on a dedicated channel during a packet data session, such as via PPP, WAP or other out-of-band methods.
At time t2, the MS tunes to the broadcast channel and begins receiving packets. At this point, the MS cannot process the received packet because the IP / ESP header is compressed by ROHC and the MS decompressor is not initialized. The PDSN provides header compression information (discussed below) at time t3. From the ROHC packet header, the MS detects and captures ROHC initialization and refresh (IR) packets that are periodically transmitted from the PDSN to the broadcast channel. ROHC The IR packet is used to initialize the decompressor state on the MS, allowing it to decompress the IP / ESP header of the received packet. As a result, the MS can process the IP / ESP header of the received packet, but since the payload is encrypted with the short-term key (SK) in CS, the MS will provide additional information to process the ESP payload. I need. SK works in conjunction with BAK, and SK is decrypted by a receiver that uses BAK. The CS provides key information updated at time t4 or additional encryption information such as the current SK. CS will provide this information to MS on a regular basis to ensure the continued security of the broadcast. At time t5, the MS receives the broadcast content from the CS. Note that alternative embodiments may incorporate alternative compression and decompression methods that enable efficient transmission of header information. Further, the alternative embodiment may implement a wide variety of security methods to protect the broadcast content. Further alternative embodiments may provide insecure broadcast services. MS uses encrypted information such as SK to decrypt and display broadcast content.
[Access network] A typical access network topology for System 300 is depicted in Figure 5 with a CS326, two PDSN320s, 322s, a PCF310, a co-located PCF and a BSC312, and three BSCs 302, 304, 306. CS326 will be combined with PDSN320,322 through IP cloud 324. Not only IP Cloud 314 and 308, but also IP Cloud 324 is basically an interconnected router configuration that forms an IP route from CS to various recipients of data from CS. In IP cloud 308, a virtual tunnel called A8 tunnel is formed to send information from PCF310 to BSC302 and BSC304. The tunnel may be a GRE tunnel. A protocol called A9 is used to establish the A8 tunnel. The IP cloud 308 may be called the A8 / A9 cloud. In IP cloud 314, a virtual tunnel called A10 tunnel is formed to send information from PDSN320 to PCF310 and PCF / BSC312 respectively. Note that the A10 tunnel is formed from PDSN320 to PDF310 and the second A10 tunnel is formed from PDSN320 to PCF / BSC312. The tunnel may be a GRE tunnel. A protocol called A11 is used to establish the A10 tunnel. IP cloud 314 may be called the A10 / A11 cloud. One embodiment is consistent with the embodiments specified in the cdma2000 and HDR standards described above. Access networks (ANs) are defined as connections from elements and PDSNs to end users, such as MS.
According to one embodiment, the broadcast CS326 sends an IP packet containing encrypted broadcast content to a multicast communication group identified by a D-class multicast communication IP address. This address is used in the destination address field of IP packets. The specified PDSN320 participates in the multicast communication routing of these packets. After compression, PDSN320 puts each packet into an HDLC frame for transmission. HDLC frames are encapsulated by generic routing encapsulation (GRE) packets. Note that GRE encapsulation forms the A10 tunnel mentioned above. The key field in the GRE packet header uses a special value to indicate the broadcast bearer connection. A 20-byte IP packet header with a source address field that identifies the IP address of PDSN320 is added to the GRE packet, and the destination address field uses a D-class multicast communication IP address. The multicast IP address is the same as that used by the original IP packet from CS326. Packets delivered over the broadcast connection are provided in sequence. In one embodiment, the GRE ordering function is enabled. Replication of IP multicast communication packets is executed by a router capable of multicast communication. Note that according to an alternative embodiment, IP Cloud 314 provides a point-to-point, or unicast tunnel, to individual recipient PCFs (s). The decision to use a multicast or unicast link for this connection point is made at a higher level, where the UC tunnel provides increased security and the MC tree provides efficiency.
According to an exemplary embodiment, the CS326 sends data to the PDSN320 over the multicast communication address, and the PDSN320 also sends data to the PCF310 and PCF / BSC312 over the multicast communication IP address. PCF310, for example, is in a destination subscription group and asks each of those users for the number of individual users in an active set that duplicates the frames received from CS326. The PDSN PCF310 determines the BSC (s) corresponding to each of the users in the subscription group.
In one embodiment, the BSC 304 is adapted to send to a nearby BSC (s), the BSC 304 replicates the received packets and makes them one or more of the neighboring BSCs (s). You may send to multiple. BSC chain formation results in even better soft handoff performance. The "anchoring" BSC method results in even better soft handoff performance. Sticking BSC304 duplicates the transmission frame and sends it to its neighboring BSCs with the same time stamp. Timestamp information is important for soft handoff operation as mobile stations receive transmission frames from various BSCs.
[Multicast communication service] One type of broadcast service is called a multicast (MC) communication service or "group call (GC)", where the "GC group" contains those users who are participants in the GC, and the group of users is the designated MC. Identified for content. A group of users is sometimes called an MC group. MC content is for MC group members only. Each active user in the MC group registers with AN. The AN then tracks the location of each registered user and targets the transmission of MC messages to these locations. Specifically, AN locates the cell, sector, and / or geographic region where each of the users in the MC group is located, and then the PCF associated with those cells, sectors, and / or geographic region. Send a message to.
In contrast to some other type of broadcast service where BC messages are sent without knowing the location and activity of the recipient or subscriber, the MC service operates using knowledge about active users, especially the location of each active user. To do. In addition, the user provides the AN with location information. In one embodiment, the active user of the MC group registers with the AN via IP communication, specifically by using Internet Group Management Protocol (IGMP) messages. The MC service can locate each user and the MC directs the transmission to those locations, so the MC service leverages a router between the PCF (s) and the PDSN (s). To do. The MC service builds a tree of connections that provides routes from CS to each PCF communicating with active users in the MC group. The tree is called an MC tree. An example of an MC tree is drawn in Figure 6 and will be described later.
In traditional IP networks or systems, such as computer networks that are coupled to the Internet, when a user wants to receive MC-type information called MC content, the user uses Internet Group Management Protocol (IGMP) to reach the nearest router. to register. The router then initiates the MC tree building process by registering with the next adjacent router. The CS then sends the MC content in the form of an MC IP packet. The MC IP packet is then routed through the MC tree to the original router. This router replicates data for each user who wants MC content. A common broadcast medium in a computer network is an Ethernet (registered trademark) hub that connects multiple users to the same information stream.
Combining the Internet and IP networks with wireless communication systems raises some separate issues. One problem is routing information from IP networks through wireless networks. Some of the interconnects are predefined in the wireless system. For example, as mentioned above, the interface between the BSC and the PCF is defined by the A8 / A9 connection. Similarly, the connection from the PCF to the PDSN is defined by the A10 / A11 connection. One embodiment forms an internal MC tree between PDSN and PCF and an external MC tree between PDSN and CS. The PCF then forms a specific tunnel to the various BSCs that require MC content. This embodiment, which will be described later, realizes operational efficiency. Another embodiment forms an external MC tree between PSDN and CS while setting up a tunnel from PSDN to each individual PCF that is supposed to receive MC content. This embodiment provides secure communication.
Generally, the MC path is considered end-to-end, and the MC content oscillates at the source and is sent to the end user. The end user may be MS. Alternatively, the MS may be a mobile router that routes MC content to the network. Note that the MC path may contain several different types of interconnects. For example, one embodiment may incorporate the aforementioned internal MC tree having a termination point in the PCF and an external MC tree having a termination point in the PDSN. Similarly, MC routes may include point-to-point tunnels, where each tunnel is formed between one node and distinct separate nodes.
According to the exemplary embodiment depicted in FIG. 5, communication system 300 includes CS326 communicating with PDSN320 and 322 via IP cloud 324. Note that the CS326 also communicates with other PDSNs not shown. The IP cloud 324 includes a router configuration such as a multicast communication router (as described above) and other routers for passing data transmission through the cloud 324. Transmission through the IP cloud 324 is IP communication. Routers in IP Cloud 324 access communications such as BS and MS messages to target recipients that match the Internet Engineering Task Force (IETF) protocol.
Continuing with Figure 5, PDSN 320 and 322 are communicating with PCF 310 and 312 via another IP cloud 314 as well as other PCFs not shown. IP cloud 314 includes the configuration of routers such as multicast routers and other routers for sending data transmissions through router 314. Transmission through the IP cloud 314 is IP communication. Routers in IP Cloud 314 access communications such as BS and MC messages to target recipients that match the Internet Engineering Task Force (IETF) protocol. In addition, PCF310 communicates with BSC304 via yet another IP cloud 308. IP Cloud 314 includes a configuration of routers such as the Cloud 314 Multicast Router and other routers for passing data transmission through Cloud 314. Routers in IP Cloud 314 provide information such as BSC and MC messages to target recipients that match the Internet Engineering Task Force (IETF) protocol. In addition, PCF310 communicates with BSC304 via yet another IP cloud 308. IP cloud 314 includes the configuration of routers such as multicast routers and other routers for passing data transmission through the cloud. Transmission through the IP cloud 314 is IP communication. The PCF312 also acts as a BSC and is communicating with any of the users in System 300 (not shown). Note that for clarity, specifically three BSCs, BSC 302, 304 and 306, are drawn. System 300 may include any number of additional BSCs (not shown). Note that alternative embodiments may incorporate alternative configurations in which any or connection indicated by multiple IP clouds, such as IP Clouds 308, 314, 324, may be replaced by point-to-point connections. Point-to-point connection is PCF, etc., device and BSC at one point, etc. It may be a secure connection made between different points of. Point-to-point connectivity is achieved on IP clouds such as IP Cloud 308 using a method called tunneling. The basic idea of tunneling is to take an IP packet, encapsulate the packet in the GRE / IP, and send the resulting packet to the destination point. If the destination address in the outer IP header is a unicast IP address, the process achieves a point-to-point tunnel. If the destination address is a multicast IP address, the process achieves a point-to-multipoint tunnel. Note that all of this runs in the same IP cloud. For example, IP Cloud 314 has several different applicable methods. One method forms a point-to-point tunnel and the second method forms a point-to-multipoint tunnel. This is in contrast to the connection method used in cloud 324, where GRE tunneling is not used and the original multicast communication IP packet is transmitted.
In an exemplary embodiment, the CS326 configures an HSBS channel with knowledge of the multicast communication IP addresses used within the IP cloud 324. The CS uses the MC IP address to send HSBS content information called the payload. Note that the configuration in Figure 8 may be used to broadcast a wide variety of BC services.
To form a tunnel, the message is encapsulated in an external IP packet. Since the encapsulated message is sent through the tunnel, the internal IP address, that is, the IP address of the original IP packet, is ignored. Encapsulation modifies the Internet routing of original IP packets. In an exemplary embodiment, the MC tunnel routes BC or MC messages through the MC tree between the PDSN and PCF.
In an exemplary embodiment, PDSN320 and PCF310 and 312 are associated with the MC group. In other words, MC group members are located within cells and / or geographic areas serviced by PCF310 and 312. System 300 builds an external MC tree from CS326 to PDSN320 and an internal tree from PDSN320 to PCF310 and 312. PDSN320 builds an external MC by continuously registering with neighboring multicast communication routers in IP cloud 324. The external MC tree is built from PDSN320 to CS326 through the IP network. The PDSN320 receives MC messages (s) for MC group members via the external MC tree. In other words, MC messages are sent through an external MC tunnel structured by an external MC tree. Each of PCF310 and 312 builds an internal MC tree to PDSN320 through IP cloud 314. MC messages (s) from PDSN320 are sent on the internal MC in the GRE / IP tunnel.
Figure 6 depicts an MC tree 400 with source 402 and multiple routers 404 to 450. Source 402 is the base of MC Tree 400. End users 412, 414, 420, 422, 424, 434 and 450 are considered leaves of MC Tree 400. The two main branches are formed via routers 404 and 406. Above the first major branch is another branch through Router 410. Above the second major branch are two subsequent branches, one through 430 and another through 432.
In one embodiment, the tree 400 has CS as a source. If the broadcast message is a broadcast service generated by CS, the source 402 is CS. In an alternative embodiment, the source may be another device in the network. For example, in the case of a group call service, the message content originates on another user and the BSC associated with that user is the source of the MC tree. In addition, there may be a group call manager function in the network that receives messages from members and forwards messages to group call members through the MC tree. In each of these cases, the tree provides a path for providing the same information content to multiple users while conserving bandwidth and avoiding redundant duplication and processing of information.
FIG. 7 illustrates method 500 for processing BC messages according to one embodiment. Process 500 builds an MC tree between at least one BSC and PCF. The tree may contain multiple BSCs. Similarly, additional trees may be built on additional PCFs. The MC tree forms a route for sending BC messages to multiple recipients without setting up a point-to-point connection. Process 500 also builds an MC tree between at least one PFC and PDSN. The tree may include multiple PCFs and one PDSN, and according to one embodiment, one internal multicast tree may flow through only one PDSN. So there is only one base per tree. In addition, Process 500 builds another MC tree between at least one PSDN and CS. The tree may contain multiple PDSNs.
The broadcasting service of the embodiment depicted in FIG. 7 is broadcasting up to the transmission range of the BS message. In the first step 502, process 500 is in cells (s), sectors (s), and / or geographic areas (s) for the transmission of BC messages. Determine the transmission range. The transmission range information is used to build the MC tree. Specifically, the identification of the transmission range identifies the leaves of the MC tree. The MC tree is built on the base from the leaves. The BSC broadcasts the broadcast indicator to the PCF in step 504. The broadcast indicator is a signaling message that alerts the PCF that the BSC wants to receive the broadcast. The process then establishes a first connection between the transmission range BSC and the associated PCF (s) in step 505. The connection is a GRE safe tunnel between each BSC and PCF pair. The process then builds an MC tree between the PDSN and PCF in step 506. The transmission range identifies the PCF (s) for BC transmission. Each PCF within the transmission range activates the MC tree by registering with a neighboring multicast communication router. According to an exemplary embodiment, the process then builds another MC tree from PDSN (s) to CS in step 508. In step 510, the CS sends a BS message to the PDSN (s) and the BC message is encapsulated in an MC IP packet. The MC IP packet is addressed to the MC IP address and identifies CS as the source of the packet. The MC IP packet address indicates delivery to any of the PDSNs in the MC tree between the PDSN (s) and the CS. In step 512, the BC message crosses the MC tree. The BC message is then sent to the BSC in step 513 over a secure tunnel or UC connection. BSC sends a BC message to users in their respective service areas in step 514.
At this point, to address the soft handoff, the receiving BSC may time stamp the BC message and use it as an anchor BSC to forward it to a neighboring BSC (s). In this way, BC messages are sent from multiple BSCs to one designated user, allowing that user to transition to a better connection without losing transmission. In addition, since the PCF sends BC messages to one BSC, the use of anchor BSCs provides efficiency, but messages may be served to multiple other BSCs.
Figure 8 depicts process 550 building an MC tree from PCF to PDF. At step 552, the PCF registers with the next neighboring multicast communication router. When registered with a multicast communication router, the registration chain is activated and each member of the chain registers with the next consecutive router. To register with a multicast communication router, it is also necessary to recognize the registering PCF as a member of the designated MC group and as the target of any IP packet addressed to the MC IP address of the MC group. Note that for BC messages, the MC group may be considered the target range. If the multicast communication router is registered with the decision diamond 554, the process terminates when the MC tree is complete. If the multicast communication router is not registered, that is, it is not part of the MC tree, the multicast communication router registers with the next consecutive neighboring multicast communication router in step 556.
Figure 9A depicts the flow of BC messages through multiple MC trees, as described in Process 500 in Figures 7 and 8. Figure 9B depicts information, the corresponding signal flow for broadcast message processing. The BC message occurs on the CS326, as depicted in Figure 9A. The original message is considered the payload. The CS326 encapsulates the payload by applying the MC IP to generate the MC IP packet. The MCIP packet indicates that CS is the source of the packet and the destination is specified as the MC IP address. The MC IP packet is sent to the next contact on the tree. In other words, MC IP packets traverse outward from the source or base of the tree towards the leaves. For clarity, a single PDSN, specifically PDSN320, is drawn, but each MC tree is an MC. It may contain any number of PDSNs identified by IP address. The PDSN320, and any other PDSN in the MC tree, compresses MCIP packets and applies framing protocols such as HDLC to form compressed framing packets (CFPs). The CFP is then encapsulated by the GRE protocol to form a GRE packet. The resulting GRE packet is further encapsulated according to the MC IP, resulting in an MC CFP, a multicast compressed frame packet. MC CFP identifies the PDSN320 as the source and the MC IP address as the destination. In the example depicted in Figure 9A, the PDSN320 passes the MC CFP to the parts of the MC tree, PCF310 and 312. Each of the PCF310 and 312 processes the received MC and forms a secure tunnel to the BSC (s) to the BSC304, etc., and the resulting packet is sourced from each PCF and has a BSCIP address. UC to identify as destination It is a BSC packet. Note that each PCF may form multiple tunnels to individual BSCs. As depicted, the MCIP addressing is used until the message reaches the PCF. From the PCF to the end user, this embodiment uses a secure tunnel or UC connection.
Figure 9B depicts the corresponding signal flow, and CS initially sets up the HSBS channel. At time t1, a GRE tunnel is set up between the BSC and the PCF. At time t2, the PCF uses IGMP to register with a neighboring multicast router. At time t3, the PCF confirms the GRE tunnel set up with the BSC. At time t4, the MC Routing Protocol (MRP) is used to register the multicast communication router between the PCF and PDSN. At time t5, the PDSN registers with a neighboring multicast communication router. The process forms the outside of the MC tree. Each of the levels of the MC tree, CS to PDSN, and PDSN to PCF, may be considered as individual MC trees, or the overall structure from CS to PCF may be considered as one tree. At this point, the BSC is set up to receive BC messages from BC CS over MC IP for the designated HSBS channel.
Figure 10 depicts an alternative embodiment of Process 700 sending a BC message. The process begins by determining the broadcast transmission range in step 702. At step 704, a UC connection is set up between the BSC and the PCF. The UC connection may be an A8 / A9 IP connection. Similarly, step 706 sets up a UC connection between the PCF and PDSN. In contrast to process 500 in Figure 10, no MC tree is built between the PDSN (s) and the PCF (s). Rather, a point-to-point GRE tunnel is formed between each PDSN and PCF pair. The PDSN to PCF UC connection may be an A10 / A11 IP connection. An MC tree is built in 708 between CS and PDSN.
The CS then sends the data to the PDSN (s) that are part of the MC tree in step 709. The data is moved to the PDSN through the MC tree in step 710. The PDSN then processes the received data or BC message and forwards the BC message to the PCF in step 712. Note that when multiple PCFs are implemented, the PDSN will make multiple copies of the data for transmission to multiple PCFs. The PCF sends data to the BSC over the UC connection in step 714. The data or BC message is then sent from the BSC associated with the MC group to the group members in step 716.
Figure 11A depicts the flow of BC messages through multiple MC trees as described in Process 700 in Figure 10. Figure 11B depicts the corresponding signal flow of information, that is, broadcast message processing. In contrast to process 500 in Figure 7, process 700 builds an MC tree between CS and PDSN (s), but PCF (s) and individual BSCs (s). Incorporate point-to-point safety tunnels not only between) but also between PDSN (s) and PCF (s). Users with point-to-point connections offer additional security at the expense of processing and bandwidth considerations.
The BC message occurs on the CS326, as depicted in Figure 11A. The original message is considered the payload. The CS326 encapsulates the payload by applying MC IP and generating MC IP packets. The MC IP packet indicates that CS is the source of the packet and the destination is specified as the MC IP address. The MC IP packet is sent to the next contact on the tree. In other words, MC IP packets traverse the tree outward from the source or base of the tree towards the leaves. For clarity, a single PDSN, specifically the PDSN320, is drawn, but the MC tree may contain any number of PDSNs, each identified by an MC IP address. The PDSN and any other PDSN in the MC tree compress the MC IP packet and apply a framing protocol such as HDLC to form a compressed frame packet (CFP). The CFP is then encapsulated by the GRE protocol to form a GRE packet. The resulting GRE packet is further encapsulated according to the unicast (UC) IP and UC Produces CFP, or unicast compressed frame packets. UCCFP identifies PDSN320 as the source and a specific PCF as the destination. In the example depicted in Figure 11A, the PDSN 320 passes the UC CFP to the PCF 310 and 312. Each of PCF310 and 312 processes UCCFP received in a manner similar to PDSN320, and the resulting packet is a UC BSC packet that identifies each PCF as the source and the BSC as the destination.
Figure 11B depicts the corresponding signal flow in which CS initially sets up the HSBS channel. At time t1, the BSC sets up a GRE tunnel between the BSC and the PCF. At time t2, the PCF PCF sets up a GRE tunnel between the PCF and the PDSN. At time t3, the PDSN confirms the GRE tunnel set up with the PCF. At time t4, the PCF confirms the GRE tunnel set up with the BSC. At time t5, the PDSN joins the multicast communication group using IGMP or MRP. Note that the initial processing may implement IGMP to the first router. The process forms an MC tree between CS and PDSN. In this regard, BSC is set up to receive BC messages over MC IP from BC CS for the designated HSBS channel.
According to one embodiment, for BC service processing, CS uses the MC IP address to send HSBS content. The HSBS configuration gives rise to a CS that sends HSBS content to the corresponding MC group. The content is sent in the form of an IP packet with a destination IP address as the CS source IP address and MC IP address.
The BSC then decides to add an HSBS channel on the designated broadcast channel. Broadcast channels must be transmitted on a set of cells / sectors. The mechanism within BSC for adding HSBS channels to broadcast channels is specific to implementation. An example of such a mechanism is an interface that enables HSBS channel configuration on the BSC, such as an operation processing & management (OA & M) interface. The BSC uses a local mechanism to set up the HSBS channel with information such as the HSBS_ID of the HSBS channel and the MC IP address corresponding to the HSBS content.
BSC sends an A9-SETUP-A8 message to the PCF. In the A9-SETUP-A8 message, the BSC sends an A8_Traffic_ID parameter that contains the IP address of the BSC entity that terminates the A-8 connection, especially for GRE cases and HSBS channels. An additional field, IP_MulticastAddress, is added to the A8_Traffic_ID parameter. An additional field identifies the IP multicast communication address used by CS to send HSBS content. New service options for the HSBS service are used in A9-Setup-A8 messages.
When the PCF receives the A9-Setup-A8 message from the BSC, it is warned that the BSC wants to join the IP multicast communication group. If the PCF is already a member of the desired multicast communication group, no additional action may be required to join the multicast communication group. Otherwise, the PCF sends an IGMP request to the multicast communication router to join the multicast communication group. If the IGMP setup is successful, the PCF sends back an A9-Connect-A8 message to the BSC. Multicast communication route information propagates from the multicast communication router using the multicast communication routing protocol to the upstream router all the way to CS through PDSN. This sets up a multicast communication path or tree from CS to PCF. The PCF achieves GRE A8-key, BSC IP address, and IP multicast address coupling and properly tunnels IP multicast communication packets to the BSC.
There are multiple multicast communication routing protocols used for multicast communication routing in an IP environment. The Distance Vector Multicast Routing Protocol (DVMRP) was specified in RFC 1075 by D. Waitzman, C. Partridge, and SE Deering on November 1, 1988. Protocol-specific multicast sparse mode (PIM-SM) was introduced in June 1998 by D.Estrin, D.Farinacci, A.Helmy, D.Thaler, S.Deering, M.Handley, V.Jacobson, C.Liu, P. Specified in RFC 2362 by .Sharma, L. Wei. There is also Multicast Open Shortest Path First (MOSPF) specified in RFC 1584 by J. Moy in March 1994 entitled "Multicast Extensions to OSPF".
Continuing with Figure 11B, the GRE connection is set up from the BSC to the PCF and a GRE tunnel setup message is sent as depicted at time t1 in Figure 11B. In the GRE setup message, the BSC sends a Traffic_ID parameter containing the GRE key and an IP addressless for the BSC entity that terminates the HSBS channel connection. IP_MulticastAddress is added to the Traffic_ID parameter. The Traffic_ID parameter may contain a wide variety of other information. IC_MulticastAddress identifies the IP MS address used by CS to send HSBS content.
During operation, CS sends HSBS content, such as BS messages, to the MC IP address. The MC IP address is used in the destination address field of the IP packet. The multicast communication router forwards the packet to the member PDSN (s). Note that multicast communication group membership is established early using IGMP and MC routing protocols. After header compression (if it is done), PDSN stores each packet in an HDLC frame. HDLC frames are encapsulated within GRE / IP packets. The PDSN sets the key field of the GRE packet to the destination MC IP address of the encapsulated IP packet. The GRE packet has the source address field of the PDSN IP address and the same MC as the encapsulated packet. A 20-byte IP packet header with a destination address field for the IP address is added. The PDSN sends the encapsulated HDLC frame to the member multicast communication router (s). All multicast communication member PCFs receive MC packets. The ordering need is for header compression within the PDSN. The GRE contains a sequence number that identifies the packet. The GRE sequence number guarantees in-order delivery of packets.
Multiple BSCs may be used to broadcast the same HSBS channel to cover a particular geographic area. In this case, the HSBS channel is associated with a particular frequency. To facilitate autonomous soft handoff, the transmission of the basic broadcast service channel, F-BSCH, is synchronized within the geographic region. This makes it possible for mobile stations to synthesize broadcast packets. According to one embodiment, the MC tree contains a leaf called an "anchor BSC" that replicates broadcast content to a secondary BSC. The anchor BSC duplicates the HDLC frame and sends it to any secondary BSC (s) on a particular interface, with unnatural delays in transmission to the secondary BSC (s). is there.
Figure 12 illustrates how to process a C message transmitted to an MMC group. The process is for group call services and the broadcast message may be generated by a user in the system. Group calls allow users to provide point-to-multipoint transmission. One user in the group sends a message for multiple intended recipients. Process 600 begins at step 602, where CS determines the start time of the MC message. MC group subscribers join BSC in step 604. In step 605, the BSC sends a setup message to the PCF. The setup message alerts the PCF that the BSC is part of the group call, while invoking the formation of a GRE tunnel between the BSC and the PCF. The process builds an MC tree between the PDSN and the PCF (s) in step 606. The process then builds an internal MC tree from PDSN to CS in step 608. Once the MC tree is set up, the source is MC in step 610 Send an MC message addressed to the IP address. The message moves through the tree in step 612. The PCF sends an MC message to the BSC over the UC connection in step 614. The BSC then forwards the MC message to the group members in the corresponding geographic area in step 616.
Note that for MC messages sent to an MC group, group members move within the communication system. If a group member is not registered in the MC tree or moves to a location where there is no partial picture of MC message transmission, the group member registers with the BSC in the new location. During a group call, group members will monitor the frequency assigned to the BC channel used for the group call. By registering with the new BSC, group members provide the system with BC frequencies. The system can then page the group members of the incoming call. Once a group member registers with a new BSC, the system creates a new MC tree containing the new BSC.
The alternative embodiment may apply the method described above to an alternative BC service in which point-to-multipoint transmission is used. Using an MC tree formed of leaves or termination points that register with contiguous routers provides a convenient and dynamic way to avoid redundancy within the communication system. In addition, the MC tree provides enhanced scalability that reduces the amount of infrastructure required to grow the network.
Those skilled in the art will appreciate that information and signals may be expressed using any of a wide variety of different techniques and techniques. For example, data, instructions, commands, information, signals, bits, symbols and chips that may be referred to throughout the description may be voltage, current, electromagnetic waves, magnetic fields, or magnetic particles, optical fields or particles, or any combination thereof. May be represented.
Those skilled in the art will further understand that various exemplary logic blocks, modules, circuits and algorithm steps in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software or a combination of both. will do. To articulate this compatibility of hardware and software, various exemplary components, blocks, modules, circuits and steps have generally been described above in terms of their functionality. Whether such functionality is realized as hardware or software depends on the design constraints imposed on the specific application and the overall system. One of ordinary skill in the art may realize the functionality described in various respects for each particular application, but such implementation decisions should not be construed as causing a deviation from the scope of the invention. ..
The various exemplary logic blocks, modules and circuits described in connection with the embodiments disclosed herein include general purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), and field programmable gates. It may be implemented or performed in an array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. .. The general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microprocessor, or state machine. The processor may be implemented as a combination of DSP and microprocessor, multiple microprocessors, one or more microprocessors working with a DSP core, or any other combination of computing devices such as such configurations. ..
The steps of the methods or algorithms described in connection with the embodiments disclosed herein may be embodied directly in hardware, in software modules executed by a processor, or in combination of the two. The software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disks, removable disks, CD-ROMs, or any other type of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write the information to the storage medium. Alternatively, the storage medium may be integrated with the processor. The processor and storage medium may reside in the ASIC. The ASIC may reside on the user terminal. Alternatively, the processor and storage medium may reside as separate components within the user terminal.
The above description of the disclosed embodiments is provided to allow one of ordinary skill in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles set forth herein may be applied to other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not intended to be limited to the embodiments presented herein, but should be given the broadest scope consistent with the principles and novel features disclosed herein.
15 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15
Every citation, both waysCites: the store holds 3 of 4
| Document | Relation | Office | Cited during |
|---|---|---|---|
| WO0150783A2 | Cites | World Intellectual Property Organization (WIPO) | Examiner |
| WO0156232A2 | Cites | World Intellectual Property Organization (WIPO) | Examiner |
| JP2001177564A | Cites | Japan | Examiner |
| JPN6012058224; 朝香 卓也 他: '決め打ち探索を用いた動的マルチキャストルーチングアルゴリズム' 電子通信学会技術研究報告(信学技報) SSE95-56 IN99-37 CS99-78 , 19990927 | Non-patent | – | Examiner |
| JPN6012058225; 宮崎 俊明 他: 'IP unicast addressを用いたマルチキャスト方式の提案' 電子通信学会技術研究報告(信学技報) IN2001-9 , 20010521 | Non-patent | – | Examiner |
| CSNG200100061003; 朝香 卓也 他: '決め打ち探索を用いた動的マルチキャストルーチングアルゴリズム' 電子通信学会技術研究報告(信学技報) SSE95-56 IN99-37 CS99-78 , 19990927 | Non-patent | – | Examiner |
| CSNG200300222008; 宮崎 俊明 他: 'IP unicast addressを用いたマルチキャスト方式の提案' 電子通信学会技術研究報告(信学技報) IN2001-9 , 20010521 | Non-patent | – | Examiner |
67 members in 17 offices
Priority claims5
| Document | Office | Kind | Date |
|---|---|---|---|
| 09970487 | United States of America | – | |
| 97048701 | United States of America | A | |
| 97048701 | United States of America | A | |
| 2001970487 | – | – | – |
| US20010970487 | – | – | – |
Members67
| Document | Office | Kind | |
|---|---|---|---|
| US2003063591A1 | United States of America | A1 | |
| CA2462526A1 | Canada | A1 | |
| CA2738582A1 | Canada | A1 | |
| WO03030453A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO03030460A2 | World Intellectual Property Organization (WIPO) | A2 | |
| US2003087653A1 | United States of America | A1 | |
| WO03030460A3 | World Intellectual Property Organization (WIPO) | A3 | |
| WO03030453A3 | World Intellectual Property Organization (WIPO) | A3 | |
| NO20041905D0 | Norway | D0 | |
| KR20040037233A | Republic of Korea | A | |
| KR20040037237A | Republic of Korea | A | |
| NO20041905L | Norway | L | |
| EP1435150A2 | European Patent Office (EPO) | A2 | |
| EP1435151A2 | European Patent Office (EPO) | A2 | |
| MXPA04003141A | Mexico | A | |
| IL161128A0 | Israel | A0 | |
| TWI223532B | Taiwan Province of China | B | |
| CN1593037A | China | A | |
| CN1596524A | China | A | |
| EP1542395A1 | European Patent Office (EPO) | A1 | |
| HK1073027A1 | Hong Kong, China | A1 | |
| RU2004113555A | Russian Federation | A | |
| JP2005534202A | Japan | A | |
| JP2005536902A | Japan | A | |
| TWI268075B | Taiwan Province of China | B | |
| US7184789B2 | United States of America | B2 | |
| CN101005457A | China | A | |
| CN101013952A | China | A | |
| EP1871044A2 | European Patent Office (EPO) | A2 | |
| EP1871044A3 | European Patent Office (EPO) | A3 | |
| BR0213087A | Brazil | A | |
| JP2008148350A | Japan | A | |
| JP2008211793A | Japan | A | |
| JP2008312218A | Japan | A | |
| JP2009010961A | Japan | A | |
| KR20090121409A | Republic of Korea | A | |
| CN100581110C | China | C | |
| US7697523B2 | United States of America | B2 | |
| KR100956040B1 | Republic of Korea | B1 | |
| KR100956041B1 | Republic of Korea | B1 | |
| US2010142432A1 | United States of America | A1 | |
| CN101789873A | China | A | |
| EP2262168A2 | European Patent Office (EPO) | A2 | |
| EP1435150B1 | European Patent Office (EPO) | B1 | |
| AT492957T | Austria | T | |
| ATE492957T1 | Austria | T1 | |
| DE60238698D1 | Germany | D1 | |
| KR101019400B1 | Republic of Korea | B1 | |
| ES2358500T3 | Spain | T3 | |
| CA2462526C | Canada | C | |
| IL202855A0 | Israel | A0 | |
| CN101005457B | China | B | |
| EP2262168A3 | European Patent Office (EPO) | A3 | |
| JP2012124944A | Japan | A | |
| JP2012130059AThis record | Japan | A | |
| JP2012142963A | Japan | A | |
| JP5006275B2 | Japan | B2 | |
| JP5107746B2 | Japan | B2 | |
| CN101789873B | China | B | |
| JP5160912B2 | Japan | B2 | |
| JP5199491B2 | Japan | B2 | |
| JP5199492B2 | Japan | B2 | |
| JP2014003667A | Japan | A | |
| CA2738582C | Canada | C | |
| JP5677995B2 | Japan | B2 | |
| JP5788441B2 | Japan | B2 | |
| EP1542395B1 | European Patent Office (EPO) | B1 |
19 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of completion of termEXPY | EXPY | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Re-examination (zenchi) completed and case transferred to appeal boardAppealJAPANESE INTERMEDIATE CODE: A912A912 | A912 | |
| Transfer to examiner for re-examination before appeal (zenchi)AppealJAPANESE INTERMEDIATE CODE: A911A911 | A911 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Decision of refusalJAPANESE INTERMEDIATE CODE: A02A02 | A02 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 2012130059
- Publication, DOCDB
- 2012130059
- Publication, EPODOC
- JP2012130059
- Application
- 33898
- Application, DOCDB
- 2012033898
- Application, EPODOC
- JP20120033898
Titles2
- Japanese
- インターネットプロトコル(IP)を使用する無線通信システム内でのデータパケットトランスポートのための方法および装置
- English
- Methods and equipment for data packet transport within wireless communication systems that use the Internet Protocol (IP)
Classification
- CPC, 16
- H04W76/40
- H04L12/18
- H04L12/1886
- H04L12/189
- H04L12/4633
- H04L45/16
- H04L47/15
- H04L47/806
- H04L47/824
- H04L47/825
- H04W4/06
- H04W80/00
- H04L2212/00
- H04L47/70
- H04L47/10
- H04W8/04
- IPC, 6
- H04W4 06
- H04W80 04
- H04L12 56
- H04L12 18
- H04L45 16
- H04W80 00