.rs .\" Troff code generated by TPS Convert from ITU Original Files .\" Not Copyright ( c) 1991 .\" .\" Assumes tbl, eqn, MS macros, and lots of luck. .TA 1c 2c 3c 4c 5c 6c 7c 8c .ds CH .ds CF .EQ delim @@ .EN .nr LL 40.5P .nr ll 40.5P .nr HM 3P .nr FM 6P .nr PO 4P .nr PD 9p .po 4P .rs \v | 5i' .sp 2P .LP \fBRecommendation\ I.122\fR .RT .sp 2P .sp 1P .ce 1000 \fBFRAMEWORK\ FOR\ PROVIDING\ ADDITIONAL\ PACKET\ MODE\ BEARER\ SERVICES\fR .EF '% Fascicle\ III.7\ \(em\ Rec.\ I.122'' .OF '''Fascicle\ III.7\ \(em\ Rec.\ I.122 %' .ce 0 .sp 1P .ce 1000 \fI(Melbourne, 1988)\fR .sp 9p .RT .ce 0 .sp 1P .LP \fB1\fR \fBIntroduction\fR .sp 1P .RT .PP 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. .PP This Recommendation establishes an architectural framework within which additional packet mode bearer services are described. .RT .sp 1P .LP 1.1 \fIScope\fR .sp 9p .RT .PP The architectural framework and service descriptions given in this Recommendation provide the basis for further work to be done by CCITT during the 1989\(hy1992 Study Period. This method of work involves first the description of services and then the development of protocols to support them. .PP 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\(hynetwork 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. .PP The Recommendation also provides a general description on interworking requirements between I.122 based services and I.462 (X.31) based services or PSPDNs. .RT .sp 1P .LP 1.2 \fIObjectives\fR .sp 9p .RT .PP 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 pragmatic approach that minimizes deployment and interworking difficulties, while at the same time providing access to packet services through an integrated physical interface. .PP The evolution of packet mode services in ISDN has been investigated, 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 establish a framework based on the ISDN protocol reference models described in Recommendation\ I.320. More specifically, this framework was aimed at achieving: .RT .LP a) full integration of C\(hyplane (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; .LP b) the decoupling of user information transfer requirements from C\(hyplane transfer requirements. This allows the possibility of defining telecommunication services whose U\(hyplane (user plane) characteristics are tailor\(hymade only to the transfer needs of user information and not to those of C\(hyplane information. .PP The bearer services supported within this architectural framework 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). .bp .sp 1P .LP 1.3 \fIDefinitions of terms\fR .sp 9p .RT .PP In the context of this Recommendation, the following definitions apply: .PP \fINote\fR \ \(em\ This list is not complete. For example, some of these definitions apply to terms relevant to only some of the bearer services discussed in this Recommendation. .RT .sp 1P .LP 1.3.1 \fBdelivered duplicate frames\fR .sp 9p .RT .PP A frame D received by a particular destination user is defined to be a duplicated frame if both of the following conditions are true: .RT .LP a) D was not generated by the source user; .LP b) D is exactly the same as a frame that was previously delivered to that destination. .sp 1P .LP 1.3.2 \fBdelivered errored frames\fR .sp 9p .RT .PP 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). .RT .sp 1P .LP 1.3.3 \fBdelivered out\(hyof\(hysequence frames\fR .sp 9p .RT .PP \fI\fR Consider a sequence of frames \fIF\fR\d1\u, \fIF\fR\d2\u, \fIf\fR\d3\u, | | | , \fIF\fR\d\fIn\fR\u. Assume that \fIF\fR\d1\uis transmitted first, \fIF\fR\d\fI2\fR\usecond, | | | \fIF\fR\d\fIn\fR\ulast. .PP A delivered frame \fIF\fR\d\fIi\fR\uis defined to be out\(hyof\(hysequence if it arrives at the destination user after any of the frames\ \fIF\fR \d(\fIi\fR \ +\ 1) \u, \fIF\fR \d(\fIi\fR \ +\ 2) \u, | | | , \fIF\fR\d\fIn\fR\u. .RT .sp 1P .LP 1.3.4 \fBdynamic window control\fR .sp 9p .RT .PP 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\(hyperceived congestion condition in the network. .RT .sp 1P .LP 1.3.5 \fBend\(hyto\(hyend communication\fR .sp 9p .RT .PP End\(hyto\(hyend communication is a direct peer\(hyto\(hypeer communication of TE to TE, or TE to a network interworking function (IWF) supporting, for example, PSPDN interworking. .RT .sp 1P .LP 1.3.6 \fBexplicit congestion message\fR .sp 9p .RT .PP Explicit congestion message is a message generated by the network and sent to a user terminal to indicate a congestion condition. .RT .sp 1P .LP 1.3.7 \fBimplicit congestion control\fR .sp 9p .RT .PP Implicit congestion control is a scheme under which user terminals first detct a possible congestion condition by means other than explicit congestion messages, and then take appropriate action to reduce their throughput. .RT .sp 1P .LP 1.3.8 \fBinformation integrity\fR .sp 9p .RT .PP Information integrity is a network providing frame\(hyrelaying bearer service defines that all frames carried by the network shall satisfy the FCS check. .RT .sp 1P .LP 1.3.9 \fBlogically separate (C\(hyplane information)\fR .sp 9p .RT .PP Logically separate means that C\(hyplane information is sent separately from U\(hyplane information in one of the following ways: .RT .LP 1) on a physically separate interface; .LP 2) on another channel (time slot) within the same interface; or .LP 3) on a separate logical link within the same channel (e.g.,\ D\(hychannel). .bp .sp 1P .LP 1.3.10 \fBlost frames\fR .sp 9p .RT .PP 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). .RT .sp 1P .LP 1.3.11 \fBmisdelivered frames\fR .sp 9p .RT .PP 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). .RT .sp 1P .LP 1.3.12 \fBquality of service (QOS)\(hyparameter set\fR (See Rec.\ X.213) .sp 9p .RT .PP For each QOS\(hyparameter, a set of \*Qsubparameters\*U is defined from among the following possibilities: .RT .LP a) a \fItarget\fR | value which is the QOS value desired by the calling user; .LP b) the \fIlower quality acceptable\fR | value which is the lowest QOS value agreeable to the calling user. (When the lowest quality acceptable refers to throughput, the term \*Qminimum\*U may be used, while when it refers to transit delay, the term \*Qmaximum\*U may be used.); .LP c) an \fIavailable\fR | value which is the QOS that the network is willing to provide; .LP d) a \fIselected\fR | value which is the QOS value to which the called user agrees. .sp 1P .LP 1.3.13 \fBreal time call establishment\fR .sp 9p .RT .PP The term real time call establishment refers to a set of procedures based on which the communication can be started in a relatively short time (i.e.\ in the order of a few seconds) after the request is made. (See definition for demand communication establishment in Rec.\ I.130). .RT .sp 1P .LP 1.3.14 \fBresidual error rate\fR .sp 9p .RT .PP Residual error rate is defined for both the additional packet\(hymode bearer services and the corresponding layer services. .PP The layer services corresponding to the additional packet\(hymode bearer services are characterized by the exchange of service data units (SDUs). For frame relaying\ 1, SDUs are exchanged at the functional boundary between the core functions of Recommendation .FS I.441* is I.441 with appropriate extensions. The use of the extensions may depend on each bearer service and is for further study. .FE and the end\(hyto\(hyend protocol implemented above them. For frame relaying\ 2 and frame switching, SDUs are exchanged at the functional boundary between the complete I.441* and the end\(hyto\(hyend functions implemented above I.441*. For the X.25\(hybased additional packet mode service (APMS), SDUs are exchanged at the functional boundary of X.25 PLP\(hyDTP (packet layer protocol\(hydata transfer part) and the end\(hyto\(hyend functions implemented above. .PP 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\(hybased APMS, they are packets as defined in X.25 PLP. .PP The residual error rate for the corresponding layer service of APMS is defined as: \v'6p' .RT .sp 1P .ce 1000 \fIR\fR = 1 \(em @ { otal~correct~SDUs~delivered } over { otal~offered~SDUs } @ .ce 0 .sp 1P .PP .sp 1 The residual error rate for the APMS is defined as the ratio: \v'6p' .sp 1P .ce 1000 \fIR\fR = 1 \(em @ { otal~correct~PDUs~delivered } over { otal~offered~PDUs } @ .ce 0 .sp 1P .LP .sp 1 .bp .sp 1P .LP 1.3.15 \fBthroughput\fR .sp 9p .RT .PP Throughput for a virtual connection section .FS Virtual connection section is defined in Rec.\ X.134. .FE in a network providing 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 section per unit time. Successful transfer means that the FCS check for each frame is satisfied. .RT .sp 1P .LP 1.3.16 \fBtransit delay\fR .sp 9p .RT .PP Transit delay is defined only between pairs of section boundaries .FS The definition of section boundaries is given in Rec.\ X.134. .FE . Transit delay of a frame protocol data unit (FPDU) .FS The definition of FPDU is given above in residual error rate. .FE starts at the time\ \fIt\fR\d1\uat which the first bit of the FPDU crosses the first boundary, and ends at the time\ \fIt\fR\d2\uat which the last bit of the FPDU crosses the second boundary. .PP Transit delay = \fIt\fR\d2\u\(em\fIt\fR\d1\u. .RT .sp 2P .LP \fB2\fR \fBService aspects\fR .sp 1P .RT .sp 1P .LP 2.1 \fIGeneral service characteristics\fR .sp 9p .RT .PP This Recommendation describes a set of potential packet mode bearer services that have the following characteristics in common: .RT .LP 1) All C\(hyplane 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). .LP 2) The U\(hyplane procedures share the same layer 1 functions based on Rec.\ I.430/I.431. Moreover, they share the same core procedres, defined in \(sc\ 3.1, that among other functions allow for statistical multiplexing of user information flows immediately above the layer\ 1 functions. .PP The basic bearer service provided by the network is the order preserving bidirectional transfer (see \(sc\ 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 .PP 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\(hyup by means of C\(hyplane 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 identifier 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. .PP 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. .RT .sp 1P .LP 2.2 \fIQuality of Service parameters\fR .sp 9p .RT .PP Each potential bearer service described in this Recommendation provides service quality that is characterized by the values of the following parameters: .RT .LP 1) throughput; .LP 2) transit delay; .LP 3) information integrity; .LP 4) residual error rate; .LP 5) delivered errored frames; .LP 6) delivered duplicated frames; .LP 7) delivered out\(hyof\(hysequence frames; .bp .LP 8) lost frames; .LP 9) misdelivered frames; .LP 10) others for further study. .PP \fINote\fR \ \(em\ The applicability and values of these parameters for different bearer services are for further study. .sp 1P .LP 2.3 \fIIndividual\fR \fIbearer service descriptions\fR .sp 9p .RT .PP This section contains descriptions of four specific potential bearer services proposed for standardization: .RT .LP a) frame relaying 1, .LP b) frame relaying 2, .LP c) frame switching, and .LP d) X.25\(hybased additional packet mode. .sp 1P .LP 2.3.1 \fIFrame relaying 1 service description\fR .sp 9p .RT .PP Frame relaying 1 shares with the other services the general service characteristics and quality of service parameters described in \(sc\(sc\ 2.1 and 2.2, respectively. .PP 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 specifically, in the U\(hyplane: .RT .LP 1) it preserves their order as given at one S/T reference point if and when they are delivered at the other end. .LP \fINote\fR \ \(em\ 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; .LP 2) it detects transmission, format and operational errors (e.g. frames of unknown DLCI); .LP 3) frames are transported transparently (in the network), only the address and FCS field may be modified; .LP 4) it does not acknowledge frames (within the network). .PP All of the above functions are based on Rec.\ I.441. Appropriate extensions to the core functions of Rec.\ I.441 may be needed, e.g.\ for congestion control. In the C\(hyplane 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 services. In the case of permanent virtual circuits (PVC) no real time call establishment is necessary and parameters are agreed upon at subscription time. .PP However, additional functions are needed: .RT .LP \(em to monitor throughput and to enforce it, .LP \(em to control congestion. .PP The mechanisms to achieve these functions are still under investigation. .PP 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. .PP From the service perspective, frame relaying 1 provides service quality characteristics with the following parameter values: .PP (Parameter values are for further study). .RT .sp 1P .LP 2.3.2 \fIFrame relaying 2 service description\fR .sp 9p .RT .PP Frame relaying 2 shares with the other services the general service characteristics and Quality of Service parameters described in \(sc\(sc\ 2.1 and 2.2, respectively. .bp .PP 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 specifically, in the U\(hyplane: .RT .LP 1) it preserves their order as given at one S/T reference point if and when they are delivered at the other end. .LP \fINote\fR \ \(em\ 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; .LP 2) it detects transmission, format and operational errors (e.g. frames of unknown DLCI); .LP 3) frames are transported transparently in the network, only the address and FCS field may be modified; .LP 4) it does not acknowledge frames (within the network); .LP 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.) .PP All of the above functions are based on Rec.\ I.441. Appropriate extensions to Rec.\ I.441 may be needed, e.g.\ in relation to congestion control. .PP In the C\(hyplane 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 services. In the case of permanent virtual circuits (PVC) no real time call establishment is necessary and any parameters are agreed upon at subscription time. .PP However, additional network functions are needed: .RT .LP \(em to monitor throughput and to enforce it, .LP \(em to control congestion. .PP The mechanisms to achieve these functions are still under investigation. .PP 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. .PP 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\(hyto\(hyend above the core functions are user selectable and may not be the upper part of Rec.\ I.441. Consequently, in frame relaying\ 1 the network in principle has no knowledge of the protocol used end\(hyto\(hyend. .PP From the service perspective, frame relaying 2 provides service quality characteristics with the following parameter values: .PP (Parameter values are for further study). .PP The terminal operates with an extended I.441 protocol. As a result the user perspective is the transparent transport of data end\(hyto\(hyend, with a quality influenced by the statistical multiplexing of data streams in the network. Acknowledgement of data is end\(hyto\(hyend as well as error detection and recovery. .RT .sp 1P .LP 2.3.3 \fIFrame switching service description\fR .sp 9p .RT .PP Frame switching has general service characteristics and Quality of Service parameters as given in \(sc\(sc\ 2.1 and 2.2, respectively. .PP In addition, in the U\(hyplane, frame switching: .RT .LP 1) provides for the acknowledged transport of frames; .LP 2) detects and recovers from transmission, format, and operational error; .LP 3) detects and recovers from lost or duplicated frames; .LP 4) provides flow control. .PP All of the above functions are based on Recommendation\ I.441. Appropriate extensions to Recommendation\ I.441 may be needed. .bp .PP In the C\(hyplane all signalling capabilities for all 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 circuits no real time call establishment is necessary and any parameters are agreed upon at subscription time. .PP From the service perspective, frame switching provides service quality characteristics with the following parameter values: .PP (Parameter values are for further study). .RT .sp 1P .LP 2.3.4 \fIX.25\(hybased\fR \fIadditional packet mode service description\fR .sp 9p .RT .PP X.25\(hybased additional packet mode has general service characteristics and Quality of Service parameters similar to the packet mode services described in X.31. .PP The U\(hyplane capabilities are the same as in X.25 PLP Data Transfer Part (DTP) .PP In the C\(hyplane 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 services. In the case of permanent virtual circuits (PVC) no real time call establishment is necessary and any parameters are agreed upon at subscription time. .RT .sp 2P .LP \fB3\fR \fBUser\(hynetwork interface protocol reference model\fR .sp 1P .RT .PP 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\(hynetwork interface protocol architecture. Only those functions on the network side that are visible on the user side of the S/T reference point are shown. .PP On the user side, Recommendations I.430 or I.431 provide the layer 1 protocol for the U\(hy (user) C\(hy (control) planes. The C\(hyplane uses the D\(hychannel 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\(hyplane may use any channel (D, B, H\d0\uand H\d1\u) on which the user implements at least the lower part (the core functions) of Recommendation\ I.441. .RT .LP .rs .sp 23P .ad r \fBFigure 1/I.122, p.\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [T1.122]\fR .ce TABLE\ 1/I.122 .ce \fBU\(hyplane functions applicable to each bearer service\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(96p) | cw(66p) | cw(66p) . Bearer service User terminal (Note 1) Network _ .T& lw(96p) | lw(66p) | lw(66p) . Frame relaying 1 I.441* Core (Note 2) I.441* Core _ .T& lw(96p) | lw(66p) | lw(66p) . Frame relaying 2 I.441* I.441* Core _ .T& lw(96p) | lw(66p) | lw(66p) . Frame switching I.441* I.441* _ .T& lw(96p) | lw(66p) | lw(66p) . { X.25\(hybased additional packet mode } I.441* X.25 DTP I.441* X.25 DTP .TE .LP \fINote\ 1\fR \ \(em\ Additional user selectable functions may be implemented. .LP \fINote\ 2\fR \ \(em\ I.441* is I.441 with appropriate extensions. The use of the extensions may depend on each bearer service and is for further study. .nr PS 9 .RT .ad r \fBTable 1/I.122 [T1.122], p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 3.1 \fICore functions of Rec. I.441\fR .sp 9p .RT .PP The core functions are: .RT .LP \(em frame delimiting, alignment, and transparency, .LP \(em frame multiplexing/demultiplexing using the address field, .LP \(em inspection of the frame to ensure that it consists of an integer number of octets prior to zero bit insertion or following zero bit extraction, .LP \(em inspection of the frame to ensure that it is neither too long nor too short (see Note), .LP \(em detection of transmission errors. .PP \fINote\fR \ \(em\ The maximum and minimum frame lengths that apply to the Additional packet mode bearer services are for further study. .sp 1P .LP 3.2 \fIOther\fR \fIuser terminal functions\fR .sp 9p .RT .PP If not already prescribed by the selected packet mode bearer service, the user may also implement functions such as, for example, 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. .RT .sp 1P .LP 3.3 \fINetwork functions\fR .sp 9p .RT .PP On the network side, Recommendations I.430 or I.431 provide the layer 1 protocol for both C\(hy and U\(hyplanes. The C\(hyplane is handled just as on the user side, i.e.\ the network fully terminates the protocols of Recommendations\ I.441 and I.451. In the U\(hyplane, 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\(hyplane 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. .PP Interactions between the U\(hy and C\(hyplanes of the terminal, and between the U\(hy and C\(hyplanes of the network are independent. As a result, coordination between the U\(hy and C\(hyplanes at the users equipment is not the responsibility of the network. .bp .PP During the three phases of a call (call establishment, data transfer, and call clearing), C\(hy and U\(hyplane synchronization is achieved in a similar way as for all ISDN telecommunications services. That is, after the C\(hyplane has established the connection, the U\(hyplane may commence data transfer with or .PP without an initialization procedure in the U\(hyplane. In the case of permanent virtual circuit the establishment and call clearing is accomplished by administrative procedures. .RT .sp 1P .LP 3.4 \fIFurther service requirements at the user\(hynetwork interface\fR .sp 9p .RT .PP Procedures at the user\(hynetwork interface should be also applicable when two users are connected via a circuit mode bearer service (permanent or demand). Mechanisms that can be used to achieve this objective include, for example, the symmetrization of the procedure involved, or the use of additional procedures for the determination of the asymmetric relationships. The selection of such a mechanism is for further study. .RT .sp 1P .LP 3.5 \fIPotential bearer services\fR .sp 9p .RT .PP 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 terminated only end\(hyto\(hyend. .PP The second potential bearer service, frame relaying 2, is provided when no functions above the core functions are terminated by the network; I.441 upper functions are terminated only at the end points. .PP The third potential bearer service, frame switching, is provided when the full Recommendation\ I.441 protocol is terminated by the network. .PP The fourth potential bearer service, X.25\(hybased additional packet mode, is provided when the full Recommendation\ I.441 protocol and the data transfer part (DTP) of Recommendation\ X.25 PLP (packet layer protocol) are terminated by the network. .PP Further information on the service characteristics of these four potential bearer services is given in Annex\ A. .RT .sp 2P .LP \fB4\fR \fBInterworking requirements\fR .sp 1P .RT .sp 1P .LP 4.1 \fIInterworking between packet mode services\fR .sp 9p .RT .PP 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: .RT .LP 1) an ISDN offering any of these additional packet mode bearer services, .LP 2) an X.25\(hybased service offered either by an ISDN or a PSPDN. .PP For interworking configuration 1), procedures for both the C\(hyplane and the U\(hyplane at an internetwork reference point which includes international gateway reference points, have to be standardized. In addition it would be desirable that these procedures be developed in such a way that they also could be used at an inter\(hyexchange 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. .PP 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. .RT .sp 1P .LP 4.2 \fISupport of existing terminals\fR .sp 9p .RT .PP Additionally, terminal adapter functions should be provided that allow existing terminals (e.g.\ asynchronous, start/stop DTEs, X.25 packet mode DTEs and V\(hySeries interface terminals) to access from an ISDN one or more of the bearer services described in this Recommendation. .RT .sp 1P .LP 4.3 \fIInterworking with circuit mode services\fR .sp 9p .RT .PP Other service interworking configurations (e.g. with a CSPDN, or between different bearer services within an ISDN) may also need to be considered. .bp .RT .sp 2P .LP \fB5\fR \fBSupport of OSI connection\(hyoriented network layer service\fR .sp 1P .RT .PP In the interworking between an ISDN offering any of the bearer services described in this Recommendation and X.25\(hybased service offered either by an ISDN or a PSPDN, an interworking function (IWF) is required. .PP To support network layer service (Rec.\ X.213) when the bearer service used is one of the bearer services described in this Recommendation, the use of additional end system functionality may be required and end\(hyto\(hyend (i.e.\ TE\(hyto\(hyTE or TE\(hyto\(hyIWF) compatibility must be ensured. .PP Annex C contains requirements for the support of network layer service (Rec.\ X.213). .RT .sp 2P .LP \fB6\fR \fBApplications\fR .sp 1P .RT .PP 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: .RT .LP 1) \fIBlock interactive data applications\fR .LP 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. .LP 2) \fIFile transfer\fR .LP 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 necessary in order to produce reasonable transfer times for large files. .LP 3) \fIMultiplexed low bit rate\fR .LP The multiplexed low bit rate application exploits the multiplexing 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\(hychannel 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. .LP 4) \fICharacter\(hyinteractive traffic\fR .LP An example of a character\(hyinteractive traffic is text editing. The main characteristics of this type of applications are short frames, low delays and low throughput. .PP Identification of additional applications and their characteristics (e.g.\ delay, throughput,\ etc.) for bearer services described in this Recommendation are desirable for the complete definition of the service requirements. \v'1P' .ce 1000 ANNEX\ A .ce 0 .ce 1000 (to Recommendation I.122) .sp 9p .RT .ce 0 .ce 1000 \fBFurther service\(hyrelated information\fR .sp 1P .RT .ce 0 .LP A.1 \fIIntroduction\fR .sp 1P .RT .PP 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. .bp .RT .sp 2P .LP A.2 \fIService related information\fR .sp 1P .RT .sp 1P .LP A.2.1 \fIFrame relaying 1\fR .sp 9p .RT .PP The U\(hyplane configuration for this service is shown in Figure\ A\(hy1/I.122. .RT .LP .rs .sp 24P .ad r \fBFigure A\(hy1/I.122, p.\fR .sp 1P .RT .ad b .RT .PP Figure A\(hy1/I.122 shows the network in a generic way and illustrates all U\(hyplane 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\(hymode functions. .PP Frame relaying 1 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\(hyto\(hyend connection at least one of the access channels is the D\(hychannel (16\ kbit/s). .PP The bearer service provided by the network at the S/T reference point supports only the core functions defined in \(sc\ 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. .PP In all other cases, the frame is relayed to one of the adjacent nodes according to the routing plan established at call set\(hyup time, or at subscription time (if the network is providing a permanent virtual circuit service). .PP No additional U\(hyplane functions (see Note) visible to the users are performed by the network. If needed by the application, additional functions are performed end\(hyto\(hyend by layer(s) above the core functions. .PP \fINote\fR \ \(em\ Some additional auxiliary U\(hyplane functions such as reset or explicit congestion control may be defined if needed from the service perspective. .bp .RT .sp 1P .LP A.2.2 \fIFrame relaying 2\fR .sp 9p .RT .PP The U\(hyplane configuration for this service is shown in Figure\ A\(hy2/I.122. .RT .LP .rs .sp 20P .ad r \fBFigure A\(hy2/I.122, p.\fR .sp 1P .RT .ad b .RT .PP Figure A\(hy2/I.122 shows the network in a generic way and illustrates all U\(hyplane 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\(hymode functions. .PP Frame relaying 2 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\(hyto\(hyend connection at least one of the access channels is the D\(hychannel (16\ kbit/s). .PP The bearer service provided by the network at the S/T reference point supports only the core functions defined in \(sc\ 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. .PP The terminals operate end\(hyto\(hyend with the complete I.441* protocol. In all other cases, the frame is relayed to one of the adjacent nodes according to the routing plan established at call set\(hyup time, or at subscription time (if the network is providing a permanent virtual circuit service). .PP No additional U\(hyplane functions (see Note) visible to the users are performed by the network. If needed by the application, additional functions are performed end\(hyto\(hyend by layer(s) above the core functions. .PP \fINote\fR \ \(em\ Some additional auxiliary U\(hyplane functions such as reset or explicit congestion control may be defined if needed from the service perspective. .RT .sp 1P .LP A.2.3 \fIFrame switching\fR .sp 9p .RT .PP The U\(hyplane configuration for this service is shown in Figure\ A\(hy3/I.122. .RT .PP Figure A\(hy3/I.122 shows the network in a generic way and illustrates 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. .bp .RT .LP .rs .sp 15P .ad r \fBFigure A\(hy3/I.122, p.\fR .sp 1P .RT .ad b .RT .PP 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\(hyto\(hyend connection at least one of the access channels is the D\(hychannel (16\ kbit/s). .PP The bearer service provided by the network at the S/T reference 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 established at call set\(hyup time, or at subscription time. .PP No additional U\(hyplane functions visible to the users are performed in the network. If needed by the application, additional functions are performed end\(hyto\(hyend by layer(s) above layer\ 2. .RT .sp 1P .LP A.2.4 \fIX.25\(hybased additional packet mode\fR .sp 9p .RT .PP The U\(hyplane configuration can comprise several nodes having layer 1, layer 2, and layer\ 3 functions as is shown in Figure\ A\(hy4/I.122. Figure\ A\(hy4/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 \(sc\ 3.1 of Recommendation\ I.122 are possible. .RT .LP .rs .sp 17P .ad r \fBFigure A\(hy4/I.122, p.\fR .sp 1P .RT .ad b .RT .LP .bp .PP X\(hy25\(hybased 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\(hyto\(hyend connection at least one of the access channels is the D\(hychannel (16\ kbit/s). .PP The bearer service provided by the network at the S/T reference point supports the full Recommendation\ I.441 and the data transfer part of Recommendation\ X.25 PLP functions. .PP The U\(hyplane contains X.25\(hybased layer 3 functions and the C\(hyplane procedures use Recommendation\ I.451 extended to transfer the parameters necessary for the establishment and release of virtual circuits (e.g.\ throughput class, window size,\ etc.). The capability to negotiate some parameters must also be provided. Whether or not X.25 multiplexing is provided is for further study. .PP X.25 PLP\(hyDTP 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. \v'1P' .RT .ce 1000 ANNEX\ B .ce 0 .ce 1000 (to Recommendation I.122) .sp 9p .RT .ce 0 .ce 1000 \fBGeneral arrangement for interworking between an ISDN\fR .sp 1P .RT .ce 0 .ce 1000 \fBwhere I.122 bearer services are requested\fR .ce 0 .ce 1000 \fBand an ISDN or a PSPDN providing service based on Recommendation X.25\fR .ce 0 .LP B.1 \fIPossible scenarios\fR .sp 1P .RT .PP Figure B\(hy1/I.122 shows the interworking arrangements considered. 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). .RT .sp 1P .LP B.2 \fIIWF logically belonging to ISDN (Recommendation I.122)\fR .sp 9p .RT .PP To enable interworking, the I.122 bearer services, in conjunction 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. .PP A PSPDN (Recommendation X.25) or an ISDN (Recommendation X.31) could also be considered as a Type\ I subnetwork. .PP As specified in Recommendation X.300, the interworking arrangement between two Type\ I subnetworks should be based on Recommendation\ X.75. .RT .sp 1P .LP B.3 \fIIWF logically belonging to the PSPDN (Recommendation X.25)/ISDN\fR \fI(Recommendation X.31)\fR .sp 9p .RT .PP The association of a PSPDN (Recommendation X.25)/ISDN (Recommendation\ X.31) with an IWF together behaves like a user terminal requesting I.122 service from an ISDN (Recommendation\ I.122). Therefore, the interworking arrangement can be based on Recommendation\ I.122. .PP 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. .bp .RT .LP .rs .sp 30P .ad r \fBFigure B\(hy1/I.122, p.\fR .sp 1P .RT .ad b .RT .ce 1000 ANNEX\ C .ce 0 .ce 1000 (to Recommendation I.122) .sp 9p .RT .ce 0 .ce 1000 \fBSupport of network layer service (X.213)\fR .sp 1P .RT .ce 0 .ce 1000 \fBin an ISDN offering additional packet mode bearer services\fR .ce 0 .PP C.1 Network layer service can be provided by using the X.25\(hybased 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 relaying, the network layer service can be provided through the use of enhanced Recommendation\ I.451, with, in addition: .sp 1P .RT .LP a) additional end system functionality, or .LP b) enhanced I.441 functions. .sp 1P .LP C.2 \fIC\(hyplane enhancements\fR .sp 9p .RT .PP Recommendation I.451 should be enhanced so that the OSI network 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 connection establishment and release primitives and parameters in relevant I.451 protocol elements. .bp .RT .sp 1P .LP C.3 \fIU\(hyplane enhancements\fR .sp 9p .RT .PP For frame switching and frame relaying, there are two different approaches for the mapping of data transfer primitives into protocol elements: .RT .LP 1) layer 3 protocol elements supported by a DTE specific protocol which is transparent for the network (preferably X.25 PLP), and .LP 2) I.441 protocol elements enhanced to map directly into the OSI network service data transfer primitives. .PP Further study is required for the selection and detailed definition of one of the two options. \v'1P' .ce 1000 ANNEX\ D .ce 0 .ce 1000 (to Recommendation I.122) .sp 9p .RT .ce 0 .ce 1000 \fBCongestion control in frame relaying service\fR .sp 1P .RT .ce 0 .PP \fINote\fR \ \(em\ This Annex does not cover congestion control in frame switching and X.25\(hybased 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. .sp 1P .RT .sp 1P .LP D.1 \fIGeneral objectives of\fR \fIcongestion control\fR .sp 9p .RT .PP The term \*Qcongestion control\*U 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. .RT .LP 1) The network should, with high probability, meet the Quality of Service in terms of throughput, delay and availability negotiated with the user. Therefore, the number of occurrences of user perceived congestion should be minimized. .LP 2) Under heavy load, the network should not allow user interference to the extent where one user can monopolize network resource usage at the expense of other users. .PP Specific congestion control mechanisms to achieve these objectives are for further study. One possible approach of congestion control is presented below. .sp 1P .LP D.2 \fIUser reaction to network congestion\fR .sp 9p .RT .PP The network has no other direct control on the data flow of a user other than dropping frames. It does so without sending explicit congestion control messages to the user. Frame discard by a network may have charging implications. This requires further study. .PP 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. .PP It is suggested that a user of frame relaying 1 service implement some form of congestion\(hysensitive adaptation function that has the following characteristics: .RT .LP i) no blocking of data flow under normal conditions, .LP ii) reduction to a lower throughput upon detection of network congestion, .LP iii) progressive increase to the maximum negotiated throughput upon congestion abatement. .PP For frame relaying 2 service, the user is required to implement the above congestion\(hysensitive 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 condition. .bp .sp 1P .LP D.3 \fIControl action by the network congestion\fR .sp 9p .RT .PP Users of frame relaying services should reduce their information transfer rate when they perceive the impact of network congestion (see \(sc\ 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. .PP The network should monitor the throughput of each call/interface and exercise a frame discard strategy under congestion conditions, for those calls/interfaces that exceed their negotiated 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. .PP The selection of mechanism(s) which may be used by the network for this purpose are for further study. .RT .LP .rs .sp 43P .ad r Blanc .ad b .RT .LP .bp .sp 1P .ce 1000 \v'3P' SECTION\ 3 .ce 0 .sp 1P .ce 1000 \fBGENERAL MODELLING METHODS\fR .ce 0 .sp 1P .sp 2P .LP \fBRecommendation\ I.130\fR .RT .sp 2P .ce 1000 \fBMETHOD FOR THE CHARACTERIZATION OF TELECOMMUNICATION\fR .EF '% Fascicle\ III.7\ \(em\ Rec.\ I.130'' .OF '''Fascicle\ III.7\ \(em\ Rec.\ I.130 %' .ce 0 .ce 1000 \fBSERVICES SUPPORTED BY AN ISDN AND NETWORK\fR .ce 0 .sp 1P .ce 1000 \fBCAPABILITIES OF AN ISDN\fR .ce 0 .sp 1P .ce 1000 \fI(Melbourne, 1988)\fR .sp 9p .RT .ce 0 .sp 1P .LP \fB1\fR \fBGeneral considerations\fR .sp 1P .RT .PP The concept and the principles of ISDNs are described in Recommendation\ I.120. The purpose of this Recommendation is to provide a method for the characterization of telecommunication services (including supplementary services) and a definition of the needed network capabilities in an ISDN, in order to support the identified services. .PP The main objectives are: .RT .LP a) to give a common framework and tools to be adopted for service description; .LP b) to show how, starting from the service definition, it is possible to define protocols and network resources for providing such services; .LP c) to make reference to those Recommendations which are relevant to the above two points. .sp 2P .LP \fB2\fR \fBStructure and application of the overall method\fR .sp 1P .RT .PP 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). .PP 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\(hynetwork interface and inside the network between different exchanges, and stage\ 3 giving the actual switching and service nodes descriptions, as well as protocols and format to be adopted. .PP 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\(hymentioned stages. .PP Level\ 1 is a description of the overall method, and is contained in this Recommendation. .PP 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\(hydefined functions, graphical conventions,\ etc. All these tools are covered by Recommendations. .PP Level\ 3 is the actual application of the method to each individual service and is contained in various Recommendations. .PP The application of the method for stage\ 1 results in a description of the service. Stage\ 2 results in one or more implementation independent scenarios, and stage\ 3 results in a set of protocol and switching Recommendations needed to realize the service for each scenario. .PP Figure\ 2/I.130 illustrates the concept of levels in relation to various Recommendations relevant to the method. .bp .RT .LP .rs .sp 47P .ad r \fBFigure 1/I.130, p. 8\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure 2/I.130, p. 9\fR .sp 1P .RT .ad b .RT .LP .bp .sp 2P .LP \fB3\fR \fBDescription of the method\fR .sp 1P .RT .PP As referred to in \(sc\ 2 above, there are three stages of the method as follows: .PP Stage\ 1 is an overall service description from the user's standpoint. .PP Stage\ 2 is an overall description of the organization of the network functions to map service requirements into network capabilities. .PP Stage\ 3 is the definition of switching and signalling capabilities needed to support services defined in stage\ 1. .PP Each stage consists of several steps. .RT .sp 1P .LP 3.1 \fIStage 1\fR .sp 9p .RT .PP 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. .PP The steps in stage\ 1 are: .RT .LP \fIStep 1.1\ \(em\ Service prose definition and description\fR .LP This step describes the service in terms of the perceptions 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 implementation. 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 contained in Recommendation\ I.210. .LP \fIStep 1.2\ \(em\ Static description of the service using attributes\fR .LP The static, that is, time\(hyindependent, aspects of a service 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 variations which are called attribute values. .LP 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. .LP \fIStep 1.3\ \(em\ Dynamic description of the service using\fR \fIgraphic means\fR .LP 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 information 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 considered. The method of using the overall SDL diagrams for service description is given in Recommendation\ I.210, Annex\ D. .sp 1P .LP 3.2 \fIStage 2\fR .sp 9p .RT .PP Stage 2 identifies the functional capabilities and the information 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 forwarding 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 signalling system independent is used as an input to the design of signalling system and exchange switching Recommendations. .bp .PP The steps in stage\ 2 are: .RT .LP \fIStep 2.1\ \(em\ Derivation of a functional model\fR .LP A functional model is derived for each basic and for each supplementary service. The functions required to provide the service 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 functional principles Recommendation\ (I.310). In the case of supplementary services the relationship between the supplementary service and the basic service is shown by a composite functional model. .LP \fIStep 2.2\ \(em\ Information flow diagrams\fR .LP The distribution of the functions needed to provide a service as defined by the functional model requires that interactions be defined between functional entities. Such an interaction is referred to as an \*Q information flow \*U 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. .LP \fIStep 2.3\ \(em\ SDL diagrams for functional entities\fR .LP 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. .LP 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. .LP \fIStep 2.4\ \(em\ Functional entity actions\fR .LP 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 understanding the meaning of the information flows and provide a basis for the stage\ 3 switching Recommendations. .LP \fINote\fR \ \(em\ The relationship between the FEAs and the elementary functions\ (EFs), as listed in Recommendation\ I.310 is for further study. .LP \fIStep 2.5\ \(em\ Allocation of functional entities to physical\fR \fIlocations\fR .LP 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 functional entities located in different physical locations must be realized wihin protocol(s) supported between those locations. .LP 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. .sp 1P .LP 3.3 \fIStage 3\fR .sp 9p .RT .PP 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. .PP 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. .PP The steps in stage\ 3 are: .RT .LP \fIStep 3.1\ \(em\ Protocols and formats\fR .LP 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. .LP \fIStep 3.2\ \(em\ Switching and service nodes\fR .LP The requirements identified for switching functions (functional entity actions) are incorporated into the switching Recommendations (Q.500\(hySeries). .bp .LP \fBMONTAGE : PAGE 84 = PAGE BLANCHE\fR .sp 1P .RT .LP .bp .sp 1P .ce 1000 \v'3P' SECTION\ 4 .ce 0 .sp 1P .ce 1000 \fBTELECOMMUNICATION NETWORK AND SERVICE ATTRIBUTES\fR \v'1P' .ce 0 .sp 1P .sp 2P .LP \fBRecommendation\ I.140\fR .RT .sp 2P .LP .EF '% Fascicle\ III.7\ \(em\ Rec.\ I.140'' .OF '''Fascicle\ III.7\ \(em\ Rec.\ I.140 %' .ce 1000 \fBATTRIBUTE TECHNIQUE FOR THE CHARACTERIZATION OF\fR .ce 0 .ce 1000 \fBTELECOMMUNICATION SERVICES SUPPORTED BY AN\fR .ce 0 .sp 1P .ce 1000 \fBISDN AND NETWORK CAPABILITIES OF AN ISDN\fR .ce 0 .sp 1P .ce 1000 \fI(former Recommendation I.130 of the Red Book;\fR .sp 9p .RT .ce 0 .sp 1P .ce 1000 \fIamended at Melbourne, 1988)\fR .ce 0 .sp 1P .LP \fB1\fR \fBGeneral considerations\fR .sp 1P .RT .PP The purpose of this Recommendation is to introduce the attribute 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. .PP This Recommendation (in the general\ I.100\(hySeries) will act as a library of all attributes and attribute values used in other I\(hySeries\ 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\(hySeries (e.g.\ to describe a CCITT\(hyrecommended service). .PP Annex\ A includes all attributes and their values so far identified and defined. .RT .sp 2P .LP \fB2\fR \fBAttribute technique\fR .sp 1P .RT .sp 1P .LP 2.1 \fIOutline of the technique\fR .sp 9p .RT .PP 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 \fIattributes\fR . | 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 identify that object. .PP It is not always necessary or useful to describe an object in great detail and so attributes have been graded into three levels: .RT .LP \(em dominant attributes : these define a sub\(hyset containing similar objects, this sub\(hyset is termed a class or category; .LP \(em secondary attributes : these define a particular object; and .LP \(em qualifying attributes : these define variants of an object. .PP Characterization of attributes should be used in the I\(hySeries of Recommendations when appropriate. .bp .sp 1P .LP 2.2 \fIBasic rules\fR .sp 9p .RT .LP \(em Each attribute is assigned a name and definition. .LP \(em Some attributes may apply to only one object, others may be applicable to several objects. In this case the same attribute name is used. .LP \(em A given value should have the same name and definition in all Recommendations. .LP \(em Depending on the nature of the object described, a particular attribute may need to be used more than once. .LP \(em Each attribute should be described by three perspectives; generic, service and network. .sp 2P .LP 2.3 \fIAttribute lists\fR .sp 1P .RT .sp 1P .LP 2.3.1 \fIGeneric attributes\fR .sp 9p .RT .LP Information transfer mode .LP Information transfer rate .LP Information transfer capability .LP Establishment .LP Symmetry .LP Configuration .LP Structure .LP Channel (rate) .LP Control protocol .LP Information transfer protocol .LP Performance .LP Interworking .LP Operations .LP Type of user information .LP High layer protocol .PP \fINote\fR \ \(em\ This list will be completed according to further results on studies of connectionless, multi\(hymedia, broadband and mobile services. .sp 2P .LP 2.3.2 \fIService attributes\fR .sp 1P .RT .sp 1P .LP 2.3.2.1 \fIBearer services\fR .sp 9p .RT .LP 1 Information transfer mode .LP 2 Information transfer rate .FS Service information transfer rate considered at the access point. .FE .LP 3 Information transfer capability .LP 4 Structure .LP 5 Establishment of communication .LP 6 Symmetry .LP 7 Communication configuration .LP 8 Access channel and rate .LP 9\(hy1 Signalling access protocol layer 1 .LP 9\(hy2 Signalling access protocol layer 2 .LP 9\(hy3 Signalling access protocol layer 3 .LP Information access protocol (layer\ 1\(hy3) at the access point. .FE 9\(hy4 Information access protocol layer 1 .LP 9\(hy5 Information access protocol layer 2 .LP 9\(hy6 Information access protocol layer 3 .LP 10 Supplementary services provided .LP 11 Quality of service .LP 12 Interworking possibilities .LP 13 Operational and commercial .LP .sp 1 .bp .sp 1P .LP 2.3.2.2 \fITeleservices\fR .sp 9p .RT .PP 1, 2, 3, 4, 5, 6, 7, 8, 9\(hy1, 9\(hy2, 9\(hy3, 9\(hy4, 9\(hy5, 9\(hy6: refer to \(sc\ 2.3.2.1. .RT .LP 10 Type of user information .LP 11 Layer 4 protocol .LP 12 Layer 5 protocol .LP 13 Layer 6 protocol .LP 14 Layer 7 protocol .LP 15 Supplementary services provided .LP 16 Quality of service .LP 17 Interworking possibilities .LP 18 Operational and commercial .sp 1P .LP 2.3.2.3 \fISupplementary services\fR .sp 9p .RT .PP For further study.\fR .RT .sp 1P .LP 2.3.2.4 \fICharging\fR .sp 9p .RT .PP For further study. .RT .sp 2P .LP 2.3.3 \fINetwork attributes\fR .sp 1P .RT .sp 1P .LP 2.3.3.1 \fIConnection types\fR .sp 9p .RT .LP 1 Information transfer mode .LP 2 Information transfer rate .FS Information transfer rate is considered between access points. .FE .LP 3 Information transfer susceptance .LP 4 Establishment of communication .LP 5 Symmetry .LP 6 Connection configuration .LP 7 Structure .LP 8 Channel (rate) .LP 9 Connection control protocol .LP 10 Information transfer coding/protocol .FS Information transfer protocol is considered between access points. .FE .LP 11 Network performance .LP 12 Network interworking .LP 13 Operations and management .sp 1P .LP 2.3.3.2 \fIConnection elements\fR .sp 9p .RT .LP 1 Information transfer mode .LP 2 Information transfer rate .LP 3 Information transfer susceptance .LP 4 Establishment of communication .LP 5 Symmetry .LP 6 Connection configuration .LP 7 Structure .LP 8 Channel (rate) .LP 9 Connection control protocol .LP 10 Information transfer coding/protocol .LP 11 Network performance .LP 12 Network interworking .LP 13 Operations and management .LP .sp 1 .bp .sp 1P .LP 2.3.3.3 \fIOther network entities\fR .sp 9p .RT .PP The definition of attributes for basic connection components, and network capabilities to support supplementary services needs further study. .RT .sp 1P .LP 2.4 \fIAttribute definition\fR .sp 9p .RT .PP A list of definitions of attributes and attribute values is contained in Annex\ A to this Recommendation. .RT .sp 2P .LP \fB3\fR \fBApplication to the I\(hySeries Recommendations\fR .sp 1P .RT .PP This technique has been applied in I.200\(hySeries Recommendations for the specification of the telecommunications services supported by and ISDN and in Recommendation\ I.340 for the characterization of ISDN connection types and connection elements. .PP The application of the attribute technique for the characterization of multi\(hymedia services is for further study. \v'1P' .RT .ce 1000 ANNEX\ A .ce 0 .ce 1000 (to Recommendation I.140) .sp 9p .RT .ce 0 .ce 1000 \fBList of definitions of \fR \fBattributes\fR .sp 9p .RT .ce 0 .ce 1000 \fBand \fR \fBattribute values\fR .ce 0 .LP A.1 \fIDefinitions of the attributes\fR .sp 1P .RT .sp 2P .LP A.1.1 \fITelecomunication service attribute definitions\fR .sp 1P .RT .sp 1P .LP \fBInformation transfer mode\fR .sp 9p .RT .PP This attribute describes the operational mode for transferring (transporting and switching) user information through the ISDN. .RT .sp 2P .LP \fIPossible values\fR : \(em\ circuit .sp 1P .RT .LP \(em\ packet .sp 1P .LP \fBInformation transfer rate\fR .sp 9p .RT .PP 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. .RT .sp 2P .LP \fIPossible values\fR : \(em\ appropriate bit or throughput rate .sp 1P .RT .sp 1P .LP \fBInformation transfer capability\fR .sp 9p .RT .PP This attribute describes the capability associated with the transfer of different types of information through the ISDN. .RT .sp 2P .LP \fIPossible values\fR : \(em\ unrestricted digital information .sp 1P .RT .LP \(em\ speech .LP \(em\ 3.1 kHz audio .LP \(em\ 7 kHz audio .LP \(em\ 15 kHz audio .LP \(em\ video .LP \(em\ other values .bp .sp 1P .LP \fBStructure\fR .sp 9p .RT .PP 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). .RT .sp 2P .LP \fIPossible values\fR : \(em\ 8 kHz integrity .sp 1P .RT .LP \(em\ service data unit integrity .LP \(em\ time slot sequence integrity .LP \(em\ restricted differential time delay .LP \(em\ unstructured .sp 1P .LP \fBEstablishment of communication\fR .sp 9p .RT .PP This attribute describes the mode of establishment associated to the telecommunication service used to establish and release a given communication. .RT .sp 2P .LP \fIPossible values\fR : \(em\ demand .sp 1P .RT .LP \(em\ reserved .LP \(em\ permanent .sp 1P .LP \fBSymmetry\fR .sp 9p .RT .PP This attribute describes the relationship of information flow between two (or more) access points or reference points involved in a communication. .RT .sp 2P .LP \fIPossible values\fR : \(em\ unidirectional .sp 1P .RT .LP \(em\ bidirectional symmetric .LP \(em\ bidirectional asymmetric .sp 1P .LP \fBCommunication configuration\fR .sp 9p .RT .PP This attribute describes the spatial arrangement for transferring 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. .RT .sp 2P .LP \fIPossible values\fR : \(em\ point\(hyto\(hypoint .sp 1P .RT .LP \(em\ multipoint .LP \(em\ broadcast .sp 1P .LP \fBAccess channel and rate\fR .sp 9p .RT .PP This attribute describes the channels and their bit rate used to transfer the user information and/or signalling information at a given access point. .RT .sp 2P .LP \fIPossible values\fR : \(em\ name of the channel (letter) and the corresponding bit rate .sp 1P .RT .PP \fINote\fR \ \(em\ This attribute can be used several times for communication characterization. .sp 1P .LP \fBSignalling access protocol layer\ 1\(hy3, information access protocol layer\ 1\(hy3\fR .sp 9p .RT .PP These attributes characterize the protocol on the signalling or user information transfer channel at a given access point or reference point. .RT .sp 2P .LP \fIPossible values\fR : \(em\ appropriate protocol .bp .sp 1P .RT .sp 1P .LP \fBType of user information\fR .sp 9p .RT .sp 2P .LP \fIPossible values\fR : \(em\ speech .sp 1P .RT .LP \(em\ sound .LP \(em\ text .LP \(em\ facsimile .LP \(em\ text\(hyfacsimile .LP \(em\ videotex .LP \(em\ video .LP \(em\ text\(hyinteractive .sp 1P .LP \fBLayer 4\ \(em\ 7 protocol\fR .sp 9p .RT .PP These attributes characterize the protocol on the user information transfer channel at a given access point or reference point. .RT .sp 2P .LP \fIPossible values\fR : \(em\ appropriate protocol .sp 1P .RT .sp 1P .LP \fBSupplementary services provided\fR .sp 9p .RT .PP This attribute refers to the supplementary services associated with a given telecommunication service. .RT .sp 1P .LP \fBQuality of service\fR .sp 9p .RT .PP This attribute is described by a group of specific sub\(hyattributes, for example: service reliability, service availability. .PP The values are under study. .RT .sp 1P .LP \fBInterworking possibilities\fR .sp 9p .RT .PP To be defined. .RT .sp 1P .LP \fBOperational and commercial\fR .sp 9p .RT .PP To be defined. .RT .sp 2P .LP A.1.2 \fIConnection type attribute definitions\fR .sp 1P .RT .sp 1P .LP \fBInformation transfer mode\fR .sp 9p .RT .PP This attribute describes the operational mode for transferring (transporting and switching) user information through the ISDN. .RT .sp 2P .LP \fIPossible values\fR : \(em\ circuit .sp 1P .RT .LP \(em\ packet .sp 1P .LP \fBInformation transfer rate\fR .sp 9p .RT .PP 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. .RT .sp 2P .LP \fIPossible values\fR : \(em\ appropriate bit or throughput rate .sp 1P .RT .sp 1P .LP \fBInformation transfer susceptance\fR .sp 9p .RT .PP This attribute describes the capability associated with the transfer of different types of information through the ISDN. .RT .sp 2P .LP \fIPossible values\fR : \(em\ unrestricted digital information .sp 1P .RT .LP \(em\ speech .LP \(em\ 3.1 kHz audio .LP \(em\ 7 kHz audio .LP \(em\ 15 kHz audio .LP \(em\ video .LP \(em\ other values .bp .sp 1P .LP \fBEstablishment of connection\fR .sp 9p .RT .PP This attribute describes the mode of establishment used to establish and release a given connection in an ISDN. .RT .sp 2P .LP \fIPossible values\fR : \(em\ demand .sp 1P .RT .LP \(em\ semi\(hypermanent .LP \(em\ permanent .sp 1P .LP \fBSymmetry\fR .sp 9p .RT .PP This attribute describes the relationship of information flow between two (or more) access points or reference points of a connection. .RT .sp 2P .LP \fIPossible values\fR : \(em\ unidirectional .sp 1P .RT .LP \(em\ bidirectional symmetric .LP \(em\ bidirectional asymmetric .sp 1P .LP \fBConnection configuration\fR .sp 9p .RT .PP This attribute describes the spatial arrangement for transferring information on a given connection. It consists of two sub\(hyattributes, topology and dynamics. .RT .sp 1P .LP \fBStructure\fR .sp 9p .RT .PP 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). .RT .sp 2P .LP \fIPossible values\fR : \(em\ 8 kHz integrity .sp 1P .RT .LP \(em\ service data unit integrity .LP \(em\ time slot sequence integrity .LP \(em\ restricted differential time delay .LP \(em\ unstructured .sp 1P .LP \fBChannel (rate)\fR .sp 9p .RT .PP This attribute describes the channels and their bit rate used to transfer the user information and/or signalling information at a given access point. .RT .sp 2P .LP \fIPossible values\fR : \(em\ name of the channel (letter) and the corresponding bit rate .sp 1P .RT .PP \fINote\fR \ \(em\ This attribute can be used several times. .sp 1P .LP \fBConnection control protocol, information transfer coding/protocol\fR .sp 9p .RT .PP These attributes characterize the protocol/coding on the signalling or user information transfer channel at a given access point or reference point. .RT .sp 2P .LP \fIPossible values\fR : \(em\ appropriate protocol or coding .sp 1P .RT .sp 1P .LP \fBNetwork performance\fR .sp 9p .RT .PP This attribute describes the network performance that relates to an ISDN connection. .bp .PP This performance attribute consists of sub\(hyattributes, for example: .RT .LP \fIError performance\fR : the values are given in the appropriate Recommendations. .LP \fISlip performance\fR : the values are given in the appropriate Recommendations. .PP The definition of further sub\(hyattributes is for further study. .sp 1P .LP \fBNetwork interworking\fR .sp 9p .RT .PP To be defined. .RT .sp 1P .LP \fBOperation and management\fR .sp 9p .RT .PP To be defined. .RT .sp 2P .LP A.1.3 \fIConnection element attribute defintions\fR .sp 1P .RT .sp 1P .LP \fBInformation transfer mode\fR .sp 9p .RT .PP This attribute describes the operational mode for transferring (transporting and switching) user information through the ISDN. .RT .sp 2P .LP \fIPossible values\fR : \(em\ circuit .sp 1P .RT .LP \(em\ packet .sp 1P .LP \fBInformation transfer rate\fR .sp 9p .RT .PP 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. .RT .sp 2P .LP \fIPossible values\fR : \(em\ appropriate bit or throughput rate .sp 1P .RT .sp 1P .LP \fBInformation transfer susceptance\fR .sp 9p .RT .PP This attribute identifies equipment which may restrict the types of information which may pass through the ISDN. .RT .sp 2P .LP \fIPossible values\fR : \(em\ speech processing equipment .sp 1P .RT .LP \(em\ echo suppression equipment .LP \(em\ multi\(hysatellite hope .LP \(em\ null .sp 1P .LP \fBEstablishment of connection\fR .sp 9p .RT .PP This attribute describes the mode of establishment used to establish and release a given connection element in an ISDN. .RT .sp 2P .LP \fIPossible values\fR : \(em\ demand .sp 1P .RT .LP \(em\ semi\(hypermanent .LP \(em\ permanent .sp 1P .LP \fBSymmetry\fR .sp 9p .RT .PP This attribute describes the relationship of information flow between two (or more) access points or reference points of a connection element. .bp .RT .sp 2P .LP \fIPossible values\fR : \(em\ undirectional .sp 1P .RT .LP \(em\ bidirectional symmetric .LP \(em\ bidirectional asymmetric .sp 1P .LP \fBConnection configuration\fR .sp 9p .RT .PP This attribute describes the spatial arrangement for transferring information across a given connection element. It consists of two sub\(hyattributes, topology and uniformity. .RT .sp 1P .LP \fBStructure\fR .sp 9p .RT .PP 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). .RT .sp 2P .LP \fIPossible values\fR : \(em\ 8 kHz integrity .sp 1P .RT .LP \(em\ service data unit integrity .LP \(em\ time slot sequence integrity .LP \(em\ 8 kHz integrity with restricted differential time delay .LP \(em\ unstructured .sp 1P .LP \fBChannel (rate)\fR .sp 9p .RT .PP This attribute describes the channels and their bit rate used to transfer the user information and/or signalling information at a given access point. .RT .sp 2P .LP \fIPossible values\fR : \(em\ name of the channel (letter) and the corresponding bit rate .sp 1P .RT .PP \fINote\fR \ \(em\ This attribute can be used several times. .sp 1P .LP \fBConnection control protocol, information transfer coding/protocol\fR .sp 9p .RT .PP These attributes characterize the protocol/coding on the signalling or user information transfer channel at a given access point or reference point. .RT .sp 2P .LP \fIPossible values\fR : \(em\ appropriate protocol or coding .sp 1P .RT .sp 1P .LP \fBNetwork performance\fR .sp 9p .RT .PP This attribute describes the network performance that relate to an ISDN connection element. .PP This performance attribute consists of sub\(hyattributes, for example: .RT .LP \fIError performance\fR : The values are given in the appropriate Recommendations. .LP \fISlip performance\fR : The values are given in the appropriate Recommendations. .PP The definition of further sub\(hyattributes is for further study. .sp 1P .LP \fBNetwork interworking\fR .sp 9p .RT .PP To be defined. .RT .sp 1P .LP \fBOperation and management\fR .sp 9p .RT .PP To be defined. .bp .RT .sp 2P .LP A.2 \fIDefinition of the attribute values\fR .sp 1P .RT .sp 1P .LP \fBunrestricted digital information\fR .sp 9p .RT .PP Transfer of information sequence of bits at its specified bit rate without alteration. .RT .LP This\ implies:\ \(em\ bit sequence independence .LP This\ implies:\ \(em\ digit sequence integrity .LP This\ implies:\ \(em\ bit integrity. .sp 1P .LP \fBspeech\fR .sp 9p .RT .PP Digital representation of speech coded according to a specified encoding rule (e.g.\ A\(hylaw, \(*m\(hylaw). .RT .sp 1P .LP \fB3.1 kHz audio\fR .sp 9p .RT .PP Digital representation of audio information such as voice\(hyband data and speech with a bandwidth of 3.1\ kHz, the encoding rule being specified (e.g.\ A\(hylaw, \(*m\(hylaw). .RT .sp 1P .LP \fB7 kHz audio\fR .sp 9p .RT .PP Digital representation of audio information with a bandwidth of 7\ kHz, the encoding rule being specified. .RT .sp 1P .LP \fB15 kHz audio\fR .sp 9p .RT .PP Digital representation of audio information with a bandwidth of 15\ kHz, the encoding rule being specified. .RT .sp 1P .LP \fBvideo\fR .sp 9p .RT .PP Digital representation of video image information, the encoding rule being specified. .RT .sp 1P .LP \fB8 kHz integrity\fR .sp 9p .RT .PP This value applies when: .RT .LP i) at each user\(hynetwork interface, intervals of 125 \(*ms are implicitly or explicitly demarcated, and .LP ii) all bits submitted within a single demarcated 125 \(*ms interval are delivered within a corresponding single demarcated 125\ \(*ms interval. .sp 1P .LP \fBservice data unit integrity\fR .sp 9p .RT .PP This value applies when: .RT .LP i) at each user\(hynetwork interface, protocols provide a mechanism for identifying the boundaries of service data units (e.g.\ X.25 complete packet sequence), and .LP ii) all bits submitted within a single service data unit are delivered in a corresponding service data unit. .sp 1P .LP \fBunstructured\fR .sp 9p .RT .PP This value is applicable when the telecommunication service or connection neither provides structural boundaries nor preserves structural integrity. .RT .sp 1P .LP \fBdemand (communication)\fR .sp 9p .RT .PP The communication can be started as soon as possible after the request is made (e.g.\ \fIt\fR\d1\u\ \(em\ \fIt\fR\d0\uis as short as possible). .PP Communication and connection release occurs in response to the request of any of the users (calling or called users), \fIt\fR\d3\u\ \(em\ \fIt\fR\d2\uis as short as possible (see Figure\ A\(hy1/I.140). .bp .RT .LP .rs .sp 18P .ad r \fBFigure A\(hy1/I.140, p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP \fBreserved (communication)\fR .sp 9p .RT .PP The communication can be started at time instant \fIt\fR\d1\uexplicitly specified at the time instant of communication and connection request, \fIt\fR\d0\u. Communication and connection release occurs at time instant \fIt\fR\d3\uexplicitly specified also at \fIt\fR\d0\u. Communication and connection 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 \fIt\fR\d3\ufollowing a release request made at time instant \fIt\fR\d2\uduring the communication and \fIa priori\fR undetermined (\fIt\fR\d3\u\ \(em\ \fIt\fR\d2\uis 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). .RT .sp 1P .LP \fBpermanent (communication)\fR .sp 9p .RT .PP The communication can be started after the connection is set up at time instant \fIt\fR\d1\uin response to a subscription request for the service at time instant \fIt\fR\d0\u. the duration may be unspecified. The communication and connection is released at time instant \fIt\fR\d3\ucorresponding to the end of the subscription. .RT .sp 1P .LP \fBswitched (connection)\fR .sp 9p .RT .PP ISDN circuit switched connections/connection elements are set up at any time on demand via e.g.\ a bit channel in response to signalling information received from subscribers, other exchanges or other networks, i.e.\ on a per\(hycall\(hybasis. Message/packet switched connections/connection elements provided by an ISDN may be set up on demand via circuit\(hymode channels (e.g.\ B\(hychannels) and special packet switching units or via the D\(hychannel subject to any D\(hychannel priority/flow control restrictions that may be applicable. .PP \fINote\fR \ \(em\ A more general definition of this value is also given in Recommendation\ I.112 (No.311). .RT .sp 1P .LP \fBsemi\(hypermanent (connection)\fR .sp 9p .RT .PP Semi\(hypermanent connections/connection elements pass through a switching network. .PP Semi\(hypermanent 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. .bp .RT .sp 1P .LP \fBpermanent (connection)\fR .sp 9p .RT .PP Permanent connections/connection elements are described by the following characteristics: .PP 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 subscribers. .RT .sp 1P .LP \fBunidirectional\fR .sp 9p .RT .PP This value applies when the information flow of messages is provided only in one direction. .RT .sp 1P .LP \fBbidirectional symmetric\fR .sp 9p .RT .PP 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. .RT .sp 1P .LP \fBbidirectional asymmetric\fR .sp 9p .RT .PP This value applies when the information flow characteristics provided by the service are different in the two directions. .RT .sp 1P .LP \fBpoint\(hyto\(hypoint communication\fR .sp 9p .RT .PP This value applies when there are only two access points. .RT .sp 1P .LP \fBmultipoint communication\fR .sp 9p .RT .PP 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. .PP \fINote\fR \ \(em\ The number of access points can be undefined. .RT .sp 1P .LP \fBbroadcast communication\fR .sp 9p .RT .PP 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. .PP \fINote\fR \ \(em\ The number of destination access points is undefined. .RT .sp 1P .LP \fBpoint\(hyto\(hypoint connection\fR .sp 9p .RT .PP This value applies when only two end points are provided by the connection. .RT .sp 1P .LP \fBmultipoint connection\fR .sp 9p .RT .PP This value applies when more than two end points are provided by the connection, and thus many different information flows are possible. .RT .sp 1P .LP \fBbroadcast connection\fR .sp 9p .RT .PP To be defined. .RT .sp 1P .LP \fBsimple connection\fR .sp 9p .RT .PP A connection consisting of only one connection element. .RT .sp 1P .LP \fBtandem connection\fR .sp 9p .RT .PP Two or more connection elements in series form a connection. .bp .RT .sp 1P .LP \fBparallel connection\fR .sp 9p .RT .PP Two or more connection elements in parallel form a connection. .RT .sp 1P .LP \fBstar\fR .sp 9p .RT .PP To be defined. .RT .sp 1P .LP \fBmesh\fR .sp 9p .RT .PP To be defined. .RT .sp 1P .LP \fBuniform\fR .sp 9p .RT .PP This value applies when all connection elements have the same attribute values. .RT .sp 1P .LP \fBnon uniform\fR .sp 9p .RT .PP This value applies in all other cases. .RT .sp 1P .LP \fBconcurrent\fR .sp 9p .RT .PP The configuration of a connection is described as concurrent when all of the connection elements involved are established simultaneously and released simultaneously. .RT .sp 1P .LP \fBsequential\fR .sp 9p .RT .PP A connection has a sequential configuration when its connection elements are established and released sequentially i.e.\ only one of several connection elements or chains of connection elements exists at any given time. .RT .sp 1P .LP \fBadd/remove\fR .sp 9p .RT .PP 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. .RT .sp 1P .LP \fBSymmetry and/or topology change\fR .sp 9p .RT .PP When the symmetry attribute value of the connection element can be changed during a call. .RT .sp 1P .LP \fBTime slot sequence integrity\fR .sp 9p .RT .PP This value applies when .RT .LP i) at each user\(hynetwork interface, time slots are implicitly or explicitly demarcated for each access channel of an aggregate of access channels, and .LP ii) the information parts delivered from the time slots at the receiving end are in the same order as submitted at the transmitting end. .PP \fINote\fR \ \(em\ Preserving the order of bits within an individual time slot from the transmitting to the receiving end is not part of this definition. .sp 1P .LP \fB8 kHz integrity with restricted differential time delay\ (RDTD)\fR .sp 9p .RT .PP This value applies when the following conditions are met: .RT .LP \(em 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 .LP \(em 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 (provisional). .bp .sp 2P .LP \fBRecommendation\ I.141\fR .RT .sp 2P .sp 1P .ce 1000 \fBISDN NETWORK CHARGING CAPABILITIES ATTRIBUTES\fR .EF '% Fascicle\ III.7\ \(em\ Rec.\ I.141'' .OF '''Fascicle\ III.7\ \(em\ Rec.\ I.141 %' .ce 0 .sp 1P .ce 1000 \fI(Melbourne, 1988)\fR .sp 9p .RT .ce 0 .sp 1P .LP \fB1\fR \fBPreamble\fR .sp 1P .RT .PP On the basis of charging principles provided in the D.200\(hySeries, this Recommendation covers the method for identifying the network charging capabilities and provides a candidate list of attributes in Annex\ A. .RT .sp 2P .LP \fB2\fR \fBGeneral\fR .sp 1P .RT .PP ISDNs shall support a range of services as defined in the I.200\(hySeries of Recommendations. Charging capabilities and mechanisms need to be associated with each service. .PP 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 identification of network requirements. The attribute technique is considered 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.) .RT .LP .rs .sp 7P .ad r \fBFigure 1/I.141, p. \fR .sp 1P .RT .ad b .RT .sp 2P .LP \fB3\fR \fBISDN services characteristics\fR .sp 1P .RT .PP Specifically, the services to which network charging capabilities attributes should be applied are as given in Table\ 1/I.141. .RT .LP .sp 2 .ce \fBH.T. [T1.141]\fR .ce TABLE\ 1/I.141 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(90p) | cw(78p) . Service Recommendations _ .T& lw(90p) | cw(78p) . Bearer services I.230\(hySeries .T& lw(90p) | cw(78p) . Teleservices I.240\(hySeries .T& lw(90p) | cw(78p) . Supplementary services I.250\(hySeries _ .TE .nr PS 9 .RT .ad r \fBTable 1/I.141 [T1.141], p. \fR .sp 1P .RT .ad b .RT .LP .bp .sp 2P .LP \fB4\fR \fBRole and application of the attribute technique\fR .sp 1P .RT .PP For each service defined in the I.200\(hySeries 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. .PP 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. .PP 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. .PP Annex\ A lists the candidate network charging capability attributes and the possible values so far identified. \v'1P' .RT .ce 1000 ANNEX\ A .ce 0 .ce 1000 (to Recommendation I.141) .sp 9p .RT .ce 0 .ce 1000 \fBCandidate network charging capability attributes\fR .sp 1P .RT .ce 0 .LP .sp 1 .ce \fBH.T. [T2.141]\fR .ce TABLE\ A\(hy1/I.141 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(78p) | cw(90p) . Attribute Possible values _ .T& lw(168p) . Charging capabilities _ .T& lw(78p) | lw(90p) . Usage | ua\d\u)\d { Service requested Call attempt | ub\d\u)\d Call set\(hyup Duration Volume Basis of provision } _ .T& lw(78p) | lw(90p) . Modulation Distance Time of usage _ .T& lw(168p) . Billing capabilities _ .T& lw(78p) | lw(90p) . Billing identification { Calling party (sent paid) Called party (reverse/collect) Transferred (third party) } _ .T& lw(78p) | lw(90p) . Collection { Subscriber billing Credit card Coin box Debit card } _ .T& lw(78p) | lw(90p) . Mode { On line Off line } .TE .LP \ua\d\u)\d The identification and definition of values for supplementary services (e.g. registration, activation) is for further study. .LP \ub\d\u)\d For further study. .nr PS 9 .RT .ad r \fBTableau A\(hy1/I.141 [T2.141], p. 13\fR .sp 1P .RT .ad b .RT .LP .bp .LP \fBMONTAGE : PAGE 100 = PAGE BLANCHE\fR .sp 1P .RT .LP .bp