.rs .\" Troff code generated by TPS Convert from ITU Original Files .\" Not Copyright ( c) 1991 .\" .\" Assumes tbl, eqn, MS macros, and lots of luck. .TA 1c 2c 3c 4c 5c 6c 7c 8c .ds CH .ds CF .EQ delim @@ .EN .nr LL 40.5P .nr ll 40.5P .nr HM 3P .nr FM 6P .nr PO 4P .nr PD 9p .po 4P .rs \v | 5i' .sp 2P .LP \fB8\fR \fBGeneral message format and information element coding\fR .sp 1P .RT .PP This section should be read in conjunction with \(sc 4 of Recommendation\ Q.931 and contains the coding of the information elements specifically used by the procedures described in this Recommendation. .RT .sp 1P .LP 8.1 \fIMessage type\fR .sp 9p .RT .PP The following additional codings are defined in Table 8\(hy1/Q.932 for message type. .RT .sp 1P .LP 8.2 \fIOther information elements\fR .sp 9p .RT .PP These information elements are coded according to the general coding rules as defined in \(sc\ 4.5.1 of Recommendation\ Q.931. .PP \fINote\fR \ \(em\ The value used for Protocol discriminator shall be as defined for messages used in Recommendation\ Q.931. .PP Table 8\(hy2/Q.932 contains the codepoints allocated to the information elements defined in this Recommendation. .RT .sp 1P .LP 8.2.1 \fIEndpoint identifier\fR .sp 9p .RT .PP The purpose of the Endpoint identifier information element is: .RT .LP \(em to indicate the user service identifier and terminal identifier for the purpose of terminal identification; and .LP \(em to indicate a specific terminal for the purpose of terminal selection. .PP (See Annex A for the associated procedures.) .PP The Endpoint identifier information element is coded as shown in Figure\ 8\(hy1/Q.932 and Table\ 8\(hy3/Q.932. .PP The default maximum length of the Endpoint identifier information element is four octets. .RT .sp 1P .LP 8.2.2 \fIFacility\fR .sp 9p .RT .PP This section defines only the structure and the coding of the Facility information element. Specific procedures that will be required are subject to further study in relation to future Recommendations on specific supplementary services. .PP The purpose of the Facility information element is to indicate the invocation and operation of supplementary services, identified by the corresponding operation value within the Facility information element. The Facility information element is defined in Figures\ 8\(hy2/Q.932 to 8\(hy5/Q.932 and Tables\ 8\(hy4/Q.932 to 8\(hy20/Q.932. .PP The Facility information element may be repeated in a given message. .PP The maximum length of the Facility information element is application dependent consistent with the maximum length of the message. .RT .sp 1P .LP 8.2.2.1 \fIComponent (Octets 4, etc.)\fR .sp 9p .RT .PP This specification makes use of and is a subset of Recommendations\ X.208\ [7] (Specification of Abstract Syntax Notation One (ANS.1)), X.209\ [8] (Specification of basic encoding rules for Abstract Syntax Notation One (ANS.1)), X.219\ [9] (Remote operations: model, notation and service definition) and X.229\ [10] (Remote operations: protocol specification). Based on Recommendations\ X.208 and X.209, the following specific encoding apply. .PP A component is a sequence of data elements each of which is made up of a tag, a length and a contents. The component type is indicated by the first octet of the Facility information element component. The component types defined for the Facility information element are: .RT .LP \(em Invoke .LP \(em Return result .LP \(em Return error .LP \(em Reject. .PP \fINote 1\fR \ \(em\ Recommendation X.229 which defines the Remote Operations Service Element (ROSE) uses the term Application Protocol Data Unit (APDU) in place of component. However since this protocol element may be applied to the support of network layer services and of application layer services, the term \*Qcomponent\*U is more appropriate in the context of this Recommendation. .PP Tables 8\(hy5/Q.932 to 8\(hy8/Q.932 show the structure of these component types. .PP \fINote 2\fR \ \(em\ See Appendix III for a general description of the component coding and formatting principles. .bp .RT .ce \fBH.T. [T12.932]\fR .ce TABLE\ 8\(hy1/Q.932 .ce \fBQ.932 message types\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(66p) | lw(114p) . { 8\ \ 7\ \ 6\ \ 5\ \ 4\ \ 3\ \ 2\ \ 1 . 0\ \ 0\ \ 1\ -\ \ -\ \ -\ \ -\ \ - (Q.931 call information phase message group) \ \ \ \ \ \ \ \ \ 0\ \ 0\ \ 1\ \ 0\ \ 0 HOLD \ \ \ \ \ \ \ \ \ 0\ \ 1\ \ 0\ \ 0\ \ 0 HOLD ACKNOWLEDGE \ \ \ \ \ \ \ \ \ 1\ \ 0\ \ 0\ \ 0\ \ 0 HOLD REJECT \ \ \ \ \ \ \ \ \ 1\ \ 0\ \ 0\ \ 0\ \ 1 RETRIEVE \ \ \ \ \ \ \ \ \ 1\ \ 0\ \ 0\ \ 1\ \ 1 RETRIEVE ACKNOWLEDGE \ \ \ \ \ \ \ \ \ 1\ \ 0\ \ 1\ \ 1\ \ 1 RETRIEVE REJECT 0\ \ 1\ \ 1\ \ -\ \ -\ \ -\ \ -\ \ - (Q.931 miscellaneous message group) \ \ \ \ \ \ \ \ \ 0\ \ 0\ \ 0\ \ 1\ \ 0 FACILITY \ \ \ \ \ \ \ \ \ 0\ \ 0\ \ 1\ \ 0\ \ 0 REGISTER } _ .TE .nr PS 9 .RT .ad r \fBTableau 8\(hy1/Q.932 [T12.932], p.1\fR .sp 1P .RT .ad b .RT .LP .sp 5 .ce \fBH.T. [T13.932]\fR .ce TABLE\ 8\(hy2/Q.932 .ce \fBInformation elements specific to supplementary service .ce control\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(60p) | cw(96p) | cw(36p) | lw(36p) . { Bits 8\ \ 7\ \ 6\ \ 5\ \ 4\ \ 3\ \ 2\ \ 1 . } Reference \(sc { Maximum length (octets) (Note 1) 0\ \ : \ \ : \ \ : \ \ : \ \ : \ \ : \ \ : \fIVariable length information elements:\fR \ \ \ 0\ \ 0\ \ 1\ \ 1\ \ 1\ \ 0\ \ 0 \ Facility 8.2.2 Note 3 \ \ \ 0\ \ 1\ \ 1\ \ 0\ \ 0\ \ 1\ \ 0 \ Information request 8.2.5 \ 3 \ \ \ 0\ \ 1\ \ 1\ \ 1\ \ 0\ \ 0\ \ 0 \ Feature activation 8.2.3 \ 4 \ \ \ 0\ \ 1\ \ 1\ \ 1\ \ 0\ \ 0\ \ 1 \ Feature indication 8.2.4 \ 5 \ \ \ 0\ \ 1\ \ 1\ \ 1\ \ 0\ \ 1\ \ 0 \ Service profile identification 8.2.6 32 \ \ \ 0\ \ 1\ \ 1\ \ 1\ \ 0\ \ 1\ \ 1 \ Endpoint identifier 8.2.1 \ 4 } _ .T& lw(228p) . .TE .nr PS 9 .RT .ad r \fBTableau 8\(hy2/Q.932 [T13.932], p.2\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 18P .ad r \fBFigure 8\(hy1/Q.932 [T14.932], p.3\fR .sp 1P .RT .ad b .RT .LP .sp 5 .ce \fBH.T. [T15.932]\fR .ce TABLE\ 8\(hy3/Q.932 .ce \fBEndpoint identifier information element\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(228p) . { \fIUser service identifier (USID) (octet 3)\fR .LP The USID is a selection parameter which identifies a group of terminals on an interface which share a common service profile and which may be addressed together. Upon receipt of this element, a terminal will consider itself as being addressed if the value received matches its stored value or if the value received is coded as all \*Q1\*Us (127). When USID is coded as 127, octet 4 is not used. } .T& lw(228p) . { \fIInterpreter (octet 4)\fR .LP Bit 7 of octet 4 indicates how a terminal is to interpret the TID field received. When set to \*Q0\*U, the terminal is being addresses only if the TID matches (see TID definition following). When set to \*Q1\*U, the terminal is being addressed only if the TID received is not 63 and does not match. In the user\(hyto\(hynetwork direction, this bit is set to \*Q0\*U. } .T& lw(228p) . { \fITerminal identifier (TID) (octet 4)\fR .LP The TID is a selection parameter which identifies a single terminal within a group designated by a USID value. For USID\ =\ 127, the TID does not apply. Upon receipt to this field, a terminal will consider itself addressed if one of the following is true: .LP \(em the interpreter bit\ =\ \*Q0\*U and the value received matches the terminal's stored value; .LP \(em the interpreter bit\ =\ \*Q1\*U and the value received does not match the terminal's stored value; .LP \(em the value received is coded all \*Q1\*Us (63). } _ .TE .nr PS 9 .RT .ad r \fBTableau 8\(hy3/Q.932 [T15.932], p.4\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 18P .ad r \fBFigure 8\(hy2/Q.932 [T16.932], p.5\fR .sp 1P .RT .ad b .RT .LP .sp 5 .ce \fBH.T. [T17.932]\fR .ce TABLE\ 8\(hy4/Q.932 .ce \fBFacility information element\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(150p) . { \fIService discriminator\fR .LP Bits 5\ \ 4\ \ 3\ \ 2\ \ 1 .LP 1\ \ 0\ \ 0\ \ 0\ \ 1 Discriminator for supplementary service applications .LP All other values are reserved and their usage is the subject of other Recommendations. } _ .TE .nr PS 9 .RT .ad r \fBTableau 8\(hy4/Q.932 [T17.932], p.6\fR .sp 1P .RT .ad b .RT .LP .rs .sp 9P .ad r Blanc .ad b .RT .LP .bp .ce \fBH.T. [T18.932] .ce TABLE\ 8\(hy5/Q.932 .ce \fBInvoke component\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(108p) | cw(44p) | cw(38p) | cw(38p) . Invoke component Reference \(sc Mandatory indication Octet group _ .T& lw(6p) | lw(102p) | cw(44p) | cw(38p) | cw(38p) . Component type tag 8.2.2.3 Mandatory \ 4 .T& lw(6p) | lw(102p) | cw(44p) | cw(38p) | cw(38p) . Component length (Note 1) 8.2.2.2 \ 5 .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . { Invoke identifier tag Invoke identifier length Invoke identifier } 8.2.2.4 8.2.2.2 Mandatory \ 6 \ 7 \ 8 _ .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . Linked identifier tag 8.2.2.4 Optional \ 9 .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . Linked identifier length 8.2.2.2 10 .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . Linked identifier 11 _ .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . Operation value tag 8.2.2.5 Mandatory 12 .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . Operation value length 8.2.2.2 13 .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . Operation value (Note 3) 14 _ .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . Argument (Note 2) 8.2.2.8 (Note 3) Optional 15, etc. .T& lw(228p) . .TE .nr PS 9 .RT .ad r \fBTableau 8\(hy5/Q.932 [T18.932], p.7\fR .sp 1P .RT .ad b .RT .LP .rs .sp 22P .ad r Blanc .ad b .RT .LP .bp .ce \fBH.T. [T19.932] .ce TABLE\ 8\(hy6/Q.932 .ce \fBReturn result component\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(108p) | cw(44p) | cw(38p) | cw(38p) . Return result component Reference \(sc Mandatory indication Octet group _ .T& lw(6p) | lw(102p) | cw(44p) | cw(38p) | cw(38p) . Component type tag 8.2.2.3 Mandatory \ 4 .T& lw(6p) | lw(102p) | cw(44p) | cw(38p) | cw(38p) . Component length (Note 3) 8.2.2.2 \ 5 .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . { Invoke identifier tag Invoke identifier length Invoke identifier } 8.2.2.4 8.2.2.2 Mandatory \ 6 \ 7 \ 8 _ .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . Sequence tag 8.2.2.8 Optional \ 9 .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . Sequence length (Note 4) 8.2.2.2 (Note 1) 10 .T& lw(96p) | cw(44p) | cw(38p) | cw(38p) . { Operation value tag Operation value length Operation value } 8.2.2.5 8.2.2.2 (Note 6) Optional (Note 2) 11 12 13 _ .T& lw(96p) | cw(44p) | cw(38p) | cw(38p) . Result (Note 5) 8.2.2.8 (Note 6) Optional 14, etc. .T& lw(228p) . .TE .nr PS 9 .RT .ad r \fBTableau 8\(hy6/Q.932 [T19.932], p.8\fR .sp 1P .RT .ad b .RT .LP .rs .sp 18P .ad r Blanc .ad b .RT .LP .bp .ce \fBH.T. [T20.932] .ce TABLE\ 8\(hy7/Q.932 .ce \fBReturn error component\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(108p) | cw(44p) | cw(38p) | cw(38p) . Return error component Reference \(sc Mandatory indication Octet group _ .T& lw(6p) | lw(102p) | cw(44p) | cw(38p) | cw(38p) . Component type tag 8.2.2.3 Mandatory \ 4 .T& lw(6p) | lw(102p) | cw(44p) | cw(38p) | cw(38p) . Component length (Note 1) 8.2.2.2 \ 5 .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . { Invoke identifier tag Invoke identifier length Invoke identifier } 8.2.2.4 8.2.2.2 Mandatory \ 6 \ 7 \ 8 _ .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . Error value tag 8.2.2.6 Mandatory \ 9 .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . Error value length 8.2.2.2 10 .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . Error value 11 _ .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . Parameter (Note 2) 8.2.2.8 (Note 3) Optional 12, etc. .T& lw(228p) . .TE .nr PS 9 .RT .ad r \fBTableau 8\(hy7/Q.932 [T20.932], p.9\fR .sp 1P .RT .ad b .RT .LP .sp 4 .ce \fBH.T. [T21.932] .ce TABLE\ 8\(hy8/Q.932 .ce \fBReject component\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(108p) | cw(44p) | cw(38p) | cw(38p) . Reject component Reference Mandatory indication Octet group _ .T& lw(6p) | lw(102p) | cw(44p) | cw(38p) | cw(38p) . Component type tag 8.2.2.3 Mandatory \ 4 .T& lw(6p) | lw(102p) | cw(44p) | cw(38p) | cw(38p) . Component length (Note) 8.2.2.2 \ 5 .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . { Invoke identifier tag Invoke identifier length Invoke identifier } 8.2.2.4 8.2.2.2 Mandatory \ 6 \ 7 \ 8 _ .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . Problem tag 8.2.2.7 Mandatory \ 9 .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . Problem length 8.2.2.2 10 .T& lw(102p) | cw(44p) | cw(38p) | cw(38p) . Problem 8.2.2.7 11 .T& lw(228p) . .TE .nr PS 9 .RT .ad r \fBTableau 8\(hy8/Q.932 [T21.932], p.10\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 8.2.2.2 \fILength of each component or of their data elements\fR .sp 9p .RT .PP Lengths up to 127 octets are coded using the short form of Recommendation\ X.209: bit\ 8 is set to zero and the remaining seven bits are a binary encoding of the length, with bit\ 1 the least significant bit. (This length encoding is identical to that of Recommendation\ Q.931 for lengths up to 127\ octets.) This is illustrated in Figure\ 8\(hy3/Q.932. .RT .LP .rs .sp 11P .ad r \fBFigure 8\(hy3/Q.932 [T22.932], p.\fR .sp 1P .RT .ad b .RT .PP .sp 5 If the length of the contents is greater than 127 octets, then the long form of the length of the contents is used. The long form length is from 2 to 127\ octets long. Bit\ 8 of the first octet is coded\ 1, and bits\ 1 to\ 7 of the first octet encode a number one less than the size of the length in octets as an unsigned binary number whose MSB and LSB are bits\ 7 and\ 1, respectively. The length itself is encoded as an unsigned binary number whose MSB and LSB are bit\ 8 of the second octet and bit\ 1 of the last octet, respectively. This binary number should be encoded in the fewest possible octets, with no leading octets having the value\ 0. This is illustrated in Figure\ 8\(hy4/Q.932. .LP .rs .sp 16P .ad r \fBFigure 8\(hy4/Q.932 [T23.932], p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 8.2.2.3 \fIComponent type tag\fR .sp 9p .RT .PP The coding of the component type tag is shown in Table 8\(hy9/Q.932. .RT .LP .sp 2 .ce \fBH.T. [T24.932]\fR .ce TABLE\ 8\(hy9/Q.932 .ce \fBComponent type tag\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(90p) | lw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) , ^ | l | l | l | l | l | l | l | l. { Component type tag Bits 8 7 6 5 4 3 2 1 } _ .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Invoke 1 0 1 0 0 0 0 1 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Return result 1 0 1 0 0 0 1 0 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Return error 1 0 1 0 0 0 1 1 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Reject 1 0 1 0 0 1 0 0 _ .TE .nr PS 9 .RT .ad r \fBTable 8\(hy9/Q.932 [T24.932], p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP .sp 5 8.2.2.4 \fIComponent identifier tags\fR .sp 9p .RT .PP An invoke identifier is used to identify an operation invocation and is reflected in the return result or return error that responds to it. An invoke may refer to another invoke through the linked identifier. When a protocol error occurs, the invoke identifier is reflected in the reject component, but if it is not available, a null is returned. Invoke and linked identifiers are one octet long. The null has zero length. The coding of the component identifier tags is shown in Table 8\(hy10/Q.932. .RT .LP .sp 2 .ce \fBH.T. [T25.932]\fR .ce TABLE\ 8\(hy10/Q.932 .ce \fBCoding of component identifier tag\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | lw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) , ^ | l | l | l | l | l | l | l | l. Bits 8 7 6 5 4 3 2 1 _ .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Invoke identifier 0 0 0 0 0 0 1 0 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Linked identifier 1 0 0 0 0 0 0 0 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Null 0 0 0 0 0 1 0 1 _ .TE .nr PS 9 .RT .ad r \fBTableau 8\(hy10/Q.932 [T25.932], p.14\fR .sp 1P .RT .ad b .RT .LP .rs .sp 2P .ad r Blanc .ad b .RT .LP .bp .sp 1P .LP 8.2.2.5 \fIOperation value tag\fR .sp 9p .RT .PP The operation value specifies the facility or supplementary service application and operation being requested. Values are encoded as integers. The value of the operation value is supplementary service specific and will be specified in future Recommendations which contain the protocol for individual supplementary services. The coding for the operation value tag is shown in Table\ 8\(hy11/Q.932. .RT .ce \fBH.T. [T26.932]\fR .ce TABLE\ 8\(hy11/Q.932 .ce \fBCoding of operation value tag\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | lw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) , ^ | l | l | l | l | l | l | l | l. Bits 8 7 6 5 4 3 2 1 _ .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Operation value tag 0 0 0 0 0 0 1 0 _ .TE .nr PS 9 .RT .ad r \fBTable 8\(hy11/Q.932 [T26.932], p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP .sp 6 8.2.2.6 \fIError value tag\fR .sp 9p .RT .PP Operations report errors as specified for each individual operation. Values are encoded as integers. The coding for the error value tag is shown in Table 8\(hy12/Q.932. .RT .LP .sp 2 .ce \fBH.T. [T27.932]\fR .ce TABLE\ 8\(hy12/Q.932 .ce \fBCoding of error value tag\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | lw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) , ^ | l | l | l | l | l | l | l | l. Bits 8 7 6 5 4 3 2 1 _ .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Error value tag 0 0 0 0 0 0 1 0 _ .TE .nr PS 9 .RT .ad r \fBTableau 8\(hy12/Q.932 [T27.932], p.16\fR .sp 1P .RT .ad b .RT .LP .rs .sp 6P .ad r Blanc .ad b .RT .LP .bp .sp 1P .LP 8.2.2.7 \fIProblem tag\fR .sp 9p .RT .PP Protocol problems are indicated in groups. Table 8\(hy13/Q.932 indicates the tags for these groups. The contents for each of these tags is indicated in Tables\ 8\(hy14/Q.932 to 8\(hy17/Q.932. The contents of these tags are defined in Table\ 8\(hy18/Q.932. .RT .LP .sp 2 .ce \fBH.T. [T28.932]\fR .ce TABLE\ 8\(hy13/Q.932 .ce \fBCoding of problem tags .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(90p) | lw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) , ^ | l | l | l | l | l | l | l | l. { Problem Bits 8 7 6 5 4 3 2 1 } _ .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . General problem 1 0 0 0 0 0 0 0 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Invoke problem 1 0 0 0 0 0 0 1 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Return result problem 1 0 0 0 0 0 1 0 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Return error problem 1 0 0 0 0 0 1 1 _ .TE .nr PS 9 .RT .ad r \fBTableau 8\(hy13/Q.932 [T28.932], p.17\fR .sp 1P .RT .ad b .RT .LP .sp 5 .ce \fBH.T. [T29.932]\fR .ce TABLE\ 8\(hy14/Q.932 .ce \fBCoding of general problem\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | lw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) , ^ | l | l | l | l | l | l | l | l. Bits 8 7 6 5 4 3 2 1 _ .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Unrecognized component 0 0 0 0 0 0 0 0 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Mistyped component 0 0 0 0 0 0 0 1 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Badly structured component 0 0 0 0 0 0 1 { 0 \fINote\fR \ \(em\ ROSE uses the term application protocol data unit (APDU) in place of component. .LP } _ .TE .nr PS 9 .RT .ad r \fBTableau 8\(hy14/Q.932 [T29.932], p.18\fR .sp 1P .RT .ad b .RT .LP .rs .sp 10P .ad r Blanc .ad b .RT .LP .bp .ce \fBH.T. [T30.932]\fR .ce TABLE\ 8\(hy15/Q.932 .ce \fBCoding of invoke problem\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | lw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) , ^ | l | l | l | l | l | l | l | l. Bits 8 7 6 5 4 3 2 1 _ .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Duplicate invocation 0 0 0 0 0 0 0 0 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Unrecognized operation 0 0 0 0 0 0 0 1 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Mistyped argument 0 0 0 0 0 0 1 0 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Resource limitation 0 0 0 0 0 0 1 1 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Initiator releasing 0 0 0 0 0 1 0 0 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . { Unrecognized linked identifier } 0 0 0 0 0 1 0 1 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Linked response unexpected 0 0 0 0 0 1 1 0 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Unexpected child operation 0 0 0 0 0 1 1 1 _ .TE .nr PS 9 .RT .ad r \fBTableau 8\(hy15/Q.932 [T30.932], p.19\fR .sp 1P .RT .ad b .RT .LP .sp 2 .ce \fBH.T. [T31.932]\fR .ce TABLE\ 8\(hy16/Q.932 .ce \fBCoding of return result problem .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | lw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) , ^ | l | l | l | l | l | l | l | l. Bits 8 7 6 5 4 3 2 1 _ .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Unrecognized invocation 0 0 0 0 0 0 0 0 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Result response unexpected 0 0 0 0 0 0 0 1 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Mistyped result 0 0 0 0 0 0 1 0 _ .TE .nr PS 9 .RT .ad r \fBTableau 8\(hy16/Q.932 [T31.932], p.20\fR .sp 1P .RT .ad b .RT .LP .sp 2 .ce \fBH.T. [T32.932]\fR .ce TABLE\ 8\(hy17/Q.932 .ce \fBCoding of return error problem\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | lw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) , ^ | l | l | l | l | l | l | l | l. Bits 8 7 6 5 4 3 2 1 _ .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Unrecognized invocation 0 0 0 0 0 0 0 0 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Error response unexpected 0 0 0 0 0 0 0 1 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Unrecognized error 0 0 0 0 0 0 1 0 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Unexpected error 0 0 0 0 0 0 1 1 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Mistyped parameter 0 0 0 0 0 1 0 0 _ .TE .nr PS 9 .RT .ad r \fBTableau 8\(hy17/Q.932 [T32.932], p.21\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [T33.932]\fR .ce TABLE\ 8\(hy18/Q.932 .ce \fBProblem code definitions\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(78p) | lw(150p) . \fIGeneral\(hyproblem\fR .T& lw(78p) | lw(150p) . { \(em unrecognized\(hycomponent } { signifies that the type of the component, as evidenced by its type identifier, is not one of the four defined by Recommendation X.229 [10] } .T& lw(78p) | lw(150p) . \(em mistyped\(hycomponent { signifies that the structure of the component does not conform to Recommendation X.229 } .T& lw(78p) | lw(150p) . { \(em badly\(hystructured\(hycomponent } { signifies that the struture fo the component does not conform to the standard notation and encoding, defined in Recommendations X.208\ [7] and X.209\ [8] } .T& lw(78p) | lw(150p) . \fIInvoke\(hyproblem\fR .T& lw(78p) | lw(150p) . \(em duplicate\(hyinvocation { signifies that the invoke\(hyidentifier parameter violates the assignment rules of Recommendation X.219 [9] } .T& lw(78p) | lw(150p) . { \(em unrecognized\(hyoperation } { signifies that the operation is not one of those agreed between the user and the network } .T& lw(78p) | lw(150p) . \(em mistyped\(hyargument { signifies that the type of the operation argument supplied is not that agreed between the user and the network } .T& lw(78p) | lw(150p) . \(em resource\(hylimitation { the performing user or network is not able to perform the invoked operation due to resource limitation } .T& lw(78p) | lw(150p) . \(em initiator\(hyreleasing { the association\(hyinitiator is not willing to perform the invoked operation because it is about to attempt to release the application\(hyassociation } .T& lw(78p) | lw(150p) . { \(em unrecognized\(hylinked\(hyidentifier } { signifies that there is no operation in progress with an invoke\(hyidentifier equal to the specified linked\(hyidentifier } .T& lw(78p) | lw(150p) . { \(em linked\(hyresponse\(hyunexpected } { signifies that the invoked operation referred to by linked\(hyidentifier is not a parent\(hyoperation } .T& lw(78p) | lw(150p) . { \(em unexpected\(hychild\(hyoperation } { signifies that the invoked child\(hyoperation is not one that the invoked parent\(hyoperation referred to by the linked\(hyidentifier allows } .T& lw(78p) | lw(150p) . { \fIReturn\(hyresult\(em\(hyroblem\fR } .T& lw(78p) | lw(150p) . { \(em unrecognized\(hyinvocation } { signifies that no operation with the specified invoke\(hyidentifier is in progress } .T& lw(78p) | lw(150p) . { \(em result\(hyresponse\(hyunexpected } { signifies that the invoke operation does not report a result } .T& lw(78p) | lw(150p) . \(em mistyped\(hyresult { signifies that the type of the result parameter supplied is not that agreed between the user and the network } .T& lw(78p) | lw(150p) . { \fIReturn\(hyerror\(hyproblem\fR } .T& lw(78p) | lw(150p) . { \(em unrecognized\(hyinvocation } { signifies that no operation with the specified invoke\(hyidentifier is in progress } .T& lw(78p) | lw(150p) . { \(em error\(hyresponse\(hyunexpected } { signifies that the invoked operation does not report failure } .T& lw(78p) | lw(150p) . \(em unrecognized\(hyerror { signifies that the reported error is not one of those agreed between the user and the network } .T& lw(78p) | lw(150p) . \(em unexpected\(hyerror { signifies that the reported error is not one that the invoked operation may report } .T& lw(78p) | lw(150p) . \(em mistyped\(hyparameter { signifies that the type of the error parameters supplied is not that agreed between the user and the network \fINote\fR \ \(em\ The former definitions are adapted from \(sc\(sc 7.4.4.2 and 7.5.4.2 of Recommendation X.229 (Remote operations: protocol specification). .LP } _ .TE .nr PS 9 .RT .ad r \fBTableau 8\(hy18/Q.932 [T33.932], p.22\fR .sp 1P .RT .ad b .RT .LP .rs .sp 4P .ad r Blanc .ad b .RT .LP .bp .sp 1P .LP 8.2.2.8 \fIParameters\fR .sp 9p .RT .PP The parameters included with a component (i.e., the argument with an invoke, the result with a return result or the parameter with a return error) are indicated in the specification of the operation. They may include optional and default parameters. Parameters shall be one of the following: .RT .LP \(em a sequence of parameters .LP \(em a set of parameters .LP \(em a specific parameter with its own tag .LP \(em nothing at all (i.e., absent). .PP When more than one parameter is required, they shall follow a sequence or set tag as specified in the specification of the operation. (The usage of the sequence and set tags is defined in Recommendations\ X.208/X.209.) .PP Sequences and sets of parameters may contain further sequences and sets as specified for the operation to be performed. Table\ 8\(hy19/Q.932 indicates the coding of the sequence and set tags. .RT .LP .sp 2 .ce \fBH.T. [T34.932]\fR .ce TABLE\ 8\(hy19/Q.932 .ce \fBCoding of sequence and set tags\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | lw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) , ^ | l | l | l | l | l | l | l | l. Bits 8 7 6 5 4 3 2 1 _ .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Sequence tag 0 0 1 1 0 0 0 0 .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Set tag 0 0 1 1 0 0 0 1 _ .TE .nr PS 9 .RT .ad r \fBTable 8\(hy19/Q.932 [T34.932], p.\fR .sp 1P .RT .ad b .RT .LP .sp 5 .sp 1P .LP 8.2.2.9 \fITreatment of existing Recommendation Q.931 information\fR \fIelements as parameters\fR .sp 9p .RT .PP Supplementary service protocol specifications are expected to require new parameters to be defined and to require existing Recommendation\ Q.931 information elements (Note\ 1). .PP New parameters shall be defined using Recommendation X.209 coding if they do not appear elsewhere in Q.931 messages. .PP Supplementary service protocol specifiers may elect to encapsulate one or more existing Recommendation\ Q.931 information elements within a Recommendation\ X.209 data element, thereby retaining the Recommendation\ Q.931 coding for these information elements. When this option is chosen, all the Recommendation\ Q.931 information elements should be grouped together as the content following the Recommendation Q.931 information elements tag. This is illustrated in Figure\ 8\(hy5/Q.932. The tag is defined in Table\ 8\(hy20/Q.932. This data element may appear by itself or as a member of a sequence or set as indicated in \(sc\ 8.2.2.8. .PP \fINote\ 1\fR \ \(em\ Encapsulation of the Facility information element within Facility information elements shall not be used. .RT .LP .rs .sp 4P .ad r Blanc .ad b .RT .LP .bp .LP .rs .sp 25P .ad r \fBFigure 8\(hy5/Q.932, p.24\fR .sp 1P .RT .ad b .RT .LP .sp 4 .ce \fBH.T. [T35.932]\fR .ce TABLE\ 8\(hy20/Q.932 .ce \fBQ.931 information elements tag\fR .ce .ce \fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | lw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) sw(12p) sw(18p) , ^ | l | l | l | l | l | l | l | l. Bits 8 7 6 5 4 3 2 1 _ .T& lw(90p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) . Q.931 information elements 0 1 0 0 0 0 0 0 .TE .LP \fINote\fR \ \(em\ All other values are reserved but this approach may also be applied in the future to coding structures from other Recommendations by defining other tags as required. .nr PS 9 .RT .ad r \fBTableau 8\(hy20/Q.932 [T35.932], p.25\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 8.2.3 \fIFeature activation\fR .sp 9p .RT .PP The purpose of the Feature activation information element is to invoke a supplementary service as identified by the feature identifier number. The service associated with the feature identifier number is dependent on that particular user's service profile. .PP The maximum length of this information element is 4\ octets. .PP The Feature activation information element is coded as shown in Figure\ 8\(hy6/Q.932 and Table\ 8\(hy21/Q.932. .RT .LP .sp 2 .rs .sp 17P .ad r \fBFigure 8\(hy6/Q.932 [T36.932], p.\fR .sp 1P .RT .ad b .RT .LP .sp 5 .ce \fBH.T. [T37.932]\fR .ce TABLE\ 8\(hy21/Q.932 .ce \fBFeature activation information element\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(228p) . { \fIFeature identifier number (octets 3 and 3a)\fR .LP The feature identifier number is a unique number assigned to a feature in a customer account that is coded as part of both the Feature activation and Feature indication information elements. This number identifies the feature that is being requested or updated. The association of a particular number to a particular feature may be different for each user. .LP Bit 8 in octet 3 is used to extend the feature identifier field. If bit 8 is 0, then another octet follows; if bit 8 is 1, then octet 3 is the last octet. The identifier numbers for a one octet field range from 1 to 127. For a multi\(hyoctet field, the order of bit values progressively decrases as the octet number increases. } _ .TE .nr PS 9 .RT .ad r \fBTable 8\(hy21/Q.932 [T37.932], p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 8.2.4 \fIFeature indication\fR .sp 9p .RT .PP The purpose of the Feature indication information element is to allow the network to convey feature indications to the user regarding the status of a supplementary service. .PP The maximum length of this information element is 5\ octets. .PP The coding of the Feature indication information element is shown in Figure\ 8\(hy7/Q.932 and Table\ 8\(hy22/Q.932. .RT .LP .rs .sp 19P .ad r \fBFigure 8\(hy7/Q.932 [T38.932], p.\fR .sp 1P .RT .ad b .RT .ce \fBH.T. [T39.932]\fR .ce \fB .ce TABLE\ 8\(hy22/Q.932 .ce \fBFeature indication information element\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(228p) . { \fIFeature identifier number (octets 3 and 3a)\fR } .T& lw(228p) . { These fields are coded as described in Table 8\(hy21/Q.932. } .T& lw(228p) . { \fIStatus indicator (octet 4)\fR } .T& lw(228p) . { The status indicator field identifies the current status of a supplementary service. } .TE .TS center box ; lw(36p) | lw(36p) | lw(69p) | lw(69p) . Bits .line 4\ \ 3\ \ 2\ \ 1 \fIStatus\fR \fIMeaning\fR { \fIExamples of possible user equipment implementation\fR } .T& lw(36p) | lw(36p) | lw(69p) | lw(69p) . 0\ \ 0\ \ 0\ \ 0 Deactivated { Feature is in the deactivated state } Lamp off .T& lw(36p) | lw(36p) | lw(69p) | lw(69p) . 0\ \ 0\ \ 0\ \ 1 Activated { Feature is in the active state } Lamp steady on .T& lw(36p) | lw(36p) | lw(69p) | lw(69p) . 0\ \ 0\ \ 1\ \ 0 Prompt { Feature prompt (waiting for user input) } Lamp steady flash .T& lw(36p) | lw(36p) | lw(69p) | lw(69p) . 0\ \ 0\ \ 1\ \ 1 Pending Feature is pending Lamp steady wink .TE .TS center box ; lw(228p) . { All other values are reserved. } _ .TE .nr PS 9 .RT .ad r \fBTable 8\(hy22/Q.932 [T39.932], p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 8.2.5 \fIInformation request\fR .sp 9p .RT .PP The purpose of the Information request information element is to provide the capability for requesting additional information and signalling completion of the information request (see Annex\ B). .PP The Information request information element is coded as shown in Figure\ 8\(hy8/Q.932 and Table\ 8\(hy23/Q.932. .PP The default maximum length of the Information request information element is three octets. .RT .LP .rs .sp 14P .ad r \fBFigure 8\(hy8/Q.932 [T40.932], p.\fR .sp 1P .RT .ad b .RT .LP .sp 5 .ce \fBH.T. [T41.932]\fR .ce TABLE\ 8\(hy23/Q.932 .ce \fBInformation request information element\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(180p) . { \fIInformation request indicator (octet 3, bit 7)\fR Bit 7 .LP 0 Information request completed .LP 1 Prompt for additional information } .T& lw(180p) . { \fIType of information (octet 3, bits 1\(hy6)\fR .LP Bits 6\ \ 5\ \ 4\ \ 3\ \ 2\ \ 1 .LP 0\ \ 0\ \ 0\ \ 0\ \ 0\ \ 0 undefined .LP 0\ \ 0\ \ 0\ \ 0\ \ 0\ \ 1 authorization code .LP 0\ \ 0\ \ 0\ \ 0\ \ 1\ \ 0 address digits .LP 0\ \ 0\ \ 0\ \ 0\ \ 1\ \ 1 terminal identification .LP All other values are reserved. } _ .TE .nr PS 9 .RT .ad r \fBTable 8\(hy23/Q.932 [T41.932], p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 8.2.6 \fIService profile identification\fR .sp 9p .RT .PP The purpose of the Service profile identification information element is to allow the user to initiate automatic assignment of the user service identifier and terminal identifier (see Annex\ A). .PP The Service profile identification information element is defined in Figure\ 8\(hy9/Q.932 and Table\ 8\(hy24/Q.932. .PP The default maximum length of the Service profile identification information element is 32\ octets. .RT .LP .rs .sp 14P .ad r \fBFigure 8\(hy9/Q.932 [T42.932], p.\fR .sp 1P .RT .ad b .RT .LP .sp 5 .ce \fBH.T. [T43.932]\fR .ce TABLE\ 8\(hy24/Q.932 .ce \fBService profile identification information element\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(204p) . { \fISPID (octet 3, etc.)\fR .LP The service profile identifier parameter is coded in IA5 characters, according to the format specified by the network. } _ .TE .nr PS 9 .RT .ad r \fBTable 8\(hy24/Q.932 [T43.932], p.\fR .sp 1P .RT .ad b .RT .LP .rs .sp 9P .ad r Blanc .ad b .RT .LP .bp .ce 1000 ANNEX\ A .ce 0 .ce 1000 (to Recommendation Q.932) .sp 9p .RT .ce 0 .ce 1000 \fBUser service profiles and terminal identification\fR .sp 1P .RT .ce 0 .LP \fR A.1 \fIIntroduction\fR .sp 1P .RT .PP These optional procedures allow an ISDN to support identification and selection of specific terminals on a multi\(hypoint user\(hynetwork interface to support multiple user service profiles in those cases in which Recommendation\ Q.931 information elements are not sufficient for such purposes. .PP A terminal or network which desires to support such multiple profiles for terminals which could not otherwise be distinguished, must support this additional identification procedure. Otherwise, it is completely optional. .RT .ce \fBH.T. [T44.932]\fR .ce TABLE\ A\(hy1/Q.932 .ce \fBTerminology .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(48p) | lw(150p) . Service profile { Service profile refers to the information that the network maintains for a given user to characterize the service offered by the network to that user. As an example, this may contain the association of feature identifiers to specific supplementary services. A service profile may be allocated to an access interface or to a particular user equipment or a group of user equipments. } _ .T& lw(48p) | lw(150p) . SPID { The service profile identifier is a parameter carried in a service profile identification information element that is sent from the user to network to allow network assignment of a USID and TID. A user's SPID should uniquely identifiy a specific profile of service characteristics stored within the network. The SPID will allow the network to distinguish between different terminals that would otherwise be indistinguishable (e.g., same ISDN number). The SPID value is provided to the user at subscription time. } _ .T& lw(48p) | lw(150p) . USID { User service identifier. A USID uniquely identifies a service profile on an access interface. } _ .T& lw(48p) | lw(150p) . TID { Terminal identifier. A TID value is unique within a given USID. If two terminals on an interface subscribe to the same service profile, then the two terminals will be assigned the same service USID. However, two different TIDs are required to uniquely identify each of the two terminals. } _ .T& lw(48p) | lw(150p) . EID { Endpoint identifier. The endpoint identifier information element is used for terminal identification. The endpoint identifier parameters contain a USID and TID and additional information used to interpret them. } _ .TE .nr PS 9 .RT .ad r \fBTable A\(hy1/Q.932 [T44.932], p.\fR .sp 1P .RT .ad b .RT .PP Figure A\(hy1/Q.932 shows examples of the relationships of terminals, SPIDs, USIDs, and TIDs and their dynamic relationship to TEIs. In this example, terminals\ 1, 3, 4 and 5 support the automatic endpoint identifier parameter assignment procedure and terminal\ 2 does not, but has the endpoint identifier parameters locally entered. Terminal 6 does not support terminal identification, therefore it utilizes the specified default service profile. .PP \fINote\fR \ \(em\ Items in parentheses indicate values or relationships which are dynamically established by initialization procedures (see \(sc\ A.4). Others are established via administrative actions and stored as a result of manual entry. .bp .RT .LP .rs .sp 41P .ad r \fBFigure A\(hy1/Q.932, p.\fR .sp 1P .RT .ad b .RT .PP A user or network that does not recognize the information elements used by this Annex shall, if these elements are received, apply the error procedures defined in \(sc\ 5.8 of Recommendation\ Q.931. .RT .sp 1P .LP A.2 \fIUser service profiles\fR .sp 9p .RT .PP The support of user service profiles requires that the service requests from a terminal are associated by the network with a specific profile. A USID is used to identify the profile on an access. The service profile is assigned to a data link connection so that the network can associate all of the service requests from the corresponding Connection Endpoint Suffix (CES) with the required profile (see Note). The assignment of a service profile to a data link connection minimizes the per\(hyservice request overhead of profile identification. .bp .PP The procedures for assigning service profile to a data link connection are incorporated into the initialization procedures described in \(sc\ A.4. .PP \fINote\fR \ \(em\ CES along with SAPI constitute the CEI (Connection Endpoint Identifier) that is used to identify message units passed between the data link layer (as represented by the TEI) and Layer\ 3. .RT .sp 1P .LP A.3 \fITerminal identification\fR .sp 9p .RT .PP The support of terminal identification requires that a call sent by the network can be addressed to: .RT .LP \(em all of the terminals of a user service profile; .LP \(em one terminal of a user service profile; or .LP \(em all but one terminal of a user service profile. .PP A USID is used to identify the user service profile with a (set of) terminals on an access interface and a TID is used to identify individual terminals within a user service profile on an access. .PP The USID and TID may be entered into the terminal by the user as arranged at subscription time, or dynamically downloaded to the terminal from the network with an automatic assignment procedure. .PP The USID and TID parameters are used by the terminal to check the compatibility of a call offered by the network. The inclusion of a USID and TID with only access uniqueness minimizes the per\(hycall overhead of supporting terminal addressing. .PP The procedures for downloading the USID and TID to a terminal are incorporated into the automatic endpoint identifier allocation and initialization procedures described in \(sc\ A.4. The procedures for using a USID and TID for terminal identification in an offered call sent by the network are described in \(sc\ A.5. .RT .sp 1P .LP A.4 \fIInitialization\fR .sp 9p .RT .PP The initialization procedure provides for the association by the network of the service requests from a terminal on a particular data link connection (as represented by the TEI) with a user service profile. A user requested automatic assignment procedure is described to also support automatic assignment of USID and TID parameters and their downloading by the network to a terminal. .PP Since initialization provides the basis for subsequent association of a service profile with a data link connection, normally, user equipment that supports initialization is expected to request the initialization procedure (e.g.,\ on the first Layer\ 3 message after dynamic assignment of a TEI). However, a request for initialization is allowed at any time. The data link connection is always associated with the most recently identified service profile. Under some circumstances, the network may solicit terminal initialization. .RT .sp 1P .LP A.4.1 \fITerminal requested initialization\fR .sp 9p .RT .LP a) Terminals may initialize by sending an Endpoint identifier information element (containing a USID and TID) in an INFORMATION message at any time to the network. Subsequent to this, the network may associate the service profile with the data link over which the message was sent. .LP b) For terminals which support automatic assignment of USID and TID parameters, initialization (that is, association of a service profile with a data link connection) is provided as part of the automatic assignment procedure described here. .LP A user may initiate automatic assignment of the endpoint identifier by sending a Service profile identification information element in an INFORMATION message with the dummy call reference. The Service profile identification information element should contain the SPID parameter allocated at the time of subscription. The initialization is acknowledged with an INFORMATION message with the Endpoint identifier information element containing a USID and TID, the values of which are determined by the network. It results in an association of the data link over which it was received with the identified service profile. .LP When a terminal determines that the initialization procedure has failed, it assumes that the network cannot support the procedure and does not repeatedly attempt initialization. .bp .sp 1P .LP A.4.2 \fINetwork solicited initialization\fR .sp 9p .RT .PP The network may solicit a request for initialization on a data link connection by sending an Information request information element with codepoint \*Qterminal identification\*U in an INFORMATION message with the dummy call reference. Upon receiving the request, the terminal may respond as described in the previous \(sc\ A.4.1\ a) or\ b). .PP When a network determines that the initialization procedure has failed, it assumes that the terminal cannot support the procedures and does not repeatedly request initialization. .RT .sp 1P .LP A.4.3 \fICollision\fR .sp 9p .RT .PP When terminal initialization and network solicitation procedures collide, the terminal ignores the solicitation from the network and the network proceeds as normal upon receipt of the initialization request from the terminal. .RT .sp 1P .LP A.5 \fIIdentification procedures\fR .sp 9p .RT .PP When the network offers a call using terminal addressing, the Endpoint identifier information element is included in the SETUP message. .PP When a terminal receives a SETUP message containing the Endpoint identifier information element, it shall: .RT .LP \(em if it is not supported, handle the Endpoint identifier information element in accordance with \(sc\ 5.8.7 of Recommendation\ Q.931 and complete normal compatibility checking procedures; or, .LP \(em test for an address compatibility with the Endpoint identifier information element if it is supported in addition to completing the normal compatibility checking procedures. \v'6p' .ce 1000 ANNEX\ B .ce 0 .ce 1000 (to Recommendation Q.932) .sp 9p .RT .ce 0 .ce 1000 \fBInformation request procedures\fR .sp 1P .RT .ce 0 .LP \fR B.1 \fIIntroduction\fR .sp 1P .RT .PP This Annex specifies optional procedures to allow a network to request additional information from a user. These procedures do not impact the Recommendation\ Q.931 call state. This capability shall only be allowed during the Null, Overlap Sending, Outgoing Call Proceeding, Call Delivered, and Activate call states. .PP The capability is intended for use with the Keypad and Feature key management protocols. .PP A user or network that does not recognize the information elements used by this Annex shall, if these information elements are received, apply the error recovery procedures defined in \(sc\ 5.8 of Recommendation\ Q.931. .RT .sp 2P .LP B.2 \fIProcedures\fR .sp 1P .RT .sp 1P .LP B.2.1 \fINormal procedures\fR .sp 9p .RT .PP The network will send an INFORMATION message to the user to request additional information. The INFORMATION message will contain the Information request information element (see \(sc\ 8), with the information request indicator set to \*Qprompt for additional information\*U and type of information set to the appropriate value. After sending the INFORMATION message, the network will start timer\ T302. The network will restart timer\ T302 on the receipt of every INFORMATION message if the requested information is not complete. .PP No Recommendation Q.931 call state changes should occur when the INFORMATION message is sent or received. .bp .PP The user may always send the requested information in keypad facility information elements contained in one or more INFORMATION messages. In addition, if the information requested was a called party number, then the user may also send the requested information in the called party number information element in one or more INFORMATION messages. .PP In both the call associated and non\(hycall associated cases, when the network has determined that sufficient information has been received to proceed, it may send an INFORMATION message to the user, containing an .PP Information request information element, with the information request indicator set to \*Uinformation request completed\*U to signal the required information has been received correctly. If the additional information was requested during Overlap Sending state, and no additional information is required before the network can proceed with processing of the call, a CALL PROCEEDING message may suffice to signal the end of information sending. .PP In the call associated case, the network may also indicate that sufficient information has been received by initiating call clearing according to \(sc\ 5.3 of Recommendation\ Q.931. .RT .sp 1P .LP B.2.2 \fIAbnormal procedures\fR .sp 9p .RT .PP If no response is received from the user, or if the information received is incomplete upon expiry of timer T302, or if the information provided by the user is invalid, then: .RT .LP \(em in the call associated case, the network shall initiate call clearing according to \(sc\ 5.3 of Recommendation\ Q.931; .LP \(em in the non\(hycall associated case, the network shall return an INFORMATION message containing a Cause information element with an appropriate cause value. .PP In the non\(hycall associated case, if the user responds with a RELEASE COMPLETE message to an INFORMATION message containing an Information request information element, then the procedure shall be considered as terminated. \v'6p' .ce 1000 APPENDIX\ I .ce 0 .ce 1000 (to Recommendation Q.932) .sp 9p .RT .ce 0 .ce 1000 \fBIllustration of the application of the three protocol types\fR .sp 1P .RT .ce 0 .LP I.1 \fIIntroduction\fR .sp 1P .RT .PP This Appendix is provided as an illustration of the application of the three protocol types defined in this Recommendation. The examples shown should not be taken as definitive examples, since the support of the Keypad and the Feature key management protocols are network dependent. .PP The signalling sequences shown are not exhaustive and are only intended to illustrate possible supplementary service control sequences. .RT .sp 1P .LP I.2 \fIExample use of the \fR \fIKeypad protocol\fR .sp 9p .RT .PP This example shows the application of the Keypad protocol using the Keypad facility and Display information elements to establish a second call while holding the first one. It should be noted that the Keypad protocol does not necessarily allow a supplementary service to be supported to the same degree of functionality as the approach based on the Functional protocol. In addition, this protocol does not impose a need for the terminal to be aware of any states other than those required for basic call control. An objective of the Keypad protocol is to provide for the support of supplementary services in circumstances where a reduced level of functionality can be tolerated. .PP The example in Figure I\(hy1/Q.932 illustrates a user feature request using the Keypad protocol. The network associates the contents of the Keypad information element with the appropriate feature. The user is shown to subsequently enter supplementary service parameters using the Keypad protocol. Feature status information may be provided by the network in the Display information element. The network completes feature processing and the user is shown to clear call reference. Alternatively, depending on the specific feature request, a CALL PROCEEDING message might be returned by the network and normal call processing procedures would continue. .bp .PP The specific example shown in Figure I\(hy2/Q.932 illustrates the support of a holdB/Fretrieve function based on the use of INFORMATION messages for the conveyance of Keypad facility or Display information elements. An enquiry call is established through the conveyance of the called party address digits via a Keypad facility information element within INFORMATION messages. These address digits are sent after putting the existing call on hold through the transfer of a facility request via a Keypad facility information element within an INFORMATION message. .RT .LP .rs .sp 41P .ad r \fBFigure I\(hy1/Q.932 [T45.932], p.\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure I\(hy2/Q.932, p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP I.3 \fIExample of use of the \fR \fIFeature key management protocol\fR .sp 9p .RT .PP This example illustrates the use of the Feature key management protocol for the invocation of a supplementary service by a user having initiated a call establishment by sending a SETUP message with incomplete (or no) address information, after having entered the overlap sending state upon receipt of the SETUP ACKNOWLEDGE message. Figure\ I\(hy3/Q.932 depicts the user providing supplementary service parameters. This is accomplished via the Keypad facility information element within INFORMATION messages after having invoked the request of a supplementary service by sending a Feature activation information element contained in an INFORMATION message to the network. The association of the feature identifier number (provided within the Feature activitation information element) with a given supplementary service has to be arranged between the user and the network at subscription time. .RT .LP .rs .sp 45P .ad r \fBFigure I\(hy3/Q.932, p.\fR .sp 1P .RT .ad b .RT .LP .bp .LP I.4 \fIExamples of use of the \fR \fIFunctional protocol\fR .sp 1P .RT .sp 2P .LP I.4.1 \fICall related supplementary service procedures\fR .sp 1P .RT .sp 1P .LP I.4.1.1 \fIInvocation with call establishment\fR .sp 9p .RT .PP The example message sequence shows the initiation of a call establishment simultaneously with a supplementary service invocation. .RT .LP .rs .sp 18P .ad r \fBFigure I\(hy4/Q.932, p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP I.4.1.2 \fIInvocation with call clearing\fR .sp 9p .RT .PP The example message sequence shows the initiation of normal call clearing simultaneously with a supplementary service invocation. .RT .LP .rs .sp 17P .ad r \fBFigure I\(hy5/Q.932, p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP I.4.1.3 \fIInvocation during the active phase of a call\fR .sp 9p .RT .PP The example message sequence shows the initiation of a supplementary service via the established signalling association CR\da\uat any time during the active phase of a call. .RT .LP .rs .sp 17P .ad r \fBFigure I\(hy6/Q.932, p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP I.4.2 \fICall independent supplementary service procedures\fR .sp 1P .RT .sp 1P .LP I.4.2.1 \fIEstablishment of a user\(hyto\(hynetwork transaction for\fR \fIsupplementary service control\fR .sp 9p .RT .LP .rs .sp 22P .ad r \fBFigure I\(hy7/Q.932, p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP I.4.2.2 \fIClearing of a user\(hyto\(hynetwork transaction for supplementary\fR \fIservice control\fR .sp 9p .RT .LP .rs .sp 20P .ad r \fBFigure I\(hy8/Q.932, p.\fR .sp 1P .RT .ad b .RT .ce \fBH.T. [T46.932]\fR .ce TABLE\ I\(hy1/Q.932 .ce \fBKey to the Figures I\(hy1/Q.932 to I\(hy8/Q.932\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(48p) | lw(120p) . \fILayer 2 frames:\fR .T& lw(48p) | lw(120p) . SABME { Set asynchronous balance mode extended } .T& lw(48p) | lw(120p) . UA { Unnumbered acknowledgement frame } .T& lw(48p) | lw(120p) . DISC Disconnect frame .T& lw(168p) . \fILayer 3 messages:\fI .T& lw(48p) | lw(120p) . INFO Information .T& lw(48p) | lw(120p) . SETUP ACK Setup acknolwledge .T& lw(48p) | lw(120p) . DISC Disconnect .T& lw(48p) | lw(120p) . REL Release .T& lw(48p) | lw(120p) . REL COMP Release complete .T& lw(168p) . { \fILayer 3 message information elements/parameters:\fR } .T& lw(48p) | lw(120p) . FAC Facility information element .T& lw(48p) | lw(120p) . F Facility identifier .T& lw(48p) | lw(120p) . Invoke Invoke operation type .T& lw(48p) | lw(120p) . RR Return result operation type .T& lw(48p) | lw(120p) . RE Return error operation type .T& lw(48p) | lw(120p) . CR a { Call reference of an active call } .T& lw(48p) | lw(120p) . CR 1 { Call reference assigned call independently } _ .TE .nr PS 9 .RT .ad r \fBTable I\(hy1/Q.932 [T46.932], p.\fR .sp 1P .RT .ad b .RT .LP .bp .ce 1000 APPENDIX\ II .ce 0 .ce 1000 (to Recommendation Q.932) .sp 9p .RT .ce 0 .ce 1000 \fBFunctional reference model for the operation\fR .sp 1P .RT .ce 0 .ce 1000 \fBof supplementary services\fR .ce 0 .PP This Appendix provides a functional model intended to show how the supplementary services can be operated by combining stimulus or Functional protocol types to interact with a unique supplementary service protocol controller which interfaces with the relevant supplementary functional components which provides and coordinates the required functions associated to each supplementary service (e.g., control of resources). .sp 1P .RT .PP The intermediate feature function performs the necessary conversions between stimulus protocols and the supplementary service functional primitives which are the only ones treated and known from the supplementary service protocol controller. As an example, the intermediate feature function translates an access code received within the Keypad facility information element or a feature identifier number within a Feature activation information element to a supplementary service priority such as hold or retrieve request. .LP .rs .sp 37P .ad r Blanc .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigura II\(hy1/Q.932, p.45\fR .sp 1P .RT .ad b .RT .LP .bp .ce 1000 APPENDIX\ III .ce 0 .ce 1000 (to Recommendation Q.932) .sp 9p .RT .ce 0 .ce 1000 \fBGeneral description of \fR \fBcomponent encoding rules\fR .sp 1P .RT .ce 0 .LP III.1 \fIGeneral component structure\fR .sp 1P .RT .PP Each data element within a component has the same structure. A data element consists of three fields, which always appear in the following order. The tag distinguishes one type from another and governs the interpretation of the contents. The length specifies the length of the contents. The contents is the substance of the data element, containing the primary information the data element is intended to convey. Figure\ III\(hy1/Q.932 shows an overview of a component and a data element. .RT .LP .rs .sp 12P .ad r \fBFigure III\(hy1/Q.932, p.\fR .sp 1P .RT .ad b .RT .PP \fR Each field is coded using one or more octets. Octets are labelled as shown in Figure\ III\(hy2/Q.932. The first octet is the first transmitted. Bits in an octet are labelled as shown in Figure\ III\(hy3/Q.932, with bit 1 the least significant and the first transmitted. .LP .rs .sp 13P .ad r \fBFigure III\(hy2/Q.932, p.\fR .sp 1P .RT .ad b .RT .LP .rs .sp 8P .ad r \fBFigure III\(hy3/Q.932, p.\fR .sp 1P .RT .ad b .RT .LP .bp .PP The contents of each data element is either one value (primitive) or one or more data elements (constructor), as shown in Figure\ III\(hy4/Q.932. .LP .rs .sp 11P .ad r \fBFigure III\(hy4/Q.932, p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP III.2 \fITag\fR .sp 9p .RT .PP A data element is first interpreted according to its position within the syntax of the message. The tag distinguishes one data element from another and governs the interpretation of the contents. It is one or more octets in length. The tag is composed of \*Qclass\*U, \*Qform\*U and \*Qtag code\*U, as shown in Figure\ III\(hy5/Q.932. .RT .LP .rs .sp 11P .ad r \fBFigure III\(hy5/Q.932 [T47.932], p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP III.2.1\ \ \fITag class\fR .sp 9p .RT .PP All tags use the two most significant bits (8 and 7) to indicate the tag class. These bits are coded as shown in Table\ III\(hy1/Q.932. .RT .ce \fBH.T. [T48.932]\fR .ce TABLE\ III\(hy1/Q.932 .ce \fBCoding of tag class\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(72p) | cw(42p) . Class Coding (87) _ .T& lw(72p) | cw(42p) . Universal 00 .T& lw(72p) | cw(42p) . Application\(hywide 01 .T& lw(72p) | cw(42p) . Context\(hyspecific 10 .T& lw(72p) | cw(42p) . Private use 11 _ .TE .nr PS 9 .RT .ad r \fBTable III\(hy1/Q.932 [T48.932], p.\fR .sp 1P .RT .ad b .RT .LP .bp .PP The universal class is used for tags that are exclusively standardized in Recommendation\ X.209 and are application independent types. Universal tags may be used anywhere a universal data element type is used. The universal class applies across all CCITT Recommendations, i.e., across Recommendation\ Q.932 facility information elements, CCITT Signalling System\ No.\ 7 ASEs, X.400 MHS, X.500 Directory Services,\ etc. .PP The application\(hywide class is used for data elements that are standardized across all applications (ASEs) using CCITT Recommendation\ Q.932 facility procedures for supplementary services. .PP The context\(hyspecific class is used for data elements that are specified within the context of the next higher construction and take into account the sequence of other data elements within the same construction. This class may be used for tags in a construction, and the tags may be re\(hyused in any other construction. .PP The private use class is reserved for data elements specific to a nation, a network or a private user. Such data elements are beyond the scope of Recommendation\ Q.932. .PP The Tag codes of the application\(hywide class not assigned in Recommendation\ Q.932 are reserved for future use. .RT .sp 1P .LP III.2.2\ \ \fIForm of the data element\fR .sp 9p .RT .PP Bit 6 is used to indicate whether the data element is \*Qprimitive\*U or \*Uconstructor\*U, as shown in Table\ III\(hy2/Q.932. A primitive element is one whose structure is atomic (i.e.,\ one value only). A constructor element is one whose content is one or more data elements which may themselves be constructor elements. .PP Both forms of elements are shown in Figure III\(hy4/Q.932. .RT .LP .sp 1 .ce \fBH.T. [T49.932]\fR .ce TABLE\ III\(hy2/Q.932 .ce \fBCoding of element form\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(60p) | cw(42p) . Element form Coding (6) _ .T& lw(60p) | cw(42p) . Primitive 0 .T& lw(60p) | cw(42p) . Constructor 1 _ .TE .nr PS 9 .RT .ad r \fBTable III\(hy2/Q.932 [T49.932], p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP .sp 5 III.2.3\ \ \fITag code\fR .sp 9p .RT .PP Bits 1 to 5 of the first octet of the tag plus any extension octets represent a tag code that distinguishes one element type from another of the same class. Tag codes in the range 00000 to 11110 (0 to 30\ decimal) are provided in one octet. .PP The extension mechanism is to code bits 1 to 5 of the first octet as 11111. Bit\ 8 of the following octet serves as an extension indication. If bit\ 8 of the extension octet is set to 0, then no further octets for this tag are used. If bit\ 8 is set to 1, the following octet is also used for extension of the tag code. The resultant tag consists of bits\ 1 to 7 of each extension octet with bit\ 7 of the first extension octet being most significant and bit\ 1 of the last extension octet being least significant. Tag code\ 31 is encoded as 0011111 in bits\ 7 to 1 of a single extension octet. Higher tag codes continue from this point using the minimum possible number of extension octets. .bp .PP Figure III\(hy6/Q.932 shows the detailed format of the tag code. .RT .LP .rs .sp 16P .ad r \fBFigure III\(hy6/Q.932 [T50.932], p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP III.3 \fILength of the contents\fR .sp 9p .RT .PP The length of the contents is coded to indicate the number of octets in the contents. The length does not include the tag nor the length of the contents octets. .PP The length of the contents uses the short, long or indefinite form. If the length is less than 128\ octets, the short form is used. In the short form, bit\ 8 is coded\ 0, and the length is encoded as a binary number using bits\ 1 to 7. .PP If the length of the contents is greater than 127 octets, then the long form of the length of the contents is used. The long form length is from 2 to 127\ octets long. Bit\ 8 of the first octet is coded\ 1, and bits\ 1 to 7 of the first octet encode a number one less than the size of the length in octets as an unsigned binary number whose MSB and LSB are bits\ 7 and 1, respectively. The length itself is encoded as an unsigned binary number whose MSB and LSB are bit\ 8 of the second octet and bit\ 1 of the last octet, respectively. This binary number should be encoded in the fewest possible octets, with no leading octets having the value\ 0. .PP The indefinite form is one octet long and may (but need not) be used in place of the short or long form, whenever the element is a constructor. It has the value\ 10000000. When this form is employed, a special end\(hyof\(hycontents (EOC) indicator terminates the contents. .PP There is no notation for the end\(hyof\(hycontents indicator. Although considered part of the contents syntactically, the end\(hyof\(hycontents indicator has no semantic significance. .PP The representation for the end\(hyof\(hycontents indicator is an element whose class is universal, whose form is primitive, whose identifier code has the value\ 0, and whose contents is unused and absent (see Table\ III\(hy3/Q.932). .RT .ce \fBH.T. [T51.932]\fR .ce TABLE\ III\(hy3/Q.932 .ce \fBRepresentation for the end\(hyof\(hycontents indicator\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(30p) | lw(30p) | lw(30p) . EOC 00 (hex) Length 00 (hex) Contents Absent _ .TE .nr PS 9 .RT .ad r \fBTable III\(hy3/Q.932 [T51.932], p.\fR .sp 1P .RT .ad b .RT .LP .bp .PP Figure III\(hy7/Q.932 shows the formats of the length field described above. The maximum value that may be encoded is constrained by Q.931 information element size limitations. .LP .rs .sp 37P .ad r \fBFigure III\(hy7/Q.932 [T52.932], p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP .sp 3 III.4 \fIContents\fR .sp 9p .RT .PP The contents is the substance of the data element and contains the information the data element is intended to convey. Its length is variable, but always an integral number of octets. The contents is interpreted in a type\(hydependent manner, i.e.,\ according to the tag value. .bp .RT .sp 1P .ce 1000 \fBAcronyms\ used\ in\ Recommendation\ Q.932\fR .ce 0 .sp 1P .sp 2P .LP \s8English French Spanish Meaning .sp 1P .RT .sp 1P .LP \s9APDU APDU UDPA Application Protocol Data Unit .sp 9p .RT .LP ASN.1 ASN.1 NSA.1 Abstract Syntax Notation One (see Recommendations\ X.208/X.209) .LP CEI CEI IEC Connection Endpoint Identifier (see Recommendation Q.920) .LP CES CES SEC Connection Endpoint Suffix (see Recommendation Q.920) .LP IA5 IA5 AI5 International Alphabet No. 5 .LP ISDN RNIS RDSI Integrated Services Digital Network .LP LSB LSB BMenosS Least Significant Bit .LP MSB MSB BM\*'asS Most Significant Bit .LP NT2 NT2 TR2 Network Termination Type Two (see Recommendation\ I.411) .LP ROSE ROSE ESOR Remote Operations Service Element (see Recommendations\ X.219/X.229) .LP SAPI SAPI IPAS Service Access Point Identifier (see Recommendation\ Q.920) .LP SPID SPID IDPS Service Profile Identifier .LP TEI TEI IET Terminal Endpoint Identifier (see Recommendation Q.920) .LP TID TID IDT Terminal Identifier .LP USID USID IDSU User Service Identifier .sp 2P .LP \fBReferences\fR .sp 1P .RT .LP [1] CCITT Recommendation \fIBasic user\(hynetwork interface \(em Layer 1\fR \fIspecification\fR , Vol.\ III, Rec.\ I.430. .LP [2] CCITT Recommendation \fIPrimary rate user\(hynetwork interface \(em Layer 1\fR \fIspecification\fR , Vol.\ III, Rec.\ I.431. .LP [3] CCITT Recommendation \fIISDN user\(hynetwork interface \(em Data link\fR \fIlayer specification\fR , Vol.\ VI, Rec.\ Q.921. .LP [4] CCITT Recommendation \fIISDN user\(hynetwork interface layer 3\fR \fIspecification for basic call control\fR , Vol.\ VI, Rec.\ Q.931. .LP [5] CCITT Recommendation \fIISDN user\(hynetwork interface layer 3 \(em General\fR \fIaspects\fR , Vol.\ VI, Rec.\ Q.930. .LP [6] CCITT Recommendation \fIISDN user\(hynetwork interface data link\fR \fIlayer \(em General aspects\fR , Vol.\ VI, Rec.\ Q.920. .LP [7] CCITT Recommendation \fISpecification of abstract syntax notation\fR \fIspecification of abstract syntax notation one (ASN.1)\fR , Vol.\ VIII, Rec.\ X.208. .LP [8] CCITT Recommendation \fISpecification of basic encoding rules for\fR \fIabstract syntax notation one (ASN.1)\fR , Vol.\ VIII, Rec.\ X.209. .LP [9] CCITT Recommendation \fIRemote operations: model, notation and\fR \fIservice definition\fR , Vol.\ VIII, Rec.\ X.219. .LP [10] CCITT Recommendation \fIRemote operations: protocol specification\fR , Vol.\ VIII, Rec.\ X.229. .bp .LP \fBMONTAGE: PAGE 424 = PAGE BLANCHE\fR .sp 1P .RT .LP .bp .sp 1P .ce 1000 \v'3P' SECTION 2 .ce 0 .sp 1P .ce 1000 \fBUSER\(hyNETWORK MANAGEMENT\fR .ce 0 .sp 1P .sp 2P .LP \fBRecommendation\ Q.940\fR .RT .sp 2P .ce 1000 \fBISDN USER\(hyNETWORK INTERFACE PROTOCOL\fR .EF '% Fascicle\ VI.11\ \(em\ Rec.\ Q.940'' .OF '''Fascicle\ VI.11\ \(em\ Rec.\ Q.940 %' .ce 0 .sp 1P .ce 1000 \fBFOR MANAGEMENT \(em GENERAL ASPECTS\fR .ce 0 .sp 1P .LP \fB1\fR \fBGeneral\fR .sp 1P .RT .PP This Recommendation is one of a proposed series of Recommendations describing the management model, service elements and protocol to be provided at the ISDN user\(hynetwork interface. These Recommendations also specify the management functions required to support the ISDN subscriber installation. This Recommendation describes the Management Architecture and provides a general overview of the management services and functions. .PP Other Recommendations in this series will specify the System Management Service Elements and Protocol and the procedures associated with management functions. .PP The management functions provided at the user\(hynetwork interface have, as an objective, full alignment with the network management functions being addressed by the Telecommunications Management Network (TMN) and the Management Framework for Open System Interconnection (OSI). While the TMN defines management functions from a network perspective, this Recommendation describes the management functions from the subscriber perspective and provides for remote user management functions. .RT .sp 1P .LP 1.1 \fIScope\fR .sp 9p .RT .PP This series of Recommendations will provide for a common approach for management communications to support procedures used by a remote maintenance centre, internal or external to the network and those initiated locally. .PP These Recommendations deal with the specification of the following items: .RT .LP a) the specification of a Management Architecture and identification of communications paths; .LP b) the specification of management functionality to be provided at the ISDN user\(hynetwork interface; .LP c) the specification of an information exchange protocol for the exchange of management information between two peer system management application entities (SMAE); .LP d) the specification of primitives between the Management Application process (user) and the SMAE (i.e., the primitives at the systems management service interface (SMSI)); .LP e) the specification of service primitives between the SMAE service element and the next lower layer service elements (i.e., primitives at the presentation layer service access point (PSAP)); .LP f) the specification of a convergence function that may be required to permit the direct access of the SMAE service elements to services provided by layer 3 (i.e., the primitives at the network layer service access point (NSAP)). .sp 1P .LP 1.2 \fIField of application\fR .sp 9p .RT .PP The protocols and procedures described in these Recommendations provide the means to support management functions at the ISDN user\(hynetwork interface. Management activities that manage network services, operations such as network resource configuration, routing .bp .PP information and maintenance activities shall be supported by the functions and protocols defined in these Recommendations. In particular these management functions should be able to support specific requirements such as those defined in the I.60\(hySeries of Recommendations (Subscriber Access and Installation Maintenance). These protocols make it possible to control loopbacks and diagnostic tests, initiate and terminate event reporting and to exchange management information across the ISDN user\(hynetwork interface, i.e., between equipment connected to the SB/FT reference points. .PP The physical layer signals in the digital transmission section which are used to control maintenance functions are outside the scope of this Recommendation. .PP The protocols can be used on the D Channel of both the basic and primary rate interface structures and across both reference points S and T. The higher layer protocols can also be used on other ISDN channels and services. .PP The protocols and procedures described in these Recommendations take into account that interactions with the TMN will occur. It is, therefore, desirable that the services and protocols to be used to support access management are aligned, wherever possible, with those to be defined for the TMN and OSI management. .RT .sp 2P .LP \fB2\fR \fBCategories of management information exchange\fR .sp 1P .RT .PP Management information exchanges may be categorized into the following three categories: .RT .LP a) Event notification: information transfer initiated by one system reporting instantaneously the occurrence of an event (e.g., a fault occurrence) to another system. .LP b) Data transfer: information exchange initiated by one system in order to get management\(hyrelated information from another system. These exchanges follow the \*Qrequest followed by response\*U paradigm. .LP c) Control information: information exchanges which are of an executive nature, where one system requests that an action be performed by another system (e.g., for test access and downloading of parameters). .sp 2P .LP \fB3\fR \fBManagement functions\fR .sp 1P .RT .PP Management functions may be classified in accordance with fields of application. The following major functions have been identified: .RT .LP a) Fault management .LP \(em Maintenance functions .LP \(em Fault tracing .LP \(em Spontaneous error reporting .LP \(em Error threshold alarm reporting .LP \(em Continuous monitoring .LP \(em Diagnostic testing .LP \(em Resource (re)initialization .LP \(em Confidence testing .LP \(em Resource identification .LP \(em Trouble isolation. .LP b) Configuration management .LP \(em Routing changes .LP \(em Data base changes .LP \(em Equipment identification .LP \(em Network/equipment reconfiguration. .LP c) Accounting management .LP \(em Reporting of billing data. .LP d) Performance management .LP \(em Collecting and reporting of traffic data .LP \(em Performance monitoring .LP \(em Applying controls. .LP e) Security management. .bp .sp 2P .LP \fB4\fR \fBManagement reference models\fR .sp 1P .RT .sp 1P .LP 4.1 \fICommunications path model\fR .sp 9p .RT .PP Figure 1/Q.940 shows the entities which may contain System Management Entities (SME) which may require capability to communicate. System Management Entities may be located in the local exchanges, subscriber installations, remote management centres or network management centres. .PP The management functions supported by the various systems may differ depending on system requirements and may vary between different networks. However, the communications facilities provided by the systems management entities should be as common as possible. .PP The scope of this Recommendation covers those functions and protocols that have immediate impact on the user\(hynetwork interface. .PP The system management entities may be in a TE, NT2 or management service provider. Although communication between any two management entities may be possible in the model, it does not imply that information held at a particular management entity is available to all other management entities. Security mechanisms may be used to restrict access to the information. .RT .LP .rs .sp 38P .ad r \fBFigure 1/Q.940, p. \fR .sp 1P .RT .ad b .RT .LP .bp .PP Figure 1/Q.940 shows that three types of management communications can be accommodated: .LP a) TE (or Remote Management Centre) < > TE (1< >2); .LP b) TE < > Network Management Function (1< >3); .LP c) TE < > Network Management Function < > TE (1 < > 3 < >2); .PP Types a) and b) are direct peer communication. In type c), the TE requests the Network Management Entity to act as an agent which then, on behalf of the requesting TE, communicates with another TE. .sp 1P .LP 4.1.1 \fISecure access to management and maintenance functions\fR .sp 9p .RT .PP To facilitate maintenance procedures and fault sectionalization, maintenance entities located in different management domains may communicate. However, since management and maintenance information is of critical importance to system integrity, access to management functions and information is subject to prior authorization and security restrictions upon access. .PP The security restrictions are normally enforced by the recipient of the management information but may be enforced by the originator independently of any security imposed by the recipient. The security measures may include requirements for peer\(hyentity authentication. .PP The use of adequate security mechanisms is especially important in the case of a network since many users may be affected by unauthorized access. .PP Whenever system management communication crosses an S or T reference point, the requirement for access authorization must be presumed. .PP \fINote\fR \ \(em\ This does not preclude implicit actions on layer management parameters as specified within the relevant signalling protocols, e.g., Recommendations\ Q.921 and Q.931. These actions are, however, beyond the scope of this Recommendation. .RT .sp 1P .LP 4.2 \fISystem management entity\fR .sp 9p .RT .PP Figure 2B/FQ.940 shows the internal structure of the SME. .RT .sp 1P .LP 4.2.1 \fISystem management application entity (SMAE)\fR .sp 9p .RT .PP The SMAE is an application layer entity that supports system management functions. The SMAE is responsible for communication with peer systems. .PP The function of the SMAE is to provide the communications necessary to make a system management accessible to another SMAP. It is not necessary for the SMAE to be provided if only local system management is required. .RT .sp 1P .LP 4.2.2 \fBsystem management application process (SMAP)\fR .sp 9p .RT .PP An SMAP is an application process of a system performing management functions. The SMAP controls the SMAE, and includes the Management Information Base (MIB) and may include one or more managers providing various functionalities. .RT .sp 1P .LP 4.2.3 \fBmanagement information base (MIB)\fR .sp 9p .RT .PP The MIB is the repository of all information relevant to the operation of a system. Both the SMAP and Layer Management Entities (LME) have access to the MIB. .RT .sp 1P .LP 4.2.4 \fBlayer management entity (LME)\fR .sp 9p .RT .PP The LME is that part of a Layer Entity which manages resources and parameters residing in its layer protocol entity. .RT .sp 1P .LP 4.2.5 \fBprotocol entity (PE)\fR .sp 9p .RT .PP The PE is that part of a layer entity which is dedicated to peer\(hyto\(hypeer communications. A layer PE provides services to the next upper layer and uses services of the next lower layer. .bp .RT .LP .rs .sp 43P .ad r \fBFigura 2/Q.940, p.\fR .sp 1P .RT .ad b .RT .PP It should be noted that this model presently permits communication between peer management processes either by attaching to a Presentation Layer Access Point (PSAP) or by attaching directly to the Network Layer Service Access Point (NSAP). A convergence function may be provided as an alternative to the full seven layer OSI Reference Model (as specified in Recommendation X.200) to accommodate simple terminals that may be used in the ISDN environment. If provided, the functions will be kept to a minimum, i.e., the OSI layer services lost by elimination of layers 4\(hy6 will not be recovered by the convergence function. Therefore, the use of all seven layers is to be preferred. This has the consequence that \*Qconvergence functions\*U may need to be specified. .bp .RT .sp 1P .LP 4.2.6 \fIManagement information protocol (MIP)\fR .sp 9p .RT .PP The Management Information Protocol provides the support for information exchange between peer SMAEs. .RT .sp 2P .LP 4.3 \fIManaged objects: a hierarchical object model\fR .sp 1P .RT .sp 1P .LP 4.3.1 \fIDefinitions\fR .sp 9p .RT .sp 1P .LP 4.3.1.1 \fBmanaged object\fR .sp 9p .RT .PP A managed object is a collection of data objects and telecommunications or information processing resources that may be managed by means of the management protocol specified in this Recommendation. .RT .PP 4.3.1.2 A \fBdata object\fR is an object that is the direct recipient of an action or generator of an event report. .sp 9p .RT .sp 1P .LP 4.3.2 \fIHierarchical object model\fR .sp 9p .RT .PP The maintenance functions are described as asymmetric functions using symmetrical communications paths. A maintenance activity is always started by an Invoker who is asking an Executor to manipulate event reports or data objects. These can be classified as belonging to individual managed objects. Each elementary operation that will have to access or refer to data objects will identify these by specifying first the managed object to which they belong and then identifying them within the managed object. .PP A hierarchical object model is defined that allows access to any individual data object in a simple way. When a given managed object may be duplicated, an instance identifier will help to resolve the ambiguity. .PP As an example, the model for user\(hynetwork ISDN access interface is represented by the hierarchical tree of Figure 3/Q.940. .RT .LP .rs .sp 15P .ad r \fBFigure 3/Q.940, p. \fR .sp 1P .RT .ad b .RT .PP The parameters and event reports pertaining to a particular managed object can then be defined implicitly within the managed object. Some managed objects may be empty when no data object is identified within them. In this case they are only present as an indication of a hierarchical level. .PP It has to be noted that the ISDN user\(hynetwork access interface model only contains managed objects that belong to the network access functions,\ i.e., that are involved in the provision of the required bearer service (signalling and lower layer protocols on the bearer channels). The protocols that are not involved in the provision of the bearer service are excluded from this model as they belong to the application part. .PP \fINote\fR \ \(em\ The identity of an object at the executing end may not be known to the Invoker when it requests a maintenance action at the remote end of a connection. In this case the Executor will be able to identify the object by the context of the connection path used to convey the maintenance request. .bp .PP As an example, remote maintenance may be required on an existing B\ Channel connection. The channel identity is only locally significant at each end. The maintenance request must be transmitted over the signalling connection that is used to control the B Channel associated with the existing call. The identity of the B Channel will be implied by the signalling connection used to convey the maintenance request. .RT .sp 2P .LP \fB5\fR \fBManagement structure and activities\fR .sp 1P .RT .PP This section considers the specific structure and activities of management in terms of system management, layer management and protocol processing for management purposes. .RT .sp 1P .LP 5.1 \fISystem management\fR .sp 9p .RT .PP This section introduces the concept of system management, its boundaries and other structures and activities related to management. .RT .sp 1P .LP 5.1.1 \fIIntroduction\fR .sp 9p .RT .PP The scope of system management is described in terms of the bounds of the SMAP. The boundaries show where the SMAP ends and other objects (either inside or outside the system) begin. The boundaries provide a sense of the relationship of the SMAP to other objects and therefore a sense of the SMAP scope. .RT .sp 1P .LP 5.1.2 \fISystem management boundaries\fR .sp 9p .RT .PP The boundaries of the SMAP are shown in Figure 4/Q.940. .RT .LP .rs .sp 30P .ad r \fBFigure 4/Q.940, p. \fR .sp 1P .RT .ad b .RT .LP .bp .PP This Figure shows the relationship between the SMAP and two other major components. The Communications component contains the seven layers of the reference model. The people and software component contains the peopleB/Fsoftware in the local environment that use the local systems manager. .PP The SMAE is the system management application entity, and (N)\(hyLME represents the layer managers in the system. .RT .sp 1P .LP 5.1.2.1 \fILocal interface\fR .sp 9p .RT .PP The local interface is located between the SMAP and the people and software that request services from the SMAP. Service requestB/Fresponses pass through this boundary to invoke one or more system management functions. Local interfaces, when present, are beyond the scope of this Recommendation. .RT .sp 1P .LP 5.1.2.2 \fILayer management service interface (LMSI)\fR .sp 9p .RT .PP The Layer Management Service Interface is the boundary between the SMAP and the individual layer management [(N)\(hyLMEs]. Data and control information pass through this boundary. The boundary provides a way for each layer manager to gain access to parameters within the scope of that layer. This service interface is not subject to standardization. .RT .sp 1P .LP 5.1.2.2.1 \fIFrom system management to layer management\fR .sp 9p .RT .PP The boundary between system management and (N)\(hylayer management supports the flow from system management to layer management of: .RT .LP 1) requests to read, set, and perform actions with respect to various values, counters, statuses, etc., within a given layer; .LP 2) response to inquiries made by an (N)\(hylayer management entity upon the system management function; .LP 3) data from the (N)\(hylayer management of other systems. .sp 1P .LP 5.1.2.2.2 \fIFrom layer management to system management\fR .sp 9p .RT .PP The boundaries between system management and (N)\(hylayer management supports the flow from (N)\(hylayer management to system management of: .RT .LP 1) responses to read, set and request for action that came from system management; .LP 2) request to send data to (N)\(hylayer management in another system; .LP 3) requests to place data into the Management Information Base; .LP 4) requests to obtain information from the Management Information Base. .sp 1P .LP 5.1.2.3 \fBsystem management service interface (SMSI)\fR .sp 9p .RT .PP The System Management Service Interface is the boundary between the SMAP and the SMAE. The SMAE is a type of application entity which communicates system management messages to its peer SMAE in another system. Data and control information to and from the SMAE pass through this boundary. A service definition defines this boundary, and this service boundary defines system management. .RT .sp 1P .LP 5.1.3 \fISystem management functions\fR .sp 9p .RT .PP The responsibilities of system management are considered from two points of view: .RT .LP a) Local system responsibilities (included for completeness of description): .LP \(em to initiate the (N)\(hylayer manager for each layer, upon system activation; .LP \(em to serve as the manager of information that is common to several layers or that is supplied externally. .LP b) Communications responsibilities: .LP \(em to provide support for the exchange of information between the (N)\(hyLMEs of a single layer so that the (N)\(hyLMEs do not need to provide separate protocols for such exchanges; .LP \(em to coordinate the activities of the various SMAPs within telecommunication networks and subscriber installations. .bp .sp 1P .LP 5.1.4 \fIRelationship to (N)\(hylayer management\fR .sp 9p .RT .PP System management provides the only vehicle for the exchange of information between layers. Direct communication of management information between layers is deliberately precluded in the reference model to prevent inter\(hylayer dependencies from occurring. .PP Since inter\(hylayer exchanges of information will have to occur (i.e., error statistics), system management has been designated as the vehicle through which this exchange will occur. Each layer will have defined sets of information it may make known or will need to acquire. .PP System management implements the means of acquiring and disseminating this information. This may require activities on the part of system management that span several systems. .PP System management maintains the MIB and provides the support of (N)\(hyLME access to the MIB. .RT .sp 1P .LP 5.1.5 \fIRelationship to the Management Information Base\fR .sp 9p .RT .PP The SMAP is responsible for the MIB and provides authorized access to the MIB across the system boundaries. .RT .sp 1P .LP 5.2 \fILayer management\fR .sp 9p .RT .PP This section introduces the concept of layer management and its relationships to other entities. .RT .sp 1P .LP 5.2.1 \fIScope\fR .sp 9p .RT .PP In keeping with the general principle that each layer is independent of all others, each layer has its own management functions. These layer management functions are described in this Recommendation as the (N)\(hyLME. .PP The role of the (N)\(hyLME is threefold. Firstly, it serves to coordinate the activities of the (N)\(hyentities within the layer. Secondly, it serves as the \*Uwindow\*U to system management for the entities within the layer. Thirdly, in conjunction with both system management and its peer LMEs it manages the layer. .PP The (N)\(hyLMEs are restricted to activities within an (N)\(hylayer. The (N)\(hyLME must not interact directly with a layer manager of any other layer. .RT .sp 1P .LP 5.2.2 \fIRelationship to (N)\(hyentities which operate protocols\fR .sp 9p .RT .PP The (N)\(hyLME is charged with coordinating the activities and relationships of various (N)\(hyentities which operate the protocols within the layer. .PP The (N)\(hyLME is responsible for accessing the MIB on behalf of the (N)\(hyentities. It will access the MIB to retrieve external parameters that the (N)\(hyentity will need to operate, and to store and retrieve operating data that is in external storage contained within the scope of the peer management entity. The (N)\(hyLME is also the focus for control of the (N)\(hyentities by system management. .RT .sp 1P .LP 5.2.3 \fIRelationship between peer (N)\(hyLMEs\fR .sp 9p .RT .PP The (N)\(hyLMEs will frequently need to exchange information. This exchange ordinarily will be accomplished through the peer SMAPs. However, in some cases, layer management protocols are necessary. These cases are limited to the following: .RT .LP 1) where the exchange of information, or the circumstances under which such information might be exchanged would necessarily interfere with the support of the SMAE by the lower layers: for example, loop testing at layer 1 might be supported by a layer 1 management protocol, and exchange of routing information might be supported by a layer 3 management protocol; .LP 2) where layer management protocols already exist; for example, see Recommendation Q.921. .PP In no event may a layer management protocol interact directly with any other layer. System management provides the only means for data transfer. .sp 1P .LP 5.2.4 \fIRelationship to system management\fR .sp 9p .RT .PP The (N)\(hyLMEs rely upon services from system management for three purposes. These are to provide communication for intra\(hylayer management activities, to coordinate inter\(hylayer management activities and to serve as a general repository for management information. .PP As system management is the supervisor for any action on layer management, the service requestB/Fresponse for external action (e.g., parameter manipulation, statistic gathering, etc.,) will use the SMAP as defined in \(sc\ 6.1. .bp .RT .sp 2P .LP 5.3 \fIProtocol processing for management purposes\fR .sp 1P .RT .sp 1P .LP 5.3.1 \fIScope\fR .sp 9p .RT .PP On occasion, the (N)\(hyentities do participate in the management process. This occurs when the protocol has embedded within itself information that must be made known to other entities and when events occur that must be made known to other entities. .RT .sp 1P .LP 5.3.2 \fIRelationship of (N)\(hyentities to (N)\(hyLMEs\fR .sp 9p .RT .PP The (N)\(hyentities rely upon the (N)\(hyLME to provide coordination between the various (N)\(hyentities in the (N)\(hylayer, and access to data and services that come from outside the (N)\(hylayer. There is, therefore, a flow of control information between the (N)\(hyentities and the (N)\(hyLME. .PP Since the (N)\(hyentities exist independently of the other (N)\(hyentities within the (N)\(hylayer, they are dependent upon the (N)\(hyLME to coordinate activities between the various (N)\(hyentities within the sub\(hysystem. As an example the (N)\(hyentities rely upon the (N)\(hyLME to determine when requests for connection are being made to establish the association between the connection request at a connection endpoint and the (N)\(hyentity. The (N)\(hyLME also controls the instantiation of (N)\(hyentities at the time of connection requests. .RT .sp 2P .LP \fB6\fR \fBOverview of services required by the SMAP\fR .sp 1P .RT .sp 1P .LP 6.1 \fIHigh layer context management\fR .sp 9p .RT .PP When the two SMAPs are involved in a management dialogue, they may want to establish a context that will be maintained during the life of the dialogue. In this sense two SMAPs typically work in a connection\(hyoriented mode. The SMAE will provide services that will allow it to work in connection\(hyoriented mode by providing the capability to establish and release associations between peer applications. .PP These services are to be described further in future Recommendations. .PP The use of a connectionless service is for further study. .RT .sp 1P .LP 6.2 \fIDefinition of a set of generic functions\fR .sp 9p .RT .PP As presented in \(sc 5, management covers a large spectrum of applications. These applications may be implemented by dedicated SMAPs that can make use of a reduced set of generic functions. The generic functions are listed hereafter with examples for their use: .RT .LP \(em Trigger an action (e.g., activate or deactivate loopbacks or internal tests); .LP \(em Event report (e.g., error reporting, alarm reporting); .LP \(em Get attributes (e.g., cumulative error counters, get parameter values); .LP \(em Set attributes (e.g., set or modify parameters, thresholds, etc.); .LP \(em Create and delete managed objects (e.g., create a routing table). .PP The SMAE provides facilities to allow the generic functions to be communicated between SMAPs. .sp 2P .LP \fB7\fR \fBAddressing for information exchange\fR .sp 1P .RT .PP The information flow takes place between two SMAPs and the originator must be able to address the destination SMAP. .PP Depending upon the location of the communicating SMAPs different addressing schemes may apply: .RT .LP 1) Explicit Addressing. In this case the remote entity is explicitly addressed by its ISDN address. .LP 2) Implicit Addressing. Implicit addressing relies on mechanisms other than an explicit address in the maintenance message to identify the recipient of the information. .PP For system management two cases of implicit addressing may be identified: .LP a) permanent connections; .LP b) hot line service. .bp .sp 2P .LP \fB8\fR \fBTerminal selection\fR .sp 1P .RT .PP In addition to the normal ISDN addressing mechanisms the maintenance procedures which require actions to perform to particular user equipment require the existence of an identification method that allows access to the unique piece of user equipment to be maintained. .PP Selection of a unique terminal is based on compatibility checking of various parameters. Compatibility is determined first on the basis of the ISDN address and then on the basis of service information (bearer capability, high layer compatibility, etc.). The service information alone is adequate to provide unique identification if a single unit of equipment satisfies this requirement. .PP When several TEs connected to the same access, sharing one ISDN address, provide the same functionality, and neither the NSAP nor service information are sufficient, then a unique equipment identifier must be used. .RT .sp 2P .LP \fB9\fR \fBAccess control\fR .sp 1P .RT .PP In many cases information accessible through the management function may be private or a management action may result in taking the equipment out of service. Access security to management and maintenance functions must, therefore, be provided. .PP Access controls may be applied both to the call establishment phase of the maintenance call and also within individual maintenance transactions. .PP The use of Calling Line Identity provides one method by which maintenance calls can be screened. Further access right discrimination can be performed on the basis of message type in which the management information is carried. Each message type may have its own implied access rights. .PP Additionally, specific access control can be performed on the basis of an explicit access control parameter. This parameter has the following characteristics: .RT .LP 1) access control mechanisms are defined as parameters of the primitives passed between system management and the service provider; .LP 2) use of access control parameters is optional; .LP 3) in addition to meeting compatibility requirements, management calls must also satisfy the access control requirements; .LP 4) access control information may be encrypted. .LP .rs .sp 24P .ad r Blanc .ad b .RT .LP .bp .LP \fBMONTAGE: PAGE 436 = PAGE BLANCHE\fR .sp 1P .RT .LP .bp