ITU-T Q 955 3-1993 STAGE 3 DESCRIPTION FOR COMMUNITY OF INTEREST SUPPLEMENTARY SERVICES USING DSS 1 CLAUSE 3 - MULTI-LEVEL PRECEDENCE AND PREEMPTION (MLPP) (Study Group XI)《使用No 1数.pdf

1、INTERNATIONAL TELECOMMUNICATION UNION)45G134 1 TELECOMMUNICATION (03/93)STANDARDIZATION SECTOROF ITU$)4!,G0G035“3#2)“%2G0G03).!,).G0G03934%-G0G0.O G0G0 34!%G0G0 G0G0$%3#2)04)/.G0G0 conference disconnected, preemption; and for indicating conference floating,served user preempted, the Notification ind

2、icator information element, as described in 4.5.21/Q.931, shall be used withthe notification descriptions, as described in Table 3-2.TABLE 3-2/Q.955Notification indicator information element3.4.4 Definition of operations and errorsThe definition of operations and errors required for the MLPP supplem

3、entary service using the ASN.1, as specified inRecommendation X.208 and using the OPERATION and ERROR macros, as defined in Figure 4/X.219, is in Table 3-3.TABLE 3-3/Q.955Definition of operations and errorsNumber Label Meaning8 Preemption46 Precedence call blocked No preemptable circuit or called us

4、er is busy with a call ofequal or higher precedence levelNotification Description (Octet 3)Bits7 6 5 4 3 2 10 0 0 0 1 0 0 Call completion delay1 0 0 1 1 1 1 Conference floating served user preempted1 0 0 1 1 0 0 Conference disconneted, preemptionG13G13G0G0“EGING0-,00G13OPERATIONSG0DEFINITIONS-,00G13

5、OPERATIONSCCITTG0RECOMMENDATIONG0QG0 G0MLPPG0 G9G0OPERATIONSG13ANDG13ERRORS G9$% if the called user is an MLPP subscriber, the originating exchange shall retainRecommendation Q.955 (03/93) 9marking on the previously marked circuit for the MLPP call. Then, in both cases above, the MLPP callsetup will

6、 continue, as described in 5.1/Q.931, except that upon receipt of the ALERTING message, thecalling user shall unmark the previously marked circuit if the StatusRequest in the Return Resultcomponent of its Facility information element is coded to “successCalledUserNotMLPPSubscriber”.3.5.2.1.1.2 Excep

7、tional Procedures1) Upon receipt of a SETUP message for an MLPP service call, the originating exchange shall check todetermine if the network supports the invoked MLPP service. If this check is not satisfied, the Facilityinformation element shall be ignored or not formulated and the MLPP call setup

8、shall continue as if itwere a basic call, as described in 5.1/Q.931, except that the first call control message shall contain theReturn Error component of the mLPPCallrequest operation in its Facility information element, which iscoded to “rejectedByNetwork”.2) If the Facility information element is

9、 present in the SETUP message for a call invoking the MLPPsupplementary service (i.e. from an MLPP subscriber) and if the calling user exceeds the maximumsubscribed precedence level, the originating exchange shall return a RELEASE COMPLETE messagetoward the calling user, which contains the Return Er

10、ror component of the mLPPCallrequest operation inits Facility information element with Error “unauthorizedPrecedenceLevel”.3) If the Facility information element is not present in the SETUP message for a call invoking MLPPsupplementary service (i.e. from an MLPP subscriber) and if the calling user h

11、as not subscribed to theMLPP supplementary service for the bearer capability in the SETUP message, the originating exchangeshall reject the call by sending a RELEASE COMPLETE message toward the calling user, which containsthe Return Error component of the mLPPCallrequest operation in its Facility in

12、formation element withError “userNotSubscribed”.4) The precedence call may not be completed as a result of a network exchange being busy with calls ofequal or higher precedence (on the path toward the called user) or no preemptable circuit at the calledinterface. In this case, upon receipt of the Re

13、lease Indication with cause value #46, “precedence callblocked” from the network, the originating exchange shall return a DISCONNECT message toward thecalling user with the same cause value to clear the call. The DISCONNECT message shall also containthe Return Result component of the mLPPCallrequest

14、 operation in its Facility information element withStatusRequest coded to “failureCaseA”, indicating call failure.5) The precedence call may not be completed as a result of called user, who has not subscribed to alternateparty, is busy with either: (a) a call of equal or higher precedence than the c

15、alling user and no callcompletion supplementary services (e.g. call waiting) or call offering supplementary services (e.g. callforwarding busy) are available or (b) non-preemptable access resources and no call completionsupplementary services (e.g. call waiting) or call offering supplementary servic

16、es (e.g. call forwardingbusy) are available. In this case, upon receipt of the Release Indication with cause value #46, “precedencecall blocked” from the network, the originating exchange shall return a DISCONNECT message towardthe calling user with the same cause value to clear the call. The DISCON

17、NECT message shall alsocontain the Return Result component of the mLPPCallrequest operation in its Facility informationelement with StatusRequest coded to “failureCaseA”, indicating call failure.6) An MLPP call may be preempted as a result of preemption in the network or access. In this case, uponre

18、ceipt of the Release Indication with cause value #8, “preemption” from the network, the originatingexchange shall return a DISCONNECT message toward the calling user with the same Cause to clear thecall. The DISCONNECT message shall also contain the Return Result component of themLPPCallrequest oper

19、ation in its Facility information element with StatusRequest coded to“failureCaseB”, indicating call failure.10 Recommendation Q.955 (03/93)3.5.2.1.2 Procedure at destination exchange/destination user side3.5.2.1.2.1 Normal operationUpon receipt of the Setup Indication, the destination exchange that

20、 serves the called user shall mark the incoming circuit(identified by the Channel identification information element within the SETUP message) busy at the precedence leveland MLPP Service Domain of the MLPP call. Then:If LFB Indication was set to “pathReserved”, the network shall stop timer TLRwhich

21、 it had started upon marking acircuit to the called user as reserved (see 3.5.2.2.2.1). Then: If the reserved (or marked) circuit to the called user (as identified by a match between the Calling PartyNumber within the Setup Indication and Calling Party Numbers of the “reserved” circuits) is found an

22、d itis not idle, and if the called user is busy, the procedure in item 3) b) (1) (a) below shall be followed;otherwise, the procedure in item 2) b) (1) below shall be followed. If the reserved circuit to the called user is found and it is idle, it shall be marked with the precedence leveland MLPP Se

23、rvice Domain of the incoming MLPP call, and the procedure in item 1) b) below shall befollowed. If the reserved circuit to the called user is not found, the LFB Indication is coded to “lfbNotAllowed”, andthe procedure in the items below shall be followed.If LFB Indication was not set to “pathReserve

24、d”, the procedure in the items below shall be followed.1) If the called user is idle and an idle circuit to deliver the call to the called user exists, it shall mark the idlecircuit busy at the precedence level and MLPP Service Domain of the incoming MLPP call. Then:a) If the incoming call is a ROUT

25、INE call, a SETUP message shall be sent to the called user, whichcontains the Invoke component of the mLPPCallrequest operation in its Facility information element.The called user shall respond with: a CALL PROCEEDING message and mark the idle circuit busyat the precedence level and MLPP Service Dom

26、ain of the incoming MLPP call or RELEASECOMPLETE message. Upon receipt of a CALL PROCEEDING message from the called userindicating that compatibility requirements have been satisfied, the procedure in item 4) shall befollowed; otherwise, upon receipt of a RELEASE COMPLETE message from the called use

27、r withcause value #88, “incompatible destination”, indicating that compatibility requirements have notbeen satisfied, the network shall unmark the previously marked circuit and clear the incoming callwith the same cause value.b) If the incoming call is a precedence call, a SETUP message shall be sen

28、t to the called user, whichcontains the Invoke component of the mLPPCallrequest operation in its Facility information element.The called user shall respond with: a CALL PROCEEDING message and mark the idle circuit busyat the precedence level and MLPP Service Domain of the incoming MLPP call or a REL

29、EASECOMPLETE message. Upon receipt of a CALL PROCEEDING message from the called user,indicating that compatibility requirements have been satisfied, the following procedure will befollowed; otherwise, upon receipt of a RELEASE COMPLETE message from the called user withcause value #88, “incompatible

30、destination”, indicating that compatibility requirements have notbeen satisfied, the network shall unmark the previously marked circuit and continue the preemptingcall setup employing the procedure in item 3) b) (1) (b), items 1) through 3).(1) If an alternate party is subscribed to, then:(a) Upon r

31、eceipt of ALERTING message, sent by the called user, indicating that the calleduser has been notified of the precedence call, the network shall start timer TK. TheALERTING message shall contain the Return Result component of the mLPPCallrequestoperation in its Facility information element. Then, the

32、 destination exchange shall checkthe StatusRequest to determine if the called user is an MLPP subscriber. If the called user isnot an MLPP subscriber (as indicated by StatusRequest coded to“successCalledUserNotMLPPSubscriber”), the destination exchange shall unmark thepreviously marked circuit for t

33、he MLPP call; if the called user is an MLPP subscriber (asindicated by StatusRequest coded to “successCalledUserMLPPSubscriber”), the destinationexchange shall retain marking on the previously marked circuit for the MLPP call. If thecalled user responds with a CONNECT message before the expiry of ti

34、mer TK(indicatingcalled user acceptance of preemption), the network shall stop timer TKand the networkshall complete the MLPP call setup, as described in 5.2.7/Q.931. If no CONNECT messageRecommendation Q.955 (03/93) 11is received from the called user before the expiry of timer TK, the network shall

35、 stop timerTKand the network shall divert the precedence call to the alternate party, using theprocedures as described in 3/Q.952 for the call forwarding no reply supplementary service.The setup sent to the alternate party shall contain: the precedence level and MLPP ServiceDomain of the diverted pr

36、ecedence call, LFB Indication set to “lfbNotAllowed”, and thereason for redirection = Call Forwarding No Reply.(b) If no ALERTING message is received, the network shall divert the precedence call to thealternate party, using the procedures as described in 3/Q.952 for the call forwarding noreply supp

37、lementary service. The setup sent to the alternate party shall contain: theprecedence level and MLPP Service Domain of the diverted precedence call, LFBIndication set to “lfbNotAllowed”, and the reason for redirection = Call Forwarding NoReply.(2) If no alternate party is subscribed to, then the pro

38、cedure in item 4) shall be followed.2) If the called user is idle, but an idle circuit to deliver the call to the called user does not exist, then:a) If the call is a ROUTINE call, clearing of the calling user shall be initiated by sending a RejectIndication to the network with cause value #34, “no

39、circuit/channel available”.b) If the call is a precedence call and the existing MLPP call is at lower precedence, then:(1) If preemptable access resources exist, the network shall mark the circuit (carrying the existingMLPP call) with the precedence level and MLPP Service Domain of the incoming call

40、 and thenetwork shall send a SETUP message, which contains the Invoke component of themLPPCallrequest operation in its Facility information element, to the called user. The calleduser may respond with a CALL PROCEEDING message or a RELEASE COMPLETEmessage. Then:Upon receipt a CALL PROCEEDING message

41、 from the called user, indicating thatcompatibility requirements have been satisfied, the network shall clear the existing MLPP callto the busy user (i.e. “other user”) on the called interface toward: (a) the busy user, using aDISCONNECT message and (b) the network with cause value #8 and the preemp

42、ting call setupcontinues employing the procedure in item 5). The DISCONNECT message shall contain theInvoke component of the mLPPCallpreemption operation in its Facility information elementwith Preempt params coded to “circuitReservedForReuse”.Upon receipt of a RELEASE COMPLETE message from the call

43、ed user with cause value #88,“incompatible destination”, indicating that compatibility requirements have not been satisfied,the network shall unmark the previously marked circuit and continue the preempting call setupemploying the procedure in item 3) b) (1) (b), items 1) through 3) except that the

44、“called user”is to be interpreted as the “other user” under consideration on the called interface.(2) If preemptable access resources do not exist, the network shall continue the preempting callsetup employing the procedure in item 3) b) (1) (b), items 1) through 3) except that the “calleduser” is t

45、o be interpreted as the “other user” under consideration on the called interface.c) If the call is a precedence call and the existing MLPP call is at equal or higher precedence, then theprocedure in item 3) b) (1) (b) shall be followed.12 Recommendation Q.955 (03/93)3) If the called user is busy, th

46、en:a) If the call is a ROUTINE call, clearing of the calling user shall be initiated by sending an Indicationto the network with cause value #17, “user busy”.b) If the call is a precedence call, then:(1) If the called user is busy with a call of lower precedence, then:(a) If preemptable access resou

47、rces exist, the network shall mark the circuit (carrying theMLPP call of the called user) with the precedence level and MLPP Service Domain of theincoming call and the network shall send a SETUP message, which contains the Invokecomponent of the mLPPCallrequest operation in its Facility information

48、element, to thecalled user. The called user may respond with a CALL PROCEEDING message or aRELEASE COMPLETE message. Then:1) Upon receipt a CALL PROCEEDING message from the called user, indicating thatcompatibility requirements have been satisfied, the network shall place the existingMLPP call on ho

49、ld, using a HOLD message delivered to the called user with causevalue #8, “preemption” (in order to notify the called user of intended preemption) andthe network shall start the timer TK. Upon sending the CALL PROCEEDING message,the called user shall mark the circuit with which the called user is busy with theprecedence level and MLPP Service Domain of the incoming MLPP call.If the called user responds with a HOLD ACKNOWLEDGE message is received beforethe expiry of timer TK(indicating the acceptance of intended preemption), the networkshall stop the timer TKand the network