AGGREGATING MULTIPLE FUNCTIONS INTO A SINGLE PLATFORM

[0001] This application claims the benefit of U.S. Provisional Application No. 61/405,734, filed Oct. 22, 2010, and titled COMMUNICATIONS METHOD AND SYSTEM AGGREGATING MULTIPLE FUNCTIONS INTO A SINGLE PLATFORM, which is incorporated by reference in its entirety.

[0002] The invention generally relates computer systems and computer executed methods of aggregating multiple functions into a single platform.

[0003] Mobile communications networks typically include many separate elements that function as independent entities. These elements may include firewalls, authentication gateways, service gateways, charging and billing gateways, Hypertext Transfer Protocol (HTTP) proxies, video caches, and so forth. These elements are often provided by different manufacturers and require element-specific skills to operate and maintain. Current communications systems have limited speed due in part to the number of diverse elements and the processing that each element perform. Thus, it is difficult and expensive for mobile carriers such as AT&T® Wireless and Verizon® Wireless, to create new services due to the number of elements involved and the diverse expertise required for each element.

[0004] The following presents a simplified summary of the innovation in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. It is intended to neither identify key or critical elements of the invention nor delineate the scope of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented later.

[0005] The present invention provides methods and apparatus, including computer program products, for aggregating multiple functions into a single platform.

[0006] In general, in one aspect, the invention features a communications system including at least one processor, at least one computer readable storage medium storing computer executable instructions that, when executed by the at least one processor, implement components including a workflow module comprising sets of workflow instructions for processing different types of information packets, and selectable communication function modules, the workflow module coordinating processing of a received packet using selected ones of the selectable communication function modules.

[0007] In another aspect, the invention features a method including, in a wireless network, receiving an information packet at an input to a wireless communication apparatus, and employing a processor executing computer executable instructions stored on a computer readable storage medium to perform the following functions: accessing a workflow module comprising rules for processing different types of information packets, determining which one of selectable communication function modules is required to process the received information packet using the rules of the workflow module, and processing the received packet using at least one of the selectable communication function modules.

[0008] In another aspect, the invention features apparatus for wireless communication including a network interface receiving information packets from a first network entity, and a computing platform processing the received packets, the computing platform including a workflow module, and selectable communication function modules, the workflow module coordinating processing of the received packets using selected ones of the selectable communication function modules, the network interface further transmitting processed information packets to a second network entity.

[0009] In another aspect, the invention features a wireless communications apparatus for establishing communication between a first network entity and a second network entity, the apparatus including a network interface receiving information packets from a first network entity, at least one processor, and at least one computer readable storage medium storing computer executable instructions that, when executed by the at least one processor, implement components including a workflow module comprising rules for processing different types of information packets, a deep packet inspection module for inspecting the received packets and providing information about the packets to the workflow module, and selectable communication function modules including a content filtering module, a HTTP proxy module, a video cache module, a video transcoding module, an analytics module, a firewall module, a charging module, a policy enforcement module, a traffic steering module and a latency service module, the workflow module coordinating processing of the received packets using selected ones of the selectable communication function modules and the network interface further transmits processed information packets to a second network entity, establishing communication between the first and second network entities.

[0016] The subject innovation is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It may be evident, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the present invention.

[0017] As used in this application, the terms “component,” “system,” “platform,” and the like can refer to a computer-related entity or an entity related to an operational machine with one or more specific functionalities. The entities disclosed herein can be either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. Also, these components can execute from various computer readable media having various data structures stored thereon. The components may communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal).

[0018] In addition, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. Moreover, articles “a” and “an” as used in the subject specification and annexed drawings should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form.

[0019] As shown in FIG. 1, a workflow server 10 includes a network processor 12 and operating system 14. The operating system 14 includes a workflow engine 16. The workflow server 10 includes a network firewall module 18, a serving gateway (SGW) module 20, a packet data network gateway (PGW) module 22, a HTTP Web proxy module 24, a video proxy module 26 and a service module 28.

[0020] The SGW module 20 routes and forwards user data packets and acts as an anchor for mobility between LTE and other 3GPP technologies.

[0021] The PGW module 22 provides connectivity from user equipment to external packet data networks by being a point of exit and entry of traffic for the user equipment. The PGW module 22 performs policy enforcement, packet filtering for each user, charging support, lawful interception and packet screening.

[0022] The HTTP Web proxy module 24 acts as an intermediary for requests from clients seeking resources from other servers. The HTTP Web proxy module 24 provides web caching, web translating and web transcoding.

[0023] The video proxy module 26 provides video caching, video translating and video transcoding. In addition, this module provides related services involving content manipulation such as advertisement insertion, splicing content together or rewriting adaptive bit rate manifest files.

[0024] The service module 28 provides a number of services, such as, for example, Radius/Diameter, Policy Personal Eventing Protocol (PEP), Packet Forwarding, Content Filtering, Session Management, Domain Name System (DNS) Service, Access Control, Packet Inspection, Session Term, IP Transport I/O, a charging function, a policy enforcement function, a traffic steering function, a latency service function, and so forth.

[0025] The charging function refers to an ability to selectively charge mobile subscribers and/or content partners based on a per flow basis by applying differentiated billing plans based on flow characteristics such as volume of packets, amount of time the flow is active, and the application associated with the flow as determined by shallow or deep packet inspection of the packet(s) in the flow or by analyzing the flow heuristics (e.g., signature analysis), or other parameters associated with servicing the flow such as time of day.

[0026] The policy enforcement function refers to an ability to apply subscriber related QoS and gating policies to a subscriber flow on a per-flow basis, where the flow is determined by shallow or deep packet inspection, or heuristic analysis (e.g., signature analysis) of the flow pattern.

[0027] The latency service refers to an ability to measure network round trip latency between any selected subscriber or set of subscribers and the gateway function in the wireless core.

[0028] The workflow engine 16 provides traffic steering to the various modules.

[0029] The workflow server 10 enables wireless carriers to logically develop service flows in an entirely automated fashion to create a flow across all the network elements and functions such as firewall, network gateways, charging gateways, content filtering engines, deep packet inspections engines to orchestrate new services. The term “service orchestration” as used herein refers to execution of the work flow engine 16, which steers network traffic and executes a collection of functions and their sequence required to instantiate a service workflow, and the multiple capabilities of the workflow server 10 to instantiate a new carrier defined service. Capabilities such as deep packet inspection, charging, content inspection, and service routing are used as tools and capabilities in the workflow engine 16 to orchestrate new services.

[0030] The capability of service orchestration in the workflow server 10 reshapes a creation of services in a carrier network. The workflow server 10 reduces time to market for new services from service conception to service delivery, leading to rapid revenue generation for new services. The workflow server 10 enables improvement in service quality and delivery. The workflow server 10 enables capital expenditure cost reduction due to reduced network integration expenses. The workflow server 10 provides operational expense savings due to minimized need for professional services. The workflow server 10 enables service creation and development flexibility at Layer 4 through 7 and device parameter and programming simplification.

[0031] The development and institution of new services in a wireless carrier environment is a complex and time consuming process. The ability of a mobile subscriber to traverse multiple packet data networks (PDNs) due to the devices ability to roam causes even further complexity to roll out new services. Unlike the Internet universal resources locator (URL) routing concept, which selects the server that hosts the application, access point name (APN) traffic routing principles are more catered toward getting a subscriber to the “network element” (GGSN) that owns the data session and not the application server. The home GGSN does not act like an application server but more like a packet forwarding engine to get the session to the next network entity in the service chain. It terminates the GTP tunnel and then uses Layer 3 transport routing rules to get the sessions to the next network element. The next element can be either one of many elements to deliver, manage, or bill the service. Service orchestration includes Layer 3 routing and rules insertion by each specific network element.

[0032] In order to orchestrate a service across all of the respective network elements, the carrier must develop a comprehensive Internet Protocol (IP) routing plan to do next route hopping to get to each element that will have a role in invoking, load balancing, charging, content filtering, firewalling, and billing the service. The engineering process to do this is a very labor intensive, complex network integration, and costly endeavor from both a professional services and time to market perspective.

[0033] In general, an access point name (APN) identifies an internet protocol (IP) packet data network (PDN), which a mobile data user wants to communicate with. In addition to identifying a PDN, an APN may also be used to define the type of service, e.g., connection to a wireless application protocol (WAP) server or a connection to a multimedia messaging service (MMS), which is provided by the PDN. Because the APN concept was purposefully designed for carrier network selection and routing and not service application selection, and considering time to market complexities, carriers are looking at alternative approaches for how APNs are used in delivering 4G, 3G and LTE services. A majority of the carriers for both their 3G and 4G infrastructure are considering the use of a single APN to run all service on the mobile device. The introduction of a generic APN reduces the complexity of introducing new services by minimizing the device aspects of the APN provisioning. When the carrier implements a single APN the problems of lengthy provisioning sweeps to rollout new services no longer exist. However, the network traffic steering processes for services takes on a greater degree of complexity if steps are not taken to simplify the network traffic flow. The workflow sever 10 simplifies the network traffic service flows through a single automated environment.

[0034] Before describing service orchestration in the workflow server 10, we will consider a fairly simplistic analogy of service orchestration in another industry. Let us consider the delivery of a FedEx® parcel from it origination point to its final delivery destination. The first thing that must happen is the FedEx® mail must be addressed by the originator to get to its final destination. This step is analogous to a mobile phone launching the APN with the intent to use, for example, an Internet Browse service. In the case of mail, the addressee, the destination address, city, state, and zip code all play a pivotal role in getting the mail to its final destination with on time delivery. There is nothing done at this point in time to determine what type of parcel it is (e.g., a letter or a box).

[0035] In the case of the wireless phone, the APN is the equivalent of addressing the packets from the mobile device for delivery. In the case where carriers use a generic APN, the specific service being requested is not known (e.g., Internet Browse or Video). Going back to the postal example, the automated system in FedEx® looks at the size, weight, delivery destination using bar codes, and sorts the letters from the boxes. It also looks at time delivery commitment intervals and appropriately sorts the parcel. Then using the bar coded label, the parcel is automatically routed to the destination address at each touch point by simply scanning the bar code for destination information. The FedEx® system is a automated rules based system that requires little manual intervention along the delivery path. It recognizes delivery priority, destination, and routing logistics by analyzing the parcel along the various touch points automatically to insure on-time delivery and quality of service to the final destination. These capabilities are needed to automate the carrier's network to facilitate the use of a generic APN to deliver services. However, in the wireless phone example, the network elements are not capable of delivering the same experience because each network element must have a set of rules manually provisioned into it each every time a new service is introduced, whereas the FedEx® system adapts to changes in parcel size, destination, delivery time at each touch point.

[0036] In the workflow server 10, workflows enable wireless operators to create service flows and include identification of a service flow via a L4-L7 DPI analyzer, a set of functions with corresponding rules and a sequence that is applied to the service flow. Workflows are created to examine packets at multiple layers in the OSI stack (Layers 4-7) and to define a set of rules to inspect any APN service flow. The service flow can be either generated by the wireless subscriber, the operator, or a content partner to route, charge, bill, filter, or to take any other action such as a Diameter or LDAP query to create a new service or modify an existing one. Workflow rules are constructed using data analyzers. These analyzers are names given to the DPI primitives that indicate the layer of the stack and the type of packet that is used to create the analyzer. For example, a data analyzer to trap a MSISDN of mobile at the GTP layer can be named GTP.MSISDN. The end result of the workflow process is service orchestration or simply stated, the instantiation of a new service in the operators network using an automated process.

[0037] The workflow process includes the functions of flow partitioning, flow dispatching and flow pipelining.

[0038] Flow partitioning refers to an ability to perform deep packet inspection on service flows and screen for the actionable triggers to trap and analyze the data. Examples include:

[0039] HTTP to URL disney.com

[0040] DNS for GTP.MSISDN=mickey

[0041] TCP with DstPort=8

[0042] SKYPE with source_user=mickey and destination_user=Minnie

[0043] Flow dispatching refers to an ability to take specific action on the returned result(s) of flow partitioning, such as route packets to internal content filters or invoke a LDAP query for subscriber information.

[0044] Analytics→log to analytics service named “mobile_latency”

[0045] Firewall→perform firewall service named “gatekeeper”

[0046] Content Filter→perform parental controls named “nanny” Charging Filter-> perform charging control named “prepaid”

[0047] Calea Filter→perform lawful intercept named “Calea”

[0048] Video→Perform video service named “madhatter”

[0049] MSISDN→perform LDAP query

[0050] Flow pipelining refers to an ability to control order and flow dispatching of packets, including an ability to make branch dependent dynamic decisions with flow decisions occurring at each branch.

[0051] Let's construct a sample workflow to orchestrate a service on a generic APN using the following flow partitioning rules and flow dispatch. The construct of the rule is as follows:

[0052] Flow Partition→Flow Dispatch

[0053] The first flow partitioning rule is used to examine the service flow from the mobile device to look for a DNS query from the mobile device to specific URLs. Both rules direct the packets from a flow dispatch perspective to the content filter service. The rules are constructed as follows:

[0054] DNS (two rule sets listed below)

[0055] DNS.URL=*.com→*.com Content Filter

[0056] DNS.URL=*.att→att.net Content Filter

[0057] The next flow partitioning rule is used to examine the service flow from the mobile at the GTP level to look for an ICMP traffic from a specific mobile IMSI and a specific traffic type of ICMP. The rule then takes the result and flow dispatches it towards a service called “Mobile Latency Analytics Service.” The rule is constructed as follows:

[0058] ICMP (one rule set listed below)

[0059] GTP.IMEI =goofy and ICMP.TYPE=ECHO→Mobile Latency Analytics Service

[0060] The last flow partitioning rule is used to examine the service flow from the mobile at the HTTP level to determine the URL type and the GTP for a specific device. The HTTP rule directs the traffic toward the .com proxy service and GTP rule directs the traffic toward a service labeled “External Transcoders.” The rules are constructed as follows:

[0061] HTTP (two rule sets listed below)

[0062] Http.URL=*.com→*.com Proxy

[0063] GTP.DEVICE=U350→External transcoder Service

[0064] Using the above set of flow partitioning rules and flow dispatch services, let's use the flow pipelining process to orchestrate a couple of services. An example of a service a wireless operator can create using workflow is a relatively simple but very valuable service to analyze the latency of a given set of mobile devices with a range of International Mobile Equipment Identity (IMEI). An example of this type service is to measure latency for all Apple® IPhone® devices in a certain geographical area (e.g., PGW serving area).

[0065] GTP.IMEI=goofy and IP.TYPE=PROTO and ICMP.TYPE=ECHO→Mobile Latency Analytics Service

[0066] The new service is instantiated across a generic APN and orchestrated to a latency mobile measurement service named Mobile Latency Analytics. FIG. 2 illustrates an exemplary mobile analytics service workflow.

[0067] In another example, a workflow is designed to analyze the traffic flow from a generic APN and steer the traffic to the workflow server 10 content filter for analysis. In this example, the workflow process goes up the TCP Layer to orchestrate the service. This service example depicts the analysis of a URL and dispatches to the content filter for screening of explicit content. This workflow process creates a simple parental control service. The new service is instantiated using the generic APN to orchestrate a service named parental control. In this case there are four flow partitioning rules, each having a different flow dispatch. The flow pipelining process then makes the dynamic branching decisions necessary to orchestrate the service called parental controls. The rules are listed below.

[0068] GTP.TID→GTP Packet Context Service

[0069] IP.Proto=UDP→IP Packet Context Service

[0070] UDP.Port=DNSPort 53→DNS Packet Context Service

[0071] DNS.URL→DNS Packet ContextService

[0072] FIG. 3 illustrates an exemplary parental control service workflow.

[0073] In still another example, a work flow is illustrated that analyzes the traffic flow from a generic APN to determine whether to route the traffic to a HTTP proxy. In this example, the work flow process goes up the HTTP layer to orchestrate the service. This service example depicts the analysis of URLs to invoke the .com proxy service on the workflow server 10. In this case, a single flow partitioning rule and flow dispatch is used to create the service. The rule is listed below.

[0074] HTTP.URL=*.com→.com Proxy Service

[0075] FIG. 4 illustrates an exemplary HTTP proxy service workflow.

[0076] The examples above indicate that the workflow process is a very powerful tool that reshapes the manner in which carriers design, provision and implement services in their network. Although the examples given were simplified, the workflow engine 16 enables the creation of multiple flow partitioning rules and facilitates a flow pipelining process to create services of varying complexity in the carrier network.

[0077] In order to facilitate the workflow engine 16, the following conventions are used.

[0078] The service work flow partitioning process should allow packet inspection at Layer 4-7 of the software stack.

[0079] A naming convention for the data analyzers for Layer 4 through 7 should be established in order to build a rule to DPI rule and to analyze the data primitive. An example of a data analyzer is GTP.IMEI that serves as the name of the analyzer to trap International Mobile Equipment Identifier (Phone Type) at the GTP layer.

[0080] A suite of data analyzers should be established for the data primitives for Layers 4-7. The suit of analyzers should be broad enough at each layer to allow robust service flow creation.

[0081] The workflow process should enable creation of multiple Data Analyzers to be established for at each layer.

[0082] The service workflow partitioning process should enable a user to input multiple rules using data analyzers from a single or multiple layers of the software stack.

[0083] The workflow engine 16 is the single place to implement service logic and rules for multiple network functions such as firewalls, content filtering, charging, data base queries and other service functions All the functions of the workflow are provisioned from the same user interface screen and there is a single place to workflow engine 16 to validate the rules provisioned as part of the workflow.

[0084] The service workflow partitioning process should enable a user to input rules using the IF, AND, OR, and ELSE syntax to create rules.

[0085] The service workflow process should enable rules using the IF, OR, AND Syntax to be chained together to create a “Super Rules” statement.

[0086] The service workflow dispatch process should enable the rule result to be dispatched and results collected in unique user defined service context.

[0087] The service workflow pipelining process should allow logical ordering of multiple service contexts (service branch results) to create a service flow.

[0088] The service workflow pipelining process should enable logical ordering of multiple service contexts (service branch results) to create a service.

[0089] TEst Mobile System (TEMS) is an Ascom network monitoring and real-time diagnostics suite. The following is a list of TEMS considerations for service flow provisioning in the workflow server 10.

[0090] TEMS should allow an operator to provision a new service workflow using an intuitive and user friendly manner from one single GUI interface.

[0091] Service workflows provisioning operators should be agnostics to the protocol level details. TEMS shall present user with various filterable attributes at each Layer (4 to 7), during a work flow provisioning flow. The operator should be agnostic to any protocol level details while selecting filtering criteria to define a work flow rule.

[0092] Context sensitive service workflows provisioning. TEMS shall present flow partitioning attributes in a context sensitive matter compared to the other flow partitioning attributes provisioned at different protocol layers for the same service work flow.

[0093] What the above means is that if stage ‘n+1’ of partitioning flow attributes depends on stage ‘n’ then only a valid set of attributes are shown to the user for selection during a service workflow provisioning.

[0094] Tabular display of all the service workflows. TEMS shall display all the service workflows provisioned per node (or per network) in a tabular fashion.

[0095] Modification of existing service workflows. TEMS shall allow operator to modify an existing work flow by letting them add, modify or delete any rules from an existing service workflows. Operator shall be notified of the impacts to the existing service workflow modifications.

[0096] Ordering rules within a service workflow. TEMS shall allow an operator to define or change the order in which different partition rules shall be executed or dispatched.

[0097] Defining relationship (AND/OR) between different rules with in a service workflow. TEMS should allow an operator to define a relationship (without the need to type in anything) of ANDing or ORing between any set of rules.

[0098] Defining relationship (AND/OR) between different rules with in a service workflow. TEMS should allow an operator to define a relationship (without the need to type in anything) of ANDing or ORing between any set of rules.

[0099] Combine different service workflows. TEMS should allow one of more existing service work flows to be combined to merged to form a new service workflows.

[0100] Service workflows history and audits. TEMS should present to the operator a complete audit trail of the service work flows creation, modification or deletion.

[0101] Validation of service workflows during its creation or modification. Before a service work flow is created or modified on a network element, a validation rule runs on the node to make sure that the new service work flow being provisioned is not conflicting with any existing service workflow. An appropriate error message shall be presented to the user in the case of a validation failure. The newly created rules shall be checked with in or outside the work flow context to make sure there are no conflicts.

[0102] Collecting analytics on service workflows. TEMS should allow operators to enable/disable analytics on any service workflows. The attributes for the analytics to be collected for any service workflow shall be pre-defined. Operator shall be able to add, delete or modify from the default analytics template for any service workflows.

[0103] Customer association with service workflows. TEMS should allow operators to associate service workflows with an end customer.

[0104] Operator shall be able to define and configure workflows to handle different overload conditions. For example, in a case of an overload, if CPU usage on a particular card is more than the high threshold mark then for a particular kind of traffic (HTTO, Video), the workflow server 10 acts as a pass through. This pass through is enabled or disabled on the workflow server 10 by configuring workflows. The Operator can configure the following rules:

[0105] a. Application.Type=Http OR Application.Type=Video Streaming [Flow Partitioning Rule]

• • [0106] i. Ssm.cpu-usage>cpu-high-threshold (e.g. 95%) [Overload Condition ‘State’]
  • [0107] ii. Delete NPU rule to forward the packet to the CSM card. This enables pass through for any http video request [Action #1]
  • [0108] iii. Non Service Impacting vs. Service Impacting [Action #2].
  • [0109] iv. No Charging (pass through case) vs. still maintain Charging information for the subscriber [Action #3].

[0110] b. Application.Type=Http OR Application.Type=Video Streaming [Flow Partitioning Rule]

• • [0111] i. Ssm.cpu-usage<={cpu-high-threshold−5% of cpu-high-threshold (e.g. 95%)} [Overload Condition ‘State’]
  • [0112] ii. Add NPU rule to forward the packet to the CSM card i.e. no pass through [Action #1].
  • [0113] iii. Non Service Impacting vs. Service Impacting [Action #2].
  • [0114] iv. No Charging vs. still maintain Charging information for the subscriber [Action #3].

[0115] Operator should be able to configure actions for the load distribution use case where CPU threshold on a particular card is more than the low threshold mark but smaller than the high threshold mark. We want operator to be notified (warning alarm) so that they can plan/budget the CSM capacity on the workflow server 10. Operator can configure the following rules:

[0116] a. Application.Type=Http OR Application.Type=Video Streaming [Flow Partitioning Rule]

• • [0117] i. Ssm.cpu-usage<cpu-high-threshold (e.g. 95%) and Ssm.cpu-usage>cpu-low-threshold (e.g. 75%) [Overload Condition ‘State’]
  • [0118] ii. Raise a warning alarm to TEMS and indicate the full CSM capacity approaching condition to the operator [Action #1].
  • [0119] iii. If this condition happens multiple times within a configured time interval (e.g., 1 day) then the alarm condition could be raised to a Major one [Action #2].

[0120] b. Application.Type=HTTP OR Application.Type=Video Streaming [Flow Partitioning Rule]

• • [0121] i. Ssm.cpu-usage<=<={cpu-low-threshold−5% of cpu-low-threshold (e.g. 75%)} [Overload Condition ‘State’]
  • [0122] ii. Clear the alarm condition [Action #1].

[0123] A user interface flow for provisioning a service workflow can be a three to four step process (launched all from the same graphical user interface (GUI) screen) where each step collects different information from the end user. The stages and the type of information to be collected at each stage are described below.

[0124] 1. (Step-1) Flow Partitioning

[0125] a. User is presented a screen with a drop down menu item indicating an option to select Layer-4 to Layer-7 flow partitioning. Depending on the selected layer, attributes specific to that layer are shown with a check box allowing users to select the attributes they want for the flow partition. Eg:-HTTP.URL, GTP.TID, IP.Proto, UDP.Port, DNS.URL etc.

[0126] Flow Partitioning Rule Examples

[0127] HTTP.URL=http://www.nytimes.com

[0128] HTTP.Referer begins with http://www.nytimes.com

[0129] DNS.QueryName finishes with nytimes.com

[0130] HTTP.URL contains nytimes

[0131] IP.TotLen<1000

[0132] IP.TotLen>1000

[0133] DNS.QueryName !finishesWith nytimes.com

[0134] 2. (Step-2) Flow Dispatching

[0135] a. A next screen presents to the end user a pre-defined set of ‘Services’ where the results of flow partitioning shall be dispatched to. The list of services can include, but are limited to, analytics like Mobile Latency, firewall like ‘gatekeeper’, Content Filter, CALEA Filter, Video or MSISDN services.

[0136] An example of a transaction for charging can be configured as follows:

[0137] HTTP.URL finishes with .mp3 and HTTP.State=RESP_OK (indicates and MP3 file was downloaded).

[0138] Actions on the above can be defined as:

[0139] Drop packet

[0140] Send packet to service with value (should be able to include things like charging values, i.e., HTTP.TotLen)

[0141] Redirect to URL (should be able to build URL dynamically from flow partitioning .

[0142] 3. (Step-3) Flow Pipelining

[0143] a. A next screen presents to the user the order in which he/she wants to the dispatched flows to be applied.

[0144] 4. (Step-4) Workflow Analytics

[0145] a. Based on the type of the service work flow, this screen can present to the end user a pre-defined set of analytics parameter that can be collected for a particular workflow or it could present a dynamic list of parameters that user can select to be collected as part of the service workflow analytics.

[0146] As shown in FIG. 5, a workflow process 100 includes receiving (102) an information packet at an input to a wireless communication apparatus.

[0147] The workflow process 100 employs (104) a processor executing computer executable instructions stored on a computer readable storage medium to perform functions (106).

[0148] The functions (106) include accessing (108) a workflow module including rules for processing different types of information packets, determining (110) which one of selectable communication function modules is required to process the received information packet using the rules of the workflow module, and processing (112) the received packet using at least one of the selectable communication function modules.

[0149] The workflow process 100 may include performing (114) a deep packet inspection on the received information packet prior to determining which of the selectable communication function modules is required to process the received information packet.

[0150] Processing (112) the received packets may include using the workflow module to coordinate the selectable communication function modules. All information flows through the workflow module to the selectable communication function modules and no information flows directly between the selectable communication function modules.

[0151] Embodiments of the invention can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Embodiments of the invention can be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

[0152] Method steps of embodiments of the invention can be performed by one or more programmable processors executing a computer program to perform functions of the invention by operating on input data and generating output. Method steps can also be performed by, and apparatus of the invention can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0153] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry.

[0154] The foregoing description does not represent an exhaustive list of all possible implementations consistent with this disclosure or of all possible variations of the implementations described. A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the systems, devices, methods and techniques described here. For example, various forms of the flows shown above may be used, with steps re-ordered, added, or removed. Accordingly, other implementations are within the scope of the following claims.