home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD2.mdf / ccitt / 1992 / i / i320.asc < prev    next >
Text File  |  1993-06-28  |  24KB  |  1,199 lines

  1. 2.    SECTION 2 - REFERENCE MODELS
  2.  
  3.  
  4.  
  5. 2.1    Recommendation I.320
  6.  
  7.  
  8.  
  9.  
  10.  
  11. ISDN PROTOCOL REFERENCE MODEL
  12.  
  13.  
  14.  
  15.  
  16.  
  17. 1.    Introduction
  18.  
  19.  
  20.  
  21.     The objective of the ISDN Protocol Reference Model (ISDN PRM) is to model the interconnection and exchange 
  22. of information - including user information and control information - to, through or inside an ISDN.
  23.  
  24.  
  25.  
  26.     Communicating entities may be:
  27.  
  28.  
  29.  
  30. -     ISDN users;
  31.  
  32. -  an ISDN user and a functional entity within an ISDN, e.g. network control facilities;
  33.  
  34. -  an ISDN user and a functional entity inside or outside an ISDN, e.g. an information storage/processing/
  35. messaging facility;
  36.  
  37. -  various functional entities in an ISDN, e.g. a network management facility and a switching facility;
  38.  
  39. -  an ISDN functional entity and an entity located in or attached to a non-ISDN network.
  40.  
  41.  
  42.  
  43.     The purpose of communications between these functional entities is to support the telecommunication ser-
  44. vices introduced in Recommendations I.211 and I.212, by providing ISDN capabilities as defined in Recommenda-
  45. tion I.310. Examples of these capabilities are:
  46.  
  47.  
  48.  
  49. -  circuit-switched connection under the control of common channel signalling;
  50.  
  51. -  packet-switched communication over B-, D- and H-channels;
  52.  
  53. -  signalling between users and network-based facilities (e.g. information retrieval systems such as 
  54. Videotex, operations data bases such as directory);
  55.  
  56. -  end-to-end signalling between users (e.g. to change mode of communication over an already 
  57. established connection);
  58.  
  59. -  combinations of the above as in multi-media communication, whereby several simultaneous 
  60. modes of communication can take place under common signalling control.
  61.  
  62.  
  63.  
  64.     With such diversity of ISDN capabilities (in terms of information flows and modes of communication), there is 
  65. a need to model all these capabilities within a common framework (i.e. reference model). This would enable the 
  66. critical protocol architectural issues to be readily identified and facilitate the development of ISDN protocols and 
  67. associated features. It is not intended as a definition of any specific implementation of an ISDN or of any systems 
  68. or equipment in, or connected to, an ISDN.
  69.  
  70.  
  71.  
  72.     Examples of applications of this model are included in this Recommendation.
  73.  
  74.  
  75.  
  76. 2.    Modelling concepts 
  77.  
  78.  
  79.  
  80. 2.1    Relationship with the X.200-Series
  81.  
  82.  
  83.  
  84.     The ISDN Protocol Reference Model (PRM) and the Reference Model of Open Systems Interconnection for CCITT Appli-
  85. cations (OSI RM), defined by Recommendation X.200, have both commonalities and differences.
  86.  
  87.  
  88.  
  89.     Both the ISDN PRM and the OSI RM organize communications functions into layers and describe the relation of these 
  90. layers with respect to each other. However, the scope of the ISDN PRM is different from the scope of the OSI RM.
  91.  
  92.  
  93.  
  94.     The scope of the ISDN PRM is to model information flows across the range of telecommunication services defined in 
  95. the I.200-Series. These are Bearer Services, Teleservices and Supplementary Services. This description necessarily incor-
  96. porates ISDN-specific characteristics not encountered in other network types. Among these characteristics are multi-
  97. service types of communications which include voice, video, data and multi-media communications.
  98.  
  99.  
  100.  
  101.     The scope of the OSI RM is not associated with any particular network type1. In that sense it is less specific than the 
  102. ISDN PRM. Further, the scope of the OSI PRM is tied to data communications and so, in that sense, its scope is more 
  103. specific than the ISDN PRM. The OSI PRM - that application is to model data communications between open systems in 
  104. an ISDN environment.
  105.  
  106.  
  107.  
  108.     The relative scopes of the two models are illustrated by Figure1/I.320. The existence of a common intersection shows 
  109. that these models coexist and overlap.
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151. FIGURE 1/I.320
  152.  
  153.  
  154.  
  155. Applicability of OSI protocols to ISDN
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165. ûûûûûûûûûûûû 
  166.  
  167. 1 Note that the term "network" in the ISDN corresponds to "sub-network" in the OSI terminology.
  168.  
  169.  
  170.  
  171.     However, in spite of these differences in scope, a number of concepts and the associated terminology which have 
  172. been introduced in
  173.  
  174. Recommendations X.200 and X.210 are fully applicable to the ISDN PRM. They include the concept of layer, layer service 
  175. (X.200), and the notions of service primitive, peer entity and peer protocol (X.210).
  176.  
  177.  
  178.  
  179. Note - The relation between service primitives and functional components introduced in Recommendation I.310 requires 
  180. further study.
  181.  
  182.  
  183.  
  184.     The layer identification used in Recommendation X.200 is limited in this Recommendation to the use of layer num-
  185. bers. Layer titles (e.g. network layer) as used in Recommendation X.200 are sometimes misleading in the ISDN context, 
  186. and have not been used here.
  187.  
  188.  
  189.  
  190.     The following ISDN needs have to be specifically catered for in Recommendation I.320:
  191.  
  192.  
  193.  
  194. -  information flows for out-of-band call control processes, or more generally, information flows among mul-
  195. tiple related protocols;
  196.  
  197. -  information flows for selection of connection characteristics;
  198.  
  199. -  information flows for re-negotiation of connection characteristics of calls;
  200.  
  201. -  information flows for suspension of connections;
  202.  
  203. -  information flows for overlap sending ;
  204.  
  205. -  information flows for multi-media calls;
  206.  
  207. -  information flows for asymmetric connections;
  208.  
  209. -  information flows for network management (e.g. change over and change back) and for maintenance func-
  210. tions (e.g test loops);
  211.  
  212. -  information flows for power activation/deactivation;
  213.  
  214. -  interworking;
  215.  
  216. -  switching of information flows;
  217.  
  218. -  new layer service definitions for non-data services;
  219.  
  220. -  application to other than end-systems, e.g. signal transfer points (STPs) and interworking points;
  221.  
  222. -  information flows for multi-point connections;
  223.  
  224. -  information flows for applications such as:
  225.  
  226. - voice (including A/╡ law conversion),
  227.  
  228. - full motion video,
  229.  
  230. - transparent,
  231.  
  232. - telex.
  233.  
  234.  
  235.  
  236. 2.2    Control and user planes
  237.  
  238.  
  239.  
  240.     The support of outband signalling, the ability to activate supplementary services during the active phase of 
  241. the call, imply a separation between control information and user information.
  242.  
  243.  
  244.  
  245.     The notion of plane - control plane, or C-plane, and user plane, or U-plane - is introduced to reflect this.
  246.  
  247.  
  248.  
  249.     The main rationale for protocols within the user plane is the transfer of information among user applications, 
  250. e.g. digitized voice, data and information transmitted between users. This information may be transmitted trans-
  251. parently through an ISDN, or it may be processed or manipulated, e.g. A/╡ conversion.
  252.  
  253.  
  254.  
  255.     The main rationale for protocols within the control plane is the transfer of information for the control of user 
  256. plane connections, e.g. in:
  257.  
  258.  
  259.  
  260. -  controlling a network connection (such as establishing and clearing down);
  261.  
  262.  
  263.  
  264. -  controlling the use of an already established network connection (e.g. change in service characteristics 
  265. during a call such as alternate speech/unrestricted 64 kbit/s);
  266.  
  267.  
  268.  
  269. -  providing supplementary services.
  270.  
  271.  
  272.  
  273.     In addition to user information, any information which control the exchange of data within a connection, but 
  274. otherwise do not alter the state of this connection (e.g. flow control), pertain to the U-plane. All control infor-
  275. mation which involve resource allocation/deallocation by the ISDN pertain to the C-plane.
  276.  
  277.  
  278.  
  279.  
  280.  
  281. 2.3     Local and global significance
  282.  
  283.  
  284.  
  285.      A key characteristic of the ISDN is that, due to the integration of telecommunication services, the facilities to 
  286. be provided depend on whether the adjacent entity, or a remote entity, is involved: different services, possibly 
  287. using different routes, may have to be provided accordingly. An example is a telecommunication service, which 
  288. can be supported by various network capabilities, (e.g. a telematic service supported either by circuit or
  289.  
  290. packet facilities), or an ISDN connection based on various types of basic connection components (e.g. analogue 
  291. and digital circuits for a speech connection).
  292.  
  293.  
  294.  
  295.     As a consequence, the control information handled by an entity may concern:
  296.  
  297.  
  298.  
  299. -  an adjacent functional entity, in which case it is said to have local significance; 
  300.  
  301.  
  302.  
  303. -  a remote (non-adjacent) functional entity, in which case it has global significance.
  304.  
  305.  
  306.  
  307.     The significance concept is illustrated by Figure 2/I.320
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.       Local
  326.  
  327. <----------------->
  328.  
  329.                 Global
  330.  
  331. <-------------------------------------->
  332.  
  333.  
  334.  
  335. OE = Originating Functional Entity
  336.  
  337.  
  338.  
  339. AE = Adjacent Functional Entity
  340.  
  341.  
  342.  
  343. RE = Remote Functional Entity
  344.  
  345.  
  346.  
  347. FIGURE 2/I.320
  348.  
  349.  
  350.  
  351. Significance
  352.  
  353.  
  354.  
  355.     The notion of significance applies to control plane information only.
  356.  
  357.  
  358.  
  359.     As an example:
  360.  
  361.  
  362.  
  363.     -    from the ISDN user's point of view:
  364.  
  365.  
  366.  
  367. -  the overall service to be provided to users has a globalsignificance;
  368.  
  369.  
  370.  
  371. -  the control of any resources to be used at the user-network interface has local significance;
  372.  
  373.  
  374.  
  375. -  from the network's point of view:
  376.  
  377.  
  378.  
  379. -  the overall service to be provided by the ISDN (ISDN connection types, as introduced in 
  380. Recommendation I.340) has a global significance;
  381.  
  382.  
  383.  
  384. -  the handling of connection elements, has local significance.
  385.  
  386.  
  387.  
  388.     Depending on their functional requirements, supplementary services relate to either the local, or global per-
  389. spective. For example:
  390.  
  391.  
  392.  
  393. -  CCBS or user-to-user signalling have global significance;
  394.  
  395.  
  396.  
  397. -  call waiting has local significance.
  398.  
  399.  
  400.  
  401.     Global information falls into three classes:
  402.  
  403.  
  404.  
  405. 1)      the information is transported transparently;
  406.  
  407.  
  408.  
  409.     2)      the information may be processed, but remains unchanged (e.g. teleservice);
  410.  
  411.                                                   
  412.  
  413.     3)      the information may be altered (e.g. destination number in relation with freephone or call forwarding 
  414. supplementary services).
  415.  
  416.  
  417.  
  418. 3.    The model
  419.  
  420.  
  421.  
  422.     The ISDN protocol reference model (PRM) is represented by a protocol block which incorporates the concepts 
  423. of layer, significance and plane described hereabove.
  424.  
  425.  
  426.  
  427.     Such a protocol block can be used to describe various elements in the ISDN user premises and the network (e.g. ter-
  428. minal equipment (TE), ISPBX network termination (NT), exchange termination (ET), signalling point (SP) and signalling 
  429. transfer point (STP), etc.).
  430.  
  431.  
  432.  
  433. 3.1    Generic Protocol Block
  434.  
  435.  
  436.  
  437.     The considerations above lead to the introduction of the concept of significance in combination with planes; the result 
  438. is a splitting of the control plane into two parts: a local control plane (LC), and a global control plane (GC), in addition to 
  439. the user plane (U).
  440.  
  441.  
  442.  
  443.     The layering principles apply in each of these planes: each plane can potentially accommodate a 7-layer stack of pro-
  444. tocols. A plane management function is required to allow coordination between the activities in the different planes. Exam-
  445. ples of plan management function are:
  446.  
  447.  
  448.  
  449.     -      the decision on whether an incoming information is relevant to 
  450.  
  451.         the LC or GC plane,
  452.  
  453.  
  454.  
  455.     -      allowing communication between C- and U-planes, for synchronization purposes.
  456.  
  457.  
  458.  
  459.     The Generic Protocol Block is represented on Figure 3/I.320.
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529. FIGURE 3/I.320
  530.  
  531.  
  532.  
  533. Generic Protocol Block
  534.  
  535.  
  536.  
  537. Note - The Plane Management Function should not be confused with the System Management as introduced to model OSI 
  538. management.
  539.  
  540.  
  541.  
  542.     The following remarks apply:
  543.  
  544.  
  545.  
  546.     1)    Some layers may be empty, i.e. they provide no functionality. For example, it is likely that not all seven layers 
  547. are required to serve the LC-plane requirements; however, entities communicating in this plane are application layer enti-
  548. ties. Note that this is not in contradiction with the OSI RM.
  549.  
  550.  
  551.  
  552.     2)    An element (either in the network, or in user premises) does not have to support in all cases protocols of LC-
  553. , GC- and U-planes: some may ignore one or even two of these planes. For example, a network service centre accessed 
  554. to provide a supplementary service (e.g. freephone) will be concerned by the LC plane only, and will have no knowledge of 
  555. the other two planes.
  556.  
  557.  
  558.  
  559.     3)    A network element - unless it provides an HLF - will generally not support any U-plane protocol above layer 3.
  560.  
  561.  
  562.  
  563.     4)    The need for application processes specific to each plane, or for application processes able to access several 
  564. planes, is for further study.
  565.  
  566.  
  567.  
  568. 3.2    Relations between layers in one plane
  569.  
  570.  
  571.  
  572.     Adjacent layers within a plane communicate using service primitives.  If a layer is empty the primitive is 
  573. mapped directly onto a primitive to the next layer.
  574.  
  575.  
  576.  
  577.     Further study is required on which layer services have to be specified in order to describe a telecommunica-
  578. tion service.
  579.  
  580.  
  581.  
  582. 3.3    Relations between planes
  583.  
  584.  
  585.  
  586.     Starting from GC-plane requirements, an entity will derive the LC-plane requirements, and the facilities that 
  587. have to be provided for the support of U-plane lower layers. For example, in order to provide an ISDN connection 
  588. (GC-plane), an exchange will have to identify the required basic connection component (LC-plane).
  589.  
  590.  
  591.  
  592.     This relation is made via the plane management function.
  593.  
  594.  
  595.  
  596.     Informations in different planes need not be carried by distinct physical/logical means in all cases. For 
  597. example:
  598.  
  599.  
  600.  
  601. -  control and user informations may use the same support, e.g. when inband signalling is used, or when 
  602. user information is carried on a D-channel;
  603.  
  604.  
  605.  
  606. -  LC and GC informations share the same support when the LC-plane pass-along facility is used;
  607.  
  608.  
  609.  
  610. -  ISPBX to ISPBX control information appears as U-plane information to the ISDN.
  611.  
  612.  
  613.  
  614. 3.4    Data flow modelling
  615.  
  616.  
  617.  
  618.     For further study.
  619.  
  620.  
  621.  
  622. 4.    ISDN management
  623.  
  624.  
  625.  
  626.     For further study.
  627.  
  628.  
  629.  
  630. 5.    Interworking
  631.  
  632.  
  633.  
  634.     A number of particular interworking situations should be considered:
  635.  
  636.  
  637.  
  638. -  internetworking with an OSI network;
  639.  
  640.  
  641.  
  642. -  interworking with an non-ISDN terminal;
  643.  
  644.  
  645.  
  646. -  interworking between two ISDNs which do not provide the same set of facilities;
  647.  
  648.  
  649.  
  650. -  interworking involving a network-provided interworking function to support high-layer and/or low-layer 
  651. facilities.
  652.  
  653.  
  654.  
  655. 5.1    General
  656.  
  657.  
  658.  
  659.     All the interworking situations mentioned above are covered by the model illustrated by Figure 4/I.320.
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705. FIGURE 4/I.320
  706.  
  707.  
  708.  
  709. Interworking Model
  710.  
  711.  
  712.  
  713. (1) Note - This reference point is an S/T reference point when considering interworking between ISDNs, or service 
  714. interworking within an ISDN.
  715.  
  716.  
  717.  
  718.     The service S may be:
  719.  
  720.  
  721.  
  722. -  the initially required telecommunication service (TS), if both networks are able to provide it (F is then 
  723. empty);
  724.  
  725.  
  726.  
  727. -  a telecommunication service resulting from a negotiation process, which both networks are able to provide 
  728. (F is then empty);
  729.  
  730.  
  731.  
  732. -  a service which is required to support the telecommunication, service to be provided, which is offered by 
  733. both networks, but by means of different capabilities in the two networks.
  734.  
  735.  
  736.  
  737.     The service S is provided:
  738.  
  739.  
  740.  
  741. -  by means of functions F1 and protocol(s) P1 in network 1;
  742.  
  743.  
  744.  
  745. -  by means of functions F2 and protocol(s) P2 in network 2.
  746.  
  747.  
  748.  
  749.     The interworking function (IWF) maps the facilities offered by F1 and F2.
  750.  
  751.  
  752.  
  753.     Two kinds of interworking can take place:
  754.  
  755.  
  756.  
  757.     1.      a one-stage interworking, where the calling user is not explicitly aware that an interworking function is 
  758. required;
  759.  
  760.  
  761.  
  762. 2.      a two-stage interworking, where the calling user has a dialogue with the interworking function prior to 
  763. exchanging control information with the destination user.
  764.  
  765.  
  766.  
  767.     The model applies to both cases.
  768.  
  769.  
  770.  
  771.     Interworking may involve the GC-plane, and/or the U-plane.
  772.  
  773.  
  774.  
  775.     In an interworking situation, the GC-plane has to:
  776.  
  777.  
  778.  
  779. -  determine the telecommunication service to be provided (agreed telecommunication service): this may 
  780. imply service negotiation;
  781.  
  782.  
  783.  
  784. -  identify the interworking situation, i.e. the fact that more than one network is involved, and that for some 
  785. service S required to support the telecommunication service, two adjacent networks do not use the same 
  786. underlying facilities;
  787.  
  788.  
  789.  
  790. -  locate and invoke an IWF capable of mapping the facilities in the two networks.
  791.  
  792.  
  793.  
  794.     In each network, the GC-plane facilities will provide the functions and protocols (Fi and Pi) required to support ser-
  795. vice S; this will result in different (and independent) requirements on the CL-plane in each network.
  796.  
  797.  
  798.  
  799.     In the two-stage interworking case, the GC-plane information is "consumed" by the IWF during the first phase, and 
  800. is forwarded (with or without modification) during the second one.
  801.  
  802.  
  803.  
  804.     Whenever interworking in the U-plane is involved the following differences apply in the two cases:
  805.  
  806.  
  807.  
  808. -  one-stage interworking: in this case only the first three layers (at most) may be involved for the provision of 
  809. the requested 
  810.  
  811.         end-to-end service. No HLF is required.
  812.  
  813.  
  814.  
  815. -  two-stage interworking: in this case the first stage is the establishment of the U-plane facilities between 
  816. the calling user and the IWF. High layer functions (HLF) and protocols may be involved, in which case the 
  817. IWF acts as a substitute for the called user.
  818.  
  819.  
  820.  
  821. 5.2    Relationships with the OSI RM
  822.  
  823.  
  824.  
  825.     The OSI RM, seen from the ISDN PRM point of view, appears not to be in contradiction with the latter, but contains 
  826. some restrictions which stem from the fact that it does not have the same scope:
  827.  
  828.  
  829.  
  830. 1)      The C- and U-planes are not separated, since the C- and U-plane information in one layer (n) always maps 
  831. onto the U-plane information of the layer below (n - 1).
  832.  
  833.  
  834.  
  835. 2)      The concept of significance does not explicitly appear; however control informations (e.g. in layer 3) include 
  836. both 'local'  informations and informations which are carried end-to-end transparently or take part in 
  837. the definition of the overall service provided to the user (e.g. throughput).
  838.  
  839.  
  840.  
  841. 3)      The C- and U-plane informations in one layer (n) map onto the 
  842.  
  843.         U-plane informations of the layer below (n - 1).
  844.  
  845.  
  846.  
  847.     Interworking between the OSI RM and ISDN PRM takes place in the following situations:
  848.  
  849.  
  850.  
  851. -  internetworking with a specialized network (e.g. PSPDN) which respects the OSI RM: the reference points 
  852. involved are K/L;
  853.  
  854.  
  855.  
  856. -  interworking with an "OSI terminal" via a terminal adaptor: the reference point is then R;
  857.  
  858.  
  859.  
  860.     -      the interworking of an ISDN terminal on the S reference point which conforms to the OSI reference 
  861. model is for further study.
  862.  
  863.  
  864.  
  865.     In each case, the interworking function (an IWF or a TA) has to map information flows of one model onto 
  866. information flows of the other.
  867.  
  868.  
  869.  
  870. 5.2.1    Interworking at reference point K/L
  871.  
  872.  
  873.  
  874.     For further study.
  875.  
  876.  
  877.  
  878. 5.2.2    Interworking at reference point R
  879.  
  880.  
  881.  
  882.     In the case when a user application, running an OSI system, requires network services across the ISDN, the 
  883. originating user application will address the terminating application as a destination user.
  884.  
  885.  
  886.  
  887.     In the OSI system, the application is considered an an ISDN user - a communicating functional entity in the 
  888. PRM.
  889.  
  890.  
  891.  
  892.     The GC information pertinent to the higher layer OSI application is carried in the U-plane to the destination 
  893. application. The GC information pertinent to the network service required is carried in the control plane with LC 
  894. control information.
  895.  
  896.  
  897.  
  898.     The OSI system requests the network service from the ISDN by placing a service request to both the LC plane 
  899. and the U-plane (Figure 5/I.320). The distribution of the information to the appropriate planes is made by the 
  900. Plane Management Function. The Plane Management Function is responsible for providing an OSI Service Access 
  901. Point to the OSI system.
  902.  
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954.  
  955.  
  956.  
  957.  
  958.  
  959.  
  960.  
  961. Figure 5/I.320
  962.  
  963.  
  964.  
  965. OSI Reference Model and ISDN Protocol Reference Model
  966.  
  967.  
  968.  
  969.  
  970.  
  971. 6.    Examples
  972.  
  973.  
  974.  
  975.     Applications of the PRM to the following examples is for further study.
  976.  
  977.  
  978.  
  979. 6.1    Basic call situations (no supplementary service, no interworking)
  980.  
  981.  
  982.  
  983. -  circuit service (see Figure 6/I.320)
  984.  
  985.  
  986.  
  987. -  packet service
  988.  
  989.  
  990.  
  991. -  multi-bearer capability
  992.  
  993.  
  994.  
  995. -  data base access.
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001. 6.2    More elaborate situations
  1002.  
  1003.  
  1004.  
  1005. -  supplementary services
  1006.  
  1007.     
  1008.  
  1009.         CCBS
  1010.  
  1011.         3-party service
  1012.  
  1013.  
  1014.  
  1015. -  PABX facilities
  1016.  
  1017.  
  1018.  
  1019. -  OA&M applications.
  1020.  
  1021.  
  1022.  
  1023. 6.3    Interworking
  1024.  
  1025.  
  1026.  
  1027. -  at reference point R (Teletex terminal)
  1028.  
  1029.  
  1030.  
  1031. -  with a PSTN
  1032.  
  1033.  
  1034.  
  1035. -  with a PSPDN (Videotex)
  1036.  
  1037.  
  1038.  
  1039. -  inside an ISDN (provision of an HLF by the network). 
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066.  
  1067.  
  1068.  
  1069.  
  1070.  
  1071.  
  1072.  
  1073.     Legend:
  1074.  
  1075.  
  1076.  
  1077.     C  - Local or Global Control depending on the destination functional entity
  1078.  
  1079.  
  1080.  
  1081.     LC - Local Control
  1082.  
  1083.  
  1084.  
  1085.     GC - Global Control
  1086.  
  1087.  
  1088.  
  1089.     M  - Plane Management Function
  1090.  
  1091.  
  1092.  
  1093.     NU - Network User Plane
  1094.  
  1095.  
  1096.  
  1097.     PU - PSN User Plane
  1098.  
  1099.  
  1100.  
  1101.     TU - Terminal User Plane
  1102.  
  1103.  
  1104.  
  1105.     Note - For simplicity reasons, NTI functional units are not shown.
  1106.  
  1107.  
  1108.  
  1109.                                             FIGURE 7/I.320
  1110.  
  1111.  
  1112.  
  1113.                     A protocol reference model example showing the underconnection of
  1114.  
  1115.                                        public and private ISDNs
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121. Function of a functional entity to support layers 1 and 2 of the user-network signalling system.
  1122.  
  1123.  
  1124.  
  1125. 305  inter-exchange signalling handling (message transfer)
  1126.  
  1127.  
  1128.  
  1129. Function of a functional entity to support the messages transfer part of the inter-exchange signalling systems.
  1130.  
  1131.  
  1132.  
  1133. 306  path search inside switching unit
  1134.  
  1135.  
  1136.  
  1137. Function of a functional entity to select an internal connection inside the switching unit.
  1138.  
  1139.  
  1140.  
  1141. 307  synchronization handling
  1142.  
  1143.  
  1144.  
  1145. Function of a functional entity to provide synchronization between different functional entities; and:
  1146.  
  1147.  
  1148.  
  1149. Function of a functional entity to provide its own internal synchronization functional entity.  
  1150.  
  1151.  
  1152.  
  1153. 308  Timing handling
  1154.  
  1155.  
  1156.  
  1157. Function of a functional entity to provide timing between time instances involved in calls.
  1158.  
  1159.  
  1160.  
  1161. 309  line service marking
  1162.  
  1163.  
  1164.  
  1165. Functions of a functional entity to store for each customer the data on the parameters of the bearer and teleservices 
  1166. that are subscribed to. The store also contains the data on the parameters of the basic bearer and teleservices that are 
  1167. subscribed to by the customer. It also contains the binary information (i.e. subscribed to or not) for a range of sup-
  1168. plementary service which the subscriber can use. In general this data does NOT contain information on the type of sub-
  1169. scriber's terminal, but it may contain information on the type of access (basic, primary rate, etc.), the type of NT2 
  1170. (simple, intelligent, etc.) and the attributesof the services subscribed to.
  1171.  
  1172.  
  1173.  
  1174. 310  real time clock
  1175.  
  1176.  
  1177.  
  1178. Function of a functional entity to provide real time information.
  1179.  
  1180.  
  1181.  
  1182. 4  SUPERVISION
  1183.  
  1184.  
  1185.  
  1186. 400  user-network access resources monitoring
  1187.  
  1188.  
  1189.  
  1190. Function of a functional entity to check the correct operation of subscriber access resources.
  1191.  
  1192.  
  1193.  
  1194. 401  transit resources monitoring
  1195.  
  1196.  
  1197.  
  1198. Function of a functional entity to check the correct operation of the transit resources.  
  1199.