1、ITU-T RECMN*d*955 93 = 4862593 0590268 119 = INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Q.955 (03/93) DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 STAG 3 DESCRIPTION FOR SUPPLEMENTARY SERVICES USING DSSI STAGE 3 DESCRIPTION FOR COMMUNITY OF INTEREST SUP
2、PLEMENTARY SERVICES USING DSS 1 AND PREEMPTION (MLPP) CLAUSE 3 - MULTI-LEVEL PRECEDENCE ITU-T Recommendation (2.955 (Previously “CCITT Recommendation“) ITU-T RECMN*Q=955 93 4862591 0590269 055 = FOREWORD The Telecommunication Standardization Sector (-T) is a permanent organ of the International Tele
3、com- munication Union. The -T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Conference (WTSC), which meets every four years, e
4、stablished the topics for study by the iTU-T Study Groups which, in their turn, produce Recommendations on these topics. -T Recommendation 4.955, clause 3, was prepared by the -T Study Group XI (1988-1993) and was approved by the WTSC (Helsinki, March 1-12, 1993). NOTES 1 As a consequence of a refor
5、m process within the International Telecommunication Union (ITU), the CCIIT ceased to exist as of 28 February 1993. In its place, the Telecommunication Standardization Sector (I”U-T) was created as of 1 March 1993. Similarly, in this reform process, the CCiR and the iFRB have been replaced by the Ra
6、diocommunication Sector. In order not to delay publication of this Recommendation, no change has been made in the text to references containing the acronyms “CCIIT, CCIR or IFRB” or their associated entities such as Plenary Assembly, Secretariat, etc. Future editions of this Recommendation will cont
7、ain the proper terminology related to the new structure. 2 telecommunication administration and a recognized operating agency. In this Recommendation, the expression “Administration” is used for conciseness to indicate both a O 1994 All rights reserved. No part of this publication may be reprodud or
8、 utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the . = 4862571 0570270 877 CONTENTS 3 Multi-level precedence and preemption (MLPP) . 3.1 Definition 3.2 Description 3.3 Operational requirements 3.4 Coding requi
9、rements . 3.5 Signalling requirements 3.6 3.7 Interactions with other networks . 3.8 Signalling flows 3.9 Parameter values -timers . Interactions with other supplementary services Page 1 1 1 2 4 8 16 20 25 29 Recommendation Q.955 (03/93) 1 ITU-T RECMN*d.955 93 m 48b259L 0590273 703 m Recommendation
10、Q.955 STAGE 3 DESCRIPTION FOR “COMMUNITY OF INTEREST” SUPPLEMENTARY SERVICES, USING DSS 1 (Helsinki 1993) 3 Multi-level precedence and preemption (MLPP) 3.1 Definition The Multi-level Precedence and Preemption (MLPP) supplementary service provides prioritized call handling service. This supplementar
11、y service has two parts - precedence and preemption. Precedence involves assigning a priority level to a call. Preemption involves the seizing of resources, which are in use by a call of a lower precedence, by a higher level precedence call in the absence of idle resources. Users in networks that do
12、 not support this service will not be affected by this service. The stage 1 description of the MLPP supplementary service is contained in 3L.255. The stage 2 description of the MLPP supplementary service is contained in 3/Q.85. 3.2 Description 3.2.1 General description The MLPP supplementary service
13、 is provided as a network providers option to a domain of a network. The domain can be the whole network or a subset of the network. The MLPP supplementary service applies to all network resources in the domain that are in common use. The maximum precedence level of a subscriber is set at the subscr
14、iption time by the service provider based on the subscribers need. The subscriber may select a precedence level up to and including the maximum subscribed to precedence level on a per call basis. Precedence calls (calls using the MLPP supplementary service that have a higher precedence than the lowe
15、st level of precedence) that are not responded to by the called party (e.g. call unanswered andor unacknowledged, called party busy with call of equal or higher precedence, or called party busy and non-preemptable) are diverted to a predetermined alternate party. This alternate party may be another
16、subscriber or a network operating position. Preemption may take one of two forms. First, the called party may be busy with a lower precedence call which must be preempted in favor of completing the higher precedence call from the calling party. Second, the network resources may be busy with calls so
17、me of which are of lower precedence than the call requested by the calling party. One or more of these lower precedence calls must be preempted to complete the higher precedence call. There are three characteristics of preemption: I) Any party whose connection was terminated (whether that resource i
18、s reused or not) must receive a distinctive preemption notification. 2) Any called party of an active call that is being preempted by a higher precedence call should be required to acknowledge the preemption before being connected to the new calling party. 3) When there are no idle resources, preemp
19、tion of the lowest lower level of precedence resources shall occur. A call can be preempted any time after the precedence level of the call has been established and before call clearing has begun. Recommendation Q.955 (03193) 1 ITU-T RECMN*Q-755 73 m YB62571 0570272 64” 9 The MLPP supplementary serv
20、ice is not intended to provide preemption of users that do not subscribe to the MLPP supplementary service. The service provides for preemption of calls within the MLPP domain, which consists of the resources belonging to the users that subscribe to the MLPP supplementary service. In other words, ca
21、lls that are originated by or made to non-MLPP users will not be preempted. Calls that are originated by MLPP subscribers may be preempted by calls of higher precedence only in networks that support this service. 3.2.2 Specific terminology The following specific terminology is used in this Recommend
22、ation: Precedence is the priority associated with a call. A precedence call is a call using the MLPP supplementary service with precedence level higher than the lowest level of precedence. An MLPP call is a call using the MLPP supplementary service that has a precedence level established and is eith
23、er being setup or is setup. In the DSS 1, an MLPP call is a call from an MLPP subscriber for which a SETUP has been sent but no DISCONNECT has been sent or received (Le. call states U1 through Vio). A preempting call is a call using the MLPP supplementary service with a precedence level higher than
24、the lowest (Le. ROUTINE) level of precedence, for which a call setup request has been received at the exchange. User is a DSS i protocol entity at the user side of the user-network interface. A user is identified by a terminal, which is addressed by its ISDN number. A called user is considered busy
25、if he is on an active call (i.e. in call state U10). Network is a DSS 1 protocol entity at the network side of the user-network interface. A preemptable circuit is a circuit that is active with or reserved for an MLPP call: (1) within the same domain as the preempting call and (2) with a lower prece
26、dence than the preempting call. A busy or reserved circuit for which a precedence levei has not been specified is not a preemptable circuit. A preemption initiating exchange is the exchange that is congested (Le. no idle circuits) and has received a preempting call setup. Congestion has been encount
27、ered when it is determined that all circuits capable of routing the MLPP call are busy (i.e. no idle circuits.) Response Timer TK is as defined in 314.85. The length of this timer is in the range of 4-30 seconds. An alternate party is as defined in 3Q.85. OE (Originating Exchange) is an exchange tha
28、t is directly connected to a calling user. DE (Destination Exchange) is an exchange that is directly connected to a called user. The “Invoke”, “Return Result, and “Return Error” components shall be as defined in 8.2.3.1.1lQ.932. 3.2.3 Qualifications on the applicability to telecommunication services
29、 This supplementary service is considered meaningful when applied to the Telephony Teleservice, speech, 3.1 kHz audio, 7 kHz audio, and 64 kbit/s unrestricted bearer services. Furthermore, it may be meaningful when applied to other services. 3.2.4 State definitions No additional call states, beyond
30、those specified in Recommendations Q.931 and 4.932, are identified for the MLPP service. 3.3 Operational requirements 3.3.1 Provisiodwithdrawal For a given ISDN number, a maximum authorized precedence level may be subscribed to for each service or collectively for all services. 2 Recommendation Q.95
31、5 (03193) ITU-T RECMN*Qm755 73 4862573 0570273 58b 3.3.1.1 Terminal options A user, as identified by a terminal, has the following subscription options for the MLPP supplementary service: i) Maximum authorized precedence level (see Note 1): a) b) 1 (FLASH) c) 2 (IMMEDIATE) d) 3 (PRIORITY) e) 4 (ROUT
32、INE - lowest). O (FLASH OVERRIDE - highest) 2) Alternate party: a) yes - network operating position - alternate party directory number b) no. Access resources non-preemptable (see Note 2): 3) a) Yes b) no. NOTES 1 2 A call of higher precedence level can preempt calls of lower precedence. For example
33、, a FLASH call can preempt IMMEDIATE, PRIORITY, or ROUTINE calls. A user having this option will not experience preemption of calls by higher precedence calls, if the cause for preemption would be due to called party busy condition. However, the user may still experience preemption of calls due to a
34、 lack of network resources other than the users own access resources. Terminal equipment invoking MLPP supplementary service should be able to indicate the precedence level of the call in the SETUP message and should support Cause values: #8, “preemption” and #46, “precedence call blocked”. Terminal
35、 equipment that receive MLPP calls, including that of the alternate party, should support the Hold and Retrieve functions, as defined in 6.2. UQ.932, Cause value: #8, “preemption”. Terminal equipment receiving MLPP calls do not have to subscribe to the call hold supplementary service. 3.3.1.2 Networ
36、k options As described in MLPP supplementary service Recommendations 1.255.3 (for stage 1) and 3/Q.85 (for stage 2). 3.3.2 Requirements on the originating network side Notification to the calling, called, and preempted users (as a result of preemption in the network or access) shall be conveyed in c
37、all control messages using Cause #8 and #46 in the Cause information element, as described in this Recommendation. Notification to the calling user of delay in call setup shall be conveyed in the NOTIFY message using notification description “O O O O 1 O 0” in the Notification indicator information
38、element, as described in this Recommendation. Notification to all conferees of served user preemption shall be conveyed in the NOTIFY message using notification description “i O O 1 1 1 1” in the Notification indicator information element, as described in this Recommendation. Notification to the rem
39、aining parties of a three way conversation that conference is disconnected as a result of preemption of one of the two calls, shall be conveyed in the NOTIFY or DISCONNECT message using notification description “1 O O 1 1 O 0” in the Notification indicator information element, as described in this R
40、ecommendation. 3.3.3 Requirements in the network This subclause is not applicable to DSS 1. Recommendation Q.955 (03/93) 3 ITU-T RECMN*Q=955 93 = 48b2591 0590234 412 = 3.3.4 Requirements on the terminating network side Notification to the calling, called, and preempted users (as a result of preempti
41、on in the network or access) shall be conveyed in call control messages using Cause #s 8 and #46 in the Cause information element. as described in this Recommendation. 3.4 Coding requirements 3.4.1 Messages The following messages are applicable to the operation of the MLPP supplementary service: SET
42、UP, ALERTING, NOTIFY, REGISTER, FACILITY, HOLD, HOLD ACKNOWLEDGE, HOLD REJECT, DISCONNECT, RELEASE, and RELEASE COMPLETE. The SETUP, ALERTING, NOTIFY, DISCONNECT, RELEASE, and RELEASE COMPLETE messages shall be as defined in 3.3.1/4.931. For the SETUP, NOTIFY, and DISCONNECT messages the following c
43、hanges are required. The SETUP message will contain the Facility information element. In addition, it shall contain the optional Calling party number, Called party number, and Channel identification information elements as mandatory information elements. The NOTIFY message shall contain the Notifica
44、tion indicator information element to indicate delay in call setup, as described in the MLPP procedure. The DISCONNECT message shall include the Cause information element, coded as described in this Recommendation. The FACILITY message shall contain the Return Result or Return Error components in it
45、s Facility information element when it is sent in response to the REGISTER message that shall be used to invoke an MLPP DSS 1 Look-ahead For Busy (LFB) query. The RELEASE COMPLETE message shall be used to terminate the signalling association created by the REGISTER message. The REGISTER, FACILITY, H
46、OLD, HOLD ACKNOWLEDGE, and HOLD RJ3ECT messages shall be as defined in 7.VQ.932. The REGISTER message shall contain the Bearer capability, Calling party number, Called party number, and Channel identification information elements encapsulated within the Invoke component of the Facility information e
47、lement. The HOLD message shall also contain the Cause information element, coded as appropriate to the MLPP procedure. 3.4.2 Codesets All information elements are in codeset O. Cause values #8 and #46, contained in the Cause information element, are proposed codeset O values. 3.4.3 Information eleme
48、nts The following information elements are applicable. 3.4.3.1 Facility information element For the functional protocol, the Facility information element, as described in 8.2.2/Q.932, shall be used for three MLPP operations, mLPPCallpreemption with operation value 26 (for management of the circuit o
49、ccupied by the to be preempted call), mLPPCallrequest (for MLPP call) with operation value 25 and mLPPLFBquery for MLPP Look-ahead for Busy (LFB) query with operation value 24. The MLPP operations and errors are defined in 3.4. 3.4.3.2 Cause Information Element For indicating the preemption of the call in the network and in the access, the Cause information element, as described in 4.5. i 21Q.93 1, shall be used with the two proposed codepoints for cause values described in Table 3-1. 4 Recommendation Q.955 (03/93) ITU-T RECMN*Q.955 93 M 48b259L 0590275
