Patent Application
20120188949
This disclosure relates to wireless communication devices, a wireless communication system comprising such devices, and a method of routing data in such a wireless communication system, in which the wireless communication devices are adapted to communicate over a plurality of heterogeneous radio interfaces.
The 3rd Generation Partnership project 3GPP has specified methods that allow a wireless communication device to determine preferable radio accesses for a specific Internet Protocol (IP) flow and attempt to route an IP flow on the most preferable radio access (for example see 3GPP technical specifications TS 23.261, TS 23.402 and TS 24.312 which are incorporated by reference herein). This determination is based on inter-system routing policies (ISRP), each of which contains one or more Filter Rules that specify which radio accesses (in priority order) should be used for traffic that matches specific criteria. IP traffic that matches the criteria in a Filter Rule of an ISRP is transmitted on the most preferable radio access of the ISRP, if it is available and connected. If it is not available or connected, it may trigger a discovery and attachment procedure in the wireless communication device.
According to TS 23.402, v10.2.0, clause 4.8.2.1, each inter-system routing policy includes the following information:
Validity conditions, i.e. conditions indicating when the provided policy is valid;
One or more Filter Rules, each one identifying a prioritized list of access technologies/access networks which shall be used by the mobile device when available to route traffic that matches specific IP filters and/or specific Access Point Names (APNs).
A filter rule also identifies which radio accesses are restricted for traffic that matches specific IP filters and/or specific APNs (e.g. WLAN is not allowed for traffic to APN-x). A Filter Rule may also identify which traffic shall or shall not be non-seamlessly offloaded to a WLAN when available, if the wireless communication device supports the non-seamless WLAN offload capability specified in clause 4.1.5 of TS 23.402 v10.2.1.
The notion of an IP flow is well known in the prior art, for example see U.S. Pat. No. 7,190,668. An IP flow is a sequence of packets or information bits that share some common properties, for example being all destined to the same IP address and port number and carrying data cast in the same IP protocol such as HTTP, UDP, TCP or similar.
As shown in
Possible wireless communication device architectures that support ISRP and simultaneous transmission of IP flows over multiple radio access interfaces are shown in
In the architecture of
One difference between the two architectures of
Although not expressly shown, in both of
Transmitting different IP flows over different radio access interfaces (as discussed above) can feature several benefits. For example, based on the provisioned ISPR policies, a wireless communication device may prefer to route voice over IP (VoIP) flows on a 3GPP cellular radio access interface to benefit from guaranteed quality of service, and offload all other traffic to wireless local area networks such as WLAN, when available. In streaming scenarios, the wireless communication device may prefer to route real time streaming protocol (RTSP) signalling on a 3GPP cellular radio access interface in order to facilitate subscriber identification and charging, and route RTP/RTCP traffic on a wireless local area network in order to offload bandwidth intensive media streams from the cellular network.
A wireless communication device, a wireless communication system comprising such a device, and a method of routing data in such a wireless communication system, in accordance with the disclosure will now be described, by way of example only, with reference to the accompanying drawings in which:
a and 2b show the routing of separate IP flows over heterogeneous radio access interfaces according to the prior art;
a and 4b illustrate how the arrangement of
a and 6b illustrate protocol architectures for implementing a wireless communications device according to an example embodiment of the present disclosure; and
A wireless communication device for use with the wireless communication system in accordance with the disclosure may be a portable or handheld or mobile telephone, a Personal Digital Assistant (PDA), a portable computer, portable television and/or similar mobile device or other similar communication device. In the following description, the communication device will be referred to generally as a UE (user equipment) for illustrative purposes and it is not intended to limit the disclosure to any particular type of wireless communication device.
A UE in accordance with the disclosure provides communication of a single IP flow over multiple radio access interfaces simultaneously.
Validity conditions, i.e. conditions indicating when the policy is valid;
One or more filter rules, each one identifying (i) a prioritized list of radio access interfaces (in the form of access technologies and/or access networks) which shall be used by the mobile device when available to simultaneously transmit a single IP flow, (ii) the matching criteria that specifies the IP flow (see
The priorities assigned to radio access interfaces in a filter rule indicate which radio access interface shall be used first for transmitting the IP flow. As explained below, the transmission of a single IP flow in the arrangement of
As an example, an ISSP policy 41 may indicate:
Validity conditions: PLMN=(MNC, MCC)
Filter Rule 1:
Scheduling Policy=Multipath TCP
Based on the above ISSP, when the UE 40 is registered in the specific PLMN (public land mobile network) identified by the validity conditions (i.e. when the ISSP is valid), then all IP packets with Destination Address 192.108.114.1, Protocol 6 (TCP) and Destination Port 80 (HTTP) must be simultaneously transmitted over a 3GPP access and a WLAN access (if both are available and connected) by employing a Multipath TCP scheduling policy. This policy indicates that the transmission scheduling on the 3GPP and WLAN accesses must be performed as specified by the Multipath TCP protocol (see draft-ietf-mptcp-architecture-04 and draft-ietf-mptcp-congestion-01), i.e. based on the TCP congestion control. By means of this policy, the UE 40 will perform a dynamic load balancing across 3GPP and WLAN access interfaces based on the determined congestion level in each access. When, for example, the 3GPP access interface starts being congested (as determined by the TCP congestion control algorithm), the UE 40 will schedule less IP flow traffic on the 3GPP access interface and more IP flow traffic on the WLAN access interface. As congestion increases more and more, the UE will schedule less and less IP flow traffic on the 3GPP access interface. In the extreme case that 3GPP access becomes unavailable (either due to congestion or due to lack of radio signal) the UE will schedule all IP flow traffic on the WLAN access interface. So, employing two access interfaces to transmit the same IP flow simultaneously can considerably improve communication in a mobile environment.
In the case that one radio access interface becomes unavailable, an ongoing session is not disrupted or otherwise discontinued but is maintained over another radio access interface. Note that the scheduling policy specifies how a specific IP flow is split into two sub-flows, each one transmitted on a different radio access interface.
As another example, an ISSP policy 41 may indicate:
Validity conditions: Roaming
Filter Rule 1:
Scheduling Policy=Loading balancing 50%
Based on the above ISSP, when the UE 40 is roaming (i.e. using any PLMN except its home PLMN), all UDP/RTP packets that carry voice as identified by the RTP payload type (see RFC 3551) must be simultaneously transmitted over a WLAN access and a 3GPP access by employing a 50%-50% load balancing. In this case, the UE will start first transmitting the IP flow on the WLAN access interface (if available), will then setup a second transmission path over 3GPP access and finally will schedule half of the IP flow traffic on WLAN access and half of the IP flow traffic on 3GPP access. No congestion control is performed in this case since the TCP protocol is not used.
Many other scheduling policies may be envisioned, for example, a policy indicating that all IP flow traffic must be scheduled on one radio access (the highest priority one) and the other radio access is used to duplicate some percentage of the IP flow traffic. In this case, the UE employs transmission access diversity where part or all the IP flow packets are transmitted over multiple radio accesses simultaneously in order to increase transmission reliability, i.e. reduce the packet error rate at the receiving side.
The ISSP policies discussed above may either be statically provisioned in the UE (e.g. during manufacturing or post manufacturing by means of a device configuration process) or be sent to the UE by a network element such as the Access Network Discovery and Selection Function (ANDSF) specified in 3GPP specification TS 23.402 v10.2.1. When sent to UE by a network element, these policies can be updated, deleted, or otherwise modified as necessary, for example with a device management protocol such as OMA DM.
To enable routing of the IP flow 35 across multiple radio access interfaces, the UE 40 does not establish a connection directly to the other network node, which may be the application server 44 illustrated in
If it is determined that the IP flow 35 should not be routed across multiple radio access interfaces, for example because the ISSP 41 prohibits that particular flow from flow splitting, then the FCSF 42 is not used and the IP flow is routed to the application server 44 without traversing the FCSF 42, as per the prior art. In this case, the most preferable radio access that should be used to carry this IP flow is determined by the ISRP that is currently specified in 3GPP TS 23.402 v10.2.1.
Although
a and 4b show two typical UE architectures that can be used to enable transmission of the single IP flow 35 across multiple radio access interfaces. As with
After that, the flow split/combine function 50 splits the IP flow 35 into the two upstream sub-flows 36, 37, each one transmitted over the available first and second connections to FCSF 42. In the opposite direction, the flow split/combine function 50 is adapted to combine pairs of downstream sub-flows (not shown in
The architecture shown in
A PCRF network entity 58 (policy and charging rules function), a defined 3GPP specified network entity (see 3GPP TS 23.203), provides the FCSF 42 with policy and control information. As in the prior art, this information may include such aspects as the quality of service that should be provided to specific IP flows and how IP flows should be charged. Additionally, as an additional functionality to support the IP flow splitting/combining of the present disclosure, the PCRF 58 may provide to FCSF 42 policies that indicate how downstream IP flows can be split into individual sub-flows for transmission to UE on different radio access interfaces. Moreover, the PCRF authorizes UEs requests to transmit certain IP flows on multiple radio accesses in the upstream direction.
A new interface Sf 60 between the UE 40 and FCSF 42 is used to transport signalling between UE and FCSF required to establish multiple sub-flow paths 36, 37. If Multipath TCP (MPTCP) is used, the interface Sf 60 may not be required because MPTCP provides the means for managing multiple paths. However, when MPTCP is not used or when multiple paths for flow types not supported by MPTCP such as UDP flows are required, the interface Sf 60 facilitates the necessary signalling between UE and FCSF. Interface Sf could be an HTTP/XML based interface, in which case an appropriate XML schema may be specified.
a and 6b illustrate suitable protocol architectures in the UE 40 and FCSF 42 when MPTCP is used in addition to a connection establishment between the UE and FCSF over a cellular radio access interface. This connection establishment is more thoroughly discussed below in relation to
b shows how the establishment of a connection through wireless LAN (WLAN) radio access interface 48 triggers the MPTCP/TCP layer 72 in the UE, to add a second communication path between the UE and FCSF for supporting the same IP flow that is already transmitted over the 3GPP radio access (as discussed in
A detailed signalling flow corresponding to the protocol architecture diagrams of
In step 4, the FCSF 42 authenticates the UE 40 by means of SOCKS5 protocol signalling. A variety of methods could be used to authenticate the UE 40, but
Later, in step 8, the WLAN radio access interface becomes available and connected. This triggers the MPTCP protocol in the UE 40 to request and establish a new TCP connection to the FCSF 42 over WLAN access that is associated with the existing TCP connection to FCSF over 3GPP access established before in step 3. At this point, the FCSF may contact the PCRF 58 to check if the UE 40 is authorized to initiate a multipath connection for its communication with the AS 44 and, if so, to download the applicable policies that instruct the FCSF 42 how to perform downstream scheduling across the two TCP connections on 3GPP access and WLAN access interfaces. Finally, in step 10, the IP flow sent by the application layer 16 is scheduled (by MPTCP in the UE) over the established TCP connections on 3GPP access and WLAN access interfaces and similarly the IP flow sent by AS is scheduled (by MPTCP in the FCSF) over the established TCP connections on 3GPP access and WLAN access interfaces. Both the UE 40 and FCSF 42 combine the sub-flows received over the different radio access interfaces and deliver a single IP flow to the application layer 16 and AS 44 respectively.
Note that the application layer or AS may generate more that one IP flow, for example, if the AS is a media streaming server, one IP flow for RTSP signalling and a second IP flow for media streaming. In such case, the MPTCP layer in the UE and FCSF decide which IP flows can be split into separate sub-flows according to their respective ISSP and schedule these IP flows on one or more radio access interfaces accordingly. For example, the RTSP signalling flow could be scheduled on the 3GPP radio access interface only and the media streaming flow could be scheduled on both interfaces by an MPTCP scheduling policy in order to benefit from higher throughput and better reliability and availability.
Note also that in
A similar detailed signalling flow for the case in which a UDP flow is required is shown in
As before, the SOCKS5 layer in the UE 40 determines a new bind request for a destination address and/or port with which multipath communication over multiple access interfaces is allowed (according to the provisioned ISSP). In response, the UE 40 discovers an FCSF 42 function in the network (if not already known), establishes a TCP connection to the SOCKS5 layer in FCSF (step 3) and then the UE is authenticated (step 4) and optionally authorized (e.g. by PCRF or another element) to use the multipath communication services provided by FCSF 42. In step 5, the SOCKS5 layer in the UE sends a SOCKS5 Bind request to FCSF which triggers the FCSF to establish a new UDP socket with the AS's IP address and UDP port. In step 7, the UDP flow is being exchanged between the UE 40 and AS 44 through the SOCKS5 proxy function in FCSF 42. When WLAN access is later connected (step 8), a UDP communication path over WLAN is negotiated between the UE and FCSF. This negotiation takes place over WLAN or 3GPP cellular radio access interfaces and uses the Sf protocol, which could be a simple XML-based protocol implemented over HTTP or another transport scheme. During this negotiation, the FCSF 42 may request PCRF 58 to authorize the establishment of this path and to provide FCSF with the applicable ISSP policies for the downstream direction. If authorization from the PCRF is successful, a second UDP communication path between UE and FCSF is established over the WLAN access network (step 9). In the final step 10, parts of the IP/UDP traffic flow are now transmitted between UE and FCSF as a first sub-flow over the first communication path on the 3GPP access interface and parts of the IP/UDP traffic flow are transmitted between UE and FCSF as a second sub-flow over the second communication path on the WLAN access interface. The traffic on these two sub-flows is determined by the scheduling policy specified in the ISSP. For example, if a 50%-50% load balancing policy is specified in the upstream direction, then the UE 40 will schedule half of the total IP flow traffic on the 3GPP access interface (first sub-flow) and half of the total IP flow traffic on the WLAN access interface (second sub-flow).
In more general terms, a method for implementing the described IP flow splitting technique, using the terminology above, may be defined as follows:
Splitting the same IP flow across different radio access interfaces as discussed above can bring considerable benefits, including increased data throughput, increased network availability, increased network reliability, enhanced mobility support, and fine-grained offload. Each of these aspects will be briefly discussed in turn below.
Using two radio accesses to transmit an IP flow can significantly increase the overall throughput provided to the application layer. This is true especially when the individual throughputs of radio accesses are comparable.
When one radio access becomes temporarily unavailable (e.g. due to slow-fading propagation), the other radio access could be used to carry all the flow traffic. The fading characteristics of heterogeneous radio accesses are highly uncorrelated, for example due to different transmission schemes, frequencies and traffic loads, and, thus, the probability that both radio accesses simultaneously experience deep-fade conditions is very small.
Real-time IP flows, which are usually transmitted in unacknowledged mode, can be received with large packet error rate when transmitted over low quality communication paths. Using access network diversity to transmit such flows (e.g. transmit some or all packets on both 3GPP and WLAN accesses) can significantly reduce the received packet error rate, thus improving communication reliability.
Transmitting a single IP flow over heterogeneous access networks can provide an effect similar to vertical soft-handovers. For example, if the UE discovers and connects to a WLAN access while it receives a video stream over E-UTRAN, the UE could setup a second communication path over WLAN to support the ongoing video stream. The streaming traffic could then be load-balanced across WLAN and E-UTRAN, and as the user moves out of LTE coverage, the path over WLAN could take over all streaming traffic.
According to current 3GPP specifications, the UE can be configured (with inter-system mobility policies) to steer selected IP flows to 3GPP access and offload other flows to WLAN access. If the UE can also be configured to steer selected IP sub-flows to 3GPP access and offload other sub-flows to WLAN access, then a fine-grained offload mechanism can be realized. With such mechanism, the operator would be able to load-balance selected traffic across e.g. 3GPP access and WLAN access.
In the foregoing specification, the invention has been described with reference to specific examples of embodiments of the invention. It will, however, be evident that various modifications and changes may be made therein without departing from the broader scope of the invention as set forth in the appended claims.
Some of the above embodiments, as applicable, may be implemented using a variety of different processing systems. For example, the Figures and the discussion thereof describe an exemplary architecture and method which is presented merely to provide a useful reference in discussing various aspects of the disclosure. Of course, the description of the architecture and method has been simplified for purposes of discussion, and it is just one of many different types of appropriate architectures and methods that may be used in accordance with the disclosure. Those skilled in the art will recognize that the boundaries between program elements are merely illustrative and that alternative embodiments may merge elements or impose an alternate decomposition of functionality upon various elements.
