U.S. patent application number 13/435542 was filed with the patent office on 2013-05-23 for method and device to control communication with multiple networks based on respective quality of service requirements.
This patent application is currently assigned to Broadcom Corporation. The applicant listed for this patent is Manish AIRY, Arzad Alam KHERANI, Pavan NUGGEHALLI. Invention is credited to Manish AIRY, Arzad Alam KHERANI, Pavan NUGGEHALLI.
Application Number | 20130128739 13/435542 |
Document ID | / |
Family ID | 48426847 |
Filed Date | 2013-05-23 |
United States Patent
Application |
20130128739 |
Kind Code |
A1 |
KHERANI; Arzad Alam ; et
al. |
May 23, 2013 |
Method and Device to Control Communication with Multiple Networks
Based on Respective Quality of Service Requirements
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.
Inventors: |
KHERANI; Arzad Alam;
(Bangalore, IN) ; NUGGEHALLI; Pavan; (Plano,
TX) ; AIRY; Manish; (Bangalore, IN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
KHERANI; Arzad Alam
NUGGEHALLI; Pavan
AIRY; Manish |
Bangalore
Plano
Bangalore |
TX |
IN
US
IN |
|
|
Assignee: |
Broadcom Corporation
Irvine
CA
|
Family ID: |
48426847 |
Appl. No.: |
13/435542 |
Filed: |
March 30, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61562196 |
Nov 21, 2011 |
|
|
|
Current U.S.
Class: |
370/235 |
Current CPC
Class: |
H04W 28/0263 20130101;
Y02D 70/1262 20180101; Y02D 70/24 20180101; H04W 52/0216 20130101;
H04L 41/0803 20130101; Y02D 30/70 20200801; Y02D 70/23 20180101;
Y02D 70/164 20180101; H03D 7/16 20130101; Y02D 70/146 20180101 |
Class at
Publication: |
370/235 |
International
Class: |
H04L 12/24 20060101
H04L012/24; H04L 12/56 20060101 H04L012/56 |
Claims
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;
receiving, in the network device, processing data associated with
communication data over the interface; 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.
Description
CROSS REFERENCE TO RELATED APPLICATION
[0001] 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
[0002] 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
[0003] 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.
[0004] 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
[0005] FIG. 1 illustrates an exemplary system including a host
device capable of supporting multiple PDNs according to an
embodiment of the present disclosure.
[0006] FIG. 2 illustrates another exemplary system including a host
device capable of supporting multiple PDNs according to an
embodiment of the present disclosure.
[0007] FIG. 3 illustrates another exemplary system including a host
device capable of supporting multiple PDNs according to an
embodiment of the present disclosure.
[0008] FIG. 4 illustrates an exemplary algorithm performed in a
network device according to an embodiment of the present
disclosure.
[0009] FIG. 5 illustrates another exemplary algorithm performed in
a network device according to an embodiment of the present
disclosure.
[0010] FIG. 6 illustrates another exemplary algorithm performed in
a network device according to an embodiment of the present
disclosure.
[0011] FIG. 7 illustrates an example computer system that can be
used to implement aspects of the present disclosure.
DETAILED DESCRIPTION
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
* * * * *