Quality of service to over the top applications used with VPN

The present invention is a continuation-in-part of U.S. application Ser. No. 14/032,913, filed Sep. 20, 2013, entitled “Mechanisms For Quality of Service to Over the Top Applications For Use in Commercial Wireless Networks”; which claims priority from U.S. Provisional No. 61/714,944, filed Oct. 17, 2012, entitled “Mechanisms for Quality of Service to Over the Top Applications For Use In Commercial Wireless Networks”. The present application also claims priority from U.S. Provisional No. 61/815,976, filed Apr. 25, 2013, entitled “Quality of Service to Over the Top Applications Used with VPN”; and from U.S. Provisional No. 61/829,745, filed May 31, 2013, entitled “Quality of Service to Over the Top Applications Used with VPN”. The entirety of all four of these applications are expressly incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to Quality of Service (QoS) control for Virtual Private Network(s) (VPNs) established between smart phones and private networks (e.g., enterprise or agency intranet) over Long Term Evolution (LTE) commercial wireless networks. These VPN(s) may be used by smart phone applications to access data in the cloud in a secure manner and typically involve tunneling of original application IP packets in an encrypted fashion inside of an outer IP packet.

2. Background of Related Art

Verizon Wireless™ has recently become the first commercial service provider to fully launch a network with Long Term Evolution (LTE) 4G wireless broadband technology. Long Term Evolution (LTE) 4G wireless broadband technology is a recent technology that supports a fast and efficient all-Internet Protocol (IP) network (i.e., a network that provides services, e.g., voice, video, data, messaging, etc., solely over the Internet). It is expected that the majority of commercial service providers will also adopt an all-Internet Protocol (IP) network at some time in the near future.

As the future of technology gears toward an all-IP network, the number of available over-the-top (OTT) applications is expected to increase. An over-the-top (OTT) application is an application that uses a data channel provided by an Internet service provider (ISP) to connect to the Internet instead of using any special data handling features or network services offered thereby.

In accordance with conventional technology, over-the-top (OTT) application data is sometimes routed over a commercial wireless network via a virtual private network (VPN) tunnel (which involves the tunneling of original IP packets inside outer IP packets in an encrypted fashion). A virtual private network (VPN) tunnel provides additional transmission security to over-the-top (OTT) application data, which is especially helpful to over-the-top (OTT) applications that lack end-to-end encryption on their network connections.

Quality of service (QoS) refers to a set of performance characteristics by which a commercial wireless network is expected to convey data traffic to and from a client (quality of service (QoS) control mechanisms are applied to both the wireless and wireline components of a commercial network). Specific performance characteristics may include throughput (i.e. data quantity transmitted per unit time), latency (i.e. time delay between transmission and receipt of data), loss rate (i.e. frequency by which a commercial wireless network fails to deliver portions of transmitted data), jitter (i.e. a measure of variance of other characteristics), etc.

Currently, there exist several inherent limitations to the quality of service (QoS) treatment that a commercial wireless network is able to provide its' clients. For example, the maximum throughput that a commercial wireless network is able to provide across all clients is dependant on: a spectrum allocation held by the commercial wireless network, a backhaul infrastructure setup between cellular towers and fixed infrastructure within the commercial wireless network, the number of cellular towers in use within the commercial wireless network, the size of a footprint assigned to each cellular tower in use within the commercial wireless network, and any sources of electromagnetic interference within the commercial wireless network.

It is found that applications (e.g. smart phone applications) typically run better (i.e., perform more objective work per unit time and provide better user experience) when they are receiving a higher level of quality of service (QoS) treatment from a commercial wireless network as opposed to a lower level of quality of service (QoS) treatment. Consequently, many clients/service providers enter into contractual agreements with commercial wireless networks to ensure that they receive a data conveyance that is at-or-above a desired minimum performance level. For example, a commercial wireless network may agree (in exchange for monetary compensation) to provide a minimum of 12 kilobit/second throughput and a minimum of 0.1 second latency to a client user equipment (UE) that desires to receive real-time streaming video feed over that wireless network.

Commercial wireless networks use well-known internal techniques to ensure that contracted clients receive a pre-negotiated level of quality of service (QoS) treatment. For example, a network operator may delay transmitting data for one low-level quality of service (QoS) client to prioritize data transmission for another high-level quality of service (QoS) client. Likewise, a network operator may discard data packets transmitted to/from one low-level quality of service (QoS) client more frequently, to ensure data conveyance for another high-level quality of service (QoS) client.

Unfortunately, vendors of over-the-top (OTT) applications and associated data do not typically enter into contractual quality of service (QoS) agreements with commercial wireless networks (e.g. Long Term Evolution (LTE) networks). Therefore, over-the-top (OTT) applications are typically unable to benefit from quality of service (QoS) control mechanisms (e.g. priority, packet delay, guaranteed bit rate, etc.) available thereon. Instead, most over-the-top (OTT) applications (e.g., Skype, Netflix, etc.) provide services on a best-effort basis (i.e., data delivery, efficiency not guaranteed).

Differentiated Services (DiffServ) has defined a mechanism for classifying and managing network traffic on modern Internet Protocol (IP) networks, for the purposes of providing quality of service (QoS) treatment thereon. In particular, DiffServ uses a 6 bit field (i.e. a DS field) in an IP header for packet classification purposes.

In accordance with conventional DiffServ technology, a DS field may be influenced (set) by an application generating IP packets. Moreover, a virtual private network (VPN) client may copy a DiffServ header from an incoming application IP packet (that will eventually be encapsulated) to an IP header of a tunneling IP packet to extend DiffServ quality of service (QoS) treatment to a virtual private network (VPN) environment.

However, though smart phone applications, application cores in the cloud, and virtual private network (VPN) software may all influence the setting of a DS field, there is no guarantee that an Internet Protocol (IP) network (e.g. a long term evolution (LTE) network) will honor a DS field setting and provide desired quality of service (QoS) treatment, being that: first, the honoring of a DS field is not mandated by current standards and, second, triggering quality of service (QoS) treatment in such a fashion defeats the purpose of quality of service (QoS) control as, conceivably, all types of data traffic flowing through an IP network could be marked for preferential treatment by a source application.

As commercial wireless networks begin carrying data for over-the-top (OTT) mission critical applications, such as applications used by emergency dispatch personnel and emergency first responders, a best-effort treatment of over-the-top (OTT) applications will no longer be acceptable. This is especially true in times of disaster, when networks are likely heavily congested. Hence, a successful means of extending quality of service (QoS) treatment to over-the-top (OTT) applications, including over-the-top (OTT) applications transmitting data over a virtual private network (VPN) tunnel, is needed.

SUMMARY

A method and apparatus for extending conventional quality of service (QoS) treatment to over-the-top (OTT) applications transmitting data over a commercial wireless network via a virtual private network (VPN) tunnel, comprises a quality of service (QoS) server. In accordance with the principles of the present invention, an over-the-top (OTT) application server and a virtual private network (VPN) client/server routing data to/from the over-the-top (OTT) application server over a virtual private network (VPN) tunnel, are each integrated with a quality of service (QoS) server. Following integration, the over-the-top (OTT) application server and/or the virtual private network (VPN) client/server may request and get desired quality of service (QoS) treatment for application data routed by the over-the-top (OTT) application over the virtual private network (VPN) tunnel. The present invention is applicable to both single-tenant virtual private network (VPN) tunnels and multi-tenant virtual private network (VPN) tunnels.

In accordance with the principles of the present invention, a single-tenant virtual private network (VPN) tunnel (i.e. a virtual private network (VPN) tunnel that is treated as a single application) is only permitted one quality of service (QoS) designation at a time. Hence, a quality of service (QoS) designation requested for/by an application routing data over a single-tenant virtual private network (VPN) tunnel is applied to all application data routed over that virtual private network (VPN) tunnel.

Alternatively, applications routing data over a multi-tenant virtual private network (VPN) tunnel are acknowledged independently and assigned their own individual quality of service (QoS) designations. Hence, a quality of service (QoS) designation requested for/by an application routing data over a multi-tenant virtual private network (VPN) tunnel is applied to application data routed by that requesting over-the-top (OTT) application, only. In accordance with the principles of the present invention, a multi-tenant virtual private network (VPN) tunnel may define a default quality of service (QoS) designation for application data routed to/from applications that have not indicated a preferred quality of service (QoS) designation.

In accordance with the principles of the present invention, the quality of service (QoS) server forwards desired quality of service (QoS) rules embedded in a quality of service (QoS) request message to a policy and charging rules function (PCRF) on a requesting over-the-top (OTT) application/virtual private network (VPN) client devices' home mobile network operator (MNO). If a client device is roaming, then the policy and charging rules function (PCRF) on the client devices' home mobile network operator (MNO) forwards received quality of service (QoS) rules to a policy and charging rules function (PCRF) serving the client device. Quality of service (QoS) treatment is then carried out in a conventional manner by the serving policy and charging rules function (PCRF).

In accordance with the principles of the present invention, a connection between a quality of service (QoS) server and a policy and charging rules function (PCRF) is preferably established via a diameter Rx interface. Accordingly, the primary function of a quality of service (QoS) server is to translate diameter protocol messages to other communication mediums and vice versa.

In accordance with the principles of the present invention, an over-the-top (OTT) application must provide identification details and register services and application characteristics with the quality of service (QoS) server before that application is permitted to request quality of service (QoS) treatment therefrom. During registration with the quality of service (QoS) server, an over-the-top (OTT) application is required to provision one or more quality of service (QoS) application profiles, each indicating a desired level of quality of service (QoS).

In accordance with the principles of the present invention, a virtual private network (VPN) client/server must furnish relevant tunneling information to the quality of service (QoS) server before that virtual private network (VPN) client/server is permitted to request quality of service (QoS) treatment therefrom. Relevant tunneling information varies depending upon a type of virtual private network (VPN) tunnel established. In particular, during registration with the quality of service (Qos) server, a single-tenant virtual private network (VPN) tunnel is required to provision identification details and one or more quality of service (QoS) application profiles on the quality of service (QoS) server. Alternatively, during registration with the quality of service (Qos) server, a multi-tenant virtual private network (VPN) tunnel must provision identification details and adequate tunneling information on the quality of service (QoS) server, but need not preprovision any quality of service (QoS) application profiles. Tunneling information furnished to the quality of service (QoS) server for a multi-tenant virtual private network (VPN) tunnel must enable the quality of service (QoS) to identify IP packets associated with application data routed thereover.

In accordance with the principles of the present invention, a quality of service (QoS) application profile ID identifying a particular quality of service (QoS) application profile (i.e. quality of service (QoS) rules), is included in each quality of service (QoS) request message sent to the quality of service (QoS) server. A quality of service (QoS) application profile ID indicates to the quality of service (QoS) server a particular quality of service (QoS) application profile to invoke.

When an over-the-top (OTT) application server detects a termination of signaling or service on an over-the-top (OTT) application client device, the over-the-top (OTT) application server sends a quality of service (QoS) termination message to the quality of service (QoS) server, to indicate that reserved quality of service (QoS) values may be terminated on the client devices' home mobile network operator (MNO).

Likewise, a virtual private network (VPN) client/server must inform the quality of service (QoS) server when a virtual private network (VPN) tunnel has terminated.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the present invention will become apparent to those skilled in the art from the following description with reference to the drawings, in which:

<figref idref="DRAWINGS">FIG. 1</figref> depicts an exemplary network structure for extending conventional quality of service (QoS) treatment to over-the-top (OTT) applications routing data over a commercial wireless network via a virtual private network (VPN) tunnel, in accordance with the principles of the present invention.

<figref idref="DRAWINGS">FIG. 2</figref> depicts an exemplary quality of service (QoS) server architecture, in accordance with the principles of the present invention.

<figref idref="DRAWINGS">FIG. 3</figref> depicts an exemplary process flow for extending quality of service (QoS) treatment to over-the-top (OTT) applications routing data over a commercial wireless network via a virtual private network (VPN) tunnel, in accordance with the principles of the present invention.

<figref idref="DRAWINGS">FIG. 4</figref> depicts conventional encryption and encapsulation of an original IP packet, in accordance with conventional IPSec virtual private network (VPN) technology.

<figref idref="DRAWINGS">FIG. 5</figref> depicts a conventional single-tenant virtual private network (VPN) tunnel.

<figref idref="DRAWINGS">FIG. 6</figref> depicts a conventional multi-tenant virtual private network (VPN) tunnel.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The present invention extends conventional quality of service (QoS) treatment to over-the-top (OTT) applications transmitting data over a commercial wireless network (e.g. a long term evolution (LTE) network) via a virtual private network (VPN) tunnel.

New wireless standards, such as long term evolution (LTE), only specify data connectivity, and do not specify any applications. Applications, rather, are expected to be facilitated via carrier-hosted application frameworks (e.g. an internet multimedia system (IMS)).

To ensure that applications carried out via carrier-hosted application frameworks operate at a desired level of quality of service (QoS) (e.g. packet delay, priority, etc.), new wireless standards have defined a policy and charging rules function (PCRF). A policy and charging rules function (PCRF) is a network element (in a long term evolution (LTE) packet core) that may be accessed by carrier-hosted application frameworks (e.g. IMS) (via a diameter protocol based interface (Rx)) for the purposes of providing quality of service (QoS) treatment to applications.

Unfortunately, applications to which policy and charging rules functions (PCRF) are expected to extend quality of service (QoS) treatment, do not include over-the-top (OTT) applications. An over-the-top (OTT) application is an application that provides services/content to a client user equipment (UE) over the Internet, absent the involvement of an Internet service provider (ISP). Hence, conventional over-the-top (OTT) applications are not facilitated via carrier-hosted application frameworks, and are thus not able to benefit from quality of service (QoS) treatment available on today's commercial wireless networks. Rather, conventional over-the-top (OTT) applications are typically forced to operate on a best-effort basis (i.e. data delivery, efficiency not guaranteed).

With the future of technology gearing towards an all IP-network (e.g. a long term evolution (LTE) network), over-the-top (OTT) applications are expected to become increasingly common. As commercial wireless networks begin carrying data for over-the-top (OTT) mission critical applications, such as those applications used by emergency dispatch personnel and emergency first responders, a best effort treatment of over-the-top (OTT) application data will no longer be acceptable.

The present invention expands a method of extending conventional quality of service (QoS) treatment to over-the-top (OTT) applications routing data over a commercial wireless network, as disclosed in co-pending and co-owned U.S. patent application Ser. No. 14/032,913, filed Sep. 20, 2013, entitled: “MECHANISMS FOR QUALITY OF SERVICE TO OVER THE TOP APPLICATIONS FOR USE IN COMMERCIAL WIRELESS NETWORKS”, claiming priority from U.S. Provisional Application No. 61/703,554, filed Sep. 20, 2012, entitled: “MECHANISMS FOR QUALITY OF SERVICE TO OVER THE TOP APPLICATIONS FOR USE IN COMMERCIAL WIRELESS NETWORKS”, and from U.S. Provisional No. 61/714,944, filed Oct. 17, 2012, entitled “MECHANISMS FOR QUALITY OF SERVICE TO OVER THE TOP APPLICATIONS FOR USE IN COMMERCIAL WIRELESS NETWORKS”, all of which are explicitly incorporated herein by reference. Mechanisms for quality of service control disclosed in U.S. patent Ser. No. 14/032,913 address a scenario wherein an over-the-top (OTT) application connects to a cloud based application infrastructure directly.

The present invention addresses a variation of the scenario described in U.S. application Ser. No. 14/032,913. In particular, the present invention addresses a scenario wherein an over-the-top (OTT) application client on a user equipment (UE) is connected to a cloud based over-the-top (OTT) application server via a virtual private network (VPN) connection. A conventional virtual private network (VPN) connection provides additional transport security to over-the-top (OTT) application data traversing a commercial wireless network, by tunneling original IP packets inside outer IP packets in an encrypted fashion. Mechanisms for establishing a virtual private network (VPN) tunnel appropriate to convey over-the-top (OTT) application data are well known to those skilled in the art.

In accordance with the principles of the present invention, conventional quality of service (QoS) treatment is extended to over-the-top (OTT) applications transmitting data over a commercial wireless network (e.g. a long term evolution (LTE) network) via a virtual private network (VPN) tunnel, without requiring that modifications be made to over-the-top (OTT) applications, and without requiring that over-the-top (OTT) application developers negotiate separate quality of service (QoS) agreements with mobile network operators (MNO). Moreover, the present invention extends conventional quality of service (QoS) treatment to virtual private networks (VPN) carrying over-the-top (OTT) application data without burdening virtual private networks (VPN) with network integration aspects, such as: knowledge of user location, knowledge of a policy and charging rules function (PCRF), knowledge of a long term evolution (LTE) packet core, etc.

In accordance with the principles of the present invention, an over-the-top (OTT) application server and a virtual private network (VPN) client/server carrying data to/from that over-the-top (OTT) application server over a virtual private network (VPN) tunnel, are each integrated with an inventive quality of service (QoS) server. Following integration, the over-the-top (OTT) application server and/or the virtual private network (VPN) client/server may send a quality of service (QoS) request message to the inventive quality of service (QoS) server (via an appropriate virtual private network (VPN) client/server interface or over-the-top (OTT) application interface) to request that desired quality of service (QoS) treatment (identified by a quality of service (QoS) application profile ID) be applied to application data routed by the over-the-top (OTT) application over the virtual private network (VPN) tunnel.

The inventive quality of service (QoS) server forwards quality of service (QoS) rules embedded in a quality of service (QoS) request message to a policy and charging rules function (PCRF) residing on a requesting over-the-top (OTT) application/virtual private network (VPN) client devices' home mobile network operator (MNO). If the client device is roaming, then the policy and charging rules function (PCRF) on that device's home mobile network operator (MNO) forwards quality of service (QoS) rules to a policy and charging rules function (PCRF) serving the client device. Quality of service (QoS) treatment is then carried out by the policy and charging rules function (PCRF) in a conventional manner.

In accordance with the principles of the present invention, an over-the-top (OTT) application server and/or a virtual private network (VPN) client/server may modify a previously requested level of quality of service (QoS) treatment, when a previously requested level of quality of service (QoS) treatment is not resulting in desired performance.

The inventive solution may be applied to various virtual private network (VPN) technologies, including: a layer 2 tunneling protocol (L2TP) technology, a point-to-point tunneling protocol (PPTP) technology, a transport layer security/virtual private network (VPN) technology, etc. However, for illustrative purposes, the present invention is described herein via use of an IPSec virtual private network (VPN) technology configured in tunnel mode. In accordance with conventional IPSec virtual private network (VPN) technology, all IP datagrams (including both datagram header and datagram packet) routed over a virtual private network (VPN) tunnel are first encapsulated inside new IP datagrams with IPSec headers.

<figref idref="DRAWINGS">FIG. 4</figref> depicts conventional encryption and encapsulation of an original IP packet, in accordance with conventional IPSec virtual private network (VPN) technology.

In particular, an original IP packet <b>420</b> (including an original IP header <b>440</b> and an original application payload <b>450</b>) is encrypted <b>400</b><i>a</i>, <b>400</b><i>b </i>and encapsulated in an outer IP packet <b>410</b> with an IPSec header <b>430</b> before it is routed over a conventional IPSec virtual private network (VPN) tunnel. A virtual private network (VPN) client/server also interprets an original IP packet <b>420</b> and assigns an appropriate security parameter index (SPI) value (in accordance with a preconfigured security parameter index (SPI) value) thereto before routing the IP packet over a virtual private network (VPN) tunnel. A security parameter index (SPI) value serves as an index to a conventional security association database (SADB) (i.e. a database that maintains information for a virtual private network (VPN) tunnel) maintained for a virtual private network (VPN) tunnel. A security association database (SADB) preferably includes some or all of the following information: security association information (i.e. security parameter index, IPSec protocol, IP destination address) and security policy information (i.e. IP source address, IP destination address, fully qualified domain name, source port number, destination port number, quality of service (QoS) application profile ID).

The present invention is applicable to both single-tenant virtual private network (VPN) tunnels and multi-tenant virtual private network (VPN) tunnels.

<figref idref="DRAWINGS">FIG. 5</figref> depicts a conventional single-tenant virtual private network (VPN) tunnel.

In particular, a single-tenant virtual private network (VPN) tunnel <b>500</b> is always treated as a single application, regardless of how many applications <b>510</b> actually utilize the tunnel <b>500</b>. Therefore, a single-tenant virtual private network (VPN) tunnel <b>500</b> is only permitted one quality of service (QoS) designation <b>540</b> at a time. In accordance with the principles of the present invention, a quality of service (QoS) designation requested for/by an application routing data over a single-tenant virtual private network (VPN) tunnel <b>500</b> is applied to all application data <b>510</b> routed over that virtual private network (VPN) tunnel <b>500</b>.

<figref idref="DRAWINGS">FIG. 6</figref> depicts a conventional multi-tenant virtual private network (VPN) tunnel.

As portrayed in <figref idref="DRAWINGS">FIG. 6</figref>, applications <b>530</b> transmitting data over a multi-tenant virtual private network (VPN) tunnel <b>520</b> are acknowledged independently and may thus be assigned their own individual quality of service (QoS) designations <b>550</b>. A quality of service (QoS) designation <b>550</b> requested for/by an application routing data over a multi-tenant virtual private network (VPN) tunnel <b>500</b> is only applied to application data routed by that application.

<figref idref="DRAWINGS">FIG. 1</figref> depicts an exemplary network structure for extending conventional quality of service (QoS) treatment to over-the-top (OTT) applications routing data over a commercial wireless network via a virtual private network (VPN) tunnel, in accordance with the principles of the present invention.

In particular, as depicted in <figref idref="DRAWINGS">FIG. 1</figref>, a quality of service (QoS) server <b>100</b> is configured to directly interface with one or more commercial wireless networks <b>102</b><i>a</i>, <b>102</b><i>b </i>via a conventional policy and charging rules function (PCRF) (i.e. an IP multimedia subsystem (IMS)/long term evolution (LTE) network component) <b>104</b>. In accordance with the principles of the present invention, a connection between a quality of service (QoS) server <b>100</b> and a policy and charging rules function (PCRF) <b>104</b> is preferably established via a diameter Rx interface <b>106</b> (3GPP specifications 29.209, 29.214). Hence, the primary function of a quality of service (QoS) server <b>100</b> is to translate diameter protocol interface <b>106</b> messages to other communication mediums and vice versa.

Once a connection is established between a policy and charging rules function (PCRF) <b>104</b> and the quality of service (QoS) server <b>100</b>, the inventive quality of service (QoS) server <b>100</b> takes on the role of a special application function (AF) connected on the backend (i.e. not accessible to a user) <b>110</b> of one or more disparate applications. The quality of service (QoS) server <b>100</b> also establishes a connection with a virtual private network (VPN) server <b>112</b> and/or virtual private network (VPN) client <b>118</b>, when application data exchanged between an over-the-top (OTT) application client <b>120</b> and an over-the-top (OTT) application server <b>110</b> happens over a virtual private network (VPN) tunnel <b>114</b>.

As depicted in <figref idref="DRAWINGS">FIG. 1</figref>, the inventive quality of service (QoS) server <b>100</b> uses a secure virtual private network (VPN) client/server interface <b>116</b> to interface with a virtual private network (VPN) client <b>118</b>/server <b>112</b> on either end of a virtual private network (VPN) tunnel <b>114</b>. In accordance with the principles of the present invention, virtual private network (VPN) clients <b>118</b>/servers <b>112</b> use the virtual private network (VPN) client/server interface <b>116</b> to provide relevant tunneling information to the quality of service (QoS) server <b>100</b>. Relevant tunneling information enables the quality of service (QoS) server <b>100</b> to identify IP packets associated with over-the-top (OTT) application data transmitted over a virtual private network (VPN) tunnel <b>114</b>.

In accordance with the principles of the present invention, a virtual private network (VPN) tunnel <b>114</b> is established between a virtual private network (VPN) client <b>118</b> on a user equipment <b>108</b>, and a fixed infrastructure virtual private network (VPN) server <b>112</b>, so that data traffic transmitted to/from one or more over-the-top (OTT) application clients <b>120</b> on the user equipment (UE) <b>108</b> may traverse the virtual private network (VPN) tunnel <b>114</b>. A virtual private network (VPN) tunnel <b>114</b> encrypts and encapsulates an original IP packet inside an outer IP packet while the IP packet is traversing a commercial wireless network. An underlying commercial wireless network <b>102</b><i>a</i>, <b>102</b><i>b </i>is typically configured to provide a certain level of quality of service (QoS) treatment to traffic traversing a virtual private network (VPN) tunnel <b>114</b>.

In accordance with the principles of the present invention, the quality of service (QoS) server <b>100</b> must be able to communicate with backend applications <b>110</b>, carrier policy and charging rules (PCRF) function(s) <b>104</b>, and virtual private network (VPN) clients <b>118</b>/servers <b>112</b>, simultaneously. Simultaneous communication may be permitted via a firewall setting and/or other network configuration rules.

In accordance with the principles of the present invention, a quality of service (QoS) server <b>100</b> may be located separate from a mobile network operator (MNO) <b>102</b><i>a</i>, <b>102</b><i>b </i>or co-located with a mobile network operator (MNO) <b>102</b><i>a</i>, <b>102</b><i>b</i>. Possible mobile network operator (MNO) integration targets currently include: a universal mobile telecommunications system (UMTS), long term evolution (LTE) technology, an evolved-universal mobile telecommunications system (E-UMTS), long term evolution (LTE) technology advanced, and Wi-Fi. The quality of service (QoS) server <b>100</b> may easily be extended to support additional network interfaces as technology evolves.

<figref idref="DRAWINGS">FIG. 2</figref> depicts an exemplary quality of service (QoS) server architecture, in accordance with the principles of the present invention.

In particular, as portrayed in <figref idref="DRAWINGS">FIG. 2</figref>, the inventive quality of service (QoS) server <b>100</b> interacts with a mobile network operator (MNO) policy and charging rules function (PCRF) interface (a diameter protocol interface) <b>106</b>, an over-the-top (OTT) application interface <b>210</b>, a number portability database (NPDB) interface <b>240</b>, and a virtual private network (VPN) client/server interface <b>116</b> to extend quality of service (QoS) treatment to applications routing data over a commercial wireless network <b>102</b><i>a</i>, <b>102</b><i>b </i>via a virtual private network (VPN) tunnel <b>114</b>.

In accordance with the principles of the present invention, the quality of service (QoS) server <b>100</b> maintains profiles and information for over-the-top (OTT) applications in a local application information database <b>220</b>, tunneling and IP packet information for registered virtual private network (VPN) tunnels in a local virtual private network (VPN) tunneling information database <b>250</b>, and home mobile network operator (MNO) information for over-the-top (OTT) application client devices in a local mobile network operator (MNO) information database <b>230</b>.

If by chance the quality of service (QoS) server <b>100</b> is not able to find home mobile network operator (MNO) information for a requesting client device <b>108</b> in the local mobile network operator (MNO) information database <b>230</b>, then the quality of service (QoS) server <b>100</b> accesses a number portability database (NPDB) interface <b>240</b> to retrieve relevant home mobile network operator (MNO) information from an external number portability database (NPDB) <b>270</b>.

The over-the-top (OTT) application interface <b>210</b>, as depicted in <figref idref="DRAWINGS">FIG. 2</figref>, is designed to operate over a secure, transport layer security (TLS)/secure sockets layer (SSL) communications channel that utilizes representational state transfer (REST) hypertext transfer protocol (HTTP), hypertext transfer protocol (HTTP), simple object access protocol (SOAP), extensible markup language (XML), etc., message formats. New mediums for the over-the-top (OTT) application interface <b>210</b> may be defined and used, as appropriate, as long as application quality of service (QoS) message formats (i.e. attributes and corresponding values included in application quality of service messages) conform minimally to application quality of service (QoS) message formats described herein (i.e. an application quality of service (QoS) request message format, an application quality of service (QoS) response message format, and an application quality of service (QoS) termination message format).

As previously stated, the quality of service (QoS) server <b>100</b> uses a diameter Rx protocol (3GPP 29.214) to interface <b>106</b> with a mobile network operator (MNO) policy and charging rules function (PCRF) <b>104</b>. A mobile network operator (MNO) policy and charging rules function (PCRF) interface <b>106</b>, as depicted in <figref idref="DRAWINGS">FIG. 2</figref>, provides discovery and addressing of a home policy and charging rules function (HPCRF) <b>104</b> assigned to a requesting over-the-top (OTT) application/virtual private network (VPN) client device <b>108</b>. The mobile network operator (MNO) policy and charging rules function (PCRF) interface <b>106</b> is also enhanced to allow tracking registration of the following IP header information: a virtual private network (VPN) security parameter index (SPI) (per RFC 2401, as required with IPSec protocol by a virtual private network (VPN) client/server) and an IPSec protocol (per RFC 2401).

In accordance with the principles of the present invention, the quality of service (QoS) server <b>100</b> assumes the role of an application function (AF) and complies with policy and charging rules function (PCRF) <b>104</b> discovery and addressing, as described in a 3GPP series 29.213 specification. In support of this 3GPP series 29.213 specification, the quality of service (QoS) server <b>100</b> preferably maintains a table with a fully qualified domain name (FQDN) or internet protocol (IP) address of a policy and charging rules function (PCRF) <b>104</b>, for each supported single policy and charging rules function (PCRF) mobile network operator (MNO), and a diameter routing agent, for each supported multi-policy and charging rules function (PCRF) mobile network operator (MNO).

The quality of service (QoS) server <b>100</b> interfaces with a home policy and charging rules function (HPCRF) <b>104</b>, regardless as to whether or not a client user equipment (UE) <b>108</b> is roaming. A home policy and charging rules function (HPCRF) <b>104</b> coordinates a download of quality of service (QoS) rules to a visiting policy and charging rules function (VPCRF) in a roaming network (per 3GPP standards) when a requesting client user equipment (UE) <b>108</b> is roaming.

In accordance with the principles of the present invention, number portability databases (NPDB) <b>270</b> and the local mobile network operator (MNO) information database <b>230</b> (as shown in <figref idref="DRAWINGS">FIG. 2</figref>) support multiple transaction capabilities application part (TCAP) based protocols (e.g., advanced intelligent network (AIN), intelligent network application protocol (INAP), American national standards institute ((ANSI)-41), etc.) for number portability queries, since such protocols support queries from both wireline and wireless networks based on various standards. The quality of service (QoS) server <b>100</b> preferably uses a number portability request (NPREQ) TCAP query (per telecommunications industry association/electronic industries association (TIA/EIA)-756A and telecommunications industry association/electronic industries association (TIA/EIA) ANSI41-D specifications) to determine a current mobile network operator (MNO) associated with an over-the-top (OTT) application client device <b>108</b>. The quality of service (QoS) server <b>100</b> may easily be extended to support other protocols for number portability lookup.

As previously stated, the quality of service (QoS) server <b>100</b> uses a virtual private network (VPN) client/server interface <b>116</b> to interface with a virtual private network (VPN) client <b>118</b> and/or a virtual private network (VPN) server <b>112</b>. The virtual private network (VPN) client/server interface <b>116</b>, as portrayed in <figref idref="DRAWINGS">FIG. 2</figref>, is designed to operate over a secure transport layer security (TLS)/secure sockets layer (SSL) communications channel that utilizes representational state transfer (REST) hypertext transfer protocol (HTTP), hypertext transfer protocol (HTTP), simple object access protocol (SOAP), extensible markup language (XML), etc., message formats. The quality of service (QoS) server <b>100</b> may also/alternatively interface with a virtual private network (VPN) client <b>118</b> via a wireless network connection <b>260</b>.

New mediums for the virtual private network (VPN) client/server interface <b>116</b> may be defined and used as appropriate, as long as VPN quality of service (QoS) message formats (i.e. attributes and corresponding values included in VPN quality of service (QoS) messages) conform minimally to VPN quality of service (QoS) message formats described herein (i.e. a VPN quality of service (QoS) request message format, a VPN quality of service (QoS) response message format, and a VPN quality of service (QoS) termination message format). Depending upon the implementation, a VPN quality of service (QoS) message may additionally be embedded in a defined message format, e.g., a radius or diameter message format.

<figref idref="DRAWINGS">FIG. 3</figref> depicts an exemplary process flow for extending quality of service (QoS) treatment to over-the-top (OTT) applications routing data over a commercial wireless network via a virtual private network (VPN) tunnel, in accordance with the principles of the present invention.

In particular, as shown in step <b>1</b><i>a </i>of <figref idref="DRAWINGS">FIG. 3</figref>, a virtual private network (VPN) tunnel performs VPN profile configuration with a quality of service (QoS) server <b>100</b> via an authenticated virtual private network (VPN) client/server interface <b>116</b>. During virtual private network (VPN) profile configuration, a virtual private network (VPN) client/server furnishes relevant tunneling information to the quality of service (QoS) server <b>100</b> for a virtual private network (VPN) tunnel established therebetween. Relevant tunneling information varies depending upon the type of virtual private network (VPN) tunnel established.

In particular, a single-tenant virtual private network (VPN) tunnel <b>500</b> provisions one or more quality of service (QoS) application profiles (and corresponding quality of service application profile IDs) on the quality of service (QoS) server <b>100</b> during VPN profile configuration. A quality of service (QoS) application profile includes tunnel identification details and indicates a desired level of quality of service (QoS) treatment.

Alternatively, a multi-tenant virtual private network (VPN) tunnel <b>520</b> provisions identification details on the quality of service (QoS) server <b>100</b> during VPN profile configuration, but need not provision any quality of service application profiles. Rather, over-the-top (OTT) applications <b>530</b> utilizing a multi-tenant virtual private network (VPN) tunnel <b>520</b> provision their own quality of service (QoS) application profiles on the quality of service (QoS) server <b>100</b> during application profile configuration, performed in step <b>1</b><i>b</i>. A quality of service (QoS) designation requested by an over-the-top (OTT) application transmitting data over a multi-tenant virtual private network (VPN) tunnel <b>520</b> is associated to that multi-tenant virtual private network (VPN) tunnel <b>520</b>.

In accordance with the principles of the present invention, a multi-tenant virtual private network (VPN) <b>520</b> tunnel must provide adequate tunneling information (including IPSec security policy and IPSec security association information) to the quality of service (QoS) server <b>100</b> during VPN profile configuration. Adequate tunneling information is any information that enables the quality of service (QoS) server <b>100</b> to determine actual IP header information <b>440</b> associated with application data routed over the multi-tenant virtual private network (VPN) tunnel <b>520</b>. Moreover, tunneling information must enable the quality of service (QoS) server <b>100</b> to adequately communicate quality of service (QoS) rules defined in a quality of service (QoS) request message to a relevant policy and charging rules function (PCRF) <b>104</b>.

Table 1 depicts exemplary tunneling information provided to the quality of service (QoS) server during virtual private network (VPN) profile configuration.

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="center" /><colspec colname="2" colwidth="210pt" align="center" /><thead><row><entry namest="1" nameend="2" rowsep="1">TABLE 1</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Security Association (Tunnel </entry><entry /></row><row><entry>Header Information)</entry><entry>Security Policy Information (For Encapsulated Traffic)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="9"><colspec colname="1" colwidth="35pt" align="center" /><colspec colname="2" colwidth="28pt" align="center" /><colspec colname="3" colwidth="35pt" align="center" /><colspec colname="4" colwidth="35pt" align="center" /><colspec colname="5" colwidth="35pt" align="center" /><colspec colname="6" colwidth="35pt" align="center" /><colspec colname="7" colwidth="28pt" align="center" /><colspec colname="8" colwidth="35pt" align="center" /><colspec colname="9" colwidth="42pt" align="center" /><tbody valign="top"><row><entry /><entry /><entry /><entry /><entry /><entry>Fully</entry><entry /><entry /><entry /></row><row><entry>Security</entry><entry /><entry>IP</entry><entry /><entry>IP</entry><entry>Qualified</entry><entry>Source </entry><entry>Destination </entry><entry>QoS-</entry></row><row><entry>Parameter</entry><entry>IPSec</entry><entry>Destination</entry><entry>IP Source</entry><entry>Destination</entry><entry>Domain</entry><entry>Port </entry><entry>Port</entry><entry>Application-</entry></row><row><entry>Index</entry><entry>Protocol</entry><entry>Address</entry><entry>Address</entry><entry>Address</entry><entry>Name</entry><entry>Number</entry><entry>Number</entry><entry>Profile-ID</entry></row><row><entry namest="1" nameend="9" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

In particular, as portrayed in Table 1, IPSec security policy information (for encapsulated data traffic) and IPSec security association information (tunnel header information) relevant to a virtual private network (VPN) tunnel is provided to the quality of service (QoS) server <b>100</b> during VPN profile configuration (step <b>1</b><i>a</i>). Relevant IPSec security policy information preferably includes: an IP source address, an IP destination address, a fully qualified domain name, a source port number, a destination port number, and a quality of service application profile ID. Relevant IPSec security association information preferably includes: a security parameter index, an IPSec protocol, and an IP destination address.

Updated tunneling information must be furnished to the quality of service (QoS) server <b>100</b> for each new virtual private network (VPN) tunnel that is established. In accordance with the principles of the present invention, tunneling information may either be preprovisioned on the quality of service (QoS) server <b>100</b> during VPN profile configuration, or provided to the quality of service (QoS) server <b>100</b> dynamically, via use of a VPN quality of service (QoS) registration message.

As portrayed in step <b>1</b><i>b </i>of <figref idref="DRAWINGS">FIG. 3</figref>, an application performs application profile configuration on the quality of service (QoS) server <b>100</b> via an authenticated over-the-top (OTT) application interface <b>210</b>. In accordance with the principles of the present invention, an over-the-top (OTT) application must provide identification details and register services and application characteristics with a quality of service (QoS) server <b>100</b> before that application is permitted to request quality of service (QoS) treatment therefrom. For security purposes, the quality of service (QoS) server <b>100</b> only accepts registration attempts from over-the-top (OTT) applications for which the quality of service (QoS) server <b>100</b> has been pre-configured to accept registration attempts. Therefore, not all over-the-top (OTT) applications are permitted to register with a quality of service (QoS) server <b>100</b>. Moreover, over-the-top (OTT) applications that are granted registration with a quality of service (QoS) server <b>100</b> are only permitted to receive levels of quality of service (QoS) treatment for which they have been pre-authorized to receive. Quality of service (QoS) requests are validated by the quality of service (QoS) server <b>100</b> before they are processed. An over-the-top (OTT) application also identifies service abilities and provisions one or more quality of service (QoS) application profiles on the quality of service (QoS) server <b>100</b> during application profile configuration.

However, before an over-the-top (OTT) application can register and provision quality of service (QoS) application profiles on the quality of service (QoS) server <b>100</b>, the quality of service (QoS) server <b>100</b> must first collect the following data from the over-the-top (OTT) application (more characteristics may be required as new application characteristics present themselves): an over-the-top (OTT) application identifier, over-the-top (OTT) access credentials, one or more quality of service (QoS) application profile IDs, over-the-top (OTT) application characteristics, and one or more mobile network operator (MNO) associations.

In accordance with the principles of the present invention, an over-the-top (OTT) application identifier is a unique string (synchronized with a carrier provided “AF-Application-Identifier”) that is provided to an over-the-top (OTT) application via an out-of-band mechanism. An over-the-top (OTT) application identifier may be prefixed with quality of service (QoS) unique identifiers for use on the quality of service (QoS) server <b>100</b>.

Over-the-top (OTT) access credentials (e.g. a secret/password or public key infrastructure (PKI) verification) are a set of credentials agreed upon by an over-the-top (OTT) application and the quality of service (QoS) server <b>100</b> in an out of band manner.

A quality of service (QoS) application profile ID is a quality of service (QoS) specific value, defined per application identifier. More particularly, the quality of service (QoS) application profile ID is defined by the quality of service (QoS) server <b>100</b> and provided to an over-the-top (OTT) application via an out of band mechanism.

In accordance with the principles of the present invention, a quality of service (QoS) application profile ID points to a quality of service (QoS) application profile that is to be provisioned for an over-the-top (OTT) application. A quality of service (QoS) application profile contains application details (e.g. service characteristics, etc.) and indicates a desired level of quality of service (QoS) treatment. A quality of service (QoS) application profile ID is referenced in each quality of service (QoS) request message sent to the quality of service (QoS) server <b>100</b>, to indicate to the quality of service (QoS) server <b>100</b> a particular quality of service (QoS) application profile to invoke. In accordance with the principles of the present invention, an over-the-top (OTT) application may provision multiple quality of service (QoS) application profiles to indicate varying levels of desired quality of service (QoS).

Over-the-top (OTT) application characteristics provided to the quality of service (QoS) server <b>100</b> during application profile configuration include (this list may be extended as new requirements develop, either by 3GPP specifications or via over-the-top (OTT) evolution): a media component number (i.e. an ordinal number of a media component), a media sub-component (i.e. a set of flows for one flow identifier), an application identifier, a media type (e.g. audio (0), video (1), data (2), application (3), control (4), text (5), message (6), other (0xFFFFFFFF)), a maximum requested bandwidth (Bw) uplink (UL), a maximum requested bandwidth (Bw) downlink (DL), a flow status, a reservation priority, RS bandwidth (Bw), RR bandwidth (Bw), codec data, and a tunnel encapsulation indicator, e.g., yes, no, IPSec, etc.

In accordance with the principles of the present invention, a media sub-component field may include the following characteristics: a flow number (i.e. an ordinal number of the IP flow), a flow description (e.g. uplink (UL) and/or downlink (DL)), a flow status, flow usage, a maximum requested bandwidth (Bw) uplink (UL), a maximum requested bandwidth (Bw) downlink (DL), and an application function (AF) signaling protocol.

Moreover, a mobile network operator (MNO) associations field provided to the quality of service (QoS) server <b>100</b> during application profile configuration identifies all of the networks for which an over-the-top (OTT) application is authorized to designate quality of service (QoS) settings. Values in a mobile network operator (MNO) associations field are defined per quality of service (QoS) implementation and represent system logical identifiers for the purposes of routing communications to particular policy and charging rules (PCRF) functions.

In accordance with the principles of the present invention, once required application data is furnished to the quality of service (QoS) server <b>100</b>, an over-the-top (OTT) application provisions one or more quality of service (QoS) application profiles on the quality of service (QoS) server <b>100</b>. Following quality of service (QoS) application profile provisioning, the over-the-top (OTT) application may begin submitting registrations to the quality of service (QoS) server <b>100</b>, on a per user equipment (UE) basis. In accordance with the principles of the present invention, an over-the-top (OTT) application is required to register with the quality of service (QoS) server <b>100</b> periodically.

Following application profile configuration, an over-the-top (OTT) application may send quality of service (QoS) requests to the quality of service (QoS) server <b>100</b>, on a per user equipment (UE) basis.

As shown in steps <b>2</b><i>a </i>and <b>2</b><i>b </i>of <figref idref="DRAWINGS">FIG. 3</figref>, a virtual private network (VPN) tunnel <b>114</b> is established between a virtual private network (VPN) client <b>118</b> on a user equipment (UE) <b>108</b> and a fixed infrastructure virtual private network (VPN) server <b>112</b>, so as to allow data traffic transmitted to/from one or more over-the-top (OTT) application clients <b>120</b> (that have undergone application profile configuration on the quality of service (QoS) server <b>100</b>) on the user equipment (UE) <b>108</b> to traverse the tunnel <b>114</b>.

In accordance with the principles of the present invention, the virtual private network (VPN) client <b>118</b>/server <b>112</b> sends a VPN quality of service (QoS) registration message with appropriate tunneling information to the quality of service (QoS) server <b>100</b> during VPN tunnel establishment, as depicted in steps <b>3</b><i>a </i>and <b>3</b><i>b </i>of <figref idref="DRAWINGS">FIG. 3</figref>. Upon receipt of the VPN quality of service (QoS) registration message, the quality of service (QoS) server <b>112</b> returns a VPN quality of service (QoS) registration response message to the virtual private network (VPN) client <b>118</b>/server <b>112</b>, as depicted in steps <b>4</b><i>a </i>and <b>4</b><i>b </i>of <figref idref="DRAWINGS">FIG. 3</figref>. VPN tunneling information may alternatively be provisioned on the quality of service (QoS) server <b>100</b> during VPN profile configuration.

Once VPN registration with the quality of service (QoS) server <b>100</b> is complete, the virtual private network (VPN) client <b>118</b>/server <b>112</b> may send a VPN quality of service (QoS) request message to the quality of service (QoS) server <b>100</b> to request desired quality of service (QoS) treatment therefrom, as shown in steps <b>5</b><i>a </i>and <b>5</b><i>b </i>of <figref idref="DRAWINGS">FIG. 3</figref>.

In accordance with the principles of the present invention, VPN quality of service (QoS) registration and request messages preferably include: a message ID (i.e. an identifier defined by, and unique to, a requesting virtual private network (VPN) server <b>112</b>/client <b>118</b>), a quality of service (QoS) application profile ID (optional), a publically available mobile network assigned source framed internet protocol (IP) address (an attribute-value pair (AVP)) or framed IPv6 prefix (an attribute-value pair (AVP), RFC 4005 [12]), a flow description (an attribute-value pair (AVP), 3GPP 29.214), a virtual private network (VPN) security parameter index (SPI) (per RFC 2041, as required with IPSec protocol by the virtual private network (VPN) client/server), an IPSec protocol (per RFC 2041), a virtual private network (VPN) IP destination (i.e. a routable IP address for the virtual private network (VPN) server), and a VPN-CS.

A quality of service (QoS) application profile ID in a VPN quality of service (QoS) request message indicates a desired level of quality of service (QoS) treatment. A quality of service (QoS) application profile ID is required in a VPN quality of service (QoS) request message when the message is provided to the quality of service (QoS) server <b>100</b> dynamically. Otherwise, the quality of service (QoS) server <b>100</b> derives a quality of service (QoS) application profile ID based on a combination of values embedded in the VPN quality of service (QoS) request message.

A flow description is required in a VPN quality of service (QoS) request message when a quality of service (QoS) application profile ID is not provided therein. In accordance with the principles of the present invention, a flow description must comprise one of the following two directions: ‘in’ or ‘out’, whereas direction ‘in’ refers to an uplink (UL) IP flow and direction ‘out’ refers to a downlink (DL) IP flow. A flow description may also contain: a source and destination IP address (possibly masked), a protocol and a source and destination port (a source port may be omitted to indicate that any source port is allowed). Lists and ranges may not be used to indicate source and/or destination ports.

In accordance with the principles of the present invention, the quality of service (QoS) server <b>100</b> accepts VPN quality of service (QoS) request messages from both a virtual private network (VPN) client <b>118</b> and a virtual private network (VPN) server <b>112</b>. Hence, depending upon the implementation, some information may be missing from a VPN quality of service (QoS) request message.

When both a virtual private network (VPN) server <b>112</b> and a virtual private network (VPN) client <b>118</b> send a VPN quality of service (QoS) request message to the quality of service (QoS) server <b>100</b> for a single VPN connection <b>114</b>, messages from each source must include a reference to the other, to enable the quality of service (QoS) server <b>100</b> to successfully assemble all relevant information and assign an appropriate quality of service (QoS) designation to over-the-top (OTT) application data traversing the virtual private network (VPN) connection <b>114</b>. A VPN-CS field is preferably used to provide such a reference.

In particular, when VPN quality of service (QoS) request messages are sent by both a virtual private network (VPN) server <b>112</b> and a virtual private network (VPN) client <b>118</b> for a single virtual private network (VPN) connection <b>114</b>, optional attribute tag, ‘VPN-CS’ is preferably included therein. Optional attribute tag ‘VPN-CS’ contains a unique message identifier that is used by both a virtual private network (VPN) server <b>112</b> and a virtual private network (VPN) client <b>118</b>, to show that messages refer to a single virtual private network (VPN) connection <b>114</b>.

As shown in step <b>6</b> of <figref idref="DRAWINGS">FIG. 3</figref>, the quality of service (QoS) server <b>100</b> performs VPN quality of service (QoS) request message validation in response to a VPN quality of service (QoS) request message received thereon. In particular, during VPN quality of service (QoS) request message validation, the quality of service (QoS) server <b>100</b> validates a quality of service (QoS) application profile ID received in the VPN quality of service (QoS) request message.

In accordance with the principles of the present invention, the quality of service (QoS) server <b>100</b> may either determine a quality of service (QoS) application profile ID directly or indirectly from the VPN quality of service (QoS) request message. Indirect determination of a quality of service (QoS) application profile ID includes analyzing and matching VPN quality of service (QoS) request message parameters to an appropriate quality of service (QoS) application profile ID. Once a quality of service (QoS) application profile ID is determined, the quality of service (QoS) server <b>100</b> performs one of the following two potential courses of action, depending upon the type of virtual private network (VPN) tunnel <b>114</b> established in steps <b>2</b><i>a</i>-<b>4</b><i>b. </i>

In particular, if the virtual private network tunnel (VPN) <b>114</b> is a multi-tenant virtual private network (VPN) tunnel <b>520</b>, then the quality of service (QoS) server <b>100</b> records and tracks virtual private network (VPN) <b>114</b> tunneling information received in the VPN quality of service (QoS) request message in a virtual private network (VPN) tunneling information database <b>250</b>, and subsequently returns a VPN quality of service (QoS) response message to the requesting virtual private network (VPN) client <b>118</b>/server <b>112</b>, as depicted in step <b>7</b>. In accordance with the principles of the present invention, the quality of service (QoS) server <b>100</b> then waits to receive an application quality of service (QoS) registration message or an application quality of service (QoS) termination message from an over-the-top (OTT) application routing or attempting to route data over the virtual private network (VPN) tunnel <b>114</b>.

In a multi-tenant virtual private network (VPN) scenario, if a quality of service (QoS) application profile ID received in an application quality of service (QoS) request message differs from a quality of service (QoS) application profile ID embedded in a VPN quality of service (QOS) request message, the quality of service (QoS) application profile ID in the application quality of service (QoS) request message is used to influence quality of service (QoS) treatment.

Alternatively, if the virtual private network tunnel (VPN) <b>114</b> established in steps <b>2</b><i>a</i>-<b>4</b><i>b </i>is a single-tenant virtual private network (VPN) tunnel <b>500</b>, then the quality of service (QoS) server <b>100</b> immediately applies quality of service (QoS) rules received in the VPN quality of service (QoS) registration or request message to all application data routed over the virtual private network (VPN) tunnel <b>114</b>. The quality of service rules are extracted from the VPN quality of service (QoS) registration message if that is the only message received and VPN quality of services (QoS) request message if both are received.

In particular, when a VPN quality of service (QoS) registration (or request if received) message is received from a single-tenant virtual private network (VPN) client <b>118</b>/server <b>112</b>, the quality of service (QoS) server <b>100</b> queries a local mobile network operator (MNO) information database <b>230</b> to retrieve home mobile network operator (MNO) information for the over-the-top (OTT) application/virtual private network (VPN) client device <b>108</b>, as depicted in step <b>8</b>. If the quality of service (QoS) server <b>100</b> cannot find home mobile network operator (MNO) information for the client device in the local mobile network operator (MNO) information database <b>230</b>, then the quality of service (QoS) server <b>100</b> alternatively queries an external number portability database (NPDB) <b>270</b> via a number portability database (NPDB) interface <b>240</b>. Results from either the number portability database (NPDB) <b>270</b> or the local mobile network operator (MNO) information database <b>230</b> provide the quality of service (QoS) server <b>100</b> with enough information to determine a home mobile network operator (MNO) for the over-the-top (OTT) application/VPN client device <b>108</b> (step <b>9</b>).

Once a home mobile network operator (MNO) is identified, the quality of service (QoS) server <b>100</b> uses the quality of service (QoS) application profile ID defined in the VPN quality of service (QoS) registration (or request if received) message to determine whether or not over-the-top (OTT) applications routing data over the virtual private network (VPN) tunnel are authorized to influence quality of service (QoS) treatment on the home mobile network operator (MNO) (step <b>10</b>). In this particular example, there is only one over-the-top (OTT) application configured to transmit data over the virtual private network (VPN) tunnel <b>114</b>.

In accordance with the principles of the present invention, if the over-the-top (OTT) application configured to route data over the virtual private network (VPN) tunnel <b>114</b> is permitted to influence quality of service (QoS) settings on the home mobile network operator (MNO), then the quality of service (QoS) server <b>100</b> sends a diameter authentication/authorization request (AAR) message with appropriate quality of service (QoS) information to a policy and charging rules function (PCRF) <b>104</b> on the client devices' <b>108</b> home mobile network operator (MNO), as shown in step <b>11</b>.

In step <b>12</b>, the policy and charging rules function (PCRF) <b>104</b> on the client devices' <b>108</b> home mobile network operator (MNO) receives the quality of service (QoS) information and returns a diameter authentication/authorization answer (AAA) message to the quality of service (QoS) server <b>100</b>.

Upon receipt of the diameter authentication/authorization answer (AAA) message, the quality of service (QoS) server <b>100</b> sends a VPN quality of service (QoS) response message to the requesting VPN client <b>118</b>/server <b>112</b>, as depicted in step <b>13</b>.

In accordance with the principles of the present invention, a VPN quality of service (QoS) response message preferably includes: a message ID, an application identifier, and a status identifier.

A status identifier included in a status field of a VPN quality of service (QoS) response message may be any one or more of the following: a success status identifier (<b>100</b>), a quality of service (QoS) system failure status identifier (<b>200</b>) (indicating a default failure or unexpected failure with no available details), a failed validation of application identifier/access credentials status identifier (<b>201</b>), a failed validation of quality of service (QoS) profile ID status identifier (<b>202</b>), a quality of service (QoS) system failure reserved message status identifier (defined per quality of service (QoS) implementation and used to explain a unique system failure) (<b>203</b>-<b>299</b>), a PCRF unavailable status identifier (<b>300</b>), and/or an AAR/AAA message failure status identifier (<b>400</b>), wherein the entire contents of the AAA message is embedded in the status field.

Once the virtual private network (VPN) tunnel <b>114</b> is setup between the virtual private network (VPN) client <b>118</b> on the user equipment <b>108</b> and the virtual private network (VPN) server <b>112</b>, the over-the-top (OTT) application client <b>120</b> configured to route data over the virtual private network (VPN) tunnel <b>114</b> may use the virtual private network (VPN) tunnel <b>114</b> to register with a corresponding over-the-top (OTT) application server <b>110</b> (via a Gi/SGi interface <b>310</b>), as shown in steps <b>14</b><i>a </i>and <b>14</b><i>b </i>of <figref idref="DRAWINGS">FIG. 3</figref>.

When the over-the-top (OTT) application server <b>110</b> receives a service registration request from the over-the-top (OTT) application client <b>120</b>, the over-the-top (OTT) application server <b>110</b> may attempt to establish a mutually authenticated (client <b>120</b> and server <b>110</b>) transport layer security (TLS)/secure sockets layer (SSL) connection with the inventive quality of service (QoS) server <b>100</b> (via standard TLS/SSL procedures for mutual authentication), as shown in step <b>15</b>.

If the initial mutual authentication step is successful, then the over-the-top (OTT) application server <b>110</b> sends an application quality of service (QoS) request message to the quality of service (QoS) server <b>100</b> to request that a desired level of quality of service (QoS) treatment be applied to application data routed by that over-the-top (OTT) application over the virtual private network (VPN) tunnel <b>114</b>, as portrayed in step <b>16</b>.

In accordance with the principles of the present invention, a quality of service (QoS) request message preferably includes: a message ID (i.e. an identifier defined by, and unique to, a requesting over-the-top (OTT) application), an application identifier (as described in 3GPP series 29.214 specification), access credentials (e.g. a secret/password public key infrastructure (PKI) verification, etc.), a quality of service (QoS) application profile ID, a source framed internet protocol (IP) address (an attribute-value pair (AVP)) or framed IPv6 prefix (an attribute-value pair (AVP), RFC 4005 [12]), a service uniform resource name (URN) (an attribute-value pair (AVP), 3GPP 29.214), a reservation priority (TS 183.017 [15]) (a vendor ID shall be set to european telecommunications standards institute (ETSI) (13019) [15]), a subscription ID (RFC 4006 [14]) identifying a particular subscription (e.g. international mobile subscriber identity (IMSI), mobile subscriber integrated services digital network (MSISDN), etc.), and a flow description (an attribute-value pair (AVP), 3GPP 29.214).

A flow description in an application quality of service (QoS) request message must comprise one of the following two directions: ‘in’ or ‘out’, whereas direction ‘in’ refers to an uplink (UL) IP flow and direction ‘out’ refers to a downlink (DL) IP flow. A flow description in an application quality of service (QoS) request message may also contain: a source and destination IP address (possibly masked), a protocol, and a source and destination port (a source port may be omitted to indicate that any source port is allowed). Lists and ranges may not be used to indicate source and/or destination ports.

A quality of service (QoS) application profile ID in an application quality of service (QoS) request message indicates appropriate quality of service (QoS) information to send to a home policy and charging rules function (PCRF) <b>104</b>.

In accordance with the principles of the present invention, the quality of service (QoS) server <b>100</b> performs application quality of service (QoS) request message validation in response to an application quality of service (QoS) request message received thereon, as portrayed in step <b>17</b> of <figref idref="DRAWINGS">FIG. 3</figref>.

During application quality of service (QoS) request message validation, the quality of service (QoS) server <b>100</b> validates the application identifier, access credentials (e.g. a secret/password public key infrastructure (PKI) verification, etc.), and quality of service (QoS) application profile ID received in the application quality of service (QoS) request message, against application profiles maintained in a local application information database <b>220</b>. The quality of service (QoS) server <b>100</b> validates the format and values of application quality of service (QoS) request message attributes in accordance with a 3GPP series 29.214 specification.

When application quality of service (QoS) request message validation is complete, the quality of service (QoS) server <b>100</b> queries a local mobile network operator (MNO) information database <b>230</b> to retrieve home mobile network operator (MNO) information for the requesting over-the-top (OTT) application client device <b>108</b>, as depicted in step <b>18</b>. If the quality of service (QoS) server <b>100</b> cannot find home mobile network operator (MNO) information for the requesting client device <b>108</b> in the local mobile network operator (MNO) information database <b>230</b>, then the quality of service (QoS) server <b>100</b> alternatively queries an external number portability database (NPDB) <b>270</b> via a number portability database (NPDB) interface <b>240</b>. Results from either the number portability database (NPDB) <b>270</b> or the local mobile network operator (MNO) information database <b>230</b> provide the quality of service (QoS) server <b>100</b> with enough information to determine a home mobile network operator (MNO) for the requesting client device <b>108</b>.

Once a home mobile network operator (MNO) is identified (step <b>19</b>), the quality of service (QoS) server <b>100</b> uses a quality of service (QoS) application profile ID, defined in the application quality of service (QoS) request message, to determine whether or not the requesting over-the-top (OTT) application is authorized to influence quality of service (QoS) treatment on the home mobile network operator (MNO).

In step <b>20</b> of <figref idref="DRAWINGS">FIG. 3</figref>, if the over-the-top (OTT) application is permitted to influence quality of service (QoS) settings on the home mobile network operator (MNO), then the quality of service (QoS) server <b>100</b> queries a local virtual private network (VPN) tunneling information database <b>250</b> to determine actual IP packet information associated with application data routed by the over-the-top (OTT) application over the virtual private network (VPN) tunnel <b>114</b>.

In step <b>21</b> of <figref idref="DRAWINGS">FIG. 3</figref>, the quality of service (QoS) server <b>100</b> sends a diameter authentication/authorization request (AAR) message with appropriate quality of service (QoS) information and appropriate IP tunneling data to a policy and charging rules function (PCRF) <b>104</b> on the client devices' <b>108</b> home mobile network operator (MNO). Appropriate quality of service (QoS) information depends on the type of virtual private network (VPN) tunnel <b>114</b> routing data.

In particular, if the virtual private network (VPN) tunnel <b>114</b> is a single-tenant virtual private network (VPN) tunnel <b>520</b>, then the diameter authentication/authorization request (AAR) message assigns quality of service (QoS) rules defined in the application quality of service (QoS) request message to all application data routed over the virtual private network (VPN) tunnel <b>114</b>, as previously described in steps <b>11</b>-<b>13</b>. This assignment allows mapping to the application quality of service (QoS) request message.

Rather, if the virtual private network (VPN) tunnel <b>114</b> is a multi-tenant virtual private network (VPN) tunnel <b>500</b>, then the quality of service (QoS) server <b>100</b> assigns quality of service (QoS) rules defined in the application quality of service (QoS) request message to application data being routed for the requesting over-the-top (OTT) application, only. In particular, the quality of service (QoS) server <b>100</b> sends a diameter authentication/authorization request (AAR) message with appropriate quality of service (QoS) rules and appropriate tunnel packet identification information to a policy and charging rules function (PCRF) <b>104</b> on the client devices' <b>108</b> home mobile network operator (MNO). Tunnel packet identification information sent to the policy and charging rules function (PCRF) must enable the policy and charging rules function (PCRF) to identify which tunnel packets to assign the requested quality of service (QoS) designation.

As portrayed in step <b>22</b>, the policy and charging rules function (PCRF) <b>104</b> on the client devices' <b>108</b> home mobile network operator (MNO) receives quality of service (QoS) information and returns a diameter authentication/authorization answer (AAA) message to the quality of service (QoS) server <b>100</b>.

In step <b>23</b>, the quality of service (QoS) server <b>100</b> sends a quality of service (QoS) application response message with an appropriate status value to the over-the-top (OTT) application server <b>110</b>.

In accordance with the principles of the present invention, a quality of service (QoS) application response message preferably comprises: a message ID, an application identifier, and a status identifier.

A status identifier included in a status field of a quality of service (QoS) application response message may be any one or more of the following: a success status identifier (<b>100</b>), a quality of service (QoS) system failure status identifier (<b>200</b>) (indicating a default failure or unexpected failure with no available details), a failed validation of application identifier/access credentials status identifier (<b>201</b>), a failed validation of quality of service (QoS) profile ID status identifier (<b>202</b>), a quality of service (QoS) system failure reserved message status identifier (defined per quality of service (QoS) implementation and used to explain a unique system failure) (<b>203</b>-<b>299</b>), a PCRF unavailable status identifier (<b>300</b>), and/or an AAR/AAA message failure status identifier (<b>400</b>), wherein the entire contents of the AAA message is embedded in the status field.

Once quality of service (QoS) rules have been forwarded to the policy and charging rules function (PCRF) <b>104</b> on the client devices' <b>108</b> home mobile network operator (MNO), the over-the-top (OTT) application client <b>120</b> can proceed to transmit and consume data for service delivery purposes (i.e. the over-the-top (OTT) client <b>120</b> delivers a service as available to its' functionality and thereby consumes IP bandwidth as a result of service fulfillment). In particular, as depicted in steps <b>24</b><i>a </i>and <b>24</b><i>b </i>of <figref idref="DRAWINGS">FIG. 3</figref>, the over-the-top (OTT) application client <b>120</b> on the user equipment <b>108</b> either initiates or receives a request to begin service fulfillment.

As shown in step <b>25</b>, once a request for service fulfillment is received (or initiated) on the over-the-top (OTT) application server <b>110</b> (via a Gi/SGi interface <b>310</b>), the over-the-top (OTT) application server <b>110</b> attempts to establish a mutually authenticated (client <b>120</b> and server <b>110</b>) transport layer security (TLS)/secure sockets layer (SSL) connection with the quality of service (QoS) server <b>100</b> (following standard transport layer security (TLS)/secure sockets layer (SSL) procedures for mutual authentication).

As portrayed in step <b>26</b>, if the initial mutual authentication step is successful, the over-the-top (OTT) application server <b>110</b> sends an application quality of service (QoS) request message over the virtual private network (VPN) tunnel <b>114</b> to the quality of service (QoS) server <b>100</b>, to request that a desired level of quality of service (QoS) treatment be applied to application data routed by the over-the-top (OTT) application over the virtual private network (VPN) tunnel <b>114</b>.

As depicted in steps <b>27</b>-<b>33</b>, the quality of service (QoS) server <b>100</b> then performs application quality of service (QoS) request message validation on the received application quality of service (QoS) request message, identifies a home mobile network operator (MNO) for the requesting client user equipment (UE) <b>108</b>, sends appropriate quality of service (QoS) data to a home policy and charging rules function (PCRF) <b>104</b> based on the type of virtual private network (VPN) tunnel <b>114</b> routing application data, and subsequently forwards a quality of service (QoS) application response message to the over-the-top (OTT) application server <b>110</b>, as previously described in steps <b>17</b>-<b>23</b>.

In accordance with the principles of the present invention, once signaling or data services are terminated on the over-the-top (OTT) application client device <b>108</b>, the over-the-top (OTT) application server <b>110</b> informs the quality of service (QoS) server <b>100</b> of the service termination, to trigger reserved quality of service (QoS) values to be terminated on the client devices' <b>108</b> home mobile network operator (MNO).

In particular, as depicted in step <b>34</b> of <figref idref="DRAWINGS">FIG. 3</figref>, when the over-the-top (OTT) application server <b>110</b> detects a termination of signaling or service on the over-the-top (OTT) application client user equipment (UE) <b>108</b>, the over-the-top (OTT) application server <b>110</b> attempts to establish a mutually authenticated (client <b>120</b> and server <b>110</b>) TLS/SSL connection with the quality of service (QoS) server <b>100</b> (following standard TLS/SSL procedures for mutual authentication).

As portrayed in step <b>35</b>, if the initial mutual authentication step is successful, the over-the-top (OTT) application server <b>110</b> sends an application quality of service (QoS) termination message to the quality of service (QoS) server <b>100</b>.

In accordance with the principles of the present invention, an application quality of service (QoS) termination message preferably includes: a message ID (an identifier defined by, and unique to, a requesting over-the-top (OTT) application), an application identifier (as described in 3GPP series 29.214 specification), access credentials (e.g. a secret/password public key infrastructure (PKI) verification, etc.), a quality of service (QoS) application profile ID, a source framed IP address (an attribute-value part (AVP)) or framed IPv6 prefix (an attribute-value part (AVP), RFC 4005 [12]), a service uniform resource name (URN) (an attribute-value part (AVP), 3GPP 29.214), a reservation priority (TS 183.017 [15]) (a vendor is preferably set to european telecommunications standards institute (ETSI) (13019) [15]), and a subscription ID (RFC 4006 [14]), identifying a particular subscription, e.g., international mobile subscriber identity (IMSI), mobile station integrated services digital network (MSISDN), etc.

In response to an application quality of service (QoS) termination message, the quality of service (QoS) server <b>100</b> performs application quality of service (QoS) termination message validation, as portrayed in step <b>36</b>. During application quality of service (QoS) termination message validation, the quality of service (QoS) server <b>100</b> validates the application identifier and access credentials (e.g., a secret/password public key infrastructure (PKI) verification, etc.) received in the application quality of service (QoS) termination message against application profile data maintained in a local application information database <b>220</b>.

As depicted in step <b>37</b>, once application quality of service (QoS) termination message validation is complete, the quality of service (QoS) server <b>100</b> sends a diameter session termination request (STR) message to the policy and charging rules function (PCRF) <b>104</b> on the over-the-top (OTT) application client device's <b>108</b> home mobile network operator (MNO), to indicate that service/signaling has been terminated.

In steps <b>38</b> and <b>39</b>, the policy and charging rules function (PCRF) <b>104</b> responds to the quality of service (QoS) server <b>100</b> with a diameter session termination answer (STA) message, and the quality of service (QoS) server <b>100</b> subsequently sends an application quality of service (QoS) response message (including an appropriate status value) to the requesting over-the-top (OTT) application server <b>110</b>.

Similarly, the virtual private network (VPN) client <b>118</b> and/or server <b>112</b> sends an IPSec tunnel mapping table, containing appropriate tunnel termination information (tunneling information depicted in Table 1) to the quality of service (QoS) server <b>100</b>, once the virtual private network (VPN) tunnel <b>114</b> is terminated.

In particular, as depicted in steps <b>40</b><i>a</i>, <b>40</b><i>b</i>, and <b>40</b><i>c</i>, the virtual private network (VPN) client <b>118</b>/server <b>112</b> sends a VPN quality of service (QoS) termination message with appropriate tunneling information (tunneling information depicted in Table 1) to the quality of service (QoS) server <b>100</b> when the virtual private network (VPN) tunnel <b>114</b> is terminated. The virtual private network (VPN) client <b>118</b> sends a VPN quality of service (QoS) termination message to the quality of service (QoS) server <b>100</b> via a conventional Gi/SGi interface <b>310</b>.

In accordance with the principles of the present invention, a VPN quality of service (QoS) termination message preferably includes access credentials and a tunnel source and destination IP address, to enable the quality of service (QoS) server to identify which tunnel is being terminated and to determine if a pending quality of service (QoS) configuration in the wireless network need be removed as a result of the tunnel termination. A quality of service (QoS) termination message is typically preceded by a session termination. However, this may not always be the case.

In step <b>41</b>, the quality of service (QoS) server <b>100</b> receives the VPN quality of service (QoS) termination message and appropriately responds to the virtual private network (VPN) client <b>118</b>/server <b>112</b> with a VPN quality of service (QoS) response message.

Many commercial wireless networks provide quality of service (QoS) to their clients. The inventive solution is described herein via use of a specific long term evolution (LTE) network provider. However, the present invention may be applied to any wireless network that supports quality of service (QoS) treatment, including: a universal mobile telecommunications system (UMTS), long term evolution (LTE) technology, an evolved-universal mobile telecommunications system (E-UMTS), long term evolution (LTE) technology advanced, and Wi-Fi.

Inventive quality of service (QoS) logic may and should be extended to support other scenarios, such as scenarios described as “Application Function” logic in 3GPP series 29 specifications.

Use of this inventive technology causes certain packets associated with a virtual private network (VPN) connection to be identified via their security parameter index (SPI) value. Identification of this nature may reveal an associative characteristic of some virtual private network (VPN) packets. Implementers of the inventive technology may wish to determine if additional security, additional encryption, etc., is required to compensate for the reveal of the associative nature of packets.

The present invention has particular applicability to United States federal agencies, such as the Federal Emergency Management Agency (FEMA), and the Department of Homeland Security (DHS), etc., as well as to emergency first responders, large over-the-top (OTT) application providers (e.g., Google™, Apple™, etc.), and enhanced long term evolution (LTE) policy and charging rules function(s) (PCRF), from policy and charging rules function (PCRF) vendors.

While the invention has been described with reference to the exemplary embodiments thereof, those skilled in the art will be able to make various modifications to the described embodiments of the invention without departing from the true spirit and scope of the invention.