2. SECTION 2 - REFERENCE MODELS 2.1 Recommendation I.320 ISDN PROTOCOL REFERENCE MODEL 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 entities is to support the telecommunication ser- vices introduced in Recommendations I.211 and I.212, by providing ISDN capabilities as defined in Recommenda- tion 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 connection); - combinations of the above as in multi-media communication, whereby several simultaneous modes of communication can take place under common signalling control. With such diversity of ISDN capabilities (in terms of information 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 systems 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 (PRM) and the Reference Model of Open Systems Interconnection for CCITT Appli- cations (OSI RM), defined by Recommendation X.200, have both commonalities and differences. Both the ISDN PRM and the OSI RM organize communications functions into layers and describe the relation of these layers with respect to each other. However, the scope of the ISDN PRM is different 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 Supplementary Services. This description necessarily incor- porates ISDN-specific characteristics not encountered in other network types. Among these characteristics are multi- service types of communications which include voice, video, data and multi-media communications. The scope of the OSI RM is not associated with any particular network type1. In that sense it is less specific than the ISDN PRM. Further, the scope of the OSI PRM is tied to data communications and so, in that sense, its scope is more specific than the ISDN PRM. The OSI PRM - that application is to model data communications between open systems in an ISDN environment. The relative scopes of the two models are illustrated by Figure1/I.320. The existence of a common intersection shows that these models coexist and overlap. FIGURE 1/I.320 Applicability of OSI protocols to ISDN 末末末末末末 1 Note that the term "network" in the ISDN corresponds to "sub-network" in the OSI terminology. 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 (X.200), and the notions of service primitive, peer entity and peer protocol (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 limited in this Recommendation to the use of layer num- bers. 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 mul- tiple related protocols; - information flows for selection of connection characteristics; - information flows for re-negotiation of connection 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; - information flows for network management (e.g. change over and change back) and for maintenance func- tions (e.g test loops); - information flows for power activation/deactivation; - interworking; - switching of information flows; - new layer service definitions for non-data services; - application to other than end-systems, e.g. signal transfer points (STPs) and interworking points; - information flows for multi-point connections; - information flows for applications such as: - voice (including A/ｵ law conversion), - full motion video, - transparent, - telex. 2.2 Control and user planes The support of outband signalling, the ability to activate supplementary services during the active phase of the call, imply a separation between control information and user information. 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 information may be transmitted trans- parently through an ISDN, or it may be processed or manipulated, e.g. A/ｵ conversion. The main rationale for protocols within the control plane is the transfer of information for the control of user plane connections, e.g. in: - controlling a network connection (such as establishing 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 control the exchange of data within a connection, but otherwise do not alter the state of this connection (e.g. flow control), pertain to the U-plane. All control infor- mation which involve resource allocation/deallocation by the ISDN pertain to the C-plane. 2.3 Local and global significance A key characteristic of the ISDN is that, due to the integration 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 Local <-----------------> Global <--------------------------------------> OE = Originating Functional Entity AE = Adjacent Functional Entity RE = Remote Functional Entity FIGURE 2/I.320 Significance The notion of significance applies to control plane information only. As an example: - from the ISDN user's point of view: - the overall service to be provided to users has a globalsignificance; - the control of any resources to be used at the user-network interface has local significance; - 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. Depending on their functional requirements, supplementary services relate to either the local, or global per- spective. For example: - CCBS or user-to-user signalling 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. The model The ISDN protocol reference model (PRM) is represented by a protocol block which incorporates the concepts of layer, significance and plane described hereabove. Such a protocol block can be used to describe various elements in the ISDN user premises and the network (e.g. ter- minal 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 concept of significance in combination with planes; the result is a splitting of the control plane into two parts: a local control plane (LC), and a global control plane (GC), in addition to the user plane (U). The layering principles apply in each of these planes: each plane can potentially accommodate a 7-layer stack of pro- tocols. A plane management function is required to allow coordination between the activities in the different planes. Exam- ples of plan management 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 on Figure 3/I.320. FIGURE 3/I.320 Generic Protocol Block 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 enti- ties. 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 supplementary 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 an HLF - will generally not support any U-plane protocol 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. 3.2 Relations between layers in one plane Adjacent layers within a plane communicate using service primitives. 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 telecommunica- tion 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 distinct physical/logical means in all cases. For example: - control and user informations may use the same support, e.g. when inband signalling is used, or when user information is carried on a D-channel; - LC and GC informations 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 considered: - internetworking with an OSI network; - interworking with an non-ISDN terminal; - interworking between two ISDNs which do not provide the same set of facilities; - interworking involving a network-provided interworking 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. FIGURE 4/I.320 Interworking Model (1) Note - This reference point is an S/T reference point when considering interworking between ISDNs, or service interworking within an ISDN. 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 networks. 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. 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 ser- vice S; this will result in different (and independent) requirements on the CL-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 one. Whenever interworking in the U-plane is involved the following 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 restrictions 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 terminal 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 destination user. In the OSI system, the application is considered an an ISDN user - a communicating functional entity in the PRM. The GC information pertinent to the higher layer OSI application is carried in the U-plane to the destination application. The GC information pertinent to the network service required is carried in the control plane with LC control 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. The Plane Management Function is responsible for providing an OSI Service Access Point to the OSI system. Figure 5/I.320 OSI Reference Model and ISDN Protocol Reference Model 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. 6.2 More elaborate situations - supplementary services CCBS 3-party service - PABX facilities - OA&M 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 network). Legend: C - Local or Global Control depending on the destination functional entity LC - Local Control GC - Global Control M - Plane Management Function NU - Network User Plane PU - PSN User Plane TU - Terminal User Plane Note - For simplicity reasons, NTI functional units are not shown. FIGURE 7/I.320 A protocol reference model example showing the underconnection of public and private ISDNs Function 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 connection 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. It also contains the binary information (i.e. subscribed to or not) for a range of sup- plementary service which the subscriber can use. In general this data does NOT contain information on the type of sub- scriber's terminal, but it may contain information on the type of access (basic, primary rate, etc.), the type of NT2 (simple, intelligent, etc.) and the attributesof the services subscribed to. 310 real time clock Function of a functional entity to provide real time information. 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.