HK1225217B - Measuring link performance using multiple radio access networks - Google Patents

Description

Measure link performance using multiple radio access networks

Background Art

Mobile device users often utilize their devices to receive multimedia content, such as streaming audio, video, or data, from communication nodes. Mobile computing devices, such as desktop computers, smartphones, ultrabooks, or tablets, are increasingly equipped with multiple transceivers supporting different Radio Access Networks (RANs), such as Wi-Fi and cellular. Similarly, it is common to find overlapping coverage between multiple RANs operating at different bandwidths. Mobile devices equipped with multiple transceivers are able to access different RAN networks to deliver content.

However, the various RATs typically operate independently in a wireless-enabled communication environment. For example, a user of a multi-radio access mobile device or user equipment (UE) can selectively decide to operate in Wi-Fi mode or in cellular mode. Alternatively, the device can automatically make the selection for the user. Although for some types of applications, such as delay-sensitive applications, the selected wireless link can provide a smooth experience to the user, it is not uncommon to experience interruptions manifested by dropped calls, buffering delays, transmission errors, and slow connections.

Virtual access network (VAN) technology allows for seamless end-to-end integration of multiple heterogeneous radio access networks (RANs), enabling advanced multi-radio resource management. However, VANs struggle to effectively compare the availability and throughput of different RATs.

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, features of the present disclosure; wherein:

FIG1 illustrates a real-time traffic flow measurement (RTFM) monitor according to an example;

FIG2 illustrates an integrated multi-radio access network (RAN) protocol stack, according to an example;

3A and 3B illustrate an embodiment of an integrated multi-RAN architecture, according to an example;

FIG4 illustrates the workflow of downlink RTFM according to an example;

5 and 6 illustrate diagrams of a VAN server communicating with a mobile node during passive and active measurements, according to examples;

FIG7 illustrates a diagram of a VAN server transmitting low priority and high priority data packets to a mobile node, according to an example;

FIG8 illustrates the functionality of computer circuitry of a mobile node for measuring link performance using multiple radio access networks (RANs), according to an example;

FIG9 illustrates the functionality of computer circuitry of a VAN server for measuring link performance using multiple RANs, according to an example.

FIG10 illustrates a method for measuring link performance using multiple RANs according to an example;

FIG11A illustrates a new S-bit field added to a VAN data packet header, according to an example;

FIG. 11B illustrates, according to an example, RTFM active measurement parameters and RTFM trigger event notifications added to a VAN control message; and

FIG12 illustrates a diagram of a user equipment (UE), according to an example.

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

DETAILED DESCRIPTION

Before disclosing and describing the present invention, it should be understood that the present invention is not limited to the specific structures, processing steps or materials disclosed herein, but is extendable to equivalents of the specific structures, processing steps or materials that would be recognized by a person of ordinary skill in the art. It should also be understood that the terminology used herein is only used to illustrate specific examples and is not meant to be limiting. The same reference numerals in different figures represent the same elements. The numbers provided in the flow charts and processes are used to clearly illustrate the steps and operations and do not necessarily indicate a specific order or sequence.

Virtual Access Network (VAN) technology allows for seamless end-to-end integration of multiple heterogeneous Radio Access Networks (RANs), enabling advanced multi-radio access resource management technologies, such as seamless traffic offload, flow mobility, bandwidth aggregation, and load balancing, in mobile devices such as user equipment (UE) or mobile stations (MS). RANs operate on defined wireless frequency bands, such as Wi-Fi and 3GGPP cellular.

Although the term "UE" is used throughout this application in general relation to Third Generation Partnership Project (3GPP) specifications, this term is not intended to be limiting. Other types of wireless wide area network (WWAN) cellular technologies may also be used in accordance with embodiments of the present invention, including the Institute of Electrical and Electronics Engineers (IEEE) 802.16 specification (commonly known as WiMAX). Other wireless local area network (WLAN) RATs that may be used in embodiments of the present invention include, but are not limited to, IEEE 802.11 (WiFi), IEEE 802.15, and Bluetooth specifications.

When a user attempts to access a radio access network (RAN), the UE can select the type of network, or RAN, used to transmit and access data, such as WLAN (Wi-Fi) or a cellular network. In one embodiment, an example of multimedia content is provided to illustrate delay-sensitive data that needs to be received promptly. However, the UE can access any type of data. When accessing delay-sensitive or low-latency data, such as multimedia content, real-time traffic measurement (RTFM) can be monitored to maintain connectivity or to maintain the desired data flow.

RTFM provides reporting information about traffic on the Internet. RTFM can be used to measure traffic in three broad areas: clients and servers, network segments, and mesh networks. RTFM is advantageous when using low-latency Internet applications such as video conferencing, live streaming, or other low-latency applications. Flow mobility can be monitored using RTFM monitors.

FIG1 illustrates one embodiment of a mobile node 110 including a RTFM monitor 150. The RTFM monitor 150 may be included in the mobile node. Alternatively, the VAN client 120, the WLAN radio 130, and the cellular radio 140 may be co-located in the mobile node 110. In another embodiment, the RTFM monitor 150 may be located in at least one of the VAN client 120, the WLAN radio 130, or the cellular radio 140. In one embodiment, the RTFM monitor 150 is configured to monitor traffic related to the WLAN RAN and the cellular RAN to help determine which RAN the mobile node should use.

In one embodiment, the RTFM monitor is configured to monitor a packet flow of a network. In one embodiment, a packet flow is a set of ordered packets that pass through the network in a given direction and are close in time. A packet flow may consist of packets that have common characteristics, such as a source Internet Protocol (IP) address; a destination Internet Protocol (IP) address; a transport protocol, such as TCP or UDP; a source port; and/or a destination port.

The access network may be a client-server based network, where a server provides an IPv4(v6) address to a client for Internet access.

2 illustrates one embodiment of an integrated multi-RAN protocol stack 210. In one embodiment, the integrated multi-RAN protocol stack 210 includes an application layer 220, a transport layer 230 such as a transmission control protocol (TCP) or a user datagram protocol (UDP), an Internet Protocol (IP) layer 240, a VAN layer 250, and a RAN layer 280. In one embodiment, the RAN layer 280 includes a WLAN link, such as a wireless fidelity (Wi-Fi) link 260, and a cellular link 270.

Figures 3A and 3B illustrate an embodiment of an integrated multi-RAN architecture. Multiple radio access network selection and flow mobility decisions can be made by a VAN client operating on a UE 310. In Figure 3A, UE 310 can connect to the Internet 370 via a cellular RAN connection, RAN 1 320, via a cellular base station (BS) 340. UE 310 can also connect to the Internet using RAN 2 330, such as a WiFi connection, via a Wi-Fi access point (AP) 350.

3A also illustrates that in one embodiment, VAN server 360 may not be co-located with Wi-Fi AP 350 and cellular BS 340. In another embodiment, as illustrated in FIG3B, the VAN server, Wi-Fi AP, and cellular BS may be co-located at node 380.

In one embodiment, a radio access network (VAN) may be an access network that operates over-the-top of one or more RANs by utilizing tunneling protocols such as mobile IP or a virtual private network (VPN). In another embodiment, the VAN may operate directly on multiple RANs.

In one embodiment, the client-centric RTFM monitoring method may consist of two steps: Step 1 includes passively measuring the packet flow of the selected RAN; Step 2 includes actively measuring the packet flow of the selected RAN and another selected RAN.

In step 1, the receiver can perform passive data flow measurements using data packets without any additional overhead. The receiver can set RTFM active measurement trigger conditions to determine when to transition to step 2. In one embodiment, the triggering event may include a receive timeout event, a low throughput event, and/or a periodic timer expiration event. In one embodiment, a receive timeout event occurs when no packets arrive for the data flow within a defined or selected period of time. For example, if no packets arrive within a period of 1ms to 500ms, a receive timeout event may be recorded. In another embodiment, a low throughput event occurs when the average receive throughput of the data flow is less than a defined or selected threshold. In one embodiment, the low throughput event is measured in kilobits per second (kbps) or megabits per second (mbps). The actual throughput may depend on the RAN and system requirements. For example, high-throughput cellular RANs such as 3GPP Long Term Evolution (LTE) RANs have higher thresholds, such as 500kbps. RANs such as Bluetooth have lower thresholds, such as 10kbps. In one embodiment, a periodic timer expiration event occurs when a defined or selected period of time expires. The amount of time can be system specific. In one example, the defined time period can be between a few milliseconds and several minutes.

In one embodiment, if any RTFM active measurement trigger condition occurs, step 2 will begin. In step 2, the transmitter will send packets of the flow through the serving RAN and the new RAN for active measurement. In another embodiment, the transmitter will send packets of the flow through multiple RANs. Packets sent through the serving RAN, the new RAN, and/or multiple RANs can be actively measured to determine which RAN performs better for the flow. Which RAN performs better for the flow can depend on the type of flow required by the system. Flow criteria can include packet delay, packet loss, and packet throughput. In one embodiment, the same packets can be sent and actively measured through each RAN so that performance (e.g., delay, loss, throughput) can be compared. The measurement results can be compiled at the VAN, such as a VAN server that communicates with each RAN.

In one embodiment, the transmitter may preemptively drop packets to reduce traffic load and overhead. For a data stream in active measurement, each packet in the data stream may be sent over both networks. In one embodiment, all traffic in the data stream may be sent over both RANs. However, WWAN technologies such as cellular have lower throughput than WLAN technologies such as WiFi. To accommodate the varying throughput rates of different RANs, active measurements can be performed by sending subsets of the data. For example, low-priority packets sent over a RAN with lower throughput may be preemptively dropped. To detect performance issues, only high-priority packets may be used conservatively during active measurement. The number of packets sent in an active test may vary depending on the network design or network type. The number of packets in an active test may range from tens of packets to hundreds or thousands of packets, depending on the type of test being performed—such as a timing test, packet loss test, or other type of test.

Whether a packet is dropped is based on the priority of the packet relative to other packets in the stream, such as the intra-stream priority. For example, for an Internet video call, the sender may drop video packets to give audio packets a higher priority.

In one embodiment, a new bit field S is added to the data packet header. In one embodiment, when step 2 is initiated, the new bit field S indicates that the data packet is being sent over multiple networks and can be used by the receiver for active measurement. In one embodiment, the receiver measures when to return to step 1 based on packets sent over both networks. Active measurements can be measured using selected parameters. For example, in one embodiment, active measurements of data packets sent over the new RAN can be performed using one or more of the following parameters: time (t), winning packet count (c), winning packet delay count (d), winning packet loss count (p), winning packet count threshold ( _Cth ), winning packet delay threshold ( _Dth ), winning packet loss threshold ( _Pth ), and/or maximum active measurement duration ( _Tth ). In one embodiment, the winning packet count, winning packet delay count, and winning packet loss count can all be initially set to zero.

In one embodiment, the active measurement may be calculated as follows:

If the copy of the packet sent via the new RAN arrives earlier within time (t): then c = c + 1, d = d + t. In one example, t can be measured in time units, such as milliseconds, seconds, minutes, or other time units. In one example, c is measured by the number of packets that arrived first or did not arrive first. In one example, d is measured by the number of packets that were delayed or not delayed.

If the copy of the packet sent by the serving RAN arrives earlier in time (t): then c = c-1, d = d-t.

If the assigned copy sent over the new RAN arrives, but the copy sent over the serving RAN is lost: then c = c + 1, p = p + 1. In one example, p is measured as the number of packets lost or not lost.

If the assigned copy sent over the serving RAN arrives, but the copy sent over the new RAN is lost: then c=c-1, p=p-1.

In one embodiment, if c > _Cth , d > _Dth , and p > _Pth , then RTFM execution is triggered, step 2 ends, the real-time stream is transferred to the new RAN, and step 1 is restarted. In one example, _Cth is a threshold for the number of first-arriving packets. In one example, _Dth is a threshold for the number of delayed packets. In one example, _Pth is a threshold for the number of lost packets.

In another embodiment, if c > _Cth , d > _Dth , or p > _Pth , then RTFM execution is triggered, step 2 ends, the real-time stream is transferred to the new RAN, and step 1 is restarted. In one embodiment, the winning packet count threshold, winning packet delay threshold, and winning packet loss threshold, such as ( _Cth , _Dth , _Pth ), can be set differently depending on whether the serving RAN is a Wi-Fi RAN or a cellular RAN. In one embodiment, when step 2 ends, step 1 is restarted.

In one embodiment, if c < _Cth , d < _Dth , and p < _Pth , then RTFM execution is triggered, step 2 ends, and the real-time stream is returned to the serving RAN, restarting step 1. In one example, _Cth is a threshold for the number of first-arriving packets. In one example, _Dth is a threshold for the number of delayed packets. In one example, _Pth is a threshold for the number of lost packets.

In another embodiment, if c < _Cth , or d < _Dth , or p < _Pth , then RTFM execution is triggered, step 2 ends, and the real-time stream is returned to the serving RAN, thereby restarting step 1. In one embodiment, the winning packet count threshold, winning packet delay threshold, and winning packet loss threshold, such as ( _Cth , _Dth , _Pth ), can be set differently depending on whether the serving RAN is a WLAN RAN or a WWAN (cellular) RAN. In one embodiment, when step 2 ends, step 1 is restarted.

In one embodiment, if the maximum valid measurement duration (T _th ) is reached, the real-time stream will remain in the current serving RAN, step 2 ends, and step 1 is restarted.

FIG4 illustrates the workflow of downlink RTFM. First, during RTFM passive measurement 470, VAN server 410 communicates with VAN client 420 via Wi-Fi connection 440. After a period of time, VAN client 420 receives a packet from VAN server 410 without Wi-Fi connection 440, triggering a receive (RX) timeout event 460. When RX timeout event 460 is triggered, VAN client 420 may send a control message 430 to VAN server 410 to notify VAN server 410 to initiate step 2, e.g., starting RTFM active measurement 480.

In one embodiment, during RTFM active measurement 480 , VAN server 410 preemptively drops low priority packets of a flow to reduce traffic load and sends high priority Wi-Fi packets 440 and cellular packets 450 over the cellular network connection and the Wi-Fi network connection.

In one embodiment, the VAN client 420 can receive high-priority Wi-Fi packets 440 and cellular packets 450 from the Wi-Fi network connection and the cellular network connection. During an RTFM active measurement period 480 during which the VAN client 420 is receiving the high-priority Wi-Fi packets 440 and cellular packets 450 from the Wi-Fi network connection and the cellular network connection, the VAN client 420 can maintain a packet count 490 using a packet counter.

The packet counter may increase the packet count 490 for each data packet received from the cellular network connection before receiving the data packet from the Wi-Fi network connection, e.g., current count = previous count - 1. The current packet count may be denoted as c _c and the previous packet count may be denoted as c _p . The packet counter may decrease the packet count 490 for each data packet received from the Wi-Fi network 440 before receiving the data packet from the cellular network 450, e.g., c _c = c _p - 1.

The VAN client 420 can repeatedly update the packet counter 490. When the current packet count is greater than a defined or selected packet count threshold ( _Cth ), for example, c _c > _Cth , RTFM execution is triggered. When RTFM execution is triggered, the VAN client 420 can send a control message 430 to the VAN server 410 to transfer the data packet flow from the serving RAN (Wi-Fi) to the new RAN (cellular). In another embodiment, the data packet flow can be transferred from the cellular network to the Wi-Fi network based on the RTFM measurement.

In another embodiment, the workflow as illustrated in FIG4 may be applied to uplink RTFM.

FIG5 illustrates a diagram of a VAN server 510 communicating with a mobile node 520 during passive measurements 530 and 560, and active measurements 550. In one embodiment, during passive measurements 530, the VAN server 510 may transmit selected data packets to the mobile node 520 using RAN 1 570. As previously described, the mobile node may be a UE, MS, or another wireless device with multiple RATs. In one embodiment, a triggering event 540 occurs, leading to active measurements 550. In one embodiment, during active measurements 550, the VAN server 510 transmits selected data packets to the mobile node 520 using RAN 1 570, and the VAN server 510 transmits substantially the same selected data packets to the mobile node 520 using RAN 2 580. In one embodiment, if the number of selected packets received via RAN 2 580 during the active measurements is greater than a selected threshold, the VAN server 510 may transfer the flow from RAN 1 570 to RAN 2 580. As mentioned before, RAN 1 may be WLAN technology and RAN 2 may be WWAN technology, or vice versa.

The ability of the VAN to transmit the same packets through both RAN 1 570 and RAN 2 580 during active measurements enables the performance of RAN 1 570 and RAN 2 580 to be accurately measured and compared, so that data flows can be maximized across different RATs.

FIG6 illustrates a diagram of a VAN server 610 communicating with a mobile node 620 during passive measurements 630 and 660, and active measurements 650. In one embodiment, during passive measurements 630, the VAN server 610 may transmit selected data packets to the mobile node 620 using RAN 1 670. In one embodiment, a triggering event 640 occurs, causing active measurements 650 to be performed. In one embodiment, during active measurements 650, the VAN server 610 may transmit substantially the same selected data packets to the mobile node 620 using the active RAN 1 670, and the VAN server 610 may transmit the selected data packets to the mobile node 620 using the active RAN 2 680. In one embodiment, if the number of selected packets received via RAN 2 680 during the active measurements is less than a selected threshold, the VAN server 610 may maintain the flow on RAN 1 680.

FIG7 illustrates an embodiment in which, during active measurements with respect to a RAN with lower throughput, VAN server 710 can preemptively drop packets to reduce traffic load and overhead. In FIG7 , during passive measurements 730, both low-priority and high-priority data packets are transmitted from VAN server 710 to mobile node 720 via first RAN 760. FIG7 illustrates an embodiment in which, during active measurements 740, VAN server 710 drops low-priority data packets based on their priority relative to other data packets in a flow, such as intra-flow priority, and transmits high-priority data packets from VAN server 710 to mobile node 720 via first RAN 760 and second RAN 770. In FIG7 , during passive measurements 750, both low-priority and high-priority data packets are again transmitted from VAN server 710 to mobile node 720 via first RAN 760. In another embodiment, during the passive measurement 750 , both low priority and high priority data packets are diverted and transmitted from the VAN server 710 to the mobile node 720 via the second RAN 770 .

FIG8 illustrates, using a flowchart, the functionality of one embodiment of a computer circuit for a mobile node that measures link performance using multiple RATs. The functionality may be implemented as a method or as instructions executed on a machine, wherein the instructions are contained on at least one computer-readable medium or a non-transitory machine-readable storage medium.

The computer circuitry may be configured to receive, at a mobile node, data packets of a flow via a first connection between the mobile node and a first RAN (block 810). The computer circuitry may also be configured to initiate active measurement when a real-time traffic measurement (RTFM) trigger condition occurs (block 820). The computer circuitry may also be configured to establish a second connection between the mobile node and a second RAN (block 830). The computer circuitry may also be configured to receive selected packets of the flow for active measurement using the first RAN and to receive selected packets of the flow using the second RAN (block 840). The computer circuitry may also be configured to transmit an RTFM execution event to a VAN server to transfer the flow from the first RAN to the second RAN when the active measurement result of the selected packet received via the second RAN is greater than a selected threshold (block 850).

In one embodiment, the computer circuitry can be further configured to continue transmitting the flow on the first RAN when the active measurement result is less than a selected threshold. In another embodiment, the RTFM triggering conditions include: no packets for the flow are received from the first RAN within a defined time threshold; the average receive throughput of the flow from the first RAN is less than a defined throughput threshold; the expiration of a defined period of time; or packet loss for the flow from the first RAN is greater than a defined threshold. In one embodiment, the RTFM execution event is determined by iteratively incrementing a packet counter for each packet received from the second RAN before receiving a packet from the first RAN, and iteratively decrementing the packet counter for each packet received from the first RAN before receiving a packet from the second RAN.

In one embodiment, data packets of a flow from the first RAN include a bit field indicating that the computer circuit will receive packets from both the first RAN and the second RAN for active measurement. This bit field may be added to a packet header to indicate whether the data packet is received via both a connection with the first RAN and a connection with the second RAN. In another embodiment, the computer circuit may be further configured to send a control message to a VAN server, the control message including RTFM active measurement parameters and a notification of an RTFM trigger event. In one embodiment, the computer circuit may be further configured to send a control message to the VAN server, the control message being incorporated into the virtual access network or being a new message. In another embodiment, the computer circuit may be further configured to determine when to initiate active measurement based on an RTFM trigger condition. In another embodiment, the computer circuit may be further configured to determine whether an RTFM execution event has been triggered based on: the arrival time of packets from the first RAN and the second RAN; the delay between arrival of each packet from the first RAN and the delay between arrival of each packet from the second RAN; or the number of packets received within a period of time. In another embodiment, the mobile node may also consist of a Virtual Access Network (VAN) client, a Wireless Fidelity (Wi-Fi) station, or a 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) Release 8, 9, 10, or 11 radio.

FIG9 illustrates, using a flowchart, the functionality of one embodiment of a computer circuit of a VAN server for measuring link performance using multiple RATs. The functionality may be implemented as a method or as instructions executed on a machine, wherein the instructions are contained on at least one computer-readable medium or a non-transitory machine-readable storage medium.

The computer circuitry may be configured to transmit data packets to the mobile node using the first RAN (block 910). The computer circuitry may be further configured to receive a first control message from the mobile node to transmit selected data packets using the first RAN and to transmit selected packets using the second RAN when a real-time traffic measurement (RTFM) trigger condition occurs (block 920). The computer circuitry may be further configured to transmit selected packets to the mobile node using the first RAN and to transmit selected packets to the mobile node using the second RAN (block 930). The computer circuitry may be further configured to receive a second control message to transmit data packets using the second RAN when the active measurement result is greater than a selected threshold (block 940).

In one embodiment, the computer circuitry may be further configured to continue transmitting data packets using the first RAN when the active measurement result is less than a selected threshold. In another embodiment, the computer circuitry may be further configured to select data packets for transmission using the first RAN and select data packets for transmission using the second RAN based on the intra-flow priority. In another embodiment, the computer circuitry may be further configured to determine the intra-flow priority based on the priority of the first data packet transmitted using the first RAN relative to the priority of the second data packet transmitted using the first RAN. In another embodiment, the computer circuitry may be further configured to determine the intra-flow priority based on the priority of the first data packet transmitted using the second RAN relative to the priority of the second data packet transmitted using the second RAN.

In one embodiment, the first control message may include RTFM active measurement parameters and an RTFM trigger event notification. The RTFM active measurement parameters may include: non-receipt of packets transmitted using the first RAN within a defined time threshold; an average receive throughput of packets transmitted using the first RAN being less than a defined throughput threshold; expiration of a defined period of time; or packet loss of packets transmitted using the first RAN being greater than a defined threshold. In another embodiment, the second control message may include RTFM active measurement parameters and an RTFM trigger event notification. In another embodiment, the RTFM active measurement parameters may include: non-receipt of packets transmitted using the first RAN within a defined time threshold; an average receive throughput of packets transmitted using the first RAN being less than a defined throughput threshold; expiration of a defined period of time; or packet loss of packets transmitted using the first RAN being greater than a defined threshold.

In one embodiment, the computer circuitry may be further configured for use with downlink or uplink communications. In another embodiment, the data packets may include a new bit field in the data packet header. In another embodiment, the new bit field indicates when each data packet has been sent using the first RAN and the second RAN.

FIG10 illustrates, using a flow chart, a method for measuring link performance using multiple radio access networks (RANs). The method may include transmitting data packets to a mobile node using a first RAN (block 1010). The method may also include, when a real-time traffic measurement (RTFM) trigger condition occurs, receiving a first control message to transmit selected data packets using the first RAN and transmitting selected packets using a second RAN (block 1020). The method may also include transmitting selected packets of a flow to the mobile node using the first RAN and transmitting selected packets of the flow to the mobile node using the second RAN (block 1030). The method may also include receiving a second control message to transfer a flow from the first RAN to the second RAN when an active measurement result exceeds a selected threshold (block 1040).

In one embodiment, the method may further include: continuing to transmit data packets using the first RAN when the active measurement result is less than a selected threshold. In another embodiment, the method may further include: transmitting selected data packets from the VAN server or eNB to the mobile node using the first RAN and the second RAN. In another embodiment, the method may further include: transmitting selected high-priority packets of the flow to the mobile node using the first RAN, and transmitting selected high-priority packets of the flow to the mobile node using the second RAN. In another embodiment, the method may further include: terminating selected low-priority packets of the flow transmitted to the mobile node using the first RAN, and terminating selected low-priority packets of the flow transmitted to the mobile node using the second RAN. The priority of the data packets of the flow from the first RAN and the priority of the data packets of the flow from the second RAN may be selected based on intra-flow priority. The selected low-priority packets of the flow from the first RAN and the selected low-priority packets of the flow from the second RAN may be terminated to reduce traffic load.

Figure 11A illustrates one embodiment in which a new bit field, the S-bit field 1120, is added to a VAN data packet header 1110. The S-bit field 1120 indicates whether the data packet will be sent via two networks. The S-bit field 1120 can be added to a new or existing VAN data packet header 1130. Figure 11B illustrates one embodiment in which RTFM active measurement parameters 1150 and RTFM trigger event notification 1160 are added to a VAN control message 1140. The RTFM active measurement parameters 1150 and RTFM trigger event notification 1160 can be added to a new or existing VAN control message 1170. In one example, the VAN control message 1140 can be incorporated into a Mobile IP Binding Update or Binding Acknowledgement. In another example, the VAN control message can be a separate or new message. In one embodiment, the RTFM active measurement parameters 1150 may include: RTFM active measurement trigger parameters, such as a reception timeout event, a low throughput event, and/or a periodic timer expiration event; and RTFM active measurement parameters, such as _Cth and _Tth . In another embodiment, the RTFM trigger event notification 1160 may include a notification that an RTFM active measurement is triggered or that the execution of an RTFM active measurement is triggered.

Figure 12 provides an 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 types of wireless devices. The wireless device may include one or more antennas configured to communicate with a node or transmitting station, such as a base station (BS), an evolved Node B (eNB), 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 types of wireless wide area network (WWAN) access points. 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 Wi-Fi. The wireless device may communicate using separate antennas for each wireless communication standard or by using a shared antenna for multiple wireless communication standards. Wireless devices can communicate in a wireless local area network (WLAN), a wireless personal area network (WPAN), and/or a WWAN.

Figure 12 also provides an illustration of 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 utilize capacitive, resistive, or another 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 storage capacity of the wireless device. A keyboard can be integrated with the wireless device or can be wirelessly connected to the wireless device to provide additional user input. A virtual keyboard can also be provided using the touch screen.

The various techniques, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) contained in a tangible medium, such as a floppy disk, CD-ROM, hard drive, non-transitory computer-readable storage medium, or any other machine-readable storage medium, wherein when the program code is loaded and executed by a machine such as a computer, the machine becomes a device for practicing the various techniques. 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 RAM, EPROM, flash drive, optical drive, hard drive, or other medium for storing electronic data. The base station and mobile station may also include a transceiver module, a counter module, a processing module, and/or a clock module or timer module. One or more programs that can implement or utilize the various techniques described herein may utilize an application programming interface (API), reusable controls, and the like. Such programs may be implemented using high-level procedural or object-oriented programming languages to communicate with the computer system. However, if desired, the programs may also be implemented in assembly or machine language. In short, a language can be compiled or interpreted and can be combined with hardware implementation.

It should be understood that many of the functional units described in this specification are labeled as modules to more clearly emphasize their implementation independence. For example, a module can be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Modules can also be implemented using programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, and the like.

Modules can also be implemented in software so that they can be executed by various processors. An identified module of executable code may, for example, contain one or more physical or logical blocks of computer instructions that can be organized into objects, procedures, or functions. The executable code of an identified module need not be physically located together, but may contain fundamentally different instructions stored in different locations that, when logically combined together, constitute the module and implement the module's intended purpose.

In practice, a module of executable code can be a single instruction or multiple instructions, and can even be distributed across several different code segments between different programs and across several storage devices. Similarly, operational data can be identified and illustrated within a module, embodied in any suitable form, and organized within any suitable type of data structure. The operational data can be centralized into a single data set, or can be distributed across different locations, including across different storage devices, and can exist at least partially as electronic signals on a system or network. Modules can be passive or active, including agents that can perform desired functions.

References in this specification to "an example" mean 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 phrase "in one example" appearing in various places in this specification is not necessarily referring to the same embodiment.

As used herein, for convenience, multiple projects, structural elements, constituent elements and/or materials may be present in a public list. However, these lists should not be understood as each item in the list being individually identified as independent and unique items. Thus, in the absence of contrary indications, each item in such a list should not be understood as the de facto equivalent of any other item in the same list merely according to its representation in the public group. In addition, each embodiment of the present invention and example may be mentioned here together with the alternatives of each assembly thereof. It should be understood that such embodiments, examples and alternatives should not be understood as de facto equivalents to each other, but should be understood as independent and autonomous representations of the present invention.

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

Although the above 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 in form, use, and details of implementation can be made without departing from the principles and concepts of the present invention without inventive effort. Therefore, the present invention is not limited except as set forth in the claims set forth below.

Claims (25)

1. A mobile node for measuring link performance using multiple radio access networks (RANs), the mobile node having computer circuitry configured to: At the mobile node, data packets of the stream are received via the first connection between the mobile node and the first RAN; Active measurement is initiated when the Real-Time Flow Measurement (RTFM) trigger condition is met; A second connection is formed between the mobile node and the second RAN; Using the first RAN, selected packets for the active measurement received stream are selected, and using the second RAN, selected packets for the received stream are selected; and When the active measurement result of a selected packet received via the second RAN exceeds a selected threshold, an RTFM execution event is transmitted to the Virtual Access Network (VAN) to transfer the flow from the first RAN to the second RAN. The RTFM execution event is determined by iteratively incrementing a packet counter for each packet received from the second RAN before receiving a packet from the first RAN. 2. The mobile node of claim 1, wherein the computer circuitry is further configured to continue transmitting the stream on the first RAN when the active measurement result is less than a selected threshold. 3. The mobile node according to claim 1, wherein the RTFM triggering condition includes: No packets of the stream were received from the first RAN within the defined time threshold; The average received throughput of the first RAN is less than the defined throughput threshold; The expiration of a defined period of time; or Packet loss from the first RAN exceeds a defined threshold. 4. The mobile node of claim 1, wherein an RTFM execution event is determined by iteratively decrementing a packet counter for each packet received from the first RAN before receiving a packet from the second RAN. 5. The mobile node of claim 1, wherein the data packets of the stream from the first RAN include a bit field instructing computer circuitry to receive packets from the first RAN and the second RAN for active measurement. 6. The mobile node of claim 5, wherein the bit field is added to the packet header to indicate whether the data packet was received via both a connection to the first RAN and a connection to the second RAN. 7. The mobile node of claim 1, wherein the computer circuitry is further configured to send control messages to a VAN server, the control messages comprising: RTFM active measurement parameters; and RTFM triggers event notification. 8. The mobile node of claim 1, wherein the computer circuitry is further configured to send control messages to a VAN server, the control messages being incorporated into the virtual access network or being new messages. 9. The mobile node of claim 1, wherein the computer circuitry is further configured to determine when to initiate active measurement based on RTFM triggering conditions. 10. The mobile node of claim 1, wherein the computer circuitry is further configured to determine whether an RTFM execution event has been triggered based on the following: Arrival time of packets from the first RAN and the second RAN; The delay between arrivals of each packet from the first RAN, and the delay between arrivals of each packet from the second RAN; or The number of packets received within a certain period of time. 11. The mobile node of claim 1, wherein the mobile node further comprises a virtual access server, a Wi-Fi station, or a 3GPP Long Term Evolution (LTE) version 8, 9, 10, or 11 radio device. 12. A Virtual Access Network (VAN) server for measuring link performance using multiple Radio Access Networks (RANs), the VAN server having computer circuitry configured to: Using the first RAN, data packets are transmitted to the mobile node; When the Real-Time Traffic Measurement (RTFM) trigger condition occurs, a first control message is received from the mobile node to transmit selected data packets using the first RAN and the second RAN. Using the first RAN, selected packets are transmitted to the mobile node; and using the second RAN, selected packets are transmitted to the mobile node. When the active measurement result exceeds the selected threshold, a second control message is received to transmit data packets using the second RAN. The second control message is determined by iteratively incrementing a packet counter for each packet received from the second RAN before the selected packet is received from the first RAN. 13. The virtual access network server of claim 12, wherein the computer circuitry is further configured to continue transmitting data packets using the first RAN when the active measurement result is less than a selected threshold. 14. The virtual access network server of claim 12, wherein the computer circuitry is further configured to select data packets to be transmitted using a first RAN and to select data packets to be transmitted using a second RAN based on intra-flow priority. 15. The virtual access network server of claim 12, wherein the computer circuitry is further configured to determine an intra-flow priority based on the priority of a first data packet transmitted using the first RAN relative to the priority of a second data packet transmitted using the first RAN. 16. The virtual access network server of claim 12, wherein the computer circuitry is further configured to determine an intra-flow priority based on the priority of a first data packet transmitted via the second RAN relative to the priority of a second data packet transmitted via the second RAN. 17. The virtual access network server according to claim 12, wherein the first control message includes: RTFM active measurement parameters, which include: No packets were received using the first RAN within the defined time threshold; The average received throughput of packets transmitted using the first RAN is less than the defined throughput threshold; The expiration of a defined period of time; or The packet loss of packets transmitted using the first RAN exceeds a defined threshold; and RTFM triggers event notification. The second control message includes: RTFM active measurement parameters, which include: No packets were received using the first RAN within the defined time threshold; The average received throughput of packets transmitted using the first RAN is less than the defined throughput threshold; The expiration of a defined period of time; or The packet loss of packets transmitted using the first RAN exceeds a defined threshold; and RTFM triggers event notification. 18. The virtual access network server of claim 12, wherein the computer circuitry is further configured for use in downlink or uplink communication. 19. The virtual access network server of claim 12, wherein the data packets include a new bit field in the data packet header. 20. The virtual access network server of claim 19, wherein the new bit field indicates when each data packet has been transmitted using the first RAN and the second RAN. 21. A method for measuring link performance using multiple radio access networks (RANs), the method comprising: Using the first RAN, data packets are transmitted to the mobile node; When a Real-Time Flow Measurement (RTFM) trigger condition is met, a first control message is received to transmit selected data packets using a first RAN and to transmit selected packets using a second RAN. Using the first RAN, selected packets of the flow are transmitted to the mobile node, and using the second RAN, selected packets of the flow are transmitted to the mobile node; and When the active measurement result exceeds the selected threshold, a second control message is received to transfer the flow from the first RAN to the second RAN. The second control message is determined by iteratively incrementing a packet counter for each packet received from the second RAN before the selected packet is received from the first RAN. 22. The method of claim 21 further comprises: when the active measurement result is less than a selected threshold, continuing to transmit data packets using the first RAN. 23. The method of claim 21, further comprising: using a first RAN and a second RAN to transmit selected data packets from a virtual access server or an enhanced node B (eNB) to a mobile node. 24. The method of claim 21, further comprising: using a first RAN to transmit selected high-priority packets of the flow to the mobile node, and using a second RAN to transmit selected high-priority packets of the flow to the mobile node. 25. The method of claim 21, further comprising: terminating selected low-priority packets of a flow transmitted to the mobile node via the first RAN, and selected low-priority packets of a flow transmitted to the mobile node via the second RAN. Based on intra-flow priority, the data packet priority from the first RAN and the data packet priority from the second RAN are selected, and... Selected low-priority packets using flows from the first RAN and selected low-priority packets using flows from the second RAN are terminated to reduce traffic load.