US20130128739A1

US20130128739A1 - Method and Device to Control Communication with Multiple Networks Based on Respective Quality of Service Requirements

Info

Publication number: US20130128739A1
Application number: US13/435,542
Authority: US
Inventors: Arzad Alam KHERANI; Pavan NUGGEHALLI; Manish Airy
Original assignee: Broadcom Corp
Current assignee: Avago Technologies International Sales Pte Ltd
Priority date: 2011-11-21
Filing date: 2012-03-30
Publication date: 2013-05-23
Also published as: US20130128937A1; US20130130751A1; US8938239B2; US9008734B2; US20130130694A1

Abstract

A network host device including a connection manager to communicate communication data with an external network over a plurality of bearers of the external network, an interface driver to provide an interface between the interface driver and the communication manager, the interface being dedicated to the external network, to receive processing data associated with the communication data over the interface, and to tag a packet of the processing data with identification information of the external network, and a traffic control unit to receive each packet of the processing data tagged with the identification information of the external network, and to select a bearer from among the plurality of hearers of the external network to communicate the communication data.

Description

CROSS REFERENCE TO RELATED APPLICATION

This non-provisional application claims the benefit of U.S. Provisional Application No. 61/562,196, filed Nov. 21, 2011, the contents of which are herein incorporated by reference in their entirety.

FIELD OF THE INVENTION

The present application is directed to packet data networks (PDNs), and more specifically to a system and a method that enables a host device to support multiple packet data networks (PDNs).

BACKGROUND OF THE INVENTION

Background Art

Conventional network host devices operating in a network environment are able to support only one PDN at a given time. Further, these conventional network host devices require the use of several dedicated modules that run and support the Internet protocol configuration protocol (IPCP) over the network to configure an interface that is required to support the PDN. As such, the functionality to configure the interface is distributed over several modules within the host device. However, the requirement to utilize several modules of the host device is undesirable because it greatly reduces the efficiency of the host device. Further, the several modules have different characteristics which are incompatible with each other with respect to the configuration of the interface.
Therefore, there is a need for a system and a method that enables a host device to support multiple PDNs at a given time based on respective quality of service requirements, and to avoid the distribution of the functionality to configure the interfaces required to support the multiple PDNs over several modules within the host device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary system including a host device capable of supporting multiple PDNs according to an embodiment of the present disclosure.

FIG. 2 illustrates another exemplary system including a host device capable of supporting multiple PDNs according to an embodiment of the present disclosure.

FIG. 3 illustrates another exemplary system including a host device capable of supporting multiple PDNs according to an embodiment of the present disclosure.

FIG. 4 illustrates an exemplary algorithm performed in a network device according to an embodiment of the present disclosure.

FIG. 5 illustrates another exemplary algorithm performed in a network device according to an embodiment of the present disclosure.

FIG. 6 illustrates another exemplary algorithm performed in a network device according to an embodiment of the present disclosure.

FIG. 7 illustrates an example computer system that can be used to implement aspects of the present disclosure.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the disclosure. However, it will be apparent to those skilled in the art that the disclosure including structures, systems, and methods, may be practiced without these specific details. The description and representation herein are the common means used by those experienced or skilled in the art to most effectively convey the substance of their work to others skilled in the art. In other instances, well-known methods, procedures, components, and circuitry have not been described in detail to avoid unnecessarily obscuring aspects of the disclosure.
References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
As described above, a conventional network host device is able to support only one PDN at a time, and involves the undesirable distribution of the functionality to configure the interface across several modules of the network host device to run and support IPCP. Therefore, the following system enables a network host device to support multiple PDNs at a time and enables the configuration of interfaces associated with the multiple PDNs without having to run and support IPCP, as discussed below.
FIG. 1 illustrates a system 150 including a host device 100 connected to multiple PDNs 101, 102, 103 according to an embodiment of the present disclosure. Each PDN is connected to the host device 100 via respective bearers 111, 112, 113 which are used for bidirectional communication of data between the PDNs 101, 102, 103 and the host device 100. In particular, PDN1 101 is connected to the host device 100 via bearers 111, PDN2 102 is connected to the host device 100 via bearers 112, and PDN3 103 is connected to the host device 100 via bearers 113.
The host device 100 includes a connection manager 104 and an integrated circuit 110. The connection manager is connected to an applications unit 107 which stores the applications to be run by the host device 100. The integrated circuit 110 further includes a memory 108, and a CPU1 120 including a PDN classification unit 106 and an interface driver 105. The interface driver 105 is connected to the connection manager 104 via interfaces 121, 122, 123. The integrated circuit 110 also includes a CPU2 140 which includes a traffic control unit 160. The traffic control unit 160 includes a PDN bearer mapping unit 161, a quality of service (QOS) enforcement unit 162, an intra-PDN classification unit 163, and a timer 164. The interface driver 105 is connected to the intra-PDN classification unit 163 via a queuing unit 130.
A PDN is an IP domain that the host device 100 is capable of communicating with. A PDN can be the Internet, a corporate network, or a private network associated with the host device 100. A PDN can be identified by an Access Point Name (APN). The host device 100 connects to a PDN when the connection manager 104 detects a need for establishing a connection with a PDN and/or when an application stored in the applications unit 107 is initiated and requests the connection manager 104 to establish a connection with a PDN. Upon detecting a need or upon receiving a request to connect with a PDN, the connection manager 104 coordinates the necessary protocol-level handshake with the PDN and negotiates a quality of service (QOS) with respect to communication between the host device 100 and the PDN. The QOS enforcement unit 162 stores these QOS requirements negotiated with the PDN. The QOS enforcement unit 162 also stores any updates or changes to the QOS requirements. In addition, the connection manager 104 informs the intra-PDN classification unit 163 of the identity of the PDN and of a default bearer that is to be used to communicate with the PDN. The connection manager 104 also manages the association of an initiated application with a PDN and the communication between the initiated application and the PDN. In one embodiment, once the manger associates the initiated application with PDN, the initiated application is configured to be able to communicate with the PDN by routing data back and forth without the involvement of the connection manager 104.
Now, upon connection with a PDN, the connection manager 104 requests the interface driver 105 to expose an interface dedicated to the connected PDN. In one embodiment, all processing of data associated with the connected PDN by the integrated circuit 110 is conducted through the interface dedicated to the connected PDN. For example, all processing of data associated with PDN1 101 by the integrated circuit 110 is conducted through the dedicated interface 121, all processing of data associated with PDN2 102 by the integrated circuit 110 is conducted through the dedicated interface 122, and all processing of data associated with PDN3 103 by the integrated circuit 110 is conducted through the dedicated interface 123. The PDN classification unit 106 monitors the communication between the connection manager 104 and the interface driver 105, and classifies or associates the exposed dedicated interfaces with their respective PDNs. In particular, based on the communication between the connection manager 104 and the interface driver 105, the PDN classification unit 106 associates the dedicated interface 121 with PDN1 101, associates the dedicated interface 122 with PDN2 102, and associates the dedicated interface 123 with PDN3 103.
In one embodiment, the interface driver 105 exposes interfaces that are Internet protocol (IP) interfaces. For example, the IP interfaces can be implemented using an Ethernet connection between the connection manger 104 and the interface driver 105. The characteristics and properties of an exposed interface are based on parameters of the PDN to which the exposed interface is dedicated. Further, the characteristics and the properties of the exposed interfaces are controllable to be dynamically changed to adapt to any changes to the parameters of the PDN. The parameters of the PDN and any changes thereto can be provided by the connection manager 104 to the interface driver 105. Specifically, the interface driver 105 receives the PDN parameters and any changes thereto, and exposes a new interface having custom characteristics and properties or adapts the characteristics and properties of an existing interface based on the received PDN parameters.
When the host device 100 is connected to a plurality of PDNs, the interface driver 105 is requested to expose a plurality of dedicated interfaces. The plurality of exposed interfaces are collectively known as the stack of exposed interfaces. The host device 100 configures the stack of exposed interfaces 121, 122, 123 without the use of the network (for example, by running IPCP), as is done by conventional host devices. In one embodiment, the traffic control unit 160 is used to configure the stack of exposed interfaces 121, 122, 123. In particular, the traffic control unit 160 configures the stack of exposed interfaces by managing the exposing of a new interface (through the interface driver 105) in the presence of existing exposed interfaces and the functioning of all the exposed interfaces with respect to each other. In one embodiment, the traffic control unit 170 performs a discovery process every time a new interface is exposed without using the network. The neighbor discovery process may include, for example, duplicate address detection to ensure that a tentative address selected for a PDN is unique with respect to an address selected for another PDN. The neighbor discovery process may also include running of an address resolution protocol. Further, the neighbor discovery process may include a connectivity detection to check the status of a connection to a PDN. The neighbor discovery process is discussed in detail later on.
An application of the host device 100 connected to a PDN is ready to communicate data with the PDN once the traffic control unit 160 has configured the stack of exposed interfaces. At this point, the connection manager 104 connects and associates each exposed interface to a respective PDN, and this knowledge is made available to the PDN classification unit 106. As such, multiple PDNs 101, 102, 103 can simultaneously be connected to and communicated with via the host device 100. That is, the host device 100 is capable of supporting multiple PDNs at a given time. Further, each PDN 101, 102, 103 has multiple respective bearers 111, 112, 113 which are used for bidirectional communication of data between each PDN 101, 102, 103 and the host device 100. In one embodiment, the connection manager 104 assigns one of the interfaces exposed by the interface driver 105 as a default interface. The default interface is used for communication of processing data associated with default packet data that is to be transmitted to a PDN, the default packet data being generated by an application which is unknown to the PDN.
Now, during simultaneous communication with multiple PDNs, the connection manager 104 is required to determine a destination PDN to which a piece of data (e.g., generated by an application of the host device) is to be routed. This process to determine the destination PDN is called inter-PDN classification. Further, once the destination PDN has been determined, the connection manager 104 is required to determine which one of the multiple bearers of the destination PDN is to be used to communicate the data based on the negotiated quality of service with the destination PDN. This process to determine the bearer for communication is called intra-PDN classification. To satisfy the QOS requirements negotiated with the PDNs, both the inter-PDN classification process and the intra-PDN classification process should be completed, as discussed below.
The inter-PDN classification process performed by the host device 100 will now be explained. When data is received from one of the multiple PDNs 101, 102, 103 at the host device 100, the connection manager 104 transfers the received data to the respective interface associated or connected to the one of the multiple PDNs. Further, the interface driver 105 identifies the PDN that provided the received data based on the interface through which it receives the received data and based on the information available from the PDN classification unit 106. Now, when an application of the host device 100 generates data to be communicated to a particular PDN, the communication manager transfers the generated data to the interface driver 105 through the interface dedicated to the particular PDN. The interface driver 105 then identifies the particular PDN, to which the generated data is to be communicated, based on the interface to which it receives the generated data and based on the information available from the PDN classification unit 106. Once the interface driver 105 has identified the destination PDN, this identification of the destination PDN is provided to the intra-PDN classification unit 163. This enables the intra-PDN classification unit to carry out the intra-PDN classification process to determine which one of the multiple bearers of the destination PDN is to be used to communicate the data to the destination PDN.
The interface driver 105 uses the queuing unit 130 to provide the identification of the destination PDN to the intra-PDN classification unit 163. In particular, the interface driver 105 tags each packet of the received data or the generated data with identification information of the destination PDN, and transfers the tagged packets to the intra-PDN classification unit 163 via the queuing unit 130. The queuing unit 130 includes modules that allow and/or guarantee preservation of the identification information tagged on to each packet of the received data or the generated data that is being transferred from the interface driver 105 to the intra-PDN classification unit 163. The use of modules that allow and/or guarantee preservation of the identification information is important because otherwise the identification information may be lost during the transfer of the tagged packet data. In particular, sometimes, when data is communicated between two separate processors (120 and 140) which use different modules, the queuing unit 130 may use mutually incompatible modules to transfer the tagged packet data, and therefore, preservation of the identification information is not guaranteed. In such situations, the identification information can be lost during the transfer of the tagged packet data. As such, it is desirable that the queuing unit 130 ensure that only those modules which allow and/or guarantee the preservation of the identification information are used in the transfer of the tagged packet data.
The tagging of each packet of the data will now be explained. As described above, the connection manager 104 transfers packet data received from one of the multiple PDNs (destination PDN) or the generated packet data received from an initiated application to the interface driver 105 over a respective interface associated with the destination PDN. The interface driver 105 identifies the destination PDN based on the respective interface over which the packet data is received from the connection manager 104. Once the interface driver 105 has identified the destination PDN, the interface driver 105 tags each packet of the packet data with identification information of the destination PDN. For example, each packet of the packet data includes a header, and the interface driver 105 includes the identification information of the destination PDN in the header of each packet. The interface driver 105 then transfers each tagged packet of the packet data to the intra-PDN classification unit 163 via the queuing unit 130.
In one embodiment, the interface driver 105 generates a respective descriptor associated with each packet of the received packet data or the generated packet data. The interface driver 105 then stores the packets of the received/generated packet data in the memory 108, and tags each of the descriptors with the identification information of the destination PDN before transferring each of the tagged descriptors to the intra-PDN classification unit 163 via the queuing unit 130. In one embodiment, the interface driver modifies a text-entry portion of the descriptor to include the identification information of the destination PDN. Further, the interface driver 105 may generate the descriptor including a pointer that indicates a location of the corresponding packet of received/generated packet data stored in the memory 108. Additionally or optionally, the interface driver 105 may store the identification information of the destination PDN in the memory 108. In this embodiment, the pointer included in the descriptor may indicate the identity of the destination PDN by pointing to the location in the memory 108 where the identification information of the destination PDN is stored. One will appreciate that transferring the descriptors obviates the need to tag and transfer each packet of the packet data, which could be a more memory intensive task. Further, each descriptor is capable of storing specific information about the corresponding packet of data such as length of the packet, type of the packet data (voice, text, etc.), and the like. This specific information is used by the intra-PDN classification unit 163 to carry out the above-described intra-PDN classification process.
In another exemplary embodiment, as shown in FIG. 2, the queuing unit 130 can be implemented as multiple queuing units 131, 132, 133, each queuing unit being dedicated to each interface exposed by the interface driver 105. Further, each queuing unit 131, 132, 133 is configured to run its own scheme of ordering the packet data (or descriptors). Now, since each exposed interface is dedicated to a particular PDN, each queuing unit from among the multiple queuing units 131, 132, 133 is also dedicated to a particular PDN. Therefore, a given queuing unit from among the multiple queuing units 131, 132, 133 always transfers data (or descriptors) associated with a given PDN from among the multiple PDNs. In this way, data (or descriptors) associated with a plurality of PDNs can be simultaneously transferred to the intra-PDN classification unit 163, thereby increasing overall efficiency. Further, since each queuing unit from among the multiple queuing units 131, 132, 133 always transfers the received/generated packet data (or descriptors) associated with a given PDN from among the multiple PDNs, the intra-PDN classification unit 163 can be configured to identify the destination PDN based on the queuing unit through with the received/generated packet data (or descriptors) is received. In this case, the tagging of each data packet (or descriptor) could be avoided.
The intra-PDN classification process performed by the host device 100 will now be explained. As discussed above, the interface driver 105 tags each packet (or descriptor) of the received/generated packet data with identification information of the destination PDN, and transfers the tagged packets (or descriptors) to the intra-PDN classification unit 163 via the queuing unit 130. The intra-PDN classification unit is configured to select a data packet (or descriptor) from among a plurality of packets (or descriptors) in a queue of the queuing unit 130 based on QOS requirements of a PDN associated with the packet (or descriptor) or based on characteristics of packet data such as, for example, the specific information included in the descriptors, n the embodiment including the multiple queuing units 131, 132, 133, the intra-PDN classification unit can be configured to select a data packet (or descriptor) from among a plurality of packets (or descriptors) based on an ordering scheme of the respective queuing unit from among the multiple queuing units 131, 132, 133.
The intra-PDN classification unit 163 stores a traffic flow template (TFT) associated with each PDN. A traffic flow template enables the intra-PDN classification unit 163 to determine which bearer from among the multiple bearers of a given PDN is to be used for communication with the given PDN, in addition, the intra-PDN classification unit 163 determines the bearer for communication based on the QOS requirements negotiated with the given PDN and stored in the QOS enforcement unit 162. Additionally or optionally, the intra-PDN classification unit 163 may determine the bearer for communication used on information (e.g., specific information) included in the tagged packet data or tagged descriptors. The QOS requirements stored in the QOS enforcement unit 162 are, for example, associated with an amount of traffic of data on each bearer from among the multiple bearers associated with each PDN. Once the intra-PDN classification unit 163 has determined the bearer for communication with the given PDN, the intra-PDN classification unit 163 references the bearer mapping information stored in the PDN bearer mapping unit 161 and informs the interface driver 105 of the mapping information of the determined bearer. The interface driver 105 then coordinates with the connection manager 104 to communicate data to the given PDN over the determined bearer.
In one embodiment, for enhanced efficiency, the intra-PDN classification unit 163 satisfies the QOS requirements negotiated with a given PDN by balancing parameters associated with the communication of data between the host device 100 and given PDN. For example, the intra-PDN classification unit 163 balances the data rate through a given bearer with an allowable jitter requirement, thereby increasing overall efficiency. Further, the intra-PDN classification unit 163 balances a check level discard timer 164 associated with a given bearer to satisfy the QOS requirements and also to arrive at the allowable jitter requirement. In one embodiment, the check level discard timer 164 starts running once the packet data or a descriptor of the packet data arrives at the intra-PDN classification unit 163, and runs for a predetermined duration of time within which the intra-PDN classification process should be completed. Finally, the intra-PDN classification unit 163 may use a token bucket algorithm to check whether the data communication through the bearers conforms to the QOS requirements stored in the QOS enforcement unit 162.
The neighbor discovery process will now be explained. First, the duplicate address detection procedure included in the neighbor discovery process will be described with reference to FIG. 3. FIG. 3 illustrates a system 350 including the host device 100 connected to multiple the PDNs 101, 102, 103 via respective PDN gateways 301, 302, 303. The remaining features of the system 350 are analogous to the features of the system 150, and therefore, a detailed discussion of these features is being omitted. In system 350, the host device 100 is connected to PDNs 101, 102, 103 via respective PDN gateways 301, 302, 303. For example, the connection manager 104 of the host device 100 is connected to PDN1 via PDN1 gateway 301, to PDN2 via PDN2 gateway 302, and to PDN3 via PDN3 gateway 303. As such, the host device 100 may simultaneously communicate with the PDNs 101, 102, 103 via respective PDN gateways 301, 302, 303. Further, the host device 100 may communicate with another host device connected to one of the PDNs 101, 102, 103.
Now, a conventional host device is required to perform a cumbersome process of neighbor solicitation when the conventional host device is connected to a given PDN, and is communicating with another conventional host device connected to the given PDN. In particular, the conventional host device is required to choose a network address to identify itself to the given PDN, and further to advertise the chosen network address over the given PDN to ensure that no other host device connected to the given PDN is using the same chosen network address. That is, the conventional host device is required to conduct the cumbersome process of neighbor solicitation to ensure uniqueness of its chosen network address. Further, the conventional host device is required to conduct additional processing to identify an intermediate node (e.g., a base station using a radio link) to which a piece of data will be initially transmitted to when the conventional host device wishes to transmit the piece of data to the another conventional host device. The conducting of these processes adversely affects the efficiency of the conventional host device. Further, the advertising of the chosen network address over the given PDN unnecessarily burdens traffic of data over the given PDN.
The present disclosure obviates the need for the host device 100 to conduct the above cumbersome processes and also reduces the traffic over a PDN by connecting the host device 100 to the PDNs via respective PDN gateways. In one embodiment, when the interface driver 105 provides an interface (e.g., IP interface 121) to be dedicated to a PDN (e.g., PDN1), the interface driver 105 is configured to assign a network address to the provided interface, and to inform the assigned network address to the connection manager 104. The connection manager 104 then provides the assigned network address to the PDN1 gateway 301 over a network link. The PDN1 gateway 301 recognizes the host device 100 as being a unique device based on this network link because the host device 100 is the only host device connected to the PDN1 gateway 301 over this network link. In one embodiment, the PDN1 gateway 301 assigns a global network address to the host device 100 based on this network link. The global network address may include the network address assigned by the interface driver 105 or a modified version of the same. In this way, the host device 100 is provided with a unique global network address with respect to PDN1 101. Now, the host device 100 only needs to provide destination information of the another host to which data is to be transmitted without having to conduct any neighbor solicitation. The PDN1 gateway 301 then resolves the path through which the transmitted data is to be routed so that the transmitted data reaches the another host. In one embodiment, the PDN1 gateway 301 includes the global network address of the host device 100 in the information sent along with the transmitted data. In this way, the host device 100 is not required to conduct the cumbersome process of neighbor solicitation or of identifying the above-mentioned intermediate node. In one embodiment, the host device 100 may communicate with all other host devices connected to PDN1 101 only via the PDN1 gateway 301. In the above embodiment, it is not necessary that the another host device be connected to PDN1 101. Rather, the another host device can be connected to any PDN, the path to which is resolved by the PDN1 gateway 301. PDN gateways 302 and 303 function in a similar way to the above exemplary functioning of PDN gateway 301.
In another embodiment, when the host device 100 is required to receive a response ensuring the uniqueness of the network address before communicating through a given PDN, the connection manager 104 is configured to generate a fake response indicating the uniqueness of the network address assigned by the interface driver 105, and to communicate the fake response to the interface driver 105. This allows the host device 100 to communicate through the given PDN without advertising the chosen network address over the given PDN to ensure uniqueness of the same. In one embodiment, the network address of the interface 121 could be an IPv6 address. In one embodiment, the network link could be a wireless network link.
The running of an address resolution protocol included in the neighbor discovery process will now be explained. For the host device 100 to be able to communicate with a destination host (beyond PDN-Gateway), the host device 100 needs to know the next-hop neighbor's link-layer address to which the data may be routed. For example, when the host device 100 uses an Ethernet device/interface, the host device 100 needs to know a Ethernet MAC address (e.g. 48 bit address) of the destination host device that the host device 100 should address its Ethernet packets to. Alternatively, when the host device 100 uses an LTE interface, the host device 100 can remove the Ethernet header before sending any uplink packet, and therefore the exact value of the advertised link-layer address for the destination host device IP address is not required. Rather, the host device 100 simply routes any uplink packet to the PDN gateway associated with the destination host, and the PDN gateway resolves the path to the destination host. In one embodiment, for this reason, when the traffic control module receives the neighbor solicitation message requesting for a link-layer address of the destination host, the traffic control module may respond with a neighbor advertisement message including an arbitrary Ethernet address.
The connectivity detection procedure included in the neighbor discovery process will now be explained when the host device 100 operates using, for example, the IPv6 protocol. Conventionally, the host device 100 would have to perform the IPv6 un-reachability detection to check the availability of another IPv6 device connected on the same link to a PDN as the host device 100, so as to ensure uniqueness and security of communication. However, in the present disclosure, the host device 100 is connected to a PDN via a PDN gateway, and the host device 100 is the only device connected to the PDN gateway on a given link. In particular, a link between the host device and a PDN gateway has no other host devices connected to the link. Therefore, it is not necessary for the host device 100 to perform the un-reachability detection described above. As such, there is no need to forward the un-reachability detection messages to the PDN gateway. However, since the IPv6 protocol requires a received response at the host device 100 to ensure uniqueness, the connection manager 104 and/or the interface driver 105 can generate un-reachability detection messages and transmit the same to the traffic control module. In response, the traffic control module responds to the un-reachability detection messages within the host device 100 without sending the messages to the PDN gateway.
In one embodiment, the integrated circuit 110 can be external to the host device 100 and can be communicatively connected to the host device 100, for example, via an IP interface. For example, the integrated circuit 110 can be communicatively connected to the host device 100 via a USB connection or via an SDIO connection. The host device 100 could be a handheld device such as a cellular phone, PDA, or the like. Further, the host device 100 could be compatible with many networks including LTE, 2G, 3G, or the like.
FIG. 4 illustrates an exemplary algorithm performed in a network device for communicating data with an external network over a plurality of bearers associated with the external network according to an embodiment of the present disclosure. One of ordinary skill in the art would appreciate that performing a subset of the disclosed steps is within the scope of the present disclosure. In step 401, the network device connects to an external network. In step 402, the network device negotiates a quality of service (QOS) requirement related to communication with the external network. In step 403, the network device stores an application that is capable of communicating with the external network. In step 404, the network device provides an interface dedicated to the external network. In step 405, processing data associated with communication over the interface is received, in step 406, the network device tags a packet of the processing data with identification information of the external network. In one embodiment, the network device identifies or generates the identification information of the external network based on the interface over which the processing data associated with the external network is received. In step 407, the network device selects a bearer from among the plurality of bearers based on the identification information tagged on the packet and/or based on the negotiated QOS requirement, to communicate with the external network.
FIG. 5 illustrates another exemplary algorithm performed in a network device for communicating data with an external network over a plurality of bearers associated with the external network according to an embodiment of the present disclosure. One of ordinary skill in the art would appreciate that performing a subset of the disclosed steps is within the scope of the present disclosure. In step 501, the network device connects to an external network. In step 502, the network device negotiates a quality of service (QOS) requirement related to communication with the external network. In step 503, the network device stores an application that is capable of communicating with the external network. In step 504, the network device provides an interface dedicated to the external network. In step 505, processing data associated with communication over the interface is received. In step 506, the network device generates a descriptor associated with a packet of the processing data. In step 507, the network device tags the generated descriptor with identification information of the external network. In one embodiment, the network device identifies and/or generates the identification information of the external network based on the interface over which the processing data associated with the external network is received. In step 508, the network device selects a bearer from among the plurality of bearers based on the identification information tagged on the descriptor and/or based on the negotiated QOS requirement, to communicate with the external network.
FIG. 6 illustrates an exemplary algorithm performed by the network device while providing an interface dedicated to the external network. In one embodiment, the network device provides the interface dedicated to the external network without running the Internet protocol configuration protocol (IPCP). In step 601, the network device provides the interface with a characteristic based on a parameter associated with the external network, and in step 602, the network device dynamically adjusts the characteristic of the interface with a change in the parameter associated with the external network. It should be noted that the exemplary algorithms discussed in the present disclosure can be performed by the hardware components of the devices (e.g., host device 100) discussed in the present disclosure.
It will be apparent to persons skilled in the relevant art(s) that various elements, features, and functions (e.g., steps) of the present disclosure can be implemented in hardware using analog and/or digital circuits, in software, through the execution of instructions by one or more general purpose or special-purpose processors, or as a combination of hardware and software, via the general purpose computer. For example, various functions of at least the host device can be implemented by one or more general purpose or special-purpose processors, and/or as a combination of hardware and software, via the general purpose computer.
The following description of a general purpose computer system is provided for the sake of completeness. Embodiments of the present disclosure can be implemented in hardware, or as a combination of software and hardware. Consequently, embodiments of the disclosure may be implemented in the environment of a computer system or other processing system. An example of such a computer system 700 is shown in FIG. 7. One or more of the features depicted in FIGS. 1-6 (e.g., communication manager 104, interface driver 105, traffic control module 160, PDN gateway 301, etc.) and their corresponding algorithms can be executed on one or more distinct computer systems 700, or a portion thereof. Furthermore, any functions performed by any of the above features can be implemented on one or more distinct computer systems 700.
A computer system 700 includes one or more processors, such as processor 704. Processor 704 can be a special purpose or a general purpose digital signal processor. Processor 704 is connected to a communication infrastructure 702 (for example, a bus or network). Various software implementations are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the relevant art(s) how to implement the disclosure using other computer systems and/or computer architectures.
Computer system 700 also includes a main memory 706, preferably random access memory (RAM), and may also include a secondary memory 708. Secondary memory 708 may include, for example, a hard disk drive 710 and/or a removable storage drive 712, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, or the like. Removable storage drive 712 reads from and/or writes to a removable storage unit 716 in a well-known manner Removable storage unit 716 represents a floppy disk, magnetic tape, optical disk, or the like, which is read by and written to by removable storage drive 712. As will be appreciated by persons skilled in the relevant art(s), removable storage unit 716 includes a computer usable storage medium having stored therein computer software and/or data.
In alternative implementations, secondary memory 708 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 700. Such means may include, for example, a removable storage unit 718 and an interface 714. Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, a thumb drive and USB port, and other removable storage units 718 and interfaces 714 which allow software and data to be transferred from removable storage unit 718 to computer system 700.
Computer system 700 may also include a communications interface 720. Communications interface 720 allows software and data to be transferred between computer system 700 and external devices. Examples of communications interface 720 may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, etc. Software and data transferred via communications interface 720 are in the form of signals which may be electronic, electromagnetic, optical, or other signals capable of being received by the host device 100. These signals are provided to communications interface 720 via a communications path 722. Communications path 722 carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link and other communications channels.
As used herein, the terms “computer program medium” and “computer readable medium” are used to generally refer to tangible storage media such as removable storage units 716 and 718 or a hard disk installed in hard disk drive 710. These computer program products are means for providing software to computer system 700.
Computer programs (also called computer control logic) are stored in main memory 706 and/or secondary memory 708. Computer programs may also be received via communications interface 720. Such computer programs, when executed, enable the computer system 700 to implement the present disclosure as discussed herein. In particular, the computer programs, when executed, enable processor 704 to implement the processes of the present disclosure, such as any of the methods described herein. Accordingly, such computer programs represent controllers of the computer system 700. Where the disclosure is implemented using software, the software may be stored in a computer program product and loaded into computer system 700 using a removable storage drive 712, interface 714, or communications interface 720.
In another embodiment, features of the disclosure are implemented primarily in hardware using, for example, hardware components such as application-specific integrated circuits (ASICs) and gate arrays. Implementation of a hardware state machine so as to perform the functions described herein will also be apparent to persons skilled in the relevant art(s).

Conclusion

It is to be appreciated that the Detailed Description section, and not the Summary and Abstract sections, is intended to be used to interpret the claims. The Summary and Abstract sections may set forth one or more but not all exemplary embodiments of the present invention as contemplated by the inventor(s), and thus, are not intended to limit the present invention and the appended claims in any way.
The present invention has been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed.
The foregoing description of the specific embodiments will so fully reveal the general nature of the invention that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present invention. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.
It should be noted that any exemplary processes described herein can be implemented in hardware, software, or any combination thereof. For instance, the exemplary process can be implemented using computer processors, computer logic, application specific circuits (ASICs), digital signal processors (DSP), etc., as will be understood by one of ordinary skill in the arts based on the discussion herein.
Moreover, any exemplary processes discussed herein can be embodied by a computer processor or any one of the hardware devices listed above. The computer program instructions cause the processor to perform the processing functions described herein. The computer program instructions (e.g., software) can be stored in a computer useable medium, computer program medium, or any storage medium that can be accessed by a computer or processor. Such media include a memory device such as a computer disk or CD ROM, or the equivalent. Accordingly, any computer storage medium having computer program code that causes a processor to perform the processing functions described herein are with the scope and spirit of the present invention.
The breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

What is claimed is:

1. A network host device, comprising:

a connection manager configured to communicate communication data with an external network over a plurality of bearers of the external network;

an interface driver configured

to provide an interface between the interface driver and the communication manager, the interface being dedicated to the external network,

to receive processing data associated with the communication data over the interface, and

to tag a packet of the processing data with identification information of the external network; and

a traffic control unit configured to receive the packet of the processing data tagged with the identification information of the external network, and to select a bearer from among the plurality of bearers based on the identification information tagged on the packet.

2. The network host device of claim 1, wherein

the connection manager is configured to negotiate a quality of service (QOS) requirement associated with communication between the host device and the external network, and

the traffic control unit is configured to select the bearer from among the plurality of bearers based on the negotiated QOS requirement.

3. The network host device of claim 1, further comprising:

a queuing unit configured to transfer the packet of the processing data tagged with identification information of the external network from the interface driver to the classification unit, and to preserve the tagged identification information during the transfer.

4. The network host device of claim 3, wherein the queuing unit is configured to be dedicated to transfer processing data that is associated with the external network.

5. The network host device of claim 1, further comprising:

an application unit configured to store an application that generates the processing data, the application configured to be in communication with the external network.

6. The network host device of claim 1, wherein the interface driver is configured to provide the interface having a characteristic based on a parameter associated with the external network, and to dynamically adjust the characteristic of the interface with a change in the parameter.

7. The network host device of claim 1, wherein the interface driver is configured to identify the external network based on the interface over which the processing data is received.

8. The network host device of claim 1, wherein

the interface driver is configured to generate a descriptor associated with the packet of the processing data, and to tag the descriptor with the identification information of the external network, and

the traffic control unit is configured to select a bearer from among the plurality of bearers of the external network to communicate the communication data based on the identification information tagged on the descriptor.

9. The network host device of claim 1, wherein the interface driver and the traffic control unit are detachable from the host device.

10. The network host device of claim 1, wherein the interface driver is configured to provide the interface between the interface driver and the communication manager without running the Internet protocol configuration protocol (IPCP).

11. A method for communicating communication data with an external network over a plurality of bearers of the external network, the method comprising:

providing, in a network device, an interface dedicated to the external network;

receiving, in the network device, processing data associated with communication data over the interface;

tagging, in the network device, a packet of the processing data with identification information of the external network; and

selecting, in the network device, a bearer from among the plurality of bearers of the external network based on the identification information.

12. The method of claim 11, further comprising:

negotiating a quality of service (QOS) requirement associated with communication with the external network, wherein

the selecting the bearer includes selecting the bearer from among the plurality of bearers based on the negotiated QOS requirement.

13. The method of claim 11, wherein the tagging includes transferring the packet of the processing data tagged with the identification information of the external network within the network device while preserving the tagged identification information during the transferring.

14. The method of claim 13, wherein the transferring the packet of the processing data includes transferring the packet of the processing data via a queue dedicated to transfer processing data associated with the external network.

15. The method of claim 11, further comprising:

storing an application that generates the processing data, the application being configured to be in communication with the external network.

16. The method of claim 11, wherein the providing the interface comprises:

providing the interface having a characteristic based on a parameter associated with the external network, and

dynamically adjusting the characteristic of the interface with a change in the parameter.

17. The method of claim 11, wherein the tagging includes identifying the external network based on the interface over which the processing data is received.

18. The method of claim 11, the tagging comprises:

generating a descriptor associated with the packet of the processing data; and

tagging the descriptor with the identification information of the external network, wherein

the selecting the bearer includes selecting the bearer from among the plurality of bearers based on the identification information tagged on the descriptor.

19. The method of claim 11, wherein the providing the interface includes providing the interface without running the Internet Protocol configuration protocol (IPCP).

20. A method for communicating communication data with an external network over a plurality of bearers of the external network, the method comprising:

connecting to an external network;

negotiating, in a network device, a quality of service (QOS) requirement related to communication with the external network;

providing, in the network device, an interface dedicated to the external network;

generating, in the network device, identification information of the external network based on the interface over which the processing data is received;

generating, in the network device, a descriptor associated with a packet of processing data;

tagging, in the network device, the descriptor with the identification information of the external network; and

selecting, in the network device, a bearer from among the plurality of bearers to communicate the communication data based on the identification information tagged on the descriptor and based on the negotiated QOS requirement.