Patent Grant
8612609
This disclosure relates generally to communication networks and, more particularly, to methods and apparatus to reassign quality of service priorities in a communication network.
Internet protocol (IP) and other types of data communication networks typically employ quality of service (QoS) priorities (also referred to as QoS levels) to represent desired performance targets, such as desired error rates, latencies, jitter, etc., for different types of traffic carried by the network. Generally, higher QoS priorities identify network traffic having more stringent performance targets and, therefore, requiring more communication resources, whereas lower QoS priorities identify network traffic having less stringent performance targets and, therefore, requiring fewer communication resources. Conventionally, a communication network service provider employs a service provisioning system to negotiate or offer a particular service level agreement to a particular network user specifying certain QoS priorities for different types of network traffic exchanged by the network user. For example, a service level agreement may specify a service profile containing respective QoS priorities for best effort traffic, streaming data traffic, voice and multimedia traffic, etc. Furthermore, different network users may have service level agreements specifying different service profiles and associated QoS priorities.
Methods and apparatus to reassign quality of service (QoS) priorities in a communication network are disclosed. An example QoS priority reassignment technique described herein involves performing a temporary QoS priority reassignment for network traffic between a first network element associated with a first user of the communication network and a second network element associated with a second user of the communication network. Additionally, such temporary QoS priority reassignment is performed without intervention by a service provider providing the communication network to the first and second users. Instead, the first user is authorized by the service provider to temporarily reassign a QoS priority associated with the second user. Furthermore, the example QoS reassignment technique involves terminating the temporary QoS priority reassignment based on one or more termination criteria when needed. Also, in some example implementations, the first user is authorized to only upgrade or promote the QoS priority associated with the second user to thereby avoid unintended service degradation.
In many conventional communication networks, the QoS priorities associated with a particular network user (e.g., such as the QoS priorities specified by the particular network user's service profile) are static. In such conventional networks, changing the QoS priorities associated with a particular network user's service profile requires the network user to renegotiate or resubscribe to a different service level agreement or a different service profile through the service provider's service provisioning system. Unlike such conventional techniques, the example QoS priority reassignment techniques described herein allow dynamic (e.g., on-demand), temporary reassignment of a QoS priority associated with a network user. Additionally, unlike conventional systems in which only the service provider can reassign static QoS priorities through its service provisioning system, the QoS priority reassignment techniques described herein are invoked for a particular network user by another authorized network user instead of by the service provider.
For example, through the QoS priority reassignment techniques described herein, a service retailer or content provider that is an authorized user of the service provider's communication network can perform an on-demand, temporary upgrade of the QoS priority of another user's network traffic to and/or from the service retailer or content provider. As another example, through the QoS priority reassignment techniques described herein, a government entity authorized by the service provider can perform an on-demand, temporary upgrade of the QoS priority of a first responder's network traffic to and/or from the government entity during an emergency situation. Furthermore, in these examples, QoS priority reassignment is able to be performed by an authorized network user without intervention by the service provider.
Such on-demand, temporary QoS priority reassignment can achieve many benefits over conventional techniques. For example, by becoming authorized to perform on-demand, temporary QoS priority upgrades for its customers, a service retailer or content provider can differentiate itself from competitors by offering services and/or applications having improved QoS performance and quality relative to the competitors' services and applications, even though the customers have subscribed to network service having lower QoS priorities (e.g., such as a best effort service). Because such differentiation may be attractive to many service retailers and content providers, the service provider can improve its revenue stream by offering premium service classes authorizing a premium user (such as a subscribing service retailer or content provider) to perform on-demand, temporary QoS priority reassignment (e.g., upgrading) of the network traffic exchanged with its customers. A further benefit of the QoS priority reassignment techniques described herein is the ability of a government agency to rapidly perform an on-demand, temporary upgrade of the QoS priority of a first responder's network traffic to and/or from the government agency without requiring intervention by the service provider. In this way, the first responder's network traffic can be given higher priority in the communication network almost immediately at the onset of an emergency situation.
Turning to the figures, a first example communication network 100 supporting the QoS priority reassignment techniques described herein is illustrated in
In the illustrated example of
The INE 115, network 120 and ENE 125 implement a data traffic path 130 (also referred to as a media path 130) between the PQRI device 105 and PQRE device 110 via which network traffic can be exchanged. The exchanged network traffic can correspond to any type of service or application, such as file downloading or uploading, streaming media, video-on-demand (VOD), voice over Internet protocol (VoIP), etc. Under normal operating conditions, the network traffic exchanged between the PQRI device 105 and the PQRE device 110 has a default QoS priority determined by the class of network service to which the PQRE has subscribed. For example, the PQRE can subscribe to a best effort service in which network traffic exchanged with the PQRE device 110 is marked with a low QoS priority corresponding to the best effort service. However, using the methods and apparatus described herein, the PQRI can invoke the PQRS and temporarily reassign (e.g., upgrade) the QoS priority of network traffic between the PQRI device 105 and PQRE device 110 even though the PQRE has only subscribed to a lower service class. As a shorthand convenience, performing a temporary QoS priority reassignment for the PQRE (and, in particular, the PQRE device 110) is also referred to herein as invoking the PQRS for the PQRE.
To implement temporary QoS priority reassignment according to the methods and apparatus described herein, the communication network 100 of the illustrated example includes first and second example network control elements 135 and 140. The first network control element is also referred to herein as the network control initiating element (NCI) 135, and the second network control element 140 is also referred to herein as the network control end-user element (NCE) 140. The NCI 135 and NCE 140 can each be implemented by any type of network control element, such as a network switch, router, bridge, gateway, etc. The NCI 135, network 120 and NCE 140 implement a PQRS control path 145 between the INE 115 serving PQRI device 105 and the ENE 125 serving the PQRE device 110. In the example of
As mentioned above, the PQRI subscribes to a PQRS that authorizes the PQRI to reassign (e.g., upgrade or promote) the QoS priority of the PQRE and, in particular, some or all of the network traffic between the PQRE device 110 and the PQRI device 105. The PQRS specifies one or more invocation criteria governing when the PQRI can perform an on-demand, temporary QoS priority reassignment the PQRE. Examples of such invocation criteria include an invocation frequency limiting a total number of temporary QoS priority reassignments allowed to be performed by the PQRI during a specified interval of time, a concurrent invocation limit limiting a total number of temporary QoS priority reassignments allowed to be active at any given time, etc. The invocation criteria allow the service provider to predict overall network traffic and appropriately size the capacity of the example communication network 100.
The PQRS also specifies one or more termination criteria governing when a temporary QoS priority reassignment of the PQRE invoked by the PQRI is to be terminated. Examples of such termination criteria are a specified invocation period during which a temporary QoS priority reassignment of the PQRE is allowed to be active, a specified total amount of network traffic allowed to be exchanged during the temporary QoS priority reassignment of the PQRE, etc. The termination criteria allow the service provider to develop any number of PQRS plans or tiers (e.g., such as plans/tiers offering shorter or longer invocation periods and/or more or less total amounts of data) having different prices, thereby allowing a PQRI to select a particular PQRS plan/tier that meets its requirements and competitive goals. Furthermore, a particular PQRI can subscribe to multiple PQRS plans/tiers, and invoke the particular PQRS plan/tier that is suited to a particular PQRE and the particular service/application being offered to the PQRE.
In at least some example implementations, the service provider charges the PQRI for any PQRS plan(s)/tier(s) to which it subscribes, with the service provider not charging the PQRE for any temporary QoS priority reassignments. In other words, the PQRE can accesses the communication network 100 under its standard service agreement with the service provider, and can receive temporary QoS priority reassignments from the PQRI without further charges from the service provider. However, the PQRI could negotiate a separate agreement with the PQRE through which the PQRE pays a certain premium to access services and/or applications offered by the PQRI at a higher QoS priority.
To illustrate an example operation of the PQRS in the communication network 100, assume that the PQRI is a multimedia service retailer, also referred to as a multimedia service distributor, subscribing to the communication network 100 to offer one or more multimedia services to customers, such as the PQRE. In such an example, the PQRE uses the PQRE device 110 to access the PQRI device 105 and obtain the multimedia service (e.g., such as an online interactive gaming environment) offered by the PQRI. For example, assume the PQRE has subscribed to a standard service, such as a best effort service, in which network traffic exchanged with the PQRE device 110 is marked with a low QoS priority (e.g., the priority corresponding to the best effort service). However, because it subscribes to the PQRS, the PQRI can reassign (e.g., upgrade or promote) the QoS priority of the PQRE and, in particular, the QoS priority of the network traffic exchanged between the PQRE device 110 and the PQRI device 105 via the data traffic path 130. In this way, the PQRE can obtain the multimedia service (e.g., such as an online interactive gaming environment) offered by the PQRI at the higher QoS offered by the PQRS without needing to renegotiate with the service subscriber to change its service profile or service level agreement for accessing the communication network 100.
For example, after subscribing to the PQRS, the PQRI can use the PQRI device 105 to initiate a temporary QoS priority reassignment of the PQRE using the PQRS. This initiation is communicated to the NCI 135, which evaluates the invocation criteria specified by the PQRS to determine whether the temporary QoS priority reassignment can be invoked. Assuming the invocation criteria are satisfied, the NCI 135 causes the INE 115 to create an entry in a PQRS marking table 150 maintained by the INE 115 to store the reassigned (e.g., upgraded or promoted) QoS priority to be used to mark network traffic sent by the PQRI device 105 to the PQRE device 110. Additionally, the NCI 135 signals the NCE 140 that a temporary QoS priority reassignment is to be invoked for the PQRE device 110 served by the NCE 140.
In response, the NCE 140 evaluates one or more authorization criteria to determine whether to accept or reject the temporary QoS priority reassignment being invoked by the NCI 135. An example of such authorization criteria includes a QoS improvement requirement that an upgraded QoS priority resulting from a temporary QoS priority reassignment must be an improvement over an existing QoS priority to which the PQRE has subscribed. Another example of such authorization criteria is a subscription rule requirement that a temporary QoS priority reassignment cannot be performed if prohibited by a service profile or service level agreement governing the PQRE's access to the communication network 100, etc. Assuming any authorization criteria are satisfied, the NCE 140 signals to the NCI 135 that invocation of the temporary QoS priority reassignment is allowed. Additionally, the NCE 140 causes the ENE 125 to create an entry in a PQRS marking table 155 maintained by the ENE 125 to store the reassigned (e.g., upgraded or promoted) QoS priority to be used to mark network traffic sent by the PQRE device 110 to the PQRI device 105.
Once the appropriate entries in the PQRS marking tables 150 and 155 are created, network traffic can be exchanged between the PQRE device 110 and the PQRI device 105 using the appropriate reassigned (e.g., upgraded or promoted) QoS priority or priorities stored in the respective PQRS marking tables 150 and 155. For example, different QoS priorities can be assigned based on the direction of the network traffic, the type of network traffic, etc. Each of these QoS priorities can be stored in the appropriate PQRS marking tables 150 and 155 and accessed to mark network traffic between the PQRE device 110 and the PQRI device 105 over the data traffic path 130 in the communication network 100.
Then, after invoking the temporary QoS priority reassignment for traffic between the PQRE device 110 and the PQRI device 105, the NCI 135 evaluates the termination criteria specified by the PQRS to determine when to terminate the temporary QoS priority reassignment. When one or more of the termination criteria is satisfied, the NCI 135 signals the INE 115 and ENE 125 (the latter via the NCE 140) to terminate the temporary QoS priority reassignment. In response, the INE 115 and the ENE 125 each clear the entries in the respective PQRS marking tables 150 and 155 associated with this temporary QoS priority reassignment. However, even though the temporary QoS priority reassignment is terminated, the PQRE device 110 and the PQRI device 105 can continue exchanging network traffic over the data traffic path 130, but at the standard QoS priority associated with the PQRE device 110. After the temporary QoS priority reassignment invoked using the PQRS is terminated, the service provider determines any appropriate billing information needed to charge the PQRI and/or the PQRE for use of the PQRS. As described above, the service provider may or mat not charge the PQRE for benefiting from the PQRS. Additionally or alternatively, the PQRI may determine any appropriate billing information to charge the PQRE depending upon an agreement between the PQRE and PQRI.
A block diagram of a second example communication network 200 supporting the QoS priority reassignment techniques described herein is illustrated in
Turning to
However, in the example communication network 200 of
While the PQRI device 105, INE 115 and PQRS marking table 150 may all be implemented as a single device in at least some example implementations of the communication network 100 of
While example manners of implementing the communication networks 100 and 200 have been illustrated in
An example implementation of the NCI 135 included in the example communication networks 100 and 200 of
The NCI 135 of
To determine whether to allow the temporary QoS priority reassignment to be performed, the PQRS invocation processor 325 also evaluates one or more invocation criteria. For example, the PQRS invocation processor 325 retrieves an invocation count value maintained by an invocation counter 330 included in the NCI 135 of
The NCI 135 of
The example NCI 135 of
Operation of the network interface 305, the PQRS invocation processor 325, the invocation counter 330, the PQRS error processor 335, the PQRS authentication processor 340, the PQRS termination processor 345, the invocation timer 350 and the traffic monitor 355 included in the NCI 135 of
While an example manner of implementing the NCI 135 of
An example implementation of the INE 115 included in the example communication networks 100 and 200 of
The INE 115 of
For example, a temporary QoS priority reassignment can cover all network traffic associated with a particular PQRE device 110, resulting in a single reassigned (e.g., upgraded or promoted) QoS priority value to be used to mark network traffic from the PQRI device 105 or PQRS server 210 served by the INE 115 to the PQRE device 110. Alternatively, a temporary QoS priority reassignment can cover only a certain type of network traffic associated with a certain type of application or service accessed by the particular PQRE device 110. For example, a temporary QoS priority reassignment can cover only data download traffic, data upload traffic, video traffic, voice traffic, etc. In such an example, multiple reassigned (e.g., upgraded or promoted) QoS priority values may be stored in the PQRS marking table 150 for a particular PQRE device 110, with each stored QoS priority value used to mark a different type of network traffic from the PQRI device 105 or PQRS server 210 served by the INE 115 to the PQRE device 110.
The INE 115 of
The INE 115 of
Operation of the network interface 405, the PQRS marking table 150, the PQRS marking table processor 425, and the data packet marker 430 included in the INE 115 of
While an example manner of implementing the INE 115 of
An example implementation of the NCE 140 included in the example communication networks 100 and 200 of
The NCE 140 of
In the case of voluntary invocation, a temporary QoS priority reassignment can be accepted or rejected on behalf of the PQRE device 110 whose QoS priority is to be reassigned. In an example implementation supporting voluntary invocation, the NCE 140 is to act as a proxy for the PQRE device 110 to determine whether to authorize a temporary QoS priority reassignment initiated by the PQRI. In particular, the PQRS invocation processor 520 causes a PQRS authorization processor 525 included in the NCE 140 to evaluate one or more authorization criteria to determine whether to allow the temporary QoS priority reassignment to be performed. For example, the PQRS authorization processor 525 can be configured to evaluate a QoS improvement requirement that an upgraded or promoted QoS priority resulting from the temporary QoS priority reassignment must be an improvement over an existing QoS priority associated with the PQRE device 110. Additionally or alternatively, the PQRS authorization processor 525 can be configured to evaluate a subscription rule requirement that a temporary QoS priority reassignment cannot be prohibited by a rule governing access to the communication network 100 or 200 by the PQRE device 110. For example, temporary QoS priority reassignments may be prohibited for the PQRE device 110 when the PQRE device 110 belongs to an enterprise network governed by certain QoS priorities, or based on traffic engineering rules at the access point of the PQRE device 110 to the communication network 100 or 200.
Furthermore, in the case of voluntary invocation, if temporary QoS priority reassignment is determined to be authorized, the PQRS authorization processor 525 sends appropriate control messages to the ENE 125 and the NCI 135 via the network interface 505 to complete invocation of the temporary QoS priority reassignment. If temporary QoS priority reassignment is determined to not be authorized, the PQRS authorization processor 525 sends appropriate error message to the NCI 135 via the network interface 505 to cancel invocation of the temporary QoS priority reassignment.
In contrast, in the case of involuntary invocation, temporary QoS priority reassignment is to be allowed automatically (or, in other words, the temporary QoS priority reassignment must be accepted on behalf of the PQRE device 110 and cannot be rejected). As such, the PQRS authorization processor 525 does not evaluate any authorization rules. Instead, the PQRS invocation processor 520 automatically sends appropriate control messages to the ENE 125 and the NCI 135 via the network interface 505 to complete invocation of the temporary QoS priority reassignment.
The NCE 140 of
The NCE 140 of
Operation of the network interface 505, the PQRS invocation processor 520, the PQRS authorization processor 525, the ENE information processor 530 and the PQRS termination processor 535 included in the NCE 140 of
While an example manner of implementing the NCE 140 of
An example implementation of the ENE 125 included in the example communication networks 100 and 200 of
The ENE 125 of
For example, a temporary QoS priority reassignment can cover all network traffic associated with a particular PQRE device 110, resulting in a single reassigned (e.g., upgraded or promoted) QoS priority value to be used to mark network traffic from the PQRE device 110 served by the ENE 125 to the PQRI device 105 or PQRS server 210. Alternatively, and as described above, a temporary QoS priority reassignment can cover only a certain type of network traffic associated with a certain type of application or service accessed by the particular PQRE device 110. In such an example, multiple reassigned (e.g., upgraded or promoted) QoS priority values may be stored in the PQRS marking table 155 for a particular PQRE device 110, with each stored QoS priority value used to mark a different type of network traffic from the PQRE device 110 served by the ENE 125 to the PQRI device 105 or PQRS server 210.
The ENE 125 of
The ENE 125 of
Operation of the network interface 605, the PQRS marking table 155, the PQRS marking table processor 625, and the data packet marker 630 included in the ENE 125 of
While an example manner of implementing the ENE 125 of
Turning to
In particular, an example message sequence diagram 700 corresponding to a scenario in which a temporary QoS priority reassignment is successfully invoked is depicted in
In such an example implementation, the PQRE_ID parameter identifies the PQRE device 110 whose QoS priority is to be temporarily reassigned (e.g., upgraded or promoted) in response to the PQRS_INVITE message 705. For example, the PQRE_ID parameter could correspond to an IP address, a landline phone number, a mobile phone number, etc., identifying the PQRE device 110. The App_Type parameter identifies the applications (or services) accessed (e.g., launched) on the PQRI device 105 by the PQRE and, in particular, the PQRE device 110 for which associated network traffic is to be the subject of a temporary QoS priority reassignment (e.g., upgrade or promotion). For example, the App_Type parameter can be set to “ALL” to indicate that QoS priorities of network traffic associated with all application types is to be reassigned (e.g., upgraded or promoted). In other example, the App_Type parameter can be set to “DATA_DOWNLOAD_ONLY,” DATA_UPLOAD_ONLY,” “VIDEO_ONLY,” “VOICE_ONLY,” etc., or any combination thereof, to indicate that network traffic associated with only the indicated application type(s) is to be reassigned (e.g., upgraded or promoted). The Invocation_Period and Total_Data_Amount parameters correspond to termination criteria specified by the PQRS to which the PQRI has subscribed. In particular, Invocation_Period specifies the maximum period during which a temporary QoS priority reassignment can be active, and Total_Data_Amount specifies the total amount of network traffic that can be exchanged during the specified Invocation_Period.
Upon receipt of the PQRS_INVITE message 705, the NCI 135 performs an authentication and invocation procedure 710 to determine whether the PQRI is authorized to temporarily reassign the QoS priority associated with the PQRE device 110 and, if so, whether the temporary QoS priority reassignment can be invoked under the present circumstances. For example, the PQRS authentication processor 335 in the NCI 135 determines whether the PQRI is subscribed to a PQRS and, if so, whether the PQRS covers the PQRE device 110. Additionally, the PQRS invocation processor 325 in the NCI 135 evaluates one or more invocation criteria as described above to determine whether to allow the temporary QoS priority reassignment to be performed.
In the example message sequence 700 of
In response to determining that the temporary QoS priority reassignment initiated by receipt of the PQRS_INVITE message 705 can be invoked, the NCI 135 also performs a PQRS invocation registration procedure 730. To perform the PQRS invocation registration procedure 730, the PQRS invocation processor 325 initializes the invocation timer 350 in the NCI 135 with the Invocation_Period parameter value included in the PQRS_INVITE message 705. Additionally or alternatively, the PQRS invocation processor 325 initializes the traffic monitor 355 in the NCI 135 with the Total_Data_Amount parameter value included in the PQRS_INVITE message 705.
After performing the PQRS invocation registration procedure 730, the NCI 135 sends a PQRS_INVITE message 735 containing the PQRE_ID and App_Type parameters to the NCE 140 to initiate PQRE-side preparations for the temporary QoS priority reassignment procedure. In response, the NCE 140 performs an authorization and ENE identification procedure 740. For example, if voluntary invocation is configured, the PQRS invocation processor 520 in the NCE 140 evaluates one or more authorization criteria as described above to determine whether to allow the temporary QoS priority reassignment being initiated by the PQRS_INVITE message 735. If involuntary invocation is configured, the NCE 140 automatically determines that the temporary QoS priority reassignment being initiated by the PQRS_INVITE message 735 is allowed. In either case, if the temporary QoS priority reassignment is allowed, the ENE information processor 530 in the NCE 140 then determines identification information as described above for the PQRE device 110 whose QoS priority is to be temporarily reassigned, and for the ENE 125 serving the PQRE device 110.
In the example message sequence 700 of
Subsequently, network traffic 765 is exchanged between the PQRI device 105 and the PQRE device 110 in the service provider's communication network 100 using the temporarily reassigned (e.g., upgraded or promoted) QoS priority or priorities stored in the marking table 150 of the INE 115 and the marking table 155 of the ENE 125. The example message sequence diagram 700 of
An example message sequence diagram 800 corresponding to a scenario in which the NCI 135 determines that a temporary QoS priority reassignment is not able to be invoked is depicted in
Continuing with the description of the message sequence diagram 800 of
An example message sequence diagram 900 corresponding to a scenario in which the NCE 140 determines that a temporary QoS priority reassignment is not authorized is depicted in
Continuing with the description of the message sequence diagram 900 of
Also in response to receiving the PQRE_REJECT message 905 (or after a timeout period has expired without receipt of the PQRE_ACK message 755), the NCI 135 performs a PQRS termination procedure 915 in which the PQRS termination processor 345 in the NCI 135 decrements the invocation counter 330 and resets the invocation timer 350 and the traffic monitor 355 to undo the failed PQRS invocation. Additionally, the PQRS termination processor 345 in the NCI 135 sends a PQRS_CLEAR message 920 to the INE 115. In response to the PQRS_CLEAR message 920, the PQRS marking table processor 425 in the INE 115 performs a PQRS marking entry clearing procedure 925 to clear any entries in the PQRS marking table 150 created by the failed PQRS invocation. The example message sequence diagram 900 of
An example message sequence diagram 1000 corresponding to a scenario in which a temporary QoS priority reassignment is terminated is depicted in
When one or more of the termination criteria are met, the PQRS termination processor 345 in the NCI 135 sends a PQRS_TERMINATE message 1010 via the NCE 140 to the ENE 125. In response to the PQRS_TERMINATE message 1010, the PQRS marking table processor 625 in the ENE 125 performs a PQRS marking entry clearing procedure 925 to clear any entries in the PQRS marking table 155 corresponding to the QoS priority reassignment that has been terminated. Similarly, the NCI 135 sends a PQRS_TERMINATE message 1020 to the INE 115. In response to the PQRS_TERMINATE message 1020, the PQRS marking table processor 425 in the INE 115 performs a PQRS marking entry clearing procedure 1025 to clear any entries in the PQRS marking table 150 corresponding to the QoS priority reassignment that has been terminated.
Subsequently, network traffic 1030 continues to be exchanged between the PQRI device 105 and the PQRE device 110 in the service provider's communication network 100 and, thus, any application or service of the PQRI being accessed by the PQRE via the PQRE device 110 need not be terminated. However, the network traffic 1030 will no longer be marked with the temporary reassigned (e.g., upgraded or promoted) QoS priority. The example message sequence diagram 1000 of
Flowcharts representative of example machine readable instructions that may be executed to implement the example communication networks 100 and/or 200, the example PQRI device 105, the example PQRE device 110, the example INE 115, the example network 120, the example ENE 125, the example data traffic path 130, the example NCI 135, the example NCE 140, the example PQRS control path 145, the example PQRS marking tables 150 and 155, the example PQRI device 205, the example PQRS server 210, the example data traffic path 215, the example network interface 305, the example PQRS invocation processor 325, the example invocation counter 330, the example PQRS error processor 335, the example PQRS authentication processor 340, the example PQRS termination processor 345, the example invocation timer 350, the example traffic monitor 355, the example network interface 405, the example PQRS marking table 150, the example PQRS marking table processor 425, the example data packet marker 430, the example network interface 505, the example PQRS invocation processor 520, the example PQRS authorization processor 525, the example ENE information processor 530, the example PQRS termination processor 535, the example network interface 605, the example PQRS marking table 155, the example PQRS marking table processor 625 and/or the example data packet marker 630 are shown in
In these examples, the machine readable instructions represented by each flowchart may comprise one or more programs for execution by: (a) a processor, such as the processor 1712 shown in the example computer 1700 discussed below in connection with
Further, although the example machine readable instructions are described with reference to the flowcharts illustrated in
Example machine readable instructions 1100 that may be executed to implement the NCI 135 of
If PQRI authentication is not successful (block 1115), control proceeds to block 1120 at which the PQRS error processor 335 in the NCI 135 generates an invocation error message having a parameter value indicating that an authentication failure has occurred. Control then proceeds to block 1125 at which the PQRS error processor 335 causes a PQRI_REASON message 805 based on the invocation error message generated at bock 1120 to be returned to the PQRI device 105 or 205 that sent the PQRS_INVITE message 705 received at block 1105. Control then returns to block 1105 at which the NCI 135 idles or performs other non-PQRS processing until the NCI 135 receives another PQRS_INVITE message 705.
However, if authorization is successful (block 1115), control proceeds to block 1130 at which the PQRS invocation processor 325 in the NCI 135 evaluates one or more invocation criteria (or invocation rules) to determine whether to invoke the temporary QoS priority reassignment initiated by receipt of the PQRS_INVITE message 705 at block 1105. For example, at block 1130 the PQRS invocation processor 325 evaluates whether an invocation frequency limiting the total number of temporary QoS priority reassignments allowed to be performed during a given time period has been exceeded, and/or whether a concurrent invocation limit limiting a total number of temporary QoS priority reassignments allowed to be active at any given time has been exceeded. If evaluation of the invocation criteria is unsuccessful (block 1135), control proceeds to block 1120 at which the PQRS error processor 335 in the NCI 135 generates an invocation error message having a parameter value indicating which of the invocation criteria was not met. Control then proceeds to block 1125 at which the PQRS error processor 335 causes a PQRI_REASON message 805 based on the invocation error message generated at bock 1120 to be returned to the PQRI device 105 or 205 that sent the PQRS_INVITE message 705 received at block 1105. Control then returns to block 1105 at which the NCI 135 idles or performs other non-PQRS processing until the NCI 135 receives another PQRS_INVITE message 705.
If, however, evaluation of the invocation criteria is successful (block 1135), control proceeds to block 1140 at which the NCI 135 sends a PQRI_ACK message 715 to the INE 115 serving the PQRI 105 or 205 responsible for the PQRS_INVITE message 705 received at block 1105. Control then proceeds to block 1145 at which the NCI 135 registers the temporary QoS priority reassignment to be performed. For example, at block 1145 the PQRS invocation processor 325 in the NCI 135 initializes the invocation timer 350 with the Invocation_Period parameter value included in the PQRS_INVITE message 705 received at block 1105. Additionally or alternatively, the PQRS invocation processor 325 initializes the traffic monitor 355 with the Total_Data_Amount parameter value included in the received PQRS_INVITE message 705. Control then proceeds to block 1150 at which the NCI 135 sends a PQRS_INVITE message 735 to the NCE 140 serving the PQRE device 110 corresponding to the PQRE_ID parameter value contained in the PQRS_INVITE message 705 received at block 1105. The PQRS_INVITE message 735 also contains the PQRE_ID and App_Type parameters provided in the received PQRS_INVITE message 705.
Next, control proceeds to block 1155 of
If the PQRS termination processor 345 determines that the invocation period has expired (block 1160) or the total amount of permissible traffic at the reassigned QoS level has been exceeded (block 1165), or both, control proceeds to block 1170 at which the PQRS termination processor 345 causes a PQRS_TERMINATE message 1010 to be sent to the ENE 125 serving the PQRE device 110 identified in the received PQRS_INVITE message 705 and whose QoS priority was temporary reassigned. However, if neither the invocation period has expired (block 1160) nor the total amount of traffic has been exceeded (block 1165), control proceeds to block 1175 at which the NCI 135 determines whether a PQRE_REJECT message 905 was received indicating that authorization of the QoS priority reassignment failed. If the PQRS_REJECT 905 message has not been received (block 1175), control returns to block 1155 and blocks subsequent thereto at which the termination processor 345 in the NCI 135 continues to evaluate the one or more termination criteria.
If, however, the PQRS_REJECT 905 message has been received (block 1175) or the PQRS_TERMINATE message 1010 has been sent at block 1170, control proceeds to block 1180 at which the PQRS termination processor 345 performs a PQRS termination procedure to clear/reset any data or processing associated with the PQRS invocation being terminated, and to cause a PQRS_TERMINATE message 1020 to be sent to the PQRI device 105 or 205 responsible for sending the PQRS_INVITE message 705. For example, at block 1180 the PQRS termination processor 345 decrements the invocation counter 330 and resets the invocation timer 350 and the traffic monitor 355 in the NCI 135 to terminate PQRS invocation. Control then returns to block 1105 of
Example machine readable instructions 1200 that may be executed to manage the PQRS marking table 150 in the INE 115 of
When the PQRS_ACK message 715 is received, control proceeds to block 1210 at which the PQRS marking table processor 425 in the INE 115 creates an entry in its PQRS marking table 150 to store each reassigned (e.g., upgraded or promoted) QoS priority value to be used to mark network traffic identified by the PQRS_ACK message 715 received at block 1205. For example, at block 1210 an entry in the PQRS marking table 150 is created that is indexed by at least the PQRE device 110 represented by the PQRE_ID parameter and the traffic type represented by the App_Type parameter.
Next, after the table entry is created at block 1210, control proceeds to block 1215 at which the INE 115 monitors the state of the PQRS invocation and, in particular, for receipt of a PQRS_CLEAR message 920 or a PQRS_CLEAR message 1020 indicating that the PQRS invocation corresponding to the table entry created at block 1210 is to be terminated. If a PQRS_CLEAR message 920 or 1020 is received (block 1220), control proceeds to block 1225 at which the PQRS marking table processor 425 clears any entries in the PQRS marking table 150 created at block 1210. Control then returns to block 1205 at which the INE 115 idles or performs other non-PQRS processing until another PQRS_ACK message 715 is received from the NCI 135.
Example machine readable instructions 1300 that may be executed to implement the NCE 140 of
If authorization is not successful (block 1315), control proceeds to block 1320 at which the PQRS authorization processor 525 in the NCE 140 generates an error code having a value indicating that an authorization failure has occurred. Control then proceeds to block 1325 at which the PQRS authorization processor 525 causes a PQRE_REJECT message 905 based on the authentication error code generated at bock 1320 to be returned to the NCI 135 that sent the PQRS_INVITE message 735 received at block 1305. Control then returns to block 1305 at which the NCE 140 idles or performs other non-PQRS processing until the NCE 140 receives another PQRS_INVITE message 735 sent by the NCI 135.
However, if authentication is successful (block 1315), control proceeds to block 1330 at which the ENE information processor 530 in the NCE 140 process the parameters contained in the received PQRS_INVITE message 735 (e.g., such as the PQRE_ID parameter) to determine identification information, such as network routing information, destination IP addresses, etc., for the PQRE device 110 whose QoS priority is to be temporarily reassigned, and for the ENE 125 serving the identified PQRE device 110.
Control then proceeds to block 1335 at which the NCE 140 sends a PQRE_ACK message 735 to the NCI 135 serving the PQRI 105 or 205 responsible for the PQRS_INVITE message 735 received at block 1305. Control then proceeds to block 1340 at which the NCE 140 sends a PQRS_INVITE message 745 to the ENE 125 identified at block 1330 as serving the PQRE device 110. The PQRS_INVITE message 745 sent at block 1340 also contains the PQRE_ID and App_Type parameters provided in the PQRS_INVITE message 735 received at block 1305.
Next, control proceeds to block 1345 at which the PQRS termination processor 535 in the NCE 140 perform a termination monitoring procedure and, in particular, monitors for receipt of a PQRS_TERMINATE message 1010 from the NCI 135 serving the PQRI device 105 or 205 responsible for the current PQRS invocation. When a PQRS_TERMINATE message 1010 is received (block 1350), control proceeds to block 1355 at which the PQRS termination processor 535 causes the PQRS_TERMINATE message 1010 to be forwarded to the ENE 125 identified at block 1330 as serving the PQRE device 110 whose QoS priority was temporarily reassigned. Control then returns to block 1305 at which the NCE 140 idles or performs other non-PQRS processing until the NCE 140 receives another PQRS_INVITE message 735 from the NCI 135.
Example machine readable instructions 1400 that may be executed to manage the PQRS marking table 155 in the ENE 125 of
When the PQRS_INVITE message 735 is received, control proceeds to block 1410 at which the PQRS marking table processor 625 in the ENE 125 creates an entry in its PQRS marking table 150 to store each reassigned (e.g., upgraded or promoted) QoS priority value to be used to mark network traffic identified by the PQRS_INVITE message 735 received at block 1405. For example, at block 1410 an entry in the PQRS marking table 155 is created that is indexed by at least the PQRI device 105 that is responsible for (e.g., the source of) the PQRS_INVITE message 735 or the PQRS server 210 identified in the PQRS_INVITE message 735, and the traffic type represented by the App_Type parameter.
Next, after the table entry is created at block 1410, control proceeds to block 1415 at which the ENE 125 monitors the state of the PQRS invocation and, in particular, for receipt of a PQRS_TERMINATE message 1010 indicating that the PQRS invocation corresponding to the table entry created at block 1410 is to be terminated. If the PQRS_TERMINATE message 1010 is received (block 1420), control proceeds to block 1425 at which the PQRS marking table processor 625 clears any entries in the PQRS marking table 155 created at block 1410. Control then returns to block 1405 at which the ENE 125 idles or performs other non-PQRS processing until another PQRS_INVITE message 735 is received from the NCI 135.
Example machine readable instructions 1500 that may be executed to implement data marking in the INE 115 of
When such a data packet is received, control proceeds to block 1510 at which the INE 115 determines whether the destination of the received data packet corresponds to a PQRE device 110 subject to a PQRS invocation (or, in other words, whose QoS priority has been temporarily reassigned). If the destination of the received data packet is such a PQRE device 110 (block 1510), control proceeds to block 1515 at which the data packet marker 430 in the INE 115 retrieves the appropriate reassigned (e.g., upgraded or promoted) QoS priority from an entry in the PQRS marking table 150 indexed by: (1) the particular PQRI device 105 or PQRS server 210 from which the data packet was received, (2) the particular PQRE device 110 that is the destination of the data packet, and/or (3) the application (or service) type of the data packet being exchanged. Next, control proceeds to block 1520 at which the data packet marker 430 marks the received data packet with the QoS priority retrieved from the PQRS marking table 150 at block 1515.
Then, after the received data packet is marked at block 1520, or if the destination of the packet is not a PQRE device 110 subject to a PQRS invocation (block 1510), control proceeds to block 1525 at which the INE 115 sends the network traffic data packet on to its destination (e.g., the PQRE device 110). Control then returns to block 1505 at which the INE 115 idles or performs other non-PQRS processing until the INE 115 receives another network traffic data packet from the PQRI device 105 or PQRS server 210 served by the INE 115.
Example machine readable instructions 1600 that may be executed to implement data marking in the ENE 125 of
When such a data packet is received, control proceeds to block 1610 at which the ENE 125 determines whether the received data packet is subject to a PQRS invocation (or, in other words, has a QoS priority that is to be temporarily reassigned). For example, at block 1610 the ENE 125 determines whether the destination of the received data packet is a PQRI device 105 or PQRS server 205 associated with a PQRI that has used the PQRS to perform a temporary QoS priority reassignment of network traffic exchanged with the PQRE device 110 providing the received data packet. If the received data packet subject to a PQRS invocation (block 1610), control proceeds to block 1615 at which the data packet marker 630 in the ENE 125 retrieves the appropriate reassigned (e.g., upgraded or promoted) QoS priority from an entry in the PQRS marking table 155 indexed by: (1) the particular PQRE device 110 from which the data packet was received, (2) the particular PQRI device 105 or PQRS server 210 that is the destination of the data packet, and/or (3) the application (or service) type of the data packet being exchanged. Next, control proceeds to block 1620 at which the data packet marker 630 marks the received data packet with the QoS priority retrieved from the PQRS marking table 155 at block 1615.
Then, after the received data packet is marked at block 1620, or if the received data packet is not subject to a PQRS invocation (block 1610), control proceeds to block 1625 at which the ENE 125 sends the network traffic data packet on to its destination (e.g., the PQRI device 105 or the PQRS server 210). Control then returns to block 1605 at which the ENE 125 idles or performs other non-PQRS processing until the ENE 125 receives another network traffic data packet from the PQRE device 110 served by the ENE 125.
The system 1700 of the instant example includes a processor 1712 such as a general purpose programmable processor. The processor 1712 includes a local memory 1714, and executes coded instructions 1716 present in the local memory 1714 and/or in another memory device. The processor 1712 may execute, among other things, the machine readable instructions represented in
The processor 1712 is in communication with a main memory including a volatile memory 1718 and a non-volatile memory 1720 via a bus 1722. The volatile memory 1718 may be implemented by Static Random Access Memory (SRAM), Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM) and/or any other type of random access memory device. The non-volatile memory 1720 may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory 1718, 1720 is typically controlled by a memory controller (not shown).
The computer 1700 also includes an interface circuit 1724. The interface circuit 1724 may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), and/or a third generation input/output (3GIO) interface.
One or more input devices 1726 are connected to the interface circuit 1724. The input device(s) 1726 permit a user to enter data and commands into the processor 1712. The input device(s) can be implemented by, for example, a keyboard, a mouse, a touchscreen, a track-pad, a trackball, an isopoint and/or a voice recognition system.
One or more output devices 1728 are also connected to the interface circuit 1724. The output devices 1728 can be implemented, for example, by display devices (e.g., a liquid crystal display, a cathode ray tube display (CRT)), by a printer and/or by speakers. The interface circuit 1724, thus, typically includes a graphics driver card.
The interface circuit 1724 also includes a communication device such as a modem or network interface card to facilitate exchange of data with external computers via a network (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.). As such, the interface circuit 1724 may implement the network interfaces 305, 405, 505 and/or 605.
The computer 1700 also includes one or more mass storage devices 1730 for storing software and data. Examples of such mass storage devices 1730 include floppy disk drives, hard drive disks, compact disk drives and digital versatile disk (DVD) drives. The mass storage device 1730 may implement the marking tables 150 and/or 155. Alternatively, the volatile memory 1718 may implement the marking tables 150 and/or 155.
At least some of the above described example methods and/or apparatus are implemented by one or more software and/or firmware programs running on a computer processor. However, dedicated hardware implementations including, but not limited to, application specific integrated circuits, programmable logic arrays and other hardware devices can likewise be constructed to implement some or all of the example methods and/or apparatus described herein, either in whole or in part. Furthermore, alternative software implementations including, but not limited to, distributed processing or component/object distributed processing, parallel processing, or virtual machine processing can also be constructed to implement the example methods and/or apparatus described herein.
It should also be noted that the example software and/or firmware implementations described herein are stored on a tangible storage medium, such as: a magnetic medium (e.g., a magnetic disk or tape); a magneto-optical or optical medium such as an optical disk; or a solid state medium such as a memory card or other package that houses one or more read-only (non-volatile) memories, random access memories, or other re-writable (volatile) memories; or a signal containing computer instructions. A digital file attached to e-mail or other information archive or set of archives is considered a distribution medium equivalent to a tangible storage medium. Accordingly, the example software and/or firmware described herein can be stored on a tangible storage medium or tangible distribution medium such as those described above or successor storage media.
To the extent the above specification describes example components and functions with reference to particular standards and protocols, it is understood that the scope of this patent is not limited to such standards and protocols. For instance, each of the standards for Internet and other packet switched network transmission (e.g., Transmission Control Protocol (TCP)/Internet Protocol (IP), User Datagram Protocol (UDP)/IP, HyperText Markup Language (HTML), HyperText Transfer Protocol (HTTP)) represent examples of the current state of the art. Such standards are periodically superseded by faster or more efficient equivalents having the same general functionality. Accordingly, replacement standards and protocols having the same functions are equivalents which are contemplated by this patent and are intended to be included within the scope of the accompanying claims.
Additionally, although this patent discloses example systems including software or firmware executed on hardware, it should be noted that such systems are merely illustrative and should not be considered as limiting. For example, it is contemplated that any or all of these hardware and software components could be embodied exclusively in hardware, exclusively in software, exclusively in firmware or in some combination of hardware, firmware and/or software. Accordingly, while the above specification described example systems, methods and articles of manufacture, persons of ordinary skill in the art will readily appreciate that the examples are not the only way to implement such systems, methods and articles of manufacture. Therefore, although certain example methods, apparatus and articles of manufacture have been described herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the appended claims either literally or under the doctrine of equivalents.
| Number | Name | Date | Kind |
|---|---|---|---|
| 6148337 | Estberg et al. | Nov 2000 | A |
| 6226277 | Chuah | May 2001 | B1 |
| 6683853 | Kannas et al. | Jan 2004 | B1 |
| 6970423 | Chuah | Nov 2005 | B2 |
| 7290028 | Brabson et al. | Oct 2007 | B2 |
| 20020152319 | Amin et al. | Oct 2002 | A1 |
| 20050064821 | Hedberg et al. | Mar 2005 | A1 |
| 20050128963 | Gazda et al. | Jun 2005 | A1 |
| 20070002765 | Kadaba et al. | Jan 2007 | A1 |
| 20080132269 | Shen et al. | Jun 2008 | A1 |
| 20080175255 | Krstulich et al. | Jul 2008 | A1 |
| 20090010156 | Song et al. | Jan 2009 | A1 |
| 20090077256 | Madan | Mar 2009 | A1 |
| 20090138596 | Song | May 2009 | A1 |
| 20090178058 | Stillwell et al. | Jul 2009 | A1 |
| 20110113480 | Ma et al. | May 2011 | A1 |
| 20110208853 | Castro-Castro et al. | Aug 2011 | A1 |
| 20120059943 | Castro Castro et al. | Mar 2012 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20110051731 A1 | Mar 2011 | US |
