WO2009065252A1 - A method and a device for controlling the overload on the network service device - Google Patents

Abstract

A method and a device for controlling the overload on the network service device are provided, and the method and device are provided controls the network service device to supply a service for a client terminal, wherein, simultaneously taking into account the overload information about the network service device, the service correlation information of the request transmitted from the client terminal and the prestored service control information to determined whether the network service device is allowed to supply service to the client terminal. So the overload controlling of the network service device can be carried out effectively.

Description

 Method and apparatus for network service equipment overload control

 The present invention relates to communication networks, and more particularly to overload control of network service equipment in a communication network. Background technique

 When an unexpected event (such as a flood, an earthquake, or a malicious act by a client) occurs, a high call request may occur in the communication network. During this high call request, network traffic is significantly higher than the predictable daily peak, and it may exhaust resources such as memory, CPU usage, or network bandwidth of network service devices.

 Thus, communication networks have recognized that an overload control mechanism needs to be provided to protect the system from the impact of excessive traffic loads.

 In the traditional intelligent network (IN), a service control node (SCP) based on an application server (a service device) can apply a gap message to the call to inform the monthly service exchange when it is in an overload state. How does the node (SSP) handle this?

^ Call. Specifically, the server uses information such as "called party number", "calling party number", "service key" as a key when performing overload control. For example, if the calling party number of an incoming call matches a pre-stored prefix and the pre-stored prefix corresponds to policy A, then policy A will be applied to control of the call (see 3GPP TS 29.078 7.3 for details). 1 ( 2006-06) 1 1.5).

 As the network evolves to IP-based Next Generation Networks (NGNs), application servers provide an execution environment for next-generation services. IETF RFC 3588 defines the Diameter base protocol, based on which a number of diameter related protocols are derived, such as RFC4005 for Diameter network access service applications, IETF RFC4006 for Diameter Credit Control Application (DCCA), for Diameter scalable Authorization protocol application IETF RFC4072 and so on. In the following, the Diameter base protocol and the diameter related protocol will be collectively referred to as the diameter protocol. Currently, the 3GPP standards group has widely adopted these IETFs.

Confirmation The diameter protocol is used in a variety of next-generation network applications. Figure 1 is a schematic illustration of various applications based on diameter. For example, based on IETF RFC4006 DCCA, 3GPP has developed various online charging RO interfaces for online charging systems, such as IMS Ro (3GPP TS 32.260), MMS Ro (3 GPP TS 32.270) and WLAN Ro (3 GPP TS 32.252). Wait.

 However, so far, the diameter protocol has not defined a practical overload control mechanism. Thus, once an application server is overloaded, a large number of call attempts directed to the application server will fail because the application server does not have sufficient resources (such as CPU, memory, etc.).

 In fact, network operators may prefer to prioritize services that address certain special services, such as emergency calls, rather than rejecting all calls. Summary of the invention

 According to the aforementioned prior art, it can be seen that overload control is very important for network service devices (e.g., application servers). Accordingly, it is an object of the present invention to provide a method and apparatus for supporting overload control of a network service device, wherein both load information of the network service device, service related information contained in a request from a client, and pre-stored are considered. The service control information is used to determine whether the network service device is allowed to provide the requested service to the client. Specifically, the pre-stored service control information includes a plurality of load level information, each of the load level information corresponding to a first type of service, and indicating one or more load levels that the first type of service is allowed .

According to an aspect of the present invention, a method for overload control of a network service device in a load control device of a communication network is provided, wherein the method includes the following steps: a. acquiring a service related service of the service requested by the client Information; b. according to the load information of the network service device, the service related information of the obtained requested service, and the pre-stored service requested; c. if the network service device is allowed to provide the The requested service controls the network service device to provide the requested service to the client. According to another aspect of the present invention, there is provided a control apparatus for performing overload control on a network service device in a communication network load control device, comprising: obtaining means for acquiring a service requested by the client The service-related information, the first determining means, configured to determine, according to the load information of the network service device, the service-related information of the acquired requested service, and the pre-stored service control information, whether to allow the network service device to The client provides the requested service; the sub-control device is configured to control the network service device to provide the client with the requested service when the network service device is allowed to provide the requested service to the client Describe the requested service.

 With the technical solution provided by the present invention, overload control of the network service device can be effectively performed in various network environments including but not limited to the diameter-based protocol. By using a plurality of load level information, each of which corresponds to a first type of service, and indicating one or more load levels allowed in the first type of service, different priority services may be performed as needed Different treatments. This is a good fit for the needs of network service providers. At the same time, many protocols such as the diameter protocol can be improved as a result. DRAWINGS

 DETAILED DESCRIPTION OF THE INVENTION The present invention will be described in detail below with reference to the accompanying drawings, wherein the same reference numerals represent the same or similar components:

 Figure 1 is a schematic diagram of certain diameter-based applications;

 2 is a schematic diagram of a communication network in which a control device according to the present invention is deployed on an application server for overload control;

 3 is a flow chart of a system method for network service device overload control in accordance with a preferred embodiment of the present invention;

 4 is a schematic diagram of load levels defined in accordance with an embodiment of the present invention; FIG. 5 is a schematic diagram of a message delivery process based on a diameter protocol between an OCS and an S-CSCF according to an embodiment of the present invention;

6 is a schematic diagram of a message delivery process based on a diabetes protocol between an OCS and an S-CSCF according to another embodiment of the present invention; 7 is a flow chart of a method for overload control of a network service device in a load control device of a communication network in accordance with a preferred embodiment of the present invention;

 Figure 8 is a block diagram of a control device for overload control of a network service device in a load control device of a communication network in accordance with a preferred embodiment of the present invention. detailed description

 Referring to Fig. 2, in the communication network shown, a control device 20 for overload control according to the present invention is deployed on an application server 2. In other examples, such a control device can also be deployed on a network control device that is separate from the application server 2.

 The present invention will be described in detail from a system perspective with reference to Figs. 3 and 2. 3 is a flow chart of a system method for network service device overload control in accordance with a preferred embodiment of the present invention.

 In S1, client 1 (for example, a client device based on the diameter protocol, referred to simply as a client for the sake of brevity) requests service from the application server 2 (for example, an application server based on the diameter protocol), generally, Client 1 sends a service request message based on a specific protocol to make the service request.

 Then, the method proceeds to S2, in which the control device 20 on the application server 2 acquires (extracts) the service-related information of the requested service from the received service request message. According to a preferred embodiment of the present invention, the acquired service related information includes any one or any of the following items: a calling party, a called party, an application identifier (ID), a service content ID, a time, Date, etc.

Thereafter, based on the acquired service related information, it is determined in S3 whether the requested service is the first type service or the second type service. In the present invention, generally, the second type of service has the highest priority, once a service request message is identified as a request for a second type of service (eg, the called party, application ID, or service of the message) The content ID matches the corresponding pre-stored information), and the control device 20 will pass the request to the corresponding application-related device 21 to provide the second type of service to the client. In general, an emergency call (in China, if the called party is a 1 19 call) always has the highest priority, so when a service request message for an emergency call arrives and is identified based on its particular called party After that, the requested service will be immediately provided to the requester (for example, a client).

 Those skilled in the art will appreciate that emergency services are only one non-limiting embodiment of a second type of service in accordance with the present invention. In practical applications, what kind of service should be directly accepted can be flexibly defined based on a certain policy rule, which can be manually or automatically configured.

 The first type of service tends to have a lower priority than the second type of service. Once a service request message is identified as a request for the first type of service, the control device 20 performs a series of checking steps to determine whether Allow the request.

 In order to support the judging process in S3, the pre-stored service control information may include a mapping table, wherein the services are divided into two categories: a first type of service and a second type of service. Those skilled in the art understand that a requested service has several characteristics, such as a calling party (number), a called party (number), an application ID, a service content ID, and the like. Thus, a service can be defined as either a first type of service or a second type of service by any one or combination of its characteristics, and one or more features used to define its type will also be used thereafter. Identification of the type of service.

 Based on such a mapping table, S3 can be executed as follows:

 - Searching the mapping table with the obtained service related information (one or more characteristics) as a key, and judging the type of the requested service based on the matching.

In the other case, this mapping table can also be omitted. Pre-stored service control information can exist in the form of a number of rules (described in more detail below), where each rule consists of one or more features and corresponding control policies. According to an embodiment of the present invention, in order to support such type identification, there may be one or more rules, each of which corresponds to a second type of service. In general, the control policy in the rule corresponding to the second type of service may indicate that the request should be allowed. According to the invention, no match is found in the mapping table or rule. The request can be banned or treated as a request for a second type of service and is allowed, depending on the configurable principle of judgment.

 If the result of the judgment obtained by S3 is: The requested service is the second type of service, the method will proceed to S4, where the application server 2 will provide the requested service to the client.

 On the other hand, if the judgment result obtained by S3 is: The requested service belongs to the first type service, the method will go to S4, wherein, according to the load information of the application server 2, the acquired service related information, and the pre-stored service control information It will judge whether or not the application server 2 is allowed to provide the requested first type of service to the client 1.

 It is understood by those skilled in the art that S4 (the step of acquiring the load information of the application server 2 for the first type of service) may be triggered by the service request message sent by the client 1 (as shown in FIG. 3), or may be controlled by the control device. 20 Do it on your own. Table 1 shows various types of resources used by the application server 2 for load detection in accordance with a preferred embodiment of the present invention.

 Table 1 :

 Application Server 2 Various resources for load detection

 CPU memory bandwidth message queue disk storage

 Usage rate usage rate usage rate

 The message queue is related to the memory buffer used to store network messages. If the buffer is full, the incoming message may be lost and the server may not be processed.

 Here, in S4, the load information of the application server 2 can be obtained by periodically detecting the state of the resources listed in Table 1 and calculating a corresponding load value based on these states. In general, the load value can be obtained by weighting each detected item in Table 1 and summing the weighted values. Here, we assume that the load value (a variable) has a maximum value of 1, and a minimum value of zero.

The calculated load value will be compared with a plurality of preset load thresholds to determine the load level at which the application server is currently located. Negative according to a specific embodiment of the invention The load threshold and its corresponding load level are defined as shown in Figure 4. Where each two consecutive load thresholds define a load level. For example, T_X and T_y define load level 3.

 The pre-stored service control information used in S4 will be detailed in the following. According to a preferred embodiment of the present invention, the pre-stored service control information exists in a preset plurality of rules.

 Typically, once the service related information obtained from the service request message from client 1 matches the feature portion of a rule, the corresponding control policy in the rule will be applied to the request. In practical applications, the following items may be used alone or together to construct a feature part of a rule:

 - Origin-Host: Example By setting the source host ="nas.example.com", the pre-stored control policy will be applied to the call initiated by the host belonging to "nas.example.com".

 - Source i or (Origin-Realm): For example, by setting the source: ^="example.com", the pre-stored control policy will be applied to calls initiated by hosts belonging to the "example.com" domain.

 - Application ID (Application-ID): This parameter indicates that the corresponding control policy will be applied to the matching application, for example: Application ID=0 for Diameter-like messages, Application ID=1 for NASREQ, Application ID=2 for Mobile-IP, Application ID=3 for Diameter base accounts, Application ID=4 for Diameter credit control applications.

 - Client ID (Subscription-ID): This parameter indicates that the overload control will be applied to the terminal client holding the client ID.

 - Service Mark: This parameter indicates that the overload control will be applied to the special credit control service in the diameter credit control request.

 - Service Content ID: This parameter indicates that the overload control will be applied to the special credit control application in the diameter credit control request.

- Event timestamp: This parameter indicates that the overload control will be applied to events for a certain period of time. For example, selecting a time period from 8:30 am to 9:30 am, and also selecting one or several other items (for example, items corresponding to a mobile game call), occurs between 8:30 am and 9:30 am The mobile game call between will be properly handled by the corresponding control strategy. - Service Information: This parameter indicates that the overload control will be applied to the request for special service related information in the diameter credit control request, such as PS information for the packet exchange service, IMS information for the IMS service information, and the like.

 According to a preferred embodiment of the present invention, the above application ID and service content ID may be simultaneously used as the feature part in the same rule, as in the following example: Rule 1):

 IF (application ID=4) AND (service content ID=32273@3gpp. Ofg) AND (system load level = 3)

 THEN prohibits service

END IF

 Rule 1) indicates that when the load level of the application server 2 is 3 (as shown in FIG. 4, level 3 is a lightweight load level), the control device 20 will block the multimedia of the credit control application (application ID=4). Broadcast service (service content ID = 32273@3gpp.org). Rule 2):

 IF (MM W=4 ) AND

 ((Service Content ID=32273 @3gpp.org) OR

 (Service content 1D=32272 @5gpp.org ) ) AND (system load level = 4)

 THEN prohibits service

END IF

 Rule 2) indicates that when the load level of the application server 2 is 4 (as shown in FIG. 4, level 3 is a medium load level), the control device 20 will reject the multimedia of the credit control application (application ID=4). Broadcast service (service content ID = 32273@3gpp.org) and session service (service content ID = 32272@3gpp.org). Rule 3):

IF (NOT (Service Content ID=32270 @3gpp.org)) AND (System Load Level = 5; THEN prohibits service

END IF

 Rule 3) indicates that when the load level of the application server 2 is 5 (as shown in FIG. 4, level 5 is the highest load level), the control device 20 will block the multimedia message service (MMS, service content ID=32270). All application services except @3gpp.org ). In other words, when the application server 2 has a load level of 5, the client only allows the MMS to be sent and received. Those skilled in the art will appreciate that such rules can be defined quite conveniently using concise symbols such as inequality, as shown in the following rule 4): Rule 4):

 IF (NOT (Service Content ID=32270 (^Sgpp.org)) AND (System Load Level >=4)

 THEN prohibits service

END IF

 Rule 4) indicates that when the load level of the application server 2 is greater than or equal to 4, the control device 20 will block all application services except the multimedia message service (MMS, service content ID = 32270@3gpp.org). In other words, when Application Server 2 has a load level of 4 or 5, the client only allows sending and receiving MMS. In S5, it is judged whether or not the request is permitted based on the service-related information acquired from the service request message in the SI, the obtained load information of the application server 2, and the pre-stored service control information. The following are a few specific examples: Example 1:

Referring to Figures 5 and 3, an example of the present invention will be described below. Figure 5 shows the message passing process between the OCS and the S-CSCF based on the diameter protocol. First, the S-CSCF (Serving Call Session Control Function) transmits a dial credit control request (CCR) message to the OCS (Online Charging System, an application server configured with the control device according to the present invention).

 According to the flow shown in Figure 3, the OCS obtains the service related information of the requested message from the received service request message. In general, the service-related information obtained includes but is not limited to: calling party, called party, "application ID=4" and "service content ID=32.270@3gpp.org"

 Based on the acquired service related information such as the called party, the OCS determines whether the requested service is the first type service or the second type service. In this example, it is assumed that each second type of service has its particular called party. In other words, it can be judged whether the requested service is of the second type based only on the "called party" information in the service related information. service. Therefore, the OCS can easily discern the requested service type by checking the called party information carried by the request information (e.g., the logical number of the called party).

 OCS will be able to judge based on the pre-obtained OCS load information (which can also be obtained each time a service request message is received from the client, as shown in Figure 3), the acquired service-related information, and the pre-stored service control information. Whether to provide the requested service.

 Assuming that the load level of the OCS is 5, based on the acquired service-related information including "application ID=4" and service content ID=32.273@3gpp.org, the OCS will find that the aforementioned preset rule 3) matches the information. Therefore, the OCS will prohibit the provision of the service request message request. The OCS then generates a reply message CCA including [INITIAL_REQUEST, RESULT_CODE=DIAMETER_TOO_BUSY] and sends it back to the S-CSCF. Since RESULT_CODE is set to DIAMETER_TOO_BUSY, the call setup in OCS will fail. Example 2:

Referring to Figures 6 and 3, another scenario according to a preferred example will be described below:

I.

― S-CSCF sends a CCR message: CCR[INITIAL_REQUEST, application ID=4, service content ID=32.270@3gpp.org, etc.]. ] After receiving the CCR message from the S-CSCF, the OCS searches for the service-related information obtained from the message as a key in the pre-stored service control information. It is assumed that the load state of the OCS is 4, and the rules in the pre-stored service control information include only the aforementioned rules 1) to 3).

 OCS will find that the service-related information obtained from the CCR does not match any of the rules 1) to 3). Here, the requested service can be regarded as a second type of service according to a predetermined principle.

 - The call will then be allowed and the control device (shown in Figure 2) will pass the request to the charging agency to reserve the service quota.

 - Once the service quota is successfully reserved in the OCS, the diameter credit control reply (CCA) message will be sent back to the S-CSCF, which is also set in the CCR. The RESULT CODE in the CCA is set to DIAMETER_SUCCESS. The call is successfully established on the OCS side.

II.

 - When the S-CSCF has used its reserved quota, it will send CCR[UPD ATE-REQUEST] to OCS to apply for more quotas.

 - When the service quota is successfully reserved, the diameter credit control reply (CCA[UPDATE-REQUEST]) is returned to the S-CSCF, which is also set in the CCR. RESULT_CODE in CCA is set to DIAMETER_SUCCESS.

III.

 - If the S-CSCF determines that the client will end the current session, it will send CCR[TERMINATION_REQUEST] to the OCS to credit the usage quota.

 ― After the service is successfully charged, OCS returns CCR[TERMINATION_REQUEST] to the S-CSCF. The RESULT_CODE in the CCA is set to DIAMETER_SUCCESS.

7 is a flow chart of a method for overload control of a network service device in a load control device of a communication network in accordance with a preferred embodiment of the present invention. An aspect of the present invention will be described below with reference to FIGS. 7 and 2. In S10, the application server 2 receives a service request message from the client 1.

 Subsequently, in S1 1, the service related information in the service request message will be extracted for the service type identification to be performed and further processing that may exist.

 In S12, the application server 2 will determine the type of service requested, as shown in Fig. 7, if the requested service is the second type of service, the method will proceed to S14. In S 14, the application server 2 will control the provision of the requested service to the client.

 On the other hand, when the requested service is the first type of service, the method proceeds to S13, where the application server 2 takes the obtained service related information as a key, and simultaneously considers the load information of the application server 2 (currently Load level), a search is performed in pre-stored service control information (eg, rules 1) to 3)) to determine whether to allow the client 1 to provide the requested first type of service. If the result of S 13 is "allowed", the method will proceed to S14, and then the application server 2 will control the service to be requested to the client 1.

 If the result of S 13 is "not allowed", Server 2 will reject the request and return a message indicating that the request was rejected, such as CCA [INITIAL-REQUEST, RESULT_CODE=DIAMETER-TOO-BUSY], and so on.

 Another aspect of the present invention will be described below with reference to Figs. 8 and 2. The illustrated control device 20 includes an acquisition device 200, a first determination device 201, a sub-control device 202, and an acquisition device 203. Specifically, the obtaining device 200 further includes a receiving device 2000 and an extracting device 2001; the first determining device 201 further includes a second determining device 2010 and a third determining device 2011.

 According to a non-limiting embodiment of the invention, the receiving device 2000 receives a service request message from the client 1 and forwards it to the extraction device 2001.

Subsequently, the service related information in the service request message will be extracted by the extracting means 2001 for use in the identification of the type of service to be performed and further processing that may exist. The acquired service related information is supplied to the second judging device 2010, and the second judging device 2010 determines the type of the requested service based on the acquired service related information. If the requested service is the second type of service, the sub-controlling device 202 will control the provision of the requested second type of service to the client based on the determination result obtained by the second determining means 2010.

 On the other hand, if the requested service is the first type of service, the second judging means 2010 will pass the judgment result to the third judging means 201 1 . Then, the third determining means 201 1 uses the obtained service related information as a key, and simultaneously considers the load information (current load level) of the application server 2, and performs a search in the pre-stored service control information to determine whether to allow the provision. The requested first type of service.

 If the result obtained by the third judging means 201 1 is "allow", it will pass the result of the judgment to the sub-controller 202, which will control the provision of the requested service to the client.

 If the result obtained by the third judging means 201 1 is "not allowed", the control means 20 rejects the request and returns a message indicating that the request is rejected to the client 1 as

 CCA[INITIAL- REQUEST, RESULT_CODE=DIAMETER_TOO_BUSY] , and so on.

 The practice of the invention is as described above. It will be appreciated by those skilled in the art that the present invention is not limited to the foregoing specific embodiments, and various modifications and changes can be made within the scope of the appended claims.

Claims

Claim A method for overload control of a network service device in a communication network, comprising the steps of:  a. Obtain information about the service of the service requested by the client;  Determining whether the network service device is allowed to provide the requested service to the client according to the load information of the network service device, the service related information of the obtained requested service, and the pre-stored service control information;  c. If the network service device is allowed to provide the requested service to the client, the network service device is controlled to provide the requested service to the client.  2. The method according to claim 1, wherein before the step b, the method further comprises the steps of:  i. Obtain the load information of the network service device.  The method according to claim 1 or 2, wherein the pre-stored service control information includes service type information for indicating one or more first type services and one or more second type services.  The step b includes the following steps:  Bl. determining, according to the obtained service related information and the service type information, that the requested service belongs to the first type service or the second type service;  The pre-stored service control information includes a plurality of load level information, where each load level information corresponds to a first type of service, and indicates one or more allowed load levels of the corresponding first type of service;  B2. If the requested service belongs to the first type of service, determining whether the load of the network service device is in an allowed load of the requested service according to load information of the network service device and corresponding load level information. Level B3. If the load of the network service device is at an allowed load level of the requested service, determining to allow the network service device to provide the requested service to the client. The method according to claim 3, wherein the step b further comprises: b2'. determining that the network service device is allowed to be the client when the requested service is a second type of service The requested service is provided at the end.  The method according to any one of claims 1 to 4, wherein the load control device is configured on the network service device, wherein the step a comprises: al. receiving from the client End service request message, including service related information of the requested service;  A2. Extracting the service related information from the service request message.  The method according to any one of claims 1 to 5, wherein the load information of the network service device comprises at least one of the following:  - a usage rate of a processor of the network service device;  - the usage rate of the bandwidth of the network service device;  - a usage rate of the memory of the network service device;  - The network service device is used to store the cache usage rate of the network message.  The method according to any one of claims 1 to 6, wherein the service related information comprises at least one of the following:  - calling party number;  - called party number  - the source host of the requested service;  - the destination host of the requested service;  - the service ID of the requested service;  - the service content ID of the requested service;  - an application ID of the requested service;  - service information of the requested service;  - time;  - date. The method according to any one of claims 1 to 7, wherein the network service device is based on a Diameter base protocol and/or a Diameter related protocol. A control device for overload control of a network service device in a load control device of a communication network, comprising:  The acquiring device is configured to obtain service related information of the service requested by the client, and the first determining means is configured to control, according to the load information of the network service device, the service related information of the obtained requested service, and the pre-stored service control Determining whether the network service device is allowed to provide the requested service to the client;  The child control device controls the network service device to provide the requested service to the client if the network service device is allowed to provide the requested service to the client.  The control device according to claim 9, further comprising: obtaining means, configured to obtain load information of the network service device.  1 1. The control device according to claim 9 or 10, wherein the pre-stored service control information comprises service type information for indicating one or more first type services and one or more second types Service,  The first determining device includes:  a second determining means, configured to determine, according to the acquired service related information and the service type information, that the requested service belongs to the first type service or the second type service;  The pre-stored service control information further includes multiple load level information, where each load level information corresponds to a first type of service, and indicates one or more allowed load levels of the corresponding first type of service;  The first determining device further includes:  a third determining means, configured to: when the requested service belongs to the first type of service, determine, according to the load information of the network service device and the corresponding load level information, whether the load of the network service device is in the requested The allowed load level of the first type of service; The sub-control device is further configured to: when the load of the network service device is in an allowed load level of the requested first type service, control the network service device to provide the requested request to the client The first type of service. The control device according to claim 11, wherein the sub-control device is further configured to: when the requested service belongs to a second type of service, control the network service device as the client The requested second type of service is provided.  The control device according to any one of claims 9 to 12, wherein the load control device is configured on the network service device, wherein the obtaining device comprises:  a receiving device, configured to receive a service request message from the client, where the service related information of the requested service is included;  And an extracting device, configured to extract the service related information from the service request message. The control device according to any one of claims 9 to 13, wherein the load information of the network service device comprises at least one of the following:  - a usage rate of a processor of the network service device;  - the usage rate of the bandwidth of the network service device;  - a usage rate of the memory of the network service device;  - a usage rate of the cache of the network service device for storing network messages.  The control device according to any one of claims 9 to 14, wherein the service related information comprises at least one of the following:  - calling party number;  - called party number  - the source host of the requested service;  - the destination host of the requested service;  - the service ID of the requested service;  - the service content ID of the requested service;  - an application ID of the requested service;  - service information of the requested service;  - time;  - date.  The control device according to any one of claims 9 to 15, wherein the network service device is based on a Diameter base protocol and/or a Diameter related protocol.