5i' Recommendation I.122 FRAMEWORK FOR PROVIDING ADDITIONAL PACKET MODE BEARER SERVICES (Melbourne, 1988) 1 Introduction Packet mode bearer services supported by an ISDN are given in Recommendation I.232. Recommendation I.462 (X.31) specifies the procedures for two such bearer services, virtual call and permanent virtual circuit bearer services, for the support of X.25 packet mode terminals in ISDN. This Recommendation establishes an architectural framework within which additional packet mode bearer services are described. 1.1 Scope The architectural framework and service descriptions given in this Recommendation provide the basis for further work to be done by CCITT during the 1989-1992 Study Period. This method of work involves first the description of services and then the development of protocols to support them. During the course of this work the first ISDN principle given in Recommendation I.120 should be followed. That is, a wide range of applications should be supported by the same network using a limited set of connection types and multipurpose user-network interface arrangements. From considerations in this Recommendation it is also desirable to limit the number of bearer services. It is recognized, however, that at this time it is premature to exclude any potential bearer services. The criteria on the basis of which the number of these bearer services could be reduced requires further study. The Recommendation also provides a general description on interworking requirements between I.122 based services and I.462 (X.31) based services or PSPDNs. 1.2 Objectives The principle of separation of the user and control planes for all telecommunication services has been established as a fundamental concept of the ISDN protocol reference model (Rec. I.320). This principle has been applied, however, only to circuit mode services. Packet mode services in ISDN are based on Recommendation I.462 (X.31). Recommendation I.462 (X.31) is a prag- matic approach that minimizes deployment and interworking difficul- ties, while at the same time providing access to packet services through an integrated physical interface. The evolution of packet mode services in ISDN has been inves- tigated, and an architectural framework for providing additional packet mode services has been established in this Recommendation. In undertaking this investigation the main objective was to estab- lish a framework based on the ISDN protocol reference models described in Recommendation I.320. More specifically, this frame- work was aimed at achieving: a) full integration of C-plane (control plane) procedures for all services, i.e. one set of protocols for call control; supplementary services and operational, administrative and maintenance messages (OAM) across all telecommunication services; b) the decoupling of user information transfer requirements from C-plane transfer requirements. This allows the possibility of defining telecommunication services whose U-plane (user plane) characteristics are tailor-made only to the transfer needs of user information and not to those of C-plane information. The bearer services supported within this architectural frame- work are in the virtual call and permanent virtual circuit bearer service category. All bearer services defined within this framework if and when included in Rec. I.232 will have recommended overall provision A (Additional). 1.3 Definitions of terms In the context of this Recommendation, the following defini- tions apply: Note - This list is not complete. For example, some of these definitions apply to terms relevant to only some of the bearer ser- vices discussed in this Recommendation. 1.3.1 delivered duplicate frames A frame D received by a particular destination user is defined to be a duplicated frame if both of the following conditions are true: a) D was not generated by the source user; b) D is exactly the same as a frame that was previ- ously delivered to that destination. 1.3.2 delivered errored frames A delivered frame is defined to be an errored frame when the value of one or more bits in the frame is in error, or when some, but not all, bits in the frame are lost bits or extra bits (i.e. bits that were not present in the original signal). (See Rec. X.140). 1.3.3 delivered out-of-sequence frames Consider a sequence of frames F1, F2, f3, | | | , Fn. Assume that F1is transmitted first, F2second, | | | Fnlast. A delivered frame Fiis defined to be out-of-sequence if it arrives at the destination user after any of the frames F (i + 1) , F (i + 2) , | | | , Fn. 1.3.4 dynamic window control The term dynamic window control refers to a set of procedures based on which the transmitter's transmit window is modified, according to a user-perceived congestion condition in the network. 1.3.5 end-to-end communication End-to-end communication is a direct peer-to-peer communica- tion of TE to TE, or TE to a network interworking function (IWF) supporting, for example, PSPDN interworking. 1.3.6 explicit congestion message Explicit congestion message is a message generated by the net- work and sent to a user terminal to indicate a congestion condi- tion. 1.3.7 implicit congestion control Implicit congestion control is a scheme under which user ter- minals first detct a possible congestion condition by means other than explicit congestion messages, and then take appropriate action to reduce their throughput. 1.3.8 information integrity Information integrity is a network providing frame-relaying bearer service defines that all frames carried by the network shall satisfy the FCS check. 1.3.9 logically separate (C-plane information) Logically separate means that C-plane information is sent separately from U-plane information in one of the following ways: 1) on a physically separate interface; 2) on another channel (time slot) within the same interface; or 3) on a separate logical link within the same chan- nel (e.g., D-channel). 1.3.10 lost frames A transmitted frame is declared to be a lost frame when the frame is not delivered to the intended destination user within a specified timeout period, and the network is responsible. (See Rec. X.140). 1.3.11 misdelivered frames A misdelivered frame is a frame transferred from a source user to a destination user other than the intended destination user. It is considered inconsequential whether the information is correct or incorrect in content. (See Rec. X.140). 1.3.12 quality of service (QOS)-parameter set (See Rec. X.213) For each QOS-parameter, a set of "subparameters" is defined from among the following possibilities: a) a target | value which is the QOS value desired by the calling user; b) the lower quality acceptable | value which is the lowest QOS value agreeable to the calling user. (When the lowest quality acceptable refers to throughput, the term "minimum" may be used, while when it refers to transit delay, the term "max- imum" may be used.); c) an available | value which is the QOS that the network is willing to provide; d) a selected | value which is the QOS value to which the called user agrees. 1.3.13 real time call establishment The term real time call establishment refers to a set of pro- cedures based on which the communication can be started in a rela- tively short time (i.e. in the order of a few seconds) after the request is made. (See definition for demand communication estab- lishment in Rec. I.130). 1.3.14 residual error rate Residual error rate is defined for both the additional packet-mode bearer services and the corresponding layer services. The layer services corresponding to the additional packet-mode bearer services are characterized by the exchange of service data units (SDUs). For frame relaying 1, SDUs are exchanged at the func- tional boundary between the core functions of Recommendation and the end-to-end protocol implemented above them. For frame relaying 2 and frame switching, SDUs are exchanged at the functional boun- dary between the complete I.441* and the end-to-end functions implemented above I.441*. For the X.25-based additional packet mode service (APMS), SDUs are exchanged at the functional boundary of X.25 PLP-DTP (packet layer protocol-data transfer part) and the end-to-end functions implemented above. The network participates in this exchange by means of protocol data units (PDUs). In frame relaying 1 and 2, PDUs are frames as defined in the core functions of I.441*. In frame switching, PDUs are frames as defined in I.441*, while in X.25-based APMS, they are packets as defined in X.25 PLP. The residual error rate for the corresponding layer service of APMS is defined as: R = 1 - otal offered SDUs ___________________________ The residual error rate for the APMS is defined as the ratio: R = 1 - otal offered PDUs ___________________________ _________________________ I.441* is I.441 with appropriate extensions. The use of the extensions may depend on each bearer service and is for further study. 1.3.15 throughput Throughput for a virtual connection section in a network pro- viding the frame relaying bearer service, is the number of data bits contained between the address field and the FCS field of the frames successfully transferred in one direction across that sec- tion per unit time. Successful transfer means that the FCS check for each frame is satisfied. 1.3.16 transit delay Transit delay is defined only between pairs of section boun- daries starts at the time t1at which the first bit of the FPDU crosses the first boundary, and ends at the time t2at which the last bit of the FPDU crosses the second boundary. Transit delay = t2-t1. 2 Service aspects 2.1 General service characteristics This Recommendation describes a set of potential packet mode bearer services that have the following characteristics in common: 1) All C-plane procedures, if needed, are performed in a logically separate manner using protocol procedures that are integrated across all telecommunications services (i.e. I.451 with appropriate extensions). 2) The U-plane procedures share the same layer 1 functions based on Rec. I.430/I.431. Moreover, they share the same core procedres, defined in S 3.1, that among other functions allow for statistical multiplexing of user information flows immediately above the layer 1 functions. The basic bearer service provided by the network is the order preserving bidirectional transfer (see S 2.3.1) of service data units (i.e. frames or packets) from one S/T reference point to another. The data units are routed through the network on the basis of an attached label (e.g. the data link connection identifier (DLCI) value of the frame). This _________________________ Virtual connection section is defined in Rec. X.134. The definition of section boundaries is given in Rec. X.134. The definition of FPDU is given above in residual error rate. label is a logical identifier with local significance. In the virtual call case, the value of the logical identifier and the other associated parameters are negotiated during the call set-up by means of C-plane procedures. Depending on the bearer service and parameters, the network may accept or reject the user requested service. In the permanent virtual circuit case, the logical iden- tifier and the other associated parameters are defined by means of administrative procedures. The network treatment of the data units, (e.g. unacknowledged transfer, acknowledged transfer, error recovery) in addition to simple transfer, depends on the specific bearer service requested. The user network interface structure at the S/T reference point allows for the establishment of multiple virtual calls and/or permanent virtual circuits to many destinations. 2.2 Quality of Service parameters Each potential bearer service described in this Recommendation provides service quality that is characterized by the values of the following parameters: 1) throughput; 2) transit delay; 3) information integrity; 4) residual error rate; 5) delivered errored frames; 6) delivered duplicated frames; 7) delivered out-of-sequence frames; 8) lost frames; 9) misdelivered frames; 10) others for further study. Note - The applicability and values of these parameters for different bearer services are for further study. 2.3 Individual bearer service descriptions This section contains descriptions of four specific potential bearer services proposed for standardization: a) frame relaying 1, b) frame relaying 2, c) frame switching, and d) X.25-based additional packet mode. 2.3.1 Frame relaying 1 service description Frame relaying 1 shares with the other services the general service characteristics and quality of service parameters described in SS 2.1 and 2.2, respectively. The frame relaying 1 data units are frames as defined in Rec. I.441. The basic bearer service provided is the unacknowledged transfer of frames from S/T to S/T reference point. More specifi- cally, in the U-plane: 1) it preserves their order as given at one S/T reference point if and when they are delivered at the other end. Note - Since the network does not terminate the upper part of I.441, sequence numbers are not kept by the network. Networks should be implemented in a way that, in principle, frame order is preserved; 2) it detects transmission, format and operational errors (e.g. frames of unknown DLCI); 3) frames are transported transparently (in the network), only the address and FCS field may be modified; 4) it does not acknowledge frames (within the net- work). All of the above functions are based on Rec. I.441. Appropri- ate extensions to the core functions of Rec. I.441 may be needed, e.g. for congestion control. In the C-plane all signalling capabil- ities for call control, parameter negotiation, etc. are based on a common set of protocols (e.g. Rec. I.451 extended), as for all ISDN telecommunication services. In the case of permanent virtual cir- cuits (PVC) no real time call establishment is necessary and param- eters are agreed upon at subscription time. However, additional functions are needed: - to monitor throughput and to enforce it, - to control congestion. The mechanisms to achieve these functions are still under investigation. Appropriate protocol capabilities should be available so that the network may discard erroneous frames if it elects to do so. Note that if networks elect to forward erroneous frames to the user, fraud and misdelivery of frames may occur. From the service perspective, frame relaying 1 provides ser- vice quality characteristics with the following parameter values: (Parameter values are for further study). 2.3.2 Frame relaying 2 service description Frame relaying 2 shares with the other services the general service characteristics and Quality of Service parameters described in SS 2.1 and 2.2, respectively. The frame relaying data units are frames as defined in Rec. I.441. The basic bearer service provided is an unacknowledged transfer of frames from S/T to S/T reference point. More specifi- cally, in the U-plane: 1) it preserves their order as given at one S/T reference point if and when they are delivered at the other end. Note - Since the network does not terminate th upper part of I.441, sequence numbers are not kept by the network. Networks should be implemented in a way that, in principle, frame order is preserved; 2) it detects transmission, format and operational errors (e.g. frames of unknown DLCI); 3) frames are transported transparently in the net- work, only the address and FCS field may be modified; 4) it does not acknowledge frames (within the net- work); 5) normally the only frames received by a user are those sent by the distant user. (Currently, implicit congestion control is preferred in which the network does not generate any congestion control messages toward the user. The generation of explicit congestion control messages by the network is for further study.) All of the above functions are based on Rec. I.441. Appropri- ate extensions to Rec. I.441 may be needed, e.g. in relation to congestion control. In the C-plane all signalling capabilities for call control, parameter negotiation, etc. are based on a common set of protocols (e.g. Rec. I.451 extended), as for all ISDN telecommunication ser- vices. In the case of permanent virtual circuits (PVC) no real time call establishment is necessary and any parameters are agreed upon at subscription time. However, additional network functions are needed: - to monitor throughput and to enforce it, - to control congestion. The mechanisms to achieve these functions are still under investigation. Appropriate protocol capabilities should be available so that the network may discard erroneous frames if it elects to do so. Note that if networks elect to forward erroneous frames to the user, fraud and misdelivery of frames may occur. The difference between the two types of frame relaying is that in frame relaying 2 the end points always implement, above the core functions, the upper part of Rec. I.441 extended. Consequently, in frame relaying 2 the network may take advantage of the knowledge of the layer 2 parameters in order to facilitate network operations such as charging and resource allocation. In frame relaying 1 the functions implemented end-to-end above the core functions are user selectable and may not be the upper part of Rec. I.441. Conse- quently, in frame relaying 1 the network in principle has no knowledge of the protocol used end-to-end. From the service perspective, frame relaying 2 provides ser- vice quality characteristics with the following parameter values: (Parameter values are for further study). The terminal operates with an extended I.441 protocol. As a result the user perspective is the transparent transport of data end-to-end, with a quality influenced by the statistical multiplex- ing of data streams in the network. Acknowledgement of data is end-to-end as well as error detection and recovery. 2.3.3 Frame switching service description Frame switching has general service characteristics and Qual- ity of Service parameters as given in SS 2.1 and 2.2, respectively. In addition, in the U-plane, frame switching: 1) provides for the acknowledged transport of frames; 2) detects and recovers from transmission, format, and operational error; 3) detects and recovers from lost or duplicated frames; 4) provides flow control. All of the above functions are based on Recommendation I.441. Appropriate extensions to Recommendation I.441 may be needed. In the C-plane all signalling capabilities for all call con- trol, parameter negotiation, etc. are based on a common set of pro- tocols (e.g. Rec. I.451 extended), as for all ISDN telecommunica- tion services. In the case of permanent virtual circuits no real time call establishment is necessary and any parameters are agreed upon at subscription time. From the service perspective, frame switching provides service quality characteristics with the following parameter values: (Parameter values are for further study). 2.3.4 X.25-based additional packet mode service description X.25-based additional packet mode has general service charac- teristics and Quality of Service parameters similar to the packet mode services described in X.31. The U-plane capabilities are the same as in X.25 PLP Data Transfer Part (DTP) In the C-plane all signalling capabilities for call control, parameter negotiation, etc. are based on a common set of protocols (e.g. Rec. I.451 extended), as for all ISDN telecommunication ser- vices. In the case of permanent virtual circuits (PVC) no real time call establishment is necessary and any parameters are agreed upon at subscription time. 3 User-network interface protocol reference model Figure 1/I.122 is a direct application of the ISDN protocol reference model to the packet mode communications discussed in this Recommendation. It shows the user-network interface protocol archi- tecture. Only those functions on the network side that are visible on the user side of the S/T reference point are shown. On the user side, Recommendations I.430 or I.431 provide the layer 1 protocol for the U- (user) C- (control) planes. The C-plane uses the D-channel with Recommendations I.441 extended and I.451 extended as the layer 2 and 3 protocols, respectively. In the case of permanent virtual circuits (PVC) no real time call establishment is necessary and any parameters are agreed upon at subscription time. The U-plane may use any channel (D, B, H0and H1) on which the user implements at least the lower part (the core functions) of Recommendation I.441. Figure 1/I.122, p. H.T. [T1.122] TABLE 1/I.122 U-plane functions applicable to each bearer service _______________________________________________________________________________ Bearer service User terminal (Note 1) Network _______________________________________________________________________________ Frame relaying 1 I.441* Core (Note 2) I.441* Core _______________________________________________________________________________ Frame relaying 2 I.441* I.441* Core _______________________________________________________________________________ Frame switching I.441* I.441* _______________________________________________________________________________ { X.25-based additional packet mode } I.441* X.25 DTP I.441* X.25 DTP _______________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - Additional user selectable functions may be implemented. Note 2 - I.441* is I.441 with appropriate extensions. The use of the extensions may depend on each bearer service and is for further study. Table 1/I.122 [T1.122], p. 3.1 Core functions of Rec. I.441 The core functions are: - frame delimiting, alignment, and transparency, - frame multiplexing/demultiplexing using the address field, - inspection of the frame to ensure that it con- sists of an integer number of octets prior to zero bit insertion or following zero bit extraction, - inspection of the frame to ensure that it is neither too long nor too short (see Note), - detection of transmission errors. Note - The maximum and minimum frame lengths that apply to the Additional packet mode bearer services are for further study. 3.2 Other user terminal functions If not already prescribed by the selected packet mode bearer service, the user may also implement functions such as, for exam- ple, recovery from detected transmission, format, and operational errors above the core functions using the full procedures of Recommendation I.441. Additional functions such as flow control may also be implemented. For example, X.25 data transfer functions may also be implemented above the preceding stack. 3.3 Network functions On the network side, Recommendations I.430 or I.431 provide the layer 1 protocol for both C- and U-planes. The C-plane is han- dled just as on the user side, i.e. the network fully terminates the protocols of Recommendations I.441 and I.451. In the U-plane, at least the core functions of Recommendation I.441 protocol are terminated. The network may terminate additional protocol functions only as requested by the user and negotiated and agreed to by the user and the network. The U-plane protocols to be terminated by the network are determined by the specific bearer service requested by the user, and negotiated and agreed to by the user and network. Interactions between the U- and C-planes of the terminal, and between the U- and C-planes of the network are independent. As a result, coordination between the U- and C-planes at the users equipment is not the responsibility of the network. During the three phases of a call (call establishment, data transfer, and call clearing), C- and U-plane synchronization is achieved in a similar way as for all ISDN telecommunications ser- vices. That is, after the C-plane has established the connection, the U-plane may commence data transfer with or without an initialization procedure in the U-plane. In the case of permanent virtual circuit the establishment and call clear- ing is accomplished by administrative procedures. 3.4 Further service requirements at the user-network inter- face Procedures at the user-network interface should be also appli- cable when two users are connected via a circuit mode bearer ser- vice (permanent or demand). Mechanisms that can be used to achieve this objective include, for example, the symmetrization of the pro- cedure involved, or the use of additional procedures for the deter- mination of the asymmetric relationships. The selection of such a mechanism is for further study. 3.5 Potential bearer services Four potential bearer services are identified as part of this architectural framework. The first potential bearer service, frame relaying 1, is provided when no functions above the core functions are terminated by the network: if needed, such functions are ter- minated only end-to-end. The second potential bearer service, frame relaying 2, is pro- vided when no functions above the core functions are terminated by the network; I.441 upper functions are terminated only at the end points. The third potential bearer service, frame switching, is pro- vided when the full Recommendation I.441 protocol is terminated by the network. The fourth potential bearer service, X.25-based additional packet mode, is provided when the full Recommendation I.441 proto- col and the data transfer part (DTP) of Recommendation X.25 PLP (packet layer protocol) are terminated by the network. Further information on the service characteristics of these four potential bearer services is given in Annex A. 4 Interworking requirements 4.1 Interworking between packet mode services To interconnect different packet mode bearer services, it is necessary to provide interworking between an ISDN offering any of the bearer services described in this Recommendation, and: 1) an ISDN offering any of these additional packet mode bearer services, 2) an X.25-based service offered either by an ISDN or a PSPDN. For interworking configuration 1), procedures for both the C-plane and the U-plane at an internetwork reference point which includes international gateway reference points, have to be stand- ardized. In addition it would be desirable that these procedures be developed in such a way that they also could be used at an inter-exchange reference point within an ISDN offering any of the bearer services described in this Recommendation. Examples of such procedures may include: routing, address translation, security and accounting tasks. For interworking configuration 2), interworking based on either call control mapping or port access is possible. A high level description of interworking arrangements is contained in Annex B. 4.2 Support of existing terminals Additionally, terminal adapter functions should be provided that allow existing terminals (e.g. asynchronous, start/stop DTEs, X.25 packet mode DTEs and V-Series interface terminals) to access from an ISDN one or more of the bearer services described in this Recommendation. 4.3 Interworking with circuit mode services Other service interworking configurations (e.g. with a CSPDN, or between different bearer services within an ISDN) may also need to be considered. 5 Support of OSI connection-oriented network layer service In the interworking between an ISDN offering any of the bearer services described in this Recommendation and X.25-based service offered either by an ISDN or a PSPDN, an interworking function (IWF) is required. To support network layer service (Rec. X.213) when the bearer service used is one of the bearer services described in this Recom- mendation, the use of additional end system functionality may be required and end-to-end (i.e. TE-to-TE or TE-to-IWF) compatibility must be ensured. Annex C contains requirements for the support of network layer service (Rec. X.213). 6 Applications Packet mode bearer services described in this Recommendation aim at data services up to 2 Mbit/s. Within this broad category, some specific applications are as follows: 1) Block interactive data applications An example of a block interactive application would be high resolution graphics (e.g. high resolution videotex, CAD/CAM). The main characteristics of this type of application are low delays [e.g. approximately less than . | | ms (the exact value is for further study)] and throughput approximately in the range of 500 kbit/s to 2048 kbit/s. 2) File transfer The file transfer application is intended to cater for large file transfer requirements. Transit delay is not as critical for this application as it is for example in the first application. Higher throughput (e.g. 16 kbit/s to 2048 kbit/s) might be neces- sary in order to produce reasonable transfer times for large files. 3) Multiplexed low bit rate The multiplexed low bit rate application exploits the mul- tiplexing capabilities of the layer 2 protocol in order to provide an economical access arrangement for a large group of low bit rate applications. The low bit rate sources should be multiplexed onto any ISDN-channel by an NT function which could take the form of a LAN, PABX, or Centrex. The delay requirements are in the area of | | | ms (the exact value is for further study) and the throughput within the range of 16 kbit/s to 2048 kbit/s. 4) Character-interactive traffic An example of a character-interactive traffic is text editing. The main characteristics of this type of applications are short frames, low delays and low throughput. Identification of additional applications and their charac- teristics (e.g. delay, throughput, etc.) for bearer services described in this Recommendation are desirable for the complete definition of the service requirements. ANNEX A (to Recommendation I.122) Further service-related information A.1 Introduction This Annex contains further service related information on the I.122 based bearer services. The intent of this Annex is to clarify and supplement the service descriptions given in the main body of this Recommendation. Note that the information given in this Annex should not be interpreted as material that completes the service descriptions of the bearer services given in this Recommendation. A.2 Service related information A.2.1 Frame relaying 1 The U-plane configuration for this service is shown in Figure A-1/I.122. Figure A-1/I.122, p. Figure A-1/I.122 shows the network in a generic way and illus- trates all U-plane functions up to and including layer 3. In a specific network, frame relaying 1 may be implemented in one or more nodes, all other nodes in the network providing only circuit-mode functions. Frame relaying 1 can be offered on both, basic and primary rate interfaces and on any ISDN channel (D, B, and H). Some res- trictions (e.g. frame length) apply when in an end-to-end connec- tion at least one of the access channels is the D-channel (16 kbit/s). The bearer service provided by the network at the S/T refer- ence point supports only the core functions defined in S 3.1. A frame received by such a point is discarded if the frame does not meet the I.441 core format requirements (for example, if the frame is too long, has an unknown label, etc.). Moreover, frames may be discarded due to internal network conditions, or other reasons such as throughput enforcement. In all other cases, the frame is relayed to one of the adja- cent nodes according to the routing plan established at call set-up time, or at subscription time (if the network is providing a per- manent virtual circuit service). No additional U-plane functions (see Note) visible to the users are performed by the network. If needed by the application, additional functions are performed end-to-end by layer(s) above the core functions. Note - Some additional auxiliary U-plane functions such as reset or explicit congestion control may be defined if needed from the service perspective. A.2.2 Frame relaying 2 The U-plane configuration for this service is shown in Figure A-2/I.122. Figure A-2/I.122, p. Figure A-2/I.122 shows the network in a generic way and illus- trates all U-plane functions up to and including layer 3. In a specific network, frame relaying 2 may be implemented in one or more nodes, all other nodes in the network providing only circuit-mode functions. Frame relaying 2 can be offered on both, basic and primary rate interfaces and on any ISDN channel (D, B, and H). Some res- trictions (e.g. frame length) apply when in an end-to-end connec- tion at least one of the access channels is the D-channel (16 kbit/s). The bearer service provided by the network at the S/T refer- ence point supports only the core functions defined in S 3.1. A frame received by such a point is discarded if the frame does not meet the I.441 core format requirements (for example, if the frame is too long, has an unknown label, etc.). Moreover, frames may be discarded due to internal network conditions, or other possible reasons such as throughput enforcement. The terminals operate end-to-end with the complete I.441* pro- tocol. In all other cases, the frame is relayed to one of the adja- cent nodes according to the routing plan established at call set-up time, or at subscription time (if the network is providing a per- manent virtual circuit service). No additional U-plane functions (see Note) visible to the users are performed by the network. If needed by the application, additional functions are performed end-to-end by layer(s) above the core functions. Note - Some additional auxiliary U-plane functions such as reset or explicit congestion control may be defined if needed from the service perspective. A.2.3 Frame switching The U-plane configuration for this service is shown in Figure A-3/I.122. Figure A-3/I.122 shows the network in a generic way and illus- trates all functions up to and including layer 3. In a specific network, frame switching must be implemented in at least one node in the network. Figure A-3/I.122, p. Frame switching can be offered on both basic and primary rate interfaces and on any ISDN channel (D, B, and H). Some restrictions (e.g. frame length) apply when in an end-to-end connection at least one of the access channels is the D-channel (16 kbit/s). The bearer service provided by the network at the S/T refer- ence point supports the full Recommendation I.441 function. Received frames that satisfy the Recommendation I.441 procedure are passed on to an adjacent node according to a routine plan esta- blished at call set-up time, or at subscription time. No additional U-plane functions visible to the users are per- formed in the network. If needed by the application, additional functions are performed end-to-end by layer(s) above layer 2. A.2.4 X.25-based additional packet mode The U-plane configuration can comprise several nodes having layer 1, layer 2, and layer 3 functions as is shown in Figure A-4/I.122. Figure A-4/I.122 shows the network in a generic way and illustrates all functions up to and including layer 3. Other configurations with nodes making use only of the core aspects of Recommendation I.441 as defined in S 3.1 of Recommendation I.122 are possible. Figure A-4/I.122, p. X-25-based additional packet mode service can be offered on both the basic and primary rate ISDN access interfaces and on any ISDN channel (D, B, and H). Some restrictions (e.g. packet length) apply when in an end-to-end connection at least one of the access channels is the D-channel (16 kbit/s). The bearer service provided by the network at the S/T refer- ence point supports the full Recommendation I.441 and the data transfer part of Recommendation X.25 PLP functions. The U-plane contains X.25-based layer 3 functions and the C-plane procedures use Recommendation I.451 extended to transfer the parameters necessary for the establishment and release of vir- tual circuits (e.g. throughput class, window size, etc.). The capa- bility to negotiate some parameters must also be provided. Whether or not X.25 multiplexing is provided is for further study. X.25 PLP-DTP consists of all X.25 PLP functions with the exception of the connection establishment and release functions, including user facilities (supplementary services). The exclusion of other X.25 PLP functions is for further study. ANNEX B (to Recommendation I.122) General arrangement for interworking between an ISDN where I.122 bearer services are requested and an ISDN or a PSPDN providing service based on Recommendation X.25 B.1 Possible scenarios Figure B-1/I.122 shows the interworking arrangements con- sidered. When the interworking function IWF logically belongs to the ISDN (Recommendation I.122), interworking based on call control mapping takes place. In the case where the IWF logically belongs to the PSPDN (Recommendation X.25) or ISDN (Recommendation X.31), interworking based on either call control mapping or port access is possible. As shown in the figure, different interfaces can be specified for the different reference points, depending on whether the IWF logically belongs to the ISDN (Recommendation I.122), or to the PSPDN (Recommendation X.25) or ISDN (Recommendation X.31). B.2 IWF logically belonging to ISDN (Recommendation I.122) To enable interworking, the I.122 bearer services, in conjunc- tion with an IWF, should provide full support of the X.213 network layer services. The association of an ISDN (Recommendation I.122) with an IWF in such a manner could therefore be considered globally as a Type I subnetwork, in the sense defined in Recommendation X.300. A PSPDN (Recommendation X.25) or an ISDN (Recommendation X.31) could also be considered as a Type I subnetwork. As specified in Recommendation X.300, the interworking arrangement between two Type I subnetworks should be based on Recommendation X.75. B.3 IWF logically belonging to the PSPDN (Recommendation X.25)/ISDN (Recommendation X.31) The association of a PSPDN (Recommendation X.25)/ISDN (Recommendation X.31) with an IWF together behaves like a user ter- minal requesting I.122 service from an ISDN (Recommendation I.122). Therefore, the interworking arrangement can be based on Recommendation I.122. In this arrangement, interworking based on either call control mapping or port access is possible. When port access method is used, existing call control procedures in Recommendation X.25 are used for the control of virtual circuits. Figure B-1/I.122, p. ANNEX C (to Recommendation I.122) Support of network layer service (X.213) in an ISDN offering additional packet mode bearer services C.1 Network layer service can be provided by using the X.25-based additional packet mode bearer service. In this case the mapping concerns enhanced Recommendations I.451 and X.25 data transfer functions. In the case of frame switching and frame relay- ing, the network layer service can be provided through the use of enhanced Recommendation I.451, with, in addition: a) additional end system functionality, or b) enhanced I.441 functions. C.2 C-plane enhancements Recommendation I.451 should be enhanced so that the OSI net- work service parameters can be paired with Recommendation I.451 messages and information elements for all bearer services. Serveral enhancements to Recommendation I.451 are needed to convey all con- nection establishment and release primitives and parameters in relevant I.451 protocol elements. C.3 U-plane enhancements For frame switching and frame relaying, there are two dif- ferent approaches for the mapping of data transfer primitives into protocol elements: 1) layer 3 protocol elements supported by a DTE specific protocol which is transparent for the network (preferably X.25 PLP), and 2) I.441 protocol elements enhanced to map directly into the OSI network service data transfer primitives. Further study is required for the selection and detailed definition of one of the two options. ANNEX D (to Recommendation I.122) Congestion control in frame relaying service Note - This Annex does not cover congestion control in frame switching and X.25-based additional packet mode bearer services. This is because in these services, there is termination of user data transfer protocol in the network and so existing mechanisms for congestion control can be used. D.1 General objectives of congestion control The term "congestion control" as used here refers to a set of mechanisms incorporated to attain certain network performance objectives, particularly in the peak periods, while optimizing or improving the network resource requirements. 1) The network should, with high probability, meet the Quality of Service in terms of throughput, delay and availabil- ity negotiated with the user. Therefore, the number of occurrences of user perceived congestion should be minimized. 2) Under heavy load, the network should not allow user interference to the extent where one user can monopolize net- work resource usage at the expense of other users. Specific congestion control mechanisms to achieve these objectives are for further study. One possible approach of conges- tion control is presented below. D.2 User reaction to network congestion The network has no other direct control on the data flow of a user other than dropping frames. It does so without sending expli- cit congestion control messages to the user. Frame discard by a network may have charging implications. This requires further study. Users should reduce their information transfer rate when they perceive the impact of network congestion. Reduction of throughput by a user may well result in an increase of the effective throughput available to the user during congestion. It is suggested that a user of frame relaying 1 service imple- ment some form of congestion-sensitive adaptation function that has the following characteristics: i) no blocking of data flow under normal condi- tions, ii) reduction to a lower throughput upon detection of network congestion, iii) progressive increase to the maximum nego- tiated throughput upon congestion abatement. For frame relaying 2 service, the user is required to imple- ment the above congestion-sensitive adaptation function through the use of the windowing mechanism in Recommendation I.441. In this case, the user will base the detection of congestion on events available in the I.441 elements of procedure (e.g. receipt of a REJECT frame, detection of frame loss, etc.). The user dynamically adjusts its window size in accordance with network congestion con- dition. D.3 Control action by the network congestion Users of frame relaying services should reduce their informa- tion transfer rate when they perceive the impact of network conges- tion (see S 2). But the network cannot rely solely on the user's behaviour to control network congestion. This is the case for both frame relaying 1 and frame relaying 2 services. The network should monitor the throughput of each call/interface and exercise a frame discard strategy under conges- tion conditions, for those calls/interfaces that exceed their nego- tiated throughput. However, because congestion can occur even when the calls do not exceed their negotiated throughput (e.g. network failures), the network should discard frames in a way that assures some fairness among users. The selection of mechanism(s) which may be used by the network for this purpose are for further study. Blanc SECTION 3 GENERAL MODELLING METHODS Recommendation I.130 METHOD FOR THE CHARACTERIZATION OF TELECOMMUNICATION SERVICES SUPPORTED BY AN ISDN AND NETWORK CAPABILITIES OF AN ISDN (Melbourne, 1988) 1 General considerations The concept and the principles of ISDNs are described in Recommendation I.120. The purpose of this Recommendation is to pro- vide a method for the characterization of telecommunication ser- vices (including supplementary services) and a definition of the needed network capabilities in an ISDN, in order to support the identified services. The main objectives are: a) to give a common framework and tools to be adopted for service description; b) to show how, starting from the service defini- tion, it is possible to define protocols and network resources for providing such services; c) to make reference to those Recommendations which are relevant to the above two points. 2 Structure and application of the overall method The method is divided into three main stages of activity: service aspects (stage 1), functional network aspects (stage 2) and network implementation aspects (stage 3). Within each stage a number of steps have been identified, as shown in Figure 1/I.130. In principle, the application of the method is sequential, stage 1 given the service description from the user point of view, stage 2 offering an intermediate view of what happens at the user-network interface and inside the network between different exchanges, and stage 3 giving the actual switch- ing and service nodes descriptions, as well as protocols and format to be adopted. In order to classify and relate the various Recommendations relevant to the method, a three level structure is used where each level applies to the three above-mentioned stages. Level 1 is a description of the overall method, and is con- tained in this Recommendation. Level 2 identifies and defines the tools for the work within each stage. Examples of these tools are frameworks for service prose descriptions, libraries of pre-defined functions, graphical conventions, etc. All these tools are covered by Recommendations. Level 3 is the actual application of the method to each indi- vidual service and is contained in various Recommendations. The application of the method for stage 1 results in a description of the service. Stage 2 results in one or more imple- mentation independent scenarios, and stage 3 results in a set of protocol and switching Recommendations needed to realize the ser- vice for each scenario. Figure 2/I.130 illustrates the concept of levels in relation to various Recommendations relevant to the method. Figure 1/I.130, p. 8 Figure 2/I.130, p. 9 3 Description of the method As referred to in S 2 above, there are three stages of the method as follows: Stage 1 is an overall service description from the user's standpoint. Stage 2 is an overall description of the organization of the network functions to map service requirements into network capabil- ities. Stage 3 is the definition of switching and signalling capabil- ities needed to support services defined in stage 1. Each stage consists of several steps. 3.1 Stage 1 Stage 1 is an overall service description from the user's point of view, but does not deal with the details of the human interface itself. The stage 1 service description is independent of the amount of functionality in the user's terminal, other than that required to provide the human interface. For example the conference calling service description is designed to be independent of whether the conference bridge is in the terminal, in the serving exchange or elsewhere. The steps in stage 1 are: Step 1.1 - Service prose definition and description This step describes the service in terms of the percep- tions of the user receiving the service and any other users involved in the service. It describes events in a generic term which does not constrain terminal or network design. It is intended to allow an understanding of the service without regard to imple- mentation. The description should include operational, control, interworking and administrative aspects as well as interactions with other sevices. A detailed format and list of definitions for terms used for service prose definition and description is con- tained in Recommendation I.210. Step 1.2 - Static description of the service using attri- butes The static, that is, time-independent, aspects of a ser- vice can, in some cases, be efficiently described by attributes. An attribute is a characteristic or functional description which is common to several services and therefore needs to be described in detail only once. Subsequently, it can be referred to by a name or other designation. Within the scope of an attribute definition there may be multiple parameters or identified functional varia- tions which are called attribute values. The attribute technique is described more fully in Recommendation I.140. It contains an outline of the technique and definitions of attributes and attributes values, valid for both services and connection types. The attributes and attribute values identified for services can be found in Rec. I.210 (Annexes B and C) for bearer services and for teleservices. The use of the attribute technique in the description of supplementary services is for further study. Step 1.3 - Dynamic description of the service using graphic means The dynamic description of a service contains all the information that is sent and received by the user from activation invocation of the service to completion of the service. The infor- mation is presented in the form of an overall Specification and Description Language (SDL) diagram. An overall SDL diagram is a flow chart which identifies all possible actions relevant to the service as perceived by the user. It treats the network as a single entity, that is, no information flows within the network are con- sidered. The method of using the overall SDL diagrams for service description is given in Recommendation I.210, Annex D. 3.2 Stage 2 Stage 2 identifies the functional capabilities and the infor- mation flows needed to support the service as described in stage 1. The stage 2 description will also include user operations not directly associated with a call (e.g. user change of call forward- ing parameters via his sevice interface) as described in stage 1. Furthermore, it identifies various possible physical locations for the functional capabilities. The output of stage 2 which is signal- ling system independent is used as an input to the design of sig- nalling system and exchange switching Recommendations. The steps in stage 2 are: Step 2.1 - Derivation of a functional model A functional model is derived for each basic and for each supplementary service. The functions required to provide the ser- vice are grouped into functional entities. The functional model is the aggregate of the functional entities and their relationships. The concept of a functional entity is contained in the ISDN func- tional principles Recommendation (I.310). In the case of supplemen- tary services the relationship between the supplementary service and the basic service is shown by a composite functional model. Step 2.2 - Information flow diagrams The distribution of the functions needed to provide a ser- vice as defined by the functional model requires that interactions be defined between functional entities. Such an interaction is referred to as an " information flow " and has a name descriptive of the intent of the information flow. Information flow diagrams are created for successful operation and may be created as appropriate for other cases. The semantic meaning and information content of each information flow is determined. Step 2.3 - SDL diagrams for functional entities The functions performed within a functional entity are identified and represented in the form of a Specification and Description Language (SDL) diagram. The inputs and outputs of the SDL diagram are to and from the users as described in stage 1 and are information flows to and from other functional entities. SDL diagrams are defined for each functional entity based on the information flows defined for the successful operation of the service. The SDL diagram also covers the unsuccessful cases. Step 2.4 - Functional entity actions The actions performed within a functional entity are represented as a list, or sequence, of functional entity actions (FEAs) in prose form. These form the basis for understand- ing the meaning of the information flows and provide a basis for the stage 3 switching Recommendations. Note - The relationship between the FEAs and the elemen- tary functions (EFs), as listed in Recommendation I.310 is for further study. Step 2.5 - Allocation of functional entities to physical locations In this step, the functional entities and information flows identified in previous steps are allocated to specific types of physical locations, e.g. a PABX or an exchange. Each allocation is called a scenario. The relationship supported between two func- tional entities located in different physical locations must be realized wihin protocol(s) supported between those locations. The detailed procedures and formats used and the concepts needed for the stage 2 description can be found in Recommendations Q.65 and I.310. 3.3 Stage 3 In stage 3 the information flow and SDL diagrams from the stage 2 output form the basis for producing the signalling system protocol Recommendations and the switching Recommendations. The steps in stage 3 will need to be repeated for each service where, because of different allocations of functional entities to physical locations, different protocols and procedures are needed. The steps in stage 3 are: Step 3.1 - Protocols and formats The messages needed to support the information flows and the modifications to existing information flows between the nodes are identified and the detailed message elements and procedures are designed into the relevant signalling systems. Step 3.2 - Switching and service nodes The requirements identified for switching functions (func- tional entity actions) are incorporated into the switching Recom- mendations (Q.500-Series). MONTAGE : PAGE 84 = PAGE BLANCHE SECTION 4 TELECOMMUNICATION NETWORK AND SERVICE ATTRIBUTES Recommendation I.140 ATTRIBUTE TECHNIQUE FOR THE CHARACTERIZATION OF TELECOMMUNICATION SERVICES SUPPORTED BY AN ISDN AND NETWORK CAPABILITIES OF AN ISDN (former Recommendation I.130 of the Red Book; amended at Melbourne, 1988) 1 General considerations The purpose of this Recommendation is to introduce the attri- bute technique and to describe attributes and list attribute values. Attributes are used in the characterization of services and network capabilities provided by an ISDN. The attribute technique can also be used to describe the salient features of other objects of study in telecommunications, e.g. charging. This Recommendation (in the general I.100-Series) will act as a library of all attributes and attribute values used in other I-Series Recommendations. The inclusion of a particular attribute value in this Recommendation does not mean that this particular object is being recommended by CCITT, but that it is a potential attribute (or attribute value) which may be used in a particular Recomendation in the I-Series (e.g. to describe a CCITT-recommended service). Annex A includes all attributes and their values so far iden- tified and defined. 2 Attribute technique 2.1 Outline of the technique This technique is used to describe objects in a structured, simple manner and to highlight the important aspects of the object. In order to be able to identify comparable objects, e.g. bearer services, the general concept of the object is broken down in a number of salient features. The salient features are termed attri- butes . | ach attribute is independent of the others so that a change in the value of one will not affect the others. To describe a particular object the attributes are assigned values which iden- tify that object. It is not always necessary or useful to describe an object in great detail and so attributes have been graded into three levels: - dominant attributes : these define a sub-set con- taining similar objects, this sub-set is termed a class or category; - secondary attributes : these define a particular object; and - qualifying attributes : these define variants of an object. Characterization of attributes should be used in the I-Series of Recommendations when appropriate. 2.2 Basic rules - Each attribute is assigned a name and definition. - Some attributes may apply to only one object, others may be applicable to several objects. In this case the same attribute name is used. - A given value should have the same name and definition in all Recommendations. - Depending on the nature of the object described, a particular attribute may need to be used more than once. - Each attribute should be described by three per- spectives; generic, service and network. 2.3 Attribute lists 2.3.1 Generic attributes Information transfer mode Information transfer rate Information transfer capability Establishment Symmetry Configuration Structure Channel (rate) Control protocol Information transfer protocol Performance Interworking Operations Type of user information High layer protocol Note - This list will be completed according to further results on studies of connectionless, multi-media, broadband and mobile services. 2.3.2 Service attributes 2.3.2.1 Bearer services 1 Information transfer mode 2 Information transfer rate 3 Information transfer capability 4 Structure _________________________ Service information transfer rate considered at the ac- cess point. 5 Establishment of communication 6 Symmetry 7 Communication configuration 8 Access channel and rate 9-1 Signalling access protocol layer 1 9-2 Signalling access protocol layer 2 9-3 Signalling access protocol layer 3 Information access protocol (layer 1-3) at the access point. 9-4 Information access protocol layer 1 9-5 Information access protocol layer 2 9-6 Information access protocol layer 3 10 Supplementary services provided 11 Quality of service 12 Interworking possibilities 13 Operational and commercial 2.3.2.2 Teleservices 1, 2, 3, 4, 5, 6, 7, 8, 9-1, 9-2, 9-3, 9-4, 9-5, 9-6: refer to S 2.3.2.1. 10 Type of user information 11 Layer 4 protocol 12 Layer 5 protocol 13 Layer 6 protocol 14 Layer 7 protocol 15 Supplementary services provided 16 Quality of service 17 Interworking possibilities 18 Operational and commercial 2.3.2.3 Supplementary services For further study. 2.3.2.4 Charging For further study. 2.3.3 Network attributes 2.3.3.1 Connection types 1 Information transfer mode 2 Information transfer rate 3 Information transfer susceptance 4 Establishment of communication 5 Symmetry 6 Connection configuration 7 Structure 8 Channel (rate) 9 Connection control protocol 10 Information transfer coding/protocol 11 Network performance 12 Network interworking 13 Operations and management 2.3.3.2 Connection elements 1 Information transfer mode _________________________ Information transfer rate is considered between access points. Information transfer protocol is considered between ac- cess points. 2 Information transfer rate 3 Information transfer susceptance 4 Establishment of communication 5 Symmetry 6 Connection configuration 7 Structure 8 Channel (rate) 9 Connection control protocol 10 Information transfer coding/protocol 11 Network performance 12 Network interworking 13 Operations and management 2.3.3.3 Other network entities The definition of attributes for basic connection components, and network capabilities to support supplementary services needs further study. 2.4 Attribute definition A list of definitions of attributes and attribute values is contained in Annex A to this Recommendation. 3 Application to the I-Series Recommendations This technique has been applied in I.200-Series Recommenda- tions for the specification of the telecommunications services sup- ported by and ISDN and in Recommendation I.340 for the characteri- zation of ISDN connection types and connection elements. The application of the attribute technique for the characteri- zation of multi-media services is for further study. ANNEX A (to Recommendation I.140) List of definitions of attributes and attribute values A.1 Definitions of the attributes A.1.1 Telecomunication service attribute definitions Information transfer mode This attribute describes the operational mode for transferring (transporting and switching) user information through the ISDN. Possible values : - circuit - packet Information transfer rate This attribute describes either the bit rate (circuit mode) or the throughput (packet mode). It refers to the transfer of digital information at the access points. Possible values : - appropriate bit or throughput rate Information transfer capability This attribute describes the capability associated with the transfer of different types of information through the ISDN. Possible values : - unrestricted digital information - speech - 3.1 kHz audio - 7 kHz audio - 15 kHz audio - video - other values Structure This attribute refers to the capability of the ISDN to deliver information to the destination access point or reference point in a structure (e.g. time interval for circuit mode, service data unit for packet mode), that was presented in a corresponding signal structured at the origin (access point or reference point). Possible values : - 8 kHz integrity - service data unit integrity - time slot sequence integrity - restricted differential time delay - unstructured Establishment of communication This attribute describes the mode of establishment associated to the telecommunication service used to establish and release a given communication. Possible values : - demand - reserved - permanent Symmetry This attribute describes the relationship of information flow between two (or more) access points or reference points involved in a communication. Possible values : - unidirectional - bidirectional symmetric - bidirectional asymmetric Communication configuration This attribute describes the spatial arrangement for transfer- ring information between two or more access points. It completes the structure associated with a telecommunication service as it associates the relationship between the access points involved and the flow of information between these access points. Possible values : - point-to-point - multipoint - broadcast Access channel and rate This attribute describes the channels and their bit rate used to transfer the user information and/or signalling information at a given access point. Possible values : - name of the channel (letter) and the corresponding bit rate Note - This attribute can be used several times for communi- cation characterization. Signalling access protocol layer 1-3, information access protocol layer 1-3 These attributes characterize the protocol on the signalling or user information transfer channel at a given access point or reference point. Possible values : - appropriate protocol Type of user information Possible values : - speech - sound - text - facsimile - text-facsimile - videotex - video - text-interactive Layer 4 - 7 protocol These attributes characterize the protocol on the user infor- mation transfer channel at a given access point or reference point. Possible values : - appropriate protocol Supplementary services provided This attribute refers to the supplementary services associated with a given telecommunication service. Quality of service This attribute is described by a group of specific sub-attributes, for example: service reliability, service availa- bility. The values are under study. Interworking possibilities To be defined. Operational and commercial To be defined. A.1.2 Connection type attribute definitions Information transfer mode This attribute describes the operational mode for transferring (transporting and switching) user information through the ISDN. Possible values : - circuit - packet Information transfer rate This attribute describes either the bit rate (circuit mode) or the throughput (packet mode). It refers to the transfer of digital information between access points or reference points. Possible values : - appropriate bit or throughput rate Information transfer susceptance This attribute describes the capability associated with the transfer of different types of information through the ISDN. Possible values : - unrestricted digital information - speech - 3.1 kHz audio - 7 kHz audio - 15 kHz audio - video - other values Establishment of connection This attribute describes the mode of establishment used to establish and release a given connection in an ISDN. Possible values : - demand - semi-permanent - permanent Symmetry This attribute describes the relationship of information flow between two (or more) access points or reference points of a con- nection. Possible values : - unidirectional - bidirectional symmetric - bidirectional asymmetric Connection configuration This attribute describes the spatial arrangement for transfer- ring information on a given connection. It consists of two sub-attributes, topology and dynamics. Structure This attribute refers to the capability of the ISDN to deliver information to the destination access point or reference point in a structure (e.g. time interval for circuit mode, service data unit for packet mode), that was presented in a corresponding signal structured at the origin (access point or reference point). Possible values : - 8 kHz integrity - service data unit integrity - time slot sequence integrity - restricted differential time delay - unstructured Channel (rate) This attribute describes the channels and their bit rate used to transfer the user information and/or signalling information at a given access point. Possible values : - name of the channel (letter) and the corresponding bit rate Note - This attribute can be used several times. Connection control protocol, information transfer coding/protocol These attributes characterize the protocol/coding on the sig- nalling or user information transfer channel at a given access point or reference point. Possible values : - appropriate protocol or coding Network performance This attribute describes the network performance that relates to an ISDN connection. This performance attribute consists of sub-attributes, for example: Error performance : the values are given in the appropriate Recommendations. Slip performance : the values are given in the appropriate Recommendations. The definition of further sub-attributes is for further study. Network interworking To be defined. Operation and management To be defined. A.1.3 Connection element attribute defintions Information transfer mode This attribute describes the operational mode for transferring (transporting and switching) user information through the ISDN. Possible values : - circuit - packet Information transfer rate This attribute describes either the bit rate (circuit mode) or the throughput (packet mode). It refers to the transfer of digital information between access points or reference points. Possible values : - appropriate bit or throughput rate Information transfer susceptance This attribute identifies equipment which may restrict the types of information which may pass through the ISDN. Possible values : - speech processing equipment - echo suppression equipment - multi-satellite hope - null Establishment of connection This attribute describes the mode of establishment used to establish and release a given connection element in an ISDN. Possible values : - demand - semi-permanent - permanent Symmetry This attribute describes the relationship of information flow between two (or more) access points or reference points of a con- nection element. Possible values : - undirectional - bidirectional symmetric - bidirectional asymmetric Connection configuration This attribute describes the spatial arrangement for transfer- ring information across a given connection element. It consists of two sub-attributes, topology and uniformity. Structure This attribute refers to the capability of the ISDN to deliver information to the destination access point or reference point in a structure (e.g. time interval for circuit mode, service data unit for packet mode), that was presented in a corresponding signal structured at the origin (access point or reference point). Possible values : - 8 kHz integrity - service data unit integrity - time slot sequence integrity - 8 kHz integrity with restricted differential time delay - unstructured Channel (rate) This attribute describes the channels and their bit rate used to transfer the user information and/or signalling information at a given access point. Possible values : - name of the channel (letter) and the corresponding bit rate Note - This attribute can be used several times. Connection control protocol, information transfer coding/protocol These attributes characterize the protocol/coding on the sig- nalling or user information transfer channel at a given access point or reference point. Possible values : - appropriate protocol or coding Network performance This attribute describes the network performance that relate to an ISDN connection element. This performance attribute consists of sub-attributes, for example: Error performance : The values are given in the appropriate Recommendations. Slip performance : The values are given in the appropriate Recommendations. The definition of further sub-attributes is for further study. Network interworking To be defined. Operation and management To be defined. A.2 Definition of the attribute values unrestricted digital information Transfer of information sequence of bits at its specified bit rate without alteration. This implies: - bit sequence independence This implies: - digit sequence integrity This implies: - bit integrity. speech Digital representation of speech coded according to a speci- fied encoding rule (e.g. A-law, u-law). 3.1 kHz audio Digital representation of audio information such as voice-band data and speech with a bandwidth of 3.1 kHz, the encoding rule being specified (e.g. A-law, u-law). 7 kHz audio Digital representation of audio information with a bandwidth of 7 kHz, the encoding rule being specified. 15 kHz audio Digital representation of audio information with a bandwidth of 15 kHz, the encoding rule being specified. video Digital representation of video image information, the encod- ing rule being specified. 8 kHz integrity This value applies when: i) at each user-network interface, intervals of 125 us are implicitly or explicitly demarcated, and ii) all bits submitted within a single demarcated 125 us interval are delivered within a corresponding single demar- cated 125 us interval. service data unit integrity This value applies when: i) at each user-network interface, protocols pro- vide a mechanism for identifying the boundaries of service data units (e.g. X.25 complete packet sequence), and ii) all bits submitted within a single service data unit are delivered in a corresponding service data unit. unstructured This value is applicable when the telecommunication service or connection neither provides structural boundaries nor preserves structural integrity. demand (communication) The communication can be started as soon as possible after the request is made (e.g. t1 - t0is as short as possible). Communication and connection release occurs in response to the request of any of the users (calling or called users), t3 - t2is as short as possible (see Figure A-1/I.140). Figure A-1/I.140, p. reserved (communication) The communication can be started at time instant t1explicitly specified at the time instant of communication and connection request, t0. Communication and connection release occurs at time instant t3explicitly specified also at t0. Communication and con- nection duration is predetermined: the communication and connection is set up for a specified period of time. As an option, connection release occurs at time instant t3following a release request made at time instant t2during the communication and a priori undeter- mined (t3 - t2is as short as possible). This option corresponds to an unspecified duration of the communication and connection, or to a possibility of unanticipated release (see Figure A.1/I.140). permanent (communication) The communication can be started after the connection is set up at time instant t1in response to a subscription request for the service at time instant t0. the duration may be unspecified. The communication and connection is released at time instant t3corresponding to the end of the subscription. switched (connection) ISDN circuit switched connections/connection elements are set up at any time on demand via e.g. a bit channel in response to sig- nalling information received from subscribers, other exchanges or other networks, i.e. on a per-call-basis. Message/packet switched connections/connection elements provided by an ISDN may be set up on demand via circuit-mode channels (e.g. B-channels) and special packet switching units or via the D-channel subject to any D-channel priority/flow control restrictions that may be applica- ble. Note - A more general definition of this value is also given in Recommendation I.112 (No.311). semi-permanent (connection) Semi-permanent connections/connection elements pass through a switching network. Semi-permanent connections/connection elements between agreed points may be provided for an indefinite period of time after subscription, for a fixed period or for agreed periods during a day, week or other interval. permanent (connection) Permanent connections/connection elements are described by the following characteristics: Permanent connections/connection elements are available to the connected subscriber at any time during the period of subscription between fixed network destination points requested by the sub- scribers. unidirectional This value applies when the information flow of messages is provided only in one direction. bidirectional symmetric This value applies when the information flow characteristics provided by the service are the same between two (or more) access points or reference points in the forward and backward directions. bidirectional asymmetric This value applies when the information flow characteristics provided by the service are different in the two directions. point-to-point communication This value applies when there are only two access points. multipoint communication This value applies when more than two access points (see Note) are provided by the service. The exact characteristics of the information flows must be specified separately based on functions provided by the ISDN. Note - The number of access points can be undefined. broadcast communication This value applies when more than two access points (see Note) are provided by the service. The information flows from a unique point (source) to the others (destination) in only one direction. Note - The number of destination access points is undefined. point-to-point connection This value applies when only two end points are provided by the connection. multipoint connection This value applies when more than two end points are provided by the connection, and thus many different information flows are possible. broadcast connection To be defined. simple connection A connection consisting of only one connection element. tandem connection Two or more connection elements in series form a connection. parallel connection Two or more connection elements in parallel form a connection. star To be defined. mesh To be defined. uniform This value applies when all connection elements have the same attribute values. non uniform This value applies in all other cases. concurrent The configuration of a connection is described as concurrent when all of the connection elements involved are established simul- taneously and released simultaneously. sequential A connection has a sequential configuration when its connec- tion elements are established and released sequentially i.e. only one of several connection elements or chains of connection elements exists at any given time. add/remove When connection elements can be established and released while other connection elements of the same connections still exist, the configuration of this connection is described as add/remove. Symmetry and/or topology change When the symmetry attribute value of the connection element can be changed during a call. Time slot sequence integrity This value applies when i) at each user-network interface, time slots are implicitly or explicitly demarcated for each access channel of an aggregate of access channels, and ii) the information parts delivered from the time slots at the receiving end are in the same order as submitted at the transmitting end. Note - Preserving the order of bits within an individual time slot from the transmitting to the receiving end is not part of this definition. 8 kHz integrity with restricted differential time delay (RDTD) This value applies when the following conditions are met: - that at each point in a connection or connection element, time slots are explicity or implicitly demarcated for each information channel or an aggregate of information channels; and - that the information parts submitted to the time slots at the transmitting end are delivered to the receiving end with a differential time delay of not more than 50 ms (provi- sional). Recommendation I.141 ISDN NETWORK CHARGING CAPABILITIES ATTRIBUTES (Melbourne, 1988) 1 Preamble On the basis of charging principles provided in the D.200-Series, this Recommendation covers the method for identifying the network charging capabilities and provides a candidate list of attributes in Annex A. 2 General ISDNs shall support a range of services as defined in the I.200-Series of Recommendations. Charging capabilities and mechan- isms need to be associated with each service. To ensure that service charging requirements may be supported by network charging facilities, it is essential that the service requirements be specified in a format which simplifies the identif- ication of network requirements. The attribute technique is con- sidered an appropriate mechanism by which service requirements may be related to network requirements and has thus been utilized in this Recommendation. (See Figure 1/I.141.) Figure 1/I.141, p. 3 ISDN services characteristics Specifically, the services to which network charging capabili- ties attributes should be applied are as given in Table 1/I.141. H.T. [T1.141] TABLE 1/I.141 __________________________________________ Service Recommendations __________________________________________ Bearer services I.230-Series Teleservices I.240-Series Supplementary services I.250-Series __________________________________________ | | | | | | | | | | | | | | | | | | Table 1/I.141 [T1.141], p. 4 Role and application of the attribute technique For each service defined in the I.200-Series Recommendations, one set of attribute values should be selected for each network charging capability attribute. Assignment of attribute values for a specific service will allow the determination of the network requirements relating to this service. The definition of charging requirements in terms of network charging capability attributes is intended to provide a link between the service charging characteristics and the respective network charging mechanisms. Network charging capability attributes are also intended to indicate the range of information to be transferred either within the signalling network or by some other means. Annex A lists the candidate network charging capability attri- butes and the possible values so far identified. ANNEX A (to Recommendation I.141) Candidate network charging capability attributes H.T. [T2.141] TABLE A-1/I.141 _________________________________________________________ Attribute | Possible values _________________________________________________________ Charging capabilities _________________________________________________________ Usage | ua) { Service requested Call attempt | ub) Call set-up Duration Volume Basis of provision } _________________________________________________________ Modulation | | | | | | | | | | | Distance Time of usage _________________________________________________________ Billing capabilities _________________________________________________________ Billing identification { Calling party (sent paid) Called party (reverse/collect) Transferred (third party) } _________________________________________________________ Collection { Subscriber billing Credit card Coin box Debit card } _________________________________________________________ Mode { On line Off line } _________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a) The identification and definition of values for supplementary services (e.g. registration, activation) is for further study. b) For further study. Tableau A-1/I.141 [T2.141], p. 13 MONTAGE : PAGE 100 = PAGE BLANCHE