5i' PART III I.300-Series Recommendations OVERALL NETWORK ASPECTS AND FUNCTIONS Blanc MONTAGE: PAGE 2 = PAGE BLANCHE SECTION 1 NETWORK FUNCTIONAL PRINCIPLES Recommendation I.310 ISDN - NETWORK FUNCTIONAL PRINCIPLES (Malaga-Torremolinos, 1984; amended at Melbourne, 1988) 1 General 1.1 Basic philosophy of the functional description The objective of this Recommendation is to provide a common understanding of the ISDN capabilities, including terminal, network and specialized service centre aspects. A functional description of ISDN capabilities must allow a clear distinction between definition/specification aspects of ser- vices provided by the ISDN and the actual specification of the equipment utilized to support those services. Therefore, an implementation-independent approach should be adopted. Moreover in the context of this Recommendation the adjective "functional" is used in the sense of an implementation-independent approach. The noun "function" itself has a specific meaning which is explained below. The description of network capabilities is consistent with the protocol reference mode, e.g.: - the layering structure of all systems involved in a communication process, i.e. partitioning the required functions between different layers; - the clear discrimination between layer service concept, layer function concept and layer protocol concept. Furthermore, the three following distinctions apply: - distinction between basic services and supplemen- tary services; - distinction between ISDN capabilities and ser- vices offered to the customer; - distinction between static and dynamic aspects of the description. 1.2 Services supported by an ISDN The concepts and the principles of an ISDN are described in Recommendation I.120. The services supported by an ISDN are given in the I.200-Series of Recommendations. A classification and the tools for the description of telecommunication services are speci- fied in Recommendation I.210 according to the description method as given in Recommendation I.130. The network capabilities to sup- port these services are defined in the I.300-Series of Recommenda- tions. The relationship between these Recommendations and some other relevant I-Series Recommendations is shown in Figure 1/I.310. Figure 1/I.310, (N), p. It should be noted that the service concept defined in Recommendation I.210 is different from the layer service concept of the OSI model. The telecommunication service concept in Recommendation I.210 corresponds to the services offered to users by the network. Besides operational and commercial aspects, the provision of these telecommunication services (bearer and teleser- vices) and associated supplementary services requires the availa- bility of appropriate capabilities: - network capabilities, in various network equipments (exchanges etc.); - terminal capabilities; - specialized service centre capabilities, when required. 1.3 Generic description of required capabilities ISDN capabilities are the total sum of the functions required to support all basic and supplementary services offered by the ISDN. 1.3.1 Static description The identification and characterization of these functions, which are related to the specification and analysis of these basic and supplementary services, form the first step of the generic description. This part of the generic description is intrinsically static. 1.3.2 Dynamic description The use of a basic or supplementary service generally requires cooperation between functions located in different equipment. The static description of the ISDN capabilities, which will be a list of functions, is not sufficient. It is necessary, in addi- tion, to depict the sequence of events and the activation of func- tions coordinated by suitable inter-equipment signals. This second step is the dynamic aspect of the description. This involves firstly an identification and characterization of the functions and then a method of showing the dynamic interaction between functions. 2 Objectives of the functional description of the ISDN As described in Recommendation I.120, an Integrated Services Digital Network (ISDN) is a network providing end-to-end digital connectivity to support a wide range of telecommunication services. The characterization of ISDN is centered on three main areas: a) the standardization of services offered to users, so as to enable services to be internationally compatible; b) the stadardization of user-network interfaces, so as to enable terminal equipment to be portable [and to assist in a)]; c) the standardization of ISDN capabilities to the degree necesary to allow user-network and network-network inter- working, and thus achieve a) and b) above. The I.200-Series of Recommendations identifies the range of telecommunication services to be offered in an ISDN, namely bearer services, teleservices, and associated supplementary services and the attributes characterizing those services. The I.400-Series of Recommendations describes both the functional and technical aspects of user-network interfaces. This Recommendation defines the ISDN capabilities to support services via interfaces in terms of func- tions. A functional description enables a decoupling of services and ISDN capabilities, and therefore allows an implementation-independent approach. The principal objectives of the ISDN functional method are: 1) to define the ISDN capabilities, by building up a harmonized set of functions that are necessary and sufficient to support telecommunication services by their static and dynamic description; 2) to aid the evolution of ISDN capabilities (modifications, addition of capabilities to support new basic or supplementary services), by organizing this set of functions in an open-ended and modular structure; 3) to aid the standardization of system-independent switching functions between exchanges of differ- ing designs and manufacture; 4) to aid the standardization of interworking standards between switching systems located in different countries; 5) to provide information for the preparation of functional specifications for new telecommunication services; 6) to maximize the exploitation of functions pro- vided and available in switching systems. The transition from an existing network to a comprehensive ISDN may require a period of time extending over one or more decades. Therefore the design of an ISDN will be revolutionary, adding capabilities in a flexible and modular manner. An ISDN may therefore be expected to provide an open-ended set of functional capabilities able to accommodate new needs as they arise at accept- able cost. During a long intermediate period, some functions may not be implemented within a given ISDN. Also, specific arrangements should be used to ensure compatibility with existing networks and ser- vices. An ISDN should also give access to existing services and interwork with existing networks and terminals. 3 Generic description model 3.1 General concepts The ISDN functional description defines a set of capabilities which enable bearer and teleservices to be offered to users (see Recommendation I.210). The services require two different levels of ISDN capabilities viz.: - the low-layer functions (LLF) relate to the bearer services; - the high-layer functions (HLF) together with the lower layer functions relate to the teleservices. In addition, operation and maintenance capabilities are required to support both bearer and teleservices (see Figure 2/I.310). Figure 2/I.310, (N), p. The capabilities of the ISDN need a detailed and rigorous characterization because there is a wide range of standardization issues involved. To achieve the functional objectives described in S 2, the ISDN functional description has been designed to: - define the overall functional characteristics of the ISDN; - be implementation-independent and place no con- straints on national network architectures beyond the network and interface standards given in the I-Series of Recommendations; - take full account of the constraints of existing dedicated networks; - support the layering protocol concepts defined in Recommendation I.320. For this purpose the concept of an ISDN function is used, which is defined as: "A distiguishing characteristic which describes functional capabilities of a given equipment, or system, or network, as seen from the designer point of view." As far as possible, the number of functions should be limited. 3.2 Static description model 3.2.1 Global functions (GF) The description of ISDN capabilities concerns the low layers (1-3) in a global context (see Note), i.e. taking into account all the equipment involved in the communication, according to the pro- tocol reference model. In this context, a global function is defined as: - referring to the ISDN capabilities; - having a global significance in the lower layers. The set of all GFs leads to the description of the total ISDN low layer capabilities. Note - This concept of global function may be extended to describe the higher layer capabilities of ISDN terminals (and net- work capabilities, where these exist). In this case the GF has a global significance inside the higher layers. Figure 3/I.310, (N), p. There are two kinds of GFs: - the Basic Global Functions (BGF), are those glo- bal functions needed to support ISDN basic services. The BGFs are related to ISDN connection types, as indicated in Table 1/I.310; - the Additional Global Functions (AGF), are related to the ISDN capability to support supplementary services. Details of the relationship between AGFs and the ISDN capability to support supplementary services are given in S 4.1.2. 3.2.2 Elementary functions (EF) The introduction of the GF concept allows a general descrip- tion of low layer capabilities. The following is a more detailed description: for each GF, a set of elementary functions is identified as the set of basic ele- ments which are then allocated to different functional entities involved in the communication. GF = (EF1, EF2, EF3, . | | EFn) An EF within this Recommendation is the lowest level of func- tionality. It is allocated to a functional entity involved in sup- porting a telecommunication service. An EF is an intrinsically static description of the capability of performing an action on a resource when defined conditions are met. For building up a GF, each associated EF must be present in one or more functional entities of the ISDN. (In this context the ISDN may include the terminals, the network or specialized service centres.) But in a specific functional entity the complete set of associated EFs need not be present (see for example Figure 4/I.310). Figure 4/I.310, (N), p. 3.2.3 Allocation of EFs This flexibility in construction of EFs allows a specializa- tion of the functions to be allocated to particular functional entities. Because the Recommendations on the architecture of the ISDN (Recommendation I.324) will only specify a functional approach to standardization, the relationship between functional entities and specific equipment is, in general, a national matter. However an important first step in allocation of functions will be the dis- tinction between terminal equipment and the network equipment involved. Recommendation I.324 introduces the functional grouping CRF (connection related functions). The CRF can be local, national transit or international transit. EFs can be associated with each of these. 3.3 Dynamic description model The complete description of ISDN capabilities must include dynamic aspects involved in the process of a call. This association of functional and protocol aspects leads to the use of the following dynamic description method: 3.3.1 Information flow diagrams The operation of basic and supplementary services are described and characterized, as seen from a network point of view, by using information flow diagrams which show the sequence of events occurring in the course of the call. 3.3.2 Executive processes An executive process (EP) corresponds to the particular use of one or more elementary functions within a particular functional entity which always yields specific results. Therefore an EP is characterized by input information it needs for execution and by output information or actions resulting from execution. Executive processes involve (see Figure 5/I.310): a) sequences that link together events producing the activation of an EP, by means of signalling information passed between the function entities; b) the information (or data) actually used: - protocol information (signalling information sent or received by the component); - component information ("network information"); - static information (description of available resources, environment, services, etc.) - dynamic information (elaborated and used during the call handling). The dynamic description of each basic or supplementary service as required in stage 2 of the description method given in Recommendation I.130, based on the above elements, results in a chart showing functional entities involved (e.g. associated with originating and destination exchanges, specialized service centres when required), the signalling information flow passed between them, and the executive processes used inside them. 4 Use of generic description model The analysis of telecommunication services and technological development leads to the identification of the range of required functions. The analysis of all the basic and supplementary services pro- vided by the ISDN will lead to the establishment of a set of ele- mentary functions which can be allocated to different functional entities. The design of a new basic or supplementary service should max- imize the use of the set of existing EFs available to existing sys- tems. This will minimize changes to the systems necessary for introducing these new services. The specifications for new equip- ment designed for providing particular services will have to comply with the set of EFs required for these services. Figure 5/I.310, (N), p. 5 4.1 Identification of ISDN global functions 4.1.1 Basic global functions (BGF) The basic global functions correspond to the ISDN capability to provide the various connection types that support telecommunica- tion services. The functions implemented to support telecommunication ser- vices can be classified into the following categories: - Connection handling: | functions which enable the establishment (set-up), holding and release of connections (e.g. user-to-network signalling). - Routing: | functions that determine a suitable connection for a particular service (call) request, i.e. suitable paths between the various equipments and inside the switching sys- tems to establish end-to-end connections (e.g. called number analysis). - Resources handling: | functions that enable the control of the resources necesary for the use of connections (e.g. transmission equipment, switching resources, data storage equipment). - Supervision: | functions that check the resources used to support the connections, to detect and signal possible problems and to solve them if possible (e.g. transmission error detection and correction). - Operation and maintenance: | functions providing the capability to control the correct working of the services/network as well for the subscribers as for the Administra- tion. - Charging: | functions providing the capability to the Administration to charge the subscribers. - Interworking: | functions providing the capa- bility for both service and network interworking. - Layer 2 and 3 data unit handling: | functions providing handling of layers 2 and 3 data units during the informa- tion transfer phase for the case of packet mode connections. According to this classification, a basic global function is defined as: - referring to an ISDN connection type; - belonging to one of the above categories. Table 1/I.310 shows the total set of BGFs. H.T. [T1.310] TABLE 1/I.310 ISDN basic global functions __________________________________________________________________________ { Connection type Category } CT 1 CT 2 . | | CT n __________________________________________________________________________ Connection handling 1 BGF 1 2 BGF 1 n BGF 1 __________________________________________________________________________ Routing 1 BGF 2 2 BGF 2 n BGF 2 __________________________________________________________________________ Resources handling 1 BGF 3 2 BGF 3 n BGF 3 __________________________________________________________________________ Supervision 1 BGF 4 2 BGF 4 n BGF 4 __________________________________________________________________________ Operation and maintenance 1 BGF 5 2 BGF 5 n BGF 5 __________________________________________________________________________ Charging 1 BGF 6 2 BGF 6 n BGF 6 __________________________________________________________________________ Interworking 1 BGF 7 2 BGF 7 n BGF 7 __________________________________________________________________________ { Layer 2 and 3 data unit handling } 1 BGF 8 2 BGF 8 n BGF 8 __________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 1/I.310, [T1.310], p. 4.1.2 Additional global functions (AGF) The additional global functions corresponds to the ISDN capa- bility to support supplementary services. The classification of AGFs is based on the principle that the support of a supplementary service is considered as being realized by a number of functions distributed throughout the ISDN. The definition of AGFs needs further study. 4.2 Identification of ISDN elementary functions Like GFs, there are two kinds of elementary functions: the basic EFs (i.e. components of BGFs, and possibly AGFs) and the additional EFs (i.e. components of AGFs). Therefore, identification of basic EFs requires a detailed analysis of connection types. Implementation and identification of additional EFs requires a detailed analysis of supplementary services implementation. - Basic EFs: | for each connection type, there are up to 8 BGFs to implement (see Table 1/I.310). Therefore each BGF is composed of basic EFs related to this connection type. However some basic EFs may be common to several connection types (e.g. "called number analysis" belonging to the BGF "routing"). - Additional EFs: | additional EFs form a common set of functional elements available to build up the various AGFs, and thus to implement supplementary services. This grouping of EFs into sets of BGFs and AGFs is illustrated in Figure 6/I.310. The list of EFs so far identified is contained in Annex A, together with a preliminary set of definitions. Figure 6/I.310, (N), p. 4.3 Identification of ISDN executive processes A possible use of the concept of an Executive Process (EP) is the definition of Functional Components (FC) as executive processes that can be invoked by the network to realize a telecommunication service. According to this an FC is a specific example of how to use the EP concept. A functional component is a set of elementary functions per- formed in an order that yields a specified result. An FC always has an invoking and a responding entity. The invoking entity is the entity which acts in response to an FC request from an invoking entity. In defining an FC, the following guidelines should be con- sidered: - FCs are used as building blocks and may be invoked in order to realize a telecommunication service. FCs will have signalling impact and should be structured in such a way that several telecommunication services can use them. In particular, the definition of an FC should as far as possible be independent of any connection type. - A new FC should not be defined if its functional- ity can be provided by one or more existing FCs. As an objective, an FC will not invoke another FC. The relationship between an FC and EFs is shown in Figure 7/I.310. Figure 7/I.310, (N), p. Once invoked, the responding entity will not be affected by unsolicited inputs from the invoking entity. However, the request for execution of an FC may be cancelled by the invoking entity if the request was received. It should also be noted that the functionality of an FC could be invoked by a user equipment, i.e. the invoking entity of an FC could be allocated to user equipment. When an FC affects the user-network interface a service description is needed. Figure 8/I.310 illustrates FCs affecting different interfaces, FC1 affecting the user-network interface, FC2 affecting an internal network interface. It also illustrates that the invoking and responding entities of different FCs may appear in the same func- tional entity. Figure 8/I.310, (N), p. FCs are building blocks, which by themselves are not suffi- cient to provide a service. There is a need for some logic reflect- ing how FCs are coordinated in order to support a given service: this logic is termed service control process concept which can be found in other Recommendations. Annex B gives descriptions of FCs so far identified for the ISDN. 5 Functional realization of basic service requests From the functional point of view, the process involved in satisfying a basic service request in the ISDN can be described as follows: a) A basic service request contains a set of attri- bute values. The appropriate connection type(s) to support the service must be identified. Service request examination: - input: service request containing a set of attri- bute values; - process: examine service request and determine appropriate connection type(s); - output: connection type(s). b) Once selected, the connection type (which has end-to-end significance) can be further broken down into one or more smaller functional components called "connection elements" (see Recommendation I.324). Connection element selection: - input: connection type; - process: determine connection element(s) to form the connection type; - output: connection element(s). c) Each connection element would require a set of functions in order to be established. Function set determination: - input: connection element; - process: select appropriate functions to estab- lish connection element; - output: set of functions. ANNEX A (to Recommendation I.310) A.1 List of identified basic elementary functions and additional elementary functions (EFs) for the ISDN A.1.1 BASIC EFs related to connection types Connection handling BEF100 Characteristics of service requested exami- nation BEF101 Connection elements type determination BEF102 User-network access resources reservation (channels) BEF103 Transit resources reservation BEF104 Communication references handling BEF 104 E: Establish call reference BEF 104 C: Clear call reference BEF105 Establishment control BEF 105 R: Establish connection-return path only BEF 105 F: Establish connection-forward path BEF 150 B: Establish connection-both directions BEF106 Release control BEF107 Service related authorizations examination BEF108 User-network signalling handling (layer 3) BEF109 Inter-exchange signalling handling (user part) BEF110 Supplementary services compatibility check- ing BEF111 Building up of and maintaining dynamic information relating to the call/connection BEF112 Signalling interworking BEF113 Priority BEF114 Queue handling Routing BEF200 ISDN number identification BEF201 Called number analysis (address analysis) BEF202 Routing information examination (if pro- vided) BEF203 Predetermined specific routing BEF204 Connection path selection BEF205 Rerouting Resources handling BEF300 Hold and release of user-network access resources (channels) BEF 300 H: Hold user-network access resources BEF 300 R: Release user-network access resource BEF301 Hold and release of transit resources (circuits) BEF 301 H: Hold transit resources BEF 301 R: Release transit resources BEF302 Insertion and suppression of specific equip- ment BEF303 Tones, announcements and display information BEF304 User-network signalling handling (layer 1-2) BEF305 Inter-exchange signalling handling (message transfer) BEF306 Path search inside switching unit BEF307 Synchronization handling BEF308 Timing handling BEF309 Line service marking BEF310 Real time clock Supervision BEF400 User-network access resources monitoring BEF401 Transit resources monitoring BEF402 Continuity checking BEF403 Detection of congestion BEF404 Semi-permanent connection checking Operation and maintenance BEF500 Management of subscriber data BEF501 Fault report Charging BEF600 Charging management BEF 600 I: Initiate charging BEF 600 C: Cease charging BEF601 Charging registering BEF602 Charging recording BEF603 Billing BEF604 Accounting BEF605 Charging information Interworking BEF700 Rate adaption BEF701 Protocol conversion BEF702 Handling of signalling for interworking BEF703 Numbering interworking BEF704 Special routing algorithms BEF705 Negotiation BEF706 Notification BEF707 Charging for interworking BEF708 Mapping of lower layer comparability A.1.2 AEFs relating to supplementary services AEF00 Insertion and suppression of additional resources (tones etc.) AEF01 Line hunting AEF02 Direct dialling-in AEF03 Address determination AEF04 Subscriber's dedicated storage AEF05 Bridge AEF06 User-network access resource hold AEF07 Hold of communication AEF08 Additional subscriber signalling AEF09 Additional inter-exchange signalling AEF10 Multi-call handling AEF11 Internal call initialization AEF12 Access/route restriction AEF13 Subscriber call data registration AEF14 Data display option A.2 Short description of elementary functions A.2.1 Basic EFs related to connection types A.2.1.1 Connection handling 100 Characteristics of service requested examination Function of a functional entity to determine the required ser- vice characteristics (certain attributes of the bearer service and optional supplementary services) of a call by means of examination of information set by calling terminal. 101 Connection elements type determination Function of a functional entity to determine connection types and connection elements necessary to provide the requested service. 102 User access resources reservation Function of a functional entity to determine the type of user-network access (basic, primary), the state of the resources (channels availability) and to reserve the channel(s) needed for establishing the access connection element. 103 Transit resources reservation Function of a functional entity to reserve the transit connec- tion element, based on the state of resources. 104 Communication references handling Function of a functional entity to assign a local reference (at the access interface) to the call and an internal reference (at the internal interface) to the connection, and to clear these references when the call/connection is cleared/released. 104 E Establish call reference. (For further study.) 104 C Clear call reference. (For further study.) 105 Establishment control Function of a functional entity to set up a connection through the functional entity. 105 R Establish connection-return path only. (For further study.) 105 F Establish connection-forward path. (For further study.) 105 B Establish connection-both direction. (For further study.) 106 Release control Function of a functional entity to release a connection through the functional entity. 107 Service related authorization examination Function of a functional entity to determine the authorization (calling or called user) relating to basic and supplementary ser- vices that have been subscribed to. 108 User-network signalling handling (layer 3) Function of a functional entity to support the layer 3 proto- col of the user-network signalling system. Note - For layers 1 and 2, see S A.2.1.3, Resources handling. 109 Inter-exchange signalling handling (user part) Function of a functional entity to support the user part of the inter-exchange signalling system. 110 Supplementary services compatibility checking Function of the network to check the compatibility of requested supplementary services, e.g.: - with requested bearer service to teleservice; - with other requested supplementary services; and to verify coherence between parameters that may be associated. 111 Building-up of and maintaining dynamic information related to the call/connection Function of a functional entity to compile information related to the call/connection, e.g.: - resources needed (connection type, connection elements, channels, circuits); - details of call in progress; - supplementary services effected and associated parameters. 112 Signalling interworking Function of a functional entity to support interworking func- tions between signalling systems. 113 Priority Function of a functional entity to handle specific calls with priority (e.g. in the case of overload or degraded mode of opera- tion). 114 Queue handling Function of a functional entity to store requests in a queue, in order to handle this information later in a predefined order. A.2.1.2 Routing 200 ISDN number identification Function of a functional entity to identify the ISDN number of the user-network interface. This information is limited to that included within the ISDN numbering plan. 201 Called number analysis Function of a functional entity to analyse called ISDN number sent by the calling terminal in the call set-up phase. 202 Routing information examination Function of a functional entity to analyse routing information that may be sent by the calling terminal and that has an effect on path selection. 203 Predetermined specific routing Function of an exchange to select a specific routing according to the information received from the calling terminal (for example routing towards operators, access points, an interworking unit, an operational or maintenance unit, etc.). 204 Connection path selection Function of a functional entity to select the transit outgoing part relating to connection types to be used, and the overall path through the network. 205 Rerouting Function of a functional entity to select a new connection path through the network depending on changed conditions during call set-up or information transfer phases. A.2.1.3 Resources handling 300 Hold and release of user-network access resources (channels) Function of a functional entity to hold the access channel(s) reserved to support the communication, and to release it at the end of this communication. 300 H Hold user-network access resource. (For further study.) 300 R Release user-network access resource. (For further study.) 301 Hold and release of transit resources (circuits) Function of a functional entity to hold the circuit(s) reserved to support the communication at the transit connection element and to release it at the end of this communication. 301 H Hold transit resources. (For further study.) 301 R Release transit resources. (For further study.) 302 Insertion and suppresion of specific equipment Function of a functional entity to insert or remove specific equipments particularly to satisfy the service request invoked by the user. Examples of such equipment include: - echo suppressers; - A-u law conversion units (change of A/D conver- sion); - interworking unit; - storage unit. 303 Tones, announcements and display information Function of a functional entity to provide call progress information in one or more of the following ways: - a tone is an audible (call progress) indication comprising one or more discrete frequencies but excluding speech; - a recorded announcement is an audible indication in the form of speech or music; - display information is (call progress) informa- tion set to the user which is displayed visually. Definitions of the other topics are not yet available. 304 User-network signalling handling (layers 1-2) Functions of a functional entity to support layers 1 and 2 of the user-network signalling system. 305 Inter-exchange signalling handling (message transfer) Function of a functional entity to support the messages transfer part of the inter-exchange signalling systems. 306 Path search inside switching unit Function of a functional entity to select an internal connec- tion inside the switching unit. 307 Synchronization handling Function of a functional entity to provide synchronization between different functional entities; and Function of a functional entity to provide its own internal synchronization functional entity. 308 Timing handling Function of a functional entity to provide timing between time instances involved in calls. 309 Line service marking Functions of a functional entity to store for each customer the data on the parameters of the bearer and teleservices that are subscribed to. The store also contains the data on the parameters of the basic bearer and teleservices that are subscribed to by the customer. In addition, it contains the binary information (i.e. subscribed to or not) for a range of supplementary services which the subscriber can use. In general this data does not contain information on the type of subscriber terminal, but it may contain information on the type of access (basic, primary rate, etc.), the type of NT2 (simple, intelligent, etc.) and the attributes of the services subscribed to. 310 Real time clock Function of a functional entity to provide real time informa- tion. A.2.1.4 Supervision 400 User-network access resources monitoring Function of a functional entity to check the correct operation of subscriber access resources. 401 Transit resources monitoring Function of a functional entity to check the correct operation of the transit resources. 402 Continuity checking Function of a functional entity to control the checking opera- tions relating to the continuity of a connection. 403 Detection of congestion Function of a functional entity to detect congestion during the selection of a connection path. 404 Semi-permanent connection checking Function of a functional entity to check the availability of a given semi-permanent connection (e.g. passive continuity checking). A.2.1.5 Operation and maintenance 500 Management of subscriber data Function of a functional entity to manage subscriber data related to services. Examples include: - in/out of service - number translation - changing of subscriber data. 501 Fault report Function of a functional entity to register the cause if an attempt to set up a call fails. A.2.1.6 Charging | (the groupings below require further study) Function of the network to determine, collect and store the charging information. The following features are involved in this process: 600 Charging management Function of a functional entity to determine by means of cer- tain parameters the charging mode (free of charge, ordinary, peak, reduced rate charge, etc.). These parameters include service type, class of customer, time information, distance, etc. 600 I Initiate charging. (For further study.) 600 C Cease charging. (For further study.) 601 Charging registering Function of a functional entity to register the details of the call (both short- and long-term storage). 602 Charging recording Function of a functional entity to format the charging details in a standardized way. 603 Billing Function of functional entity to calculate the variable charges to the customer which depend on the use of a service and on the fixed costs of the subscription. Both of these are accumulated over a fixed period of time. This billing is associated with the subscriber and not with a user-network interface, a terminal, etc. 604 Accounting Function of a functional entity to analyse, store and forward information relating to the use of inter-network resources between the different Administrations involved in a call. 605 Charging information Function of the network to indicate the user the amount of the charge involved in the (current) use of the service. A.2.1.7 Interworking Functions that permit the establishment of end-to-end connec- tions when an ISDN and a dedicated network are involved. This requires the provision of the basic elementary features (BEFs) which are described below and others that have been defined already (service request examination, signalling interworking, called number analysis, routing information examination, insertion and suppresion of interworking units, etc.). 700 Rate adaption Function of a functional entity to adapt, according to a cer- tain method, the user/dedicated network bit rates to the ISDN bit rates. 701 Protocol conversion Function of a functional entity to support mapping functions between interfaces. 702 Handling of signalling for interworking Function of a functional entity to handle signalling informa- tion for interworking (interpretation, termination, generation). 703 Numbering interworking Function of a functional entity to support interworking func- tions between numbering plans. 704 Special routing algorithms | (For further study) 705 Negotiation | (For further study) 706 Notification | (For further study) 707 Charging for interworking | (For further study) 708 Mapping of lower layer comparability (LLC) lists | (For further study) A.2.2 Additional EFs relating to supplementary services AEF00 Insertion and suppression of additional resources (tone, etc.) Note - A definition has already been proposed for a basic EF. It needs to be considered if this feature should also be regarded as an additional feature. With respect to supplementary services a proposed description is: Function of an exchange to manage (reserve, insert, release) additional resources related to the handling of supplementary ser- vices. AEF01 Line hunting Function of a functional entity to select, on receipt of a certain terminal address, one free line in a multi-line group corresponding to that number. AEF02 Direction dialling-in Function of a functional entity to transfer address and other appropriate call handling information to a PABX for the purpose of setting up a call to its extensions without assistance of the PABX operator. AEF03 Address determination Function of a functional entity to determine the destination number(s) called by means of short-long number conversion or of association between one code and one list of numbers. AEF04 Subscriber's dedicated storage Function of a functional entity to store details in addition to the LSM (line service marking) for each customer and which con- tains the registration data for supplementary services that have been subscribed to (i.e. listed in the LSM as binary 1). For exam- ple, it would contain a list of abbreviated numbers. AEF05 Bridge Functions of a functional entity to allow more than two indi- vidual participants on the same call. AEF06 User-network access resource hold Function of a functional entity to hold the user-network access resources (channel) involved in a communication in a waiting condition and, at the same time, to release the network connection. The call reference information is maintained. AEF07 Hold of communication Function of a functional entity to initiate the function to hold one, or more, of the other parties engaged in an established call in a waiting condition without the disestablishment of the call, and at the same time to release the initiating user-network access resource. AEF08 Additional subcriber signalling Functions of an exchange to send or receive specific signal- ling information to or from the user, related to the handling of supplementary services. (Additional signalling to the subscriber signalling for basic calls.) AEF09 Additional inter-exchange signalling Function of a functional entity to send or receive specific signalling information to or from another component, related to the handling of supplementary services. (Additional signalling to the inter-exchange signalling for basic calls.) AEF10 Multi-call handling Function of a functional entity to set up and manage several connections by means of a single procedure. (In response to only one call request.) AEF11 Internal call initialization Functions of a functional entity to initiate the setting-up of a connection without receiving a call request from the user [e.g. used for Completion of Call to Busy Subscribers (CCBS) sup- plementary service and alarm call services]. AEF12 Access/route restriction Function of a functional entity to reject incoming or outgoing calls, either: - totally for all services, or - for one type of service (e.g. telephony). AEF13 Subscriber call data registration Function of a functional entity to register and display or print subscriber call data. Subscriber call data is information related to specific calls. This data is collected by the same func- tional entity as that which contains the EF "subscriber call data registration". AEF14 Data display option Functions of a terminal to display information to the user. ANNEX B (to Recommendation I.310) Descriptions of identified functional components (FCs) for the ISDN B.1 Hold invocation This FC allows to invoke the disconnection of an established communication channel between the initiating and responding enti- ties and its resevation for subsequent reuse for another (or the previous) communication. This implies the interruption of the com- munication for an existing connection. The initiating entity provides the information required to identify the connection to be interrupted. The successful application of this FC results in: - the disconnection of the communication channel between the initiating and the responding entities; - the reservation of the disconnected communication channel for the initiating entity (for originating or terminating connections); - an indication of successful completion from the responding entity. The unsuccessful application of this FC results in a response containing the failure details. Note - The exact definition of communication channel is for further study. B.2 Retrieve This FC allows the initiating entity to request the reconnec- tion of a communication channel between the initiating and respond- ing entities in order to re-establish a previously held connection. The initiating entity provides the information required to identify the connection to be re-established over the reserved com- munication channel. The successful completion of this FC results in: - the re-establishment of the connection. The com- munication channel will be the reserved channel whenever possible. If exceptionally an alternate channel had to be allocated, the responding entity will indicate its identity; - an indication of succesful completion from the responding entity. The unsuccessful application of the FC results in a response containing the failure details. The possible re-establishment of a connection over another communication channel than the reserved one is for further study. B.3 Join This FC allows to invoke the addition of a connection in order to form, or to add to, a multiparty connection of the same connec- tion type. The initiating entity provides all information required to identify the connection to be joined to the multi-party connection. The responding entity executes the functions to join the connection and provides the initiating entity with the information of the result of the execution. Upon successful completion, all connections involved are con- nected together. A successful indication is returned to the ini- tiating entity. Upon unsuccessful completion, the status of last connection remains unchanged and an unsuccessful indication is returned to the initiating party with failure cause(s). B.4 Split This FC allows the initiating entity to separate a connection from a multiparty connection. The initiating entity provides the identities of the mul- tiparty connection and the connection to be separated. The respond- ing entity executes the functions to separate the designated con- nection from the multiparty connection. Upon successful completion the designated connection is separated from the multiparty connection. The separated connection is put on hold; the remainder of the multiparty connection remains unchanged. A successful indication is returned to the initiating entity. Upon unsuccessful completion, the status of the multiparty connection remains unchanged and an unsuccessful indication is returned to the initiating party with failure cause(s). B.5 Transfer This FC allows the initiating entity to reassign the ownership of a call to an elected subscriber. The initiating entity provides the identity of the connection to be transferred and the identity of the elected subscriber. Successful completion of this FC results in: - the elected subscriber assumes the subsequent charges; - the initiating entity receives a successful con- firmation from the responding entity; - the initiating entity is disconnected from the transferred connection. Upon unsuccessful completion, the status of the connection remains unchanged and an unsuccessful indication is returned to the initiating party with failure cause(s). Note - The concept of ownership requires further investiga- tion in relation to control and charging aspects. B.6 Notify This FC provides the capability for one entity to inform another entity of some action or condition without requiring a response from the receiving entity. Note - A more precise definition of this FC is required. B.7 Enquire This FC provides the capability for the initiating entity to request information from another entity, without changing that information. The initiating entity provides to the responding entity what information is requested and other information the responding entity needs to respond successfully. For example, in requesting information from the responding entity about busy/idle status of an interface, the initiating entity provides information uniquely identifying that interface. Upon successful completion, the responding entity returns to the initiating entity the requested information. Upon unsuccessful completion, the responding entity returns an unsuccessful indication including failure cause(s). B.8 Adjourn This FC provides the capability for the initiating and responding entities to retain knowledge of a call ( or call attempt) sufficient for subsequent re-establishment. The initiating entity provides to the responding entity the identity of the call to be adjourned. Upon successful completion, all channels previously allocated for the call (or call attempt) are released and the knowledge of the call is retained. Upon unsuccessful completion, the status of the call remains unchanged and an unsuccessful completion indication with failure cause(s) is returned to the initiating entity. B.9 Restart This FC provides the capability for the initiating entity to allocate resources to restore an adjourned call. The initiating entity provides the identity of the adjourned call to be restored. Upon successful completion, the necessary resources to re-establish the call are restored and the call set-up process resumes. Upon unsuccessful completion, the adjourned call is released and a failure indication returned to the initiating entity includ- ing failure cause(s). B.10 Monitor This FC allows the initiating entity to watch for an event (e.g. transition to idle, transition to busy) on a resource. The resource being monitored may be a network resource or a user resource. The initiating entity provides the identity of the resource to be monitored, the event to be reported, and optionally the period of the monitor function. If the event to be monitored is the avai- lability of a resource, the initiating entity may also request the resource be reserved when it becomes available. The responding entity will indicate acceptance or rejection of the monitor request immediately and subsequently check the states of the resource dur- ing the period specified. Upon successful completion, the responding entity will notify the intiating entity if the period expired before the monitored event occured. Upon unsuccessful completion, an unsuccessful indication is returned to the initiating entity with failure cause(s). B.11 Reroute The FC allows the initiating entity to redirect an incoming call to an alternate address before the call is established. The initiating entity provides the identity of the incoming call and the aternate address to where the incoming call is to be redirected. Upon successful completion, the incoming call is connected to the alternate address. Upon unsuccessful completion, the responding entity provides to the initiating entity the cause of failure and the call process- ing of the incoming call is resumed. BLANC SECTION 2 REFERENCE MODELS Recommendation I.320 ISDN PROTOCOL REFERENCE MODEL (Malaga-Torremolinos, 1984; amended at Melbourne, 1988) 1 Introduction The objective of the ISDN Protocol Reference Model (ISDN PRM) is to model the interconnection and exchange of information - including user information and control information - to, through or inside an ISDN. Communicating entities may be: - ISDN users; - an ISDN user and a functional entity within an ISDN, e.g. network control facilities; - an ISDN user and a functional entity inside or outside an ISDN, e.g. an information storage/processing/messaging facility; - various functional entities in an ISDN, e.g. a network management facility and a switching facility; - an ISDN functional entity and an entity located in or attached to a non-ISDN network. The purpose of communications between these functional enti- ties is to support the telecommunication services introduced in Recommendations I.211 and I.212, by providing ISDN capabilities as defined in Recommendation I.310. Examples of these capabilities are: - circuit-switched connection under the control of common channel signalling; - packet-switched communication over B-, D- and H-channels; - signalling between users and network-based facilities (e.g. information retrieval systems such as Videotex, operations data bases such as directory); - end-to-end signalling between users (e.g. to change mode of communication over an already established connec- tion); - combinations of the above as in multi-media com- munication, whereby several simultaneous modes of communication can take place under common signalling control. With such diversity of ISDN capabilities (in terms of informa- tion flows and modes of communication), there is a need to model all these capabilities within a common framework (i.e. reference model). This would enable the critical protocol architectural issues to be readily identified and facilitate the development of ISDN protocols and associated features. It is not intended as a definition of any specific implementation of an ISDN or of any sys- tems or equipment in, or connected to, an ISDN. Examples of applications of this model are included in this Recommendation. 2 Modelling concepts 2.1 Relationship with the X.200-Series The ISDN Protocol Reference Model (ISDN PRM) and the Open Sys- tems Interconnection Reference Model (OSI RM) for CCITT Applica- tions, defined by Recommendation X.200, have both commonalities and differences. Both the ISDN PRM and the OSI RM organize communications func- tions into layers and describe the relation of these layers with respect to each other. However, the scope of the ISDN PRM is dif- ferent from the scope of the OSI RM. The scope of the ISDN PRM is to model information flows across the range of telecommunication services defined in the I.200-Series. These are bearer services, teleservices and supple- mentary services. This description necessarily incorporates ISDN-specific characteristics not encountered in other network types. Among these characteristics are multi-service types of com- munications which include voice, video, data and multi-media com- munications. The scope of the OSI RM is not associated with any particular network type of the OSI PRM is tied to data communications and so, in this respect, its scope is more specific than the ISDN PRM. The OSI is used to model data communications between open systems in an ISDN environment. The relative scopes of the two models are illustrated by Figure 1/I.320. The existence of a common intersection shows that these models coexist and overlap. Figure 1/I.320, (N), p. However, in spite of these differences in scope, a number of concepts and the associated terminology which have been introduced in Recommendations X.200 and X.210 are fully applicable to the ISDN PRM. They include the concept of layer, layer service (Recommendation X.200), and the notions of service primitive, peer entity and peer protocol (Recommendation X.210). Note - The relation between service primitives and functional components introduced in Recommendation I.310 requires further study. The layer identification used in Recommendation X.200 is lim- ited in this Recommendation to the use of layer numbers. Layer titles (e.g. network layer) as used in Recommendation X.200 are sometimes misleading in the ISDN context, and have not been used here. The following ISDN needs have to be specifically catered for in Recommendation I.320: - information flows for out-of-band call control processes, or more generally, information flows among multiple related protocols; - information flows for selection of connection characteristics; - information flows for re-negotiation of connec- tion characteristics of calls; - information flows for suspension of connections; - information flows for overlap sending ; - information flows for multi-media calls; - information flows for asymmetric connections; _________________________ Note that the term "network" in the ISDN corresponds to "sub-network" in the OSI terminology. - information flows for network management (e.g. change over and change back) and for maintenance functions (e.g test loops); - information flows for power activation/deactivation; - interworking; - switching of information flows; - new layer service definitions for non-data ser- vices; - application to other than end-systems, e.g. sig- nal transfer points (STPs) and interworking points; - information flows for multi-point connections; - information flows for applications such as: i) voice (including A/u law conversion), ii) full motion video, iii) transparent flow, IV telex. 2.2 Control and user planes The support of out-of-band signalling and the ability to activate supplementary services during the active phase of the call imply a separation between control information and user informa- tion. The notion of plane - control plane, or C-plane, and user plane, or U-plane - is introduced to reflect this. The main rationale for protocols within the user plane is the transfer of information among user applications, e.g. digitized voice, data and information transmitted between users. This infor- mation may be transmitted transparently through an ISDN, or it may be processed or manipulated, e.g. A/u law conversion. The main rationale for protocols within the control plane is the transfer of information for the control of user plane connec- tions, e.g. in: - controlling a network connection (such as estab- lishing and clearing down); - controlling the use of an already established network connection (e.g. change in service characteristics during a call such as alternate speech/unrestricted 64 kbit/s); - providing supplementary services. In addition to user information, any information which con- trols the exchange of data within a connection, but otherwise does not alter the state of this connection (e.g. flow control), per- tains to the U-plane. All control information which involves resource allocation/deallocation by the ISDN pertains to the C-plane. 2.3 Local and global significance A key characteristic of the ISDN is that, due to the integra- tion of telecommunication services, the facilities to be provided depend on whether the adjacent entity, or a remote entity, is involved: different services, possibly using different routes, may have to be provided accordingly. An example is a telecommunication service, which can be supported by various network capabilities, (e.g. a telematic service supported either by circuit or packet facilities), or an ISDN connection based on various types of basic connection components (e.g. analogue and digital circuits for a speech connection). As a consequence, the control information handled by an entity may concern: - an adjacent functional entity, in which case it is said to have local significance; - a remote (non-adjacent) functional entity, in which case it has global significance. The significance concept is illustrated by Figure 2/I.320 The notion of significance applies to control plane informa- tion only. As an example from the ISDN user's point of view: - the overall service to be provided to users has a global significance; - the control of any resources to be used at the user-network interface has local significance; and, from the network's point of view: - the overall service to be provided by the ISDN (ISDN connection types, as introduced in Recommendation I.340) has a global significance; - the handling of connection elements has local significance. Figure 2/I.320, (N), p. Depending on their functional requirements, supplementary ser- vices relate to either the local, or global perspective. For exam- ple: - completion of calls to busy subscribers (CCBS) or user-to-user signalling (UUS) have global significance; - call waiting has local significance. Global information falls into three classes: 1) the information is transported transparently; 2) the information may be processed, but remains unchanged (e.g. teleservice); 3) the information may be altered (e.g. destination number in relation with freephone or call forwarding supplementary services). 3 Model The ISDN PRM is represented by a protocol block which incor- porates the concepts of layer, significance and plane described above. Such a protocol block can be used to describe various elements in the ISDN user premises and the network [e.g. terminal equipment (TE), ISPBX network termination (NT), exchange termination (ET), signalling point (SP) and signalling transfer point (STP), etc.]. 3.1 Generic protocol block The considerations above lead to the introduction of the con- cept of significance in combination with planes; the result is a splitting of the control plane into two parts: a local control (LC) plane, and a global control (GC) plane, in addition to the user (U) plane. The layering principles apply in each of these planes: each plane can potentially accommodate a 7-layer stack of protocols. A plane management function is required to allow coordination between the activities in the different planes. Examples of plane manage- ment function are: - the decision on whether an incoming information is relevant to the LC- or GC-plane, - allowing communication between C- and U-planes, for synchronization purposes. The Generic protocol block is represented in Figure 3/I.320. Note - The plane management function should not be confused with the system management as introduced to model OSI management. The following remarks apply: 1) Some layers may be empty, i.e. they provide no functionality. For example, it is likely that not all seven layers are required to serve the LC-plane requirements; however, entities communicating in this plane are application layer entities. Note that this is not in contradiction with the OSI RM. 2) An element (either in the network, or in user premises) does not have to support in all cases protocols of LC-, GC- and U-planes: some may ignore one or even two of these planes. For example, a network service centre accessed to provide a supple- mentary service (e.g. freephone) will be concerned by the LC plane only, and will have no knowledge of the other two planes. 3) A network element - unless it provides a high layer function (HLF) - will generally not support any U-plane pro- tocol above layer 3. 4) The need for application processes specific to each plane, or for application processes able to access several planes, is for further study. Figure 3/I.320, (N), p. 3.2 Relations between layers in one plane Adjacent layers within a plane communicate using service prim- itives. If a layer is empty the primitive is mapped directly onto a primitive to the next layer. Further study is required on which layer services have to be specified in order to describe a telecommunication service. 3.3 Relations between planes Starting from GC-plane requirements, an entity will derive the LC-plane requirements, and the facilities that have to be provided for the support of U-plane lower layers. For example, in order to provide an ISDN connection (GC-plane), an exchange will have to identify the required basic connection component (LC-plane). This relation is made via the plane management function. Informations in different planes need not be carried by dis- tinct physical/logical means in all cases. For example: - control and user information may use the same support, e.g. when in-band signalling is used, or when user infor- mation is carried on a D-channel; - LC and GC information share the same support when the LC-plane pass-along facility is used; - ISPBX-to-ISPBX control information appears as U-plane information to the ISDN. 3.4 Data flow modelling For further study. 4 ISDN management For further study. 5 Interworking A number of particular interworking situations should be con- sidered: - internetworking with an OSI network; - interworking with an non-ISDN terminal; - interworking between two ISDNs which do not pro- vide the same set of facilities; - interworking involving a network-provided inter- working function to support high-layer and/or low-layer facilities. 5.1 General All the interworking situations mentioned above are covered by the model illustrated by Figure 4/I.320. The service S may be: - the initially required telecommunication service (TS), if both networks are able to provide it (F is then empty); - a telecommunication service resulting from a negotiation process, which both networks are able to provide (F is then empty); - a service which is required to support the telecommunication service to be provided, which is offered by both networks, but by means of different capabilities in the two net- works. The service S is provided: - by means of functions F1 and protocol(s) P1 in network 1; - by means of functions F2 and protocol(s) P2 in network 2. The interworking function (IWF) maps the facilities offered by F1 and F2. Figure 4/I.320, (N), p. 13 Two kinds of interworking can take place: 1) a one-stage interworking, where the calling user is not explicitly aware that an interworking function is required; 2) a two-stage interworking, where the calling user has a dialogue with the interworking function prior to exchanging control information with the destination user. The model applies to both cases. Interworking may involve the GC-plane, and/or the U-plane. In an interworking situation, the GC-plane has to: - determine the telecommunication service to be provided (agreed telecommunication service): this may imply service negotiation; - identify the interworking situation, i.e. the fact that more than one network is involved, and that for some service S required to support the telecommunication service, two adjacent networks do not use the same underlying facilities; - locate and invoke an IWF capable of mapping the facilities in the two networks. In each network, the GC-plane facilities will provide the functions and protocols (Fi and Pi) required to support service S; this will result in different (and independent) requirements on the LC-plane in each network. In the two-stage interworking case, the GC-plane information is "consumed" by the IWF during the first phase, and is forwarded (with or without modification) during the second phase. Whenever interworking in the U-plane is involved, the follow- ing differences apply in the two cases: - one-stage interworking: in this case only the first three layers (at most) may be involved for the provision of the requested end-to-end service. No HLF is required. - two-stage interworking: in this case the first stage is the establishment of the U-plane facilities between the calling user and the IWF. High layer functions (HLF) and protocols may be involved, in which case the IWF acts as a substitute for the called user. 5.2 Relationships with the OSI RM The OSI RM, seen from the ISDN PRM point of view, appears not to be in contradiction with the latter, but contains some restric- tions which stem from the fact that it does not have the same scope: 1) The C- and U-planes are not separated, since the C- and U-plane information in one layer (n ) always maps onto the U-plane information of the layer below (n - 1). 2) The concept of significance does not explicitly appear; however control informations (e.g. in layer 3) include both "local" informations and informations which are carried end-to-end transparently or take part in the definition of the overall service provided to the user (e.g. throughput). 3) The C- and U-plane informations in one layer (n ) map onto the U-plane informations of the layer below (n - 1). Interworking between the OSI RM and ISDN PRM takes place in the following situations: - internetworking with a specialized network (e.g. PSPDN) which respects the OSI RM: the reference points involved are K/L; - interworking with an "OSI terminal" via a termi- nal adaptor: the reference point is then R; - the interworking of an ISDN terminal on the S reference point which conforms to the OSI reference model is for further study. In each case, the interworking function (an IWF or a TA) has to map information flows of one model onto information flows of the other. 5.2.1 Interworking at reference point K/L For further study. 5.2.2 Interworking at reference point R In the case when a user application, running an OSI system, requires network services across the ISDN, the originating user application will address the terminating application as a destina- tion user. In the OSI system, the application is considered as an ISDN user - a communicating functional entity in the PRM. The GC information pertinent to the higher layer OSI applica- tion is carried in the U-plane to the destination application. The GC information pertinent to the network service required is carried in the C-plane with LC information. The OSI system requests the network service from the ISDN by placing a service request to both the LC-plane and the U-plane (Figure 5/I.320). The distribution of the information to the appropriate planes is made by the plane management function access point to the OSI system. 6 Examples Applications of the PRM to the following examples is for further study. 6.1 Basic call situations | (no supplementary service, no interworking) - circuit service (see Figure 6/I.320) - packet service - multi-bearer capability - data base access. Figure 5/I.320, (N), p. 14 Figure 6/I.320, (N), p. 15 6.2 More elaborate situations - supplementary services: - completion of calls to busy subsribers (CCBS); - three-party service; - PABX facilities; - OAM (operational, administrative and maintenance) applications. 6.3 Interworking - at reference point R (Teletex terminal): - with a PSTN; - with a PSPDN (Videotex); - inside an ISDN (provision of an HLF by the net- work); - of public ISDN with other networks (a possible example is given in Figure 7/I.320). Figure 7/I.320, (N), p. MONTAGE: Rec. I.324 sur le reste de cette page