KR20080059345A - Protocol parameter negotiation - Google Patents

Abstract

This invention relates to a method for negotiating at least one parameter of a protocol that is operated between a first protocol entity (1) and a second protocol entity (2), comprising receiving (301) a first negotiation message (3) that carries a first value for said at least one parameter, wherein said first value is an invalid value for said at least one parameter, and sending (309) a second negotiation message that carries a second value for said at least one parameter in response to said first negotiation message (3). The invention further relates to a computer program, a computer program product, a system (30) a terminal (10) and a network element (20). Said protocol may for instance be a Radio Link Protocol, and said first (3) and second (4) negotiation messages may for instance be eXchange Identification XID command and response, respectively.

Description

Protocol parameter negotiation

The present invention relates to a method for negotiating at least one parameter of a protocol operated between a first protocol entity and a second protocol entity.

In second and third generation mobile radio systems such as, for example, Global System for Mobile Communications (GSM) and Universal Mobile Telecommunications System (UMTS), non-transmission services that provide error-free data transmission services to users. -transparent, NT) data bearer is provided. Data transfer services include the Radio Link Protocol (RLP) and the Connected Layer-2 Relay (L2R) Protocol (COP). The RLP function adds a Forward Error Correction (FEC) process and an RLP Protocol Data Unit (PDU) to the Frame Check Sequence (FCS) of the RLP for each transmitted RLP frame. The mobile station (MS) from the mobile station (MS) in order to detect errors by means of error detection and to eliminate errors by repeating frame transmission under the use of time-variance of the transmission medium. It provides an automatic repeat request (ARQ) protocol that extends to network interworking functions (IWF) in MSC. The L2R function translates the layer-2 protocol of the MS into a CP using transports protected by the RLP.

RLP is controlled by parameters such as acknowledgment, reply and resequencing timers or retransmission attempts, or window size requested, which are assigned by default values or by the user or the network. For example, it may be modified by AT commands. These parameters are defined, for example, in Table 2 of Technical Document TS 24.002 of the Third Generation Partnership Project (3GPP). If a change in parameter is initiated within an MS RLP entity or an MSC RLP entity, the desired parameter is signaled to the corresponding peer RLP entity via eXchange IDentification (XID) frames, where the exchange identification frame is information. The fields are RLP frames (PDUs) that are interpreted as exchange identifications on behalf of the data. To start the negotiation, an XID command frame will be signaled. The peer entity identifies the parameter values by returning a value in the XID response or by providing a low or high value in their location in accordance with the negotiation detection of the parameter.

This negotiation procedure is described by way of example in the signaling chart of FIG. 1A. In FIG. 1A, in order to establish a data transmission, the RLP entity 1 in the MS sets the XID instruction frame 3 to the proposed value for the parameter, in this example the proposed value for the resequencing timer T4, together with the MSC. To its peer RLP entity 2 in the. It will be appreciated that an XID command / response frame can be used to negotiate several parameters at the same time. However, to simplify the presentation, FIG. 1A only depicts a single parameter (timer T4) to be negotiated. The XID command / response frames may further comprise, for example, an RLP version number and / or may include a plurality of parameters that depend at least in part on each other. Returning to the example of FIG. 1A, the value of timer T4 may be determined by the user of the MS, for example via an AT command, and may be selected as T4 = 60 ms. The RLP entity 2 in the MSC receives the XID instruction frame 3, extracts the proposed value for T4, and determines whether this value is acceptable or must be increased or decreased in accordance with the detection of the negotiation indicated for the parameter. Decide Next, an XID response containing the accepted / replaced value for the timer T4 (T4 = 60ms) or the value substituted or replaced (e.g. T4 = 80ms because the detection of negotiation of the T4 parameter only allows the negotiation to go up). The frame 4 is returned to the MS RLP entity 1 by sending it from the MSC entity 2 to the MS RLP entity 1. Further negotiation steps may occur for parameter T4 or other RLP parameters until data transmission between the MS and the MSC can eventually be established based on the RLP. Prior to data transmission 5, Set Asynchronous Balanced Mode (SABM) and Unnumbered Acknowledge (UA) frames may have to be exchanged between peer entities (1, 2). In FIG. 1A this exchange is assumed to be aggregated into the data transfer representation 5.

In FIG. 1B, a similar negotiation procedure is depicted. However, in contrast to the procedure in FIG. 1A, the data transmission 5 may be configured by the first XID instruction frame 3 with the suggestion of the value of at least one parameter (eg, resequencing timer T4) of the MS. From RLP entity 1 to RLP entity 2 in the MSC, ie the parameters are renegotiated during data transmission 5. The RLP entity 2 in the MSC then accepts or replaces the suggested value for the parameter and returns the accepted / replaced value in the XID response frame 4 returned to the RLP entity 1 of the MS. Following this parameter renegotiation, data transmission 5 can continue based on the RLP and its renegotiation RLP parameters. It will be appreciated that the interruption of data transmission 5 is not necessarily required for parameter renegotiation, and that renegotiation can take place in parallel with data transmission 5.

In general, the values for the RLP parameters are limited to each range or alphabet indicated by the RLP. For example, the second column of Table 2 of TS 24.022 defines a validity range for the plurality of RLP parameters. During negotiation, the values for the proposed parameters in the XID command frames and the values accepted / replaced within the XID response frame must have valid values for each of the above parameters. That is, they must be within the same valid range as defined by the RLP for each parameter. For example, the RLP parameter P1 (dictionary size) has a valid range of 512-65535, so the suggested value for P1 of 500 would be an invalid value.

However, due to other interpretation or implementation errors of the RLP specification by the manufacturer of the MS and / or MSC, the values for the RLP parameters in the XID instruction frames may be invalid. That is, outside the validity range defined by the RLP specification. The result of using invalid values for RLP parameters during negotiation is usually to discard the XID command frame received by the entity receiving the XID frame with the invalid value, where the entire XID frame (multiple RLP parameters Possible values) or the invalid value itself is discarded. An RLP entity sending an XID command frame with an invalid value then attempts to send (retransmit) the same XID command frame several times over and over again, since it does not receive the corresponding XID response frame as a positive response. If the number of "maximum transmissions" is exceeded for an XID command frame, an RLP entity trying to send an XID command frame with a value for the RLP parameter may terminate the connection (depending on its implementation).

This scenario is depicted in FIG. The RLP entity 1 in the MS sends an XID instruction frame to its peer entity 2 in the MSC with an invalid value for the parameter (eg, resequencing timer T4). The RLP entity 2 in the MSC now detects an invalid value in the XID instruction frame 3 and discards the completed XID instruction frame 3. After the timer controlling the time window in which a response to the XID command frame 3 should be received expires, the RLP entity 1 in the MS does not receive an XID response frame 4 from the RLP entity 2 in the MSC. Notify, which causes the XID instruction frame 3 to be resent again with an invalid value, and the XID instruction frame 3 is discarded again because the value contained therein in the RLP entity 2 in the MSC is invalid. do. This procedure continues until the maximum number of retransmissions in the RLP entity 1 in the MS is exceeded. Since the XID commands are not answered and no further transmission of XID command frames is allowed, the RLP entity 1 in the MS may next decide to release the connection.

In view of the aforementioned problems in the context of a radio link protocol, it is particularly a method, computer program, computer program product, system for a more robust negotiation of at least one parameter of a protocol operated between a first protocol entity and a second protocol. It is a general object of the present invention to provide a terminal and a network component.

A method is proposed for negotiating at least one parameter of a protocol operated between a first protocol entity and a second protocol entity, the method comprising: a first for the at least one parameter that is an invalid value for the at least one parameter; Receiving a first negotiation message conveying a value; And transmitting a second negotiation message that carries a second value for the at least one parameter in response to the first negotiation message.

The protocol can be any protocol that allows the first and second entities to exchange data. The exchange may be performed by sending and receiving PDUs between the first and second entities, where the physical transmission of the PDUs is performed based on protocols. The protocol may provide services for enhancing the layer protocol. For example, the protocol may be an RLP providing an ARQ service for the connection between the MS and the MSC of the mobile communication system, where the first and second entities may next be logically connected with the MS and the MSC respectively. have.

The protocol includes at least one parameter. The parameter may, for example, be required for the operation or the protocol or may enhance its performance. If the protocol is RLP, the parameter may be, for example, a resequencing timer, a maximum number of retransmissions, or a data compression parameter. The first and second values are assigned to the at least one parameter of the parameter, for example the values may be numerical values for the parameter, such as "40 ms" for the resequencing timer.

The negotiation may be an initial negotiation of a parameter or may be a renegotiation of a parameter, where the initial negotiation for the parameter used prior to the renegotiation may be, for example, a default value, and the renegotiation may for example be an external event or user interaction. Triggered by action.

The negotiation includes receiving a first negotiation message that conveys a first value for the at least one parameter. The first negotiation message may equally appropriately contain several values of each of several parameters to be negotiated. The value may be, for example, a number, symbol, letter, or other information display. The first negotiation message may be transmitted from the first entity to the second entity, for example. The first value can be, for example, a suggestion of a value for the at least one parameter, and can be, for example, a default value that can be supported by the entity proposing the first value. The first value is an invalid value, ie the value is not allowed by the protocol. For example, if the at least one parameter can be represented by a number, the protocol can define a valid range of numbers that can be used as the value for the at least one parameter. Optionally, if the at least one parameter can be indicated by a symbol, the protocol can define a limited alphabet of symbols that can be used as values for the at least one parameter.

Although the first negotiation message includes an invalid value for the at least one parameter, a second negotiation message is sent from the second entity to the second entity, for example in response to the first negotiation message. The second negotiation message includes a second value for the at least one parameter. Thus the negotiation is not interrupted or terminated by sending the first negotiation message with an invalid value for the at least one parameter. The second value may be, for example, the same as the first value or may be changed to a valid value, for example, by the entity that received the first negotiation message.

In contrast to the prior art, in accordance with the present invention, negotiation of at least one parameter is not interrupted or terminated by sending a negotiation message containing an invalid value for the at least one parameter. Instead, the first negotiation message is responded with a second negotiation message that includes a second value for the at least one parameter. This second negotiation message maintains the negotiation procedure, thereby making both negotiation and protocol strong. In particular, when the first entity that sent the first negotiation message with an invalid first value waits for a response (second negotiation message), the enhancement may be increased, which appears in the prior art due to the invalidity of the first value. If not, the first entity must wait until the waiting time expires, and then resend the first negotiation message with an invalid value. Worse still, if the maximum value of retransmissions is exceeded, the first entity decides to cancel the entire connection. Due to the blocking of this first entity, the fact that the same invalid value is used in all retransmissions, useless frequent retransmissions and potential release of the entire connection are prevented by the present invention. Furthermore, the reason for the proposal of the first negotiation message, for example the protocol standard or other interpretation of implementation errors, for the present invention is irrelevant. As an added advantage, the present invention is easily implemented and does not require significant changes to the current implementation.

A preferred embodiment of the present invention further comprises checking whether the detection of negotiation of the at least one parameter causes the invalid first value to negotiate with a valid value. If the first value is a number, the detection of the negotiation indicates, for example, that if the value v1 is proposed in the first negotiation message, only the value v2 is used in the second negotiation message sent in response to the first negotiation message. V2 is equal to or greater than v1 for up-negotiation, and equal to or less than v1 for down-megotiation. The detection of a similar negotiation may be performed on the values of the at least one parameter that are symbols or characters, for example by referring to a sequence of symbols or characters within a valid symbol or character alphabet that defines valid symbols or characters. Can be defined. The negotiation detection may be defined by the protocol, for example. If the detection of the negotiation causes the first (invalid) value to be negotiated with a valid value, this value may be included as the second value in the second negotiation message, and then the at least one parameter negotiation. It can be the last or intermediate result of. For example, if the first (invalid) value of the at least one parameter is less than the lower limit of the valid range for the values of the parameter and if the detection of the negotiation is abnormal, the second value is the lower limit of the valid range. Can be selected as a default or recommended value within the valid range, or as a value selected by the user.

A preferred embodiment of the present invention further comprises checking whether the at least one parameter is required for the operation of the protocol. If the at least one parameter is not required for the operation of the protocol, the second value can be chosen, for example, equal to the first (invalid) value, since it is not required anyway. Optionally, the second value may be changed to a valid value before responding to the first negotiation message. If at least basic operation of the protocol is possible without proper selection of the parameter, it is recognized that no parameter is required for the operation of the protocol. Such non-required parameters may be, for example, parameters that will be enriched according to the current selection of performance-enhanced parameters, optional parameters, or other parameters.

According to a preferred embodiment of the present invention, the second value is a valid value for the at least one parameter. Negotiation may then end successfully or further continue based on the valid second value, with no impediment or unsuccessful termination of negotiation with the declining implementation of additional protocols and services that depend on the protocol.

According to a preferred embodiment of the invention, the protocol is a radio link protocol which at least partly controls the data transmission between the mobile station and the mobile service switching center. The first negotiation message may then be an exchange identification XID command and the second negotiation message may be an XID response.

A computer program is proposed with instructions that operate to cause a processor to perform the steps of the aforementioned method. The computer program may be executed, for example, in the processor of the device, in the processor of the MS or MSC.

A computer program product is proposed that includes a computer program having instructions that operate to cause a processor to perform the steps of the aforementioned method. The computer program product may be stored, for example, in a chip memory such as a device's cache, random access memory (RAM) or read only memory (ROM), or for example a memory card, a memory stick. Or on a storage medium such as a disk.

Further proposed is a system for negotiating at least one parameter of a protocol operated between a first protocol entity and a second protocol entity, the system passing a first value that is an invalid value for the at least one parameter. Means configured to receive a negotiation message; And means configured for sending a second negotiation message conveying a second value for the at least one parameter in response to the first negotiation message.

Further proposed is a terminal of a communication system in which at least one parameter of a protocol operated between a protocol entity in a terminal and a protocol terminal in a network is negotiated, the terminal delivering a first value that is invalid for the at least one parameter. Means configured to receive a first negotiation message; And means configured for sending a second negotiation message in response to the first negotiation message. The terminal may be, for example, an MS in a mobile communication system.

Further proposed is a network component of a communication system in which at least one parameter of a protocol operated between a protocol entity in a terminal and a protocol terminal in a network component is negotiated, the network component being an invalid value for the at least one parameter. Means configured to receive a first negotiation message that conveys a first value; And means configured for sending a second negotiation message in response to the first negotiation message. The network component may be included, for example, in the MSC of the mobile communication system.

Other or other aspects described herein of the present invention will be apparent from or elucidated with reference to the embodiments described below.

In the following part of this specification, an embodiment of the present invention will be presented for illustration of parameter negotiation within the context of a radio link protocol (RLP). It will be appreciated that the present invention enables strong parameter negotiation even within other types of protocols and is not intended to be limited to the embodiments presented herein.

The present invention proposes to respond to the negotiation message even if it contains an invalid value proposal for the parameter.

Thus, the XID command frame 3 containing the invalid parameters is repeatedly discarded by the reception of the RLP entity 2, and the repeated discard of the XID command frame 3 indicates that the transmission of the RLP entity 1 is peered. The scenario illustrated in FIG. 2 no longer occurs for the example case of parameter negotiation within the context of the RLP protocol that allows to release the RLP connection between entities.

Instead, the negotiation procedure according to the invention occurs as illustrated in FIGS. 1A and 1B, with the difference that the value for at least one parameter included in the XID command frame 3 of FIGS. 1A and 1 is an invalid value. . As a result, in accordance with the present invention, as in FIGS. 1A and 1B, the XID command frame 3 may not be valid even if the proposed value for at least one parameter, such as the resequencing timer T4, is invalid. Is answered.

According to a preferred embodiment of the invention, upon receiving an XID command frame with an invalid value for the RLP parameter, it is checked whether the detection of negotiation of the target parameter allows the negotiation to be a valid value. If negotiation is triggered by user interaction, or if the user has made the desired choice for the parameter, then the value given by the user becomes the purpose of the negotiation, and the value for that parameter in the XID response frame will be selected accordingly. Can be.

For example, if the user changes the value for the resequencing timer T4 from MS to 100 ms (T4 value range:> 25 ms according to TS 24.022; detection of negotiation is up), the XID instruction frame is an RLP entity within the MSC. When received from, where T4 is set to 20 ms in the XID command frame, the T4 value is set to 100 ms in an XID response frame sent back from the RLP entity in the MS to the RLP entity in the MSC.

Alternatively or additionally to checking the detection of negotiation of the target parameter in the above embodiment, it will be checked whether the target parameter is required for the RLP connection. Next, if invalid values for the parameters are not required for the RLP connection, they will be accepted during negotiation. If the peer RLP entity proposes an invalid value for a parameter that is not required for the connection, the values can be negotiated with a legal value and, regardless of their validity, if detection of the negotiation allows or optionally permits it. They can be accommodated. In the latter case, therefore, the detection of negotiation is not an obstacle.

For example, the peer RLP sends an XID command frame with the following compression parameters.

Compression: V.42 bis

Direction: None

Dictionary size: 0 (according to TS 24.022, the allowed range is 512-65535; downward detection of negotiation)

Maximum string length: 0 (depending on specification, allowed range is 6-250; negotiation detects downward)

In this case, the dictionary size and the maximum string length are impossible to negotiate with valid values, which means that the detection of each negotiation is downward and the proposed values would have been increased to obtain a valid value. However, since the compression direction is set to "none", i.e., no compression is used, the parameter dictionary size and the maximum string length are not necessary for the operation of the RLP protocol, which allows the parameters to be so accepted. As a result, the same values as the suggested values are returned in the XID response frame.

3 is an exemplary flowchart of a method according to a preferred embodiment of the present invention. In a first step 301 a first negotiation message (e.g., an XID command frame for the RLP protocol) is received, the first negotiation message being a first value for a parameter of the protocol (e.g., a resequencing timer of the RLP protocol). Value for T4). In step 302, it is next checked whether or not this first value is a valid value (eg, in the case of the RLP protocol, the valid range of the timer T4 may be checked from TS 24.022). If the first value is found to be a valid value, then step 303 enters a standard negotiation processing step as known in the prior art. For example, in the case of the RLP protocol, an XID response frame is sent with an accepted or replaced value, the acceptance or replacement of the value being determined by some kind of negotiation example. If the first value is found to be an invalid value, it is checked in step 304 whether the parameter associated with the value is a parameter required for the protocol. If not required by the protocol, in step 305 the second value is set equal to the first value and a second negotiation message is sent with the second value (indicating acceptance of the second value). If the parameter is required, it is checked at step 306 whether the negotiation detection indicated for the parameter causes the first invalid value to be negotiated with a valid second value. If this is not possible, enter the error handling procedure of step 307, which may include, for example, sending an error message to an error handler or disconnecting or similar to a protocol connection. . If it is possible to negotiate the first value to a valid second value, then in step 308 the second value is set to a valid value and then in step 309 it is sent in the second negotiation message. 3 also depicts an optional implementation (given in dashed lines) for the case where the first value is an invalid value (step 302), but a parameter associated with the first value is not required for the protocol (step 304). Instead of accepting the first value as it is (step 305), it may be checked whether the detection of negotiation indicated for the parameter in step 310 allows to negotiate the first invalid value to a valid second value. have. If this is possible, go to step 308. Otherwise, go to step 305.

4 diagrammatically depicts the logical components of a system 30 in accordance with the present invention. The system consists of an MS 10 and an MSC 20 in which only the MS RLP entity 1 and the MSC RLP entity 2 located within the RLP layer appear. The protocol layer below the RLP layer is shown simplified. The MS RLP entity 1 includes a negotiation example 101, a parameter information database 102, and a transmit / receive interface 103.

The transmit / receive interface 103 is capable of logically transmitting and / or receiving XID frames within the RLP layer, where for the actual physical transmission of these XID frames, the XID frames are passed through the service access point 104. It is transmitted to lower protocol layers providing a frame transport service to the RLP layer.

The negotiation example 101 performs negotiation of RLP parameters between the MS and peer RLP entities in the MSC. For example, the negotiation example 101 in the MS RLP entity 1 consults the parameter information base 102 for a default or recommendation value for a parameter or a value selected by a user, and the transmit / receive interface ( 103 may initiate the parameter negotiation step by sending this default / recommendation / selected value to its peer entity 20 as an XID command frame.

Similarly, upon receiving the XID command frame from the peer RLP entity 2 via the transmit / receive interface 103, the negotiation example 101 consults the parameter information database 102 and proposes a proposed message within the XID command frame. It can be determined whether the value is a valid value, can be negotiated up or down, and whether this parameter is required for the current RLP protocol.

According to the result of this reference, even if the proposed value for the at least one parameter in the next received XID instruction frame is invalid, the negotiation example 101 is appropriately selected for the at least one parameter that is currently negotiated. It can trigger the transmission of the XID response frame containing the value. It is readily apparent that the logical components 201, 202, 203 in the MSC RLP entity 2 perform exactly the same functions as their counterparts in the MS RLP entity 1.

The invention has been described above by means of preferred embodiments. It will be appreciated that there are alternative methods and variations that will be apparent to those skilled in the art and that they may be implemented without departing from the scope and spirit of the appended claims. In particular, the invention is not limited to applications within the context of the RLP protocol, and can be equally appropriately applied to all types of protocols in which parameter negotiation is made, regardless of whether these protocols are used in a wired or wireless communication system. have.

1A is a diagram illustrating a signaling chart of a first example negotiation procedure according to the prior art.

1B is a diagram illustrating a signaling chart of a second example negotiation procedure according to the prior art.

2 illustrates a signaling chart of a negotiation procedure terminated due to the proposal of an invalid parameter according to the prior art.

3 is an exemplary flowchart of a method according to a preferred embodiment of the present invention.

4 shows a schematic view of the logical components of a system according to the invention.

Claims (28)

By negotiating at least one parameter of the protocol, Receiving (301) a first negotiation message (3) conveying a first value for the at least one parameter that is invalid for the at least one parameter; And Transmitting (309) a second negotiation message (4) conveying a second value for said at least one parameter in response to said first negotiation message (3), And the invalid value is a value not allowed by the protocol. The method of claim 1, Said at least one parameter of said protocol is required for the operation of said protocol or enhances the performance of said protocol. The method of claim 1, The first value and the second value are to be assigned to at least one parameter of the protocol. The method of claim 1, And the first value is a default value or a user defined value for the at least one parameter. The method of claim 1, And checking (306) whether detection of negotiation of the at least one parameter allows the negotiated first value to be negotiated to a valid value. The method of claim 1, Checking (304) whether said at least one parameter is required for operation of said protocol. The method of claim 1, And said second value is a valid value for said at least one parameter. The method of claim 6, And said second value is equal to said first value. The method of claim 1, Said protocol is a radio link protocol that at least partially controls data transmission between a mobile station (10) and a mobile service switching center (20). The method of claim 9, The first negotiation message (3) is an exchange identification XID command and the second negotiation message (4) is an XID response. The method of claim 5, If the detection of the negotiation allows to negotiate the invalid first value to a valid value, this value is included as the second value in the second negotiation message and is the last or intermediate of the negotiation for the at least one parameter. The result of the parameter negotiation method. The method of claim 6, If the at least one parameter is not required for operation of the protocol, the second value is selected to be equal to the first value. The method of claim 6, If the at least one parameter is not required for operation of the protocol, the second value is changed to a valid value before responding to the first negotiation message. A computer-readable recording medium comprising a computer program having instructions operable to cause a processor to perform the steps of the method of claim 1. An apparatus 30 for negotiating at least one parameter of a protocol, Means (101-103, 201-203) configured to receive a first negotiation message (3) conveying a first value for the at least one parameter that is an invalid value for the at least one parameter; And Means (101-103, 201-203) configured to transmit a second negotiation message (4) conveying a second value for said at least one parameter in response to said first negotiation message (3), And the invalid value is a value not allowed by the protocol. The method of claim 15, And said first and second values are assigned to at least one parameter of said protocol. The method of claim 15, And the first value is a default value or a user defined value for the at least one parameter. The method of claim 15, And means (306) configured to check (306) whether the detection of negotiation of the at least one parameter permits the negotiation of the invalid first value to a valid value. The method of claim 15, Means for checking (304) whether the at least one parameter is required for operation of the protocol. The method of claim 15, And the second value is a valid value for the at least one parameter. The method of claim 19, And the second value is the same as the first value. The method of claim 19, Said protocol is a radio link protocol which at least partially controls data transmission between a mobile station (10) and a mobile service switching center (20). The method of claim 22, The first negotiation message (3) is an exchange identification XID command and the second negotiation message (4) is an XID response. The method of claim 18, If the detection of the negotiation allows to negotiate the invalid first value to a valid value, this value is included as the second value in the second negotiation message and is the last or intermediate of the negotiation for the at least one parameter. Parameter negotiation device, characterized in that the result. The method of claim 19, And if the at least one parameter is not required for operation of the protocol, the second value is selected to be equal to the first value. The method of claim 19, And if the at least one parameter is not required for operation of the protocol, the second value is changed to a valid value before responding to the first negotiation message. As a terminal 10 of a communication system 30 in which at least one parameter of a protocol operated between a protocol entity 1 in a terminal 10 and a protocol entity 2 in a network 20 is negotiated, Means (101-103) configured to receive a first negotiation message (3) conveying a first value for the at least one parameter that is invalid for the at least one parameter; And Means (101-103) configured to transmit a second negotiation message (4) conveying a second value for said at least one parameter in response to said first negotiation message (3), The invalid value is a value not allowed by the protocol. As device 20 in communication system 30, When at least one parameter of the protocol operating between the protocol entity 1 in the terminal 10 and the second protocol entity 2 in the apparatus 20 is negotiated, The device 20, Means (201-203) configured to receive a first negotiation message (3) conveying a first value for the at least one parameter that is invalid for the at least one parameter; And Means 201-203 configured to transmit a second negotiation message 4 conveying a second value for the at least one parameter in response to the first negotiation message 3, The invalid value is a value not allowed by the protocol.

Images