WO2008095394A1 - Procédé et dispositif de transmission et de réception de données entre un contrôleur de réseau radio et un noeud de station - Google Patents

Procédé et dispositif de transmission et de réception de données entre un contrôleur de réseau radio et un noeud de station Download PDF

Info

Publication number
WO2008095394A1
WO2008095394A1 PCT/CN2007/071021 CN2007071021W WO2008095394A1 WO 2008095394 A1 WO2008095394 A1 WO 2008095394A1 CN 2007071021 W CN2007071021 W CN 2007071021W WO 2008095394 A1 WO2008095394 A1 WO 2008095394A1
Authority
WO
WIPO (PCT)
Prior art keywords
multiplexing
pdu
udp packet
payload
udp
Prior art date
Application number
PCT/CN2007/071021
Other languages
English (en)
French (fr)
Inventor
Zhichang Lai
Shengyi Qin
Chengxu Guo
Haiqing Lan
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.
Priority to EP07817212A priority Critical patent/EP2053798B1/en
Priority to ES07817212T priority patent/ES2399929T3/es
Publication of WO2008095394A1 publication Critical patent/WO2008095394A1/zh

Links

Classifications

    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • 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
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/04—Interfaces between hierarchically different network devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/04—Interfaces between hierarchically different network devices
    • H04W92/12—Interfaces between hierarchically different network devices between access points and access point controllers

Definitions

  • the present invention relates to the field of wireless communications, and in particular to a user plane data transmission technique between a radio network controller and a base station node.
  • the Universal Mobile Telecommunications System is a third-generation mobile communication system using Wideband Code Division Multiple Access (WCDMA) air interface technology, usually also a UMTS system.
  • WCDMA Wideband Code Division Multiple Access
  • the UMTS system adopts a structure similar to that of the second generation mobile communication system, including a Radio Access Network ("RAN") and a Core Network (“CN").
  • the wireless access network is used to handle all wireless related functions, and the CN handles all voice calls and data connections in the UMTS system and implements switching and routing functions with the external network.
  • the CN is logically divided into a Circuit Switched Domain ("CS") and a Packet Switched Domain (“PS”).
  • UMTS Terrestrial Radio Access Network (UMTS) "), CN and User Equipment (“UE”) together constitute the entire UMTS system.
  • UTRAN The structure of UTRAN is shown in Figure 1, which contains one or several wireless network subsystems (Radio).
  • Radio wireless network subsystems
  • RNS Network Subsystem
  • An RNS consists of a Radio Network Controller ("RNC") and one or more base stations (Node B).
  • RNC Radio Network Controller
  • Node B The interface between the RNC and the CN is the Iu interface, and the interface between the Node B and the RNC is the Iub interface.
  • the RNCs are interconnected via the Iur interface, and the Iur can be connected via a direct physical connection between the RNCs or via a transport network.
  • the RNC is used to allocate and control the radio resources of the Node B connected or related to it.
  • the Node B completes the data stream conversion between the Iub interface and the Uu interface, and also participates in some wireless resource management.
  • the RNC is used to control the radio resources of the UTRAN, and mainly completes the Radio Resource Control ("RRC") connection establishment and disconnection, handover, macro diversity, and radio resources. Source management and other functions. details as follows:
  • RRC Radio Resource Control
  • Switching and service RNC Service RNC, referred to as "SRNC" migration and other mobility management functions
  • Radio resource management and control functions such as macro diversity combining, power control, and radio bearer allocation.
  • Node B is the base station (i.e., wireless transceiver) of the WCDMA system, including the wireless transceiver and baseband processing components.
  • the physical layer protocol of the Uu interface is mainly processed through the standard lub interface and the RNC interconnection. Its main functions are spread spectrum, modulation, channel coding and despreading, demodulation, channel decoding, and also the function of mutual conversion of baseband signals and radio frequency signals.
  • the lub interface protocol stack structure is shown in Figure 2, which is divided into wireless network control planes ( Radio Network
  • the bearer layer has Asynchronous Transfer Mode (ATM) transmission and Internet Protocol (Internet Protocol, referred to as "Internet Protocol”). IP”) transmission in two ways.
  • ATM Asynchronous Transfer Mode
  • IP Internet Protocol
  • the transport layer of the wireless network control plane uses the Service Specific Coordination Function - User Network Interface (SSCF-UNI) / the specific service connection oriented protocol (Special Service Connect Oriented Protocol) , referred to as "SSCOP") / ATM Adaptation Layer Type 5 (AAL5) / ATM, the access network control application part (Access Link Control Application Part, referred to as "ALCAP" ) /SSCF-UNI/SSCOP/AAL5/ATM, the user plane transport layer uses ATM Adaptation Layer Type 2 (AAL2" /ATM 0
  • the transport layer of the wireless network control plane uses the Stream Control Transmission Protocol ("SCTP") / IP/Data Link Layer (data link layer), and the user plane transport layer uses the user data protocol ( User Datagram Protocol (abbreviated as "UDP”) /IP/Data Link Layer, no transport network control plane.
  • SCTP Stream Control Transmission Protocol
  • UDP User Datagram Protocol
  • FP Frame Protocol
  • RACH Random Access Channel
  • PCH Paging Channel
  • FACH Forward Access Channel
  • DCH Dedicated Channel
  • HS-DSCH High Speed Downlink The High Speed Downlink Shared Channel
  • DSCH Downlink Shared Channel
  • the UE's voice and data are encapsulated in various FP frames and transmitted over the Iub interface using the transport layer (ATM or IP) function.
  • ATM transport layer
  • WCDMA voice services include narrowband adaptive multi-rate (Adaptive Multi- Rate, abbreviated
  • AMR and wideband AMR, narrowband AMR includes 12.2k / 10.2k / 7.95k / 7.4k / 6.7k / 5.9k / 4.75k and other rates, broadband AMR based on 16kHz sampling rate, including between 6.6k and 23.85k 9 rates, the most commonly used is the narrowband AMR 12.2kbps.
  • Data traffic rates include 8k/16k/32k/64k/128k/144k/256k/384k/2048k and so on. Due to the high rate of data services supported by WCDMA, the bandwidth of the bearer layer required for data services is much larger than that of voice services.
  • Backhaul transmission resources from Node B to RNC are always the most valuable resources for operators. According to statistics, the cost of backhaul transmission accounts for more than 30% of the operating costs of wireless network operators. Therefore, improving the transmission efficiency of the Iub interface and maximizing the use of transmission resources have always been one of the operators' concerns.
  • the operator can use the Hub Node B or the existing ATM transmission network resources, and pass the virtual path (Virtual Path, referred to as "VP").
  • the virtual channel (Virtual Channel, referred to as "VC") exchange implements statistical multiplexing of Iub interface services, improves transmission efficiency, and saves transmission bandwidth.
  • IP transmission mode IP header compression and Point-to-Point Protocol (PPP) header compression can be used to reduce service overhead, or PPP multiplexing (PPP Multiplex, referred to as "PPPmux").
  • PPP Multiplex PPP Multiplex, referred to as "PPmux”
  • the equal multiplexing technology distributes the overhead to each user's service flow, thereby improving transmission efficiency and saving transmission bandwidth.
  • Composite IP scheme Composite IP (Composite IP, referred to as "CIP") scheme is applicable to user plane data transmission of Iub/Iur/Iu interface.
  • the CIP scheme multiplexes multiple CIP packets of different lengths into one CIP container, as shown in Figure 3, and the length of the CIP container is variable. This effectively utilizes the link bandwidth and distributes the UDP/IP overhead to multiple CIP packets.
  • CIP supports sub-reorganization function, The segment/reassembly divides the FP Protocol Data Unit ("PDU”) into small packets. Large FP PDU packets are required to be fragmented, as shown in Figure 4, to avoid IP fragmentation while maintaining a low transmission delay.
  • PDU FP Protocol Data Unit
  • PPPmux scheme based on High-Level Data Link Control requires 7 bytes of overhead, including 1 byte Flag field, 1 byte Address ( Address) field, 1-byte Control field, 2-byte Protocol field, and 2-byte CRC (Cyclic Redundancy Check) field. If the Address field and the Control field are not transmitted through negotiation, and the Protocol field is compressed to 1 byte, the overhead of each PPP frame is 4 bytes.
  • HDPP-based PPPmux is a Layer 2 multiplexing technology. Its main idea is to send multiple encapsulated PPP sub-frames in a PPP frame. The cost of PPP frames will be allocated to each PPP sub-frame, thus reducing overhead and improving. The purpose of efficiency.
  • the method of multiplexing multiple PPP subframes into one PPP frame is to insert one delimiter before each PPP subframe.
  • NCP PPP Network Control Protocol
  • the receiver can use the PPPmux control protocol to indicate the reception of multiplexed frames.
  • Protocol Field Flag (PFF) bit and the Length Extension (LXT) field belong to the length field. If the Protocol field is included in a PPP subframe, the PFF bit is 1 and 0 otherwise.
  • PPPmux frame format is shown in Figure 5.
  • the inventor of the present invention finds that the solution is only applicable to the point-to-point link networking, so that the application scenario is limited.
  • the main technical problem to be solved by the embodiments of the present invention is to provide a data transmission and reception method and device between a radio network controller and a base station node, which not only makes the Iub interface data transmission efficiency high, but also can be applied to various application scenarios.
  • An embodiment of the present invention provides a data transmission method between a radio network controller and a base station node, including: selecting at least two conditions satisfying multiplexing conditions from a frame protocol FP protocol data unit PDU to be transmitted. FP PDU; the selected FP PDU is multiplexed and encapsulated as a payload in a User Datagram Protocol UDP packet, the UDP packet includes a multiplexing flag; and the UDP packet containing the multiplexing flag is sent.
  • the embodiment of the present invention further provides a data receiving method between a radio network controller and a base station node, including: receiving a UDP packet; if the received UDP packet includes indicating that the UDP packet is multiplexed by at least two FP PDUs The multiplexing flag is used to demultiplex the payload of the UDP packet to obtain an FP PDU.
  • the embodiment of the present invention further provides a data transmitting apparatus between a radio network controller and a base station node, including: a selecting unit, configured to select at least two FP PDUs that satisfy a multiplexing condition from the FP PDU to be transmitted; And the FP PDU selected by the selecting unit is multiplexed and encapsulated as a payload in the UDP packet; the marking unit is configured to set a multiplexing flag for the UDP packet with the multiplexed FP PDU as the payload; a unit, configured to send the UDP packet that includes the multiplexing tag.
  • the embodiment of the present invention further provides a data receiving apparatus between a radio network controller and a base station node, including: a receiving unit, configured to receive a UDP packet; and a multiplexing determining unit, configured to determine whether the UDP packet received by the receiving unit is included a multiplexing mark, the multiplexing mark is used to indicate that the UDP packet is multiplexed by at least two FP PDUs; and a demultiplexing unit is configured to determine, by the multiplexing decision unit, a payload of the UDP packet that includes the multiplexing mark Demultiplexing to obtain an FP PDU.
  • the FP PDU is directly multiplexed into the payload of the UDP packet. Because the UDP packet is IP-based, it can be used in both the point-to-point link networking scenario and the routing networking scenario. Because the FP PDU is multiplexed, it has no effect on the UDP layer. Therefore, there is no special requirement for the intermediate transmission node between the RNC and the Node B. It can be used alone or in combination with other layers. The combination of efficiency improvement technologies, such as UDP/IP header compression, PPPmux, PPP header compression, etc., is used to achieve higher transmission efficiency.
  • efficiency improvement technologies such as UDP/IP header compression, PPPmux, PPP header compression, etc.
  • the FP PDUs satisfying the multiplexing condition are multiplexed instead of multiplexing all the FP PDUs, the FP PDUs with higher multiplexing efficiency can be selected for multiplexing, thereby improving the multiplexing effect and improving the overall efficiency. Data transfer efficiency.
  • FIG. 1 is a schematic structural diagram of a UTRAN network according to the prior art
  • FIG. 2 is a schematic structural diagram of an Iub interface protocol stack according to the prior art
  • 3 is a schematic diagram of a UDP/IP packet format multiplexed according to a CIP scheme in the prior art
  • 4 is a schematic diagram of a packet payload according to a CIP scheme in the prior art
  • FIG. 5 is a schematic diagram of a PPPmux frame format according to the prior art
  • FIG. 6 is a flow chart of a data transmission method between an RNC and a Node B according to a first embodiment of the present invention
  • FIG. 7 is a schematic diagram of a UDP packet format with a multiplexed FP PDU as a payload according to a first embodiment of the present invention
  • FIG. 8 is a schematic structural view of a multiplexing head according to a first embodiment of the present invention.
  • FIG. 9 is a flow chart of a data receiving method between an RNC and a Node B according to a second embodiment of the present invention.
  • FIG. 10 is a schematic structural diagram of a data transmitting apparatus between an RNC and a Node B according to a third embodiment of the present invention.
  • Figure 11 is a block diagram showing the structure of a data receiving apparatus between an RNC and a Node B according to a fourth embodiment of the present invention.
  • a first embodiment of the present invention relates to a method for transmitting data between an RNC and a Node B. The specific process is shown in FIG. 6.
  • the sender selects an FP PDU that satisfies the multiplexing condition from the FP PDUs to be transmitted.
  • the FP PDU packet length is about 500 bytes, and the efficiency improvement after using the multiplexing technology is small, so
  • the FP PDU is selected, and the FP PDUs satisfying the multiplexing condition are multiplexed instead of multiplexing all the FP PDUs, so that the FP PDUs with higher multiplexing efficiency can be selected for multiplexing, and multiplexing is improved. The effect of the overall data transmission efficiency.
  • the length of the FP PDUs participating in the multiplexing is less than a predetermined threshold, and the threshold can be configured by itself;
  • the UDP packet payload generated after multiplexing is less than a predetermined threshold, and the threshold can be configured by itself; Because the header length of the UDP packet is fixed, the UDP packet length generated after multiplexing can also be used as a multiplexing condition.
  • the FP PDUs participating in the multiplexing belong to the same service type, such as R99/HSPA (High Speed Packet Access) service, voice/data service, and so on.
  • R99/HSPA High Speed Packet Access
  • voice/data service and so on.
  • Reusing FP PDUs that meet the multiplexing conditions can effectively improve the transmission efficiency of user services and maximize the use of transmission resources.
  • the sender multiplexes the selected FP PDUs and encapsulates them in the UDP packet as a payload. That is, for the selected multiple FP PDUs that satisfy the multiplexing condition (at least two
  • a separator is inserted between the plurality of FP PDUs to distinguish different FP PDUs.
  • a multiplexing header (ie, a separator) is set for each FP PDU participating in the multiplexing, and the multiplexing header includes two parts: a User Identifier (UID) for indicating the multiplexing header.
  • UID User Identifier
  • the user data service flow to which the FP PDU belongs is 2 bytes in length and supports up to 65535 user IDs.
  • the Length Field is 1 - 2 bytes in length.
  • Each FP PDU and its multiplexing header are cascaded together, and the multiplexed data packet is used as a payload of the UDP packet and encapsulated into a UDP packet, as shown in FIG.
  • the UID can be the destination UDP port number of the user data service flow to which the FP PDU belongs. This is because the 3GPP specifies that the user data service flow is identified by the source IP, the destination IP, the source UDP port, and the destination UDP port, but the Iub interface uplink user data flow identifier and the downlink user data flow identifier are irrelevant, that is, the RNC allocation.
  • the UDP port is used to identify the data stream received by the RNC side, and the UDP port number assigned by the Node B is used to identify the data stream received by the Node B side.
  • the RNC and Node B can correctly receive the user data stream of the corresponding port and process it accordingly. Therefore, only the destination UDP port number of the user data service flow to which the FP PDU belongs is required to uniquely identify the user data service flow.
  • the source IP, the destination IP, the source UDP port that is, the source UDP port of the multiplexed UDP packet
  • the destination UDP port that is, the destination UDP port of the multiplexed UDP packet
  • the UID identifies the user data service flow.
  • the source UDP port that is, the source UDP port of the multiplexed UDP packet
  • the destination UDP port that is, the destination UDP port of the multiplexed UDP packet
  • the FP PDUs that are multiplexed are the same; the UID can be the destination UDP port number of the user data service flow to which the corresponding FP PDU belongs.
  • the destination UDP port of the user data service flow to which the FP PDU belongs is used to identify the user data service flow to which the FP PDU belongs, so that the multiplexer can be unique with a small multiplexer. Identify user data traffic and improve data transmission efficiency.
  • the multiplexer header may further include an extension flag, and when the value of the extension flag indicates an extension field, the multiplex header further includes an extension field of a predetermined length (e.g., 8 bits). As shown in FIG. 8, the extension flag EF is 1 bit. If EF is 1, it indicates that there is an extension field, and the extension field is 1 byte. At this time, the length field is 2 bytes. Otherwise, the multiplexing header does not include an extension. Field, length field is 1 byte.
  • the multiplex header also includes a length field indicating the length of the FP PDU.
  • the multiplex header also includes an extension field, which can be used to extend the length field or other information.
  • the 8-bit extension field is divided into 2 segments, where 4 bits are used together with 7 bits in the length field to represent the FP PDU length, and the other 4 bits can represent one or more other information. That is, when the length field is 1 byte (that is, there is no extension field), the FP PDU has a maximum length of 127 (2 7 - 1 ) bytes; when the length field is 2 bytes (that is, there is an extension field) The FP PDU has a maximum length of 2047 ( 2 11 - 1 ) bytes. Since the extended flag and the extended field are introduced in the multiplexing header, the extended field can be transmitted only when the extended information needs to be carried, the fixed overhead in the multiplexing header is reduced, and the multiplexing flexibility is increased.
  • a multiplex flag is set for the UDP packet and then sent to the receiver (such as Node B or RNC).
  • the UDP packet is marked as a UDP packet multiplexed by a plurality of FP PDUs. Therefore, the source UDP port and/or destination UDP port number can be set to a self-named port (such as 2007) and sent to the receiver. It can be seen that the specific source UDP port number and/or the destination UDP port number are used as the multiplexing tags of the UDP packet, and the UDP packet can be multiplexed without additional overhead, so that the receiving end can correctly distinguish the receiver.
  • the sender can still send the FP PDU according to the scheme specified by the 3GPP, that is, according to the source IP, the source UDP port, the destination IP, and the destination UDP port identifier.
  • the FP PDU is directly multiplexed into the payload of the UDP packet, and the UDP packet is based on the IP, so it can be used for the point-to-point link networking scenario or the routing network. Scenes. Because the FP PDU is multiplexed, it has no effect on the UDP layer. Therefore, there is no special requirement for the intermediate transmission node between the RNC and the Node B. It can be used alone or in combination with other layers. Improve the combination of technology, such as UDP/IP header compression, PPPmux, PPP header compression and other technologies to achieve higher transmission efficiency.
  • a second embodiment of the present invention relates to a data receiving method between an RNC and a Node B.
  • the present embodiment is a receiving method corresponding to the first embodiment, and a specific process is shown in FIG. 9.
  • the receiving party e.g., Node B or RNC receives the UDP packet.
  • the receiver determines whether the UDP packet contains a multiplexing flag.
  • the multiplex flag is used to indicate that the UDP packet is multiplexed by at least two FP PDUs. Since in the first embodiment, the multiplexing flag is set by setting the source UDP port and/or the destination UDP port of the UDP packet to a predetermined value, in the present embodiment, if the source UDP port of the UDP packet And/or the destination UDP port is a predetermined value, and the UDP packet contains a multiplexing flag. If the UDP packet contains a multiplex flag, the process proceeds to step 930, otherwise, the process proceeds to step 940.
  • the receiver demultiplexes the payload of the UDP packet to obtain an FP PDU.
  • the UDP packet includes a multiplexing flag
  • at least two FP PDUs can be obtained after demultiplexing the payload of the UDP packet.
  • each multiplexing header includes a UID and a length field, and thus is demultiplexed by:
  • Reading a multiplexing header of an FP PDU from the payload of the UDP packet, and reading a corresponding FP PDU from the payload of the UDP packet according to a length field in the multiplexing header, according to the UID in the multiplexing header Determine the user data service flow to which the FP PDU belongs. Repeat this step until all data in the UDP packet payload has been processed.
  • the UID may be the destination UDP port number of the user data service flow to which the FP PDU belongs.
  • the multiplex header of each FP PDU includes the UID, extended flag, and length field
  • there may be The extension field therefore, when reading the multiplex header of the FP PDU, first read the basic part of the multiplex header (ie, UID + extension flag + length field field), and determine whether there is an extension field according to the extension flag in the basic part If yes, the extended field of the multiplex header is further read from the payload of the UDP packet, otherwise the reading of the extended field is ignored.
  • a third embodiment of the present invention relates to a data transmitting apparatus between an RNC and a Node B.
  • the sending apparatus (such as an RNC or a Node B) includes a selecting unit 101, configured to select from the FP PDUs to be sent.
  • At least two FP PDUs of the multiplexing condition (if the FP PDUs participating in the multiplexing have the same priority, the length of the FP PDUs participating in the multiplexing is less than a predetermined threshold, the UDP packet payload length generated after multiplexing, or the UDP packet length is less than a predetermined threshold, or any combination thereof; a multiplexing unit 103, configured to multiplex the FP PDU selected by the selecting unit 101 and encapsulate the FP PDU as a payload in a UDP packet; and the marking unit 104 is configured to be multiplexed
  • the FP PDU sets a multiplexing flag for the payload UDP packet; and a sending unit 102 is configured to send the UDP packet.
  • the marking unit 104 has a plurality of specific implementation forms.
  • the marking unit 104 is specifically configured to set a source UDP port and/or a destination UDP port of the UDP packet to a predetermined value, where the predetermined value is Reuse tags.
  • the multiplexing unit 103 further includes: a subunit for setting a multiplexing header for each FP PDU participating in the multiplexing, the multiplexing header including a user identifier indicating a user data service flow to which the FP PDU belongs and one indicating the The length field of the FP PDU length, the user identifier is the destination UDP port number of the user data service flow to which the FP PDU belongs; the sub-unit that cascades each FP PDU and its multiplexing header.
  • a fourth embodiment of the present invention relates to a data receiving apparatus between an RNC and a Node B, where the receiving apparatus corresponds to the transmitting apparatus in the third embodiment, and as shown in FIG. 11, the receiving apparatus (such as a Node B or an RNC) includes a receiving unit.
  • the multiplexing determining unit 112 is configured to determine whether the UDP packet received by the receiving unit 111 includes a multiplexing flag, where the multiplexing flag is used to indicate that the UDP packet is multiplexed by at least two FP PDUs.
  • the demultiplexing unit 113 is configured to demultiplex the payload of the UDP packet containing the multiplexing flag by the multiplexing decision unit 112 to obtain at least two FP PDUs.
  • each multiplexing header includes a user identifier and a length field
  • the demultiplexing unit 113 further includes: a multiplexing header reading subunit 115, a multiplexing header for reading an FP PDU from a payload of a UDP packet; an FP PDU reading sub-unit 117 for reading a length field in the multiplexing header read by the sub-unit 115 according to the multiplexing header , From The corresponding FP PDU is read in the payload of the UDP packet; the attribution determining subunit 116 is configured to determine the FP PDU reading subunit according to the user identifier in the multiplexing header read by the multiplexing header reading subunit 115.
  • the FP PDU reading subunit 117 and the home determining subunit 116 acquire the next FP PDU from the payload of the UDP packet.
  • the multiplexing decision unit 112 determines whether the UDP packet contains the multiplexing flag by determining whether the source UDP port and/or the destination UDP port of the UDP packet are predetermined values. If the source UDP port and/or destination UDP port of the UDP packet is a predetermined value, the UDP packet contains a multiplexing tag.
  • the FP PDU is directly multiplexed into the payload of the UDP packet. Because the UDP packet is IP-based, it can be used for the point-to-point link networking scenario. Applicable to routing networking scenarios. Because the FP PDU is multiplexed, it has no effect on the UDP layer. Therefore, there is no special requirement for the intermediate transmission node between the RNC and the Node B. It can be used alone or in combination with other layers. Improve the combination of technology, such as UDP/IP header compression, PPPmux, PPP header compression and other technologies to achieve higher transmission efficiency.
  • the FP PDUs that satisfy the multiplexing condition are multiplexed instead of all the FP PDUs, so that the FP PDUs with higher multiplexing efficiency can be selected for multiplexing, thereby improving the multiplexing effect and improving the overall data.
  • Transmission efficiency For example, a smaller FP PDU can be selected for multiplexing, and a larger FP PDU still uses the original transmission mode, thereby effectively improving the transmission efficiency of low-rate user services and maximizing the utilization of transmission resources.
  • the destination UDP port identifies the user data service flow to which the FP PDU belongs, so that the user data service flow can be uniquely identified with a small multiplexing header, thereby improving data transmission efficiency.
  • the 3GPP specifies that the user data service flow is identified by the source IP, the destination IP, the source UDP port, and the destination UDP port.
  • the uplink and downlink user data flow identifiers of the Iub interface data stream are separated, that is, the UDP port number allocated by the RNC is used.
  • the data stream received by the RNC side is identified, and the UDP port number allocated by the Node B is used to identify the data stream received by the Node B side. Therefore, only the target UDP port number is required to uniquely identify the user data service flow.
  • the transmission of the extension field reduces the fixed overhead in the multiplex header and increases the flexibility of multiplexing.
  • the specific source UDP port number and/or the destination UDP port number are used as multiplexing tags of the UDP packet, and the UDP packet can be multiplexed without additional overhead, so that the receiving end can correctly distinguish and resolve the multiplexing. Or non-multiplexed UDP packets.
  • the multiplexing conditions can be flexibly configured to improve multiplexing efficiency.

Landscapes

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

Description

无线网络控制器与基站节点间数据收发方法和装置
本申请要求于 2007 年 2 月 7 日提交中国专利局、 申请号为 200710004886.7、 发明名称为"无线网络控制器与基站节点间数据收发方法和 装置"的中国专利申请的优先权， 其全部内容通过引用结合在本申请中。
技术领域
本发明涉及无线通信领域，特别涉及无线网络控制器与基站节点间用户面 数据传输技术。
背景技术
通用移动通信系统 ( Universal Mobile Telecommunications System, 简称 "UMTS" )是采用宽带码分多址（Wideband Code Division Multiple Access, 简 称" WCDMA" )空中接口技术的第三代移动通信系统，通常也把 UMTS系统称 为 WCDMA通信系统。 UMTS系统采用了与第二代移动通信系统类似的结构， 包括无线接入网络 ( Radio Access Network, 简称" RAN" )和核心网络 ( Core Network, 简称" CN" )。 其中无线接入网络用于处理所有与无线有关的功能， 而 CN处理 UMTS 系统内所有的话音呼叫和数据连接， 并实现与外部网络的 交换和路由功能。 CN从逻辑上分为电路交换域（Circuit Switched Domain, 简 称" CS" )和分组交换域（ Packet Switched Domain, 简称" PS" )„ UMTS陆地无 线接入网（UMTS Terrestrial Radio Access Network, 简称" UTRAN")、 CN与用 户设备 ( User Equipment, 简称" UE" )一起构成了整个 UMTS 系统。
UTRAN 的结构如图 1 所示， 包含一个或几个无线网络子系统（Radio
Network Subsystem, 简称" RNS" )。 一个 RNS由一个无线网络控制器（Radio Network Controller, 简称" RNC" )和一个或多个基站（Node B )组成。 RNC 与 CN之间的接口是 Iu接口， Node B和 RNC之间的接口是 Iub接口。在 UTRAN 内部， RNC之间通过 Iur接口互联， Iur可以通过 RNC之间的直接物理连接或 通过传输网连接。 RNC用来分配和控制与之相连或相关的 Node B的无线资源， Node B完成 Iub接口和 Uu接口之间数据流的转换， 同时也参与一部分无线资 源管理。
RNC 用于控制 UTRAN 的无线资源， 主要完成无线资源控制 （Radio Resource Control, 简称" RRC" )连接建立和断开、 切换、 宏分集合并、 无线资 源管理等功能。 具体如下：
(1)执行系统信息广播与系统接入控制功能；
(2)切换和服务 RNC ( Service RNC, 简称" SRNC" )迁移等移动性管理功 (3)宏分集合并、 功率控制、 无线承载分配等无线资源管理和控制功能。
Node B是 WCDMA系统的基站（即无线收发信机）， 包括无线收发信机 和基带处理部件。通过标准的 lub接口和 RNC互连，主要完成 Uu接口物理层 协议的处理。 它的主要功能是扩频、调制、信道编码及解扩、解调、信道解码， 还包括基带信号和射频信号的相互转换等功能。
lub接口协议栈结构如图 2所示， 分为无线网络控制面 （ Radio Network
Control Plane )、 传输网络控制面 （ Transport Network Control Plane )和用户面 ( User Plane ), 承载层有异步传输模式 ( Asynchronous Transfer Mode, 简称 "ATM" )传输和网间互联协议 ( Internet Protocol , 简称" IP" )传输两种方式。
ATM传输方式时， 无线网络控制面的传输层使用特定业务协调功能 -用户 网络接口 ( Service Specific Coordination Function -User Network Interface , 简称 "SSCF-UNI" ) /特定业务面向连接协议 ( Special Service Connect Oriented Protocol, 简称" SSCOP" ) / ATM适配层类型 5 ( ATM Adaptation Layer Type 5 , 简称" AAL5" )/ATM,传输网络控制面使用接入链路控制应用部分（Access Link Control Application Part, 简称" ALCAP" ) /SSCF-UNI/SSCOP/AAL5/ATM, 用 户面传输层使用 ATM适配层类型 2 ( ATM Adaptation Layer Type 2, 简称 "AAL2" ) /ATM0
IP传输方式时， 无线网络控制面的传输层使用流控制传输协议（Stream Control Transmission Protocol,简称" SCTP" ) /IP/Data Link Layer (数据链路层）， 用户面传输层使用用户数据 协议 ( User Datagram Protocol , 简称" UDP" ) /IP/Data Link Layer, 没有传输网络控制面。
用户面不同的信道使用不同的帧协议 ( Frame Protocol, 简称" FP" )格式， 包括随机接入信道 (Random Access Channel , 简称" RACH") FP、 寻呼信道 (Paging Channel, 简称" PCH") FP、 前向接入信道 (Forward Access Channel, 简 称" FACH") FP、 专用信道（Dedicated Channel, 简称" DCH" ) FP、 高速下行共 享信道（High Speed Downlink Shared Channel, 简称 "HS-DSCH" ) FP， 以及其 他信道如下行共享信道 (Downlink Shared Channel, 简称" DSCH") FP等。 UE的 语音和数据 , 封装在各种 FP帧中， 使用传输层（ ATM或 IP )功能， 在 Iub接 口传输。
WCDMA语音业务包括窄带自适应多速率 （ Adaptive Multi- Rate , 简称
"AMR" )和宽带 AMR, 窄带 AMR包括 12.2k /10.2k/7.95k/7.4k/6.7k/5.9k/4.75k 等速率， 宽带 AMR基于 16kHz采样速率， 包括 6.6k与 23.85k之间的 9种速 率， 目 前最常用 的是窄带 AMR 12.2kbps。 数据业务速率包括 8k/16k/32k/64k/128k/144k/256k/384k/2048k等。由于 WCDMA支持的数据业务 速率较高， 因此， 数据业务所需的承载层带宽也远大于语音业务。
从 Node B到 RNC之间的回程传输资源永远是运营商最宝贵的资源。 据 统计， 回程传输费用占无线网络运营商运营成本的 30%以上。 因此， 提升 Iub 接口传输效率， 最大化利用传输资源， 一直是运营商的关注重点之一。
目前， 对于 E1/T1传输及微波传输等应用场景， ATM传输方式下， 运营 商可采用 Hub Node B或者基于目前已有的 ATM传输网资源， 通过虚路径 ( Virtual Path, 简称" VP" ) I虚通道（ Virtual Channel, 简称" VC" ) 交换实现 Iub接口业务的统计复用， 提高传输效率， 节省传输带宽。 IP传输方式下， 可 采用 IP头压缩和点到点协议（ Point-to-Point Protocol, 简称" PPP" ) 头压缩等 技术减少业务的开销， 或者采用 PPP复用（PPP Multiplexing, 简称" PPPmux" ) 等复用技术将开销分摊到各个用户业务流，从而提高传输效率，节省传输带宽。 但是， Iub接口上要提供这些提升传输效率的功能特性， 仅 RNC和 Node B支 持还不够，还需要中间传输节点支持。要么是中间传输节点不支持这些功能特 性， 使得这些技术无法应用， 要么是中间传输节点价格过于昂贵， 大大增加端 到端传输成本， 从而限制了这些传输效率提升技术的应用。
下面对现有技术中的两种提高传输效率的方案进行分别介绍。
( 1 )复合 IP方案：复合 IP( Composite IP,简称" CIP" )方案适用于 Iub/Iur/Iu 接口用户面数据传输。 CIP方案将多个不同长度的 CIP包复用到一个 CIP容器 ( CIP container ), 如图 3所示， 并且 CIP容器的长度可变。 这样可有效利用链 路带宽， 将 UDP/IP的开销分摊到多个 CIP包上。 CIP支持分 重组功能， 分 段 /重组将 FP协议数据单元（ Protocol Data Unit, 简称" PDU" )分割成小的数 据包。 要求大 FP PDU包必须分段， 如图 4所示， 以避免 IP分片， 同时保持 较低的传输时延。 但是， 本发明的发明人发现， 该方案要求全部 FP PDU数据 包采用 UDP、 IP和连接标识符（ Connection Identifier, 简称" CID" )标识。 对 于大 FP PDU数据包，采用分 重组后产生更多需要传输的辅助信息，传输效 率反而降低了。
( 2 )基于高级数据链路控制（ High-Level Data Link Control,简称" HDLC" ) 的 PPPmux方案： PPP封装需要 7字节的开销 , 包括 1字节 Flag (标志）域、 1字节 Address (地址）域、 1字节 Control (控制）域、 2字节 Protocol (协议） 域和 2字节 CRC(循环冗余校验）域。若通过协商，不传送 Address域和 Control 域 , 且 Protocol域压缩为 1字节， 则每个 PPP帧的开销为 4字节。
基于 HDLC的 PPPmux属于层二复用技术， 它的主要思想是在一个 PPP 帧里发送多个封装的 PPP子帧 , 这样 PPP帧的开销将分摊到每个 PPP子帧 , 从而达到减少开销、 提升效率的目的。 多个 PPP子帧复用到 1个 PPP帧的方 法是在每个 PPP子帧前面插入 1个分隔符。 在 PPP的网络控制协议 ( Network Control Protocol, 简称" NCP" )协商阶段， 接收方可以使用 PPPmux控制协议 来表示接收复用帧。
若 PPP子帧的 Protocol域与前面 PPP子帧的 Protocol域相同，则不需要传 送。 Protocol域标志（ Protocol Field Flag, 简称" PFF" )比特和长度扩展 ( Length Extension, 简称" LXT" )域属于长度域。 若 Protocol域包含在 PPP子帧中， 则 PFF比特为 1 , 否则为 0。 PPPmux帧格式如图 5所示。
但是， 由于本方案属于层二复用技术， 因此， 本发明的发明人发现该方案 仅适用于点到点链路组网 , 使得应用场景受到限制。
发明内容
本发明实施方式解决的主要技术问题是提供一种无线网络控制器与基站 节点间数据收发方法和装置， 不但使 Iub接口数据传输效率较高， 而且可以适 用于多种应用场景。
本发明实施方式提供一种无线网络控制器与基站节点间数据发送方法 ,包 括：从待发送的帧协议 FP协议数据单元 PDU中选出满足复用条件的至少两个 FP PDU; 对所述选出的 FP PDU进行复用后作为净荷封装在用户数据报协议 UDP包中， 所述 UDP包中包含复用标记； 发送所述含有复用标记的 UDP包。
本发明实施方式还提供一种无线网络控制器与基站节点间数据接收方法， 包括： 接收 UDP包； 如果所述接收到的 UDP包中包含指示该 UDP包由至少 两个 FP PDU复用而成的复用标记， 则对所述 UDP包的净荷进行解复用， 得 到 FP PDU。
本发明实施方式还提供一种无线网络控制器与基站节点间数据发送装置， 包括： 选择单元， 用于从待发送的 FP PDU 中选出满足复用条件的至少两个 FP PDU; 复用单元， 用于将所述选择单元选出的 FP PDU进行复用后作为净 荷封装在 UDP包中； 标记单元 , 用于为以复用的 FP PDU为净荷的 UDP包设 置复用标记； 发送单元， 用于发送所述包含复用标记的 UDP包。
本发明实施方式还提供一种无线网络控制器与基站节点间数据接收装置， 包括： 接收单元， 用于接收 UDP包； 复用判决单元， 用于判断所述接收单元 接收的 UDP包中是否包含复用标记，该复用标记用于指示该 UDP包由至少两 个 FP PDU复用而成； 解复用单元， 用于对所述复用判决单元判定含有复用标 记的 UDP包的净荷进行解复用 , 得到 FP PDU。
本发明实施方式与现有技术相比， 主要区别及其效果在于：
将 FP PDU直接复用为 UDP包的净荷， 因为 UDP包是基于 IP的， 所以 既可用于点到点链路组网场景 ,也可应用于路由组网场景。又因为是对 FP PDU 进行复用， 对 UDP以下的层没有任何影响， 所以对 RNC和 Node B之间的中 间传输节点没有特殊的要求， 既可以单独使用， 也可以与其它层三、 层二效率 提升技术组合使用， 如与 UDP/IP头压缩、 PPPmux、 PPP头压缩等技术组合使 用， 以取得更高的传输效率。 由于是对满足复用条件的 FP PDU进行复用， 而 不是对所有的 FP PDU都进行复用， 从而可以选择复用效率较高的 FP PDU进 行复用， 提高复用的效果， 进而提升整体的数据传输效率。
附图说明
图 1是根据现有技术中的 UTRAN网络结构示意图；
图 2是根据现有技术中的 Iub接口协议栈结构示意图；
图 3是根据现有技术中的 CIP方案复用后的 UDP/IP包格式示意图； 图 4是根据现有技术中的 CIP方案的包净荷示意图；
图 5是根据现有技术中的 PPPmux帧格式示意图；
图 6是根据本发明第一实施方式的 RNC与 Node B间数据发送方法流程 图；
图 7是根据本发明第一实施方式中以复用的 FP PDU为净荷的 UDP包格 式示意图；
图 8是根据本发明第一实施方式中的复用头结构示意图；
图 9是根据本发明第二实施方式的 RNC与 Node B间数据接收方法流程 图；
图 10是根据本发明第三实施方式的 RNC与 Node B间数据发送装置结构 示意图；
图 11是根据本发明第四实施方式的 RNC与 Node B间数据接收装置结构 示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚， 下面将结合附图对本发明 实施方式作进一步地伴细描述。
本发明的第一实施方式涉及 RNC与 Node B间数据发送方法， 具体流程 如图 6所示。
在步骤 610中， 发送方（如 RNC或 Node B )从待发送的 FP PDU中选出 满足复用条件的 FP PDU。 具体地说， 由于在 Iub接口中一些数据包并不需要 采用复用技术，如高速率 384kbps数据业务，其 FP PDU包长为 500字节左右， 采用复用技术后的效率提升很小， 因此， 先对 FP PDU进行选择， 对满足复用 条件的 FP PDU进行复用， 而不是对所有的 FP PDU都进行复用， 从而可以选 择复用效率较高的 FP PDU进行复用， 提高复用的效果， 进而提升整体的数据 传输效率。
比如说， 将复用条件设置为以下之一或其任意组合：
( 1 ) 参加复用的 FP PDU具有相同的优先级；
( 2 ) 参加复用的 FP PDU的长度小于预定门限， 该门限可自行配置；
( 3 ) 复用后生成的 UDP包净荷小于预定门限， 该门限可自行配置； 因为 UDP包的包头长度是固定的，所以也可以以复用后生成的 UDP包长度小 于预定门限作为复用条件。
( 4 ) 参加复用的 FP PDU属于同一业务类型， 如按 R99/HSPA (高速 分组接入）业务区分、 按语音 /数据业务区分等。
对满足复用条件的 FP PDU进行复用 , 可有效提升用户业务的传输效率 , 最大化利用传输资源。
接着， 进入步骤 620， 发送方对选出的 FP PDU进行复用后作为净荷封装 在 UDP包中。 也就是说， 对选择出的满足复用条件的多个 FP PDU (至少两个
FP PDU )进行复用后， 作为 UDP包的净荷， 多个 FP PDU之间插入分离符， 以区分不同的 FP PDU。
具体地说， 为参加复用的每个 FP PDU设置一个复用头 （即分离符）， 该 复用头包括两部分： 用户标识符（User Identifier, 简称" UID" ), 用于指示该
FP PDU所归属的用户数据业务流， 长度为 2字节， 最大可支持 65535个用户 标识； 长度域（Length Field ), 长度为 1 - 2字节。 将各 FP PDU及其复用头级 联在一起， 复用后的数据包作为 UDP 包的净荷， 封装到 UDP 包中， 如图 Ί 所示。
其中， 复用头如图 8所示， 总长度为 3 - 4字节。 UID可以是 FP PDU所 归属的用户数据业务流的目的 UDP端口号。 这是因为， 3GPP中规定以源 IP、 目的 IP、 源 UDP端口、 和目的 UDP端口标识用户数据业务流， 但 Iub接口上 行用户数据流标识和下行用户数据流标识是不相关的， 即 RNC分配的 UDP 端口用于标识 RNC侧接收的数据流， 而 Node B分配的 UDP端口号用于标识 Node B侧接收的数据流。 只要往所分配的端口发送数据， 则 RNC和 Node B 就能够正确接收到对应端口的用户数据流， 并进行相应处理。 所以只需要 FP PDU所归属的用户数据业务流的目的 UDP端口号就可以唯一标识用户数据业 务流。
也就是说， 本实施方式中以源 IP、 目的 IP、 源 UDP端口 （即复用后的 UDP包的源 UDP端口）、 目的 UDP端口 （即复用后的 UDP包的目的 UDP端 口）、 和 UID标识用户数据业务流。 其中， 源 UDP端口 （即复用后的 UDP包 的源 UDP端口）和目的 UDP端口 （即复用后的 UDP包的目的 UDP端口）对 于所复用的各 FP PDU都是相同的； UID可以为相应的 FP PDU所归属的用户 数据业务流的目的 UDP端口号。 由此可见 , 在 UDP包的净荷中， 以 FP PDU 所归属的用户数据业务流的目的 UDP端口， 来标识 FP PDU所归属的用户数 据业务流，从而以较小的复用头就可以唯一标识用户数据业务流，提高了数据 传输效率。
复用头中还可以包括扩展标志， 当该扩展标志的值指示有扩展字段时，该 复用头还包括预定长度（如 8比特） 的扩展字段。 如图 8所示， 扩展标志 EF 为 1比特， 若 EF为 1 , 表示存在扩展字段， 该扩展字段为 1字节， 此时， 长 度域就为 2字节， 否则， 复用头不包含扩展字段， 长度域为 1字节。
复用头中还包括一个为 Ί比特的表示该 FP PDU长度的长度域。
如果 EF为 1 , 则说明复用头中还包括扩展字段， 扩展字段可用于扩展长 度域或其它信息。 比如说， 将 8比特的扩展字段分为 2段， 其中 4个比特与长 度域中的 7个比特一起用于表示 FP PDU长度，其它 4个比特可以表示一项或 多项其它信息。 也就是说， 当长度域为 1字节时（即不存在扩展字段）， 该 FP PDU长度最大为 127 ( 27 - 1 )字节； 当长度域为 2字节时（即存在扩展字段）， 该 FP PDU长度最大为 2047 ( 211 - 1 )字节。 由于在复用头中引入了扩展标志 和扩展字段，可以仅在需要携带扩展信息时传输扩展字段， 减少了复用头中的 固定开销， 增加了复用的灵活性。
可以对图 7所示的 UDP包格式作一些变化， 例如可以将所有的复用头级 联在一 ^丈在 UDP包净荷的前部 ,将所有的 FP PDU级联在一^丈在 UDP包 净荷的后部， 等等。 这些变化的包格式同样可以实现本发明实施例的目的， 只 需要在接收端相应地修改读取顺序即可。
接着，进入步骤 630，为该 UDP包设置复用标记后发送给接收方（如 Node B或 RNC )。 具体地说， 通过将该 UDP包的源 UDP端口和 /或目的 UDP端口 设置为预定的值， 标记该 UDP包为多个 FP PDU复用的 UDP包。 因此， 可将 源 UDP端口和 /或目的 UDP端口号设为自命名端口 （如 2007 )后发送给接收 方。 由此可见 , 以特定的源 UDP端口号和 /或目的 UDP端口号作为 UDP包的 复用标记， 可以在不增加额外开销的前提下指示 UDP包是否被复用， 使接收 端可以正确地区分和解析复用或非复用的 UDP包。 需要说明的是， 在本实施方式中， 对于不满足复用条件的 FP PDU, 发送 方仍然可以基于 3GPP规定的方案发送 FP PDU, 即根据源 IP、 源 UDP端口、 目的 IP、 目的 UDP端口标识该 FP PDU归属的用户数据业务流。
不难发现， 由于本实施方式中将 FP PDU直接复用为 UDP包的净荷 , 而 UDP包是基于 IP的， 所以既可用于点到点链路组网场景， 也可应用于路由组 网场景。 因为是对 FP PDU进行复用， 对 UDP以下的层没有任何影响， 所以 对 RNC和 Node B之间的中间传输节点没有特殊的要求， 既可以单独使用， 也可以与其它层三、 层二效率提升技术组合使用， 如与 UDP/IP 头压缩、 PPPmux, PPP头压缩等技术组合使用， 以取得更高的传输效率。
本发明的第二实施方式涉及 RNC与 Node B间数据接收方法， 本实施方 式为对应于第一实施方式的接收方法， 具体流程如图 9所示。
在步骤 910中， 接收方 （如 Node B或 RNC )接收 UDP包。
接着， 进入步骤 920， 接收方判断该 UDP包中是否包含复用标记。 该复 用标记用于指示该 UDP包由至少两个 FP PDU复用而成。 由于在第一实施方 式中， 通过将 UDP包的源 UDP端口和 /或目的 UDP端口设置为预定的值， 来 设置复用标记， 因此， 在本实施方式中， 如果该 UDP包的源 UDP端口和 /或 目的 UDP端口为预定的值， 则该 UDP包中包含复用标记。 如果该 UDP包中 包含复用标记， 则进入步骤 930， 否则， 进入步骤 940。
在步骤 930中，接收方对该 UDP包的净荷进行解复用， 得到 FP PDU。 本 领域技术人员可以理解 , 由于该 UDP包中包含复用标记 , 因此， 在对该 UDP 包的净荷进行解复用后， 可以得到至少两个 FP PDU。 具体地说， 由于 UDP 包的净荷中包括至少两个 FP PDU及其复用头，每个复用头包括 UID和长度域， 因此， 通过以下方式进行解复用：
从该 UDP包的净荷中读取一个 FP PDU的复用头， 根据该复用头中的长 度域从该 UDP包的净荷中读取相应的 FP PDU, 根据该复用头中的 UID确定 该 FP PDU所归属的用户数据业务流。 重复该步骤， 直至处理完该 UDP包净 荷中的所有数据。 其中， UID可以是 FP PDU所归属的用户数据业务流的目的 UDP端口号。
由于每一个 FP PDU的复用头包括了 UID、 扩展标志、 长度域， 可能还有 扩展字段， 因此，在读取 FP PDU的复用头时，先读取该复用头的基本部分（即 UID +扩展标志 +长度域字段）， 根据基本部分中的扩展标志判断是否存在扩 展字段， 如果是则进一步从 UDP包的净荷中读取该复用头的扩展字段， 否则 忽略对扩展字段的读取。
本发明的第三实施方式涉及 RNC与 Node B间数据发送装置， 如图 10所 示， 发送装置（如 RNC或 Node B )中包含选择单元 101， 用于从待发送的 FP PDU中选出满足复用条件的至少两个 FP PDU (如参加复用的 FP PDU具有相 同的优先级、 参加复用的 FP PDU的长度小于预定门限、 复用后生成的 UDP 包净荷长度或 UDP包长度小于预定门限， 或其任意组合）； 复用单元 103 , 用 于将该选择单元 101选出的 FP PDU进行复用后作为净荷封装在 UDP包中； 标记单元 104，用于为以复用的 FP PDU为净荷的 UDP包设置复用标记；和发 送单元 102， 用于发送该 UDP包。
所述标记单元 104有多种具体实现形式， 例如， 所述标记单元 104， 具体 用于将所述 UDP包的源 UDP端口和 /或目的 UDP端口设置为预定的值， 所述 预定的值是复用标记。 复用单元 103进一步包括： 为参加复用的每个 FP PDU 设置一个复用头的子单元，该复用头中包括一个指示该 FP PDU所归属的用户 数据业务流的用户标识和一个表示该 FP PDU长度的长度域， 该用户标识是 FP PDU所归属的用户数据业务流的目的 UDP端口号；将各 FP PDU及其复用 头级联在一起的子单元。
本发明的第四实施方式涉及 RNC与 Node B间数据接收装置， 该接收装 置对应于第三实施方式中的发送装置， 如图 11所示， 接收装置（如 Node B或 RNC )中包含接收单元 111， 用于接收 UDP包； 复用判决单元 112， 用于判断 该接收单元 111接收的 UDP包中是否包含复用标记， 该复用标记用于指示该 UDP包由至少两个 FP PDU复用而成； 解复用单元 113， 用于对该复用判决单 元 112判定含有复用标记的 UDP包的净荷进行解复用，得到至少两个 FP PDU。
由于 UDP包的净荷中包括至少两个 FP PDU及其复用头 , 每个复用头包 括用户标识和长度域， 因此， 解复用单元 113进一步包括： 复用头读取子单元 115, 用于从 UDP包的净荷中读取一个 FP PDU的复用头； FP PDU读取子单 元 117, 用于根据该复用头读取子单元 115 所读取的复用头中的长度域， 从 UDP包的净荷中读取相应的 FP PDU; 归属确定子单元 116, 用于根据复用头 读取子单元 115所读取的复用头中的用户标识 ,确定该 FP PDU读取子单元 117 读取的 FP PDU所归属的用户数据业务流；结束判断子单元 114，用于判断 UDP 包净荷中的数据是否已读完， 如果没有读完则指示该复用头读取子单元 115、 FP PDU读取子单元 117和归属确定子单元 116从该 UDP包的净荷中获取下一 个 FP PDU。
其中 , 复用判决单元 112通过判断 UDP包的源 UDP端口和 /或目的 UDP 端口是否为预定的值， 来判断 UDP包中是否包含复用标记。如果该 UDP包的 源 UDP端口和 /或目的 UDP端口为预定的值， 则说明该 UDP包中包含复用标 记。
综上所述， 在本发明的各实施方式中， 将 FP PDU直接复用为 UDP包的 净荷， 因为 UDP包是基于 IP的， 所以既可用于点到点链路组网场景， 也可应 用于路由组网场景。 因为是对 FP PDU进行复用， 对 UDP以下的层没有任何 影响， 所以对 RNC和 Node B之间的中间传输节点没有特殊的要求， 既可以 单独使用， 也可以与其它层三、 层二效率提升技术组合使用， 如与 UDP/IP头 压缩、 PPPmux、 PPP头压缩等技术组合使用， 以取得更高的传输效率。
对满足复用条件的 FP PDU进行复用， 而不是对所有的 FP PDU都进行复 用， 从而可以选择复用效率较高的 FP PDU进行复用， 提高复用的效果， 进而 提升整体的数据传输效率。 例如可以选择较小的 FP PDU进行复用， 而较大的 FP PDU仍使用原来的传输方式， 从而有效提升低速率用户业务的传输效率， 最大化利用传输资源。
在 UDP包的净荷中， 以目的 UDP端口标识 FP PDU所归属的用户数据业 务流，从而以较小的复用头就可以唯一标识用户数据业务流，提高了数据传输 效率。 3GPP中规定以源 IP、 目的 IP、 源 UDP端口、 和目的 UDP端口标识用 户数据业务流，但是， Iub接口数据流上行和下行的用户数据流标识是分离的， 即 RNC分配的 UDP端口号用于标识 RNC侧接收的数据流， 而 Node B分配 的 UDP端口号用于标识 Node B侧接收的数据流， 所以只需要目标 UDP端口 号就可以唯一标识用户数据业务流。
通过在复用头中引入扩展标志和扩展字段，可以仅在需要携带扩展信息时 传输扩展字段， 减少了复用头中的固定开销， 增加了复用的灵活性。 以特定的源 UDP端口号和 /或目的 UDP端口号作为 UDP包的复用标记， 可以在不增加额外开销的前提下指示 UDP包是否被复用， 使接收端可以正确 地区分和解析复用或非复用的 UDP包。
复用条件可以灵活配置， 从而提高复用效率。
虽然通过参照本发明的某些优选实施方式，已经对本发明进行了图示和描 述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改 变， 而不偏离本发明的精神和范围。

Claims

权 利 要 求
1. 一种无线网络控制器与基站节点间数据发送方法， 其特征在于， 包括： 从待发送的帧协议 FP协议数据单元 PDU中选出满足复用条件的至少两个
FP PDU;
对所述选出的 FP PDU进行复用后作为净荷封装在用户数据报协议 UDP 包中 , 所述 UDP包中包含复用标记；
发送所述含有复用标记的 UDP包。
2. 根据权利要求 1所述的无线网络控制器与基站节点间数据发送方法， 其特征在于， 所述对选出的 FP PDU进行复用包括：
为所述选出的每个 FP PDU设置一个复用头， 该复用头中包括指示该 FP
PDU所归属的用户数据业务流的用户标识和表示该 FP PDU长度的长度域； 将所述选出的各 FP PDU及其复用头级联在一起。
3. 根据权利要求 2所述的无线网络控制器与基站节点间数据发送方法， 其特征在于， 所述用户标识是 FP PDU所归属的用户数据业务流的目的 UDP 端口号。
4. 根据权利要求 2所述的无线网络控制器与基站节点间数据发送方法， 其特征在于， 所述复用头中还包括扩展标志， 当该扩展标志的值指示有扩展字 段时， 所述复用头还包括预定长度的扩展字段。
5. 根据权利要求 4所述的无线网络控制器与基站节点间数据发送方法，
FP PDU的长度。
6. 根据权利要求 1所述的无线网络控制器与基站节点间数据发送方法， 其特征在于，通过为所述 UDP包设置复用标记来实现所述 UDP包中包含复用 标记， 所述为 UDP包设置复用标记包括：
将所述 UDP包的源 UDP端口和 /或目的 UDP端口设置为预定的值。
7. 根据权利要求 1至 6中任一项所述的无线网络控制器与基站节点间数 据发送方法， 其特征在于， 所述复用条件包括以下之一或其任意组合：
参加复用的 FP PDU具有相同的优先级；
参加复用的 FP PDU的长度小于预定门限； 复用后生成的 UDP包的净荷长度或所述 UDP包的长度小于预定门限； 参加复用的 FP PDU属于同一业务类型。
8. 一种无线网络控制器与基站节点间数据接收方法， 其特征在于， 包括： 接收 UDP包；
如果所述接收到的 UDP包中包含指示该 UDP包由至少两个 FP PDU复用 而成的复用标记， 则对所述 UDP包的净荷进行解复用， 得到 FP PDU。
9. 根据权利要求 8所述的无线网络控制器与基站节点间数据接收方法， 其特征在于， 所述 UDP包的净荷中包括至少两个 FP PDU及其复用头 , 每个 复用头包括用户标识和长度域；
所述对 UDP包的净荷进行解复用包括：
从所述 UDP包的净荷中读取一个 FP PDU的复用头 , 根据该复用头中的 长度域从该 UDP包的净荷中读取相应的 FP PDU ,根据该复用头中的用户标识 确定该 FP PDU所归属的用户数据业务流；
上述步骤完成一个 FP PDU的读取， 重复上述步骤直至处理完所述 UDP 包净荷中的所有数据。
10. 根据权利要求 9所述的无线网络控制器与基站节点间数据接收方法， 其特征在于， 所述用户标识是 FP PDU所归属的用户数据业务流的目的 UDP 端口号；
如果所述 UDP包的源 UDP端口和 /或目的 UDP端口为预定的值， 则所述 预定的值为该 UDP包的复用标记。
11. 根据权利要求 9所述的无线网络控制器与基站节点间数据接收方法， 其特征在于， 所述复用头还包括扩展标志；
所述对 UDP包的净荷进行解复用中完成一个 FP PDU的读取还包括： 读取所述 FP PDU的复用头时， 先读取所述复用头的扩展标志， 根据所述 扩展标志的值判断是否存在扩展字段， 如果是则进一步从所述 UDP包的净荷 中读取所述复用头的扩展字段。
12.一种无线网络控制器与基站节点间数据发送装置，其特征在于， 包括： 选择单元， 用于从待发送的 FP PDU中选出满足复用条件的至少两个 FP
PDU; 复用单元，用于将所述选择单元选出的 FP PDU进行复用后作为净荷封装 在 UDP包中；
标记单元， 用于为以复用的 FP PDU为净荷的 UDP包设置复用标记； 发送单元， 用于发送所述包含复用标记的 UDP包。
13.根据权利要求 12所述的无线网络控制器与基站节点间数据发送装置， 其特征在于， 所述复用单元包括：
用于为所述选择单元选出的每个 FP PDU设置一个复用头的子单元，该复 用头中包括一个指示该 FP PDU所归属的用户数据业务流的用户标识和一个表 示该 FP PDU长度的长度域； 以及
用于将各 FP PDU以及各自的复用头级联在一起的子单元。
14.根据权利要求 13所述的无线网络控制器与基站节点间数据发送装置， 其特征在于， 所述用户标识是 FP PDU所归属的用户数据业务流的目的 UDP 端口号。
15.根据权利要求 12所述的无线网络控制器与基站节点间数据发送装置， 其特征在于，
所述标记单元， 具体用于将所述 UDP包的源 UDP端口和 /或目的 UDP端 口设置为预定的值， 所述预定的值是复用标记。
16.根据权利要求 12至 15中任一项所述的无线网络控制器与基站节点间 数据发送装置，其特征在于， 所述选择单元使用的所述复用条件包括以下之一 或其任意组合：
参加复用的 FP PDU具有相同的优先级；
参加复用的 FP PDU的长度小于预定门限；
复用后生成的 UDP包净荷长度或 UDP包长度小于预定门限；
参加复用的 FP PDU属于同一业务类型。
17.一种无线网络控制器与基站节点间数据接收装置，其特征在于， 包括： 接收单元， 用于接收 UDP包；
复用判决单元， 用于判断所述接收单元接收的 UDP包中是否包含复用标 记， 该复用标记用于指示该 UDP包由至少两个 FP PDU复用而成；
解复用单元， 用于对所述复用判决单元判定含有复用标记的 UDP包的净 荷进行解复用， 得到 FP PDU。
18.根据权利要求 17所述的无线网络控制器与基站节点间数据接收装置， 其特征在于， 所述 UDP包的净荷中包括至少两个 FP PDU及其复用头 , 每个 复用头包括用户标识和长度域；
所述解复用单元进一步包括以下子单元：
复用头读取子单元 ,用于从 UDP包的净荷中读取一个 FP PDU的复用头； FP PDU读取子单元， 用于根据所述复用头读取子单元所读取的复用头中 的长度域 , 从所述 UDP包的净荷中读取相应的 FP PDU;
归属确定子单元，用于根据所述复用头读取子单元所读取的复用头中的用 户标识 , 确定所述 FP PDU读取子单元读取的 FP PDU所归属的用户数据业务 流;
结束判断子单元， 用于判断所述 UDP包净荷中的数据是否已读完， 如果 没有读完则指示所述复用头读取子单元、 FP PDU读取子单元和归属确定子单 元从该 UDP包的净荷中获取下一个 FP PDU。
19.根据权利要求 18所述的无线网络控制器与基站节点间数据接收装置， 其特征在于， 所述用户标识是 FP PDU所归属的用户数据业务流的目的 UDP 端口号；
所述复用判决单元， 具体用于通过判定所述 UDP包的源 UDP端口和 /或 目的 UDP端口为预定的值， 来判定该 UDP包中包含复用标记。
PCT/CN2007/071021 2007-02-07 2007-11-06 Procédé et dispositif de transmission et de réception de données entre un contrôleur de réseau radio et un noeud de station WO2008095394A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP07817212A EP2053798B1 (en) 2007-02-07 2007-11-06 Method and device for data transmitting and receiving between radio network controller and station node
ES07817212T ES2399929T3 (es) 2007-02-07 2007-11-06 Método y dispositivo para la transmisión y recepción de datos entre un controlador de red de radio y un nodo de estación

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200710004886.7 2007-02-07
CN 200710004886 CN101242561B (zh) 2007-02-07 2007-02-07 无线网络控制器与基站节点间数据收发方法和装置

Publications (1)

Publication Number Publication Date
WO2008095394A1 true WO2008095394A1 (fr) 2008-08-14

Family

ID=39681257

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2007/071021 WO2008095394A1 (fr) 2007-02-07 2007-11-06 Procédé et dispositif de transmission et de réception de données entre un contrôleur de réseau radio et un noeud de station

Country Status (4)

Country Link
EP (1) EP2053798B1 (zh)
CN (1) CN101242561B (zh)
ES (1) ES2399929T3 (zh)
WO (1) WO2008095394A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101374266A (zh) * 2007-08-23 2009-02-25 华为技术有限公司 数据发送、接收方法及无线接入点设备、网关、通信系统
CN102957730B (zh) * 2011-08-29 2016-12-21 腾讯科技（深圳）有限公司 数据传输方法和系统
CN103607259B (zh) * 2013-11-18 2017-05-24 海能达通信股份有限公司 一种数据帧传输方法及其传输装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1490987A (zh) * 2002-10-18 2004-04-21 ��Ϊ�������޹�˾ 一种在同步数字网上传送数据业务的方法
US20050043030A1 (en) * 2003-08-22 2005-02-24 Mojtaba Shariat Wireless communications system
CN1889575A (zh) * 2006-07-18 2007-01-03 华为技术有限公司 在ip层实现头压缩及复用的方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6993021B1 (en) * 1999-03-08 2006-01-31 Lucent Technologies Inc. Lightweight internet protocol encapsulation (LIPE) scheme for multimedia traffic transport
KR100582575B1 (ko) * 2003-10-27 2006-05-23 삼성전자주식회사 멀티 프레임을 이용한 무선 통신 시스템의 데이터 전송방법

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1490987A (zh) * 2002-10-18 2004-04-21 ��Ϊ�������޹�˾ 一种在同步数字网上传送数据业务的方法
US20050043030A1 (en) * 2003-08-22 2005-02-24 Mojtaba Shariat Wireless communications system
CN1889575A (zh) * 2006-07-18 2007-01-03 华为技术有限公司 在ip层实现头压缩及复用的方法

Also Published As

Publication number Publication date
EP2053798B1 (en) 2013-01-16
ES2399929T3 (es) 2013-04-04
EP2053798A1 (en) 2009-04-29
EP2053798A4 (en) 2009-10-21
CN101242561A (zh) 2008-08-13
CN101242561B (zh) 2011-04-06

Similar Documents

Publication Publication Date Title
US9078290B2 (en) Uplink transmission method, downlink transmission method, and convergence device
US7944943B2 (en) Method and apparatus for MAC layer inverse multiplexing in a third generation radio access network
US7302497B2 (en) Using internet protocol (IP) in radio access network
US8059681B2 (en) Method and apparatus for transmitting/receiving packet in mobile communication system
WO2010031324A1 (zh) 数据传输的方法、装置和系统
US9001654B2 (en) Enhanced multiplexing for single RLC entity
AU2003290983B2 (en) System and method for communicating traffic between a cell site and a central office in a telecommunications network
WO2009026845A1 (fr) Procédé d'émission et de réception de données, appareil de point d'accès sans fil, passerelle et système de communication
KR100582575B1 (ko) 멀티 프레임을 이용한 무선 통신 시스템의 데이터 전송방법
CN100514975C (zh) 宽带码分多址网络中Iub接口数据传输方法
WO2008095394A1 (fr) Procédé et dispositif de transmission et de réception de données entre un contrôleur de réseau radio et un noeud de station
CN100466630C (zh) 移动通信网络中Iub接口数据传输方法及其系统
CN1332578C (zh) 基站和无线网络控制器间的传输系统及其方法
JP2005123787A (ja) 無線アクセスネットワークシステム及びデータ転送方法
KR20100082698A (ko) 다중화 ｍａｃ 헤더를 이용한 효율적인 데이터 전송방법 및장치
WO2006032203A1 (fr) Reseau d'acces radio et procede de communication correspondant
KR20100047788A (ko) Ｍａｃ 헤더를 이용한 효율적인 데이터 전송방법 및 장치

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2007817212

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE