HK1190215A - Aggregating multiple functions into a single platform - Google Patents
Aggregating multiple functions into a single platform Download PDFInfo
- Publication number
- HK1190215A HK1190215A HK14103340.5A HK14103340A HK1190215A HK 1190215 A HK1190215 A HK 1190215A HK 14103340 A HK14103340 A HK 14103340A HK 1190215 A HK1190215 A HK 1190215A
- Authority
- HK
- Hong Kong
- Prior art keywords
- module
- workflow
- communication function
- function modules
- information
- Prior art date
Links
Abstract
Methods and apparatus, including computer program products, for aggregating multiple functions into a single platform. A communications system includes 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.
Description
Cross Reference to Related Applications
This application claims the benefit of U.S. provisional application No. 61/405,734, entitled "composite functional coatings in input sheet PLATFORM", filed on 22/10/2010, which is incorporated herein by reference in its entirety.
Background
The present invention relates generally to computer systems and computer-implemented methods that aggregate multiple functions into a single platform.
A mobile communication network typically comprises many separate elements operating 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 components are typically provided by different manufacturers and require component-specific skills to operate and maintain. Current communication systems have limited speed due in part to the number of different elements and the processing performed by each element. Thus, for mobile operators (e.g. mobile operators)Wireless andwireless), creating new services is difficult and expensive due to the number of components involved and the various expertise required for each component.
Summary of The Invention
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.
The present invention provides a method and apparatus, including a computer program product, for aggregating multiple functions into a single platform.
In general, in one aspect, the invention features a communication system that includes at least one processor; at least one computer-readable storage medium storing computer-executable instructions that, when executed by at least one processor, implement a component comprising: a workflow module comprising a set of workflow instructions for processing different types of information packets; and optional communication function modules, the workflow module coordinating processing of the received packets using selected ones of the optional communication function modules.
In another aspect, the invention features a method that includes: in a wireless network, receiving an information packet at an input to a wireless communication device, and employing a processor executing computer-executable instructions stored in a computer-readable storage medium to perform functions comprising: accessing a workflow module, the workflow module including rules for processing different types of information packets; determining which optional communication function module 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.
In another aspect, the invention features an apparatus for wireless communication, comprising: a network interface to receive an information packet from a first network entity; and a computing platform to process the received packets, the computing platform including a workflow module and optional communication function modules, the workflow module coordinating processing of the received packets using selected ones of the optional communication function modules, the network interface further to send the processed information packets to a second network entity.
In another aspect, the invention features a wireless communications apparatus for establishing communications between a first network entity and a second network entity, the apparatus including a network interface that receives information packets from the first network entity; at least one processor; and at least one computer-readable storage medium storing computer-executable instructions that, when executed by at least one processor, implement a component comprising: a workflow module comprising rules for processing different types of information packets; a deep packet inspection module for inspecting a received packet and providing information related to the packet to the workflow module; and an optional communication function module including a content filtering module, an HTTP proxy module, a video caching module, a video transcoding module, an analysis 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 received packets using selected ones of the optional communication function modules, and the network interface further sending the processed information packets to a second network entity, thereby establishing communication between the first network entity and the second network entity.
Brief Description of Drawings
The present invention will be more fully understood by reference to the detailed description taken in conjunction with the following drawings, in which:
FIG. 1 is a block diagram of an exemplary workflow server.
Fig. 2 is an exemplary mobile analytics service workflow.
Figure 3 is an exemplary parental control services workflow.
Fig. 4 is an exemplary HTTP service workflow.
Fig. 5 is a flowchart.
Detailed Description
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.
As used in this application, the terms "component," "system," "platform," and the like can refer to a computer-related entity or an entity associated with an operational machine having one or more specific functions. The entities disclosed herein may be hardware, a combination of hardware and software, or software in execution. For example, a component may be, but is not limited to being, a process running on 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. In addition, 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).
In addition, the term "or" means an inclusive "or" rather than an exclusive "or". That is, unless specified otherwise, or clear from context, "X employs a or B" means any of the natural inclusive permutations. That is, if X employs A; x is B; or X employs both A and B, then "X employs A or B" is satisfied under any of the foregoing circumstances. In addition, the articles "a" and "an" as used in the subject specification and drawings are generally to be construed to mean "one or more" unless specified otherwise or clear from context to be directed to a singular form.
As shown in FIG. 1, the workflow server 10 includes a network processor 12 and an 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, an HTTP network proxy module 24, a video proxy module 26, and a service module 28.
The SGW module 20 routes and forwards user data packets and serves as an anchor for mobility between LTE and other 3GPP technologies.
PGW module 22 provides connectivity from the user equipment to external packet data networks by acting as an egress and ingress point for traffic of the user equipment. PGW module 22 performs policy enforcement, packet filtering for each user, charging support, lawful interception and packet screening.
The HTTP network proxy module 24 acts as an intermediary for requests from clients seeking resources from other servers. The HTTP network proxy module 24 provides network caching, network translation, and network transcoding.
The video proxy module 26 provides video caching, video conversion, and video transcoding. In addition, the module provides related services that involve content manipulation (such as ad insertion, splicing together content, or rewriting adaptive bitrate manifest files).
The service module 28 provides a number of services such as, for example, radius/diameter, policy personal transaction protocol (PEP), packet forwarding, content filtering, session management, Domain Name System (DNS) services, access control, packet inspection, session deadline, IP transport I/O, charging functions, policy enforcement functions, traffic steering functions, latency service functions, and so forth.
The charging function refers to the ability to selectively charge mobile users and/or content partners on a per flow basis by applying a differentiated charging scheme based on flow characteristics (such as the volume of packets, the amount of time a flow is active, and the application associated with the flow) or other parameters associated with serving the flow (such as the time of day), as determined by surface or deep packet inspection of one or more packets in the flow, or by analyzing flow heuristics (e.g., signature analysis).
Policy enforcement functions refer to the ability to apply user-related QoS and gating policies to user flows on a per-flow basis, where flows are determined by surface or deep packet inspection or heuristic analysis of flow patterns (e.g., signature analysis).
Latency service refers to the ability to measure the network round-trip latency between any selected user or group of users and the gateway function in the wireless core.
The workflow engine 16 provides traffic steering to the various modules.
The workflow server 10 enables wireless carriers to logically develop service flows in a fully automated manner to create flows across all network elements and functions (e.g., firewalls, gateways, charging gateways, content filtering engines, deep packet inspection engines) to orchestrate new services. The term "service orchestration" as used herein refers to the execution of the workflow engine 16, which directs network traffic and performs a set of functions and its order required to instantiate a service workflow, as well as the functions of the workflow server 10 for instantiating new operator-defined services. Functions such as deep packet inspection, charging, content inspection, and service routing are used as tools and functions in orchestrating new services in the workflow engine 16.
The service orchestration capability in the workflow server 10 may reshape the service creation in the operator network. The workflow server 10 shortens the time-to-market for a new service from the service concept to the service delivery, thereby enabling the new service to generate revenue quickly. The workflow server 10 enables improvements in quality of service and delivery. The workflow server 10 may result in reduced capital expenditure costs due to reduced network integration costs. The workflow server 10 provides operational cost savings as the need for professional services is minimized. The workflow server 10 enables flexibility in service creation and development as well as simplification of device parameters and programming on layers 4 to 7.
Developing and establishing new services in a wireless carrier environment is a complex and time consuming process. Due to the device roaming capability, mobile users are able to traverse multiple Packet Data Networks (PDNs), which makes the introduction of new services even more complicated. Unlike the internet Uniform Resource Locator (URL) routing concept, which chooses the server that hosts the application, the Access Point Name (APN) traffic routing principle is more appropriate for users to reach the "network element" (GGSN) that owns the data session instead of the application server. The home GGSN does not operate like an application server but rather like a packet forwarding engine that takes 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 session to the next network element. The next element may be one of a plurality of elements used to deliver, manage, or bill for the service. Service orchestration includes layer 3 routing and rule insertion by each particular network element.
To orchestrate a service across all of the corresponding network elements, the operator must develop a comprehensive Internet Protocol (IP) routing scheme to make the next route hop to reach each element that will participate in the invocation, load balancing, charging, content filtering, firewall, and billing of the service. The engineering process to do this is a very labor intensive, complex network integration and costly laborious task from both a professional service and time-to-market perspective.
In general, an Access Point Name (APN) identifies an Internet Protocol (IP) Packet Data Network (PDN) with which a mobile data user wishes to communicate. In addition to identifying the PDN, an APN may also be used to define a service type, e.g. whether a connection to a Wireless Application Protocol (WAP) server or a connection to a Multimedia Messaging Service (MMS) provided by the PDN. Because the APN concept is purposefully designed for operator network selection and routing rather than service application selection, and taking into account the complexity of time-to-market, operators are looking for alternative approaches to how to make APNs for providing 4G, 3G and LTE services. For their 3G and 4G infrastructure, most carriers are considering using a single APN to run all services on a mobile device. The introduction of generic APNs may reduce the complexity of introducing new services by minimizing the device aspects of APN provisioning. The problem of lengthy provisioning procedures to bring up new services is no longer present when the operator implements a single APN. However, the network traffic steering process for a service can entail a greater degree of complexity if no measures are taken to simplify the network traffic flow. The workflow server 10 simplifies network traffic service flow through a single automation environment.
Before describing the service orchestration in the workflow server 10, we will consider a rather simplified analogy to service orchestration in other industries. Let us considerThe delivery process of a package from its origin to its final delivery destination. The first thing that must occur isMail must be addressed by its originator to reach its final destination. This step is similar to the mobile phone initiating an APN with the intention to use e.g. an internet browsing service. In the case of mail, the recipient, destination address, city, state, and zip code all play an important role in getting the mail to its final destination with on-time delivery. Nothing is done at this point in time to determine what type of package (e.g., letter or box) this is.
In the case of a wireless telephone, the APN corresponds to the delivery address of the packet from the mobile device. In case the operator uses a generic APN, the specific service requested (e.g. internet browsing or video) is not known. Returning to the example of mailing of the mail,the automated system in (1) will look at size, weight, delivery destination using bar code, and sequence letters from boxes. The system also looks at the time delivery commitment interval and orders the packages appropriately. The package is then automatically dispatched to the destination address at each contact point using a bar code label by simply scanning the bar code for destination information.The system is an automated rule-based system that requires little human intervention along the delivery path. The system identifies delivery priority, destination, and dispatch logistics by automatically analyzing packages along various points of contact to ensure on-time delivery and quality of service to the final destination. These functions are needed to automate the operator's network in order to provide services using a generic APN. However, in the wireless telephone example, the network elements are not able to provide the same experience because each network element must have a set of rules manually provisioned into it each time a new service is introduced, andthe system accommodates variations in package size, destination, delivery time at each contact point.
In the workflow server 10, the workflow may enable the wireless carrier to create a service flow and include an identification of the service flow via an L4-L7 (layers 4 to 7) DPI analyzer, a set of functions with corresponding rules, and a sequence applied to the service flow. A workflow is created to examine packets at multiple layers (layers 4-7) in the OSI stack and define a set of rules to detect any APN service flow. The service flow may be generated by the wireless user, operator, or content partner to route, charge, bill, filter, or take any other action (such as diameter or LDAP query) to create a new service or modify an existing service. Workflow rules are constructed using a data analyzer. These analyzers are the names given to the DPI primitives, which indicate the layers of the stack and the type of packet used to create the analyzers. For example, a data analyzer that captures the MSISDN of the mobile at the GTP layer may be named GTP. The end result of the workflow process is service orchestration or simply, the use of an automated process to instantiate a new service in the operator network.
The workflow process includes functions of flow division, flow scheduling, and flow delivery.
Flow partitioning refers to the ability to deep packet inspect a service flow and screen against operational triggers to capture and analyze data. Examples include:
com to URL disney
DNS for gtp. msisdn ═ mickey
DstPort-8 TCP
SKYPE of source _ user ═ mickey and destination _ user ═ Minnie
Flow scheduling refers to the ability to take specific actions (such as routing packets to an internal content filter or invoking an LDAP query for user information) on one or more returned results of flow partitioning.
Analyze → Login to an analysis service named "Mobile _ latency
Firewall → executing Firewall service named "gatekeeper
Content Filter → performing parental controls named "nanny
Charge Filter → implementation of Charge control named "prepoid
Calea (communications assistance Law Enforcement Act) Filter → enforcement of statutory interception named "Calea
Video → performing a video service named "madhatter
MSISDN → performing LDAP queries
Flow delivery refers to the ability to control the order of packets and flow scheduling, including the ability to make branch-related dynamic decisions through flow decisions that occur on each branch.
Let us build an example workflow to orchestrate services on a generic APN using the following flow partitioning rules and flow scheduling. The rules are structured as follows:
flow division → flow scheduling
The first flow splitting rule is used to examine the service flow from the mobile device for DNS queries from the mobile device to a particular URL. From a flow scheduling perspective, both rules direct packets to a content filtering service. The rules are structured as follows:
DNS (two rule sets listed below)
URL ═ com →
Url att → att
The next flow splitting rule is used to examine service flows from mobiles at the GTP level for ICMP traffic from a particular mobile IMSI and a particular traffic type for ICMP. The rule then takes the result and the flow schedules it towards a Service called "Mobile Latency analysis Service". The rules are structured as follows:
ICMP (one rule set listed below)
Imei goofy and icmp type ECHO → mobile latency analysis service
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 GTP for the particular device. The HTTP rules direct traffic towards the com proxy service, while the GTP rules direct traffic towards the service labeled "External Transcoders". The rules are structured as follows:
HTTP (two rule sets listed below)
Url ═ com →
Device U350 → external transcoding service
Using the above set of flow partitioning rules and flow scheduling service, let us use flow deliveryTo program several services. An example of a service that a wireless operator may create using a workflow is a relatively simple but very valuable service to analyze the latency of a given group of mobile devices having a range of International Mobile Equipment Identities (IMEIs). An example of this type of service is measuring all Apple within a certain geographic area (e.g., PGW service area)The latency of the device.
Gtp, imei, goofy, type, PROTO, icmp, type, ECHO → mobile latency analysis service
The new service is instantiated across generic APNs and is arranged into a Latency Mobile measurement service named Mobile Latency Analytics. Fig. 2 illustrates an exemplary mobile analytics service workflow.
In another example, the workflow is designed to analyze traffic flows from a generic APN and direct the traffic to a workflow server 10 content filter for analysis. In this example, the workflow process reaches the TCP layer to orchestrate the services. The service example depicts the analysis of URLs and the scheduling to content filters to filter explicit content. This workflow process creates a simple parental control service. A new service is instantiated using a generic APN to orchestrate a service named "parental control". In this case, there are four flow partitioning rules, each with a different flow schedule. The streaming process then makes the dynamic branching decisions necessary to orchestrate the service named "parental control". These rules are listed below.
GTP.TID → GTP packet context service
Proto UDP → IP packet context service
Port and DNSPort 53 → DNS packet context service
URL → DNS packet context service
Figure 3 illustrates an exemplary parental control services workflow.
In another example, a workflow is shown that analyzes traffic flows from a generic APN to determine whether to route traffic to an HTTP proxy. In this example, the workflow process goes to the HTTP layer to orchestrate the service. The example of this service depicts analyzing the URL to invoke the com proxy service on the workflow server 10. In this case, a single flow partitioning rule and flow scheduling are used to create the service. The rules are listed below.
Url ═ com →. com proxy service
Fig. 4 illustrates an exemplary HTTP proxy service workflow.
The above example shows that the workflow process is a very powerful tool that can reshape the way operators design, provision and implement services in their networks. Although simplifying the example given, the workflow engine 16 enables the creation of multiple flow partitioning rules and facilitates the flow delivery process to create services of varying complexity in the operator network.
To facilitate the workflow engine 16, the following convention is used.
The service workflow partitioning process should allow packet inspection at layers 4-7 of the software stack.
A naming convention for layer 4 to layer 7 data analyzers should be created to establish rules for DPI rules and analyze data primitives. Imei, which is the name of the analyzer used to capture the international mobile equipment identity (phone type) on the GTP layer.
A suite of data analyzers should be created for layer 4-layer 7 data primitives. The set of parsers should be wide enough on each layer to allow for robust service flow creation.
The workflow process should enable the creation of multiple data analyzers to be built at each layer.
The service workflow partitioning process should enable a user to input a plurality of rules using a data analyzer from one or more layers of the software stack.
The workflow engine 16 is a single place to implement service logic and rules for multiple network functions, such as firewall, content filtering, charging, database querying, and other service functions. All functions of the workflow are provisioned from the same user interface screen and there is a single place for the workflow engine 16 to validate rules provisioned as part of the workflow.
The service workflow partitioning process should enable the user to input rules using IF, AND, OR AND ELSE syntax to create rules.
The service workflow process should enable rules using IF, OR, AND syntax to be chained together to create a "super rule" statement.
The service workflow scheduling process should enable rule results to be scheduled and results collected in a unique user-defined service context.
The service workflow delivery process should allow logic to order multiple service contexts (service branch results) to create a service flow.
The service workflow delivery process should enable logical ordering of multiple service contexts (service branch results) to create a service.
A test mobile system (TEMS) is the Ascom network monitoring and real-time diagnostic suite. The following is a list of TEMS considerations for service flow provisioning in the workflow server 10.
TEMS should allow operators to provision new service workflows from a single GUI interface in an intuitive and user-friendly way.
The service workflow provisioning operator should be unaware of protocol level details. In the workflow provisioning flow, TEMS should present the user with various filterable attributes on each layer (4 to 7). The operator should be unaware of any protocol level details when selecting filtering criteria to define the workflow rules.
Context sensitive service workflow provisioning. TEMS should present the flow partitioning attributes in a context sensitive manner compared to other flow partitioning attributes provisioned on different protocol layers for the same service workflow.
The above means that if the phase 'n + 1' dividing the flow attributes depends on the phase 'n', only a valid set of attributes is displayed to the user for selection during service workflow provisioning.
A tabular display of all service workflows. TEMS should display all service workflows provisioned for each node (or each network) in a tabular form.
An existing service workflow is modified. TEMS should allow operators to modify existing workflows by letting them add, modify or delete any rules in existing service workflows. The operator should be informed of the impact of existing service workflow modifications.
Rules within the service workflow are ordered. TEMS should allow the operator to define or change the order in which different partitioning rules are to be executed or scheduled.
Relationships (AND/OR) between different rules in the service workflow are defined. TEMS should allow the operator to define the relation between any rule sets to either the AND operation OR the OR operation (without any input).
Relationships (AND/OR) between different rules in the service workflow are defined. TEMS should allow the operator to define the relationship with the operation or operations between any rule sets (without the need to enter anything).
Different service workflows are combined. TEMS should allow one or more existing service workflows to be combined to form a new service workflow.
History and auditing of service workflows. TEMS should present the operator with a complete audit trail of service workflow creation, modification or deletion.
Validation of a service workflow during its creation or modification. Validation rules are run on the nodes before service workflows are created or modified on the network element to ensure that new service workflows being provisioned do not conflict with any existing service workflows. In case of a failure of the authentication, the user should be presented with an appropriate error message. The newly created rules should be checked in or out of the workflow context to ensure there are no conflicts.
An analysis of the service workflow is collected. TEMS should allow the operator to enable/disable analysis of any service workflow. The attributes of the analysis collected for any service workflow should be predefined. The operator should be able to add, delete or modify default analysis templates for any service workflow.
Associated with a customer servicing the workflow. TEMS should allow operators to associate service workflows with end customers.
An operator should be able to define and configure workflows to handle different overload conditions. For example, in the case of overload, if the CPU usage on a particular card is greater than the high threshold tag, then the workflow server 10 will act as a pass-through for a particular type of traffic (HTTO, video). By configuring the workflow, the pass is enabled or disabled on the workflow server 10. The operator may configure the following rules:
type of video stream [ stream partitioning rule ]
i.ssm. CPU-use > CPU-high-threshold (e.g. 95%) [ overload condition 'state' ]
Delete NPU rules to forward packets to CSM card. This may enable the passage of any http video request [ action #1]
Non-service impact and service impact [ action #2 ].
No charging (pass case) and still maintaining charging information for the user [ action #3 ].
Type of video stream [ stream partitioning rule ]
i.ssm.cpu-use < { cpu-high-threshold-cpu-high-threshold of 5% (e.g. 95%) } [ overload condition 'state' ]
Add NPU rules to forward the packet to the CSM card, i.e. not pass [ action #1 ].
Non-service impact and service impact [ action #2 ].
No charging and still maintaining charging information for the user [ action #3 ].
The operator should be able to configure actions for load sharing use cases where the CPU threshold on a particular card is greater than the low threshold flag, but less than the high threshold flag. We want to inform operators (warning alerts) so they can plan/budget CSM capabilities on the workflow server 10. The operator may configure the following rules:
type of video stream [ stream partitioning rule ]
i.ssm.cpu-use < CPU-high-threshold (e.g. 95%) and ssm.cpu-use > CPU-low-threshold (e.g. 75%) [ overload condition 'state' ]
issue a warning alarm to TEMS and indicate to the operator that full CSM capacity is close to condition [ action #1 ].
if this happens multiple times within a configured time interval (e.g., 1 day), then the alarm condition may be promoted to the primary alarm condition [ action #2 ].
Type HTTP OR application type video stream partitioning rule
i.ssm.cpu-use < ═ 5% (e.g. 75%) of { cpu-low-threshold-cpu-low-threshold) } [ overload condition 'state' ]
Clearing the alarm condition [ action #1 ].
The user interface flow for provisioning a service workflow may be a three to four step process (all steps being initiated from the same Graphical User Interface (GUI) screen) where each step collects different information from the end user. The following describes the stages and the types of information collected at each stage.
(step-1) stream partitioning
a. The user is presented with a screen with an option drop-down menu item indicating selection of the layer 4 to layer 7 flow division. According to the selected layer, attributes specific to that layer are displayed with checkboxes that allow the user to select the attributes they want for stream partitioning. For example: url, gtp.tid, ip.proto, udp.port, dns.url, etc.
Stream partitioning rule example
HTTP.URL=http://www.nytimes.com
Referer begins with http:// www.nytimes.com
Dns, queryname ends with nytimes
URL contains nytimes
IP.TotLen<1000
IP.TotLen>1000
Com. dns. queryname does not end with nytimes
(step-2) flow scheduling
a. The next screen presents to the end user a set of predefined 'services' to which the results of the stream partitioning should be scheduled. The list of services may include, but is not limited to, analysis like cell phone latency, firewalls like 'gatekeeper', content filters, CALEA filters, video or MSISDN services.
An example of a charging transaction may be configured as follows:
url ends at MP3 and http state RESP OK (indicating MP3 file was downloaded).
The actions described above may be defined as:
discarding packets
Send packets with value to the service (should be able to include things like a charge value, i.e. http
Redirect to URL (it should be possible to dynamically build URL from stream partitioning.
(step-3) stream transport
a. The next screen presents to the user the order in which the streams he/she wants to be scheduled are applied.
(step-4) workflow analysis
a. Based on the type of service workflow, the screen may present to the end user a predefined set of analysis parameters that may be collected for a particular workflow, or the screen may present a dynamic list of parameters that the user may select to collect as part of the service workflow analysis.
As shown in fig. 5, the workflow process 100 includes receiving (102) an information packet at an input to a wireless communication device.
The workflow process 100 employs 104 a processor executing computer-executable instructions stored in a computer-readable storage medium to perform 106 various functions.
The functions (106) include accessing (108) a workflow module including rules for processing different types of information packets, using the rules of the workflow module to determine (110) which of the optional communication function modules is required to process the received information packet, and using at least one of the optional communication function modules to process (112) the received packet.
The workflow process 100 may include performing (114) deep packet inspection on the received information packet before determining which optional communication function module is needed to process the received information packet.
Processing (112) the received packet may include coordinating optional communication function modules using a workflow module. All information flows through the workflow module to the alternative communication function modules and no information flows directly between the alternative communication function modules.
Embodiments of the invention may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Embodiments of the invention may 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.
Method steps of embodiments of the invention may 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).
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, such as 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.
The foregoing description is not intended to be an exhaustive list of all possible implementations or all possible variations of the described implementations consistent with the present disclosure. 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 herein. For example, different forms of the flows shown above may be used, with steps reordered, added, or deleted. Accordingly, other implementations are within the scope of the following claims.
Claims (23)
1. A wireless communication system, comprising:
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 a component comprising:
a workflow module comprising a set of workflow instructions for processing different types of information packets; and
optional communication function modules, the workflow module coordinating processing of the received packets using selected ones of the optional communication function modules.
2. The system of claim 1, wherein the workflow instruction set can be modified.
3. The system of claim 1, wherein the component further comprises a deep packet inspection module to inspect the received packet and provide information about the packet to the workflow module.
4. The system of claim 1, wherein the component further comprises a user module for inspecting the received packet and providing at least one user attribute to the workflow module.
5. The system of claim 1, wherein the component further comprises a network module for inspecting the received packet and providing at least one network protocol attribute to the workflow module.
6. The system of claim 1, wherein the selectable communication function modules comprise a content filtering module.
7. The system of claim 1, wherein the selectable communication function modules comprise a hypertext transfer protocol (HTTP) proxy module.
8. The system of claim 1, wherein the selectable communication function modules include a video caching module.
9. The system of claim 1, wherein the selectable communication function modules comprise a video transcoding module.
10. The system of claim 1, wherein the selectable communication function modules comprise an analysis module.
11. The system of claim 1, wherein the selectable communication function modules comprise a firewall module.
12. The system of claim 1, wherein the selectable communication function modules comprise a fee calculator.
13. The system of claim 1, wherein the selectable communication function modules comprise a policy enforcement module.
14. The system of claim 1, wherein rules for handling different types of information packets are configurable by an operator.
15. The system of claim 1, wherein the information packets contain information types selected from the group consisting of text, audio, video, multimedia, user information, mobile television, protocol information, and the internet.
16. The system of claim 1, wherein an operator can add additional functional modules to the selectable communication functional modules.
17. A method, comprising:
receiving, in a wireless network, an information packet at an input to a wireless communication device; and
employing a processor executing computer executable instructions stored in 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 optional communication function module 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.
18. The method of claim 17, further comprising performing deep packet inspection on the received information packet prior to determining which of the optional communication function modules is needed to process the received information packet.
19. The method of claim 17, wherein the processing the received packet further comprises coordinating the selectable communication function modules using the workflow module.
20. The method of claim 19, wherein all information flows through the workflow module to the selectable communication function modules and no information flows directly between the selectable communication function modules.
21. A device for wireless communication, comprising:
a network interface to receive an information packet from a first network entity; and
a computing platform to process the received packet, the computing platform comprising:
a workflow module; and
optional communication function modules, the workflow module coordinating processing of the received packets using selected ones of the optional communication function modules, the network interface further sending the processed information packets to a second network entity.
22. The apparatus of claim 21, wherein the computing platform further comprises a deep packet inspection module to inspect the received packet and provide information about the packet to the workflow module.
23. A wireless communications apparatus for establishing communication between a first network entity and a second network entity, the apparatus comprising:
a network interface to receive an information packet 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 a component comprising:
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
an optional communication function module comprising:
a content filtering module;
an HTTP proxy module;
a video cache module;
a video transcoding module;
an analysis module;
a firewall module;
a charging module;
a policy enforcement module;
a flow direction module; and
a latency service module;
the workflow module coordinates processing of the received packets using selected ones of the selectable communication function modules, and the network interface further sends the processed information packets to a second network entity, thereby establishing communication between the first and second network entities.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US61/405,734 | 2010-10-22 |
Publications (2)
Publication Number | Publication Date |
---|---|
HK1190215A true HK1190215A (en) | 2014-06-27 |
HK1190215B HK1190215B (en) | 2017-10-27 |
Family
ID=
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103348335B (en) | Aggregate multiple functions into a single platform | |
EP3148118B1 (en) | Providing application metadata using export protocols in computer networks | |
US10361969B2 (en) | System and method for managing chained services in a network environment | |
US9210122B2 (en) | System and method for inspecting domain name system flows in a network environment | |
KR101234326B1 (en) | Distributed traffic analysis | |
US7881215B1 (en) | Stateful and stateless data processing | |
US8117335B2 (en) | Service or application driven processing of network traffic using a smart router | |
US8295198B2 (en) | Method for configuring ACLs on network device based on flow information | |
US20150372904A1 (en) | Predictive traffic steering over software defined networks | |
CN104519121A (en) | Session-aware service chaining within computer networks | |
KR20170023179A (en) | Policy and charging control method and apparatus for an application service chain based on an sdn network | |
Amadeo et al. | SDN-managed provisioning of named computing services in edge infrastructures | |
CN103718508A (en) | Advanced determination, processing and control in communication networks | |
US20120324099A1 (en) | Content delivery control methods, apparatuses and computer programs | |
Kamoun et al. | Improvement of MQTT semantic to minimize data flow in IoT platforms based on distributed brokers | |
Nakao et al. | Application-specific slicing for MVNO and traffic characterization | |
HK1190215A (en) | Aggregating multiple functions into a single platform | |
HK1190215B (en) | Aggregating multiple functions into a single platform | |
HK1231645B (en) | Aggregating multiple functions into a single platform | |
Houssos et al. | Generic adaptation mechanism for the support of context-aware service provision in 3G networks | |
Gazis et al. | Intelligent network provisioning for dynamically downloadable applications in beyond 3G mobile networks |