5i' MONTAGE: FIN DE LA RECOMMANDATION Q.707 EN-T | TE DE CETTE PAGE Recommendation Q.708 NUMBERING OF INTERNATIONAL SIGNALLING POINT CODES 1 Introduction This Recommendation describes the numbering scheme of interna- tional signalling point codes for Signalling System No. 7 networks. The technical aspects of the signalling networks are specified in Recommendation Q.705. The worldwide signalling network is structured into two func- tionally independent levels, namely the international and national levels. This structure makes possible a clear division of responsi- bility for signalling network management and allows numbering plans of signalling points of the international network and the different national networks to be independent of one another. It is also noted that the point code is intended to be pro- cessed within the Message Transfer Part of each signalling point or signalling transfer point, so that there is no direct relationship to the telephone, data, or ISDN numbering. 2 Numbering of International Signalling Points 2.1 A 14-bit binary code is used for the identification of signalling points. 2.2 An international signalling point code (ISPC) should be assigned to each signalling point which belongs to the interna- tional signalling network. For some network environment, one physi- cal network node may serve as more than one signalling point, and may therefore be assigned more than one signalling point code. 2.3 All international signalling point codes (ISPC) should consist of three identification sub-fields as indicated in Figure 1/Q.708. The sub-field of 3 bits (NML) should identify a world geographical zone. The sub-field of 8 bits (K-D) should iden- tify a geographical area or network in a specific zone. The sub-field of 3 bits (CBA) should identify a signalling point in a specific geographical area or network. The combination of the first and second sub-fields could be regarded as a signalling area/network code (SANC). 2.4 Each country (or geographical area) should be assigned at least one signalling area/network code (SANC). 2.5 Two of the zone identifications, namely 0 and 1 codes, are reserved for future allocation. 2.6 The system of international signalling point codes (ISPC) will provide for 6 x 256 x 8 (12288) ISPCs. 2.7 If a country (or geographical area) should require more than 8 international signalling points, one or more additional sig- nalling area/network code(s) (SANC) would be assigned to it. 2.8 Lists of signalling area/network codes (SANC) to be used in the development of international signalling point codes (ISPC) is given in Annex A to this Recommendation. It shows SANCs assigned to each geographical area that already has other code assignments in existing public telecommunication networks. All codes not shown on the lists are spare codes. 2.9 The assignment of signalling area/network codes (SANC) is to be administered by the CCITT. The assignment of signalling point identifications in the sub-field (CBA) will be made by each country (or geographical area) and the CCITT Secretariat notified. 2.10 The Member countries of the International Telecommunica- tions Union not mentioned in Annex A who wish to take part in the international signalling network or those Members that require an additional signalling area/network code (SANC) should ask the Director of the CCITT for the assignment of an available SANC. In their request, they may indicate the available SANC preferred. 2.11 The Director of the CCITT takes care that: - generally the assignments are made on a one by one basis and contiguously for a given geographical area, or a given signalling network. (Geographical designations, or network names, may be entered in the list.) - the needs of each Member country of the Interna- tional Telecommunication Union for a new SANC shall be met under all circumstances. Should there not be any additional contiguous codes available, a new sequence of contiguous codes shall be opened up for the country concerned. Such a new code sequence will be established firstly at the bottom of the block of spare codes at the end of the lists in Annex A, and secondly at the bottom of existing sequences when it is likely that the adjacent code groups will not require the spares. - code assignments appearing in Annex A, but obvi- ously not required anymore because the networks concerned are reached with other SANCs will be deleted from the Annex. 2.12 Assignments by the Director of the CCITT of SANC as well as assignments by countries of the signalling point identifications will be published in the Operational Bulletin of the ITU. The representation of ISPC should be shown in decimal form in each sub-field, i.e. Z-UUU-V where Z, UUU, and V are corresponding to bits NML, K-D and CBA, respectively. Figure 1/Q.708, (M), p. ANNEX A (to Recommendation Q.708) Lists of Signalling Area/Network Codes (SANC) Note - These lists are shown by the decimal representation, i.e. Z-UUU where Z is zone identification and UUU is area/network identification. Zone 2 Code Geographical Area or Signalling Network 2-004 Greece 2-008 Netherlands (Kingdom of the) 2-012 Belgium 2-016 through 2-023 France 2-024 Monaco 2-028 Spain 2-032 Hungarian People's Republic 2-036 German Democratic Republic 2-040 Yugoslavia (Socialist Federal Republic of) 2-044 through 2-046 Italy 2-052 Romania (Socialist Republic of) 2-056 Switzerland (Confederation of) 2-060 Czechoslovak Socialist Republic 2-064 Austria 2-068 United Kingdom of Great Britain and Northern Ireland (British Telecom) 2-072 United Kingdom of Great Britain and Northern Ireland (Mercury Telecommunications Limited) 2-076 Denmark 2-080 and 2-081 Sweden 2-084 Norway 2-088 Finland 2-100 Union of Soviet Socialist Republics 2-120 Poland (People's Republic of) 2-124 through 2-131 Germany (Federal Republic of) 2-132 Gibraltar 2-136 Portugal 2-140 Luxembourg 2-144 Ireland 2-148 Iceland 2-152 Albania (Socialist People's Republic of) 2-156 Malta (Republic of) 2-160 Cyprus (Republic of) 2-168 Bulgaria (People's Republic of) 2-172 Turkey Zone 2, Spare Codes: 224 Zone 3 Code Geographical Area or Signalling Network 3-004 Canada 3-016 St. Pierre and Miquelon (French Department of) 3-020 through 3-059 United States of America 3-060 Puerto Rico 3-064 Virgin Islands (USA) Zone 3 (cont.) Code Geographical Area or Signalling Network 3-068, 3-069 and 3-070 Mexico 3-076 Jamaica 3-080 French Antilles 3-084 Barbados 3-088 Antigua and Barbuda 3-092 Cayman Islands 3-096 British Virgin Islands 3-100 Bermuda 3-104 Grenada 3-108 Montserrat 3-112 St. Kitts and Nevis 3-116 St. Lucia 3-120 St. Vincent and the Grenadines 3-124 Netherlands Antilles 3-128 Bahamas (Commonwealth of the) 3-132 Dominica (Commonwealth of) 3-136 Cuba 3-140 Dominican Republic 3-144 Haiti (Republic of) 3-148 Trinidad and Tobago 3-152 Turks and Caicos Islands 3-156 Guadeloupe 3-160 Martinique Zone 3, Spare Codes: 228 Zone 4 Code Geographical Area or Signalling Network 4-008 India (Republic of) 4-020 Pakistan (Islamic Republic of) 4-024 Afghanistan (Democratic Republic of) 4-026 Sri Lanka (Democratic Socialist Republic of) 4-028 Burma (Socialist Republic of the Union of) 4-030 Lebanon 4-032 Jordan (Hashemite Kingdom of) 4-034 Syrian Arab Republic 4-036 Iraq (Republic of) 4-038 Kuwait (State of) 4-040 Saudi Arabia (Kingdom of) 4-042 Yemen (Arab Republic) 4-044 Oman (Sultanate of) 4-046 Yemen (People's Democratic Republic of) 4-048 United Arab Emirates 4-050 Israel (State of) 4-052 Bahrain (State of) 4-054 Qatar (State of) 4-056 Mongolian People's Republic 4-058 Nepal 4-060 United Arab Emirates (Abu Dhabi) 4-062 United Arab Emirates (Dubai) 4-064 Iran (Islamic Republic of) Zone 4 (suite) Code Geographical Area or Signalling Network 4-080 Japan 4-100 Korea (Republic of) 4-104 Viet Nam (Socialist Republic of) 4-108 Hong Kong 4-110 Macao 4-112 Democratic Kampuchea 4-114 Lao People's Democratic Republic 4-120 China (People's Republic of) 4-135 Korea (Democratic People's Republic of) 4-140 Bangladesh (People's Republic of) 4-144 Maldives (Republic of) Zone 4, Spare Codes: 223 Zone 5 Code Geographical Area or Signalling Network 5-004 Malaysia 5-010 Australia 5-020 Indonesia (Republic of) 5-030 Philippines (Republic of) 5-040 Thailand 5-050 Singapore (Republic of) 5-056 Brunei Darussalam 5-060 New Zealand 5-070 Guam 5-072 Nauru (Republic of) 5-074 Papua New Guinea 5-078 Tonga (Kingdom of) 5-080 Solomon Islands 5-082 Vanatu (Republic of) 5-084 Fiji (Republic of) 5-086 Wallis and Futuna Islands 5-088 American Samoa 5-090 Niue Island 5-092 New Caledonia and Dependencies 5-094 French Polynesia 5-096 Cook Islands 5-098 Western Samoa (Independent State of) 5-100 Kiribati (Republic of) 5-102 Tuvalu Zone 5, Spare Codes: 232 Zone 6 Code Geographical Area or Signalling Network 6-004 Egypt (Arab Republic of) 6-006 Algeria (Algerian Democratic and Popular Republic) 6-008 Morocco (Kingdom of) 6-010 Tunisia 6-012 Libya (Socialist People's Libyan Arab Jamahiriya) 6-014 Gambia (Republic of the) 6-016 Senegal (Republic of the) 6-018 Mauritania (Islamic Republic of) 6-020 Mali (Republic of) 6-022 Guinea (Republic of) 6-024 C | te d'Ivoire (Republic of the) 6-026 Burkina Faso 6-028 Niger (Republic of the) 6-030 Togolese Republic 6-032 Benin (People's Republic of) 6-034 Mauritius 6-036 Liberia (Republic of) 6-038 Sierra Leone 6-040 Ghana 6-042 Nigeria (Federal Republic of) 6-044 Chad (Republic of) 6-046 Central African Republic 6-048 Cameroon (Republic of) 6-050 Cape Verde (Republic of) 6-052 Sao Tome and Principe (Democratic Republic of) 6-054 Equatorial Guinea (Republic of) 6-056 Gabon Republic 6-058 Congo (People's Republic of the) 6-060 Zaire (Republic of) 6-062 Angola (People's Republic of) 6-064 Guinea-Bissau (Republic of) 6-066 Seychelles (Republic of the) 6-068 Sudan (Republic of the) 6-070 Rwanda (Republic of) 6-072 Ethiopia (People's Democratic Republic of) 6-074 Somali Democratic Republic 6-076 Republic of Djibouti 6-078 Kenya (Republic of) 6-080 Tanzania (United Republic of) 6-082 Uganda (Republic of) 6-084 Burundi (Republic of) 6-086 Mozambique (People's Republic of) 6-090 Zambia (Republic of) 6-092 Madagascar (Democratic Republic of) 6-094 Reunion (French Department of) 6-096 Zimbabwe (Republic of) 6-098 Namibia 6-100 Malawi 6-102 Lesotho (Kingdom of) 6-104 Botswana (Republic of) 6-106 Swaziland (Kingdom of) 6-108 Comoros (Islamic Federal Republic of the) 6-110 South Africa (Republic of) Zone 6, Spare Codes: 203 Zone 7 Code Geographical Area or Signalling Network 7-004 Belize 7-008 Guatemala (Republic of) 7-012 El Salvador (Republic of) 7-016 Honduras (Republic of) 7-020 Nicaragua 7-024 Costa Rica 7-028 Panama (Republic of) 7-032 Peru 7-044 Argentine Republic 7-048 Brazil (Federative Republic of) 7-060 Chile 7-064 Colombia (Republic of) 7-068 Venezuela (Republic of) 7-072 Bolivia (Republic of) 7-076 Guyana 7-080 Ecuador 7-084 Guiana (French Department of) 7-088 Paraguay (Republic of) 7-092 Suriname (Republic of) 7-096 Uruguay (Eastern Republic of) Zone 7, Spare Codes: 236 Recommendation Q.709 HYPOTHETICAL SIGNALLING REFERENCE CONNECTION 1 Introduction This Recommendation specifies how the elements of a signalling connection are combined to meet the signalling requirements of the networks that it supports. Included are parameters for signalling transfer delay in both national and international networks, and overall signalling delay that such combinations will produce, together with the availability required, to enable the performance of the network served by the signalling network to be maintained. A probabilistic approach is been taken, i.e., limits are specified for mean and 95% of connections. These figures will apply to the normal operation of a signalling network. No consideration is given to the "unusually long" signalling paths that are found in some signalling networks. Any unusual routing caused by some net- work structures and/or reconfigurations due to network failure are considered to be covered in the remaining 5% of connections. The hypothetical signalling reference connection (HSRC) for international working is specified in this Recommendation by defin- ing the constituent parts of: i) the international section, ii) the national section. In any combination of those sections to produce an overall hypothetical signalling reference connection, it is necessary to consider what impact each of the component parts (international and two national sections) have on each other and the full hypothetical signalling reference connection. This means that certain national or international limits such as the maximum number of signalling transfer points allowed in a signalling relation (see Recommendation Q.705, S 5.2) require modification and account of this has been taken in this Recommendation. 2 Requirements of networks served by the signalling connec- tion To meet the requirements of services carried on the network served by the signalling network, the signalling connection perfor- mance should be closely aligned with those requirements. Since these services are ultimately to be carried on an ISDN, the hypothetical signalling reference connection is based upon the hypothetical reference connection produced for that network (Recommendation G.801). However, for a considerable time the majority of services in the network served by the signalling network will be telephony-based and account must therefore be taken of the refer- ence connection for conventional telephony application (Recommendation G.101). 3 Hypothetical signalling reference connection components for link-by-link signalling 3.1 General The components of an hypothetical signalling reference connec- tion are signalling points and STPs which are connected in series by signalling data links to produce a signalling connection (Note 1). The number of signalling points and STPs depend on the size of the network. Two limits are prescribed to cover mean or 95% cases. Separate cases are allowed for large countries and average sized countries (Note 2). This section outlines the considerations involved in formulating a hypothetical signalling reference connec- tion for link-by-link signalling and details the number of hypothetical signalling reference connection components and the delays they produce. Note 1 - The term signalling point is used to designate use of the user function in a signalling point: whether or not STP function is presented irrelevant in this context. The term STP is used to designate use of the STP function in a signalling point: whether or not user function is present is irrelevant in this con- text. Note 2 - When the maximum distance between an international switching centre and a subscriber who can be reached from it does not exceed 1000 km or, exceptionally, 1500 km, and when the country has less than n x 107 subscribers, the country is considered as of average size. A country with a larger distance between an interna- tional switching centre and a subscriber, or with more than n x 107 subscribers, is considered as of large size. (The value of n is for further study.) 3.1.1 Number of signalling points in the hypothetical sig- nalling reference connection The number of signalling points in the hypothetical signalling reference connection has been determined by considering the maximum number of links allowed by the Telephone Routing Plan (Q.13/E.171). These Recommendations define "last choice" backbone routes and only a small proportion of traffic take these routes. Traffic generated in metropolitan areas, generally the largest source of traffic, usually takes far fewer links to an international switching centre. Even for rural areas a connection to the international switching centre will not generally be required to follow the backbone route. Limitation of the number of signalling points required will reduce the signalling delay, considering that signalling point delay, forms the largest component of signalling delay. 3.1.2 Number of STPs in an hypothetical signalling refer- ence connection The number of STPs in the hypothetical signalling reference connection is a function of the number of signalling points, and the signalling network topology used to connect these signalling points. The number of STPs should be kept to a minimum in order to limit the signalling delay. In some signalling relationship, associated signalling may be used for which no STPs are required. In others, one or more STPs may be used. For international signal- ling relationship, it is recommended that no more than 2 STPs be used in a signalling relation. (See Recommendation Q.705, S 5.2.) 3.1.3 Signalling network availability The availability of a signalling connection is an important network parameter. It is necessary for the availability to be sig- nificantly better than the availability of the component being con- trolled (e.g. a circuit). A figure of 10 minutes down time per year maximum unavailability is recommended for any particular signalling route set (Recommendation Q.706, S 1.1). This corresponds to an availability of 0.99998, which can be achieved by the use of suitable network redundancies. 3.1.4 Signalling message transfer delay Signalling message transfer delay is another important network parameter. It affects call set up delay and also affects network response time to service requests made during a call. In this Recommendation, the transmission propagation delays are not included (see S 7.2). 3.2 International component of hypothetical signalling reference connection The international component of the hypothetical signalling reference connection includes all international signalling points in the connection and the STPs carrying signalling messages between the signalling points. The maximum number of signalling points and STPs allowed are listed in Table 1/Q.709. The unavailability of the overall international component of the signalling network should not exceed the following totals per year for both the 50 and 95 percent cases. - 20 minutes for large country to large country, - 30 minutes for large country to average-sized country, and - 40 minutes per year for average-sized country to average-sized country. H.T. [T1.709] TABLE 1/Q.709 Maximum number of signalling points and STPs in international component _________________________________________________________________________________________________ Country size (Note) Percent of connections Number of STPs Number of signalling points _________________________________________________________________________________________________ Large mean 3 to 3 Large 95 4 _________________________________________________________________________________________________ Large mean 4 to 4 Average-sized 95 5 _________________________________________________________________________________________________ Average-sized mean 5 to 5 Average-sized 95 7 _________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note - See Note 2 to S 3.1. Tableau 1/Q.709 [T1.709], p. The maximum signalling transfer delay under normal conditions for the international component of a connection should not be worse than the values listed in Table 2/Q.709. 3.3 National components of hypothetical signalling refer- ence connection The national components of the hypothetical signalling refer- ence connection includes all national exchanges in the connection (but does not include the international switching centre in the country) and all STPs carrying signalling messages between the national exchanges and between the highest level national exchange and the international switching centre. The maximum number of sig- nalling points and STPs allowed are listed in Table 3/Q.709. H.T. [T2.709] TABLE 2/Q.709 Maximum signalling delays for international component _____________________________________________________________ Delay (Note) (ms) Message type Country size Percent of connections _____________________________________________________________ Large mean 390 600 to Large 95 410 620 _____________________________________________________________ Large mean 520 800 to Average-sized 95 540 820 _____________________________________________________________ Average-sized mean 650 1000 to Average-sized 95 690 1040 _____________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note - Only the mean delay component from Table 4/Q.706, Table 3/Q.725 and Table 1/Q.766 have been used in calculating the delay. Further study is required, e.g. for the mean values as well as the inclusion of overload and/or 95 percentile cases of each component value. Tableau 2/Q.709 [T2.709], p. H.T. [T3.709] TABLE 3/Q.709 Maximum number of signalling points and STPs in national components ___________________________________________________________________________________________________ Country size (Note 1) Percent of connections Number of STPs Number of signalling points ___________________________________________________________________________________________________ mean 3 3 Large 95 4 4 ___________________________________________________________________________________________________ mean 2 2 Average-sized 95 3 3 ___________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - See Note 2 to S 3.1. Note 2 - The values in this Table are provisional. (A higher number of signalling points and/or STPs might be included in a national network, e.g. in the case that a two-level hierarchical signalling network is adopted. This matter is for further study.) Tableau 3/Q.709 [T3.709], p. The unavailability of each of the overall national components of the signalling network should not exceed the following totals per year: - 20 minutes for mean case of average-sized coun- tries, - 30 minutes for 95 percent case of average-sized countries and mean case of large countries, and - 40 minutes for 95 percent case of large coun- tries. Note 1 - Although the signalling component of the interna- tional switching centre in the country was not included in Table 3/Q.709, it is included in the unavailability objectives. Note 2 - The hypothetical signalling reference connection define a unique path through the national and international net- works, therefore when considering the overall unavailability of each national component, no account is taken of any standby path, if provided, in that national network. The values given are based on those for each component route-set as specified in Recommendation Q.706, S 1.1. They are provisional and for further study. The maximum signalling transfer delay under normal conditions for each of the national components of a connection should not be worse than the values listed in Table 4/Q.709. H.T. [T4.709] TABLE 4/Q.709 Maximum signalling delays for each national component ______________________________________________________________________ Delay (Notes 1 and 2) (ms) Message type Country size Percent of connections ______________________________________________________________________ mean 390 600 Large 95 520 800 ______________________________________________________________________ mean 260 400 Average-sized 95 390 600 ______________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - See Note to Table 2/Q.709. Note 2 - The delay does not include any delay for the Interna- tional Switching Centre in the country, which is included in the international component. Tableau 4/Q.709 [T4.709], p. 4 Overall signalling delay for link-by-link signalling From the hypothetical signalling reference connection and the values of message transfer times given for signalling point and STP, the overall signalling delay due to signalling point, and STP delays can be determined from Tables 2 and 4 of this Recommenda- tion, for a given load in a given network. Average delays and 95 percentile delays are given in Table 5/Q.709 for various combi- nations of large and average-sized countries. Average signalling point and STP delays at normal loading are assumed. These values must be increased by the transmission propagation delays (see Table 1/Q.41). H.T. [T5.709] TABLE 5/Q.709 Maximum overall signalling delays _____________________________________________________________ Delay (Note) (ms) Message type Country size Percent of connections _____________________________________________________________ Large mean 1170 1800 to Large 95 1450 2220 _____________________________________________________________ Large mean 1170 1800 to Average-sized 95 1450 2220 _____________________________________________________________ Average mean 1170 1800 to Average-sized 95 1470 2240 _____________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note - See Note to Table 2/Q.709. Tableau 5/Q.709 [T5.709], p. 5 Hypothetical signalling reference connection (HSRC) components for end-to-end signalling 5.1 General The components of a hypothetical signalling reference connec- tion are signalling end points (SEP), signalling points with SCCP relay function (SPR) and STPs which are connected in series by sig- nalling data links to produce an end-to-end signalling connection (Note 1). The number of the various signalling nodes depends on the size of the network. Two limits are prescribed to cover mean or 95% cases. Separate cases are allowed for large countries and average-sized countries (Note 2). This section outlines the con- siderations involved in formulating a hypothetical signalling reference connection and details the number of hypothetical signal- ling reference connection components and the delays they produce. Note 1 - a) Signalling End Point (SEP) - This includes processing in UP/AP (User part/application part), SCCP (Signalling connection control part), MTP (Message transfer part) and also MTP-SCCP-UP/AP b) Signalling Point with SCCP relay function (SPR) - This includes only processing in MTP-SCCP-MTP c) Signalling Transfer Point - This includes pro- cessing in MTP exclusively. Note 2 - When the maximum distance between an international switching centre and a subscriber who can be reached from it does not exceed 1000 km or, exceptionally, 1500 km, and when the country has less than n x 107 subscribers, the country is considered as of average size. A country with a larger distance between an interna- tional switching centre and a subscriber, or with more than n x 107 subscribers is considered as of large size. (The value of n is for further study.) 5.1.1 Number of signalling nodes in the end-to-end HSRC The same signalling network is used for end-to-end messages and link-by-link messages. This means that the maximum number of signalling nodes is equal in both cases. The maximum number of sig- nalling nodes from the originating node to the destination node is 18 in 50 percent of the connections and 23 in 95 percent of the connections except for average-sized to average-sized country. In that case the value is 24. In general a fast transfer of end-to-end signalling messages has to be required. For such messages a route with a minimum number of signalling transfer and relay points is highly desirable. It is desirable to use the message routing of the MTP (STP functions) as far as possible and trying in this way to avoid pro- cessing in higher layers (SCCP or user functions). 5.1.2 Signalling network availability The availability of a signalling connection is an important network parameter. It is necessary for the availability to be sig- nificantly better than the availability of the component being con- trolled (e.g. a circuit). A figure of ten minutes down time per year maximum unavailability is recommended for any particular sig- nalling route set (Recommendation Q.706, S 1.1). This corresponds to an availability of 0.99998, which can be achieved by the use of suitable network redundancies. 5.1.3 Signalling message transfer delay Signalling message transfer delay is another important network parameter. It affects call set up delay and also affects network response time to service requests made during a call. The use of signalling points with SCCP relay functions (SPR) should be kept to a minimum. In an SPR additional processing is performed which causes an additional delay, for example address translation for CR or UDT message types (processing intensive mes- sages) or a local reference message mapping for CC or DT messages (processing simple message types). The cross office transit time for SPR is defined in Q.716. The cross-office transit time for an SEP is equal to Tc\duin Q.766 or Q.725 and for an STP is equal to Tc\ds in Q.706. 5.2 International component of hypothetical signalling reference connection The international component of the hypothetical signalling reference connection includes all international signalling nodes (e.g. SPR and STP) in the connection. The maximum number of SPRs and STPs allowed are listed in Table 6/Q.709. H.T. [T6.709] TABLE 6/Q.709 Maximum number of SPRs and STPs in international component ____________________________________________________________________________ Country size Percent of connections Number of STPs Number of SPRs ____________________________________________________________________________ Large mean 4 2 to Large 95 4 3 ____________________________________________________________________________ Large mean 6 2 to Average-sized 95 6 3 ____________________________________________________________________________ Average-sized mean 8 2 to Average-sized 95 8 4 ____________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 6/Q.709 [T6.709], p. The unavailability of the overall international component of the signalling network should not exceed the following totals per year for both the 50 and 95 percent cases: - 20 minutes for large country to large country; - 30 minutes for large country to average-sized country, and - 40 minutes per year for average-sized country to average-sized country. The maximum delay at the signalling nodes under normal condi- tions for the international component of a connection should not be worse than the values listed in Table 7/Q.709. H.T. [T7.709] TABLE 7/Q.709 Maximum delay at the signalling nodes for international component ___________________________________________________________ Delay (ms) Country size Percent of connections Message type ___________________________________________________________ Large mean 300 440 to Large 95 410 620 ___________________________________________________________ Large mean 340 480 to Average-sized 95 450 660 ___________________________________________________________ Average-sized mean 380 520 to Average-sized 95 600 880 ___________________________________________________________ | | | | | Note 1 - The maximum signalling nodes delay is the sum of all cross-office delays involved. Note 2 - All values are provisional. Tableau 7/Q.709 [T7.709], p. 5.3 National components of hypothetical signalling refer- ence connections The national components of the hypothetical signalling refer- ence connection includes all national signalling nodes (e.g., SEP, SPR, STP) in the connection (but does not include the international switching centre in the country). The maximum number of SEPs, SPRs and STPs allowed are listed in Table 8/Q.709. The unavailability of each of the overall national components of the signalling network should not exceed the following totals per year: - 20 minutes for mean case of average-sized coun- tries; - 30 minutes for 95 percent case of average-sized countries and mean case of large countries, and - 40 minutes for 95 percent case of large coun- tries. H.T. [T8.709] TABLE 8/Q.709 Maximum number of SEPs, SPRs and STPs in national component _______________________________________________________________________________________________ Country size Percent of connections Number of STPs Number of SPRs Number of SEPs _______________________________________________________________________________________________ Large _______________________________________________________________________________________________ Average-sized _______________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 8/Q.709 [T8.709], p. Note 1 - Although the signalling component of the interna- tional switching centre in the country is not included in Table 8/Q.709, it is included in the unavailability objectives. Note 2 - The hypothetical signalling reference connection defines a unique path through the national and international net- works, therefore when considering the overall unavailability of each national component, no account is taken of any standby path, if provided, in that national network. The values given are based on those for each component route-set as specified in Recommendation Q.706, S 1.1. The maximum delay at the signalling nodes under normal condi- tions for each of the national components of a connection should not be worse than the values listed in Table 9/Q.709. H.T. [T9.709] TABLE 9/Q.709 Maximum delay at the signalling nodes for each national component ___________________________________________________________ Delay (ms) Country size Percent of connections Message type ___________________________________________________________ mean 300 440 Large 95 430 640 ___________________________________________________________ mean 260 400 Average-sized 95 300 4 ___________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - The maximum signalling nodes delay is the sum of all cross-office delays involved. Note 2 - All values are provisional. Tableau 9/Q.709 [T9.709], p. 6 Overall signalling delay for end-to-end signalling The link-by-link signalling delay is applicable where messages are processed by each signalling point (e.g. during call establish- ment). The use of end-to-end signalling intended to reduce the overall signalling delay. From the hypothetical signalling reference connection and the values of message transfer times given for SEPs, SPRs and STPs, the overall signalling delay due to the node delays can be determined from Tables 7 and 9 of this Recommendation, for a given load in a given network. Average delays and 95 percentile delays are given in Table 10/Q.709 for various combinations of large and average-sized countries. Average signalling node delays at normal loading are assumed. H.T. [T10.709] TABLE 10/Q.709 Maximum overall delay at the signalling nodes ___________________________________________________________ Delay (ms) Country size Percent of connections Message type ___________________________________________________________ Large mean 900 1320 to Large 95 1270 1900 ___________________________________________________________ Large mean 900 1320 to Average-sized 95 1180 1740 ___________________________________________________________ Average-sized mean 900 1320 to Average-sized 95 1200 1760 ___________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - The maximum signalling nodes delay is the sum of all cross-office delays involved. Note 2 - All values are provisional. Tableau 10/Q.709 [T10.709], p. 7 Remarks 7.1 The above values for signalling delays assumes a message length distribution as given in Table 2/Q.706 and Table 2/Q.725, with a mean message length of 15 octets. However, a message length of e.g. 128 octets for SCCP user data in CR and CC messages and 255 octets for SCCP user data in DT messages are permissible. For such a message length the transmission time at 64 kbit/s is, in each signalling node, about 15 ms (128 octets) to 30 ms (255 octets) longer. 7.2 When defining an overall signalling delay the propagation delay must be included. This delay cannot be completely neglected due to the geographical size of the HSRC (see Table 1/Q.41). MONTAGE: PAGE 368 = BLANCHE SECTION 3 SIMPLIFIED MESSAGE TRANSFER PART Recommendation Q.710 SIMPLIFIED MTP VERSION FOR SMALL SYSTEMS 1 Field of application 1.1 This Recommendation is applicable for systems using a sim- plified MTP version to interface to the public network(s). 1.2 The MTP functions specified in S 3 of this Recommendation may be applied in general for small systems, e.g., PABX's, remote concentrators, etc., interfacing with the message transfer part described in Recommendations Q.702, Q.703, Q.704 and Q.707. 1.3 The Recommendation applies only for digital access arrangements. 1.3.1 In case one channel carries signalling information for more than one multiplex system, at least one additional channel should be pre-assigned as a stand-by signalling link in a multiplex system other than that which contains the active channel. This allows the changeover and changeback procedures specified in SS 3.4.4 and 3.4.5 to be performed. 1.3.2 The stand-by channel(s) should not be used as B-channel(s). 1.4 Only the associated mode of signalling is applicable. 1.5 A variety of information types may be supported by the signalling system, e.g., relating to circuit switched call control and packet communication. 2 Functional content The functional requirements are as follows: 2.1 The network call control functions are as specified in Recommendation Q.930 (I.451). Note - Different network layer protocols (circuit switching and packet switching) may be supported by using the protocol discriminator included in Recommendation Q.930. As an alternative, different network layer entities may access the interface functions directly. In that case, the interface functions will use separate service indicator codes to discriminate the applicable network layer entity. This will be similar to the use of SAPI specified in Recommendation Q.920. Which principle to be applied is determined by the Administration/RPOA. 2.2 The minimum set of Message Transfer Part functions are specified in Recommendations Q.702, Q.703, Q.704 and Q.707, with the qualifications specified in S 3 of this Recommendation. 2.3 The additional interface functions required for the proper operation of the D-channel call control functions in combination with the message transfer part functions, are specified in S 4 of this Recommendation (see Figure 1/Q.710). Figure 1/Q.710, (MC), p. 3 Message Transfer Part (MTP) functions 3.1 General The MTP functions as specified in Recommendations Q.702, Q.703, Q.704 and Q.707 are applicable. However, the following exceptions and modifications to those Recommendations may be applied for the PABX system, see SS 3.2-3.4. In order to prevent fraudulent use of the signalling network, it has to be ensured that no signalling messages generated by a PABX can be routed further than the public exchange to which the PABX has access. The manner in which this is made may be dependent on national circumstances and system implementations. An example of how such a function could be implemented is given in S 3.5. 3.2 Level 1 | (Recommendation Q.702) Only digital signalling data links are relevant. Recommendation Q.702, S 6, is not applicable. 3.3 Level 2 | (Recommendation Q.703) 3.3.1 Initial alignment procedure | (Recommendation Q.703, S 7) In the initial alignment procedure specified in Recommendation Q.703, S 7, only the emergency proving is applica- ble. Thus, in states "aligned" and "proving" of the initial align- ment procedure status indication "N" is not sent. 3.3.2 Processor outage | (Recommendation Q.703, S 8) The processor outage function specified in Recommendation Q.703, S 8, is not applicable. When the level 2 function receives an indication that a pro- cessor outage situation exists at the remote and (through the reception of status signal units indicating processor outage), it transmits status signal units indicating "out of service". 3.3.3 Flow control | (Recommendation Q.703, S 9) The sending of the link status indication "B" from the PABX is not applicable. When the level 2 function of the PABX receives the link status indication "B", no action is taken by the PABX. 3.4 Level 3 | (Recommendation Q.704) 3.4.1 Routing label | (Recommendation Q.704, S 2.2) The signalling link selection (SLS) field defined in S 2.2.4 is always coded 0000. 3.4.2 Message routing function | (Recommendation Q.704, S 2.3) The load sharing function between link sets and within a link set defined in S 2.3.2 is not applicable. 3.4.3 Message discrimination | (Recommendation Q.704, S 2.4) The discrimination function defined in S 2.4.1 is not applica- ble. 3.4.4 Changeover | (Recommendation Q.704, S 5) Changeover between link sets is not applicable. Initiation of changeover at the reception of a changeover order from the remote end of a link is not applicable (c.f. Recommendation Q.704, S 3.2.2). The buffer updating procedure defined in S 5.4 is not applica- ble. At reception of a changeover order (or emergency changeover order) an emergency changeover acknowledgement is sent in response. The message retrieval procedure defined in S 5.5 is not appli- cable. Diversion of traffic is performed at expiry of a time-out T1 (c.f. Recommendation Q.704, S 16.8) is started when the changeover is initiated. 3.4.5 Changeback | Recommendation Q.704, S 6) Changeback between link sets is not applicable. The sequence control procedure defined in S 6.3 is not appli- cable. At reception of a changeback declaration, a changeback ack- nowledgement is sent in response. For the purpose of ensuring message sequence integrity, the time controlled diversion procedure specified in S 6.4 is used. 3.4.6 Forced rerouting | Recommendation Q.704, S 7) Forced rerouting is not applicable. 3.4.7 Controlled rerouting | Recommendation Q.704, S 8) Controlled rerouting is not applicable. 3.4.8 Signalling point restart | Recommendation Q.704, S 9) Signalling point restart is not applicable. 3.4.9 Management inhibiting | Recommendation Q.704, S 10) Management inhibiting is not applicable. 3.4.10 Signalling traffic flow control | Recommendation Q.704, S 11) Signalling route set congestion (Recommendation Q.704, S 11.2.3) is not applicable. MTP User flow control (Recommendation Q.704, S 11.2.7) is not applicable. 3.4.11 Signalling link management | Recommendation Q.704, S 12.2) Only basic link management procedures are applicable. 3.4.12 Link set activation | Recommendation Q.704, S 12.2.4) Link set normal activation defined in S 12.2.4.1 is not appli- cable. Link set emergency restart is used in all cases. 3.4.13 Transfer prohibited | Recommendation Q.704, S 13.2) The transfer prohibited function is not applicable. At the reception of a TFP message, no action should be taken. 3.4.14 Transfer allowed | (Recommendation Q.704, S 13.3) The transfer allowed function is not applicable. At the recep- tion of a TFA-message, no action should be taken. 3.4.15 Transfer restricted | (Recommendation Q.704, S 13.4) The transfer restricted function is not applicable for the PABX. At the reception of the TFR message no action is taken by the PABX. 3.4.16 Signalling-route-set-test | (Recommendation Q.704, S 13.5) The signalling-route-set-test procedure is not applicable. 3.4.17 Transfer controlled | (Recommendation Q.704, SS 13.7, 13.8) The transfer controlled function is not applicable for the PABX. At the reception of the TFC message, no action is taken by PABX. 3.4.18 Signalling route-set-congestion-test | (Recommenda- tion Q.704, S 13.9) The signalling route-set-congestion-test function is not applicable for the PABX. At the reception of signalling-route-set-congestion-test mes- sage no action is taken by the PABX. 3.4.19 Signalling link test | (Recommendation Q.707, S 2.2) The ability to respond to a signalling link test message with a signalling link test acknowledge message must always be provided by the PABX. 3.5 Example of "Screening Function" Note - This paragraph is provided for illustration purposes only. At an exchange (which has the capability of acting as an STP) each message received on a PABX access link is passed through a "screening function" that checks that the DPC of the message is the same as the SP code of the exchange. If that is the case, the mes- sage is sent to the normal MTP message handling functions. Other- wise, the message is discarded. 4 Interface functions 4.1 General The task of the interface functions is to provide the layer-to-layer interfaces according to what is specified in Recommendations Q.920, Q.930 on the one hand and in Recommendation Q.704 on the other, see the Figure 2/Q.710. This will include some conversion functions which are specified in S 4.4. Figure 2/Q.710, (MC), p. 4.2 Interactions with the network layer entity (Q.930) The layer-to-layer interactions between the network layer and the data link layer of the D-channel protocol are specified in Recommendation Q.920, S 4. The interactions are specified in the form of primitives. The primitive applicable for the primary rate interface structure are: DL-DATA-REQUEST/INDICATION The DL-DATA-REQUEST primitive is used to request that a network layer message unit be sent. The DL-DATA-INDICATION indi- cates the arrival of a message unit. 4.3 Interactions with the message transfer part The layer-to-layer interactions between the MTP and the User Parts of Signalling System No. 7 are specified in Recommendations Q.701 and Q.704, Figures 23/Q.704 and 27/Q.704. The following primitives are used: a) MTP-TRANSFER (see Recommendation Q.701, S 8.1), b) MTP-PAUSE (see Recommendation Q.701, S 8.2), c) MTP-RESUME (see Recommendation Q.701, S 8.3). 4.4 Conversion functions The Table 1/Q.710 shows the association between the D-channel primitives and the Signalling System No. 7 interactions. H.T. [T1.710] TABLE 1/Q.710 _________________________________________________ D-channel SS No. 7 _________________________________________________ Information transfer DL-DATA MTP-TRANSFER _________________________________________________ Flow control - - { MTP-PAUSE (STOP) MTP-RESUME (START) } _________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 1/Q.710 [T1.710], p. 4.4.1 Information transfer When receiving a DL-DATA-REQUEST primitive from the network layer entity, the interface entity generates a MTP-TRANSFER Request primitive which contains: - The message unit associated with the primitive. - A label consisting of DPC, OPC and SLS. The label is generated by the interface entity on the basis of information regarding the destination of the message. The SLS is coded 0000. Note - In some implementations where the label is not used for routing purposes, the entire label may be coded "all zeros". - A service information octet (SIO) is generated by the interface entity in accordance with a predetermined rule and, as a national option, on the basis of priority information associ- ated with the primitive. The NI is coded 10 or 11. The SI code is determined by the Administration or RPOA. Note - In the case when the interface functions provide direct access to more than one network layer entity, the SI code will depend on the network layer entity to which the message is associated. When receiving a MTP-TRANSFER Indication from the MTP, the interface entity sends a DL-DATA-INDICATION primitive to the net- work layer entity. 4.4.2 Flow control When receiving a MTP-PAUSE indication from the MTP, the inter- face entity will generate a DL-PAUSE-INDICATION primitive to the network layer entity. When receiving a MTP-RESUME indication from the MTP, the interface entity will generate a DL-RESUME-INDICATION primitive to the network layer entity. Blanc SECTION 4 SIGNALLING CONNECTION CONTROL PART (SCCP) Recommendation Q.711 FUNCTIONAL DESCRIPTION OF THE SIGNALLING CONNECTION CONTROL | PART 1 Introduction 1.1 General The Signalling Connection Control Part (SCCP) provides addi- tional functions to the Message Transfer Part (MTP) to cater for both connectionless as well as connection-oriented network services to transfer circuit related and non-circuit related signalling information and other type of information between exchanges and specialized centres in telecommunication networks (e.g., for management and maintenance purposes) via a Signalling System No. 7 network. A functional block situated above the Message Transfer Part, the latter being described in Recommendations Q.701 through Q.707, performs the functions and procedures of the SCCP. Thus the Message Transfer Part remains unchanged (Figure 1/Q.711). The combination of the MTP and the SCCP is called Network Service Part (NSP). The Network Service Part meets the requirements for Layer 3 services as defined in the OSI-Reference Model, CCITT Recommendation X.200. 1.2 Objectives The overall objectives of the Signalling Connection Control Part are to provide the means for: a) logical signalling connections within the CCITT No. 7 Signalling Network; b) a transfer capability for Signalling Data Units with or without the use of logical signalling connections. Functions of the SCCP are also used for the transfer of cir- cuit related and call related signalling information of the ISDN User Part with or without setup of end-to-end logical signalling connections. These functions are described in Recommendations Q.714 and Q.764. Figure 1/Q.711 illustrates the embedding of the SCCP within the CCITT No. 7 signalling system. 1.3 General characteristic 1.3.1 Technique of description The Signalling Connection Control Part (SCCP) is described in terms of: - services provided by the SCCP, - services assumed from the MTP, - functions of the SCCP. The functions of the SCCP are performed by means of the SCCP-protocol between two systems which provide the NSP-service to the upper layers. The service interfaces to the upper layers and to the MTP are described by means of primitives and parameters, as recommended in CCITT Recommendation X.200. Figure 2/Q.711 illustrates the rela- tionship between the SCCP protocol and the adjacent services. Figure 1/Q.711, (N), p. Figure 2/Q.711, (N), p. 1.3.2 Primitives Primitives consist of commands and their respective responses associated with the services requested of the SCCP and of the MTP, see Figure 3/Q.711. The general syntax of a primitive is specified in Recommendation Q.700. Figure 3/Q.711, (N), p. 1.3.3 Peer-to-peer communication Exchange of information between two peers of the SCCP is per- formed by means of a protocol. The protocol is a set of rules and formats by which the control information (and user data) is exchanged between the two peers. The protocol caters for: - the setup of logical signalling connections, - the release of logical signalling connections, - the transfer of data with or without logical sig- nalling connections. A signalling connection is modelled in the abstract by a pair of queues. The protocol elements are objects on that queue added by the origination SCCP user and removed by the destination SCCP user. Each queue represents a flow control function. Figure 4/Q.711 illustrates the modes described above. (Model for the connection- less service is for further study.) Figure 4/Q.711, (N), p. 1.3.4 Contents of the Recommendations Series Q.71x Recommendation Q.711 contains a general description of the services provided by the MTP, the services provided by the SCCP and the functions within the SCCP. Recommendation Q.712 defines the set of protocol elements and their embedding into messages. Recommendation Q.713 describes the formats and codes used for the SCCP messages. Recommendation Q.714 is a detailed description of the SCCP procedures as a protocol specification. Recommendation Q.716 defines and specifies values for the SCCP performance parameters, including quality of service parameters and internal parameters. 2 Services provided by the SCCP The overall set of services is grouped into: - connection-oriented services, - connectionless services. Four classes of service are provided by the SCCP protocol, two for connectionless services and two for connection-oriented ser- vices. The four classes are: 0 Basic connectionless class 1 Sequenced (MTP) connectionless class 2 Basic connection-oriented class 3 Flow control connection-oriented class 2.1 Connection-oriented services A distinction has to be made between: - temporary signalling connections, - permanent signalling connections. Temporary signalling connection establishment is initiated and controlled by the SCCP user. Temporary signalling connections are comparable with dialled telephone connections. Permanent signalling connections are established and con- trolled by the local (or remote) O&M-function or by the management function of the node and they are provided for the SCCP user on a semipermanent basis. They can be compared with leased telephone lines. 2.1.1 Temporary signalling connections 2.1.1.1 Description The control of a signalling connection is divided into the following phases: - connection establishment phase, - data transfer phase, - connection release phase. 2.1.1.1.1 Connection establishment phase Connection establishment procedures provide the mechanism for establishing temporary signalling connections between users of the SCCP. A signalling connection between two SCCP users may consist of one or more connection sections. During connection establishment, routing functions are pro- vided by the SCCP, in addition to those provided by the MTP. At intermediate nodes, SCCP routing determines whether a sig- nalling connection should be realized by one connection or by several concatenated connection sections. The ISDN UP may provide the routing of the request for the setup of a connection section. The connection refusal procedure is invoked if the SCCP is unable to establish a signalling connection. 2.1.1.1.2 Data transfer phase The data transfer service provides for an exchange of user data, called Network Service Data Units (NSDU), in either direction or in both directions simultaneously on a signalling connection. A SCCP message between two peer consists of: - Network Protocol Control Information (NPCI), - Network Service Data Unit (NSDU). The Network Protocol Control Information supports the joint operating of the SCCP-peer entities within the two nodes communi- cating with each other. It contains a connection reference parame- ter which allocates the message to a certain signalling connection. The Network Service Data Unit contains a certain amount of information from the SCCP user which has to be transferred between two nodes using the service of the SCCP. Network Protocol Control Information and Network Service Data Unit are put together and transferred as a message (Figure 5/Q.711). If the size of user data is too big to be transferred within one message, user data are segmented into a number of portions. Each portion is mapped to a separate message, consisting of the NPCI and a NSDU (Figure 6/Q.711). The data transfer service caters for sequence control and flow control depending on the quality of service required by the SCCP user (two different classes of the connection-oriented service are provided by the protocol; see Recommendation Q.714). Figure 5/Q.711, (N), p. Figure 6/Q.711, (N), p. 2.1.1.1.3 Connection release phase Connection release procedures provide the mechanism for disconnecting temporary signalling connections between users of the SCCP. 2.1.1.2 Network service primitives and parameters 2.1.1.2.1 Overview Table 1/Q.711 gives an overview of the primitives to the upper layers and the corresponding parameters for the (temporary) connec- tion oriented network service. Figure 7/Q.711 shows an overview state transition diagram for the sequence of primitives at a con- nection endpoint, refer to Recommendation X.213, Network Layer Ser- vice Definition of Open Systems Interconnection for CCITT applica- tion. A more detailed description for the primitives and their parameters is given in the following chapters. H.T. [T1.711] TABLE 1/Q.711 Network service primitives for connection-oriented services _____________________________________________________________________ Primitives Generic name Specific name Parameters _____________________________________________________________________ N-CONNECT { Request Indication Response Confirmation } { Called address Calling address Responding address Receipt confirmation selection Expedited data selection Quality of service parameter set User data Connection identification | ua) } _____________________________________________________________________ N-DATA Request Indication { Confirmation request User data Connection identification | ua) } _____________________________________________________________________ N-EXPEDITED DATA Request Indication { User data Connection identification | ua) } _____________________________________________________________________ { N-DATA ACKNOWLEDGE (for further study) } Request Indication { Connection identification | ua) } _____________________________________________________________________ N-DISCONNECT Request Indication { Originator Reason User data Responding address Connection identification | ua) } _____________________________________________________________________ N-RESET { Request Indication Response Confirmation } { Originator Reason Connection identification | ua) } _____________________________________________________________________ | a) In Recommendation X.213, S 5.3, this parameter is implicit. Tableau 1/Q.711 [T1.711], p. 21 Blanc Figure 7/Q.711, (N), p. 22 2.1.1.2.2 Connection establishment phase A SCCP user (calling user) initiates the setup of the connec- tion by means of the primitive "N-CONNECT request" to the SCCP. The SCCP entity evaluates the primitive and adds the protocol control information. The SCCP message (consisting of the protocol control information (PCI) and possibly an NSDU) is transmitted by means of the MTP-services to the remote peer entity of the SCCP. It evalu- ates and strips the PCI and sends a primitive "N-CONNECT indica- tion" to the local SCCP user. On both ends of the connection the status "pending" is assumed. The called SCCP user answers with the primitive "N-CONNECT response" to the local SCCP, which sends the response SCCP message including PCI to the calling SCCP. The calling SCCP sends the prim- itive "N-CONNECT confirmation" to the calling SCCP-User. The con- nection is now ready for data transfer. The four types of N-CONNECT, the request, the indication, the response and the confirmation contain the parameters as shown and further described in Table 2/Q.711. H.T. [T2.711] TABLE 2/Q.711 Parameters of the primitive N-CONNECT _______________________________________________________________________________________________________________________________ Primitive Parameter N-CONNECT request N-CONNECT indication N-CONNECT response N-CONNECT confirmation _______________________________________________________________________________________________________________________________ Called address X X | ud) _______________________________________________________________________________________________________________________________ Calling address X | ud) X _______________________________________________________________________________________________________________________________ Responding address X X _______________________________________________________________________________________________________________________________ { Receipt confirmation selection | ua) } X X X X _______________________________________________________________________________________________________________________________ Expedited data selection X X X X _______________________________________________________________________________________________________________________________ { Quality of service parameter set } X X X X _______________________________________________________________________________________________________________________________ User data | ub) X X X X _______________________________________________________________________________________________________________________________ { Connection identification | uc) } X X X X _______________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | X Parameter present within the primitive. a) Parameter conditionally present. b) User data within the connection primitives are defined as a pro- vider option (refer to CCITT Recommendatiom X.213). c) This parameter is not in Recommendation X.213 and is for further study. d) This parameter may be implicitly associated with the SCCP ser- vice access point at which this primitive is issued. Tableau 2/Q.711 [T2.711], p. The parameters "Called address/Calling address" convey addresses identifying the destination/source of a communication. There are three types of addresses: Global Title, Subsystem Number, Signalling Point Code. The Global Title is an address such as dialled digits which does not explicitly contain information that would allow routing in the signalling network, i.e., a translation function is required. The Subsystem Number is an identification of a specific user func- tion within a certain signalling point (SP), like the ISDN-User Part, the SCCP-Management, etc. The parameter "Responding address" indicates to which destina- tion the connection has been established or refused. The "Responding address" parameter in the N-CONNECT primitive conveys the address of the service access point to which the sig- nalling connection has been established. Under certain cir- cumstances (e.g. call redirection, generic addressing, etc.), the value of this parameter may be different from the "Called address" in the corresponding N-CONNECT request. Such facilities that cause the difference are for further study. The "Responding address" parameter is present in the N-DISCONNECT primitive only in the case where the primitive is used to indicate rejection of a signalling connection establishment attempt by an SCCP user function. The parameter conveys the address of the service access point from which the N-DISCONNECT-request was issued and under circumstances like that mentioned above the "Responding address" may be different from the "Called address" in the corresponding N-CONNECT request primitive. The parameter "Receipt confirmation selection" indicates the use/availability of the receipt confirmation service. The need for such a service is for further study. The parameter "Expedited data selection" may be used to indi- cate during setup whether expedited data can be transferred via the connection. A negotiation will be performed between SCCP users, local and remote. The Quality of Service parameters are used during call setup to negotiate the protocol class for the connection and, if applica- ble, the flow control window size. The N-CONNECT primitives may or may not contain user data. The parameter "Connection identification" is used to allocate a primitive to a certain connection. In principle, the connection establishment has to be completed (i.e., data transfer status has to be reached) before sending or receiving data messages. If data messages arrive at the calling user before the connection establishment is finished these data messages are discarded. In addition, user data can also be transferred to/from the SCCP within the primitives N-CONNECT and N-DISCONNECT. 2.1.1.2.3 Data transfer phase During this phase four different primitives may occur: a) N-DATA (Table 3/Q.711), b) N-EXPEDITED DATA (Table 4/Q.711), c) N-DATA ACKNOWLEDGE, d) N-RESET (Table 5/Q.711). The primitive " N-DATA " (Table 3/Q.711) exists only as a "request", i.e. from the SCCP user to the local SCCP and as an "indication" at the remote end of the connection, i.e., from the SCCP to the local SCCP user. N-DATA can occur bidirectionally, i.e., from the calling as well as the called user of the SCCP-connection. The parameter "Confirmation request" is used in an N-DATA primitive to indicate the need to confirm the receipt of the N-DATA primitive by the remote SCCP user. The confirmation may be given by the N-DATA ACKNOWLEDGE primitive. Receipt confirmation is provided only on connections which get the Receipt Confirmation facility during setup. The matter is for further study. The primitive " N-EXPEDITED DATA " (Table 4/Q.711) may be used by the SCCP user only, if the signalling connection is set up according to a class providing the capability to transfer expedited data (refer to Recommendation Q.714). H.T. [T3.711] _______________________________________________________________________ TABLE 3/Q.711 { Parameters of the primitive N-DATA } Primitive Parameter N-DATA request N-DATA indication _______________________________________________________________________ { Confirmation request | ua) } X X _______________________________________________________________________ User data X X _______________________________________________________________________ { Connection identification | ub) } X X _______________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | X Parameter present within the primitive. a) Parameter conditionally present. b) This parameter is for further study. Tableau 3/Q.711 [T3.711], p. 24 H.T. [T4.711] ________________________________________________________________________________ TABLE 4/Q.711 { Parameters of the primitive N-EXPEDITED DATA } Primitive N-EXPEDITED DATA request { Parameter ________________________________________________________________________________ User data X X ________________________________________________________________________________ { Connection identification | ua) } X X ________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | X Parameter present within the primitive. a) This parameter is for further study. Tableau 4/Q.711 [T4.711], p. 25 Blanc The primitive "N-DATA ACKNOWLEDGE" is used when the delivery confirmation service is selected. This primitive is for further study. The primitive N-RESET (Table 5/Q.711) can occur in the data transfer state of a connection with a protocol class including flow control. N-RESET overrides all other activities and causes the SCCP to start a re-initialization procedure for sequence numbering. N-RESET appears as a request, an indication, a response and a con- firmation. After reception of a N-RESET request and before the sending of a N-RESET confirmation, all NSDUs from SCCP are dis- carded by th SCCP. H.T. [T5.711] TABLE 5/Q.711 Parameters of the primitive N-RESET ______________________________________________________________________________________________________________________ Primitive Parameter N-RESET request N-RESET indication N-RESET response N-RESET confirmation ______________________________________________________________________________________________________________________ Originator X ______________________________________________________________________________________________________________________ Reason X X ______________________________________________________________________________________________________________________ { Connection identification | ua) } X X X X ______________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | X Parameter present within the primitive. a) This parameter is for further study. Tableau 5/Q.711 [T5.711], p. The parameter "Originator" indicates the source of the reset and can be any of the following: the "network service provider" (network originated), the "network service user" (user originated), or "undefined". The parameter "Reason" indicates "network service provider congestion", "reason unspecified" or "local SCCP ori- ginated" for a network originated reset, and indicates "user syn- chronization" for a user originated reset. The "Reason" parameter is "undefined" when the "Originator" parameter is "undefined". 2.1.1.2.4 Release phase The primitives for the release phase are N-DISCONNECT request and N-DISCONNECT indication. These primitives are also used for the connection refusal during connection establishment phase. Parame- ters are included to notify the reason for connection release/refusal and the initiator of the connection release/refusal procedure. User data may be also be included (see Table 6/Q.711). The parameter "Originator" indicates the initiator of the con- nection release or the connection refusal. It may assume the fol- lowing values: - the network service provider, - the network service user, - undefined. H.T. [T6.711] _________________________________________________________________________________________ TABLE 6/Q.711 { Parameters of the primitive N-DISCONNECT } Primitive Parameter N-DISCONNECT request N-DISCONNECT indication _________________________________________________________________________________________ Originator X _________________________________________________________________________________________ Responding address X X _________________________________________________________________________________________ Reason X X _________________________________________________________________________________________ User data X X _________________________________________________________________________________________ { Connection identification | ua) } X X _________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | X Parameter present within the primitive. a) This parameter is for further study. Tableau 6/Q.711 [T6.711], p. The parameter "Reason" gives information about the cause of the connection release or the connection refusal. It may assume any of the following values in accordance with the value of the "Origi- nator": These values may be used locally at the originating/initiating node as an implementation option. It is noted that the term "connection rejection" is used in Recom- mendation X.213 for the "Reason" parameter values. 1) When the "Originator" parameter indicates the "network service provider": - disconnection - abnormal condition of non-transient nature; - disconnection - abnormal condition of transient nature; - disconnection - invalid state ; - disconnection - release in progress ; - connection refusal - destination address unknown (non-transient condition) ; - connection refusal - destination inaccessible/non-transient condition ; - connection refusal - destination inaccessible/transient condition ; - connection refusal - QOS not available/non-transient condition ; - connection refusal - QOS not available/transient condition ; - connection refusal - reason unspecified/non-transient condition ; - connection refusal - reason unspecified/transient condition ; - connection refusal - local error ; - connection refusal - invalid state ; - connection refusal - no translation ; - connection refusal - in restart phase 2) When the "Originator" parameter indicates the "network service user": - disconnection - normal condition; - disconnection - abnormal condition; - disconnection - end user congestion; - disconnection - end user failure; - disconnection - SCCP user originated; - disconnection - access congestion; - disconnection - access failure; - disconnection - subsystem congestion; - connection refusal - non-transient condition; - connection refusal - transient condition; - connection refusal - incompatible information in NSDUs; - connection refusal - end user originated; - connection refusal - end user congestion; - connection refusal - end user failure; - connection refusal - SCCP user originated; - connection refusal - access congestion; - connection refusal - access failure; - connection refusal - subsystem congestion. 3) When the "Originator" parameter is "undefined", then the "Reason" parameter is also "undefined". Note - Addition to, or refinement of, this list of possible values for the parameter "Reason" to convey more specific diagnos- tic, cause and management information is for further study. 2.1.1.3 Additional SCCP primitive and interface elements In addition to those primitives in Recommendation X.213, there is a primitive N-INFORM needed by the SCCP connection-oriented ser- vices during data transfer phase. There are also three interface elements used by User Part Type A, e.g. ISDN-UP, as in Figure 1/Q.711. 2.1.1.3.1 Notice service The provision of the notice service by use of the "N-INFORM" primitive is for further study. The primitive N-INFORM (Table 7/Q.711) is used during data transfer to convey relevant network/user information. The primitive "N-INFORM" will contain the parameters "Reason', "Connection Iden- tification" and "QOS parameter set". The primitive "N-INFORM request" is provided to inform the SCCP of the connection user failure/congestion, or anticipated QOS changes. A further primitive "N-INFORM indication" is provided to indicate actual failures of the SCCP to the SCCP-user functions or anticipated quality of service changes or other indications to the SCCP-user functions. The parameter "Reason" contains the network/user information to be conveyed. It may assume the following values: - network service provider failure; - network service congestion; - network service provider QOS change; - network service user failure; - network service user congestion; - network service user QOS change; - reason unspecified. H.T. [T7.711] ______________________________________________________________________________ TABLE 7/Q.711 { Parameters of the primitive N-INFORM } Primitive Parameter N-INFORM request N-INFORM indication ______________________________________________________________________________ Reason X X ______________________________________________________________________________ { Connection identification | ua) } X X ______________________________________________________________________________ QOS parameter set | ua) X X ______________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | X Parameter present within the primitive. a) Parameter is for further study. Tableau 7/Q.711 [T7.711], p. 2.1.1.3.2 Connection establishment interface elements For the User Part Type A in Figure 1/Q.711, two mechanisms are available to set up a signalling connection. For example, the ISDN-User Part may use the mechanism described in S 2.1.1.2.2 or may request the SCCP to initiate a connection and return the infor- mation to the ISDN-User Part for transmission within an ISDN-User-Part call setup message, like an Initial Address Message (IAM). Three interface elements are defined for the information flow between SCCP and ISDN-User Part: a) REQUEST to the SCCP, Type 1 and Type 2; b) REPLY from the SCCP. The REQUEST Type 1 contains the following parameters: - connection identification (for further study); - receipt confirmation selection; - expedited data selection; - quality of service parameter set. The REQUEST Type 2 contains the following parameters: - protocol class; - credit; - connection identification (for further study); - source local reference; - originating signalling point code; - reply request; - refusal indicator. The REPLY contains the following parameters: - source local reference; - protocol class; - credit; - connection identification (for further study). 2.1.2 Permanent signalling connections 2.1.2.1 Description The setup/release service is controlled by the Administration (e.g. O&M application). The functions for setup and release may be similar to those provided for temporary signalling connections and are for further study. The classes of service are the same. Permanently established signalling connections may require additional safeguarding mechanisms within the endpoints (relay- points) of the connection in order to guarantee their re-establishment in case of a processor outage followed by a recovery. 2.1.2.2 Primitives and parameters The primitives and their parameters are listed in Table 8/Q.711. Their content and functionality correspond to the description within S 2.1.1.2.3. H.T. [T8.711] TABLE 8/Q.711 Primitives for the data transfer on permanent connections ____________________________________________________________________ Primitives Generic Name Specific Name Parameters ____________________________________________________________________ N-DATA Request Indication { Confirmation request User data Connection identification | ua) } ____________________________________________________________________ N-EXPEDITED DATA Request Indication { User data Connection identification | ua) } ____________________________________________________________________ { N-DATA ACKNOWLEDGE (for further study) } Request Indication { Connection identification | ua) } ____________________________________________________________________ N-RESET { Request Indication Response Confirmation } { Originator Reason Connection identification | ua) } ____________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a) Parameter is for further study. Tableau 8/Q.711 [T8.711], p. 2.2 Connectionless services The SCCP provides the SCCP user with the ability to transfer signalling messages via the signalling network without setup of a signalling connection. In addition to the MTP capability, a "Rout- ing" function has to be provided within the SCCP, which maps the called address to the Signalling Point Codes of the MTP Service. This mapping function may be provided within each node or might be distributed over the network or could be provided in some special translation centres. Under certain conditions of congestion and unavailability of subsystems and/or signalling points, connectionless messages could be discarded instead of being delivered. If the SCCP user wishes to be informed of the non-delivery of messages, the Return Option parameter must be set to "return message on error" in the primitive to the SCCP. 2.2.1 Description There are two possibilities to transfer data without a connec- tion setup with regard to the sequence control mechanisms provided by the MTP. a) The MTP guarantees (to a high degree of proba- bility) an in-sequence delivery of messages which contain the same Signalling Link Selection (SLS) code. The SCCP user can demand this MTP service by allocating a parameter "Sequence control" into the primitive to the SCCP. The SCCP will put the same SLS code into the primitive to the MTP for all primitives from the SCCP user with the same "Sequence control" parameter. b) If the in-sequence delivery is not required, the SCCP can insert SLS codes randomly or with respect to appropriate load sharing within the signalling network. The rules to achieve load sharing are not defined in the SCCP Recommendations. 2.2.2 Primitives and parameters of the connectionless ser- vice 2.2.2.1 Overview Table 9/Q.711 gives an overview of the primitives to the upper layers and the corresponding parameters for the connectionless ser- vice. H.T. [T9.711] TABLE 9/Q.711 Primitives and parameters of the connectionless service ___________________________________________________________ Primitives Generic Name Specific Name Parameters ___________________________________________________________ N-UNITDATA Request Indication { Called address Calling address Sequence control | ua) Return option | ua) User data } ___________________________________________________________ N-NOTICE Indication { Called address Calling address Reason for return User data } ___________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a) An integration of the parameter Sequence control/Return option into the Quality of Service parameter set is for further study. Tableau 9/Q.711 [T9.711], p. 2.2.2.2 Parameters 2.2.2.2.1 Address The parameters "Called address" and "Calling address" serve to identify the destination and origination respectively, of the con- nectionless message. These parameters may contain some combination of global titles, subsystem numbers, and signalling point codes. 2.2.2.2.2 Sequence control The parameter "Sequence control" indicates to the SCCP whether the user wishes the service "sequence guaranteed" or the service "sequence not guaranteed". In the case of "sequence guaranteed" service, this parameter is an indication to the SCCP that a given stream of messages with the same called address has to be delivered in sequence by making use of the features of the MTP. In addition, this parameter is also used to distinguish different streams of messages so that the SCCP can allocate SLS codes appropriately to help the MTP in achieving an even distribution of signalling traffic. 2.2.2.2.3 Return option The parameter "Return option" is used to determine the han- dling of messages encountering transport problems. "Return option" may assume the following values: - discard message on error; - return message on error. 2.2.2.2.4 Reason for return The parameter "Reason for return" identifies the reason why a message was not able to be delivered to its final destination. "Reason for return" may assume the following values: - no translation for an address of such nature; - no translation for this specific address; - subsystem configuration; - subsystem failure; - unequipped user; - network congestion; - network failure. 2.2.2.2.5 User data The parameter "User data" is information which is to be transferred transparently between SCCP users. 2.2.2.3 Primitives 2.2.2.3.1 UNITDATA The "N-UNITDATA request" primitive is the means by which a SCCP user requests the SCCP to transport data to another user. The "N-UNITDATA indication" primitive informs a user that data is being delivered to it from the SCCP. Table 10/Q.711 indicates the parameters of the primitive N-UNITDATA 2.2.2.3.2 NOTICE The "N-NOTICE indication" primitive is the means by which the SCCP returns to the originating user a message which could not reach the final destination. Table 11/Q.711 indicates the parameters of the primitive N-NOTICE H.T. [T10.711] TABLE 10/Q.711 Parameters of the primitive N-UNITDATA _______________________________________________________________________ Primitive Parameter N-UNITDATA request N-UNITDATA indication _______________________________________________________________________ Called address X X _______________________________________________________________________ Calling address X X _______________________________________________________________________ Sequence control | ua) X _______________________________________________________________________ Return option X _______________________________________________________________________ User data X X _______________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a) The inclusion of this parameter in the N-UNITDATA indication primitive is for further study. Tableau 10/Q.711 [T10.711], p. H.T. [T11.711] TABLE 11/Q.711 Parameters of the primitive N-NOTICE __________________________________________ Primitive Parameter N-NOTICE indication __________________________________________ Called address X __________________________________________ Calling address X __________________________________________ Reason for return X __________________________________________ User data X __________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 11/Q.711 [T11.711], p. 2.3 SCCP management 2.3.1 Description The SCCP provides SCCP management procedures (see Recommendation Q.714, S 5) to maintain network performances by rerouting or throttling traffic in the event of failure or conges- tion in the network. These SCCP management procedures apply to both the connection-oriented and the connectionless services of the SCCP. 2.3.2 Primitives and parameters of the SCCP management 2.3.2.1 Overview Table 12/Q.711 gives an overview of the primitives to the upper layers and the corresponding parameters for the SCCP manage- ment. H.T. [T12.711] TABLE 12/Q.711 Primitives and parameters of the SCCP management __________________________________________________________________________________________________________________________ Primitives Generic Name Specific Name Parameters __________________________________________________________________________________________________________________________ R-COORD { Request Indication Response Confirmation } { Affected subsystem Subsystem multiplicity indicator } __________________________________________________________________________________________________________________________ N-STATE Request Indication { Affected subsystem User status Subsystem multiplicity indicator } __________________________________________________________________________________________________________________________ N-PCSTATE Indication { Affected DPC Signalling Point Status H.T. [T13.711] } __________________________________________________________________________________________________________________________ TABLE 13/Q.711 { Parameters of the primitive N-COORD } | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Primitive Parameter N-COORD request N-COORD indication N-COORD response N-COORD confirmation __________________________________________________________________________________________________________________________ Affected subsystem X X X X __________________________________________________________________________________________________________________________ { Subsystem multiplicity indicator } X X __________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 12/Q.711 [T12.711], p. 2.3.2.2 Parameters 2.3.2.2.1 Address See S 2.2.2.2.1. 2.3.2.2.2 Affected subsystem The parameter "Affected subsystem" identifies a user which is failed, withdrawn, congested, or allowed. The "Affected subsystem" parameter contains the same type of information as the "Called address" and "Calling address". 2.3.2.2.3 User status The parameter "User status" is used to inform a SCCP user of the status of the affected subsystem. "User status" may assume one of the following values: - User-in-service (UIS); - User-out-of-service (UOS). 2.3.2.2.4 Subsystem multiplicity indicator The parameter "Subsystem multiplicity indicator" identifies the number of replications of a subsystem. 2.3.2.2.5 Affected DPC The parameter "Affected DPC" identifies a signalling point which is failed, congested, or allowed. The "Affected DPC" parame- ter contains unique identification of a signalling point. 2.3.2.2.6 Signalling point status The parameter "Signalling point status" is used to inform a user of the status of an affected DPC. "Signalling point status" may assume the following values: - Signalling point inaccessible, - Signalling point congested, - Signalling point accessible. 2.3.2.3 Primitives 2.3.2.3.1 COORD The "N-COORD" primitive (Table 13/Q.711) is used by replicated subsystems to coordinate the withdrawal of one of the subsystems. The primitive exists as: a "request" when the originating user is requesting permission to go out of service; an "indication" when the request to go out of service is delivered to the originator's replicate; a "response" when the originator's replicate announced it has sufficient resources to let the originator go out of ser- vice; and as a "confirmation" when the originator is informed that it may go out of service. H.T. [T13.711] TABLE 13/Q.711 Parameters of the primitive N-COORD _______________________________________________________________________________________________________________________ Primitive Parameter N-COORD request N-COORD indication N-COORD response N-COORD confirmation _______________________________________________________________________________________________________________________ Affected subsystem X X X X _______________________________________________________________________________________________________________________ { Subsystem multiplicity indicator } X X _______________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 13/Q.711 [T13.711], p. 2.3.2.3.2 STATE The " N-STATE request" primitive (Table 14/Q.711) is used to inform the SCCP management about the status of the originating user. The "N-STATE indication" primitive is used to inform an SCCP user accordingly. H.T. [T14.711] TABLE 14/Q.711 Parameters of the primitive N-STATE ___________________________________________________________________________ Primitive Parameter N-STATE request N-STATE indication ___________________________________________________________________________ Affected subsystem X X ___________________________________________________________________________ User status X X ___________________________________________________________________________ { Subsystem multiplicity indicator } X ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 14/Q.711 [T14.711], p. 2.3.2.3.3 PCSTATE The " N-PCSTATE primitive " (Table 15/Q.711) is used to inform a user about the status of a signalling point. H.T. [T15.711] TABLE 15/Q.711 Parameters of the primitive N-PCSTATE _________________________________________________ Primitive Parameter N-PCSTATE indication _________________________________________________ Affectedd DPC X _________________________________________________ Signalling Point Status X _________________________________________________ | | | | | | | | | | | | | | | | | | | | | Tableau 15/Q.711 [T15.711], p. 3 Services assumed from the MTP 3.1 Description This paragraph describes the functional interface offered by the MTP to the upper layer functions, i.e., the SCCP and the User Parts. In order to align the terminology with the OSI-Model, the description uses the terms "primitives" and "parameters". 3.2 Primitives and parameters The primitives and parameters are shown in Table 16/Q.711. H.T. [T16.711] TABLE 16/Q.711 Message transfer part service primitives _____________________________________________________________________ Primitives Generic Name Specific Name Parameters _____________________________________________________________________ MTP-TRANSFER Request Indication OPC DPC SLS SIO User Data _____________________________________________________________________ MTP-PAUSE (Stop) Indication Affected DPC _____________________________________________________________________ MTP-RESUME (Start) Indication Affected DPC _____________________________________________________________________ MTP-STATUS Indication { Affected DPC Cause | ua) } _____________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a) The cause parameter has, at present, two values: i i) Signalling network congested (level) This level value is applicable if national option with congestion priorities and multiple signalling link states without congestion priorities as in Recommendation Q.704 is implemented. ii) Remote user unavailable. Tableau 16/Q.711 [T16.711], p. 3.2.1 TRANSFER The primitive "MTP-TRANSFER" is used between level 4 and level 3 (SMH) to provide the MTP message transfer service. 3.2.2 PAUSE The primitive "MTP-PAUSE" indicates to the SCCP total inabil- ity of providing the MTP service to the specified destination. This primitive corresponds to the destination inaccessible state as defined in Recommendation Q.704. 3.2.3 RESUME The primitive "MTP-RESUME" indicates to the SCCP total ability of providing the MTP service to the specified destination. This primitive corresponds to the destination accessible state as defined in Recommendation Q.704. 3.2.4 STATUS The primitive "MTP-STATUS" indicates to the SCCP partial ina- bility of providing the MTP service to the specified destination, or the unavailability of the remote peer user. The response of the SCCP for the latter case is for further study. In the case of national option with congestion priorities and multiple signalling link congestion states without priorities as in Recommendation Q.704 is implemented, this "MTP-STATUS" primitive is also used to indicate a change of congestion level. This primitive corresponds to the destination congested state as defined in Recommendation Q.704. 4 Functions provided by the SCCP This section is an overview of the functional blocks within the SCCP. 4.1 Connection-oriented functions 4.1.1 Functions for temporary signalling connections 4.1.1.1 Connection establishment functions The connection establishment service primitives defined in S 2 are used to set up a signalling connection. The main functions of the connection establishment phase are listed below: - Setup of a signalling connection; - Establish the optimum size of NPDUs (Network Pro- tocol Data Unit); - Map network address onto signalling relations; - Select functions operational during data transfer phase (for instance, layer service selection); - Provide means to distinguish network connections; - Transport user data (within the request). 4.1.1.2 Data transfer phase function The data transfer phase functions provide means for a two-way simultaneous transport of messages between the two endpoints of the signalling connection. The main functions of the data transfer phase as listed below are used or not used in accordance with the result of the selection performed in the connection establishment phase. - Segmenting/reassembling, - Flow control, - Connection identification, - NSDU delimiting (M-Bit), - Expedited data, - Missequence detection, - Reset, - Receipt confirmation , - Others. 4.1.1.3 Release phase functions These functions provide disconnection of the signalling con- nection, regardless of the current phase of the connection. The release may be performed by an upper layer stimulus or by mainte- nance of the SCCP itself. The release can start at each end of the connection (symmetrical procedure). The main function of the release phase is the disconnection. 4.1.2 Functions for permanent signalling connections 4.1.2.1 Connection establishment phase and connection release phase functions _________________________ The need for this functions is for further study. The setup and release for permanent signalling connections are for further study. The stimuli for setup and release of permanent connections are originated from the Administration function. 4.1.2.2 Data transfer phase functions The functions for the data transfer on permanent signalling connections correspond to that for temporary connections. Differ- ences may exist regarding the quality of service. This matter is for further study. 4.2 Connectionless service functions The functions of the connectionless service are listed below: - mapping the network address to signalling rela- tions, - sequence service classification. 4.3 Management functions | (for further study) The SCCP provides functions which manage the status of the SCCP subsystems. These functions allow other nodes in the network to be informed of the change in status of SCCP subsystems at a node, and to modify SCCP translation data if appropriate. Subsystem congestion management is for further study. Functions are also provided to allow a coordinated change of status of replicated SCCP subsystems. At present, this allows a replicated subsystem to be withdrawn from service. When a subsystem is out of service, SCCP test functions are activated at nodes receiving unavailability information. At periodic intervals the status of the unavailable subsystem is checked by a SCCP management procedure. Broadcast functions within SCCP management broadcast subsystem status changes to nodes within the network which have an immediate need to be informed of a particular signalling point/subsystem status change. Notification functions to local subsystems within the node (local broadcast) are also provided. 4.4 Routing and translation functions (for further study) The SCCP routing provides a powerful address translation func- tion, which is asked for connectionless and connection-oriented service. Detailed description of the SCCP routing function can be found in Recommendation Q.714, SS 2.2 and 2.3. The basic translation function performed by the SCCP is to transfer the SCCP address parameter from a global title to a point code and a subsystem number. Other translation results are also possible. The global title form of the address could typically be dialed digits (e.g. a Freephone (800) number). Several standardized CCITT numbering plans may be supported by SCCP; details are given in Recommendation Q.713, S 3.4. The address translation capabilities of the SCCP in relation to handling OSI Network Service Access Points (NSAP) are for further study. ANNEX A (to Recommendation Q.711) OSI network layer conformance The following information should be taken into account when reading Recommendation Q.711 in relation to the provision of an OSI network layer service. All references to connectionless classes 0 and 1 are not included in Recommendation X.200. S 2.1.1 The Connection identification parameters in the following primitives are implicit in Recommendation X.213: N-CONNECT N-DATA N-EXPEDITED DATA N-DATA ACKNOWLEDGE N-DISCONNECT N-RESET The N-INFORM primitive does not exist within Recommendation X.213. The connection establishment interface elements described in S 2.1.1.3.2 is not required to support an OSI network layer ser- vice. S 2.1.2 Permanent connection services are not defined in Recommendation X.200 and are not required to support an OSI network layer service. The service is offered by the SCCP for specific No. 7 applications. S 2.2 Connectionless network service is still under study in Study Group VII and is not defined in Recommendation X.213. S 2.3 This section on SCCP management is not defined in Recommendation X.213 and none of the primitives exist in OSI. APPENDIX (to Recommendation Q.711) Unresolved issues in SCCP Recommendations This appendix lists the topics in SCCP on which study is con- tinuing in the next study period. It is not an exhaustive list, but does indicate where the Recommendations might change. In these areas, RPOAs may need to supplement the Recommendations, but in such a way as not to conflict with ongoing work; implementors should consider likely future developments and, where possible, design to accommodate these. The topics under study are listed below; the references are to the Blue Book. 1) Inter-nodal communication model with SCCP con- nectionless service (S 1.3.3, Rec. Q.711); 2) Delivery confirmation service (N-DATA ACK- NOWLEDGE primitive) (Table 1/Q.711); 3) Transitions caused by N-DATA ACK primitive (Figure 7/Q.711); 4) Facilities causing differences in the called and responding addresses in N-CONNECT request and response (S 2.1.1.2.2, Rec. Q.711); 5) The need for Receipt Confirmation Service in SCCP (SS 2.1.1.2.2 and 4.1.1.2, Rec. Q.711); 6) Connection identification parameter inclusion in Request types 1 and 2, and reply primitives between SCCP and ISUP (S 2.1.1.3.2, Rec. Q.711); 7) Connection identification parameter inclusion in N-CONNECT, N-DATA, N-EXPEDITED DATA, N-RESET, and N-DISCONNECT primitives (Tables 2/Q.711, 3/Q.711, 4/Q.711, 5/Q.711, 6/Q.711, 7/Q.711, 8/Q.711); 8) The list of release reason parameter values (S 2.1.1.2, Rec. Q.711); 9) QOS parameter set inclusion in N-INFORM (Table 7/Q.711); 10) Setup and release functions for permanent sig- nalling connections (S 2.1.2.1, Rec. Q.711); 11) Integrating sequence control and return option parameters in the QOS set (Table 9/Q.711); 12) Sequence control parameter inclusion in the N-UNITDATA indication primitive (Table 10/Q.711); 13) SCCP response to MTP-STATUS (S 3.2.4, Rec. Q.711); 14) Difference in QOS between permanent and tem- porary signalling connections (S 4.1.2.2, Rec. Q.711); 15) SCCP management procedures for subsystem congestion (S 4.3, Rec. Q.711; SS 3.11, 3.12, 3.15, Rec. Q.713; SS 5.1, 5.3, Rec. Q.714); 16) SCCP capabilities in OSI NSAP address transla- tion (S 4.4, Rec. Q.711); 17) Possible need for diagnostic parameter (S 2.6, Rec. Q.712); 18) Constraints on order of optional parameter transmission (S 1.8, Rec. Q.713); 19) Destination local reference coded as all ones (S 3.2, Rec. Q.713); 20) Source local reference coded as all ones (S 3.3, Rec. Q.713); 21) Alignment with X.96 call progress information (SS 3.11, 3.15, Rec. Q.713); 22) Inclusion of routing failure causes as for return cause in Recommendation Q.713, S 3.12 (S 3.15, Rec. Q.713); 23) Data parameter maximum length for Unitdata | nd Unitdata Service | messages (SS 4.10, 4.11, Rec. Q.713; SS 1.1.2, 4, Rec. Q.714); 24) Need for Released message | cause value 1110 "not obtainable" (Annex A, Rec. Q.713); 25) Need for Reset Request | message cause value 1011 "not obtainable" (Annex A, Rec. Q.713); 26) Notification regarding unrecognized messages/parameters (S 1.14, Rec. Q.714); 27) Classification of SCCP routing failure causes (S 2.4, Rec. Q.714); 28) Management procedures for non-dominant mode nodes/subsystems with more than one backup (S 5.1, Rec. Q.714); 29) Receipt from a local originating subsystem of a message for a prohibited subsystem (S 5.3.2.1, Rec. Q.714); 30) Possible introduction of a subsystem out of service denial message (S 5.3.5.3, Rec. Q.711); 31) Mathematical analysis of SCCP performance; 32) Recommendation Q.716 parameter valus (S 3, Rec. Q.716).