Application program interface

Application program interface

Technical field

The invention relates to an application program interface (API).

Background technique

An application program interface is usually a special method specified by a computer operating system or another application program, by which a programmer who writes an application program can make a request to the operating system or another application program. More specifically, an API is a formatted collection of software calls and routines, which can be referenced by applications to access supported services.

Summary of the invention

In one aspect, the present invention is characterized by providing a method in the network, including receiving a message from an application program using an application program interface (API), and transferring the message from the API to a mobile service exchange platform (MSSP) Control the process.

Embodiments may include one or more of the following: the network may be a wireless network, the wireless network may be a second-generation wireless network, a GSM network, a GSM network that can use GPRS, or a TDMA network. The wireless network can be a CDMA network, a UMTS network, a TETRA network, or a Tetrapol network. The wireless network can also be a DECT network, an AMPS network, a WLAN network, or a third-generation wireless network.

The API may provide a protocol that allows applications to control the switching and routing functions in the MSSP.

The API can provide a protocol that allows applications to redirect packet flows through MSSP on a per-flow basis.

The API may provide a protocol that allows applications to control policy decisions within the MSSP.

The API may include protocols that allow applications to arm initial detection points (IDPs) and services associated with IDP events in the control process.

The API may include protocols that allow applications to release detection points (IDPs) and services related to IDP events in the control process.

The API may include a protocol that allows applications to request event reports.

The API may include a protocol that allows the application program to specify the programming behavior at a certain detection point in the control process.

The API may include a protocol that allows an application program to configure data elements metered by the control process of the MSSP.

The API may include a protocol that allows applications to request byte-based reports. The report can be session-based or stream-based.

The API may include an agreement that allows the application to specify the cost of the service provided.

The API may include a protocol that allows the application to record the billing scheme used in the detailed record, and a protocol that allows the application to control when the detailed record is written.

The API may include a protocol that allows the application program to obtain statistics on the session managed by the application program.

The API may include a protocol that allows the application program to obtain statistics on the flow managed by the application program.

The API may include a protocol that allows applications to monitor the status of other applications connected to the MSSP control process.

On the other hand, the present invention is characterized by an application program interface (API) that includes a set of application layer protocols that allow the use of transmission control between the application process and the control process of the mobile service exchange platform (MSSP) Protocol/Internet Protocol (TCP/IP) network services exchange messages.

In an embodiment, the set of application layer protocols may include protocols that allow application processes to be equipped with detection points (IDPs) and services related to IDP events in the control process.

The set of application layer protocols may include protocols that allow application processes to release detection points (IDPs) and services related to IDP events in the control process.

The set of application layer protocols may include a protocol that allows the application process to request event reports from the control process.

The set of application layer protocols may include a protocol that allows the application process to specify the programming behavior at a certain detection point in the control process.

The set of application layer protocols may include a protocol that allows the application process to configure data elements measured by the control process.

The set of application layer protocols may include a protocol that allows application processes to request byte-based reports in the control process. The report may include a session-based report or a stream-based report.

The set of application layer protocols may include a protocol that allows the application process to specify the cost of the service provided by the MSSP.

The set of application layer protocols may include a protocol that allows the application process to record the charging scheme used in the detailed record, and the detailed record is stored in the MSSP.

The set of application layer protocols may include a protocol that allows the application process to control when to write the detailed record.

The set of application layer protocols may include a protocol that allows the application process to obtain session statistics managed by the application process.

The set of application layer protocols may include a protocol that allows the application process to obtain convection statistics managed by the application process.

The set of application layer protocols may include a protocol that allows the application process to monitor the status of other application processes connected to the control process.

On the other hand, the present invention is characterized by a system that includes a gateway general packet radio service support node (GGSN) linked to a control process in a mobile service switching platform (MSSP), and a set of global networking links to the control process The computer is connected to the application program interface (API) that controls the process, and the application system that executes the application process that is linked to the API.

In an embodiment, the system may include a general packet radio service support node linked to the GGSN. The system may include a base station controller (BSC) linked to a general packet radio service support node. The system may include a base transceiver station (BTS) linked to the BSC and a mobile base station (MS) linked to the BTS.

The API may include a set of application layer protocols that allow messages to be exchanged between the application process and the control process.

The set of application layer protocols may include protocols that allow application processes to be equipped with detection points (IDPs) and services related to IDP events in the control process.

The set of application layer protocols may include protocols that allow application processes to release detection points (IDPs) and services related to IDP events in the control process.

The set of application layer protocols may include a protocol that allows the application process to request event reports from the control process.

The set of application layer protocols may include a protocol that allows the application process to specify the programming behavior at a certain detection point in the control process.

The set of application layer protocols may include a protocol that allows the application process to configure data elements measured by the control process.

The set of application layer protocols may include a protocol that allows application processes to request byte-based reports in the control process. The report can be session-based or stream-based.

The set of application layer protocols may include a protocol that allows the application process to specify the service cost provided by the MSSP.

The set of application layer protocols may include a protocol that allows the application process to record the charging scheme used in the detailed record, and the detailed record is stored in the MSSP.

The set of application layer protocols may include a protocol that allows the application process to control when to write the detailed record.

The set of application layer protocols may include a protocol that allows the application process to obtain session statistics managed by the application process.

The set of application layer protocols may include a protocol that allows the application process to obtain convection statistics managed by the application process.

The set of application layer protocols may include a protocol that allows the application process to monitor the status of other application processes connected to the control process.

Embodiments of the invention may include one or more of the following advantages: The application program interface (API) provides an application layer protocol that uses a simple TCP/IP network that is available on almost all computer platforms The service exchanges messages with the mobile service exchange platform (MSSP).

The API provides a set of protocols that allow business logic contained in external applications to control the switching and routing functions of the mobile business switching platform.

The API provides a protocol for operators to limit the scope of application detection points, where the detection points are locations defined in the state machine of the control entity, where application event reporting and/or control can be performed.

The API provides a protocol that is common to all applications and has nothing to do with application privileges.

The API provides a protocol that allows applications to equip or remove initial detection points (IDPs) in the mobile service exchange platform and services associated with IDP events. IDP is defined as the equipped detection points to meet various conditions When the criteria are given, a new control dialog with an application is created.

The API provides a protocol that allows an application to request additional event reports following the initial detection point event. When the IDP that initiates the control dialog is a trigger, the application usually requests reports of additional events.

The API provides a protocol that allows applications to specify programming behaviors at a certain detection point (DP) without the application's participation. Use the message to match the incoming request to decide whether to perform a predetermined business interaction. The matching process is similar to the process of the initial detection point commonly used, and wildcards can be used for the matched fields. If a stream meets the standard, the behavior specified in the message memo will be performed without the participation of the application. Specified actions can include event reporting, and redirection of requests to specified redirection addresses and port numbers. If an event report is requested, the message is used to decide which event will be reported in the future for this stream. The standard to be matched may not overlap with the armed initial detection point standard. If the request cannot be completed for any reason, a message will be returned containing the matching RequestID code and an error code indicating the nature of the failure. If the request is successfully completed, another message will be returned. Service filtering is always active, unless cancelled by a special message request.

The API provides a data element that allows applications to configure data elements that are metered by the mobile service exchange platform (MSSP).

The API provides a protocol that allows applications to request byte-based reports. The report can be requested based on session or based on flow. Session-based charging notification effectively produces the same charging notification standard that will be applied to all flows in the session. The registration of the charging notification event will cause the measurement of the number of bytes of the specified type transmitted in the uplink and downlink directions. Each time the reporting threshold is reached, a message is sent from the MSSP to the application, indicating the number of bytes that have been transmitted, and the counters are reset, and then counting towards the threshold. The charging notification continues until the flow is stopped or the charging notification is explicitly cancelled by the cancellation request. A packet is an atomic unit of count, and each packet can arrive either before or after the count evaluation. Therefore, the billing notice may not happen to appear on the specified byte count. For example, if a notification is requested every 10K bytes, and if the packet whose count exceeds 10K is slightly larger than 500 bytes, the notification may appear at 10.5K bytes. The actual counter value is provided in the message.

The API provides a protocol that allows the application to indicate the cost of the service provided and record the billing scheme used in the MSSP detailed record.

The API provides a protocol that allows an application to control when to write MSSP detailed records.

The API provides a protocol that allows an application to obtain various statistics on sessions or streams managed by the application.

The API provides a protocol that allows applications to monitor the status of other applications connected to the same MSSP instance.

The API provides a protocol that allows redirection of packet flows on a per-flow basis.

The specification, drawings and claims of the present invention will describe in detail other technical features, objectives and advantages of the present invention.

Description of the drawings

Figure 1 is a network block diagram.

Figure 2 is a flowchart of the monitoring process.

Fig. 3 is a flowchart of the start-up phase of the business application of Fig. 2.

Fig. 4 is a flowchart of the service initialization phase of Fig. 2.

Fig. 5 is a flowchart of the service deployment phase of Fig. 2.

Fig. 6 is a flowchart of the business logic stage of Fig. 2.

Fig. 7 is a flowchart of the service stop phase of Fig. 2;

Fig. 8 is a table of data types used by the API in Fig. 1.

Fig. 9 is a block diagram of a communication path.

Figure 10 is a block diagram of the TCP/IP byte stream being divided into session messages by the transport layer.

The table in Figure 11 lists exemplary error codes.

The table in Figure 12 lists exemplary feature types.

detailed description

Figure 1 shows a network 10, the network 10 may be, for example, a wireless network, the wireless network may be, for example, a second-generation wireless network, a global system for mobile communications (GSM) network, or a general packet radio system (GPRS) may be used GSM network. The wireless network may be a time division multiple access (TDMA) network, a code division multiple access (CDMA) network, or a universal mobile telecommunications system (UMTS) network. The wireless network can be a TETRA network, a Tetrapol network, a DECT network, an AMPS network, a wireless local area network (WLAN), or a third-generation wireless network. The following describes the GSM network that can use GPRS as an example.

The network 10 includes a mobile station (MS) 12 connected to a base transceiver station (BTS) 14, and the BTS 14 is connected to a base station controller (BSC) 16. In the field of mobile communication, the MS 12 is a station located in the mobile service (zone) to be used that is in motion or stopped at an uncertain point, and a handheld cellular phone is an example of a mobile station.

The BTS 14 has a wireless transceiver that defines the cell, and coordinates the wireless link agreement with the MS12. The BTS 14 is an integral part of the network 10 and transmits and receives all signals. The BTS 14, usually called a cell phone tower, is linked to and controlled by a base station controller (BSC) 16. The BSC 16 is an integral part of the network 10 and manages wireless resources for one or more base transceiver stations, such as the exemplary BTS 14.

The BSC 16 is linked to the SGSN 18. The SGSN 18 is a General Packet Radio Service (GPRS) node, and the BSC 16 sends or receives packets to serve GPRS mobile (phone). The SGSN 18 is linked to a gateway GPRS support node (GGSN) 20, which serves as a gateway between the General Packet Radio Service (GPRS) network and the Packet Switched Public Data Network (PSPDN).

The GGSN 20 is linked to a mobile service switching platform (MSSP) server 22. The MSSP server 22 is located between the GGSN 20 and a group of globally networked computers, such as the Internet 24. The MSSP server 22 analyzes all Internet Protocol (IP) packets exchanged between the MS 12 and the Internet 24. The MSSP control process 26 provides the ability to set triggers or event notifications and increment counters according to the characteristics of the IP flow. An IP stream can be thought of as an abstract representation of data movement between two endpoints, such as MS 12 and a server (not shown) located on the Internet 24. The MSSP control process 26 uses these capabilities to implement various internal operations and detailed reports. An application program interface (API) 28 links the MSSP control process 26 to an external application 30. The API 28 provides a mechanism for the external application 30 to control the MSSP control process 26 to provide intelligent services. In various embodiments, for example, the API 28 may be implemented as a Corba-based API, an XML-based API, a PARLAY server, an OSA server, or a JAIN server, etc.

In short, the MSSP server 22 is both a router of the Internet and an analyzer of IP packets. The data contained in the IP packet header field is defined by Internet Engineering Task Force (IETF) RFC 791, which is incorporated herein as a reference (see www.ietf.org). IETF is a large and open international community of network designers, operators, suppliers and researchers. It pays attention to the development of the Internet structure system and the smooth operation of the Internet.

The Internet Protocol (IP) was designed for interconnection systems used in packet-switched computer communication networks. IP provides for sending data blocks from source to destination, which are called datagrams, where the source and destination are hosts identified by fixed-length addresses. IP also provides segmentation and reassembly of long datagrams, and, when necessary, is transmitted over a "small packet" network.

The MSSP control process 26 is used to analyze the header of the IP packet in real time when the packet characteristics meet specific conditions, so as to manage various counters and signals. The signal can be an event report or a trigger. The event report reports the occurrence of certain events while continuously monitoring the packet stream. The trigger suspends the processing of the IP packet until the MSSP control process 26 responds to a specific instruction for resuming the processing of the IP packet. The trigger response may simply allow IP packet processing to continue unchanged, or change the processing of the packet by specifying a different destination for the packet, or discard the packet altogether. In one embodiment, the API 28 provides methods for other applications 30 to communicate with the MSSP control process 26 and manipulate event reports and triggers.

The MSSP control process 26 manages multiple different types of IP packets. In one example, the MSSP control process 26 is divided into different state machines (not shown), and each state machine is responsible for different types of packets. Generally, a state machine usually refers to any device that stores the state of something at a given time, and can operate on inputs to change the state and/or cause an action or output to occur for any given change. In fact, state machines are used to extend and describe specific device or program interactions.

Within each state machine of the MSSP control process 26, there are some strategic locations where important information becomes available or critical decisions are made. These locations are called detection points, and a detection point (DP) is a defined location in the state machine of the controlling entity. At this location, application event reporting and/or control is feasible and can be managed through API 28.

Event detection point (EDP) is a detection point equipped in the existing control dialogue environment. There is no clear standard for event detection points, and can only be applied to a specific state machine instance of the control entity that generates the control dialog. Normally, the event detection points set in a control dialog will not affect the behavior of any other instances of the state machine. A complete set of detection points in a specified state machine is called a detection point class.

One of the most commonly used Internet protocols is the Transmission Control Protocol (TCP) defined in IETF RFC 793. The following will discuss the use of TCP detection points for demonstration. Of course, other protocols will also be used.

TCP provides a reliable, connection-oriented communication path between two application processes (usually a client and a server). Before any data exchange, the client initiates the connection, and the server accepts the connection. The TCP protocol guarantees that all sent data can be correctly received by the other party in the order in which they were sent.

To initiate a TCP connection to the server, the client sends an IP packet to the server's IP address. The packet contains a TCP header with the "SYN" flag set, and specifies the port number of the server application that it wants to connect to. The server accepts the connection by returning a similar SYN packet to the client, and the client confirms that it has received the "SYN" from the server by sending an IP packet containing the TCP header with the "ACK" flag set.

The packet passes through the MSSP control process 26 in the MSSP server 22, and is transmitted between a client such as the MS 12 and a server (not shown) located on the Internet 24. By checking the IP header of the packet, the MSSP control process 26 determines that the IP packet encapsulates TCP data and distributes this packet to the TCP control logic. Combining the data in the IP header and checking the data in the TCP header, the TCP control logic can distinguish each segment established by the connection.

For example, if one of the business applications 30 wants to "intercept" TCP connections to a specific server on the Internet 24, and redirect these connections to different servers on the Internet 24, it may be based on the current server load conditions. Knowledge of business applications. The business application 30 can instruct the MSSP control process 26 to generate a trigger through the API 28, and the trigger searches for TCPSYN packets with addresses that match the server to be monitored. This is called the initial detection point (IDP). IDP is such a detection point, when the conditions meet the given standard criteria, the detection point is equipped (arm) in order to generate a new control dialogue with the application.

Continue to process all other TCP packets and TCPSYN data sent to different destinations normally. However, a TCP SYN packet with an address matching the equipped standard standard causes the processing of the packet to be suspended, and an IDP event notification is sent to the service application 30 equipped with IDP through API 28.

The IDP event notification may include, for example, information from the suspended packet, and the service application 30 will use this information to determine the correct purpose of the connection. Then, the service application 30 instructs the MSSP control process 26 to resume the processing of the packet through the API 28 with a different destination address. The MSSP control process 26 forwards the modified TCP SYN packet to the new destination address, where the server responds in the usual way. The participation of the business application is completely transparent, that is to say, neither the client such as the MS 12 nor the server (not shown) on the Internet 24 is aware of the occurrence of the redirection.

The business application 30 interacts with the MSSP control process 26 by exchanging TCP/IP messages. The API 28 listens for connections from the business application 30. When the application connection is established, the API 28 authenticates the identity of the connected business application 30 and searches for the characteristics that the application is authorized to access.

Once the communication session between the service application 30 and the API 28 is established, the service application 30 requests a list of services that it wants to provide from the MSSP control process 26, and then arm the initial detection points required to execute these services. Thereafter, when the service application 30 has packet data matching the equipped standard, the service application 30 waits for the MSSP control process 26 to signal.

When the MSSP control process 26 signals an IDP event, the business application 30 applies its business logic (not shown) through the API 28. In addition to directing the packet to the selected destination address, the business logic can configure additional metering for the packet flow that encounters the detection point, request additional event reports from the packet flow, and indicate the charging scheme applicable to the packet flow , Request periodic charging notification events, or request flow statistics.

For example, using the active service filtering API 28 request message, the default behavior of the service interaction between the MSSP control process 26 and the service logic of the application 30 can be specified, without the need to implement trigger detection points. The source address, source port, and destination address string in the protocol port and the data part of the packet are used to match incoming requests and determine whether to perform a predefined service interaction. If a flow meets the standard, the actions specified in the memo of the message will be performed. The prescribed actions can include, for example, event reporting, and redirecting a certain request to a specified redirection address and port number.

In another example, when the IDP is detected, the business logic starts to execute. The business logic receives the event notification and informs that the detection point is encountered. If the detection point is registered as a request detection point, when the MSSP requests an instruction within the timeout period, the business logic responds. The response can modify the packet and then forward it, or release the stream or session, or redirect or use a connection request to connect the packet. Other requests for programmatic policy filters to be applied to streams or sessions are also possible. When a detection point is encountered, the business logic can optionally use a business filter request to specify the business interaction to be performed.

For example, the API 28 provides a connection request message to instruct the MSSP control process 26 to establish a connection to a specified destination address on a certain flow, and the flow is suspended at a certain trigger point. The destination address can be different from the destination address in the packet matching the trigger condition. This allows the business logic in the business application 30, for example, to route these connections to the best available resources.

The API 28 provides a release stream message, instructing the MSSP control process 26 to terminate the active stream. The MSSP control process 26 will terminate the stream and provide any event or metering messages after confirming the termination.

Therefore, using API 28, the business application 30 manages and controls the following: the hosted packet-switched data service, which includes any and all special network addresses that identify the packet-switched data service; decides how to direct users, and direct users to The policy decision of which packet to switch the data service provider (that is, a specific server on the Internet); and the policy decision of which sponsor to charge for the session and on what basis. Policy filters can be used to block IP services based on ports, protocols, IP addresses, and cookies, and can also block IP services based on other layer seven protocol characteristics (layer seven protocol characteristics). Policy filters also allow business logic to create and manage wall gardens or subscription based models. The policy filter is dynamic in nature, allowing new services to be dynamically ordered and updated by the business logic.

The selection and billing policy decision may include the rules for the formation of a pre-agreement between the operator and a third party (either the sponsor or the service provider), which is about the selection of the service provider And the method and basis of paying the sponsor. According to the following factors, such as user identity, user's location, date, user category, service provider category, network conditions, the rules of the previous agreement, and/or government rules and regulations, the business to be connected to can be determined at the time of business request The providers strategic decision. For example, the service request can be based on similar factors, such as user identity, user location, date, user category, service provider category, network conditions, rules of the previous agreement, and/or government rules and regulations. The sponsor and the base billing strategy decision.

Business interaction is defined by business logic, and has a beginning, middle, and end. When a detection point is encountered, an IDP (Initial Detection Point) event sent to the business logic is usually used to identify the beginning of a business interaction. When the business logic has no events to register or the business logic explicitly terminates the conversation, the business interaction will end. The business interaction is bounded by the event sequence and the received API call, and is carried out by the business logic between the IDP and the terminal event. Business interaction is usually a chargeable event, which causes the business logic to be written into the CDR after the interaction ends. The detailed content of the business interaction boundary is defined by the business logic. For example, when the report IDP matches the request, the stock quote service starts and ends with a response containing the quote. This example can be extended to, for example, file downloads and e-mail sending. MSSP provides means to detect and control business interactions, and business logic is responsible for making API calls and processing events to complete the business.

Referring to FIG. 2, taking TCP as an example, the monitoring process 50 includes a service application startup phase 52, a service initialization phase 54, a service deployment phase 56, a service logic phase 58, and a termination phase 60.

Referring to FIG. 3, the service application startup phase 52 includes initializing (step 70) the transport layer. The transport layer is initialized (step 70) by creating a TCP/IP socket and connecting the socket through API28. Phase 52 initializes (step 72) the session layer. The initialization (step 72) includes sending a session open request to the MSSP server 22, and the MSSP server 22 authenticates the application credentials. The session open confirmation is received from the MSSP server 22. Phase 52 initializes (step 74) the application layer. Initialization (step 74) includes sending a negotiated API version request and receiving a negotiated API version confirmation. Send and confirm the open request.

Referring to FIG. 4, the service initialization phase 54 includes sending (step 80) a request to obtain a service list, and the MSSP server 22 searches for various services for the application. Stage 54 receives (step 82) the confirmation of obtaining the service list, and sends (step 84) the detailed request for obtaining the service; the MSSP server 22 searches for configuration data for the service. The stage 54 receives (step 86) the confirmation of obtaining the detailed service request.

Referring to FIG. 5, the service application deployment phase 56 includes sending (step 90) a request for IDP provisioning, and receiving (step 92) a confirmation of IDP provisioning. The MSSP server 22 verifies that the equipped standards meet any restrictions configured for applications and services, and programs the ICP standards into the MSSP server 22.

Referring to FIG. 6, the business logic stage 58 includes receiving (step 100) an initial DP event. Stage 58 determines (step 102) a new destination address for the user connection, and sends (step 104) a connection request to the new destination address. Phase 58 receives (step 106) a connection confirmation.

Referring to FIG. 7, the stop phase 60 includes sending (step 110) a request to release the IDP, and receiving (step 112) a confirmation to release the IDP. Stage 60 sends (step 114) a close request and receives (step 116) a close confirmation. Stage 60 sends (step 118) a session close request, and receives (step 120) a session close confirmation, and closes (step 122) the TCP/IP socket.

Referring to Figure 8, Table 130 lists a set of data types used by AIP28 to define fields in messages. Table 130 includes data type name 132, definition 134, and byte size 136. CHAR[n] refers to a UTF-8 character string. UTF-8 is a character encoding scheme in which the entire ASCII character set is encoded into one byte in the same encoding method as ASCII, and it also allows the use of multi-byte sequences to encode all Unicode characters. In the section sequence, no byte contains an ASCII character value.

All digital data longer than one byte are sent in the normal network byte order defined by the TCP/IP standard, that is, the order from the most significant byte to the least significant byte. It should be noted that in order to ensure the correctness and portability of applications, application developers are encouraged to use the host-to-network and network-to-host conversion functions of their platform (such as htonl() and ntohl()), even if they know that the host platform uses network words Section order. htonl() is an example of the UNIX function, which converts a 32-bit (4 byte) number from the host byte order to the network byte order, ntohl() is also an example of the UNIX function, which converts the network byte order The 32-bit number is converted to host byte order.

Referring to FIG. 9, the communication path 140 (shown by the arrow) between the application program 30 and the MSSP server 22 uses a hierarchical structure. The application program 30 communicates to the corresponding lower layers 154, TCP of the MSSP server 22 through its system application layer 142, presentation layer 144, session layer 146, transport layer 148, TCP/IP layer 150, and lower layers 152. /IP layer 156, transport layer 158, session layer 160, presentation layer 162, and application layer 164 transmit data.

The transport layer 158 is used to provide reliable transmission to the session layer 160. Since it is located on top of the local TCP/IP layer 156, the TCP/IP layer definition is reliable, so the transport layer 158 is relatively light. The transport layer 158 receives the message from the session layer 160 and then sends the message out. The transport layer 158 divides the byte stream provided by the TCP/IP layer 156 into messages framed by transport headers.

Generally, a frame is the data transmitted between network nodes as a complete unit including addressing and necessary protocol control information. The frame is usually transmitted continuously bit by bit, and contains a header field and a tail field used to "frame" the data.

Fig. 10 shows the process in which the TCP/IP byte stream is divided into several session messages by the transport layer. Unlike other protocols, the frame tag itself does not define the boundaries of the transmitted message header. In the absence of negative effects or special encoding, the frame mark data pattern can also be placed elsewhere in the TCP/IP byte stream. Frame markers provide a means to detect common programming errors (such as incorrect byte order or length calculation errors). These programming errors may cause the receiver to incorrectly interpret other data as the header of the transmitted message and take inappropriate actions.

API 28 uses the 8-byte transmission message header as the first element in the message. The 8-byte transmission message header includes a 4-byte INIT "framemarker" field, which is a constant used to verify the existence of a valid transmission message header. Any other value can indicate a message framing error. The 8-byte transmission message header also includes a 4-byte "messagelength" field and contains the UNIT data type, which indicates the length of the subsequent message data in bytes.

API 28 uses a session-level interface built on the reliable TCP/IP transport layer to ensure the arrival of messages. The session layer provides a set of session-level services to the application layer. These services include authentication, session-level heartbeat, and session-level confirmation.

Usually, the heartbeat monitors the status of the communication link and identifies the time when the last message string is not received. When either end of the connection does not send any data within the specified few seconds, it should send a heartbeat message. When either end of the connection does not receive any data within the specified few seconds, it should send a test request message. If the heartbeat message is still not received after the same time, the connection is considered lost and corrective action is taken.

All messages exchanged at the session layer include a header with 4 USHORT 2-byte fields as the first element in the message. The title refers to the title of the session message, including the SessionMessage type field, the SessionSendSeqNo field, and the SessionReceiveSeqNo field.

The SessionMessage type field contains values that identify the message type and message data format. The SessionInstance field contains a value that uniquely identifies the session instance. The SessionReceiveSeqNo field contains the sending sequence number of the message. The SessionReceiveSeqNo field contains the sending sequence number from the last received message.

All conversation messages include a pair of serial numbers in the header of the conversation message. These serial numbers are set by the sender and verified by the receiver. Each sender starts from zero and increments the sequence number sent for each message sent. In addition, each sender keeps track of the SessionSendSeqNo that it wants to receive next. Each message sent includes this number pair. The sequence number is used to detect lost session messages and provide a means to confirm data reception. If the session is idle for the SessData message, the sequence numbers are exchanged periodically in the session heartbeat message to ensure that these sequence numbers are kept up-to-date.

The session layer protocol version is negotiated during the open sequence. The client specifies the desired protocol version to be used during the session. At the beginning, the customer specifies the highest version of the protocol it supports. The server checks the requested version number and compares the version number with the version it supports. If the requested version is within the range of the version supported by the server, it is indicated in the subsequent SessOpenConf message that the version is accepted. If the version requested by the client exceeds the range supported by the server, the server responds with a SessOpenConf message, indicating that the session has been established using the highest version supported by the server. This version is different from the version originally requested by the customer. If the server cannot find a commonly supported protocol version, it will send a SessError message with the error code "MSSP_E_INVALID_VERSION" and close the session.

Likewise, session layer options are negotiated during the open sequence. The client specifies the desired protocol options to be used during the session. Customers should always initially specify all the options they support. The server checks the requested option mask and selects the options it supports. The final common conversation option is communicated to the customer in the subsequent SessOpenConf message. If the client cannot operate because the server reduces the options, the SessError message with the error code "MSSP_E_INVALID_OPTIONS" is sent, and the session is closed.

Similarly, the heartbeat interval is also agreed during the open sequence. The client specifies the desired heartbeat interval in the SessOpenReq message, and in the subsequent SessOpenConf message, the server responds with the heartbeat interval to be used by the client.

The client and server exchange various credentials during the session establishment sequence. The client provides an encrypted session security descriptor, which is the MD-5 message digest of the SessOpenReq message (excluding the SessionSecurityDescriptor field), and uses the private key in the public/private key pair to perform the message encryption. The MD5 message format is designed by "RSA Data Security (RSA Data Security, Inc.)". The message format is specified in the IETF RFC It is defined in 1321 (see www.ietf.org). Since a given application may open its session in the same way every time, in order to prevent the generation of a "constant" message digest value and to prevent the generation of a predictable session security descriptor, the message contains a random number field. The configuration of the MSSP server 22 application contains the public key of the public/private key pair. When receiving the security descriptor in the SessOpenReq message, the server queries the application in the MSSP server 22 configuration, obtains the client's public key, uses the public key to decrypt the given security descriptor, and verifies the decrypted result and the received message Whether the generated MD5 message digest matches exactly. If the credential is invalid, the server responds with a SessError message with the error code "MSSP_E_AUTH_FAILURE". If errors occur one after another within a unit of time, the server will suspend monitoring of connection requests for no less than one minute.

If the certificate is valid, the server provides the client with an encrypted session security descriptor (SessionSecurityDescriptor) in the SessOpenConf message, which is the MD5 message digest of the SessOpenReq message (excluding the SessionSecurityDescriptor field), using the private key of the public/private key pair to the message Encrypted. The client uses the server's public key to decrypt the descriptor and authenticate the server. If the validity of the server credential fails on the connected client, the client sends a SessError message with the error code "MSSP_E_AUTH_FAILURE". If errors occur one after another within a unit of time, the client suspends the connection request in no less than one minute.

The SessOpenReq message is used to start the session-level information exchange between the application and the API 28. The SessOpenReq message is the first message after the above-mentioned transport layer connection is established. The SessOpenReq message has the following format: an 8-byte SessionHeader field, which is a session header with a SessionMessageType equal to Sess_Open_Req. A 4-byte UNIT SessionVersion field indicates the session protocol version supported by the client. A 4-byte UNITSessionOptionsMask field indicates a bitwise combination of all session layer options supported by the client. A 4-byte UNIT The SessionHeartbeatlnterval field indicates the nominal time interval between the exchange of session heartbeat messages, in seconds. A 4-byte UINTSessionApplicationID field represents a value determined by the MSSP server 22, and the value is used to uniquely identify the client's application in the MSSP server 22. A 4-byte UNITSessionRandonNum field represents any unforeseen value and is used to prevent a foreseeable SessionSecurityDescriptor. A 16-byte BYTE[16]SessionSecurityDescriptor field represents the session security descriptor. The descriptor is the MD5 message digest of the message (excluding this field). The message is encrypted using the client's private key of the public/private key pair. The server uses a copy of the client's public key to decrypt the session security descriptor to authenticate the client.

The SessOpenConf message is used to complete the establishment of the session and notify the result of the negotiation parameters. The message is sent as a successful response to the SessOpenReq message. The message has the following format: an 8-byte SessionHeader field, indicating a session header with SessionMessageType=SESS_OPEN_CONF. A 4-byte UNIT SessionVersion field indicates the session protocol version selected by the server. A 4-byte UNITSessionOptionsMask field indicates a bitwise combination of all client session layer options selected by the server. A 4-byte UNIT SessionHeartbeatlnterval field, representing the nominal time interval between session heartbeat message exchanges, in seconds. A 4-byte UNITSessionServerID field represents a value that uniquely identifies the instance of the MSSP server 22. A 4-byte UNIT The SessionRandonNum field represents any unforeseen value and is used to prevent the foreseeable SessionSecurityDescriptor. A 16-byte BYTE[16]SessionSecurityDescriptor field, representing the session security descriptor, which is the MD5 message digest of the message (excluding this field), and the private key in the public/private key pair of the server is used for the message Encrypted. The client should use a copy of the server's public key to decrypt the session security descriptor to authenticate the server.

The session requires the client and server to participate in the session maintenance program. The session maintenance program ensures that inactive or idle sessions can run, and the response time is within a reasonable range. The session maintenance program runs independently, regardless of whether other data is sent in the session. The session maintenance program includes the exchange of SessHeartbeatReq messages, followed by SessHeartbeatConf messages. The session maintenance program is started from the connected client by sending a SessHeartbeatReq message. The server performs a set of operations to ensure that the server is running correctly, and when everything is normal, it returns a SessHeartbeatConf message. If the server does not respond within the heartbeat interval, the client invalidates the session by sending a SessError message with the error code "MSSP_E_HEARTBEAT_TIMEOUT" to the server. When a session is established, the client sends a heartbeat request at the periodic interval specified in the SessOpenConf message. The first client heartbeat is sent when a SessOpenConf message is received. To send a SessHeartbeatReq message, set the client timer to the heartbeat interval. When the timer expires, send a SessHeartbeatReq message. The server expects to see heartbeat requests within the specified heartbeat interval. The server sets a timer after sending the SessOpenConf message, and sets the timeout period to twice the heartbeat interval. If the heartbeat request is not received before the timer expires, the server invalidates the session by sending a SessError message with the error code "MSSP_E_HEARTBEAT_TIMEOUT". Every time a new heartbeat request is received, the server-side timer is reset. At any given moment, only the heartbeat is outstanding. Note that the heartbeat message is also used to confirm the DATA message or to detect errors related to the error management of the sequence number on the idle session connection.

The SessHeartbeatReq message is used to request to verify that the conversation party is operating normally. The message has the following format: an 8-byte SessionHeader field, indicating a session header with SessionMessageType=SESS_HEARTBEAT_REQ. A 4-byte UNITSessionHeartbeatInstance field indicates the value that uniquely identifies the specified heartbeat in the session. A 4-byte TIME SessionTimeStamp field indicates the time when the heartbeat request was issued. A 4-byte UNIT SessionHeartbeatlnterval field, representing the nominal time interval between session heartbeat message exchanges, in seconds. When the sender expects to negotiate a new heartbeat interval, the heartbeat interval may be different from the current heartbeat interval.

The SessHeartbeatConf message is used to complete the verification of the normal operating state of the conversation party. This message is sent as a successful response to the SessHeartbeatReq message. The SessHeartbeatConf message has the following format: an 8-byte SessionHeader field, indicating that the SessionMessageType is equal to SESS_HEARTBEAT_CONF with a session header. A 4-byte UNITSessionHeartbeatInstance field indicates the same SessionHeartbeatInstance value given in the corresponding heartbeat request. A 4-byte TIME SessionTimeStamp field indicates the same SessionTimeStamp value given in the corresponding heartbeat request. A 4-byte UNIT SessionHeartbeatInterval field, representing the nominal time interval between session heartbeat message exchanges, in seconds. When a new heartbeat interval has been agreed, the heartbeat interval may be different from the current heartbeat interval.

After a successful session is established, the client or server can close the session at any time. The client or server initiates the closing procedure by sending a SessCloseReq message to the conversation partner. The SessCloseReq message contains a code indicating the reason for closing. The party requesting the conversation closes (in the sense of the socket) the transport layer after sending the SessCloseReq message. The receiving conversation party notifies the application layer to allow any pending requests to be completed on the conversation. The query session message is sent before the SessCloseConf message is sent. Once the SessCloseConf message is sent, the transmission connection is stopped, and the socket connection is closed from the end that requested to close the session. If the server does not respond within a reasonable time, the client can determine that the shutdown request has timed out. If the closing request is set as a timeout by the client, a SessError message with the error code "MSSP_ECLOSE_TIMEOUT" is sent to the server. If the session has not been opened before the closing request, the conversation party cannot process the closing request, then a SessError message with the error code "MSSP_E_NO_SESSION" is sent to the requesting party. If the session is in the active or initialized state and the session party cannot process the closing request for any reason, the receiver sends a SessError message with the error code "MSSP_E_UNSPECIFIED_FAILURE" to the requester.

The SessCloseReq message is used to initiate the orderly termination of the session. The message has the following format: an 8-byte SessionHeader field, indicating a session header with SessionMessageType=SESS_CLOSE_REQ. A 4-byte UNITSessionCloseReasonCode field indicates the value of the reason for closing the session. For example, MSSP reason codes include normal operation, some details of normal operation, normal stop, user logout, stream timeout, and session timeout.

The SessCloseConf message is used to complete the orderly termination of the session. The message is sent as a successful response to the SessCloseReq message. The message has the following format: an 8-byte SessionHeader field, indicating a session header with SessionMessageType=SESS_CLOSE_CONF.

One of the purposes of establishing a session is to exchange data between the client and the server. After completing the session opening sequence, data messages can be exchanged between the parties. The session layer does not interpret data messages. The received data message is forwarded to the application layer for processing. Only the bytes contained in the SessionData field of the SessData message are forwarded to the application layer. This can effectively eliminate the conversational part of the message before it is delivered to the application. The message received from the transport layer also does not have any transport layer header or data, and the message is complete before processing. The reverse is also true when transferring data. The session layer encapsulates the application data in the session data message and forwards it to the transport layer for transmission.

The SessData message is used to transmit application-layer data to the conversation party. The message has the following format: an 8-byte SessionHeader field, indicating a session header with SessionMessageType=SESS_DATA. A variable-length SessionData field indicates the data to be transmitted to the application layer.

Due to communication or process failures, the session will become invalid at any time. If the session fails, in the case that the session party detects the failure, the failure is reported asynchronously. The client or server can send SessError messages. After the SessOpenReq message, a SessError message can be sent from the client at any time. The SessError message is sent from the server at any time, and the message includes the response to the SessOpenReq message. The SessError message contains an error code indicating the cause of the failure. The conversation party may also receive or not receive SessError messages, depending on the nature of the error. After the transmission or reception of the SessError message, data can be sent without using the session, and the underlying transmission connection should be stopped and closed.

The SessError message is used to notify the conversation party of an error condition, which will prevent further session-level communication; the message has the following format: an 8-byte SessionHeader field, indicating a session header with SessionMessageType=SESS_ERROR. A 4-byte UNIT SessionErrorCode field indicates the value of the cause of the session failure.

Figure 11 shows a table 170 containing exemplary error codes.

The performance of the MSSP server 22 can be grouped according to characteristic types. When the application 30 opens a session with the MSSP server 22, the application 30 specifies its desired characteristics through the API 28. Each MSSP feature has a corresponding privilege bit. The configuration items in the MSSP configuration database 32 located in the MSSP storage device 34 contain a set of feature privileges that control the features used by the authorized application 30. Only requests for authorized features of the application 30 are permitted, and in the response to the request, the application 30 is notified that these features have been successfully acquired. The application that attempts to use the message within the feature category for which no privilege has been granted is rejected through a privilege error (code).

Table 180 in FIG. 12 lists the characteristic types. Feature categories include public service feature category 182, initial detection point feature category 184, event report feature category 186, service filtering feature category 188, metering configuration feature category 190, billing notification feature category 192, billing plan feature category 194, and detailed records Control feature category 196, statistical feature category 198, and application monitoring feature category 200. Messages related to feature categories 182-200, according to their different formats, are listed in Appendix A and become part of this article by reference.

Other embodiments are within the scope of the claims.

Appendix A Public Service Description: The messages in this part are public to all applications that use the API, and have nothing to do with the privileges of the application.

Privilege requirements: None.

Message list: MSSPNegotiateAPIVersionReq, MSSPNegotiateAPIVersionConf, MSSPOpenReq, MSSPOpenConf, MSSPCIoseReq, MSSPCloseConf, MSSPFailureConf, MSSPFailureEvent, MSSPGetSystemTimeReq, MSSPGetSystemTimeConf, MSSPGetServiceListReq, MSSPGetServiceListConf, MSSPGetServiceListReq, MSSPGetServiceListConf, MSSPGetServiceListReq.

MSSPNegotiateAPIVersionReq description: This message is sent by the application to MSSP22, indicating the API version to be used for application-level communication. Due to the different formats of the messages, the API version must be negotiated before any other application messages are exchanged. It is only guaranteed that MSSPNegotiateAPIVersionReq, MSSPNegotiateAPIVersionConf and MSSPFailureConf have the same message format in all API versions. This is the first message that should be sent after the communication session is established as described earlier.

MSSP22 answers with MSSPNegotiateAPIVersionConf message, stipulating that the negotiated API version should be used for all further application messages. This is the highest API version supported by MSSP 22 that is lower than or equal to the version requested by the application. If neither of the parties can identify the API version, an MSSPFailureConf message containing the error code MSSP_E_INVALID_VERSION will be returned from MSSP 22.

Message flow chart:

Message format:

MSSPNegotiateAPIVersionReq message format MSSPNegotiateAPIVersionConf description: MSSP 22 sends this message to confirm the receipt of the MSSPNegotiateAPIVersionReq request message and to provide the API version selected for all further application layer messages.

Message format:

MSSPNegotiateAPIVersionConf message format MSSPOpenReq description: This message is used to start application-level information exchange between the application and MSSP 22. This is the first message that should be sent after the above-mentioned API version is determined. The application uses this message to request access to one or more MSSP 22 functions.

Message flow chart

Message format:

MSSPOpenReq message format

MSSP 22 functional mask MSSPOpenConf description: MSSP 22 sends this message to confirm the reception of the MSSPOpenReq request message. This message indicates which services requested in the MSSPOpenReq request message have been authorized to use.

Message format:

MSSPOpenConf message format

MSSPCIoseReq description: This message is used to terminate the application-level information exchange between the application and MSSP 22.

Message flow chart:

Message format:

MSSPCloseReq message format MSSPCIoseConf description: MSSP 22 sends this message to confirm the reception of the MSSPCIoseReq request message. No other application-level messages will be sent or received from the MSSP 22 anymore.

Message format:

MSSPCloseReq message format MSSPFailureConf description: When an error condition successfully prevents the processing of the previous application request message, MSSP22 sends this message. The message contains the RequestID specified by the application request message and an error code indicating the cause of the failure.

Message format:

MSSPFailureConf message format MSSPFailureEvent description: MSSP 22 sends this message when the error condition that occurs is not directly related to the previous application request message. The message contains an error code indicating the cause of the failure.

Message format:

MSSPFailureEvent message format

MSSPGetSystemTimeReq Description: This message is used to request the current time from MSSP 22.

Message flow chart:

Message format:

MSSPGetSystemTimeReq message format MSSPGetSystemTimeConf description: MSSP 22 sends this message in response to the MSSPGetSystemElmeReq request message.

Message format:

MSSPGetSystemTimeConf message format

MSSPGetServiceListReq description: Use this message to request a list of MSSP 22 service identification codes provided by the application.

Message flow chart:

Message format:

MSSPGetServiceListReq message format MSSPGetServiceListConf description: Description: MSSP 22 sends this message in response to the MSSPGetServiceListReq request message.

Message format:

MSSPGetServiceListConf message format MSSPGetServiceDetailReq description: sending this message is used to request the detailed information of the specified MSSP 22 service configuration. The application may only request the detailed information of the service provided by its configuration.

Message flow chart:

Message format:

MSSPGetServiceDetailReq message format MSSPGetServiceDetailConf description: MSSP 22 sends this message in response to the MSSPGetServiceDetailReq request message.

Message format:

MSSPGetServiceDetailConf message format MSSPServiceRemovedEvent description: When the application is still connected to MSSP 22, if a service is cancelled from the services provided by the application configuration, MSSP 22 sends this message. MSSP 22 automatically releases service resources (such as detection points) used by any application.

Message format:

MSSPServiceRemovedEvent message format

MSSPResourceUnavailableEvent description: MSSP 22 sends this message when a fault condition or MSSP 22 hardware reconfiguration causes the resources used by the application to be unavailable. The MSSPResourceAvailableEvent message is sent when the resource is restored to a normal state.

Message format:

MSSPResourceUnavailableEvent message format MSSPResourceAvailableEvent description: MSSP 22 sends this message when the previously reported unavailable resource in the MSSPResourceUnavailableEvent message returns to a normal working state.

Message format:

MSSPResourceAvailableEvent message format Initial detection point (IDP) function description: This part of the message allows the application to configure and release the initial detection point in MSSP 22 and service-related IDP events.

Privilege required: IDP.

Message list: MSSPArmlDPReq, MSSPArmlDPConf, MSSPDisarmlDPReq, SSPDisarmIDPConf, MSSPInitialDPEvent, MSSPContinueReq, MSSPContinueConf, MSSPConnectReq, MSSPConnectConf, MSSPReleaseReq, MSSPReleaseConf, MSSPActivityTestReq, and MSSPActivityTestConf.

Message flow chart:MSSPArmlDPReq description: This request is used to identify the initial detection point and specify the traffic standard that causes the notification application. According to the setting of the TakeControl field, the initial detection point can be configured for simple event notification or as a trigger.

Set the TakeControl field to MSSP_TRIGGER, and configure the trigger.

When the flow encounters a detection point with a trigger, it stops forwarding packets and notifies the application. The application controls the resume packet forwarding by responding with one of the following requests: MSSPContinueReq, MSSPConnectReq, MSSPControlReq, or MSSPReleaseReq.

These requests instruct MSSP 22 how to work and send packets in the stream accordingly. The application must respond to the trigger immediately. The delay between the trigger and the related response is measured by the service and the application. If it cannot respond within 1000 milliseconds, MSSP 22 will increment the service and application trigger timeout counter and resume normal grouping. Processing is like receiving a "continue" response. If the equipped detection point is only used for event notification, the event notification will be sent to the application, as in the case of the trigger, unless the packet forwarding is not stopped and the application's response is not expected.

The standard string may include a wildcard value, which is used to specify the range of each trigger. When the IDP is successfully equipped, MSSP 22 sends an MSSPArmlDPConf message. Conversely, if the fault condition prevents the IDP from being equipped, the MSSPFailureConf message is returned to indicate the cause of the fault.

Message format:

MSSPArmIDPReq message format

The following sections describe each detection point class in more detail. In each section, while describing the attributes and equipment standards related to each inspection point, a list of inspection points is listed. The detection point with the "IDP" attribute can be used as the initial detection point, and the detection point with the "Trigger" attribute can be used as a trigger or an event report. Detection points not listed in the "Trigger" attribute can only be used to provide incident reports.

Conversation group detection point class When the limit of multiple user groups is exceeded, this detection point class allows the application to execute policy decisions. The application provides limit values in the IDP equipment standard. If equipped with IDP as a trigger, the application can send a Continue or Release trigger response to decide whether to allow the limit to be exceeded.

Session group detection point IDP event Note: The NumericValue1 and NumericValue2 parameters in the Initial DP Event message contain the actual values of the parameters during detection and evaluation, not the limit values.

Standard note: All standards must be fully specified, and wildcard values must not be used.

Control operation: None.

Session detection point class This detection point class allows applications to monitor and control the establishment and termination of mobile user sessions. If the IDP is used as a trigger, the application can decide whether to continue the user session by sending a Continue or Release trigger response.

Standard remarks for session detection points: Wildcards can be specified for Operator and SubscriberGroupID. A zero-length StringValue can be specified as a wildcard, which matches any user.

Control operation: None.

RADIUS detection point class This detection point class allows applications to monitor and control the activities of the remote authentication dial-in user service (RADIUS) protocol for mobile user sessions. If IDP is used as a trigger, the application can issue control operations to control user access and change the attributes of RADIUS messages.

Standard remarks for RADIUS detection points: wildcards can be used for OperatorID and SubscriberGroupID. The zero-length StringValue can be used as a wildcard to match any user.

Control operation: The following control operations are defined:

RADIUS control operation DHCP detection point class This detection point class allows applications to monitor and control the dynamic host configuration protocol (DHCP) behavior of mobile user sessions.

DHCP detection point IDP event Remarks: The DestinationIP parameter in the initial DP event message from the detection point DP_DHCP_ACK contains the IP address assigned to the user.

Standard note: OperatorID can use wildcards. The zero-length StringValue can be used as a wildcard to match any user.

Control operation: None.

DNS checkpoint class This checkpoint class allows applications to monitor and control the behavior of the Domain Name System (DNS) protocol of mobile user sessions.

The control operation is defined as allowing the application to configure the IP address and resolve the mobile user DNS query.

DNS detection point IDP event remarks: The DestinationIP parameter in the initial DP event message from the DP_DNS_QUERY_RESPONSE detection point contains the IP address returned from the DNS server.

Standard note: OperatorID and SubscriberGroupID can use wildcards. StringValue can specify some wildcards in the format "*.Domain", such as "*.yahoo.com". The zero-length StringValue can be used as a wildcard to match any host.

Control operation: The following operations are defined:

DNS control operation TCP detection point class This detection point class allows applications to monitor and control the behavior of the Transmission Control Protocol (TCP) of mobile user sessions.

Standard remarks for TCP checkpoints: wildcards can be used for OperatorID, SubscriberGroupID, Session, SourcePort, and DestinationPort. SourceIPAddress and DestinationIPAddress can be used as partial wildcard IP addresses by specifying the number of address bits that must match (from left to right). A zero-length IP address can be used as a wildcard to match any IP address.

Control operation: None.

IP detection point class This detection point class allows applications to monitor and control the behavior of mobile user sessions at the lowest level, the Internet Protocol (IP) layer, and all other protocols are located on top of the Internet protocol.

Standard remarks for IP checkpoints: wildcards can be used for OperatorID, SubscriberGroupID, SessionID, and IPProtocolNumber (NumericValue1). SourceIPAddress and DestinationIPAddress can be used as partial wildcard IP addresses by specifying the number of address bits that must match (from left to right). A zero-length IPAddress can be used as a wildcard to match any IP address. The zero-length StringValue can be used as a wildcard to match any user.

When equipped with this level of detection points, you must be very careful, especially the use of wildcards, to avoid severely affecting the performance of the network (the application becomes a bottleneck, limiting the traffic of all Internet traffic). At the same time, it is possible to equip triggers with all standards as wildcards, but this is obviously inappropriate in the operating environment, so it is not recommended.

Control operation: None.

MSSPArmIDPConf description: MSSP 22 sends this message to confirm that the previous MSSPArmIDPReq message is successfully equipped with the initial detection point.

Message format:

MSSPArmIDPConf message format MSSPDisarmfDPReq description: This value is used to remove the initial detection point and discard the previously established service volume standard set.

Message format:

MSSPDisarmIDPReq message format MSSPDisarmIDPConf description: This message is sent by MSSP 22 to confirm that the previous MSSPDisarmlDPReq message successfully removed the initial detection point.

Message format:

MSSPDisarmIDPConf message format MSSPInitialDPEvent description: The initial detection point event is used to indicate that the conditions described by the standard have been met at the initial detection point equipped previously. The detection points are equipped to obtain visibility or control of the data flow that matches a specific pattern. Regardless of whether wildcards are used in the equipped standards, IDP event representation provides fully qualified data for all standards related to the detection point.

The initial detection points equipped with the TakeControl option set are called triggers. By setting the TakeControl flag to the MSSP_TRIGGER in the event message, the initial detection point event indicating that the trigger or event detection point has been encountered is sent to the relevant application to indicate whether the detection point is a trigger detection point.

The application must send the following request in response to the trigger detection event: MSSPContinueReq, MSSPConnectReq, MSSPControlReq, or MSSPReleaseReq.

For non-trigger initial detection point events, no response is required.

Message format:

MSSPlnitialDPEvent message format MSSPContinueReq description: This continuation request causes normal processing to restore the previously suspended packet at the trigger point. This request can be used to provide an application synchronization point at which the application can adjust the pace of each connection request. The packet to be processed and its related context are identified by the ControlID field in the request message.

If the ControlID is invalid, send an MSSPFailureConf message containing the error code MSSP_E_INVALID_CONTROL_ID as confirmation. If the ControlID is valid, but not waiting at the trigger detection point, send an MSSPFailureConf message containing the error code MSSP_E_INVALID_STATE as confirmation. If the continued operation is successful, the MSSPContinueConf message is sent to confirm that the packet processing has continued.

Message format:

MSSPContinueReq message format

The control flag MSSPContinueConf describes: MSSP 22 sends this message to confirm the successful continuation of the packet processing performed by the previous MSSPContinueConf message.

Message format:

MSSPContinueConf message format

MSSPConnectReq description: This connection request instructs MSSP 22 to establish a connection to the specified destination address for the previously suspended packet at the trigger point. The destination address may be different from the destination address in the packet matching the trigger condition. This allows applications to route connections to the best available resources and provides a means to virtualize Packet800 services.

The pending packet and its related context are identified by the ControlID field in the request message, and the destination address will provide the IP address and port number to establish the connection. EventReportMask and TriggerMask can be used to request subsequent event reports and triggers from the instance of the detection point class.

If the ControlID is invalid, send an MSSPFailureConf message containing the error code MSSP_E_INVALID_CONTROL_ID as confirmation. If the ControlID is valid, but not waiting at the trigger detection point, send an MSSPFailureConf message containing the error code MSSP_E_INVALID_STATE as confirmation. If the connection operation is successful, the MSSPConnectConf message is sent to confirm that the packet processing has resumed.

Message format:

MSSPConnectReq message format MSSPConnectConf description: MSSP 22 sends this message to confirm the successful execution of the previous MSSPConnectReq message.

Message format:

MSSPConnectConf message format MSSPControlReq description: send out this message to perform the control operation on the suspended group. The pending packet and its related context are identified by the ControlID field in the request message. If the ControlID is invalid, send the error code MSSP_E_INVALID_CONTROL_ID as confirmation. If the ControlID is valid, but not waiting at the trigger detection point, send an MSSPFailureConf message containing the error code MSSP_E_INVALID_STATE as confirmation. If the connection operation is successful, the MSSPConnectConf message is sent to confirm that the packet processing has resumed. If the ControlID is valid and waiting at the trigger detection point, send an MSSPFailureConf message containing the error code MSSP_E_INVALID_CONTROL_OP as a confirmation. If the control operation is successful, the part of the MSSPControlConf message sent specifies the general definition of the message, and all detection point classes share this definition. The memo of the message content is specific to each detection point class. These checkpoint-specific fields follow the general message format: each field is identified by a two-byte tag, followed by a two-byte long field that specifies the size of the following data in bytes, followed by the data. Each additional message field is simply appended to the message. The total length of the message (configured by the underlying transmission mechanism) can be used to determine the existence of these "floating" fields.

Message format:

MSSPControlReq message format

Control label MSSPControlConf description: This message is sent by MSSP 22 to confirm the successful execution of the previous MSSPControlReq message.

Message format:

MSSPControlConf message format

MSSPReleaseReq description: send this message to terminate the active stream. The stream to be terminated may be suspended or activated at the trigger point. After transmitting the MSSPReleaseConf message, MSSP 22 will terminate the stream and provide any event or metering messages. Sort before sending any events or metering messages caused by the termination of the flow. If the message is a response to a trigger, the pending packet and its related context are identified by the control field in the request message. If the ControlID value in the message is zero, the flow to be terminated (active) is identified by FlowID.

The ReasonCode field will contain a value indicating the reason for terminating the stream. The ReasonCode value will be stored in any detailed records generated for the stream. Send MSSPReleaseConf message to actively confirm the released stream operation. If the ControlID field is invalid, an MSSPFailureConf message containing the error code MSSP_E_INVALID_CONTROL_ID will be returned. If the FlowID field is invalid, an MSSPFailureConf message containing the error code MSSP_E_INVALID_FLOW_ID will be returned.

Message format:

MSSPReleaseReq message format MSSPReleaseConf

Description: This message is sent by MSSP 22 to confirm the successful execution of the previous MSSPReleaseReq message.

Message format:

MSSPReleaseConf message format MSSPActivityTestReq description: This request is used to check the status of the previously reported stream or session. If the specified stream is still valid (active), the MSSPActivityTestConf message is returned. If the flow identified by FlowID is invalid, an MSSPFailureConf message with error code MSSP_E_INVALD_FLOW_ID will be sent as confirmation.

Message format:

MSSPActivityTestReq message format MSSPActivityTestConf description: MSSP 22 sends this message to confirm the successful execution of the previous MSSPActivityTestReq message.

Message format:

MSSPActivityTestConf message format event report function description: This part of the message allows the application to request additional event reports following the initial detection point event. When the IDP that initiates the control dialog is a trigger, the application usually requests additional event reports through the EventReporfMask and/or TriggerMask fields in the MSSPContinueReq message or MSSPConnectReq message in response to the IDP event. When the IDP is not a trigger (that is, there are only event reports and no packet processing is suspended), the MSSPEventReportReq request is the only means to request additional event reports.

Privilege requirement: EDP.

Message list: MSSPEventReportReq, MSSPEventReportConf, MSSPEventReportEvent.

Message flow chart:

MSSPEventReportReq description: This message is used to equip the event report detection point. This detection point is only equipped as an event detection point for the specified flow. When the flow passes the control state specified in any event report or trigger mask, an event will be sent. When an incident report request is received, MSSP 22 will be equipped with a detection point and will send a confirmation, indicating that the operation is successful. If a failure occurs in the process of trying to equip the requested detection point, the MSSPFailureConf message will be returned to indicate the cause of the failure.

This request will result in the sending of an MSSPEventReportEvent message, indicating that the stream has transitioned to the specified state. This request is different from the MSSPAnmIDPReq request. It is used to change the event report of a single, existing stream, while MSSPAnnlDPReq requests to establish the starting point of the stream being monitored for the first time.

MSSP 22 automatically releases the event report detection point that remains after the stream is terminated. The MSSPEventReportReq request for a stream that has been equipped with event report detection points can replace the previous request. You can use MSSPEventReportReq without EventReportMask or TriggerMask to request cancellation of all previously requested event reports and triggers for this control dialog.

Message format:

MSSPEventReportReq message format MSSPEventReportConf description: This message is sent by MSSP 22 to confirm the successful execution of the previous MSSPEventReportReq message.

Message format

MSSPActivityTestConf message format EventReportEvent description: This message is sent by MSSP 22 to confirm the successful execution of the previous MSSPActivityTestReq message.

Message format:

MSSPEventReportEvent message format service filtering function description: This part of the message allows the application to specify the programming behavior of the detection point without the application's participation. The SourceIPAddress, SourcePort, DestinationIPAddress, and IPProtocolNumber fields will be used to match the incoming request to determine whether to perform a predetermined service interaction. The matching process is usually the same as that of the initial detection point, and wildcards can also be used for the matched fields.

If the stream meets the standard, the behavior specified in the memo of the message will be performed without the participation of the application. The prescribed actions include event reporting and redirecting the request to a specified redirection address and port number. If event reporting is required, use EventReportMask to determine which event of the stream will be reported in the future. The matched standard shall not overlap with the equipped inspection point standard. If the request cannot be completed for any reason, an MSSPFailureConf message with the matching request and an error code is returned. The error code indicates the nature of the failure. If the request is successfully completed, the MSSPAcKvateServiceFilterConf message is returned. Unless cancelled by MSSPCancelServiceFilterReq, service filtering is always active.

Privilege requirement: ServiceFilter.

Message list: MSSPActivateServiceFilterReq, MSSPActivateServiceFilterConf, MSSPCancelServiceFilterReq, MSSPCancelServiceFilterConf.

Message flow chart:

MSSPActivateServiceFilterReq description: This request is used to identify the initial detection point and specify the service volume standard that causes the application to behave as intended.

When the flow encounters the initial detection point with service filtering, and the condition meets the service filtering standard, the predetermined behavior in the service filter is applied to the group, and the processing of the group continues as instructed. The standard string can contain wildcards to specify a wider range of triggers. When the IDP successfully configures the service filter, MSSP 22 sends a MSSPActivateServiceFilterConf message. If the failure condition prevents the IDP from being configured, the MSSPFailureConf message is returned, indicating the cause of the failure.

Message format:

MSSPActivateServiceFiIterReq message format MSSPActivateServiceFilterConf description: This message is sent by MSSP 22 to confirm that the previous MSSPActivateServiceFilterReq message is successfully equipped with an initial detection point for service filtering.

Message format:

MSSPActivateServiceFilterConf message format MSSPCancelServiceFiIterReq Description: This request is used to cancel the service filter previously established by MSSPActivateServiceFilterReq.

Message format:

MSSPCancelServiceFilterReq message format MSSPCancelServiceFilterConf description: The message is sent by MSSP 22 to confirm that the previous MSSPCancelServiceFilterReq message successfully cancels service filtering.

Message format:

MSSPCancelServiceFi(terConf message format metering configuration function description: This part of the message allows the application to configure the data elements metered by MSSP 22. The metering configuration will affect the metering elements filled in the MSSPGetStatsConf and MSSPPeriodicStatsEvent messages, as well as the details stored in the MSSP 22 database Call list.

Privilege requirements: metering configuration.

Message list: MSSPConfigureMetersReq and MSSPConfigureMetersConf.

Message flow chart:MSSPConfigureMetersReq description: This message is used to configure the metering performed by MSSP 22 at the lowest level. The MeterClass field includes one of the following two values: MSSP_METER_CLASS_SESSION or MSSP_METER_CLASS_FLOW. The class field is used to indicate the scope of the measurement request. The ObjectID field will identify the instance of the object to be measured based on the MeterClass. For example, if the MeterClass is MSSP_METER_CLASS_SESSION, ObjectID represents the session identification code, and if the MeteringType is MSSP_METER_CLASS_FLOW, ObjectID represents the stream identification code.

The MetersEnabled field contains a one-bit mask that identifies the special meters available within the class range specified by the MeterClass field.

If the MSSPConfigureMetersReq request is sent to an object that has already configured metering, the MetersEnabled field specifies a new metering configuration for the object. The zero value of the mask position of the previously configured meter will make the meter unavailable, and the non-zero value of the mask position of the meter that has not been previously configured will make the meter available. The metering configuration will affect the metering elements, which are filled in the MSSPGetStatsConf and MSSPPeriodicStatsEvent messages, and stored in the detailed CDRs in the MSSP 22 database.

If the request is successful, MSSP 22 will process the request and return an MSSPConEgureMetersConf message as a positive confirmation. When the request is unsuccessful, an MSSPFailureConf message will be sent as a negative confirmation.

Depending on the invalid request parameter, the error code value will contain one of the following values: MSSP_E_INVALID_METER_CLASS, MSSP_E_INVALiD_FLOW_ID, MSSP_E_INVALID_SESSION_ID, or MSSP_E_INVALID_FLOW_METER_MASK.

Message format:

MSSPConfigureMetersReq message format

Measurement meta mask MSSPConfigureMetersConf description: MSSP 22 sends this message to confirm the successful execution of the previous MSSPConfigureMetersReq message.

Message format:

MSSPConfigureMetersConf message format charging notification function description: this part of the message allows applications to request byte-based reports. Reports can be requested by session or stream. Session-based charging notification will effectively result in the same charging notification standard applied to all flows in the session.

Registering for a charging notification event will result in the measurement of the number of bytes of the specified type transmitted in the uplink and downlink. Each time the reporting threshold is reached, MSSP 22 sends an MSSPNotifyChargeEvent message to the application, indicating the number of bytes transferred, resets the counter, and restarts counting. The charging notification continues until the stream is terminated or the charging notification is obviously cancelled by the MSSPCancelNotifyChargeReq request.

A packet is the atomic unit of counting, and each packet can arrive either before or after the count evaluation. Therefore, the billing notice may not appear exactly on the specified byte count. For example, if a notification is requested every 10 kilobytes, when the packet whose count exceeds 10 kilobytes is slightly larger than 500 bytes, the notification may appear on the 10.5th kilobyte. The MSSPNotifyChargeEvent message provides the actual counter value.

Privilege requirement: billing notice.

Message list: MSSPNotifyChargeReq, MSSPNotifyChargeConf, MSSPCancelNotifyChargeReq, MSSPCancelNotifyChargeConf, and MSSPNotifyChargeEvent

Message flow chart:

MSSPNotifyChargeReq description: This request is used to register a byte-based report, which is either on a session or per-flow basis. Sending the MSSPNotifyChargeConf message indicates that the charging notification is successfully available. If the billing notification is not available, send the STL_FAILURE_CONF message to indicate the failure, and the error code field will identify the cause of the failure.

Message format:

MSSPNotifyChargeReq message format MSSPNotifyChargeConf description: MSSP 22 sends this message to confirm the successful execution of the previous MSSPNotifyChargeReq message.

Message format:

MSSPNotifyChargeConf message format

MSSPCancelNotifyChargeReq description: This request is used to cancel the byte-based report created by the previous MSSPNotifyChargeReq request.

Message format:

MSSPCancelNotifyChargeReq message format MSSPCancelNotifyChargeConf description: MSSP 22 sends this message to confirm the successful execution of the previous MSSPCancelNotifyChargeReq message.

Message format:

MSSPCancelNotifyChargeConf message format

MSSPNotifyChargeEvent description: This message is used to notify the application that the previously registered charging notification threshold has been exceeded.

Message format:

MSSPNotifyChargeEvent message format charging scheme function description: this part of the message allows the application to show the cost of the provided service and record the used charging scheme in the MSSP 22 detailed record.

Privilege requirements: billing plan.

Message list: MSSPSetChargePlanReq, MSSPSetChargePlanConf.

Message flow chart:

MSSPSetChargePlanReq description: This message is used to record the charging plan used by the service in the MSSP 22 detailed record.

Message format:

MSSPSetChargePlanReq message format MSSPSetChargePlanConf

Description: MSSP 22 sends this message to confirm the successful execution of the previous MSSPSetChargePlanReq message.

Message format:

MSSPSetChargePlanConf message format detailed record control function description: this part of the message allows the application to control when MSSP 22 writes the detailed record.

Privilege requirement: DetailRecordControl.

Message list: MSSPWriteDetailRecordReq and MSSPWriteDetailRecordConf.

Message flow chart:

MSSPWriteDetailRecordReq description: This message allows the application to control when to write detailed records into the MSSP 22 database. The detailed record written by this request is automatically assigned a reason code MSSP_RC_PARTIAL_DETAIL. Partial detailed records are usually used to ensure that once an unrecoverable failure occurs, most of the recent behaviors of user interactions can be recorded for billing purposes.

Message format:

MSSPWriteDetailRecordReq message format MSSPWriteDetailRecordConf description: MSSP 22 sends this message to confirm the successful execution of the previous MSSPWriteDetailRecordReq message.

Message format:

MSSPWriteDetailRecordConf message format statistics function description: This part of the message allows the application to obtain various statistics of the session or flow managed by the application.

Privilege requirements: statistics.

Message list: MSSPGetStatsReqMSSPGetStatsConf and MSSPPeriodicStatsEvent.

Message flow chartMSSPGetStatsReq description: This request is used to request session or flow statistics. In addition to the current statistics, the request can optionally request future updates, either periodically or when the stream or session is terminated. The statistical value depends on the meter configured by the previous MSSPConfigureMetersReq request.

If the request is successful, MSSP 22 will process the request and return an MSSPGetStatsConf message with the current statistics value as a positive confirmation. In addition, if a future update is requested through the interval field Interval, an MSSPeriodicStatsEvent message will be sent. If the request is unsuccessful, an MSSPFailureConf message will be sent as a negative confirmation. According to the invalid request parameter, the error code contains one of the following values: MSSP_E_INVALID_STATS_TYPE, MSSP_E_INVALID_FLOW_ID, MSSP_E_INVALID_SESSION_ID, or MSSP_E_INVALID_INTERVAL.

Message format:

MSSPGetStatsReq message format MSSPGetStatsConf description: This request is used to return the statistics of the session or flow requested by the previous MSSPGetStatsReq. The statistical value depends on the meter configured in the previous MSSPConfrgureMetersReq request.

Message format:

The MSSPGetStatsConf message format has fields marked with *, and only when the corresponding measurement configuration is in MSSP 22 (as described in the EnabledMeterMask field) will it contain valid data.

MSSPPeriodicStatsEvent description: This request is used to return the periodic update of the stream or session requested by the previous MSSPGetStatsReq. The statistical value depends on the meter configured by the previous MSSPConfgureMetersReq request.

Message format:

The MSSPPeriodStatsEvent message format has fields marked with *, and only when the corresponding measurement configuration is in MSSP 22 (as shown in the EnabledMeterMask field) will it contain valid data.

Application monitoring function description: This part of the message allows the application to monitor the status of other applications connected to the same MSSP 22 instance.

Privilege requirements: application monitoring.

Message list: MSSPAppSessionEvent.

MSSPAppSessionEvent description: MSSP 22 sends this message to report the occurrence of an application session event. After the session is opened, the MSSP 22 immediately sends this message to the application enjoying the application monitoring privilege, notifying it of other application sessions (pre-existing).

Message format:

MSSPAppSessionEvent message format