CN116192719A

CN116192719A - Method and system for traffic steering over multiple access networks based on dynamic policies

Info

Publication number: CN116192719A
Application number: CN202211691187.5A
Authority: CN
Inventors: 吉里什·钱德兰
Original assignee: Viasat Inc
Current assignee: Viasat Inc
Priority date: 2016-07-21
Filing date: 2017-07-14
Publication date: 2023-05-30
Also published as: IL290220A; KR20230080494A; HUE050501T2; JP7404433B2; EP3748915B1; KR102540823B1; DK3488560T3; CO2019000743A2; AU2017299496B2; IL290220B; ES2912565T3; ES2811355T3; SG11201900300YA; IL264196A; EP3748915A1; MY195660A; MX2019000904A; US10855599B2; NZ749856A; EP3488560B1

Abstract

Methods and systems for separate forward link and return link policies for network communications are disclosed. In some aspects, separate forward link and return link policies define how data is routed between a client execution unit and a provider execution unit over multiple access networks. In some aspects, the individual policies may be based on metrics collected by the client-side execution units and the provider-side execution units, which may be located at each end of one or more access networks.

Description

Method and system for traffic steering over multiple access networks based on dynamic policies

Technical Field

Embodiments relate generally to communication systems and, more particularly, to an improved method of routing communications across multiple access networks.

Background

Multiple access networks may be used to transfer data between a communication terminal and a destination accessible via the access networks. In view of the different characteristics these access networks may have, there is a need for improved methods and systems for managing communications with communication terminals through these access networks.

Disclosure of Invention

Methods and systems for providing dynamic policy updates to provider and client execution units that control forward and return link traffic (traffic) through multiple access networks, respectively, are disclosed. The policy update controls how network communications between a client communication terminal and a destination accessible via an access network are routed from its source to its destination.

As discussed below, a communication terminal may include a device that provides connectivity to multiple access networks that provide communication between the terminal and one or more destination networks. By dynamically routing data through multiple access networks using the techniques described herein, a number of benefits may be realized. For example, policies may be specific to individual users, as opposed to network policies that apply to all users. Furthermore, policies may be dynamically modified over a period of time based on, for example, user behavior. For example, in some embodiments, usage quotas may be set for individual users. The first policy may be valid when the user does not exceed the allocated quota, but a second policy may be allocated to the user that changes how to route the user-generated network message when the user usage exceeds the quota. Further, in some aspects, the access network itself may have a usage quota. Thus, when the usage of a particular access network exceeds a predetermined usage, the network routing policy may be updated such that fewer network messages are routed through the access network. Further, in some aspects, the client communication terminal may be mobile and thus move from one part of the access network to another, or from one access network to another. In order to maintain network service as the communication terminal moves, policies for the user and/or access terminal may be dynamically updated to accommodate the access terminal changing location. For example, as a user moves from an area covered by a first satellite beam to a second satellite beam, their routing policy may be updated to preferentially route their network messages through the second satellite beam.

In some aspects, policies may be applied to communication terminals within a geographic region. For example, some areas may implement a particular policy during peak demand periods, while access networks in other areas may implement different policies during the same peak demand periods. These peak demand policies may be different from the off-peak traffic policies within the access network.

In the disclosed methods and systems, a client execution unit is located at a client of an access network such that it is able to route data generated by one or more network devices through one or more available access networks and such that data received from the access networks may be appropriately transferred. The client execution unit performs such routing functions based on the return link policy information provided by the policy management unit, which is also discussed below.

The disclosed method and system may also utilize a provider side execution unit located on the other side of the access network. The policy management unit may be configured to generate individual forward link policy information to be applied by the provider side execution unit. In some cases, the return link policy information and the forward link policy information may cause each of the client-side execution unit and the provider-side execution unit to make different routing decisions for a single network session (e.g., a TCP connection, UDP datagram exchange between SSAPs/DSAPs, etc.), respectively. For example, in some aspects, forward link data for a particular network session may follow a first network path, while return link data for that same network session may follow a second, different network path.

In addition, the forward link and return link policies generated for the provider side execution units and the client side execution units may be dynamically updated. For example, the policy may be updated in response to one or more of: a change in the location of the client execution unit, a network condition in a change in one or more access networks available to the client communication terminal, an amount of data or network messages sent to and/or from the communication terminal, and other factors.

The policy management unit may also generate policies for the client-side enforcement unit and the provider-side enforcement unit based on various factors, including network conditions of one or more access networks. For example, delay, throughput, packet loss statistics, and other characteristics may vary between multiple access networks available to a client execution unit and its corresponding communication terminal. In some aspects, one or more metrics representative of these network conditions may be generated in the client-side execution units and/or the provider-side execution units based on their use of the respective access networks.

These characteristics may affect the efficiency of network communication through each access network. In some aspects, the policy management unit may determine that certain types of traffic (e.g., traffic that is sensitive to delay) are to be sent over a first access network having a link with a lower delay, while traffic that is less sensitive to delay is to be sent over a second access network having a link with a higher delay. For example, delay sensitive traffic may include Web browsing traffic, while delay insensitive traffic may include email and streaming traffic.

After the policy management unit generates a return link policy based on network conditions of the access networks available to the client execution unit and the corresponding one or more communication terminals, the policy management unit sends the updated return link policy to the client execution unit, which then routes traffic generated by the one or more communication terminals via the client execution unit based on the received return link policy over the available access networks. Similarly, after the policy management unit generates a forward link policy based on network conditions of the access networks available to the provider end execution unit, the policy management unit transmits the updated forward link policy to the provider end execution unit, which then routes the generated traffic to the one or more communication terminals via the provider end execution unit based on the received forward link policy.

Drawings

The present disclosure is described with reference to the accompanying drawings:

fig. 1 shows a simplified diagram of a first example of a communication system.

Fig. 2 is a simplified diagram of a second example of a communication system.

Fig. 3 is a simplified diagram of an example of the communication system of fig. 1, including a block diagram of an example client execution unit.

Fig. 4A is a simplified diagram of an example of the communication system of fig. 1, including a block diagram of an example core network.

Fig. 4B is a simplified diagram of an exemplary communication system including a block diagram of an exemplary policy management unit of a core network.

Fig. 5 is a diagram of a moving transport device. The device is shown moving between positions A, B, C and D.

Fig. 6 is a flow chart of a method for dynamically updating a transmission routing policy for an execution unit.

Fig. 7 is a flow chart of a method for dynamically updating a transmission routing policy for an execution unit.

Fig. 8 is a flow chart of a method for routing user data at an execution unit.

In the drawings, similar components and/or features may have the same reference numerals. Further, it is possible to distinguish various components of the same type by using a second reference numeral that distinguishes among the similar components after the reference numeral. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.

Detailed Description

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. However, it will be recognized by one of ordinary skill in the art that the present disclosure may be practiced without these specific details. In some instances, circuits, structures, and techniques have not been shown in detail in order not to obscure the disclosure.

Fig. 1 shows a simplified diagram of a first example of a communication system 100. Many other configurations are possible with more or fewer components than the communication system 100 of fig. 1. For example, although fig. 1 is an example of a mobile communication terminal discussed below, in some aspects, the methods and systems disclosed herein may be applied to fixed location communication terminals. More generally, the methods and systems described herein may be applied to systems including fixed location communication terminals and/or including mobile communication terminals.

In the illustrated embodiment, communication system 100 includes one or more transport devices (shown as aircraft 110) in communication with destination network 160 via a satellite access network (including satellite 105, gateway terminal 150, and network 152), an air-to-ground access network (including air-to-ground tower 154 and network 156), and core network 180.

Although a satellite-based access network and an air-to-ground access network are shown in fig. 1 as examples, the disclosed methods and systems contemplate other types of access networks, not limited to those shown in fig. 1. For example, the access network may include a drone, a balloon, a satellite network (LEO, MEO, or GEO), a terrestrial network, or any other type of network that provides communication between two points. Furthermore, although a single core network 180 is shown in fig. 1, the functionality of the core network 180 and the computing and network resources therein may be distributed across multiple physical locations.

In this example, the transportation device 110a may include a two-way communication terminal 112 to facilitate two-way communication with a satellite access network and an air-to-ground antenna access network. In the illustrated embodiment, the two-way communication terminal 112 includes two antenna systems 170a-b, two transceivers 172a-b, two modems 174a-b, a client execution unit 140, a Wireless Access Point (WAP) 178, and one or more mobile network devices 120a-n. Other contemplated embodiments may include three, four, five, six, seven, eight, nine, or ten antennas, transceivers, modems, as needed to facilitate communications over the available access networks or types of available access networks, in terms of providing a transportation device having more than two access networks at the same time or requiring special purpose hardware to communicate over the available access networks.

The core network 180 may also communicate with the transportation device 110a via a satellite access network and an air-to-ground access network. In some aspects, core network 180 may be in network communication with transport devices 110a-b via other types of networks, with satellite access networks and air-to-ground networks being shown as examples. More details of the core network 180 are discussed below with reference to fig. 4B. The core network 180 may communicate with, for example, a client execution unit 140 installed within the transportation device 110 a.

The two-way communication terminal 112 installed in the transportation device 110a may provide: the forward link signals are received from and the return link signals are transmitted to the satellite access network (via network 152, gateway terminal 150, and satellite 105) and/or the air-to-ground access network (via network 156 and air-to-ground tower 154), supporting bi-directional data communications between the moving network device 120 and destination network 160 within the transport equipment 110 a-b. The network device 120 in motion may include a mobile device (e.g., a smart phone, laptop, tablet, netbook, etc.), such as a Personal Electronic Device (PED) that is brought onto the transportation apparatus 110a-b by a passenger. As a further example, the moving network device 120 may include a passenger seat back system or other device on the transport apparatus 110 a-b. Network device 120 may communicate with client execution unit 140 via a communication link, which may be wired and/or wireless. The communication link may be part of a local area network, for example, a Wireless Local Area Network (WLAN) supported by WAP 178. One or more WAPs 178 may be distributed around the transport devices 110a-b and may provide traffic exchange and routing functions with the client execution units 140.

In operation, the client execution unit 140 may provide uplink data received from the moving network device 120 to either or both of the modems 174a-b to generate modulated uplink data (e.g., transmit Intermediate Frequency (IF) signals) for transmission to the respective transceivers 172a-b in accordance with a separate return link strategy (discussed in more detail below). The respective transceivers 172a-b may up-convert and then amplify the modulated uplink data to generate return link signals for transmission to the satellites 105 or the air-to-ground towers 154 via the respective antenna systems 170 a-b. Similarly, the respective transceivers 172a-b may receive forward link signals from 105 and/or the air-to-ground towers 154 via the respective antenna systems 170 a-b. The respective transceivers 172a-b may amplify and downconvert the forward link signals to generate modulated return link data (e.g., receive IF signals) for demodulation by the respective modems 174 a-b. Demodulated return link data from modems 174a-b may be provided to client execution unit 140 for routing to the moving network device 120. One or more of modems 174a-b may be integrated with client execution unit 140 or may be a separate component in some examples.

Within the core network 180 may be a policy management unit 182 and a provider side enforcement unit 184. Policy management unit 182 may manage policies that control data routing across multiple access networks (via client execution unit 140 and provider-side execution unit 184). The policies generated by policy management unit 182 may be separate from a particular client-side execution unit or provider-side execution unit. For example, a first policy may be generated for a client execution unit 140 within a transport device 110 and a second policy may be generated for a second client execution unit within another transport device. Further, the policies generated by policy management unit 182 may include a forward link policy and a separate return link policy. For example, policy information for a transport device 110a may include a first forward link policy and a first return link policy, while policy information for another transport device may include a second forward link policy different from the first forward link policy and a second return link policy different from the first return link policy. In addition, the first forward link policy and the second forward link policy may be different from the first return link policy and the second return link policy, respectively. The forward link policy may be performed by the provider side execution unit 184, while the return link policy may be performed by the client execution unit 140 installed within the respective transport device 110 a.

Furthermore, each policy discussed above may be dynamically updated. For example, policies may be updated as network conditions change and/or as communication terminals (e.g., two-way communication terminals 112 on transport devices 110 a-b) move over a geographic area. Both policy management unit 182 and provider side enforcement unit 184 are discussed in more detail below.

In the illustrated embodiment, the transport apparatus 110a is an aircraft. Alternatively, the transportation device 110a may not be an aircraft, such as a train, bus, cruise ship, or the like. As shown, destination network 160 may be any type of network and may include, for example, the internet, an IP network, an intranet, a Wide Area Network (WAN), a Local Area Network (LAN), a Virtual Private Network (VPN), a Virtual LAN (VLAN), a fiber optic network, a wired network, a Public Switched Telephone Network (PSTN), a Public Switched Data Network (PSDN), a public land mobile network, and/or any other type of network that supports communications described herein. Destination network 160 may include both wired and wireless connections and optical links.

The access networks discussed above may have different characteristics. For example, while satellite access networks may provide continuous access over a large geographic area, they have high capacity and are relatively inexpensive to operate, while air-to-ground access networks may provide lower latency network communications. Air-to-ground access networks may also not provide continuous access over a geographic area as large as satellite access networks.

Furthermore, the performance of multiple access networks may vary, not only based on the inherent characteristics of the technology on which the access networks depend, but also on the current condition of each access network. For example, if an aircraft communicates with satellites via a particular spot beam (e.g., using a particular carrier frequency, polarization, etc.), the capacity of the link may be affected by the number of other users of the spot beam service (including other aircraft and/or other transportation devices 110, mobile user terminals, fixed user terminals, etc.), weather (e.g., rain fade, etc., may cause packet loss and/or other effects), communication schemes (e.g., modulation and/or coding schemes, etc., may increase overhead of the communication), etc.

Fig. 2 is a simplified diagram of the second communication system 101. The communication system 101 includes one or more network devices 220a-n that communicate with the destination network 160 via a satellite access network (including satellite 105, gateway terminal 150, and network 152), a terrestrial access network (including terrestrial tower 230 and network 232), and a core network 180. In contrast to the communication system 100 discussed above with reference to fig. 1, the two-way communication terminal 212 communication system 101 includes two-way communication terminals 212 operating from a fixed location (e.g., a residence or business). Similar to fig. 1, the two-way communication terminal 212 includes a client execution unit 140 that can determine how to route network messages generated by respective network devices 220a-220n through one or more available access networks for transmission to the destination network 160. For example, client execution unit 140 may determine whether to route each network message generated by network devices 220a-220n through a satellite access network and/or a terrestrial access network. In the illustrated embodiment, the two-way communication terminal 212 communicates wirelessly with a ground tower 230. For example, the terrestrial access network may be a cellular network. In other embodiments, the ground access network may communicate with the two-way communication terminal 212 via a wired connection. Similar to the two-way communication terminal 112 of fig. 1, the two-way communication terminal 212 includes devices (transceivers 272a-b, modems 274a-b, and WAPs 278) for facilitating communication with a satellite access network and a terrestrial access network.

Also similar to the communication system 100 of fig. 1, the core network 180 is located between the destination network 160 and the terrestrial access network and the satellite access network, thereby routing network messages to one of the network devices 120a-n through multiple access networks. As in the case of fig. 1, the core network 180 includes a policy management unit 184 and a provider-side execution unit 182. As discussed above with reference to fig. 1, policy management unit 184 may be configured to generate individual return link policies for one or more of client execution unit 140a and/or network devices 220 a-n. Policy management unit 184 may also be configured to generate a separate forward link policy for defining or addressing network messages to each network device 120 a-n. Policy management unit 184 may then distribute these generated forward link and individual return link policies to the appropriate provider side execution units 182 and client side execution units 140, respectively. As described above, in at least some aspects, the forward link and return link policies may specify routing traffic for a particular network session or network service 120 through a first network path and a different second network path, respectively. For example, TCP acknowledgements may be communicated over the air-to-ground access network while the rest of the TCP session is conducted over the satellite access network.

Fig. 3 is a simplified diagram of an example of the communication system 100 of fig. 1, including a detailed block diagram of the client execution unit 140. The client execution unit 140 of the communication system 101 of fig. 2 may be the same as shown in fig. 3. Many other configurations of client execution unit 140 are possible with more or fewer components. Furthermore, the functionality described herein may be distributed among the components in a different manner than described herein. Fig. 3 omits the core network 180, gateway terminal 150, and

networks

152, 156, as well as some elements of the bi-directional communication terminal 112, to avoid overcomplicating the drawing.

In keeping with fig. 1 and 2, the client execution unit 140 communicates with the destination network 160 via a satellite access network and an air-to-ground access network (or other suitable access networks as described above) and other components of the two-way communication terminal 112 (not shown in fig. 3). The client execution unit 140 is also in communication with the network device 120. In fig. 2 and the following discussion, some components of the two-way communication terminal 112 discussed above with reference to fig. 1 (e.g., the antenna system 170, transceiver 172, modem 174, WAP 178) are omitted to avoid overcomplicating the drawing.

The illustrated aspects of client execution unit 140 include an electronic hardware processor 305 and a network interface 310. The processor 305 may communicate with the network interface 310 via an electronic bus (not shown) within the client execution unit 140. The processor may communicate with the network interface 310 to send and/or receive packets over a network (e.g., a network providing connectivity to one or more network devices 120 a-n). In some aspects, such connectivity may be provided by the wireless access point 178 and/or modem 174 discussed above with reference to fig. 1.

Client execution unit 140 also includes policy executor 315 and traffic classifier 320. Policy enforcer 315 and traffic classifier 320 may be part of volatile or stable memory, such as virtual or physical memory space accessible to processor 305. Policy executor 315 and traffic classifier 320 may include binary data defining instructions that configure processor 305 to perform various functions. For example, policy enforcer 315 may include instructions that configure processor 320 to enforce policies that define how data generated by one or more of network devices 120a-n is transmitted to destination network 160 over multiple access networks. For example, policy enforcer 315 may determine whether to route particular data generated by network devices 120a-n to destination network 160 via a satellite access network or an air-to-ground access network (or other access network as described above) based on applicable network policies. In some aspects, policy enforcer 315 may make these routing decisions based on policies and also based on the characteristics of the particular message being routed. For example, in some aspects, the type of message may determine how the message is routed. In some aspects, for example, delay-sensitive traffic may be routed through a null-to-ground network while delay-insensitive traffic is routed through a satellite access network. In some aspects, the policy enforcer may make routing decisions based on the size of the network message. For example, in some aspects, messages above a threshold length may be routed through a first access network, while shorter messages below a threshold length may be routed through a second access network.

Traffic classifier 320 may include instructions that configure processor 305 to classify messages received from network devices 120 a-n. For example, traffic classifier 320 may classify a message based on one or more of a destination IP address, a Service Access Point (SAP), an application protocol signature, etc., to determine whether the message is part of an email, web browsing, streaming media, or file transfer network session.

In some implementations, how traffic is classified may involve differences between multiple access networks being managed. For example, in some aspects, if the first access network has a higher delay than the second access network, the traffic classifier 320 may determine whether the network traffic is delay sensitive or delay insensitive. This information may then be used, at least in part, by policy enforcer 315 to route network traffic through the first access network or the second access network. In some aspects, the first access network may have a different capacity or throughput than the second access network. In these aspects, traffic classifier 320 may determine the amount of data that a particular network traffic (e.g., network packets or data flows as part of a network session) is attempting to transmit. The policy enforcer may then route the particular network traffic through the first access network or the second access network based on the amount of data. For example, network sessions having a relatively large amount of network data (i.e., an amount of data above a threshold) to be transmitted may be routed through a higher capacity access network, while network sessions having a relatively smaller amount of data (i.e., an amount of data below a threshold) to be transmitted may be routed through a lower capacity access network.

In some aspects, the classified traffic may associate one or more network messages with a particular network session. A network session may uniquely identify a data exchange between two endpoints. For example, in some aspects, a network session may correspond to a single Transmission Control Protocol (TCP) connection (a combination of source/destination IP address and source/destination service access point). In some aspects, the network session may correspond to a unique combination of user datagram service access points and a combination of source/remote IP addresses. For example, the data comprising the source IP address of IP1, the destination IP address of IP2, the source UDP Service Access Point (SAP) of SAP1, and the destination UDP SAP of SAP2 may be the same network session as the message indicating the source IP address of IP2, the destination IP address of IP1, the source UDP SAP of SAP2, and the destination UDP SAP of SAP 1.

Instructions in one or more of policy executor 315 and traffic classifier 320 may configure processor 305 to read data from policy database 325. For example, in some aspects, the processor 305 may read data from the policy database 325 to determine to apply a traffic policy to network traffic generated by one or more network devices 120. Although fig. 3 illustrates client execution unit 140 as one physical device, in some implementations, the functions discussed above and below in connection with client execution unit 140 may be implemented on multiple physical devices within transport apparatus 110. For example, in some aspects, the functionality associated with each of policy executor 315 and traffic manager 320 may each be provided on separate physical devices having their own dedicated electronic hardware processors, memory, and network interfaces. Additionally, in some implementations, policy database 325 may also be implemented on one or more devices separate from one or more of policy executor 315 and traffic classifier 320. How the functionality discussed above and below is partitioned on one or more physical hardware devices does not substantially affect the methods and systems disclosed herein.

Fig. 4A shows a simplified diagram of an example of the communication system 100 of fig. 1, including a block diagram of a core network 180. The core network 180 of the communication system 100 of fig. 2 may be the same as that shown in fig. 4A. Many other configurations of the core network 180 are possible with more or fewer components. Furthermore, the functionality described herein may be distributed among the components in a different manner than described herein.

Within the core network 180 is a provider-side execution unit 184 that communicates with the transport apparatus 110 and one or more network devices therein (shown as network devices 120a-b in fig. 1). In some aspects, the core network 180 communicates with the transportation device 110a via a satellite access network and/or an air-to-ground access network 175. The core network 180 is also in communication with the destination network 160. Provider side execution unit 184 receives communications from destination network 160 that are destined for transport apparatus 110 and/or network devices 120a-n within transport apparatus 110. In some aspects, provider-side execution unit 184 may communicate with satellite access networks and/or air-to-ground access networks via network 160, or may communicate with these access networks using other networks and/or technologies.

The illustrated aspects of provider side execution unit 184 include an electronic hardware processor 410 and a network interface 415. The processor 410 may communicate with the network interface 415 via an electronic bus (not shown) within the provider side execution unit 405. The processor 410 may communicate with the network interface 415 to send and/or receive packets over a network (e.g., the destination network 160).

Provider side execution unit 184 also includes policy executor 420, policy manager 425, and traffic classifier 430. Policy enforcer 420, policy manager 425, and traffic classifier 430 may be part of volatile or stable memory, such as virtual or physical memory space accessible to processor 410. Policy executor 420, policy manager 425, and traffic classifier 430 may include binary data defining instructions that configure processor 410 to perform various functions. For example, policy enforcer 420 may include instructions that will cause processor 410 to enforce a policy that defines how forward link data to one or more network devices 120a-n residing on transport apparatus 110 is to be sent to transport apparatus 110. For example, policy enforcer 420 may determine whether to route particular data destined for network devices 120a-n to transportation equipment 110 via a satellite access network or an air-to-ground access network based on applicable network policies. These decisions by provider-side enforcement unit 184 may enforce forward link policies between destination network 160 and transport device 110 because the policies are enforced for traffic flowing from destination network 160 to network apparatuses 120a-n and/or transport device 110. In some aspects, policy enforcer 420 may make these routing decisions based on policies and also based on the characteristics of the particular message being routed. For example, in some aspects, traffic classifier 430 may classify messages received by provider side execution unit 184 to determine the type of each message. The type may determine how to route the message. In some aspects, for example, the type of delay-sensitive traffic may be routed through one access network while less sensitive traffic is routed through a second access network. In some aspects, whether traffic is delay sensitive may be based on one or more of: whether the traffic utilizes User Database Protocol (UDP) (UDP protocol traffic tends to be more delay sensitive than TCP traffic), whether the traffic is inherently continuous (delay sensitive traffic tends to exhibit continuity), and the amount of data being sent (low data amounts tend to be used with delay sensitive traffic).

Instructions in one or more of policy executor 420, policy manager 425, and traffic classifier 430 may configure processor 410 to read data from policy database 435. For example, in some aspects, the processor 410 may read data from the policy database 410 to determine a traffic policy for a network traffic application to one or more network devices 120 residing within the transportation equipment 110. While fig. 4A illustrates provider side execution unit 184 as one physical device, those skilled in the art will appreciate that in some aspects, the functions discussed above and below in connection with provider side execution unit 184 may be implemented on multiple physical devices in some implementations. For example, in some aspects, the functionality associated with each of policy executor 420, policy manager 425, and traffic classifier 430 may each be provided on separate physical devices having their own dedicated electronic hardware processors, memory, and network interfaces. Additionally, in some implementations, policy database 435 may also be implemented on one or more devices separate from one or more of policy executor 420, policy manager 425, and traffic classifier 430. How the functionality discussed above and below is partitioned on one or more physical hardware devices does not substantially affect the methods and systems disclosed herein.

Fig. 4B is a simplified diagram of an example of the communication system 100 of fig. 1, including a block diagram of a policy management unit 182 of the core network 180. The policy management unit 182 of the core network 180 of fig. 2 may be the same as that shown in fig. 4B. Many other configurations of the core network 180 are possible with more or fewer components. Furthermore, the functionality described herein may be distributed among the components in a different manner than described herein.

Policy management unit 182 within core network 180 communicates with one or more network devices 120a-n via a satellite access network and an air-to-ground access network or other suitable access network and other components (not shown in fig. 4B) of bi-directional communication terminal 112. In particular, fig. 4B shows policy management unit 182 in communication with client execution unit 140 located within a transport device (e.g., transport device 110). Policy management unit 182 is also in communication with a provider side enforcement unit 184.

The illustrated aspects of policy management unit 182 include an electronic hardware processor 455 and a network interface 460. The processor 455 may communicate with the network interface 460 via an electronic bus (not shown) within the policy management unit 182. The processor 455 may communicate with a network interface 460 to send and/or receive packets over a network (e.g., any network providing connectivity to the client execution unit 140 and one or more network devices 120 a-n).

Policy management unit 182 further includes a policy generator 465 and an access network state manager 470. Policy generator 465 and access network state manager 470 may be part of volatile or stable memory, such as virtual or physical memory space accessible to processor 455. Policy generator 465 and access network state manager 470 may comprise binary data defining instructions that configure processor 405 to perform various functions. For example, policy generator 465 may include instructions that configure processor 455 to define how to send return link data generated by one or more of network devices 120a-n to destination network 160 by controlling how client execution unit 140 routes policies from devices 120 a-n. For example, policy generator 465 may configure processor 455 to determine whether client execution unit 140 should route data to destination network 160 via a satellite access network or an air-to-ground access network based on status information of one or more access networks.

Policy generator 465 may also configure processor 455 to generate a particular policy for provider side execution unit 405. This policy may be different from the policy provided to the client execution unit 405. The policy of provider side execution unit 184 may control how forward link data is routed from destination network 160 to network devices 120a-120n. In particular, the policy of provider side execution unit 184 may define how data destined for or addressed to network devices 120a-n is routed via the first access network or the second access network, as described above with reference to FIG. 1.

Access network state manager 470 may include instructions that configure processor 455 to receive access network state information from client execution unit 140 and/or provider end execution unit 184. For example, the access network state manager 470 may configure the processor 455 to receive a state regarding a satellite access network and/or an air-to-ground access network. The status information may include one or more of the following: congestion information, dropped packet information, delay information, throughput information, or other information characterizing the performance of the access network between client execution unit 140 and destination network 160.

Although fig. 4B illustrates policy management unit 182 as one physical device, those skilled in the art will appreciate that in some aspects, the functions discussed above and below in connection with policy management unit 182 may be implemented on multiple physical devices in some implementations. For example, in some aspects, the functionality associated with each of policy generator 245 and access network state manager 470 may each be provided on separate physical devices having their own dedicated electronic hardware processors, memory, and network interfaces. How the functionality discussed above and below is partitioned on one or more physical hardware devices does not substantially affect the methods and systems disclosed herein.

Fig. 5 is a diagram of the moving transport apparatus 110. The device 110 is shown moving between positions A, B, C and D. As the transportation device 110 moves between the illustrated locations, different access networks may become available to them, and other access networks may become unavailable to them. For example, at location a, device 110 communicates via a satellite access network including satellite 105a or an air-to-ground access network including air-to-ground tower 154 a. At location B, device 110 communicates via an air-to-ground access network including air-to-ground towers 154B or a satellite access network including satellite 105 a. At location C, device 110 communicates via an air-to-ground access network including air-to-ground towers 154b or a satellite access network including satellites 105 b. At location D, device 110 communicates via an air-to-ground access network including air-to-ground towers 154b or a satellite access network including satellites 105 b.

FIG. 5 also shows that the device 110 and the corresponding client execution units 140 contained within the device 110 receive dynamic policy updates at each of the locations A-D. The dynamic policy update received by the transport device 110 at location a may indicate how the client execution unit 140 should route data between the multiple access networks available for communication. For example, as discussed below with reference to fig. 6, policy management unit 182 may generate a policy based on metrics related to network performance of the first access network and the second access network. In some aspects, these metrics may be collected by a client execution unit 140 residing on the transport device 110 and sent to a policy management unit 180. Policy management unit 182 may then generate a policy update based at least in part on the metrics provided thereto. When a policy update is provided to the transportation device 110 of location a, the policy management unit 182 may also provide a corresponding policy update to the provider side execution unit 184. Policy updates to the client execution units and the provider execution units ensure that the forward link (via provider execution unit 184) and the return link (via client execution unit 140) work together to consistently route traffic between client execution unit 140 and destination network 160 (not shown). For example, in some aspects, network messages included in a single network session may be routed through a common access network regardless of whether the traffic is forward link traffic or return link traffic. In some other aspects, network messages included in a single network session may be routed through different access networks, depending on whether the network message is part of forward link traffic or reverse link traffic.

The policy updates received by client execution unit 140 at location B may indicate how client execution unit 140 should route data between satellite access networks provided via satellite 105a or air-to-ground access networks provided via air-to-ground towers 154B. Policy updates received by client execution unit 140 on transport device 110 at location B may also be based on one or more characteristics of the first access network and the third access network, such as their relative congestion, delay, throughput, and other characteristics. As discussed above with reference to the policy update of location a, when the policy update is provided to the client execution unit 140 within the transport device of location B, the policy management unit 182 may also provide the corresponding policy update to the provider end execution unit 184.

The policy update received by the client execution unit 140 within the transport device 110 at location C may indicate how the client execution unit 140 should route data between the fourth access network provided via satellite 105b and the third access network provided via air-to-ground tower 154 b. Policy updates received by the client execution unit 140 within the transportation device 110 at location C may also be based on one or more characteristics of the third access network and the fourth access network, such as their relative congestion, delay, throughput, and other characteristics. As discussed above with reference to policy updates for locations a and B, when a policy update is provided to client execution unit 140 within the transport facility of location C, policy management unit 182 may also provide a corresponding policy update to provider end execution unit 184.

The policy update received by the client execution unit 140 within the transport device 110 at location D may indicate how the client execution unit 140 should route data between the fourth access network provided via satellite 105b and the third access network provided via air-to-ground tower 154 b. Policy updates received by client execution unit 140 within transport device 110 at location D may also be based on one or more characteristics of the third access network and the fourth access network, such as their relative congestion, delay, throughput, and other characteristics.

Although in the illustrated example, client execution unit 140 within transport device 110a has the same available access network at location C and location D, policy updates provided at location D may be based on metrics that characterize the network performance of the third access network and the fourth access network that are different from metrics collected at location C, which also characterize the network performance of the third access network and the fourth access network. For example, in some aspects, the performance of the third access network and/or the fourth access network may change as the client execution unit 140 within the transport device 110 moves from location C to location D. Such variations may reflect the relative differences between metrics collected at or near each location. Thus, the policy management unit 180 may be configured to generate a policy of the client performing unit 140 based at least on a changed condition of the third access network and/or the fourth access network at location D with respect to location C, the policy being different at location D than at location C. As discussed above with reference to policy updates, when a client execution unit 140 within a transport device 110 is located at a location a-C, the policy management unit 182 may also provide a corresponding policy update to the provider end execution unit 184 when the policy update is provided to the client execution unit 140 within a transport device at location D. The corresponding policy updates may ensure that the individual forward link policies and individual return link policies for a particular client execution unit 140 within the transportation device are consistent such that messages included in a particular network session using the particular client execution unit 140 within the transportation device are routed through the same access network. However, in some aspects, the policy updates may define different individual forward link and individual reverse link policies such that forward link network messages are routed through different network paths than reverse link network messages.

Fig. 6 is a flow chart of a method of dynamically updating individual routing policies for an execution unit. In some aspects, the routing policy may control how one or more network messages are routed through one or more access networks. In some aspects, the process 600 may be performed within the

communication system

100, 101 shown in fig. 1 and 2. For example, in some aspects, the electronic hardware processor 455 of the policy management unit 182 may be configured (e.g., as represented by the policy generator 465 and the access network state manager 470) by instructions stored in memory to perform one or more of the functions described below with reference to process 600.

In block 605, one or more first metrics relating to network transmissions by a first execution unit over a first access network and a second access network are obtained. In some aspects, the first metric may be received by the policy management unit 182 shown in fig. 4B from the first execution unit. In some aspects, a first portion of the first metric may relate to network transmission and/or reception by the first execution unit over the first access network, and a second portion of the first metric may relate to network transmission and/or reception by the first execution unit over the second access network. The metrics may include a measure of activity through the first access network or the second access network, such as one or more of a congestion level measurement, a delay measurement, a cost measurement, a capacity measurement, a dropped packet measurement, or a throughput measurement. In some aspects, one or more of the functions discussed above with reference to block 605 may be performed by processor 455 configured by instructions stored in access network state manager 470 as discussed above with reference to fig. 4B.

In block 610, one or more second metrics relating to network transmissions by a second execution unit over the first access network and the second access network are received. In some aspects, policy management unit 182 may also receive a second metric. The first portion of the second metric may relate to network transmissions of the second execution unit over the first access network, and the second portion of the second metric may relate to network transmissions of the second execution unit over the second access network. The second metric may include a measurement of activity through the first access network or the second access network, such as one or more of a congestion level measurement, a delay measurement, a cost measurement, a capacity measurement, a dropped packet measurement, or a throughput measurement. In some aspects, one or more of the functions discussed above with reference to block 610 may be performed by processor 455 configured by instructions stored in access network state manager 470 as discussed above with reference to fig. 4B.

In some aspects, the first execution unit and the second execution unit discussed above may be the client execution unit 140 and the provider-side execution unit 184.

At block 615, individual network routing policy information is determined for the first execution unit based on the first metric and the second metric. The network routing policy determined in block 615 is a policy that is separate from the first execution unit. In some aspects, the individual policies are policies that have been customized based on one or more attributes of the first execution unit. For example, in some aspects, portions of the first metric and the second metric associated with the first access network may be aggregated or summarized to generate one or more metrics characterizing performance of the first access network based on at least data from the first execution unit and the second execution unit. Similarly, in some aspects, portions of the first metric and the second metric associated with the second access network may be aggregated or summarized to produce one or more metrics that characterize performance of the second access network.

Metrics characterizing the first access network and metrics characterizing the second access network may then be evaluated to determine a network routing policy. For example, in some aspects, if the determined metric indicates that the first access network provides reduced latency relative to the second access network, the network routing policy may be defined to transmit a greater percentage of network data through the first access network than the second access network. Conversely, in this exemplary embodiment, if the determined metric indicates that the first access network provides increased delay relative to the second access network, block 615 may generate or determine a network routing policy that transmits a greater percentage of network data through the second access network than the first access network.

In some aspects, a network routing policy may be generated to send delay-sensitive network messages over an access network that provides lower delays and/or more predictable delays (e.g., by delay variance or delay standard deviation measurements). The execution unit may be configured to characterize one or more network messages generated by the communication terminal as delay-sensitive or delay-insensitive based on one or more of an application type, a source or destination IP address, a source or destination serving access point, or other characteristics of the network messages. In some aspects, one or more of the functions discussed above with reference to block 615 may be performed by policy generator 465, as discussed above with reference to fig. 4B.

In some aspects of block 615, a network routing policy may be generated to define the network routing policy for the network message based on a user or subscriber associated with the network message. For example, in some aspects, the policy management unit may generate the transmission policy based on network usage of the first access network and the second access network by the subscriber during a previous period of time.

In some aspects of block 615, a network routing policy may be generated based on aggregate usage of the plurality of execution units during the previous time period. The plurality of execution units is not necessarily all of the execution units within the system 100 of FIG. 1, but may include groups of execution units. For example, the plurality of execution units may be comprised of execution units residing in a particular group of transportation devices, but not other transportation devices within the system 100.

For example, in some aspects, the network routing policy may be based on aggregate usage from multiple execution units within a particular geographic area. For example, a first client execution unit may enter a first geographic region, generate a first set of network performance measurements, then move out of the first geographic region, and generate a second set of network performance measurements. The second client execution unit may enter the first geographic region, generate a third set of network performance measurements, and then move out of the first geographic region. The second client execution unit may then generate a fourth set of network performance measurements. Some aspects may aggregate the first set of performance measurements and the third set of performance measurements to determine an aggregate characterization of the first region, but not include the second set of performance measurements and the fourth set of performance measurements in the characterization.

In some aspects of block 615, a network routing policy for the plurality of execution units is determined. For example, in some aspects, a network routing policy for executing a group of elements may be determined. In some aspects, each execution unit is included in a group based on a type of communication terminal associated with the execution unit. For example, in some aspects, execution units associated with fixed location communication terminals may be included in one group, while execution units associated with mobile communication terminals (e.g., aircraft, buses, trains, etc.) may be associated with a second group. In these aspects, execution units in the same group may use the same network policy, while execution units in different groups use different network policies. In some aspects, a portion of the transmission policy for each execution unit in the group is generated in common, while a second portion of the transmission policy for each execution unit in the group may be different between members of the group.

In some aspects of block 615, a network routing policy is generated to define how the execution unit should route the received network message based on the time at which the data of the received network message was received. For example, the network routing policy may define that transmissions are made using a first access network during a first time period and a second access network during a second time period.

In some aspects, a network routing policy is generated to define that the execution unit routes the received network message based on a type of device that generated the received network message. For example, in some aspects, the network routing policy may indicate that the execution unit should use the first access network for a laptop and the second access network for a cellular phone and a tablet.

In some aspects of block 615, a network routing policy for one or more of the client-side execution unit and the provider-side execution unit may be determined based on the first metric and the second metric. The provider end execution unit network routing policy may enforce a forward link policy of network traffic destined for the client execution unit (and/or network devices residing on the same transport equipment as the client execution unit). The client side execution unit network routing policy may enforce a separate return link policy for network traffic (indirectly) destined for the provider side execution unit. For example, traffic may be destined for one or more devices residing within destination network 160, but may need to flow through provider-side execution units to reach its destination. The provider side execution unit network routing policy and/or the individual client side execution unit network routing policy may provide consistent routing of network sessions between the client side execution unit and the provider side execution unit. For example, if the client-side execution unit routes a particular session through the first access network, the provider-side execution unit also routes the session through the first access network. In some aspects, the generated network policy of the provider end execution unit may route data of the particular network session through a different access network than the corresponding client end execution unit.

In block 620, the determined network routing policy information is sent to the first execution unit. In some aspects, the first execution unit may then apply a network transmission routing policy to determine whether traffic it receives should be routed through the first access network or the second access network. In some aspects, one or more of the functions discussed above with reference to block 620 may be performed by processor 455 configured by instructions stored in policy generator 465, as discussed above with reference to fig. 4B.

In some aspects, the process 600 includes determining one or more access networks available to the first execution unit during a particular time period. For example, as shown in fig. 5, the transport device 110 may be moved over a geographic area. As the transportation device moves, some of the access networks previously accessible may become inaccessible to those devices; while other access networks that were previously inaccessible may become accessible. Thus, in some aspects, an apparatus (e.g., policy management unit 450) executing process 600 may be configured to dynamically determine which access networks are accessible to client execution unit 140 when determining a network routing policy for the client execution unit. This information may be considered along with the first metric and/or the second metric described above to determine how a particular execution unit in a particular geographic region should route data to an available access network.

Furthermore, in some aspects, a change to the set of available access networks for the client execution unit may result in execution of process 600. For example, as the transport device moves, one or more access networks may become unavailable to the respective client execution units and/or one or more additional access networks may become available to the client execution units. Process 600 may be performed in response to one or more of these changes. Similarly, process 600 may be performed in response to a change in one or more aspects of the performance of one or more access networks. For example, if one or more available access networks are offline, or alternatively experience a reduced or increased amount of network congestion, process 600 may be performed to adjust one or more of the individual forward link policies and/or individual return link policies of the client execution unit such that the routing of the individual forward link data or the individual return link data is appropriate for a given network condition of the available access networks.

To determine which access networks are available, in some aspects, policy management unit 182 may receive information from a particular execution unit indicating the accessibility of the access network to that particular execution unit. For example, in some aspects, the enforcement unit may send status information to the policy management unit 182, e.g., over the network, indicating which access networks are currently available to it. In some aspects, policy management unit 182 may read a data store (e.g., database) that provides an indication of accessible networks based on the geographic location of the communication terminal containing the execution unit. Thus, in some aspects, policy management unit 182 may generate a network routing policy based at least in part on the geographic location of the corresponding communication terminal and/or a data store that maps geographic locations to accessible access networks. Thus, the system shown in FIG. 1 may dynamically update the transmission policy of one or more client execution units as the corresponding communication terminal containing the execution units moves across a geographic area through execution of process 600. The policy updates may vary not only with the physical location of the transportation device, and thus with the execution units contained therein, but also based on the condition of one or more networks accessible to the execution units at the physical location. These conditions may be based on actual operating experience of the particular execution unit and the one or more networks.

Fig. 7 is a flow chart of a method of dynamically updating individual routing policies for an execution unit. In some aspects, process 700 may be performed within the communication system shown in fig. 1-4. In some aspects, the electronic hardware processor 305 of the client execution unit 140 may perform one or more of the functions discussed below with reference to process 700. For example, the electronic hardware processor 305 may be configured by instructions in one or more of the policy executor 315 and/or the traffic classifier 320 to perform the functions described below with reference to process 700.

In some other aspects, process 700 may be performed by electronic hardware processor 410 of provider side execution unit 184. For example, the electronic hardware processor 410 may be configured by instructions in one or more of the policy executor 420, the policy manager 425, and/or the traffic classifier 430 to perform the functions described below with reference to the process 700.

Since process 700 may be implemented in various aspects by a client-side execution unit or a provider-side execution unit, process 700 may be used to implement a forward link-only policy or a return link-only policy, and is commonly referred to as a "transmission routing policy" in process 700 of fig. 7.

In block 708, individual transmission routing policies are managed based on the received policy information. The received policy information is specific to the execution unit. For example, the received policy information may include an identifier that associates the policy information with the execution unit. Some aspects of process 700 include determining whether an identifier included in the policy information identifies an execution unit. If the identifier is not found, the execution unit may not process the policy information further. For example, in this case, blocks below block 708 in fig. 7 may not be performed.

In some aspects, the received policy information includes individual return link policies to be dynamically enforced by the client execution unit. In some aspects, the received policy information defines individual forward link policies to be dynamically enforced by the provider-side execution units. In some aspects, process 700 may include one or more of the following: the individual return link policies are dynamically enforced by the client-side execution unit and the individual return link policies are dynamically enforced by the provider-side execution unit. In some aspects, the return link policy and the forward link policy may provide inconsistent routing of network messages communicated with two network devices sharing the same communication terminal. For example, in some aspects, a first network message sent by a first network device may utilize a network path that includes a first access network (rather than a second access network), while a second network message sent by a second network device may utilize a network path that includes a second access network (rather than the first access network). In other aspects, both the first network message and the second network message may use the same network path.

In some aspects, if the execution unit is a client execution unit, the received policy defines a separate return link policy because it controls how data generated by one or more network devices is routed through one or more access networks.

In some aspects, if the execution unit is a provider-side execution unit, the received policy defines a forward link policy because it controls how data received from destination network 160 and destined for or addressed to a transport apparatus (e.g., transport apparatus 110) or network devices within a transport apparatus (e.g., one or more of network devices 120 a-n) is routed through one or more access devices to reach the destination device.

In some aspects, the received policy information is sent only to the execution unit by another device (e.g., a device within the core network 180). In some aspects, the second device (e.g., policy management unit 182) may generate policy information specifically for a particular execution unit. For example, policy information may be generated based on the current or expected location of the execution unit and then sent to the execution unit by the second device directly or indirectly. In some aspects, the received individual policy information may be specifically generated based on access networks available to the execution unit at a particular time or at a particular location of the execution unit.

The individual transmission routing policies may define whether messages received by the execution unit (e.g., messages sent by network devices 120a-n or to network devices 120 a-n) are sent by the execution unit over the first access network or the second access network. In some aspects, the first access network and/or the second access network may have different characteristics. For example, in some aspects, the first access network and the second access network may have different congestion levels, delays, throughput, or other different network performance.

In block 716, the execution unit receives a first network message from a network service. The network service from which the first network message is received may be any device capable of providing a message for transmission over the network. The network device may be any type of device, such as an end user device, an appliance, or the like. If the execution unit is a client execution unit, the device from which the first network message is received may be a network device used by the passenger on the transportation device, such as one of the network services 120a-n shown in FIG. 1, or one of the network devices 220a-n shown in FIG. 2. This may include any of a cell phone, tablet, laptop, or other computing device. If the execution unit is a provider-side execution unit, the network message may be sent by any device having network connectivity to the destination network 160. For example, the first network message may be sent by a network server or streaming server to send data to passengers on a transportation device (e.g., device 110).

The received message is for transmission via the first access network and the second access network to a destination accessible to the execution unit. For example, if the execution unit is a client execution unit, the received message may include a destination address of a device residing within or accessible through destination network 160 of fig. 1-2. There are multiple routing paths available from the client execution unit to the destination network. In some aspects, the client execution unit may maintain or access routing information (e.g., an internet protocol routing table) indicating destination addresses at which received messages may be accessed via the first routing path and the second routing path. For example, in embodiments utilizing Internet Protocol (IP) routing, the destination IP address included in the IP header of the received message may be accessed via multiple routes, such as those utilizing the satellite access network or the air-to-ground access network of fig. 1.

If the execution unit is a provider-side execution unit, the message is addressed to a destination device accessible via the first access network and the second access network. For example, a device on network 160 may send a first network message to a network device that may be accessed by provider side execution unit 182 via a plurality of access networks. As described above, in some aspects, such accessibility may be based on the internet protocol address of the destination device and an IP routing table maintained by or accessible to the provider end execution unit.

In block 720, the execution unit sends a first network message via at least one of the first access network and the second access network. In some aspects, the execution unit determines whether to send the first network message via the first access network or the second access network based on the received policy information. In some embodiments, the received policy information may indicate whether the first access network or the second access network is preferred for the destination address of the first network message.

In some aspects, the execution unit may classify the first network message, and the routing decision may be based on such classification. Classification may be performed based on one or more portions of the network message. For example, as shown in fig. 3, traffic classifier 320 may analyze portions of the first network message to determine whether the first network message is email data, streaming media, web browsing data, file transfer data, or other types of data. Based on this classification, the transmission policy may indicate whether the first network message should be routed through the first access network or the second access network.

In some other aspects, the received policy information may define a routing rule that, when executed, determines whether to send the first network message over the first access network or the second access network. For example, in some aspects, the received policy information may define a routing rule that indicates that streaming media data is sent over the first access network at the same time as email data is sent over the second access network. In some aspects, the rules may be evaluated in a defined order such that some rules defined by the received policy information are prioritized over other rules defined by the received policy information.

In some aspects, the received policy information may define that network messages generated by a first type of device (e.g., a laptop) are sent over a first access network, and network messages generated by a second type of device (e.g., a cell phone or tablet) are sent over a second access network.

In block 726, the execution unit receives updated policy information that is also execution unit specific. The updated policy information may be based on the transmission of the execution unit through the first access network and/or the second access network.

In block 728, the execution unit updates the individual transmission routing policies based on the received updated policy information. In some aspects, updating the individual transmission routing policies may include overwriting or integrating the transmission policies of block 708 with the received updated policy information received in block 726.

In block 730, the execution unit receives a second network message. The second network message is for delivery to the destination. For example, in the case of a client execution unit, the second network message may include a destination address (e.g., an IP address) that may be accessed via destination network 160, and may be routed through either access network. In the case of a provider side execution unit, the network message may be destined for the network service provider side execution unit 184 via any of the access networks.

In block 732, the execution unit sends a second network message over the first access network or the second access network based on the updated individual transmission routing policies. As discussed above with reference to block 720, the updated individual transmission routing policy may define whether to send the second network message over at least one of the first access network and the second access network. For example, the updated individual transmission routing policy may indicate that all messages should be sent over one of the first access network or the second access network. Alternatively, the updated individual transmission policy may indicate that transmission of the second network message over the first access network or the second access network is conditional on one or more characteristics of the second network message, such as source and/or destination address, service access point, application protocol type (e.g., streaming media, email data, web browsing data, etc.). In some aspects, the updated transmission routing policy received in block 728 may indicate that the second network message is to be sent over the same access network that was used to send the first network message in block 720.

Fig. 8 is a flow chart of a method for routing user data at an execution unit. In some aspects, method 800, discussed below with reference to fig. 8, may be performed by one or more of client-side execution unit 140 and provider-side execution unit 182. For example, instructions in policy executor 315 and/or policy executor 420 may configure

processors

305 and 410, respectively, to perform one or more functions discussed below with reference to fig. 8. Further, policy generator 465 may configure processor 455 to generate policy information that configures one or more of the client-side execution units and/or the provider-side execution units to perform process 800. For example, in some aspects, policy generator 465 may generate rules that implement process 800 and send the rules to the appropriate execution units. Alternatively, policy generator 465 may send data defining quota limits for one or more users to the appropriate execution units so that they may perform process 800 appropriately.

Since process 800 may be implemented by either the provider-side execution unit or the client-side execution unit, the quota described below with reference to fig. 8 may be specific to either the return link policy alone or the return link policy alone, or both in some aspects. In other words, in some aspects, separate quota values may be implemented for both the return link data and the forward link data. Alternatively, the forward link data and the return link data may share a quota in other aspects.

At block 805, the execution unit receives data for transmission to a user. For example, in some aspects, the data received in block 805 may be generated by the web service 120a-n or 220a-n shown in FIGS. 1-2 (e.g., if the referenced execution unit is a client execution unit). Alternatively, the data received in block 805 may be generated by a device on the destination network 160 that is destined for one of the network devices 120a-n or 220a-n (e.g., if the referenced execution unit is a provider-side execution unit).

At block 810, a set of access networks available to the execution unit for transmitting user data is determined. The access network comprises a first access network and a second access network. The set of access networks determined in block 810 represents an access network that provides a network path to a destination node indicated by data from an execution unit (e.g., via a destination IP address).

Block 815 determines whether the user's quota for the first access network has been exceeded. In some aspects, a user quota may be maintained for one or more access networks in the access network group determined in block 810. In some aspects, the aggregate sum of data sent on behalf of the user over the access network may be maintained for a period of time, such as a day, a week, a month, or any period of time. In some aspects, the user may be restricted or prevented from using the network when the sum exceeds the quota for the period of time. In some aspects, the time period may correspond to a contract period for the user/subscriber. In some aspects, the time period may be independent of the user's contract period.

In some aspects, the quota may not be user specific. For example, in these aspects, if the user data is transmitted over the first access network, decision block 815 may evaluate whether the maximum bandwidth within the time period is to be exceeded. For example, in some aspects, the process 800 may aggregate all data transmitted over a first access network over a period of time. When such aggregate data amounts for all users exceed the quota, the network services of the users referenced in fig. 8 may be prevented from sending additional data over the first access network.

In some aspects, the quota may not be an amount of data sent over the access network, but rather a maximum number of concurrent users of the first access network may be utilized. In these aspects, block 815 may compare the current number of users of the first access network to a quota of the first access network. If the current number of users equals or exceeds the quota, process 800 may move from block 815 to block 820.

If the quota is exceeded, the first access network is excluded from the group of access networks, as shown in block 820. In block 825, the remaining access networks in the group are used to determine how to send the user's data. For example, in some aspects, block 825 may utilize process 800 to determine how to transmit data over one of a plurality of access networks (note that the first access network of fig. 7 may be a different access network than the first access network of fig. 8).

The methods disclosed herein include one or more acts for implementing the described methods. The methods and/or acts may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of actions is specified, the order and/or use of specific actions may be modified without departing from the scope of the claims.

The described functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, thenThe functions may be stored as one or more instructions on a tangible computer-readable medium. Storage media may be any available tangible media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other tangible medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, includes Compact Disc (CD), laser disc, optical disc, digital Versatile Disc (DVD), floppy disk and blu-ray disc

Optical discs, in which a magnetic disc usually reproduces data magnetically, and optical discs reproduce data optically with laser light.

The computer program product may perform certain operations presented herein. For example, such a computer program product may be a computer-readable tangible medium having instructions tangibly stored (and/or encoded) thereon, the instructions being executable by one or more processors to perform the operations described herein. The computer program product may comprise packaging material. The software or instructions may also be transmitted over a transmission medium. For example, the software may be transmitted from a website, server, or other remote source using a transmission medium such as a coaxial cable, fiber optic cable, twisted pair, digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, or microwave.

Further, modules and/or other suitable means for performing the methods and techniques described herein may be downloaded and/or otherwise obtained and/or coupled to a server or the like through a suitable terminal to facilitate transfer of means for performing the methods described herein. Alternatively, the various methods described herein may be provided via a storage device (e.g., RAM, ROM, a physical storage medium such as a CD or floppy disk, etc.), such that the various methods are available to the user terminal and/or base station when the storage device is coupled to or provided to the device. Further, any other suitable technique for providing the methods and techniques described herein to a device may be used. Features that implement the functions may also be physically located at various locations including being distributed such that portions of the functions are implemented at different physical locations.

In describing the present invention, the following terms will be used: the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to an item includes reference to one or more items. The terms "a" and "an" mean one, two, or more, and generally applies to select some or all of the amounts. The term "plurality" refers to two or more items. The term "about" means that the amounts, dimensions, sizes, formulations, parameters, shapes, and other characteristics need not be exact, but may be approximated and/or larger or smaller, as desired, reflecting acceptable tolerances, conversion factors, rounding off, measurement error and the like, and other factors known to those of skill in the art. The term "substantially" means that the characteristic, parameter or value described is not necessarily to be achieved precisely, but may deviate or vary, including, for example, tolerances, measurement errors, measurement accuracy limitations and other factors known to those skilled in the art, without impeding the effect that the characteristic is intended to provide. Numerical data may be expressed or presented in a range format. It is to be understood that such range format is used merely for convenience and brevity and thus should be interpreted flexibly to include not only the numerical values explicitly recited as the limits of the range, but also to include all the individual numerical values or sub-ranges encompassed within that range as if each numerical value and sub-range is explicitly recited. By way of illustration, a numerical range of "about 1 to 5" should be interpreted to include not only the explicitly recited values of about 1 to about 5, but also include individual values and sub-ranges within the indicated range. Included within this numerical range are, therefore, individual values such as 2, 3, and 4, as well as subranges such as 1-3, 2-4, and 3-5, etc. The same principle applies to ranges reciting only one numerical value (e.g., "greater than about 1"), and should apply regardless of the breadth of the range or the nature of the characteristic being described. For convenience, multiple items may be presented in a common list. However, these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, any individual member of such a list should not be construed as a de facto equivalent of any other member of the same list solely based on their presentation in a common group without indications to the contrary. Furthermore, when the terms "and" or "are used in conjunction with a list of items, they are to be construed broadly, and any one or more of the listed items may be used alone or in combination with other listed items. The term "optionally" refers to the selection of one of two or more alternatives, and is not intended to limit the selection to only those listed alternatives or to only one of the listed alternatives unless the context clearly indicates otherwise. The term "coupled," as used herein, does not require that the components be directly connected to each other. Rather, the term is intended to also include configurations with indirect connections, wherein one or more other components may be included between the coupled components. Such other components may include, for example, amplifiers, attenuators, isolators, directional couplers, redundant switches, and the like. Furthermore, as used herein, including as recited in the claims, the use of "or" in a list of items containing "at least one" means a separate list, e.g. "at least one of A, B or C" list means a or B or C or AB or AC or BC or ABC (i.e. a and B and C). Furthermore, the term "exemplary" does not mean that the example is preferred or advantageous over other examples. As used herein, a "set" of elements is intended to mean "one or more" of those elements unless the set is explicitly required to have more than one or explicitly allowed to be empty.

Various changes, substitutions, and alterations can be made to the techniques described herein without departing from the techniques of the teachings as defined by the appended claims. Furthermore, the scope of the present disclosure and claims is not limited to the particular aspects of the process, machine, manufacture, composition of matter, means, methods and acts described above. A process, machine, manufacture, composition of matter, means, methods, or acts, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein may be utilized. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or acts.

Claims

1. A system for performing dynamic policy updates of a unit, comprising:

a plurality of client execution units, a client execution unit of the plurality of client execution units comprising:

one or more first network interfaces for communicating over a first access network having a first characteristic between a client execution unit and a destination network and a second access network having a second characteristic between the client execution unit and the destination network, the second characteristic being different from the first characteristic; and

A first processing unit for:

dynamically enforcing individual return link policies based on the received policy information specific to the client-side enforcement unit;

receiving a network message from a network device for transmission to a destination network;

sending a network message over at least one of the first access network and the second access network via one or more first network interfaces using a separate return link policy; and

a policy management unit comprising:

one or more second network interfaces for communicating over at least one of the first access network and the second access network; and

a second processing unit for:

obtain information indicating respective transmissions of each of the plurality of client execution units over the first access network and over the second access network,

updating policy information specific to each of the plurality of client execution units based on the information, and

updated policy information specific to each client execution unit is sent via the one or more second network interfaces.

2. The system of claim 1, wherein in response to receiving the updated policy information, the first processing unit of the client execution unit updates the individual return link policy for subsequent transmission of network messages over the first access network and the second access network.

3. The system of claim 1, wherein the second processing unit is further configured to obtain second information indicative of respective transmissions to each of the plurality of client execution units over the first access network and over the second access network, and update policy information specific to each of the plurality of client execution units based on the second information.

4. The system of claim 1, wherein the plurality of client execution units comprises a first set of client execution units and a second set of client execution units, wherein a separate return link policy for each client execution unit of the first set is different from a separate return link policy for each client execution unit of the second set.

5. The system of claim 4, wherein each client execution unit of the first group is associated with a communication terminal of a first type and each client execution unit of the second group is associated with a communication terminal of a second type.

6. The system of claim 4, wherein at least a portion of the individual return link policies of each client execution unit of the first group are common.

7. The system of claim 1, wherein the network message is a first network message, and the system further comprises a provider-side execution unit comprising:

one or more third network interfaces for communicating over the first access network and the second access network;

a third processing unit configured to:

dynamically executing individual forward link policies of the client execution units based on second policy information received from the policy management unit that is specific to the client execution units;

receiving a second network message for transmission to the network device, and

the second network message is sent over at least one of the first access network and the second access network via one or more third network interfaces using the separate forward link policy.

8. The system of claim 7, wherein the individual forward link policy is different from the individual return link policy.

9. The system of claim 7, wherein the first network message and the second network message are associated with a network session, the first processing unit to send the first network message over a first access network, the third processing unit to send the second network message over a second access network.

10. The system of claim 1, wherein a first portion of the network message is sent over a first access network and a second portion of the network message is sent over a second access network.