WO2009021442A1 - Procédé et système pour maintenir la communication de schéma de compression d'en-tête robuste en continu - Google Patents

Procédé et système pour maintenir la communication de schéma de compression d'en-tête robuste en continu Download PDF

Info

Publication number
WO2009021442A1
WO2009021442A1 PCT/CN2008/071921 CN2008071921W WO2009021442A1 WO 2009021442 A1 WO2009021442 A1 WO 2009021442A1 CN 2008071921 W CN2008071921 W CN 2008071921W WO 2009021442 A1 WO2009021442 A1 WO 2009021442A1
Authority
WO
WIPO (PCT)
Prior art keywords
rohc
target
r0hc
function entity
asn
Prior art date
Application number
PCT/CN2008/071921
Other languages
English (en)
Chinese (zh)
Inventor
Chengyan Feng
Wenliang Liang
David Xiang
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2009021442A1 publication Critical patent/WO2009021442A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/08—Reselecting an access point

Definitions

  • the present invention relates to the field of communication technologies, and in particular, to a method and system for maintaining a robust Robust Header Compression (ROHC) communication continuity in a wireless network.
  • ROHC Robust Header Compression
  • the wireless link Due to physical conditions, the wireless link has a lower transmission rate and a higher bit error rate than the wired link.
  • IP technology is applied in a wireless cell environment, there is a problem that the packet header overhead is excessive.
  • the packet payload that the user really needs is often only 22% of the entire packet. This not only wastes bandwidth, but also increases the probability that packets will be discarded due to errors. If effective measures are not taken, the quality of service (QoS) will be reduced while wasting valuable wireless network resources.
  • QoS quality of service
  • ROHC can solve the above problems while also ensuring the inherent flexibility of the IP protocol.
  • R0HC is a stream-based header compression scheme. In the process of network data transmission, most of the header fields of the same stream have the same domain value. The ROHC takes a reference packet in a certain stream, and only transmits information about the change of the reference packet in the header field for other packets to achieve the purpose of compression, thereby making more efficient use of the bandwidth. At the same time, ROHC also makes the header compression mechanism highly efficient and reasonable robust by controlling the frequency and quantity of feedback messages, detecting strict logic of different steps, and error checking. In this way, ROHC provides a header compression mechanism suitable for high bit error rate and long latency links.
  • ROHC defines a compressor (Compressor) and a decompressor (DeCompressor), each with three states.
  • the three states of the compressor are: Initialization and Refresh (IR), the first normal state (Fir st Order, FO) and the second normal state (Second Order, SO); the three states of the decompressor are : No Context ( NC ), Static Context (SC ) and Full Context (FC ).
  • the ROHC based feedback form is also divided into three modes: one-way mode (U_mode), two-way reliable mode (R-mode), and bidirectional optimization mode (0-mode).
  • U_mode one-way mode
  • R-mode two-way reliable mode
  • 0-mode bidirectional optimization mode
  • Communication in one-way mode is one-way, compressor-like State transitions are not dependent on feedback; negative feedback is mandatory in bidirectional optimization mode; both positive and negative feedback are mandatory in bidirectional reliable mode.
  • ROHC defines different prof i le according to different service flow types.
  • the compression fields of each prof le le may be different, the packets sent are different, and the feedback is different; but the compressor and decompressor have the same three.
  • the state, the transition between states has a similar mechanism, and is divided into three modes according to the feedback form.
  • ROHC also defines the conversion process and trigger conditions between the three modes. The transition between modes is initiated by the decompressor.
  • ROHC Context The basis for the compressor and decompressor in the header compression and decompression process.
  • the ROHC context contains the header information of the previous packet in the data stream.
  • ROHC channel (ROHC channe l): A logical channel.
  • the entry is a compressor
  • the exit is a decompressor
  • the compressor and the decompressor are in one-to-one correspondence.
  • the compressor compresses the original data and sends it to the decompressor through the logical channel.
  • ROHC feedback channe l In order to support bidirectional compression, the decompressor must be able to provide feedback to the compressor.
  • the ROHC feedback channel is the logical channel carrying this feedback information.
  • the ingress is the decompressor of the corresponding ROHC channel, and the egress is the compression of the corresponding ROHC channel.
  • the ROHC channel parameters include a maximum context identifier (MAX_CID), a length and length attribute of the context identifier (LARGE-CIDS), a format type set (PROFILES) of the data stream for which header compression is directed, FEEDBACK-FOR, and a maximum reconstruction receiving unit (MRRU).
  • MAX_CID maximum context identifier
  • LARGE-CIDS length and length attribute of the context identifier
  • PROFILES format type set
  • FEEDBACK-FOR FEEDBACK-FOR
  • MRRU maximum reconstruction receiving unit
  • the ROHC compression mechanism can be used for header compression.
  • the ROHC execution function entity migrates, for example, when the terminal performs ASN handover, R3 (reference interface 3) migration, or the terminal exits the idle mode process in the WiMAX network, the ROHC execution function entity serving the terminal may occur. Change, terminal and network side ROHC channel parameters The number may change, and ROHC communication cannot continue.
  • the ROHC execution function entity migration refers to the change of the ROHC execution function entity that provides services to the terminal. Therefore, how to maintain ROHC communication continuity is a problem that needs to be solved.
  • a method for maintaining robust header compression communication continuity provided by an embodiment of the present invention can be implemented as follows:
  • the target ROHC performs a function of the ROHC channel parameter sent by the functional entity receiving source ROHC to perform the functional entity;
  • a method for maintaining robust header compression communication continuity provided by an embodiment of the present invention can be implemented as follows:
  • the target ROHC execution function entity receives the ROHC channel parameter sent by the source ROHC execution function entity;
  • the target ROHC performs the function entity to re-negotiate the ROHC channel parameter with the terminal; the target ROHC execution function entity utilizes the renegotiation ROHC channel parameters for ROHC operating.
  • a communication system provided by the present invention includes:
  • the source ROHC performs a function entity, and is configured to send the ROHC channel parameter to the target ROHC execution function entity during the migration process;
  • the target ROHC performs a function entity, and after the migration is completed, if the ROHC channel parameters of the migrated terminal and the network side are unchanged, the ROHC channel parameter is used to provide the terminal and the network side with the ROHC operation.
  • the source ROHC performs a function entity, and is configured to send the ROHC channel parameter to the target ROHC execution function entity during the migration process;
  • the target ROHC performs the function entity. After the migration is completed, if the ROHC channel parameter between the migrated terminal and the network side changes, the ROHC channel parameter negotiated by the terminal and the network side is used for ROHC operation.
  • the source ROHC performs a function entity, and is configured to: pass the ROHC channel parameter to the anchor paging controller for saving before the terminal enters the idle mode;
  • the target ROHC performs a function entity for obtaining the ROHC channel parameter from the anchor paging controller when the terminal exits the idle mode.
  • the ROHC channel parameter in the source ROHC execution function entity is sent to the target ROHC execution function entity during the ROHC execution function entity migration process; after the migration is completed, if the ROHC channel parameters of the terminal and the network side do not change And the terminal and the target ROHC execution function entity continue to perform the ROHC operation by using the ROHC channel parameter; if the ROHC channel parameter between the terminal and the network side changes, the terminal and the network side perform ROHC channel parameter renegotiation, and The ROHC operation is performed using the ROHC channel parameters after renegotiation.
  • the application of the embodiment of the present invention can enable the MS to maintain the ROHC communication during the migration process, such as ASN handover, R3 migration, and exiting the idle mode.
  • Figure 1 shows the Wimax network reference model
  • FIG. 2 is a schematic flowchart of a method for implementing continuous R0HC communication according to an embodiment of the present invention
  • FIG. 3 is a schematic flowchart of transmitting a R0HC channel parameter and a R0HC context in a handover preparation phase according to an embodiment of the present invention
  • FIG. 4 is a schematic flowchart of transmitting a R0HC channel parameter and a R0HC context in a successful handover execution phase according to an embodiment of the present invention
  • FIG. 5 is a schematic flowchart of a R0HC channel parameter and a R0HC context in a successful uncontrolled handover process according to an embodiment of the present invention
  • FIG. 6 is a schematic flowchart of transmitting R0HC channel parameters and R0HC context in a R3 migration process of PMIPv4 no-re-authentication according to an embodiment of the present invention
  • FIG. 7 is a schematic flowchart of the process of transmitting R0HC channel parameters and R0HC context in the R3 migration process of the PMIPv4 authenticator & PMIP client redirection according to an embodiment of the present invention
  • FIG. 8 is a schematic flowchart of transmitting R0HC channel parameters and R0HC contexts in a CMIPv4 R3 migration process according to an embodiment of the present invention
  • FIG. 9 is a schematic flowchart of a process of transmitting a R0HC channel parameter and a R0HC context in a CMIPv6 R3 migration process according to an embodiment of the present invention.
  • FIG. 10 is a schematic flowchart of transmitting R0HC channel parameters and R0HC context in an idle mode entry process initiated by a terminal according to an embodiment of the present invention
  • FIG. 11 is a schematic flowchart of a R0HC channel parameter and a R0HC context in an idle mode entry procedure initiated by a network side according to an embodiment of the present invention
  • FIG. 12 is a schematic flowchart of a process of transmitting a R0HC channel parameter and a R0HC context when a terminal exits an idle mode entry process according to an embodiment of the present invention
  • FIG. 13 is a schematic flowchart of the R0HC channel parameter and the R0HC context transmitted by the anchor PC in the paging process according to an embodiment of the present invention
  • FIG. 14 is a schematic diagram showing the structure of a communication system according to an embodiment of the present invention
  • FIG. 15 is a schematic diagram showing the structure of a communication system according to an embodiment of the present invention.
  • WiMAX Worldwide Interoperability for Microwave Access
  • WiMAX is based on the industry's wireless metropolitan area network access technology based on the IEEE 802.16 series of standards. The basic goal is to provide a point-to-multipoint network in the metropolitan area network. Broadband wireless access means that can interoperate effectively in a vendor environment.
  • the air interface part protocol layer of the WiMAX system mainly includes a physical layer (PHY) and a media access control (MAC) layer.
  • the PHY layer physically performs modulation, demodulation, and codec operations on the signal
  • the MAC layer mainly implements the media access control function of the WiMAX system.
  • FIG. 1 shows the WiMAX end-to-end reference model.
  • the R1 interface is a wireless air interface.
  • the remaining interfaces are all wired interfaces.
  • WiMAX mainly includes a mobile station (MS)/subscriber station (Substation Station, SS), an Access Service Network (ASN), and a Connectivity Service Network (CSN).
  • MS mobile station
  • ASN Access Service Network
  • CSN Connectivity Service Network
  • the ASN provides a set of network functions for wireless access services for WiMAX user terminals.
  • the ASN includes BS and ASN gateways, and one ASN may be shared by multiple CSNs.
  • the main functions of the ASN include the functions of the BS and the functions of the ASN gateway.
  • the functions of the BS are: providing L2 connection between the BS and the subscriber station SS/MS, radio resource management, measurement and power control, and compression and encryption of air interface data.
  • the functions of the ASN gateway include: proxy function for SS/MS authentication, authorization and accounting functions; network discovery and selection for network service provider (NSP); relay function for providing L3 information for SS , such as IP address allocation.
  • the CSN provides an IP connection service for WiMAX user terminals.
  • CSN mainly provides the following functions: SS/MS ⁇ IP address is divided into West, Internet access, Ma Quan card, 4 authorized, Accounting (AAA) proxy or service (server), user-based authorization Control, ASN to CSN tunnel, WiMAX subscriber billing and inter-operator settlement, roaming In the case of tunneling between CSNs, switching between ASNs, and various WiMAX services, such as location-based services, multimedia multicast and broadcast services, and IP multimedia subsystem services.
  • ROHC compression can be used for header compression.
  • the ROHC execution function entity migration may occur in the WiMAX network, that is, the ROHC execution function entity serving the terminal changes, and the ROHC execution function entity migration process may occur during the ASN handover process and the R3 migration process of the terminal.
  • the ROHC execution function entity for the terminal service before the migration is referred to as the source ROHC execution function entity
  • the ROHC execution function entity for the terminal service after the migration is referred to as the target ROHC execution function entity.
  • the ROHC execution function entity for the terminal service may be different.
  • the ROHC execution function entity serving the terminal service before the migration before entering the idle mode is referred to as a source.
  • the ROHC performs a functional entity.
  • the ROHC performing function for the terminal is called a target ROHC execution function entity.
  • the ROHC execution function entity may be a compressor type ROHC execution function entity or a decompressor type ROHC execution function entity.
  • the ROHC channel parameter in the source ROHC execution function entity is sent to the target ROHC execution function entity during the migration process; if the ROHC channel parameter of the terminal and the network side does not change after the migration is completed, The terminal and the target ROHC execution function entity continue the ROHC operation using the ROHC channel parameters.
  • the target ROHC execution function entity performs ROHC operation by using the renegotiated ROHC channel parameter.
  • the ROHC channel parameter in the source ROHC execution function entity is transferred to the anchor paging controller before the terminal exits the idle mode. And when the terminal exits the idle mode, transmitting the ROHC channel parameter in the anchor paging controller to the target ROHC execution function entity.
  • the ROHC channel parameters include the type of ROHC channel and the attributes of the ROHC channel, ie, which service flows (SF) have been ROHC, or which service types of traffic have been R0HC.
  • the existing message can be used to transmit the ROHC channel.
  • the parameters can also be used to transmit ROHC channel parameters with newly defined independent messages.
  • the target ROHC Before performing the migration process or the idle state of the terminal, it is necessary to determine the target ROHC to perform the functional entity according to the source ASN and the ROHC capability of one or more potential ASNs, that is, select the target ROHC to execute the functional entity. Depending on the decision entity, the way in which the target ROHC performs the functional entity can be selected to include a variety of situations.
  • the process of selecting the target ROHC to perform the functional entity may be implemented as follows: When the source ROHC performing functional entity is located in the base station or gateway of the source ASN, the ROHC channel parameter in the source ROHC performing functional entity may be sent to more than one potential target ROHC.
  • the source ROHC performing functional entity receives ROHC support capabilities and/or ROHC channel parameters of the one or more potential target ROHC performing functional entities, and deciding one of the ROHC execution functional entities of the one or more potential targets Performing a functional entity as a target ROHC; or, by performing ROHC support capabilities and/or ROHC channel parameters of the functional entity to the one or more potential target ROHCs, selecting more than one target from the one or more potential target ROHC execution functional entities
  • the ROHC execution function entity executes the function entity as the candidate target ROHC, and then the terminal selects one of the candidate target ROHC execution function entities as the target ROHC execution function entity.
  • the ROHC channel parameter in the source ROHC execution function entity may be sent to more than one target ROHC execution function entity in a handover preparation phase; the ROHC support capability and/or ROHC channel parameter is sent to the source ROHC during the handover preparation response process Execute functional entities.
  • the process of selecting the target ROHC to perform the function entity may also be implemented as follows: the source ROHC execution function entity is located in the base station of the source ASN, and the ROHC channel parameter of the source ROHC execution function entity is sent to more than one potential through the gateway of the source ASN.
  • the target ROHC performs a functional entity
  • the gateway of the source ASN receives the ROHC support capability and/or the ROHC channel parameter of the one or more potential target ROHC performing functional entities, and performs a functional entity from the ROHC of the one or more potential targets Determining a function entity as a target ROHC; or, the gateway of the source ASN receives the ROHC support capability and/or the ROHC channel parameter of the one or more potential target ROHC performing functional entities, from the one or more potential Select one or more targets from the target ROHC execution function entity
  • the ROHC execution function entity executes the function entity as the candidate target ROHC, and then the terminal selects one of the candidate target ROHC execution function entities as the target ROHC execution function entity.
  • ROHC channel parameter determines whether the ROHC performing functional entity included in the ROHC can perform the functional entity as the target ROHC, and send the determined result to the source ASN; Determining the result, selecting one ROHC execution function entity as the target ROHC execution function entity; or selecting one or more ROHC execution function entities from it as the candidate target ROHC execution function entity, performed by the terminal from the candidate target ROHC Select one of the functional entities to perform the functional entity as the target ROHC.
  • the terminal When the target ASN to be switched by the terminal does not have the ROHC capability, the terminal is notified that the ROHC operation is not performed after the handover. Specifically, it may be implemented to: send an indication message carrying the ROHC capability information in the ASN to the terminal in the process of initiating the DSC (Dynamic Service Flow Modification), or send an indication message containing a preset value to the terminal, indicating The ROHC function is not supported in the ASN.
  • DSC Dynamic Service Flow Modification
  • the method for implementing ROHC communication continuity in the embodiment of the present invention includes the following steps:
  • Step 201 In the R0HC performing functional entity migration process, sending the R0HC channel parameter in the source R0HC execution function entity to the target R0HC execution function entity;
  • Step 202 After the R0HC performs the function entity migration, if the R0HC channel parameter of the terminal and the network side does not change, the terminal and the target R0HC execution function entity continue to perform the R0HC operation by using the R0HC channel parameter;
  • the R0HC channel parameters between the network sides are changed, such as: FEEDBACK-F0R parameters, and the R0HC operation is performed by using the re-negotiated R0HC channel parameters.
  • the R0HC execution function entity can be divided into two types of R0HC execution functions: compressor and decompressor. Entity, for each ROHC channel, the two ROHC execution functional entities are located in the MS and ASN, respectively. In the ASN, the ROHC executive function entity may be located at the BS or at the ASN gateway. For the scenario where the R4 tunnel exists, the ROHC execution function entity is located in the anchor data path function entity (Da ta Path Funct ion, DPF).
  • DPF anchor data path function entity
  • the source ROHC execution functional entity is located in the BS in the source ASN, or the ASN gateway in the source ASN; the target ROHC execution functional entity may be located in the target ASN. BS, or ASN gateway in the target ASN.
  • the terminal switches from a network performing ROHC operation on the BS to a network performing ROHC operation on the ASN gateway, that is, the source ROHC execution function entity is located in the BS in the source ASN, and the target ROHC execution function entity is located in the GW in the target ASN.
  • the source ROHC performing function entity to transfer the ROHC channel parameter to the target ROHC execution function entity may be implemented as follows: the source ROHC execution function entity, in the handover process, the ROHC corresponding to the terminal in the base station in the source ASN The channel parameters are sent to the ASN gateway in the target ASN.
  • the R3 migration process is triggered, and the anchor DPF is migrated to the ASN gateway in the target ASN.
  • the terminal switches from a network that performs ROHC operations on the ASN gateway to a network that performs ROHC operations on the BS. If the switch is only performed in the ASN, the ASN gateway of the original ASN is still used as the target ROHC to execute the functional entity, or the source.
  • the ROHC performs the ASN gateway of the functional entity in the original ASN
  • the target ROHC performs the BS of the functional entity in the target ASN, but needs to perform the ROHC operation on the ASN gateway in the original ASN, which will not affect the ROHC operation.
  • the source ROHC execution function entity is located in the BS in the source ASN
  • the target ROHC execution function entity is located in the ASN gateway in the target ASN.
  • the source ROHC performs the function entity to deliver the ROHC channel parameter to the target ROHC.
  • the execution function entity may be implemented as follows: the source ROHC execution function entity transmits the ROHC channel parameter to the ASN gateway in the target ASN during the handover process; During the R3 migration process, the anchor DPF is migrated to the ASN gateway in the target ASN; after the R3 migration is completed, the ROHC channel parameters in the gateway in the target ASN are delivered to the BS in the target ASN.
  • the target ROHC performing functional entity may utilize ROHC channel parameters and ROHC context following The first mode:
  • the R0HC context in the source R0HC execution function entity may be sent to the target R0HC execution function entity, so that after the R0HC execution function entity migration is completed, the target R0HC execution function entity may directly utilize the source R0HC.
  • the R0HC channel parameter in the functional entity and the R0HC context are executed to continue the R0HC operation.
  • the second mode After the R0HC execution function entity migration is completed, the R0HC context can be re-established. At this time, the target R0HC execution function entity can continue to use the re-established R0HC context and the received source R0HC to perform the R0HC channel parameter of the functional entity. Perform R0HC operation.
  • the R0HC execution function entity migration is completed, if the R0HC channel parameter between the terminal and the network side changes, the above two methods are also applied to obtain the R0HC context. That is, in the first manner, in the R0HC performing functional entity migration process, the R0HC context in the source R0HC execution function entity is further sent to the target R0HC execution function entity; then the target R0HC execution function entity is using renegotiation The R0HC channel parameter and the R0HC context continue with the R0HC operation.
  • a R0HC context is established between the terminal and the network side; then the target R0HC execution function entity is to utilize the renegotiated R0HC channel parameter and the established R0HC context, Continue with the R0HC operation.
  • R3 migration process is Mobile IP Version 6 (MIP6)
  • MIP6 Mobile IP Version 6
  • the R0HC execution function entity can be triggered to return to the initialization and reset states. Update the R0HC context; you can also modify the original R0HC context directly.
  • the R0HC execution function entity may change.
  • the R0HC context in the source R0HC execution function entity may also be sent to the target ROHC execution function entity;
  • the R0HC context in the anchor paging controller is further transmitted to the target ROHC execution function entity.
  • the network supports R0HC operation before the network enters idle mode, and the network after exiting idle mode does not support R0HC operation. After the terminal exits the idle mode network re-entry, the R0HC channel parameter and the R0HC context described in the anchor paging controller are deleted.
  • the terminal may delete the related R0HC channel parameters and the R0HC context before re-entry.
  • the R0HC execution function entity After the terminal completes the handover, or after the terminal exits the idle mode, if the mapping relationship between the feedback channel and the service flow of the service flow that performs the R0HC operation needs to be changed, the R0HC execution function entity initiates a DSA process to create a new service flow to carry the feedback channel. Or initiating a DSC process to carry the feedback channel on an existing service flow.
  • the R0HC channel parameter is transmitted together with the R0HC context, but is not limited to transmitting the two kinds of information.
  • the R0HC channel parameter may be transmitted, the R0HC context is not included, and some other related information of the terminal may be added. If the R0HC operation is implemented on the BS, when the MS switches between BSs, the serving ASN may transmit the R0HC channel parameters to one or more BSs in the target ASN during the handover.
  • the R0HC support capability (which may include the R0HC channel parameter) is added to the handover response (H0_RSP) message returned by the ROHC performing functional entity in one or more BSs in the target ASN, and the serving ASN may determine the corresponding BS according to the R0HC support capability. Whether it can be used as a target set.
  • the R0HC channel parameters and the R0HC context of the MS-related SF need to be delivered by the serving ASN to the target ASN during the handover preparation phase or the handover execution phase.
  • the first embodiment is for the scenario that the network side R0HC performs the function entity on the BS, and delivers the R0HC channel parameter and the R0HC context in the switch preparation phase.
  • the service ASN includes a service BS and a service GW.
  • the target ASN includes the target BS and the target GW.
  • the service BS in the service ASN is referred to as a service ASN BS
  • the service GW in the service ASN is referred to as a service GW.
  • ASN GW may be a separate physical device, it can be integrated in one physical device. For the case where the BS and the GW are integrated in one physical device, a message between the BS and the GW can be omitted.
  • Step 301 The terminal sends an inter-BS handover request (M0B_MSH0_REQ) message to the serving ASN BS to initiate a handover procedure, where the message carries one or more target BS information.
  • M0B_MSH0_REQ inter-BS handover request
  • Step 301 is performed when the switch is actively triggered by the MS. If the handover initiated by the network side begins, step 302 begins.
  • Step 302 The serving ASN BS sends an R6 handover request (R6-H0 REQ) message to the serving ASN GW, where the message carries the R0HC channel parameter, and may also include the R0HC context.
  • R6-H0 REQ R6 handover request
  • Step 303 Perform a context request process between the serving ASN GW and the authenticator (Authent ica tor ASN) to obtain the AK context and service authorization information of the MS. This step can also be performed between the target ASN GW and the authenticator after step 304.
  • Step 304 The serving ASN GW sends an R4 handover request (R4-H0 REQ) message to the target ASN GW, where the message carries the R0HC channel parameter, and may also include the R0HC context.
  • R4-H0 REQ R4 handover request
  • Step 305 After receiving the R4 handover request (R4-H0 REQ) message, the target ASN GW sends an R6 handover request (R6-H0 REQ) message to the target ASN BS, where the message carries the R0HC channel parameter and the R0HC context.
  • Step 306 The target ASN may initiate a pre-registration process of the data channel to the anchor ASN. After performing the pre-registration, step 307 is performed. Here, step 306 is optional.
  • Step 307 The target ASN BS determines the negotiated R0HC channel parameter according to the R0HC channel parameter carried in the R6-H0 REQ message, and sends an R6 handover response (R6-H0 RSP) message to the target ASN GW, which includes its own R0HC support. Capability and negotiated R0HC channel parameters.
  • Step 308 After receiving the R6-H0 RSP message, the target ASN GW sends an R4 handover response (R4-H0 RSP) message to the serving ASN GW, where the R0HC support capability of the target ASN BS is included. / or negotiated ROHC channel parameters.
  • R4-H0 RSP R4 handover response
  • Step 309 The serving ASN GW sends an R6-H0 RSP message to the serving ASN BS, which includes the R0HC support capability of the target ASN BS and/or the negotiated R0HC channel parameter.
  • Step 310 The monthly service ASN BS that receives the R6-H0 RSP message may be in the R0HC support capability and/or the R0HC channel parameter in one or more R6-H0 RSPs currently received, determine the target BS, and send the BS.
  • a handover response (M0B_BSH0-RSP) message is sent to the MS, which contains information of the determined one or more target BSs.
  • Step 311 The serving ASN BS sends an R6 handover confirmation (R6-H0 ACK) message to the serving ASN GW.
  • R6-H0 ACK R6 handover confirmation
  • Step 312 After receiving the R6-H0 ACK message, the serving ASN GW sends an R4 handover feedback (R4-H0 ACK) message to the target ASN GW.
  • R4-H0 ACK R4 handover feedback
  • Step 313 After receiving the R4-H0 ACK message, the target ASN GW sends an R6-H0 ACK message to the target ASN BS.
  • the R0HC channel parameter and the R0HC context may also be transmitted by the serving ASN BS to the target ASN BS in the handover confirmation message of steps 311, 312 and 313.
  • the R0HC channel parameter may also be sent in an independent message. R0HC context.
  • the R0HC channel parameter is negotiated in the handover preparation phase, and then the target R0HC execution function entity is selected in the handover execution phase, the R0HC context is transmitted from the source R0HC execution function entity to the target R0HC execution function entity; And in the handover execution phase, the R0HC channel parameters and the context are passed together to the target R0HC execution functional entity.
  • Step 401 The MS sends a M0B_H0_IND (Handover Indication) message to the serving ASN to notify the service ASN to switch to the target ASN BS.
  • M0B_H0_IND Haandover Indication
  • Step 402 After receiving the M0B_H0-IND message, the serving ASN sends an R4 switch to the target ASN. Know (R4-H0 conf i rm ) message.
  • the message contains the R0HC channel parameters and the R0HC context associated with the MS.
  • Step 403 After receiving the R4-H0 conf i rm, the target ASN sends an R4-H0 ACK message to the serving ASN, where the message may include: R0HC support capability of the target ASN.
  • Step 404 Perform a context interaction process between the target ASN and the authenticator (authentication ASN), which is optional.
  • Step 405 A data channel pre-registration process is performed between the target ASN and the DPF in the anchor ASN, and the step is optional.
  • Step 406 The MS initiates a network re-entry process with the target ASN.
  • Step 407 The target ASN initiates a data channel registration process with the anchor ASN.
  • Step 408 By successfully completing the network reentry, the target ASN initiates a CMAC (Message Digest Algorithm) Key Count Upda te (CMAC Key Counter Update) procedure, with the latest received from the MS.
  • CMAC Message Digest Algorithm
  • CMAC Key Counter Update CMAC Key Counter Update
  • the CMAC Key Count value updates the authenticator.
  • Step 409 After successfully completing the network reentry, the target ASN sends an R4 handover complete (R4-H0).
  • Step 410 By completing the data channel registration process with the target ASN (Da ta Pa th
  • the anchor ASN initiates the deregistration process with the original service ASN.
  • the anchor ASN may also be included to register a pre-registered data channel with the unselected target ASN.
  • the serving ASN BS sends an R6-H0 conf i rm message to the ASN GW after receiving the M0B_H0_IND message, where the message carries the R0HC channel.
  • the parameter and the R0HC context, the R6-H0 conf i rm message is not shown in Figure 4.
  • the following is a specific embodiment to describe a scenario in which a network side R0HC performs a functional entity on a BS, and describes a R0HC channel parameter and a R0HC context in a successful uncontrolled handover process. Schematic diagram of the process.
  • Step 501 The MS sends an RNG-REQ (Ranging Request) message to the target ASN, where the service BS ID TLV (Base Station Identity) is included to perform an uncontrolled handover procedure. Prior to this, the target ASN did not receive an indication that the MS was about to switch, and did not participate in the handover execution phase.
  • RNG-REQ Radio Network Request
  • TLV Base Station Identity
  • Step 502 The target ASN initiates a context request procedure to the serving ASN to obtain the context of the MS.
  • the serving ASN sends the context information of the MS in the response message, which includes: an authenticator ASN ID, an anchor ASN ID, and a R0HC channel parameter and a R0HC context.
  • Step 503 Perform a context interaction process between the target ASN and the authenticator.
  • Step 504 The target ASN initiates a data channel registration process with the anchor ASN.
  • Step 505 The target ASN sends an RNG-RSP (Ranging Response) message to the MS, confirms the HMAC/CMAC tuple, and the AC/CMAC is a message digest to ensure the security of the message, and includes the handover process optimization parameter (HO Proces) s Op t imi za t ion TLV ).
  • RNG-RSP Raster Network Response
  • Step 506 The target ASN initiates a CMAC Key Count Upda te process to update the authenticator with the newly received CMAC Key Count value.
  • Step 507 The anchor ASN initiates a deregistration process with the source service ASN. This step can also occur after step 504.
  • the pure R3 migration based on network-side resource optimization does not cause the network side R0HC to perform the change of the functional entity.
  • the R0HC execution function entity is located on the GW, that is, on the anchor DPF, when the R3 migration occurs, the R0HC execution function entity on the network side will migrate accordingly due to the migration of the anchor DPF. Therefore, during the R3 migration process, the R0HC channel parameters and the R0HC context need to be transmitted from the service anchor DPF to the target anchor DPF.
  • MIP4 For Mobile IP Version 4 (MIP4), the data address is the HoA of the MS (home Addres s: Home address), HoA does not change during R3 migration; for mobile IP version 6 (MIP6), MS's data packet address is CoA, and R3 will cause CoA change after migration, which will cause ROHC compressor to return to IR state. Update the ROHC context. Therefore, when the R3 migration occurs in the mobile IP version 6 (MIP6), the ROHC channel parameters can be transmitted only to the target, and after the R3 migration is completed, the MS and the network side are triggered to return to the IR state, and the ROHC context is updated. Or directly modify the relevant ROHC context, that is, replace the CoA related content in the ROHC context with the RA after the R3 switch.
  • MIP6 Mobile IP version 6
  • the fourth embodiment is a process for transmitting the ROHC channel parameter and the ROHC context in the R3 migration process of the PMIPv4 non-re-authentication in the scenario that the network-side ROHC performs the function entity on the ASN GW.
  • Step 601 If the target ASN ASNb sends an anchor DPF HO Tr i gger message to the wrong DPF in the source ASNa to initiate an FA (Fore g g agent) redirection. If ASNa agrees to the FA redirection, proceed to step 602.
  • Step 602 The ASNa sends an Anchor DPF HO Reques t message to the ASNb, where the message includes the MS related ROHC channel parameter and the R0HC context.
  • Step 603 The target of the FA redirection ASN ASNb sends an Anchor DPF Re loca te REQ message to the PMIP client (C l ient ), which carries the care-of address (CoA) of the target FA and the like.
  • Steps 604 ⁇ 607 The PMIP client starts the Mobile IP (MIP) registration process.
  • MIP Mobile IP
  • Step 608 The target ASN sends an Anchor DPF HO Response message to the source ASNa, indicating a successful FA redirection.
  • the source ASN can delete the mobile binding of the MS, the DHCP context information, and the R4 data channel between the source ASNa and the ASNb.
  • Embodiment 5 In the scenario that the R0HC execution function entity is implemented on the GW, the R0HC channel parameter and the R0HC context are transmitted in the R3 migration process of the PMIPv4 authenticator and the PMIP client redirection.
  • Step 700 Establish an R4 channel between the anchor ASN and the serving ASN.
  • Steps 701 - 702 Perform an R3-Re loca t ion-REQ/RSP message exchange between the ASN where the PMIP client is located and the service ASN, and confirm the R3 redirection.
  • This process can be initiated by the service ASN, that is, the push mode, or it can be initiated by the ASN where the PMIP client is located, that is, the pull mode.
  • Steps 703 - 704 The serving ASN requests the MS-related context from the anchor ASN (the ASN where the Anchor DPF/FA is located); the anchor ASN sends the context information to the serving ASN, where the message includes the R0HC channel parameter and the R0HC context. This process can also be triggered after step 705.
  • Step 705 The MS performs a re-authentication process.
  • Step 706 MIP4 registration process.
  • Steps 707 - 708 The serving ASN and the source anchor ASN release the R4 data channel between them.
  • the sixth embodiment is to transmit the R0HC channel parameter and the R0HC context in the CMIP4 R3 migration process in the scenario that the network side R0HC execution function entity is implemented on the ASN GW.
  • Step 801 The target ASN sends an R3-Re loca t ion-REQ message to the source ASN, requesting R3 redirection.
  • Step 802 The source ASN sends an R3_Re loca_ion_RSP message to the target ASN to confirm that the R3 is redirected.
  • the message carries the R0HC channel parameter and the R0HC context.
  • Step 803 A context interaction process may be performed between the target ASN and the source ASN.
  • Step 8 0 4 MS and HA (Home Agent: Home Agent) perform MIP 4 registration process, complete
  • the R0HC channel parameters and the R0HC context may also be passed by the source ASN to the target ASN in step 803.
  • an authenticator redirection operation may be performed between steps 802 and 803.
  • Embodiment 7 In the scenario implemented by the network-side ROHC performing functional entity on the ASN GW, the ROHC channel parameter and the ROHC context are delivered during the CMIP6 R3 migration process.
  • Step 901 Before the handover, a data channel is established between the target ASN and the serving ASN.
  • Step 902 The Intra-ASN Functional entity sends an R3_Relocate REQ message to the target ASN to initiate an R3 handover.
  • Steps 903 ⁇ 904 After receiving the R3_Relocate REQ message, the target ASN requests the service ASN to request the MS-related context, and the service ASN sends the MS-related R0HC channel parameter and the R0HC context to the target ASN in a response message (Context Report).
  • Step 905 The target ASN sends a Router Advertisement to the MS. Steps 903, 904, and 905 have no inevitable chronological relationship.
  • Steps 906 ⁇ 908 The MS generates a new care-of address CoA and sends a Binding Update to the HA for MIP registration, and the HA sends a Binding ACK to the MS.
  • Step 909 The target AR determines the state of the MIPv6 registration process by analyzing the BU/BA message in passive mode.
  • Steps 910 ⁇ 911 The target ASN redirects the result to the ASN function entity.
  • Step 912 The target ASN deletes the data channel between the serving ASN and the serving ASN.
  • steps 903 and 904 can also be triggered after step 909 or step 910 or step 911.
  • the relevant service flow SF parameters are stored in the anchor PC, and when the idle mode is exited, the parameters of the relevant SF are taken out from the anchor PC.
  • the SF parameters contain the R0HC channel parameters and the R0HC context.
  • the eighth embodiment is that, in the scenario that the network side R0HC execution function entity is implemented on the BS, the R0HC channel parameter and the R0HC context are delivered to the anchor PC when the MS enters the idle mode.
  • Step 1001 The MS sends a DREG_CMD (Deregistration Command) message to the BS in the ASN (a). Carry to enter the idle mode indication.
  • DREG_CMD Deregistration Command
  • Steps 1002 ⁇ 1003 The local relay PC of the ASN selects an anchor PC for the MS, and the anchor PC is in the ASN (c).
  • the BS in the ASN (a) sends an IM Entry MS State Change REQ message to the GW in the ASN (a); the GW in the ASN (a) then sends an IM Entry MS State Change REQ to the anchor PC (entering the idle state terminal state change request) ) Message.
  • the message includes the MS related R0HC channel parameters and the R0HC context.
  • Steps 1004 ⁇ 1005 The anchor PC interacts with the authenticator to verify that the MS is allowed to idle mode. That is: the anchor PC sends an IM Entry MS State Change REQ message to the authenticator; the authenticator responds to the anchor PC with an IM Entry MS State Change RSP message.
  • Steps 1006 ⁇ 1007 The anchor PC sends an R4 IM Entry MS State Change RSP to the GW in the ASN(a) to update the MS's location information (PGID) and other parameters, including the R0HC channel parameters. And the R0HC context, then the GW in ASN(a) then sends an R6 IM_Entry_State_Change_RSP message to ASN(a).
  • PGID MS's location information
  • R6 IM_Entry_State_Change_RSP message to ASN(a).
  • Step 1008 The BS sends a DREG-CMD message to the MS, informing the MS of its anchor PC and some other parameters.
  • Steps 1009 ⁇ 1010 The ASN sends an IM Entry MS Sate Change Ack to the anchor PC.
  • Step 1013 The anchor DPF initiates a data path to the registration process.
  • Steps 1014 ⁇ 1015 CMAC Key Count update process.
  • the R0HC channel parameters and the R0HC context may also be passed to the anchor PC for storage by the current R0HC execution function entity (BS or GW) in steps 1009 and 1010.
  • the R0HC execution functional entity is located at the ASN GW (i.e., at the anchor DPF)
  • the R0HC channel parameters and the R0HC context are passed to the anchor PC by the anchor DPF in step 1012.
  • Embodiment 9 is that, in the scenario that the network side R0HC execution function entity is implemented on the BS, the R0HC channel parameter and the R0HC context are delivered to the anchor PC when the MS enters the idle mode. i LH . ⁇ U /.09.2008)
  • This embodiment is the idle mode entry process initiated by the network side.
  • the main flow is the same as that of the embodiment 8, and the R0HC channel parameters and the R0HC context are also transmitted the same, and are not described here.
  • the R0HC execution function entity is located at the ASN GW (i.e., at the anchor DPF)
  • the R0HC channel parameters and the R0HC context are passed to the anchor PC by the anchor DPF in step 1012.
  • Embodiment 10 is to pass the R0HC channel parameter and the R0HC context to the R0HC execution function entity when S exits the idle mode.
  • Step 1201 The MS sends an RNG-REQ message to the BS, instructing the MS to exit the idle mode.
  • Steps 1202 ⁇ 1203 The ASN sends an IM Exi t MS State Change REQ message to the anchor PC indicating that the MS wants to be activated.
  • Steps 1204 ⁇ 1205 The anchor PC interacts with the authenticator to request the relevant secure context.
  • Steps 1206 ⁇ 1207 The anchor PC sends an IM-Exi t-Site-Change-RSP message to the ASN, carrying the MS-related ROHC channel parameters and the ROHC context. If the network side ROHC execution function entity is located in the BS, steps 1206 and 1207 need to carry the ROHC channel parameter and the ROHC context; if the network side ROHC execution function entity is located in the ASN GW, only step 1206 needs to carry the ROHC channel parameter and the ROHC context.
  • Steps 1208 ⁇ 1211 The BS starts the data channel registration process.
  • Step 1212 The BS sends an RNG-RSP message to the MS.
  • Step 1213 The MS performs a network reentry process.
  • Step 1214 CMAC Key Count update process.
  • Steps 1215 ⁇ 1217 Data channel registration confirmation process.
  • Embodiment 11 is directed to a scenario in which a network-side ROHC execution functional entity is implemented on an ASN GW.
  • the ROHC channel parameters and the ROHC context are passed by the anchor PC to the ROHC execution function entity during the paging process.
  • the relevant ROHC channel parameters and ROHC context of the MS may be transmitted by the anchor PC to the anchor DPF during the paging procedure.
  • Step 1301 The FA receives the data sent from the HA to the MS, and the anchor DPF associated with the FA caches the data.
  • Step 1302 The anchor DPF sends an R4-Initiate-Paging_REQ (R4 reference point trigger paging request) message to the anchor PC to request paging, and the message carries the QoS parameters of the arriving data stream.
  • R4-Initiate-Paging_REQ R4 reference point trigger paging request
  • Step 1303 The anchor PC sends an R4-Initiate_Paging_RSP (R4 reference point triggering paging response) message to the anchor DPF, which is used to indicate whether the context of the MS included in the PC/LR is correct, and whether the requested paging is authorized.
  • the message carries the MS related R0HC channel parameters and the R0HC context.
  • the R0HC execution function entity is located in the DPF, and the parameter is retained on the DPF in the idle mode, the information may not be carried in this message. However, if the R0HC execution function entity is located in the BS, then in the idle mode, the BS releases the R0HC information, so this information needs to be carried in the message here.
  • Step 1304 The anchor PC performs a paging process.
  • Step 1305 The paging proxy PA at the BS sends an M0B-PAG-ADV message on the air interface, where the MS related R0HC channel parameter and the R0HC context may be included.
  • Step 1306 The MS performs an idle mode exit or location update process.
  • the network side R0HC execution function entity is implemented on the ASN BS, in the MS idle mode, the R0HC channel parameter and the R0HC context in the source ASN BS need to be transmitted to the ASN GW, and then sent to the anchor by the service anchor DPF in the ASNGW.
  • the anchor PC when the terminal exits the idle mode, the anchor PC transmits the ROHC channel parameter and the ROHC context to the target anchor DPF, and the target anchor DPF transmits the ROHC channel parameter and the ROHC context to the BS in the target ASN.
  • the network-side ROHC operation can be implemented on the BS, it can also be implemented on the GW, that is, the execution entity that performs the ROHC function may be a BS or a . Then, when the MS switches between the two systems, or the two networks have different ROHC capabilities before and after the handover, for example, the MS may switch from the network performing the ROHC operation to the network that does not support the ROHC operation, and how to determine which network device Performing the ROHC operation is a problem that needs to be solved, that is, there are currently multiple target ROHC execution functional entities, and how to select the target ROHC to execute the functional entity.
  • the MS switches from a ROHC-capable BS to a ROHC-free BS.
  • the network side ROHC execution function entity can be implemented on the BS or the ASN GW, when the MS switches, there may be a case where the MS switches from a BS performing ROHC operation to a BS not having the ROHC function, and at this time, there are two Kind of situation.
  • the capability information, its own ROHC function, and the current ROHC operational strategy determine the target ROHC performing functional entity after the handover.
  • the ROHC channel parameters and the ROHC context need to be passed to the final decision target ROHC execution function entity during the handover process.
  • the target ROHC execution function entity of the final decision is the target ASN GW
  • the specific process is similar to that of the first embodiment, except that it is only transmitted to the target GW instead of the target BS, and then the R3 migration process is triggered, and the FA/anchor DPF is migrated to the target GW. , see example Four to seven.
  • the target ROHC performing functional entity of the last decision is the original GW, the ROHC channel parameter and the ROHC context in the original BS need to be transmitted to the original GW.
  • the DSC process may be initiated by the MS or the target ASN, the two parties renegotiate the ROHC channel parameters, and then re-establish the ROHC context during the data transmission.
  • the second case After the switched network does not have the ROHC function, the ROHC operation cannot be performed after the switching is completed.
  • the MS switches from a ROHC-capable GW to a ROHC-free GW.
  • the network-side ROHC executive function entity can be implemented on the BS or ASN GW, when the MS switches, there may be a case where the MS switches from a GW that performs ROHC operation to a GW that does not have the ROHC function.
  • the target GW does not have the ROHC capability. If the R3 migration occurs, and the anchor DPF in the target GW does not have the ROHC function, and only the ROHC function exists on the BS, then the source GW needs to pass the target after the R3 migration is completed. The GW passes the ROHC channel parameters and the ROHC context to the target BS.
  • the ASN includes GW and BS, and the interaction signaling between the GW and the BS is omitted in Figures 6-9.
  • the specific implementation is as follows: For the fourth embodiment, after the step 602, an RR-REQ message is sent by the GW in the ASNb to the BS, and the MS related R0HC channel parameter and the R0HC context are informed.
  • an RR-REQ message is sent by the GW in the serving ASN to the BS, and the MS related R0HC channel parameter and the R0HC context are informed.
  • adding an RR-REQ message after step 802 is sent by the GW in the new ASN to the BS, and informs the MS about the R0HC channel parameter and the R0HC context.
  • an RR-REQ message is sent by the GW in the target ASN to the BS, and the MS related R0HC channel parameter and the R0HC context are informed.
  • the DSC process is initiated by the target ASN, and the MS is re-established.
  • the ROHC channel parameters are negotiated and then the ROHC context is re-established during the data transmission.
  • the MS switches from a ROHC-capable network to a ROHC-free network.
  • the MS and the BS/GW can know each other's ROHC capabilities. If the target network does not have the ROHC capability, if the ROHC is performed on the BS before the handover, the MS should no longer use the ROHC compression mechanism after the handover is completed; if the ROHC function is performed on the anchor DPF before the handover, the network side is completed after the handover is completed.
  • the ROHC execution function entity has not changed and can continue ROHC operation until an R3 migration occurs. After the R3 migration is successful, if the new anchor DPF or BS does not support ROHC capability, MS should no longer use the ROHC compression mechanism.
  • the new anchor DPF does not have ROHC capability and no ROHC compression is performed.
  • the MS needs to be told not to use the ROHC function.
  • the mutual ROHC capability can be negotiated, and the ROHC indication (Indication parameter) can be added to indicate whether the ROHC capability is available, and whether the GW or the BS performs the ROHC operation.
  • the original anchor DPF knows that the new anchor DPF has no ROHC capability, and the new BS does not support it, or the new anchor DPF knows that the MS has ROHC operation at the original anchor DPF, and when it does not support the operation, both can initiate the RR/DSC process. To inform the MS not to perform ROHC operations.
  • the target BS also supports the ROHC function. At this time, the target GW should not tell the MS that the ROHC function is not supported. Only the BS and the GW do not support the ROHC. Of course, there are many other ways. How to make the MS know the ROHC function on the network side is not limited to the above.
  • a message RR-REQ is sent to the BS by the GW in the ASNa or ASNb, and the BS sends the DSC-REQ to inform the MS that the R0HC operation is no longer performed.
  • the target or service The GW in the ASN is sent to the BS, and the BS resends the DSC-REQ to inform the MS that the ROHC operation is no longer performed.
  • a message is added after the step 801 or 802.
  • the RR-REQ is sent by the GW in the old ASN or the new ASN to the BS, and the BS then sends the DSC-REQ to inform the MS that the R0HC operation is no longer performed.
  • a message is added after the step 903 or 904.
  • the RR-REQ is sent by the GW in the serving ASN or the target ASN to the BS, and the BS sends the DSC-REQ to inform the MS that the R0HC operation is no longer performed.
  • the R0HC channel parameters change after the MS is switched or after the idle mode is exited if the MS completes the handover (ASN handover or R3 migration), or the MS exits the idle mode, the R0HC channel parameters of the originally stored related service flows SF change. For example, if the feedback channel of the service flow of other R0HC operations carried on the service flow SF changes, after the MS exits the idle mode activation, the MS or the network needs to initiate a DSC process to modify the R0HC channel parameters.
  • the DSA process may be initiated by the decompressor side to create a new service flow to carry the feedback channel, or initiate a DSC process to carry the feedback channel on an existing service flow.
  • the network side needs to initiate the DSC process to inform the MS of the new anchor GW.
  • the IP address thus enables the MS to send an upstream R0HC feedback message.
  • the communication system of the embodiment of the present invention includes a source R0HC execution function entity 411 and a target R0HC execution function entity 412.
  • the source R0HC performs a function entity 411, configured to send the R0HC channel parameter to the target R0HC execution function entity during the migration process;
  • the target R0HC performs a function entity 412, configured to provide a R0HC operation for the terminal and the network side by using the R0HC channel parameter if the R0HC channel parameter of the terminal and the network side is unchanged after the migration is completed. If the R0HC channel parameter between the terminal and the network side changes, the terminal and the network side perform R0HC channel parameter renegotiation, and perform R0HC operation by using the re-negotiated R0HC channel parameter.
  • the source ROHC performing functional entity may be located at a base station in the source ASN, or a gateway in the source ASN.
  • the target R0HC execution function entity is a base station in the target ASN, or a gateway in the target ASN.
  • the system can also include: a decision module for performing a functional entity of the target R0HC that needs to be switched according to the R0HC capabilities of the source ASN and the base station or gateway in the one or more ASNs.
  • the decision module When the source R0HC performs a function entity located in a base station in the source ASN, the decision module is located in a base station in the source ASN or a gateway in the source ASN; or, when the source R0HC performs a function entity located in the source ASN The decision module is located at a gateway in the source ASN.
  • a communication system includes: a source R0HC execution function entity 511 and a target R0HC execution function entity 512.
  • the source R0HC performs a function entity 511, configured to: before the terminal enters the idle mode, transmit the R0HC channel parameter to the anchor paging controller for saving;
  • the target R0HC performs a function entity 512, configured to obtain the R0HC channel parameter from the anchor paging controller when the terminal exits the idle mode.
  • the anchor paging controller is further configured to save a R0HC context in the source R0HC execution function entity, and provide the R0HC context to the target R0HC execution function entity when the terminal exits the idle mode.
  • the system may further include: a control module, configured to: if the terminal supports the R0HC operation before the network enters the idle mode, and the network after exiting the idle mode does not support the R0HC operation, after the terminal exits the idle mode network reentry, the deletion is performed.
  • a control module configured to: if the terminal supports the R0HC operation before the network enters the idle mode, and the network after exiting the idle mode does not support the R0HC operation, after the terminal exits the idle mode network reentry, the deletion is performed.
  • the R0HC channel parameters described in the anchor paging controller configured to: if the terminal supports the R0HC operation before the network enters the idle mode, and the network after exiting the idle mode does not support the R0HC operation, after the terminal exits the idle mode network reentry, the deletion is performed.
  • the R0HC channel parameters described in the anchor paging controller configured to: if the terminal supports the R0HC operation before the network enters the idle mode, and the network after exiting
  • the system may further include: a context establishing module, configured to establish a R0HC context between the terminal and the network side when the terminal exits the idle mode.
  • a context establishing module configured to establish a R0HC context between the terminal and the network side when the terminal exits the idle mode.
  • the method for maintaining the continuity of the R0HC communication provided by the embodiment of the present invention, applying the embodiment of the present invention, keeps the R0HC communication continuous during the handover process, such as ASN handover, R3 migration, and exiting the idle mode.
  • Embodiments of the invention may be applied in a wireless network, such as a Wimax network.
  • the methods described in the embodiments of the present invention are equally applicable to other compression mechanisms, such as CRTP, ECRTP, and the like.
  • the parameters passed at the time of the handover process or entering/exiting the idle mode are the corresponding specifics of the compression mechanism. Parameters and ROHC context. For example, for CRTP/ECRTP, the parameters defined in the corresponding RFC.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne un procédé pour maintenir la communication de compression d'en-tête robuste en continu. Le procédé est le suivant : - pendant la progression du transfert d'entité de la fonction d'opération ROHC (compression d'en-tête robuste), envoi des paramètres de canal ROHC de l'entité de fonction opérationnelle ROHC source à l'entité de fonction opérationnelle ROHC cible, - après la réalisation du transfert, si les paramètres du canal ROHC du terminal et du côté réseau n'ont pas changé, le terminal et l'entité de fonction opérationnelle ROHC cible poursuivent l'opération ROHC à l'aide des paramètres de canal ROHC, - si les paramètres de canal ROHC du terminal et du côté réseau ont changé, le terminal et le côté réseau renégocient les paramètres de canal ROHC et entrent en fonctionnement ROHC à l'aide des paramètres de canal ROHC renégociés. L'invention concerne également un système de communication. En appliquant l'invention, il est possible de maintenir une communication ROHC continue pendant la progression de transfert MS, comme un transfert ASN, un transfert R3 et la sortie du mode de veille.
PCT/CN2008/071921 2007-08-10 2008-08-07 Procédé et système pour maintenir la communication de schéma de compression d'en-tête robuste en continu WO2009021442A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200710141596.7A CN101364937B (zh) 2007-08-10 2007-08-10 保持鲁棒性头标压缩机制通信连续的方法、系统
CN200710141596.7 2007-08-10

Publications (1)

Publication Number Publication Date
WO2009021442A1 true WO2009021442A1 (fr) 2009-02-19

Family

ID=40350385

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/071921 WO2009021442A1 (fr) 2007-08-10 2008-08-07 Procédé et système pour maintenir la communication de schéma de compression d'en-tête robuste en continu

Country Status (2)

Country Link
CN (1) CN101364937B (fr)
WO (1) WO2009021442A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111800826A (zh) * 2019-08-01 2020-10-20 维沃移动通信有限公司 一种rohc反馈处理方法及用户设备

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010118579A1 (fr) * 2009-04-16 2010-10-21 华为技术有限公司 Procédé et appareil d'amélioration d'efficacité de compression d'en-tête
CN101801108B (zh) * 2010-02-09 2015-06-03 中兴通讯股份有限公司 一种业务流建立方法和系统
CN102202347B (zh) * 2010-03-27 2014-12-10 中兴通讯股份有限公司 稳健头压缩业务流处理方法及装置
CN101984621B (zh) * 2010-10-25 2014-09-10 中兴通讯股份有限公司 鲁棒性头压缩中一种提高列表压缩效率的方法及装置
CN102215236B (zh) * 2011-06-13 2017-02-08 中兴通讯股份有限公司 鲁棒性头压缩协议层的工作模式切换方法和装置
CN102291774B (zh) * 2011-07-27 2017-09-26 中兴通讯股份有限公司 鲁棒性头压缩处理方法、压缩器及系统
CN102457901B (zh) * 2011-12-22 2017-11-07 中兴通讯股份有限公司 鲁棒性头压缩版本适配方法和装置
CN102546100B (zh) * 2011-12-22 2017-10-17 中兴通讯股份有限公司 鲁棒性头压缩反馈管理方法、装置及解压器
CN102694730B (zh) * 2012-05-28 2014-12-03 华为技术有限公司 一种并行处理的方法及装置
US9635603B2 (en) * 2012-11-21 2017-04-25 Intel Corporation Systems and methods for implementing multiple band service discovery
CN104703230A (zh) * 2013-12-09 2015-06-10 中兴通讯股份有限公司 一种基于鲁棒性头压缩协议的切换方法、设备和系统
WO2016000180A1 (fr) 2014-06-30 2016-01-07 华为技术有限公司 Procédé de gestion de terminal et dispositif de réseau
CN107426771B (zh) * 2016-05-23 2020-07-17 中国移动通信有限公司研究院 一种数据传输方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1507286A (zh) * 2002-12-09 2004-06-23 中国科学技术大学 用于MIPv6的鲁棒性头标压缩／解压方法
CN1663215A (zh) * 2001-01-10 2005-08-31 诺基亚有限公司 重定位头标压缩中的上下文信息
CN1859768A (zh) * 2006-01-24 2006-11-08 华为技术有限公司 通信网络中用户终端在接入网间进行切换的方法
WO2007043601A1 (fr) * 2005-10-10 2007-04-19 Nec Corporation Procede d'optimisation de compression d'en-tete pendant et apres des transferts dans un reseau de communication cellulaire

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6300887B1 (en) * 1999-11-09 2001-10-09 Nokia Networks Oy Efficient handoff procedure for header compression

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1663215A (zh) * 2001-01-10 2005-08-31 诺基亚有限公司 重定位头标压缩中的上下文信息
CN1507286A (zh) * 2002-12-09 2004-06-23 中国科学技术大学 用于MIPv6的鲁棒性头标压缩／解压方法
WO2007043601A1 (fr) * 2005-10-10 2007-04-19 Nec Corporation Procede d'optimisation de compression d'en-tete pendant et apres des transferts dans un reseau de communication cellulaire
CN1859768A (zh) * 2006-01-24 2006-11-08 华为技术有限公司 通信网络中用户终端在接入网间进行切换的方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111800826A (zh) * 2019-08-01 2020-10-20 维沃移动通信有限公司 一种rohc反馈处理方法及用户设备

Also Published As

Publication number Publication date
CN101364937B (zh) 2013-12-18
CN101364937A (zh) 2009-02-11

Similar Documents

Publication Publication Date Title
WO2009021442A1 (fr) Procédé et système pour maintenir la communication de schéma de compression d'en-tête robuste en continu
KR101044685B1 (ko) 리소스를 구축하고 삭제하기 위한 방법 및 네트워크 장비
US7440757B2 (en) Handover method in a wireless communication system
US8325682B2 (en) Resource release control method, communication system and device
WO2007062583A1 (fr) Procede et systeme de gestion du contexte d'un terminal mobile
WO2007006227A1 (fr) Procédé et système de négociation destinés à l’établissement de chemins de données d’interface
WO2007051423A1 (fr) Systeme et procede de communication pour l’entree et la sortie du mode repos d’un terminal
CN102177748B (zh) 一种网络切换方法、终端、网关和网络系统
WO2011000318A1 (fr) Procédé et dispositif permettant de commander un transfert
WO2010048868A1 (fr) Procédé, système et appareil destinés à un transfert dans un réseau
KR20100085146A (ko) 다중―모드 모바일 유닛들에 대한 무선 베어러 및 ｍｉｐ 세션 연속성을 유지하기 위한 최선형 핸드오프의 방법
JP5362699B2 (ja) データアタッチメントポイントのハンドオフ
WO2007137519A1 (fr) Procédé et système pour un ue en mode réserve fermant une session réseau
WO2007128241A1 (fr) Procédé permettant de faire entrer un terminal du côté du réseau en mode de repos dans un réseau métropolitain sans fil
WO2007128240A1 (fr) Procédé permettant à un terminal d'entrer en mode de repos dans un réseau métropolitain sans fil
WO2008113235A1 (fr) Procédé pour éviter la libération erronée de ressources pendant une mise à jour de zone de suivi ou un transfert intercellulaire
CN101047709B (zh) 在客户端移动网际协议下终端退网的实现方法
WO2008119296A1 (fr) Procédé et dispositif permettant de réaliser la négociation du protocole de gestion de la mobilité
WO2009117879A1 (fr) Procédé pour indiquer la gestion de support de la passerelle de desserte
KR20100010936A (ko) 네트워크에서의 위치 업데이트를 위한 방법, 시스템 및 장치
WO2009062392A1 (fr) Procédé de transfert de système, système de communication et entité pcrf
KR20060066373A (ko) 이종 무선망에서 ＭＩＰｖ4 기반의 고속 핸드오프 방법 및장치
WO2007048343A1 (fr) Procédé et dispositif pour gérer des informations d'un terminal sorti d'un mode de veille
WO2007107104A1 (fr) Système et procédé pour indication de traitement de terminal et procédé et appareil et système de traitement de terminal
WO2007006224A1 (fr) Procédé et système destinés à réaliser la translation de l’interface r3

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08783914

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08783914

Country of ref document: EP

Kind code of ref document: A1