WO2009021422A1 - Procédé et système permettant d'établir une communication à compression d'en-tête, et entité fonctionnelle de politique de compression d'en-tête - Google Patents

Procédé et système permettant d'établir une communication à compression d'en-tête, et entité fonctionnelle de politique de compression d'en-tête Download PDF

Info

Publication number
WO2009021422A1
WO2009021422A1 PCT/CN2008/071476 CN2008071476W WO2009021422A1 WO 2009021422 A1 WO2009021422 A1 WO 2009021422A1 CN 2008071476 W CN2008071476 W CN 2008071476W WO 2009021422 A1 WO2009021422 A1 WO 2009021422A1
Authority
WO
WIPO (PCT)
Prior art keywords
header compression
function entity
policy
execution function
rohc
Prior art date
Application number
PCT/CN2008/071476
Other languages
English (en)
French (fr)
Inventor
Wenliang Liang
Liang Gu
Xianhui He
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
Priority claimed from CN2008100826340A external-priority patent/CN101364980B/zh
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2009021422A1 publication Critical patent/WO2009021422A1/zh
Priority to US12/698,397 priority Critical patent/US8223797B2/en

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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a method and system for establishing header compression communication, and a header compression policy functional entity.
  • IP Internet Protocol
  • 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 the packet will be discarded due to packet 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
  • the header compression mechanism can solve the above problems while ensuring the inherent flexibility of the IP protocol.
  • the header compression mechanism may include Robust Header Compression (ROHC), Real-Time Transport Protocol Header Compression (CRTP) mechanism, and Extended RTP Header Compression (Extended RTP Header Compression). ECRTP) mechanism, etc.
  • ROHC Robust Header Compression
  • CRTP Real-Time Transport Protocol Header Compression
  • ECRTP Extended RTP Header Compression
  • ROHC is a stream-based header compression scheme.
  • the ROHC mechanism 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 saving the packet header overhead and utilizing the bandwidth more effectively.
  • the ROHC mechanism also makes the ROHC mechanism highly efficient and reasonable robust by controlling the frequency and quantity of feedback messages, detecting unsynchronized logic, and error checking. Therefore, the ROHC mechanism provides a header compression mechanism for high bit error rate and long latency links.
  • the ROHC channel is a logical channel.
  • the entry is a compressor
  • the exit is a solution.
  • the compressor performs header compression on the original data and sends it to the decompressor through the logical channel.
  • the ROHC channel is a unidirectional logical channel.
  • the decompressor in order to support bidirectional compression, the decompressor must be able to provide feedback information to the compressor, so the ROHC feedback channel is the logical channel carrying the feedback information, the entry is the decompressor, and the exit is the compressor.
  • Wimax Worldwide Interoperability for Microwave Access
  • Wimax mainly includes mobile station (MS, Mobile Station)/subscriber station (SS, Subscribe Station), access service network (ASN, Access Service Network) and Connection Service Network (CSN).
  • MS mobile station
  • SS Subscriber station
  • ASN Access Service Network
  • CSN Connection Service Network
  • /SS is the terminal, and the user uses the terminal to access the Wimax network.
  • the ASN provides wireless access service for the Wimax user terminal, and the ASN includes two base stations (BS, Base Station) and ASN gateway (ASN-GW, ASN Gate Way).
  • ASN-GW ASN Gate Way
  • an ASN can be shared by multiple CSNs.
  • CSN provides IP connection services for Wimax user terminals, such as location-based services, multimedia multicast services, broadcast services, and IP multimedia subsystem services.
  • the embodiments of the present invention provide a method and system for establishing a header compression communication, and a header compression policy function entity, which is used to solve the problem that the header compression communication cannot be implemented in the prior art.
  • the header compression execution function entity receives a header compression indication from the header compression policy function entity; the header compression execution function entity performs header compression channel parameter negotiation with a corresponding other header compression execution function entity to establish a header compression channel.
  • Head compression policy function entity first header compression execution function entity and second header compression execution function Entity; among them,
  • the header compression policy function entity is configured to: if the decision needs to perform header compression, the header compression indication is sent to the first header compression execution function entity or the second header compression execution function entity;
  • the first header compression execution function entity receives the header compression indication, and performs head compression channel parameter negotiation with the second header compression execution function entity;
  • the second header compression execution function entity receives the header compression indication and performs head compression channel parameter negotiation with the first header compression execution function entity.
  • the header compression policy function entity provided by the embodiment of the present invention includes: a decision unit and a delivery unit; the decision unit is configured to perform header compression according to the service quality requirement of the service flow and the available resource situation decision, and trigger the Hair unit
  • the sending unit is configured to receive a trigger of the decision unit, and send a header compression indication to the first header compression execution function entity or the second header compression execution function entity.
  • the header compression indication is sent to the header compression execution function entity; the header compression execution function entity that receives the header compression indication and the corresponding header compression execution function entity perform headers.
  • Compress channel parameter negotiation establish a head compressed channel, save wireless network resources, and improve service quality.
  • FIG. 1 is a schematic structural diagram of a Wimax network in the prior art
  • FIG. 2 is a schematic flowchart of a method according to an embodiment of the present invention.
  • FIG. 3 is a schematic flowchart of a first embodiment of a method according to an embodiment of the present invention
  • FIG. 4 is a schematic flowchart of a second embodiment of a method according to an embodiment of the present invention
  • FIG. 6 is a schematic flowchart of a fourth embodiment of the present invention
  • FIG. 7 is a schematic structural diagram of a system according to an embodiment of the present invention.
  • FIG. 8 is a schematic flowchart of determining a header compression policy by a header compression policy function entity in a method according to an embodiment of the present invention. detailed description
  • the header compression indication is sent to the header compression execution function entity; the header compression execution function entity that receives the header compression indication and the corresponding header compression execution function entity
  • the header compression channel parameter negotiation is performed, wherein the two header compression execution function entities described above are both ends of a header compression channel. That is, one header compression execution function entity is the compressor, that is, the header of the header compression channel, and the other header compression execution function entity is the decompressor, that is, the exit of the header compression channel.
  • the header compression channel parameters are negotiated, that is, a header compression channel is established between the two header compression execution function entities, thereby implementing header compression communication.
  • a method for establishing header compression communication includes the following steps:
  • Step 201 When the header compression policy function entity decision needs to perform header compression, the header compression indication is sent to the header compression execution function entity.
  • Step 202 The header compression execution function entity that receives the header compression indication performs a header compression channel parameter negotiation with the corresponding other header compression execution function entity to establish a header compression channel.
  • the header compression indication is sent to the header compression execution function entity; the header compression execution function entity that receives the header compression indication and the corresponding other header compression execution function entity Perform header compression channel parameter negotiation, establish a header compression channel, save wireless network resources, and improve service quality.
  • the header compression execution function entity may employ an ROHC mechanism, a CRTP header compression mechanism, or an ECRTP header compression mechanism.
  • the header compression enforcement function entity may be located in the terminal, or in a base station in the access service network ASN or in an anchor data path entity (DPF).
  • the header compression policy function entity may be located in a terminal, a policy function entity in an ASN, or a policy function entity in a CSN; the policy function entity in the ASN may include a base station, an anchor service flow licensor (SFA), and a service SFA. Or anchor DPF; the policy function entity in the CSN may include a Policy Function Entity (PF), a Policy Charging Rules Function Entity (PCRF), or an Authentication, Authorization, and Accounting (AAA) server.
  • PF Policy Function Entity
  • PCRF Policy Charging Rules Function Entity
  • AAA Authentication, Authorization, and Accounting
  • the entities such as the anchor data path entity DPF, the anchor service flow licensor, and the service SFA described in the embodiments of the present invention are described by taking a logical function entity as an example. In a specific networking, these entities may be separate physical entities, or It is integrated as a logical functional entity in a base station or gateway.
  • the header compression policy function entity can decide whether header compression is required according to the service quality requirement of the service flow and the available resource situation.
  • the header function policy is performed by the policy function entity in the connection service network CSN.
  • the policy function entity in the ASN can send its own header compression policy and/or idle resource information to the policy function entity in the connection service network CSN.
  • the policy function entity in the connection service network CSN makes a decision indication of header compression.
  • the header compression policy decision is performed by the policy function entity itself in the connection service network CSN.
  • the possible causes of the scenario include, but are not limited to: the policy function entity in the ASN does not report its own header compression policy and/or idle resources.
  • the information is sent to the policy function entity in the CSN, or the policy function entity in the ASN reports the policy function entity in the CSN, and the priority of the header compression policy decision by the policy function entity in the ASN is lower than that of the policy function entity in the CSN. Prioritize header compression policy decisions, or other situations.
  • the policy function entity in the connection service network CSN may send its own header compression policy and/or idle resource information to the policy function entity in the ASN, and the policy function entity in the ASN makes a header compression decision indication.
  • the heading of the policy is performed by the policy function entity in the ASN.
  • the possible causes of the scenario include, but are not limited to: the policy function entity in the CSN does not deliver its own header compression policy and/or idle resource information.
  • the policy function entity in the ASN, or the policy function entity in the CSN sends a notification to the policy function entity in the ASN, and the priority of the header compression policy decision by the policy function entity in the CSN is lower than that of the policy function entity in the ASN.
  • the priority of the header compression policy decision or other circumstances.
  • the header compression channel may be mapped according to the following Establishment: for a service flow establishment; or, for a terminal establishment; or, part of the business flow scheduling type establishment, part of the business flow establishment; or, for the business flow scheduling type.
  • the terminal and the ASN may establish a dynamic service flow establishment request (DSA-REQ), and the dynamic service flow establishment response (DSA- RSP), Dynamic Service Flow Modification Request (DSC-REQ), Dynamic Service Flow Modification Request Response (DSC-RSP) or predefined message for negotiation of header compressed channel parameters.
  • DSA-REQ dynamic service flow establishment request
  • DSC-REQ Dynamic Service Flow Modification Request
  • DSC-RSP Dynamic Service Flow Modification Request Response
  • a compressed execution function entity When a compressed execution function entity is located at the terminal, and another header compression execution function entity is located in the anchor data path entity DPF in the ASN, and when the header compression channel is established for a service flow, between the terminal and the ASN Can be performed by one or more of a resource reservation request (RR-REQ), a resource reservation response (RR-RSP) message, a DSA-REQ, a DSA-RSP, a DSC-REQ, a DSC-RSP, or a predefined message.
  • RR-REQ resource reservation request
  • RR-RSP resource reservation response
  • the terminal and the ASN may pass the user basic capability request (SBC-REQ), the user basic capability response (SBC-RSP), the registration request (REG-REQ), and the registration response (REG-RSP). Or one or more of the predefined messages, and a NetEntry MS State Change REQ, a NetEntry MS State Change ACK message, negotiating a header compression channel parameter.
  • the header compression when the header compression is performed by the ROHC mechanism, when a compression execution function entity is located at the terminal, and the terminal is initially in the network, the header compression may be performed through the SBC-REQ, SBC-RSP, REG-REQ, and REG-RSP messages.
  • the negotiation of the fixed parameters in the channel parameters; the header compression execution function entity receiving the header compression indication and the corresponding header compression execution function entity may perform the negotiation of the specific parameters in the header compression channel parameters through the dynamic service flow message.
  • the method further includes: negotiating the mapping manner between the terminal and the network side to establish a header compressed channel, and receiving the header pressure
  • the header compression execution function entity of the thumbnail indication and the corresponding other header compression execution function entity establish a header compression channel by using the negotiated setup header compression channel mapping manner.
  • the mapping manner of the header compressed channel can be negotiated by a User Basic Capability (SBC) or a Registration (REG) message.
  • the header compression execution function entity further includes: before receiving the header compression indication from the header compression policy function entity:
  • the header compression policy function entity receives a header compression capability or policy of the terminal sent by the network side, and/or a header compression capability or policy supported by the network side;
  • the header compression policy function entity determines and delivers a header compression indication to the header compression execution function entity according to the header compression capability or policy.
  • the header compression policy function entity is AAA, or PCRF;
  • the header compression policy function entity When the header compression policy function entity is a PCRF, the header compression policy function entity receives the header compression capability or policy sent by the network side as follows:
  • the PCRF receives the header compression capability or policy from the network side through AAA.
  • the header compression indication is a quality of service type indicating a QCI extension value, or a media type extension value, or a separate attribute value.
  • the header compression execution function entity further receives a control policy from the header compression policy function entity, where the control policy is that when the header compressed channel cannot be established, the service flow is not established, or an uncompressed service flow is established. .
  • the header compression policy function entity is a ROHC policy function entity
  • the header compression execution function entity is a ROHC execution function entity
  • the header compression channel parameter is a ROHC channel parameter.
  • the header compression channel is a ROHC channel.
  • the ROHC policy functional entity may be located in a terminal, a policy functional entity in the ASN, or a policy functional entity in the CSN.
  • the policy function entity in the ASN may include a base station, an anchor SFA, or an anchor DPF; the policy function entity in the CSN may include a PF, a PCRF, or an AAA server.
  • the ROHC executive function entity may be located in a terminal, a base station in an ASN, or a DPF.
  • One ROHC channel includes two ROHC execution functional entities, one ROHC execution function entity is a ROHC compressor, and the other ROHC execution function entity is a ROHC decompressor; and one ROHC execution function entity is located at the terminal, and another ROHC execution function entity A base station or DPF located in the ASN.
  • the ROHC policy function entity decides whether header compression is required according to the QoS requirements of the service flow and the available resources.
  • the terminal may determine the ROHC operation of the uplink service flow. If the ROHC policy function entity is located in the ASN domain, the downlink service may be determined by the BS or the anchor DPF in the ASN domain. Flow ROHC operation.
  • the establishment of the above ROHC channel includes the following four mapping methods:
  • the ROHC channel is established for a service flow, that is, the ROHC channel and the service flow are in a one-to-one mapping relationship.
  • the ROHC channel is established for one terminal, that is, one ROHC channel is established for each of the uplink service flow and the downlink service flow of one terminal.
  • the ROHC channel establishment mode has the advantages that: one terminal and the network side establish two ROHC channels for respectively carrying the uplink and downlink service flows of the terminal, which greatly simplifies the negotiation process of the ROHC channel parameters, and also simplifies the ROHC communication system.
  • the ROHC channel is established for a service scheduling type, that is, any type of service flow scheduling between the terminal and the network side, such as an Unsolicited Grant Service (UGS), and one for each of the uplink service flow and the downlink service flow.
  • the ROHC channel, the service flow belonging to the service flow scheduling type performing ROHC operation, is carried on the ROHC channel for transmission.
  • the ROHC execution function entity can negotiate which service flow scheduling type of service flow to perform ROHC operation.
  • the mapping between the ROHC channel and the link layer established in this way is between the first mode and the second mode.
  • the negotiation process of the ROHC channel parameters and the advantages of the ROHC communication system are avoided, and the The excessive granularity of the ROHC channel and link layer mapping leads to the disadvantage that the ROHC algorithm state machine is unstable.
  • the ROHC channel is established for the traffic flow scheduling type, and the other part is for The service flow establishes the ROHC channel.
  • the Extended Real-Time Polling Service ertPS
  • BE Best Effort
  • the ROHC channel is established based on the air interface scheduling type.
  • the terminal and the ASN may perform the ROHC channel through the DSA-REQ, DSA-RSP or DSC-REQ, DSC-RPSP message.
  • the terminal and the ASN may perform the ROHC channel through the DSA-REQ, DSA-RSP or DSC-REQ, DSC-RPSP message.
  • ROHC execution function entity When a ROHC execution function entity is located at the terminal, another ROHC execution function entity is located in the DPF in the ASN, and when the ROHC channel is established for one service flow SF, the terminal and the ASN may pass the RR-REQ
  • the RR-RSP message and one or more of the DSA-REQ, DSA-RSP, and DSC-REQ, DSC-RSP messages are negotiated for ROHC channel parameters.
  • ROHC execution function entity When a ROHC execution function entity is located at the terminal, another ROHC execution function entity is located in the DPF in the ASN, and when the ROHC channel is established for the uplink service flow and the downlink service flow for one terminal; or, when the ROHC When the channel is established for the traffic flow scheduling type, the terminal and the ASN pass SBC-REQ SBC-RSP and REG-REQ, one or more of the REG-RSP messages, and the NetEntry MS State Change REQ or NetEntry MS State Change RSP message.
  • the ROHC execution function entity that receives the header compression indication and the corresponding another ROHC execution function entity may perform the negotiation of the service flow scheduling type of the ROHC operation before establishing the ROHC channel.
  • the ROHC policy function entity sends the policy in different forms:
  • the CSN side sends the policy to the ASN based on the service flow, such as
  • the service flow such as
  • the allowed Head compression type is ROHC or other header compression mode
  • header compression feedback mode that is, whether feedback is needed, and whether the Packet-Flow or the data stream possessing this QoS is allowed to be used to carry feedback information of other data streams;
  • the policy sent by the CSN to the ASN is based on the terminal, such as adding a property for the terminal through the RADIUS message, including whether to allow header compression of the uplink and downlink data, The type of header compression allowed by the row data, whether the uplink and downlink data is allowed to carry feedback information, and whether the uplink and downlink data require feedback;
  • the policy sent by the CSN to the ASN is based on the service scheduling type. For example, by adding a list of attributes to the RADIUS message, the head is set for each type of service scheduling.
  • the compression-related attribute definition includes whether to allow header compression of the uplink and downlink data of the service type, the type of header compression allowed by the uplink and downlink data of the service type, whether the uplink/downlink data of the service type is allowed to carry feedback information, and the service type. Whether the uplink and downlink data requires feedback;
  • mapping method of the hybrid type the corresponding technical solution may be used for the specific mapping manner.
  • the ROHC channel parameters may include a maximum context identifier (MAX_CID), a context identifier length attribute (LARGE_CIDS), a format type set (PROFILES) of the data stream for which header compression is directed, a FEEDBACK_FOR, and a maximum reconstruction receiving unit (MRRU) One or more parameters in ).
  • the ROHC channel parameters can also be divided into fixed parameters of the ROHC channel and specific parameters of the ROHC channel. Where FEEDBACK-FOR is a specific parameter of the ROHC channel, and parameters other than the FEEDBACK-FOR parameter are fixed parameters of the ROHC channel.
  • the method further includes: negotiating the fixed parameter in the ROHC channel parameter by using the SBC-REQ, the SBC-RSP or the REG-REQ, the REG-RSP message;
  • the ROHC execution function entity that receives the header compression indication performs the ROHC channel parameter negotiation with the corresponding another ROHC execution function entity, and the negotiation of the specific parameter in the ROHC channel parameter may be performed by using the dynamic service flow message.
  • the method further includes: the terminal and the network side negotiate the ROHC channel mapping manner, and the negotiation process may be completed by using an SBC or REG message. Therefore, the header compression performing function entity that receives the header compression indication and the corresponding other header compression performing function entity may establish the ROHC channel by using the negotiated mapping manner of establishing the ROHC channel.
  • ROHC execution function entity When the ROHC channel is established for the traffic flow scheduling type, when a ROHC execution function entity receives information for establishing a ROHC channel for the traffic flow scheduling type, and which of the traffic flow scheduling types needs to perform the ROHC operation, the information is notified. The functional entity is executed for the corresponding other ROHC, after which the two ROHC performing functional entities negotiate the ROHC channel parameters based on the information.
  • Downlink ROHC Downlink service flow establishment
  • Step 301 The anchor SFA in the ASN (b) sends an RR-REQ message to the anchor DPF/serving SFA in the ASN (a), where the message includes indication information about whether to perform ROHC header compression for each service flow.
  • Step 302 The service SFA of the GW where the anchor DPF is located is determined according to whether the ROHC compression capability is provided by itself.
  • the RR-REQ or the path request (PR-REQ, Path-Reg-REQ) is sent to the BS.
  • the message carries the ROHC channel parameter, and the parameter may include one of the following parameters or a combination of multiple parameters: MAX—CID, LARGE—CIDS, PROFILES, FEEDBACK—FOR, MRRU.
  • Step 303 The BS sends a DSA-REQ or DSC-REQ message to the MS, where the message carries the ROHC channel parameter corresponding to the service flow.
  • Step 304 The MS sends a DSA-RSP or DSC-RSP message to the BS, where the message carries all or part of the ROHC channel parameters corresponding to the service flow.
  • Step 305 The BS sends a DSA-ACK or DSC-ACK message to the MS, and the step is an optional step.
  • Step 306 The BS sends an RR-RSP or Path-Reg-RSP message to the serving SFA, where the message includes all or part of the ROHC channel parameters corresponding to the service flow.
  • Step 307 The service SFA sends an RR-RSP message to the anchor SFA, where the message includes the result of establishing or modifying the service flow. So far, the ASN and the MS complete the negotiation of the ROHC channel parameters and establish a ROHC channel.
  • the ROHC function in the ASN is implemented on the anchor DPF. If the ROHC function in the ASN is implemented on the BS, the ROHC channel parameter is negotiated between the BS and the MS.
  • the message sent by the serving SFA to the BS includes whether to perform for each service flow SF. An indication of ROHC header compression, the message in step 306 does not include ROHC channel parameters.
  • the header compression policy function entity such as the anchor SFA
  • the header compression indication is sent to a compression execution function entity such as an anchor DPF
  • the indicated header compression execution function entity negotiates with the corresponding other header compression execution function entity, such as the terminal MS, for header compression channel parameters, establishes a header compression channel, saves wireless network resources, and improves service quality.
  • the policy of the header compression may be that the ASN sends the ASN header compression policy and the idle resource to the AAA server during the access authentication process of the MS.
  • the AAA server can further combine the policies maintained by the AAA server (such as the subscription policy of the MS and/or the policy of the AAA itself) to perform the header compression policy decision, and send the result of the header compression policy decision.
  • the ASN performs the result of the header compression policy decision. If the ASN has the header compression resource reported, but the result of the header compression policy decision is that header compression is not required, the ASN may release the header compression resource.
  • UpLink ROHC uplink service flow establishment
  • Step 401 The MS determines to perform a ROHC operation on a service flow, and sends a DSA/DSC-REQ message to the BS, where the message may carry the relevant ROHC channel parameter.
  • Step 402 The BS sends an RR-REQ or a Path-Reg-REQ message to the serving SFA, where the message may carry the ROHC channel parameter corresponding to the service flow SF.
  • Step 403 The service SFA sends an RR-REQ message to the anchor SFA, requesting to establish or modify a service flow.
  • the ROHC indication and/or the ROHC channel parameter can also be carried.
  • Step 404 The anchor SFA makes a decision on whether to perform an ROHC operation for the QoS requirements and resource usage of the service flow.
  • Step 405 the anchor SFA sends a service flow request message to the policy function entity in the CSN, requesting the policy function entity in the CSN to perform service flow establishment or modification.
  • the ROHC indication may also be carried in the service flow request message requesting the policy function entity in the CSN to make an ROHC decision.
  • the service flow request message can be forwarded by a proxy policy control point (PCEF).
  • PCEF proxy policy control point
  • the policy functional entities within the CSN include PF/PCRF, or a combination of proxy PCEF and PCRF.
  • Step 406 Optionally, after the policy function entity makes a decision, sending a service flow response message to the anchor SFA. If the policy function entity decides whether to perform ROHC operation, then the ROHC decision result message is returned at this time, and the message can be relayed through the proxy PCEF.
  • Step 407 The anchor SFA sends an RR-RSP message to the serving SFA, where the message carries the ROHC decision result information made by the anchor SFA or the policy function entity.
  • Step 408 The serving SFA sends an RR-RSP or Path-Reg-RSP message to the BS according to the received ROHC decision result, where the message may carry part of the ROHC channel parameter, such as a FEEDBACK_FOR parameter.
  • Step 409 The BS sends a DSA-RSP or DSC-RSP message to the MS, where the message may carry part of the ROHC channel parameter. So far, the MS and the ASN have completed the negotiation of the ROHC channel parameters.
  • Step 410 the MS sends a DSA-ACK or DSC-ACK message to the BS.
  • the ROHC channel parameters are in the MS and Negotiated between BSs.
  • the header compression indication is sent to the header compression execution function entity such as the base station BS;
  • the header compression execution function entity that receives the header compression indication negotiates with the corresponding other header compression execution function entity, such as the terminal MS, to establish a header compression channel, saves the radio network resources, and improves the quality of service.
  • Step 501 The policy function entity in the CSN may make a decision whether to perform the ROHC operation, and send an RR-REQ message to the anchor SFA, where the message may include an indication (Indication) of whether to perform the ROHC header compression operation. This message can be relayed through the proxy PCEF.
  • the policy function entities within the CSN include a combination of an AAA server, a PF/PCRF, or a proxy PCEF/PCRF.
  • the header compression policy decision process may further include: the ASN puts the ASN header in the access authentication process of the MS.
  • the compression policy and the idle resources are sent to the AAA server.
  • the ASN may reserve the header compression resources.
  • the AAA server may further combine the policies maintained by the AAA server (such as the MS subscription policy and/or the AAA itself).
  • the policy is to perform a header compression policy decision, and the result of the header compression policy decision is sent to the ASN, and the ASN performs the result of the header compression policy decision. If the ASN has a reserved header compression resource before, the decision result is that no header compression is required. , ASN can release the header compression resources.
  • the PCEF sends the header compression policy and the idle resource of the ASN to the PCRF in the process of initiating the service.
  • the PCEF may reserve the header compression resource, and after receiving the information, the PCRF may further combine the policies maintained by the PCRF (for example, The contracting strategy of the MS and/or the strategy of the PCRF itself) perform a header compression policy decision, and send the result of the header compression policy decision to the PCEF, and the PCEF performs the result of the header compression policy decision, if the PCEF has a reserved header compression resource before, but The decision result is Without header compression, the PCEF can release the header compression resources.
  • Step 502 The anchor SFA sends an RR-REQ message to the serving SFA.
  • the message may include an indication of whether to perform a ROHC header compression operation.
  • the anchor SFA may make a decision whether to perform ROHC header compression.
  • Step 503 The serving SFA sends an RR-REQ or Path-Reg-REQ message to the BS, where the indication may be included whether to perform ROHC header compression.
  • Step 504 The BS sends a DSA-REQ or DSC-REQ message to the MS, where the ROHC channel parameter and/or the indication of whether the ROHC header compression operation is performed is included.
  • the BS makes a decision whether to perform ROHC header compression.
  • Step 505 The MS negotiates with the BS according to the received ROHC channel parameter, and then the MS sends a DSA-RSP or DSC-RSP message to the BS, including some or all of the ROHC channel parameters.
  • Step 506 Optionally, the BS sends a DSA-ACK or DSC-ACK message to the MS.
  • Step 507 The BS completes ROHC channel parameter negotiation with the MS, and the BS sends an RR-RSP or Path-Reg-RSP message to the serving SFA.
  • Step 508 The service SFA sends an RR-RSP message to the anchor SFA, where the service flow establishment result information is included.
  • Step 509 The anchor SFA sends an RR-RSP message to the policy function entity, where the service flow establishment result is included. This message can be relayed through the proxy PCEF.
  • the ROHC function is implemented on the BS.
  • the service flow establishing process in this embodiment may be a preset service flow or a dynamic service flow establishment process triggered by the policy function entity.
  • the policy function entity in the CSN triggers the establishment of the service flow
  • the indication is sent to the base station BS, or directly by the policy function in the ASN.
  • the ROHC operation can be performed by the entity or the base station to decide, the ROHC channel parameters are negotiated by the base station BS and the MS, the header compressed channel is established, the wireless network resources are saved, and the service quality is improved.
  • ROHC channel parameters other than the FEEDBACK-FOR parameter can be considered as MS or ASN fixed capabilities.
  • the capability of the MS is unchanged, and the capability of the ASN remains unchanged until the handover. Therefore, the fixed parameters of the ROHC channel parameters other than FEEDBACK-FOR can be placed in the SBC-REQ, SBC-RSP message, or REG-REQ of the MS initial network access.
  • Negotiation is performed in the REG-RSP message. Referring to FIG. 6, when the MS is initially connected to the network, the specific implementation process of this embodiment is as follows:
  • Step 601 The MS searches for a downlink channel, and obtains a MAC synchronization and an uplink channel parameter by receiving a DL-MAP message.
  • Step 602 Perform an initial ranging (Ranging) process between the MS and the BS through RNG-REQ or RNG-RSP.
  • Step 603 The MS sends an SBC-REQ message to the BS, where the ROHC channel parameter is included.
  • Step 604 The BS sends a NetEntry MS State Change REQ message to the anchor DPF/serving SFA of the ASN-GW2, where the ROHC channel parameter is included.
  • Step 605 The anchor DPF/service SFA sends a NetEntry MS State Change RSP message to the BS, where the ROHC channel parameter is included.
  • Step 606 The BS sends an SBC-RSP message to the MS, where the ROHC channel parameter is included.
  • Step 607 The BS sends a NetEntry MS State Change ACK message to the anchor DPF/serving SFA.
  • Step 603 to step 607 the basic capability negotiation between the MS and the network side is implemented.
  • the message may be for the granularity of the ROHC channel, such as for the MS or for the type of service, including ROHC channel parameters other than FEEDBACK-FOR. If the ROHC function is implemented on the BS, only the ROC channel parameters are included in the SBC-REQ or SBC-RSP message.
  • Step 608 Perform a normal PKMv2 and Extensible Authentication Protocol (EAP) procedure between the MS and the network.
  • EAP Extensible Authentication Protocol
  • Step 609 The MS sends a REG-REQ message to the BS, where the ROHC channel parameter is included.
  • Step 610 The BS sends a NetEntry MS State Change REQ message to the anchor DPF/serving SFA, where the ROHC channel parameter is included.
  • Step 611 The anchor DPF/service SFA sends a NetEntry MS State Change RSP message to the BS, where the ROHC channel parameter is included.
  • Step 612 The BS sends a REG-RSP message to the MS, where the ROHC channel parameter is included.
  • Step 613 The BS sends a NetEntry MS State Change ACK message to the anchor DPF/serving SFA.
  • step 609 to step 613 the process of the MS registering with the network. If the ROHC channel parameter negotiation is not performed in steps 603 to 607, the ROHC channel parameter negotiation may be performed in the process from step 609 to step 613.
  • ROHC channels can be established between the MS and the ASN.
  • a plurality of ROHC channels are established; or a ROHC channel is partially established for the scheduling type, and a hybrid mode of the ROHC channel is partially established for the service flow SF.
  • the ROHC channel may be established based on the service flow.
  • the ROHC channel can be established based on the air interface scheduling type.
  • the decision whether or not to perform the ROHC operation is performed by the ROHC executive function entity, i.e., MS and/or ASN.
  • the context of the ROHC corresponds to a stream of IP quintuple identification.
  • the terminal does not specify the FEEDBACK_FOR parameter during the initial network access process, it can be specified by the dynamic service flow message in the subsequent service flow establishment process.
  • the ROHC channel parameters are negotiated by the MS and the ASN, the header compressed channel is established, the wireless network resources are saved, and the quality of service is improved.
  • Step 701 The ASN reports the ROHC support capability or policy of the terminal (such as the MS) and/or the ASN itself to the CSN, such as a PCRF, or an AAA server.
  • the PCRF When the PCRF is reported to the PCRF, the PCRF can receive the header compression capability or policy through the AAA.
  • the ASN first reports the information to the AAA server, and then the AAA server forwards the information to the PCRF.
  • the forwarding opportunity can be obtained by the AAA server.
  • the time of the information may also be the time when the AAA server receives the forwarding request of the PCRF.
  • Step 702 The AAA server or the PCRF determines whether the ASN and/or the terminal supports the ROHC according to the header compression capability or the policy, and when the service flow parameter is sent (the header includes the header compression indication), The header compression indication indicates whether the specific service flow requires ROHC compression.
  • the AAA server or the PCRF may also send a control policy at the same time as the service flow parameter is sent: If the ROHC channel cannot be established between the terminal and the ASN, the service flow is not established, or the ROHC attribute is ignored, and the non-ROHC compressed service is established. flow.
  • it includes not only the scenario when the service flow is initially established, but also the scenario where the network side header compression execution function entity re-establishes the service flow after migration.
  • Step 703 The ASN determines whether to perform header compression on a service flow according to different QCI extension values or media type extension values or other manner indication information. Meanwhile, the ASN determines, according to the control policy, that the service flow in the ROHC channel scenario cannot be established. Processing method.
  • the AAA determines whether the ROHC is required according to the capabilities of the MS and/or the ASN, and defines a processing scheme when the header compression channel cannot be established, which improves the establishment process of the ROHC channel, and reduces the The possibility that the ROHC channel cannot be established has increased The ROHC channel cannot establish the flexibility of the ASN process in the scenario.
  • a communication system includes: a header compression policy function entity, a first header compression execution function entity, and a second header compression execution function entity.
  • the header compression policy function entity is configured to: when the decision needs to perform header compression, outputting a header compression indication to the first header compression execution function entity or a second header compression execution function entity;
  • the function entity is configured to receive the header compression indication, and perform a header compression channel parameter negotiation with the second header compression execution function entity; the second header compression execution function entity receives the header compression indication, and the first The header compression execution function entity performs header compression channel parameter negotiation.
  • Head compression can be performed using a robust header compression mechanism, a CRTP header compression mechanism, or an ECRTP header compression mechanism.
  • the second header compression execution function entity is located in the base station or the anchor DPF in the ASN; when the second header compression execution function entity is located in the terminal, The first header compression execution function entity is located in the base station or anchor DPF in the ASN
  • the header compression policy function entity is located in the terminal, the policy function entity in the ASN, or the policy function entity in the connection service network CSN; the policy function entity in the ASN includes a base station, an anchor SFA or an anchor DPF; Policy function entities include PF PCRF or AAA service crying
  • the header compression policy function entity includes: a decision unit and a delivery unit;
  • the determining unit is configured to: determine whether the header compression is required according to the service quality requirement of the service flow and the available resource, and trigger the sending unit when the decision needs to perform header compression; When receiving the trigger of the decision unit, the header compression indication is sent to the first header compression execution function entity.
  • the header compression indication is sent to the first header compression execution function entity or the second header compression execution function entity;
  • the corresponding second header compression execution function entity performs head compression channel parameter negotiation, establishes a header compression channel, saves wireless network resources, and improves service quality.
  • the header compression execution function entity uses the robust header compression mechanism
  • the header compression policy function entity is a ROHC policy function entity
  • the first header compression execution function entity is a first ROHC execution function entity
  • the second The header compression execution function entity executes the functional entity for the second ROHC.
  • the system of the embodiment of the present invention includes: a ROHC policy function entity 71, a first ROHC execution function entity 72, and a corresponding second ROHC execution function entity 73;
  • the ROHC policy function entity 71 includes: a decision unit 711 and a sending unit 712; the first ROHC execution function entity 72 is a ROHC execution function entity, and the second ROHC execution function entity 73 is Another ROHC performs a function entity corresponding to the ROHC execution function entity 72, that is, one ROHC execution function entity is a compressor, that is, an entry of a ROHC channel, and another ROHC execution function entity is a decompressor, that is, an exit of the ROHC channel. .
  • the ROHC policy function entity 71 is configured to: when the decision needs to perform header compression, issue a header compression indication to the first ROHC execution function entity 72;
  • the first ROHC execution function entity 72 when receiving the header compression indication, performs ROHC channel parameter negotiation with the second ROHC execution function entity 73;
  • the second ROHC performs a function entity 73 for performing ROHC channel parameter negotiation with the first ROHC execution function entity 72.
  • the second ROHC execution function entity 73 is located in a base station or anchor data path entity DPF in the access service network ASN; when the second ROHC performs a functional entity
  • the first ROHC performing functional entity 72 is located in a base station or anchor data path entity DPF in the access service network ASN.
  • the ROHC policy function entity 73 is located at the terminal, a policy function entity in the ASN, or a policy function entity in the connection service network CSN;
  • the policy function entity in the ASN includes a base station, an anchor service flow licensor SFA or an anchor DPF; and the policy function entity in the CSN includes a PF, a PCRF or an AAA server.
  • the decision unit 711 decides whether header compression is required according to the service quality requirement of the service flow and the available resources, and when the decision requires header compression
  • the triggering unit 712 is triggered;
  • the sending unit 712 is configured to send a header compression indication to the first ROHC execution function entity 72 when receiving the trigger of the decision unit 711.
  • the ROHC channel may be established for one service flow SF, or established for one terminal; or, partially for service flow scheduling type establishment, partially for service flow establishment; or, for service flow scheduling type establishment.
  • the first ROHC execution function entity 72 When the first ROHC execution function entity 72 is located at the terminal, the second ROHC execution function entity 73 is located at the base station in the ASN, or the second ROHC execution function entity 73 is located at the terminal, the first ROHC execution function entity 72 When the base station is located in the ASN, the terminal and the ASN negotiate the ROHC channel parameters through DSA-REQ, DSA-RSP, DSC-REQ, DSC-RSP message or a predefined message.
  • the first ROHC execution function entity 72 When the first ROHC execution function entity 72 is located at the terminal, the second ROHC execution function entity 73 is located in the DPF in the ASN, or the second ROHC execution function entity 73 is located at the terminal, the first ROHC execution function entity 72
  • the terminal and the ASN pass the RR-REQ, the RR-RSP message, the DSA-REQ, the DSA-RSP, and the DSC-REQ.
  • the DSC-RSP message and one of the predefined messages are used to negotiate the ROHC channel parameters.
  • the first ROHC execution function entity 72 When the first ROHC execution function entity 72 is located at the terminal, the second ROHC execution function entity 73 is located in the DPF in the ASN, or the second ROHC execution function entity 73 is located at the terminal, the first ROHC execution function entity 72 When the DPF is located in the ASN, and when the ROHC channel is established for the uplink traffic flow and the downlink traffic flow for one terminal; or, when the ROHC channel is established for the traffic flow scheduling type, the terminal and the ASN
  • the ROHC channel parameters are negotiated by one of the SBC-REQ, SBC-RSP and SBC-REQ, SBC-RSP messages, and the NetEntry MS State Change REQ, NetEntry MS State Change RSP message.
  • the first ROHC When the ROHC channel is established for a traffic flow scheduling type, the first ROHC performs a function entity 73, and further performs a ROHC operation service flow scheduling type with the second ROHC execution function entity 73 before establishing the ROHC channel.
  • the ROHC channel parameters include fixed parameters of the ROHC channel and specific parameters of the ROHC channel;
  • the terminal When the first ROHC execution function entity 72 is located at the terminal, the terminal initially enters the network, the first ROHC execution function entity 72 and the second ROHC execution function entity 73, by SBC-REQ, SBC-RSP or REG- The REQ, REG-RSP message performs negotiation of fixed parameters of the ROHC channel;
  • the first ROHC execution function entity 72 when receiving the header compression indication, negotiates with the second ROHC execution function entity 73 for a specific parameter of the ROHC channel by using a dynamic service flow message.
  • the first ROHC execution function entity 72 When the first ROHC execution function entity 72 is located at the terminal, and the terminal initially enters the network, the first ROHC execution function entity 72 and the second ROHC execution function entity 73 negotiate the ROHC channel establishment through the SBC or REG message. the way.
  • the ROHC channel parameter includes one or more of the following parameters:
  • a technical solution for establishing a header compression communication is provided by the embodiment of the present invention.
  • the header compression policy function entity sends a header compression indication to a compression execution function entity
  • the header compression execution function entity and the corresponding other header compression execution function entity perform The negotiation of the header compression channel parameters establishes a header compression channel to implement header compression communication, which saves wireless network resources and improves service quality compared to a wireless network without a header compression mechanism.
  • the wireless network can be a Wimax network.
  • each type of header compression mechanism corresponds to a specific header compression indication
  • the negotiated parameters are also specific parameters corresponding to the compression mechanism.
  • the negotiated parameters are the parameters defined in the corresponding RFC.
  • the header compression execution function entity receives a header compression indication from the header compression policy function entity; the header compression execution function entity performs header compression channel parameter negotiation with a corresponding other header compression execution function entity to establish a header compression channel.
  • the above-mentioned storage medium may be a read only memory, a magnetic disk or an optical disk or the like.
  • the present invention cover the modifications and variations of the inventions

Description

建立头压缩通信的方法及系统、 头压缩策略功能实体 技术领域
本发明涉及通信技术领域， 尤其涉及建立头压缩通信的方法及系统、 头 压缩策略功能实体。
背景技术
由于物理条件的限制， 无线链路与有线链路相比， 传输速率较低， 而误 码率偏高。 当将网际协议（IP )技术应用在无线网络小区环境中时， 存在分组 头标开销过大的问题。 例如， 一个 IPv6语音通信分组， 用户真正需要的分组 净荷往往只占整个分组的 22%。 这样不仅浪费带宽， 还增大了由于分组出错 而导致的该分组被丟弃的概率。 若不釆取有效措施， 在浪费宝贵无线网络资 源的同时， 还会降低服务质量 ( QoS )。
釆用头压缩机制可以解决上述问题， 同时可保证 IP协议固有的灵活性。 头压缩机制可包括鲁棒性头标压缩（ROHC, Robust Header Compression ), 实 时传输协议头压缩 ( Real-time Transport Protocol Header Compression, CRTP ) 机制， 以及扩展实时传输协议头压缩 （Extended RTP Header Compression, ECRTP )机制等。
以 ROHC为例， ROHC是一种基于流的头标压缩方案。 在网络数据传输 过程中， 同一个流的分组中大部分头标域具有相同的域值。 ROHC机制在某 个流中取一个参考分组， 对于其他分组仅仅发送头标域中相对参考分组变化 的信息， 以达到压缩目的， 从而节省分组头标开销， 更加有效地利用带宽。 同时， ROHC 机制还通过控制反馈消息的频率和数量、 检测不同步的逻辑以 及差错校验等手段， 使该 ROHC机制具有高度的有效性和合理的鲁棒性。 因 此， ROHC机制提供了一种应用于高误码率和长时延链路的头标压缩机制。
通过 ROHC机制在无线网络中进行通信，需要建立 ROHC信道（ channel ), ROHC信道为一个逻辑信道， 在这个逻辑信道中， 入口是压缩器， 出口是解 压缩器， 压缩器和解压缩器——对应。 压缩器把原始数据进行头压缩以后通 过该逻辑信道发送给解压缩器。 该 ROHC信道为单向逻辑信道。 同时， 为了 支持双向压缩， 解压缩器必须能够给压缩器提供反馈信息， 因此 ROHC反馈 信道（ feedback channel )为承载所述反馈信息的逻辑信道， 入口是解压缩器， 出口是压缩器。
微波接入全球互通 ( Wimax, Worldwide Interoperability for Microwave Access )技术是基于电子和电气工程师协会（IEEE, Institute of Electrical and Electronics Engineers ) 802.16系列标准的无线城域网接入技术， 图 1为 Wimax 网络结构示意图， 其中， R1接口为无线空中接口， 其余接口均为有线接口。 如图所示， Wimax主要包含移动台（ MS , Mobile Station )/用户站（ SS , Subscribe Station )、接入服务网络（ ASN, Access Service Network )和连接服务网络（ CSN, Connectivity Service Network )„ MS/SS为终端， 用户使用该终端接入 Wimax 网络。 ASN为 Wimax用户终端提供无线接入服务， ASN包含了基站 ( BS, Base Station )和 ASN网关（ASN-GW, ASN Gate Way )两个网元， 一个 ASN 可被多个 CSN共享。 CSN为 Wimax用户终端提供 IP连接服务， 如基于位置 的业务、 多媒体多播业务、 广播业务和 IP多媒体子系统业务等。
但是， 现有技术并没有给出建立头压缩通信的方法。
发明内容
本发明实施例提供一种建立头压缩通信的方法及系统、 头压缩策略功能 实体， 用以解决现有技术中存在无法实现头压缩通信的问题。
本发明实施例提供的一种建立头压缩通信的方法包括：
头压缩执行功能实体收到来自头压缩策略功能实体的头压缩指示； 所述头压缩执行功能实体与对应的另一头压缩执行功能实体进行头压缩 信道参数协商， 建立头压缩信道。
本发明实施例提供的一种通信系统包括：
头压缩策略功能实体、 第一头压缩执行功能实体和第二头压缩执行功能 实体； 其中，
所述头压缩策略功能实体， 用于若决策需要进行头压缩， 下发头压缩指 示给所述第一头压缩执行功能实体或第二头压缩执行功能实体；
所述第一头压缩执行功能实体， 接收所述头压缩指示， 与所述第二头压 缩执行功能实体进行头压缩信道参数协商；
所述第二头压缩执行功能实体， 接收所述头压缩指示， 与所述第一头压 缩执行功能实体进行头压缩信道参数协商。
本发明实施例提供的头压缩策略功能实体， 包括： 决策单元和下发单元； 所述决策单元， 用于根据业务流的服务质量需求和可得资源情况决策需 要进行头压缩， 触发所述下发单元；
所述下发单元， 用于接收所述决策单元的触发， 下发头压缩指示给第一 头压缩执行功能实体或第二头压缩执行功能实体。
本发明实施例中当头压缩策略功能实体决策需要进行头压缩时， 下发头 压缩指示给头压缩执行功能实体； 收到头压缩指示的头压缩执行功能实体与 对应的另一头压缩执行功能实体进行头压缩信道参数协商， 建立头压缩信道， 节省无线网络资源， 并提高了服务质量。
附图说明
图 1为现有技术中 Wimax网络结构示意图；
图 2为本发明实施例提供的方法流程示意图；
图 3为本发明实施例提供的方法的具体实施例一的流程示意图； 图 4为本发明实施例提供的方法的具体实施例二的流程示意图； 图 5为本发明实施例提供的方法的具体实施例三的流程示意图； 图 6为本发明实施例提供的方法的具体实施例四的流程示意图； 图 7为本发明实施例提供的系统结构示意图；
图 8为本发明实施例提供的方法中头压缩策略功能实体确定头压缩策略 的流程示意图。 具体实施方式
在本发明实施例中， 当头压缩策略功能实体决策需要进行头压缩时， 下 发头压缩指示给头压缩执行功能实体； 收到头压缩指示的头压缩执行功能实 体与对应的另一头压缩执行功能实体进行头压缩信道参数协商， 其中， 上面 描述的两个头压缩执行功能实体是一个头压缩信道的两端。 也就是说， 一个 头压缩执行功能实体为压缩器， 即头压缩信道的入口， 另一个头压缩执行功 能实体为解压缩器， 即该头压缩信道的出口。 协商好头压缩信道参数后， 也 就是在上述两个头压缩执行功能实体之间建立头压缩信道， 进而可以实现头 压缩通信。
参见图 2, 本发明实施例建立头压缩通信的方法包括以下步骤：
步骤 201:当头压缩策略功能实体决策需要进行头压缩时， 下发头压缩指 示给头压缩执行功能实体。
步骤 202:收到头压缩指示的头压缩执行功能实体与对应的另一头压缩执 行功能实体进行头压缩信道参数协商， 建立头压缩信道。
本发明实施例通过当头压缩策略功能实体决策需要进行头压缩时， 下发 头压缩指示给头压缩执行功能实体； 收到头压缩指示的所述头压缩执行功能 实体与对应的另一头压缩执行功能实体进行头压缩信道参数协商， 建立头压 缩信道， 节省无线网络资源， 并提高了服务质量。
所述头压缩执行功能实体可以釆用 ROHC 机制、 CRTP 头压缩机制或 ECRTP头压缩机制。
所述头压缩执行功能实体可以位于终端中， 或接入服务网络 ASN中的基 站中或锚数据通路实体（DPF ) 中。 所述头压缩策略功能实体可以位于终端、 ASN中的策略功能实体， 或 CSN中的策略功能实体中； 所述 ASN中的策略 功能实体可以包括基站、 锚业务流授权者（ SFA ), 服务 SFA或锚 DPF; 所述 CSN中的策略功能实体可以包括策略功能实体（PF )、策略计费规则功能实体 ( PCRF )或认证、 授权和计费 （AAA )服务器。 本发明实施例中所述的锚数据通路实体 DPF、锚业务流授权者、服务 SFA 等实体是以逻辑功能实体为例进行说明， 具体组网中， 这些实体可以是单独 的物理实体， 也可以是作为逻辑功能实体集成在基站或网关中。
所述头压缩策略功能实体可以根据业务流的服务质量需求和可得资源情 况， 决策是否需要进行头压缩。
根据策略决策点的不同， 可以有如下几种场景，
1、 由连接服务网络 CSN 中的策略功能实体进行头压缩策略决策， ASN 中的策略功能实体可以把自身的头压缩策略和 /或空闲资源信息发送给连接服 务网络 CSN中的策略功能实体，由连接服务网络 CSN中的策略功能实体做出 头压缩的决策指示。
2、 或者， 由连接服务网络 CSN 中的策略功能实体自身进行头压缩策略 决策， 这种场景可能的原因包括不限于： ASN中的策略功能实体没有上报其 自身的头压缩策略和 /或空闲资源信息给 CSN中的策略功能实体， 或是 ASN 中的策略功能实体上报告知 CSN中的策略功能实体， 由 ASN中的策略功能 实体进行头压缩策略决策的优先级低于由 CSN中的策略功能实体进行头压缩 策略决策的优先级， 或是其它情况。
3、 或者， 连接服务网络 CSN 中的策略功能实体可以把自身的头压缩策 略和 /或空闲资源信息发送给 ASN中的策略功能实体， 由 ASN中的策略功能 实体做出头压缩的决策指示。
4、 或者， 由 ASN 中的策略功能实体自身进行头压缩策略决策， 这种场 景可能的原因包括不限于： CSN 中的策略功能实体没有下发其自身的头压缩 策略和 /或空闲资源信息给 ASN中的策略功能实体， 或是 CSN中的策略功能 实体下发告知 ASN中的策略功能实体， 由 CSN中的策略功能实体进行头压 缩策略决策的优先级低于由 ASN中的策略功能实体进行头压缩策略决策的优 先级， 或是其它情况。
所述釆用 ROHC机制进行头压缩时， 所述头压缩信道可根据如下映射方 式建立： 针对一个业务流建立； 或， 针对一个终端建立； 或， 部分针对业务 流调度类型建立， 部分针对业务流建立； 或， 针对业务流调度类型建立。
当一头压缩执行功能实体位于终端， 另一头压缩执行功能实体位于 ASN 中的基站时， 所述终端与 ASN 之间可以通过动态业务流建立请求 ( DSA-REQ ) , 动态业务流建立响应 （DSA-RSP )、 动态业务流修改请求 ( DSC-REQ ), 动态业务流修改请求响应（DSC-RSP )或预先定义的消息进行 头压缩信道参数的协商。
当一头压缩执行功能实体位于终端， 另一头压缩执行功能实体位于 ASN 中的锚数据通路实体 DPF中时， 且， 当所述头压缩信道是针对一个业务流建 立时， 所述终端与 ASN之间可通过资源预留请求（RR-REQ )、 资源预留响应 ( RR-RSP ) 消息、 DSA-REQ、 DSA-RSP, DSC-REQ, DSC-RSP或预先定义 的消息中的一个或多个进行头压缩信道参数的协商。
当一头压缩执行功能实体位于终端， 另一头压缩执行功能实体位于 ASN 中的锚数据通路实体 DPF中时， 且， 当所述头压缩信道是针对一个终端建立 时； 或， 当所述头压缩信道是针对业务流调度类型建立时， 所述终端与 ASN 可通过用户基本能力请求（SBC-REQ )、 用户基本能力响应 （SBC- RSP )、 注 册请求（REG-REQ )、 注册响应 （REG-RSP )或预先定义的消息中一个或多 个， 以及入网终端状态变更请求（ NetEntry MS State Change REQ )， 入网终端 状态变更响应（ NetEntry MS State Change ACK )消息， 协商头压缩信道参数。
当釆用 ROHC机制进行头压缩时， 当一头压缩执行功能实体位于终端， 并且该终端在初始入网时， 可以先通过 SBC-REQ, SBC-RSP, REG-REQ、 REG-RSP消息， 进行头压缩信道参数中固定参数的协商； 则收到头压缩指示 的头压缩执行功能实体与对应的另一头压缩执行功能实体可以通过动态业务 流消息进行头压缩信道参数中特定参数的协商。
当一头压缩执行功能实体位于终端， 并且该终端在初始入网时， 该方法 还包括： 协商所述终端与网络侧的建立头压缩信道的映射方式， 则收到头压 缩指示的头压缩执行功能实体与对应的另一头压缩执行功能实体利用所述协 商的建立头压缩信道的映射方式， 建立头压缩信道。 而且， 可以通过用户基 本能力 （SBC )或注册（REG ) 消息协商所述头压缩信道的映射方式。
所述头压缩执行功能实体收到来自头压缩策略功能实体的头压缩指示之 前进一步包括：
所述头压缩策略功能实体接收网络侧发送的终端的头压缩能力或策略， 和 /或网络侧所支持的头压缩能力或策略；
所述头压缩策略功能实体根据所述头压缩能力或策略， 确定并下发头压 缩指示给所述头压缩执行功能实体。
其中， 所述头压缩策略功能实体是 AAA, 或者 PCRF;
当所述头压缩策略功能实体是 PCRF 时， 所述头压缩策略功能实体接收 网络侧发送的所述头压缩能力或策略具体为：
所述 PCRF通过 AAA从网络侧接收所述头压缩能力或策略。
所述头压缩指示是服务质量类型指示 QCI扩展值，或者媒体类型扩展值， 或者单独属性值。
所述头压缩执行功能实体还收到来自所述头压缩策略功能实体的控制策 略， 其中， 所述控制策略为， 当头压缩信道不能建立时， 不建立该服务流， 或者建立非压缩的服务流。
当头压缩执行功能实体釆用鲁棒性头压缩机制时， 则所述头压缩策略功 能实体为 ROHC策略功能实体，头压缩执行功能实体为 ROHC执行功能实体， 所述头压缩信道参数为 ROHC信道参数， 所述头压缩信道为 ROHC信道。
以下以 ROHC机制为例说明本发明实施例的技术方案。
所述 ROHC 策略功能实体可以位于终端、 ASN 中的策略功能实体， 或 CSN 中的策略功能实体中。 所述 ASN 中的策略功能实体可以包括基站、 锚 SFA或锚 DPF; 所述 CSN中的策略功能实体可以包括 PF、 PCRF或 AAA服 务器。 所述 ROHC执行功能实体可以位于终端、 ASN中的基站或 DPF中。 一个 ROHC信道包括两个 ROHC执行功能实体，其中一个 ROHC执行功 能实体为 ROHC压缩器， 另外一个 ROHC执行功能实体为 ROHC解压缩器； 并且一个 ROHC执行功能实体位于终端， 而另外一个 ROHC执行功能实体位 于 ASN中的基站或 DPF。
所述 ROHC策略功能实体根据业务流的 QoS需求和可得资源情况， 决策 是否需要进行头压缩。 当所述 ROHC策略功能实体位于终端时， 则可以由终 端来决策上行业务流的 ROHC操作，如果所述 ROHC策略功能实体位于 ASN 域， 则可以由 ASN域中的 BS或锚 DPF来决策下行业务流的 ROHC操作。
上述 ROHC信道的建立包括以下四种映射方式：
一、 ROHC信道针对一个业务流建立， 即所述 ROHC信道和业务流为一对 一的映射关系。
二、 ROHC信道针对一个终端建立， 即对于一个终端的上行业务流和下行 业务流各建立一个 ROHC信道。
该 ROHC信道建立方式的优点在于： 一个终端与网络侧建立两条 ROHC信 道， 用于分别承载该终端的上下行业务流， 大大简化了 ROHC信道参数的协商 过程， 并且还简化了 ROHC通信系统。
三、 ROHC信道针对一个业务调度类型建立， 即终端和网络侧之间任意 一种业务流调度类型， 如主动授予业务（Unsolicited Grant Service ,UGS ) , 在 上行业务流和下行业务流上各建立一个 ROHC信道， 进行 ROHC操作的属于该 业务流调度类型的业务流都承载于该 ROHC信道上传输。 其中， ROHC执行功 能实体之间可以协商哪种业务流调度类型的业务流进行 ROHC操作。
釆用此种方式建立的 ROHC信道与链路层的映射的粒度介于方式一和方 式二之间， 既有方式二中简化 ROHC信道参数的协商过程以及 ROHC通信系统 的优点， 又避免了由于 ROHC信道与链路层映射的粒度过大导致 ROHC算法状 态机不稳定的缺点。
四、 混合方式： 部分针对业务流调度类型建立 ROHC信道， 另一部分针对 业务流建立 ROHC信道， 例如， 对于 UGS、 扩展实时轮询业务 （Extended Real-Time Polling Service, ertPS )可以基于业务流建立 ROHC信道， 对于其它 业务， 如尽力而为业务（Best Effort, BE )可以基于空口调度类型建立 ROHC 信道。
当一 ROHC执行功能实体位于终端， 另一 ROHC执行功能实体位于 ASN中 的基站时， 所述终端与 ASN之间可通过 DSA-REQ、 DSA- RSP或 DSC-REQ、 DSC- RSP消息进行 ROHC信道参数的协商。
当一 ROHC执行功能实体位于终端， 另一 ROHC执行功能实体位于 ASN中 的 DPF时， 且， 当所述 ROHC信道是针对一个业务流 SF建立时， 所述终端与 ASN之间可通过 RR-REQ、 RR-RSP消息以及 DSA-REQ、 DSA-RSP和 DSC-REQ、 DSC- RSP消息中一个或多个， 进行 ROHC信道参数的协商。
当一 ROHC执行功能实体位于终端， 另一 ROHC执行功能实体位于 ASN中 的 DPF时， 且， 当所述 ROHC信道是针对一个终端在上行业务流和下行业务流 上建立； 或， 当所述 ROHC信道是针对业务流调度类型建立时， 所述终端与 ASN通过 SBC-REQ SBC- RSP和 REG-REQ, REG-RSP消息中一个或多个， 以 及 NetEntry MS State Change REQ或 NetEntry MS State Change RSP消息协商 ROHC信道参数。
当所述 ROHC信道是针对业务流调度类型建立时， 收到头压缩指示的 ROHC执行功能实体与对应的另一 ROHC执行功能实体在建立 ROHC信道之 前， 可以进行 ROHC操作的业务流调度类型的协商。
依据上述四种映射关系， ROHC策略功能实体下发策略的形式也不相同： 当 ROHC信道的映射方式是针对在一个业务流建立时，则 CSN侧发送给 ASN的 策略就是基于业务流的， 如通过远程认证拨号用户服务器协议（RADIUS )消 息中 包流描述符 （ Packet-Flow Descriptor ) 或者业务质量描述符 ( QoS-Descriptor )属性中增加一个是否允许头压缩的子属性， 还可以明确指 出所允许的头压缩类型，是 ROHC还是其他头压缩模式， 以及头压缩的反馈模 式， 即是否需要反馈， 以及此 Packet-Flow或者拥有此 QoS的数据流是否允许被 用于承载其他数据流的反馈信息；
当 ROHC信道的映射方式是针对一个终端建立时，那么 CSN侧发送给 ASN 的策略就是基于终端的， 如通过 RADIUS消息中增加一个针对终端的属性， 包 括是否允许对上下行数据进行头压缩， 上下行数据所允许的头压缩的类型， 上下行数据是否允许承载反馈信息， 以及上下行数据是否需要反馈；
当 ROHC信道的映射方式是针对一个业务调度类型建立时，那么 CSN侧发 送给 ASN的策略就是基于业务调度类型的，如通过 RADIUS消息中增加一个属 性列表， 即针对每一种业务调度类型进行头压缩相关的属性定义， 包括是否 允许对该业务类型上下行数据进行头压缩， 该业务类型上下行数据所允许的 头压缩的类型， 该业务类型上下行数据是否允许承载反馈信息， 以及该业务 类型上下行数据是否需要反馈；
对于混合类型的映射方式， 可以分别针对具体的映射方式釆用对应的上 述技术方案即可。
所述 ROHC信道参数可以包括最大上下文标识（MAX— CID ) 、 上下文标 识的长短属性 （LARGE— CIDS ) 、 头压缩所针对的数据流的格式类型集合 ( PROFILES ) 、 FEEDBACK_FOR和最大重建接收单元（ MRRU ) 中的一种 或多种参数。 而 ROHC信道参数还可以分为 ROHC信道的固定参数和 ROHC信 道的特定参数。 其中 FEEDBACK— FOR为 ROHC信道的特定参数， 除 FEEDBACK— FOR参数以外的参数为 ROHC信道的固定参数。
当一 ROHC执行功能实体位于终端， 并且该终端在初始入网时， 进一步包 括： 可以通过 SBC-REQ、 SBC-RSP或 REG-REQ、 REG-RSP消息进行 ROHC信 道参数中的固定参数的协商；
则收到头压缩指示的 ROHC执行功能实体与对应的另一 ROHC执行功能 实体进行 ROHC信道参数协商包括： 可以通过动态业务流消息进行 ROHC信 道参数中的特定参数的协商。 在终端初始入网时， 该方法进一步包括： 终端和网络侧协商 ROHC信道 映射方式， 该协商过程可以通过 SBC或 REG消息完成。 因此， 收到头压缩指 示的头压缩执行功能实体与对应的另一头压缩执行功能实体可以利用所述协 商的建立 ROHC信道的映射方式， 建立所述 ROHC信道。
当所述 ROHC信道是针对业务流调度类型建立时， 当一 ROHC执行功能 实体收到针对业务流调度类型建立 ROHC信道， 以及其中哪个业务流调度类 型需要进行 ROHC操作的信息后， 将这些信息通知给对应的另一 ROHC执行 功能实体， 此后， 两个 ROHC执行功能实体再根据这些信息协商 ROHC信道 参数。
下面针对各种情况， 给出本发明实施例提供的几个具体实施例。
具体实施例一：
参见图 3 , 当网络侧发起下行业务流建立时（Downlink ROHC ), 本实施 例的具体实现过程如下：
步骤 301： ASN(b)中的锚 SFA向 ASN(a)中的锚 DPF/服务 SFA发送 RR-REQ 消息， 该消息中包括针对每个业务流是否进行 ROHC头压缩的指示信息。
步骤 302: 所述锚 DPF所在 GW的服务 SFA根据自身是否具备 ROHC压缩能 力进行决策， 当需要进行 ROHC头压缩时， 向 BS发送 RR-REQ或路径请求 ( PR-REQ, Path-Reg-REQ ) 消息， 该消息中携带 ROHC信道参数， 该参数可 以包括以下一种参数或多种参数的组合： MAX— CID , LARGE— CIDS , PROFILES, FEEDBACK— FOR, MRRU。
步骤 303: 所述 BS向 MS发送 DSA-REQ或 DSC-REQ消息， 该消息中携带业 务流对应的 ROHC信道参数。
步骤 304: 所述 MS向 BS发送 DSA-RSP或 DSC-RSP消息， 该消息中携带所 述业务流对应的全部或部分 ROHC信道参数。
步骤 305: 所述 BS向所述 MS发送 DSA-ACK或 DSC-ACK消息， 该步骤为 可选步骤。 步骤 306: 所述 BS向所述服务 SFA发送 RR-RSP或 Path-Reg-RSP消息，该消 息中包含所述业务流对应的全部或部分 ROHC信道参数。
步骤 307: 所述服务 SFA向所述锚 SFA发送 RR-RSP消息， 该消息中包括 所述业务流的建立或修改结果。 至此， ASN和所述 MS完成了 ROHC信道参数 的协商， 建立了 ROHC信道。
上述实施例中， ASN内的 ROHC功能在锚 DPF上实现。 若 ASN内的 ROHC 功能在 BS上实现， 则 ROHC信道参数是在 BS和 MS之间进行协商， 即步骤 302 中， 在服务 SFA向 BS发送的消息中包含的是针对每一个业务流 SF是否进行 ROHC头压缩的指示， 步骤 306中所述消息不包括 ROHC信道参数。
本发明实施例中， 当网络侧发起下行业务流建立时， 通过头压缩策略功 能实体如锚 SFA决策需要进行头压缩时， 下发头压缩指示给一头压缩执行功 能实体如锚 DPF; 收到头压缩指示的头压缩执行功能实体与对应的另一头压 缩执行功能实体如终端 MS 进行头压缩信道参数协商， 建立头压缩信道， 节 省无线网络资源， 并提高了服务质量。
进一步的，在本发明实施实例中， 头压缩的策略决策过程还可以是， ASN 在 MS的接入认证的过程中把 ASN的头压缩策略以及空闲资源发送给 AAA服 务器， 此时 ASN可能会预留头压缩资源， AAA服务器接收到这些信息后， 进 一步的还可结合 AAA服务器维护的策略 (如 MS的签约策略和 /或 AAA本身的策 略)进行头压缩策略决策， 把头压缩策略决策的结果发送给所述 ASN, 则 ASN 执行此头压缩策略决策的结果， 如果 ASN在上报有预留头压缩资源， 但头压 缩策略决策的结果为不需要进行头压缩， 则 ASN可以释放头压缩资源。
具体实施例二：
参见图 4 , 当 MS发起上行业务流建立时（ UpLink ROHC ), 本实施例的 具体步骤如下：
步骤 401 : MS决定对某业务流进行 ROHC操作，向 BS发送 DSA/DSC-REQ 消息， 该消息中可携带相关的 ROHC信道参数。 步骤 402: 所述 BS向服务 SFA发送 RR-REQ或 Path-Reg-REQ消息， 该 消息中可携带所述业务流 SF对应的 ROHC信道参数。
步骤 403： 所述服务 SFA向锚 SFA发送 RR-REQ消息 , 请求进行业务流 建立或者修改。 在该消息中， 还可以携带 ROHC指示和 /或 ROHC信道参数。
步骤 404:所述锚 SFA针对所述业务流的 QoS要求和资源使用情况， 作出 是否进行 ROHC操作的决策。
步骤 405: 可选地， 所述锚 SFA向 CSN内的策略功能实体发送业务流请 求消息， 请求所述 CSN内的策略功能实体进行业务流建立或者修改。 在该业 务流请求消息中也可以携带 ROHC指示，请求所述 CSN内的策略功能实体进 行 ROHC 决策。 该业务流请求消息可以通过代理策略控制执行点 （Policy Control Enforcement Point, PCEF ) 的转发。 CSN 内的策略功能实体包括 PF/PCRF, 或者代理 PCEF和 PCRF的组合。
步骤 406: 可选地， 所述策略功能实体做出决策后， 向所述锚 SFA发送 业务流响应消息。 若由策略功能实体决策是否进行 ROHC操作， 则此时返回 ROHC决策结果消息， 该消息可通过代理 PCEF中转。
步骤 407： 所述锚 SFA向所述服务 SFA发送 RR-RSP消息， 该消息中携 带所述锚 SFA或者策略功能实体做出的 ROHC决策结果信息。
步骤 408: 所述服务 SFA根据接收到的 ROHC决策结果， 向所述 BS发 送 RR-RSP或 Path-Reg-RSP消息， 该消息中可以携带部分 ROHC信道参数， 如 FEEDBACK— FOR参数。
步骤 409: 所述 BS向所述 MS发送 DSA-RSP或 DSC-RSP消息， 该消息 中可以携带部分 ROHC信道参数。 至此， 所述 MS和 ASN完成了 ROHC信 道参数的协商。
步骤 410: 可选地， 所述 MS向所述 BS发送 DSA-ACK或 DSC-ACK消 息。
若 ASN内的 ROHC功能在 BS上实现， 则 ROHC信道参数是在 MS和 BS之间进行协商的。
本发明实施例中，若头压缩策略功能实体如锚 SFA或是进一步的由 CSN 内的策略功能实体如 PCRF 决策需要进行头压缩时， 下发头压缩指示给头压 缩执行功能实体如基站 BS; 收到头压缩指示的头压缩执行功能实体与对应的 另一头压缩执行功能实体如终端 MS 进行头压缩信道参数协商， 建立头压缩 信道， 节省无线网络资源， 并提高了服务质量。
具体实施例三：
参见图 5, 当 CSN内的策略功能实体触发业务流建立时， 本实施例的具 体实现过程如下：
步骤 501 : CSN内的策略功能实体可以作出是否进行 ROHC操作的决策， 向锚 SFA发送 RR-REQ消息，该消息中可以包括是否进行 ROHC头压缩操作 的指示（Indication )。 该消息可以通过代理 PCEF中转。 CSN内的策略功能实 体包括 AAA服务器、 PF/PCRF, 或者代理 PCEF/PCRF的组合。
本发明实施例中， 进一步的， 所述 CSN内的策略功能实体作出是否进行 ROHC操作的决策之前， 头压缩的策略决策过程还可以进一步包括， ASN在 MS的接入认证过程中把 ASN的头压缩策略以及空闲资源发送给 AAA服务 器， 此时， ASN可能会预留头压缩资源， AAA服务器接收到这些信息后， 可 进一步结合 AAA服务器维护的策略 (如 MS的签约策略和 /或 AAA本身的策略) 进行头压缩策略决策，把头压缩策略决策的结果发送给所述 ASN, 则 ASN执 行此头压缩策略决策的结果， 如果 ASN之前有预留头压缩资源， 但决策结果 为不需要进行头压缩， 则 ASN可以释放头压缩资源。
或者， PCEF在发起业务的过程中把 ASN的头压缩策略以及空闲资源发 送给 PCRF, 此时， PCEF可能会预留头压缩资源， PCRF接收到这些信息后， 可进一步结合 PCRF维护的策略 (如 MS的签约策略和 /或 PCRF本身的策略） 进行头压缩策略决策， 把头压缩策略决策的结果发送给 PCEF, 则 PCEF执行 此头压缩策略决策的结果，如果 PCEF之前有预留头压缩资源，但决策结果为 不需要进行头压缩， 则 PCEF可以释放头压缩资源。
步骤 502: 所述锚 SFA向服务 SFA发送 RR-REQ消息。 该消息中可以包 括是否进行 ROHC头压缩操作的指示。
若所述锚 SFA接收到的所述 RR-REQ消息中， 不包含 ROHC头压缩指 示， 则所述锚 SFA可作出是否进行 ROHC头压缩的决策。
步骤 503: 所述服务 SFA向 BS发送 RR-REQ或 Path-Reg-REQ消息， 其 中可以包括所述是否进行 ROHC头压缩的指示。
步骤 504: 所述 BS向 MS发送 DSA-REQ 或 DSC-REQ消息， 其中包括 ROHC信道参数和 /或所述是否进行 ROHC头压缩操作的指示。
若所述 BS接收到的所述 RR-REQ或 Path-Reg-REQ消息中，不包含 ROHC 头压缩指示， 则所述 BS作出是否进行 ROHC头压缩的决策。
步骤 505: 所述 MS根据收到的 ROHC信道参数与所述 BS进行协商， 然 后所述 MS向所述 BS发送 DSA-RSP或 DSC-RSP消息，其中包括部分或全部 ROHC信道参数。
步骤 506: 可选地， 所述 BS向所述 MS发送 DSA-ACK或 DSC-ACK消 息。
步骤 507: 所述 BS完成与所述 MS之间的 ROHC信道参数协商， 所述 BS向所述服务 SFA发送 RR-RSP或 Path-Reg-RSP消息。
步骤 508: 所述服务 SFA向所述锚 SFA发送 RR-RSP消息， 其中包括业 务流建立结果信息。
步骤 509: 所述锚 SFA向所述策略功能实体发送 RR-RSP消息， 其中包 括所述业务流建立结果。 该消息可通过代理 PCEF中转。
本实施例中， ROHC功能在 BS上实现。 本实施例的业务流建立过程可以 为策略功能实体触发的预置业务流或动态业务流建立过程。
本发明实施例中， 当 CSN内的策略功能实体触发业务流建立时， 若决策 需要进行 ROHC操作， 则下发指示给基站 BS , 或是直接由 ASN内的策略功 能实体或基站来决策需要进行 ROHC操作， 由基站 BS和 MS协商 ROHC信 道参数， 建立头压缩信道， 节省无线网络资源， 并提高了服务质量。
具体实施例四：
除了 FEEDBACK— FOR参数以外的 ROHC信道参数都可以看成是 MS或 者 ASN固定的能力。 MS的能力不变， ASN的能力在切换之前都保持不变， 所以 ROHC信道参数除了 FEEDBACK— FOR以外的固定参数都可以放在 MS 初始入网的 SBC-REQ、 SBC-RSP消息， 或者 REG-REQ、 REG-RSP消息中进 行协商， 参见图 6, 当 MS初始入网时， 本实施例的具体实现过程如下：
步骤 601 : MS搜索下行信道， 通过接收 DL-MAP消息获取 MAC同步和 上行信道参数。
步骤 602: 所述 MS和 BS之间 , 通过 RNG-REQ或 RNG-RSP进行初始 测距（Ranging )过程。
步骤 603： 所述 MS向所述 BS发送 SBC-REQ消息， 其中包括 ROHC信 道参数。
步骤 604:所述 BS向 ASN-GW2的锚 DPF/服务 SFA发送 NetEntry MS State Change REQ消息， 其中包括所述 ROHC信道参数。
步骤 605：所述锚 DPF/服务 SFA向所述 BS发送 NetEntry MS State Change RSP消息， 其中包括所述 ROHC信道参数。
步骤 606:所述 BS向所述 MS发送 SBC- RSP消息，其中包括所述 ROHC 信道参数。
步骤 607:所述 BS向所述锚 DPF/服务 SFA发送 NetEntry MS State Change ACK消息。
步骤 603至步骤 607, 实现所述 MS和网络侧之间的基本能力协商。 所 述消息可以针对 ROHC信道的粒度， 如针对 MS 或针对业务类型， 包含除 FEEDBACK— FOR之外的 ROHC信道参数。 若 ROHC功能在 BS上实现， 则 仅所述 SBC-REQ或 SBC-RSP消息中包含 ROHC信道参数。 步骤 608: MS和网络之间进行正常的 PKMv2和可扩展认证协议 ( EAP ) 过程。
步骤 609: 所述 MS向所述 BS发送 REG-REQ消息， 其中包括 ROHC信 道参数。
步骤 610:所述 BS向所述锚 DPF/服务 SFA发送 NetEntry MS State Change REQ消息， 其中包括 ROHC信道参数。
步骤 611 :所述锚 DPF/服务 SFA向所述 BS发送 NetEntry MS State Change RSP消息， 其中包括 ROHC信道参数。
步骤 612: 所述 BS向所述 MS发送 REG-RSP消息， 其中包括 ROHC信 道参数。
步骤 613:所述 BS向所述锚 DPF/服务 SFA发送 NetEntry MS State Change ACK消息。
步骤 609至步骤 613的过程， MS向网络注册的过程。 若步骤 603至步骤 607中未进行 ROHC信道参数协商， 则可以在步骤 609至步骤 613的过程中 进行 ROHC信道参数的协商。
MS和 ASN之间可以建立多个 ROHC信道。 针对不同的 QoS调度类型， 建 立若干个 ROHC信道； 或者部分针对调度类型建立 ROHC信道， 部分针对业务 流 SF建立 ROHC信道的混合方式， 例如， 对于 UGS、 ertPS业务， 可以基于业 务流建立 ROHC信道，对于其它业务，如 BE,可以基于空口调度类型建立 ROHC 信道。
在本实施例中，是否进行 ROHC操作的决策由 ROHC执行功能实体完成， 即 MS和 /或 ASN。 ROHC的上下文对应于一个 IP五元组标识的流。对于终端 在初始入网过程中未指定 FEEDBACK— FOR参数的情况， 可以在后续的业务 流建立过程中通过动态业务流消息进行指定。
这样， 本发明实施例中， 由 MS和 ASN协商 ROHC信道参数， 建立头压 缩信道， 节省无线网络资源， 并提高了服务质量。 具体实施例五：
本实施例介绍头压缩策略功能实体确定头压缩策略的方法， 参见图 8。 步骤 701 : ASN把终端（如 MS )和 /或 ASN自身的 ROHC支持能力或策 略上报给 CSN, 如 PCRF, 或者 AAA服务器。
当上报给 PCRF时， PCRF可以通过 AAA接收所述头压缩能力或策略， 即 ASN先把这些信息上报给 AAA服务器，再由 AAA服务器把这些信息转发 给 PCRF,其中，转发时机可以是 AAA服务器获得信息的时刻，也可以是 AAA 服务器收到 PCRF的转发请求的时刻。
步骤 702: AAA服务器或者 PCRF根据所述头压缩能力或策略， 可以确 定出 ASN和 /或终端是否支持 ROHC,在下发服务流参数 (该参数中包含头压 缩指示） 的时候， 就可以在其中的头压缩指示中指示出具体服务流是否要求 ROHC压缩。
所述头压缩指示是服务质量类型指示 QCI扩展值，或者媒体类型扩展值， 或者单独属性值， 即， 用不同的取值来表示， 如使用 QCI=1表示 UGS业务， 同时 QCI=N+1表示需要头压缩的 UGS业务； N是一个固定常数。
AAA服务器或者 PCRF在下发服务流参数的同时， 还可以下发一个控制 策略： 如果终端和 ASN之间不能建立起 ROHC信道， 则不建立该服务流， 或 者忽略 ROHC属性， 建立非 ROHC压缩的服务流。 此处， 不仅包括服务流初 始建立时的场景， 也包括网络侧头压缩执行功能实体迁移后重新建立服务流 的场景。
步骤 703: ASN按照不同 QCI扩展值或者媒体类型扩展值或者其他方式 的指示信息， 来决定是否对某服务流进行头压缩； 同时， ASN依据控制策略， 来决策不能建立 ROHC信道场景中服务流的处理方式。
这样， 在本发明实施例中， 由 AAA依据 MS和 /或 ASN的能力确定是否 需要 ROHC, 以及定义了在无法建立头压缩信道的时候的处理方案， 完善了 ROHC 信道的建立过程， 减小了 ROHC 信道无法建立的可能性， 增加了在 ROHC信道无法建立场景中 ASN处理过程的灵活性。
本发明实施例的一种通信系统包括： 头压缩策略功能实体、 第一头压缩 执行功能实体和第二头压缩执行功能实体。 其中， 所述头压缩策略功能实体， 用于当决策需要进行头压缩时， 下发头压缩指示给所述第一头压缩执行功能 实体或第二头压缩执行功能实体； 所述第一头压缩执行功能实体， 接收所述 头压缩指示， 与所述第二头压缩执行功能实体进行头压缩信道参数协商； 所 述第二头压缩执行功能实体， 接收所述头压缩指示， 与所述第一头压缩执行 功能实体进行头压缩信道参数协商。
可以釆用鲁棒性头压缩机制、 CRTP头压缩机制或 ECRTP头压缩机制进 行头压缩。
当所述第一头压缩执行功能实体位于终端中时， 则所述第二头压缩执行 功能实体位于 ASN中的基站或锚 DPF; 当所述第二头压缩执行功能实体位于 终端时， 则所述第一头压缩执行功能实体位于 ASN中的基站或锚 DPF
所述头压缩策略功能实体位于终端、 ASN中的策略功能实体， 或连接服 务网络 CSN中的策略功能实体； 所述 ASN中的策略功能实体包括基站、 锚 SFA或锚 DPF ； 所述 CSN中的策略功能实体包括 PF PCRF或 AAA服务 哭
所述头压缩策略功能实体包括： 决策单元和下发单元；
所述决策单元， 用于根据业务流的服务质量需求和可得资源情况， 决策 是否需要进行头压缩， 并且， 当决策需要进行头压缩时， 触发所述下发单元； 所述下发单元， 用于接收到所述决策单元的触发时， 下发头压缩指示给 所述第一头压缩执行功能实体。
本发明实施例中， 若头压缩策略功能实体决策需要进行头压缩时， 下发 头压缩指示给第一头压缩执行功能实体或第二头压缩执行功能实体； 由第一 头压缩执行功能实体与对应的第二头压缩执行功能实体进行头压缩信道参数 协商， 建立头压缩信道， 节省无线网络资源， 并提高了服务质量。 而所述头压缩执行功能实体釆用鲁棒性头压缩机制时， 头压缩策略功能 实体为 ROHC策略功能实体， 所述第一头压缩执行功能实体为第一 ROHC执 行功能实体， 所述第二头压缩执行功能实体为第二 ROHC执行功能实体。
以下以釆用 ROHC头压缩机制为例， 说明本发明实施例的系统。
参见图 7 ,本发明实施例的系统包括： ROHC策略功能实体 71、第一 ROHC 执行功能实体 72和对应的第二 ROHC执行功能实体 73；
其中，所述 ROHC策略功能实体 71包括： 决策单元 711和下发单元 712; 所述第一 ROHC执行功能实体 72为一个 ROHC执行功能实体， 所述第 二 ROHC执行功能实体 73为与所述第一 ROHC执行功能实体 72对应的另一 ROHC执行功能实体，也就是说一个 ROHC执行功能实体为压缩器，即 ROHC 信道的入口， 另外一个 ROHC执行功能实体为解压缩器， 即该 ROHC信道的 出口。
所述 ROHC策略功能实体 71 , 用于当决策需要进行头压缩时， 下发头压 缩指示给所述第一 ROHC执行功能实体 72;
所述第一 ROHC执行功能实体 72, 收到所述头压缩指示时， 与所述第二 ROHC执行功能实体 73进行 ROHC信道参数协商；
所述第二 ROHC执行功能实体 73 ,用于与所述第一 ROHC执行功能实体 72进行 ROHC信道参数协商。
当所述第一 ROHC执行功能实体 72位于终端中时， 则所述第二 ROHC 执行功能实体 73位于接入服务网络 ASN中的基站或锚数据通路实体 DPF; 当所述第二 ROHC执行功能实体 73位于终端中时， 则所述第一 ROHC 执行功能实体 72位于接入服务网络 ASN中的基站或锚数据通路实体 DPF。
所述 ROHC策略功能实体 73位于终端、 ASN中的策略功能实体， 或连 接服务网络 CSN中的策略功能实体；
所述 ASN中的策略功能实体包括基站、锚业务流授权者 SFA或锚 DPF ； 所述 CSN中的策略功能实体包括 PF、 PCRF或 AAA服务器。 当所述 ROHC策略功能实体 71位于 ASN中的锚 DPF时， 所述决策单元 711 ,根据业务流的服务质量需求和可得资源情况，决策是否需要进行头压缩， 并且， 当决策需要进行头压缩时， 触发所述下发单元 712;
所述下发单元 712, 用于接收到所述决策单元 711的触发时， 下发头压缩 指示给所述第一 ROHC执行功能实体 72。
所述 ROHC信道可以是针对一个业务流 SF建立， 或针对一个终端建立； 或， 部分针对业务流调度类型建立， 部分针对业务流建立； 或， 针对业务流 调度类型建立。
当所述第一 ROHC执行功能实体 72位于终端， 所述第二 ROHC执行功 能实体 73位于 ASN中的基站，或者所述第二 ROHC执行功能实体 73位于终 端，所述第一 ROHC执行功能实体 72位于 ASN中的基站时，所述终端与 ASN 之间通过 DSA-REQ、 DSA-RSP, DSC-REQ、 DSC-RSP消息或预先定义的消 息进行 ROHC信道参数的协商。
当所述第一 ROHC执行功能实体 72位于终端， 所述第二 ROHC执行功 能实体 73位于 ASN中的 DPF,或者所述第二 ROHC执行功能实体 73位于终 端， 所述第一 ROHC执行功能实体 72位于 ASN中的 DPF时， 且， 当所述 ROHC信道是针对一个业务流建立时， 所述终端与 ASN之间通过 RR-REQ、 RR-RSP消息、 DSA-REQ、 DSA- RSP、 DSC-REQ, DSC-RSP消息以及预先 定义的消息中的一个， 进行 ROHC信道参数的协商。
当所述第一 ROHC执行功能实体 72位于终端， 所述第二 ROHC执行功 能实体 73位于 ASN中的 DPF,或者所述第二 ROHC执行功能实体 73位于终 端， 所述第一 ROHC执行功能实体 72位于 ASN中的 DPF时， 且， 当所述 ROHC信道是针对一个终端在上行业务流和下行业务流上建立； 或， 当所述 ROHC信道是针对业务流调度类型建立时， 所述终端与 ASN通过 SBC-REQ、 SBC-RSP和 SBC-REQ、 SBC-RSP消息中一个，以及 NetEntry MS State Change REQ、 NetEntry MS State Change RSP消息协商 ROHC信道参数。 当所述 ROHC信道是针对业务流调度类型建立时， 所述第一 ROHC执行 功能实体 73 ,在建立 ROHC信道之前， 进一步与所述第二 ROHC执行功能实 体 73进行 ROHC操作的业务流调度类型的协商。
所述 ROHC信道参数包括 ROHC信道的固定参数和 ROHC信道的特定参 数；
当所述第一 ROHC执行功能实体 72位于终端， 该终端初始入网时， 所述 第一 ROHC 执行功能实体 72 与所述第二 ROHC 执行功能实体 73 , 通过 SBC-REQ, SBC-RSP或 REG-REQ、 REG-RSP消息进行 ROHC信道的固定参 数的协商；
则所述第一 ROHC执行功能实体 72, 当收到所述头压缩指示时， 与所述 第二 ROHC执行功能实体 73通过动态业务流消息进行 ROHC信道的特定参 数的协商。
当所述第一 ROHC执行功能实体 72位于终端， 并且该终端初始入网时， 所述第一 ROHC执行功能实体 72与所述第二 ROHC执行功能实体 73 , 通过 SBC或 REG消息协商 ROHC信道建立的方式。
所述 ROHC信道参数包括以下一种或多种参数：
MAX— CID、 LARGE— CIDS、 PROFILES, FEEDBACK— FOR、 MRRU。 本发明实施例提供的一种建立头压缩通信的技术方案， 当头压缩策略功 能实体下发头压缩指示给一头压缩执行功能实体时， 该头压缩执行功能实体 与对应的另一头压缩执行功能实体进行头压缩信道参数的协商， 建立头压缩 信道， 实现头压缩通信， 相比没有釆用头压缩机制的无线网络来说， 节省无 线网络资源， 提高了服务质量。 并且， 所述无线网络可以为 Wimax网络。
当然， 本发明技术方案对于其它压缩机制， 例如 CRTP、 ECRTP等， 也 同样适用。 当然， 每种头压缩机制对应特定的头压缩的指示， 而协商的参数 也是压缩机制对应的特定参数。 例如， 对于 CRTP或 ECRTP压缩机制， 协商 的参数为对应的 RFC中定义的参数。 本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤 是可以通过程序来指令相关的硬件完成， 所述的程序可以存储于一种计算机 可读存储介质中， 该程序在执行时， 包括如下步骤：
头压缩执行功能实体收到来自头压缩策略功能实体的头压缩指示； 所述头压缩执行功能实体与对应的另一头压缩执行功能实体进行头压缩 信道参数协商， 建立头压缩信道。
上述提到的存储介质可以是只读存储器， 磁盘或光盘等。 发明的精神和范围。 这样， 倘若本发明的这些修改和变型属于本发明权利要 求及其等同技术的范围之内， 则本发明也意图包含这些改动和变型在内。

Claims

权利 要 求 书
1、 一种建立头压缩通信的方法， 其特征在于， 该方法包括：
头压缩执行功能实体收到来自头压缩策略功能实体的头压缩指示； 所述头压缩执行功能实体与对应的另一头压缩执行功能实体进行头压缩信 道参数协商， 建立头压缩信道。
2、 根据权利要求 1所述的方法， 其特征在于， 所述头压缩是釆用鲁棒性头 压缩 ROHC机制、 实时传输协议 CRTP头压缩机制或扩展实时传输协议 ECRTP 头压缩机制。
3、 根据权利要求 1所述的方法， 其特征在于， 所述头压缩执行功能实体和 另一头压缩执行功能实体中的一个位于终端中， 另一个位于接入服务网络 ASN 中的基站中， 或锚数据通路实体 DPF中。
4、 根据权利要求 1所述的方法， 其特征在于， 所述头压缩策略功能实体位 于终端、 ASN中的策略功能实体， 或连接服务网络 CSN中的策略功能实体中； 所述 ASN中的策略功能实体包括基站、 锚业务流授权者， 服务业务授权者 或锚 DPF;
所述 CSN中的策略功能实体包括策略功能实体 PF、策略计费规则功能实体 PCRF, 或认证、 授权和计费 AAA服务器。
5、 根据权利要求 1所述的方法， 其特征在于， 所述头压缩执行功能实体收 到来自头压缩策略功能实体的头压缩指示前进一步包括：
所述头压缩策略功能实体根据业务流的服务质量需求和可得资源情况决策 需要进行头压缩；
所述头压缩策略功能实体下发头压缩指示给所述头压缩执行功能实体。
6、 根据权利要求 5所述的方法， 其特征在于， 所述头压缩策略功能实体根 据业务流的服务质量需求和可得资源情况决策需要进行头压缩具体包括：
ASN 中的策略功能实体把自身的头压缩策略和 /或空闲资源信息发送给 CSN中的策略功能实体， 由 CSN中的策略功能实体做出头压缩的决策指示。
7、 根据权利要求 5所述的方法， 其特征在于， 所述头压缩策略功能实体根 据业务流的服务质量需求和可得资源情况决策需要进行头压缩具体包括：
CSN 中的策略功能实体把自身的头压缩策略和 /或空闲资源信息发送给 ASN中的策略功能实体， 由 ASN中的策略功能实体做出头压缩的决策指示。
8、 根据权利要求 2所述的方法， 其特征在于， 所述头压缩釆用 ROHC机制 时， 所述头压缩信道是根据如下映射方式建立：
针对一个业务流建立； 或，
针对一个终端建立； 或，
部分针对业务流调度类型建立， 部分针对业务流建立； 或，
针对业务流调度类型建立。
9、 根据权利要求 3所述的方法， 其特征在于， 若所述头压缩执行功能实体 位于终端， 所述另一头压缩执行功能实体位于 ASN中的基站， 则
所述终端与 ASN之间通过动态业务流建立请求 /响应 DSA-REQ/RSP、 动态 业务流修改请求 /响应 DSC-REQ/RSP或预先定义的消息中的一个或多个， 进行 头压缩信道参数的协商。
10、 根据权利要求 3或 8所述的方法， 其特征在于， 若所述头压缩执行功 能实体位于终端， 所述另一头压缩执行功能实体位于 ASN中的锚数据通路实体 DPF中， 且， 若所述头压缩信道是针对一个业务流建立， 则
所述终端与 ASN 之间通过资源预留请求 /响应 RR-REQ/RSP 消息、 DSA-REQ/RSP和 DSC-REQ/RSP或预先定义的消息中的一个或多个， 进行头压 缩信道参数的协商。
11、 根据权利要求 3或 8所述的方法， 其特征在于， 若所述头压缩执行功 能实体位于终端， 所述另一头压缩执行功能实体位于 ASN中的锚数据通路实体 DPF 中， 且， 若所述头压缩信道是针对一个终端建立或所述头压缩信道是针对 业务流调度类型建立， 则 所述终端与 ASN通过用户基本能力请求 /响应 SBC-REQ/RSP、 注册请求 / 响应 REG-REQ/RSP或预先定义的消息中一个或多个，以及入网终端状态变更请 求 /响应消息协商头压缩信道参数。
12、 根据权利要求 2或 3所述的方法， 其特征在于， 所述头压缩是 ROHC 机制， 若头压缩执行功能实体位于终端， 在该终端在初始入网时， 进一步包括： 通过 SBC-REQ/RSP或 REG-REQ/RSP消息进行头压缩信道参数的协商； 则收到头压缩指示的头压缩执行功能实体与对应的另一头压缩执行功能实 体进行头压缩信道参数协商包括：
通过动态业务流消息进行头压缩信道参数中特定参数的协商。
13、 根据权利要求 3 所述的方法， 其特征在于， 若头压缩执行功能实体位 于终端， 在该终端在初始入网时， 该方法还包括：
协商所述终端与网络侧的建立头压缩信道的映射方式，
则收到头压缩指示的头压缩执行功能实体与对应的另一头压缩执行功能实 体利用所述协商的建立头压缩信道的映射方式， 建立头压缩信道。
14、 根据权利要求 13 所述的方法， 其特征在于， 通过用户基本能力 SBC 或注册 REG消息协商所述头压缩信道的映射方式。
15、 根据权利要求 1 所述的方法， 其特征在于， 所述头压缩执行功能实体 收到来自头压缩策略功能实体的头压缩指示之前进一步包括：
所述头压缩策略功能实体接收网络侧发送的终端的头压缩能力或策略， 和 / 或网络侧所支持的头压缩能力或策略；
所述头压缩策略功能实体根据所述头压缩能力或策略， 确定并下发头压缩 指示给所述头压缩执行功能实体。
16、 根据权利要求 15所述的方法， 其特征在于， 所述头压缩策略功能实体 是 AAA, 或者 PCRF;
当所述头压缩策略功能实体是 PCRF 时， 所述头压缩策略功能实体接收网 络侧发送的所述头压缩能力或策略具体为： 所述 PCRF通过 AAA从网络侧接收所述头压缩能力或策略。
17、 根据权利要求 15所述的方法， 其特征在于， 所述头压缩指示是服务质 量类型指示 QCI扩展值， 或者媒体类型扩展值， 或者单独属性值。
18、 根据权利要求 1 所述的方法， 其特征在于， 所述头压缩执行功能实体 还收到来自所述头压缩策略功能实体的控制策略， 其中，
所述控制策略为， 当头压缩信道不能建立时， 不建立该服务流， 或者建立 非压缩的服务流。
19、 一种通信系统， 其特征在于， 该系统包括：
头压缩策略功能实体、 第一头压缩执行功能实体和第二头压缩执行功能实 体； 其中，
所述头压缩策略功能实体， 用于若决策需要进行头压缩， 下发头压缩指示 给所述第一头压缩执行功能实体或第二头压缩执行功能实体；
所述第一头压缩执行功能实体， 接收所述头压缩指示， 与所述第二头压缩 执行功能实体进行头压缩信道参数协商；
所述第二头压缩执行功能实体， 接收所述头压缩指示， 与所述第一头压缩 执行功能实体进行头压缩信道参数协商。
20、 根据权利要求 19所述的系统， 其特征在于， 若所述第一头压缩执行功 能实体位于终端中， 则所述第二头压缩执行功能实体位于 ASN 中的基站或锚 DPF; 或
若所述第二头压缩执行功能实体位于终端中， 则所述第一头压缩执行功能 实体位于 ASN中的基站或锚 DPF。
21、 根据权利要求 19所述的系统， 其特征在于， 所述头压缩策略功能实体 位于终端、 ASN中的策略功能实体， 或连接服务网络 CSN中的策略功能实体； 所述 ASN中的策略功能实体包括基站、 锚 SFA或锚 DPF ；
所述 CSN中的策略功能实体包括 PF、 PCRF或 AAA服务器。
22、 一种头压缩策略功能实体， 其特征在于， 包括： 决策单元和下发单元； 所述决策单元， 用于根据业务流的服务质量需求和可得资源情况决策需要 进行头压缩， 触发所述下发单元；
所述下发单元， 用于接收所述决策单元的触发， 下发头压缩指示给第一头 压缩执行功能实体或第二头压缩执行功能实体。
PCT/CN2008/071476 2007-08-10 2008-06-27 Procédé et système permettant d'établir une communication à compression d'en-tête, et entité fonctionnelle de politique de compression d'en-tête WO2009021422A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/698,397 US8223797B2 (en) 2007-08-10 2010-02-02 Method and system for setting up header compression communication, header compression policy function entity

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN200710141595.2 2007-08-10
CN200710141595 2007-08-10
CN200810082634.0 2008-02-27
CN2008100826340A CN101364980B (zh) 2007-08-10 2008-02-27 建立头压缩通信的方法及系统、头压缩策略功能实体

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/698,397 Continuation US8223797B2 (en) 2007-08-10 2010-02-02 Method and system for setting up header compression communication, header compression policy function entity

Publications (1)

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

Family

ID=40350374

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/071476 WO2009021422A1 (fr) 2007-08-10 2008-06-27 Procédé et système permettant d'établir une communication à compression d'en-tête, et entité fonctionnelle de politique de compression d'en-tête

Country Status (1)

Country Link
WO (1) WO2009021422A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110069659A1 (en) * 2009-09-18 2011-03-24 Samsung Electronics Co. Ltd. Method and apparatus for providing local breakout service in wireless communication system
EP4135442A4 (en) * 2020-04-21 2023-04-26 Guangdong Oppo Mobile Telecommunications Corp., Ltd. COMMUNICATION PROCESS AND ASSOCIATED MECHANISM

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1615618A (zh) * 2002-08-14 2005-05-11 Lg电子株式会社 双向分包数据传输系统和方法
US20070098016A1 (en) * 2005-10-27 2007-05-03 Rohit Kapoor System and method for improving robust header compression (ROHC) efficiency
WO2007065300A1 (en) * 2005-12-08 2007-06-14 Intel Corporation A header compress/decompress framework
US20070195764A1 (en) * 2006-02-22 2007-08-23 Nortel Networks Limited Service Flow with Robust Header Compression (ROHC) in a WiMAX Wireless Network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1615618A (zh) * 2002-08-14 2005-05-11 Lg电子株式会社 双向分包数据传输系统和方法
US20070098016A1 (en) * 2005-10-27 2007-05-03 Rohit Kapoor System and method for improving robust header compression (ROHC) efficiency
WO2007065300A1 (en) * 2005-12-08 2007-06-14 Intel Corporation A header compress/decompress framework
US20070195764A1 (en) * 2006-02-22 2007-08-23 Nortel Networks Limited Service Flow with Robust Header Compression (ROHC) in a WiMAX Wireless Network

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110069659A1 (en) * 2009-09-18 2011-03-24 Samsung Electronics Co. Ltd. Method and apparatus for providing local breakout service in wireless communication system
US9241297B2 (en) * 2009-09-18 2016-01-19 Samsung Electronics Co., Ltd. Method and apparatus for providing local breakout service in wireless communication system
EP4135442A4 (en) * 2020-04-21 2023-04-26 Guangdong Oppo Mobile Telecommunications Corp., Ltd. COMMUNICATION PROCESS AND ASSOCIATED MECHANISM

Similar Documents

Publication Publication Date Title
CN101364980B (zh) 建立头压缩通信的方法及系统、头压缩策略功能实体
JP5070334B2 (ja) モバイルサブスクライバステーションのためのｖｏｉｐ呼をサポートする装置
TWI754244B (zh) Pdu會話的管理方法和使用者設備
US8811161B2 (en) Method of creating and deleting service flow for robust header compression, and wireless communication system supporting the same
JP5806394B2 (ja) データストリーム伝送方法及び関連設備、システム
EP2363979B1 (en) Call establishment and maintenance in a wireless network
EP1869934B1 (en) Method of communication supporting media independent handover
US20080273520A1 (en) NETWORK ARCHITECTURE FOR DYNAMICALLY SETTING END-TO-END QUALITY OF SERVICE (QoS) IN A BROADBAND WIRELESS COMMUNICATION SYSTEM
US20060028986A1 (en) Packet processing apparatus and method in a portable Internet system
WO2011134329A1 (zh) 一种小数据包传输的方法和系统
WO2013131458A1 (zh) 一种ip数据包的传输方法和设备
JP2005510131A6 (ja) ＩＥＥＥ８０２．１１ｅＭＡＣのためのサービス品質シグナリングを提供する装置および方法
WO2011054241A1 (zh) 一种通过业务卸载功能（tof）实体保持业务连续性的方法、装置
WO2019196788A1 (zh) 通信方法和通信装置
WO2010124471A1 (zh) 一种数据传输的方法、装置
JP2024506094A (ja) ハンドオーバ手順に基づくメッセージ送信方法、装置、機器及びプログラム
WO2010006493A1 (zh) 动态业务流的处理方法及系统
WO2009021422A1 (fr) Procédé et système permettant d'établir une communication à compression d'en-tête, et entité fonctionnelle de politique de compression d'en-tête
KR100901206B1 (ko) 기지국과 네트워크 개체간의 서비스 품질 보장이 가능한데이터 교환방법
KR20080098313A (ko) 종단 간 동적 서비스 품질 설정을 위한 통신 네트워크 구조
KR20090074408A (ko) 광대역 무선통신 시스템에서 동적 서비스 품질 설정 시스템및 방법
US9253706B2 (en) Method, apparatus, and system for local routing authorization
WO2010127490A1 (zh) 实现本地路由的方法、装置及系统
Wang et al. Architecture of IMS over WiMAX PCC and the QoS mechanism
WO2022166559A1 (zh) 通信方法及装置

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: 08757875

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 282/KOLNP/2010

Country of ref document: IN

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08757875

Country of ref document: EP

Kind code of ref document: A1