5i' Recommendation I.333 TERMINAL SELECTION IN ISDN (Melbourne, 1988) 1 Introduction This Recommendation defines "terminal selection" as the pro- cedures carried out between a terminating ISDN exchange and ISDN terminal equipment situated behind an ISDN interface leading to customer premises whereby terminal response equivalent to answer or rejection is solicited. The procedures apply to both point-to-point and point-to-multipoint terminal operations. Note that in case of an existing terminal (TE2) connected via a terminal adaptor (TA) to an ISDN access, the combination of TA and TE2 is seen as to provide the same functionality as a TE1. As there should be no modifications to the existing terminal, the functions described are provided by the terminal adaptor. Note - In the context of this Recommendation "terminal" is an abstract term and does not constrain the implementation of physical terminals which may consist of one or more logical terminals. 1.1 Terminal selection responsibilities The network responsibility is to deliver a call to the inter- face identified by the called number using connection types con- sistent with the service requested by the calling party. It is the responsibility of the called party to arrange the terminals on the interface so that incoming calls properly originated are accepted only by the appropriate terminal(s). The network may provide addi- tional functions to aid in the completion of calls from dedicated networks. The network may provide additional services to ensure that calls are completed only to terminals consistent with informa- tion provided by the caller. It is the responsibility of the termi- nal manufacturer and/or service provider to provide terminals that use the terminal selection data in a way that is consistent with the intended application of the terminal, (e.g. for telematic ter- minals according to Recommendation T.90). The calling party agrees, when placing a call, to accept the terminating capabilities provided by the called party. The ter- minating exchange has a cooperative role with the terminal in establishing an information transfer which lends itself to the required terminal selection needs for a given interface. 1.2 Identification requirements An ISDN number identifies any of the interfaces at reference point S (Recommendation I.330, S 2.1). Additional identifiers or terminal selection functions are therefore needed in those cases where the number is insufficient to make needed distinctions among terminals. This Recommendation addresses the general principles to be applied in identifying: 1) specific individual terminals or 2) groups of terminals among which no further dis- tinction is required by the terminating user. Specific sequences in which identifying information is applied are not specified. 1.3 General operations While specific selection sequences for the application of ter- minal identifiers are not required, the ISDN number is a fundamen- tal discriminator. The whole network - including the terminating exchange - relies heavily on this resource. The bearer capability must also be given a high status since its transfer across the interface is mandatory with every call request. Other information potentially useful in the selection process is given in S 4. An originator of a call is generally not required to provide any of the other information in every call. Exceptions for telematic ter- minals are listed in Recommendation T.90. If terminal selection is to be successful in establishing a connection between the calling and the called terminal in a prescribed manner, the calling terminal should conform to the rea- sonable expectations of the called subscriber's terminal arrange- ment. A calling subscriber who does not conform to the expectations of the called subscriber's terminal arrangement is inviting an irregularity. The terminating subscriber has a corresponding obli- gation to provide a means for needed discrimination among termi- nals. It should be noted that information expected at a called subscriber's terminal configuration may not, in all cases, be pro- vided by the calling subscriber, (for example, interworking with a non-ISDN). The point-to-multipoint operation tends to be emphasized in subsequent text because distinctions in this mode of operation require some terminal selection functions. Nevertheless, the treat- ment of both point-to-point and point-to-multipoint selection pro- cedures are considered appropriate for this Recommendation. The terminal selection stage is said to be completed when an individual terminal reacts and is awarded the call. In the case of NT2, the call award need not come as a direct result of the point-to-point procedure but may come later from a terminal attached to the NT2. The details regarding the processing of this information by the terminating exchange and the sequence used in offering this information to the user-network interface may be a matter of formal agreement between the subscriber and the Administration at the time of service provisioning. The call set-up and terminal selection procedures in ISDN require that the terminating exchange and the terminals play cooperative roles. 2 Objective 2.1 The primary objective of this Recommendation is to provide overall principles on terminal selection in ISDN. This Recommenda- tion therefore provides a framework within which Administrations may choose appropriate terminal selection procedures, to suit their own operating environment and applications. 2.2 The guidelines contained in the appendices do not represent requirements on terminals for terminal selection func- tionality, but represent terminal selection techniques that are useful in appropriate circumstances. Possible choices are contained in appendices. However, other Recommendations, e.g. Recommendation T.90 have also to be taken into account. 3 Scope 3.1 It is recognized that call set-up is an end-to-end process requiring appropriate switching, signalling and terminal func- tionality at both ends. However, the frame of reference used in this Recommendation is mainly the terminating ISDN exchange and the terminal configuration(s) served by that exchange. The originating exchange and the terminal configuration(s) served by that exchange are covered only if a specific request for a terminal function at the calling side, supporting the terminal selection procedure at the called side, is identified. 3.2 It is also recognized that calls originating from existing dedicated networks with limited addressing and signalling capabili- ties will not be able to avail themselves of the full range of ter- minal identification functions. This Recommendation therefore addresses the terminal selection for the following types of calls: - calls within the ISDN: i) selection based on network assisted capabilities (e.g. see Appendices II and III); ii) selection based on end-to-end user capability (e.g. see Appendices I and II); - calls from public dedicated networks to ISDN. Note - Calls from private networks to ISDN are not currently addressed in this Recommendation. 3.3 This Recommendation addresses terminal selection in ISDN for both basic and primary rate access. 3.4 Though selection of a specific terminal in a multipoint configuration in ISDN for maintenance and operation purposes may be a requirement, this Recommendation does not currently address this application. 3.5 This Recommendation is related to and/or is compatible with the following Recommendations: - Recommendations of the I.200-Series on ISDN ser- vices; - Recommendation I.330: ISDN numbering and address- ing principles; - Recommendation I.331 (E.164): Numbering plan for the ISDN era; - Recommendations I.410, I.411, I.412: ISDN user-network interfaces; - Recommendation I.441 (Q.921): ISDN user-network interfaces: layer 2 specifications; - Recommendation I.451 (Q.931): ISDN user-network interfaces: layer 3 specifications; - Recommendations of the I.500-Series defining interworking between various networks; - Recommendation Q.932, Annex A: Generic procedures for the control of ISDN supplementary services - User service pro- files and terminal identification; - Recommendation T.90: Characteristics and proto- cols for terminals for telematic services in ISDN. 4 Terminal selection functions 4.1 Any information which categorizes attributes of an incom- ing call may be used for the terminal selection process (some information given hereafter is service oriented and some is termi- nal oriented): 1) an ISDN number; 2) bearer capability; 3) other low layer functionality; 4) higher layer functionality; 5) direct dialling-in (DDI) number, multiple sub- scriber number, or subaddress; 6) ISDN/non-ISDN call source indicator; 7) local exchange functionality. In a point-to-multipoint configuration, call set-up informa- tion from the terminating ISDN exchange to the terminal configura- tion is transferred via broadcast procedures. All active terminals receive attribute values and determine whether or not to respond. In the case of more than one terminal supporting the same ser- vice, the supplementary service Multiple Subscriber Number (MSN) (Note 1) or Direct Dialling-In (DDI) (Note 2) may be used to iden- tify a specific terminal. To support these services the terminal must be able to recognize its own identity based typically on a number of digits, which consist of the whole, or a part of the Sub- scriber Number (SN) in the ISDN numbering plan. Alternatively, S 4.3 may apply. This principle applies for both a homogeneous ISDN environment and for interworking cases with non-ISDN. In a homogeneous ISDN environment the subaddressing function (Note 3) may be used alter- natively. However, it cannot be used in all cases of interworking. Note 1 - Based on the use of distinct ISDN numbers, the mul- tiple subscriber number supplementary service enables specific terminal(s), connected to the basic access in a point-to-multipoint configuration, to be indicated by the called party number. Note 2 - Based on the use of distinct ISDN numbers, the direct dialling-in supplementary service enables a user to estab- lish a connection to another user or an ISPBX, or other private system without attendant intervention. Note 3 - Based on an extension of the addressing capability beyond the E.164 (I.331) numbering plan, subaddressing enables the calling user to select a specific terminal at the called user's termination and/or to invoke a specific process in the called ter- minal at the called user's termination. 4.2 The terminal selection function in S 4.1 is currently sup- ported by Recommendation Q.931 (I.451) call set-up protocols, Q.932 and Q.921 as follows: 1) called party number information element; 2) bearer capability information element; 3) low layer compatibility information element; 4) High Layer Compatibility (HLC) information ele- ment; 5) called party number/subaddress information ele- ment; 6) progress indicator information element; 7) End point Identifier (EID) information element (see Q.932, Annex A); 8) Terminal End point Identifier (TEI) (see Q.921, S 3.3.4). 4.3 It is recognized that a local procedure, between the ISDN exchange and terminal, may be provided to allow the exchange to assign a particular terminal with network parameters (e.g. logical terminal profile). This identification mechanism will assist the exchange in providing additional terminal selection or service features (see Appendix III). 5 Terminal selection 5.1 Calls within ISDN(s) 5.1.1 Terminal selection functions These are described in S 4. 5.1.2 Processing of selection functions In the terminating exchange, the called subscriber number and the bearer capability are checked. If any form of subscriber pro- file exists for the interface, it may also be consulted. a) For point-to-point applications Proceed to establish the connection according to sub- scriber requirements; for an NT2 transfer all appropriate informa- tion. b) For point-to-multipoint applications (broadcast) i) As information is broadcast from the terminating exchange to the terminal configuration, each active terminal receives the presented information to identify the requested ser- vice, as described in S 4.1 ii) Each active terminal which wishes to be awarded the call will inform the network. The network will award the call to the first terminal equipment which requests connection. When supporting multiple types of terminals, e.g. telematic and telephone terminals, on a point-to-multipoint confi- guration, improper call handling will occur if inappropriate termi- nals request connection of the call. Appendices I, II and III pro- vide possible solutions to these problems. e.g. solutions specifi- cally aimed at telematic terminals are included in Appendix I. The development of terminal configurations in addition to those described in the appendices which will operate successfully in specific circumstances (e.g. select a specific terminal from among several for services, supplementary services, maintenance operations, etc.) are for further study. Provision of guidance to terminal manufacturers, ISDN subscribers, and network operators about how terminals might respond in such circumstances, requires further study. 5.1.3 Terminal differentiation The terminating party is expected to arrange available termi- nals to facilitate access. Distinctions may be drawn, for example, by taking notice in a terminal of the presence or absence (not the content) of a subaddress (see also S 4.2). Calls interworking from PSTN (bearer capability 3.1 kHz audio), for example, could be accepted by terminals sensing no subaddress, while allowing more capable terminals to bid for calls with the same bearer capability and subaddress as well. 5.2 Calls from PSTN to ISDN A call originated in the PSTN, supported by conventional sig- nalling prior to arrival at the ISDN interworking point, will belong to one of two indistinguishable call types, i.e. ordinary speech or voiceband data. At the interworking point the bearer capability "3.1 kHz audio" will be assigned to assure compatibility with these call types. A progress indicator is also applied to mark a non-ISDN call source. Some PSTN customers, however, will be served from ISDN-capable exchanges and calls will be supported by common channel signalling for the entire connection. This affords some added opportunities to make distinctions. The extent to which this should be recommended is for further study. Those cases where the bearer capability "3.1 kHz audio" does not apply (such as digital data service based on digital PSTNs) require further study, based on Recommendation I.231, and Recommendation I.515. 5.3 Calls from PSPDN to ISDN A call originated in the PSPDN will carry either a circuit or a packet bearer capability when presented to an ISDN terminal (case A or B according to Recommendation X.31). Terminal selection procedures in these cases are for further study. 5.4 Calls from CSPDN to ISDN A call originated in the CSPDN will carry a circuit bearer capability and indicate the kind of bitrate adaption used when presented to an ISDN terminal configuration. If the CSPDN is used to offer a teleservice, e.g. Teletex in some countries, the inter- working point may not be able to provide this information to ISDN. Therefore, a distinction between a circuit mode data call and a Teletex call may not be possible and again the only basic principle which allows individual distinction between terminals is the sup- plementary service multiple subscriber number. APPENDIX I (to Recommendation I.333) Examples of terminal selection for general purpose terminals I.1 Scope The aim of this Appendix is to describe terminal selection functions for general purpose terminals which allow operation when multiple terminals supporting a variety of services (including telematic services) are in a point-to-multipoint configuration (S/T bus), and the full complement of terminal selection functions (including HLC information element) have to be invoked for success- ful terminal selection. Terminals which comply with the clauses below do not impose any constraints on terminal configurations with respect to existing recommendations dealing with telematic services. Application of the terminal selection guidelines contained in this Appendix is described in S I.3. I.2 Terminal functions To meet the requirements mentioned in the scope of this Appen- dix, the following functions shall be provided by terminals con- nected to an ISDN. The functions are grouped into those which shall be provided as a minimum for offering an adequate quality of ser- vice and into those which may be implemented additionally. Note - The processing of information at the called side can be executed in the order appropriate to a particular customer installation. The order chosen in this Recommendation is for description and does not impose any constraints on implementations. I.2.1 Terminals supporting bearer services I.2.1.1 Minimum functions I.2.1.1.1 For outgoing calls, generation of information defining the service and address information, i.e. bearer capability and called address. I.2.1.1.2 For incoming calls, analysis of whether a bearer service is requested (not a teleservice). If a higher layer protocol (repesenting a specific teleservice) is requested, the terminal shall ignore the call. This function may be provided by the simple determination of the existence of higher layer protocol information received with the incoming call message. I.2.1.1.3 For incoming calls, analysis of the individual bearer service requested. This function is obtained by the analysis of the bearer capability information received with the incoming call mes- sage. I.2.1.1.4 For incoming calls, analysis of multiple subscriber number information, if provided. A call shall only be answered if the requested multiple subscriber number matches the identity assigned to the terminal. Terminals which do not support the multiple subscriber number supplementary service, shall at least detect the presence of this information. If present, such terminals shall not answer the call. Terminals supporting the multiple subscriber number supplemen- tary service must analyze this information and will only answer the call if the received information matches the pre-assigned identity or if there is a global call. I.2.1.1.5 For incoming calls, analysis of subaddress information. A call shall only be answered if the requested subaddress matches the one assigned to the terminal. Terminals which do not support the subaddressing mechanism, shall at least detect the presence of this information. If present, such terminals shall not answer the call. Terminals supporting the subaddressing mechanism must analyze this information and will only answer the call if the received information matches the pre-assigned information. Terminals with subaddress capability shall not reject calls on the absence of subaddress information. I.2.1.1.6 Terminals supporting more than one bearer service must apply rules of SS I.2.1.1.1, I.2.1.1.2 and I.2.1.1.3 individually. The assignment of a multiple subscriber number or a subaddress may be common for all bearer services. I.2.1.2 Optional functions I.2.1.2.1 Terminals supporting the multiple subscriber number sup- plementary service may be pre-assigned more than one number and will therefore answer incoming calls which match one of the pre-assigned identities or which have a global identity (global call) (see Note). I.2.1.2.2 Terminals supporting the subaddressing mechanism may be pre-assigned more than one subaddress and will therefore answer incoming calls which match one of the pre-assigned subaddress or which have no subaddress ( global call ). Note - An incoming call is global if there is no information contained in the call set-up message to relate the call to sub-set of the terminal population based on terminal identity (information on terminal identity is conveyed in the called party number infor- mation element). The term " global identity " is used to reflect the global relationship with respect to terminal identity, and suitable coding methods are: - to omit the called party number information ele- ment; - to define a specific called party number as a global number (see also Recommendation Q.931). I.2.2 Terminals supporting teleservices I.2.2.1 Minimum functions I.2.2.1.1 For outgoing calls, generation of information defining the service and address information, i.e. bearer capability, higher layer protocol information specifying the requested teleservice and called address. I.2.2.1.2 For incoming calls, analysis of whether a teleservice is requested (and not a bearer service), i.e. if high layer protocol information (representing a specific teleservice) is not requested, the terminal shall ignore the call. This function may be provided by the simple determination of the exitence of high layer protocol information received with the incoming call message. As high layer compatibility (HLC) information may not be provided in the case of interworking with a non-ISDN, its absence should not be used as a reason for rejecting the call (see S I.2.3.1). I.2.2.1.3 For incoming calls, analysis of the individual teleser- vice requested. This function is obtained by the analysis of the bearer capability information and the high layer protocol informa- tion received with the incoming call message. I.2.2.1.4 For incoming calls, analysis of multiple subscriber number information. A call shall only be answered if the requested multiple subscriber number matches the identity assigned to the terminal. Terminals which do not support the multiple subscriber number supplementary service, shall at least detect the presence of this information. If present, such terminals shall not answer the call. Terminals supporting the multiple subscriber number supplemen- tary service must analyze this information and will only answer the call if the received information matches the pre-assigned identity or if there is a global call. I.2.2.1.5 For incoming calls, analysis of subaddress information. A call shall only be answered if the requested subaddress matches the one assigned to the terminal. Terminals which do not support the subaddressing mechanism shall at least detect the presence of this information. If present, such terminals shall not answer the call. Terminals supporting the subaddressing mechanism must analyze this information and will only answer the call if the received information matches the pre-assigned information. Terminals with subaddress capability shall not reject calls on the absence of subaddress information. I.2.2.1.6 Terminals supporting more than one teleservice must apply rules of SS I.2.2.1.1, I.2.2.1.2 and I.2.2.1.3 individually. The assignment of a multiple subscriber number or a subaddress may be common for all teleservices. I.2.2.2 Optional functions I.2.2.2.1 Terminals supporting the multiple subscriber number sup- plementary service may be pre-assigned more than one number and will therefore answer incoming calls which match one of the pre-assigned identities or which have a global identity (global call). I.2.2.2.2 Terminals supporting the subaddressing mechanism may be pre-assigned more than one subaddress and will therefore answer incoming calls which match one of the pre-assigned subaddress or which have no subaddress (global call). I.2.3 Terminals interworking with dedicated networks I.2.3.1 General For calls from the ISDN to a dedicated network the interworking function has to make provision that only calls which can be handled by the dedicated network are forwarded. For calls originated in the dedicated network the interworking function may be unable to provide all elements exactly specifying the service requested according to the rules for a call within the ISDN. For example a call from the telephone network may be a request for telephony, for facsimile or for modem-based data transmission and is presented to the ISDN as a request for the 3.1 kHz audio bearer service. In the case of interworking with a dedicated network, appropriate information is generated by the interworking function (progress indicator). The presence/absence of this information should be used as a criterion for different treatment of a call depending on whether the call originated within ISDN or within a dedicated network. I.2.3.1.1 Calls from PSTN to ISDN A PSTN call, supported by conventional signalling prior to arrival at an ISDN interworking point, will belong to one of two indistinguishable call types, i.e. ordinary speech of voiceband data, of which the latter includes facsimile and modem-based data. At the interworking point the bearer capability "3.1 kHz audio" is routinely assigned to assure compatibility with any of these call types. A "progress indicator" is also applied to mark a non-ISDN call source. Some PSTN customers, however, will be served from ISDN-capable exchanges and calls will be supported by common chan- nel signalling for the entire connection. This affords some added opportunities to make distinctions between the call types. The extent to which this should be recommended is for further study. I.2.3.1.2 Calls from PSPDN to ISDN (See S 5.3 of this Recommendation.) I.2.3.1.3 Calls from PSPDN to ISDN (See S 5.4 of this Recommendation.) I.2.3.1.4 Calls from networks referred to as digital PSTNs, pre-ISDNs, pilot ISDNs or extended IDNs to ISDNs Calls providing a 64 kbit/s transfer rate transparently from one of the above-mentioned networks to an ISDN terminal configuration are not yet finally defined. The 64 kbit/s unres- tricted bearer service will be used, but in any case there is an interworking taking place. A progress indicator is present, indi- cating a non-ISDN call source. Specific high or low layer func- tionality information cannot, however, be guaranteed. Therefore, the only basic principle which allows distinction between indivi- dual terminals is the supplementary service multiple subscriber number. I.2.3.2 Telephone terminals in ISDN Telephone terminals have certain particular characteristics which have to be taken into account. With these terminals, compati- bility checking will be aided by the HLC. Details are for further study. In the case of absence of HLC information, telephone termi- nals may be considered in a similar manner as terminals supporting bearer services described in S I.2.1 above - even if telephony is a teleservice. Telephone terminals must interwork with the existing analogue telephone network. For incoming calls they must therefore accept not only the bearer capability "speech", which occurs in calls within ISDN, but also the bearer capability "3,1 kHz audio", which is the bearer capability in case of interworking with the analogue telephone network and which is accompanied with call progress information indicating the interworking case. I.2.3.3 Facsimile terminals in ISDN A facsimile terminal on ISDN may have the capability to sup- port both Group 2/3 mode and Group 4 mode (Group 3/Group 4 machine), Group 2/3 mode only (Group 3 machine) or Group 4 mode only (Group 4 machine). In order to cater for the case where calls are incoming from networks not able to convey HLC information (e.g. PSTN, switched 64 kbit/s, non-ISDN networks) it must be possible for a facsimile terminal to accept calls without the provision of an HLC informa- tion element. This may involve subscription to the Multiple Sub- scriber Number (MSN) supplementary service, in order to substitute the missing HLC information element. Moreover, for successful call establishment the facsimile terminal has to support the bearer ser- vice offered by the interworking function and the mode requested by the calling facsimile terminal. Similar problems may occur for facsimile calls within the ISDN, if a Group 3 machine in combination with a terminal adaptor (TA) function is connected to the ISDN. It is obvious that a Group 4 machine and a Group 3 machine are unable to communicate, whatever the network configuration is, when interworking with a dedicated network or TA. However, a Group 3/Group 4 machine is able to communicate to a facsimile machine connected to a dedicated network (this is a Group 3 machine in the case of PSTN, and a Group 4 machine in the case of switched 64 kbit/s, non-ISDN Networks) or connected to the ISDN by means of a TA function. Appendix IV describes the circumstances and capabil- ities of facsimile terminals for the interworking situations iden- tified above. I.2.3.4 Data terminals in ISDN Data terminals in ISDN may interwork with compatible data ter- minals in a dedicated data network or in the telephone network. For outgoing calls, the terminal has to operate as described in S I.2.1 above and it selects the proper bearer capability according to the service request. For incoming calls, a data terminal shall function as described for terminals supporting bearer services in S I.2.1 above. In case of interworking with the telephone network it has to accept calls indicating the bearer capability 3.1 kHz audio which is accompanied with the call progress information. Automatic answering data terminals connected to the ISDN and interworking with the telephone network or with the CSPDN shall support the multiple subscriber number supplementary service, because this is the only safeguard to avoid that a data terminal will capture each incoming telephone call, facsimile call from the PSTN or possibly each teletex call from the CSPDN. I.3 Applications Terminals (or terminal adaptors) that follow these terminal selection guidelines can be used on the same point-to-multipoint configuration with terminals of different functionality (e.g. Telefax, Teletex), but following the same terminal selection guidelines, thereby allowing incoming calls to be selected by the appropriate terminal. The inclusion on a point-to-multipoint confi- guration of terminals not following these guidelines may result in the mishandling of some calls. Since the application of the terminal selection guidelines is not mandatory for ISDN terminals, it is essential to ensure that the terminals used on each multipoint interface are compatible among themselves for terminal selection. APPENDIX II (to Recommendation I.333) Examples of terminal selection in illustrative configurations II.1 Scope This appendix describes arrangements indicating some methods which could be used in terminal selection. The different terminal capabilities described in the arrangements are for illustration only. It is the responsibility of the terminal provider to provide terminals with capabilities appropriate to the intended use of the terminal. It is the responsibility of the called party to arrange the terminals on the interface so that incoming calls are handled according to the desires of the called party. Each illustration indicates likely circumstances for use, and the potential impact of using the terminals on a point-to-multipoint configuration with terminals having different terminal selection functionality. Other terminal selection arrange- ments may be useful for certain circumstances. Since the application of the terminal selection guidelines is not mandatory for ISDN terminals, it is essential that the termi- nals used on each multipoint interface are compatible among them- selves for terminal selection. II.2 Limited functionality speech terminal II.2.1 Configuration An example of a simple terminal configuration is illustrated in Figure II-1/I.333. The multiple terminal configuration example consists of up to eight voice terminals without terminal selection logic. Figure II-1/I.333, p. II.2.2 Terminals and network capabilities Calls are delivered to the interface on the basis of an ISDN subscriber number (ISDN-SN). The terminals respond to the call offered on the basis of presumed eligibility to complete the call. II.2.3 Offered call treatment A terminal will respond to a set-up message regardless of other terminal selection information (e.g. LLC) present in the set-up message. More than one terminal may answer the offered call, but the network awards the call to the first terminal from which it receives an answer (connect) indication. II.2.4 Application This type of terminals is appropriate for subscribers who wish only to receive speech calls and who are not concerned with which terminal answers the call. The use of this type of terminal on a point-to-multipoint configuration with terminals designed for any- thing other than speech calls will result in the mishandling of some calls. II.3 Terminal selected by end point identifier (EID) or subaddress II.3.1 Configuration - Multiple terminals with the same subscriber number. - Distinction among the terminals is obtained using the EID or the subaddress (see Figure II-2/I.333). Figure II-2/I.333, p. II.3.2 Terminals and network capabilities The network may deliver the call using terminal identification procedures based on the end point identifier (EID). The terminal may respond to the set-up message based on terminal identification procedures (e.g. use of the EID as defined in Recommendation Q.932 or subaddressing). II.3.3 Offered call treatment The network provides a set-up message with terminal selection information that uniquely identifies a terminal. The terminal iden- tification procedures based on EID or subaddressing schemes will identify a particular terminal and this terminal will respond according to the call or service offered. II.3.4 Application The EID is provided by the network to identify a specific ter- minal. The network may make use of a User Service Profile together with terminal selection data to select the EID. In other applica- tions, particularly those involving data terminals, each terminal may be assigned a subaddress and would respond only to calls containing that subaddress. II.4 Multiple different terminals on a passive bus II.4.1 Configuration This example considers a speech terminal, a terminal adaptor for analogue interface, and a terminal adaptor for digital inter- face connected on a passive bus. The interface has been assigned three numbers that can be used (by non-ISDN customers) to indicate the terminal they wish to access. The arrangement is shown in Figure II-3/I.333. Figure II-3/I.333, p. II.4.2 Terminals and network capabilities In this example, the terminals are connected to an interface that has been assigned three numbers. Any of the three numbers may be used from another ISDN for any service supported by the sub- scribers' terminals. For callers from networks that cannot indicate directly the service required (PSTNs, CSPDNs, and PSPDNs), the first number "201-555-1111" is intended for speech services. The second number, "201-555-2222" is intended for modem data services. The third number, "201-555-3333" is intended for access to the ter- minal adaptor for digital interface. Terminal selection based on the ISDN subscriber number, bearer capability, and progress indicators is used to identify one (or none) of the three terminals that is appropriate to respond to an offered call. II.4.3 Offered call treatment II.4.3.1 Speech terminal (see Figure II-4/I.333) Offered call bearer capability - "Speech": The terminal responds to the call. Offered call bearer capability - "3.1 kHz audio": 1) Progress indicator - non-ISDN: i) Called number - 201-555-1111: The terminal responds to the call ii) Other called numbers: The terminal does not respond. 2) No progress indicator - ISDN origination and transit: The terminal assumes that the call is a data call and does not respond. Offered call with other bearer capabilities: the terminal does not respond. Figure II-4/I.333, p. II.4.3.2 TA for analogue interface/video display terminal The terminal adaptor contains a codec that produces an analo- gue signal that is connected to a modem; the modem has a V-Series interface to the Video Display Terminal (VDT). The logic is shown in Figure II-5/I.333. Offered call bearer capability - "3.1 kHz audio": 1) Progress indicator - non-ISDN: i) Called number - 201-555-2222: The terminal adaptor assumes that the call is a data call and responds. The call is connected to the video display terminal through a modem. ii) Other called number: The terminal adaptor does not respond. 2) No progress indicator - ISDN origination and transit: The terminal adaptor responds. It assumes that, since the call originated at an ISDN terminal, the call is a data call regardless of the called number. Offered call with other bearer capabilities: the terminal adaptor does not respond. Figure II-5/I.333, p. II.4.3.3 TA for digital interface/video display terminal The terminal adaptor adapts the V-Series interface to the interface at reference point S of ISDN. The adaptation includes rate adapting the 9600 bit/s rate of the display terminal to the 64 kbit/s rate of a B-channel. The logic for the digital terminal adaptor is shown in Figure II-6/I.333. For non-ISDN calls, it is assumed that the call is routed through an interworking function that establishes a bearer capabil- ity of 64 kbit/s for the call. Offered call bearer capability - "64 kbit/s unrestricted": 1) Progress indicator - non-ISDN: i) Called number - 201-555-3333: The switch routes the connection through an interworking unit (e.g. a modem). The terminal adaptor for digital interface/display terminal answers the call. ii) Other called numbers: The terminal adaptor does not respond. 2) No progress indicator - ISDN origination and transit: The terminal adaptor responds. It assumes that, since the call originated at an ISDN terminal, the call is a data call regardless of the called number. Figure II-6/I.333, p. II.4.4 Application This example of multiple different terminals on a passive bus illustrates the terminal selection logic that allows the appropri- ate terminal, from among a speech terminal, a terminal adaptor for analogue interface, and a terminal adaptor for digital interface, to respond to an incoming call. Calls from a non-ISDN network are selected on the basis of the called ISDN number; calls from an ISDN subscriber are selected on the basis of the bearer capability. The addition to the interface of other terminals with different functionality but using the same bearer capability would result in incorrect terminal selection. APPENDIX III (to Recommendation I.333) Examples of terminal selection using local terminal selection procedures This appendix describes the concept of a logical terminal and its application in assisting the network to provide services to the access through local terminal identification mechanisms. III.1 Logical terminals There may exist up to 8 physical terminals on an S/T bus. Within each physical terminal there may exist one or more logical terminals (as shown in Figure III-1/I.333). A logical terminal is considered to be the exchange's view of the physical terminal(s) on an interface. The parameters which are maintained by the exchange, which describe the logical terminal characteristics, are collec- tively termed to be the Logical Terminal Profile (LTP). The LTP may contain such information as subscriber numbers, bearer capabilities supported, services subscribed to, or other information which the exchange may require to successfully offer service to the terminals on the interface. A physical terminal can appear (to the network) to be several logical terminals by using several unique TEIs (see Note), each of which may map into a single LTP. The relationship of logical terminals to LTPs may be one-to-one or many-to-one. The relationship between physical terminals, logical terminals. TEIs and LTPs is illustrated in Figure III-2/I.333). Note - The terminal end point identifier (TEI) is part of the D-channel layer 2 address field [see Recommendation Q.921 (I.441)]. Eight logical terminals (the inner boxes, labeled LT1 to LT8) are shown in a total of four physical terminals (the outer boxes, labeled PT1 to PT4). Each logical terminal corresponds to one TEI. This arrangement reflects a customer subscribing to the multiple subscriber number (MSN) supplementary service. Figure III-1/I.333, p. Figure III-2/I.333, p. III.2 Application It is considered that the subscriber may want the exchange to provide terminal selection functions for his terminals. A local terminal selection procedure will accommodate this. In addition, future services may be facilitated which could require special call treatment based on knowledge of the terminal(s) maintained in an LTP and identified using a local procedure. In the context of terminating calls, when an exchange receives digits of a subscriber number (SN) for a call to a terminal on a subscriber line, it would search for the LTP(s) associated with the SN. It would then formulate network-layer call control messages to alert these terminals based on the descriptions associated with the LTP. The Q.932 procedure is used to allow association of a TEI with an LTP. The procedures used for all establishment comply with Recommendation Q.931 (I.451). APPENDIX IV (to Recommendation I.333) Facsimile terminals in ISDN IV.1 Outgoing calls In accordance with S I.2.2.1.1 a G3/G4 (Group3/Group/4) machine or a G4 machine attempting a G4 call shall use the bearer capability according to the capabilities of the network, which may be either "circuit-mode 64 kbit/s unrestricted 8 kHz structured" (category I.231.1) or "virtual call" (category I.232.1), or both of them, and provide the HLC information element with high layer characteristics identification "facsimile group 4". In accordance with S I.2.2.1.1 a Terminal Adaptor (TA) sup- porting a G3 machine shall use the 3.1 kHz audio bearer capability and shall provide the HLC information element with high layer characteristics identification "facsimile group 3". The actions to be taken by the calling facsimile terminal fol- lowing an unsuccessful call attempt where incompatibility has been indicated (e.g. cause "incompatible destination" for calls within the ISDN, or call rejection with a suitable cause indication in the case of interworking with a dedicated network) require further study. The optimum condition to achieve compatibility in a call re-attempt greatly depends on the cause indication provided to the calling facsimile terminal and its capability to divert to the requested characteristics for the call re-attempt. For a certain type of facsimile terminal these actions may include: i) A G3 machine shall release the call and take no further action. ii) A G4 machine shall release the call. The G4 machine may initiate a call re-attempt, if a mismatch of the bearer capability has been indicated and it can match the requested characteristics, e.g. in the case where the "virtual call" (category I.232.1) bearer capability has been requested by the calling facsimile terminal and interworking with switched 64 kbit/s non-ISDN network takes place. Otherwise it can- not take further actions and is unable to communicate with the called facsimile terminal. iii) A G3/G4 machine shall release the call. If interworking ISDN to PSTN has been indicated, or cause "incompatible destination" for calls within the ISDN, when the call has been rejected, the G3/G4 machine may initiate a re-attempt in the G3 mode. It shall use the 3.1 kHz audio bearer capability and shall provide the HLC information element with high layer charac- teristics identification "facsimile group 3". If interworking ISDN, to switched 64 kbit/s non-ISDN net- work, has been indicated when the call has been rejected, actions according to item ii) may be appropriate. IV.2 Incoming calls For incoming calls originated within ISDN, the facsimile ter- minal shall function as described for terminals supporting teleser- vices in S I.2.2. For incoming calls from non-ISDN networks such as the tele- phone network (PSTN), the facsimile terminal will receive the appropriate information indicating an interworking situation (call progress information). It shall rely on the call progress informa- tion element to accept calls which are offered without information specifying high layer protocols, if it matches other elements describing the incoming call. Otherwise it shall release or ignore the call (user options). Facsimile terminals connected to the ISDN and interworking with non-ISDN networks must support the supplementary service Multiple Subscriber Number. This supplementary service allows to substitute the missing information describing the call and is the only means to avoid having a facsimile terminal accept calls which are not appropriate to it, e.g. incoming call from non-ISDN net- works such as telephone calls or data calls. The rules below are applicable to a certain type of facsimile terminal. They define the criteria which should be used by the ter- minal to determine whether, and in what mode it should answer the call: i) A TA supporting a G3 machine should answer the call if the following criteria are fulfilled: a) The called party number information element, if present, contains a number which matches the number assigned to the TA; and b) the bearer capability information element indi- cates the information transfer capability "3.1 kHz audio"; and c1) the progress indicator information element indicates the progress description "call is not end-to-end ISDN" (incoming call from PSTN);and d1) the high layer compatibility information ele- ment is not present; and e1) the called party subaddress information element is not present; or (instead of c1, d1, e1) c2) the progress indicator information element is not present (incoming call from ISDN); and d2) the high layer compatibility information ele- ment indicates high layer characteristics identification "facsimile group 3"; and e2) the called party subaddress information ele- ment, if present, contains a number which matches the subaddress assigned to the terminal. ii) A G3/G4 machine should answer the call in the G3 mode (including modem and codec functions) if the following cri- teria are fulfilled (incoming call from PSTN); a) The called party number information element, if present, contains a number which matches the number assigned to the terminal; and b) the bearer capability information element indi- cates the information transfer capability "3.1 kHz audio"; and c) the progress indicator information element indicates the progress description "call is not end-to-end ISDN"; and d) the high layer compatibility information element is not present; and e) the called party subaddress information element is not present. iii) A G3/G4 machine (or a G4 machine) should answer the call in the G4 mode (neither modem nor codec functions) if the following criteria are fulfilled (incoming call from switched 64 kbit/s network (non-ISDN); a) The called party number information element, if present, contains a number which matches the number assigned to the terminal; and b) the bearer capability information element indicates the information transfer capability "unrestricted digital information" and transfer mode "circuit mode"; and c) the progress indicator information element indicates the progress description "call is not end-to-end ISDN"; and d) the high layer compatibility information element is not present; and e) the called party subaddress information element is not present. iv) A G3/G4 machine (or a G4 machine) should answer the call in the G4 mode (neither modem nor codec functions) if the following criteria are fulfilled (incoming call from ISDN); a) The called party number information element, if present, contains a number which matches the number assigned to the terminal; and b) the bearer capability information element indi- cates the information transfer capability "unrestricted digital information" and a transfer mode which is supported by the called facsimile terminal ("circuit mode" or "packet mode"); and c) the progress indicator information element is not present; and d) the high layer compatibility information element indicates high layer characteristics identification "facsimile group 4"; and e) the called party subaddress information element, if present, contains a number which matches the subaddress assigned to the terminal. Recommendation I.334 PRINCIPLES RELATING ISDN NUMBERSB/FSUBADDRESSES TO THE OSI REFERENCE MODEL NETWORK LAYER ADDRESSES (Melbourne, 1988) 1. Introduction Recommendation X.200, covering the open systems reference model, applies the term "address" to identify service access points at each layer. With respect to the network layer, a service access point may be identified by an ISDN numberB/Fsubaddress. This Recom- mendation is provided to clarify the concepts and terminology which relate ISDN numbers and subaddresses to one another and to OSI reference model network layer addresses. 1.1 Basic relationships The essential purpose of the network layer is to achieve rout- ing of information within the Open Systems Interconnection (OSI) environment. To that purpose it may be useful to establish a correspondence between an ISDN address (ISDN number, possibly with subaddress) and an X.200 network layer service access point. How- ever, an ISDN address may in some instances identify an end-system not conforming to the OSI model. In such cases the format and syn- tax of the subaddress are available for user-specific purposes. Section 2 summarizes the coding agreements which allow this flexi- bility. (The publication of the summary in this Recommendation is for information only and does not indicate administrative responsi- bility for contents nor assure current status of the material presented.) 1.2 NSAPs and ISDN addresses The ISDN address (ISDN number, possibly with subaddress) may include the OSI network layer address and thereby offer means to identify Network Service Access Points (NSAPs). Figure 1/I.334 shows the three cases, a), b) and c) below, relating an ISDN address to a particular OSI NSAP address. For completeness, references to protocol elements are included in the three cases which follow. For circuit mode access, the callingB/Fcalled subaddress information elements associated with the Q.931 SET-UP message are used to transmit subaddress informa- tion, while the X.25 address extension field serves this purpose for packet mode access. For interoffice circuit mode calls, the Q.931 subaddress information elements may be transmitted within the access transport parameter of the Signalling System No. 7 (S.S. No. 7) initial address message. On packet mode internetwork calls, the X.75 address extension field is available to carry subaddress information. The components of the OSI NSAP address are the AFI (Authority and Format Identifier), the IDI (Initial Domain Identifier) and possibly the DSP (Domain Specific Part) (see also S 3). a) The OSI NSAP address is comprised only of an AFI IDI, in which the IDI is semantically identical to the ISDN number. There is no DSP. A terminal can do one of the following: a1) The entire NSAP is carried in the subaddress field; or a2) If the conditions in S 1.3.1 are satisfied, the NSAP address can be inferred from the E.164 number. Note - For circuit mode calls, the semantic content of the AFI may be contained in the numbering and addressing plan iden- tification in the Q.931 or S.S. No. 7 callingB/Fcalled address pro- tocol elements. For packet mode calls, similar information may be found in the X.25B/FX.75 protocol. Until such time as a protocol mechanism for identifying the numbering plan and the type of number is implemented in X.25B/FX.75, analogous to that which exists in Q.931B/FS.S. No. 7, such information may be derivable from the X.25B/FX.75 address fields which may include a numbering plan escape code. It may also be possible for the semantic content of the AFI to be implied by network arrangements. .bp b) The OSI NSAP address is comprised of an AFI+IDI+DSP, in which the IDI is semantically identical to the ISDN number. In this case, the entire NSAP address is carried in the subaddressB/Faddress extension field. c) The OSI NSAP address is comprised of an AFI+IDI+DSP, in which the IDI is not related to the ISDN number. The entire NSAP address is conveyed in the subaddressB/Faddress extension field. Figure 1/I.334, p. 1.3 Encoding of NSAP addresses 1.3.1 Use of the AF (Address Field) Under certain conditions, the NSAP address, as defined in ISO 8348 AD2, may be conveyed entirely in the AF. These conditions are: a) the NSAP address consists solely of the IDP (i.e. the DSP is null); b) the AFI can be deduced from the contents of the AF (e.g. with knowledge of the subnetwork to which the DTE is attached); and c) the IDI is the same as the SNPA (Subnetwork Point of Attachment) address. When all the above conditions are satisfied, the AF may be used to convey the semantics of the entire NSAP address (the AFI is implied and the contents of the AF are equivalent to the IDI). In these cases, the AEF (Address Extension Field) may also be used (see S 1.3.2). 1.3.2 Use of the AEF (Address Extension Field) When the conditions in S 1.3.1 are not satisfied, the AEF shall be used. The NSAP address, complete with AFI, is placed in the AEF (type of subaddress is X.213B/FISO 8348 AD2). In this case, the contents of the AF are not defined by this Recommendation. 1.4 Decoding of NSAP addresses 1.4.1 Absent AEF case If the AEF is not present, then local knowledge is required by the receiving NL (Network Layer) entity to determine whether an OSI NSAP address is to be deduced from the content of the AF. If this local knowledge indicates that an NSAP address is present, its abstract syntax is as follows: a) the AFI is deduced from knowledge of the subnet- work from which the packet was received; b) the IDI is the same as the contents of the AF; and c) the DSP is absent. 1.4.2 AEF case If the AEF is present and the type of subaddress is X.213/ISO 8348 AD2, then the NSAP address is contained entirely within the AEF. The abstract syntax is as follows: a) the AFI is contained within the first two digits of the AEF; b) the IDI is the remainder of the Initial Domain Part (IDP) after any leading and trailing padding digits are dis- carded; and c) the DSP, if present, constitutes the remainder of the AEF content after any trailing padding digits are discarded. 2 Means to specify the type of subaddress Considering the three cases in which the NSAP address may be related to the ISDN addressB/Fsubaddress, a mechanism which permits determination of the type of subaddress present may be useful in making distinctions. The method of distinction is dependent upon the protocol being used. In the case of Q.931B/FI.451, 3 bits within octet 3 of each subaddress information element (i.e., calling and called party subaddress) establish the "type of subaddress". Two existing assignments, subject to change by responsible authorities are "user-specified" and "X.213B/FISO 8348 AD2". All other values are reserved. The actual subaddress information is coded beginning in octet 4 with the possibility of continuing up to octet 23, i.e., the subaddress information element has the capacity to carry a maximum of 20 octets of subaddress information. - Under the X.213B/FISO 8348 AD2 encoding of type of subaddress, the initial two digits of the subaddress represent the AFI which permits further distinction in subaddress encoding schemes as specified in Figure 2/I.334. - Under the user-specified encoding of type of subaddress, the subaddress field is encoded according to user specifications subject to a maximum length of 20 octets. In the case of packet mode calls using X.25/ISO 8208, bits within the first octet of the calling/called address extension facility parameter field indicate the "type of address extension" in a similar manner. Figure 2/I.334, p. 3 The OSI NSAP address format For reference purposes, a description of terms used in connec- tion with NSAP addresses is provided below: The format of the NSAP address is: Figure, p. IDP - Initial Domain Part contains all the interna- tionally standardized parts of the NSAP address, i.e. those addresses and numbers which are controlled either by ISO or CCITT. _________________________ Octets 1 and 2 of the subaddress information elements serve as information element and length identifiers, respectively. AFI - Authority and Format Identifier code indi- cates the authority responsible for the number following the AFI, such as X.121 or E.164 and the format of the DSP. This is always two digits and is allocated as per X.213/ISO 8348 AD2. IDI - Initial Domain Identifier for example, an E.164 or X.121 number. The networks which use these numbering schemes are termed subnetwork by ISO. The overall length of the field is determined by the maximum length of the number format being used. DSP - Domain Specific Part E.164 IDI, this part contains an address which is relevant only to the domain which has been accessed beyond the domain specified within the IDI, such as a PBX extension, a LAN terminal and so on. This is a variable length field, and is constrained by the length of the IDP, as the overall maximum length of the OSI NSAP address is 20 octets. Recommendation I.335 ISDN ROUTING PRINCIPLES (Melbourne, 1988) 1 Introduction A wide range of services is likely to be offered on ISDNs, which will be supported by a specific set of network capabilities. From a routing point of view, the relationship between these ser- vices and network capabilities must therefore be considered. The aim of this Recommendation is to lay down basic routing principles defining the relationship between ISDN telecommunication services, as described in the I.200-Series of Recommendations, and ISDN network capabilities as described in the I.300-Series of Recommendations. This Recommendation addresses the relevance of these principles to the proposed routing plan for ISDN, and indi- cates what factors are involved in processing a call. ISDN routing implications of interworking (intra-ISDN and with other networks) are for further study. 2 General routing principles As described in Recommendation I.210, telecommunication ser- vices are the communication capabilities offered to customers. The service concept can therefore be considered to be time independent. A particular instance (or use by the user) of a service is commonly referred to as a call. Likewise, the network capabilities which support services, the ISDN connection types, are described in Recommendation I.340. These connection types are also time independent in their concept. The ISDN network architecture Recommendation I.324 explains how an ISDN connection type is made up of connection elements: - the "access connection element"; - the "national transit connection element"; and - the "international transit connection element". The connection elements, also time independent, are used for the description of the different reference configurations associated with the different connection types (see Recommendation I.325). It should be noted that the user specifies only the service required. The network allocates the resources to set up a connec- tion of the specific type as necessary to support the requested service. For certain services, additional network functions, e.g. additional lower layer function and/or higher layer functions, may be required as depicted in Figure 1/I.335. For examples of such cases refer to Recommendation I.310. Figure 1/I.335, p. Figure 2/I.335 shows the general relationship between telecom- munication services and ISDN connection types of a service provi- sion (call) by the establishment of a connection through the selec- tion of a route. The relationship between a call and a connection is a route . This means that a route is the application of a particular connec- tion to a specific call. The connection (being an instance of a connection type) will specify the network capabilities being used on a particular call. A route therefore has geographical signifi- cance. Figure 2/I.335, p. In order to establish a communication an ISDN must select: - an appropriate connection type, i.e. functional grouping , to support the service; - an appropriate association between the selected functional grouping in terms of a physical realization, i.e. the network allocates the set of connection elements necessary to real- ize the appropriate connection type. The concept of connection type describes network capabilities using the attribute technique. One of these attributes is known as "information transfer susceptance". Some other attributes (e.g. "connection control protocol") describe the signalling capa- bilities. i) Information transfer susceptance For each service requested by the user, the network has to provide a connection type having a suitable value of the informa- tion transfer susceptance attribute, involving switching and transmission capability. The selection of an appropriate connection type is part of the routing functions. The relationship between the information transfer suscep- tance attribute of a connection type and the transmission/switching capabilities is detailed in Recommendation E.172. ii) Signalling capabilities Since the telephone network will progressively evolve towards ISDN, not all part of the network will initially have the same signalling capabilities. Between two given exchanges in the network, the following signalling systems for example, may be available: - channel associated signalling: R1, R2. - Signalling System No. 6 - Signalling System No. 7: TUP - Signalling System No. 7: ISUP These different signalling systems have different signal- ling capabilities. The routing functions have to take into account the signalling capabilities of the network to ensure that the required service will be correctly provided. It is also necessary to consider the case where the required service can be provided, but with some restrictions. Example - For a telephone call between two ISDN sub- scribers, TUP may be sufficient to set up a call but does not allow end-to-end information transfer and some supplementary services. The routing principles consider these different cases. The ISDN routing process, which is further detailed in S 4 is divided into three aspects: 1) matching between telecommunication services and ISDN connection types; 2) determination of parameters relevant to routing to be conveyed and possibly processed across the signalling net- work; 3) selection of rules for routing through the dif- ferent connection elements with respect to the reference configura- tions in Recommendation I.325. The "routing plan" itself, which is the set of rules for path selection in the ISDN, is given in Recommendation E.172. This routing plan follows the routing principles outlined in Recommendation I.335 as well as other factors. Among others, the use of connections over geostationary satellites does not call for any alterations in the basic principles of ISDN routing. Figure 3/I.335 shows the relationship between Recommendations relating to routing. 3 Matching between telecommunication services and connection types 3.1 General The user requests a service not a connection type. It is the responsibility of the network, as part of its routing functions, to allocate a suitable connection type to support the requested ser- vice. Providing a mapping between the ISDN services and connection types would assist the network in its routing decisions. Network operators will have freedom of choice in the selection of a suitable connection type for a given service request. For international connections, the connection type selected should, for reasons of economy, generally be the minimum necessary to support the service. If for reasons of congestion such a connec- tion type is not available the next higher capability connection type could be selected. Figure 3/I.335, p. 3.2 List of bearer services Tables 1a/I.335 and 1b.I.335 list the attribute values and recommended provision of circuit-mode and packet-mode bearer ser- vice, respectively, as described in Recommendations I.231 and I.232. 3.3 List of teleservices Table 2/I.335 lists the attribute values of teleservices described in Recommendation I.241. 3.4 List of connection types Table 3/I.335 lists the recommended connection types in an ISDN as described in Recommendation I.340. 3.5 Mapping of bearer services for ISDN connection types Tables 4a/I.335, 4b/I.335 and 4c/I.335 show the mapping between bearer services and connection types. Note that, in certain cases, more than one connection type may be suitable for a given bearer service. The first value would usu- ally represent an exact match to the already defined bearer service attribute values, and subsequent values would represent acceptable alternative(s). Therefore, in determining the connection types usable for a given bearer service the network may provide: a) a connection type which is an exact mapping between the already defined bearer service and connection type attribute values; b) a connection type wherein the mapping between the bearer service and the connection type attribute values differs for certain attributes, but shall provide equivalent or superior performance to that of a). Also, permanent services might be supported on semi-permanent connections. This is for further study. 3.6 Mapping of teleservices to ISDN connection types Teleservices are expected to be supported by the same set of connection types, but further studies are needed on additional routing aspects that may be required (see Table 5/I.335). 4 Routing process in an ISDN This section describes the routing process within the ISDN using the general model of the ISDN provided in the Recommendation I.324. The routing process is the sequence of steps required to establish a connection in response to a service request. A diagram of how routing parameters are used in the ISDN rout- ing process, using the currently defined Q.760 parameter fields is provided in Figure 4/I.335. 4.1 Description 4.1.1 User-network interface The user places a request for a particular service. The termi- nal equipment converts this request into a Q.931 set-up message. This Q.931 set-up message is presented to the user-network inter- face to request one of the following: - a bearer service - a bearer service and supplementary service(s) - a teleservice - a teleservice and supplementary service(s) The Q.931 request is coded to indicate the appropriate attri- butes of the requested service. The information elements indicated within the Q.931 message will vary depending on the type of bearer service or teleservice and supplementary service(s) requested. 4.1.2 Originating local CRF The originating local connection related function (CRF), e.g. local exchange, processes the Q.931 service request and deter- mines if network routing is required. If network routing is required using S.S. No. 7 ISDN user part (ISUP), the local CRF translates this request into an appopriate initial address message (IAM) and determines the network resources needed to support this service. The IAM contains certain attributes of a connection type that specifies network capabilities sufficient to support this ser- vice. During the translation of the request the local CRF selects appropriate basic connection components. 4.1.3 Transit CRF The transit CRF processes the incoming IAM and generates an appropriate outgoing IAM for the next stage of the call. The outgo- ing IAM contains certain attributes that defines network capabili- ties required to support this service. The transit CRF also allo- cates appropriate basic connection components, e.g. echo cancell- ers, u-A law converters, satellite links. H.T. [T1.335] ________________________________________________ TABLE 1a/I.335 { Circuit-mode bearer services recommended in an ISDN | ua) } ________________________________________________ | | | | | | | | | | | | | | __________________________________________________________________________________________________________________________________________________________________________________ No. Transfer mode Transfer rate (kbit/s) Transfert capability { Establishment of communication } Structure Communication configuration Symetry | ub) __________________________________________________________________________________________________________________________________________________________________________________ 1.1 circuit 64 { unrestricted digital | uc) } demand 8 kHz pt-pt bidirectional symmetric 1.2 circuit 64 { unrestricted digital | uc) } reserved 8 kHz pt-pt bidirectional symmetric 1.3 circuit 64 { unrestricted digital | uc) } permanent 8 kHz pt-pt bidirectional symmetric __________________________________________________________________________________________________________________________________________________________________________________ 2.1 circuit 64 speech demand 8 kHz pt-pt bidirectional symmetric 2.2 circuit 64 speech reserved 8 kHz pt-pt bidirectional symmetric 2.3 circuit 64 speech permanent 8 kHz pt-pt bidirectional symmetric __________________________________________________________________________________________________________________________________________________________________________________ 3.1 circuit 64 3.1 kHz audio demand 8 kHz pt-pt bidirectional symmetric 3.2 circuit 64 3.1 kHz audio reserved 8 kHz pt-pt bidirectional symmetric 3.3 circuit 64 3.1 kHz audio permanent 8 kHz pt-pt bidirectional symmetric __________________________________________________________________________________________________________________________________________________________________________________ 4.1 circuit 64 alt speech/unrestricted demand 8 kHz pt-pt bidirectional symmetric 4.2 circuit 64 alt speech/unrestricted reserved 8 kHz pt-pt bidirectional symmetric 4.3 circuit 64 alt speech/unrestricted permanent 8 kHz pt-pt bidirectional symmetric __________________________________________________________________________________________________________________________________________________________________________________ 5.1 circuit 2x64 unrestricted demand 8 kHz | ud) pt-pt bidirectional symmetric 5.2 circuit 2x64 unrestricted reserved 8 kHz | ud) pt-pt bidirectional symmetric 5.3 circuit 2x64 unrestricted permanent 8 kHz | ud) pt-pt bidirectional symmetric __________________________________________________________________________________________________________________________________________________________________________________ 6.1 circuit 384 unrestricted demand 8 kHz pt-pt bidirectional symmetric 6.2 circuit 384 unrestricted reserved 8 kHz pt-pt bidirectional symmetric 6.3 circuit 384 unrestricted permanent 8 kHz pt-pt bidirectional symmetric __________________________________________________________________________________________________________________________________________________________________________________ 7.1 circuit 1536 unrestricted demand 8 kHz pt-pt bidirectional symmetric 7.2 circuit 1536 unrestricted reserved 8 kHz pt-pt bidirectional symmetric 7.3 circuit 1536 unrestricted permanent 8 kHz pt-pt bidirectional symmetric __________________________________________________________________________________________________________________________________________________________________________________ 8.1 circuit 1920 unrestricted demand 8 kHz pt-pt bidirectional symmetric 8.2 circuit 1920 unrestricted reserved 8 kHz pt-pt bidirectional symmetric 8.3 circuit 1920 unrestricted permanent 8 kHz pt-pt { bidirectional symmetric } __________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a) As given in Recommendation I.231. b) Unidirectional services are for further study. c) During an interim period some networks may only offer restricted digital information transfer capability (i.e. an all-zero octet is not allowed). d) With RDTD "Restricted differential time delay". Tableau 1a/I.335 [T1.335], A L'ITALIENNE, p. 15 H.T. [T2.335] TABLE 1b/I.335 Packet mode bearer services | ua) ______________________________________________________________________________________________________________________________________________________ Bearer service No. Transfer mode Transfer rate Transfer capability { Establishment of the communication } Structure ______________________________________________________________________________________________________________________________________________________ Virtual call P1 P2 packet packet FS FS unrestricted unrestricted demand permanent SDU SDU ______________________________________________________________________________________________________________________________________________________ User to user signalling P3 P4 packet packet FS FS unrestricted unrestricted demand permanent SDU ______________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SDU a) As given in Recommendation I.232. FS For further study. SDU Service data unit. Tableau 1b/I.335 [T2.335], p. 16 Blanc H.T. [T3.335] ____________________________________________ TABLE 2/I.335 { List of teleservices (as described in Recommendation I.241) } ____________________________________________ | | | | | | | | | | | | __________________________________________________________________________________________________________________________________________________________________________________________ No. Teleservice Transfer mode Transfer rate (kbit/s) Transfer capability { Establishment of communication } Structure Communication configuration Symmetry __________________________________________________________________________________________________________________________________________________________________________________________ 1.1 telephony circuit 64 speech demand 8 kHz pt-pt bidirectional symmetric 1.2 telephony circuit 64 speech reserved 8 kHz pt-pt bidirectional symmetric 1.3 telephony circuit 64 speech permanent 8 kHz pt-pt bidirectional symmetric 1.4 telephony circuit 64 speech demand 8 kHz multipt bidirectional symmetric 1.5 telephony circuit 64 speech reserved 8 kHz multipt bidirectional symmetric 1.6 telephony circuit 64 speech permanent 8 kHz multipt bidirectional symmetric __________________________________________________________________________________________________________________________________________________________________________________________ 2.1 teletex circuit 64 unrestricted demand 8 kHz pt-pt bidirectional symmetric __________________________________________________________________________________________________________________________________________________________________________________________ 3.1 telefax (Group 4) circuit 64 unrestricted demand 8 kHz pt-pt bidirectional symmetric __________________________________________________________________________________________________________________________________________________________________________________________ 4.1 mixed mode circuit 64 unrestricted demand 8 kHz pt-pt bidirectional symmetric __________________________________________________________________________________________________________________________________________________________________________________________ 5.1 videotex | ua) circuit 64 unrestricted demand 8 kHz pt-pt bidirectional symmetric 5.2 videotex | ub) circuit 64 unrestricted demand 8 kHz pt-pt bidirectional symmetric 5.3 videotex | ub) circuit 64 unrestricted permanent 8 kHz pt-pt bidirectional symmetric 5.4 videotex | ub) circuit 64 unrestricted demand 8 kHz multipt bidirectional symmetric 5.5 videotex | ub) circuit 64 unrestricted permanent 8 kHz multipt bidirectional symmetric 5.6 videotex | ub) packet FS unrestricted demand SDU pt-pt bidirectional symmetric 5.7 videotex | ub) packet FS unrestricted permanent SDU pt-pt bidirectional symmetric 5.8 videotex | ub) packet FS unrestricted demand SDU multipt bidirectional symmetric 5.9 videotex | ub) packet FS unrestricted permanent SDU multipt bidirectional symmetric __________________________________________________________________________________________________________________________________________________________________________________________ 6.1 telex circuit 64 unrestricted demand 8 kHz pt-pt bidirectional symmetric 6.2 telex circuit 64 unrestricted reserved 8 kHz pt-pt bidirectional symmetric 6.3 telex circuit 64 unrestricted permanent 8 kHz pt-pt bidirectional symmetric 6.4 telex circuit 64 unrestricted demand 8 kHz multipt bidirectional symmetric 6.5 telex circuit 64 unrestricted reserved 8 kHz multipt bidirectional symmetric 6.6 telex circuit 64 unrestricted permanent 8 kHz multipt bidirectional symmetric 6.7 telex packet FS unrestricted demand SDU pt-pt bidirectional symmetric 6.8 telex packet FS unrestricted demand SDU multipt { bidirectional symmetric } __________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a) Transmission between user terminal and Videotex centre. b) Transmission between Videotex centres and external computers. FS For further study. SDU Service data unit. Tableau 2/I.335 [T3.335], A L'ITALIENNE, p. 17 H.T. [T4.335] ________________________________________________ TABLE 3/I.335 { ISDN connection types (based on Table 2/I.340) } ________________________________________________ | | | | | | | | | | _____________________________________________________________________________________________________________________________________________________________________________________________ Connection type No. Transfer mode Transfer rate (kbit/s) Transfer capability Structure Establishment of connection { Communication configuration | ua) } Symmetry _____________________________________________________________________________________________________________________________________________________________________________________________ A.1 circuit 64 unrestricted digital 8 kHz switched pt-pt bidirectional symmetric A.2 circuit 64 unrestricted digital 8 kHz semi-permanent pt-pt bidirectional symmetric A.3 circuit 64 unrestricted digital 8 kHz permanent pt-pt bidirectional symmetric _____________________________________________________________________________________________________________________________________________________________________________________________ A.4 circuit 64 speech 8 kHz switched pt-pt bidirectional symmetric A.5 circuit 64 speech 8 kHz semi-permanent pt-pt bidirectional symmetric A.6 circuit 64 speech 8 kHz permanent pt-pt bidirectional symmetric _____________________________________________________________________________________________________________________________________________________________________________________________ A.7 circuit 64 3.1 kHz audio 8 kHz switched pt-pt bidirectional symmetric A.8 circuit 64 3.1 kHz audio 8 kHz semi-permanent pt-pt bidirectional symmetric A.9 circuit 64 3.1 kHz audio 8 kHz permanent pt-pt bidirectional symmetric _____________________________________________________________________________________________________________________________________________________________________________________________ A.10 circuit 2x64 unrestricted digital 8 kHz | ub) switched pt-pt bidirectional symmetric A.11 circuit 2x64 unrestricted digital 8 kHz | ub) semi-permanent pt-pt bidirectional symmetric A.12 circuit 2x64 unrestricted digital 8 kHz | ub) permanent pt-pt bidirectional symmetric _____________________________________________________________________________________________________________________________________________________________________________________________ B.1 packet 64 (FS) unrestricted digital SDU switched pt-pt bidirectional symmetric B.2 packet 64 (FS) unrestricted digital SDU semi-permanent pt-pt bidirectional symmetric _____________________________________________________________________________________________________________________________________________________________________________________________ C.1 circuit 384 { unrestricted digital | uc) } 8 kHz switched pt-pt bidirectional symmetric C.2 circuit 384 { unrestricted digital | uc) } 8 kHz semi-permanent pt-pt (unidirectionnal: FS) C.3 circuit 384 { unrestricted digital | uc) } 8 kHz permanent pt-pt (unidirectionnal: FS) _____________________________________________________________________________________________________________________________________________________________________________________________ C.4 circuit 1536 unrestricted digital 8 kHz switched pt-pt bidirectional symmetric C.5 circuit 1536 unrestricted digital 8 kHz semi-permanent pt-pt (unidirectional: FS) C.6 circuit 1536 unrestricted digital 8 kHz permanent pt-pt (unidirectional: FS) _____________________________________________________________________________________________________________________________________________________________________________________________ C.7 circuit 1920 unrestricted digital 8 kHz switched pt-pt bidirectional symmetric C.8 circuit 1920 unrestricted digital 8 kHz semi-permanent pt-pt (unidirectional: FS) C.9 circuit 1920 unrestricted digital 8 kHz permanent pt-pt (unidirectional: FS) _____________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a) For multipoint services the necessary multipoint capabilities have to be provided. b) With RDTD "Restricted differential time delay". c) During an interim period some networks may only offer restricted digital information transfer capability (i.e. an all-zero octet is not allowed). FS For further study. SDU Service data unit. Tableau 3/I.335 [T4.335], A L'ITALIENNE, p. 18 H.T. [T5.335] TABLE 4a/I.335 Mapping of bearer services at 64 kbit/s to connection types ____________________________________________________________________________________________________________________ { Speech 3.1 kHz audio { Notes { A.1 A.2 A.3 A.4 A.5 A.6 A.7 A.8 A.9 A.10 A.11 A.12 ____________________________________________________________________________________________________________________ Unrestricted 1.1 X digital 1.2 X 64 kbit/s 1.3 X X ____________________________________________________________________________________________________________________ Speech 2.2 a) X X b) ____________________________________________________________________________________________________________________ 3.1 kHz 3.1 a) X b) audio 3.2 a) X b) ____________________________________________________________________________________________________________________ Alternate 4.1 a) c) speech/64 kbit/s 4.2 a) c) unrestricted 4.3 a) a) c) ____________________________________________________________________________________________________________________ Unrestricted 5.1 X digital 5.2 X 2 x 64 kbit/s 5.3 X X ____________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a) May present A-u law conversion problems, echo control problems, etc. b) Analogue transmission may also be used. c) For the possibility of change of service during a call, see S 5.2 of Recommendation I.340. X Indicates that the connection type can definitely support the service. Note 1 - During an interim period, some networks may only support restricted transfer capability (i.e. no all-zero octet allowed). Note 2 - For multipoint services the necessary multipoint capabil- ities have to be provided. Tableau 4a/I.335 [T5.335], p. 19 Blanc H.T. [T6.335] TABLE 4b/I.335 Mapping of bearer services 64 kbit/s (up to primary rate) to connection types _________________________________________________________________________________________________________________________________________ 384 kbit/s unrestricted 1536 kbit/s unrestricted 1920 kbit/s unrestricted { C.1 C.2 C.3 C.4 C.5 C.6 C.7 C.8 C.9 _________________________________________________________________________________________________________________________________________ 384 kbit/s 6.1 X a) a) unrestricted 6.2 X a) a) _________________________________________________________________________________________________________________________________________ 1536 kbit/s 7.1 X a) unrestricted 7.2 X a) _________________________________________________________________________________________________________________________________________ 1920 kbit/s 8.1 X unrestricted 8.2 X _________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a) An appropriate rate adaption scheme must be defined and util- ized. X Indicates that the connection type can definitely support the service. Tableau 4b/I.335 [T6.335], p. 20 H.T. [T7.335] TABLE 4c/I.335 Mapping of packet-mode bearer services to connection types ________________________ { Connection types Bearer services } B.1 B.2 ________________________ P.1 X P.2 X P.3 | ua) P.4 | ua) ________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a) The connection types for these bearer services are for further study. Tableau 4c/I.335 [T7.335], p. 21 H.T. [T8.335] TABLE 5/I.335 Mapping of teleservices to ISDN connection types _____________________________________________________________________________________________________________________________________________________________________________ 64 kbit/s unrestricted 64 kbit/s speech 64 kbit/s 3.1 kHz audio Packet User signalling Notes { A.1 A.2 A.3 A.4 A.5 A.6 A.7 A.8 A.9 B.1 B.2 B.3 B.4 _____________________________________________________________________________________________________________________________________________________________________________ Telephony 1.3 a) a) X X X X c) b) _____________________________________________________________________________________________________________________________________________________________________________ Teletex 2.1 X _____________________________________________________________________________________________________________________________________________________________________________ Facsimile 3.1 X _____________________________________________________________________________________________________________________________________________________________________________ Mixed mode 4.1 X _____________________________________________________________________________________________________________________________________________________________________________ Videotex 5.5 X X c) _____________________________________________________________________________________________________________________________________________________________________________ Telex 6.4 X c) _____________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a) May present A-u law conversion problems; echo control problems, etc. b) Analogue transmission may also be used. c) For multipoint services the necessary multipoint capabilities have to be provided. X Indicates that the connection type can definitely support the service. Tableau 5/I.335 [T8.335], p. 22 Figure 4/I.335, p. 23 4.1.4 Terminating local CRF The terminating local CRF, e.g. local exchange, processes the incoming IAM. The local CRF uses the information from within the incoming IAM to generate an appropriate Q.931 set-up message. The set-up message is then offered to the destination terminal across the user network interface, subject to certain local conditions and decisions. 4.2 Elements and parameters The routing plan is a set of rules defining the process of selecting appropriate basic connection components conforming to the connection elements capable of supporting a given telecommunication service. These rules are developed in Recommendation E.172. To be able to implement these rules the CRFs must be capable of process- ing an elaborate set of parameters. 4.2.1 Description This section describes the elements and parameters that may be required for the call routing process. Different network CRFs need not require a complete set of these parameters; however each CRF will require a minimum set to ensure efficient and effective rout- ing. a) Calling customer's subscription parameters The local CRF may validate service requests against the customer's subscription parameters before the outgoing route is selected. b) Incoming route Some incoming routes may require special treatment (e.g. not allow access to all outgoing routes). c) Called number The called number, when provided, is used for routing. Access may be barred to a particular network or a particular custo- mer, under either administrative or network management control, by analysis of the called number. Note - For destination network, see Table 7/I.335. d) Basic telecommunication service request The nature of the bearer or teleservice requested, requires parameter analysis to determine relevant attribute values of the minimum necessary connection type capable of supporting that ser- vice (e.g. information transfer susceptance, signalling system capabilities, etc.). The parameters analyzed, for call routing, are predom- inantly related to the lower layers (e.g. BC). The network may, however, additionally analyze higher layer parameters (e.g. HLC). e) Transmission medium requirement (TMR) The TMR is the encoding of the information transfer suscep- tance attribute value of the minimum necessary connection type capable of supporting the call. Note - Relevant attributes of the minimum necessary con- nection type are derived at the originating local CRF from the BC (Bearer Capability) and supplementary service request as an inter- mediate step in determining the values of routing parameters. The information transfer susceptance is derived from the information transfer capability and information transfer rate fields contained in the Q.931 BC information element. The encoding of the TMR may, depending on the network operator's policy, represent a higher value of the information transfer susceptance attribute that the minimum necessary to sup- port the call. However, between international and internetwork gateways, the TMR should represent the minimum necessary (to sup- port the requested service) and should not be modified. The TMR can then be used between such gateways to perform efficient routing. This does not preclude that some gateways may need to examine addi- tional information [e.g. USI (User Service Information)]. Table 6/I.335 identifies the relationship between some circuit-mode bearer services and teleservices identified in I.230 with the (minimum) TMR value. The values of TMR for other services is for further study. H.T. [T9.335] TABLE 6/I.335 Relationships between the requested service and the minimum TMR value _____________________________________________________________________________________________ TMR value Requested service Speech 3.1 kHz audio 64 kbit/s unrestricted _____________________________________________________________________________________________ 64 kbit/s unrestricted X 3.1 kHz audio X Speech X __________________________________________________________________________ Bearer services _____________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 6/I.335 [T9.335], p. f ) User Service Information (USI) The USI is the encoding of the Q.931 BC into Q.762 ISUP. The USI parameter may be used to regenerate attributes of the TMR required by the routing function(s) at intermediate CRFs [see item e) above]. g) Supplementary service request Both ISDN and PSTN services may invoke various supplemen- tary services which may require analysis before the outgoing route is selected. The services can be split into those supported by both the ISDN and PSTN and those supported only by the ISDN. Within each of these two groups, some supplementary services may be realized as a function of the originating local exchange (e.g. short code dial- ling) while others will require end-to-end capabilities across the network (e.g. calling line identification and closed user group). The provision of these latter supplementary services can influence call routing in terms of the signalling system capability require- ment. Therefore the supplementary service requested can influence the value of the signalling system capability attribute of the con- nection type capable of supporting that combination of basic and supplementary service. h) ISUP preference indicator This is an indicator contained within the forward call indicators parameter field of ISUP, sent in the forward direction indicating whether or not the ISDN user part (ISUP) is required or preferred or not required in all parts of the network connection. This information is derived at the originating local CRF from the network signalling capability attribute of the minimum necessary connection type, which is itself derived from the BC and supplemen- tary service request contained in the Q.931 set-up message. i) Environment of the connection This information element contains three secondary attri- butes of the requested bearer service that may influence the rout- ing process, namely: 1) the establishment of communication (demand, reserved, permanent); 2) the configuration of communication (point-to-point, multipoint, broadcast); 3) symmetry (symmetric, asymmetric). These secondary attributes are contained in the Q.931 BC information element and are directly transposed by the originating local CRF into the ISUP user service information parameter field [see item f ) above]. The impact of the environment of the connec- tion on TMR for future service is for further study. Note - Each of these three secondary attributes may invoke special arrangements that may be necessary in order to establish, for example, point-to-multipoint, or asymmetric calls. j) Network management conditions There may be cases where network management control of routing functions is required. (Route selection may be under con- trol of routing information dynamically updated by network routing processors, i.e. processors monitoring network traffic flows.) For this reason CRFs may be required to implement capabilities for sup- porting this facility. k) Transit network selection National networks may implement capabilities allowing requests for specific transit network(s) to be used in the call. Impact of this on call routing may require further study. l) Connection history In order to ensure that the number of links, the number of satellite hops and any other network limiting functions are not exceeded in a connection, a connection history should be available for processing prior to route selection. A set of relevant parame- ters is provided in ISUP by the nature of connection indicators parameter field. This field is generated at the originating local exchange and modified at subsequent transit exchanges each time a relevant parameter (e.g. number of satellite links) is affected as a result of the transmission path chosen. Code points for other parameters, e.g. number of sections with digital circuit multipli- cation equipment (DCME) and A-u law converters, may not be required for routing purposes since these should be taken into account in the hypothetical digital reference connection (HDRC) at the exchange routing data planning stage. However a signalling capabil- ity may be necessary to provide a means of verifying that parameter values are within the allowed limits. Note - It is considered that the responsibility of inter- national operators for correctly setting up exchange routing data is of paramount importance to ensure that signalling systems and exchange processors are not burdened with the need for per-call conveyance and examination of unnecessary information. m) Time of day Because of varying traffic distributions during a 24 hour period, it may be advantageous to change the call routing arrange- ments as a function of the time of day. 4.2.2 Application in the routing process This section deals with the application of the information elements and parameters in the routing process identified in S 4.2.1. The elements and parameters are given in Table 7/I.335 together with their significance with regard to different network CRFs (nodes). 4.2.2.1 Originating local CRF The originating local CRF processes the Q.931 service request and determines if network routing is required. When routing is required, the local CRF maps the requested service into attributes of a connection type that specifies network capabilities sufficient to support this service. This mapping, discussed in S 3, defines the network resources needed to support the service and results in the generation of an appropriate IAM. Additionally, the local CRF allocates the appropriate basic connection components which, as a minimum, conform to the required connection type. 4.2.2.2 Transit CRF The transit CRF will process an incoming IAM and will generate an appropriate outgoing IAM. The incoming and outgoing IAM mesage contains the following parameter fields which may be used for routing purposes: - nature of connection indicators, - forward call indicators, - calling party's category, - transmission medium requirement (TMR) , - called party number, - user service information (USI), - transit network selection (national use only). The IAM message may contain other parameters whose presence may influence the choice of signalling system capability for the call. These parameters are: - call reference, - calling party number, - optional forward call indicators, - redirecting number, - CUG interlock code, - connection request, - user-to-user information, - access transport. The parameters listed above contain all the signalling infor- mation needed to perform routing in the international network. In the international network, the TMR is set to the value that represents the minimum network capability to provide the requested service and that value is not modified. 5 ISDN routing principles applicable to network interworking This section describes routing considerations in network interworking situations (i.e. ISDN to/from other networks), defined in the I.500-Series of Recommendations. 5.1 ISDN-PSTN interworking Routing implications of the following ISDN-PSTN interworking scenarios are described: i) ISDN to PSTN In this scenario, the call is initiated from an ISDN access and terminated on a PSTN access. ii) PSTN to ISDN In this scenario, the call is initiated from a PSTN access and terminated on an ISDN access. These scenarios do not apply to network interworking situa- tions wherein a transit network other than an ISDN or PSTN is involved. The ISDN bearer capabilities that are compatible with the capabilities of the PSTN are identified in Recommendation I.530. In the general case, an ISDN-originated call incompatible with PSTN capabilities is cleared with an appropriate message. 5.1.1 ISDN to PSTN direction In the ISDN to PSTN direction, a call originating from an ISDN access encounters ISDN to PSTN interworking in the following cases: i) the call destination is on a PSTN access; ii) interworking with a non-ISUP signalling system is encountered. H.T. [T10.335] TABLE 7/I.335 Elements and parameters in routing process (Note 1) ________________________________________________________________________________________________________________________________________________________________________________ { { Originating local exchange National transit exchange International exchange (ISC) Terminating local exchange ________________________________________________________________________________________________________________________________________________________________________________ { a) Calling customer's subscription parameters } X ________________________________________________________________________________________________________________________________________________________________________________ b) Incoming route X X ________________________________________________________________________________________________________________________________________________________________________________ { c) Called number (including NPI/TON information, if present) } X X X X ________________________________________________________________________________________________________________________________________________________________________________ Destination network X X X ________________________________________________________________________________________________________________________________________________________________________________ { d) Basic service request - bearer capability (BC) } X ________________________________________________________________________________________________________________________________________________________________________________ { e) Transmission medium requirement (TMR) } Generated X X (Note 2) Terminated ________________________________________________________________________________________________________________________________________________________________________________ { f) User service information (USI) } Generated X X (Note 2) ________________________________________________________________________________________________________________________________________________________________________________ { g) Supplementary service request } X (Note 3) ________________________________________________________________________________________________________________________________________________________________________________ h) ISUP preference indicator Generated X X Terminated ________________________________________________________________________________________________________________________________________________________________________________ { i) Environment of the connection } X ________________________________________________________________________________________________________________________________________________________________________________ { j) Network management conditions } X X X ________________________________________________________________________________________________________________________________________________________________________________ k) Transit network selection X X ________________________________________________________________________________________________________________________________________________________________________________ l) Connection history Generated X X Terminated ________________________________________________________________________________________________________________________________________________________________________________ m) Time of day X X X ________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - This table identifies the elements and parameters nor- mally used to route calls. The use of other elements and parameters is not precluded for special circumstances at any routing stage. Note 2 - The USI parameter field containing the BC information element may be processed if necessary to regenerate the required TMR value capable of supporting the requested service. For calls where BD = speech or 3.1 kHz audio, between A and u-law networks the BC would be modified (by the u-law international gateway) accordingly. Note 3 - The supplementary service request may influence the value of the ISUP preference indicator. Tableau 7/I.335 [T10.335], p. 25 Blanc On ISDN to PSTN calls, the call is routed as in an ISDN up to the interworking point. The routing decision is performed at the interworking point. This decision is generally based on information available in the ISUP initial address message. If the interworking point is a transit CRF (national or international) where interwork- ing with a non-ISUP signalling system is encountered, signalling interworking (ISUP to/from non-ISUP) is also performed. If the call can proceed to the PSTN, call establishment continues using normal routing procedures within the PSTN from the interworking point onwards. On ISDN to PSTN calls, progress indications are returned via S.S. No. 7 ISUP and the procedures of Q.931 to the ISDN origina- tion as soon as interworking with the PSTN is encountered. 5.1.2 PSTN to ISDN direction In the PSTN to ISDN direction, a call encounters PSTN to ISDN interworking in the following cases: i) the call destination is on an ISDN access; ii) interworking with an ISUP signalling system is encountered. In the general case, a call originating from a PSTN access is assumed by the network to be either a voice call or modem-derived voice-band data call; these two call types are indistinguishable. On PSTN to ISDN calls, the call is routed using normal PSTN routing procedures up to the interworking point. At the interworking point the call is routed in the ISDN and offered to the destination as a "3.1 kHz audio" call accompanied by an appropriate Q.931 progress indication. For some cases, the selection of 3.1 kHz audio may be inap- propriate. For example, for PSTN-ISDN data interworking using the 64 kbit/s bearer service, refer to Recommendation I.231. Various selection mechanisms are contained in Recommendation I.515. The routing impacts are for further study. If the interworking point is a transit CRF (national or inter- national) where interworking with an ISUP signalling system is encountered, signalling interworking (non-ISUP to/from ISUP) is performed at this interworking point. 5.2 ISDN-PSPDN interworking Routing implications of ISDN-PSPDN interworking are for further study. 5.3 ISDN-CSPDN interworking Routing implications of ISDN-CSPDN interworking are for further study. 5.4 ISDN-ISDN interworking over concatenated networks Network concatenation occurs when an existing network (e.g. PSTN, CSPDN, PSPDN) provides a connection between the ori- ginating and terminating ISDNs. The routing implications of network concatenation scenarios are for further study. Blanc MONTAGE: PAGE 110 = PAGE BLANCHE