KR20040036688A - Platform and method for providing wireless data services - Google Patents

Abstract

Access the mobile terminal via a mobile network 132 of the wireless telephone network 120 and a data network, such as the Internet 140, using a method of handling a packet-based data communication session between a user and one or more data services. Create and provide data services to monitor and control packet based data sessions between possible service providers 150. For any particular mobile terminal, multiple service conversations that can overlap in time can be handled during the period in which the mobile terminal maintains data communication with the system. In one aspect, the method features providing a service on a node comprising configuring a detection point for the service. The node handles the communication. The processing step includes monitoring the communication to confirm a match with the configured detection point. When matching with the configured detection point is confirmed, the service logic of the service is notified to the detection point.

Description

How to Provide Platform and Wireless Data Services {PLATFORM AND METHOD FOR PROVIDING WIRELESS DATA SERVICES}

First generation wireless telephone networks, such as the Analog Mobile Phone Service (AMPS), used analog wireless communication technology to provide mobile communications that enable mobile phone users to connect to analog service providers such as voice services. These systems did not directly support data communication over wireless networks between mobile phones and other computers or devices.

Most wireless systems today are digital and are based on many different wireless communication technologies and system architectures, including Global System for Mobile Communication (GSM), Time Division Multiple Access (TDMA), and Code Division Multiple Access (CDMA). These digital systems are generally referred to as second generation (2G) systems. In general, these 2G systems use a digital circuit switched connection to provide a mobile service in which a mobile terminal (eg, a mobile phone) is connected to a particular recipient. The most common services provided on the wireless network are voice services such as land to mobile, mobile to land and mobile to mobile calls. The voice signal for the call is digitally encoded during wireless communication between the mobile terminal and the fixed mobile network. In fixed mobile networks, encoded voice traffic is handled and exchanged on separate circuit bases, for example, traffic is exchanged with other mobile terminals, public switched telephone networks (PSTNs), or other public land mobile networks (PLMNs) on the same wireless network. do.

Support for data services in these second generation wireless networks is somewhat limited. One type of data service in these systems is a short message service that can transfer short datagrams up to 256 bytes in length in one direction to the mobile phone. Some 2G systems, such as GSM, can also send SMS messages in both directions. However, the SMS is designed to send an independent message that can tolerate a moderate delivery delay through the network.

Another type of data service in a 2G system is a circuit-switched data (CSD) service that forms a data circuit between a mobile terminal (eg, a mobile phone of an associated computer via a mobile phone) and a particular receiver. . While the mobile terminal is connected, it dedicates one or more channels of the type used to support the encoded voice traffic. The total capacity of these channels is allocated to the user, and the user is typically advertised according to the "call" period. For example, the mobile terminal can be connected to a gateway to a data network such as the Internet, and a data channel of constant speed is formed and maintained between the mobile terminal and the gateway. Thus, CSDs are not particularly effective at communicating over packet switched data networks where traffic is “congested” (ie, very high variable data rates) because much of the data channel capacity is not used. For example, "web browsing" from a mobile terminal to a server on the Internet results in congestion of data channel usage.

In order to enable the second generation network to more optimally provide a bearer service for packet switched data communication between a mobile terminal and a fixed network, an upgrade technique such as a general packet radio system (GPRS) has been developed. GPRS allows GSM systems to handle packet switched data more effectively. GPRS is more effective in part by not maintaining the entire channel for a particular mobile terminal. In a GPRS-type system, various nodes are added within the standard mobile network structure. The Packet Control Unit (PCU) is used to provide a packet data exchange interface to the wireless interface of the network. One or more Serving GPRS Support Nodes (SGSN) and Gateway GPRS Support Nodes (GGSN) are also added to provide the data path from the PCU to the external network. Other GPRS related nodes may also be added, but these are generally the minimum requirements to run on the second generation network. The GPRS enable network still handles voice services using circuit switched methods. However, an important characteristic of GPRS for data communication is that, unlike CSD, GPRS is specifically designed to transmit packet switched data. Because of this feature, multiple users can share the radio and fixed bearer resources of the network even if they are in the same service radio cell. This significantly increases resource efficiency and improves network utilization. GPRS depends on the radio link state and requires specific compatibility for this mode by both the network air interface and the mobile terminal, but can theoretically provide user application speeds up to 115 kB per second. Because data bearer services depend on packet-switched data from mobile terminals transmitted over the network, multiplexing on the bearer service is facilitated so that multiple application data streams can be delivered between the mobile terminal and different points inside and outside the wireless network. can do. For example, a user can simultaneously browse the web, check email, launch a videophone session, and download files.

The present invention relates to a method for providing a data service in a data communication system.

1 is a diagram of a wireless system that provides data services to a user number of a mobile station.

2 is a system architecture diagram of the wireless communication system shown in FIG. 1 in a GSM / GPRS environment.

3 is a diagram of a logical structure of a mobile switching services platform (MSSP).

4 is a diagram of a Service Control Layer structure of an MSSP.

5 is a diagram illustrating the use of detection points of a TCP flow.

6 is a diagram of the physical structure of an MSSP.

7 is a block diagram of an input / output module and a service module of the MSSP.

8 is a flowchart of a sponsor data service.

9 is a flowchart of an exchangeable data service.

This application is incorporated by reference in US Provisional Application No. 60 / 292,564 filed May 22, 2001, entitled "Method for Sponsored Packet Switched Data Services on a Wireless Network," and May 25, 2001, entitled "Method for Transaction Based." Priority claims the advantages of US Provisional Application No. 60 / 293,756, filed "Packet Switched Data Service on a Wireless Network", all of which are incorporated herein by reference.

Current GPRS systems offer limited options in the provision, management, pricing and advertising of mobile phone users' use of data services. For example, SGSN and GGSN can create a call detail record (CDR) for the entire period of time that data is connected to the mobile terminal. Advertisements based on these CDRs are generally based on the duration of the connection, the amount of data sent and received with the mobile terminal, or a flat fee.

In a general aspect, the present invention provides a mechanism for handling packetized data communication sessions between a user and one or more services. The mechanism can apply to the creation, provision, and use of data services to monitor and control packetized data sessions between mobile terminals of wireless telephone networks and content providers accessible to these mobile terminals via data networks, for example, the Internet. do. For any particular mobile terminal, multiple service conversations that may overlap in time may be handled during the period in which the mobile terminal maintains data communication with the system.

The handling of data communications can be characterized by one or more of monitoring for calculations and advertisements, controlling access to services, and switching access to services.

Monitoring of sessions for calculations and advertisements may include various different advertising models including advertisements and hourly calculations used, amount of data transferred, and the number and type of transactions executed, to one or more parties determined by the nature of each communication session. Provide support for

Access to the service may be controlled according to various service related criteria, for example user related information. One example of controlling access is a prepaid data service in which access is controlled such that a user cannot exceed the prepayment amount.

Redirecting access to a service includes directing the attempted access to the "virtual service" to the actual service. This type of redirection is analogous to directing a call to a free ("800") phone number indicated by the telephone number network to the actual phone number.

The handling of a data communication session may be characterized by passing information about the session to an external system and receiving instructions from the external system that are used to determine how to further handle the session. For example, when redirecting to a "virtual service", the external system may be required to provide an indication of the user's attempt to access the virtual service, which then identifies the actual service to which the user is directed. Send a response.

The handling of the data communication session may be characterized by monitoring the session using a state machine that establishes a model for the session. Preconfigured or configurable states or state exchanges of the model are associated with the events of the monitored session according to the state machine. The detection of these states or state exchanges determines how the session is handled.

In one aspect, the invention generally relates to a method of processing data communication through a node of a data network. The method includes providing a service on a node comprising configuring a detection point for the service. Communication through the node is handled by the node. The processing step includes the step of monitoring the communication to confirm the match with the configured detection point. When confirming the match with the configured detection point, the service logic for the service is notified to the detection point.

Aspects of the invention may include one or more of the following characteristics:

The processed data communication includes communication from a wireless network, such as a second generation wireless telephone network, or a third generation wireless telephone network.

The processed data communication includes communication from a GPRS enabled wireless network.

The processed data communication includes communication from a wireless local area network (WLAN).

Providing a service includes receiving a specification for configuring a detection point.

Providing a service includes receiving service configuration information from a server outside the node, for example, to provide an application running outside the node.

Data communication includes packet data communication. For example, packet data communication includes Internet Protocol (IP) data communication.

Configuring the detection point includes specifying a characteristic at one or more protocol layers, such as a network layer, transport layer, or application layer.

Specifying an attribute at the transport layer includes specifying an attribute related to a transport control protocol (TCP).

Specifying a property at the application layer includes specifying a property of a Hyper Text Transport Protocol (HTTP), a RADIUS application protocol, or a Domain Name Service (DNS) protocol.

Specifying a characteristic at one or more protocol layers includes specifying a characteristic at a plurality of protocol layers.

Specifying a characteristic in one or more protocol layers includes specifying a regulatory expression that identifies a data packet field in one or more protocol layers.

The method includes processing communication according to service logic when a match with a detection point is confirmed.

When a match with the detection point is confirmed, the communication associated with the matched detection point is stopped.

Further processing the communication includes receiving a specification for an event detection point from service logic, configuring an event detection point, and monitoring the communication to confirm conformity with the configured event detection point. do.

Processing the communication further includes diverting the communication.

Further processing the communication includes sending the communication over a communication tunnel to a destination associated with the service.

Processing the communication further includes filtering the communication.

Filtering includes blocking the data packet according to an address identified within the packet.

Processing the communication further includes applying the policy to the communication.

Applying the policy to the communication includes applying a data rate policy.

Providing the service includes identifying an accumulated characteristic for the service conversation. Processing the communication passing through the node further includes detecting a service conversation of the data communication associated with each service and recording accumulated information about the detected service conversation.

Recording the accumulated information for the detected service conversation includes recording the amount of data transmitted in the service conversation.

Recording the amount of data transmitted includes recording the number of packets.

Recording the amount of data transmitted includes recording a number proportional to the number of bytes.

Recording the amount of data transmitted includes recording the amount of data that has passed through the node in one direction.

Recording the accumulation information for the detected service conversation includes recording the data rate transmitted during the service conversation.

In another aspect, the present invention relates to a method of processing data communication through a node of a data network. The method includes processing a communication session of data communication through the node, including monitoring data packets for the communication session to confirm conformity with the configured detection point. When a match with the configured detection point of one of the communication sessions is confirmed, a request to confirm the detection point is sent to the external service logic. The communication session is further processed according to the information received from the service logic in response to the transmitted request.

In another aspect, in general, the present invention includes accumulating a service provided on data passing through a node of a data network. The method includes providing a service. The providing step includes identifying characteristics of the communication for the service conversation. Service conversations are detected in data communications each associated with a particular user of the service. Next, the detected service conversation related information is provided.

In yet another aspect, the present invention generally relates to a method for processing packet data communication between a mobile station on a wireless telephone network and a content provider on a fixed network. The method includes providing a service on a node that associates a wireless network with a fixed network, including configuring service logic for the service. Packet data communication through the node between the radiotelephone network and the fixed network is handled at the node. The processing step includes monitoring the communication to confirm a communication session associated with the provided service. The detection point is matched in the confirmed communication session, and service logic is executed in response to the match of the detection point.

Executing service logic may include communicating with an external service platform, and processing packet data communication includes processing a communication in accordance with information received from the external service platform.

In another aspect, the invention generally relates to a communication node. The node includes a service management program configured to receive provisioning information about the service. The node also includes a database associated with a service management program and including a storage device for storing the received provision information. The node includes circuitry for passing packet data communication through the node and detecting configurable events in the data communication. The service execution engine is programmed to communicate with the service management program and to receive notification of the detected event for the circuit passing the data.

The database may further include a storage device for detailed recording, and the service execution engine is further programmed to generate a detailed recording in response to the received notification.

The present invention can provide one or more of the following advantages.

Detailed calculation and pricing models can be implemented using the above configuration. For example, while in data communication with a wireless network with a mobile phone, some of the data communication may be billed to the user, some to the service provider of the free data service, and some to the sponsor of the data service, which is the employer of the user. have. This detailed fee is not used by today's wireless data network operators because of the relatively crude granularity provided by the existing detailed records.

By separating event and trigger detection from fairly complex service logic, the service logic can be modified without any change in hardware configuration. The method provides a number of advantages that can be seen in an Intelligent Network (IN) based telephone network where the switching system is separate from the control logic residing in the Service Control Point (SCP). In an IN-based telephone network, by enabling an appropriate detection point of a call flow, a new service can be implemented without changing the switching system. By using a mechanism for data services, similar separation is achieved by monitoring data packet communications according to a finite state model and enabling the detection points of the model to support external service logic.

The method is naturally not limited to handling data communication between a wireless telephone network and an external fixed network. Fine control and monitoring of packet data is applicable to other environments. For example, the method is applicable to handling packet communications between wired networks or over wireless local area networks.

Other features and advantages of the invention will be apparent from the following detailed description and claims.

Referring to FIG. 1, in the wireless communication system 100, a mobile data-exchange center is provided between a plurality of mobile stations (MS) 132 such as wireless cellular phones and a plurality of content providers 150 such as a web server. Data communication is performed by a mobile data-switching center (MDSC) 110. Mobile terminal 132 is manipulated by mobile user 130 and communicates with a transceiver base station (BTS) 122 via a wireless link. BTS 122 is associated with MDSC 110 via mobile network 120, which provides a fixed network communication infrastructure that communicates between MDSC 110 and MS 132. MDSC 110 is also coupled to content provider 150 via a data network, herein the public Internet 140.

The wireless communication system 100 also supports voice communication between the MS 132 and the telephone network, ie, public switched telephone network (PSTN / SS7), controlled by the signaling scheme 7 (SS7) infrastructure. Mobile switching center (MSC) 180 is coupled between mobile network 120 and PSTN / SS7 190.

Mobile Data Exchange Center (MSDC) 110 further enhances the processing of mobile data communication sessions between MS 132 and content provider 150. One type of processing relates to the monitoring of sessions for advertisements.

One aspect of such monitoring relates to the tracking and processing of individual sessions that occur during data communication by the MS 132 over the Internet 140. For example, MS 132 may establish data communication over mobile network 120 for a period of time. The MS 132 is assigned an Internet Protocol (IP) address to use for a period of time in data communication over the mobile network 120 and communicates with other devices via the Internet 140 in the same manner as a fixed computer associated with the Internet. Can be. Thus, MS 132 may establish multiple communication sessions with different content providers 150, which may overlap in time. Examples of content providers include content servers, such as today's Web servers that provide content using Hyper Text Transport Protocol (HTTP) or mail servers that provide mail messages using Post Office Protocol (POP).

MDSC 110 executes a service model for data conversations between MS 132 and content provider 150. In summary, "service" refers to delivering content or functionality to user 130 in a manner that provides a value to the user. A particular service defines a conversation with a user having a start, a middle, and an end, respectively, and is typically associated with a particular content provider 150.

The operator 135 provides a number of different types of services on the MDSC 110. The system may include a number of Mobile Virtual Network Operators (MVNOs) as well as operators 135 of the physical wireless network. For example, different services may be associated with different content providers 150. The service typically determines the advertisement information that is captured by the user 130 to generate a detailed record of the service usage. The definition of a service may also provide a regulatory information class that may be applied to a user or group of users to inhibit a particular service or characteristic associated with a given service. MDSC 110 optionally collects execution and usage fees that may be provided to operator 135. MDSC 110 creates a Service Detail Record (SDR) to provide a partial or complete summary of service conversations that are also provided to operator 130. One use of the operator 130 with SDR is for advertising. In general, a single SDR is written to summarize the service conversation of a particular user, although a partial record may be generated for a resource intensive service conversation so that at least the partial advertisement record is reliably available in the event of a complete system failure. Multiple SDRs may also occur when service conversation costs are split between multiple parties, for example between advertisers, subscribers, and sponsors.

As part of the service definition provided by the operator 130 on the MDSC 110, the initial detection point specifies the start of a conversation with the service user 130. The MDSC 110 monitors and controls a variety of different types of data packets at various protocol layers, depending on which state machines are each capable of responding to a particular type of packet. Within each state machine is a specific strategic location where important information is available or where major control decisions can be made. These positions are called detection points. The service definition identifies the specific detection point as the initial detection point for the service. When MDSC 110 identifies the initial detection point in the data flowing through it, the service logic of the associated service is executed. Service logic generally establishes a dialogue between the service and the user in order to continue the conversation. During the service conversation, the service logic may register additional detection points with various state machines to obtain real time access to the packet data and influence the control decisions made by the state machine.

MDSC 110 examines all data packets passing between MS 132 and Internet 110. Between detection point generations for an application, data passes through the MDSC 110 without interference of service logic. Thus, most packets are examined and passed through MDSC 110 without further delay due to the inspection. Some packets, such as those associated with the start or end of a communication session, may require further processing and may be intercepted and delayed until acted upon by the service logic executed on the MDSC or external service platform associated with the MDSC.

MDSC 110 handles data communication at various layers of the protocol stack. For example, MDSC 110 processes sessions in higher layer protocols such as HTTP, as well as IP, UDP, TCP or other protocols. In addition, MDSC 110 processes a "sub" session that user 130 understands as a "session". For example, when a user accesses a Hyper Text Markup Language (HTML) document on a web server, data may be sent to the user from a number of different content providers. For example, a separate "sub" session may be established between the MS 132 and the advertiser 160 such that the content the user is searching for may be provided from the content provider while the advertising content is delivered from the advertiser. In general, MDSC 11 processes session data of any layer 2 (data link layer) via layer 7 (application layer) of the standard ISO protocol stack.

In accordance with the monitoring of communication data passing through the MDSC 110, the MDSC 110 sends various types of detailed records to the operator 130 of the wireless system generally in real time (i.e. with little delay as opposed to periodic batch processing). send. Different advertising policies apply to communication sessions depending on the services to be executed by the user. The differences in policy include the advertising basis, for example, the duration of the session, the amount of data transmitted during the session, or the number or type of transactions with the content provider executed during the session. Another difference includes the session payer, which may include one or more of the user 132, the content provider 150, or the advertiser 160 in communication with the user. The payer may also include session sponsor 170, which may not communicate directly with the user. An example of a sponsor is the employer of the user.

In addition to monitoring communication data for advertisements, MDSC 110 also monitors communication data for control. An example of control of a communication session is access control that includes determining whether a user is allowed to establish a particular session. For example, access control may depend on a user subscribing to a service that the user attempts to connect to. In addition, access control may depend on a prepaid model in which a user can access the service if the balance of the account is sufficient. Other types of access control may depend on the user providing credentials (eg, a password) or payment agreement for the service to access. The MDSC may communicate with the operator 130 to determine whether the user is allowed to establish a session.

Another type of communication session control involves switching. The user may attempt to establish a communication session with the service, and upon monitoring the attempt, the MDSC 110 switches communication to a specific content provider 150. The transition can include diverting a request to establish a communication session with one content provider and another content provider 150. The transition can also include diverting a communication request between the "virtual" service and the actual content provider 150. For example, a service may be identified by a name such as "Flower" and MDSC 110 redirects the request to a content provider that provides online orders of flowers. The conversion property is configurable. The conversion may depend on the specific characteristics of the user attempting to establish the session, such as whether or not they have subscribed to a "bouquet" service. In addition, the switching may depend on the characteristics of the mobile station 132 used by the user, such as the geographic location of the MS, or the performance of the MS device.

These types of transitions share many of the characteristics of diverting intelligent telephone (IN) phone calls. For example, when a user dials an invalid call telephone number, i.e., 1-800-FLOWERS (1-800-356-9377), the call is detected by a telephone switch. The external platform, in particular in SCP, receives the detected free telephone number notification and determines the actual telephone number to which the call is made. In the data service approach described above, the MSSP may require the external platform to determine where the virtual data service is designated.

With reference to FIG. 2, in one aspect of the wireless system 100, the functionality of the system shown in FIG. 1 is implemented in a GSM-type system in which data communication is provided according to a General Packet Radio Service (GPRS) approach. In this example, an additional network element, Mobile Service Translation Processor (MSSP) 260, is inserted into the standard GSM / GPRS configuration of the communication path between mobile network 120 and the Internet 140. In general, MSSP 260 executes session monitoring and control functions as described above.

In the system of the above aspect, Gateway GPRS Support Node (GGSN) 250 provides a gateway for communication between the MS 132 and an external network such as the Internet 140. Within the mobile network 120, a base station controller (BSC) 222, which forms a base station system (BSS) 220 with one or more BT 122 connected, is responsible for wireless communication with one or more MSs 132. Provide a fixed terminal. As the MS 132 moves, the MS can communicate with a number of different BSSs 222 even when in voice or data communication with the system, and the system maintains communication with the MS by managing the mobility according to standard techniques. .

Voice and data communications from the MS 132 are split in a packet control unit (PCU), not shown, of the BSC 222. Voice communication passes through the MSC 180 while data communication passes through the SGSN 230. MSC 180 sets up the voice circuit over PSTN 290 using control communication over SS7 network 292. Control of these voice circuits may include supporting prepaid voice services serviced over the SS7 network to determine whether MSC 180 access is in the right balance for the call with the user.

The MSC 180 communicates with a number of servers when providing voice communication services. These include a prepaid server 212, a home location register (HLR) 214, a visitor location register (VLR) 216, and a location server 218.

Data communication passes between the BSC 222 and the SGGN 230. In general, SGSN 230 supports multiple BSSs 220, and each BSS 220 is connected to one SGSN 230. Each SGSN 230 communicates with the GGSN 250 via a common GPRS Backbone Network (GBN) 240 where a private data network that associates the SGSN with the GGSN nodes.

If the user wants to establish data communication from the MS 132, the user initiates and attaches the request sent by the MS 132 to the data network. The request is received by the BSS 220 and then sent to SGSN 230. SGSN 230 receives the MS identification, typically the International Mobile Subscriber Identity (IMSI), and authenticates the user. The MS requires the SGSN to write Packet Data Protocol (PDP) content indicating that it needs an Internet Protocol address or needs a dynamically assigned address. SGSN sends the request to GGSN, which creates a data communication link and acts as a gateway for communication between the MS and the external network. The MS may require a connection with a particular network. In the above example, the MS is considered to require a connection with the public internet. After the PDP content is set, the MS has a virtual link between this virtual link and the GGSN that provides gateway functionality to the external network.

During the establishment of the PDP context, GGSN 250 communicates with an authentication server 275, such as a RADIUS server. MSSP 260 detects and monitors the interchange with the authentication server. Using the monitored information, MSSP 260 determines the mapping between the identity of MS 132 and the IP address used by the user for communication over the Internet. In another embodiment, that is, if authentication is not performed using communication passing through the MSSP, the MSSP 260 obtains a mapping of external information over the SS7 network 292. For example, MSSP 260 may communicate over an SS7 network to obtain information from servers 212-218 used by MSC 180.

Both SGSN 230 and GGSN 250 relate to the MS 130 PDP context passing through the charging gateway 272 to perform some processing and matching of the CDRs and to send charging information to the charging node 270. Create a call detail record (CDR). In general, SGSN 230 collects information about the wireless portion of the virtual data link between MS 132 and GGSN 250. For example, SGSN collects the total connection duration and the amount of data sent and received by the MS. In general, GGSN 250 collects information about the external network portion of the communication, including the connected network (eg, the Internet), the duration of the PDP context, and the amount of data transmitted and received with the external network.

After the MS 132 establishes a virtual data link with the GGSN 250, the MS 132 may initiate communication with the Internet 140. For example, MS 260 may first attempt a connection with a domain name server (DNS), a computer on the Internet 140 that translates a textual host name into a numeric address. MSSP 260 detects the response as well as the initial translation request.

MSSP 260 monitors all communication between each MS 132 and a host on the Internet 140. MSSP 260 identifies the source MS of each packet according to the source IP address. While monitoring the communication, MSSP 260 generates a number of detailed records that are sent to billing node 270. By translating the user IP address into IMSI, these detailed records directly identify the IMSI, MSDN, or both of the user without the need for further translation.

When the MSSP 260 detects a particular point in the communication session between the MS 132 and a destination on the Internet, it generates a detailed record that is sent to the charging node 270. The point, i.e., the "detection point" may include, for example, the initialization or termination of an IP flow to a specific content provider. In addition, as discussed above, MSSP 260 also controls the IP flow and associated protocol state machine. MSSP 260 communicates with management and service platform 280, which is a separate computer associated with the MSSP. These service platforms execute service logic that determines how events in the IP flow detected by the MSSP are handled. One or more of these platforms are co-located with the MSSP and can operate as a system forming MDSC 110 as shown in FIG. 1. MSSP 260 may also communicate with external service platform 282 via, for example, a data network. For example, the external service platform 282 may be manipulated by the content provider 150 or the virtual operator.

MSSP 260 may be configured to determine when to generate a detailed record and when to block an IP flow hold indication from service platform 280. The configuration can be supplied statically. In addition, the configuration may dynamically form or update a user entering the area by the MSSP, for example, while processing a communication session or in response to external events. The MSSP can optionally obtain this information through a link with a location server.

Referring to FIG. 3, MSSP 260 is technically divided into three different layers. The hardware layer 310 processes the packets passing between the mobile network 110 and the Internet 140 at high speed. Certain packets are identified as requiring further handling at the hardware layer, and they are handled by a Service Transport Layer (STL) 320, possibly a Service Control Layer (SLC) 330. When the hardware layer 310 does not process the packet, it buffers the packet to send information about the packet (typically not the packet itself) to the STL 320 and sends a response from the STL before further processing the packet. Wait

The hardware layer 310 implements an interface with the STL 320 as well as a physical data communication interface with an external network such as the mobile network 110 and the Internet 140. The hardware layer also provides the ability to set trigger or event notifications depending on the IP flow characteristics that the hardware layer detects from the upper layers of the configuration without the need for software. The hardware layer 310 is designed to support the quality of service provision for each user and application. In addition to trigger and event processing, the hardware layer performs deep packet processing to analyze data on the fly in real time. The virtual output queuing system in the hardware layer allows fine control that can be used for traffic shaping or polishing of IP flows. The hardware layer also provides SS7 connectivity.

The STL 320 not only manages hardware resources used to route packet traffic between input and output ports of the MSSP, but can also manipulate various hardware registers that control data flow and the setting of triggers and detection events. The STL 320 directly processes the information received from the hardware layer and informs the hardware layer how to process the packet, or sends information about the packet to the third layer, the SLC layer 330.

STL 320 may process requests generated in subscriber session related SCL 330 and detection point notification requests. STL 320 also executes the IP routing engine used to route packets onto the IP network. STL 320 detects the session event and notifies the SCL. STL controls hardware layer 310, thereby determining how packet flows are handled. The STL may manage hardware registers used to have both trigger and event detection points and register event notifications.

STL 330 provides an interface with management and service platform 280, and executes service logic associated with interim services and interfaces with STL 320 to control hardware layer processing of data passing through MSSP 260. do. The SCL executes the interface logic and state machine required to run each APL. The application is registered with the API to set the detection point, monitor connection status, and root service request. The SCL layer identifies the API request and translates it into an STL request to enable detection points and event monitoring.

STL 320 handles different communication IP conversations, such as user sessions (ie, PDP contexts) and TCP sessions, within the entire user session. STL 330 processes and inspects subscriber data packets and executes various types of flow and detection points. STL 320 supports address translation, packet filters, tunnel flows, and control flows. In addition, the STL calculates the transmitted and received bytes included in the packet as well as any predetermined flow. STL executes detection points on the flow. The detection point may depend on the individual flow type and may depend on the pattern determined using the protocol layers 2 to 7. The STL provides the ability to set the detection point according to the threshold on the counter value, and sets the detection point so that, for example, every 10 kB of data is transmitted.

STL 320 may define an IP address / port number for each set of session groups. This capability can be used by the SCL to configure packet-filtering services and network-based firewalls.

STL 320 may also send packet meeting criteria to a preconfigured tunnel. The criteria depends on the IP header and transport layer header characteristics. These flows can be used by the SCL to configure VPN performance.

SCL 330 supports various external MSSP interfaces, such as interface with service platform 280. SLC 330 also implements the interface logic and state machines used to execute each APL. The SCL can, for example, communicate over an SS7 network to obtain information about the subscriber. An application running on the service platform registers with the API to set the detection point, monitor connection status, and root service request. SCL 330 may identify API requests from applications, translate them into STL requests, and pass them to STL 320 as needed to request and notify detection points and event monitoring. SCL 330 may also embed an MSSP configuration database and an IP Detail Record (IPDR) database. SCL 330 provides an interface with an external network management system for provision and error management. The SCL collects data per service request from the STL 320, external applications running on the service platform 280, and API state machines to generate IPDRs for charging or service request strategies sent to the billing node.

Referring to FIG. 4, the SCL 330 includes a service management and monitoring related module and a prepared service logic execution related module.

The SCL may contain a configuration database 432 and a detailed record database 434. SCL is also interfaced with an external network management system for preparation and error management. The SCL collects data for every service request from the STL, external applications, and API state machines to generate a detail record (DR) for the charging or service request strategy.

The service management program 420 may not only manage various services related to functions, but also may be interfaced to the core to execute management functions. An Operations Administration Maintenance and Provisioning (OAM & P) server 410, including a staging server, a network management server, a billing server, and a reporting server, interfaces between the operator system and the service management program 420. The OAM & P server 410 not only disconnects the service management program from external customers but also provides a structure necessary for preferential access to management resources.

One characteristic of the service management program 420 is to respond to requests from the preparation application to form and prepare a particular service. The service management program 420 forms a service and stores the service related information in the configuration database 432. The service management program 420 communicates with the SCL core 450 to be serviceable so that a user session for that service is handled by the MSSP.

As part of the preparation process, the operator may also identify one or more subscriber groups associated with the service. Subscriber groups can be used to group users by authority or speed plan. A subscriber group can organize one or more users sharing common property for billing or network access. The user configures an individual subscriber having a session with a packet translation network having one or more active flows. Subsequent subsections examine each of these concepts in more detail. The subscriber does not need to be prepared separately for the MSSP.

The service management program 420 communicates with the SCL core 450, which generally controls the real-time aspects of monitoring and controlling service conversations. SCL core 450 is the central runtime component of the SCL software configuration. The SCL core provides an event base execution environment in which the order of pending messages is serviced. The SCL core uses a script to act as a sequencer for message processing. The script acts as a list of currencies linked with the compiled code and not only has desirable performance characteristics, but also maintains a great deal of flexibility with respect to specific system logic. Some messages processed by the SCL core are associated with detected points detected in the data flowing through the MSSP. In processing a message, the SCL core 450 executes a script associated with the message. Typically, script execution stops when it asks the remote server, and requires a response and confirmation. The aborted script is run again when the remote server that originally blocked the script provides a response and confirmation. Other messages that were aborted are handled by the script.

SCL core 450 uses STL server 460 as an interface with STL 320 and API server 440 as an interface with an application running on a service platform outside of the MSSP.

SCL core 450 not only calculates statistics of system performance, but also supports the generation of detailed records. These statistics are updated with script control running in the execution environment. Periodically, the SCL core 450 sends these calculated statistics to the service management program 420, which uses these statistics to compute the obtained statistics. The service management program 420 calculates system performance statistics according to the information received from the SCL core 450.

A script that executes service logic for a particular provided service can control a number of different data flows. Flow is an abstraction used to represent the movement of packet data through an MSSP. The user can have multiple active flows in one session on the context. Flows are dynamic in nature and are typically set up and torn when users interact with network resources that provide various services. One flow belongs to one user in the context of a single service. In addition, a flow can also be considered to belong indirectly to a particular operator because the user belongs to one operator subscriber base. It should be noted that a user can have multiple flows that belong to different services and are active at the same time. For example, a user may have multiple windows open on a wireless device that browses different web sites each executing a particular service.

SCL core 450 collects each flow meter that can be further gathered within each session meter. Flow detail records can be conditionally written at the end of a flow. The detail record formed to provide a partial or complete summary of the flow is known as a flow detail record (FDR). Each detailed record may be ordered, including order, for the order in which it was written within a given user session or particular flow context.

SCL core 450 provides a set of real-time statistics sent to service management program 420 for distribution to external processes configured to receive real-time monitoring data. Real-time statistics sent by the core are periodically sent according to the MSSP configuration. Real-time statistics may depend on each operator, user group or service.

SCL core 450 periodically sends an operator real-time record to the service management program to provide real-time performance metrics for each operator. Real time recordings are typically computed in real time within the SCL core when messages are processed within the execution environment. The configurable periodic timer initiates a real-time data ejection process that packs real-time data elements and sends them to the service management program for distribution and further computation. Service real-time records and subscriber group real-time records are likewise sent periodically from the SCL core to provide real-time performance metrics for each service. SCL 330 supports multiple detailed recording formats so that data can be captured at multiple levels. These include Application Detail Records, Service Detail Records, User Detail Records, and Flow Detail Records. The service management program calculates statistics for time intervals, for example 5 minutes, one hour or all day intervals, and reports these calculated statistics in a database.

The SCL 330 may register and report an event for each flow under the control of a script that executes service logic. The process starts when the service application registers for notification detection points. The registration process involves establishing a set of patterns that match the flow in real time. In general, the pattern is keyed off from the control message of the protocol used in layers 2-7. For example, an open TCP session exchanges multiple protocol messages between two hosts. The exchange of TCP protocol control messages allows the flow state machine to pass through the connection setup state. The concept of detection points initiates a set of transform identifications within the state machine as where state transitions can be detected and reported to an external application. The detection point may be further limited to a set of conditions such that only certain flows that match the condition are reported to the external application. In practice, a detection point is a combination of a particular point in a state machine and a set of condition variables. Event reporting is the process of notifying external applications when a flow passes through one or more detection points and encounters a condition parameter. The actual event reported is a function of the protocol being executed. The concept of event reporting is generally very useful for connection orientation protocols because these types of protocols run well-formed state machines. Event reporting on disconnected protocols, such as UDP, is generally not very useful because the state machine reports a lot. In many cases, the state machine runs on a higher level protocol layered over UDP. An example of this class of protocol is WAP 1.0. The WAP stack forms an application layer protocol over UDP running the state machine. The detection point may be formed on an application protocol included in the UDP packet.

The request detection point may be the point at which the application controls the session while the flow of data communication is interrupted. It is common for an application to register a request detection point with a strategy point to be included in connection setup or protocol processing. When a packet in a flow path matches all of the condition parameters associated with the detection point, the flow process stops and an event message is sent to the application setting the detection point. The application can act to change the default handling of the flow. The change can include switching the connection request to a different destination address or terminating the connection completely. The application has the ability to determine how the connection request is routed through the network, as well as the ability to configure flow or session parameters for billing or security. The application must respond in time to the request event. Otherwise, you may incur unnecessary delays or wait significantly longer. If the application fails to respond to the request event within the timeout period (configurable), the suspended flow restarts and the default action configured for the service is executed.The request detection point causes the application to selectively interrupt the flow so that the service Implement the service logic to determine how to provide. Request detection points are most useful for connection orientation protocols, but they can also be applied to connectionless orientation protocols such as DNS, DHCP, or RADIUS. In these protocols, request detection points can be used to interrupt and server requests, as well as to synchronize responses with applications running outside the MSSP. The request detection point can be useful for responding to RADIUS authentication requests because it can configure the filter for the flow before notifying the application and sending a command to the MSSP to return to the authentication response. The sequence can be reliably applied to the flow from the start with the appropriate filter. It should be noted that both types of detection points (request and notification) can be used simultaneously in a complementary manner, allowing the application to control and monitor the conversation.

An example of a request detection point on TCP Open is to request that an application supply a destination address and receive an event report until the session fails because the session cannot or cannot be established successfully.

The detection point may be registered as a request detection point or a notification detection point. When the flow encounters the request detection point, packet transmission stops and is notified to the SCL Core. Instructs the STL how the response from the service logic will proceed, thus forwarding the packet in the flow. When a detection point is registered as a notification detection point, an event is sent for the case where the condition defined when the notification detection point is registered and the packet in the flow match. The detection point condition string may include wildcard card characters that can be used to specify a wide range of matching values. On receiving the registration request, the STL installs a detection point and sends a confirmation indicating that the registration operation was successful.

STL allows an application to specify a filter and apply it to each flow or flow on the session (user). The functionality can be used to form a wall garden that enforces a subscription model where subscribers can only access sites about their subscriptions. In addition, the functionality can be used to form a network-resident firewall. Functionality can be dynamically applied so that when a subscriber subscribes to paid viewing, the application updates the filter applied to an individual subscriber so that the subscriber can access the functionality for the duration of the contract. The dynamic nature of the filtering feature can be used to commandly open a hole on the dynamic port by a media gateway using an API. Thus, the operator can ensure that only authorized streaming traffic is allowed on the carrier network. This is in contrast to typical IP routers, where static access lists can be configured to manage packet filtering. The MSSP allows the functionality to be performed more effectively than by the users of the static list or the users of the application server software by hardware and embedded software. MSSP access is configurable for each flow, but the access list can be controlled for each user or session.

MSSPs allow applications to manage flows sent through VPNs and VPNs within the system. The use of VPNs is increasing because of the wide range of Internet and network security attacks. The MSSP can support client initiated VPNs and NAS-Initiated (Network Access Server) VPNs. The MSSP provides the capability to configure each type of VPN and allows the application to control when the VPN is set up and what traffic is sent over the set up VPN. In addition, the MSSP may accumulate the VPN simply passing through the MSSP from the user client to the remote Internet terminal point.

The application is associated with the detection point by identifying the detection point class, the detection point, and the conditions that must exist to form a control conversation with the application. The detection point calls an Initial Detection Point (IDP). Traffic passing through a state machine that does not meet certain condition criteria is not affected. When the condition matches a predetermined criterion, a control conversation is established between the state machine and the application, and the application is notified of the event.

When the detection point is ready to provide only event reporting, the control conversation is long enough to send an event notification, and packet processing by the state machine continues uninterrupted. When a detection point is provided as a trigger, the control conversation continues after the event report, and packet processing by the state machine is suspended until it receives a response from the application. The trigger can cause the application to influence subsequent control decisions made by the state machine.

When a packet is dropped at the detection point, the application responds in a different way. This allows packet processing to be simply resumed without affecting any control on the state machine. This type of response is called Continue. Another possible response is called Release, which can stop the state machine from adding packets. The application can also provide a new destination for the packet by using the connection response. Finally, the application can provide state machine control in packet addition processing of the stake machine by using the control response. The control conversation continues only after the application provides a trigger response when additional event reporting is requested.

The application can also use the control conversations generated by the IDP to request subsequent event reporting from different detection points in the same execution context of the state machine. An event detection point may be required by the application in connection with the continuation and connection trigger response, or may be required with each event report request message. The event detection point is only applied to the state machine context that generates the control conversation and prevents event reporting from being generated by any other context of the state machine. The event detection point is automatically removed when the corresponding state machine is removed.

A control dialogue is always created if the state meets the arming criteria at the initial detection point. In general, an application will be activated at only one initial detection point within any detection point class (state machine) as a trigger, resulting in a control dialogue resulting from requiring any additional event reporting required by the application. Use However, an application can activate multiple IDPs within any detection point class. Each IDP operates independently of the others, and the resulting control dialogues are unique. In any case, it may be possible for an application to have multiple concurrent control conversations set up for the same state machine context, but no benefit is gained from this fact, and the control conversations are still independent as if other applications were involved. Is processed.

See Figure 5 of a high-level example of a detection point message flow for a hypothetical application that controls a TCP connection to a particular destination address.

1. The application of the SCL activates the detection point associated with the detection of the SYN packet, which is related to the generation of the TCP flow. The target destination address to be controlled by the detection point reference is identified.

2. The mobile station MS initiates a TCP connection to the target destination address, which causes a TCP SYN packet to be sent to the target destination address.

3. If the TCP SYN packet sends an MSSP, the STL's TCP state machine evaluates the state at the TCP SYN state detection point and identifies whether it matches the arming criteria stored by the SCL in step 1. Processing of the SYN packet is delayed and an initial detection point indication is sent to the SCL to initiate a control conversation to the SCL.

4. The SCL evaluates the data provided by the detection event indication and determines whether the TCP connection is to another destination. It responds to the STL with the address of another destination and asks for the end of the TCP connection.

5. The STL acknowledges the connection request, forwarding the TCP SYN to the new destination, and activates the TCP connection termination detection point to provide an event report for this connection.

6. The new destination and mobile station (MS) completes the TCP protocol to open the connection and exchange data.

7. The mobile station (MS) initiates a TCP disconnection procedure, which sends a TCP FIN packet. When the FIN packet sends the MSSP, the TCP state machine of the STL entity evaluates the state at the TCP FIN detection point and identifies in step 5 whether it matches the arming criteria stored by the SCL. The requested event report indication is sent to the SCL. Since this detection point is activated not as a trigger but as an event report, the processing of the TCP FIN packet is started, the packet is sent to DEST, and the TCP protocol to terminate the connection is completed.

In this example, the detection point is associated with a TCP state machine. The STL layer includes a plurality of state machines including load monitoring, session groups, subscriber sessions, RADIUS protocols, DHCP protocols, DNS protocols, TCP protocols, and IP protocols.

Criteria for specifying IP detection point characteristics include operator ID, subscriber group ID, session ID, source IP address, source IP port number, destination IP address, destination IP address, destination IP port number, and application.

For a TCP state machine, detection points that can be registered include FORWARD_SYN, REVERSE_SYN, TCP_ACK, FORWARD_FIN, REVERSE_FIN, and RESET.

The SCL may require the STL to configure a packet filter for active sessions. Typically this request will be made as a result of the STL detecting the subscriber login. The subscriber login is delayed while the SCL creates a session and configures the appropriate packet filter for the session. After successful completion of the packet filter is required, the SCL sends a subscriber login configuration (Login Conf) so that the subscriber session can be processed.

An example of the overall operation of the MSSP is as follows.

1. At the beginning of this example, operators, subscriber groups, services, and applications are preconfigured in the MSSP database. For example, they reside permanently in the MSSP or are supplied by an operator.

2. The STL process starts, initializes, and sends an STL Up indication message to the SCL. The message indicates what configuration data is required for the STL entity and what capabilities the STL entity supports.

3. The STL process starts, initializes, and obtains the configuration from the MSSP database. The SCL responds to the STL Up indication message with an STL Version Config Request.

4. Each STL entity completes a version decision with the SCL and receives the configuration data required for the STL Up indication message.

5. Each STL entity supporting a detection point registers each detection point, specifies IDP and trigger characteristics, and indicates whether the reference parameters are related to each other.

6. The detection point registration message causes the SCL to create a context object for later management of the detection point resources.

7. The internal application service is activated on the MSSP.

8. The SCL API server begins to accept external application connections.

Next, after the MSSP is running:

1. An external application connects to the API server, initiates a session, and provides its identification and security information.

2. The API server authenticates the application, finds everything in order, and verifies that the session was opened by sending a response back to the application.

3. The application and API server determine the protocol version to be used for the rest of the session.

4. If not preconfigured with the service provided by the application, the application gets a list of services that are configured to be provided from the API server.

5. The application communicates Arm IDP requests to the API server and identifies MSSP services, detection points, and arming criteria.

6. The SCL API server checks for the application's configuration characteristics and the requirements for service criteria restrictions, and then sends an Arm IDP request to the SCL core.

7. The SCL core script confirms the request, associates the indicated MSSP service with the application, adds coefficients at the corresponding application and service context object, and then sends an Arm IDP request to each STL entity supporting the detection point. .

In addition, the detection point arming criteria may be stored in the SCL core context object and an arming request may be generated if an STL entity supporting this detection point is subsequently added.

8. When each STL entity confirms the detection point arming, the corresponding detection point resource is added to the MSSP service context object. The addition of the first DP resource causes the MSSP service state to change to "Deployed" and an acknowledgment of the Arm IDP request is sent to the API server (the script of the acknowledgment counts the coefficients in the corresponding application and service context object). After the addition).

9. The API server relays the Arm IDP checks to the application.

10. After the same procedure, the application activates any additional initial detection points that need to fulfill the services it provides.

11. The application waits for an IDP event indication message.

Next, if the mobile user wants to use the service:

1. The user turns on the telephone (MS) and initiates a RADIUS request.

2. The MSSP RADIUS proxy sends a RADIUS request to the RADIUS server.

3. The MSSP RADIUS Proxy receives a successful response from the RADIUS server, determines the subscriber group ID and operator ID to which the mobile subscriber belongs, and sends an STL subscriber login request to the SCL core.

4. The SCL core script creates a new session context object, combines it with the subscriber group and operator context object, assigns the session to one STL entity, and sends the entity in an STL generated session request message.

5. The STL entity specifies the resource for the session and responds with an STL generated session confirmation message.

6. When the SCL core receives the acknowledgment, any meters and packet filters configured for the operator and subscriber groups are configured for the new session by sending the appropriate message to the STL entity. Default meter masks for operators and subscriber groups are combined and configured in one request to the STL entity.

7. When all session configuration is complete, the SCL Core responds to the MSSP RADIUS Proxy with an STL Subscriber Login Configuration message.

8. The MSSP RADIUS Proxy returns a successful RADIUS response back to the MS.

Then, while the user has a data connection:

1. The mobile user initiates a browser connection.

2. A protocol packet requesting a new session is sent to the hardware controlled by the STL entity to which this subscriber session is assigned.

3. The STL entity evaluates and matches the criteria at its activated initial detection point.

4. The STL entity stops processing the packet and sends an STL IDP event indication message to the SCL.

5. The SCL script combines the stopped flow with the service containing the reported IDP, adds service and application trigger counts, and sends an IDP event indication to the API server.

6. The API server sends an IDP event indication to the application.

7. The application examines the IDP event parameters and determines another destination address for the MS connection, which feeds the API server in a connection request message.

8. The API server sends a connection request to the SCL core.

9. The SCL core script increments the service and application trigger response counts and sends the STL connection request to the STL entity as a stopped packet flow.

10. The STL entity changes the packet to the updated destination address, resumes packet processing, and returns the STL connection configuration to the SCL core.

11. The SCL core relays the connection confirmation to the API server.

12. The API server relays the connection confirmation to the application.

13. The destination selected by the application receives a connection request from the MS and opens a connection with the MS.

14. The MS and the destination server exchange data.

15. Periodically for the duration of the connection, an STL flow meter indication message is sent from the STL entity to the SCL core to convey the value of the meter element configured for the session.

16. The SCL core accumulates data of periodic flow meter indications, updating flows, sessions, subscriber groups, operators, and application context objects.

17. The MS disconnects from the destination server.

18. The STL entity detects the end of the flow and sends the final STL flow meter indication for the flow to the SCL core. No detection point activated by the application or the SCL is necessary to achieve this action. However, there are a number of scenarios in which the STL entity does not recognize when the flow has ended. In these cases the SCL core must implement the flow timeout policy and cause the flow to be released by the STL entity.

19. The SCL core script, as before, accumulates data from flow meter instructions, updating flows, sessions, subscriber groups, operators, services and application context objects.

20. The SCL core script creates application detail records corresponding to flows, subscribers, services, and closed flows. The association between the flow and the service context object may allow a billing plan ID configured in the service to be located in the flow detail record, or the application may provide a billing plan ID to be located in the flow detail record. Can be.

21. Detailed records are stored in the MSSP database until collected by the operator billing subsystem.

Referring to FIG. 6, MSSP 260 is a chassis based on a number of different modules with backplane 650 connections. There are four module types: input / output module 610, service module 620, control module 630, and fabric module 640. Optionally, there are control of spare information, SS7, I / O and fabric modules of the system. The number of input / output modules 610 is dependent on the external connection requiring the wireless system in which the MSSP is used. In general, the number of service modules 620 depends on the number of subscribers as well as the number and complexity of services the MSSP needs to support. The input / output module 610 and the service module 620 do not necessarily need to be combined in a one-to-one relationship. The control module 630 may alternatively be a mixed configuration where additional functionality is provided to the chassis or some functionality is provided to the internal control module 630 and combined functionality is provided to an external computer. All module types can be duplicated for one-to-one redundancy. For example, it may be two fabric modules of the MSSP.

The fabric module 640 provides an N-by-N interconnect to another module, allowing any module to directly forward packet data or other information to another module.

The control module 630 provides a platform for hosting the software base layer of the MSSP configuration. In this version of the system, the control module uses a processor based on Sun Microsystem SPARC.

The input / output module 610 and the service module 620 execute hardware base processing of the data packet. The general data path of the packet is input to the MSSP at the input / output module 610. The input / output module transmits the packet to the service module 620 through the fabric module 640. The service module immediately processes the packet and sends it to the input / output module 620 to export it from the MSSP or retains the packet for subsequent processing.

If the service module 620 needs to communicate with the software-based SCL, the module passes a message through the fabric module 640 to the control module 630 hosting the software layer. The control module 630 executes a TCP / IP communication stack. If the SCL 330 executing the control module 630 needs to communicate with the service platform 280, the module provides the communication to the service platform via the TCP / IP stack and fabric module 640. Transfer to input / output module 610.

Referring to FIG. 7, the input / output module 610 and the service module 640 share a common hardware configuration. Fabric interface 720 provides a communication path to fabric module 640 that forwards data to other modules at the back. In this version of the system, the fabric interface uses Gigabit Ethernet (GE) to communicate with the fabric module 640. The network processor 740 communicates with the fabric interface 720, receives the packet, and passes the packet through the fabric module 640. In this version of the system, the network processor is an Intel IXP 1240 processor. The network processor 740 uses a shared host memory 742 controlled by the network control processor 744 and shared between the network control processor and the network processor.

In addition, the input / output module 610 includes an input / output interface 710. The service module 620 does not need to include this interface or currently does not generally use it. Input / output interface 710 provides an external data connection for the MSSP. For example, data is transferred between the MSSP and the mobile network 120 and between the MSSP and the Internet 140 by the input / output interface described above. The packet is passed directly between the input / output interface 710 and the network processor 740.

The classification coprocessor 730 "snoops" on the data packets passed between the network input / output interface 710 and the fabric interface 720 and the network processor 740. The classification coprocessor is configured to detect a particular type of packet by detecting the characteristics of the packet at any protocol level. The pattern detected by the classification coprocessor is stored in coprocessor pattern memory 732 which sets classification control processor 734. When the classification coprocessor 730 detects the specific type of packet it is looking for, the classification coprocessor notifies the network processor 740 with a slight delay after the network processor 740 receives the packet. In this version of the system, classification coprocessor 730 is manufactured by Solidum Systems and provides for the detection of packets according to regular expression specifications. These regular expressions contain the characteristics of packets at one or more protocol layers.

The software layer of the MSSP configuration, executing the control module 630, is a packet pattern (i.e., detected by communicating with the classification control processor 734 via the fabric module 650, the fabric interface 720, and the network processor 740). , Detection point).

The service module 620 also includes an encryption / decryption engine 750, which is used by the service module to maintain tunnel connections to external services. For example, communication between MSSP 250 and content provider 150 may be along a secure tunnel. The encryption / decryption engine performs encryption and decryption necessary for the hardware.

The general path for packets from the mobile network 120 to the Internet 140 enters the MSSP 260 via the input / output interface 710 of the input / output module 610. The packet passes through the network processor 740 of the input / output module. Helped by the classification coprocessor 730, the network processor 740 determines whether the packet is one side of communication with a mobile station (MS) 132 that is supposed to be processed by the MSSP. If so, the network processor 740 forwards the packet directly to the service module 620 via the fabric interface 720 and the fabric module 650. The packet enters the service module via its fabric interface 720 and is delivered to the network processor 740 of the service module. The classification coprocessor 730 snoops into the packet from the fabric interface 720 to the network processor 740. If the packet matches the pattern that the classification coprocessor is trying to detect, the packet coprocessor informs the network processor and the network control processor 744.

If the packet does not need to be processed by the software layer of the configuration, the network processor 740 sends the packet from the fabric interface 720 to the input / output module for delivery out of the MSSP. The input / output module receives packets passed out of the input / output interface 710 and the MSSP through the network processor 740.

If the packet is combined with a detection point that requires intervention of the software layer of the configuration, the network processor 740 of the service module does not immediately send the packet. Rather, the network control processor 744 communicates with the software by communicating through a fabric module to a control module where the software is hosted. The network control processor eventually receives a response from the software layer and controls the network processor to properly process the packet. If the response does not come within the configured period, the packet is processed using the default processing rules.

If the packet is combined with a detection point that does not require this packet to be stopped but requires notification of the software layer, the network control processor 744 sends a message to the control module, and the network processor 740 indicates from the control module. Deliver the packet to the appropriate I / O module without waiting for it.

The operation of the MSSP 260 uses a model, such as finite state models, to monitor the communication session between the mobile stations (MSs) 132 and the content provider 150. MSSP 260 is configured to allow detection points in changes in these call models, for example in the state or state change of the finite state model. The call model occurs at multiple protocol layers. For example, at the lowest layer, the call model is combined with the overall PDP context. At higher layers, the call model is combined with transport layer flows such as TCP flows. The state of the call model is related to the initial setup and the end of the flow. At the higher protocol layer, the call model is combined with application layer exchange, for example, with a communication session following the HTTP protocol.

The service logic executable by the service platform 280, external service platform 282, or control module inside the MSSP registers a particular detection point that requires notification or receives control of the session. The detection point is generally identified by a particular state or state change in one of the call models as well as the detection point parameter. One example is attempting to configure a TCP session to a specific IP address, or setting a detection point when an HTTP session requires a specific web page.

The SCL of the MSSP executing on the control module at the back receives a request to register a detection point and issues a corresponding request of the STL, which in turn requires configuration of the classification coprocessor and network processor of the service module.

The approach described above supports a wide range of service types and charging models. Many illustrative examples are described below.

The first type of service is similar to a toll-free telephone calling model. In this service, the user will not charge for data communication with the content provider. An example of this is a flower grower service that is accessed as if it were a web server from an Internet host called 800Flowers.com.

In the setup state, the external service platform communicates with the MSSP to request that the user attempt to retrieve a web page from a host called 800Flowers.com. In the MSSP, the SCL requests the STL to set up the events and hardware triggers necessary to receive and confirm the request and to execute the detection.

When the user attempts to retrieve a web page from his MS at 800Flowers.com, the configured trigger is detected. The STL informs the SCL of the detection identifying the external service platform. The external service platform determines where the request is sent, in this case FTD.com, informs the SCL, sends the SCL a change direction indication, and the STL directs the network flow to the FTD.com rather than 800Flowers.com. Require change. The original packet detected is delivered directly to the Internet and changed to reflect the redirected address.

Upon completion of the session with FTD.com, the SCL generates an IPDR that reflects the amount and estimate of data delivered during the session, and sends it to the billing node. The operator will also charge the FTD for this portion of the user's communication rather than charging the user.

Another service is similar to wireless prepaid voice services. An MSSP is provided to detect the setup of a PDP context from a particular user. When the MSSP detects a new PDP context, the application logic residing in the control module in this case communicates with an external accounting server to determine if the user has a positive balance in his account. In one version of this service, this accounting server is accessible by SS7 network using the same protocol used for voice prepaid service.

After the SCL confirms the user, the user's data is passed to the MSSP without modification. When the user ends the session, the SCL sends a command to the accounting server to reduce the user's deductible balance based on the amount of data passed during the session or the duration.

In another embodiment, the network 100 is used to provide a sponsored packet switched data service that is accessed by a user on a fully sponsored basis by another person. Application-based services (content or user chat services) and network services (packet data transfers) are free and staged to users. Prior to using the service, the user knows that the "air time" packet data transfer charge or other content or use service charge does not apply by connection of the service. Optionally, the user can be notified at the time of requesting a sponsored service.

The network operator is responsible for any and all unique network addresses that identify a packet switched data service, policy decisions that determine how the user is directed to the packet switched data service provider, and to which packet switched data service provider the user is directed, and Processes and controls the Sponsor Packet Switching Data Service, including a policy decision that determines which principle the sponsor will charge for and during the session. The policy decision for selection and billing establishes provisions for integrating a pre-agreement between the operator and a third party, sponsor or service provider, regarding the choice of service provider and the methods and principles of payment for the sponsor. It may include. The policy decision of the service provider to connect may be made at the time of service request based on factors such as user identity, user's location, time of day, user class, service provider class, network status, pre-registration rules, and / or government regulations. have. For example, policy decisions on which sponsors will be charged under what principles and billing may be based on similarities such as identity, user's location, time of day, user class, service provider class, network status, pre-registration rules, and / or governmental regulations. Can be made at the time of service request according to the factor.

Referring to FIG. 8, the sponsored packet switched data service process 800 includes a step 802 of receiving a request for a packet switched data service. This request is typically initiated by a user connecting to the network 100 by the air interface. The request may also be a response to a push operation by the service sponsor encouraging the user to try the sponsor's service. A push action is a job where a sponsor starts an activity.

The process 800 determines 804 whether a user is authorized to access the network 100 for packet switched data services. User class information and location information needed to make a later policy decision for the packet switched data service is collected during the decision 804. If the user is not authorized to access the network 100, the process 800 denies the user request (806).

If the user is authorized to access network 100 for packet switched data services, the process 800 determines 808 whether the requested service is for a sponsored packet switched data service. If the service request is not a sponsored packet switched data service, the process 800 processes the user request with another service request process (810).

If the service request is for a sponsored packet switched data service, the process 800 determines 812 whether the user is authorized to access a particular requested sponsored packet switched data service. If the user is not authorized to access a particular requested packet switched data service, the process 800 denies the user request (806).

If the user is authorized to access a particular requested packet switched data service, the process 800 selects 814 a service provider for the particular requested switched data service. The selection 814 is made in connection with a stored regulatory principle that performs a policy decision of the operator of the network 100 according to one or more factors. The elements may include user identity, user location, time of day, user class, service provider class, network status, pre-registration rules, and / or governmental regulations. For example, if the operator of the network 100 normally supplies a particular requested exchange data service, then the rule selection preferably selects the operator as a service provider.

The selected service provider, i.e. sponsor, identity may be a rule for determining a sponsor from the class, the service provider selected next, and the information obtained next. In the case of providing the service, the operator will be nominated as a sponsor. If a third party is chosen as the service provider and agrees to sponsor the service, the third party will also be considered a sponsor. The process 800 may use other regulatory principles to implement an operator's policy decision to select a sponsor. As one example, the selection depends on a pre-contract between the third party and the operator to be sponsored or the co-sponsor of the particular service.

The process 800 connects the user to the selected service provider (816) and initiates a packet switched data service session. The process 800 monitors and measures packet switched data sessions, for example, while collecting billing and other information generated during the session. The type of billing and other information that is generated depends on the type of packet switched data service and sponsor that is supplied. As one example, the type of information collected is a policy decision of the network operator. In the case of a third party sponsor, the policy decision is generally dependent on the precontract between the manager and the third party. For example, if the third party service provider is a sponsor of a free packet switched data service, billing information is collected for network connection fees based on the number of criteria. In addition, information about the use of the data service may be collected, so that the supplier may, for example, charge the marketing and advertising customer with the above costs. Similarly, if the service provider is an operator, it usually does not have any one-time payment, but may be needed to know network usage and data usage and may, for example, convey this information to its marketing and advertising customers.

During the session, the process 800 can send the fare information in real time or near real time.

Once the session is complete, the process 800 sends 820 the billing and other information to the appropriate node. The node writes in the account (s) of the identified sponsor (s) for the stored fee and information unit for information transfer. Also, if necessary, any usage information is matched by the node to the user record.

In another embodiment, network 100 is used to provide a transaction-based packet switched data service to a user in accordance with a purchase service provided to the user by a service provider. The service provider may be a single third party, multiple third parties, and / or operators of the network 100. The purchase service may be an application-based service, for example the content of the service or a user interactive service, a product, for example a software program, a license, for example the right to use the software program, a product for post-delivery, for example For example, an item may be easily picked up by a user, a sales outlet or a sales location, or for delivery to a user's location by a service provider. The network service for packet switched data transmission included in the delivery of the service is included in the total purchase price of the service, i.e. the user does not incur an individual fee or cost for any network service required to fulfill the purchase request. Before using the service, the user knows that by accessing the service, the service is provided on a fee basis and includes package network services and transmission charges. As an example, a user may be notified at the time of requesting a service that is a transaction based on a fee basis.

The operator of the network 100 processes and controls the transaction-based packet switched data service. This includes any and all unique network addresses that identify a packet switched data service, a policy decision that determines how the user is directed to a packet switched data service provider, and which packet switched data service provider the user is directed to, and in what principles and Policy decisions that determine how to be billed, and any policy decisions that are delegated to service providers. The policy decision for selection and billing may include provisions for incorporating any pre-contract between a third party, such as an operator and a service provider, with respect to the choice of service provider and the method and principle of payment of the user. For example, the policy decision of the service provider to connect to may be made in service requests based on factors such as user identity, user's location, time of day, user class, service provider class, network status, pre-registration rules, and / or governmental regulations. .

With reference to FIG. 9, a transaction-based packet switched data service process 900 includes receiving 902 a request from a user for a packet switched data service. The service request may originate from a user connecting to the network 100 via an air interface or the service request may be in response to a push operation by a service provider who advises the user to purchase the service. A push action is an action where a sponsor starts an activity.

The process 900 determines (904) whether a user is authorized to access the network 100 for transaction-based packet switched data services. User class information and location information needed to make a later policy decision for the requested transaction-based packet switched data service is collected during the decision 904. If the user is not authorized to access the network 100, the process 900 denies the user request (906).

If the user is authorized to access network 100 for transaction-based packet switched data service, the process 900 determines 908 whether the requested service is a transaction-based packet switched data service. If the service request is not for a transaction-based packet switched data service, the process 900 processes the user request with another service request process (910).

If the service request is for a transaction-base packet switched data service, the process 900 determines (912) whether the user is authorized to access a particular requested transaction-base packet switched data service. If the user is not authorized to access a particular requested transaction-base packet switched data service, the process 900 denies the user request (906).

If the user is authorized to access a particular requested transaction-base packet switched data service, the process 900 selects 914 a service provider for the particular requested transaction-base packet switched data service. The selection 914 is made in connection with a stored regulatory principle that makes policy decisions of operators of the network 100 according to one or more elements. The elements may include user identity, user location, time of day, user class, service provider class, network status, pre-registration rules, and / or governmental regulations. For example, if the operator of the network 100 normally supplies a particular requested transaction-based packet switched data service, then the rule selection preferably selects the operator as a service provider.

The process 900 authorizes the user's request (916). Authorization 916 may include participation by a service provider and / or operator of network 100. The service required by the transaction-based authorization 916 user includes determining whether the requesting user has sufficient credit or payment capability to pay anticipated debt arising from the service provided. If the user is not authorized to make a purchase of the selected transaction-based service, the process 900 denies the service to the user (906).

If the user is authorized to continue purchasing the selected transaction-based service, the process 900 connects the user to the identified service provider (918) and initiates a packet switched data service session. The disclosed transaction-based packet switched data service may include the purchase of one or more transaction based services by a user from an identified service provider. The process 900 monitors each individual purchase session within one user session (920) and generates (922) billing and other information for the purchase or purchases. During each purchase session, the process 900 sends billing information to the node in real time or near real time. The type of billing information and other information depends on the type of packet switched data service and provider provided. As one example, the type of information collected is the policy decision of the network operator. In the example of a third party provider, the type of information collected generally depends on the pre-contract between the operator of the network 100 and the third party provider. For example, a purchase authorization may limit the maximum network resources that can be used to attempt to deliver a transaction based service. The pre-arranged policy may determine under certain conditions that the service is delivered and constitutes a restriction of suitable attempts to deliver the service by the network operator.

For example, if an inadequate network condition results in an unacceptable number of packet retransmissions during a service delivery attempt because of an unrecoverable packet error condition between the provider and the user, the pre-arranged policy provisions may stop the service delivery attempt, It may include a threshold at which the purchase is canceled and the purchase session is declared prematurely completed. Under the more general "normal" state, the purchase session is determined to be complete when the delivery of the transaction-based service is complete.

Once the purchase session is complete, the process 900 sends 962 billing information and other information to the node. Billing may be such as volume, duration, time of day, final destination, location, quality of service, SMS, IMSI / subscriber supplied, recipient payment fee, free fee, flat rate, and bearer service. It can be based on a number of factors.

The process 900 writes the billing unit to the user's account for the stored payment and information unit for transfer of information (928). There may also be an exchange of information between the service provider and the network operator involved in completing the purchase session. The process 900 matches any usage information to the service provider record.

If the service session between the user and the service provider includes multiple purchase sessions, the user may choose to make different transaction based service requests. If the user has no other needs and / or all purchasing sessions are completed, the service session is completed. If the user chooses to make different and / or multiple purchase requests from the same service provider during the same service session, these additional requests are processed by process 900.

In other hardware configurations, rather than using the back side with a fabric card, an integrally combined input and output module and service module provide external data access and packet processing. This combined card is hosted in a computer chassis, such as a pizza box "pizza box".

In another embodiment, the MSSP is used to provide voice by IP (VoIP) service where packetized voice traffic is passed between the mobile network and the fixed network.

In another embodiment, the approach described above applies to a Mobile Virtual Network Operator (MVNO) environment. In one such environment, multiple operators share one MSSP. Services, user groups, and other configurations are one per operator base. In this manner, data communication between subscribers of one virtual operator is handled by the operator service. That is, only the subscriber flow starts the service provided by the operator. Operators of the physical network may receive usage information, for example, to bill the virtual operator for use of their physical network. The virtual operators can receive detailed records for their subscribers and can bill advertisers based on their subscribers, service providers, and service models. In other MVNO environments, one MSSP may send communications for a particular virtual operator to another MSSP without having to process another network location, for example a flow.

In other embodiments, other types of wireless configurations than GSM / GRPS are supported. For example, the MSSP described above can act as a gateway for many other types of wireless data networks, including CDMA, TDMA, and third generation (3G) systems.

In addition, in the case of GSM / GPRS, the functionality of the MSSP can be combined with other nodes. For example, the functions of the GGSN and MSSP can be combined in one node.

The MSSP may also control communications that do not include a wireless data network. For example, a model approach with an external service platform is applicable to monitoring and controlling communication sessions passing between networks, such as between a subscriber's network and a wide area network, or between a wireless LAN and a fixed network.

Many other hardware configurations are possible. For example, in other configurations, the functions of the input / output module and the service module may be combined, and some of the functions supported by the control module may be hosted with the MSSP chassis.

It is to be understood that the above description is intended to be illustrative, and not to limit the scope of the invention, which is limited by the scope of the appended claims. Other embodiments are within the scope of the following claims.

Claims (63)

In the method of processing data communication passing through a node of a data network, Providing a service on the node comprising the step of configuring a detection point of a service, Processing a communication passing through the node, including monitoring the communication to identify a match with the configured detection point; and Upon identifying a match with the configured detection point, notifying service logic for the service of the detection point Data communication processing method comprising a. The method of claim 1, Processing the communication passing through the node comprises processing data communication from a wireless network. The method of claim 2, Processing data communication from the wireless network comprises processing data communication from a second-generation (2G) wireless telephone network. The method of claim 2, Processing data communication from the wireless network comprises processing data communication from a third generation wireless telephone network. The method of claim 2, Processing data communication from the wireless network comprises processing data communication from a GPRS enabled wireless network. The method of claim 2, Processing data communication from the wireless network comprises processing data communication from a wireless local area network (WLAN). The method of claim 1, Processing the communication passing through the node comprises processing data communication from a fixed network. The method of claim 1, Configuring a plurality of service operators on the node. The method of claim 8, Configuring the operator comprises configuring a virtual operator. The method of claim 8, Providing the service comprises associating the service with one of the operators. The method of claim 10, The data communication processing method further comprises providing data security between the operators. The method of claim 1, Providing the service further comprises receiving a specification constituting the detection point. The method of claim 1, Providing the service includes receiving configuration information of the service from a server outside the node. The method of claim 1, And the data communication comprises packet data communication. The method of claim 14, And said packet data communication comprises Internet Protocol (IP) data communication. The method of claim 15, The step of configuring a detection point includes specifying a characteristic at one or more protocol layers. The method of claim 16, Specifying the characteristic at the one or more protocol layers comprises specifying the characteristic at a network layer. The method of claim 16, Specifying the characteristic at the one or more protocol layers comprises specifying the characteristic at the transport layer. The method of claim 18, The step of specifying a characteristic at the transport layer comprises the step of specifying a characteristic relating to a transport control protocol (TCP). The method of claim 18, The step of specifying a characteristic at the transport layer includes a step of specifying a characteristic relating to Universal Datagram Protocol (UDP), The method of claim 16, Specifying the characteristic at the one or more protocol layers comprises specifying the characteristic at an application layer. The method of claim 21, Processing the characteristic at the application layer comprises specifying a characteristic of a Hyper Text Transport Protocol (HTTP). The method of claim 21, Specifying an attribute at the application layer comprises specifying an attribute of a RADIUS application protocol. The method of claim 21, Specifying an attribute at the application layer comprises specifying an attribute of a Domain Name Service (DNS) protocol. The method of claim 16, Specifying the characteristic at the one or more protocol layers includes specifying the characteristic at a plurality of protocol layers. The method of claim 16, Specifying the characteristic at the one or more protocol layers comprises specifying a regular expression that identifies a data packet field in the one or more protocol layers. The method of claim 1, The data communication processing method further comprises the step of processing the communication according to the service logic upon identifying a match with the detection point. The method of claim 27, And the communication processing method further comprises, upon identifying a match with the detection point, stopping the communication associated with the matched detection point. The method of claim 27, Further processing the communication Receiving a specification of an event detection point from the service logic, Configuring the event detection point, and Monitoring the communication to identify a match with the configured event detection point Communication processing method comprising a. The method of claim 27, Further processing the communication comprises redirecting the communication. The method of claim 27, Processing the communication further comprises forwarding the communication to a destination associated with the service via a communication tunnel. The method of claim 27, Further processing the communication comprises filtering the communication. 33. The method of claim 32, And the filtering step includes blocking the data packet according to an identified address in the data packet. The method of claim 27, Further processing the communication comprises applying a policy to the communication. The method of claim 34, wherein Applying a policy to the communication includes applying a data rate policy. The method of claim 1, And providing the service comprises communicating with a network management system. The method of claim 1, Providing the service includes identifying communication metering characteristics for a two-way service conversation, Processing the communication passing through the node further includes detecting a two-way service conversation of a data communication associated with each of the services, and recording fee information for the detected two-way service conversation. Communication processing method. The method of claim 37, Recording the fee information for the detected two-way service conversation comprises recording the amount of data transmitted in the two-way service conversation. The method of claim 38, Recording the amount of transmitted data comprises recording the number of packets. The method of claim 38, Recording the amount of transmitted data comprises recording a number proportional to the number of bytes. The method of claim 38, Recording the amount of transmitted data comprises recording the amount of data that has passed through the node in one direction. The method of claim 37, Recording the fee information for the detected two-way service conversation comprises recording a data transmission rate during the two-way service conversation. The method of claim 37, Recording the fee information comprises recording fee information for an individual flow of the interactive service conversation. The method of claim 37, Recording the fee information comprises recording fee information for a flow group of the interactive service conversation. The method of claim 37, Recording the fee information comprises recording the fee information for the entire interactive service conversation. A method of processing data communication through nodes of a data network, the method comprising: Processing the communication session in a data communication passing through the node, including monitoring a data packet for the communication session to identify a match with a configured detection point; Upon identifying a match with the configured detection point in one of the communication sessions, forwarding a request to the external service logic to identify the detection point, and Further processing the communication session according to the information received from the service logic in response to the forwarded request. Data communication processing method comprising a. 47. The method of claim 46 wherein The further processing step comprises stopping the communication session and then transferring data for the communication session in accordance with the received information. 47. The method of claim 46 wherein And said further processing step of switching said communication session in accordance with said received information. A method of monitoring a service provided on data communication through a node of a data network, comprising: Providing a service comprising identifying communication characteristics for a two-way service conversation, Detecting a bidirectional service conversation of data communication each associated with a particular user of the service, and Providing information regarding the detected interactive service conversation Service monitoring method comprising a. The method of claim 49, And detecting the two-way service conversation comprises matching the data communication to a detection point. 51. The method of claim 50, The detection point comprises a characteristic of a multiple protocol layer. The method of claim 49, Providing the information includes sending the information to an external system. The method of claim 49, And wherein the information about the detected session is information about a subscriber population. The method of claim 49, And the information about the detected session is information about a specific service. The method of claim 49, And the information about the detected session is information about an operator. The method of claim 49, And wherein the information about the detected session comprises a detailed record of a given session. The method of claim 56, wherein The detailed record about the session comprises a detailed record of only a portion of the session. The method of claim 49, And the information about the detected session includes information about a time interval of an operation. A method for processing packet data communication between a mobile station on a wireless telephone network and a service provider on a fixed network, the method comprising: Providing the service on a node that associates the wireless telephone network with the fixed network, including configuring service logic for a service, Monitoring the communication to identify a communication session associated with the provided service, processing packet data communication passing between the wireless telephone network and the fixed network via the node; Matching detection points of the identified communication session, and Executing the service logic in response to matching of the detection points Packet data communication processing method comprising a. The method of claim 59, Executing the service logic comprises communicating with an external service platform, and processing the packet data communication comprises processing the communication according to information received from the external service platform. Treatment method. In a communication node, Means for providing the service on the node, including means for configuring a detection point for the service, Means for processing the communication passing through the node, including means for monitoring the communication to identify a match with the configured detection point, and Means for notifying service logic for a service of the detection point when identified as being matched with the configured detection point Communication node comprising a. In a communication node, A service manager configured to accept the provision of information about the service, A database associated with the service manager, including a storage device storing the received information provision; Circuitry for passing packet data communication through a predetermined device and detecting a configurable event of said data communication, and A service execution engine programmed to communicate with the service manager and receive a notification of the detected event to a circuit that passes data Communication node comprising a. The method of claim 62, The database further comprises a storage device for a detailed record, wherein the service execution engine is further programmed to generate a detailed record in response to the received notification.