Controlling data access and rate in a network

Concepts and technologies are disclosed herein for controlling data access and rate in a network. An enforcement application can detect a request for a data session and determine how and when the requested data session is to be established. The enforcement application can consider various data, input obtained at the user device, and/or other considerations including subscriber data and network data. Based upon these data, the enforcement application can determine network congestion, available resources, available bandwidth, an allocation rate of congestion credits (“credits”) for the user, a flow rate of the credits from an account to a credit pool, and a usage rate of the credits from the credit pool. The enforcement application can be configured to enforce the usage rate against a data session and to issue one or more commands to control the data session.

BACKGROUND

This application relates generally to network control. More specifically, the disclosure provided herein relates to controlling data access and rate in a network.

In some modern communication networks such as some cellular networks, data communications have become even more prevalent than voice communications. As such, some communication network operators have recently shifted network growth efforts from increasing capacity for voice communications to efforts for growing data communications portions of the communication networks in an effort to provide customers with quick and reliable data communications. Notwithstanding network operators' efforts to increase the capacity of data portions of these communications networks, congestion continues to be a problem for many network operators.

Some communications networks may process millions or even billions of requests for data communications per day. The requests for data communications can effectively ask the network to establish a data session between the requestor and some source of data such as a media server, an email server, or the like. The network may or may not inspect the requests to determine priority and/or importance of the requests. Rather, the network may simply establish the requested session on a first-come-first-served basis.

While network traffic is relatively predictable, current events or other trends may cause temporary or even prolonged spikes in data traffic. These spikes may be difficult to predict. Additionally, because data resources of the network typically are finite, there may be no way to quickly adjust network operations to accommodate such a spike in data traffic. Furthermore, users sometimes pay for and expect reliable and fast data communications. These users expect their data sessions to begin almost immediately. Because the users may not be aware of network congestion at any given time, these users expect data delivery to be consistent and any delay or performance degradation can affect a user's perception of the network provider. Thus, network congestion can not only affect performance of the network, but also can affect user satisfaction with the network in general.

SUMMARY

The present disclosure is directed to controlling data access and rate in a network. An application or service such as an application executing at a user device can request data from a data source by way of a request. The user device can transmit the request to the data source. An enforcement application executing at a server computer can be configured to detect the request and/or to be called or accessed by the data source to determine how and when the data source is to respond to the request. The enforcement application can be configured to use congestion credits (“credits”) to control the requested data session based upon various data, input obtained at the user device, and/or other considerations.

In particular, the enforcement application can be configured to obtain subscriber data and network data. Based upon these data, the enforcement application can determine network congestion, available resources, available bandwidth, a credit allocation rate (“allocation rate”) of credits for the user, a credit flow rate (“flow rate”) of the credits from an account to a credit pool, and a credit usage rate (“usage rate”) of the credits from the credit pool. In some embodiments, charging and billing systems can be configured to communicate with the user device to determine the usage rate, and the charging and billing systems can provide that information to the enforcement application as part of the subscriber data. In some embodiments, the charging and billing systems can generate one or more usage rate options and transmit the options to the user device as or within options data that can be presented at the user device. A selection or decision relating to the options can be represented in traffic management data generated at the user device and transmitted to the charging and billing systems.

The enforcement application can be configured to enforce the usage rate against a data session. The enforcement application also can be configured to issue one or more commands to the data source to control the data session. For example, the enforcement application can monitor the credit pool and apply the usage rate to the credit pool. If the credit pool runs out of credits, the enforcement application can issue commands to terminate the data session, to order a query to the user device to determine if a user wants to buy more credits, to change a guaranteed or applied QoS and/or other quality aspect of the data session, and/or to take other actions. As such, the enforcement application can use credits to control data access in networks. The functionality of the enforcement application described herein also can be used to reward “good” behavior on a network such as not using congested resources.

According to one aspect of the concepts and technologies disclosed herein, a device is disclosed. The device can include a processor and a memory storing computer-executable instructions. When the computer-executable instructions are executed by the processor, the processor can detect a data session request, prompt, at the device, for a traffic control decision specifying a credit usage rate, obtain the traffic control decision at the device, generate traffic management data including an indication of the traffic control decision, and provide the traffic management data to a network device.

According to some embodiments, the device can be configured to obtain options data from a charging and billing system, the options data specifying an option including the credit usage rate, present the options data in a user interface, and detect a selection of the option via the user interface. The user interface can include a UI control for presenting an option including the credit usage rate, and a further UI control for presenting a further option including a further credit usage rate. The device also can be configured to present a user interface for viewing options associated with a credit account used to control network access. The user interface can include a field for presenting a credit balance in the credit account, a further field for presenting accredit subscription plan associated with the credit account, the credit subscription plan including a credit allocation rate, a UI control for purchasing credits, and a further UI control for modifying the credit subscription plan.

According to another aspect of the concepts and technologies disclosed herein, a method is disclosed. The method can include detecting a data session request, the data session request including a request for a data session between a data source and a user device, obtaining, at a server computer executing an enforcement application, network data indicating a network condition, determining, based at least partially upon the network data, a credit usage rate, and applying the credit usage rate during a data session.

In some embodiments, the method can include obtaining subscriber data and determining, based at least partially upon the subscriber data, the credit usage rate. The subscriber data can include subscriber information and a credit subscription plan. In some embodiments, the subscriber data can include the credit usage rate, wherein the credit usage rate can be obtained from the user device. In some embodiments, determining the credit usage rate can include generating a data session credit usage rate option, transmitting the data session credit usage rate option to the user device, and obtaining a selection of the data session credit usage rate from the user device.

In some embodiments, applying the credit usage rate further can include determining a time associated with the credit usage rate, initiating a timer set to the time, and determining if the time has passed. In response to a determination that the time has passed, the method can include removing a credit from a credit pool associated with the user device. The method also can include determining if additional credits are available in an account associated with the user device, and in response to a determination that additional credits are not available, issuing a command to terminate the data session. In some embodiments, the method can also include determining if additional credits are available in an account associated with the user device, and in response to a determination that additional credits are not available, issuing a command to generate a prompt at the user device to purchase additional credits. Applying the credit usage rate further can include allocating credits to a credit account associated with the user device at an allocation rate, adding credits from the credit account to a credit pool at a flow rate, and removing credits from the credit pool at the credit usage rate.

According to yet another aspect, a computer storage medium is disclosed. The computer storage medium can have computer-executable instructions stored thereon that, when executed by a processor, cause the processor to perform operations including detecting a request for a data session between a data source and a user device, obtaining network data indicating a network condition, determining, based at least partially upon the network data, a credit usage rate, and applying the credit usage rate during a data session.

In some embodiments, the operations can further include obtaining subscriber data including subscriber information and a credit subscription plan, and determining, based at least partially upon the subscriber data, the credit usage rate. In some embodiments, the subscriber data can include the credit usage rate. The credit usage rate can be obtained from the user device. In some embodiments, determining the credit usage rate can include generating a data session credit usage rate option, issuing a command to transmit the data session credit usage rate option to the user device, and obtaining a selection of the data session credit usage rate from the user device.

In some embodiments, the operations can also include determining a time associated with the credit usage rate, initiating a timer set to the time, determining if the time has passed, and in response to a determination that the time has passed, removing a credit from a credit pool associated with the user device. The operations also can include determining if additional credits are available in an account, and in response to a determination that additional credits are not available in the account, issuing a command to terminate the data session. Applying the credit usage rate during the data session can include allocating credits to a credit account associated with the user device at an allocation rate, adding credits from the credit account to a credit pool at a flow rate, and removing credits from the credit pool at the credit usage rate. In some embodiments, the operations also can include determining a time associated with the credit usage rate, initiating a timer set to the time, determining if the time has passed, and in response to a determination that the time has passed, removing a credit from the credit pool associated with the user device.

The credit usage rate also can be defined, in some embodiments, as a number of bytes transferred. Thus, a number of transferred bytes may cost one credit, or the like. Thus, some embodiments of the concepts and technologies disclosed herein can determine a number of bytes associated with the credit usage rate, initiate a counter to count bytes transferred, determine if the number of bytes have been transferred, and in response to a determination that the number of bytes have been transferred, removing a credit from the credit pool associated with the user device.

DETAILED DESCRIPTION

The following detailed description is directed to controlling data access and rate in a network. According to various embodiments of the concepts and technologies disclosed herein, a user device can request data from a data source by way of a request. The user device can transmit the request to the data source. An enforcement application executing at a server computer can be configured to detect the request and/or to be called or accessed by the data source to determine how and when the data source is to respond to the request. The enforcement application can be configured to use credits to control the requested data session based upon various data, input obtained at the user device, and/or other considerations.

In particular, the enforcement application can be configured to obtain subscriber data and network data. Based upon these data, the enforcement application can determine network congestion, available resources, available bandwidth, an allocation rate of credits for the user, a flow rate of the credits from an account to a credit pool, and a usage rate of the credits from the credit pool. In some embodiments, charging and billing systems can be configured to communicate with the user device to determine the usage rate, and the charging and billing systems can provide that information to the enforcement application as part of the subscriber data. In some embodiments, the charging and billing systems can generate one or more usage rate options and transmit the options to the user device as or within options data that can be presented at the user device. A selection or decision relating to the options can be represented in traffic management data generated at the user device and transmitted to the charging and billing systems.

The enforcement application can be configured to enforce the usage rate against a data session. The enforcement application also can be configured to issue one or more commands to the data source to control the data session. For example, the enforcement application can monitor the credit pool and apply the usage rate to the credit pool. If the credit pool runs out of credits, the enforcement application can issue commands to terminate the data session, to order a query to the user device to determine if a user wants to buy more credits, to change a guaranteed or applied QoS and/or other quality aspect of the data session, and/or to take other actions. As such, the enforcement application can use credits to control data access in networks.

Referring now toFIG. 1, aspects of an operating environment100for various embodiments of the concepts and technologies disclosed herein for controlling data access and rate in a network will be described, according to an illustrative embodiment. The operating environment100shown inFIG. 1includes a user device102operating in communication with and/or as part of a communications network (“network”)104. According to various embodiments, the functionality of the user device102can be provided by one or more mobile telephones, smartphones, or the like. The functionality of the user device102also can be provided by one or more personal computers (“PCs”), server computers, tablet computers, laptop computers, set-top boxes, other computing systems, and the like. For purposes of describing the concepts and technologies disclosed herein, the user device102is described as a smartphone. It should be understood that this embodiment is illustrative, and should not be construed as being limiting in any way.

The user device102can execute an operating system106and one or more application programs such as a traffic control application108. The operating system106is a computer program for controlling the operation of the user device102. The traffic control application108is an executable program configured to execute on top of the operating system106to provide various functionality described herein for controlling data access and rate in a network.

According to various embodiments, the traffic control application108can include, or can be included as a part of, a natively executed application, a Web application, and/or another type of application. The traffic control application108can be configured to control one or more aspects of a data session over which the user device102uses, obtains, and/or relies upon data110obtained from one or more data sources112. For example, the traffic control application108can control a data session used by a Web browser application executed at the user device102to obtain the data110from the data source112, wherein the data110can correspond to a Web page, multimedia content, applications, or the like. Because the data110can be obtained from almost any type of data source112, it should be understood that these embodiments are illustrative, and should not be construed as being limiting in any way.

According to various embodiments, the user device102can generate one or more requests114for the data110and transmit the requests114to the data source112. For example, the user device102can access a resource hosted or provided by the data source112, and the request114can therefore correspond to a request to access the resource. As such, it should be understood that the user device102can request access to the data110in a number of ways such as, for example, accessing the data source112to use or read the data110, requesting the data110explicitly by way of a request114, and/or in other ways. In response to receiving the requests114, the data source112can provide the requested data110by way of a data session between the data source112and the user device102. According to various embodiments of the concepts and technologies disclosed herein, the user device102and/or other devices can be configured to control various aspects of the data session. In some embodiments described herein, the data source112can be configured to conduct the data session with the user device102in accordance with one or more commands116received from one or more network nodes, devices or systems. The commands116can set or define a bandwidth, communication speed, and/or quality of service (“QoS”) of the data session. The determination of these and other aspects of the data session are described in more detail below.

In the embodiment shown inFIG. 1, a policy enforcement application or module (“enforcement application”)118can be hosted by a computing device such as, for example, a server computer120. In some embodiments, the enforcement application118and the server computer120can collectively provide functionality of a policy enforcement function (“PEF”), though this is not necessarily the case. The enforcement application118can be configured to detect the requests114received by the data source112and to issue the commands116for controlling one or more data sessions between the data source112and the user device102, for example, a data session for providing the data110in response to one or more of the requests114. It should be understood that these embodiments are illustrative, and should not be construed as being limiting in any way.

In some embodiments, the enforcement application118can be configured to enforce various communication policies on communications including, but not limited to, data communications between the user device102and the data source112. These communication policies can be based, at least partially, upon subscription plans, network conditions, traffic conditions, user and/or network communication limits, available network resources, other information, combinations thereof, or the like. According to some embodiments, the enforcement application118can be configured to track and enforce user congestion credit balances and/or congestion credit accounts.

In particular, the enforcement application118can be configured to determine a user or device allotment of congestion credits (“credits”)122, which can be allocated to a user congestion credit allocation or account (“account”)124. The credits122can be allocated to the account124at an allocation rate ra. The allocation rate racan correspond, according to various implementations, to a subscription plan for credits122. Thus, for example, a user subscription or credit subscription can correspond to a daily, monthly, or yearly credit allocation rate ra. In some embodiments, for example, the allocation rate racan include five hundred credits per month, one thousand credits per month, five credits per week, ten credits per day, twenty five credits per day, one credit per hour, one credit per minute, and/or other numbers of credits per any desired measure of time. Because the allocation rate racan be almost any number and almost any time measure, it should be understood that these embodiments are illustrative, and should not be construed as being limiting in any way.

As shown inFIG. 1, the credits122can be allocated to the account124at the allocation rate ra. In the above example wherein the allocation rate racorresponds to five hundred credits per month, five hundred credits122can be added to an account124associated with a user at a designated time such as, for example, a particular day of the month, a particular point of time in a billing cycle, e.g., a month, and/or at other times. It should be understood that the enforcement application118may or may not maintain an account124for each user or device. Rather, the enforcement application118can obtain information such as, for example, a current balance, an allocation rate ra, and an account balance to perform the functionality described herein.

According to various embodiments, the enforcement application118is configured to draw credits122from the account124associated with a user or device at a flow rate rf. The credits122drawn from the account124can be moved into a credit pool126associated with the user or device. As such, the credits122can flow from the account124to the credit pool at the rate rf. According to various embodiments, the enforcement application118moves the credits122from the account124to the credit pool126during any times at which the user or device is not involved in a data session. In some other embodiments, the enforcement application118moves the credits122from the account124to the credit pool126during a data session. In yet other embodiments, the enforcement application118moves the credits122from the account124to the credit pool126during times at which the user or device is involved in a data session that does not involve congested network resources.

When the enforcement application118begins monitoring a data session and/or enforcing policies against a data session, the enforcement application118can be configured to remove credits122from the credit pool126at a usage rate ru. The usage rate rucan be a variable rate that can be based, at least partially, upon network conditions, user account information, available resources, available network quality of service, network congestion, network load, traffic type and/or category, geographic location of the user device102and/or the data source112between which the data session occurs, whether a user or user device102is roaming out of a home network, access type (e.g., secured, unsecured, or the like), speed of the devices and/or connections, other considerations, or the like, as will be explained in more detail below. In some embodiments, the usage rate rucan be expressed as a function of traffic type, quality-of-service (“QoS”) level, a network congestion level, and/or other considerations. As such, in one contemplated embodiment the usage rate rucan be expressed as κ*f(θ)*g(ρ, τ), wherein κ can be a constant or variable for unit conversion and/or scaling, f(θ) can correspond to a function that represents a contribution or rate increase/decrease due to the required QoS level (e.g., providing data at twice the rate can be represented by an increase in this function, etc.), and g(ρ,τ) can correspond to a function of a congestion level ρ and a traffic type τ. It should be understood that this embodiment is illustrative, and should not be construed as being limiting in any way.

The credits122can be removed from the credit pool126until the credits122in the credit pool126are exhausted. Because the credits122can be added to the credit pool126at the flow rate rf, it can be appreciated that the credit pool126can operate in accordance with a leaky bucket model. As such, the credits122can be added to the credit pool126at the flow rate rfand removed from the credit pool126at the usage rate ru. The flow rate rfand the usage rate runeed not be equal to one another. As such, if the usage rate ruexceeds the flow rate rf, the credits122in the credit pool126will eventually be exhausted. If the flow rate rfexceeds the usage rate ru, the credits122in the credit pool126may never be exhausted.

According to various embodiments, the credit pool126can have a maximum capacity. The maximum capacity of the credit pool126can be attained if the flow rate rfexceeds the usage rate ru, if the credit pool126is not being used, and/or for other reasons. If the maximum capacity of the credit pool126is attained, the enforcement application118can be configured to suspend additions of the credits122to the credit pool126. Because credits122may only flow into the credit pool126during a data session, the enforcement application118can, by way of the maximum capacity, effectively cap the number of credits122in the credit pool126. As such, the enforcement application118can limit, at least to some extent, a number of credits122that can be used during a particular data session, and as such, a user's or device's access to congested network resources.

As noted above, the enforcement application118can be configured to consider a number of states, operating characteristics, and/or other conditions when determining how to enforce policies against a user, device, or data session associated with a user or device. In various embodiments, the enforcement application118can be configured to obtain subscriber data128. In some embodiments, the subscriber data128can be obtained from one or more charging and billing systems130. The subscriber data128also can include subscriber information132, which can be stored at and/or obtained from a data storage device such as a data store134. Thus, it can be appreciated that the subscriber data128can include subscription information, usage information, user information, account balances, allocation rates ra, QoS information, flow rates rf, usage rates ru, policies associated with users and/or devices, combinations thereof, or the like.

In some embodiments, the functionality of the data store134can be provided by one or more real or virtual resources including, but not limited to, databases, server computers, desktop computers, mobile telephones, laptop computers, other computing systems, and the like. In some embodiments, the data store134can correspond to a subscriber information repository or database, though this is not the case. In the illustrated embodiments, the functionality of the data store134is provided by a database hosted on a server computer. It should be understood that this embodiment is illustrative, and should not be construed as being limiting in any way.

As is explained in more detail below, particular with reference toFIGS. 2 and 5B, the charging and billing systems130can be configured to communicate with the user device102to obtain traffic management data136and/or include at least a portion of the traffic management data136in the subscriber data128. The traffic management data136can include user preferences, options, and/or settings such as, for example, data usage options, or the like. The traffic management data136also can include user selections and/or traffic management decisions, which can be made at the user device102before, during, and/or after initiation of a data session.

In addition to the subscriber data128, the enforcement application118also can be configured to obtain network information, statistics, and/or analytics (“network data”)138. In particular, the enforcement application118can be configured to obtain, receive, and/or request network data138that can be analyzed and/or interpreted by the enforcement application118to determine network congestion and/or other conditions that may affect policies enforced against the user, device, and/or data session requested by the requests114. The network data138can be obtained from one or more network reporting systems or devices (“network reporting device”)140. The network reporting device140can include various devices, systems, reporting mechanisms, network control systems, or the like.

In some embodiments, the enforcement application118can be configured to detect a data session request such as the request114, and to determine, based upon various data including, but not limited to, the subscriber data128and the network data138, how a data session requested by the data session request is to be established. In other words, the enforcement application118can determine one or more options for the data session with regard to QoS levels, timing, devices to be used, usage rates ru, other factors, or the like. The charging and billing systems130can determine one or more data session options that include, for example, a QoS determination, a usage rate rudetermination, and/or the like, and transmit these options to the user device102for a decision. The options can be transmitted to the user device102as options data142. The traffic control application108can load the options data142into a user interface for presentation at the user device102, obtain a selection of an option, generate the traffic management data136that includes the selection, and transmit the traffic management data136to the charging and billing systems130.

The charging and billing systems130can update the subscriber data128in accordance with the selection at the user device102and the enforcement application118can enforce the determined policies on the data session. During enforcement, the enforcement application118can apply the determined usage rate ruand monitor the credit pool126. The enforcement application118also can issue commands116to control the data session based upon the monitoring. These and other aspects of enforcement are described in additional detail below, particularly with reference toFIG. 4.

In operation of various embodiments of the concepts and technologies disclosed herein, an application or service requests data110. For example, an application program executing at the user device102can request data110from a data source112by way of a request114, which the user device102can transmit to the data source112. The data source112can be configured to call or access the enforcement application118and/or to provide the functionality described herein with respect to the enforcement application118. For example, the enforcement application118can be called or accessed by way of one or more application programming interfaces (“APIs”) exposed by the enforcement application118and/or a device executing the enforcement application118such as, for example, the server computer120.

In some other embodiments, the enforcement application118can be configured to enforce policies against a user, device, and/or data session without being called and/or otherwise requested. In some other embodiments, the data source112and/or an application or service executing on or in association with the data source112or elsewhere can be configured to provide the functionality of the enforcement application118and/or to call or access the enforcement application118. Thus, it should be understood that the enforcement application118can operate as an application on one or more devices and/or can operate as a service and can respond to calls from various entities or devices such as, for example, the data source112.

The enforcement application118can be configured to obtain subscriber data128and network data138to determine an allocation rate ra, a flow rate rf, and a usage rate ru. In some embodiments the charging and billing systems130can be configured to communicate with the user device102during setup of the data session (and/or at other times during the data session) to determine the usage rate ruand/or other rates associated with the functionality of the enforcement application118described herein. In particular, the charging and billing systems130can generate one or more usage rate options and transmit the options to the user device102as the options data142. The traffic control application108can load the options data142into a display and obtain a selection from the user or other entity at the user device102. The selection or decision can be represented in traffic management data136generated at the user device102and transmitted to the charging and billing systems130.

The enforcement application118can begin enforcing the usage rate ru, the flow rate rf, and/or the allocation rate rabased upon the network data138and the subscriber data128. It can be appreciated that in various embodiments, the usage rate rucan be higher at times of network congestion relative to a lower usage rate ruat a time of relatively lower network congestion. As such, the usage rate rucan be a dynamic value or function that can be used to dynamically control data access based upon network congestion, traffic type, and/or other factors as explained herein. The usage rate rualso can be changed during a data session in response to changing network conditions, either by the enforcement application118without user input and/or by sending options data142to the user device102for a determination as explained above. Because other considerations can be used to raise and/or lower usage rates ru, it should be understood that these embodiments are illustrative, and should not be construed as being limiting in any way.

Based upon the usage rate ru, the subscriber data128, the network data138, and credit balances, the enforcement application118can issue one or more commands116to the data source112to control the data session. For example, during the data session, the enforcement application118can monitor the credit pool126. If the credit pool126runs out of credits122, the enforcement application118can issue commands116to terminate the data session, ask a user to purchase more credits, change a guaranteed or applied QoS and/or other quality aspect of the data session, take other actions, or the like. As such, the enforcement application118can issue a command116to terminate the data session. Because the commands116can be issued at other times and/or under other circumstances, it should be understood that these embodiments are illustrative, and should not be construed as being limiting in any way.

FIG. 1illustrates one user device102, one network104, one data source112, one server computer120, one instance of the charging and billing systems130, one data store134, and one network reporting device140. It should be understood, however, that various implementations of the operating environment100include multiple user devices102, multiple networks104, multiple data sources112, multiple server computers120, multiple instances of the charging and billing systems130, multiple data stores134, and/or multiple network reporting devices140. As such, the illustrated embodiment should be understood as being illustrative, and should not be construed as being limiting in any way.

Thus, it should be appreciated that the logical operations described herein are implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance and other requirements of the computing system. Accordingly, the logical operations described herein are referred to variously as states, operations, structural devices, acts, or modules. These states, operations, structural devices, acts, and modules may be implemented in software, in firmware, in special purpose digital logic, and any combination thereof. As used herein, the phrase “cause a processor to perform operations” and variants thereof is used to refer to causing a processor of a computing system or device, such as, the user device102and/or the server computer120to perform one or more operations and/or causing the processor to direct other components of the computing system or device to perform one or more of the operations.

For purposes of illustrating and describing the concepts of the present disclosure, the methods disclosed herein are described as being performed by the user device102via execution of one or more software modules such as, for example, the traffic control application108. It should be understood that additional and/or alternative devices and/or network nodes can provide the functionality described herein via execution of one or more modules, applications, and/or other software including, but not limited to, the traffic control application108. Thus, the illustrated embodiments are illustrative, and should not be viewed as being limiting in any way.

The method200begins at operation202, wherein the user device102detects a data session request or generates a request to begin a data session. Detecting the data session request in operation202can correspond to detecting that the user device102has requested data110from the data source112; that the user device102has initiated an application program that uses data110from the data source112; that the user device102has requested access to the data source112; that the user device102has submitted data to the data source112; and/or detecting other data communications between the user device102and the data source112that can correspond to initiation of a data session. It should be understood that that the data session request detected in operation202can correspond to any type of request for data communications between one or more devices operating on or in communication with the network104. As such, it should be understood that the above example embodiments are illustrative, and should not be construed as being limiting in any way.

From operation202, the method200proceeds to operation204, wherein the user device102prompts for one or more traffic control decisions. As explained above, and as will be illustrated and described below with reference toFIG. 5B, the user device102can be configured to obtain options data142from the charging and billing systems130. The options data142can include one or more data session options for presentation at the user device102.

In particular, the user device102can be configured to execute the traffic control application108to generate and/or present a display screen and/or other user interface for presenting the one or more data session options included in the options data142. Similarly, the user device102can be configured to obtaining a choice, decision, or selection (referred to herein as a “traffic control decision”). The traffic control decision can indicate a decision, selection, or choice regarding a QoS for the data session, a credit usage rate ru, other rates, or the like. Thus, while not explicitly shown inFIG. 2, the user device102can obtain the options data142and generate one or more for presentation at the user device102.

From operation204, the method200proceeds to operation206, wherein the user device102can generate the traffic management data136for communication to the charging and billing systems130. The traffic management data136generated in operation206can include the choice or selection made at the user device in operation204. As explained above with reference toFIG. 1, the traffic management data136generated by the user device102also can include account options or settings such as, for example, subscription plan information, or the like, though this information may or may not be included in the traffic management data136generated in operation206.

From operation206, the method200proceeds to operation208, wherein the user device102can provide the traffic management data136to one or more entities. In various embodiments, the user device102can provide the traffic management data136to the charging and billing systems130and/or other nodes or entities for use in generating enforcement decisions. As such, the method200can be executed by the user device102to prompt a user for a data session option and to communicate a choice or decision of the user to a network device or other entity.

From operation206, the method200proceeds to operation208. The method200ends at operation208.

Turning now toFIG. 3, aspects of a method300for controlling network traffic will be described in detail, according to an illustrative embodiment. For purposes of illustrating and describing the concepts of the present disclosure, the method300is described as being performed by the server computer120via execution of one or more software modules such as, for example, the enforcement application118. It should be understood that additional and/or alternative devices and/or network nodes can provide the functionality described herein via execution of one or more modules, applications, and/or other software including, but not limited to, the enforcement application118. Thus, the illustrated embodiments are illustrative, and should not be viewed as being limiting in any way.

The method300begins at operation302, wherein the server computer120detects a data session request. As explained above in detail, detecting the data request in operation302can correspond to detecting, at the server computer120, that a device such as the user device102has requested data110from the data source112and/or detecting other data communications between the user device102and the data source112. It should be understood that that the data request detected in operation302can correspond to any type of request for data communications between one or more devices operating on or in communication with the network104. As such, it should be understood that the above example embodiments are illustrative, and should not be construed as being limiting in any way.

From operation302, the method300proceeds to operation304, wherein the server computer120obtains network data138and/or other network or traffic information and/or analytics. In some embodiments, one or more reporting mechanisms such as the network reporting device140can submit network data such as the network data138to the server computer120. In some other embodiments, the server computer120can request network data such as the network data138from the one or more reporting mechanisms such as the network reporting device140and receive the network data138in response to the request.

As explained above, the network data138can include, but is not limited to, data indicating used and/or available network bandwidth; network congestion; resource availability information; other information; combinations thereof; or the like. Because other types of network data can be obtained in operation304, it should be understood that these embodiments are illustrative, and should not be construed as being limiting in any way.

From operation304, the method300proceeds to operation306, wherein the server computer120obtains subscriber data128. As explained above, the subscriber data128obtained in operation306can include subscription plans, usage information, usage limits, credit balances and/or rates associated with the credits, other information relating to the user device102or a user associated with the user device102, combinations thereof, or the like. The subscriber data128also can include information obtained by the charging and billing systems130with regard to one or more data session options. As such, it should be understood that the subscriber data128obtained in operation306can include and/or can be based upon the traffic management data136generated by the user device102in the method200described above. Because the subscriber data128can include additional and/or alternative information, it should be understood that this embodiment is illustrative, and should not be construed as being limiting in any way.

From operation306, the method300proceeds to operation308, wherein the server computer120determines a usage rate ru. The usage rage rudetermined by the server computer120in operation308can be based, at least partially, upon the subscriber data128and/or the network data138. As such, the usage rate rucan vary based upon network conditions, subscription plans, or the like. In some embodiments, for example, the usage rate rucan increase as network congestion increases, and can decrease as network congestion decreases, though this is not necessarily the case. Additionally, as explained above, the server computer120can determine the usage rate rubased upon a user selection. As such, a user can select a usage rate rufor a particular data session, if desired, and the server computer120can use that usage rate ruduring the data session. Additional details of a user selecting the usage rate ruare explained below with reference toFIG. 5B.

From operation308, the method300proceeds to operation310, wherein the server computer120can apply the usage rate ruto the data session. According to various embodiments, the server computer120can monitor the credit pool126and/or a balance of credits122in the credit pool126. As a time corresponding to the usage rate rupasses, the server computer120can remove one credit122from the credit pool126. Thus, for example, if the usage rate rucorresponds to one credit per minute, the server computer120can maintain a timer. At the expiration of one minute, the server computer120can remove a credit122from the credit pool126and restart the timer. This can continue as long as the data session is in progress. Additional details of applying the usage rate ruto the data session are illustrated and described below with reference toFIG. 4.

From operation310, the method300proceeds to operation312, wherein the server computer120can issue one or more commands116. The commands116issued by the server computer120can cause the data source112to initiate the data session, continue the data session, and/or terminate the data session. The commands116issued by the server computer120also can prompt the data source112to change a QoS associated with the data session and/or otherwise to modify various aspects of the data session. Thus, the commands116can prompt the data source112to allow/restrict traffic associated with the data session in accordance with the usage rate rudetermined in operation308.

From operation312, the method300proceeds to operation314. The method300ends at operation314.

Turning now toFIG. 4, aspects of a method400for applying the usage rate to the data session will be described in detail, according to an illustrative embodiment. The functionality of the method400can, but does not necessarily, correspond to operation310of the method300illustrated and described with reference toFIG. 3above. For purposes of illustrating and describing the concepts of the present disclosure, the method400is described as being performed by the server computer120via execution of one or more software modules such as, for example, the enforcement application118. It should be understood that additional and/or alternative devices and/or network nodes can provide the functionality described herein via execution of one or more modules, applications, and/or other software including, but not limited to, the enforcement application118. Thus, the illustrated embodiments are illustrative, and should not be viewed as being limiting in any way.

The method400begins at operation402, wherein the server computer120determines if a time associated with the usage rate rudetermined in operation308of the method300has passed. As mentioned above, the server computer120can maintain a timer. The server computer120can determine a time corresponding to and/or associated with the usage rate rudetermined in operation308of the method300described above. Thus, for example, if the usage rate is fifteen credits per minute, the server computer120can determine that the time associated with the usage rate ruis four seconds. The server computer120can start the timer, and at the expiration of the timer, the server computer120can determine that the time associated with the usage rate ruhas passed. Because other usage rates ruare possible and are contemplated, it should be understood that this example is illustrative, and should not be construed as being limiting in any way.

If the server computer120determines, in operation402that the time associated with the usage rate ruhas not passed, the method400can return to operation402. As such, it can be appreciated that execution of the method400can pause and/or reiterate operation402until the server computer determines, in any iteration of operation402, that the time associated with the usage rate ruhas passed. If the server computer120determines in operation402that the time associated with the usage rate ruhas passed, the method400can proceed to operation404.

In operation404, the server computer120determines if additional credits122are available in the credit pool126associated with the user device102and/or a user of the user device102. If the server computer120determines in operation404that one or more additional credits122are available in the credit pool126, the method400can proceed to operation406. In operation406, the server computer120can remove a credit122from the credit pool126. Therefore, it can be appreciated that by executing operations402-406, the server computer120can remove a credit122from the credit pool126at a rate that is equal to the usage rate ru. From operation406, the method400can return to operation402, and the server computer120can again determine if the time associated with the credit usage rate ruhas passed. Although not shown inFIG. 4, the server computer120also can restart a timer, if used, before, upon, and/or after returning to operation402.

If the server computer120determines in operation404that additional credits122are not available in the credit pool126, the method400proceeds to operation408. In operation408, the server computer120can determine that the data session is to be terminated. Although not explicitly illustrated inFIG. 4, it should be understood that server computer120also can be configured to cause the charging and billing systems130to communicate with the user device102to prompt a user or other entity to buy additional credits122. In some embodiments, the server computer120and/or the charging and billing systems130also can be configured to prompt a user to increase the flow rate rfinstead of terminating the session as shown at operation408. Thus, instead of terminating a session due to determining that additional credits122are not available in the credit pool126, the server computer120and/or other systems or devices can allow a user to modify the flow rate rf, buy additional credits122, and/or take other actions to prevent termination of the session. As such, the illustrated example of method400should be understood as being one contemplated embodiment and should not be construed as being limiting in any way.

From operation408, the method400proceeds to operation410. The method400ends at operation410.

While the method400is described as using a usage rate ruthat is time-based, it should be understood that other usage rates ruare contemplated and are possible. In particular, a usage rate rucan be defined as a number of request, a number of bytes, and/or other numbers or amounts. Thus, in some embodiments the method400can track a number of bytes transferred instead of, or in addition to, tracking a time associated with the usage rate ru. In one example embodiment, the server computer120can be configured to determine if a number of bytes associated with the usage rate rudetermined in operation308of the method300have been transferred. Thus, for example, if the usage rate is five hundred kilobytes, the server computer120can start a counter or request monitoring of a data stream to determine when five hundred kilobytes have been transferred. It should be understood that the usage rate rucan vary over time due to changing network conditions and as such, the enforcement and/or monitoring of the number of bytes can be adjusted based upon a variable usage rate ruand/or flow rate rf.

When the specified number of bytes has been transferred, the server computer120can be configured to remove a credit122from the credit pool126as discussed above if credits122remain in the credit pool126. As explained above, if credits122do not remain in the credit pool126, the server computer120can communicate with the user and/or instruct other devices or systems such as the charging and billing systems130to communicate with the user to increase the flow rate rf, purchase additional credits122, reduce the usage rate ru, and/or take other actions. If the user declines to take any action, the server computer120can terminate the session. Thus, it can be appreciated that various types of usage rates rucan be enforced by the server computer120. Because the above example is illustrative of only one contemplated embodiment, it should be understood that this example embodiment is illustrative, and should not be construed as being limiting in any way.

Turning now toFIGS. 5A-5B, UI diagrams showing various aspects of the concepts and technologies disclosed herein for controlling data access and rate in a network will be described according to various illustrative embodiments.FIG. 5Ashows an illustrative screen display500A generated by a device such as the user device102. According to various embodiments, the user device102can generate the screen display500A and/or other screen displays in conjunction with and/or based upon data received from the traffic control application108, the enforcement application118, the charging and billing systems130, and/or other devices or systems as described herein. As explained above, the concepts and technologies disclosed herein for controlling data access and rate in a network can be provided by one or more applications or modules executed by the user device102and/or by a device remote from the user device102such as, for example, the server computer120. It should be appreciated that the UI diagram illustrated inFIG. 5Ais illustrative of one contemplated embodiment, and therefore should not be construed as being limited in any way.

Although not shown inFIG. 5A, the screen display500A can include various menus and/or menu options such as options for returning to a previous screen, exiting the current application or screen, advancing to a next screen, and/or other options. It also should be understood that the screen display500A and/or other screen displays can be provided at almost any time during operation of the user device102. InFIG. 5A, the user device102is illustrated as displaying a user interface for setting and/or modifying one or more data access options. The screen display500A can include a data access options screen502for presenting and/or allowing modification of one or more data access options.

In the embodiment shown inFIG. 5A, the data access options screen502includes a subscription plan field504. The subscription plan field504can present data for informing a user or other entity of a credit subscription plan. In the illustrated embodiment, the subscription plan field504presents data indicating a subscription plan of one thousand five hundred credits per month. It can be appreciated from the description ofFIG. 1above that one thousand five hundred credits per month can correspond to an allocation rate raof credits122to an account124, though this is not necessarily the case. The screen display500A also can include a current balance field506for displaying a current balance of credits122associated with the user device102. Thus, the current balance field506can be used to display a balance of the account124. Thus, a user or other entity can view the data access options screen502to determine a subscription plan and credit balance associated with the user, the user device102, and/or another entity.

The data access options screen502also can include a UI control508for changing a subscription plan associated with the user device102. Selection of the UI control508and/or other types of input such as voice commands, touch commands, keystrokes, or the like can cause the user device102to change a credit subscription plan. In some embodiments, selection of the UI control508can cause the user device102to exchange traffic management data136with the charging and billing systems130and/or other devices or systems to modify the credit subscription plan. Similarly, the data access options screen502can include a UI control510for purchasing credits122. Selection of the UI control510can cause the user device102to begin a credit purchase process. In some embodiments, selection of the UI control510can cause the user device102to exchange the traffic management data136with the charging and billing systems130and/or other devices or systems to purchase credits122.

Thus, a user or other entity can, by way of interacting with the data access options screen502, view a credit subscription plan, modify a credit subscription plan, view a credit balance, and/or purchase credits122. The data access options screen502also can include a UI control512for exiting the data access options screen502and/or a UI control514for accessing an account associated with the user device102and/or a user or other entity associated with the user device102. Because additional or alternative fields and/or UI controls can be included in the screen display500A, and/or because additional or alternative actions can be taken in response to selection of the UI controls508,510,512,514included in the screen display500A, it should be understood that these embodiments are illustrative, and should not be construed as being limiting in any way.

Referring now toFIG. 5B, a UI diagram showing additional aspects of the concepts and technologies disclosed herein for controlling data access and rate in a network are described in detail. In particular,FIG. 5Bshows a screen display500B generated by a device such as the user device102. In some embodiments, the screen display500B can be generated by the user device102in response to receiving options data142from the billing and charging systems130. According to some other embodiments, the screen display500B can be generated by the user device102in response to detecting a tap, touch, gesture, keystroke, voice command, or other input for accessing data access settings or options, purchasing credits122, changing a credit subscription plan, or the like.

In yet other embodiments, the screen display500B can be presented by the user device102in response to detecting a data access request such as the request114. Thus, it should be understood that presentation of the screen display500B and/or other screen displays can correspond to prompting for a traffic control decision as illustrated and described above with reference to operation204of the method200. Because the screen display500B can be presented at additional and/or alternative times, it should be understood that these embodiments are illustrative, and should not be construed as being limiting in any way.

The screen display500B can include a data access option display520for displaying a credit balance; presenting one or more data access options and/or credit usage rates for selection by a user; viewing account information and/or application settings; combinations thereof, or the like. In particular, data access options display520can include a credit balance field522. The credit balance field522can display a balance of credits122associated with the user and/or the user device102. Although not shown inFIG. 5B, it should be understood that the data access option display520also can include a UI control for purchasing credits122and/or changing a credit subscription plan. Because the data access option display520can include additional and/or alternative controls, fields, and/or information, it should be understood that the illustrated embodiment is illustrative, and should not be construed as being limiting in any way.

The data access option display520can display information for informing a user or other entity that a data session has been requested. The data access option display520also can include a UI control524. The UI control524can present a first data access option for use during the requested data session. In the illustrated embodiment, the UI control524displays an option for conducting the requested data session at a bandwidth of up to seven hundred fifty megabits per second (Mbps), though other quality of service levels and/or grades can be displayed in addition to, or instead of, seven hundred fifty Mbps. The UI control524also displays a cost of this option, in terms of credits122and/or a credit usage rate ru. In the illustrated embodiment, the credit usage rate ruassociated with the UI control524corresponds to fifteen credits122per minute. Thus, selection of this option, based upon a current credit balance, is illustrated as corresponding to about forty six minutes of data communications before the credits122are exhausted. It should be understood that this embodiment is illustrative, and should not be construed as being limiting in any way.

According to various embodiments, selection of the UI control524can cause the user device102to generate the traffic management data136and to transmit the traffic management data136to the charging and billing systems130indicating the data access option. The charging and billing systems130can also be configured to communicate this choice to the enforcement application118as or with subscriber data128for controlling the requested data session. Thus, as explained above with reference toFIG. 1, the enforcement application118can begin applying the credit usage rate ruassociated with the first data access option.

The data access option display520also includes a UI control526. The UI control526presents a second data access option for use during the requested data session. In the illustrated embodiment, the UI control526displays an option for conducting the requested data session at a bandwidth of up to three hundred fifty Mbps, though other QoS levels and/or grades can be displayed in addition to, or instead of, three hundred fifty Mbps. The UI control526also displays a cost of this option, in terms of credits122and/or a credit usage rate ru. In the illustrated embodiment, the credit usage rate ruassociated with the UI control526can correspond to three credits122per minute. As such, selection of the second option, based upon a current credit balance of six hundred ninety two credits122, can correspond to about two hundred thirty minutes of data communications before the credits122are exhausted. It should be understood that this embodiment is illustrative, and should not be construed as being limiting in any way.

According to various embodiments, selection of the UI control526can cause the user device102to generate the traffic management data136and to transmit the traffic management data136to the charging and billing systems130and/or other network nodes, devices, or the like. The traffic management data136can indicate that the user or other entity has selected the second data access option. The charging and billing systems130can also be configured to communicate the choice of the second data access option as or within the subscriber data128to the enforcement application118to control the requested data session. Thus, as explained above with reference toFIG. 1, the enforcement application118can begin applying the credit usage rate ruassociated with the second data access option.

The screen display500B also can include a UI control528for exiting the data access options and/or the data access option display520. The screen display500B also can include a UI control530for accessing one or more settings associated with the data access control functionality disclosed herein. Thus, selection of the UI control528can cause the user device102to stop displaying the data access option display520and selection of the UI control530can cause the user device102to begin displaying options or settings associated with the data access control functionality described herein. It should be understood that these embodiments are illustrative, and should not be construed as being limiting in any way.

While the screen display500B is illustrated as displaying two data access options, corresponding to the fields524,526, it should be understood that less than two data access options, two data access options, and/or more than two data access options can be displayed on the screen display500B in accordance with the concepts and technologies disclosed herein. Thus, the illustrated embodiment is illustrative and should not be construed as being limiting in any way.

In the above description ofFIGS. 1-5B, the enforcement application118and the traffic control application108have been described as executing various functions to provide the functionality described herein for controlling data access in the network104. It should be understood that the traffic control application108and the enforcement application118, as well as other entities and/or application illustrated and described herein, can communicate with one another and/or work together in a synchronized manner to provide the functionality described herein. For example, the traffic control application108and the enforcement application118can communicate with each other to ensure that credits122are issued and/or deducted in a timely manner. Because other communications between the various entities illustrated inFIG. 1and/or described herein are contemplated and are possible, it should be understood that this example of communications between these is illustrative, and should not be construed as being limiting in any way.

Turning now toFIG. 6, additional details of the network104are illustrated, according to an illustrative embodiment. The network104includes a cellular network602, a packet data network604, for example, the Internet, and a circuit switched network606, for example, a publicly switched telephone network (“PSTN”). The cellular network602includes various components such as, but not limited to, base transceiver stations (“BTSs”), Node-B's or e-Node-B's, base station controllers (“BSCs”), radio network controllers (“RNCs”), mobile switching centers (“MSCs”), mobile management entities (“MMEs”), short message service centers (“SMSCs”), multimedia messaging service centers (“MMSCs”), home location registers (“HLRs”), home subscriber servers (“HSSs”), visitor location registers (“VLRs”), charging platforms, billing platforms, voicemail platforms, GPRS core network components, location service nodes, an IP Multimedia Subsystem (“IMS”), and the like. The cellular network602also includes radios and nodes for receiving and transmitting voice, data, and combinations thereof to and from radio transceivers, networks, the packet data network604, and the circuit switched network606.

A mobile communications device608, such as, for example, a cellular telephone, a user equipment, a mobile terminal, a PDA, a laptop computer, a handheld computer, and combinations thereof, can be operatively connected to the cellular network602. The cellular network602can be configured as a 2G GSM network and can provide data communications via GPRS and/or EDGE. Additionally, or alternatively, the cellular network602can be configured as a 3G UMTS network and can provide data communications via the HSPA protocol family, for example, HSDPA, EUL (also referred to as HSUPA), and HSPA+. The cellular network602also is compatible with 4G mobile communications standards as well as evolved and future mobile standards.

The packet data network604includes various devices, for example, servers, computers, databases, and other devices in communication with one another, as is generally known. The packet data network604devices are accessible via one or more network links. The servers often store various files that are provided to a requesting device such as, for example, a computer, a terminal, a smartphone, or the like. Typically, the requesting device includes software (a “browser”) for executing a web page in a format readable by the browser or other software. Other files and/or data may be accessible via “links” in the retrieved files, as is generally known. In some embodiments, the packet data network604includes or is in communication with the Internet. The circuit switched network606includes various hardware and software for providing circuit switched communications. The circuit switched network606may include, or may be, what is often referred to as a plain old telephone system (POTS). The functionality of a circuit switched network606or other circuit-switched network are generally known and will not be described herein in detail.

The illustrated cellular network602is shown in communication with the packet data network604and a circuit switched network606, though it should be appreciated that this is not necessarily the case. One or more Internet-capable devices610, for example, a PC, a laptop, a portable device, or another suitable device, can communicate with one or more cellular networks602, and devices connected thereto, through the packet data network604. It also should be appreciated that the Internet-capable device610can communicate with the packet data network604through the circuit switched network606, the cellular network602, and/or via other networks (not illustrated).

As illustrated, a communications device612, for example, a telephone, facsimile machine, modem, computer, or the like, can be in communication with the circuit switched network606, and therethrough to the packet data network604and/or the cellular network602. It should be appreciated that the communications device612can be an Internet-capable device, and can be substantially similar to the Internet-capable device610. In the specification, the network104is used to refer broadly to any combination of the networks602,604,606. It should be appreciated that substantially all of the functionality described with reference to the network104can be performed by the cellular network602, the packet data network604, and/or the circuit switched network606, alone or in combination with other networks, network elements, and the like.

FIG. 7is a block diagram illustrating a computer system700configured to provide the functionality described herein for a verification service, in accordance with various embodiments of the concepts and technologies disclosed herein. The computer system700includes a processing unit702, a memory704, one or more user interface devices706, one or more input/output (“I/O”) devices708, and one or more network devices710, each of which is operatively connected to a system bus712. The bus712enables bi-directional communication between the processing unit702, the memory704, the user interface devices706, the I/O devices708, and the network devices710.

The processing unit702may be a standard central processor that performs arithmetic and logical operations, a more specific purpose programmable logic controller (“PLC”), a programmable gate array, or other type of processor known to those skilled in the art and suitable for controlling the operation of the server computer. Processing units are generally know, and therefore are not described in further detail herein.

The memory704communicates with the processing unit702via the system bus712. In some embodiments, the memory704is operatively connected to a memory controller (not shown) that enables communication with the processing unit702via the system bus712. The memory704includes an operating system714and one or more program modules716. The operating system714can include, but is not limited to, members of the WINDOWS, WINDOWS CE, and/or WINDOWS MOBILE families of operating systems from MICROSOFT CORPORATION, the LINUX family of operating systems, the SYMBIAN family of operating systems from SYMBIAN LIMITED, the BREW family of operating systems from QUALCOMM CORPORATION, the MAC OS, iOS, and/or LEOPARD families of operating systems from APPLE CORPORATION, the FREEBSD family of operating systems, the SOLARIS family of operating systems from ORACLE CORPORATION, other operating systems, and the like.

The program modules716may include various software and/or program modules described herein. In some embodiments, for example, the program modules716include the enforcement application118. Additionally, some embodiments of the computer system700can include, in the program modules716, applications, programs, or modules for providing the functionality described herein with respect to the charging and billing systems130and the network reporting devices140. These and/or other programs can be embodied in computer-readable media containing instructions that, when executed by the processing unit702, perform one or more of the methods300,400described in detail above with respect toFIGS. 3-4. According to embodiments, the program modules716may be embodied in hardware, software, firmware, or any combination thereof. Although not shown inFIG. 7, it should be understood that the memory704also can be configured to store the subscriber data128, the subscriber information132, the network data138, and/or other data, if desired.

The user interface devices706may include one or more devices with which a user accesses the computer system700. The user interface devices706may include, but are not limited to, computers, servers, personal digital assistants, cellular phones, or any suitable computing devices. The I/O devices708enable a user to interface with the program modules716. In one embodiment, the I/O devices708are operatively connected to an I/O controller (not shown) that enables communication with the processing unit702via the system bus712. The I/O devices708may include one or more input devices, such as, but not limited to, a keyboard, a mouse, or an electronic stylus. Further, the I/O devices708may include one or more output devices, such as, but not limited to, a display screen or a printer.

The network devices710enable the computer system700to communicate with other networks or remote systems via a network, such as the network104. Examples of the network devices710include, but are not limited to, a modem, a radio frequency (“RF”) or infrared (“IR”) transceiver, a telephonic interface, a bridge, a router, or a network card. The network104may include a wireless network such as, but not limited to, a Wireless Local Area Network (“WLAN”) such as a WI-FI network, a Wireless Wide Area Network (“WWAN”), a Wireless Personal Area Network (“WPAN”) such as BLUETOOTH, a Wireless Metropolitan Area Network (“WMAN”) such a WiMAX network, or a cellular network. Alternatively, the network104may be a wired network such as, but not limited to, a Wide Area Network (“WAN”) such as the Internet, a Local Area Network (“LAN”) such as the Ethernet, a wired Personal Area Network (“PAN”), or a wired Metropolitan Area Network (“MAN”).

Turning now toFIG. 8, an illustrative mobile device800and components thereof will be described. In some embodiments, the user device102described above with reference toFIGS. 1-7can be configured as and/or can have an architecture similar or identical to the mobile device800described herein inFIG. 8. It should be understood, however, that the user device102may or may not include the functionality described herein with reference toFIG. 8. While connections are not shown between the various components illustrated inFIG. 8, it should be understood that some, none, or all of the components illustrated inFIG. 8can be configured to interact with one other to carry out various device functions. In some embodiments, the components are arranged so as to communicate via one or more busses (not shown). Thus, it should be understood thatFIG. 8and the following description are intended to provide a general understanding of a suitable environment in which various aspects of embodiments can be implemented, and should not be construed as being limiting in any way.

As illustrated inFIG. 8, the mobile device800can include a display802for displaying data. According to various embodiments, the display802can be configured to display asset information, asset tag or asset ID information, asset management account information, various graphical user interface (“GUI”) elements, text, images, video, virtual keypads and/or keyboards, messaging data, notification messages, metadata, internet content, device status, time, date, calendar data, device preferences, map and location data, combinations thereof, and/or the like. The mobile device800also can include a processor804and a memory or other data storage device (“memory”)806. The processor804can be configured to process data and/or can execute computer-executable instructions stored in the memory806. The computer-executable instructions executed by the processor804can include, for example, an operating system808, one or more applications810such as the traffic control application108, other computer-executable instructions stored in a memory806, or the like. In some embodiments, the applications810also can include a UI application (not illustrated inFIG. 8).

The UI application can be executed by the processor804to aid a user in entering content, scanning or capturing asset ID or asset tag information, creating new asset tags or asset ID numbers, viewing asset information and/or account information, answering/initiating calls, entering/deleting data, entering and setting user IDs and passwords for device access, configuring settings, manipulating address book content and/or settings, multimode interaction, interacting with other applications810, and otherwise facilitating user interaction with the operating system808, the applications810, and/or other types or instances of data812that can be stored at the mobile device800. The data812can include, for example, subscriber information, subscription plans, credit balances, usage rates ru, flow rates rf, allocation rates ra, and/or other applications or program modules.

According to various embodiments, the data812can include, for example, presence applications, visual voice mail applications, messaging applications, text-to-speech and speech-to-text applications, add-ons, plug-ins, email applications, music applications, video applications, camera applications, location-based service applications, power conservation applications, game applications, productivity applications, entertainment applications, enterprise applications, combinations thereof, and the like. The applications810, the data812, and/or portions thereof can be stored in the memory806and/or in a firmware814, and can be executed by the processor804. The firmware814also can store code for execution during device power up and power down operations. It can be appreciated that the firmware814can be stored in a volatile or non-volatile data storage device including, but not limited to, the memory806and/or a portion thereof.

The mobile device800also can include an input/output (“I/O”) interface816. The I/O interface816can be configured to support the input/output of data such as location information, asset information, user information, organization information, presence status information, user IDs, passwords, and application initiation (start-up) requests. In some embodiments, the I/O interface816can include a hardwire connection such as a universal serial bus (“USB”) port, a mini-USB port, a micro-USB port, an audio jack, a PS2 port, an IEEE 1394 (“FIREWIRE”) port, a serial port, a parallel port, an Ethernet (RJ45) port, an RJ11 port, a proprietary port, combinations thereof, or the like. In some embodiments, the mobile device800can be configured to synchronize with another device to transfer content to and/or from the mobile device800. In some embodiments, the mobile device800can be configured to receive updates to one or more of the applications810via the I/O interface816, though this is not necessarily the case. In some embodiments, the I/O interface816accepts I/O devices such as keyboards, keypads, mice, interface tethers, printers, plotters, external storage, touch/multi-touch screens, touch pads, trackballs, joysticks, microphones, remote control devices, displays, projectors, medical equipment (e.g., stethoscopes, heart monitors, and other health metric monitors), modems, routers, external power sources, docking stations, combinations thereof, and the like. It should be appreciated that the I/O interface816may be used for communications between the mobile device800and a network device or local device.

The mobile device800also can include a communications component818. The communications component818can be configured to interface with the processor804to facilitate wired and/or wireless communications with one or more networks such as the network104described herein. In some embodiments, other networks include networks that utilize non-cellular wireless technologies such as WI-FI or WIMAX. In some embodiments, the communications component818includes a multimode communications subsystem for facilitating communications via the cellular network and one or more other networks.

The communications component818, in some embodiments, includes one or more transceivers. The one or more transceivers, if included, can be configured to communicate over the same and/or different wireless technology standards with respect to one another. For example, in some embodiments one or more of the transceivers of the communications component818may be configured to communicate using GSM, CDMAONE, CDMA2000, LTE, and various other 2G, 2.5G, 3G, 4G, and greater generation technology standards. Moreover, the communications component818may facilitate communications over various channel access methods (which may or may not be used by the aforementioned standards) including, but not limited to, TDMA, FDMA, W-CDMA, OFDM, SDMA, and the like.

In addition, the communications component818may facilitate data communications using GPRS, EDGE, the HSPA protocol family including HSDPA, EUL or otherwise termed HSUPA, HSPA+, and various other current and future wireless data access standards. In the illustrated embodiment, the communications component818can include a first transceiver (“TxRx”)820A that can operate in a first communications mode (e.g., GSM). The communications component818also can include an Nthtransceiver (“TxRx”)820N that can operate in a second communications mode relative to the first transceiver820A (e.g., UMTS). While two transceivers820A-N (hereinafter collectively and/or generically referred to as “transceivers820”) are shown inFIG. 8, it should be appreciated that less than two, two, and/or more than two transceivers820can be included in the communications component818.

The communications component818also can include an alternative transceiver (“Alt TxRx”)822for supporting other types and/or standards of communications. According to various contemplated embodiments, the alternative transceiver822can communicate using various communications technologies such as, for example, WI-FI, WIMAX, BLUETOOTH, infrared, infrared data association (“IRDA”), near field communications (“NFC”), other RF technologies, combinations thereof, and the like. In some embodiments, the communications component818also can facilitate reception from terrestrial radio networks, digital satellite radio networks, internet-based radio service networks, combinations thereof, and the like. The communications component818can process data from a network such as the Internet, an intranet, a broadband network, a WI-FI hotspot, an Internet service provider (“ISP”), a digital subscriber line (“DSL”) provider, a broadband provider, combinations thereof, or the like.

The mobile device800also can include one or more sensors824. The sensors824can include temperature sensors, light sensors, air quality sensors, movement sensors, orientation sensors, noise sensors, proximity sensors, or the like. As such, it should be understood that the sensors824can include, but are not limited to, accelerometers, magnetometers, gyroscopes, infrared sensors, noise sensors, microphones, combinations thereof, or the like. Additionally, audio capabilities for the mobile device800may be provided by an audio I/O component826. The audio I/O component826of the mobile device800can include one or more speakers for the output of audio signals, one or more microphones for the collection and/or input of audio signals, and/or other audio input and/or output devices.

The illustrated mobile device800also can include a subscriber identity module (“SIM”) system828. The SIM system828can include a universal SIM (“USIM”), a universal integrated circuit card (“UICC”) and/or other identity devices. The SIM system828can include and/or can be connected to or inserted into an interface such as a slot interface830. In some embodiments, the slot interface830can be configured to accept insertion of other identity cards or modules for accessing various types of networks. Additionally, or alternatively, the slot interface830can be configured to accept multiple subscriber identity cards. Because other devices and/or modules for identifying users and/or the mobile device800are contemplated, it should be understood that these embodiments are illustrative, and should not be construed as being limiting in any way.

The mobile device800also can include an image capture and processing system832(“image system”). The image system832can be configured to capture or otherwise obtain photos, videos, and/or other visual information. As such, the image system832can include cameras, lenses, charge-coupled devices (“CCDs”), combinations thereof, or the like. The mobile device800may also include a video system834. The video system834can be configured to capture, process, record, modify, and/or store video content. Photos and videos obtained using the image system832and the video system834, respectively, may be added as message content to an MMS message, email message, and sent to another mobile device. The video and/or photo content also can be shared with other devices via various types of data transfers via wired and/or wireless communication devices as described herein.

The mobile device800also can include one or more location components836. The location components836can be configured to send and/or receive signals to determine a geographic location of the mobile device800. According to various embodiments, the location components836can send and/or receive signals from global positioning system (“GPS”) devices, assisted-GPS (“A-GPS”) devices, WI-FI/WIMAX and/or cellular network triangulation data, combinations thereof, and the like. The location component836also can be configured to communicate with the communications component818to retrieve triangulation data for determining a location of the mobile device800. In some embodiments, the location component836can interface with cellular network nodes, telephone lines, satellites, location transmitters and/or beacons, wireless network transmitters and receivers, combinations thereof, and the like. In some embodiments, the location component836can include and/or can communicate with one or more of the sensors824such as a compass, an accelerometer, and/or a gyroscope to determine the orientation of the mobile device800. Using the location component836, the mobile device800can generate and/or receive data to identify its geographic location, or to transmit data used by other devices to determine the location of the mobile device800. The location component836may include multiple components for determining the location and/or orientation of the mobile device800.

The illustrated mobile device800also can include a power source838. The power source838can include one or more batteries, power supplies, power cells, and/or other power subsystems including alternating current (“AC”) and/or direct current (“DC”) power devices. The power source838also can interface with an external power system or charging equipment via a power I/O component840. Because the mobile device800can include additional and/or alternative components, the above embodiment should be understood as being illustrative of one possible operating environment for various embodiments of the concepts and technologies described herein. The described embodiment of the mobile device800is illustrative, and should not be construed as being limiting in any way.

Based on the foregoing, it should be appreciated that systems and methods for controlling data access and rate in a network have been disclosed herein. Although the subject matter presented herein has been described in language specific to computer structural features, methodological and transformative acts, specific computing machinery, and computer-readable media, it is to be understood that the concepts and technologies disclosed herein are not necessarily limited to the specific features, acts, or media described herein. Rather, the specific features, acts and mediums are disclosed as example forms of implementing the concepts and technologies disclosed herein.