HK1223481B - End-to-end (e2e) tunneling for multi-radio access technology (multi-rat) - Google Patents

Description

End-to-end (E2E) tunneling for multi-radio access technology (multi-RAT)

Background Art

Wireless mobile communication technologies use various standards and protocols to transmit data between nodes (e.g., transmitting stations) and wireless devices (e.g., mobile devices). Some wireless devices communicate using orthogonal frequency-division multiple access (OFDMA) for downlink (DL) transmissions and single carrier frequency division multiple access (SC-FDMA) for uplink (UL) transmissions. Standards and protocols that use orthogonal frequency-division multiplexing (OFDM) for signal transmission include the Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) (e.g., Release 11 or V11.3.0, dated June 2013), the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standards (e.g., 802.16e, 802.16m) (which is commonly referred to by the industry as WiMAX (Worldwide interoperability for Microwave Access)), and the IEEE 802.11 standards (e.g., 802.11ac, 802.11ad) (which is commonly referred to by the industry as WiFi (Wireless Fidelity)).

In a 3GPP radio access network (RAN) LTE system, a node may be a combination of an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly referred to as an evolved Node B, enhanced Node B, eNodeB, or eNB) and a Radio Network Controller (RNC), which communicates with wireless devices called user equipment (UE). Downlink (DL) transmissions may be communications from a node (e.g., an eNodeB) to a wireless device (e.g., a UE), and uplink (UL) transmissions may be communications from a wireless device to a node.

A wireless device may include mobile communication technology that communicates using multiple radio access technologies, such as LTE, WiMax, or WiFi. For example, in some configurations, a wireless device may include a radio that communicates via an eNB using LTE protocols, and a radio that communicates via a wireless access point (WAP) using WiFi protocols. In other configurations, a wireless device may include a single radio that communicates with both an eNB and a WAP.

When a wireless device (e.g., a mobile node) can simultaneously access both a wireless local area network (WLAN) (e.g., Wi-Fi) and a wireless wide area network (WWAN) (e.g., second generation/third generation (2G/3G) cellular, LTE, or WiMAX), the wireless device can select a network for Internet Protocol (IP) packet flows (e.g., IP flow mobility technology).

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the present disclosure will become apparent from the following detailed description taken in conjunction with the accompanying drawings, which together illustrate, by way of example, the features of the present disclosure; and in which:

1A illustrates a diagram of a multi-network configuration with Internet Protocol (IP) services, wherein a mobile node (e.g., UE) can simultaneously access a wireless local area network (WLAN) (e.g., Wi-Fi) and a wireless wide area network (WWAN) (e.g., LTE or WiMax), according to an example;

1B illustrates another diagram of a multi-network configuration with Internet Protocol (IP) services, according to an example, in which a mobile node (e.g., UE) can simultaneously access a wireless local area network (WLAN) (e.g., Wi-Fi) and a wireless wide area network (WWAN) (e.g., LTE or WiMax);

FIG2 illustrates a diagram of communication layers according to an example;

FIG3A illustrates a diagram of a multi-radio access technology (RAT) network and a mobile node (e.g., UE) that simultaneously accesses a wireless local area network (WLAN) (e.g., Wi-Fi) and a wireless wide area network (WWAN) (e.g., LTE or WiMax) via a multi-RAT control server and/or gateway (e.g., home agent) according to an example;

3B illustrates a layer diagram of a multi-radio access technology (RAT) network and a mobile node (e.g., UE) that simultaneously accesses a wireless local area network (WLAN) (e.g., Wi-Fi) and a wireless wide area network (WWAN) (e.g., LTE or WiMax) via a multi-RAT control server and/or gateway (e.g., home agent) according to an example;

FIG4 illustrates an enhanced tunneling header format according to an example;

FIG5 illustrates a diagram of a dynamic load balancing (DLB) operation according to an example;

6A illustrates a diagram of a client-initiated downlink dynamic load balancing (DLB) process according to an example;

6B illustrates a diagram of a client-initiated uplink dynamic load balancing (DLB) process according to an example;

7 depicts a flow diagram for sequencing packets in a tunnel layer using multiple radio access technologies (RATs), according to an example;

8 depicts functionality of computer circuitry of a mobile node for measuring quality of service (QoS) in a tunnel layer using multiple radio access technologies (RATs) according to an example; and

9 illustrates a diagram of a wireless device (eg, UE) according to an example.

Reference will now be made to the exemplary embodiments illustrated, and specific language will be used herein to describe the same, but it will be understood that no limitation of the scope of the invention is thereby intended.

DETAILED DESCRIPTION

Before disclosing and describing the present invention, it should be understood that the present invention is not limited to the specific structures, process steps or materials disclosed herein, but can be extended to equivalent forms thereof as recognized by those skilled in the relevant art. It should also be understood that the terms used herein are only used to describe specific examples and are not intended to be limiting. The same reference numerals in different figures represent the same elements. The numbers provided in the flow charts and processes are provided for clarity when illustrating the steps and operations and do not necessarily represent a specific order or sequence.

Exemplary embodiments

An initial summary of the technology embodiments is provided below, and specific technology embodiments are then further described in detail below. This initial overview is intended to help the reader understand the technology more quickly but is not intended to identify the key features or essential features of the technology, nor is it intended to limit the scope of protection of the claimed subject matter.

Internet Protocol (IP) flow mobility technology can support the simultaneous transmission of a single IP flow over multiple networks. As used herein, "single IP flow" or "single data flow" means a group of IP packets that can be classified into the same group for flow binding based on traffic selector information such as source IP address, destination IP address, protocol type, source port number, or destination port number. Using flow mobility technology to split individual IP flows across multiple available wireless networks can provide an enhanced user experience, such as higher aggregate throughput.

Figure 1A illustrates a multi-network configuration in which a mobile node (MN) 320 (e.g., a UE, mobile station (MS), subscriber station (SS), or mobile client) can access a wireless local area network (WLAN) (e.g., Wi-Fi) via a WLAN node 314 and a wireless wide area network (WWAN) (e.g., 2G/3G cellular, LTE, or WiMAX) via a WWAN node 312, and control IP intra-flow mobility. In one example, the mobile node can simultaneously connect to an IP service 330 via the Internet 350, WLAN, and WWAN. A multi-RAT control gateway (M-RAT C-GW) 352 can be coupled between the IP service and a radio access network (RAN) 316. The RAN can include nodes for various RATs, such as Wi-Fi, 2G/3G cellular, LTE, or WiMAX. The multi-RAT control gateway can be used to route IP flows via a tunnel layer to any available wireless network (e.g., WWAN or WLAN) in the RAN. The multi-RAT control gateway may include a multi-RAT control server to process packets and provide multi-RAT control gateway functions (e.g., multi-RAT resource control). In another example, the multi-RAT control gateway may communicate with a core network (CN) 340, as illustrated in FIG1A . In another configuration, the CN may include a multi-RAT control gateway, as illustrated in FIG1B .

In one configuration, the IP service 330 may be coupled to the server 332. The WLAN may operate using IEEE 802.11-based protocols. The WWAN may operate using 3GPP-based protocols, WiMax-based protocols, UMTS-based protocols, CDMA2000-based protocols, GSM-based protocols, CDPD-based protocols, and/or Mobitex-based protocols. Although Figures 1A-1B illustrate two different access points to the IP service as a WLAN node and a WWAN node, other configurations may be used, such as two or more WWAN nodes using different radio access technologies (RATs).

In an example, conventional IP flow mobility techniques allow a mobile node to send a binding update message to a home agent (HA) 356, which may be included in a multi-RAT control gateway 352. In one example, the multi-RAT control gateway may be included in a home core network for the mobile node 320. The HA may register multiple local IP addresses for the mobile node to a single permanent home address (i.e., HoA) at the home agent (HA). Each registered local IP address (e.g., a care-of address (CoA)) may correspond to a specific wireless network.

In conventional IP flow mobility techniques, a mobile node may have a registered CoA1 with a home agent for a first IP flow 364 (e.g., for a third-party application), and a registered CoA2 for a second IP flow 362 (e.g., a Voice over Internet Protocol (VoIP) application). The first IP flow may be sent to the mobile node via a WLAN using the local IP address CoA1, and the second IP flow 362 may be sent to the mobile node via a WWAN using CoA2. Both IP flows may use the same HoA, so moving flows from one network to another can be completely transparent from the perspective of the IP service application.

Alternatively, first IP flow 364 and second IP flow 362 may represent packets from a single split IP flow from IP service 330, as shown in FIG1A . Similar to switching an IP flow from one network to another, splitting an IP flow using at least two different networks can be transparent to the user (e.g., using the same HoA). Sequence-based flow splitting techniques that balance the load for specific IP flows can be used to increase end-to-end throughput. For example, a WiFi WLAN can be used to offload some or all of the WWAN traffic for an IP flow.

Each RAN connection (e.g., between a WiFi WAP and an LTE eNB) is referred to as a tunnel. Computer networks use tunneling protocols when one network protocol (i.e., transport protocol) encapsulates a different payload protocol. By using tunnels, a network can carry payloads across incompatible transport networks or provide a secure path through untrusted networks.

Techniques described herein (e.g., mobile nodes, IP services, multi-RAT control servers and/or gateways, methods, computer circuitry, systems, structures, and mechanisms) can support the delivery of a single Transmission Control Protocol (TCP) flow (e.g., a video stream over multiple radio access networks), including managing out-of-order delivery to improve TCP performance. A single TCP flow can use an enhanced tunnel header to provide seamless Wi-Fi offload and IP flow mobility solutions. The TCP flow can provide a tunnel layer (e.g., a User Datagram Protocol (UDP) tunnel or an IP-in-IP tunnel) to support and measure end-to-end (E2E or e2e) Quality of Service (QoS) performance. QoS performance measurements (e.g., local measurements) made by a mobile node (e.g., a client device) can be used to make network selection and flow mobility decisions. For example, an enhanced tunnel header and protocol that supports dynamic load balancing (DLB) with enhanced packet reordering capabilities can provide several enhancements to the tunnel layer.

The Transmission Control Protocol (TCP) is one of the core protocols in the Internet Protocol (IP) suite. TCP provides reliable, ordered, error-checked delivery of octet streams between programs running on computers connected to a local area network (LAN), intranet, or the public internet. TCP operates at the transport layer.

The User Datagram Protocol (UDP) is another core component of the IP suite, the network protocol suite used by the Internet. UDP allows computer applications to send messages, called datagrams, to other hosts on an IP network without requiring prior communication to set up a special transmission channel or data path.

Figure 1A illustrates an IP service that splits an IP flow into packets for a first IP flow 364 and a second IP flow 362. Figure 1B illustrates a multi-RAT control gateway 352 (e.g., home agent 356) that splits an IP flow 360 into packets for a first IP flow 364 and a second IP flow 362 based on various communication layers.

In computer networking and/or wireless communications, different functions may be provided by different layers in a protocol stack. A protocol stack may be an implementation of a set of computer networking protocols. A protocol stack (or set of protocols) may include definitions and implementations of protocols. Each layer or protocol in the protocol stack may provide a specific function. The modularization of layers and protocols may make the design and evaluation of computer networking and/or wireless communications easier. In one example, each protocol module or layer module in a protocol stack may communicate with at least two other modules (e.g., a higher layer and a lower layer). The lowest protocol or layer may provide low-level physical interaction with the hardware. Each higher layer may add more features. Upper or top layers may include user applications and services.

In an LTE system, communication layers 458 (e.g., LTE layer 478) may include a physical layer 460 (PHY 480) (i.e., layer 1 (L1)), a data link layer or link layer 462 (i.e., layer 2 (L2)), a network layer 462 (i.e., layer 3 (L3)), a transport layer 466 (i.e., layer 4 (L4)), a session layer 468 (i.e., layer 5 (L5)), and an application layer 470, as illustrated in FIG2 . In one example, the link layer may include a media access control (MAC), a radio link control (RLC), a packet data convergence protocol (PDCP), and a radio resource control (RRC) layer 482. The network layer may use the Internet Protocol (IP) 484, and the transport layer may use the Internet Transmission Control Protocol (TCP) 486 or the User Datagram Protocol (UDP) in the Internet protocol suite. In one example, a tunneling layer may occur within one of the communication layers. The session layer may use the hypertext transfer protocol (HTTP) 488. The application layer may include video, audio, voice, and timed text 494, a 3GPP file format 492, or a media presentation description (MPD) 490.

FIG3A illustrates IP flow #1 364 communicating from an IP service 330 to a mobile node 320 using a WLAN 324 (e.g., an access point (AP)), and IP flow #2 communicating from an IP service 330 to a mobile node 320 using a WWAN (e.g., an eNB, NB, or BS). FIG3B illustrates the communication layers for IP flow #1 and IP flow #2 from an IP service to a mobile node via a multi-RAT control server and/or gateway 358. Four communication layers for an IP service are shown, including an application layer (application program) 216, a transport layer (e.g., TCP or UDP) 226, an IP layer 236, and an L1 and/or L2 layer (e.g., Ethernet or physical layer) 246. Application layer traffic 218 and data are processed by the IP service and the mobile node. Six communication layers are shown at the mobile node, including an application layer (application) 210, a transport layer (e.g., TCP or UDP) 220, an IP layer, a tunneling layer (e.g., via UDP) 240, and an L1 and/or L2 layer (e.g., a physical layer for WLAN 260 and WWAN 268 signal processing). The IP layer may include a virtual IP layer 230 that provides a virtual IP address mapped to a physical IP address for tunneling and a physical IP layer 250 that provides a physical address to the WWAN or WLAN in the RAN 316.

The multi-RAT control server and/or gateway 358 can provide a tunnel interface between the IP service 330 and the mobile node 320. The multi-RAT control server and/or gateway can include an IP layer (virtual IP or VIP) 232 to interact with the mobile node and the IP layer to interact with the IP service, so that the underlying RAT used in the transmission is transparent to the IP flow 238. In one example, the IP flow can use a HoA and/or be associated with a virtual IP layer. In another example, the multi-RAT control server and/or gateway can act as a virtual private network (VPN) for the mobile node. The multi-RAT control server and/or gateway can use L1 and/or L2 layers (e.g., Ethernet protocol) 244 to provide physical layer communication with the IP service via a wired or optical connection. The tunnel layer (or tunnel layer) 242 can use the UDP protocol to provide multi-RAT resource control 248, such as DLB, IP flow mobility, and QoS measurement for the tunnel or RAN connection. The multi-RAT control server and/or gateway may provide mapping of IP flows 238 to physical IP (PIP) layer 256 addresses of access nodes (WAP, eNB, NB, or BS) of a WWAN or WLAN in the RAN. Each access node may have PIP 252 and 254 addresses and L1 and/or L2 layer processing (WLAN 262 and WWAN 264) to wirelessly transmit packets to the mobile node. Physical IPs (PIPs) 250, 252, 254, and 256 may be associated with a tunnel. In one example, the HoA of an IP flow may be mapped to a local IP address CoA1 for WLAN (e.g., IP flow #1) or to a local IP address CoA2 for WWAN (e.g., IP flow #2). The core network and/or RAN may provide L1 and/or L2 layer signaling (e.g., Ethernet, WiFi, WiMax, or LTE protocols) 266 for the access nodes. The L1 and/or L2 layers (eg, Ethernet) may be used by the multi-RAT control server and/or gateway to communicate with the RAN or core network.

Packet headers, packet formats, and packet configurations can be used to support different communication layers. For example, a packet may include an IP header (IP Hdr), a UDP header (UDP Hdr), an enhanced tunneling layer, and a payload. The payload may include the message or actual data to be sent.

The enhanced tunnel header can support dynamic load balancing (DLB) operations and E2E QoS measurements. In another example, the mobile node can represent one end (e.g., receiver or transmitter) in an end-to-end (E2E) QoS measurement, and the multi-RAT control server and/or gateway can represent the other end (e.g., transmitter or receiver). The enhanced tunnel header can include various parameters or bit fields, such as QoS parameters, resource management parameters, or administrative parameters. In one example, the enhanced tunnel header can include a total of four bytes. In other examples, each of the parameters in the enhanced tunnel header can have a varying bit size. The enhanced tunnel header can include all or some of the parameters required by the tunnel layer and QoS measurement.

QoS parameters may include the data transmission (DT: data transmission) time interval between a tunnel packet and the previous tunnel packet in a tunnel flow, or the sequence number (SN: sequence number) of the tunnel packet of the tunnel flow. In one example, the DT field may represent the transmission interval of the tunnel packet in time units (e.g., milliseconds (ms)) and may be used by the receiver to measure E2E delay variation. A timer in the transmitter may count the time between each tunnel packet and include the timer value in the DT field. The timer may be reset after the transmitted packet, or the transmission interval may be the difference between the transmitted packet and the previous packet. In another example, the DT bit field may be 7 bits long. For example, if the actual transmission interval is greater than (>) 127ms, the DT field may be set to a bit value of 127. The SN field may be the order of the tunnel packets. The SN field may be used for reordering and packet loss measurement. In one example, the DT field may be 7 bits and the SN field may be 16 bits.

Resource management parameters may include an aggregation bit field (A) indicating when a tunnel packet includes multiple Internet Protocol (IP) data packets, a compression bit field (C) indicating when header compression is used for an IP data packet, or a priority bit field (P) indicating the priority of the tunnel packet. Resource management parameters can be used to better manage resources for tunnel packets. Multiple packets at a transmitter (e.g., one end of a tunnel) can be combined or aggregated into a single aggregated packet to save header overhead. When aggregation is used, the A field can be set to alert receivers in other tunnels that the tunnel packet includes multiple smaller packets. Compression can be used to reduce header size. The C field indicates that compression is used for the header of the current tunnel packet, and receivers can decompress the header to obtain the header information. In one example, the A field and the C field can be a single bit. Priority can be assigned to each packet to ensure minimal delay for the highest priority data and traffic. The P field can indicate the priority of the tunnel packet, particularly when the priority in the IP header or UDP header is unavailable (e.g., due to layer header processing) or is compressed. For example, a lower or smaller number can indicate a higher priority. When two bits are used, four different priority levels can be used.

The administrative parameters include a type bit field (T) indicating whether the tunnel packet is for control (e.g., binding update or RRC messaging) or includes an IP data packet, a settings bit field (S) indicating when a tunnel packet uses a different tunnel burst size (TBS) setting than the previous tunnel packet, or a flow identifier (FID) for the tunnel packet. The tunnel burst size (TBS) can be the number of consecutive packets sent via a RAN connection (e.g., WiFi or cellular). The administrative parameters can provide administrative information for the tunnel packet. For example, the T field can indicate whether the tunnel payload carries an IP data packet (e.g., zero for data) or a control message (e.g., one for a control transmission message), such as a binding update (BU) message or a binding acknowledgement (BA). For example, the rest of the header fields can be valid only when T=0.

The S field can be used by the transmitter to signal to the receiver that the TBS setting for a stream has changed, allowing the receiver to detect out-of-order packet delivery. For example, the S field of a packet can be set to zero for one TBS setting, and then when the DLB process switches or changes to a different TBS setting, the S field can be set to one. With another change in the TBS setting, the S field can be set back to zero, and so on - oscillating between zero and one for each change in the TBS setting.

Figures 6A and 6B illustrate the use of the S field in the DLB process. For example, tbs(0) may represent a tunnel using a WiFi connection, and tbs(1) may represent a cellular connection (e.g., LTE or WiMax). When tbs(0)=2, two consecutive packets of a tunnel burst may be sent on the WiFi connection before the packet is sent on the cellular connection. When tbs(1)=2, then two consecutive packets of a tunnel burst may be sent on the cellular connection after the WiFi tunnel burst, as shown in packets 0-9 of Figure 5. After each burst, subsequent packets of the IP flow may be sent on the next connection until all connections are used, and then rotate back to the first connection. Referring back to Figures 6A and 6B, when the TBS settings for the IP flow are represented as tbs(0)=2 and tbs(1)=2, then the S field may be equal to zero (S=0). When a DLB process (e.g., used by a client) changes the TBS settings to tbs(0)=2 and tbs(1)=3, then subsequent packets may include S=1 in the tunnel header (i.e., an enhanced tunnel header) to indicate the change. When the DLB process again changes the TBS settings to another setting, such as tbs(0)=2 and tbs(1)=8, then subsequent packets may include S=0 in the tunnel header (e.g., switching the S field back to zero) to indicate the subsequent change. The switching of the S field may indicate a change in the DLB.

The FID field can be used to identify which flow a packet belongs to. In one example, to limit the size of the tunnel header, the FID field can be 3 bits. As defined in the 3GPP LTE standard (Release 11), the FID can be 16 bits. For example, flows with FIDs = 1 to 7 can have SNs counted separately from the FIDs. Flows with more than 7 FIDs (FIG>7) can be considered as a single flow with the FID field set to 0.

By including QoS parameters in the enhanced tunnel header, as illustrated in Figure 4, QoS metrics can be measured for each individual tunnel (or tunnel connection). Such QoS metrics may include packet loss rate, throughput, delay variation, reordering delay, congested packet ratio, or available bandwidth. Packet loss rate can be the number of packets lost from the total number of packets sent. The SN field allows each tunnel packet to have a unique number, so the packet loss rate can be calculated when the SN number is lost. Throughput can be the number of packets received in a period of time, such as 1 second (s).

Delay variation (or congestion period) can be represented by DRX-DTX, where DTX represents the time interval (e.g., delay) between two consecutive packets at the transmitter (TX), and DRX represents the time interval (e.g., delay) between two consecutive packets at the receiver (RX). The receiver may include a timer to determine the delay. Delay variation can use the DT field and the SN field. DTX can be determined from the DT field, and DRX can be determined by the delay between subsequent SNs. Delay variation can be used to detect congestion and measure the available bandwidth of a tunnel, and to compare the E2E latency between two tunnels. Based on the E2E latency, packets of an IP flow can be rerouted to a less congested tunnel connection using DLB operations.

Reordering delay can measure how long a packet waits at a receiver due to out-of-order delivery. The SN field can be used to detect the ordering and out-of-order delivery or reception of packets at a receiver. The congested packet ratio can be the number of packets experiencing congestion compared to the total number of transmitted packets. As already mentioned, the congested packet ratio can be calculated based on the delay variation exceeding a specified (or predetermined) threshold delay or congestion threshold. The threshold delay or congestion threshold can be determined statically (e.g., by a wireless standard or protocol) or dynamically based on other criteria. Available bandwidth can be the maximum achievable throughput of a tunnel. In one example, available bandwidth can represent the bandwidth without delay variation or congestion periods.

The determination of DLB or flow mobility can be made by a client (e.g., a mobile node) or a server (e.g., a multi-RAT control server and/or gateway). The client can measure downlink tunnel performance (e.g., using QoS metrics), and the server (e.g., an IP service) can measure uplink tunnel performance and report the QoS metrics back to the client, where the client can make the determination of DLB or flow mobility. Alternatively, the server can measure uplink tunnel performance (e.g., using QoS metrics), and the client (e.g., an IP service) can measure uplink tunnel performance and report the QoS metrics back to the server, where the server can make the determination of DLB or flow mobility.

DLB (dynamic load balancing) control parameters may include tunnel burst size (TBS), maximum aggregation delay (MAD) and re-ordering timer (ROT). DLB control parameters may be included in control message transmission (e.g., request, response, or acknowledgment (ACK)). TBS may be a parameter that specifies the number of consecutive packets sent via a connection that is over a specific network (e.g., WiFi or LTE). ROT may be a parameter that specifies the maximum time a packet waits at a receiver due to out-of-order transmission before a retransmission request is made. ROT may specify how long a packet waits in a reordering buffer until the previously in-sequence packet is received. In one example, ROT may use time units (e.g., rot = 0.5s). MAD may be a parameter that specifies the maximum time a packet may wait at a transmitter due to aggregation (e.g., putting multiple small packets into a single tunnel packet to reduce tunnel overhead). In one example, MAD may use time units (e.g., mad = 50ms).

Referring back to Figure 5, tbs(i) may represent the TBS of tunnel (i.e., connection) #i, where i is an integer. For example, i=0 may represent a WiFi tunnel, and i=1 may represent a cellular (e.g., LTE or WiMax) connection. Figure 5 illustrates how traffic may be split across WiFi and cellular. In this example, the DLB may start with an equal shared load between WiFi (i.e., tbs(0)=2) and cellular (e.g., tbs(1)=2). In packet #11, the WiFi load ratio may increase to 60% as the DLB changes (e.g., tbs(0)=3 and tbs(1)=2).

When TCP packets are split across multiple RAN connections (ie, tunnels), the receiver can reorder packets that were delivered out of order. However, packets may be lost in the tunnels due to unreliable wireless channels or buffer overflows.

Identifying at the receiver which tunnel a packet originated from can be used to distinguish between packet loss and out-of-order delivery and minimize unnecessary reordering delays. For example, if any consecutive packets from the same tunnel arrive, the receiver can determine that the packet was lost, assuming that packets from the same tunnel will never arrive out of order. Typically, packets from a particular network using the same network path will arrive in order, but this order may not apply to different tunnels or different networks. For example, if packet 3 arrives on a cellular tunnel and packet 2 does not, packet 2 can be considered lost, but if packet 1 does not arrive, the arrival of packet 3 cannot determine that the packet was lost because packet 1 was transmitted using a WiFi connection, which may have additional latency over a cellular connection. Enhanced tunnel headers and/or DLB control parameters can provide additional information to distinguish between packet loss and out-of-order delivery and minimize unnecessary reordering delays.

A deterministic tunnel burst scheduling strategy can be used to determine the order in which packets in IP flows sent to various tunnels are sent. For example, tunnels with smaller (or higher) binding IDs (BIDs) may be scheduled first in each round; the minimum SN may be "0" (e.g., the first packet of the first burst), which may represent the first packet of a burst in the tunnel with the smallest BID; and the maximum SN may be given by S _max = (2 ^L - 1), where L may represent the length of the SN field. The BID may be an unsigned integer that uniquely identifies a tunnel. The BID may be used to identify a network.

Since the rules (e.g., tunnel burst scheduling policy) can be known to both the transmitter and the receiver, the receiver can then determine which tunnel the lost packet came from based on the SN number of the lost packet and the current TBS setting. In another example, the rules can be known to and applied by the multi-RAT control server and/or gateway.

Referring back to Figures 6A and 6B, the dynamic load balancing (DLB) protocol can be illustrated. Figure 6A illustrates a client-initiated DLB process for the downlink, and Figure 6B illustrates a client-initiated DLB process for the uplink. In the client-initiated DLB process for the downlink (Figure 6A), the client (e.g., mobile node 320 (Figure 1)) can send a message to the server 332 (Figure 1) (via IP service 330 (Figure 1)). For example, the message may include an existing binding update message as defined in Mobile IP, or an RRC message used in LTE. Other message types for other wireless standards may also be used. The message may include a DLB request (DLB-REQ: DLB-request), which may indicate a new TBS setting for the flow identified by the FID (e.g., tbs(0)=2, tbs(1)=3, mad=50ms). The DLB-REQ may include various control parameters (e.g., TBS, ROT, or MAD). The server may then send a response message (e.g., DLB-RSP: DLB-response) which may include the starting SN for the DLB change. The response message may include an existing binding ACK (BA: binding ACK) message as defined in Mobile IP, or an RRC message used in LTE.

To ensure that both the client (e.g., mobile node) and the server (e.g., home agent) are synchronized regarding which packets the new TBS setting will begin to take effect on, the server may include starting SN information in the DLR-RSP for downlink transactions. The starting SN may represent the sequence number (SN) of the first packet that will use the new TBS setting. For the uplink, the client may send another DLB-REQ including the starting SN information after receiving the DLR-REP from the server.

In the client-initiated DLB procedure for the uplink ( FIG. 6B ), the client (e.g., a mobile node) may send a message to the server with control parameters (e.g., tbs(0)=2, tbs(1)=3, rot=0.5 ms) indicating a DLB request. The client-initiated DLB procedure for the uplink may use similar messaging to the client-initiated DLB procedure for the downlink. The server may acknowledge the change or request in the DLB-RSP. The client may provide a starting SN for the DLB change in the DLB-REQ, and the server may send the DLB-RSP. A DLB change may be initiated with the sending of the starting SN, even without a subsequent ACK.

The DLB process, protocol, or processing can help the receiver distinguish between packet loss and out-of-order delivery and minimize unnecessary reordering delays. Because the tunnel burst scheduling policy can be known to both the transmitter and the receiver, the receiver can determine when a packet has been lost from the tunnel based on the packet's SN and the current TBS setting, which can be sent using the DLB protocol. Reducing reordering delays and determining packet loss can utilize the SN and FID parameters in the enhanced tunnel header.

Another example provides a method 500 for ordering packets at the tunnel layer using multiple radio access technologies (RATs), as shown in the flowchart of FIG7 . The method may be executed as instructions on a machine or computer circuitry, wherein the instructions are embodied on at least one computer-readable medium or a non-transitory machine-readable storage medium. The method includes communicating a tunnel configuration via a message request and a message response, wherein the message request or message response includes dynamic load balancing (DLB) control parameters when the DLB changes, and the DLB control parameters include a maximum aggregation delay (MAD) value that provides a maximum time that a packet can wait at a transmitter due to packet aggregation, as shown in block 510 . The next operation of the method may be sending packets of the data flow into a separate tunnel connection, wherein at least two RATs communicate via the separate tunnel connection using the tunnel configuration, as shown in block 520 . The method may also include minimizing reordering delay using the DLB control parameters, as shown in block 530 .

In one example, the DLB control parameters may include a tunnel burst size (TBS) of a number of consecutive packets sent via the tunnel connection, a reordering timer (ROT) indicating the maximum time a packet can wait at a receiver due to out-of-order delivery, or a starting sequence number (SN) of packets of the flow indicating when the DLB changes. In another example, the operation of sending packets of the flow to a separate tunnel connection may further include: splitting the packets of the flow into the separate tunnel connection, or receiving packets of the flow from the separate tunnel connection.

In another configuration, the packet may use an enhanced tunnel header. The enhanced tunnel header may include quality of service (QoS) parameters, resource management parameters, or administrative parameters. The QoS parameters may include a data transfer (DT) time interval between a tunnel packet and a previous tunnel packet in a tunnel flow, or a sequence number (SN) of a tunnel packet. The resource management parameters may include an aggregation bit field (A) indicating when a tunnel packet includes multiple Internet Protocol (IP) data packets, a compression bit field (C) indicating when header compression is used for an IP data packet, or a priority bit field (P) indicating the priority of the tunnel packet. Administrative parameters may include a type bit field (T) indicating whether the tunnel packet is used for control or includes an IP data packet, a setting bit field (S) indicating when a tunnel packet uses a tunnel burst size (TBS) setting different from that of a previous tunnel packet, or a flow identifier (FID) of the tunnel packet. In another example, the method may further include generating a QoS metric from the QoS parameters within the enhanced tunnel header of the received packet.

In another example, the different RATs may include 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE), Institute of Electrical and Electronics Engineers (IEEE) 802.16, Worldwide Interoperability for Microwave Access (WiMAX), IEEE 802.11, or Wireless Fidelity (WiFi). In another configuration, the operation of sending packets of the flow into a separate tunnel connection may also include: sending packets in downlink transmission from the multi-RAT control server and/or gateway (or Internet Protocol (IP) service) via a base station (BS), Node B (NB), or evolved Node B (eNB) to the mobile node; or sending packets in uplink transmission from the mobile node via a BS, NB, or eNB to the multi-RAT control server and/or gateway (or IP service). The IP service may be coupled to the server. The multi-RAT control server and/or gateway may be coupled between the IP service and the BS, NB, or eNB.

In another configuration, the method may further include scheduling packets in a burst of tunnels, wherein a tunnel with a smaller binding identifier (BID) is scheduled first and then a tunnel with a second smallest BID is scheduled next, and a smallest sequence number (SN) represents a first packet of the burst in the tunnel with the smallest BID, and a maximum SN is represented by S _max =(2 ^L -1), where L represents a length of the SN bit field.

Another example provides functionality 600 of a computer circuit system for a mobile node measuring quality of service (QoS) in a tunnel layer using multiple radio access technologies (RATs), as shown in the flowchart of FIG8 . The functionality may be implemented as a method, or the functionality may be executed on a machine as instructions, wherein the instructions are included on at least one computer-readable medium or a non-transitory machine-readable storage medium. The computer circuit system may be configured to receive packets of a data flow from a separate tunnel connection, wherein at least two different RATs communicate via the tunnel connection, as shown in block 610. The computer circuit system may also be configured to generate a QoS metric for the data flow from a QoS parameter within an enhanced tunnel header of the received packet, as shown in block 620.

In another configuration, the computer circuitry may be configured to receive packets of the data flow from a separate tunnel connection over which the RATs communicate. The computer circuitry may also be configured to generate a QoS metric for the data flow from QoS parameters within an enhanced tunnel header of the received packets.

In one example, the QoS parameters may include a data transfer (DT) time interval between a tunnel packet and a previous tunnel packet in a tunnel flow, or a sequence number (SN) of a tunnel packet.

In another example, QoS metrics can provide end-to-end QoS performance measurements. QoS performance measurements can include: packet loss rate based on SN; delay variation based on DT and SN; reordering delay based on SN; congested packet ratio based on delay variation; throughput based on the number of packets received within a duration; or available bandwidth based on throughput and delay variation.

In another configuration, the enhanced tunnel header may include resource management parameters or administrative parameters. The resource management parameters may include an aggregation bit field (A) indicating when a tunnel packet includes multiple Internet Protocol (IP) data packets, a compression bit field (C) indicating when header compression is used for an IP data packet, or a priority bit field (P) indicating the priority of the tunnel packet. The administrative parameters may include a type bit field (T) indicating whether the tunnel packet is used for control or includes an IP data packet, a setting bit field (S) indicating when the tunnel packet uses a different configuration. The different configuration may include a tunnel burst size (TBS) or a flow identifier (FID) of the tunnel packet that is different from the previous tunnel packet. In another example, the different RAT may include Third Generation Partnership Project (3GPP) Long Term Evolution (LTE), Institute of Electrical and Electronics Engineers (IEEE) 802.16 or Worldwide Interoperability for Microwave Access (WiMAX) or IEEE 802.11 or Wireless Fidelity (WiFi).

In another example, the computer circuit system may be further configured to determine a tunnel burst schedule for the received packets. The tunnel with the smaller (or larger) binding identifier (BID) may be scheduled first, then the tunnel with the second smallest (largest) BID may be scheduled next, and the smallest sequence number (SN) represents the first packet of the burst in the tunnel with the smallest BID, and the largest SN is represented by S _max = (2 ^L -1), where L represents the length of the SN bit field. In another configuration, the computer circuit system may be further configured to use the enhanced tunnel header of the received packet to reorder packets from the stream of the separate tunnel connection.

In another configuration, the computer circuitry may be further configured to: send a message request to a multi-RAT control server and/or gateway to change dynamic load balancing (DLB) between tunnel connections based on a QoS metric; receive a message response from the multi-RAT control server and/or gateway during downlink DLB processing, the message response having a starting sequence number (SN) of tunnel packets of a flow indicating when the DLB was changed; receive a message response from the multi-RAT control server and/or gateway confirming the DLB change during uplink DLB processing; and send a message request to the multi-RAT control server and/or gateway during uplink DLB processing, the message request having a starting SN of tunnel packets of a flow indicating when the DLB was changed. For LTE, the message request may include a DLB request, and the message response may include a DLB response.

The message request and message response use radio resource control (RRC) messages for communication using 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE). The message request may include a binding update, and the message response may include a binding acknowledgment (ACK) for a mobile IP flow. The message request may include a change in the tunnel burst size (TBS) for each tunnel connection. The message request for downlink DLB processing may include a maximum aggregate delay (MAD), and the message request for uplink DLB processing may include a reordering timer (ROT) value.

In another configuration, the mobile node comprises a user equipment (UE), a mobile station (MS), or a mobile client.

Referring back to Figure 1, the mobile node 320 may include a transceiver and a processor. The processor and/or transceiver of the mobile node may be configured to reorder packets in the tunnel layer using multiple radio access technologies (RATs), as shown in 500 of Figure 7. In another configuration, the processor and/or transceiver of the mobile node may be operable to measure quality of service (QoS) in the tunnel layer using multiple radio access technologies (RATs), as shown in 600 of Figure 8.

Figure 9 provides an example illustration of a wireless device, such as a user equipment (UE), a mobile station (MS), a mobile wireless device, a mobile communication device, a tablet computer, a cell phone, or other type of wireless device. The wireless device may include one or more antennas configured to communicate with a node (or access node or transmitting station), such as a base station (BS), an evolved Node B (eNB), a Node B (NB), a baseband unit (BBU), a remote radio head (RRH), remote radio equipment (RRE), a relay station (RS), radio equipment (RE), a remote radio unit (RRU), a central processing module (CPM), or other type of wireless wide area network (WWAN) access point. The wireless device may be configured to communicate using at least one wireless communication standard, including 3GPP LTE, WiMAX, High Speed Packet Access (HSPA), Bluetooth, and WiFi. The wireless device may communicate using separate antennas for each wireless communication standard or using a shared antenna for multiple wireless communication standards. Wireless devices can communicate in wireless local area networks (WLANs), wireless personal area networks (WPANs), and/or WWANs.

FIG9 also illustrates a microphone and one or more speakers that can be used for audio input and output from the wireless device. The display screen can be a liquid crystal display (LCD) screen, or another type of display screen, such as an organic light emitting diode (OLED) display. The display screen can be configured as a touch screen. The touch screen can use capacitive, resistive, or another type of touch screen technology. An application processor and a graphics processor can be coupled to internal memory to provide processing and display capabilities. A non-volatile memory port can also be used to provide data input/output options to the user. The non-volatile memory port can also be used to expand the memory capacity of the wireless device. A keyboard can be integrated with the wireless device or wirelessly connected to the wireless device to provide additional user input. A virtual keyboard can also be provided using the touch screen.

At a high level, a network may include a core network (CN), such as an evolved packet core (EPC), and an air interface access network (E-UTRAN). The CN may be responsible for overall control and bearer establishment for various user equipment (UE) connected to the network. The CN may include functional entities such as a multi-RAT control gateway, a home agent (HA), and/or any access network discovery and selection function (ANDSF) servers or entities. The E-UTRAN may be responsible for radio-related functions.

Some of the main logical nodes of the CN may include a serving gateway general packet radio service (GPRS) support node (GGSN), a mobility management entity (MME), a home subscriber server (HSS), a serving gateway (SGW or S-GW), a packet data network (PDN) gateway, and a policy and charging rules function (PCRF) manager. Each of the network elements of the CN can be interconnected by well-known standardized interfaces such as interfaces S3, S4, or S5.

Referring back to Figures 1A-1B, the Internet Protocol (IP) service 330 may include a transceiver 334 and a processor 336. In another example, the multi-RAT control gateway may be configured to provide quality of service (QoS) parameters in an enhanced tunnel header. In one example, the transceiver and processor functions applicable to the multi-RAT control gateway may be applied to the IP service. The processor may be configured to split packets of a data stream into separate tunnel connections. At least two different RATs (e.g., WiFi, WiMAX, or LTE) may communicate via the tunnel connections. The transceiver may be configured to: send downlink packets with an enhanced tunnel header to the mobile node using one of the tunnel connections during downlink transmission, and receive uplink packets with an enhanced tunnel header from the mobile node using one of the tunnel connections during uplink transmission. The enhanced tunnel header may include QoS parameters.

In another configuration, the QoS parameters may include a data transfer (DT) time interval between a tunnel packet and a previous tunnel packet in a tunnel flow, or a sequence number (SN) of a tunnel packet. The enhanced tunnel header may include resource management parameters and administrative parameters. The resource management parameters may include an aggregation bit field (A) indicating when a tunnel packet includes multiple Internet Protocol (IP) data packets, a compression bit field (C) indicating when header compression is used for an IP data packet, or a priority bit field (P) indicating the priority of the tunnel packet. The administrative parameters may include a type bit field (T) indicating whether the tunnel packet is used for control or includes an IP data packet, a setting bit field (S) indicating when a tunnel packet uses a different tunnel burst size (TBS) setting than a previous tunnel packet, or a flow identifier (FID) of the tunnel packet. Different RATs may include Third Generation Partnership Project (3GPP) Long Term Evolution (LTE), Institute of Electrical and Electronics Engineers (IEEE) 802.16 or Worldwide Interoperability for Microwave Access (WiMAX) or IEEE802.11 or Wireless Fidelity (WiFi).

In another example, the processor may be further configured to schedule packets in a tunnel burst for separate tunnel connections. The tunnel with the smaller (or larger) binding identifier (BID) may be scheduled first, and then the tunnel with the second smallest BID may be scheduled next. The smallest sequence number (SN) represents the first packet in the burst of the tunnel with the smallest BID. The maximum SN may be represented by S _max = (2 ^L - 1), where L represents the length of the SN bit field.

In another configuration, the transceiver may be further configured to communicate tunnel configurations via message requests and message responses. The message request or message response may include a starting sequence number (SN) of a packet representing when dynamic load balancing (DLB) changes. The message request may include a DLB request, and the message response may include a DLB response. The message request and message response may use radio resource control (RRC) messages for third generation partnership project (3GPP) long term evolution (LTE). In another example, the information request may include a binding update, and the message response may include a binding acknowledgment (ACK) for a mobile IP flow. The message request may include a DLB control parameter having a tunnel burst size (TBS), a reordering timer (ROT), or a maximum aggregation delay (MAD).

The multi-RAT control gateway 352 can be coupled to the server 354 and can communicate with the mobile node 320 via a base station (BS), a node B (NB), an evolved node B (eNB), a baseband unit (BBU), a remote radio head (RRH), a remote radio equipment (RRE), a remote radio unit (RRU), a central processing module (CPM), a WLAN node 314, or a WWAN node 312.

The various techniques or aspects or portions thereof may take the form of program code (i.e., instructions) embodied in a tangible medium, such as a floppy disk, a compact disc read-only memory (CD-ROM), a hard drive, a non-transitory computer-readable storage medium, or any other machine-readable storage medium, wherein when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the various techniques. A circuit system may include hardware, firmware, program code, executable code, computer instructions, and/or software. A non-transitory computer-readable storage medium may be a computer-readable storage medium that does not include signals. In the case of program code execution on a programmable computer, the computing device may include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. The volatile and non-volatile memory and/or storage elements may be random access memory (RAM), erasable programmable read-only memory (EPROM), a flash drive, an optical drive, a hard drive, a solid-state drive, or other media for storing electronic data. The nodes and wireless devices may also include a transceiver module (i.e., a transceiver), a counter module (i.e., a counter), a processing module (i.e., a processor), and/or a clock module (i.e., a clock) or a timer module (i.e., a timer). One or more programs that can implement or utilize the various techniques described herein can use an application programming interface (API), reusable controls, etc. However, if desired, the one or more programs can be implemented in component or machine language. In any case, the language can be an assembled or interpreted language and combined with hardware implementation.

It should be understood that many of the functional units described in this specification have been labeled as modules in order to more specifically emphasize their implementation independence. For example, a module can be implemented as a hardware circuit including custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module can also be implemented in a programmable hardware device, such as a field programmable gate array, a programmable logic array, a programmable logic device, and the like.

Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for example, comprise one or more physical or logical blocks of computer instructions, which may, for example, be organized as objects, procedures, or functions. However, the executable files of an identified module need not be physically located together, but may comprise discrete instructions stored in different locations that, when logically joined together, comprise the module and achieve the stated purpose for the module.

Of course, the module of executable code can be a single instruction, or many instructions, and can even be distributed on several different code segments, in different programs, and distributed across several memory devices. Similarly, operational data can be identified and illustrated in this article within the module, and can be implemented in any suitable form and organized within the data structure of any suitable type. Operational data can be collected as a single data set, or can be distributed in different locations (including being distributed on different storage devices), and can exist at least in part only as an electronic signal on a system or network. A module can be passive or active, including an agent that can be operated to perform a desired function.

Reference throughout this specification to "example" or "exemplary" means that a particular feature, structure, or characteristic described in connection with the example is included in at least one embodiment of the present invention. Thus, the appearances of the phrase "in one example" or the word "exemplary" in various places throughout this specification are not necessarily all referring to the same embodiment.

As used herein, multiple items, structural elements, composite elements and/or materials may be present in a common list for convenience. However, these lists should not be interpreted as each member of the list being individually identified as a separate and unique member. Therefore, no individual member of this list should be interpreted as a de facto equivalent of any other member of the same list solely based on the presence of the other member in the common set without any contrary indication. In addition, various embodiments and examples of the present invention may be mentioned herein together with alternative forms of its various components. It should be understood that such embodiments, examples and alternative forms should not be interpreted as de facto equivalents of each other, but should be considered as separate and autonomous representative forms of the present invention.

In addition, the described features, structures or characteristics can be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details, such as layout examples, distances, network examples, etc., are provided to provide a thorough understanding of embodiments of the present invention. However, those skilled in the relevant art will recognize that the present invention can be practiced without one or more of these specific details or with other methods, components, layouts, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the present invention.

Although the foregoing examples illustrate the principles of the present invention in one or more specific applications, it will be apparent to those skilled in the art that numerous modifications may be made in the form, use, and details of the embodiments without inventiveness and without departing from the principles and concepts of the present invention. Therefore, the present invention is not limited except as set forth in the claims set forth below.

Claims (23)

1. A mobile node for measuring Quality of Service (QoS) in a tunnel layer using multiple radio access technology (RAT), comprising a computer circuitry system configured to perform the following functions: Receive packets of data stream from a separate tunnel connection, wherein the RAT communicates via the tunnel connection; and Generate a QoS metric for the data stream from the QoS parameters within the enhanced tunnel header of the received packets. The computer circuit system is further configured to: The tunnel burst scheduling of the received packets is determined, wherein the tunnel with the smaller Binding Identifier (BID) is scheduled first, followed by the tunnel with the second smallest BID, and the minimum sequence number (SN) represents the first packet in the burst of the tunnel with the minimum BID, and the maximum SN is represented by _Smax = ( ^2L - 1), where L represents the length of the SN bit field; and The packets from the stream of the separated tunnel connection are reordered using the enhanced tunnel header of the received packets. 2. The mobile node of claim 1, wherein the QoS parameter includes a data transmission (DT) time interval between tunnel packets and previous tunnel packets in the tunnel flow, or a sequence number (SN) of a tunnel packet. 3. The mobile node of claim 2, wherein the QoS metric provides end-to-end QoS performance measurement, comprising: Based on the packet loss rate of the aforementioned SN; Based on the delay changes of the DT and the SN; Reordering delay based on the SN; Based on the congestion grouping ratio of the aforementioned delay variation; Throughput based on the number of packets received during the duration; or Available bandwidth based on the throughput and the latency variation. 4. The mobile node of claim 1, wherein the enhanced tunnel header includes resource management parameters or administrative parameters, wherein the resource management parameters include an aggregation bit field (A) indicating when a tunnel packet includes multiple Internet Protocol (IP) data packets, a compression bit field (C) indicating when header compression is used for IP data packets, or a priority bit field (P) indicating the priority of the tunnel packet, and wherein the administrative parameters include a type bit field (T) indicating whether the tunnel packet is used to control or include the IP data packets, a setting bit field (S) indicating when the tunnel packet uses a different configuration, and the different configuration includes a tunnel burst size (TBS) from a previous tunnel packet or a flow identifier (FID) of the tunnel packet. 5. The mobile node of claim 1, wherein the multiple RATs include 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE), Institute of Electrical and Electronics Engineers (IEEE) 802.16 or WiMAX or IEEE 802.11 or WiFi. 6. The mobile node of claim 1, wherein the computer circuitry is further configured to: Send a message request to the multiple RAT control gateways to change the dynamic load balance (DLB) between the tunnel connections based on the QoS metric. During downlink DLB processing, a message response is received from the multi-RAT control gateway, which has a start sequence number (SN) of the tunnel packet of the flow indicating when the DLB changes; During uplink DLB processing, receive a message response from the multi-RAT control gateway confirming the DLB change; and During the uplink DLB processing, a message request is sent to the multi-RAT control gateway, the message request having the start SN of the tunnel packet of the flow indicating when the DLB changes. 7. The mobile node according to claim 6, wherein: The message request includes a DLB request, and the message response includes a DLB response; and the message request and the message response use Radio Resource Control (RRC) messages for communication using 3GPP Long Term Evolution (LTE); and The message request includes a binding update, and the message response includes a binding acknowledgment (ACK) for the mobile IP flow. 8. The mobile node of claim 6, wherein the message request includes a change in the tunnel burst size (TBS) for each tunnel connection, and the message request for downlink DLB processing includes the maximum aggregation delay (MAD), and the message request for uplink DLB processing includes a reordering timer (ROT) value. 9. The mobile node of claim 1, wherein the mobile node includes a user equipment (UE), a mobile station (MS), or a mobile client, and the mobile node includes an antenna, a touch-sensitive display, a speaker, a microphone, a graphics processor, an application processor, internal memory, or a non-volatile memory port. 10. A method for sequencing packets in a tunnel layer using multiple radio access technology (RAT), comprising: Tunnel configuration is transmitted via message requests and message responses, wherein the message request or the message response includes dynamic load balancing (DLB) control parameters when the DLB changes, and the DLB control parameters include a maximum aggregate delay (MAD) value that provides the maximum time a packet may wait at the transmitter due to packet aggregation. Packets of data streams are sent to separate tunnel connections, wherein at least two RATs use the tunnel configuration to communicate via the separate tunnel connections; and The reordering latency is minimized using the aforementioned DLB control parameters. The method further includes: The packets in the scheduling tunnel burst are arranged such that the tunnel with the smaller binding identifier (BID) is scheduled first, then the tunnel with the second smallest BID is scheduled next, and the minimum sequence number (SN) represents the first packet in the burst of the tunnel with the minimum BID, and the maximum SN is represented by S _max = ( ^2L - 1), where L represents the length of the SN bit field. 11. The method of claim 10, wherein the DLB control parameters include the tunnel burst size (TBS) of a plurality of consecutive packets transmitted via the tunnel connection, a reorder timer (ROT) indicating the maximum time a packet may wait at the receiver due to out-of-order delivery, or the start sequence number (SN) of the packets in the stream indicating when the DLB changes. 12. The method of claim 10, wherein sending packets of the stream to a separate tunnel connection further comprises: The packets of the stream are split into the separate tunnel connections, or the packets of the stream are received from the separate tunnel connections. 13. The method of claim 10, wherein the packet uses an enhanced tunnel header, and the enhanced tunnel header includes a Quality of Service (QoS) parameter, a resource management parameter, or a regulatory parameter, wherein the QoS parameter includes a data transfer (DT) time interval between a tunnel packet and a previous tunnel packet in the tunnel flow, or a sequence number (SN) of the tunnel packet, and wherein the resource management parameter includes an aggregation bit field (A) indicating when the tunnel packet includes multiple Internet Protocol (IP) data packets, a compression bit field (C) indicating when header compression is used for IP data packets, or a priority bit field (P) indicating the priority of the tunnel packet, and wherein the regulatory parameter includes a type bit field (T) indicating whether the tunnel packet is used to control or include the IP data packets, a setting bit field (S) indicating when the tunnel packet uses a different tunnel burst size (TBS) setting than the previous tunnel packet, or a flow identifier (FID) of the tunnel packet. 14. The method of claim 13, further comprising: A QoS metric is generated from the QoS parameters within the enhanced tunnel header of the received packet. 15. The method of claim 10, wherein sending packets of the stream to a separate tunnel connection further comprises: In downlink transmission, the packets are sent from the multi-RAT control gateway to the mobile node via a base station (BS), node B (NB), or evolved Node B (eNB); or In uplink transmission, the packet is sent from the mobile node to the multi-RAT control gateway via the BS, the NB, or the eNB. The multi-RAT control gateway is coupled to the server. 16. A system for sequencing packets in a tunnel layer using multiple radio access technology (RAT), comprising a module for implementing the method of any one of claims 10-15. 17. A multi-radio access technology (multi-RAT) control gateway for providing Quality of Service (QoS) parameters in an enhanced tunnel header, comprising: A processor for splitting packets of a data stream into separate tunnel connections, wherein at least two different RATs communicate via said tunnel connections; and Transceiver, which: During downlink transmission, a downlink packet with the enhanced tunnel header is sent to the mobile node using one of the tunnel connections; and During uplink transmission, an uplink packet with the enhanced tunnel header is received from the mobile node using one of the tunnel connections. The enhanced tunnel header includes QoS parameters. The processor is further configured to schedule packets in a tunnel burst for the separate tunnel connection, wherein the tunnel with the smaller binding identifier (BID) is scheduled first, followed by the tunnel with the second smallest BID, and the minimum sequence number (SN) represents the first packet in the burst of the tunnel with the minimum BID, and the maximum SN is represented by _Smax = ( ^2L -1), where L represents the length of the SN bit field. 18. The multi-RAT control gateway of claim 17, wherein the QoS parameter includes a data transmission (DT) time interval between tunnel packets and previous tunnel packets in a tunnel flow, or a sequence number (SN) of a tunnel packet. 19. The multi-RAT control gateway of claim 17, wherein the enhanced tunnel header includes resource management parameters and administrative parameters, wherein the resource management parameters include an aggregation bit field (A) indicating when a tunnel packet includes multiple Internet Protocol (IP) data packets, a compression bit field (C) indicating when header compression is used for IP data packets, or a priority bit field (P) indicating the priority of the tunnel packet, and wherein the administrative parameters include a type bit field (T) indicating whether the tunnel packet is used to control or include the IP data packets, a setting bit field (S) indicating when the tunnel packet uses a different tunnel burst size (TBS) setting than a previous tunnel packet, or a flow identifier (FID) of the tunnel packet. 20. The multi-RAT control gateway of claim 17, wherein the multi-RAT includes 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE), Institute of Electrical and Electronics Engineers (IEEE) 802.16 or WiMAX or IEEE 802.11 or WiFi. 21. The multi-RAT control gateway according to claim 17, wherein The transceiver is also configured to communicate tunnel configuration via message requests and message responses, wherein the message request or the message response includes a start sequence number (SN) of the tunnel packet of the flow indicating when the dynamic load balancing (DLB) changes. 22. The multi-RAT control gateway of claim 17, wherein the multi-RAT control gateway is coupled to a server and communicates with the mobile node via a base station (BS), a node B (NB), an evolved node B (eNB), a baseband unit (BBU), a remote radio head (RRH), a remote radio device (RRE), a remote radio unit (RRU), or a central processing module (CPM). 23. A non-transitory machine-readable storage medium for wireless communication, storing a plurality of instructions executable by a processor to implement the method according to any one of claims 10-15.