ITU-T Q 764 AMD 3-2004 Signalling System No 7 C ISDN user part signalling procedures Amendment 3 SERIES Q SWITCHING AND SIGNALLING Specifications of Signalling System No 7 C ISDN u.pdf

1、 INTERNATIONAL TELECOMMUNICATION UNION ITU-T Q.764TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Amendment 3(04/2004) SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7 ISDN user partSignalling System No. 7 ISDN user part signalling procedures Amendment 3 ITU-T Recommendat

2、ion Q.764 (1999) Amendment 3 ITU-T Q-SERIES RECOMMENDATIONS SWITCHING AND SIGNALLING SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE Q.1Q.3 INTERNATIONAL AUTOMATIC AND SEMI-AUTOMATIC WORKING Q.4Q.59 FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN Q.60Q.99 CLAUSES APPLICABLE TO ITU-T STANDARD

3、 SYSTEMS Q.100Q.119 SPECIFICATIONS OF SIGNALLING SYSTEMS No. 4, 5, 6, R1 AND R2 Q.120Q.499 DIGITAL EXCHANGES Q.500Q.599 INTERWORKING OF SIGNALLING SYSTEMS Q.600Q.699 SPECIFICATIONS OF SIGNALLING SYSTEM No. 7 Q.700Q.799 General Q.700 Message transfer part (MTP) Q.701Q.709 Signalling connection contro

4、l part (SCCP) Q.711Q.719 Telephone user part (TUP) Q.720Q.729 ISDN supplementary services Q.730Q.739 Data user part Q.740Q.749 Signalling System No. 7 management Q.750Q.759 ISDN user part Q.760Q.769 Transaction capabilities application part Q.770Q.779 Test specification Q.780Q.799 Q3 INTERFACE Q.800

5、Q.849 DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 Q.850Q.999 PUBLIC LAND MOBILE NETWORK Q.1000Q.1099 INTERWORKING WITH SATELLITE MOBILE SYSTEMS Q.1100Q.1199 INTELLIGENT NETWORK Q.1200Q.1699 SIGNALLING REQUIREMENTS AND PROTOCOLS FOR IMT-2000 Q.1700Q.1799 SPECIFICATIONS OF SIGNALLING RELATED TO BEARER

6、INDEPENDENT CALL CONTROL (BICC) Q.1900Q.1999 BROADBAND ISDN Q.2000Q.2999 For further details, please refer to the list of ITU-T Recommendations. ITU-T Rec. Q.764 (1999)/Amd.3 (04/2004) i ITU-T Recommendation Q.764 Signalling System No. 7 ISDN user part signalling procedures Amendment 3 Summary This

7、Amendment 3 to the ISUP Specification Q.764 (12/1999) contains three modifications: 1) Fallback procedures; modification of clause 2.5.2.2.2. 2) Procedures to support the calling partys category for calls from mobile terminals; new procedures in a new clause 2.26. 3) Signalling procedures for automa

8、tic re-routing (crankback); new procedures in a new clause 2.27. NOTE Previous amendments to ITU-T Rec. Q.764 (12/1999) still apply and need to be taken into account when applying this amendment. Source Amendment 3 to ITU-T Recommendation Q.764 (1999) was approved on 13 April 2004 by ITU-T Study Gro

9、up 11 (2001-2004) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. Q.764 (1999)/Amd.3 (04/2004) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is

10、 a permanent organ of ITU. ITU-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 Assembly (WTSA), which meets every four years,

11、establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessar

12、y standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, t

13、he Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equival

14、ents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a clai

15、med Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had n

16、ot received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database. ITU 2004 All rights r

17、eserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ITU-T Rec. Q.764 (1999)/Amd.3 (04/2004) iii CONTENTS Page 1) Clause 2.5.2.2.2 Succeeding network does not have the capability of performing fallback . 1 2) New clause 2.26 Ca

18、lling partys category for calls from mobile terminals 1 3) New clause 2.27 Signalling procedures for automatic re-routing (crankback) 1 ITU-T Rec. Q.764 (1999)/Amd.3 (04/2004) 1 ITU-T Recommendation Q.764 Signalling System No. 7 ISDN user part signalling procedures Amendment 3 1) Clause 2.5.2.2.2 Su

19、cceeding network does not have the capability of performing fallback Modify the first paragraph as follows: The intermediate exchange will include a transmission medium used parameter (which has been set according to the fallback connection type indicated in the transmission medium requirement prime

20、 parameter) in the address complete message or call progress message indicating that fallback has occurred for this call. 2) New clause 2.26 Calling partys category for calls from mobile terminals 2.26.1 General For the purpose of this clause, the initiating exchange is the exchange which initiates

21、the procedure, and the terminating exchange is the exchange which terminates the procedure. The use of these specific calling partys category parameter values between network operators is based on bilateral agreements. 2.26.2 Actions at the initiating exchange Once the initiating exchange has determ

22、ined, either by indication from mobile network or by other means (e.g., number range), that the call is from a mobile terminal located in the home PLMN, then the calling partys category parameter is set to “mobile terminal located in the home PLMN“. If, for this call, the initiating exchange has det

23、ermined that the call is from a mobile terminal located in a visited PLMN, then the calling partys category parameter is set to “mobile terminal located in a visited PLMN“. If there is no indication that the mobile initiated call has roamed or not, then the default setting of the calling partys cate

24、gory parameter for this procedure will be “mobile terminal located in the home PLMN“. 2.26.3 Actions at the terminating exchange The terminating exchange shall pass this information to the management system. 2.26.4 Actions at other exchanges All other exchanges shall pass on these values of the call

25、ing partys category parameter. 3) New clause 2.27 Signalling procedures for automatic re-routing (crankback) 2.27.1 Introduction The automatic re-routing (crankback) signalling procedure allows the call set-up to return to a preceding exchange so that the call can be automatically re-routed from the

26、re. Crankback is an optional signalling procedure that allows for sophisticated support of the automatic re-routing (ARR) capability (refer to ITU-T Rec. E.170). This procedure is an additional procedure to the unsuccessful call set-up procedures described in 2.2. An exchange invokes the automatic r

27、e-routing 2 ITU-T Rec. Q.764 (1999)/Amd.3 (04/2004) signalling procedure when a call cannot be routed further from that exchange. There are three possible cases: 1) The process to select an outgoing circuit from the exchange fails. 2) A backward REL is received during the outgoing call set-up. The c

28、ause value received is either specific for the route chosen (e.g., bearer capability not implemented) or is temporary in nature (e.g., congestion). 3) The call cannot be established to the user at the destination local exchange. The number of attempts to re-route a call is limited. This limit is a n

29、etwork specific value, not exceeding 63. It needs to be emphasized that the automatic re-routing signalling procedure can only be effective when introduced on a network-wide basis. 2.27.2 Actions at an intermediate exchange 2.27.2.1 Sending a REL with the possible invocation of automatic re-routing

30、Automatic re-routing may or may not be invoked when the call cannot be routed further from an intermediate exchange as described in the cases 1 and 2 in 2.27.1. Invocation of automatic re-routing involves the setting or updating of the re-routing counter which keeps track of the number of re-routing

31、 attempts. A reason for not invoking automatic re-routing is when the counter has reached its upper limit. Four cases can be distinguished in an intermediate exchange: a) Automatic re-routing is invoked and the automatic re-routing parameter has not been received in the IAM for the incoming call. In

32、 this case, the intermediate exchange sends a REL towards the preceding exchange including the automatic re-routing parameter with the re-routing counter set to “one“ and the re-routing inhibit indicator set to “no indication“. b) Automatic re-routing is invoked and the automatic re-routing paramete

33、r has been received in the IAM for the incoming call. In this case, the intermediate exchange sends a REL towards the preceding exchange including the automatic re-routing parameter with the re-routing counter incremented by one, and the re-routing inhibit indicator set to “no indication“. c) Automa

34、tic re-routing is not invoked and the automatic re-routing parameter has or has not been received in the IAM for the incoming call. In this case, the intermediate exchange sends a REL towards the preceding exchange including the automatic re-routing parameter with the re-routing inhibit indicator se

35、t to “do not crankback“. The re-routing counter is not incremented if it was received in the incoming IAM. d) If the intermediate exchange does not support the automatic re-routing signalling procedure, no automatic re-routing parameter is sent in the REL message and thus a regular backward release,

36、 according to 2.2.2 or 2.2.3, takes place. As a network option, the reason for invoking or not invoking automatic re-routing can be indicated in the automatic re-routing parameter. This information could be helpful for operations and maintenance purposes. For example, it could be important to know w

37、hether an invocation (and, in particular, a re-routing inhibit) is based on: a cause code as received in a REL received during outgoing call set-up; ITU-T Rec. Q.764 (1999)/Amd.3 (04/2004) 3 trunk group data (which could, for instance, indicate that re-routing is useless since no other trunk group i

38、n the network exists to the final destination of the call); routing data (which could, for instance, indicate that re-routing is useless since no other route exists to the final destination of the call). 2.27.2.2 Receiving a REL with the automatic re-routing parameter An intermediate exchange can ta

39、ke four possible actions when it receives a REL from the succeeding exchange with the automatic re-routing parameter: a) It attempts to re-route the call to an alternative route if: automatic re-routing has been invoked (re-routing counter greater or equal to one and re-routing inhibit indicator cod

40、ed as “no indication“); autonomous logic in the exchange indicates that re-routing should be applied in this exchange. If an alternate route is available and the maximum number of re-routing attempts has not been exceeded, the exchange includes the automatic re-routing parameter into the IAM to indi

41、cate how many automatic re-routing (crankback) attempts have already occurred. If no alternative route is available, or the re-routing counter exceeds the maximum number of re-routing attempts allowed by the network, the received REL shall be passed towards the preceding exchange with the inclusion

42、of the automatic re-routing parameter as received. NOTE 1 The maximum number of re-routing attempts is network specific. b) It does not attempt re-routing but passes the received REL towards the preceding exchange with the inclusion of the automatic re-routing parameter as received if the re-routing

43、 inhibit indicator is coded as “do not crankback“. NOTE 2 The re-routing inhibit indicator is the means by which a succeeding exchange can explicitly prevent a preceding exchange from performing automatic re-routing. c) It does not attempt re-routing but passes the received REL towards the preceding

44、 exchange with the inclusion of the automatic re-routing parameter as received if the re-routing inhibit indicator is coded as “no indication“, and autonomous logic in the exchange indicates that no re-routing should be applied in this exchange. If the intermediate exchange wants to inhibit re-routi

45、ng, it includes the re-routing inhibit indicator set to “do not crankback“ in the automatic re-routing parameter. d) It handles the automatic re-routing parameter as an unrecognized parameter according to 2.9.5.3.2 if the exchange does not support the automatic re-routing signalling procedure and, a

46、s a result, does not recognize the parameter. This may render the automatic re-routing mechanism ineffective. 2.27.2.3 Receiving an IAM with the automatic re-routing parameter The intermediate exchange may receive the automatic re-routing parameter in an IAM. This parameter is passed on if the call

47、is routed to the succeeding exchange. If the call cannot be routed to the succeeding exchange, clause 2.27.2.1 applies. Procedures for unrecognized parameters apply if the intermediate exchange does not support the automatic re-routing signalling procedure and, as a result, does not recognize the pa

48、rameter; see 2.9.5.3.2. This may render the automatic re-routing mechanism ineffective. 2.27.3 Actions at a gateway exchange The actions as described in 2.27.2 apply. However, passing of the automatic re-routing parameter in the IAM and REL messages between networks depends on bilateral agreement (e

49、.g., exchanging automatic re-routing information may not be deemed desirable when crossing a network boundary). 4 ITU-T Rec. Q.764 (1999)/Amd.3 (04/2004) 2.27.4 Actions at the originating exchange The originating exchange performs the same actions as described in 2.27.2.2 with the exception that the call is released according to the normal release procedures if it is not re-routed. 2.27.5 Actions at the destination exchange When a destination local exchange cannot establish a call towards a user (case 3 in 2.27.1) and the incoming c