1、 INTERNATIONAL TELECOMMUNICATION UNION ITU-T Q.1980.1TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (12/2004) SERIES Q: SWITCHING AND SIGNALLING Specifications of signalling related to Bearer Independent Call Control (BICC) The Narrowband Signalling Syntax (NSS) Syntax definition ITU-T Recommendati
2、on Q.1980.1 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 SYSTEMS Q.100Q.1
3、19 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 DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 Q.850Q.999 PUBLIC LAND MOBILE N
4、ETWORK 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 CALL CONTROL (BICC) Q.1900Q.1999 BROADBAND ISDN Q.2000Q.2999 For fur
5、ther details, please refer to the list of ITU-T Recommendations. ITU-T Rec. Q.1980.1 (12/2004) i ITU-T Recommendation Q.1980.1 The Narrowband Signalling Syntax (NSS) Syntax definition Summary This Recommendation describes a Narrowband Signalling Syntax (NSS) to provide a normalized set of telephony
6、parameters. NSS enables mapping from multiple telephony protocols in use today into a common parameter set. Source ITU-T Recommendation Q.1980.1 was approved on 10 December 2004 by ITU-T Study Group 11 (2005-2008) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. Q.1980.1 (12/2004) FOREWOR
7、D The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing
8、 Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics
9、. 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 necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “A
10、dministration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and
11、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 equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendat
12、ion 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 claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claim
13、ed 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 received notice of intellectual property, protected by patents, which may be required to implement this Recommendat
14、ion. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database. ITU 2005 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission
15、of ITU. ITU-T Rec. Q.1980.1 (12/2004) iii CONTENTS Page 1 Scope 1 2 References. 1 3 Definitions 2 4 Abbreviations 3 5 Message and parameter syntax overview . 3 5.1 Character set . 3 5.2 Structure . 4 5.3 NSS compact transmission mode . 5 6 Message definitions 5 6.1 Unsupported messages . 5 6.2 NSS m
16、essage identifier codes 5 7 Parameter definitions 7 7.1 Unsupported parameter disposition 7 7.2 NSS parameter codes 7 7.3 Detailed parameter descriptions . 14 7.4 BAT ASE parameters. 78 8 MIME encoding of NSS body 90 8.1 MIME-Version header field . 90 8.2 Content-Type header field 90 8.3 Content-Tra
17、nsfer-Encoding header field 90 8.4 Content-Disposition header field 90 8.5 NSS MIME media type specification. 91 9 Encapsulation in SIP. 91 10 Encapsulation in H.323. 91 11 Security considerations. 91 12 NSS-specific syntactical elements and procedures 91 12.1 NSS-specific messages. 91 12.2 NSS-spec
18、ific parameters 91 12.3 NSS compatibility procedures 92 Annex A Narrowband Signalling Syntax ABNF grammar 94 Appendix I Narrowband Signalling Syntax (NSS) encoding examples . 113 I.1 Message examples 113 I.2 Compatibility ordering example. 115 I.3 GCI and TID structure example . 115 Appendix II NSS
19、verbose encoding 117 ITU-T Rec. Q.1980.1 (12/2004) 1 ITU-T Recommendation Q.1980.1 The Narrowband Signalling Syntax (NSS) Syntax definition 1 Scope This Recommendation specifies a flexible encoding syntax of narrowband signalling information to be transferred in protocols that cannot inherently tran
20、sfer such information. Figure 1/Q.1980.1 Scope of this Recommendation 2 References The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were
21、valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendati
22、ons is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. ITU-T Recommendation H.225.0 (2003), Call signalling protocols and media stream packetization for packet-based multimedia communication syst
23、ems. ITU-T Recommendation H.323 (2003), Packet-based multimedia communication systems. ITU-T Recommendation Q.761 (1999), Signalling System No. 7 ISDN User Part functional description. ITU-T Recommendation Q.762 (1999), Signalling System No. 7 ISDN User Part general functions of messages and signals
24、. ITU-T Recommendation Q.763 (1999), Signalling System No. 7 ISDN User Part formats and codes; plus Amendment 1 (2001), Coding of the application transport parameter; Corrigendum 1 (2001); plus Amendment 2 (2002), Support for the International Emergency Preference Scheme. ITU-T Recommendation Q.765.
25、5 (2004), Signalling System No. 7 Application Transport Mechanism: Bearer Independent Call Control (BICC). ITU-T Recommendation Q.767 (1991), Application of the ISDN User Part of CCITT Signalling System No. 7 for international ISDN interconnections; plus Amendment 1 (2002), Support for the Internati
26、onal Emergency Preference Scheme. 2 ITU-T Rec. Q.1980.1 (12/2004) ITU-T Recommendation Q.850 (1998), Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN User Part; plus Addendum 1 (2000), plus Amendment 1 (2001). ITU-T Recommendation Q.9
27、31 (1998), ISDN user-network interface layer 3 specification for basic call control; plus Amendment 1 (2002), Extensions for the support of digital multiplexing equipment; plus Erratum 1 (2003). ITU-T Recommendation Q.1902.3 (2001), Bearer Independent Call Control protocol (Capability Set 2) and Sig
28、nalling System No. 7 ISDN user part: Formats and codes; plus Amendment 1 (2002), Support for the International Emergency Preference Scheme. ETSI TS 126 103 v 5.5.0 (2004-09), Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Speech codec list f
29、or GSM and UMTS (3GPP TS 26.103 version 5.5.0 Release 5). IETF RFC 2045 (1996), Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. IETF RFC 2046 (1996), Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. IETF RFC 2183 (1997), Communicating Pres
30、entation Information in Internet Messages: The Content-Disposition Header Field. IETF RFC 2234 (1997), Augmented BNF for Syntax Specifications: ABNF. IETF RFC 2327 (1998), SDP: Session Description Protocol. IETF RFC 3261 (2002), SIP: Session Initiation Protocol. 3 Definitions This Recommendation def
31、ines the following terms: 3.1 compatibility parameter: A compatibility parameter is a NSS parameter used to carry unrecognized syntax objects and requiring the PRN parameter for interpretation. The set of compatibility parameters includes FDC, UFC, PCI, and MCI. NOTE The ATP parameter also requires
32、the PRN parameter for interpretation. 3.2 mappable parameter: An ISUP/BICC parameter which satisfies the following conditions with respect to the protocol transporting the NSS body: every field in the ISUP/BICC parameter is accounted for by a field or combination of fields in the encapsulating proto
33、col; every potential value of the ISUP/BICC field is accounted for by a value of the corresponding field(s) in the encapsulating protocol; and the original value of every ISUP/BICC field can be recovered when the encapsulating protocol alone (disregarding any encapsulated NSS or ISUP/BICC) is mapped
34、 back to the same variant of ISUP/BICC as was mapped into the encapsulating protocol at the NSS-originating node. 3.3 NSS message: A NSS message is a body composed of a contiguous set of text lines as defined in clause 5. ITU-T Rec. Q.1980.1 (12/2004) 3 4 Abbreviations This Recommendation uses the f
35、ollowing abbreviations: ABNF Augmented Backus-Naur Form (see RFC 2234) ASCII American Standard Code for Information Interchange BICC Bearer Independent Call Control COT Continuity Test (used for TDM circuits) IA5 International Alphabet No. 5 (same as 7-bit ASCII) IE Information Element IEPS Internat
36、ional Emergency Preference Scheme ISDN Integrated Services Digital Network ISUP ISDN User Part ITU-T International Telecommunication Union Telecommunication Standardization Sector MIME Multipurpose Internet Mail Extensions NSS Narrowband Signalling Syntax PBX Private Branch eXchange POTS Plain Old T
37、elephone Service PSTN Public Switched Telephone Network RAS Registration, Admission and Status (see ITU-T Rec. H.225.0) RTP Real-time Transport Protocol SDP Session Description Protocol SIP Session Initiation Protocol SS7 Signalling System No. 7 TDM Time Division Multiplexing 5 Message and parameter
38、 syntax overview The general rules for NSS message, parameter, and field formats are specified in this clause. 5.1 Character set NSS messages are composed of printable IA5 (i.e., 7-bit US ASCII) characters plus carriage return (CR = x0D) and line feed (LF = x0A). Alphabetic characters are case sensi
39、tive. The case rules are described in this clause and in 5.2. Values potentially requiring the representation of information lying outside this character set shall be presented as a sequence of one or more binary octets, expressed as a series of one or more pairs of characters (“0“-“9“, “A“-“F“) wit
40、hout a preceding “x“ representing the binary octets as hexadecimal values. The characters “A“ through “F“ must be upper case. The ordering of the binary octets in a given value is defined by the source protocol. The resulting sequence of character pairs will be placed into an NSS value field with no
41、 leading “x“ character in that same order. The first character of each pair represents the most significant four bits of the binary octet being expressed. If an octet of the source protocol contains bits which do not belong to the field or sub-field value being encoded, these bits shall be set to ze
42、ro before applying the hexadecimal encoding. 4 ITU-T Rec. Q.1980.1 (12/2004) NOTE The ordering of bits within individual octets as represented by the hexadecimal encoding is the reverse of their order of transmission in the source protocol. See 1.9/Q.763. Clauses 7.3 and 7.4 indicate for each field
43、or subfield value whether the direct or ASCII-hexadecimal representation is used. The CR and LF characters are reserved for use together as line termination. See 5.2.1. The “,“ and “=“ characters are reserved for use as separators. Parentheses “(“ and “)“ and braces “ and “ are reserved for use as g
44、roup delimiters. The application of these reserved characters is described in 5.2. The “ character is reserved for use as an escape mechanism and must be placed immediately before any “,“ or “=“ or “(“ or “)“ or “ or “ or CR or LF or “ character found in a field value during parameter construction.
45、During parsing, each first encounter of an “ character is not used as part of the field value and the character following the “ is treated as part of the field value. 5.2 Structure 5.2.1 NSS message A NSS message is composed of a sequence of lines, each beginning with a sequence of three upper-case
46、letters followed by a comma and ending with a carriage return line feed sequence (x0Dx0A). Except for the Message Identifier line, the initial sequence of letters on a line identifies a parameter. On the Message Identifier line, the initial sequence of letters identifies a message. The set of messag
47、e identifiers defined in this Recommendation is listed in 6.2, “NSS message identifier codes“. The set of parameter identifiers defined in this Recommendation is listed in 7.2, “NSS parameter codes“. A NSS message begins with three mandatory NSS-specific parameters: Version (VER), Protocol Name/Vers
48、ion (PRN), and Message Identifier in that order. These are followed by zero or more other parameters. This Recommendation does not specify which additional parameters must be present in a NSS message, nor does it specify the order in which those parameter lines must appear. It is recommended that th
49、is order be the same as that of the corresponding parameters in the source protocol message. NOTE It is expected that NSS messages will not include parameter lines derived from source protocol parameters that have been successfully mapped to the encapsulating protocol. Rules for interworking BICC and ISUP to the combination of SIP (RFC 3261) or ITU-T Rec. H.323 and NSS are not in the scope of this Recommendation. Multiple parameters of the same type indicate concurrent instances of a para
