InfoMagic Standards 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1993 July / Disc.iso / ccitt / 1992 / q / q931g.asc < prev next >

Wrap

Text File | 1991-12-31 | 19.4 KB | 1,165 lines

G.7 Interworking class G.7.1 Cause No. 127 "interworking unspecified" This cause indicates that there has been interworking with a network which does not provide causes for actions it takes, thus, the precise cause for a message which is being sent cannot be ascertained. Annex H (to Recommendation Q.931) Examples of information elements coding This annex gives examples on the detailed coding of the following information elements: - bearer capability information element; - channel identification information element; - called/calling party sub-address. H.1 Bearer capability information element H.1.1 Coding for speech H.1.2 Coding for 3.1 kHz audio H.1.3 Coding for unrestricted digital information Type 1: Synchronous 64 kbit/s working Type 2: Synchronous rates less than 64 kbit/s with CCITT standardized rate adaption V.110/X.30; in-band negotiation not possible. H.1.4 Coding for X.25 packet mode access connections Case (b) H.2 Channel identification information element H.2.1 Basic interface, circuit mode, B channel Example (a) - Channel B1 preferred. - Channel is located in same interface which includes the D channel. Example (b) - Any B channel. H.2.2 Primary rate interface, circuit mode, B channel Case (a) Case (b) Example (c) H.3 Called/calling party sub-address information element H.3.1 Coding of IA5 sub-address digits Note 1 - AFI code 50 (in BCD) indicates that the sub-address consists of IA5 characters (see ISO standard 8348 AD2). Note 2 - IA5 character according to CCITT Recommendation T.50/ISO 646. Note 3 - The number of IA5 characters shown above is just an example. There may be up to 19 IA5 characters. Note 4 - The value of this bit has no significance when the type of sub-address is "NSAP". Annex I (to Recommendation Q.931) Use of progress indicators This annex describes the use of the different progress indicator values defined in 4.5.22. Examples of use are given. Progress indicator No. 1 indicates that interworking with a non-ISDN has occurred within the network or networks through which the call has traversed. Progress indicator No. 2 indicates that the destination user is not ISDN. Progress indicator No. 3 indicates that the origination user is not ISDN. Progress indicator No. 4 indicates that a call which had left the ISDN has returned to the ISDN at the same point it had left due to redirection within the non-ISDN. This progress indicator would be employed when a prior Recommendation Q.931 message resulted in a progress indicator No. 1 "call is not end-to-end ISDN" being delivered to the calling user. The use of progress indicators Nos. 1, 2 and 3 is exemplified in the following. Three interworking situations are identified in the figure below: a) interworking with another network; b) interworking with a non-ISDN user connected to ISDN; c) interworking with non-ISDN equipment within the calling or called user's premises. As regards calls from A the following applies: case a) - progress indicator No. 1 sent to A; case b) - progress indicator No. 2 sent to A; case c) - progress indicator No. 2 sent to A (location sub-field = private network). As regards calls towards A the following applies: case a) - progress indicator No. 1 sent to A; case b) - progress indicator No. 3 sent to A; case c) - progress indicator No. 3 sent to A (location sub-field = private network) The use of progress indicator No. 8 "in-band information or appropriate pattern now available" is described in 5. Annex J (to Recommendation Q.931) Examples of cause value and location for busy condition This annex gives examples on the detailed cause value and location to be sent in a Cause information element for the busy condition. Figure J-1/Q.931 shows the reference configuration which identifies nodes where busy condition may occur and therefore a cause should be generated. Table J-1/Q.931 shows: a) a cause value and location to be generated at the point where the busy condition occurs; and b) a cause value and location to be delivered to the user (indicated as A) for each location (B - P) where the busy condition occurs. As is indicated in the table, the cause value is not changed but the location may be changed in the receiving exchange, when the cause value crosses a network boundary. Note - The interface A-B, C-D, M-N and O-P are assumed to be Q.931. FIGURE J-1/Q.931 Examples of cause values and location for busy condition TABLE J-1/Q.931 Location where busy occurs and the cause codings ┌───────────────────┬──────────────────┬──────────────────┐ │ Location where │Cause at the point│ Cause received │ │ busy occurs │ of generation │ by user A │ ├───────────────────┼──────────────────┼──────────────────┤ │ │ │ │ │B incoming circuit │ #34 or #44 LPN │ ) │ │B outgoing circuit │ #34 LPN │ ) │ │C outgoing circuit │ #34 LPN │ ) │ │ │ │ ) │ │D incoming circuit │ #34 or #44 LN │ ) │ │D outgoing circuit │ #34 LN │ )The same as left│ │E outgoing circuit │ #34 LN │ ) │ │ │ │ ) │ │F outgoing circuit │ #34 TN │ ) │ │G outgoing circuit │ #34 TN │ ) │ │ │ │ ) │ │H outgoing circuit │ #34 INTL │ ) │ │I outgoing circuit │ #34 INTL │ ) │ │ │ │ │ │J outgoing circuit │ #34 TN │ #34 TN │ │K outgoing circuit │ #34 TN │ #34 TN │ │ │ │ │ │L outgoing circuit │ #34 LN │ #34 RLN │ │M outgoing circuit │ #17 LN │ #17 RLN │ │ │ │ │ │N incoming circuit │ #34 or #44 LPN │ #34 or #44 RPN │ │N outgoing circuit │ #34 LPN │ #34 RPN │ │O outgoing circuit │ #17 LPN │ #17 RPN │ │ │ │ │ │P incoming circuit │ #34 or #44 U │ #34 or #44 U │ │P call control │ #17 U │ #17 U │ └───────────────────┴──────────────────┴──────────────────┘ LPN : Private network serving the local user LN : Public network serving the local user. TN : Transit network. INTL: International transit network. RLN : Public network serving the remote user. RPN : Private network serving the remote user. U : User. Table J-1/Q.931 is for further study. Annex K (to Recommendation Q.931) Message segmentation procedures K.1 Introduction Layer 3 messages that are longer than the length of frames that the data link layer can support may be partitioned into several segments. Message segmentation shall only be used when the message length exceeds N.201 (defined in Recommendation Q.921) [3]. These procedures are optional and may not be supported by all equipment. The architectural relationship to other Recommendation Q.931 functions is shown in Figure K-1/Q.931. These procedures apply only within a specific data link connection and do not impact the procedures in operation on other parallel data link connections. K.2 Message segmentation The following rules apply when Recommendation Q.931 messages are to be segmented for transmission: a) the default maximum number of message segments is eight. If the message is too long to be segmented then a local maintenance activity shall be notified; b) the first message segment shall begin with the protocol discriminator immediately followed by the Call reference, the segment message type, the Segmented message information element, and one or more other information elements; c) each subsequent message segment shall begin with the protocol discriminator immediately followed by the call reference, the segment message type, the Segmented message information element and one or more other information elements; d) the first segment indicator field of the Segmented message information element shall be set to indicate the first segment of a segmented message, and not set in any other segment; e) the number of segments remaining field of the Segmented message information element shall be set to indicate how many more segments are to be sent, see Figure L-2/Q.931. f) the Message type information element shall be coded to indicate a segment message, and the Segmented message information element shall indicate the message type of the original message; g) the transmission of a segmented message may be aborted by: sending a message or message segment containing a different call reference; sending a message with the message type not coded "segment message" or stopping the transmission of subsequent message segments pertaining to the same message; h) once the first segment has been transmitted on a particular data link connection, then all remaining segments of that message shall be sent (in order) before any other message (segmented or not) for any other call reference is sent on that data link connection; i) messages shall be segmented only at information element boundaries; i.e., no information element shall be separated into two segments; j) the information element order as a whole is preserved for the Segmented message regardless of segment boundary. K.3 Reassembly of segmented messages The following rules apply to the receipt and reassembly of segmented Q.931 messages: a) a reassembly function, on receiving a message segment containing the Segmented message information element with the first segment indicator indicating "first message", and containing the call reference and message type (coded as "segment message" shall enter the Receiving Segmented Message state and accumulate message segments; b) timer T314, shall be initialized or reinitialized upon receipt of a message segment containing the Segmented message information element with a non-zero number of segments remaining field. Timer T314 shall be stopped upon receipt of the last segment; i.e., a message segment containing the segmented message information element with the number of segments remaining field coded zero. Timer T314 shall not be initialized or reinitialized if error procedures as identified in rules below are initiated; c) a reassembly function receiving a message segment with a segmented message information element should wait for receipt of the last message segment pertaining to the same message i.e., containing the segmented message information element with the number of segments remaining field coded zero before delivering the message for further Q.931 processing as specified in 5.8. The reassembly function shall enter the Null state; d) upon expiry of timer T314, the reassembly function shall: discard all segments of this message so far received; notify the layer 3 management entity for the data link connection that message segments have been lost; and enter the null state. Note - Subsequent message segments relating to the same message shall be discarded according to rule f). e) a reassembly function, upon receiving eight message segments of the same segmented message without receiving a message segment with a number of segments remaining field of the Segmented message information element coded zero, shall: discard all message segments so far received; notify the layer 3 management entity for the data link connection that messages have been discarded; and enter the Null state; Note - Subsequent message segments relating to the same message shall be discarded according to rule f). f) a reassembly function, on receiving a message segment containing a Segmented message information element, but with no call reference or Message type information element, while in the Null state shall discard that message segment and remain in the Null state; g) a reassembly function, on receiving a message segment containing a Segmented message information element, while in the Receiving Segmented Message state with the number of segments remaining field that is not decremented from the number of segments remaining field in the Segmented message information element of the previous message segment, shall: discard all segments of this message so far received; and enter the Null state; Note - Subsequent message segments relating to the same message shall be discarded according to rule f). h) if there is a DL RELEASE INDICATION primitive or DL ESTABLISH INDICATION primitive received while in the Receiving Segmented Message state, the reassembly function shall: discard all received message segments so far received; forward the DL RELEASE INDICATION primitive or DL ESTABLISH INDICATION primitive for further Q.931 processing, and enter the null state; i) a reassembly function, upon receiving a message segment with the first segment indicator of the Segmented message information element indicating "subsequent", while in the Null state, shall: discard that message segment; and remain in the Null state. FIGURE K-1/Q.931 Logical architecture containing segmentation function FIGURE K-2/Q.931 Relation between message and segments Block diagram FIGURE K-3/Q.931 Segmentation functional interaction diagram FIGURE K-4/Q.931 Message segmenter SDL FIGURE K-5/Q.931 Message reassembler SDL (1 of 3) FIGURE K-5/Q.931 Message reassembler SDL (2 of 3) FIGURE K-5/Q.931 Message reassembler SDL (3 of 3)