Software Technology for “Flow tagging to support service policy implementation”

Communications – Gregory G. Raleigh, Jeffrey Green, James Lavine, Vien-Phuong Nguyen, Headwater Research LLC

Abstract for “Flow tagging to support service policy implementation”

“Flow tagging is the act of tagging data flows at multiple points within the flow. The data flow could be tagged at sockets and proxy manager APIs, for example. It is possible to map network usage activities to the appropriate initiating apps by tagging data flows at multiple points.

Background for “Flow tagging to support service policy implementation”

“With mass market digital communications, applications, and content distribution, many access network such as wireless networks and cable networks and Digital Subscriber Lines (DSL) are under pressure for user capacity with, for instance, Evolution-Data Optimized(EVDO), High Speed Packet Access/LTE, Long Term Evolution/LTE), Worldwide Interoperability For Microwave Access (WiMax), DOCSIS and DSL becoming constrained in their user capacity. In wireless, while network capacity will rise with higher capacity wireless radio access technology, such as Multiple-Input Multiple-Output, and more frequency spectrum and cell splitting being deployed in future, this capacity increase is likely to be smaller than what is needed to meet growing digital networking demands.

“Similarly, even though wireline access networks such as DSL and cable can offer higher average capacity per user than wireless, wireline user service consumption habits are moving toward high bandwidth applications that consume the available capacity quickly and can degrade overall network experience. This trend will negatively impact service provider profits as some service provider components are more expensive with increased bandwidth. It is also becoming more important to link device access network services usage (e.g. network data services usage and voice services usage). Application, widget, service or process, embedded object, and any combination thereof. Services that you are using.

The above example of trends or issues is meant to be an illustration and not a complete list. After reading the specification and studying the drawings, you will see other limitations to the art.

The invention may be implemented in many ways. It can be used as an apparatus, a process, a system, a composition, a product of computer programming, and/or a CPU, such as one that executes instructions stored on or provided by a memory connected to the processor. These implementations and any other form of the invention can be called techniques in this specification. The invention allows for the possibility of altering the order of steps in disclosed processes. A component, such as a processor and a memory, described as being capable of performing a task can be implemented either as a general component that is temporarily set up to perform the task at a particular time or as a specific component that was manufactured to do the task. The term “processor” is used herein. The term “processor” refers to any one or more devices, circuits and/or processing cores that are designed to process data such as computer program instruction.

Below is a detailed description of some embodiments of the invention, along with accompanying figures that illustrate its principles. Although the invention is described with these embodiments in mind, it is not limited to them. The claims limit the scope of the invention, and the invention includes many alternatives, modifications, and equivalents. The following description provides a detailed understanding of the invention. These details are given for example purposes only. The invention can be used according to the claims without any or all of these details. To be clear, the technical material related to the invention that is well-known has not been described in detail. This is done in order not to obscure the invention.

For example, wireless networks must manage the wireless access connections capacity and network connection resources to maintain network performance when network resources/capacity demand rises. If network resource management and capacity management are employed, many network performance measures can be beneficially maintained or improved when network load increases. These performance measures include network availability, ability to deliver connections for all users and/or devices; network access success rate; transmission speed experienced with one or more devices, applications, or users; network bit error rate and packet error rate; time delay from network request to delivery access connection; one-way delay or round trip delay for a transmission transmission; delay timing jitter transmission transmission; time variation in transmission speeds for one or more connections. The network’s ability to share or distribute performance measures (e.g. the performance measures mentioned above) uniformly

“For instance, if there’s a restricted amount of bandwidth available for a group of users (e.g., a network with a number of base stations or controllers or femto cells or pico cells; or a network using cable modem networks, etc.), then the network can become overloaded. If multiple or all devices permit all applications to access network resources, transmit/receive traffic or access them indiscriminately, the network may become overload. This can lead to poor network performance for a small number of users/devices, or even all users/devices. Another example is when multiple or all of the devices that make up a subset allow multiple applications to access the network resources and transmit/receive data. The network may become overwhelmed. This can lead to poor network performance for a subset or even all users/devices.

Mobile devices have been designed to maximize network capacity and prevent network resources being overtaxed. Wireless devices browsing the Internet use special protocols like WAP, data traffic compression, or low resolution techniques. This is in contrast to standard HTTP protocols and traffic that are used in wired Internet devices.

“However, wireless devices that use specialized methods to access the Internet or other networks often implement complicated specifications provided by one of the wireless carriers that owns the networks the device is intended to connect to. Complex specifications can be time-consuming to design, test, and certify. These processes have the effect of reducing the number of suppliers for devices to those who are qualified and willing to do the specialized work. This can slow down time to market, increase the cost of developing new devices, and reduce the support of certain applications.

“Device OEMs recently developed wireless devices that look more like standard Internet devices, but are not optimized to maximize network bandwidth and other resources. This type of device is desired by many wireless service customers. OEMs want to make it easier and faster to bring these devices to market. New market requirements and government regulations may require carriers to offer more flexibility in bringing new devices onto their networks. This means that the process doesn’t require the same specialized design or certification as previously. These factors and others are driving the demand for simpler and faster wireless device certification and design processes.

Many carriers are now selling devices that can connect to the Internet through standard Internet service devices. There is a growing demand for general-purpose Internet devices and apps to access wireless networks. This is because they don’t have to go through the certification and design process required to make them efficient and authorized to access such networks.

However, general-purpose Internet devices can be more expensive and sparing than wireless network access bandwidth. Popular Internet services and applications have found that they can access the Internet at very low cost and pay little attention to network traffic. More general-purpose Internet devices (e.g. mobile wireless networks) are being offered to us over wireless networks. This can lead to a higher frequency of inefficient wireless networking accesses, which can sometimes reduce network capacity to levels that limit access for that device (e.g. user, device and software demand) as well as other devices on the wireless network and/or that segment. Although judicious usage of wireless network bandwidth, capacity and resources can result in better service for users, the majority of device manufacturers and wireless network providers (e.g. wireless network carriers and carriers) do not have more sophisticated bandwidth usage techniques. This causes less control by the carrier of device design and poses a risk to network capacity and performance preservation in the long term as more devices are created with less optimized wireless designs.

There are many factors that impact network performance and user performance, such as overall network congestion, access network performance, communications protocols and/or operating systems functions, and/or performance of a user, device, app, network service source or communication protocol. A wireless network’s capacity can be limited, so network performance for a group of users, applications and network service providers, communication protocols, and/or users, or a single device, app, network source, communication protocol, or user, may decrease somewhat. However, as network resources/network capacity demand increases (e.g., more wireless network data traffic is demanded in aggregate; more devices are serviced by the network; more users are serviced by the network; more applications are serviced by the network; more network service sources are serviced by the network; more operating system functions are serviced by the network; and/or more differentiated QoS sessions are serviced by the network), network availability/performance can decrease and/or the network may not adequately service one or more users, devices, applications, network service sources, communication protocols, and/or operating system functions, or may not service one or more groups of users, devices, applications, network service sources, communication protocols, and/or operating system functions.”

There are many ways that increasing network capacity can cause network performance to decrease. These include an increase in latency, decreased bandwidth availability, increased latency for QoS reservations services, performance issues with some communication protocols, unacceptable user experiences, and other similar or similar effects on users and devices. Network communication protocols such as Internet protocol (IP), HTML protocol, voice communication protocols including VOIP protocol, streaming media protocols (e.g. audio/video, etc), gaming protocols and VPN protocols can all lead to reduced performance due to excessive network loading. It is important to protect and preserve network capacity.

“It is important to limit the amount of transactions that are requested from a network resource (e.g. edge network segment, base stations, controllers, MAC resources and pico cell, Femto Cell, etc.). In order to ensure that the network resource can handle transaction demand, it is important that they are not exceeded in terms of their ability to service transactions. Network resources such as base station resources or controllers, media access control resources, traffic transport resource, AAA resources and security or authentication resources are all examples of network resources that should be avoided. Traffic analysis, network security, bandwidth resources, bandwidth reservation, QoS reservation and coordination resources. QoS transport resource, service charging resource, traffic analysis, network security resources. Network performance can be affected by an incremental increase in network capacity/resource demand. This is because network resources become more taxed from limited transaction processing capabilities or limited bandwidth. If the equipment needed to establish a session of the PPP can only handle a limited number of sessions opening and closing per hour, or if the device’s behavior is such that many PPP sessions are opened and/or shut down, the PPP session transaction rate (e.g. openings/closings) may exceed the transaction capability of the session management resources. This is often called “flooding” Overloading is another term. Overloading is when a network resource has too many connections or too much demand. In these cases, the resource might fall behind in meeting transaction demand in a controlled manner. For example, the resource may continue to process transactions at or near the maximum rate allowed by the network resource. However, in other cases the resource may become overwhelmed and its processing speed may drop under overload. The PPP session establishment resource example shows that once the request rate exceeds the resource maximum transactions rate, unmet demand can increase to the point where one or more devices experience delays in connecting to the network and/or communicating (e.g. sending/receiving information).

“Another example is that if there are no traffic access reservation protocols, MAC protocol or bandwidth delivery protocols, then the network may experience more collisions. This can lead to a decrease in network efficiency and cause network performance to fall below acceptable levels. Unmanaged and/or uncontrolled QoS reservations requests and/or reservation grant can result in QoS services being under-utilized. Another example is when networks require a minimum resource allocation for transmissions and reservations or network resource transactions. If one or more devices or applications, network service source functions, operating system functions, and/or communications protocols have a high rate of network resource requests, network accesses, or data transmissions for small payloads (e.g. minimum MAC reservation factor, minimum security overhead factor, minimum QoS reservation factor, minimum response time for establishing a connection to a base station, minimum responses for establishing/clos/being released from a session), Even though the data packet containing the access event may be small, the network resources needed to complete it are often busy serving the access event for longer periods than is necessary for actual data transmission.

Another example of device service activity behavior which can impact network performance is how the device, subsystems, and/or modems power cycle or transition from one power saving state to the next. Establishing a basic connection between a device and a wireless basestation consumes resources. In some cases, it can also consume other network resources like AAA, HLR and HA. When a device disconnects from the base station’s connection, the modem subsystem, e.g., or a portion thereof, goes from active connection state into a power-save state, network resources are used every time the device enters and exits power-save state. This can happen for a time period of seconds to minutes, in extreme cases even minutes. When a device uses an aggressive power-saving algorithm, such as a device that goes into power save after a brief idle period, it can cause the network to be unable to support many devices. Another example is the creation of network sessions after the base station connection has been established. This is e.g., the establishment a PPP session with a home agent (HA), or another gateway. In this scenario network resources that are required to open/close the network session will be ignorantly consumed if the device exhibits aggressive power-save state cycling or terminates the data session frequently for other reasons.

Application that maintain persistent network communications that generate a high number of packets per second are another example of device activity that can affect network performance. This category includes applications that use persistent signaling. Examples include the frequent device signaling sequences that update widgets on a computer’s desktop, synchronize user data like calendars, contacts and email, check or update email feeds or RSS feeds, access social networking sites or tools, update real-time information, update voice and video chats, and update text and other relevant information. Other application behaviors that can tie up network resources and limit capacity include conference meeting services, video streaming and content update, software updates, and/or any other similar behavior. Even though the user isn’t using or benefiting directly from these types of applications, they can still run in the background and continue to use potentially large network resources.

“Service activities and/or device behavior can impact network capacity and/or resource availability. These include frequent OS and app background network accesses, signaling, software updates, frequent OS and device updates, cloud synchronization services. RSS feeds and/or any other background information feeds. Background email downloads. Subscription service updates and downloads. Text/voice/video chat clients and virus updates. Peer to peer networking apps. Inefficient network access sequences during frequent power cycle or power save state cycling. Large downloads or other high-bandwidth accesses. And/or greedy applications that constantly and/or often access the network with little transmissions or requests. One of ordinary skill in art will be able to see many other examples.

High device transmission bandwidth demand can degrade network capacity, performance and/or availability. However, other types of persistent and frequent traffic such as network resource requests, network accesses, or network interaction can also cause network capacity, performance and/or resource degradation, regardless of whether the aggregate bandwidth demand (measured by total data throughput) is high or low. This is why it is necessary to maintain network capacity.

“Smart phones and other similar devices are exacerbated by frequent queries to the wireless network while such devices move between cell sites. They can, for example push email, access social media tools and/or perform repetitive actions. Data traffic is increasing, but signaling traffic is growing by between 30 and 50 percent according to some estimates. Yahoo IM users may send a message, but wait a few seconds before sending another. The smart phone is often set to idle mode in order to conserve battery life. The device must set up a signaling pathway again after the user has sent another message. Even if the signaling resource has been released, the network does not usually react quickly enough to allow the next station to use resources for several seconds or even minutes. This causes the base station controller to spend a lot of resources processing the signaling. It cannot do other tasks such as allocating additional resources for data network use.

Smart phone vendors have a quick dormancy feature that allows mobile devices to make a quick query to the radio controller to let go of the connection and allow them to return to an idle state quicker. The device is communicating that it is going dormant to save resources (e.g. signaling channel), rather than network resources. The fast dormancy function can make this worse by asking for a network release prematurely and then following up with a request either to reconnect to the network, or to re-establish contact with the network.

“Network carriers have tried to manage network capacity using a variety of purely central/core network-based approaches. Some carriers, for example, have suggested that a robust capacity planning process is necessary and that sufficient investment is required to address the growing capacity crunch. There are limitations to a purely centralized network solution that does not include assistance from a service processor or device-based software agent. If a service user uses certain device apps, OS functions, or other services, there may be limitations to the network. For example, if a network connection is closed behind a base station, even though it isn’t allowed to transfer data, the network can still consume significant network bandwidth or capacity. If the service usage activity is too aggressive in attempting to establish a network connection to transfer data, but the network blocks it somewhere in the network, then a lot of network capacity can be used by many devices that exhibit such behavior, even though they are not allowed to use the service. Some embodiments of protecting network capacity include controlling network usage activities at the source. In some embodiments, service usage can be controlled so that re-try attempts to connect with the network are delayed, prevented, or reduced.

“In some cases, a drawback to purely central network solutions to protect network bandwidth is when service usage activities can be controlled, blocked, throttled and/or delayed in central network equipment without any mechanisms or support to link with a device user interface (UI), to inform the user about what is happening and why. This can result in a poor user experience and lower customer satisfaction. In some embodiments, a device-based UI provides real-time or near-real time information to the user about why a service usage activity has been blocked, throttled and/or controlled to protect network bandwidth. A UI may also be provided in some embodiments that informs the user of the available options to control, modify, override or change service usage controls for the purpose protecting network capacity. Some embodiments allow for user preferences to be used in conjunction with a change of service usage billing. These changes in service usage billing caused by capacity sparing service control modifications by the user are communicated via a UI notification sequence to the user. Some embodiments use user notifications to warn users when service usage activity that is not classified under differential user notification policies could cause the user’s service plan limits to be exceeded (e.g. total data byte count usage caps).

Intelligent network monitoring is required to monitor network traffic at various levels (e.g. packet/layer, stack application layer level/layer and/or application/layer) to ensure that network capacity is protected while maintaining acceptable user experiences. Network operators/carriers would have greater visibility into network usage and network traffic using Device Assisted Services (DAS), and sometimes network-based techniques. This would allow them to monitor network traffic and provide network service usage monitoring.

“Intelligent wireless network monitoring to efficiently manage network service usage can include providing Device Assisted Services, (DAS), for protecting network capacities in accordance with various embodiments. Intelligent network monitoring can be used to monitor network usage and protect network capacity. This includes differentially controlling software updates over the air and/or via wired connections only. Another example of intelligent network monitoring is differentially controlling different applications to protect network capacity. Intelligent network monitoring of wireless networks can be used to monitor network service usage and protect network capacity. This can include managing network access requests that result from power failures in the modem. These can lead to resource-intensive reconnection and/or authentication processes. Intelligent network monitoring of wireless networks can also be used to protect network capacity. This includes techniques to keep PPP sessions alive in order to prevent the need for network resources to reestablish them (unless an application behavior analysis predicts that the mean access time is too long for the PPP session not to be dropped)

“Unlike traditional QoS methods, which are used for establishing a single or end to end service level(s), techniques disclosed herein to protect network capacities facilitate the implementation of services on networks to facilitate differential control over certain services to protect network capability (e.g. to reduce network congestion and demand, network resources demand, and/or increase network availability). As also disclosed herein, techniques disclosed herein for protecting network capacity facilitate implementation of services on a network to facilitate differential control of certain services to protect network capacity can also facilitate QoS implementations by maintaining needed levels of network capacity/availability to facilitate delivery of certain QoS levels/classes. Techniques disclosed herein can be used to protect network capacity by aggregating across multiple services and/or devices in order to allow differential control of certain services to ensure network capacity. As another example, techniques disclosed herein for protecting network capacity can be used to provide for dynamic QoS classifications (e.g., dynamically assigning/classifying and reassigning/reclassifying (based on various criteria, events, and/or measures) network service usage activities to various QoS levels/classes, such as described herein) to facilitate differential control of certain services to protect network capacity.”

“Device Assisted Services (DAS), which protect network capacity, are provided. DAS is a method of protecting network capacity. In some instances, DAS can be used to control network activity usage by a device that connects wirelessly to the network. For example, controlling network service usage activities can include classifying and/or controlling network access requests (e.g., IP address requests), network access reservation requests (e.g., a QoS reservation/sequence), network capacity/resources usage (e.g., bandwidth usage), and/or any other network service usage activities. Some embodiments allow applications, OS functions and/or other network usage activities to request IP addresses from the network address server resources. These requests can be classified and/or managed so that IP address requests can be withheld, delayed or time windowed, reduced frequency, aggregated, or otherwise controlled. These policies are called “IP address request control policies”. For one or more applications, OS functions and/or other network usage activities are set up, updated, or modified before it is communicated over a network connection with a network element (e.g. a service controller, or another network element/function). Some embodiments allow network service usage activities to be generated/requested from applications, operating system functions (OS) and/or other software/functions that are executed on a device communicating with the network. It is possible to use a service usage policy to control network usage to protect network capacity (e.g. reduce network capacity demand). Some applications and/or Os functions are not able to defer traffic types based only on their fixed settings. These applications and/or functions cannot optimize network service usage activities based upon a current network bust state (e.g. changing network capacity or network performance). In some embodiments, the network busiest state, or alternatively, the network availability state, is a description of congestion (e.g. or conversely, available capacity) in the network for one or several device connections. The network busy state, for example, can indicate how congested a segment of the network (e.g. network edge element) is in relation to one or more devices. Another example is network availability state, which can indicate the network resources available to one or more devices. Network availability state and network busy state are two different ways to provide similar information. As described in various embodiments, they can be interchangeable.

“In some embodiments, techniques can be used to assign a priority to network service usage activities and control traffic associated with those usage activities based on that priority. Some embodiments provide techniques for the implementation of a differentiated, dynamic background service classification. This could be, for instance, as a function network availability state or network busy state.

“In some embodiments, the service usage control policy can be used to assist in network access control of network usage activities (e.g. deferring some of the network capacity demand from such source activities). Some embodiments allow for some or all of the network capacity to be satisfied at the point when the network resources or capacity is more available or less busier. Some embodiments provide techniques for classifying network activity associated with an application or OS function to a background class and differentially controlling background service class traffic. Some embodiments provide techniques for classifying network service activities associated to an application or OS functionality to a background class while other network activity associated with the application or OS functions are classified to other service types (e.g. or to different background class priority levels).

“In some embodiments, techniques can be used to determine a network busiest state (e.g. for a network edge connection to a device such as for a radio access number (RAN) for the device’s wireless network access and/or the base station/base controller in wireless communication with that device. Some embodiments provide techniques for controlling network traffic using a service usage policy. This is based on whether a particular activity, group of activities or service class is in the network busy state.

“In some instances, DAS to protect network capacity involves monitoring a communications device’s network service use activity in network communication; classifying that network service activity for differential network acces control for protecting the network capacity; associating that network service utilization activity with a network usage control policy based upon a classification of network service activity to facilitate differential network control to protect network capacity.”

In some embodiments, a network usage activity refers to any activity that involves wireless network communication. An application, an OS, and/or another device function can generate a network usage activity in some embodiments. An application, an OS, and/or another device function may generate one or more network service usage activity in some embodiments. A network service usage activity can include a voice connection (e.g. coded voice connection or voice-over IP (VOIP) connection), an application connection or widget connection to an operating system (OS), an email text connection to an email server, an email download connection to an email, and a file transfer connection to an internet connection.

“In some instances, network service usage activity can be classified, associated with, or assigned to a background classification (e.g., QoS or background service class). This is done to enable differential network service usage control in order to protect network capacity. Some embodiments of differential network usage control include the following: monitoring network usage activity, accounting for network usage activity, reporting network usage activity, generating a notification for a service usage event; accepting a preference for network usage activity control; implementing a network usage policy (e.g. block/allow; traffic control methods such as delay, priority queues, time window, throttle, kill, remove and other well-known traffic control techniques); implementing UI interception procedures; generating a notification about network activity; generating a notification; generating a notification; generating a notification; generating a notification; generating a notification; generating a service usage of a service; a notification to generate a service usage of a service activity for differential network usage control; generating a notification

“In some embodiments, a network availability state includes a state or measure of availability/capacity of a segment of a network (e.g., a last edge element of a wireless network). A network busy state, in some embodiments, refers to a state that measures the network usage or network congestion for a segment of a given network (e.g., last edge element of wireless network). In some cases, the network availability state and network busiest state are inverted measures. In certain embodiments, network availability and network busy states can be interchangeably used based on design choices. For example, designing to assign background policy based on network availability or network busy yields similar results but they are different ways of characterizing network performance, capacity, and/or congestion. In some embodiments, network availability state and network busy state are dynamic measures as such states change based on network usage activities (e.g., based on a time of day, availability/capacity level, congestion level, and/or performance level). Some embodiments allow differential network usage control to be based on network availability or network busy states.

In some embodiments, network service usage activities can be classified as background services. Some embodiments classify certain network service usage activities as background services. They are classified based upon a network busier state. These activities can be differentially controlled to protect network capacity. Some embodiments use differential network usage control policies that are based upon a time, a network busier state, background services, and/or QoS classification changes based a time, day, and/or network busy states. This allows for a deterministic schedule and back-off for certain network usage activities. It also provides a window in which network usage control policies can be applied to one or more service activities.

“In some embodiments, the network capacity controlled service/network capacity controlled services class includes one to more network services (e.g. background download services and/or other types/categories of services as described herein), selected for differential network usage control to protect network capacity. A network capacity controlled services class may include one or more network services that are associated with a network control service/class priority setting to limit network usage. A network capacity controlled service, or network capacity controlled classes class, may include one or more network services that are associated with a QoS classification for differential network usage control to protect network capacity. A network capacity controlled service, or network capacity controlled class in some embodiments includes one or more network service associated with a dynamic QoS classification for differential network service usage control to protect network capacity.

“For example, differentially managing network service usage activities using network capacity controlled services, dynamic QoS, or QoS classes can help protect network capacity. This includes improving network performance, increasing network accessibility, decreasing network resource demand, and/or reducing demand for network capacity (e.g., depending on an individual device or aggregate devices connected with an edge element and/or aggregate devices connecting to many edge elements). Some embodiments allow for differential control of network service usage activities using network capacity controlled services, dynamic QoS and QoS classifications. This can help protect network capacity and maintain proper device operation. In some embodiments, differentially controlling network service usage activities based on network capacity controlled services or dynamic QoS or QoS classifications can protect network capacity while maintaining an acceptable user experience (e.g., proper and/or expected device operation, proper and/or software/application/OS/function operation, avoiding (whenever possible) significant adverse impact on device functions, and/or user notifications to keep the user informed of various differential control implemented on the device).”

“In some embodiments dynamic QoS classes include QoS categories that can dynamically be modified (e.g. reclassified or reprioritized and/or upgraded and/or downgraded). These QoS classifications are based upon various criteria, settings and/or user inputs as described herein. The various techniques herein for DAS to provide network capacity and/or QoS to DAS can be applied to some embodiments.

“As wireless networks such as mobile networks evolve towards higher bandwidth services (e.g. conversational, interactive and streaming data and/or many (end-to end) real-time services that can benefit from QoS), there will be increased demand for converged networking services to facilitate such services between networks (e.g. to allow control and/or support such services across network boundaries such as between wireless network (such as different service provider networks), IP networks (such the Internet) and/or other networks. Although many efforts have been made to address these QoS issues, including policy management frameworks to facilitate QoS end to end solutions, it is clear that there is a need for Device Assisted Services to meet various QoS requirements.

“Accordingly Quality of Service (QoS), for Device Assisted Services, (DAS), is provided.” In certain embodiments, QoS is available for DAS.

Differentiated services are usually available to establish a QoS channel. This means that one class/level has a higher priority than the other in order to provide differentiated services on a network such as a wireless network. In a wireless network, for example, different network functions/elements can be configured and controlled to create a single end-to-end QoS channel. A centralized QoS policy coordination function and decision function using DAS techniques is available in some embodiments to coordinate the QoS channel setup control and coordination among various elements of a wireless networking.

In some embodiments, QoS channels refer to the logical communication channel that is connected to a device that offers a desired QoS service level. A QoS channel may be made with one or more QoS Links. Each link represents a QoS-enabled connection that spans a portion the entire end to end network communication path, from a near device to a distant device. The far end device may be connected to the same network as the near end device, or to a different network with different access technology, and/or different access network carriers. One or more QoS channels may include QoS links. In other words, some links are QoS-enabled and/or others are not. A QoS channel may include, for example, the following links.

“In some embodiments, each link described above has the ability to provide QoS service for the segment of an overall QoSchannel. Some embodiments enable QoS for the device traffic path link,/or the device access network equipment link, but not the carrier core network or IPX network links. Some embodiments have enough bandwidth over-provisioning to ensure that QoS can not be limited by these network elements. This could, for instance, limit the bandwidth available to the device traffic link or the device to access the network equipment link. These links are not desirable QoS enabled. One common example is a wireless network that has a 2G/3G/4G network. In this case, the QoS channel links for the core network and IPX networks are enabled.

“In some embodiments, QoS sessions refer to QoS-enabled traffic that flows over a QoS channel/QoS link. This QoS traffic supports QoS service activities. A QoS service activity may include a request, configuration, or service that is preferably provided with a certain level of QoS. Some embodiments define a QoS service activity as a service usage that is requested, configured, or preferably serviced with a given level of QoS. For example, QoS service activities that are supported by QoS sessions can include VOIP traffic, streaming video traffic, differentiated access bandwidth during busy network periods, real-time interactive traffic, such as network connected multimedia meetings (e.g., shared presentations, picture, video, voice, and/or other such applications/services), best effort interactive, such as Internet browsing, time sensitive services, such as email message body delivery, near real-time interactive services, such as SMS or push to talk, background download services, such as email downloads and other file transfers (e.g., FTP), and/or truly background download services, such as software updates (e.g., OS or application software updates and/or antimalware updates including content/signature updates).”

“In certain embodiments, different QoS levels and classes are supported. A conversation class, for example, can allow real-time traffic. This is a sensitive service that can tolerate packet loss and bit errors. The conversational classes are used for Voice Over IP (VOIP), and video telephony. Users of these services can benefit from the conversational classes’ short delay features. The streaming class is similar in function to the conversational, except that it can generally tolerate more delay than the conversational. A streaming class is used when the user on one end is a human user and the other is a machine/computer. This is for streaming content applications such as streaming videos or other video content. An interactive class is designed for traffic that can allow for delay variation and requires a low response time (e.g. web browsing or other applications where the channel may be used for long periods of times but the user requests a new page/data. The response time should be reasonable low). A background class is generally used for lowest priority service usages (e.g., typically used for e-mail with and without downloads/attachments, application software updates, OS software updates, and/or other similar applications/functions). In some cases, different QoS classes and services can be applied to the conversational Class. In some cases, different QoS classes and services can also be applicable to the streaming class. Some embodiments allow for various QoS services or classes to be applicable to interactive classes, but not to background classes. One of ordinary skill can see that other classes are possible depending on channel requirements, service usage, and/or network architectures.

“In some embodiments, QoS links or QoS channels support one QoS session. Some embodiments support multiple QoS sessions through a QoS connection or QoS channel. QoS link provisioning can be used to set the QoS traffic level of a QoS session, or group of QoSs.

In some embodiments, a QoS Channel can be either a single-ended QoS channel (or an end to end QoS channels). If a QoS channels is end-to-end, the QoS channel provisioning takes place in coordination for each QoS enabled link within the QoSchannel. A single-ended QoS channel means that the network elements and/or devices participate in provisioning the QoS channels for as many ends as possible. Provisioning the QoS channels for other ends of the QoS channels is left to the device and/or network element responsible for handling the traffic. One end of a QoS channel may include another QoS channel at its other end. One end may have a single-ended QoS channel while the other end is a best effort level. This is possible, for example, when one end is QoS capable on a 3G wireless network with limited bandwidth and the other end is QoS disabled on a cable modem network device that is lighter loaded, but which may not be required to enable QoS to ensure adequate voice quality.

“In some embodiments, QoS requests (e.g., QoS channel request, QoS services request) are requests for a QoS provisioning event that will enable a QoS channels for one or more QoS activity. In some embodiments, QoS availability assessment involves determining whether one or several links in a QoS channel are available (e.g. based on network quality and transmission quality) to provide the required level of QoS. A device, user, application and/or network element/function can initiate a QoS request in some embodiments.

“In some embodiments, the service plan is the collection of access services capabilities, QoS capabilities and/or network capacities controlled services that are associated to a communications device. The access control policies that are set for the device can determine the access service capabilities, QoS abilities, and/or network capacities controlled services. These service control policies may be implemented in the network equipment in some embodiments. These access control policies can be implemented in both the network equipment and the device in some embodiments. These access control policies may be implemented directly in the device. There may be different levels in service control capabilities depending on the level of service plan payments, device standing, or user standing. Some embodiments allow for different levels of service control policies depending on network type, time, network busy status and/or other criteria/measures. Some embodiments determine the type of service activity to be controlled and the access control and QoS policies based on it. The policies associated with the service plans can determine the QoS and access levels available for a particular service activity for a device or user. A QoS authorization assessment may be performed in some embodiments to determine if a device or user is able to access the required level of QoS.

“In some embodiments, QoS availability assessments are performed before a QoS link or channel is provisioned. This is done to assess the availability of communication channels to provide the required level of QoS to the channel or link. This QoS availability assessment can be done in a number of ways. The available QoS link capacity for a number of devices can be evaluated, including a device traffic path and a device-to-access network equipment link. A core network link and/or an IPX link. QoS service requests can be granted if the QoS assessment reveals that there is sufficient channel capacity and quality to provide the required QoS level for the requested QoS activities. A QoS link, or QoS channels reservation process, may be provided in some embodiments to reserve QoS quality and capacity prior to link or channel provisioning. This is to ensure that QoS resources are not allocated between QoS availability assessment or QoS channel provisioning.

“In certain embodiments, QoS availability assessment may be performed after QoS authorization assessment. This prevents unnecessary exercise of network elements if the user or device does not have enough service plan to receive the desired QoS level. This can be an important screening function performed on the device in the service processor, or by a centralized network function such as the service controller (e.g., or interchangeably, the home agent; Home Location Register (HLR); Authentication, Authorization, and Accounting (AAA) server/gateway/function; base station; one of the gateways, policy and charging rules function (PCRF), or other network element/function). In some cases, QoS availability can be assessed before a QoS authorization assessment is conducted or after receiving the response.

“In some embodiments, the QoS channel is provisioned in order to create the QoS channels to support a session (e.g., QoS service activities). QoS channel provision may include routing and/or assigning QoS session traffic over QoS links within the QoS channel.

“In some instances, device-assisted service traffic control and QoS can be applied directly and readily to the problems associated with managing a QoS link for QoS channel provisionsing. In some embodiments, a service provider can be provided to help with the provisioning of the device section of the QoS channel. Some embodiments provide the service processor with the ability to provision the device link portion. This is done by giving higher priority to higher QoS traffic. This QoS priority can be implemented in various ways. For example, routing higher priority QoS traffic to first priority in downstream and/or upperstream traffic queues. In some embodiments, upstream traffic queuing can be done directly by sending guaranteed bit rate traffic first with higher available throttling speeds, differentiated QoS trafic second with a controlled throttled rate, best effort traffic third with lower controlled throttled rates and/or background traffic forth when/if bandwidth is not required by the higher QoS traffic levels and lower controlled throttling rates. To handle downstream traffic, one can queue traffic and delay or prevent TCP acknowledgments from being returned for lower QoS priorities, while simultaneously passing traffic and TCP acknowledgments for higher QoS priorities. In order to provision the device link portion, the QoS channel, policies are used to determine the TCP acknowledgement return rate, queuing priority and delay for device traffic. This is based on the available bandwidth at the time. In some embodiments, different device service processor traffic control abilities regulate or partially regulate QoS according to a set network policy instructions. Some embodiments include a service plan policy set.

“In some instances, the device service processor creates multiple QoS channels via the device traffic path. Each QoS channel has traffic control policies as discussed herein. With each QoS channel policy creating a different type of QoS. This multiple QoS channel approach can provide QoS for certain service activities by routing traffic to the QoS channel that has the correct QoS policy settings. There are many ways to route traffic to the QoS channel. The routing can be done by applying a common traffic control policy to all traffic related to QoS service activities that request or require the QoS. You can apply the service traffic control policy in many ways using the embodiments for the policy implementation and policy control agents described herein. This reduces the problem of assigning a QoS channels to multiple QoS services activities by applying a predetermined set service traffic control policy to each QoS activity. Each service traffic control policy represents a different QoS category. The device will manage the overall QoS of all traffic based upon the available traffic capacity, quality, total aggregate traffic demand for each QoS class, and the policy rules that determine how each class is provided with differential bits rate and traffic quality compared to other traffic classes for the same level of traffic capacity.

The service processor can adjust the available bit rate or percentage of traffic capacity based on aggregate demand for each traffic class. In some embodiments, the aggregate traffic demand class for real-time interactive traffic control (e.g. In some embodiments, the aggregate demand for the real-time interactive traffic control class (e.g. The QoS channel capacity is allocated more capacity out of available capacity as the QoS services become more demanding. When the QoS activities are less frequent, this QoS channel capacity is released. If the device doesn’t have enough capacity at a guaranteed QoS rate, additional QoS service activity that require, request or desire this QoS will be denied access. Instead, the QoS will be reduced or the user will be forbidden from connecting to the network. Some embodiments allow for a hierarchy of QoS service activity types. If there is not enough capacity at a particular service QoS level then the QoS classes available are given to service activities with the highest priority. After that, one or more QoS activities that are too low in the priority list to receive service with that QoS type are either denied access or bumped to a lower class. Some embodiments allow for the allocation of remaining QoS channel class capacity among other QoS channels classes according to a priority policy. This policy is based on the relative priorities of each service class, each QoS activity’s relative priority, or a combination of both the relative priorities of each QoS class and each QoS activity. These relative priority policies may vary from one device to another depending on the service plan selected, device type, user status, user group, device connection, type and time of day, network business state, and/or any other criteria/measures.

“In some embodiments, the QoS link between the device (and an access network equipment element) is established. These equipment elements can include, for example, a 2G/3G/4G/4G wireless basestation, a wireless access station, a wireless head end, a DSL network DSLAM and a fiber network traffic aggregator. A frame relay aggregation, ATM aggregation, and/or any other network equipment. Some embodiments create a logical communication link between the device and network equipment element. The logical communication link supports a particular level of QoS/QoS class traffic policy. The logical channel may include a RAB between a base station (2G/3G/4G) and a wireless device endpoint. You can create the RAB by controlling the media access control parameters (MAC) of the base station radio channel to ensure that QoS class policies are implemented. The RAB can be configured to support constant bit rate, low latency communication traffic. This is for guaranteed bitrate real-time traffic. It can also be used for streaming traffic. This QoS channel link can be used to support a single device or shared with a subset or all of them. This QoS channel link can be used by the device for support of a single QoS activity, or group of QoS actions as described in this article. One of ordinary skill can now see that similar settings for cable modem MAC and cable head end can produce similar QoS levels for QoS connections for the cable modem case. Similar techniques can also be used for a wireless access points or satellite system MAC to achieve comparable QoS classes. One of ordinary skill can now see that similar QoS classes QoS links can also be established by using multiple logical channels within the device link and/or changing the access network capacity and quality for each channel. This is possible for both DSL and fiber distribution networks cases.

“In some embodiments, the device service processor routes QoS service activities along a logical communication channel that is established for the QoS class desired by an access network element and the device. Some embodiments allow the use of the device service processor elements, such as the policy implementation agent or the policy control agent, to assign the same QoS control policies to multiple QoS activity activities that have the same QoS level. Similar to above, some embodiments allow the device service processor elements to be used to route service activity traffic of a particular QoS level to the correct logical communication link between the device (e.g., 2G/3G/4G access station) that supports the traffic management policies for the requested QoS. A QoS service connection that supports guaranteed bit rates and latency can be established using one or several RABs from the base station to the device. A second QoS link can also be established that supports preferred streaming content access via one or more RABs. Finally, a third best-effort RAB can be used for best effort traffic. Each required RAB is requested first and then provisioned according to the requirements for the QoS service classes associated with the RAB policy parameters. Once the logical QoS channels are established, the service processor, e.g., QoS router function, routes traffic associated with each QoS activity to the relevant RAB. Some embodiments allow the service processor to detect changes in aggregate QoS classes demand as QoS activities are initiated and terminated. The service processor can then communicate any required increases or decreases of RAB assignments necessary to support that logical channel.

“In some cases, the access QoS connection is established via direct communication between the device and the access network element. In these cases, the device requests the channel or link from the access device or an intermediate networking device such as a service controller. The device service processor may base the QoS channel request or link request on the association that the device makes to match a QoS activity or QoS traffic control policies set. This can be done by using a pre-defined policy mapping, which is stored on the device. This policy mapping store can be populated by a service controller and/or updated in some embodiments. A service controller may determine the mapping based on the report from the device of the QoS activity that requires the QoS channel/link.

“In certain embodiments, the required QoS level for one of more QoS activity activities can be determined by a set QoS traffic control policies that have been pre-assigned to different QoS activities. A QoS class can be assigned to an application, for example. A QoS class can also be assigned to a web service destination, such as a VOIP site. Another example is that an application may have one QoS level for Internet traffic and another for real-time gaming traffic. Another example is that a broadcasting website may have a best effort level of QoS for general browsing and programming information, and a streaming QoS degree for broadcast traffic content. Some embodiments allow for the assignment of QoS to an activity by a device processor in accordance with a pre-defined QoS rule rules table. This can also be done by a service controller using information from the device.

“In embodiments where both ends of the QoS channel take part in the establishment of an end-to-end QoS channel the required QoS level can be determined and/or communicated to the receiving end point. The receiving end point may determine and/or communicate the QoS level in some embodiments. The receiving end point service controller may determine and/or communicate the required QoS level. This could be the access network element (such a base station), HLR, home agent or mobile switching center, AAA or gateway, or any other function or element of the network. The receiving end point controller may determine and/or communicate the QoS level (e.g., alternatively, the access network element (such a base station), HLR, home agent mobile switching center AAA, gateway or any other network element/function). In some embodiments, the receiving or access point service controller, such as the base station, HLR, home agent or mobile switching center, AAA or gateway, and the originating end-point service controller (e.g. or another similar function) communicate to one another in order to coordinate the establishment of the QoS channel among the end points.

“In some cases, the near end (or originating end device) service processor contacts far end (or terminating device) service processor to initiate a quality of service channel. The far end device initiates the QoS channel automatically if it detects that the service processor of the near end or origin device requires a certain level of QoS for communication between the devices. Some embodiments require that the near end, originating device service processor, detects that a QoS channel is required for communication between the two devices and contact a central network resource, such as the service provider (e.g. or another equipment element with similar function). The service controller then provisions the far side of the QoS channels by either communicating directly with the far device or communicating with its service controller (e.g. or another equipment element with similar function). Some embodiments allow the far-end device service controller to be contacted to help with provisioning the QoS channels. This is done using a lookup function that uses some aspect of far end device credentials (e.g. phone number, SIM ID and MEID, IMSI or IP address), and then the service controller provisions the far end of the QoS channel.

“In some embodiments, mapping QoS service activity at the desired QoS level or QoS traffic control policy is done by providing a QoS API within the device service processor. This API allows applications to request a QoS channel connection or class. An API is available to allow application developers to create software that uses standard interface commands for setting up QoS channels. The API may perform one or more of these functions: receives QoS channels from applications, formats them into a protocol that can be transmitted to network equipment (e.g. the device control system), coordinates to reserve QoS channels, coordinates to other network elements to provide a QoS channel to the application and/or coordinates to other network elements, such as the device control system, to connect it to the QoS class desired. The QoS API may accept an application QoS request, coordinate with one or more QoS equipment elements (e.g., base station, cablehead end, or access point) and possibly communicate and coordinate with them. The QoS API may accept the QoS request form the application, and communicate with and coordinate with an intermediate network element such as a service processor or another similar function, in some instances. The QoS API may assess the QoS plan standing of the device or user, before initiating the QoS request sequence. This simplifies the complex task of setting up a QoS channels with all of the equipment communication protocols required to establish QoS channels. It also makes it easy for the application development community to use the API commands to create QoS differentiated applications and services.

“In some cases, traffic control on both the device service processor and the link between it and the access network element is combined. This allows both the device to access network element QoS and device traffic control path QoS links to be combined for optimal QoS performance. The link between the device and access network elements can be coordinated, based on the available capacity and quality for the device’s access network traffic. Predefined policies loaded onto the device from the service controller or equivalent network element determine how the device handles local traffic control and establishes access network elements logical channels (e.g. RABs). They also determine how traffic is routed to and from these logical channels. These policies may be set by the service controller in some instances.

“In some embodiments, the QoS user interface (e.g. QoSUI) is presented to a device user. The QoS UI may inform the user based on their service plan selection which level of QoS services they are authorized to receive. The QoS UI may inform the user about the available QoS services on the network to which the device is currently connected. The QoS UI may notify the user if a higher level of QoS services is necessary or desired for a service activity the device has initiated. The QoS UI may offer a variety of upgrade options that allow the user to upgrade their service plan to include a higher QoS level for one or more service activities. The QoS UI allows the user to select the level of QoS they would like to use for one or more services. The QoS UI can be used to create a service plan that offers differentiated QoS in busy times. The QoS UI may allow the user to buy one or more grades service QoS. This can be done with a post-pay that covers a predetermined service period and one, two, or three pre-determined service usage limits. The QoS UI allows the user to enable QoS or to pay for QoS services that are initiated by an incoming connection.

“QoS for DAS technologies may include verifying that the device implements the QoS traffic control policy, such as in accordance to a service plan. This prevents hacking, manipulations of user device software settings, and other malware events from causing an inappropriate level of QoS on a particular device or group of devices. In some embodiments, traffic control and QoS verification techniques are used to ensure that QoS is being applied in accordance with QoS priority policies for certain service usage activities. Verification of QoS channel request policies behavior can be done in many ways. For example, it is possible to monitor QoS channel requests from devices and compare the QoS received with the QoS plan that the device is allowed to receive. You can verify that a QoS channel is being used properly by a device in many ways. For example, you could monitor network reports about QoS service usage, and compare the network reports with the service policy rules for the device’s service plan. You can verify that traffic control policies are properly being implemented by devices to ensure that they are performing as intended. DAS techniques for protecting network capacity may include various verification techniques, such as verifying monitoring, traffic control, reporting and/or any other functions performed or executed by the device.

“In certain embodiments, the QoS router prioritizes traffic to the device. The QoS router may connect the QoS-enabled session to the RAB with the appropriate QoS level. One session can be routed to the RAB in some embodiments. One session can be routed directly to the RAB in some embodiments. In some embodiments multiple RABs with multiple QoS levels can be created to the device. The QoS router routes every service activity to the RAB determined by the QoS policy rules.

“In some instances, the network may collect service usage fees for different QoS classes. Some embodiments allow for differentiated service charging to be applied to different types of QoS service usage. Because guaranteed bit rate traffic uses network resources regardless of whether it is being used, there may be a time factor in charging calculations. For example, guaranteed bit rates services can be charged based on the bandwidth provided to the device at any given time multiplied with the time bandwidth was made available. Differentiated access traffic with a higher QoS than the best effort traffic, but not guaranteed bit rate, can be charged at a higher than best effort traffic, but lower than guaranteed bits rate. These traffic may be charged according to the time that the QoS channel becomes available or the total data transmitted over it. In some embodiments, best effort traffic is charged based on the total data used. The data charges are less than those for differentiated streaming access services. In some embodiments, background data services are charged at the lowest rates. This could be because they are not available during peak hours or when there is less demand for them. The service is also based on the total data transmitted. All QoS service levels may be charged at a fixed price and for a fixed period. There may also be a usage cap that can be added to add additional fees. For higher QoS levels, the price is higher in such fixed-price scenarios. Some embodiments collect service usage fees from the network for different classes of network capacity controlled service. Some embodiments allow for differentiated service charging to be applied to different types of network capacity controlled service usage.

“In some embodiments the network equipment (e.g. access network element, gateways and AAA, service usage storage system, home agent, HLR and/or billing system) records and reports service usage for one or several QoS service classes. The device service processor may record and report service usage for one or several QoS services classes and send the QoS class usage to the controller (e.g. or another substitute network element). If the device records usage data for one or more QoS services classes, it is necessary to verify that reports of device usage are accurate. As described in this article, some embodiments require that service usage reports are verified against the actual service usage. This can be done using the following techniques: service processor agent functional operation verification, agent query responses sequences, service control policies on the device, device service processing software protection techniques, software environment checks for device service processor software, and many other techniques. One or more of the verification techniques can be used to verify a device-assisted QoS service usage billing system. Another example is that one or more of the verification techniques can be used to provide a verifiable network-capacity controlled service usage charging system. Some embodiments of network equipment, such as access network elements, gateways, AAA service usage storage system, home agent, HLR mobile data center and/or billing systems, record and report service usage for one, or more, network capacity controlled service classes that are used by the device.

Device assisted traffic control may be used to manage network congestion in certain embodiments. Device assisted traffic control is provided for managing network congestion in certain embodiments. For example, if a base station or group has traffic demand that exceeds the available capacity or quality, then a service controller (e.g. or another network function), can issue, send and/or implement traffic control policies to/for devices according to the amount of excess traffic demand the base station is experiencing. The device service processors that are connected to a busy base station can be instructed, for example, to lower the traffic control priority for one or two classes of QoS traffic. This will reduce the queueing priority, throttling speed, delay, and/or access allowance for any or all of the classes. Another example is that the device service processors attached to a busy base station can be instructed reduce the traffic priority for one or several classes of network capacity controlled traffic traffic. This will decrease the queuing priorit, throttling, delay, and/or access allowance for any or all of these classes. Another example is background downloads, which may include software updates, can be disabled completely or throttled back substantially. Another example is that best effort traffic, such as Internet browsing, can be throttled or decreased for devices that are connected to base stations with high traffic demand. Another example is that a policy may be applied to devices connected to busy bases stations. This policy allows the device to browse the Internet or perform other best effort services at a high throttling speed for a time period. However, if the device consumes more service (e.g. total data downloaded/uploaded) within a time period, then the device can be traffic controlled using an adaptive throttle policy, as described below. Higher QoS traffic can’t be throttled under certain circumstances. This is the case for VOIP traffic, which requires a real-time guaranteed bitrate to meet user expectations. Lower priority traffic, such as background download and interactive browsing, may not be throttled. Some embodiments adjust the QoS availability assessment process described herein so that higher QoS channels cannot be provided or provisioned at times or locations when a base station or group has excess demand or demand exceeding a threshold.

“In certain embodiments, devices or users with service plans that offer higher quality of service or higher priority during busy network times have different traffic control policies applied to them (e.g. for QoS services or network capacity controlled services). This results in higher traffic performance and/or higher availability of QoS services. Emergency service workers may be granted access policies with higher traffic control that allow them to provide differentiated services during peak times. Some embodiments allow users to obtain premium service plans for differentiated access during peak busier times. They may also use higher QoS settings and/or service packages to ensure differentiated service during peak peak hours. Services that require high QoS levels, such as instant messaging, push, differentiated streaming and/or interactive games, are not traffic controlled in the same way that lower priority services are or are traffic controlled during peak times. This type of service differentiation could also be applied based upon device type, user group and user standing, points earned from user reward zones, and/or any other criteria/measures, as described in the above.

“In some embodiments, the device service processor makes the decision to reduce, increase, or otherwise control access traffic control settings according to the device’s assessment and network capacity. This can be done using various methods as described herein. A service controller, which is an interchangeable network element or elements described herein, connects to the device and provides instructions to the device for adjusting the access policy settings. In some embodiments, this decision to control access traffic control settings as described above, is made by the device service processor. The service controller, for example, can access information about network capacity from access equipment elements or device reports of traffic quality and/or traffic capacity as described herein. It also has the ability to obtain reports on traffic capacity/quality from dedicated devices that are used for the purpose assessing network capacities. Some embodiments allow the control of access traffic control settings to be determined based on time of day or week to account for cyclical patterns in traffic demand and network capacity.

“In some embodiments, the service controller (e.g. or another network element or elements) evaluates the network busy state and controls device traffic demand by reducing one or more service classes (e.g. for QoS services or network capacity controlled services) supported through the access network elements such as a wireless basis station. The service controller (or similar function) collects network capacity information using one of these techniques and then instructs one or several access network elements to lower the capacity offered for one or multiple levels of QoS classes or network capacity controlled services classes to one or both of the devices connected with the access network elements. The determination of which devices to throttle back may be based, for example, on equal throttling of all devices in a service plan status or on device traffic patterns in the past, as described herein.

“In certain embodiments, the device can be enabled with ambient services that offer differentiated QoS and/or network capacity-controlled services. Ambient QoS can be provided by using pre-assigned QoS policy for a service activity within the ambient service or an ambient service application that requests QoS via the QoS API. One of ordinary skill in this art will be able to see other ways of providing QoS differentiated services activities within the ambient service offerings. Another example is ambient network capacity controlled service techniques that can be offered using pre-assigned network capacities controlled policies for a particular service activity set within an ambient service, monitoring, dynamically assigned techniques and/or an ambient service application using API or emulated API technologies and/or other techniques described herein.

“In some cases, the QoS service control policies are adapted to the network that the device is connected. QoS traffic control policies, and/or QoS charging policies, can differ depending on whether the device is connected wirelessly (e.g. a 3G/4G network with less QoS enabled traffic capacity) or wiredly (e.g. a cable network with more QoS available). The service controller and the device processor can work together to adjust the QoS control policies and/or QoS charging policies depending on the network to which the device is connected. The device QoS control policy and/or the QoS charging policy can be modified based on whether it is connected to a home or roaming wireless network. As described above, some embodiments adapt a network-capacity controlled service control policy or a network-capacity controlled charging policy based on the type of network the device connects to.

“In some embodiments, QoS-related techniques and/or network capacities controlled services techniques described in this document are performed on the device by DAS techniques and/or the service controller in secure communications with a verified processor executed on the device via DAS techniques. In some embodiments, various of the QoS related techniques and/or network capacity controlled services techniques described herein are performed by/in coordination/communication with one or more intermediate network elements/functions for assisting in various techniques (e.g., functions) for QoS techniques and/or network capacity controlled services techniques as described herein.”

“FIG. “FIG. The network architecture in FIG. illustrates how QoS is implemented for DAS techniques. 1. Some embodiments of DAS to protect network capacity techniques described herein can be implemented using the network architecture illustrated in FIG. 1.”

“As shown, FIG. FIG. 1 shows a 4G/3G/2G wireless networks operated by, for instance, a central provider. As can be seen, different wireless devices 100 communicate with base stations (125) for wireless network communication with wireless network (e.g. via firewall 124), while other devices 100 communicate with Wi-Fi Access points (APs), Mesh 702 to wireless communication to Wi Fi Access CPE 704 and the central provider access network (109). One or more of the 100 devices may be in communication with another network element/equipment, such as a DSL network DSLAM (distributed over a wireless network), a fiber network aggregater node and/or satellite network aggregation. Each of the 100 wireless devices includes a service processor (as shown), which is executed on the processor of the wireless device 100. Each service processor connects via a secure control plane link with a service controller (e.g. using encrypted communications).

“In some embodiments service usage information can include network based information (e.g. network based charging data records (CDRs) or network based services usage measures (not shown), which can be generated by service utilization measurement apparatus in network equipment). This information is obtained from one or several network elements (e.g. BTS/BSCs 125 and RAN Gateways (not showed), Transport Gateways(not shown), Mobile Wireless Center/HLRs 132 and AAA 121, Service Use History/CDR Aggregation Mediation, Feed 118 or another network equipment). Some embodiments include micro-CDRs in service usage information. Some embodiments use micro-CDRs for reconciliation or CDR mediation that allows for service usage accounting for any device activity. Each device activity that is associated with a billing event in some embodiments is assigned a microCDR transaction number and the service processor (115) is programmed for accounting for that transaction code. The service processor 115 reports micro-CDR usage information periodically to the service controller 122, or another network element, in some embodiments. The service controller 122 may reformat the heartbeat microCDR usage information into a valid CDR file (e.g. a CDR file that can be processed or generated by an SGSN/GGSN or any other network elements/equipment authorized for generating/processing CDRs). This is then transmitted to a function for CDR mediation (e.g. CDR Storage Aggregation Mediation, Feed 118).

CDR mediation can be used in some cases to account for micro-CDR service use information. This is done by depositing the information into a suitable service usage account and subtracting it from the bulk user device service usage account. This technique, for example, allows for flexible service usage billing solutions that use pre-existing infrastructures and/or CDR mediation and billing techniques. The billing system, e.g. billing system 123, or billing interface 127) processes CDR mediation’s mediated CDR feed, assigns the appropriate account billing codes and generates billing events. This does not require any changes to existing billing systems. For example, new transaction codes are used to label new device-assisted billing capabilities. Network provisioning system 160 may provide various network functions for authorization. For example, it can store, aggregate, mediation, feed 128, and other network elements/functions to provide micro-CDRs.

“As shown at FIG. “As shown in FIG. 1, a CDR storage and aggregation, mediation feed 118 are provided. Some embodiments of the CDR storage and aggregation, mediation feed 118 receive, store, aggregate, and mediate micro-CDRs from mobile devices 100. CDR storage, aggregate, mediation, feed118 may also provide a settlement platform that uses the mediated microCDRs in some embodiments. “In some embodiments, another network component provides the settlement platform using aggregated micro-CDRs and/or mediated micro CDRs (e.g. central billing interface 127 or another function/network element).

“In some embodiments, different techniques are used to partition the mobile devices 100 (e.g. allocating a subset 100 for a distributor or OEM and/or another entity). FIG. FIG. 1. A MVNO core network 210 comprises a MVNO storage, aggregation and mediation feed 118, a MVNO bill interface 122 and 123 (as well as other elements as shown in FIG. 1). 1).

“Those with ordinary skill in the arts will recognize that other network architectures are possible for providing device group partitions or a settlement platform. FIG. FIG. 1 illustrates one example of a network architecture that can provide settlement platform and device group partitions.

“In some embodiments CDR storage and aggregation mediation feed 118 (e.g. service usage 118) is a functional description for, in some embodiments a device/network-level service usage information collection and aggregation. 1 (e.g. central provider access network109 and/or core network 110), which are in communication with the service control 122 and central billing interface127. As illustrated in FIG. FIG. Some embodiments of the CDR storage and aggregation, mediation feed 118 function are located outside the network, partially in another location, or integrated with/as a part of other elements. CDR storage and aggregation, mediation feed 118 functionality may be located in some embodiments in the AAA server (121) or the mobile wireless center/Home Location Register 132 (as illustrated, in communication to a DNS/DHCP (126). Some embodiments of service usage 118 functionality are located or partially located within the base station, controller, and/or aggregator. These entities collectively are referred to in FIG. 125 as base station. 1. CDR storage, mediation, and aggregation are some of the possible locations for CDR storage in certain embodiments. These components can be found or partially located within a central provider access network (109), a core network 110 networking component, central billing system 123, central billing interface 127 or another component or function in the network. The discussion about the locations of the network-based and device-based service usage information collection and mediation, aggregation and mediation, and reporting function (e.g. CDR storage. aggregation. mediation. feed 118) can easily be generalized and shown in the figures and embodiments herein by an ordinary skilled in the art. As shown in FIG. 1 shows that the service controller 122 is in communication to the central billing interface (127, also known as the billing communication interface or external billing management interface), which is in communications with the central bill system 123. FIG. 1. An order management 180, and subscriber 182 are in communication with the central core network 110 to facilitate order and subscriber management of services 100 in accordance some embodiments.”

“Some embodiments provide a service process download 170, which allows for periodic downloads and updates of service processors (e.g. service processor 115). Some embodiments provide verification techniques that include updating, replacing, or updating an obscure version of the service process processor or any other techniques when there is a possibility of compromise or tampering with any service processor functionality (e.g. QoS functionality or network capacity controlled services functionality). These techniques can be used in response to any indication of a possible compromise or tampering with any service processor functionality executed on or implemented by the device 100.

“In some embodiments the CDR storage and aggregation mediation feed 118 (and/or any other network elements or combinations thereof) provides a device/network-level service usage information collection, aggregation mediation, and reporting function. CDR storage, aggregate, mediation, feed118 (and/or any other network elements or combinations thereof) collects device-generated/assisted usage information (e.g. micro-CDRs), and then provides that information in a syntax along with a communication protocol that the wireless network can use to augment or replace the network generated usage information. The syntax may be a charging data recording (CDR) and the communication protocol can be selected from any of the following: 3GPP3, 3GPP2, and other protocols. As described herein, some embodiments collect/receive micro-CDRs from one or more devices using the wireless network (e.g. devices 100) in the CDR storage and aggregation. Some embodiments include a CDR storage, aggregate, mediation, feed118 (e.g. or other network elements, and/or different combinations of network elements), and a service usage store (e.g. a billing aggregator) for aggregating device-generated service usage information. Some embodiments use a network device as a CDR feed aggregater. The CDR storage, aggregate, mediation feed 118 (and/or additional network elements or combinations thereof) aggregates (network-based) CDRs or micro-CDRs from the one or several devices on the wireless system. A set of rules is applied to the aggregated CDRs or micro-CDRs using an engine. This includes a bill by account, transactional, revenue sharing model and/or any other rules for collecting service/a CDR with a CDR that has a billing offset (e. A revenue sharing platform may be provided in some embodiments using the various techniques described herein. Various techniques are used to provide QoS usage accounting/charging, and/or network-capacity controlled services usage accounting/charging in some embodiments.

“In some embodiments the CDR storage and aggregation, mediation feed 118 (and/or any other network elements/combinations of network elements) communicates a brand new set of CDRs (e.g. aggregated and managed CDRs and/or micro CDRs that are then converted into standard CDRs for a wireless network) for one or more devices to a billing interface (e.g. central billing interface 127), or a billing software (e.g. central billing system 123). Some embodiments communicate the CDR storage and aggregation, mediation feed 118 (and/or any other network elements or combinations thereof) with a service controller (122) to collect device-generated service usage information (e.g. micro-CDRs for one or more devices connected to the wireless network. Some embodiments allow the CDR storage and aggregation, mediation feed 118 (and/or any other network elements or combinations thereof) to communicate with a service controller. In this case, the service controller is communicating with a billing interface, or a billing system. Some embodiments communicate the device-generated service usage information to a billing interface. Some embodiments communicate the CDR storage and aggregation, mediation feed 118 (and/or any other network elements or combinations thereof) with a transport gateway or a Radio Access Network gateway to collect network-based service usage information. The service controller 122 may communicate the device-assisted service usage information (e.g. micro-CDRs), to the CDR Storage, Aggregation, Mediation, Feed 118 (e.g. or other network elements and/or different combinations of network elements).

“In some embodiments the CDR storage and aggregation, mediation feed 118 (e.g. or other network elements and/or different combinations of network elements), performs rules for performing a bill-by-account aggregation function and a mediation function. In some embodiments, the CDR storage, aggregation, mediation, feed 118 (and/or other network elements or combinations of network elements) performs rules for performing a service billing function, as described herein, and/or for performing a service/transactional revenue sharing function, as described herein. The service controller 122, in communication with CDR storage, aggregate, mediation, feed118 (and/or any other network elements or combinations thereof) performs a rule engine for aggregating the service usage information (e.g. micro-CDRs) and mediating it. A rules engine device, in communication with the CDR Storage, Aggregation, Mediation, Fee 118 (e.g. or other network elements and/or varied combinations of network elements), performs a rule engine for aggregating, mediating the device-assisted service usage information (e.g. QOS service usage data and/or network capacity controlled service usage information).

“In some embodiments the rules engine is integrated (e.g., part of/integrated with/part the CDR storage and aggregation. Mediation, feed 118. The rules engine and its associated functions are sometimes a separate function or device in some embodiments. The service controller 122 may perform some or all of the rules engine-based functions described herein and communicates with central billing interface 127. The service controller 122 may perform some or all these rules engine-based functions as described herein and communicates with central billing system (123).

“In certain embodiments, a settlement service is provided. A micro-CDR can be used to aggregate and mediate service usage by a communications device (e.g., the user of the communication device). A rules engine, or another function, can determine the revenue share allocation for service usage to determine the settlement for such revenue sharing model and to distribute accounting information and settlement information to one of the carriers, distribution partners, wholesale partners, MVNOs, or other partners or entities. The service may be a transactional service in some instances.

“In some cases, duplicate CDRs may be sent from network equipment to billing system 123 which is used for service billing. Some embodiments filter duplicate CDRs to only send CDRs/records that are controlled by the service processor and/or controller (e.g. managed devices) This approach, for example, can offer the same level, lower level, and/or higher reporting than the central billing system 123.

“Some embodiments provide a bill-by account billing offset. By providing a CDR aggregate feed that aggregates device assisted service usage data feeds to create a new set CDRs for managed devices, the bill-by-account offset information can be provided to the central accounting system 123. Transaction billing can be provided in some cases using similar methods. Transaction billing log information, for example, can be sent to the central billing interface (127) and/or central billing system (123).

“In certain embodiments, the rules engine, e.g., performed using the service usage 118or another network element as described herein, provides a bill by account billing offset. Device assisted service usage information, such as micro-CDRs, may include a transaction type field (or transaction code) that indicates the type of service being used. The rules engine may apply a rule, or a group of rules, to the identified service that is associated with the device-generated service usage information in order to determine a bill by-account charging offset. For example, a new CDR could be generated to provide the bill-by account billing offset. The bill-by-account offset can be used to credit the user’s account.

Another example is that a transactional services CDR can be generated using a negative offset to account for user’s transactional usage. A second CDR can then be generated using a positive service value to charge the same usage to the transactional provider (e.g. Amazon, eBay, or any other transactional provider). The service controller 122 creates the two new CDRs and aggregates the service usage 118 stores. These two CDRs are then communicated to the central billing interface (127). The service controller 122 generates the two new CDRs and the service usage 118 store aggregates. These two CDRs are then communicated to the central billing interfacing 127. In which the central billing interface 127 applies the rules (e.g. the rules engine for determining bill-by-account offset).

“In some embodiments, service controller 122 transmits device-generated CDRs to the rule engine (e.g., service usage data store, rules engine such as mediation, storage, aggregation and feed 118), and then the rules engine applies one to more rules such as those described herein, and/or any other billing/service usage related regulations as would be obvious to one of ordinary skill. The service controller 122 may generate CDRs that are similar to other network elements. In some instances, the rules (e.g. bill-by-account), are executed in the central billing interface. In some embodiments, such as the service controller 122, which generates CDRs that are similar to other network elements in certain embodiments, the rules (e.g. bill-by-account) are performed in the central billing interface 127.

“In some embodiments, service controller 122 can be provisioned as a new type or function of networking that is recognized by other elements in the network as valid, authorized, secure sources for CDRs (e.g. CDR storage, aggregate, mediation, feed 128) If the network apparatus is unable to recognize CDRs from certain types or equipment, some embodiments may be used. If the necessary network apparatus only recognizes CDRs from certain types of networking equipment (e.g., a transport gateway or RAN gateway), the service controller 122 provides authentication credentials to other equipment that indicates that it is approved for providing CDRs. In certain embodiments, the link between service controller 122, the required CDR aggregation or mediation equipment is encrypted and/or signed.

“In some embodiments, CDR storage and aggregation, mediation feed 118 may discard network-based service usage information (e.g. network based CDRs), received from one or more network element. These embodiments provide the device-based service usage information to the CDR storage and aggregation.

“In some embodiments the device-based CDRs (e.g. micro-CDRs and/or new CDRs generated by execution of a rule engine as described herein) are only available for devices that have been managed and/or are based upon device group, service plans, or any other criteria.

“QoS for DAS may include a service processor, which is any device-assisted element/function that facilitates coordination and/or provision of wireless access/radio bearers (e.g. RABs). The service processor in some embodiments determines whether a request is for QoS. This can be based on QoS service level, user standing and available local network capacity (e.g. as reported by another device(s), network)). Some embodiments provide or augment network capacity demand reports by device QoS capacity.

Summary for “Flow tagging to support service policy implementation”

“With mass market digital communications, applications, and content distribution, many access network such as wireless networks and cable networks and Digital Subscriber Lines (DSL) are under pressure for user capacity with, for instance, Evolution-Data Optimized(EVDO), High Speed Packet Access/LTE, Long Term Evolution/LTE), Worldwide Interoperability For Microwave Access (WiMax), DOCSIS and DSL becoming constrained in their user capacity. In wireless, while network capacity will rise with higher capacity wireless radio access technology, such as Multiple-Input Multiple-Output, and more frequency spectrum and cell splitting being deployed in future, this capacity increase is likely to be smaller than what is needed to meet growing digital networking demands.

“Similarly, even though wireline access networks such as DSL and cable can offer higher average capacity per user than wireless, wireline user service consumption habits are moving toward high bandwidth applications that consume the available capacity quickly and can degrade overall network experience. This trend will negatively impact service provider profits as some service provider components are more expensive with increased bandwidth. It is also becoming more important to link device access network services usage (e.g. network data services usage and voice services usage). Application, widget, service or process, embedded object, and any combination thereof. Services that you are using.

The above example of trends or issues is meant to be an illustration and not a complete list. After reading the specification and studying the drawings, you will see other limitations to the art.

The invention may be implemented in many ways. It can be used as an apparatus, a process, a system, a composition, a product of computer programming, and/or a CPU, such as one that executes instructions stored on or provided by a memory connected to the processor. These implementations and any other form of the invention can be called techniques in this specification. The invention allows for the possibility of altering the order of steps in disclosed processes. A component, such as a processor and a memory, described as being capable of performing a task can be implemented either as a general component that is temporarily set up to perform the task at a particular time or as a specific component that was manufactured to do the task. The term “processor” is used herein. The term “processor” refers to any one or more devices, circuits and/or processing cores that are designed to process data such as computer program instruction.

Below is a detailed description of some embodiments of the invention, along with accompanying figures that illustrate its principles. Although the invention is described with these embodiments in mind, it is not limited to them. The claims limit the scope of the invention, and the invention includes many alternatives, modifications, and equivalents. The following description provides a detailed understanding of the invention. These details are given for example purposes only. The invention can be used according to the claims without any or all of these details. To be clear, the technical material related to the invention that is well-known has not been described in detail. This is done in order not to obscure the invention.

For example, wireless networks must manage the wireless access connections capacity and network connection resources to maintain network performance when network resources/capacity demand rises. If network resource management and capacity management are employed, many network performance measures can be beneficially maintained or improved when network load increases. These performance measures include network availability, ability to deliver connections for all users and/or devices; network access success rate; transmission speed experienced with one or more devices, applications, or users; network bit error rate and packet error rate; time delay from network request to delivery access connection; one-way delay or round trip delay for a transmission transmission; delay timing jitter transmission transmission; time variation in transmission speeds for one or more connections. The network’s ability to share or distribute performance measures (e.g. the performance measures mentioned above) uniformly

“For instance, if there’s a restricted amount of bandwidth available for a group of users (e.g., a network with a number of base stations or controllers or femto cells or pico cells; or a network using cable modem networks, etc.), then the network can become overloaded. If multiple or all devices permit all applications to access network resources, transmit/receive traffic or access them indiscriminately, the network may become overload. This can lead to poor network performance for a small number of users/devices, or even all users/devices. Another example is when multiple or all of the devices that make up a subset allow multiple applications to access the network resources and transmit/receive data. The network may become overwhelmed. This can lead to poor network performance for a subset or even all users/devices.

Mobile devices have been designed to maximize network capacity and prevent network resources being overtaxed. Wireless devices browsing the Internet use special protocols like WAP, data traffic compression, or low resolution techniques. This is in contrast to standard HTTP protocols and traffic that are used in wired Internet devices.

“However, wireless devices that use specialized methods to access the Internet or other networks often implement complicated specifications provided by one of the wireless carriers that owns the networks the device is intended to connect to. Complex specifications can be time-consuming to design, test, and certify. These processes have the effect of reducing the number of suppliers for devices to those who are qualified and willing to do the specialized work. This can slow down time to market, increase the cost of developing new devices, and reduce the support of certain applications.

“Device OEMs recently developed wireless devices that look more like standard Internet devices, but are not optimized to maximize network bandwidth and other resources. This type of device is desired by many wireless service customers. OEMs want to make it easier and faster to bring these devices to market. New market requirements and government regulations may require carriers to offer more flexibility in bringing new devices onto their networks. This means that the process doesn’t require the same specialized design or certification as previously. These factors and others are driving the demand for simpler and faster wireless device certification and design processes.

Many carriers are now selling devices that can connect to the Internet through standard Internet service devices. There is a growing demand for general-purpose Internet devices and apps to access wireless networks. This is because they don’t have to go through the certification and design process required to make them efficient and authorized to access such networks.

However, general-purpose Internet devices can be more expensive and sparing than wireless network access bandwidth. Popular Internet services and applications have found that they can access the Internet at very low cost and pay little attention to network traffic. More general-purpose Internet devices (e.g. mobile wireless networks) are being offered to us over wireless networks. This can lead to a higher frequency of inefficient wireless networking accesses, which can sometimes reduce network capacity to levels that limit access for that device (e.g. user, device and software demand) as well as other devices on the wireless network and/or that segment. Although judicious usage of wireless network bandwidth, capacity and resources can result in better service for users, the majority of device manufacturers and wireless network providers (e.g. wireless network carriers and carriers) do not have more sophisticated bandwidth usage techniques. This causes less control by the carrier of device design and poses a risk to network capacity and performance preservation in the long term as more devices are created with less optimized wireless designs.

There are many factors that impact network performance and user performance, such as overall network congestion, access network performance, communications protocols and/or operating systems functions, and/or performance of a user, device, app, network service source or communication protocol. A wireless network’s capacity can be limited, so network performance for a group of users, applications and network service providers, communication protocols, and/or users, or a single device, app, network source, communication protocol, or user, may decrease somewhat. However, as network resources/network capacity demand increases (e.g., more wireless network data traffic is demanded in aggregate; more devices are serviced by the network; more users are serviced by the network; more applications are serviced by the network; more network service sources are serviced by the network; more operating system functions are serviced by the network; and/or more differentiated QoS sessions are serviced by the network), network availability/performance can decrease and/or the network may not adequately service one or more users, devices, applications, network service sources, communication protocols, and/or operating system functions, or may not service one or more groups of users, devices, applications, network service sources, communication protocols, and/or operating system functions.”

There are many ways that increasing network capacity can cause network performance to decrease. These include an increase in latency, decreased bandwidth availability, increased latency for QoS reservations services, performance issues with some communication protocols, unacceptable user experiences, and other similar or similar effects on users and devices. Network communication protocols such as Internet protocol (IP), HTML protocol, voice communication protocols including VOIP protocol, streaming media protocols (e.g. audio/video, etc), gaming protocols and VPN protocols can all lead to reduced performance due to excessive network loading. It is important to protect and preserve network capacity.

“It is important to limit the amount of transactions that are requested from a network resource (e.g. edge network segment, base stations, controllers, MAC resources and pico cell, Femto Cell, etc.). In order to ensure that the network resource can handle transaction demand, it is important that they are not exceeded in terms of their ability to service transactions. Network resources such as base station resources or controllers, media access control resources, traffic transport resource, AAA resources and security or authentication resources are all examples of network resources that should be avoided. Traffic analysis, network security, bandwidth resources, bandwidth reservation, QoS reservation and coordination resources. QoS transport resource, service charging resource, traffic analysis, network security resources. Network performance can be affected by an incremental increase in network capacity/resource demand. This is because network resources become more taxed from limited transaction processing capabilities or limited bandwidth. If the equipment needed to establish a session of the PPP can only handle a limited number of sessions opening and closing per hour, or if the device’s behavior is such that many PPP sessions are opened and/or shut down, the PPP session transaction rate (e.g. openings/closings) may exceed the transaction capability of the session management resources. This is often called “flooding” Overloading is another term. Overloading is when a network resource has too many connections or too much demand. In these cases, the resource might fall behind in meeting transaction demand in a controlled manner. For example, the resource may continue to process transactions at or near the maximum rate allowed by the network resource. However, in other cases the resource may become overwhelmed and its processing speed may drop under overload. The PPP session establishment resource example shows that once the request rate exceeds the resource maximum transactions rate, unmet demand can increase to the point where one or more devices experience delays in connecting to the network and/or communicating (e.g. sending/receiving information).

“Another example is that if there are no traffic access reservation protocols, MAC protocol or bandwidth delivery protocols, then the network may experience more collisions. This can lead to a decrease in network efficiency and cause network performance to fall below acceptable levels. Unmanaged and/or uncontrolled QoS reservations requests and/or reservation grant can result in QoS services being under-utilized. Another example is when networks require a minimum resource allocation for transmissions and reservations or network resource transactions. If one or more devices or applications, network service source functions, operating system functions, and/or communications protocols have a high rate of network resource requests, network accesses, or data transmissions for small payloads (e.g. minimum MAC reservation factor, minimum security overhead factor, minimum QoS reservation factor, minimum response time for establishing a connection to a base station, minimum responses for establishing/clos/being released from a session), Even though the data packet containing the access event may be small, the network resources needed to complete it are often busy serving the access event for longer periods than is necessary for actual data transmission.

Another example of device service activity behavior which can impact network performance is how the device, subsystems, and/or modems power cycle or transition from one power saving state to the next. Establishing a basic connection between a device and a wireless basestation consumes resources. In some cases, it can also consume other network resources like AAA, HLR and HA. When a device disconnects from the base station’s connection, the modem subsystem, e.g., or a portion thereof, goes from active connection state into a power-save state, network resources are used every time the device enters and exits power-save state. This can happen for a time period of seconds to minutes, in extreme cases even minutes. When a device uses an aggressive power-saving algorithm, such as a device that goes into power save after a brief idle period, it can cause the network to be unable to support many devices. Another example is the creation of network sessions after the base station connection has been established. This is e.g., the establishment a PPP session with a home agent (HA), or another gateway. In this scenario network resources that are required to open/close the network session will be ignorantly consumed if the device exhibits aggressive power-save state cycling or terminates the data session frequently for other reasons.

Application that maintain persistent network communications that generate a high number of packets per second are another example of device activity that can affect network performance. This category includes applications that use persistent signaling. Examples include the frequent device signaling sequences that update widgets on a computer’s desktop, synchronize user data like calendars, contacts and email, check or update email feeds or RSS feeds, access social networking sites or tools, update real-time information, update voice and video chats, and update text and other relevant information. Other application behaviors that can tie up network resources and limit capacity include conference meeting services, video streaming and content update, software updates, and/or any other similar behavior. Even though the user isn’t using or benefiting directly from these types of applications, they can still run in the background and continue to use potentially large network resources.

“Service activities and/or device behavior can impact network capacity and/or resource availability. These include frequent OS and app background network accesses, signaling, software updates, frequent OS and device updates, cloud synchronization services. RSS feeds and/or any other background information feeds. Background email downloads. Subscription service updates and downloads. Text/voice/video chat clients and virus updates. Peer to peer networking apps. Inefficient network access sequences during frequent power cycle or power save state cycling. Large downloads or other high-bandwidth accesses. And/or greedy applications that constantly and/or often access the network with little transmissions or requests. One of ordinary skill in art will be able to see many other examples.

High device transmission bandwidth demand can degrade network capacity, performance and/or availability. However, other types of persistent and frequent traffic such as network resource requests, network accesses, or network interaction can also cause network capacity, performance and/or resource degradation, regardless of whether the aggregate bandwidth demand (measured by total data throughput) is high or low. This is why it is necessary to maintain network capacity.

“Smart phones and other similar devices are exacerbated by frequent queries to the wireless network while such devices move between cell sites. They can, for example push email, access social media tools and/or perform repetitive actions. Data traffic is increasing, but signaling traffic is growing by between 30 and 50 percent according to some estimates. Yahoo IM users may send a message, but wait a few seconds before sending another. The smart phone is often set to idle mode in order to conserve battery life. The device must set up a signaling pathway again after the user has sent another message. Even if the signaling resource has been released, the network does not usually react quickly enough to allow the next station to use resources for several seconds or even minutes. This causes the base station controller to spend a lot of resources processing the signaling. It cannot do other tasks such as allocating additional resources for data network use.

Smart phone vendors have a quick dormancy feature that allows mobile devices to make a quick query to the radio controller to let go of the connection and allow them to return to an idle state quicker. The device is communicating that it is going dormant to save resources (e.g. signaling channel), rather than network resources. The fast dormancy function can make this worse by asking for a network release prematurely and then following up with a request either to reconnect to the network, or to re-establish contact with the network.

“Network carriers have tried to manage network capacity using a variety of purely central/core network-based approaches. Some carriers, for example, have suggested that a robust capacity planning process is necessary and that sufficient investment is required to address the growing capacity crunch. There are limitations to a purely centralized network solution that does not include assistance from a service processor or device-based software agent. If a service user uses certain device apps, OS functions, or other services, there may be limitations to the network. For example, if a network connection is closed behind a base station, even though it isn’t allowed to transfer data, the network can still consume significant network bandwidth or capacity. If the service usage activity is too aggressive in attempting to establish a network connection to transfer data, but the network blocks it somewhere in the network, then a lot of network capacity can be used by many devices that exhibit such behavior, even though they are not allowed to use the service. Some embodiments of protecting network capacity include controlling network usage activities at the source. In some embodiments, service usage can be controlled so that re-try attempts to connect with the network are delayed, prevented, or reduced.

“In some cases, a drawback to purely central network solutions to protect network bandwidth is when service usage activities can be controlled, blocked, throttled and/or delayed in central network equipment without any mechanisms or support to link with a device user interface (UI), to inform the user about what is happening and why. This can result in a poor user experience and lower customer satisfaction. In some embodiments, a device-based UI provides real-time or near-real time information to the user about why a service usage activity has been blocked, throttled and/or controlled to protect network bandwidth. A UI may also be provided in some embodiments that informs the user of the available options to control, modify, override or change service usage controls for the purpose protecting network capacity. Some embodiments allow for user preferences to be used in conjunction with a change of service usage billing. These changes in service usage billing caused by capacity sparing service control modifications by the user are communicated via a UI notification sequence to the user. Some embodiments use user notifications to warn users when service usage activity that is not classified under differential user notification policies could cause the user’s service plan limits to be exceeded (e.g. total data byte count usage caps).

Intelligent network monitoring is required to monitor network traffic at various levels (e.g. packet/layer, stack application layer level/layer and/or application/layer) to ensure that network capacity is protected while maintaining acceptable user experiences. Network operators/carriers would have greater visibility into network usage and network traffic using Device Assisted Services (DAS), and sometimes network-based techniques. This would allow them to monitor network traffic and provide network service usage monitoring.

“Intelligent wireless network monitoring to efficiently manage network service usage can include providing Device Assisted Services, (DAS), for protecting network capacities in accordance with various embodiments. Intelligent network monitoring can be used to monitor network usage and protect network capacity. This includes differentially controlling software updates over the air and/or via wired connections only. Another example of intelligent network monitoring is differentially controlling different applications to protect network capacity. Intelligent network monitoring of wireless networks can be used to monitor network service usage and protect network capacity. This can include managing network access requests that result from power failures in the modem. These can lead to resource-intensive reconnection and/or authentication processes. Intelligent network monitoring of wireless networks can also be used to protect network capacity. This includes techniques to keep PPP sessions alive in order to prevent the need for network resources to reestablish them (unless an application behavior analysis predicts that the mean access time is too long for the PPP session not to be dropped)

“Unlike traditional QoS methods, which are used for establishing a single or end to end service level(s), techniques disclosed herein to protect network capacities facilitate the implementation of services on networks to facilitate differential control over certain services to protect network capability (e.g. to reduce network congestion and demand, network resources demand, and/or increase network availability). As also disclosed herein, techniques disclosed herein for protecting network capacity facilitate implementation of services on a network to facilitate differential control of certain services to protect network capacity can also facilitate QoS implementations by maintaining needed levels of network capacity/availability to facilitate delivery of certain QoS levels/classes. Techniques disclosed herein can be used to protect network capacity by aggregating across multiple services and/or devices in order to allow differential control of certain services to ensure network capacity. As another example, techniques disclosed herein for protecting network capacity can be used to provide for dynamic QoS classifications (e.g., dynamically assigning/classifying and reassigning/reclassifying (based on various criteria, events, and/or measures) network service usage activities to various QoS levels/classes, such as described herein) to facilitate differential control of certain services to protect network capacity.”

“Device Assisted Services (DAS), which protect network capacity, are provided. DAS is a method of protecting network capacity. In some instances, DAS can be used to control network activity usage by a device that connects wirelessly to the network. For example, controlling network service usage activities can include classifying and/or controlling network access requests (e.g., IP address requests), network access reservation requests (e.g., a QoS reservation/sequence), network capacity/resources usage (e.g., bandwidth usage), and/or any other network service usage activities. Some embodiments allow applications, OS functions and/or other network usage activities to request IP addresses from the network address server resources. These requests can be classified and/or managed so that IP address requests can be withheld, delayed or time windowed, reduced frequency, aggregated, or otherwise controlled. These policies are called “IP address request control policies”. For one or more applications, OS functions and/or other network usage activities are set up, updated, or modified before it is communicated over a network connection with a network element (e.g. a service controller, or another network element/function). Some embodiments allow network service usage activities to be generated/requested from applications, operating system functions (OS) and/or other software/functions that are executed on a device communicating with the network. It is possible to use a service usage policy to control network usage to protect network capacity (e.g. reduce network capacity demand). Some applications and/or Os functions are not able to defer traffic types based only on their fixed settings. These applications and/or functions cannot optimize network service usage activities based upon a current network bust state (e.g. changing network capacity or network performance). In some embodiments, the network busiest state, or alternatively, the network availability state, is a description of congestion (e.g. or conversely, available capacity) in the network for one or several device connections. The network busy state, for example, can indicate how congested a segment of the network (e.g. network edge element) is in relation to one or more devices. Another example is network availability state, which can indicate the network resources available to one or more devices. Network availability state and network busy state are two different ways to provide similar information. As described in various embodiments, they can be interchangeable.

“In some embodiments, techniques can be used to assign a priority to network service usage activities and control traffic associated with those usage activities based on that priority. Some embodiments provide techniques for the implementation of a differentiated, dynamic background service classification. This could be, for instance, as a function network availability state or network busy state.

“In some embodiments, the service usage control policy can be used to assist in network access control of network usage activities (e.g. deferring some of the network capacity demand from such source activities). Some embodiments allow for some or all of the network capacity to be satisfied at the point when the network resources or capacity is more available or less busier. Some embodiments provide techniques for classifying network activity associated with an application or OS function to a background class and differentially controlling background service class traffic. Some embodiments provide techniques for classifying network service activities associated to an application or OS functionality to a background class while other network activity associated with the application or OS functions are classified to other service types (e.g. or to different background class priority levels).

“In some embodiments, techniques can be used to determine a network busiest state (e.g. for a network edge connection to a device such as for a radio access number (RAN) for the device’s wireless network access and/or the base station/base controller in wireless communication with that device. Some embodiments provide techniques for controlling network traffic using a service usage policy. This is based on whether a particular activity, group of activities or service class is in the network busy state.

“In some instances, DAS to protect network capacity involves monitoring a communications device’s network service use activity in network communication; classifying that network service activity for differential network acces control for protecting the network capacity; associating that network service utilization activity with a network usage control policy based upon a classification of network service activity to facilitate differential network control to protect network capacity.”

In some embodiments, a network usage activity refers to any activity that involves wireless network communication. An application, an OS, and/or another device function can generate a network usage activity in some embodiments. An application, an OS, and/or another device function may generate one or more network service usage activity in some embodiments. A network service usage activity can include a voice connection (e.g. coded voice connection or voice-over IP (VOIP) connection), an application connection or widget connection to an operating system (OS), an email text connection to an email server, an email download connection to an email, and a file transfer connection to an internet connection.

“In some instances, network service usage activity can be classified, associated with, or assigned to a background classification (e.g., QoS or background service class). This is done to enable differential network service usage control in order to protect network capacity. Some embodiments of differential network usage control include the following: monitoring network usage activity, accounting for network usage activity, reporting network usage activity, generating a notification for a service usage event; accepting a preference for network usage activity control; implementing a network usage policy (e.g. block/allow; traffic control methods such as delay, priority queues, time window, throttle, kill, remove and other well-known traffic control techniques); implementing UI interception procedures; generating a notification about network activity; generating a notification; generating a notification; generating a notification; generating a notification; generating a notification; generating a service usage of a service; a notification to generate a service usage of a service activity for differential network usage control; generating a notification

“In some embodiments, a network availability state includes a state or measure of availability/capacity of a segment of a network (e.g., a last edge element of a wireless network). A network busy state, in some embodiments, refers to a state that measures the network usage or network congestion for a segment of a given network (e.g., last edge element of wireless network). In some cases, the network availability state and network busiest state are inverted measures. In certain embodiments, network availability and network busy states can be interchangeably used based on design choices. For example, designing to assign background policy based on network availability or network busy yields similar results but they are different ways of characterizing network performance, capacity, and/or congestion. In some embodiments, network availability state and network busy state are dynamic measures as such states change based on network usage activities (e.g., based on a time of day, availability/capacity level, congestion level, and/or performance level). Some embodiments allow differential network usage control to be based on network availability or network busy states.

In some embodiments, network service usage activities can be classified as background services. Some embodiments classify certain network service usage activities as background services. They are classified based upon a network busier state. These activities can be differentially controlled to protect network capacity. Some embodiments use differential network usage control policies that are based upon a time, a network busier state, background services, and/or QoS classification changes based a time, day, and/or network busy states. This allows for a deterministic schedule and back-off for certain network usage activities. It also provides a window in which network usage control policies can be applied to one or more service activities.

“In some embodiments, the network capacity controlled service/network capacity controlled services class includes one to more network services (e.g. background download services and/or other types/categories of services as described herein), selected for differential network usage control to protect network capacity. A network capacity controlled services class may include one or more network services that are associated with a network control service/class priority setting to limit network usage. A network capacity controlled service, or network capacity controlled classes class, may include one or more network services that are associated with a QoS classification for differential network usage control to protect network capacity. A network capacity controlled service, or network capacity controlled class in some embodiments includes one or more network service associated with a dynamic QoS classification for differential network service usage control to protect network capacity.

“For example, differentially managing network service usage activities using network capacity controlled services, dynamic QoS, or QoS classes can help protect network capacity. This includes improving network performance, increasing network accessibility, decreasing network resource demand, and/or reducing demand for network capacity (e.g., depending on an individual device or aggregate devices connected with an edge element and/or aggregate devices connecting to many edge elements). Some embodiments allow for differential control of network service usage activities using network capacity controlled services, dynamic QoS and QoS classifications. This can help protect network capacity and maintain proper device operation. In some embodiments, differentially controlling network service usage activities based on network capacity controlled services or dynamic QoS or QoS classifications can protect network capacity while maintaining an acceptable user experience (e.g., proper and/or expected device operation, proper and/or software/application/OS/function operation, avoiding (whenever possible) significant adverse impact on device functions, and/or user notifications to keep the user informed of various differential control implemented on the device).”

“In some embodiments dynamic QoS classes include QoS categories that can dynamically be modified (e.g. reclassified or reprioritized and/or upgraded and/or downgraded). These QoS classifications are based upon various criteria, settings and/or user inputs as described herein. The various techniques herein for DAS to provide network capacity and/or QoS to DAS can be applied to some embodiments.

“As wireless networks such as mobile networks evolve towards higher bandwidth services (e.g. conversational, interactive and streaming data and/or many (end-to end) real-time services that can benefit from QoS), there will be increased demand for converged networking services to facilitate such services between networks (e.g. to allow control and/or support such services across network boundaries such as between wireless network (such as different service provider networks), IP networks (such the Internet) and/or other networks. Although many efforts have been made to address these QoS issues, including policy management frameworks to facilitate QoS end to end solutions, it is clear that there is a need for Device Assisted Services to meet various QoS requirements.

“Accordingly Quality of Service (QoS), for Device Assisted Services, (DAS), is provided.” In certain embodiments, QoS is available for DAS.

Differentiated services are usually available to establish a QoS channel. This means that one class/level has a higher priority than the other in order to provide differentiated services on a network such as a wireless network. In a wireless network, for example, different network functions/elements can be configured and controlled to create a single end-to-end QoS channel. A centralized QoS policy coordination function and decision function using DAS techniques is available in some embodiments to coordinate the QoS channel setup control and coordination among various elements of a wireless networking.

In some embodiments, QoS channels refer to the logical communication channel that is connected to a device that offers a desired QoS service level. A QoS channel may be made with one or more QoS Links. Each link represents a QoS-enabled connection that spans a portion the entire end to end network communication path, from a near device to a distant device. The far end device may be connected to the same network as the near end device, or to a different network with different access technology, and/or different access network carriers. One or more QoS channels may include QoS links. In other words, some links are QoS-enabled and/or others are not. A QoS channel may include, for example, the following links.

“In some embodiments, each link described above has the ability to provide QoS service for the segment of an overall QoSchannel. Some embodiments enable QoS for the device traffic path link,/or the device access network equipment link, but not the carrier core network or IPX network links. Some embodiments have enough bandwidth over-provisioning to ensure that QoS can not be limited by these network elements. This could, for instance, limit the bandwidth available to the device traffic link or the device to access the network equipment link. These links are not desirable QoS enabled. One common example is a wireless network that has a 2G/3G/4G network. In this case, the QoS channel links for the core network and IPX networks are enabled.

“In some embodiments, QoS sessions refer to QoS-enabled traffic that flows over a QoS channel/QoS link. This QoS traffic supports QoS service activities. A QoS service activity may include a request, configuration, or service that is preferably provided with a certain level of QoS. Some embodiments define a QoS service activity as a service usage that is requested, configured, or preferably serviced with a given level of QoS. For example, QoS service activities that are supported by QoS sessions can include VOIP traffic, streaming video traffic, differentiated access bandwidth during busy network periods, real-time interactive traffic, such as network connected multimedia meetings (e.g., shared presentations, picture, video, voice, and/or other such applications/services), best effort interactive, such as Internet browsing, time sensitive services, such as email message body delivery, near real-time interactive services, such as SMS or push to talk, background download services, such as email downloads and other file transfers (e.g., FTP), and/or truly background download services, such as software updates (e.g., OS or application software updates and/or antimalware updates including content/signature updates).”

“In certain embodiments, different QoS levels and classes are supported. A conversation class, for example, can allow real-time traffic. This is a sensitive service that can tolerate packet loss and bit errors. The conversational classes are used for Voice Over IP (VOIP), and video telephony. Users of these services can benefit from the conversational classes’ short delay features. The streaming class is similar in function to the conversational, except that it can generally tolerate more delay than the conversational. A streaming class is used when the user on one end is a human user and the other is a machine/computer. This is for streaming content applications such as streaming videos or other video content. An interactive class is designed for traffic that can allow for delay variation and requires a low response time (e.g. web browsing or other applications where the channel may be used for long periods of times but the user requests a new page/data. The response time should be reasonable low). A background class is generally used for lowest priority service usages (e.g., typically used for e-mail with and without downloads/attachments, application software updates, OS software updates, and/or other similar applications/functions). In some cases, different QoS classes and services can be applied to the conversational Class. In some cases, different QoS classes and services can also be applicable to the streaming class. Some embodiments allow for various QoS services or classes to be applicable to interactive classes, but not to background classes. One of ordinary skill can see that other classes are possible depending on channel requirements, service usage, and/or network architectures.

“In some embodiments, QoS links or QoS channels support one QoS session. Some embodiments support multiple QoS sessions through a QoS connection or QoS channel. QoS link provisioning can be used to set the QoS traffic level of a QoS session, or group of QoSs.

In some embodiments, a QoS Channel can be either a single-ended QoS channel (or an end to end QoS channels). If a QoS channels is end-to-end, the QoS channel provisioning takes place in coordination for each QoS enabled link within the QoSchannel. A single-ended QoS channel means that the network elements and/or devices participate in provisioning the QoS channels for as many ends as possible. Provisioning the QoS channels for other ends of the QoS channels is left to the device and/or network element responsible for handling the traffic. One end of a QoS channel may include another QoS channel at its other end. One end may have a single-ended QoS channel while the other end is a best effort level. This is possible, for example, when one end is QoS capable on a 3G wireless network with limited bandwidth and the other end is QoS disabled on a cable modem network device that is lighter loaded, but which may not be required to enable QoS to ensure adequate voice quality.

“In some embodiments, QoS requests (e.g., QoS channel request, QoS services request) are requests for a QoS provisioning event that will enable a QoS channels for one or more QoS activity. In some embodiments, QoS availability assessment involves determining whether one or several links in a QoS channel are available (e.g. based on network quality and transmission quality) to provide the required level of QoS. A device, user, application and/or network element/function can initiate a QoS request in some embodiments.

“In some embodiments, the service plan is the collection of access services capabilities, QoS capabilities and/or network capacities controlled services that are associated to a communications device. The access control policies that are set for the device can determine the access service capabilities, QoS abilities, and/or network capacities controlled services. These service control policies may be implemented in the network equipment in some embodiments. These access control policies can be implemented in both the network equipment and the device in some embodiments. These access control policies may be implemented directly in the device. There may be different levels in service control capabilities depending on the level of service plan payments, device standing, or user standing. Some embodiments allow for different levels of service control policies depending on network type, time, network busy status and/or other criteria/measures. Some embodiments determine the type of service activity to be controlled and the access control and QoS policies based on it. The policies associated with the service plans can determine the QoS and access levels available for a particular service activity for a device or user. A QoS authorization assessment may be performed in some embodiments to determine if a device or user is able to access the required level of QoS.

“In some embodiments, QoS availability assessments are performed before a QoS link or channel is provisioned. This is done to assess the availability of communication channels to provide the required level of QoS to the channel or link. This QoS availability assessment can be done in a number of ways. The available QoS link capacity for a number of devices can be evaluated, including a device traffic path and a device-to-access network equipment link. A core network link and/or an IPX link. QoS service requests can be granted if the QoS assessment reveals that there is sufficient channel capacity and quality to provide the required QoS level for the requested QoS activities. A QoS link, or QoS channels reservation process, may be provided in some embodiments to reserve QoS quality and capacity prior to link or channel provisioning. This is to ensure that QoS resources are not allocated between QoS availability assessment or QoS channel provisioning.

“In certain embodiments, QoS availability assessment may be performed after QoS authorization assessment. This prevents unnecessary exercise of network elements if the user or device does not have enough service plan to receive the desired QoS level. This can be an important screening function performed on the device in the service processor, or by a centralized network function such as the service controller (e.g., or interchangeably, the home agent; Home Location Register (HLR); Authentication, Authorization, and Accounting (AAA) server/gateway/function; base station; one of the gateways, policy and charging rules function (PCRF), or other network element/function). In some cases, QoS availability can be assessed before a QoS authorization assessment is conducted or after receiving the response.

“In some embodiments, the QoS channel is provisioned in order to create the QoS channels to support a session (e.g., QoS service activities). QoS channel provision may include routing and/or assigning QoS session traffic over QoS links within the QoS channel.

“In some instances, device-assisted service traffic control and QoS can be applied directly and readily to the problems associated with managing a QoS link for QoS channel provisionsing. In some embodiments, a service provider can be provided to help with the provisioning of the device section of the QoS channel. Some embodiments provide the service processor with the ability to provision the device link portion. This is done by giving higher priority to higher QoS traffic. This QoS priority can be implemented in various ways. For example, routing higher priority QoS traffic to first priority in downstream and/or upperstream traffic queues. In some embodiments, upstream traffic queuing can be done directly by sending guaranteed bit rate traffic first with higher available throttling speeds, differentiated QoS trafic second with a controlled throttled rate, best effort traffic third with lower controlled throttled rates and/or background traffic forth when/if bandwidth is not required by the higher QoS traffic levels and lower controlled throttling rates. To handle downstream traffic, one can queue traffic and delay or prevent TCP acknowledgments from being returned for lower QoS priorities, while simultaneously passing traffic and TCP acknowledgments for higher QoS priorities. In order to provision the device link portion, the QoS channel, policies are used to determine the TCP acknowledgement return rate, queuing priority and delay for device traffic. This is based on the available bandwidth at the time. In some embodiments, different device service processor traffic control abilities regulate or partially regulate QoS according to a set network policy instructions. Some embodiments include a service plan policy set.

“In some instances, the device service processor creates multiple QoS channels via the device traffic path. Each QoS channel has traffic control policies as discussed herein. With each QoS channel policy creating a different type of QoS. This multiple QoS channel approach can provide QoS for certain service activities by routing traffic to the QoS channel that has the correct QoS policy settings. There are many ways to route traffic to the QoS channel. The routing can be done by applying a common traffic control policy to all traffic related to QoS service activities that request or require the QoS. You can apply the service traffic control policy in many ways using the embodiments for the policy implementation and policy control agents described herein. This reduces the problem of assigning a QoS channels to multiple QoS services activities by applying a predetermined set service traffic control policy to each QoS activity. Each service traffic control policy represents a different QoS category. The device will manage the overall QoS of all traffic based upon the available traffic capacity, quality, total aggregate traffic demand for each QoS class, and the policy rules that determine how each class is provided with differential bits rate and traffic quality compared to other traffic classes for the same level of traffic capacity.

The service processor can adjust the available bit rate or percentage of traffic capacity based on aggregate demand for each traffic class. In some embodiments, the aggregate traffic demand class for real-time interactive traffic control (e.g. In some embodiments, the aggregate demand for the real-time interactive traffic control class (e.g. The QoS channel capacity is allocated more capacity out of available capacity as the QoS services become more demanding. When the QoS activities are less frequent, this QoS channel capacity is released. If the device doesn’t have enough capacity at a guaranteed QoS rate, additional QoS service activity that require, request or desire this QoS will be denied access. Instead, the QoS will be reduced or the user will be forbidden from connecting to the network. Some embodiments allow for a hierarchy of QoS service activity types. If there is not enough capacity at a particular service QoS level then the QoS classes available are given to service activities with the highest priority. After that, one or more QoS activities that are too low in the priority list to receive service with that QoS type are either denied access or bumped to a lower class. Some embodiments allow for the allocation of remaining QoS channel class capacity among other QoS channels classes according to a priority policy. This policy is based on the relative priorities of each service class, each QoS activity’s relative priority, or a combination of both the relative priorities of each QoS class and each QoS activity. These relative priority policies may vary from one device to another depending on the service plan selected, device type, user status, user group, device connection, type and time of day, network business state, and/or any other criteria/measures.

“In some embodiments, the QoS link between the device (and an access network equipment element) is established. These equipment elements can include, for example, a 2G/3G/4G/4G wireless basestation, a wireless access station, a wireless head end, a DSL network DSLAM and a fiber network traffic aggregator. A frame relay aggregation, ATM aggregation, and/or any other network equipment. Some embodiments create a logical communication link between the device and network equipment element. The logical communication link supports a particular level of QoS/QoS class traffic policy. The logical channel may include a RAB between a base station (2G/3G/4G) and a wireless device endpoint. You can create the RAB by controlling the media access control parameters (MAC) of the base station radio channel to ensure that QoS class policies are implemented. The RAB can be configured to support constant bit rate, low latency communication traffic. This is for guaranteed bitrate real-time traffic. It can also be used for streaming traffic. This QoS channel link can be used to support a single device or shared with a subset or all of them. This QoS channel link can be used by the device for support of a single QoS activity, or group of QoS actions as described in this article. One of ordinary skill can now see that similar settings for cable modem MAC and cable head end can produce similar QoS levels for QoS connections for the cable modem case. Similar techniques can also be used for a wireless access points or satellite system MAC to achieve comparable QoS classes. One of ordinary skill can now see that similar QoS classes QoS links can also be established by using multiple logical channels within the device link and/or changing the access network capacity and quality for each channel. This is possible for both DSL and fiber distribution networks cases.

“In some embodiments, the device service processor routes QoS service activities along a logical communication channel that is established for the QoS class desired by an access network element and the device. Some embodiments allow the use of the device service processor elements, such as the policy implementation agent or the policy control agent, to assign the same QoS control policies to multiple QoS activity activities that have the same QoS level. Similar to above, some embodiments allow the device service processor elements to be used to route service activity traffic of a particular QoS level to the correct logical communication link between the device (e.g., 2G/3G/4G access station) that supports the traffic management policies for the requested QoS. A QoS service connection that supports guaranteed bit rates and latency can be established using one or several RABs from the base station to the device. A second QoS link can also be established that supports preferred streaming content access via one or more RABs. Finally, a third best-effort RAB can be used for best effort traffic. Each required RAB is requested first and then provisioned according to the requirements for the QoS service classes associated with the RAB policy parameters. Once the logical QoS channels are established, the service processor, e.g., QoS router function, routes traffic associated with each QoS activity to the relevant RAB. Some embodiments allow the service processor to detect changes in aggregate QoS classes demand as QoS activities are initiated and terminated. The service processor can then communicate any required increases or decreases of RAB assignments necessary to support that logical channel.

“In some cases, the access QoS connection is established via direct communication between the device and the access network element. In these cases, the device requests the channel or link from the access device or an intermediate networking device such as a service controller. The device service processor may base the QoS channel request or link request on the association that the device makes to match a QoS activity or QoS traffic control policies set. This can be done by using a pre-defined policy mapping, which is stored on the device. This policy mapping store can be populated by a service controller and/or updated in some embodiments. A service controller may determine the mapping based on the report from the device of the QoS activity that requires the QoS channel/link.

“In certain embodiments, the required QoS level for one of more QoS activity activities can be determined by a set QoS traffic control policies that have been pre-assigned to different QoS activities. A QoS class can be assigned to an application, for example. A QoS class can also be assigned to a web service destination, such as a VOIP site. Another example is that an application may have one QoS level for Internet traffic and another for real-time gaming traffic. Another example is that a broadcasting website may have a best effort level of QoS for general browsing and programming information, and a streaming QoS degree for broadcast traffic content. Some embodiments allow for the assignment of QoS to an activity by a device processor in accordance with a pre-defined QoS rule rules table. This can also be done by a service controller using information from the device.

“In embodiments where both ends of the QoS channel take part in the establishment of an end-to-end QoS channel the required QoS level can be determined and/or communicated to the receiving end point. The receiving end point may determine and/or communicate the QoS level in some embodiments. The receiving end point service controller may determine and/or communicate the required QoS level. This could be the access network element (such a base station), HLR, home agent or mobile switching center, AAA or gateway, or any other function or element of the network. The receiving end point controller may determine and/or communicate the QoS level (e.g., alternatively, the access network element (such a base station), HLR, home agent mobile switching center AAA, gateway or any other network element/function). In some embodiments, the receiving or access point service controller, such as the base station, HLR, home agent or mobile switching center, AAA or gateway, and the originating end-point service controller (e.g. or another similar function) communicate to one another in order to coordinate the establishment of the QoS channel among the end points.

“In some cases, the near end (or originating end device) service processor contacts far end (or terminating device) service processor to initiate a quality of service channel. The far end device initiates the QoS channel automatically if it detects that the service processor of the near end or origin device requires a certain level of QoS for communication between the devices. Some embodiments require that the near end, originating device service processor, detects that a QoS channel is required for communication between the two devices and contact a central network resource, such as the service provider (e.g. or another equipment element with similar function). The service controller then provisions the far side of the QoS channels by either communicating directly with the far device or communicating with its service controller (e.g. or another equipment element with similar function). Some embodiments allow the far-end device service controller to be contacted to help with provisioning the QoS channels. This is done using a lookup function that uses some aspect of far end device credentials (e.g. phone number, SIM ID and MEID, IMSI or IP address), and then the service controller provisions the far end of the QoS channel.

“In some embodiments, mapping QoS service activity at the desired QoS level or QoS traffic control policy is done by providing a QoS API within the device service processor. This API allows applications to request a QoS channel connection or class. An API is available to allow application developers to create software that uses standard interface commands for setting up QoS channels. The API may perform one or more of these functions: receives QoS channels from applications, formats them into a protocol that can be transmitted to network equipment (e.g. the device control system), coordinates to reserve QoS channels, coordinates to other network elements to provide a QoS channel to the application and/or coordinates to other network elements, such as the device control system, to connect it to the QoS class desired. The QoS API may accept an application QoS request, coordinate with one or more QoS equipment elements (e.g., base station, cablehead end, or access point) and possibly communicate and coordinate with them. The QoS API may accept the QoS request form the application, and communicate with and coordinate with an intermediate network element such as a service processor or another similar function, in some instances. The QoS API may assess the QoS plan standing of the device or user, before initiating the QoS request sequence. This simplifies the complex task of setting up a QoS channels with all of the equipment communication protocols required to establish QoS channels. It also makes it easy for the application development community to use the API commands to create QoS differentiated applications and services.

“In some cases, traffic control on both the device service processor and the link between it and the access network element is combined. This allows both the device to access network element QoS and device traffic control path QoS links to be combined for optimal QoS performance. The link between the device and access network elements can be coordinated, based on the available capacity and quality for the device’s access network traffic. Predefined policies loaded onto the device from the service controller or equivalent network element determine how the device handles local traffic control and establishes access network elements logical channels (e.g. RABs). They also determine how traffic is routed to and from these logical channels. These policies may be set by the service controller in some instances.

“In some embodiments, the QoS user interface (e.g. QoSUI) is presented to a device user. The QoS UI may inform the user based on their service plan selection which level of QoS services they are authorized to receive. The QoS UI may inform the user about the available QoS services on the network to which the device is currently connected. The QoS UI may notify the user if a higher level of QoS services is necessary or desired for a service activity the device has initiated. The QoS UI may offer a variety of upgrade options that allow the user to upgrade their service plan to include a higher QoS level for one or more service activities. The QoS UI allows the user to select the level of QoS they would like to use for one or more services. The QoS UI can be used to create a service plan that offers differentiated QoS in busy times. The QoS UI may allow the user to buy one or more grades service QoS. This can be done with a post-pay that covers a predetermined service period and one, two, or three pre-determined service usage limits. The QoS UI allows the user to enable QoS or to pay for QoS services that are initiated by an incoming connection.

“QoS for DAS technologies may include verifying that the device implements the QoS traffic control policy, such as in accordance to a service plan. This prevents hacking, manipulations of user device software settings, and other malware events from causing an inappropriate level of QoS on a particular device or group of devices. In some embodiments, traffic control and QoS verification techniques are used to ensure that QoS is being applied in accordance with QoS priority policies for certain service usage activities. Verification of QoS channel request policies behavior can be done in many ways. For example, it is possible to monitor QoS channel requests from devices and compare the QoS received with the QoS plan that the device is allowed to receive. You can verify that a QoS channel is being used properly by a device in many ways. For example, you could monitor network reports about QoS service usage, and compare the network reports with the service policy rules for the device’s service plan. You can verify that traffic control policies are properly being implemented by devices to ensure that they are performing as intended. DAS techniques for protecting network capacity may include various verification techniques, such as verifying monitoring, traffic control, reporting and/or any other functions performed or executed by the device.

“In certain embodiments, the QoS router prioritizes traffic to the device. The QoS router may connect the QoS-enabled session to the RAB with the appropriate QoS level. One session can be routed to the RAB in some embodiments. One session can be routed directly to the RAB in some embodiments. In some embodiments multiple RABs with multiple QoS levels can be created to the device. The QoS router routes every service activity to the RAB determined by the QoS policy rules.

“In some instances, the network may collect service usage fees for different QoS classes. Some embodiments allow for differentiated service charging to be applied to different types of QoS service usage. Because guaranteed bit rate traffic uses network resources regardless of whether it is being used, there may be a time factor in charging calculations. For example, guaranteed bit rates services can be charged based on the bandwidth provided to the device at any given time multiplied with the time bandwidth was made available. Differentiated access traffic with a higher QoS than the best effort traffic, but not guaranteed bit rate, can be charged at a higher than best effort traffic, but lower than guaranteed bits rate. These traffic may be charged according to the time that the QoS channel becomes available or the total data transmitted over it. In some embodiments, best effort traffic is charged based on the total data used. The data charges are less than those for differentiated streaming access services. In some embodiments, background data services are charged at the lowest rates. This could be because they are not available during peak hours or when there is less demand for them. The service is also based on the total data transmitted. All QoS service levels may be charged at a fixed price and for a fixed period. There may also be a usage cap that can be added to add additional fees. For higher QoS levels, the price is higher in such fixed-price scenarios. Some embodiments collect service usage fees from the network for different classes of network capacity controlled service. Some embodiments allow for differentiated service charging to be applied to different types of network capacity controlled service usage.

“In some embodiments the network equipment (e.g. access network element, gateways and AAA, service usage storage system, home agent, HLR and/or billing system) records and reports service usage for one or several QoS service classes. The device service processor may record and report service usage for one or several QoS services classes and send the QoS class usage to the controller (e.g. or another substitute network element). If the device records usage data for one or more QoS services classes, it is necessary to verify that reports of device usage are accurate. As described in this article, some embodiments require that service usage reports are verified against the actual service usage. This can be done using the following techniques: service processor agent functional operation verification, agent query responses sequences, service control policies on the device, device service processing software protection techniques, software environment checks for device service processor software, and many other techniques. One or more of the verification techniques can be used to verify a device-assisted QoS service usage billing system. Another example is that one or more of the verification techniques can be used to provide a verifiable network-capacity controlled service usage charging system. Some embodiments of network equipment, such as access network elements, gateways, AAA service usage storage system, home agent, HLR mobile data center and/or billing systems, record and report service usage for one, or more, network capacity controlled service classes that are used by the device.

Device assisted traffic control may be used to manage network congestion in certain embodiments. Device assisted traffic control is provided for managing network congestion in certain embodiments. For example, if a base station or group has traffic demand that exceeds the available capacity or quality, then a service controller (e.g. or another network function), can issue, send and/or implement traffic control policies to/for devices according to the amount of excess traffic demand the base station is experiencing. The device service processors that are connected to a busy base station can be instructed, for example, to lower the traffic control priority for one or two classes of QoS traffic. This will reduce the queueing priority, throttling speed, delay, and/or access allowance for any or all of the classes. Another example is that the device service processors attached to a busy base station can be instructed reduce the traffic priority for one or several classes of network capacity controlled traffic traffic. This will decrease the queuing priorit, throttling, delay, and/or access allowance for any or all of these classes. Another example is background downloads, which may include software updates, can be disabled completely or throttled back substantially. Another example is that best effort traffic, such as Internet browsing, can be throttled or decreased for devices that are connected to base stations with high traffic demand. Another example is that a policy may be applied to devices connected to busy bases stations. This policy allows the device to browse the Internet or perform other best effort services at a high throttling speed for a time period. However, if the device consumes more service (e.g. total data downloaded/uploaded) within a time period, then the device can be traffic controlled using an adaptive throttle policy, as described below. Higher QoS traffic can’t be throttled under certain circumstances. This is the case for VOIP traffic, which requires a real-time guaranteed bitrate to meet user expectations. Lower priority traffic, such as background download and interactive browsing, may not be throttled. Some embodiments adjust the QoS availability assessment process described herein so that higher QoS channels cannot be provided or provisioned at times or locations when a base station or group has excess demand or demand exceeding a threshold.

“In certain embodiments, devices or users with service plans that offer higher quality of service or higher priority during busy network times have different traffic control policies applied to them (e.g. for QoS services or network capacity controlled services). This results in higher traffic performance and/or higher availability of QoS services. Emergency service workers may be granted access policies with higher traffic control that allow them to provide differentiated services during peak times. Some embodiments allow users to obtain premium service plans for differentiated access during peak busier times. They may also use higher QoS settings and/or service packages to ensure differentiated service during peak peak hours. Services that require high QoS levels, such as instant messaging, push, differentiated streaming and/or interactive games, are not traffic controlled in the same way that lower priority services are or are traffic controlled during peak times. This type of service differentiation could also be applied based upon device type, user group and user standing, points earned from user reward zones, and/or any other criteria/measures, as described in the above.

“In some embodiments, the device service processor makes the decision to reduce, increase, or otherwise control access traffic control settings according to the device’s assessment and network capacity. This can be done using various methods as described herein. A service controller, which is an interchangeable network element or elements described herein, connects to the device and provides instructions to the device for adjusting the access policy settings. In some embodiments, this decision to control access traffic control settings as described above, is made by the device service processor. The service controller, for example, can access information about network capacity from access equipment elements or device reports of traffic quality and/or traffic capacity as described herein. It also has the ability to obtain reports on traffic capacity/quality from dedicated devices that are used for the purpose assessing network capacities. Some embodiments allow the control of access traffic control settings to be determined based on time of day or week to account for cyclical patterns in traffic demand and network capacity.

“In some embodiments, the service controller (e.g. or another network element or elements) evaluates the network busy state and controls device traffic demand by reducing one or more service classes (e.g. for QoS services or network capacity controlled services) supported through the access network elements such as a wireless basis station. The service controller (or similar function) collects network capacity information using one of these techniques and then instructs one or several access network elements to lower the capacity offered for one or multiple levels of QoS classes or network capacity controlled services classes to one or both of the devices connected with the access network elements. The determination of which devices to throttle back may be based, for example, on equal throttling of all devices in a service plan status or on device traffic patterns in the past, as described herein.

“In certain embodiments, the device can be enabled with ambient services that offer differentiated QoS and/or network capacity-controlled services. Ambient QoS can be provided by using pre-assigned QoS policy for a service activity within the ambient service or an ambient service application that requests QoS via the QoS API. One of ordinary skill in this art will be able to see other ways of providing QoS differentiated services activities within the ambient service offerings. Another example is ambient network capacity controlled service techniques that can be offered using pre-assigned network capacities controlled policies for a particular service activity set within an ambient service, monitoring, dynamically assigned techniques and/or an ambient service application using API or emulated API technologies and/or other techniques described herein.

“In some cases, the QoS service control policies are adapted to the network that the device is connected. QoS traffic control policies, and/or QoS charging policies, can differ depending on whether the device is connected wirelessly (e.g. a 3G/4G network with less QoS enabled traffic capacity) or wiredly (e.g. a cable network with more QoS available). The service controller and the device processor can work together to adjust the QoS control policies and/or QoS charging policies depending on the network to which the device is connected. The device QoS control policy and/or the QoS charging policy can be modified based on whether it is connected to a home or roaming wireless network. As described above, some embodiments adapt a network-capacity controlled service control policy or a network-capacity controlled charging policy based on the type of network the device connects to.

“In some embodiments, QoS-related techniques and/or network capacities controlled services techniques described in this document are performed on the device by DAS techniques and/or the service controller in secure communications with a verified processor executed on the device via DAS techniques. In some embodiments, various of the QoS related techniques and/or network capacity controlled services techniques described herein are performed by/in coordination/communication with one or more intermediate network elements/functions for assisting in various techniques (e.g., functions) for QoS techniques and/or network capacity controlled services techniques as described herein.”

“FIG. “FIG. The network architecture in FIG. illustrates how QoS is implemented for DAS techniques. 1. Some embodiments of DAS to protect network capacity techniques described herein can be implemented using the network architecture illustrated in FIG. 1.”

“As shown, FIG. FIG. 1 shows a 4G/3G/2G wireless networks operated by, for instance, a central provider. As can be seen, different wireless devices 100 communicate with base stations (125) for wireless network communication with wireless network (e.g. via firewall 124), while other devices 100 communicate with Wi-Fi Access points (APs), Mesh 702 to wireless communication to Wi Fi Access CPE 704 and the central provider access network (109). One or more of the 100 devices may be in communication with another network element/equipment, such as a DSL network DSLAM (distributed over a wireless network), a fiber network aggregater node and/or satellite network aggregation. Each of the 100 wireless devices includes a service processor (as shown), which is executed on the processor of the wireless device 100. Each service processor connects via a secure control plane link with a service controller (e.g. using encrypted communications).

“In some embodiments service usage information can include network based information (e.g. network based charging data records (CDRs) or network based services usage measures (not shown), which can be generated by service utilization measurement apparatus in network equipment). This information is obtained from one or several network elements (e.g. BTS/BSCs 125 and RAN Gateways (not showed), Transport Gateways(not shown), Mobile Wireless Center/HLRs 132 and AAA 121, Service Use History/CDR Aggregation Mediation, Feed 118 or another network equipment). Some embodiments include micro-CDRs in service usage information. Some embodiments use micro-CDRs for reconciliation or CDR mediation that allows for service usage accounting for any device activity. Each device activity that is associated with a billing event in some embodiments is assigned a microCDR transaction number and the service processor (115) is programmed for accounting for that transaction code. The service processor 115 reports micro-CDR usage information periodically to the service controller 122, or another network element, in some embodiments. The service controller 122 may reformat the heartbeat microCDR usage information into a valid CDR file (e.g. a CDR file that can be processed or generated by an SGSN/GGSN or any other network elements/equipment authorized for generating/processing CDRs). This is then transmitted to a function for CDR mediation (e.g. CDR Storage Aggregation Mediation, Feed 118).

CDR mediation can be used in some cases to account for micro-CDR service use information. This is done by depositing the information into a suitable service usage account and subtracting it from the bulk user device service usage account. This technique, for example, allows for flexible service usage billing solutions that use pre-existing infrastructures and/or CDR mediation and billing techniques. The billing system, e.g. billing system 123, or billing interface 127) processes CDR mediation’s mediated CDR feed, assigns the appropriate account billing codes and generates billing events. This does not require any changes to existing billing systems. For example, new transaction codes are used to label new device-assisted billing capabilities. Network provisioning system 160 may provide various network functions for authorization. For example, it can store, aggregate, mediation, feed 128, and other network elements/functions to provide micro-CDRs.

“As shown at FIG. “As shown in FIG. 1, a CDR storage and aggregation, mediation feed 118 are provided. Some embodiments of the CDR storage and aggregation, mediation feed 118 receive, store, aggregate, and mediate micro-CDRs from mobile devices 100. CDR storage, aggregate, mediation, feed118 may also provide a settlement platform that uses the mediated microCDRs in some embodiments. “In some embodiments, another network component provides the settlement platform using aggregated micro-CDRs and/or mediated micro CDRs (e.g. central billing interface 127 or another function/network element).

“In some embodiments, different techniques are used to partition the mobile devices 100 (e.g. allocating a subset 100 for a distributor or OEM and/or another entity). FIG. FIG. 1. A MVNO core network 210 comprises a MVNO storage, aggregation and mediation feed 118, a MVNO bill interface 122 and 123 (as well as other elements as shown in FIG. 1). 1).

“Those with ordinary skill in the arts will recognize that other network architectures are possible for providing device group partitions or a settlement platform. FIG. FIG. 1 illustrates one example of a network architecture that can provide settlement platform and device group partitions.

“In some embodiments CDR storage and aggregation mediation feed 118 (e.g. service usage 118) is a functional description for, in some embodiments a device/network-level service usage information collection and aggregation. 1 (e.g. central provider access network109 and/or core network 110), which are in communication with the service control 122 and central billing interface127. As illustrated in FIG. FIG. Some embodiments of the CDR storage and aggregation, mediation feed 118 function are located outside the network, partially in another location, or integrated with/as a part of other elements. CDR storage and aggregation, mediation feed 118 functionality may be located in some embodiments in the AAA server (121) or the mobile wireless center/Home Location Register 132 (as illustrated, in communication to a DNS/DHCP (126). Some embodiments of service usage 118 functionality are located or partially located within the base station, controller, and/or aggregator. These entities collectively are referred to in FIG. 125 as base station. 1. CDR storage, mediation, and aggregation are some of the possible locations for CDR storage in certain embodiments. These components can be found or partially located within a central provider access network (109), a core network 110 networking component, central billing system 123, central billing interface 127 or another component or function in the network. The discussion about the locations of the network-based and device-based service usage information collection and mediation, aggregation and mediation, and reporting function (e.g. CDR storage. aggregation. mediation. feed 118) can easily be generalized and shown in the figures and embodiments herein by an ordinary skilled in the art. As shown in FIG. 1 shows that the service controller 122 is in communication to the central billing interface (127, also known as the billing communication interface or external billing management interface), which is in communications with the central bill system 123. FIG. 1. An order management 180, and subscriber 182 are in communication with the central core network 110 to facilitate order and subscriber management of services 100 in accordance some embodiments.”

“Some embodiments provide a service process download 170, which allows for periodic downloads and updates of service processors (e.g. service processor 115). Some embodiments provide verification techniques that include updating, replacing, or updating an obscure version of the service process processor or any other techniques when there is a possibility of compromise or tampering with any service processor functionality (e.g. QoS functionality or network capacity controlled services functionality). These techniques can be used in response to any indication of a possible compromise or tampering with any service processor functionality executed on or implemented by the device 100.

“In some embodiments the CDR storage and aggregation mediation feed 118 (and/or any other network elements or combinations thereof) provides a device/network-level service usage information collection, aggregation mediation, and reporting function. CDR storage, aggregate, mediation, feed118 (and/or any other network elements or combinations thereof) collects device-generated/assisted usage information (e.g. micro-CDRs), and then provides that information in a syntax along with a communication protocol that the wireless network can use to augment or replace the network generated usage information. The syntax may be a charging data recording (CDR) and the communication protocol can be selected from any of the following: 3GPP3, 3GPP2, and other protocols. As described herein, some embodiments collect/receive micro-CDRs from one or more devices using the wireless network (e.g. devices 100) in the CDR storage and aggregation. Some embodiments include a CDR storage, aggregate, mediation, feed118 (e.g. or other network elements, and/or different combinations of network elements), and a service usage store (e.g. a billing aggregator) for aggregating device-generated service usage information. Some embodiments use a network device as a CDR feed aggregater. The CDR storage, aggregate, mediation feed 118 (and/or additional network elements or combinations thereof) aggregates (network-based) CDRs or micro-CDRs from the one or several devices on the wireless system. A set of rules is applied to the aggregated CDRs or micro-CDRs using an engine. This includes a bill by account, transactional, revenue sharing model and/or any other rules for collecting service/a CDR with a CDR that has a billing offset (e. A revenue sharing platform may be provided in some embodiments using the various techniques described herein. Various techniques are used to provide QoS usage accounting/charging, and/or network-capacity controlled services usage accounting/charging in some embodiments.

“In some embodiments the CDR storage and aggregation, mediation feed 118 (and/or any other network elements/combinations of network elements) communicates a brand new set of CDRs (e.g. aggregated and managed CDRs and/or micro CDRs that are then converted into standard CDRs for a wireless network) for one or more devices to a billing interface (e.g. central billing interface 127), or a billing software (e.g. central billing system 123). Some embodiments communicate the CDR storage and aggregation, mediation feed 118 (and/or any other network elements or combinations thereof) with a service controller (122) to collect device-generated service usage information (e.g. micro-CDRs for one or more devices connected to the wireless network. Some embodiments allow the CDR storage and aggregation, mediation feed 118 (and/or any other network elements or combinations thereof) to communicate with a service controller. In this case, the service controller is communicating with a billing interface, or a billing system. Some embodiments communicate the device-generated service usage information to a billing interface. Some embodiments communicate the CDR storage and aggregation, mediation feed 118 (and/or any other network elements or combinations thereof) with a transport gateway or a Radio Access Network gateway to collect network-based service usage information. The service controller 122 may communicate the device-assisted service usage information (e.g. micro-CDRs), to the CDR Storage, Aggregation, Mediation, Feed 118 (e.g. or other network elements and/or different combinations of network elements).

“In some embodiments the CDR storage and aggregation, mediation feed 118 (e.g. or other network elements and/or different combinations of network elements), performs rules for performing a bill-by-account aggregation function and a mediation function. In some embodiments, the CDR storage, aggregation, mediation, feed 118 (and/or other network elements or combinations of network elements) performs rules for performing a service billing function, as described herein, and/or for performing a service/transactional revenue sharing function, as described herein. The service controller 122, in communication with CDR storage, aggregate, mediation, feed118 (and/or any other network elements or combinations thereof) performs a rule engine for aggregating the service usage information (e.g. micro-CDRs) and mediating it. A rules engine device, in communication with the CDR Storage, Aggregation, Mediation, Fee 118 (e.g. or other network elements and/or varied combinations of network elements), performs a rule engine for aggregating, mediating the device-assisted service usage information (e.g. QOS service usage data and/or network capacity controlled service usage information).

“In some embodiments the rules engine is integrated (e.g., part of/integrated with/part the CDR storage and aggregation. Mediation, feed 118. The rules engine and its associated functions are sometimes a separate function or device in some embodiments. The service controller 122 may perform some or all of the rules engine-based functions described herein and communicates with central billing interface 127. The service controller 122 may perform some or all these rules engine-based functions as described herein and communicates with central billing system (123).

“In certain embodiments, a settlement service is provided. A micro-CDR can be used to aggregate and mediate service usage by a communications device (e.g., the user of the communication device). A rules engine, or another function, can determine the revenue share allocation for service usage to determine the settlement for such revenue sharing model and to distribute accounting information and settlement information to one of the carriers, distribution partners, wholesale partners, MVNOs, or other partners or entities. The service may be a transactional service in some instances.

“In some cases, duplicate CDRs may be sent from network equipment to billing system 123 which is used for service billing. Some embodiments filter duplicate CDRs to only send CDRs/records that are controlled by the service processor and/or controller (e.g. managed devices) This approach, for example, can offer the same level, lower level, and/or higher reporting than the central billing system 123.

“Some embodiments provide a bill-by account billing offset. By providing a CDR aggregate feed that aggregates device assisted service usage data feeds to create a new set CDRs for managed devices, the bill-by-account offset information can be provided to the central accounting system 123. Transaction billing can be provided in some cases using similar methods. Transaction billing log information, for example, can be sent to the central billing interface (127) and/or central billing system (123).

“In certain embodiments, the rules engine, e.g., performed using the service usage 118or another network element as described herein, provides a bill by account billing offset. Device assisted service usage information, such as micro-CDRs, may include a transaction type field (or transaction code) that indicates the type of service being used. The rules engine may apply a rule, or a group of rules, to the identified service that is associated with the device-generated service usage information in order to determine a bill by-account charging offset. For example, a new CDR could be generated to provide the bill-by account billing offset. The bill-by-account offset can be used to credit the user’s account.

Another example is that a transactional services CDR can be generated using a negative offset to account for user’s transactional usage. A second CDR can then be generated using a positive service value to charge the same usage to the transactional provider (e.g. Amazon, eBay, or any other transactional provider). The service controller 122 creates the two new CDRs and aggregates the service usage 118 stores. These two CDRs are then communicated to the central billing interface (127). The service controller 122 generates the two new CDRs and the service usage 118 store aggregates. These two CDRs are then communicated to the central billing interfacing 127. In which the central billing interface 127 applies the rules (e.g. the rules engine for determining bill-by-account offset).

“In some embodiments, service controller 122 transmits device-generated CDRs to the rule engine (e.g., service usage data store, rules engine such as mediation, storage, aggregation and feed 118), and then the rules engine applies one to more rules such as those described herein, and/or any other billing/service usage related regulations as would be obvious to one of ordinary skill. The service controller 122 may generate CDRs that are similar to other network elements. In some instances, the rules (e.g. bill-by-account), are executed in the central billing interface. In some embodiments, such as the service controller 122, which generates CDRs that are similar to other network elements in certain embodiments, the rules (e.g. bill-by-account) are performed in the central billing interface 127.

“In some embodiments, service controller 122 can be provisioned as a new type or function of networking that is recognized by other elements in the network as valid, authorized, secure sources for CDRs (e.g. CDR storage, aggregate, mediation, feed 128) If the network apparatus is unable to recognize CDRs from certain types or equipment, some embodiments may be used. If the necessary network apparatus only recognizes CDRs from certain types of networking equipment (e.g., a transport gateway or RAN gateway), the service controller 122 provides authentication credentials to other equipment that indicates that it is approved for providing CDRs. In certain embodiments, the link between service controller 122, the required CDR aggregation or mediation equipment is encrypted and/or signed.

“In some embodiments, CDR storage and aggregation, mediation feed 118 may discard network-based service usage information (e.g. network based CDRs), received from one or more network element. These embodiments provide the device-based service usage information to the CDR storage and aggregation.

“In some embodiments the device-based CDRs (e.g. micro-CDRs and/or new CDRs generated by execution of a rule engine as described herein) are only available for devices that have been managed and/or are based upon device group, service plans, or any other criteria.

“QoS for DAS may include a service processor, which is any device-assisted element/function that facilitates coordination and/or provision of wireless access/radio bearers (e.g. RABs). The service processor in some embodiments determines whether a request is for QoS. This can be based on QoS service level, user standing and available local network capacity (e.g. as reported by another device(s), network)). Some embodiments provide or augment network capacity demand reports by device QoS capacity.

Click here to view the patent on Google Patents.

How to Search for Patents

A patent search is the first step to getting your patent. You can do a google patent search or do a USPTO search. Patent-pending is the term for the product that has been covered by the patent application. You can search the public pair to find the patent application. After the patent office approves your application, you will be able to do a patent number look to locate the patent issued. Your product is now patentable. You can also use the USPTO search engine. See below for details. You can get help from a patent lawyer. Patents in the United States are granted by the US trademark and patent office or the United States Patent and Trademark office. This office also reviews trademark applications.

Are you interested in similar patents? These are the steps to follow:

1. Brainstorm terms to describe your invention, based on its purpose, composition, or use.

Write down a brief, but precise description of the invention. Don’t use generic terms such as “device”, “process,” or “system”. Consider synonyms for the terms you chose initially. Next, take note of important technical terms as well as keywords.

Use the questions below to help you identify keywords or concepts.

• What is the purpose of the invention Is it a utilitarian device or an ornamental design?
• Is invention a way to create something or perform a function? Is it a product?
• What is the composition and function of the invention? What is the physical composition of the invention?
• What’s the purpose of the invention
• What are the technical terms and keywords used to describe an invention’s nature? A technical dictionary can help you locate the right terms.

2. These terms will allow you to search for relevant Cooperative Patent Classifications at Classification Search Tool. If you are unable to find the right classification for your invention, scan through the classification’s class Schemas (class schedules) and try again. If you don’t get any results from the Classification Text Search, you might consider substituting your words to describe your invention with synonyms.

3. Check the CPC Classification Definition for confirmation of the CPC classification you found. If the selected classification title has a blue box with a “D” at its left, the hyperlink will take you to a CPC classification description. CPC classification definitions will help you determine the applicable classification’s scope so that you can choose the most relevant. These definitions may also include search tips or other suggestions that could be helpful for further research.

4. The Patents Full-Text Database and the Image Database allow you to retrieve patent documents that include the CPC classification. By focusing on the abstracts and representative drawings, you can narrow down your search for the most relevant patent publications.

5. This selection of patent publications is the best to look at for any similarities to your invention. Pay attention to the claims and specification. Refer to the applicant and patent examiner for additional patents.

6. You can retrieve published patent applications that match the CPC classification you chose in Step 3. You can also use the same search strategy that you used in Step 4 to narrow your search results to only the most relevant patent applications by reviewing the abstracts and representative drawings for each page. Next, examine all published patent applications carefully, paying special attention to the claims, and other drawings.

7. You can search for additional US patent publications by keyword searching in AppFT or PatFT databases, as well as classification searching of patents not from the United States per below. Also, you can use web search engines to search non-patent literature disclosures about inventions. Here are some examples:

• Add keywords to your search. Keyword searches may turn up documents that are not well-categorized or have missed classifications during Step 2. For example, US patent examiners often supplement their classification searches with keyword searches. Think about the use of technical engineering terminology rather than everyday words.
• Search for foreign patents using the CPC classification. Then, re-run the search using international patent office search engines such as Espacenet, the European Patent Office’s worldwide patent publication database of over 130 million patent publications. Other national databases include:
• European Patent Office (EPO) provides esp@cenet to access a network of Europe’s patent databases with access to machine translation of European patents. 
• Japan Patent Office (JPO) – with access to machine translations of Japanese patents.
• World Intellectual Property Organization (WIPO) offers PATENTSCOPE with a full-text search of published international patent applications and machine translations for some documents, as well as a list of international patent databases.
• Korean Intellectual Property Rights Information Service (KIPRIS)
• State Intellectual Property Office (SIPO) with machine translation of Chinese patents.
• Other International Intellectual Property Offices with online patent databases include Australia, Canada, Denmark, Finland, France, Germany, Great Britain, India, Israel, Netherlands, Norway, Sweden, Switzerland, and Taiwan.
• Search non-patent literature. Inventions can be made public in many non-patent publications. It is recommended that you search journals, books, websites, technical catalogs, conference proceedings, and other print and electronic publications.

To review your search, you can hire a registered patent attorney to assist. A preliminary search will help one better prepare to talk about their invention and other related inventions with a professional patent attorney. In addition, the attorney will not spend too much time or money on patenting basics.

Download patent guide file – Click here