News Column

"Multihomed Communication Device" in Patent Application Approval Process

June 30, 2014



By a News Reporter-Staff News Editor at Clinical Trials Week -- A patent application by the inventors Stojanovski, Saso (Paris, FR); Vedrine, Arnaud (Paris, FR), filed on December 27, 2010, was made available online on June 19, 2014, according to news reporting originating from Washington, D.C., by NewsRx correspondents (see also Patents).

This patent application has not been assigned to a company or institution.

The following quote was obtained by the news editors from the background information supplied by the inventors: "In 3GPP cellular systems, a cellular terminal (referred to as UE) can access several IP networks in parallel by establishing a so-called Packet Data Network (PDN) connection (also referred to as Primary PDP Context in pre-Rel-8 3GPP specifications) to each of the PDNs it wishes to access. A typical use case is the following. The UE may need to access the Internet in parallel to the operator's IP Multimedia Subsystem (IMS) and in parallel to the user's corporate intranet. On every PDN connection the UE is assigned a distinct IP address. In IETF parlance, the UE is an IP host with multiple IP interfaces, also referred to as 'multi-homed host'.

"A general issue with multi-homed terminals is that when sending an IP packet the terminal needs to select the correct interface, the reason being that parallel PDNs may be disjoint networks using private IP address space and specific destinations can be reached on a specific PDN only. Selecting the correct IP interface is a routing decision and needs to be performed not only for data traffic, but also for control packets, such as DNS requests.

"In some cases it is possible to reach the same set of destination IP addresses (e.g. the public Internet addresses) via more than one PDN. In such scenarios it is desirable to select the most appropriate PDN e.g. the one incurring the lowest transport cost.

"The IETF has recently started working on a similar problem, namely the problem of hosts having multiple network interfaces (physical interfaces, virtual interfaces, or combinations thereof). The IETF has created a working group called MIF (for Multiple InterFaces) whose charter is available on the Internet (see IETF MIF working group's charter: http://www.ietf.org/dyn/wg/charter/mif-charter.html). However this working group has not yet come up with much output beyond the problem description and a list of current practices in terminal implementations. The current practices rely on a number of suboptimal mechanisms such as: static configuration (e.g. defining one interface as a primary interface for all traffic, which is typically the case for computers equipped with Windows operating systems up to Vista), or load sharing between the multiple interfaces (for traffic that can be sent on either interface), or trial-and-error mechanisms, etc. All these approaches are suboptimal as they do not take into account the specifics of the underlying IP networks (e.g. transport cost).

"On the 3GPP side, the problem of multi-homed UEs has been touched upon as part of the Release-10 work item on 'non-seamless WLAN offload' (see in particular 3GPP SP-090616 'WID on IP Flow Mobility and seamless WLAN offload' and 3GPP TS 23.861 'Feasibility study on MAPIM'). The offload is qualified as non-seamless because traffic is offloaded on a care-of address, which means that the session is broken if the radio access is changed (the address needs to change). The objective is to allow dual-mode dual radio terminals (i.e. UEs having a cellular and a WLAN interface) to use the WLAN access to connect to the Internet directly, without traversing the 3GPP operator's core network. As of Sep 2010, it was agreed that this can be achieved by provisioning operator's policies via extensions to the ANDSF (Access Network Discovery and Selection Function) framework (S2-104336) that was specified in 3GPP TS 23.402 ('Architecture enhancements for non-3GPP accesses; Stage 2'). But with non-seamless offload, when IP flows are sent to the WLAN, they are not associated with any specific APN. In other words, non-seamless offload operates on an IP flow basis, but does not choose an APN corresponding to the IP flow; instead it chooses a radio interface (e.g. WLAN). There is no PDN connection (which would be linked to a PGW and associated with an APN).

"Depicted in FIG. 1 is an example scenario of non-seamless WLAN offload. A Rel-10 UE capable of non-seamless WLAN offload can do the following:

"use the cellular access (macro or femto) for access to either operator's services or the Internet

"use the WLAN interface for non-seamless WLAN offload and access to either local resources or the Internet

"In this example the UE has one PDN connection via cellular access (PDN1) to the Operator's PDN. It is depicted as a grayed tunnel between the UE and the Packet Data Gateway (PGW), a node representing the ingress point to PDN1, which also assigns the IP address used by the UE on this PDN.

"In order to be able to use the non-seamless WLAN offload feature, the UE needs to be dual mode (3GPP+WLAN) and dual radio. In the example in FIG. 1 the UE uses the WLAN access to directly access the Home network. Note that the Home network assigns another IP address to the UE ? it is used in all IP packets that UE sends or receives via the Home network.

"Some destinations are reachable only via PDN1 or via the direct WLAN access. For instance, the P-CSCF node (which is the ingress point to the operator's IP multimedia subsystem) is reachable only via PDN1, whereas the Home server is reachable only via the direct WLAN access. On the other hand, hosts residing in the Internet can be reached via either access.

"Performing non-seamless WLAN offload in this example means routing Internet-bound traffic via the direct WLAN access whenever the UE is in WLAN coverage, because the cost of using WLAN is much lower compared to the cost of using the cellular access.

"As the UE moves out of WLAN coverage, the Internet-bound traffic can be re-routed via PDN1.

"Non-seamless WLAN offload was defined in 3GPP Rel-10. Routing policies described in the previous paragraphs are provided to the UE via extensions to the ANDSF (Access Network Discovery and Selection Function) architecture specified in 3GPP TS 23.402.

"Since the Internet can be reached through both, ANDSF policies should steer Internet traffic towards WLAN, whenever available, and when non-seamless WLAN offload is used to access the Internet, the overall effect is similar to SIPTO from a femto cell ('femto-SIPTO'). SIPTO is explained below.

"Depicted in FIG. 2 and FIG. 3 are the non-roaming and roaming ANDSF architectures (respectively), as defined in 3GPP TS 23.402.

"The ANDSF can be accessed via either 3GPP or non-3GPP access, however, the provided information is used only in relation with a non-3GPP access.

"The ANDSF architecture (optional) may be used to:

"provide access network discovery information to the terminal e.g. a list of available WLAN or WiMAX hotspots corresponding to the current UE location,

"provide Inter-System Mobility Policies (ISMPs) that steer the terminal to the preferred network access.

"In Rel-10 the ANDSF was enhanced to provide Inter-System Routing Policies (ISRPs); among other things they are used to steer IP flows towards WLAN access for Non-seamless WLAN offload.

"FIG. 4 shows a hypothetical terminal perspective in the context of a non-seamless WLAN offload. The Care-of Address is used for non-seamless WLAN offload in both cases. Inter-System Routing Policies (ISRPs) are used at the 'top routing layer' to decide on a per-packet basis whether an outgoing user packet will be routed towards the EPC or will be offloaded non-seamlessly via the WLAN. The ISRPs are configured either statically or dynamically via the ANDSF (Rel-10 enhancement). When steering the packets, the OS needs to use the correct IP address (i.e. CoA versus the Home Address HoA) in the Source Address field of the IP header.

"Non-seamless WLAN offload allows for certain IP traffic to leak out of the EPC via the local Care-of Address (CoA-L). It is non-seamless because the leaked traffic is not anchored in the PDN GW.

"In the same Rel-10 timeframe 3GPP was developing solutions for Selective IP Traffic Offload (SIPTO). The SIPTO feature allows the network to offload certain traffic (e.g. Internet traffic) either via a femto cell or a macro cell. In the femto cell scenario the candidate traffic can be offloaded on the residential or enterprise IP network, and from there it can be routed onward towards the packets' final destination (e.g. the Internet). As of Sep 2010, 3GPP has agreed on a solution only for macro-SIPTO. The femto-SIPTO requirement will probably be handled in Rel-11 In either case (femto or macro) the terminal uses the 3GPP cellular access only, which makes any use of the ANDSF framework out of scope.

"With SIPTO, the operator can offload selected (typically Internet) traffic by routing it through a PGW that resides close to the RAN. The offload is transparent to the user.

"If the UE has an established LIPA connection, performing 'femto-SIPTO' equates to routing of Internet-bound traffic via the LIPA connection and as the UE moves out of the femto cell coverage, the Internet-bound traffic can be re-routed via a PDN connection corresponding to a macro cell.

"Depicted in FIG. 5 is an example scenario of SIPTO for Internet traffic from a femto cell. In this example the UE has two PDN connections:

"One PDN connection via femto cellular access (PDN1) to the Operator's PDN. It is depicted as a grayed tunnel between the UE and the Packet Data Gateway (PGW), a node representing the ingress point to PDN1, which also assigns the IP address used by the UE on this PDN;

"Another PDN connection via femto cellular access (PDN2) to the Home or Enterprise IP network. It is also depicted as a grayed tunnel, this time terminated on the Local Gateway (L-GW), a node representing the ingress point to PDN2, which also assigns the IP address used by the UE on the Home or Enterprise IP network.

"Similar to the example on non-seamless WLAN offload in FIG. 1, some destinations are reachable only via PDN1 or only via PDN2. For instance, the P-CSCF node (which is the ingress point to the operator's IP multimedia subsystem) is reachable only via PDN1, whereas the Home (or Enterprise) server is reachable only via PDN2. On the other hand, hosts residing in the Internet can be reached via either access.

"Performing SIPTO for Internet traffic in this example equates to routing of Internet-bound traffic via PDN2 whenever the UE is in femto cell coverage and has an established PDN2 connection, because the cost of using PDN2 is much lower compared to the cost of using the PDN1.

"As the UE moves out of the femto cell coverage, the Internet-bound traffic can be rerouted via PDN1.

"A comparison of the use cases described in FIG. 1 and FIG. 5 shows that from an IP routing perspective there are two similar problems to solve. In both situations we are confronted with a multi-homed UE (i.e. UE with multiple IP interfaces) that needs to be assisted in routing of IP packets.

"However, there is at least one difference: with the SIPTO/LIPA scenario shown on FIG. 5 the terminal is a single-mode terminal (i.e. it makes use of the 3GPP interface only). Given this, the usage of the ANDSF framework is simply out of scope for this scenario, as ANDSF is used only in conjunction of non-3GPP accesses.

"FIG. 6 shows a terminal perspective in a femto-SIPTO context. In this context, steering of IP packets (how to route them for example to HoA1 or HoA2) is not defined by 3GPP. Simultaneous access to LIPA and operator's services requires support for multiple PDN connection. The operating system of the UE needs to cope with multiple IP addresses. Presently ANDSF policies can steer flows toward WLAN, but there are currently no operator policies for routing of IP flows across multiple PDN connections (although it is an old feature in 3GPP systems).

"Two other techniques (MAPCON and IFOM) are also available to assist the UE in routing of IP packets based on ANDSF policies, however, neither of them solves the problem of routing across multiple PDN connections.

"FIG. 7 represents an overview of an IFOM architecture. IFOM stands for IP Flow Mobility and is specified in TS 23.261. IFOM allows for individual IP flows to be routed over WLAN or over 3GPP access defined for DSMIPv6 only (currently there is no solution with network based mobility). The UE is a dual radio UE; WLAN and 3GPP interface run continuously in parallel. IFOM is also known as 'seamless WLAN offload', because flows can be re-routed from one access to another with no service break. From an implementation perspective this is only a DSMIPv6 enhancement. IFOM enables simultaneous multi-access PDN connection to the same APN. So IFOM offers IP flow granularity, but only on a single APN.

"FIG. 8 represents an overview of an MAPCON architecture. MAPCON stands for Multi Access PDN CONnectivity. MAPCON allows for entire PDN connections to be routed over WLAN or over 3GPP access. In other words, the granularity of MAPCON is only on a per PDN connection basis, not on a per IP flow basis. MAPCON works with both DSMIPv6 and network based mobility. The UE is a dual radio UE; WLAN and 3GPP interface run continuously in parallel. MAPCON enables simultaneous multiple PDN connectivity to different APNs.

"The invention seeks to improve the situation."

In addition to the background information obtained for this patent application, NewsRx journalists also obtained the inventors' summary information for this patent application: "Solution to Problem

"The invention relates in particular to a method for routing an uplink IP packet of a cellular device. The method comprises obtaining, by a routing client of the cellular device, a routing rule from a routing server. The method comprises routing the uplink IP packet, according to the routing rule, through a first PDN connection or through a second PDN connection, both PDN connections being established over the same cellular radio interface of the cellular device. The invention also relates to a cellular device implementing the above method.

"To achieve these and other advantages and in accordance with the purpose of the present invention, as embodied and broadly described herein, there is provided a method for A method for routing an uplink IP packet of a cellular device, the method comprising: (a) obtaining, by a routing client of the cellular device, a routing rule from a routing server; and (b) according to the routing rule, routing the uplink IP packet through a first PDN connection or through a second PDN connection, both PDN connections being established over the same cellular radio interface of the cellular device.

"Preferably, the routing client may be an ANDSF client and wherein the routing server is an ANDSF server.

"Preferably, the first PDN connection may be established with a gateway providing access to a local IP network, and the second PDN connection is established with a mobile operator's packet core network.

"Preferably, the routing rule may comprise identification information in the form of an IP 5-tuple allowing the cellular device to identify the candidate traffic class of the uplink IP packet.

"Preferably, the routing rule may comprise a list of APNs sorted by priority order, each APN identifying a PDN connection.

"Preferably, the step (a) may comprise submitting, by the cellular device, a list of APNs to the routing server, and receiving, from the routing server, a routing rule comprising only a subset of APNs corresponding to the list of APNs submitted.

"Furthermore, there is provided a cellular device set to establish two PDN connections over the same cellular radio interface of the cellular device, the cellular device comprising: a routing client set to obtain a routing rule from a routing server, wherein the cellular device is set to route an uplink IP packet through the first or through the second PDN connection depending on the routing rule.

"Preferably, the routing client may be an ANDSF client and wherein the routing server is an ANDSF server.

"Preferably, the cellular device may be set to establish the two PDN connections through a common femto cell.

"Preferably, the cellular device may be set to establish the first PDN connection with a gateway providing access to a local IP network, and to establish the second PDN connection with a mobile operator's packet core network.

"Preferably, the routing rule may comprise identification information in the form of an IP 5-tuple allowing the cellular device to identify the candidate traffic class of the uplink IP packet.

"Preferably, the routing rule may comprise a list of APNs sorted by priority order, each APN identifying a PDN connection.

"Preferably, the cellular device may be set to submit a list of APNs to the routing server, and to receive, from the routing server, a routing rule comprising only a subset of APNs corresponding to the list of APNs submitted.

BRIEF DESCRIPTION OF DRAWINGS

"Other aspects and advantages of the invention will become apparent from the following detailed description of specific embodiments of the invention, and the accompanying drawings, in which:

"FIG. 1 represents a possible scenario of non-seamless WLAN offload;

"FIG. 2 represents a non-roaming ANDSF architecture;

"FIG. 3 represents a roaming ANDSF architecture;

"FIG. 4 shows a terminal perspective in the context of a non-seamless WLAN offload;

"FIG. 5 represent a possible scenario of SIPTO for Internet traffic from a femto cell;

"FIG. 6 shows a terminal perspective in a femto-SIPTO context;

"FIG. 7 represents an overview of an IFOM architecture;

"FIG. 8 represents an overview of an MAPCON architecture."

URL and more information on this patent application, see: Stojanovski, Saso; Vedrine, Arnaud. Multihomed Communication Device. Filed December 27, 2010 and posted June 19, 2014. Patent URL: http://appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.html&r=4225&p=85&f=G&l=50&d=PG01&S1=20140612.PD.&OS=PD/20140612&RS=PD/20140612

Keywords for this news article include: Patents, Internet.

Our reports deliver fact-based news of research and discoveries from around the world. Copyright 2014, NewsRx LLC


For more stories covering the world of technology, please see HispanicBusiness' Tech Channel



Source: Clinical Trials Week


Story Tools






HispanicBusiness.com Facebook Linkedin Twitter RSS Feed Email Alerts & Newsletters