WPCL 2BJ|x ` H   x|@  6'6' 2.HSECTION 2 REFERENCE MODELS 2.1HRecommendation I.320 3ISDN PROTOCOL REFERENCE MODEL 1.HIntroduction  8 HThe 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. HCommunicating entities may be: HH© ISDN users;   HH©  an ISDN user and a functional entity within an ISDN, e.g. network control facilities;   HH©  an ISDN user and a functional entity inside or outside an ISDN, e.g. an information storage/processing/messaging facility;   HH©  various functional entities in an ISDN, e.g. a network management facility and a switching facility;   HH©  an ISDN functional entity and an entity located in or attached to a nonISDN network.  `   H HThe purpose of communications between these functional entities 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:   HH©  circuitswitched connection under the control of common channel signalling;   HH©  packetswitched communication over B, D and Hchannels;  ( HH©  signalling between users and networkbased facilities (e.g. information retrieval systems such as Videotex, operations data bases such as directory);   HH©  endtoend signalling between users (e.g. to change mode of communication over an already established connection);   HH©  combinations of the above as in multimedia communication, whereby several simultaneous modes of communication can take place under common signalling control.  `   X HWith 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. HExamples of applications of this model are included in this Recommendation. 2.HModelling concepts 2.1HRelationship with the X.200Series HThe ISDN Protocol Reference Model (PRM) and the Reference Model of Open Systems Interconnection for CCITT Applications (OSI RM), defined by Recommendation X.200, have both commonalities and differences. HBoth 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. HThe scope of the ISDN PRM is to model information flows across the range of telecommunication services defined in the I.200Series. These are Bearer Services, Teleservices and Supplementary Services. This description necessarily incorporates ISDNspecific characteristics not encountered in other network types. Among these characteristics are multiservice types of communications which include voice, video, data and multimedia communications. HThe 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. HThe 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. IFIGURE 1/I.320 P =Applicability of OSI protocols to ISDNă  1 Note that the term "network" in the ISDN corresponds to "subnetwork" in the OSI terminology. HHowever, 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. HThe layer identification used in Recommendation X.200 is limited 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. HThe following ISDN needs have to be specifically catered for in Recommendation I.320:   HH©  information flows for outofband call control processes, or more generally, information flows among multiple related protocols;   HH©  information flows for selection of connection characteristics; HH©  information flows for renegotiation of connection characteristics of calls; HH©  information flows for suspension of connections; HH©  information flows for overlap sending ; HH©  information flows for multimedia calls; HH©  information flows for asymmetric connections;  8 HH©  information flows for network management (e.g. change over and change back) and for maintenance functions (e.g test loops); HH©  information flows for power activation/deactivation; HH©  interworking; HH©  switching of information flows; HH©  new layer service definitions for nondata services;   HH©  application to other than endsystems, e.g. signal transfer points (STPs) and interworking points; HH©  information flows for multipoint connections; HH©  information flows for applications such as: HHX © voice (including A/ law conversion), HHX © full motion video, HHX © transparent, HHX © telex.  `  2.2HControl and user planes HThe 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.  8 HThe notion of plane control plane, or Cplane, and user plane, or Uplane is introduced to reflect this.   HThe 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 transparently through an ISDN, or it may be processed or manipulated, e.g. A/ conversion. HThe main rationale for protocols within the control plane is the transfer of information for the control of user plane connections, e.g. in:   HH©  controlling a network connection (such as establishing and clearing down);  `   H HH©  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);  `  HH©  providing supplementary services.   HIn 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 Uplane. All control information which involve resource allocation/deallocation by the ISDN pertain to the Cplane. 2.3 HLocal and global significance HA 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  X packet facilities), or an ISDN connection based on various types of basic connection components (e.g. analogue and digital circuits for a speech connection). HAs a consequence, the control information handled by an entity may concern:   HH©  an adjacent functional entity, in which case it is said to have local significance;  `    HH©  a remote (nonadjacent) functional entity, in which case it has global significance.  `  HThe 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 A ;Significanceă   HThe notion of significance applies to control plane information only. HAs an example: H from the ISDN user's point of view:   HHX © the overall service to be provided to users has a global , significance;  `   H HHX © the control of any resources to be used at the usernetwork interface has local significance;  `  HH© from the network's point of view:   HHX © the overall service to be provided by the ISDN (ISDN connection types, as introduced in Recommendation I.340) has a global significance;  `  HHX © the handling of connection elements, has local significance.   HDepending on their functional requirements, supplementary services relate to either the local, or global perspective. For example:   HH©  CCBS or usertouser signalling have global significance;  `  HH©  call waiting has local significance. HGlobal information falls into three classes: HHX H1) the information is transported transparently;   HHX HH2) the information may be processed, but remains unchanged (e.g. teleservice); HHX HH3) the information may be altered (e.g. destination number in relation with freephone or call forwarding supplementary services). 3.HThe model HThe ISDN protocol reference model (PRM) is represented by a protocol block which incorporates the concepts of layer, significance and plane described hereabove. HSuch 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.1HGeneric Protocol Block HThe 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). HThe layering principles apply in each of these planes: each plane can potentially accommodate a 7layer stack of protocols. A plane management function is required to allow coordination between the activities in the different planes. Examples of plan management function are: H  the decision on whether an incoming information is relevant to H the LC or GC plane, H  allowing communication between C and Uplanes, for synchronization purposes. HThe Generic Protocol Block is represented on Figure 3/I.320. JFIGURE 3/I.320 Q FGeneric Protocol Blockă Note The Plane Management Function should not be confused with the System Management as introduced to model OSI management. HThe following remarks apply: H1)  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 LCplane requirements; however, entities communicating in this plane are application layer entities. Note that this is not in contradiction with the OSI RM. H2)  An element (either in the network, or in user premises) does not have to support in all cases protocols of LC, GC and Uplanes: 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. H3)  A network element unless it provides an HLF will generally not support any Uplane protocol above layer 3. H4)  The need for application processes specific to each plane, or for application processes able to access several planes, is for further study.  ,Ԍ3.2HRelations between layers in one plane HAdjacent 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. HFurther study is required on which layer services have to be specified in order to describe a telecommunication service. 3.3HRelations between planes HStarting from GCplane requirements, an entity will derive the LCplane requirements, and the facilities that have to be provided for the support of Uplane lower layers. For example, in order to provide an ISDN connection (GCplane), an exchange will have to identify the required basic connection component (LCplane). HThis relation is made via the plane management function. HInformations in different planes need not be carried by distinct physical/logical means in all cases. For example:   HH©  control and user informations may use the same support, e.g. when inband signalling is used, or when user information is carried on a Dchannel;  `    HH©  LC and GC informations share the same support when the LCplane passalong facility is used;  `    HH©  ISPBX to ISPBX control information appears as Uplane information to the ISDN.  `  3.4HData flow modelling HFor further study. 4.HISDN management HFor further study. 5.HInterworking  8 HA number of particular interworking situations should be considered: HH©  internetworking with an OSI network;  `  HH©  interworking with an nonISDN terminal;  H HH©  interworking between two ISDNs which do not provide the same set of facilities;  `    HH©  interworking involving a networkprovided interworking function to support highlayer and/or lowlayer facilities.  `  5.1HGeneral   HAll the interworking situations mentioned above are covered by the model illustrated by Figure 4/I.320. XDFIGURE 4/I.320 XK XBInterworking Modelă (1) Note This reference point is an S/T reference point when considering interworking between ISDNs, or service interworking within an ISDN. HThe service S may be:  8 HH©  the initially required telecommunication service (TS), if both networks are able to provide it (F is then empty);  `    HH©  a telecommunication service resulting from a negotiation process, which both networks are able to provide (F is then empty);  `    HH©  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.  `  HThe service S is provided:   HH©  by means of functions F1 and protocol(s) P1 in network 1;  `    HH©  by means of functions F2 and protocol(s) P2 in network 2.  `   H HThe interworking function (IWF) maps the facilities offered by F1 and F2. HTwo kinds of interworking can take place: HHX HH1. a onestage interworking, where the calling user is not explicitly aware that an interworking function is required;  h HHX H2. a twostage interworking, where the calling user has a dialogue with the interworking function prior to exchanging control information with the destination user.  `  HThe model applies to both cases. HInterworking may involve the GCplane, and/or the Uplane. ,Ԍ HIn an interworking situation, the GCplane has to:  8 HH©  determine the telecommunication service to be provided (agreed telecommunication service): this may imply service negotiation;  `    HH©  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;  `    HH©  locate and invoke an IWF capable of mapping the facilities in the two networks.  `   X HIn each network, the GCplane 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 CLplane in each network. HIn the twostage interworking case, the GCplane information is "consumed" by the IWF during the first phase, and is forwarded (with or without modification) during the second one. HWhenever interworking in the Uplane is involved the following differences apply in the two cases:  H HH©  onestage interworking: in this case only the first three layers (at most) may be involved for the provision of the requested  ` H endtoend service. No HLF is required.   HH©  twostage interworking: in this case the first stage is the establishment of the Uplane 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.2HRelationships with the OSI RM   HThe 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:  h HHX H1) The C and Uplanes are not separated, since the C and Uplane information in one layer (n) always maps onto the Uplane information of the layer below (n 1).  `   h HHX H2) 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 endtoend transparently or take part in the definition of the overall service provided to the user (e.g. throughput).  `   X HHX H3) The C and Uplane informations in one layer (n) map onto the  ` H Uplane informations of the layer below (n 1).   HInterworking between the OSI RM and ISDN PRM takes place in the following situations:   HH©  internetworking with a specialized network (e.g. PSPDN) which respects the OSI RM: the reference points involved are K/L;  `    HH©  interworking with an "OSI terminal" via a terminal adaptor: the reference point is then R;  `    H  the interworking of an ISDN terminal on the S reference point which conforms to the OSI reference model is for further study. HIn 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.1HInterworking at reference point K/L HFor further study. 5.2.2HInterworking at reference point R HIn 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. HIn the OSI system, the application is considered an an ISDN user a communicating functional entity in the PRM. HThe GC information pertinent to the higher layer OSI application is carried in the Uplane to the destination application. The GC information pertinent to the network service required is carried in the control plane with LC control information.   HThe OSI system requests the network service from the ISDN by placing a service request to both the LC plane and the Uplane (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.  ,Ԍ HHFigure 5/I.320 HO H5OSI Reference Model and ISDN Protocol Reference Modelă 6.HExamples HApplications of the PRM to the following examples is for further study. 6.1HBasic call situations (no supplementary service, no interworking) HH©  circuit service (see Figure 6/I.320)  `  HH©  packet service HH©  multibearer capability HH©  data base access. 6.2HMore elaborate situations HH©  supplementary services H H CCBS H 3party service HH©  PABX facilities HH©  OA&M applications. 6.3HInterworking HH©  at reference point R (Teletex terminal) HH©  with a PSTN HH©  with a PSPDN (Videotex) HH©  inside an ISDN (provision of an HLF by the network).   H&'H&' HLegend: HC Local or Global Control depending on the destination functional entity HLC Local Control HGC Global Control HM Plane Management Function HNU Network User Plane HPU PSN User Plane HTU Terminal User Plane HNote 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  `  6'6'   Function of a functional entity to support layers 1 and 2 of the usernetwork signalling system. 305 interexchange signalling handling (message transfer) Function of a functional entity to support the messages transfer part of the interexchange 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 supplementary service which the subscriber can use. In general this data does NOT contain information on the type of subscriber'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 attributes , of the services subscribed to. 310 real time clock Function of a functional entity to provide real time information. 4 SUPERVISION 400 usernetwork 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.