1、 INTERNATIONAL TELECOMMUNICATION UNION ITU-T Q.1902.4TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Amendment 2(04/2004) SERIES Q: SWITCHING AND SIGNALLING Specifications of signalling related to Bearer Independent Call Control (BICC) Bearer Independent Call Control protocol (Capability Set 2): Bas
2、ic call procedures Amendment 2 ITU-T Recommendation Q.1902.4 (2001) Amendment 2 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
3、 ISDN Q.60Q.99 CLAUSES APPLICABLE TO ITU-T STANDARD 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 Q3 INTERFACE Q.800Q.849 DIGITA
4、L 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 INDEPENDENT
5、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.1902.4 (2001)/Amd.2 (04/2004) i ITU-T Recommendation Q.1902.4 Bearer Independent Call Control protocol (Capability Set 2): Basic call procedures Amendment
6、 2 Summary This amendment to the ISUP Specification ITU-T Rec. Q.1902.4 (07/2001) contains seven modifications: 1) Correction of a cut and paste error in 7.4.1 and 7.4.4; 2) Modifications of the codec negotiation in 8.3; 3) Fallback procedures modification of 8.6.2.2.2; 4) Signalling procedures for
7、automatic rerouting (crankback); new procedures in a new clause 8.21; 5) Procedures to support the calling partys category for calls from mobile terminals; new procedures in a new clause 8.22; 6) Handling of national use elements at an international gateway SN or CMN; new procedures in a new clause
8、13.8; 7) Two message flows examples in codec negotiation and modification in Appendix I. NOTE Previous Amendment(s) to Q.1902.4 (07/2001) still apply and need to be taken into account when applying this Amendment. Source Amendment 2 to ITU-T Recommendation Q.1902.4 (2001) was approved on 13 April 20
9、04 by ITU-T Study Group 11 (2001-2004) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. Q.1902.4 (2001)/Amd.2 (04/2004) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardi
10、zation Sector (ITU-T) is 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
11、meets every four years, 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-
12、Ts purview, the necessary 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
13、is voluntary. However, the 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“
14、and the negative equivalents 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 i
15、nvolve the use of a claimed 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 R
16、ecommendation, ITU had not 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 databas
17、e. ITU 2004 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ITU-T Rec. Q.1902.4 (2001)/Amd.2 (04/2004) iii CONTENTS Page 1) Clause 7.4.1 Per-call bearer set-up in the forward direction 1 2) Clause 7.4.4 Per-cal
18、l bearer set-up using bearer control tunnelling delayed forward 1 3) Clause 8.3 Codec negotiation . 1 4) Clause 8.3.2 SN transiting codec negotiation. 1 5) Clause 8.3.4.1 Per-call bearer set-up in forward direction . 2 6) Clause 8.3.4.2 Per-call bearer set-up in backward direction 2 7) Clause 8.3.5.
19、1 Per-call bearer set-up in forward direction . 2 8) Clause 8.3.5.2 Per-call bearer set-up in backward direction 2 9) Clause 8.3.6.3 Codec negotiation in a SN transiting codec negotiation. 3 10) Clause 8.6.2.2.2 Succeeding network does not have the capability of performing fallback . 3 11) New claus
20、e 8.21 Signalling procedures for automatic rerouting (crankback) 3 12) New clause 8.22 Calling partys category setting for mobile terminals . 6 13) New clause 13.8 Handling of national use elements at an international gateway SN or CMN. 7 14) Clause I.2 Contents. 7 15) New Figures I.18 and I.19 8 IT
21、U-T Rec. Q.1902.4 (2001)/Amd.2 (04/2004) 1 ITU-T Recommendation Q.1902.4 Bearer Independent Call Control protocol (Capability Set 2): Basic call procedures Amendment 2 1) Clause 7.4.1 Per-call bearer set-up in forward direction Modify point 2.4 as follows: . 2.4) A Bearer Set-up request is sent to t
22、he selected BCF. This request includes: BNC-ID (as received sent in the BICC_Data indication primitive). BIWF address (as received sent in the BICC_Data indication primitive). Bearer Characteristics 2) Clause 7.4.4 Per-call bearer set-up using bearer control tunnelling delayed forward Modify point 2
23、.3 as follows: . 2.3) A Bearer Set-up request primitive is then sent to the selected BCF containing: BNC-ID (if received sent in the BICC_Data indication primitive). BIWF address (if received sent in the BICC_Data indication primitive). Bearer Characteristics 3) Clause 8.3 Codec negotiation Add the
24、following new paragraph at the end of clause 8.3: . When a call includes some SNs that are not supporting codec negotiation, procedures defined in this clause provide for codec negotiation between adjacent SNs supporting the capability. Basic bearer set-up procedures defined in 7.4 and 7.5 are used
25、in those portions of the connection that do not support codec negotiation. A combination of codec procedures for a single call will result in selection and placement of codecs in a connection that is assumed to have acceptable transmission performance. 4) Clause 8.3.2 SN transiting codec negotiation
26、 Modify clause 8.3.2 as follows: . In the case of a GSN between a network supporting codec negotiation and a network not supporting such capability, then: 2 ITU-T Rec. Q.1902.4 (2001)/Amd.2 (04/2004) The following cases apply as appropriate when interworking occurs between a network that supports co
27、dec negotiation and one that does not support codec negotiation: if the incoming side of the call is the network that supports codec negotiation then the CSF shall perform the codec negotiation procedures described in 8.3.3 for SN terminating codec negotiation; if the incoming side of the call is th
28、e network that does not support codec negotiation subsequent, then the CSF shall perform the codec negotiation procedures described in 8.3.1 for an SN initiating codec negotiation. 5) Clause 8.3.4.1 Per-call bearer set-up in forward direction Modify clause 8.3.4.1 as follows: . The selected codec id
29、entity is indicated to the BCF, unless it is identical to the preferred codec indicated to the BCF in 8.3.1, and the Available Codec List is stored in the CSF for future use. For abnormal procedures, see 8.3.6. 6) Clause 8.3.4.2 Per-call bearer set-up in backward direction Modify clause 8.3.4.2 as f
30、ollows: . The selected codec identity is indicated to the BCF, unless it is identical to the preferred codec indicated to the BCF in 8.3.1, and the Available Codec List is stored in the CSF for future use. For abnormal procedures, see 8.3.6. 7) Clause 8.3.5.1 Per-call bearer set-up in forward direct
31、ion Modify clause 8.3.5.1 as follows: . The selected codec identity is indicated to the BCF and the Available Codec List is stored in the CSF for future use (if not already stored). For abnormal procedures, see 8.3.6. 8) Clause 8.3.5.2 Per-call bearer set-up in backward direction Modify clause 8.3.5
32、.2 as follows: . 2) The selected codec identity is indicated to the BCF and the Available Codec List is stored in the CSF for future use (if not already stored). 3) The procedures to initiate bearer set-up continue at 7.5.2, 7.5.3 or 7.5.5 item 2. For abnormal procedures, see 8.3.6. ITU-T Rec. Q.190
33、2.4 (2001)/Amd.2 (04/2004) 3 9) Clause 8.3.6.3 Codec negotiation in an SN transiting codec negotiation Modify clause 8.3.6.3 as follows: Whenever a CSF transiting codec negotiation for a call, as described in 8.3.2, receives a BAT Compatibility Report information element in a BICC_Data indication pr
34、imitive from the succeeding node indicating that the codec negotiation parameters have been discarded and the call is proceeding without such parameters, the procedures are for further study codec negotiation procedures towards the succeeding CSF should be abandoned and basic bearer set-up procedure
35、s, defined in 7.4 and 7.5, should be resumed. The CSF will initiate procedures described in 8.3.3 for the terminating codec negotiation towards the preceding CSF. 10) Clause 8.6.2.2.2 Succeeding network does not have the capability of performing fallback Modify clause 8.6.2.2.2 as follows: The CSF w
36、ill include a Transmission Medium Used parameter (which has been set according to the fallback connection type indicated in the Transmission Medium Requirement parameter) in the ACM or CPG indicating that fallback has occurred for this call. . 11) New clause 8.21 Signalling procedures for automatic
37、rerouting (crankback) Add new clause 8.21 as follows: 8.21.1 Introduction The automatic rerouting (crankback) signalling procedure allows the call set-up to return to a preceding SN so that the call can be automatically rerouted from there. Crankback is an optional signalling procedure that allows f
38、or sophisticated support of the automatic rerouting (ARR) capability (refer to ITU-T Rec. E.170). This procedure is an additional procedure to the unsuccessful call set-up procedures described in clause 9. An SN invokes the automatic rerouting signalling procedure when a call cannot be routed furthe
39、r from that SN. There are three possible cases: 1) The process to select an outgoing route from the SN fails; 2) A backward REL is received during the outgoing call set-up. The cause value received is either specific for the route chosen (e.g., bearer capability not implemented) or is temporary in n
40、ature (e.g., congestion); 3) The call cannot be established to the user at the destination local SN. The number of attempts to reroute a call is limited. This limit is a network-specific value, not exceeding 63. It needs to be emphasized that the automatic rerouting signalling procedure can only be
41、effective when introduced on a network-wide basis. 8.21.2 Actions at an intermediate SN 8.21.2.1 Sending a REL with the possible invocation of automatic rerouting Automatic rerouting may or may not be invoked when the call cannot be routed further from an intermediate SN as described in the cases 1
42、and 2 in 8.21.1. Invocation of automatic rerouting involves the setting or updating of the rerouting counter which keeps track of the number of rerouting attempts. A reason for not invoking automatic rerouting is when the counter has reached its upper limit. 4 ITU-T Rec. Q.1902.4 (2001)/Amd.2 (04/20
43、04) Four cases can be distinguished in an intermediate SN: a) Automatic rerouting is invoked and the automatic rerouting parameter has not been received in the IAM for the incoming call. In this case, the intermediate SN sends a REL towards the preceding SN, including the automatic rerouting paramet
44、er with the rerouting counter set to “one“ and the rerouting inhibit indicator set to “no indication“. b) Automatic rerouting is invoked and the automatic rerouting parameter has been received in the IAM for the incoming call. In this case, the intermediate SN sends a REL towards the preceding SN in
45、cluding the automatic rerouting parameter with the rerouting counter incremented by one and the rerouting inhibit indicator set to “no indication“. c) Automatic rerouting is not invoked and the automatic rerouting parameter has, or has not, been received in the IAM for the incoming call. In this cas
46、e, the intermediate SN sends a REL towards the preceding SN including the automatic rerouting parameter with the rerouting inhibit indicator set to “do not crankback“. The rerouting counter is not incremented if it was received in the incoming IAM. d) If the intermediate SN does not support the auto
47、matic rerouting signalling procedure, no automatic rerouting parameter is sent in the REL message and thus a regular backward release, according to 9.3, takes place. As a network option, the reason for invoking, or not invoking, automatic rerouting can be indicated in the automatic rerouting paramet
48、er. This information could be helpful for operations and maintenance purposes. For example, it could be important to know whether an invocation (and, in particular, a rerouting inhibit) is based on: a cause code as received in a REL received during outgoing call set-up; trunk group data (which could
49、, for instance, indicate that rerouting is useless since no other trunkgroup in the network exists to the final destination of the call); routing data (which could, for instance, indicate that rerouting is useless since no other route exists to the final destination of the call). 8.21.2.2 Receiving a REL with the automatic rerouting parameter An intermediate SN can take four possible actions when it receives a REL from the succeeding SN with the automatic rerouting parameter: a) It attempts to reroute the
