GB/T 11597-1999 Procedure for exchanging control information and user data between a packet assembly and disassembly (PAD) facility and a packet-based DTE or another PAD

See this standard for details. GB/T 11597-1999 Procedure for exchanging control information and user data between a packet assembly and disassembly (PAD) facility and a packet DTE or another PAD GB/T11597-1999 Standard download decompression password: www.bzxz.net

National Standard of the People's Republic of China
GB/T11597—1999
idtITU-TX.29：1997
Procedure for the exchange of control information and user data between a packetassembly/disassembly (PAD)facilityandpacket modeDTEor another PAD1999-11-11 Issued
2000-06-01 Implementation
State Administration of Quality and Technical Supervision
GB/T11597—1999
This standard is equivalent to the ITU-TX.29：1997 standard recommendation. This standard defines the process for exchanging control information and user data between a PAD and a packet mode DTE or another PAD in a packet switching network. It specifies the call user data format, user sequence format and control message format. This standard applies to public data networks.
The main contents of this revision of the standard are as follows: 1) Some expansions have been made to the control messages described in the previous version (see text 4.4.1, 4.4.2, 4.4.11 for details); 2) The call data field has added provisions for use with the quick selection facility (see text 4.2.2, 4.4.10, 4.4.11 for details); 3) Added content related to multi-function PAD (see text 3.3.8, 3.7, 4.4.7 for details). The standards referenced by this standard are as follows:
GB/T GB/T 11589—1999 (eqyITU-TX.1:1996) International user service categories and access types for public data networks and integrated services digital networks (ISDN) GB/T 11590—1999 International data transmission services and optional user service facilities for public data networks (eqVITU-TX.21996) GB/T 11591—1999 Assembly and disassembly facilities in public data networks (idtITU-TX.3 ：1993）GB/T11595-1999 Interface between packet data terminal equipment (DTE) and data circuit terminating equipment (DCE) connected to the public data network by dedicated circuits (idtITU-TX.25:1996)GB/T11596-1999 Interface between DCE/DTE of the packet assembly and disassembly (PAD) facilities of the start-stop data terminal entering the public data network of the country (idtITU-TX.28:1997) Appendix A of this standard is the appendix of the standard.
From the date of implementation, this standard will replace GB/T11597-1989. This standard is proposed by the Ministry of Posts and Telecommunications of the People's Republic of China. This standard is under the jurisdiction of the Telecommunications Science Research and Planning Institute of the Ministry of Posts and Telecommunications. This standard was drafted by the Data Communication Technology Research Institute of the Ministry of Posts and Telecommunications. The main drafter of this standard is Gao Haiyan.
This standard is entrusted to the Data Communication Technology Research Institute of the Ministry of Posts and Telecommunications for interpretation. I
GB/T11597—1999
ITU-T Foreword
The establishment of public data networks that provide packet switching data transmission services in many countries requires the development of some standards to promote international interoperability.
a) Recommendations X.1 and X.2 specify user service categories and facilities in public data networks, and Recommendation X.96 specifies call progress signals.
b) Recommendation X.3 specifies PAD in public data networks; c) Recommendation X.8 specifies the framework and service definition of multi-function PAD (MAP); d) Recommendation X.28 specifies the DTE/DCE interface of the start-stop DTE access PAD in public data networks; e) Recommendation X.25 specifies DTE for DTE operating in packet mode in public data networks; The interface between TE and DCE; f) the need to enable intercommunication between packet-type DTE and non-packet-type DTE in packet-switching transmission services; g) the urgent need to allow intercommunication between start-stop DTE in the public switched telephone network, public switched data network or leased line and packet-type DTE using packet-switching transmission service virtual call facilities; h) the need to enable intercommunication between PADs;
i) Packet-type DTE should not be forced to use control procedures appropriate to PAD functions, but some packet-type DTEs may wish to control certain specific functions of the PAD.
To Recommendation
(1) X.29 procedures should be applicable to the Recommendation X.25 interface between DCE and packet-based DTE; (2) X.29 procedures can be used for interworking between PADs; (3) The specific procedures shall be as specified in Chapter 1 "Procedures for the exchange of PAD control information and user data"; (4) The method of transmitting user data shall be as specified in Chapter 2 "User data transmission"; (5) The procedures for controlling PADs through PAD messages shall be as specified in Chapter 3 "Procedures for the use of PAD messages"; (6) The format of the data field that can be transmitted according to virtual calls shall be as specified in Chapter 4 "Format". NOTE
1 For ease of understanding, this Recommendation refers to specific packet types and procedures of Recommendation X.25. For interworking between PADs limited to domestic networks, these packet types or procedures may have different forms from those used in Recommendation X.25, but should have the same operational content. 2 The following items are for further study:
--use of permanent virtual circuit services;
--interworking between DTEs that have interfaces for different data transmission services; -operation of non-packet-mode DTEs that is not start-stop. National Standard of the People's Republic of China
Procedure for the exchange of control information and user data between a packet assembly/disassembly (PAD) facility and a packet mode DTE or another PAD
Procedure for the exchange of control information and user data between a packet assembly/disassembly (PAD) facility and a packet mode DTE or another PAD1 Procedure for the exchange of PAD control information and user data GB/T11597-1999
idtITU-Tx.29:1997
Replaces GB/T11597-1989
1.1 The exchange of control information and user data between a PAD and a packet mode DTE or PAD shall be carried out using the user data field specified in Recommendation X.25.
1.2 Annex A describes certain features of virtual calls specified in Recommendation X.25, such as the features regarding the PAD presenting a start-stop DTE as a packet-mode DTE. The features described in Annex A also apply to interworking between PADs. 1.3 Call User Data
The call user data field of an incoming call or call request packet to or from a packet-mode DTE or PAD consists of two fields: a) a protocol identifier field and
b) a call data field.
The protocol identifier field is used for protocol identification and the call data field contains user data. The PAD accepts incoming call packets received by the PAD that do not contain a call user data field. If a call user data field is present, the PAD shall send it unchanged to the start-stop DTE using the call data code block of the incoming PAD service signal (see 3.5.22/X.28). 1.4 User Sequence
1.4.1 The user sequence is used to exchange user data between a PAD and a packet-mode DTE or between PADs. 1.4.2 User sequences are transmitted in the user data field of a complete sequence of packets with Q=0 in both directions of a virtual call (see Recommendation X.25).
1.4.3 There is only one user sequence in a complete sequence of packets. 1.4.4 The PAD sends data packets with all D bits set to 0. After receiving a data packet with the D bit set to 1, the PAD shall send the corresponding acknowledgment as soon as possible. If the PAD does not support the D bit procedure, the PAD may reset the virtual call. Since there is no error correction procedure from the PAD to the start-stop DTE, the acknowledgment does not mean that the transmission is error-free. 1.5 PAD messages
1.5.1 PAD messages are used to exchange control information between the PAD and the packet-based DTE (or the remote PAD). The PAD message consists of a control identifier field and a message code field, which may be followed by a parameter field (see 4.4). 1.5.2 PAD messages are transmitted in the user data field of a complete sequence of packets with Q=1 in both directions of a virtual call (see Recommendation X.25).
Approved by the State Administration of Quality and Technical Supervision on November 11, 1999 and implemented on June 1, 2000
GB/T 11597—1999
1.5.3 There is only one PAD message in a complete packet sequence. 1.5.4 The PAD considers it as a PAD message only after it has been completely received. 1.5.5 When the parameter reference number (see 3) appears multiple times in a PAD message, only the last reference number is valid. 1.5.6 The PAD sends a data packet with all D bits set to 0. After receiving a data packet with both the O bit and the D bit set to 1, the PAD should send the corresponding confirmation signal as soon as possible. If the PAD does not support the D bit procedure, the PAD can reset the virtual call. 2 User Data Transfer
2.1 The PAD shall forward data packets upon receipt of a Set, Read or SetReadPAD message, or under any other data forwarding condition provided by the PAD (see 4.4/X.28). 2.2 The occurrence of a data forwarding condition shall not cause the PAD to send empty data packets. 3 Procedures for Using PAD Messages
3.1 Procedures for Reading, Setting and SetReadPAD Parameters3.1.1 The current value of a PAD parameter may be changed and read by sending a Set, Read or SetReadPAD message to the PAD. 3.1.2 When a PAD receives a Set, Read or SetReadPAD message, all previously received data shall be sent to the originating and ending DTE before any action is taken based on the PAD message. The PAD shall also treat the arrival of such a PAD message as a data forwarding condition. 3.1.3 The PAD shall respond to a valid Read or SetReadPAD message by sending a ParameterIndicationPAD message. The PAD message shall contain a parameter field containing the parameter reference number and a table of current values ​​(after any necessary modifications) of the PAD parameters to which the received PAD message relates.
3.1.4 The PAD shall not send back a parameter indication PAD message in response to receipt of a valid Set PAD message. 3.1.5 Table 1 specifies the PAD response to the Set, SetRead and ReadPAD messages. 3.1.6 If the parameter value selected using the Set or SetReadPAD messages causes the function of a character to be repeated, the PAD shall consider these parameter changes valid and respond as described in this Recommendation. After these changes have been invoked, the PAD shall act according to the procedures described in 3.3.2/X.28.
Table 1 PAD messages sent by the PAD in response to the Set, SetRead and ReadPAD messages PAD messages received by the PAD
SetRead
Parameter field
Select parameter table with desired values
Select parameter table with desired values
Select parameter table
Action taken based on PAD parameters
Reset all implemented Recommendation X.3 parameters
to initial values ​​corresponding to initial profile values
Set selected parameters to given values
a) If no errors were encountered
b) If the PAD failed to successfully modify some parameter values
Set all implemented Recommendation X.3 parameters to the given values
a) If no errors were encountered
b) If the PAD failed to successfully modify some parameter values
Set all implemented Recommendation X.3 parameters to the given values Resets the Recommended X.3 parameters
to the initial values ​​corresponding to the initial profile values
Sets the selected parameters to the given values
Corresponding
Parameter indication PAD message sent to the packet-mode DTE
a) None
b) Table of these invalid parameters (Note)
Lists all implemented Recommended X.3 parameters with their initial values
Table of these parameters with their new current values ​​(Note) Lists all Recommended X.3 implemented parameters with their
current values
Table of these parameters with their current values ​​(Note)
Note: If any parameter contains an error, the error bit is set and the parameter value field is encoded as specified in Table 3. 2
3.2 Procedure for requesting to clear PAD
GB/T11597—1999
3.2.1 The request to clear PAD message is used to request the PAD to clear the virtual call after transmitting all data previously sent to the start-stop DTE.
Note: The clear request packet sent by the PAD after transmitting the last character to the start-stop DTE shall contain the clear reason field with DTE cleared.
3.3 Interrupt and discard procedure
3.3.1 If parameter 7 is set to 21, in order to indicate that the PAD is discarding the received user sequence at the request of the start-stop DTE, the PAD shall send an interrupt packet with all bits in the interrupt user data field set to 0, followed by an interrupt indication PAD message. The PAD message contains an indication in its parameter field that parameter 8 has been set to 1 (discard output). 3.3.2 Before data transmission to the PAD is resumed, the response to the Break Indication PAD message will be a Set or Set Read PAD message to show that Parameter 8 is set to 0 (normal data transmission). Before sending this PAD message, any complete sequence of packets being sent to the PAD must be terminated according to the procedures specified in Recommendation X.25 (using packets to be discarded by the PAD). 3.3.3 If the PAD receives a Break Indication PAD message containing the parameter fields specified in 3.3.1, the PAD shall respond by sending a Set PAD message as described in 3.3.2 above and send a Break signal to the Start-Stop DTE. If the PAD receives a Break Indication PAD message without the parameter fields, the PAD does not respond to the Packet DTE or PAD, but the PAD shall send a Break signal to the Start-Stop DTE.
3.3.4 When the PAD sends an Interrupt Packet after receiving an Interrupt PAD Command Signal or Interrupt Signal from a Start-Stop DTE, if Parameter 7 is set to 1, the encoding of bits 8 to 1 of the Interrupt User Data field is 00000001. 3.3.5 If the PAD receives an Interrupt Packet, the PAD shall confirm the Interrupt Packet according to the procedures specified in Recommendation X.25. The PAD shall not send the contents of the Interrupt User Data field to the Start-Stop DTE. The PAD shall not process the value of the Interrupt User Data field. 3.3.6 If Parameter 7 is set to 5, the PAD shall send an Interrupt Packet with all bits of the User Data field of the Interrupt Packet set to 0, followed by an Interrupt Indication PAD message, which does not contain the parameter field described in 4.4.7. 3.3.7 Some PADs may always send an Interrupt Signal to a Start-Stop DTE based on a received Interrupt Packet instead of a received Interrupt Indication PAD message.
3.3.8 Support for multi-function PADs conforming to Recommendation X.8, using the Break Indication PAD message to indicate changes in the PAD functionality defined in 3.3.1. As the details of how to request and/or indicate changes at the far end are pending in Recommendation X.28, the details of how to request and/or indicate changes at the far end and whether this signal must be passed to the local start-stop DTE interface are pending in this Recommendation. 3.4 Reset Procedures
A virtual call may be reset in accordance with the procedures specified in Recommendation X.25. The procedure for resetting the value of PAD parameter 8 has the effect of resetting its value to 0 (normal data transfer). However, the existing values ​​of all other PAD parameters are not affected. 3.5 Error Handling Procedures for PADs
3.5.1 If a PAD receives a Set, Read or SetRead PAD message containing an invalid reference number for a PAD parameter, the Parameter field in the ParameterIndication PAD message sent by the PAD shall contain an indication that this has occurred. All other valid reference numbers for PAD parameters are processed by the PAD.
The reasons for invalid access to a PAD parameter may be: a) the parameter reference number is not implemented in the PAD; b) the parameter value is not implemented in the PAD, or cannot be changed from the current value; c) the parameter is a read-only parameter (only for Set and SetReadPAD messages) d) the parameter follows an invalid parameter delimiter (see 4.4.5.4). 3.5.2 The PAD sends an ErrorPAD message containing the message code of an invalid PAD message received under the following conditions: a) if the PAD receives an unrecognizable message code, b) if the parameter field following the recognizable message code is incorrect or incompatible with the message code; 3
GB/T11597—1999
c) if the format of the parameter field following the recognizable message code is invalid: d) if the PAD receives a parameter indication PAD message that is not required; e) if the PAD receives a PAD message that is too long. 3.5.3 If the received PAD message is less than 8 bits, the PAD shall send an error PAD message. 3.5.4 If the PAD receives an error PAD message, the PAD shall not respond with any type of PAD message. 3.6 Procedure for requesting PAD to reselect called DTE After PAD has transmitted all previously sent data of packet DTE to start-stop DTE, packet DTE shall request PAD to clear virtual call using Reselect or Reselect PAD message with TOA/NPI (Address Type/Numbering Plan Indicator), then PAD shall establish call to reselected DTE. NOTE: TOA/NPI address reservation facility is defined in Recommendation X.2. After receiving Reselect PAD message, PAD shall send Error PAD message with error type of No Right to Reselect PAD message (00000110) in the following cases: a) packet DTE has established virtual call; b) start-stop DTE has requested to prevent called DTE reselection facility; c) more than N Reselect PAD messages have been received (where N value is to be determined). The format of Reselect PAD message is given in 4.4.9. Reselect PAD message with TOA/NPI is given in 4.4.10. These messages contain the information required by the PAD to establish a new virtual call. Upon receipt of a Reselect or Reselect PAD message with TOA/NPI, the PAD shall: - send all previously received data to the originating DTE; - clear the established virtual call,
- establish the virtual call to the reselected DTE after completing the appropriate state changes as specified in 3.2.5/X.28. The call request packet sent by the PAD shall contain only the facilities pre-defined and/or assigned by default to the originating DTE. Any other facilities contained in the Reselect PAD message shall be ignored. In particular: i) Closed User Group Signaling - The PAD shall use the same closed user group as the originating call, regardless of the closed user group indicated in the Reselect PAD message.
i) Reverse Charging - If the originating DTE was not charged, the reselected call shall not be charged to the originating DTE, regardless of the indication in the Reselect PAD message (i.e. the PAD shall use the reverse charging facility in the call request packet). If the originating DTE is charged for the call, then the reselected DTE shall also be charged for the reselected call when the reselection PAD message contains the reverse charging facility. iv) Charging Information
· This facility is allocated for use during the agreed contract period: then the charging information shall be sent to the originating DTE when clearing each (originated or reselected) call, or when clearing the last reselected call. If the latter procedure is selected (i.e., the charging information is sent to the originating DTE when clearing the last reselected call), the PAD shall send the total charging information instead of the charging for each (originated and reselected) call. · This facility is used on a per call basis: then the PAD processes the charging as indicated above (by the originating DTE or packet DTE) starting from the first request for charging information facility. iv) ROA selection: To be determined
1 The other facilities shown in Note 2 of Table 4/X.28 are to be determined. 2 This procedure is an optional feature of the PAD. Those PADs that do not implement this feature should regard the reselect and reselect PAD messages with TOA/NPI as invalid. The PAD can implement this feature by accepting 1) the reselect PAD message or 2) the reselect and reselect PAD messages with TOA/NPI. How the PAD sends the reselect or reselect PAD messages with TOA/NPI is to be determined. 3.7 Procedures for supporting MAP
GB/T11597—1999
If the PAD supports multi-functions (as defined in Recommendation X.8), it should send an interrupt packet to notify the modification of the PAD function when requested by the start-stop DTE. All bits of the user data field of the sent interrupt packet are set to 0, and the subsequent interrupt indication PAD message notifies the modification of the PAD function, as described in 4.4.7.1 below. The reference number field shall be coded as 00000001 (indicating a PAD function modification), and the parameter value field shall be coded as the decimal value of the first character of the function type that the remote PAD has invoked. Table 11/X.28 lists the current PAD functions in full, and the PAD function operations supported by MAPs that conform to Recommendation X,28 and this Recommendation. Similar to the relevant parts of Recommendation X.28, the implementation of remote PAD function modifications is pending on how the local PAD function operations of the MAP that support the MAP can be notified.
4 Format
4.1 Introduction
The bits of the octet are numbered from 8 to 1, where bit 1 is the least significant bit and is transmitted first. The octets of Call User Data, User Sequence, PAD Message, and Interrupt User Data are numbered sequentially starting from 1 and are transmitted in this order. 4.2 Call User Data Format (See Figure 1) E
Cooperative Identificationwww.bzxz.net
Call Invitation
Note: N may have a value between 4 and 16, or between 4 and 128 (when used with the fast selection facility) Figure 1 Call User Data Field Format
4.2.1 Protocol Identifier Format
The Protocol Identifier field consists of 4 octets. The first octet is encoded as follows:
Bits 8 and 7 = 00 for ITU-T use;
=01 for national use;
=10 for use by the international user community
=11 for DTE-DTE use.
When bits 8 and 7 are equal to 00, bits 6 to 1 are equal to 000001, indicating a PAD message for the packet assembly/disassembly facility of the start-stop DTE. Other encodings of bits 6 to 1 are within the rules of Recommendation X.244, which is standardized by ITU-T. All bits of octets 2, 3, and 4 are set to 0. These octets are reserved for future mechanisms to provide additional information about the calling party to the called PAD or packet DTE. 4.2.2 Call Data Format
Each octet of the call data field shall contain the user characters received by the PAD from the start-stop DTE during the call establishment phase. The encoding of these octets is similar to the encoding of the user sequence (see 4.3). The call data field is limited to 12 octets, or 124 octets when used in conjunction with the fast selection facility (see Figure 1). 4.3 User Sequence Format
GB/T11597—1999
4.3.1 The bit order sent from the PAD is the same as the bit order received from the start-stop DTE. The bit order transmitted to the start-stop DTE is also the same as the bit order received by it. 4.3.2 The maximum length of the user sequence is not specified. 4.4 Control Message Format
4.4.1 Bits 8, 7, 6, and 5 of octet 1 of the user data field of the complete packet sequence with Q=1 are defined as the control identifier field to identify the facility to be controlled, such as PAD. The coding of the control identifier field is as follows:
Bits 8, 7, 6, and 5—
-0000 to 0011: reserved for PAD control;
-0100 to 0111: reserved for service extension;
—1000 to 1111: reserved for dedicated extension. For start-stop DTE, the control identifier field coding of the PAD message that controls the PAD is 0000. Other coding of the control identifier in the range of 0000 to 0011 is reserved for further standardization by ITU-T. The control identifier field coding of the telematic service message that controls a specific device is 0100. Other encodings of the Control Identifier field in the range 0100 to 0111 are standardized by ITU-T. NOTE
1 When a PAD receives messages with a Control Identifier field that the PAD does not support, those messages shall be treated as unrecognizable message codes. 2 The possibility of extending the Control Identifier field is reserved. 4.4.2 When the Control Identifier field (see 4.4.1) is set to 0000, bits 4, 3, 2, 1 of octet 1 are defined as the Message Code field. The Message Code field is used to identify a specific PAD message type as given in Table 2. When the Control Identifier field (see 4.4.1) is set to 0100, bits 4, 3, 2, 1 of octet 1 are defined as the Telematics Service Code field. The Telematics Service Code field is used to identify a specific telematics service; for videotex, its value is 0000. Other values ​​are left to ITU-T standardization. The Telematics Service Message Format is described in 4.4.11. Table 2 Type and Coding Class of PAD Message Octet 1
Set PAD Message
Read PAD Message
Set Read PAD Message
Parameter Indication PAD Message
Request Clear PAD Message
Break Indication PAD Message
Reselect PAD Message
Error PAD Message
Reselect with TOA/NPI
Note: Other message codes are reserved for the extended message code field. Message Code
Bits 4321
4.4.3 All PAD messages consist of a Control Identifier field (bits 8, 7, 6, 5 of octet 1 are equal to 0000) and a Message Code field (bits 4, 3, 2, 1 of octet 1). The Set, Read, SetRead and ParameterIndication PAD messages all consist of octet 1 which may be followed by one or more parameter fields, each of which consists of a parameter reference octet and a parameter value octet. The parameter value octet of a Read PAD message has the value 0. The Error PAD message consists of octet 1 and one or two octets giving the cause of the error. The DisconnectIndication PAD message consists of octet 1 which may be followed by a parameter field. The RequestClear PAD message consists of octet 1 only. 4.4.4 The maximum length of a PAD message is network dependent but shall be at least 128 octets. 6
GB/T11597—1999
4.4.5 Parameter fields of the Set, Read, SetRead and ParameterIndication PAD messages (see Figure 2) The parameter fields in any of these PAD messages consist of a reference field and a parameter value field. When the extension mechanism is not used, the length of the parameter field is 2 octets (see 4.4.5.1). 6765
Comparison
Educational treatment,
(Social 2)
Social Education Examination Number
Benefit (Let 1)
Dijiao Special Number
Value Note 1)
Message Code: 0010-
1 These octets are all 0 in the Read PAD message. 2 The Parameter field need not appear (see Table 1). 2
Message Code
Set Read
Parameter Indication
—1Data Packet
Data Segment
Figure 2 Set, Read, Set Read and Parameter Indication PAD Message Format 4.4.5.1 The Reference Number field contains the reference number of the parameter, which is indicated by a decimal number in Recommendation X.3. Bits 7 to 1 of the Reference Number field are coded in binary, where bit 1 is the low order bit. The Reference Number field need not be sorted in ascending order of the parameter reference number. The encoding of bits 7 to 1 in the Reference Number field, 1111111 (decimal 127), is used to extend the Reference Number field. This encoding indicates that another octet follows, which is coded as the parameter reference number of Recommendation X.3 minus 127. 4.4.5.2 Bit 8 of each octet in the PAD message received by the PAD is ignored. As described in 3.5, in the Parameter Indication PAD message, bit 8 of each Reference Number field is set to 1 to indicate that access to the relevant parameter is invalid. 4.4.5.3 The Parameter Value field consists of the value of the parameter reference number, indicated as a decimal number in Recommendation X.3. Bits 8 to 1 of the Parameter Value field are coded in binary, with bit 1 being the low order bit. The Parameter Value field in the Read PAD message is coded as all binary zeros. In the Set and Set Read PAD messages, the Parameter Value field shows the required parameter value. In the Parameter Indication PAD message, the Parameter Value field indicates the current value of the PAD parameter. If there is any modification, it indicates the current value of the PAD parameter after the modification. If bit 8 (error bit) in the preceding octet (Parameter Reference Number field) is set to 1, the Parameter Value field indicates the error cause given in Table 3. Table 3 Coding of the parameter value field in error cases Parameter value field coding
Error type
No additional information
Parameter reference number that does not exist or is not implemented in the PAD Parameter value is invalid or is not implemented in the PAD Bit
87654321
00000000
00000001
00000010
Decimal
Error type
Parameter value cannot be changed from the currently set value Parameter is read-only
Parameter followed by an invalid parameter separator Note: The value 0 is required, other values ​​are arbitrary. GB/T11597—1999
Table 3 (end)
Parameter Value Field Coding
87654321
00000011
00000100
00000101
Decimal
4.4.5.4 Parameters not standardized by ITU-T may be supported. The parameter delimiter used in the PAD message separates the parameters specified in Recommendation X.3 from any other parameters implemented in other countries or regions. The parameter delimiter consists of a parameter field including a reference number field set to 00000000 and a parameter value field set to 00000000. If the parameter delimiter and the country or region parameter field are present, they shall be placed after all ITU-T standardized parameter fields in the PAD message.
Note: It is recommended that only the parameters specified in Recommendation X.3 be used when communicating with PADs in different countries or networks. 4.4.6 Format of the error PAD message (see Figure 3)7
Error type (see Table
Effective message code ()
Note: This octet is not present when the error type is 00000000. Figure 3 Format of the error PAD message
Octet 2 of the error PAD message is encoded as shown in Table 4-1
For cases b, c, d, e and f of Table 4, octet 3 of the error PAD message will contain the message of the received PAD message Table 4
Coding and meaning of octet 2 of the error PAD message
The received PAD message has less than 8 bits
The message code in the received PAD message is not recognized. The format of the parameter field in the received PAD message The format is incorrect or incompatible with the message code
The received PAD message is not an integral number of octetsThe received parameter indication PAD message is not requestedThe received PAD message is too long
Unauthorized reselection of PAD message
Parameter field of the disconnection indication PAD message (see Figure 4) is encoded
Bit 8765
This PAD message may not contain a parameter field, or may contain a type field consisting of 2 octets (i.e., 1 reference number field and 1 parameter value field), which is encoded as follows. 4.4.7.1 For the disconnection indication PAD message that notifies the modification of the PAD function, the reference number field should be encoded as 00000001 (indicating PAD8
GB/T 11597—1999
Function Modification), the parameter value field shall be encoded with the decimal value of the first character indicating the function type that the remote PAD has invoked. Table 11/X.28 fully lists the current PAD functions, PAD function operations supported by MAPs that comply with Recommendation X.28 and this Recommendation. 4.4.7.2 For the break indication PAD message that notifies a break based on the Recommendation X.3 parameter set value, the reference number field shall be encoded as 00001000 (indicating parameter 8) and the parameter value field shall be encoded as 00000001 (indicating decimal 1). 8
2 Data Field
Figure 4 Break Indication PAD Message Format
4.4.8 Parameter Fields for Requesting the Elimination of PAD Message (see Figure 5) The PAD message shall not contain a parameter field.
Child's Byte Group
Reselect PAD Message Format
This message format is shown in Figure 6.
Request Clear PAD Message Format
Newly Selected DT Address Length
Reselected DT Address (Note 1)
Application Length
Call, User Activation Data (Note 2)
1This figure assumes that the number of half octets in the DTE address is an odd number. Number
Data Word
Data Separation
Create Data Segment
2A maximum of 12 octets may be present, or 124 octets when used with the fast selection facility. Figure 6 Reselect PAD Message Format
4.4.9.1 Reselected DTE Address Length Field Bits 4, 3, 2, and 1 in the Reselected DTE Address Length field indicate the address length of the reselected DTE in units of half an octet. The address length is binary coded, and bit 1 is the low-order bit of this indicator. 4.4.9.2Address Field
Octet 3 and subsequent octets constitute the reselected DTE address. Each digit in the address is binary-decimal encoded as a half-octet, where bit 5 or 1 is the low-order bit of the digit. The address encoded in octet 3 begins with the high-order digit, and each of the subsequent octets consists of 2 digits, with the high-order digit being the encoding of bits 8, 7, 6, and 5 of the respective octet. If necessary, the address field should be enclosed by inserting 0s in bits 4, 3, 2, and 1 of the last octet of the field.
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.