|
DataMuseum.dkPresents historical artifacts from the history of: RegneCentralen RC850 |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about RegneCentralen RC850 Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - download
Length: 86400 (0x15180)
Types: RcTekst
Names: »VIL.WPB«
└─⟦51ec6abc5⟧ Bits:30005985 Manualer - TELETEX Document Handler
└─⟦this⟧ »VIL.WPB«
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
════════════════════════════════════════════════════════════════════════
↓
«index» formatlinie til RC manualer↲
┆14┆┆b3┆↲
┆14┆┆b3┆┆06┆- ┆0b┆ -↲
┆a1┆┆b0┆1.╞ INTRODUCTION↲
↲
╞ ┆84┆This manual specifies the TTXDH module (in the following called ↓
┆19┆┆89┆┄┄DH), which stands for TELETEX Document Handler.↲
↲
╞ ┆84┆The function of the DH can shortly be described as administration ↓
┆19┆┆89┆┄┄of transmission and receival of documents in accordance with the ↓
┆19┆┆89┆┄┄S.62 protocol requirements (see ref.1.).↲
↲
╞ ┆84┆This involves error recovery and mapping of documents on sessions ↓
┆19┆┆89┆┄┄when documents are transmitted, and linkage of documents at re┄↓
┆19┆┆89┆┄┄ceival. The DH also performs the communication with the DS (docu┄↓
┆19┆┆89┆┄┄ment store) in accordance with the specifications in ref. 3., with ↓
┆19┆┆89┆┄┄the exception of IMC connection administration.↲
↲
╞ ┆84┆The DH is a part of the Teletex Control Unit (CU), which is spe┄↓
┆19┆┆89┆┄┄cified in ref. 2. As described there the DH communicates with the ↓
┆19┆┆89┆┄┄following modules:↲
↲
╞ TTXSI╞ ┆84┆The Teletex Service Interface.↲
╞ ╞ ┆84┆Is the link between IMC and DH. The primitives ↓
┆19┆┆93┆┄┄described in ref. 3 are transferred to or from the DH, ↓
┆19┆┆93┆┄┄which performs all services not particulary IMC ↓
┆19┆┆93┆┄┄oriented.↲
↲
╞ S62CP╞ ┆84┆The S.62 Protocol Handler.↲
╞ ╞ ┆84┆Performs the session service as described in ref. 4. ↓
┆19┆┆93┆┄┄S62CP makes sure that the S.62 protocol is followed.↲
↲
╞ NCP╞ ┆84┆The Net Control Probe.↲
╞ ╞ ┆84┆Performs the LCP interface described in ref. 5, and acts ↓
┆19┆┆93┆┄┄as a link between the LCP part of the DH and the Net ↓
┆19┆┆93┆┄┄Con┄trol Center.↲
╞ ╞ ┆84┆Events are generated when an important change of state ↓
┆19┆┆93┆┄┄occurs in the DH, and information of the current state ↓
┆19┆┆93┆┄┄of packets and sessions can be obtained by means of ↓
┆19┆┆93┆┄┄sense operations.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆The term "specifies" is so general that this manual in fact serves ↓
┆19┆┆89┆┄┄several purposes. Therefore a short description of the content of ↓
┆19┆┆89┆┄┄the chapters is given here:↲
↲
╞ ┆a1┆┆84┆Chapter 2┆e1┆ gives an informal specification of the function of the ↓
┆19┆┆89┆┄┄DH.↲
↲
╞ ┆a1┆┆84┆Chapter 3┆e1┆ defines the interface to the TTXSI and has primarily ↓
┆19┆┆89┆┄┄interest for the TTXSI programmer.↲
↲
╞ ┆84┆┆a1┆Chapter 4┆e1┆ describes the communication with S62CP, with the main ↓
┆19┆┆89┆┄┄purpose to define how various parameters to the primitives are ↓
┆19┆┆89┆┄┄used.↲
↲
╞ ┆a1┆┆84┆Chapter 5┆e1┆ describes the content and the meaning of the Net Control ↓
┆19┆┆89┆┄┄transactions.↲
↲
╞ ┆a1┆┆84┆Chapter 6┆e1┆ is the detailed specifications of the DH (together with ↓
┆19┆┆89┆┄┄chapter 4). It views the DH as a protocol machine.↲
↲
╞ ┆a1┆┆84┆Chapter 7┆e1┆ describes the status information delivered in IND.UPDATE ↓
┆19┆┆89┆┄┄primitive from the DH to the DS. It is of interest when status of ↓
┆19┆┆89┆┄┄a packet should be presented to a teletex user.↲
↲
╞ ┆84┆The various terms used will normally have been defined in the re┄↓
┆19┆┆89┆┄┄ferences (see appendix A) or in the chapters where they are used. ↲
╞ ↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆2.╞ DH SERVICE DESCRIPTION↲
↲
╞ ┆84┆The purpose of this chapter is to give an informal description of ↓
┆19┆┆89┆┄┄the service of the DH. The reader should be familiar with ref.3 ↓
┆19┆┆89┆┄┄and ref.4 and the terms defined there.↲
↲
╞ ┆84┆As already mentioned the direct communication partners for DH are ↓
┆19┆┆89┆┄┄the TTXSI and the S62CP (and the NCP, the communication to which ↓
┆19┆┆89┆┄┄no further description is given in this chapter). The communica┄↓
┆19┆┆89┆┄┄tion with S62CP is described in ref.4. Regarding the communication ↓
┆19┆┆89┆┄┄with the TTXSI the following can be said:↲
↲
╞ ┆84┆In ref.3 the interface the CU offers to the DS, (or, in principle, ↓
┆19┆┆89┆┄┄the various DS's) is described. The role of the TTXSI is solely to ↓
┆19┆┆89┆┄┄hide the administration of IMC connections for DH. Therefore ref.3 ↓
┆19┆┆89┆┄┄can be regarded as an interface description of the DH too. The ↓
┆19┆┆89┆┄┄blocks defined there are also exchanged between the TTXSI and the ↓
┆19┆┆89┆┄┄DH, with the exception of those solely for administration of IMC ↓
┆19┆┆89┆┄┄connections (f.ex. LOGON BLOCKS).↲
↲
╞ ┆84┆Because of the ignorance by the DH concerning the existence of IMC ↓
┆19┆┆89┆┄┄connections, it views the world like this:↲
↲
↲
┆0e┆↓
╞ ╞ TU1↲
↲
╞ ╞ TU2↲
↲
╞ ╞ -↲
╞ TTXSI╞ -╞ ╞ ╞ DH↲
╞ ╞ -↲
↲
╞ ╞ TUn↲
↲
┆0f┆↓
↲
╞ While the real situation is:↲
↲
┆8c┆┆83┆┆bc┆↓
┆0e┆↓
╞ ╞ ╞ ╞ ╞ ╞ CU↲
↲
╞ DS╞ ╞ request connection╞ ╞ ↲
╞ for↲
╞ TU1 - - - TUi╞ indication connection↲
↲
↲
╞ -╞ ╞ ╞ -↲
╞ -╞ ╞ ╞ -╞ ╞ TTXSI╞ DH↲
╞ -╞ ╞ ╞ -↲
↲
↲
╞ DS for╞ ╞ request connection↲
╞ TUj - - - TUn↲
╞ ╞ ╞ indication connection↲
↲
┆0f┆↓
↲
╞ ┆84┆The establishment of indication and request connections are com┄↓
┆19┆┆89┆┄┄pletely unknown to the DH. A break down of these connections will ↓
┆19┆┆89┆┄┄by be seen by DH as a REQ.SUSPEND block (see section 2.1) for ↓
┆19┆┆89┆┄┄every TU belonging to them.↲
↲
╞ ┆84┆The various blocks are transferred between the DH and the TTXSI by ↓
┆19┆┆89┆┄┄means of the procedure signal. The CU TU number (which is unam┄↓
┆19┆┆89┆┄┄biguous for the CU) is used as TU identification.↲
↲
╞ ┆84┆However, the above mentioned only holds for control commands, ↓
┆19┆┆89┆┄┄which are those exchanged on the request or indication ↓
┆19┆┆89┆┄┄connections. The document associations are to the DH known as ↓
┆19┆┆89┆┄┄┆a1┆document streams.┆e1┆ They are opened when the DH sends a TRANSFER ↓
┆19┆┆89┆┄┄block to TTXSI. It will contain the CU TU number (to make the ↓
┆19┆┆89┆┄┄TTXSI able to establish the document association to the right IMC ↓
┆19┆┆89┆┄┄port) and an index, which further on identifies the stream.↲
↲
╞ ┆84┆There are defined primitives so that both the TTXSI and the DH can ↓
┆19┆┆89┆┄┄request a document stream closed. This possibility will be used by ↓
┆19┆┆89┆┄┄TTXSI when the document association breaks down for some reason.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆Finally it should be noted that for reasons of convenience the ↓
┆19┆┆89┆┄┄term "DS" in the following is used for the communication partner ↓
┆19┆┆89┆┄┄of the DH, even if the correct phrase would be "the DS to which ↓
┆19┆┆89┆┄┄the current TU belongs".↲
↲
↲
┆a1┆┆b0┆2.1 ╞ TU handling↲
↲
╞ ┆84┆The most of the work concerning TU handling is done by S62CP (or ↓
┆19┆┆89┆┄┄lower level modules). The role of the DH is for some of the ↓
┆19┆┆89┆┄┄primitives to perform session clean up before forwarding it to ↓
┆19┆┆89┆┄┄S62CP.↲
↲
╞ ┆84┆A TU is made known to the DH by a REQ.ACTIVATE command from DS. ↓
┆19┆┆89┆┄┄This is immediately transferred into an ACTIVATE_TI primitive to ↓
┆19┆┆89┆┄┄S62CP. When it is answered, and the result is ok, a CONF.ACTIVATE ↓
┆19┆┆89┆┄┄is sent to DS, also with the result ok.↲
↲
╞ ┆84┆A TU can be removed by a REQ.REMOVE. The DH will actively remove ↓
┆19┆┆89┆┄┄all alive sessions on this TU by means of SESSION ABORT REQ, and ↓
┆19┆┆89┆┄┄all packets are removed at once. When the session clean up ↓
┆19┆┆89┆┄┄procedure is ended for all these sessions, a DEACTIVATE TI is sent ↓
┆19┆┆89┆┄┄to S62CP and a CONF.REMOVE to DS.↲
↲
╞ ┆84┆If the associations to the DS break down, the TTXSI will send a ↓
┆19┆┆89┆┄┄REQ.SUSPEND for all TU's concerned. This command is not used by ↓
┆19┆┆89┆┄┄the DS itself. The handling is as for REQ.REMOVE, and ends in a ↓
┆19┆┆89┆┄┄SUSPEND TI being sent to S62CP. All incoming calls to this TU will ↓
┆19┆┆89┆┄┄from now on be answered with "terminal out of order" by TS.↲
↲
╞ ┆84┆When the communication with the DS is reestablished, and the TTXSI ↓
┆19┆┆89┆┄┄receives a REQ.ACTIVATE for a previously activated TU, a ↓
┆19┆┆89┆┄┄REQ.RESUME command is sent to DH for this TU. A RESUME TI is sent ↓
┆19┆┆89┆┄┄to S62CP.↲
↲
╞ ┆84┆The DS can redefine the TU attributes by means of a REQ.REDEFINE. ↓
┆19┆┆89┆┄┄In this case will packets and sessions live on, and the DH awaits ↓
┆19┆┆89┆┄┄the moment where no session exists on the TU before sending a ↓
┆19┆┆89┆┄┄REDEFINE TI to S62CP. When the answer on this is received, a ↓
┆8c┆┆83┆┆d4┆↓
┆19┆┆89┆┄┄CONF.REDEFINE is sent to DS. Note that a redefine transaction can ↓
┆19┆┆89┆┄┄be alive for a long time.↲
↲
╞ ┆84┆Finally the DS can request a TU to be disabled by means of a ↓
┆19┆┆89┆┄┄REQ.DISABLE, which contains a text message. The DH will await the ↓
┆19┆┆89┆┄┄moment where no documents can be received any more. This is the ↓
┆19┆┆89┆┄┄case when the following conditions are fulfilled:↲
┆19┆┆89┆┄┄↲
╞ a) ┆84┆All sessions activated from the remote party haave been ↓
┆19┆┆8d┆┄┄removed.↲
╞ b) ┆84┆All sessions activated on this side, which is in sink state, ↓
┆19┆┆8d┆┄┄have either been set back to source state by a CHANGE CONTROL ↓
┆19┆┆8d┆┄┄IND or have been removed.↲
↲
╞ ┆84┆When this hap┄pens, a CONF.DISABLE is sent to DS. From this moment ↓
┆19┆┆89┆┄┄on all in┄coming SESSION START IND primitives are answered by a ↓
┆19┆┆89┆┄┄SESSION START RESP NEG, containing the text message. Packet ↓
┆19┆┆89┆┄┄submission can, however, still take place.↲
↲
╞ ┆84┆This state is terminated by DS issuing a REQ.ENABLE, which is ↓
┆19┆┆89┆┄┄answered immediately by a CONF.ENABLE. Packet receival can take ↓
┆19┆┆89┆┄┄place again.↲
↲
╞ ┆84┆It should be noted that both a redefine and a disable transaction ↓
┆19┆┆89┆┄┄is terminated at once if a REQ.REMOVE or a REQ.SUSPEND is re┄↓
┆19┆┆89┆┄┄ceived.↲
↲
↲
┆a1┆┆b0┆2.2 ╞ Normal Packet Transmission.↲
↲
╞ ┆84┆Normal packet transmission is started when a REQUEST.SUBMIT is ↓
┆19┆┆89┆┄┄received from DS with service=TTX or FTX. Because these services ↓
┆19┆┆89┆┄┄are alike to the DH, the term TTX will in the rest of this manual ↓
┆19┆┆89┆┄┄denote "TTX or FTX".↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆84┆┆a1┆┆b0┆2.2.1 ╞ Session Allocation.↲
↲
╞ ┆84┆To transmit the document in the packet a session is necessary.↲
↲
╞ ┆84┆Such a session is not in all cases available at once. The reason ↓
┆19┆┆89┆┄┄for this is that the number of sessions allowed to be open at the ↓
┆19┆┆89┆┄┄same time is limited. If an x21 network is used, only one session ↓
┆19┆┆89┆┄┄is avaible. But also by an x25 network the number of sessions will ↓
┆19┆┆89┆┄┄possibly be significantly lesser than the number of possible ↓
┆19┆┆89┆┄┄packets, because a session demands resources in all levels in the ↓
┆19┆┆89┆┄┄CU.↲
↲
╞ ┆84┆Therefore queue, the socalled ┆a1┆busy queue┆e1┆, is introduced. Packets ↓
┆19┆┆89┆┄┄which cannot immediately get a session will enter this queue. The ↓
┆19┆┆89┆┄┄situation concerning SUBMIT packets can be viewed like this:↲
↲
↲
┆0e┆↓
↲
╞ ╞ ╞ ╞ ╞ ╞ busy queue↲
╞ ╞ packet A╞ ╞ packet B↲
↲
↲
╞ ╞ ╞ packet C╞ ╞ session↲
↲
┆0f┆↓
↲
╞ ┆84┆How packets are ordered in the busy queue is described in section ↓
┆19┆┆89┆┄┄2.2.4.↲
↲
╞ ┆84┆When a session resource becomes avaible, i.e. an answer on a ↓
┆19┆┆89┆┄┄STREAM CLEARING RESP is received from S62CP, the first packet in ↓
┆19┆┆89┆┄┄the busy queue is removed from it, and a session can be estab┄↓
┆19┆┆89┆┄┄lished to transmit the packet. This is done by issuing a SESSION ↓
┆19┆┆89┆┄┄START REQ to S62CP. When the corresponding SESSION START CONF POS ↓
┆19┆┆89┆┄┄is received the session can be used to transmit documents.↲
↲
╞ ┆84┆The parameters to SESSION START REQ is the corresponding ↓
┆19┆┆89┆┄┄parameters from REQ.SUBMIT. Note especially the addressee TI ↓
┆19┆┆89┆┄┄parameter, identifying the receiver.↲
↲
┆8c┆┆83┆┆d4┆↓
┆0e┆↓
↲
╞ fig. 1. Session allocation.↲
↲
↲
╞ DS╞ ╞ ╞ DH╞ ╞ ╞ S62CP↲
↲
╞ REQ.SUBMIT↲
↲
╞ ╞ ╞ packet in↲
╞ ╞ ╞ busy queue↲
↲
╞ ╞ ╞ ╞ ╞ answer on a↲
╞ ╞ ╞ ╞ ╞ STREAM CLEARING RESP↲
↲
╞ ╞ ╞ packet exits↲
╞ ╞ ╞ busy queue↲
↲
╞ ╞ ╞ ╞ SESSION START REQ↲
↲
╞ ╞ ╞ ╞ SESSION START CONF POS↲
↲
┆0f┆↓
↲
┆a1┆┆b0┆2.2.2 ╞ Document Transmission Preparation.↲
↲
╞ ┆84┆Before the transmission starts, the document description is read ↓
┆19┆┆89┆┄┄from DS by means of an IND.READ command. This description ↓
┆19┆┆89┆┄┄contains, among others, the following information:↲
↲
╞ checkpoint↲
╞ number: ┆84┆=0 if this document has not been attempted trans┄↓
┆19┆┆99┆┄┄mitted before, or if no pages were acknowledged. ↓
┆19┆┆99┆┄┄(The two situations are treated alike by DH).↲
↲
╞ document↲
╞ number: ┆84┆A reference to the actual document file at DS. ↓
┆19┆┆99┆┄┄Used when a TRANSFER block is sent.↲
↲
┆0e┆↓
╞ S62 document↲
╞ identification: ┆84┆Only interesting if checkpoint number<>0.↲
┆0f┆↓
↲
┆8c┆┆83┆┆e0┆↓
╞ ┆84┆It should be noted that checkpoint number<>0 at packet ↓
┆19┆┆89┆┄┄initialisation means that the connection between DH and DS has ↓
┆19┆┆89┆┄┄broken down earlier while the packet was being transmitted.↲
↲
╞ ┆84┆The DH will then open the document stream. Note that this stream ↓
┆19┆┆89┆┄┄only will be open while the packet is in possession of a session.↲
↲
╞ The most important parameters to TRANSFER are:↲
↲
╞ mode: ┆84┆=R (read)↲
╞ document: ┆84┆The document number field from the document ↓
┆19┆┆95┆┄┄description. It identifies the document file to be ↓
┆19┆┆95┆┄┄read.↲
╞ checkpoint: ┆84┆The corresponding field from the document description. ↓
┆19┆┆95┆┄┄Identifies the position where the reading begins.↲
↲
╞ ┆84┆When a REPLY OK block is received on the document stream, the ↓
┆19┆┆89┆┄┄capabilities contained in the document header should be requested ↓
┆19┆┆89┆┄┄at the remote party. This is done by sending a CAPABILITIES REQ ↓
┆19┆┆89┆┄┄primitive to S62CP, on which a CAPABILITIES CONF POS is expected ↓
┆19┆┆89┆┄┄as response. A CAPABILITIES CONF NEG instead will provoke ↓
┆19┆┆89┆┄┄immediate packet termination.↲
↲
┆8c┆┆82┆┆94┆↓
┆0e┆↓
↲
╞ fig. 2. Document transmission preparation.↲
↲
↲
╞ DS╞ ╞ ╞ DH╞ ╞ ╞ S62CP↲
↲
╞ IND.READ↲
↲
╞ RESP.READ↲
↲
╞ TRANSFER↲
↲
╞ REPLY OK↲
╞ ╞ ╞ ╞ CAPABILITIES REQ↲
↲
╞ ╞ ╞ ╞ CAPABILITIES CONF POS↓
↲
┆0f┆↓
↲
↲
┆a1┆┆b0┆2.2.3 ╞ Document Transmission.↲
↲
╞ ┆84┆When the preparation is ended, one of the following two situations ↓
┆19┆┆89┆┄┄arises:↲
↲
╞ 1) checkpoint number=0↲
╞ ┆84┆This is transmission of a document from the beginning, and a ↓
┆19┆┆8c┆┄┄DOCUMENT START REQ is used to start the transmission.↲
╞ ┆84┆The S.62 document identification in the document description ↓
┆19┆┆8c┆┄┄should be defined for use in future error recovery. The ↓
┆19┆┆8c┆┄┄constituents "calling TI", "called TI" and "additional session ↓
┆19┆┆8c┆┄┄reference number" are taken from the SESSION START CONF POS ↓
┆19┆┆8c┆┄┄primitive.↲
╞ ┆84┆The document reference number, however, is defined from S62CP ↓
┆19┆┆8c┆┄┄in a DOCUMENT START CONF. When this is received by DH, the do┄↓
┆19┆┆8c┆┄┄cument description is fully defined.↲
↲
╞ 2) checkpoint number<>0↲
╞ ┆84┆This is an earlier interrupted document, of which the identi┄↓
┆19┆┆8c┆┄┄fication already is defined. The transmission is started by ↓
┆19┆┆8c┆┄┄sending a DOC CONT REQ containing this identification.↲
↲
┆8c┆┆83┆┆ec┆↓
╞ ┆84┆After this is done, the transmission proceeds by sending STREAM ↓
┆19┆┆89┆┄┄blocks to S62CP as DATA REQ primitives, and CHECKPOINT blocks as ↓
┆19┆┆89┆┄┄PAGE END REQ primitives.↲
↲
╞ ┆84┆When a PAGE END CONF is received, it means that the opposite party ↓
┆19┆┆89┆┄┄has stored the corresponding page on permanent storage. The check┄↓
┆19┆┆89┆┄┄point number in the document description is increased by one, and ↓
┆19┆┆89┆┄┄the updated description is written back at DS by an IND.WRITE.↲
↲
╞ ┆84┆At receival of the corresponding RESP.WRITE, a PAGE END CONF ↓
┆19┆┆89┆┄┄RESP can be sent to S62CP. The sending of this primitive is delayed ↓
┆19┆┆89┆┄┄until this moment because the PAGE END CONF has not been fully ↓
┆19┆┆89┆┄┄taken into account before it is sure that the checkpoint number is ↓
┆19┆┆89┆┄┄updated at DS.↲
↲
╞ ┆84┆The importance of this is seen when the communication between the ↓
┆19┆┆89┆┄┄DS and the DH breaks down, and the packet later is being re┄trans┄↓
┆19┆┆89┆┄┄mitted by DS with a REQ.SUBMIT when the communication is reestab┄↓
┆19┆┆89┆┄┄lished. The DH will in this case read the document descrip┄tion ↓
┆19┆┆89┆┄┄from DS before error recovery is made (the original packet is ↓
┆19┆┆89┆┄┄forgotten by DH).↲
↲
╞ ┆84┆When, at last, a STREAM END is received on the document stream, a ↓
┆19┆┆89┆┄┄DOC END REQ is sent to S62CP. This will, when the document is ↓
┆19┆┆89┆┄┄fully stored at the receiver, be answered by a DOC END CONF.↲
↲
╞ ┆84┆The checkpoint number in the document description is increased ↓
┆19┆┆89┆┄┄by one, and the updated document description is written back at ↓
┆19┆┆89┆┄┄DS.↲
↲
╞ ┆84┆Finally the document stream will be closed, and document trans┄↓
┆19┆┆89┆┄┄mission will be complete. This involves termination of the session ↓
┆19┆┆89┆┄┄(if it cannot be used by another packet, see section 2.2.9), and ↓
┆19┆┆89┆┄┄sending of a CONF.SUBMIT.↲
↲
┆8c┆┆83┆┆a4┆↓
┆0e┆↓
↲
╞ fig. 3. Document transmission.↲
↲
↲
╞ DS╞ ╞ ╞ DH╞ ╞ ╞ S62CP↲
↲
↲
╞ ╞ ╞ ╞ DOCUMENT START REQ↲
↲
╞ ╞ ╞ ╞ DOCUMENT START CONF POS↲
╞ ↲
╞ ↲
╞ STREAM *1)↲
╞ ╞ ╞ ╞ DATA REQ↲
↲
╞ CHECKPOINT↲
╞ ╞ ╞ ╞ PAGE END REQ↲
╞ STREAM↲
╞ ╞ ╞ ╞ DATA REQ↲
↲
╞ IND.WRITE╞ PAGE END CONF↲
╞ checkpoint=1↲
↲
↲
╞ *1) ┆84┆This can, of course, also have been received earlier, but it ↓
┆19┆┆8d┆┄┄will then have been queued at DH until this moment.↲
┆0f┆↓
┆8c┆┆82┆┆b8┆↓
┆0e┆↓
↲
╞ fig.3. continued.↲
↲
╞ DS╞ ╞ ╞ DH╞ ╞ ╞ S62CP↲
↲
╞ RESP.WRITE↲
╞ ╞ ╞ ╞ PAGE END CONF RESP↲
↲
╞ STREAM╞ ╞ ╞ ↲
╞ ╞ ╞ ╞ DATA REQ↲
↲
╞ STREAM END↲
╞ ╞ ╞ ╞ DOC END REQ↲
↲
╞ IND.WRITE╞ ╞ DOC END CONF↲
╞ checkpoint=2,finished=true ↲
↲
╞ RESP.WRITE↲
↲
╞ close of document stream↲
↲
╞ document stream closed↲
╞ ╞ ╞ ╞ SESS END REQ↲
↲
╞ CONF.SUBMIT, result=ok↲
┆0f┆↓
↲
↲
┆a1┆┆b0┆2.2.4 ╞ Packet Priority.↲
↲
╞ The following amounts are interesting in this aspect:↲
↲
╞ 1) priority: 0 for normal packets↲
╞ ╞ 1 for expedited packets↲
╞ It is a parameter from REQ.SUBMIT↲
↲
╞ 2) class╞ : 0 or 1↲
╞ ┆84┆It is decided from the " remaining pages" , which initially is ↓
┆19┆┆8c┆┄┄equal to the "number of pages" field in the document descrip┄↓
┆19┆┆8c┆┄┄tion. If number of pages<=class 0 pages, where "class 0 pages" ↓
┆8c┆┆83┆┆d4┆↓
┆19┆┆8c┆┄┄are a configuration parameter, the class will be 0. Otherwise ↓
┆19┆┆8c┆┄┄it will be 1.↲
↲
╞ ┆84┆Remaining pages is decreased by one every time a PAGE END CONF ↓
┆19┆┆8c┆┄┄is received. Consequentely can a packet change class while ↓
┆19┆┆8c┆┄┄being transmitted.↲
↲
╞ ┆84┆Between two submit packets, A and B, a relation, "A precede B", ↓
┆19┆┆89┆┄┄is defined, the relation is true when the following holds:↲
╞ ┆84┆(priority A>priority B) or (priority A= priority B and class A< ↓
┆19┆┆89┆┄┄class B).↲
↲
╞ ┆84┆The precedes relation is used to order the packets in the busy ↓
┆19┆┆89┆┄┄queue, in such a way that when A precede B holds, A will be re┄↓
┆19┆┆89┆┄┄moved from the busy queue before B. If priority A=priority B and ↓
┆19┆┆89┆┄┄class A=class B, it is undefined which exits the busy queue first.↲
↲
↲
┆a1┆┆b0┆2.2.5 ╞ Document Transmission Interruption.↲
↲
╞ ┆84┆The DH can interrupt a document transmission by sending a DOCUMENT ↓
┆19┆┆89┆┄┄RESYNCHRONIZE REQ to S62CP, on which a DOCUMENT RESYNCH/DISCARD ↓
┆19┆┆89┆┄┄CONF is expected as response. This makes it possible to leave the ↓
┆19┆┆89┆┄┄document level in an well ordered manner (in opposition to sending ↓
┆19┆┆89┆┄┄a SESSION ABORT REQ).↲
↲
╞ ┆84┆This possibility is used in the following cases:↲
↲
╞ 1) ┆84┆EXCEPTION IND received from S62CP.↲
↲
╞ 2) Document stream break down.↲
╞ ┆84┆This is a premature close of a document stream. After the ↓
┆19┆┆8c┆┄┄DOCUMENT RESYNCH/DISCARD CONF has been received the packet will ↓
┆19┆┆8c┆┄┄be terminated by a CONF.SUBMIT with result=pers_err.↲
↲
╞ 3) ┆84┆A REQ.ABORT is being executed while document transmission is in ↓
┆19┆┆8c┆┄┄progress.↲
↲
╞ 4) Interruption by another packet.↲
↲
┆8c┆┆83┆┆e0┆↓
╞ The rest of this section deals with case 4).↲
↲
╞ ┆84┆A relation, "A interrupts B" is defined between two submit ↓
┆19┆┆89┆┄┄packets. It is true when the following holds:↲
╞ ┆84┆"(A precedes B) and class B>0".↲
↲
╞ ┆84┆If document transmission is in progress for packet B, and A ar┄↓
┆19┆┆89┆┄┄rives in the busy queue, the transmission of B is interrupted.↲
↲
╞ ┆84┆When B relases hold of the session resource B will enter the busy ↓
┆19┆┆89┆┄┄queue and the first in the busy queue (probably A) can be trans┄↓
┆19┆┆89┆┄┄mitted.↲
↲
╞ ┆84┆Note that only class 1 packets can be interrupted in this way.↲
↲
┆8c┆┆81┆┆b4┆↓
┆0e┆↓
╞ fig. 4. Packet interruption.↲
↲
╞ DS╞ ╞ ╞ DH╞ ╞ ╞ S62CP↲
↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
╞ ╞ -╞ document╞ ╞ -↲
╞ ╞ -╞ transmission╞ ╞ -↲
╞ ╞ ╞ for packet B↲
↲
╞ REQ.SUBMIT(A)↲
╞ ╞ ╞ A enters the↲
╞ ╞ ╞ busy queue↲
╞ ╞ ╞ ╞ DOCUMENT RESYNCHRONIZE REQ↲
↲
╞ ╞ ╞ ╞ DOCUMENT RESYNC/DISC CONF↲
╞ close of document stream↲
↲
╞ document stream closed↲
╞ ╞ ╞ ↲
╞ ╞ ╞ B enters↲
╞ ╞ ╞ busy queue↲
╞ ╞ ╞ ╞ SESSION END REQ↲
↲
╞ ╞ ╞ ╞ STREAM CLEARING IND↲
↲
╞ ╞ ╞ ╞ STREAM CLEARING RESP↲
↲
╞ ╞ ╞ ╞ answer on↲
╞ ╞ ╞ ╞ STREAM CLERING RESP↲
↲
↲
╞ ╞ ╞ A exits↲
╞ ╞ ╞ busy queue↲
╞ ╞ ╞ ╞ SESSION START REQ↲
↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
↲
┆0f┆↓
↲
┆8c┆┆83┆┆e0┆↓
┆a1┆┆b0┆2.2.6 ╞ Packet Error Recovery.↲
↲
╞ ┆84┆A document transmission can be interrupted outside the control of ↓
┆19┆┆89┆┄┄DH in the following ways:↲
↲
╞ 1) ┆84┆Receival of a SESSION ABORT from S62CP.↲
↲
╞ 2) ┆84┆Receival of a SESSION START CONF NEG on the session which the ↓
┆19┆┆8c┆┄┄packet should use.↲
↲
╞ 3) ┆84┆Receival of an EXCEPTION IND from S62CP.↲
↲
╞ ┆84┆In case 1) and 2) it is not necessarily the opposite party which ↓
┆19┆┆89┆┄┄has requested the interruption, but it can also be due to network ↓
┆19┆┆89┆┄┄failure of some kind.↲
↲
╞ ┆84┆The DH should try to resume transmission of the packet. This ↓
┆19┆┆89┆┄┄should not, however, be done at once. Other packets should have ↓
┆19┆┆89┆┄┄the chance to get a session (the error can be related to this ↓
┆19┆┆89┆┄┄packet only). In addition to this there will in case of an X.21 ↓
┆19┆┆89┆┄┄network be some restraints on how fast a retransmission may be ↓
┆19┆┆89┆┄┄made for some kind of errors.↲
↲
╞ ┆84┆Therefore a timer will be started, the duration of which depends ↓
┆19┆┆89┆┄┄on the kind of error. The packet is said to be ┆a1┆encapsulated.┆e1┆ As ↓
┆19┆┆89┆┄┄long as this timer runs, the packet will be idle.↲
↲
╞ ┆84┆When the timer runs out, the session allocation procedure will be ↓
┆19┆┆89┆┄┄repeated. The packet will eventually get a session, and when this ↓
┆19┆┆89┆┄┄happens the document transmission will be repeated with DOCUMENT ↓
┆19┆┆89┆┄┄CONTINUE REQ or possibly DOCUMENT START REQ. The last will be the ↓
┆19┆┆89┆┄┄case if checkpoint number in the document description is 0 (no ↓
┆19┆┆89┆┄┄pages has been acknowledged).↲
↲
╞ ┆84┆It is limited how long a packet's accumulated encapsulation time ↓
┆19┆┆89┆┄┄may be. If this limit is exceeded, the packet will be terminated ↓
┆19┆┆89┆┄┄by a CONF.SUBMIT.↲
↲
↲
┆8c┆┆83┆┆d4┆↓
┆a1┆┆b0┆2.2.7 ╞ Regret Handling.↲
↲
╞ ┆84┆A REQ.REGRET is a request for the DH to send a DOCUMENT DISCARD ↓
┆19┆┆89┆┄┄REQ for the document. This in turn is a request to the opposite ↓
┆19┆┆89┆┄┄party to delete the already received part of the document from its ↓
┆19┆┆89┆┄┄permanent storage.↲
↲
╞ ┆84┆If a REQ.REGRET is received for a submit packet where document ↓
┆19┆┆89┆┄┄transmission is in progress, the DOCUMENT DISCARD REQ is send. ↓
┆19┆┆89┆┄┄When the corresponding DOCUMENT RESYNCH/DISC CONF occurs from ↓
┆19┆┆89┆┄┄S62CP the checkpoint number in the document description is set to ↓
┆19┆┆89┆┄┄zero, indicating that a possible later transmission should start ↓
┆19┆┆89┆┄┄from the beginning. This document description is written back at ↓
┆19┆┆89┆┄┄DS by an IND.WRITE, wherupon the REGRET transaction is terminated ↓
┆19┆┆89┆┄┄by sending a CONF.REGRET with result=ok.↲
↲
╞ ┆84┆If no document transmission is in progress, however, the following ↓
┆19┆┆89┆┄┄possibilities arise:↲
↲
╞ - The packet is in the busy queue.↲
╞ - The packet is encapsulated.↲
╞ - ┆84┆The REGRET transaction is received without a SUBMIT being ↓
┆19┆┆8b┆┄┄alive on the packet↲
╞ - ┆84┆Document transmission has been terminated (by sending a ↓
┆19┆┆8b┆┄┄DOCUMENT END REQ)↲
↲
╞ ┆84┆In the last case the REGRET will be terminated by a CONF.REGRET ↓
┆19┆┆89┆┄┄with result=pers_err.↲
↲
╞ ┆84┆Otherwise a session should be established to send a DOCUMENT ↓
┆19┆┆89┆┄┄CONTINUE REQ followed by the discard. Therefore the handling of ↓
┆19┆┆89┆┄┄a discard packet is the same as described in preceding sections ↓
┆19┆┆89┆┄┄for submit packets, up to and including sending of a DOC CONTINUE ↓
┆19┆┆89┆┄┄REQ. A REQ.REGRET has in fact the same parameters as a REQ.SUBMIT.↲
↲
╞ ┆84┆The only difference is that packet interruption is meaningless. A ↓
┆19┆┆89┆┄┄regret packet has the class 0.↲
↲
╞ ┆84┆When a DOC CONTINUE REQ has been sent, the handling is as ↓
┆19┆┆89┆┄┄described in the beginning of this section.↲
↲
↲
┆8c┆┆83┆┆f8┆↓
┆0e┆↓
╞ fig. 5. REGRET Handling.↲
↲
╞ DS╞ ╞ ╞ DH╞ ╞ ╞ S62CP↲
↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
╞ ╞ -╞ document╞ ╞ -↲
╞ ╞ -╞ transmission╞ ╞ -↲
╞ ╞ ╞ in progress↲
↲
╞ REQ.REGRET↲
╞ ╞ ╞ ╞ DOCUMENT DISCARD REQ↲
╞ CONF.SUBMIT result=not_proc↲
↲
╞ close of document stream↲
↲
╞ document stream closed╞ ↲
╞ ╞ ╞ ╞ DOCUMENT RESYNCH/DISCARD CONF↲
╞ IND.WRITE, checkpoint=0↲
╞ ╞ ╞ ╞ SESSION END REQ↲
╞ RESP.WRITE↲
↲
╞ CONF.REGRET, result=ok↲
↲
┆0f┆↓
↲
↲
┆a1┆┆b0┆2.2.8 ╞ Abort Handling.↲
↲
╞ ┆84┆When a REQ.ABORT is received and document transmission is in ↓
┆19┆┆89┆┄┄progress, the packet will be terminated as described in section ↓
┆19┆┆89┆┄┄2.2.5. In all other cases the packet will be terminated at once by ↓
┆19┆┆89┆┄┄sending a CONF.ABORT with result=ok.↲
↲
↲
┆a1┆┆b0┆2.2.9 ╞ Reuse of Sessions.↲
↲
╞ ┆84┆Up to now one could get the impression that sessions always are ↓
┆19┆┆89┆┄┄terminated when a submit packet does not need it anymore.↲
↲
╞ ┆84┆However, when a DOCUMENT END CONF or a DOCUMENT RESYNCH/DISCARD ↓
┆8c┆┆83┆┆d4┆↓
┆19┆┆89┆┄┄CONF has been received from S62CP, the session is in the source ↓
┆19┆┆89┆┄┄idle state, and another packet can use it.↲
↲
╞ The following is done in this case:↲
↲
╞ ┆84┆The busy queue is inspected to see if there is another packet ↓
┆19┆┆89┆┄┄which can use this session. The following conditions should be ↓
┆19┆┆89┆┄┄fulfilled:↲
↲
╞ - ┆84┆The addressee TI parameters should match the called TI from the ↓
┆19┆┆8b┆┄┄session identification (calling TI if the remote party was ↓
┆19┆┆8b┆┄┄initi┄ator of the session).↲
↲
╞ - ┆84┆Service for the packet should be TTX.↲
↲
╞ - ┆84┆The packet must not request charge because it then sshould be ↓
┆19┆┆8b┆┄┄transmitted in a session by its own (see section 2.2.10).↲
↲
╞ - ┆84┆There must not be any other packet in the busy queue which ↓
┆19┆┆8b┆┄┄precedes the one in question.↲
↲
╞ ┆84┆When all this is ok the packet will be removed from the busy ↓
┆19┆┆89┆┄┄queue and document transmission preparation can be done as des┄↓
┆19┆┆89┆┄┄cribed in section 2.2.2. if it was a SUBMIT packet. A REGRET ↓
┆19┆┆89┆┄┄packet also can reuse a session (to send the discard).↲
↲
┆8c┆┆82┆┆b8┆↓
┆0e┆↓
╞ fig.6. Reuse of a session.↲
↲
╞ DS╞ ╞ ╞ DH╞ ╞ ╞ S62CP↲
↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
╞ ╞ -╞ document╞ ╞ -↲
╞ ╞ -╞ transmission╞ ╞ -↲
╞ ╞ ╞ for packet A↲
╞ ╞ ╞ in progress.↲
╞ REQ.SUBMIT(B)↲
╞ (same parameters)↲
╞ ╞ ╞ B enters busy↲
╞ ╞ ╞ queue↲
↲
↲
╞ ╞ ╞ ╞ DOCUMENT END CONF↲
╞ IND.WRITE↲
↲
╞ RESP.WRITE↲
↲
╞ close of document stream↲
↲
╞ document stream closed↲
↲
╞ CONF.SUBMIT(A)↲
↲
╞ ╞ ╞ packet B exits↲
╞ ╞ ╞ busy queue↲
↲
╞ IND.READ↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
↲
↲
╞ ┆84┆For the rest of the story, see fig.2 and fig. 3.↲
┆0f┆↓
┆8c┆┆83┆┆b0┆↓
┆0e┆↓
┆a1┆┆b0┆2.2.10 ╞ Charge Request Handling.↲
↲
╞ ┆84┆When the charge request bit is set in options for a SUBMIT packet, ↓
┆19┆┆89┆┄┄the charge request will be specified in the SESSION START REQ for ↓
┆19┆┆89┆┄┄the session, which the packet shall use.↲
┆0f┆↓
↲
╞ ┆84┆However, the CHARGE INF IND is only delivered by S62CP after a ↓
┆19┆┆89┆┄┄SESSION END REQ (or SESSION ABORT REQ) has been sent by DH. The ↓
┆19┆┆89┆┄┄packet should await the CHARGE INF IND and reuse of the session ↓
┆19┆┆89┆┄┄is of course impossible.↲
↲
╞ ┆84┆The termination of such a packet will look like this (please refer ↓
┆19┆┆89┆┄┄to fig. 3 and 4):↲
┆0e┆↓
↲
╞ fig.7. charge handling.↲
↲
╞ DS╞ ╞ ╞ DH╞ ╞ ╞ S62CP↲
↲
↲
╞ close of document stream↲
↲
╞ document stream closed↲
╞ ╞ ╞ ╞ SESSION END REQ↲
↲
╞ ╞ ╞ ╞ SESSION END CONF↲
↲
↲
╞ IND.UPDATE╞ CHARGE INF IND↲
╞ charge information↲
↲
╞ CONF.SUBMIT↲
↲
↲
┆0f┆↓
↲
╞ ┆84┆If the session is terminated abnormally by receival of a SESSION ↓
┆19┆┆89┆┄┄ABORT IND, the CHARGE INF IND will be awaited before the encapsul┄↓
┆19┆┆89┆┄┄ation is made.↲
↲
↲
┆8c┆┆83┆┆d4┆↓
┆a1┆┆b0┆2.3. ╞ TLX Packet Transmission.↲
↲
╞ ┆84┆This is a packet aimed at the TELETEX/TELEX conversion unit. Such ↓
┆19┆┆89┆┄┄a packet consists of:↲
↲
╞ 1) ┆84┆A control document, containing information to the conversion ↓
┆19┆┆8c┆┄┄unit, f.ex. identification of the end user. (Telex addressee)↲
↲
╞ 2) ┆84┆One or more normal (TELEX) documents, which should be sent to ↓
┆19┆┆8c┆┄┄the end user as one telex.↲
↲
╞ ┆84┆These documents should be transmitted in one session, because it ↓
┆19┆┆89┆┄┄is exactly the fact that they belong to the same session which ↓
┆19┆┆89┆┄┄defines the correspondence between them.↲
↲
╞ ┆84┆The DH will proceed like this:↲
↲
╞ 1) ┆84┆The session allocation is done as described in section 2.2.1. ↓
┆19┆┆8c┆┄┄The busy queue contains both TTX and TLX packets.↲
↲
╞ 2) ┆84┆When a session is allocated, the control document is ↓
┆19┆┆8c┆┄┄transmitted as described in section 2.2.2 and 2.2.3, up to the ↓
┆19┆┆8c┆┄┄moment where the document stream has been closed.↲
↲
╞ 3) ┆84┆An IND.READ is issued for the next document in the packet, and ↓
┆19┆┆8c┆┄┄this is transmitted as mentioned in 2).↲
↲
╞ 4) ┆84┆When the last document in the packet has been transmitted, ↓
┆19┆┆8c┆┄┄which is detected by an IND.READ being answered by RESP.READ ↓
┆19┆┆8c┆┄┄with result=failed,a SESSION END REQ is sent, which to the ↓
┆19┆┆8c┆┄┄conversion unit signifies that packet transmission is complete. ↓
┆19┆┆8c┆┄┄The packet remains in possession of the session until a SESSION ↓
┆19┆┆8c┆┄┄END CONF is received. Only when this happens the packet is↓
┆19┆┆8c┆┄┄stored at the conversion unit for sure, and a CONF.SUBMIT with ↓
┆19┆┆8c┆┄┄result=ok can be sent.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆Error recovery is a special problem for TLX packets, for the ↓
┆19┆┆89┆┄┄following reasons:↲
↲
╞ - ┆84┆The conversion unit will never keep partial packets in its ↓
┆19┆┆8b┆┄┄permanent storage, and packet retransmission shall always start ↓
┆19┆┆8b┆┄┄from the beginning.↲
↲
╞ - ┆84┆If transmission of the control document has been successfull, it ↓
┆19┆┆8b┆┄┄is not allowed to retransmit the packet before a special ↓
┆19┆┆8b┆┄┄document, a socalled NACK document, has been sent back by the ↓
┆19┆┆8b┆┄┄conversion unit in another session.↲
↲
╞ ┆84┆The last point puts severe restraints on the DH error recovery. ↓
┆19┆┆89┆┄┄The DH does not interpret the content of received/transmitted do┄↓
┆19┆┆89┆┄┄cuments. Consequently it will not realize the correspondence be┄↓
┆19┆┆89┆┄┄tween the original packet and the NACK document, which to the DH ↓
┆19┆┆89┆┄┄is an independent receival packet.↲
↲
╞ ┆84┆Therefore encapsulation is only made when the control document has ↓
┆19┆┆89┆┄┄not been fully transmitted. After the encapsulation packet trans┄↓
┆19┆┆89┆┄┄mis┄sion will start from the beginning.↲
↲
╞ ┆84┆Otherwise the DH will give the packet back to DS by means of a ↓
┆19┆┆89┆┄┄CONF.SUBMIT with result=failed. It is then up to the DS to ↓
┆19┆┆89┆┄┄perform error recovery, if any.↲
↲
╞ ┆84┆The possibility to send DOCUMENT RESYNCHRONIZE REQ or DOCUMENT ↓
┆19┆┆89┆┄┄DISCARD REQ is not used. In the cases where these primitives would ↓
┆19┆┆89┆┄┄be applied for normal packets a SESSION ABORT REQ will be sent ↓
┆19┆┆89┆┄┄instead. This also holds for handling of a REQ.REGRET or a ↓
┆19┆┆89┆┄┄REQ.ABORT, which are treatet alike by DH for TLX packets.↲
↲
╞ ┆84┆Finally it should be mentioned that charge can be requestet for ↓
┆19┆┆89┆┄┄TLX packets too. The termination of the packet will be as ↓
┆19┆┆89┆┄┄described in section 2.2.10.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆2.4.╞ Memory Reservation.↲
↲
╞ ┆84┆When a session has been established by the DH receiving a SESSION ↓
┆19┆┆89┆┄┄START IND, and sending SESSION START RESP POS, the session will ↓
┆19┆┆89┆┄┄for the moment not be related to anything at all. It is said to be ↓
┆19┆┆89┆┄┄in the sink idle state.↲
↲
╞ ┆84┆However, if a MEMORY RESERVATION IND occurs, this will be a ↓
┆19┆┆89┆┄┄request for reservation of an amount of memory, to be used for one ↓
┆19┆┆89┆┄┄or more documents to be received in the session.↲
↲
╞ ┆84┆The reservation cannot, however, be related to a specific packet, ↓
┆19┆┆89┆┄┄because the same reservation can be used for several documents.↲
↲
╞ ┆84┆Therefore the memory reservation protocol is introduced. An ↓
┆19┆┆89┆┄┄IND.RESERVE will be sent to DS, requesting the same amount of ↓
┆19┆┆89┆┄┄memory. The DS reacts with a RESP.RESERVE, in which it can state ↓
┆19┆┆89┆┄┄one of the following:↲
↲
╞ - Reservation can be made.↲
╞ - ┆84┆Some of the amount can be reserved.↲
╞ - reservation cannot be made.↲
↲
╞ ┆84┆The same information is then given to S62CP in a MEMORY ↓
┆19┆┆89┆┄┄RESERVATION RESP primitive.↲
↲
╞ ┆84┆If nothing can be reserved, the DH forgets everything about it. ↓
┆19┆┆89┆┄┄Otherwise the DS Mem. Res. number will be used as "reservation" ↓
┆19┆┆89┆┄┄parameter in all TRANSFER blocks sent for documents received on ↓
┆19┆┆89┆┄┄this session.↲
↲
╞ ┆84┆A memory reservation is cancelled by an IND.RELEASE in the fol┄↓
┆19┆┆89┆┄┄lowing cases:↲
↲
╞ - ┆84┆A new MEMORY RESERVATION IND is received. An IND.RELEASE and an ↓
┆19┆┆8b┆┄┄IND.RESERVE is sent , in that order.↲
╞ - ┆84┆The session is terminated, either normally or abmormally.↲
↲
↲
┆8c┆┆83┆┆d4┆↓
┆a1┆┆b0┆2.5 ╞ Normal Packet Reception.↲
↲
╞ ┆84┆This covers receival of packets (documents) where the opposite ↓
┆19┆┆89┆┄┄party is not the TELEX conversion unit.↲
↲
↲
┆a1┆┆b0┆2.5.1╞ Packet Creation.↲
↲
╞ ┆84┆This section describes creation of a new receival packet. This is ↓
┆19┆┆89┆┄┄done when a DOCUMENT START IND or a DOCUMENT CONTINUE IND with an ↓
┆19┆┆89┆┄┄unknown document identification is received.↲
↲
╞ ┆84┆An IND.CREATE is sent to DH, whereupon a RESP.CREATE is awaited. ↓
┆19┆┆89┆┄┄The DH then proceeds by an IND.INITIATE to create a document ↓
┆19┆┆89┆┄┄description for the document.↲
↲
╞ ┆84┆However, the new document description at DS will not contain the ↓
┆19┆┆89┆┄┄S62 document identification , taken from the DOCUMENT START IND or ↓
┆19┆┆89┆┄┄the DOCUMENT CONTINUE IND. Therefore the DH on reception of the ↓
┆19┆┆89┆┄┄RESP.INITIATE at once will send an IND.WRITE containing the fully ↓
┆19┆┆89┆┄┄defined document description.↲
↲
╞ ┆84┆Note that continuation will be true in the description in case of ↓
┆19┆┆89┆┄┄DOCUMENT CONTINUE IND. ↲
↲
╞ ┆84┆When, at last, the RESP.WRITE is received from DS, the DH will ↓
┆19┆┆89┆┄┄issue a TRANSFER block, with mode=W(write), opening a document ↓
┆19┆┆89┆┄┄stream. When the REPLY OK is received on the stream, a DOCUMENT ↓
┆19┆┆89┆┄┄START/CONTINUE RESP is sent to S62CP and document data can be ↓
┆19┆┆89┆┄┄received.↲
↲
┆8c┆┆82┆┆f4┆↓
┆0e┆↓
↲
╞ fig.8. Packet creation.↲
↲
↲
╞ DS╞ ╞ ╞ DH╞ ╞ ╞ S62CP↲
↲
╞ ╞ ╞ ╞ DOCUMENT START IND↲
╞ IND.CREATE↲
↲
╞ RESP.CREATE,result=ok↲
↲
╞ IND.INITIATE↲
↲
╞ RESP.INIT,result=ok↲
↲
╞ IND.WRITE↲
↲
╞ RESP.WRITE↲
↲
╞ TRANSFER(W)↲
↲
╞ REPLY OK↲
╞ ╞ ╞ ╞ DOCUMENT START/CONT RESP POS↲
┆0f┆↓
↲
↲
┆a1┆┆b0┆2.5.2 ╞ Document Receival.↲
↲
╞ ┆84┆After packet creation (or document continuation, see section ↓
┆19┆┆89┆┄┄2.5.3) the document reception will proceed by DATA IND blocks ↓
┆19┆┆89┆┄┄being sent on the document stream as TRANSFER blocks, and the PAGE ↓
┆19┆┆89┆┄┄END IND blocks as CHECKPOINT blocks.↲
↲
╞ ┆84┆When a CHECKPOINT block is received on the document stream from ↓
┆19┆┆89┆┄┄DS the corresponding page is stored at permanent storage. A PAGE ↓
┆19┆┆89┆┄┄END RESP can be sent, but first will the DH make sure that the DS ↓
┆19┆┆89┆┄┄document description is consistent by performing a WRITE transac┄↓
┆19┆┆89┆┄┄tion, containing the updated checkpoint number.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆When a DOCUMENT END IND is received from S62CP, a STREAM END is ↓
┆19┆┆89┆┄┄sent on the document stream. At the arrival of the corresponding ↓
┆19┆┆89┆┄┄STREAM END from DS the document description will be written back ↓
┆19┆┆89┆┄┄ (with finished = true and updated checkpoint number) at DS by a ↓
┆19┆┆89┆┄┄WRITE transaction.↲
↲
╞ ┆84┆The document stream will be closed, and when this is finished a ↓
┆19┆┆89┆┄┄DOCUMENT END RESP can be sent to S62CP (the DH is ready to receive ↓
┆19┆┆89┆┄┄another document) and an IND.DELIVER to DS.↲
↲
╞ ┆84┆The session will be in the sink idle state, and a new packet can ↓
┆19┆┆89┆┄┄be received on it or the session can be terminated.↲
↲
┆8c┆┆81┆┆9c┆↓
┆0e┆↓
↲
╞ fig. 9. Document receival.↲
↲
╞ DS╞ ╞ ╞ DH╞ ╞ ╞ S62CP↲
↲
╞ ╞ ╞ ╞ DATA IND↲
╞ STREAM↲
╞ ╞ ╞ ╞ PAGE END IND↲
╞ CHECKPOINT↲
╞ ╞ ╞ ╞ DATA IND↲
╞ STREAM↲
↲
╞ CHECKPOINT↲
↲
╞ IND.WRITE↲
↲
╞ RESP.WRITE╞ ╞ ↲
╞ ╞ ╞ ╞ PAGE END CONF↲
↲
↲
↲
╞ IND.WRITE╞ DOCUMENT END IND↲
╞ finished=true╞ ↲
↲
↲
╞ ╞ STREAM END↲
↲
↲
╞ STREAM END↲
╞ RESP.WRITE↲
↲
↲
╞ close of document stream↲
↲
╞ document stream closed↲
╞ ╞ ╞ ╞ DOCUMENT END CONF↲
╞ IND.DELIVER↲
┆0f┆↓
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆2.5.3╞ Document Receival Interruption.↲
↲
╞ ┆84┆A document receival can be terminated abnormally in the following ↓
┆19┆┆89┆┄┄ways:↲
↲
╞ 1) ┆84┆By the DH sending an EXCEPTION REQ, on which a DOCUMENT RESYN┄↓
┆19┆┆8c┆┄┄CHRONIZE IND or a DOCUMENT DISCARD IND is expected as response. ↓
┆19┆┆8c┆┄┄This possibility is used by DH when a premature break down of ↓
┆19┆┆8c┆┄┄the document stream occurs.↲
↲
╞ 2) ┆84┆By receival of a DOCUMENT DISCARD IND, see section 2.5.4.↲
↲
╞ 3) ┆84┆By receival of a DOCUMENT RESYNCH IND. The opposite party re┄↓
┆19┆┆8c┆┄┄quests a temporary interruption of the transfer. The document ↓
┆19┆┆8c┆┄┄level can be left in an well ordered manner by the DH reacting ↓
┆19┆┆8c┆┄┄with DOCUMENT RESYNCH/DISC RESP, after which the session re┄↓
┆19┆┆8c┆┄┄turns to the sink idle state.↲
↲
╞ 4) ┆84┆By receival of a SESSION ABORT IND. This can be a request from ↓
┆19┆┆8c┆┄┄the opposite party, but it can also signify network failure.↲
↲
╞ ┆84┆In the last two cases it is possible that packet reception can be ↓
┆19┆┆89┆┄┄continued later. Therefore the DH will keep the packet waiting.↲
↲
╞ ┆84┆When a DOCUMENT CONTINUE IND is received referring to this packet, ↓
┆19┆┆89┆┄┄discovered by comparing the S.62 document id in the document des┄↓
┆19┆┆89┆┄┄cription with the corresponding parameter from DOCUMENT CONTINUE ↓
┆19┆┆89┆┄┄IND, the document reception will be resumed.↲
↲
╞ ┆84┆The DH will proceed in the same way as for packet creation (see ↓
┆19┆┆89┆┄┄section 2.5.1) after receival of the RESP.INIT. The IND.WRITE╞ ↓
┆19┆┆89┆┄┄will here contain the updated checkpoint number (can be lesser ↓
┆19┆┆89┆┄┄than before)↲
↲
╞ ┆84┆The waiting for a continuation is, however, limited by a timer. ↓
┆19┆┆89┆┄┄When this runs out, the packet will be terminated by an ↓
┆19┆┆89┆┄┄IND.DELIVER.↲
↲
↲
┆8c┆┆83┆┆d4┆↓
┆a1┆┆b0┆2.5.4╞ ERASE and CANCEL Handling.↲
↲
╞ ┆84┆If a DOCUMENT DISCARD IND is sent by S62CP to DH, the opposite ↓
┆19┆┆89┆┄┄party has requested the already received part of the document to ↓
┆19┆┆89┆┄┄be cancelled.↲
↲
╞ ┆84┆The DH will then issue an IND.ERASE removing the document descrip┄↓
┆19┆┆89┆┄┄tion. After that the DH will deliver the empty packet to DS by an ↓
┆19┆┆89┆┄┄IND.DELIVER.↲
↲
╞ ┆84┆However, if the packet was initialised by a DOCUMENT CONTINUE IND, ↓
┆19┆┆89┆┄┄an IND.CANCEL will be sent instead. This informs the DS (or poss┄↓
┆19┆┆89┆┄┄ibly the end user) that no continuation will occur for the earlier ↓
┆19┆┆89┆┄┄received partial packet.↲
↲
╞ ┆84┆Finally it should be noted that if a document receival inter┄↓
┆19┆┆89┆┄┄ruption occurs (see preceding section), and no pages have been ↓
┆19┆┆89┆┄┄acknowledged (checkpoint number in the document description is ↓
┆19┆┆89┆┄┄zero), the handling will be as if a discard was received.↲
↲
┆8c┆┆81┆┆f0┆↓
┆0e┆↓
↲
╞ fig. 10. CANCEL handling.↲
↲
╞ DS╞ ╞ ╞ DH╞ ╞ ╞ S62CP↲
↲
╞ ╞ ╞ ╞ DOCUMENT CONTINUE IND↲
╞ ╞ ╞ ╞ (unknown S62 doc id)↲
╞ IND.CREATE↲
↲
↲
╞ ╞ -╞ document ╞ ╞ -↲
╞ ╞ -╞ reception╞ ╞ -↲
╞ ╞ -╞ in progress╞ ╞ -↲
↲
╞ ╞ ╞ ╞ DOCUMENT DISCARD IND↲
╞ close of document stream↲
↲
╞ document stream closed↲
╞ ╞ ╞ ╞ DOCUMENT DISC/RESYNCH RESP↲
╞ IND.ERASE↲
↲
╞ ╞ IND.CANCEL↲
┆0f┆↓
┆8c┆┆82┆┆88┆↓
┆0e┆↓
┆a1┆┆b0┆2.6╞ TLX Packet Receival.↲
↲
╞ ┆84┆This is a packet from the TELEX conversion unit. Such a packet ↓
┆19┆┆89┆┄┄consists of either:↲
↲
╞ - one control document (f.ex. a NACK document)↲
↲
╞ or↲
↲
╞ - ┆84┆one control document followed by a normal (telex) document, ↓
┆19┆┆8b┆┄┄which originates from the telex end user.↲
┆0f┆↓
↲
╞ ┆84┆A TLX packet will in all cases be transmitted in one session.↲
↲
╞ The following is done:↲
↲
╞ ┆84┆When the first DOCUMENT START IND occurs on a session, which ↓
┆19┆┆89┆┄┄originated from the conversion unit, packet creation is done as ↓
┆19┆┆89┆┄┄described in section 2.5.1↲
↲
╞ ┆84┆Document receival will then take place as described in section ↓
┆19┆┆89┆┄┄2.5.2, up to and including sending of a DOCUMENT END RESP to ↓
┆19┆┆89┆┄┄S62CP.↲
↲
╞ ┆84┆The packet will then, however, remain in possession of the ↓
┆19┆┆89┆┄┄session. The following situations can occur:↲
↲
╞ 1) SESSION END IND received.↲
╞ ┆84┆The packet is complete and an IND.DELIVER with result=ok is ↓
┆19┆┆8c┆┄┄made.↲
↲
╞ 2) ┆84┆SESSION ABORT IND received.↲
╞ ┆84┆Here, too, the packet is delivered by an IND.DELIVER with ↓
┆19┆┆8c┆┄┄result=ok. It is impossible for DH to discover if the packet ↓
┆19┆┆8c┆┄┄consisted of one or two documents.↲
↲
╞ 3) A new DOCUMENT START IND received.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆In the last case an IND.INITIATE will be sent to create a document ↓
┆19┆┆89┆┄┄description. From this point onward, receival of the normal docu┄↓
┆19┆┆89┆┄┄ment proceeds as for the control document.↲
↲
╞ ┆84┆However, if a new DOCUMENT START IND occurs, it is an error and ↓
┆19┆┆89┆┄┄SES┄SION ABORT REQ will be sent.↲
↲
╞ ┆84┆Finally, if a document transfer is interrupted, either by a SES┄↓
┆19┆┆89┆┄┄SION ABORT IND or a SESSION ABORT REQ from DH, the packet will be ↓
┆19┆┆89┆┄┄delivered as it is by an IND.DELIVER. Continu┄ation is not poss┄↓
┆19┆┆89┆┄┄ible.↲
↲
╞ ┆84┆SESSION ABORT REQ is used by DH when document stream troubles ↓
┆19┆┆89┆┄┄occur or a DOCUMENT RESYNCH. (DISCARD) IND is received.↲
↲
↲
┆a1┆┆b0┆2.7╞ Change in Source/sink Relationship.↲
↲
╞ ┆84┆This section describes how the DH uses the possibility offered by ↓
┆19┆┆89┆┄┄S.62 to change source/sink relationship. This is never done for ↓
┆19┆┆89┆┄┄TLX packets.↲
↲
↲
┆a1┆┆b0┆2.7.1 Change from Sink to Source.↲
↲
╞ ┆84┆The whole story of what happens when a SUBMIT/REGRET packet enters ↓
┆19┆┆89┆┄┄the busy queue has not yet been told.↲
↲
╞ ┆84┆When this happens, and no packets can be interrupted, it will be ↓
┆19┆┆89┆┄┄tested if there is a session where the DH is sink and where the ↓
┆19┆┆89┆┄┄conditions for session, mentioned in section 2.2.9, is fulfilled.↲
↲
╞ ┆84┆If such a session is found, a PLEASE CHANGE CONTROL REQ will be ↓
┆19┆┆89┆┄┄sent, and nothing more will be done at the moment.↲
↲
┆8c┆┆83┆┆a4┆↓
┆0e┆↓
╞ ┆84┆If a CHANGE CONTROL IND is received on a session, the busy queue ↓
┆19┆┆89┆┄┄will be inspected to see if there is a packet, which can use the ↓
┆19┆┆89┆┄┄session to transmit its document as described in section 2.2.9. ↓
┆19┆┆89┆┄┄(Possibly the packet which caused the PLEASE CHANGE CONTROL REQ to ↓
┆19┆┆89┆┄┄be sent). If that is the case, the packet will be transmitted as ↓
┆19┆┆89┆┄┄described in section 2.2.2 and 2.2.3. However, when the document ↓
┆19┆┆89┆┄┄stream has been closed, the control is given back by a CHANGE CON┄↓
┆19┆┆89┆┄┄TROL REQ, provided this side is not caller, and no other packet ↓
┆19┆┆89┆┄┄can use the session.↲
┆0f┆↓
↲
↲
↲
┆8c┆┆81┆┆90┆↓
┆0e┆↓
╞ fig. 11. Change from sink to source.↲
↲
╞ DS╞ ╞ ╞ DH╞ ╞ ╞ S62CP↲
↲
╞ ╞ ╞ ╞ SESSION START IND↲
↲
╞ ╞ ╞ ╞ SESSION START CONF↲
↲
╞ ╞ ╞ ╞ DOCUMENT START REQ↲
↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
╞ ╞ -╞ document receival╞ -↲
╞ ╞ -╞ in progress╞ ╞ -↲
╞ ╞ ╞ for packet A↲
↲
╞ REQ.SUBMIT(B)↲
╞ (same address)↲
↲
╞ ╞ ╞ B enter↲
╞ ╞ ╞ busy queue↲
╞ ╞ ╞ ╞ PLEASE CHANGE CONTR. REQ↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
╞ IND.DELIVER(A) DOCUMENT END CONF↲
↲
╞ ╞ ╞ ╞ CHANGE CONTR IND↲
↲
╞ ╞ ╞ B exits↲
╞ ╞ ╞ busy queue↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
╞ ╞ ╞ ╞ DOCUMENT END CONF↲
↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
╞ ╞ -╞ ╞ ╞ ╞ -↲
╞ CONF.SUBMIT(B)╞ CHANGE CONTROL REQ↲
↲
┆0f┆↓
↲
┆8c┆┆83┆┆ec┆↓
┆a1┆┆b0┆2.7.2╞ Change from Source to Sink.↲
↲
╞ ┆84┆When a PLEASE CHANGE CONTROL IND is received on a session orig┄↓
┆19┆┆89┆┄┄inating on this side, the request cannot be granted automatically, ↓
┆19┆┆89┆┄┄because this side is charged for the call.↲
↲
╞ ┆84┆The adressee TI is looked up in a table, the "associates list", ↓
┆19┆┆89┆┄┄which contains the addresses for which the request can be granted.↲
↲
╞ ┆84┆If it is found there, a CHANGE CONTROL REQ is sent when no more ↓
┆19┆┆89┆┄┄packets can use the session. The session will be in the sink idle ↓
┆19┆┆89┆┄┄state, and packets can be received.↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆3.╞ COMMUNICATION WITH THE TTXSI↲
↲
╞ ┆84┆In ref. (3) the various commands (blocks) which can be exchanged ↓
┆19┆┆89┆┄┄between the DS and the CU is listed .The function and parameters ↓
┆19┆┆89┆┄┄of these commands are also explained there, and this chapter will ↓
┆19┆┆89┆┄┄only describe how these commands are exchanged between the TTXSI ↓
┆19┆┆89┆┄┄and DH.↲
↲
╞ ┆84┆The buffers with these commands (in the following called the com┄↓
┆19┆┆89┆┄┄mand buffers) are transferred by means of the procedure signal. ↓
┆19┆┆89┆┄┄The two processes know each others main semaphores and it is con┄↓
┆19┆┆89┆┄┄se┄quently not a multiuser interface. But the DH is as already men┄↓
┆19┆┆89┆┄┄tioned unaware of the administration of IMC connec┄tions.↲
↲
╞ ┆84┆Furthermore, the DH does not know the existence of different DS's. ↓
┆19┆┆89┆┄┄The DH only knows TU's and it is the responsibility of the TTXSI ↓
┆19┆┆89┆┄┄to suspend the TU's belonging to a DS, to which the connection is ↓
┆19┆┆89┆┄┄lost.↲
↲
╞ ┆84┆The commands interchanged are the ones mentioned in ref. 3, with ↓
┆19┆┆89┆┄┄the exceptions of the ones used solely for IMC connection admini┄↓
┆19┆┆89┆┄┄stration. A few additional commands are introduced too.↲
↲
╞ ┆84┆The following applies to the following description in generel:↲
↲
┆84┆╞ ┆84┆If one of the rules stated in this capter are violated, it will ↓
┆19┆┆89┆┄┄normally provoke an exception or a deadlock due to lack of buf┄fers ↓
┆19┆┆89┆┄┄in DH or lower level modules. However, some errors will be re┄↓
┆19┆┆89┆┄┄garded as DS protocol errors, but this will be explecitely men┄↓
┆19┆┆89┆┄┄tioned.↲
↲
↲
┆a1┆┆b0┆3.1╞ Control Commands.↲
↲
╞ ┆84┆These commands are the ones not related to the document transfer ↓
┆19┆┆89┆┄┄protocol, with the exception the following commands commands:↲
╞ ╞ ╞ LOGON↲
╞ ╞ ╞ REPLY-OK↲
╞ ╞ ╞ REPLY NOTOK↲
╞ A few new commands are added.↲
┆8c┆┆83┆┆e0┆↓
┆a1┆┆b0┆3.1.1╞ Control Commands from TTXSI to DH.↲
↲
╞ ┆84┆The commands in question are the REQUEST commands and the RESPONSE ↓
┆19┆┆89┆┄┄commands. Two new commands are added: REQUEST.SUSPEND and ↓
┆19┆┆89┆┄┄REQUEST.RESUME.↲
↲
╞ ┆84┆The command buffers are transferred to DH by means of a signal to ↓
┆19┆┆89┆┄┄the DH main mailbox (described by dh_main, see appendix B).↲
↲
╞ The buffers belong to (are allocated by) TTXSI.↲
↲
╞ a) Buffer format (when received by DH):↲
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000e181e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
╞ ┆a1┆buffer attributes:↲
↲
╞ u1:╞ ttxsi_buf↲
╞ bufsize:╞ ┆84┆should be great enough to contain the area indi┄↓
┆19┆┆98┆┄┄cated by offset and top.↲
↲
╞ top:╞ ┆84┆should be at least offset + 10 allowing room for ↓
┆19┆┆98┆┄┄header byte, kind, DS TU number, CU TU number, DS ↓
┆19┆┆98┆┄┄packet number, and CU packet number. The command ↓
┆19┆┆98┆┄┄dependent check of top is made by DH.↲
↲
╞ eventkind: message event.↲
↲
╞ Unmentioned buffer attributes are undefined.↲
↲
╞ ┆a1┆data area:↲
↲
╞ ┆84┆The beginning of the buffers (accessed by means of "lockbuf") ↓
┆19┆┆8d┆┄┄has the format:↲
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000e181e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000e181e28323c464b555f69737d8791ff04╱
↓
↲
╞ ┆a1┆ ↲
╞ ! ! !↲
╞ ! - ! 0 !↲
╞ ┆a1┆! ! !↲
╞ <2octets> <2octets>↲
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000e181e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000e181e28323c464b555f69737d8791ff04╱
↓
↲
╞ ┆84┆In the area of the buffer pointed out by top and offset is ↓
┆19┆┆8d┆┄┄placed the command data with the format described in ref. 3.↲
↲
┆8c┆┆83┆┆e0┆↓
╞ ┆84┆The CU-TU number field cannot be zero, however, as described ↓
┆19┆┆8d┆┄┄be┄low.↲
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000e181e28323c464b555f69737d8791ff04╱
↓
↲
╞ b) answers.↲
╞ ┆84┆The buffer will, with some exceptions, (see next section) be ↓
┆19┆┆8d┆┄┄sent back to TTXSI by means of a call of return.↲
╞ ┆84┆This indicates that the buffer resource is free. The answer ↓
┆19┆┆8d┆┄┄will always be generated at once. All buffer at┄tributes (ex┄↓
┆19┆┆8d┆┄┄cept eventkind) will be unchanged. This holds for the data ↓
┆19┆┆8d┆┄┄area too.↲
↲
╞ c) ┆84┆Identification of TU's.↲
╞ ┆84┆TU's are identified to the DH by the CU-TU number. It is the ↓
┆19┆┆8d┆┄┄re┄sponsibility of the TTXSI to ensure that this field is set ↓
┆19┆┆8d┆┄┄before forwarding the buffer to DH.↲
↲
╞ ┆84┆The CU-TU number should inside the range 1.. no_of_tu where ↓
┆19┆┆8d┆┄┄no_of_tu is a program parameter to DH (see appendix B). This ↓
┆19┆┆8d┆┄┄parameter shall consequently be transferred to TTXSI too. This ↓
┆19┆┆8d┆┄┄ensures that both DH and TTXSI can access a TU by simple in┄↓
┆19┆┆8d┆┄┄dexing.↲
↲
╞ ┆84┆DH regards a TU to exist when a REQUEST.ACTIVATE is received ↓
┆19┆┆8d┆┄┄where CU-TU number indicates an idle TU (not used before or ↓
┆19┆┆8d┆┄┄released as described in the next section).↲
↲
╞ d) Identification of packets.↲
╞ ┆84┆The TTXSI should not know anything about packets, and the ↓
┆19┆┆8d┆┄┄handling of DS-PACKET number and CU-PACKET number is done ↓
┆19┆┆8d┆┄┄completely by DH.↲
┆a1┆↲
╞ e) ┆84┆The REQUEST.SUSPEND command.↲
╞ This command has the format:↲
↲
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
╞ ┆a1┆ ↲
╞ ! ! ! ! ! ! !↲
╞ ! 0 ! 19 ! DS TU no ! CU TU no ! 0 ! 0 !↲
╞ ┆a1┆! ! ! ! ! ! !↲
<ioctet><1octet> <2octets> <2octets> ↓
↲
↲
╞ ↲
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆This command is intended for use when the communication with ↓
┆19┆┆8d┆┄┄the DS, to which the TU belongs, breaks down. The TS will re┄↓
┆19┆┆8d┆┄┄ject all incoming calls, informing that the terminal is "out ↓
┆19┆┆8d┆┄┄of order". The following should be noted, however:↲
↲
╞ - ┆84┆the TTXSI is not allowed to send any commands concerning ↓
┆19┆┆8f┆┄┄this TU until a CONFIRMATION.SUSPEND is received. Until it ↓
┆19┆┆8f┆┄┄sends a REQUEST.RESUME, the only other legal command from ↓
┆19┆┆8f┆┄┄the TTXSI is REQUEST.REMOVE.↲
↲
╞ - ┆84┆if the TU is being removed (see next section) the ↓
┆19┆┆8f┆┄┄REQUEST.SUSPEND will be ignored, and no CONF.SUSPEND sent.↲
↲
╞ - ┆84┆all packet communication is terminated in the same way as ↓
┆19┆┆8f┆┄┄for REQUEST.REMOVE.↲
↲
╞ f) The REQUEST.RESUME command.↲
╞ It has the format:↲
↲
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
┆a1┆╞ ╞ ╞ ╞ ╞ ↲
! ! ! ! ! ! !↲
! 0 ! 20 ! DS TU no ! CU TU no ! 0 ! 0 !↲
┆a1┆! ! ! ! ! ! !↲
<1octet><1octet> <2octets> < 2octets > <2octets> <2octets>↲
↲
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
↲
╞ ┆84┆Reactivates the TU. Is only allowed when a CONFIR┄MA┄↓
┆19┆┆8d┆┄┄TION.SUSPEND has been received from DH for this TU, and no ↓
┆19┆┆8d┆┄┄REQUEST.REMOVE has been sent.↲
↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆3.1.2╞ Control Commands from DH to TTXSI↲
↲
╞ ┆84┆These are the CONFIRMATION and the INDICATION commands with the ↓
┆19┆┆89┆┄┄addition of the INDICATION.ERROR and the CONFIRMATION.SUSPEND ↓
┆19┆┆89┆┄┄mentioned below.↲
↲
╞ ┆84┆The command buffer is transferred to TTXSI by means of a signal to ↓
┆19┆┆89┆┄┄the TTXSI main mailbox, described by ttxsi_main, see appendix B.↲
↲
╞ ┆84┆The buffer will normally belong to DH but a TTXSI buffer is used ↓
┆19┆┆89┆┄┄instead for CONFIRMATION commands when this command can be ↓
┆19┆┆89┆┄┄generated right away. It is f.ex. the case when busy or not proc ↓
┆19┆┆89┆┄┄results is to be returned.↲
╞ This helps the DH to compute buffer demands for TU's and packets.↲
↲
┆0e┆↓
╞ a) ┆84┆Buffer format (when received by TTXSI).↲
↲
╞ ┆a1┆buffer attributes↲
↲
╞ top:╞ ╞ ┆84┆Defines together with offset command data ↓
┆19┆┆9d┆┄┄area.↲
↲
╞ eventkind:╞ message event.↲
┆0f┆↓
↲
╞ ┆84┆Unmentioned buffer attributes are either undefined (in case of ↓
┆19┆┆8d┆┄┄the buffer belonging to the DH) or unchanged (in case of the ↓
┆19┆┆8d┆┄┄buffer belonging to TTXSI).↲
↲
╞ ┆a1┆data area↲
╞ ┆84┆The beginning of the buffer (accessed by means of "lockbuf" ↓
┆19┆┆8d┆┄┄has the format:↲
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
↲
╞ ┆a1┆ ↲
╞ ! ! !↲
╞ ! - ! 0 !↲
╞ ┆a1┆! ! !↲
╞ <2octets> <1octet>↓
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
↲
╞ ┆84┆In the area of the buffer pointed out by offset and top the ↓
┆19┆┆8d┆┄┄command data is placed. The format is as described in ref. 3 ↓
┆19┆┆8d┆┄┄ex┄cept that the content of DS-TU number will be undefined.↲
↲
┆8c┆┆83┆┆e0┆↓
╞ b) ┆a1┆┆e1┆answers↲
╞ ┆84┆When a command buffer belonging to DH should be sent back to ↓
┆19┆┆8d┆┄┄DH by TTXSI, it should be done by means of a call of return.↲
╞ ┆84┆Of the buffer attributes, u1, should be unchanged. This also ↓
┆19┆┆8d┆┄┄holds for first two words in the buffer and the fields ↓
┆19┆┆8d┆┄┄header_byte, kind, CU-TU number, and CU-packet number in the ↓
┆19┆┆8d┆┄┄data area.↲
↲
╞ ┆84┆The following rules apply to the sequence in which the buffers ↓
┆19┆┆8d┆┄┄should be returned for a specific TU.↲
↲
╞ 1) ┆84┆A CONFIRMATION.REMOVE command buffer should be returned ↓
┆19┆┆93┆┄┄last of all command buffers for the TU in question.↲
↲
┆0e┆↓
╞ 2) ┆84┆the following commands define termination of a packet:↲
╞ ┆84┆CONFIRMATION.SUBMIT, when no REGRET or ABORT is out┄↓
┆19┆┆93┆┄┄standing.↲
╞ ╞ CONFIRMATION.REGRET, when no ABORT is outstanding↲
╞ ╞ CONFIRMATION.ABORT↲
╞ INDICATION.CANCEL↲
┆0f┆↓
╞ ┆84┆Such a command buffer should be returned last of all ↓
┆19┆┆93┆┄┄command buffers for the packet in question.↲
╞ ┆84┆Note that rule 1) and 2) are easily obeyed by returning ↓
┆19┆┆93┆┄┄all buffers for a given TU in the sequence they are sent ↓
┆19┆┆93┆┄┄by DH, which again is easily done when using the IMC.↲
↲
╞ 3)╞ ┆84┆It is generally assumed that the DS cannot react on a ↓
┆19┆┆93┆┄┄received INDICATION or CONFIRMATION command before the ↓
┆19┆┆93┆┄┄command buffer has been returned to DH.↲
↲
╞ ╞ ┆84┆Some of the consequences are:↲
↲
╞ ╞ - ┆84┆┆84┆A buffer containing an INDICATION command should have ↓
┆19┆┆95┆┄┄been returned before the corresponding RESPONSE com┄↓
┆19┆┆95┆┄┄mand is received by DH.↲
↲
╞ ╞ - ┆84┆A DS packet number cannot be reused before the command ↓
┆19┆┆95┆┄┄buffer, which releases the packet (f.ex. CONF.ABORT) ↓
┆19┆┆95┆┄┄is returned.↲
↲
┆8c┆┆83┆┆e0┆↓
╞ ╞ ┆84┆DH will for certain commands check that this rule is ↓
┆19┆┆93┆┄┄fol┄lowed. Failure to comply with this rule is regarded ↓
┆19┆┆93┆┄┄as a DS protocol error↲
↲
╞ 4) ╞ ┆84┆When the TTXSI has sent a REQ.SUSPEND, it needs not to ↓
┆19┆┆93┆┄┄follow rule 2).↲
↲
╞ 5) ┆84┆A CONFIRMATION.SUSPEND should be returned last of all ↓
┆19┆┆93┆┄┄buffers for the TU in question. ↲
↲
╞ c) ┆a1┆┆e1┆Removal of TU's↲
╞ ┆84┆The following commands sent to the TTXSI will indicate removal ↓
┆19┆┆8d┆┄┄of a TU and is called remove commands:↲
↲
╞ ╞ CONFIRMATION.REMOVE with result = ok↲
╞ ╞ CONFIRMATION.ACTIVATE with result = busy↲
╞ ╞ ╞ ╞ ┆81┆or↲
╞ ╞ ┆81┆╞ ╞ result = dupl_fct↲
╞ ┆84┆The DH regards the TU as removed when the answer on a remove ↓
┆19┆┆8d┆┄┄command is received.↲
↲
╞ d) ┆a1┆┆e1┆Error handling↲
╞ ┆84┆To indicate fatal DS errors a INDICATION.ERROR command is ↓
┆19┆┆8d┆┄┄used. Because errors to DH's point of view concern TU's (con┄↓
┆19┆┆8d┆┄┄trol or data connections are not known) the format used by DH ↓
┆19┆┆8d┆┄┄is as follows:↲
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
┆0e┆↓
↲
╞ ┆a1┆ ╞ ╞ ↲
╞ ! ! ! ! ! ! ! !↲
╞ ! 102 ! code ! CU TU no ! 32 ! 21 ! DS TU no ! CU TU no !↲
╞ ┆a1┆!┆a1┆ ! ! ! ! ! ! !↲
<1octet><1octet><2 octets><1octet><1octet><2octets> <2octets>↲
↲
┆a1┆ ↲
╞ ! ! ! !↲
╞ ! 0 ! 0 ! code !↲
╞ ┆a1┆! ! ! !↲
<2octets> <2octets> <1octet>↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
↲
╞ code can obtain the following values:↲
════════════════════════════════════════════════════════════════════════
↓
╞ 8.╞ protocol error.↲
╞ ╞ ┆84┆A control command has been re┄ceived in a TU state or a ↓
┆19┆┆93┆┄┄packet state when it was not allowed.↲
╞ 9.╞ block format error.↲
╞ ╞ ┆84┆A command received from TTXSI had an incomprehensive ↓
┆19┆┆93┆┄┄content.↲
↲
╞ 10.╞ block length error.↲
╞ ╞ ┆84┆A received command had an illegal length.↲
↲
╞ ┆84┆The command causing the error will otherwise be ignored. A ↓
┆19┆┆8d┆┄┄REQUEST.SUSPEND for the TU in question is expected to be ↓
┆19┆┆8d┆┄┄received soon.↲
↲
╞ e) ┆84┆CONFIRMATION.SUSPED↲
╞ This command has the format:↲
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
↲
╞ ┆a1┆ ↲
╞ ! ! ! ! ! ! !↲
╞ ! 31 ! 19 ! DS TU no ! - ! 0 ! 0 !↲
╞ ┆a1┆! ! ! ! ! ! !↲
<1octet><1octet> <2octets> <2octets> <2octets> <2octets>↲
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
↲
↲
┆a1┆┆b0┆3.2╞ Document Transfer Commands↲
↲
╞ ┆84┆These commands are the ones exchanged on a data connection, with ↓
┆19┆┆89┆┄┄exception of the following:↲
↲
╞ ╞ LOGON↲
╞ ╞ REPLY_OK as answer to a LOGON↲
↲
TTXSI stream close and DH stream close are introduced, see below.↲
╞ ┆84┆Data connections are here called document streams. They are ↓
┆19┆┆89┆┄┄identi┄fied by a stream number.↲
↲
╞ ┆84┆Stream numbers will be inside the range 1...max_sess_nu, where ↓
┆19┆┆89┆┄┄"max_sess_nu" is a process parameter (see appendix B.). This para┄↓
┆19┆┆89┆┄┄meter should be transferred to the TTXSI too.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆3.2.1╞ Document Transfer Commands from DH to TTXSI↲
↲
╞ ┆84┆a) Buffer format (when received by TTXSI)↲
↲
╞ ┆a1┆buffer attributes↲
↲
╞ offset, top: ┆84┆defines the place in the buffer where the ↓
┆19┆┆9b┆┄┄command is placed.↲
↲
╞ eventkind: message event.↲
↲
╞ Unmentioned buffer attributes are undefined.↲
↲
┆a1┆┆e1┆ ┆a1┆data area↲
↲
╞ ┆84┆The beginning of the buffer (accessed by means of "lockbuf") ↓
┆19┆┆8e┆┄┄has the format:↲
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
╞ ┆a1┆ ┆a1┆┆82┆┆e1┆┆82┆-----↲
! ! !↲
! CU TU no ! stream no !↲
┆a1┆┆e1┆ ┆a1┆! ! !┆e1┆┆82┆-----↲
<2octets> <2octets>↲
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
↲
╞ ┆84┆The command, with the format as defined in ref. 3, is placed ↓
┆19┆┆8e┆┄┄in the area pointed out by offset and top.↲
↲
╞ b) Opening of document streams↲
↲
╞ ┆84┆A document stream is opened by DH with a TRANSFER block. The ↓
┆19┆┆8e┆┄┄content of the DS TU number hold will be undefined.↲
↲
╞ c) Closing of document streams.↲
↲
╞ ┆84┆A new primitive, DH stream close, is defined. It has the ↓
┆19┆┆8e┆┄┄header byte 6 and no further data.↲
↲
╞ ┆84┆It will always be sent by DH as the last message on the ↓
┆19┆┆8e┆┄┄stream. When the buffer is returned, the DH regards the ↓
┆19┆┆8e┆┄┄stream as removed, and nothing more should be sent from TTXSI ↓
┆19┆┆8e┆┄┄on it.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆It should be noted that if the DH wants a stream prematurely ↓
┆19┆┆8e┆┄┄terminated, it will send a REPLY NOTOK follwed by a DH stream ↓
┆19┆┆8e┆┄┄close. This is, however, not the case if a TTXSI stream close ↓
┆19┆┆8e┆┄┄or a REPLY NOTOK first has been received from TTXSI.↲
↲
╞ d) Answers.↲
↲
╞ The following rules should be obeyed:↲
↲
╞ 1. The u1 attribute should be unchanged.↲
╞ 2. ┆84┆The header byte should be unchanged.↲
╞ 3. ┆84┆The first three words in the buffer should be unchanged.↲
╞ 4. ┆84┆A buffer with a DH stream close should be returned last ↓
┆19┆┆92┆┄┄of all DH buffers on this stream.↲
╞ 5. ┆84┆A TRANSFER buffer should be returned before the REPLY OK ↓
┆19┆┆92┆┄┄is sent to DH.↲
╞ 6. ┆84┆If a write operation is in progress and the TTXSI sends a ↓
┆19┆┆92┆┄┄CHECKPOINT (STREAM END) to DH, the following conditions ↓
┆19┆┆92┆┄┄should hold:↲
╞ - ┆84┆The corresponding CHECKPOINT (STREAM END) from DH ↓
┆19┆┆95┆┄┄should have been returned by TTXSI. If this rule is ↓
┆19┆┆95┆┄┄not followed, it will be regarded as a DS protocol ↓
┆19┆┆95┆┄┄error on the stream.↲
- ┆84┆The Data buffers from DH precceding the CHECKPOINT ↓
┆19┆┆95┆┄┄(STREAM END) should have been returned by TTXSI.↲
↲
↲
╞ ┆84┆It should be noted that only a limited number of STREAM ↓
┆19┆┆8e┆┄┄buffers can be pending at TTXSI at the same time. This ↓
┆19┆┆8e┆┄┄creates the back pressure which controls the flow con┄trol on ↓
┆19┆┆8e┆┄┄the corresponding session.↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆3.2.2╞ Document Stream Commands from TTXSI to DH↲
↲
╞ ┆84┆a) Buffer format (when received by DH)↲
↲
┆0e┆↓
╞ ┆a1┆buffer attributes↲
↲
╞ u1: ttxsi_buf↲
┆0f┆↓
↲
╞ offset: should at least be s62_head_lgt.↲
╞ ╞ ┆84┆This makes it possible to forward the blocks to ↓
┆19┆┆99┆┄┄S62CP. The only additional condition is that it ↓
┆19┆┆99┆┄┄should point inside the buffer.↲
↲
╞ top:╞ ┆84┆Defines together with offset the area in the buf┄↓
┆19┆┆99┆┄┄fer where the command data is placed.↲
╞ ╞ ┆84┆Note that the DH will check if its value is con┄↓
┆19┆┆99┆┄┄sistent.↲
┆82┆↲
╞ eventkind: message event.↲
↲
╞ ┆a1┆data area↲
↲
╞ ┆84┆The beginning of the buffer will have the following format:↲
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
↲
╞ ┆a1┆ ┆e1┆┆82┆----↲
╞ ! ! !↲
╞ ! - ! stream no !↲
╞ ┆a1┆! ! !┆e1┆┆82┆----↲
╞ <2octets> <2octets>↲
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
↲
╞ ┆84┆In the area pointed out by offset and top the command should ↓
┆19┆┆8e┆┄┄be placed.↲
↲
╞ b) Closing of document streams.↲
↲
╞ ┆84┆The TTXSI can request a document stream closed by sending a ↓
┆19┆┆8e┆┄┄TTXSI stream close to DH. This command has the header byte 6, ↓
┆19┆┆8e┆┄┄and indicates a premature close of the document stream. It ↓
┆19┆┆8e┆┄┄can also, however, be used as a reaction on a DH stream close ↓
┆19┆┆8e┆┄┄to use the answer as a means to detect when all buffers are ↓
┆19┆┆8e┆┄┄home.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆Note that it should be sent before the DH stream close is ↓
┆19┆┆8e┆┄┄returned.↲
↲
╞ c) Answers.↲
↲
╞ The following holds:↲
↲
╞ 1. ┆84┆Of the buffer attributes u2, u1, top and offset (and of ↓
┆19┆┆91┆┄┄course eventkind) are destroyed, the rest is unchanged.↲
╞ 2. ┆84┆The stream no field in the buffer will be unchanged. The ↓
┆19┆┆91┆┄┄rest of the buffer content is destroyed.↲
╞ 3. ┆84┆A TTXSI stream close is returned last of all.↲
┆81┆↲
↲
↲
↲
↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆4.╞ COMMUNICATION WITH S62CP↲
↲
╞ ┆84┆┆84┆This chapter deals with the communication with S62CP with the main ↓
┆19┆┆89┆┄┄emphasis on how parameters correspond with parameters on the DS ↓
┆19┆┆89┆┄┄primitives. A close knowledge of both ref. 3 and ref. 4 is neces┄↓
┆19┆┆89┆┄┄sary for the reader.↲
↲
╞ ┆84┆In the following sections the S62CP primitives are listed, one per ↓
┆19┆┆89┆┄┄section. The following things are explained:↲
↲
╞ - ┆84┆Parameters and the use of them.↲
↲
╞ ┆84┆The following remarks are common to all of the primitives:↲
↲
╞ ┆84┆t_ref: index pointing to the TU description in DH.↲
╞ ┆84┆It is the same as the CU TU no. used in DS primitives.↲
↲
╞ ┆84┆For all session oriented primitives holds:↲
↲
╞ u_sess_ref (if defined):↲
╞ Index pointing on the session description in DH.↲
↲
╞ s_sess_ref (if defined:)↲
╞ ┆84┆For messages sent to S62CP it will be the value delivered ↓
┆19┆┆8c┆┄┄earlier from this module.↲
↲
╞ - Buffer format for message.↲
╞ ┆84┆If nothing is remarked the buffers consist of the parameters ↓
┆19┆┆8c┆┄┄placed in the beginning of the buffers. The value of offset is ↓
┆19┆┆8c┆┄┄without importance.↲
↲
╞ - Answers:↲
╞ ┆84┆It will for messages to S62CP be explained if the answers mean ↓
┆19┆┆8c┆┄┄anything. If nothing is mentioned it will just be regarded as a ↓
┆19┆┆8c┆┄┄free buffer resource.↲
↲
╞ ┆84┆For messages to DH it will be explained if anything can delay ↓
┆19┆┆8c┆┄┄its return. If nothing is mentioned it is answered right away.↲
↲
┆8c┆┆83┆┆d4┆↓
╞ ┆84┆If an S62CP primitive is omitted from the description nothing of ↓
┆19┆┆89┆┄┄interest is to be said concerning the things mentioned above.↲
↲
↲
┆a1┆┆b0┆4.1╞ ACTIVATE TI↲
↲
╞ ┆84┆Parameters:↲
╞ ┆84┆They are constructed from parameters from REQ.ACTIVATE. (In the ↓
┆19┆┆89┆┄┄following the abbreviations REQ for REQUEST, IND for INDI┄CATION, ↓
┆19┆┆89┆┄┄RESP for RESPONSE and CONF for CONFIRMATION is used).↓
↲
╞ ti : ┆84┆The corresponding parameter from REQ.ACTIVATE.↲
╞ ↲
switch : ┆84┆The switch bit in the option parameters.↲
↲
╞ switch_ti3 : ┆84┆tsap_id is set equal to the switch_ti parameter ↓
┆19┆┆98┆┄┄from REQ.ACTIVATE, and tsap_id_signf is set so ↓
┆19┆┆98┆┄┄trailing spaces are removed.↲
↲
╞ switch_visi : = the switch visible bit in options.↲
╞ ↲
╞ rec_unkn : = ┆84┆the recipient unknown bit in options.↲
↲
╞ rec_unkn_visi: = the recipient unknown visible bit in options.↲
↲
╞ rec_cap : Is set to the capabilities parameters.↲
↲
╞ Answer:↲
╞ The result has the following meaning:↲
↲
╞ busy : Result is set to busy in CONF.ACTIVATE.↲
↲
╞ dupl_func : result is set to dupl_fct.↲
↲
╞ format_err: The DS has made a protocol error.↲
↲
┆8c┆┆83┆┆b0┆↓
┆0e┆↓
↲
┆a1┆┆b0┆4.2╞ REDEFINE TI↲
↲
╞ parameters:↲
╞ ┆84┆switch, switch_ti3, switch_visi, rec_unkn, rec_unkn_visi, rec_cap, ↓
┆19┆┆89┆┄┄see 4.1., but they are taken from a REQ.REDEFINE.↲
┆0f┆↓
↲
┆a1┆↲
┆a1┆┆b0┆4.3╞ SESSION START REQ↲
↲
╞ ┆84┆The parameters are constructed from the REQ.SUBMIT ( or the ↓
┆19┆┆89┆┄┄REQ.REGRET) parameters in the following way:↲
↲
╞ addressee_ti : ┆84┆the corresponding parameter, except when ↓
┆19┆┆99┆┄┄SERVICE=TLX. Then it is the address on the con┄↓
┆19┆┆99┆┄┄version unit which is s process parameter to ↓
┆19┆┆99┆┄┄DH.↲
↲
╞ check_ta : the personal bit from options.↲
↲
╞ check_mnem : true if↲
╞ ╞ 1) personal = true↲
╞ ╞ or↲
╞ ╞ 2) the verify part 4 bit is true↲
↲
╞ charge_inf_req: the charge request bit from option.↲
↲
╞ queuing_time : Process parameter to DH.↲
↲
╞ Answer:↲
╞ result = busy:↲
╞ ┆84┆The call must have crossed an incoming call (the session resources ↓
┆19┆┆89┆┄┄in S62CP and DH should be equal).↲
╞ A short encapsulation is made.↲
↲
╞ result = format_err↲
╞ The DS has made a protocol error.↲
↲
┆8c┆┆83┆┆c8┆↓
┆0e┆↓
┆a1┆┆b0┆4.4╞ SESSION START CONF POS↲
↲
╞ Parameters:↲
╞ ┆84┆They are used (together with a document reference number) to con┄↓
┆19┆┆89┆┄┄struct document identifications.↲
┆0f┆↓
↲
↲
┆a1┆┆b0┆4.5╞ SESSION START CONF NEG↲
↲
╞ ┆84┆Parameters:↲
╞ ┆84┆user_inf are delivered to DS in an IND.UPDATE together with DH ↓
┆19┆┆89┆┄┄user info constructed from rej_reason, see chapter 7.↲
↲
↲
┆a1┆┆b0┆4.6╞ SESSION START IND↲
↲
╞ ┆84┆Parameters:↲
╞ ┆84┆called_ti, calling_ti, date_and_time, add_s_ref:↲
╞ used to construct document identifications.↲
╞ ┆84┆addressee_ta: ↲
╞ ┆84┆transferred to DS as the addressee TI parameter in an ↓
┆19┆┆89┆┄┄IND.DELIVER.↲
↲
╞ answer:↲
╞ ┆84┆If there is no free session description available (inside the cor┄↓
┆19┆┆89┆┄┄responding session pool, see section 6.3.1) the following is done:↲
╞ ┆84┆If a START SESSION REQ (from the same pool) is pending, the answer ↓
┆19┆┆89┆┄┄is delayed until the answer on the pending message is received. ↓
┆19┆┆89┆┄┄Then the free resource will be allocated to the session.↲
↲
╞ ┆84┆Otherwise the message will be returned with result = busy.↲
↲
╞ ┆84┆This strategy will ensure that incoming calls have priority over ↓
┆19┆┆89┆┄┄outgoings.↲
↲
╞ ┆84┆If the TU, identified by t_ref, are being removed or suspended, ↓
┆19┆┆89┆┄┄the result not_proc is used.↲
↲
↲
┆8c┆┆83┆┆d4┆↓
┆a1┆┆b0┆4.7╞ SESSION START RESP NEG↲
↲
╞ ┆84┆Used for a disabled TU.↲
↲
╞ parameters:↲
╞ reason=2↲
╞ text message: From the REQ.DISABLE↲
↲
↲
┆a1┆┆b0┆4.8╞ SESSION ABORT REQ↲
↲
╞ parameters:↲
╞ reason= ┆84┆local terminal error if the cause was a document stream ↓
┆19┆┆91┆┄┄break down by a TLX packet.↲
= ┆84┆unrecoverable procedure error if a procedure error from ↓
┆19┆┆91┆┄┄the telex conversion unit is detected.↲
= "no reason given" otherwise↲
↲
↲
┆a1┆┆b0┆4.9╞ SESSION ABORT IND↲
↲
╞ ┆84┆The parameters are delivered to the DS by means of an IND.UPDATE, ↓
┆19┆┆89┆┄┄see chapter 7.↲
↲
╞ ┆84┆Note, however, that if ab_reason is lpe, the DS has made a proto┄↓
┆19┆┆89┆┄┄col error.↲
↲
↲
┆a1┆┆b0┆4.10╞ CHARGE INF IND↲
↲
╞ ┆84┆Parameters:↲
╞ charge_inf is delivered to the DS in an IND.UPDATE.↲
↲
↲
┆a1┆┆b0┆4.11╞ STREAM CLEARING RESP↲
↲
╞ ┆84┆Indicates that all pending S62CP buffers have been returned. If a ↓
┆19┆┆89┆┄┄document receival was in progress, the sending of this primitive ↓
┆19┆┆89┆┄┄awaits the document stream close. (DATA IND and PAGE END messages ↓
┆19┆┆89┆┄┄can be pending as STREAM and CHECKPOINT messages at TTXSI.↲
↲
┆8c┆┆83┆┆ec┆↓
╞ ┆84┆Answer:↲
╞ ┆84┆The answer indicates that all pending messages on this stream are ↓
┆19┆┆89┆┄┄home. If a document transmission has been in progress, termina┄tion ↓
┆19┆┆89┆┄┄of the document stream should await this.↲
╞ ┆84┆(STREAM and CHECKPOINT messages can be pending as DATA REQ and ↓
┆19┆┆89┆┄┄PAGE END REQ).↲
↲
↲
┆a1┆┆b0┆4.12╞ CAPABILITIES REQ↲
↲
╞ Parameters:↲
╞ mem_req : use of this parameter is for further study.↲
↲
╞ cap_req : ┆84┆Taken from the document header field from the document ↓
┆19┆┆93┆┄┄stream REPLY_OK block.↲
↲
↲
┆a1┆┆b0┆4.13╞ CAPABILITIES CONF POS↲
↲
╞ Parameters:↲
╞ ┆84┆The uses of the parameters mem_answ and mem_reserv are for further ↓
┆19┆┆89┆┄┄study.↲
↲
↲
┆a1┆┆b0┆4.14╞ DOCUMENT START REQ↲
↲
╞ ┆84┆Parameters:↲
╞ service interwork,↲
╞ doc_type↲
╞ req_cap : ┆84┆Taken from the document header field from the ↓
┆19┆┆9d┆┄┄document stream REPLY_OK block.↲
↲
↲
┆a1┆┆b0┆4.15╞ DOCUMENT START CONF↲
↲
╞ Parameters:↲
╞ doc_ref_no : ┆84┆Used to construct the document identification.↲
↲
↲
┆8c┆┆83┆┆d4┆↓
┆a1┆┆b0┆4.16╞ DOCUMENT CONTINUE REQ↲
↲
╞ session_info : always true↲
↲
╞ called_ti,↲
╞ calling_ti,↲
╞ date_and_time,↲
╞ add_sess_ref_no,↲
╞ doc_ref_no : ┆84┆The document identification constructed when ↓
┆19┆┆9d┆┄┄DOCUMENT START REQ was sent for this docu┄↓
┆19┆┆9d┆┄┄ment.↲
↲
╞ checkp_ref_no : ┆84┆The checkpoint number from the document ↓
┆19┆┆9d┆┄┄description.↲
↲
╞ service_interwork,↲
╞ doc_type,↲
╞ req_cap : ┆84┆As for DOCUMENT START REQ.↲
╞ ╞ ↓
↲
↲
┆a1┆┆b0┆4.17╞ DATA REQ↲
↲
╞ ┆84┆This is originally a STREAM block from the document stream.↲
↲
╞ buffer format for message:↲
╞ ┆84┆Offset from the STREAM block received from TTXSI will be increased ↓
┆19┆┆89┆┄┄by one, thus skipping the header byte field.↲
↲
╞ answer:↲
╞ ┆84┆Returned directly to the TTXSI from S62CP.↲
↲
↲
┆8c┆┆83┆┆8c┆↓
┆0e┆↓
↲
┆a1┆┆b0┆4.18╞ PAGE END REQ↲
↲
╞ ┆84┆This is originally a CHECKPOINT block from the document stream.↲
↲
╞ answer:↲
╞ ┆84┆Returned directly to the TTXSI by S62CP.↲
┆0f┆↓
↲
↲
┆a1┆↲
↲
┆a1┆┆b0┆4.19╞ EXCEPTION IND↲
↲
╞ ┆84┆Parameters:↲
╞ except_reason: ┆84┆Used to construct DH user info which is sent to DS ↓
┆19┆┆98┆┄┄in an IND.UPDATE together with the user_info ↓
┆19┆┆98┆┄┄parameter.↲
↲
↲
┆a1┆┆b0┆4.20╞ DOCUMENT DISCARD REQ↲
↲
╞ ┆84┆This primitive is used when a REQ.REGRET should be executed.↲
↲
╞ parameters:↲
╞ reason : no specific reason - - -.↲
↲
↲
┆a1┆┆b0┆4.21╞ DOCUMENT RESYNCHRONIZE REQ↲
↲
╞ ┆84┆Parameters:↲
╞ reason : ┆84┆depends on why the resynchronize is sent in the fol┄↓
┆19┆┆93┆┄┄lowing way: "no specific ---" if the document is ↓
┆19┆┆93┆┄┄interrupted by another packet, or a REQ.ABORT was being ↓
┆19┆┆93┆┄┄executed.↲
╞ ┆84┆"local terminal error" if it is a document stream break ↓
┆19┆┆93┆┄┄down.↲
↲
↲
┆8c┆┆83┆┆c8┆↓
┆a1┆┆b0┆4.22╞ MEMORY RESERVATION IND↲
↲
╞ Parameters:↲
╞ mem_req : ┆84┆transferred to DS as the size parameter is an ↓
┆19┆┆93┆┄┄IND.RESERVE.↲
↲
↲
┆a1┆┆b0┆4.23╞ MEMORY RESERVATION RESP↲
↲
╞ Parameters:↲
╞ mem_answ : ┆84┆depends on the result parameter in RESP.RESERVE ↓
┆19┆┆9b┆┄┄in the following way:↲
╞ ok: = ┆84┆req_reserved↲
╞ ╞ failed: =┆84┆ mem_reserved↲
╞ ╞ busy: = not_reserved↲
↲
╞ mem_reserv : ┆84┆The size parameter from RESP.RESERVE.↲
↲
↲
┆a1┆┆b0┆4.24╞ DOCUMENT START IND↲
↲
╞ Parameters:↲
╞ doc_ref_no : ┆84┆used to construct the document identification.↲
↲
╞ doc_type : ┆84┆delivered in the document header parameter in a ↓
┆19┆┆9b┆┄┄document stream TRANSFER with mode=w.↲
↲
╞ service_interwrk: as doc_type.↲
↲
╞ req_cap : as doc_type.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆4.25╞ DOCUMENT CONTINUE IND↲
↲
╞ ┆84┆Parameters:↲
╞ session_info : ┆84┆if false, the add_s_ref_no parameter from SES┄↓
┆19┆┆9b┆┄┄SION START CONF POS or SESSION START IND is used ↓
┆19┆┆9b┆┄┄to construct the document identification, for ↓
┆19┆┆9b┆┄┄which a search should be made.↲
↲
╞ called_ti,↲
╞ calling_ti,↲
╞ date_and_time,↲
╞ doc_ref_no : ┆84┆used to construct the document identification, ↓
┆19┆┆9b┆┄┄for which a search is made.↲
↲
╞ add_s_ref : ┆84┆if session_info = true, see above.↲
↲
╞ service_interwrk,↲
╞ doc_type,↲
╞ req_cap : ┆84┆transferred to DS in the header field in a ↓
┆19┆┆9b┆┄┄TRANSFER block with mode = W.↲
↲
╞ answer:↲
╞ ┆84┆Can be delayed if the packet, to which it refers, not are ready to ↓
┆19┆┆89┆┄┄process it.↲
↲
↲
↲
┆a1┆┆b0┆4.26╞ DATA IND↲
↲
╞ ┆84┆This message is transferred to TTXSI as a STREAM block. Offset is ↓
┆19┆┆89┆┄┄decreased with one, and a header byte = 3 is inserted before the ↓
┆19┆┆89┆┄┄user information.↲
↲
╞ answer:↲
╞ ┆84┆The message is returned directly from the TTXSI, and offset will ↓
┆19┆┆89┆┄┄be destroyed.↲
↲
↲
↲
┆8c┆┆83┆┆d4┆↓
┆a1┆┆b0┆4.27╞ DOCUMENT END RESP↲
↲
╞ ┆84┆answer:↲
╞ ┆84┆It is assumed that the answer to this message is delayed until all ↓
┆19┆┆89┆┄┄other document level massages are returned.↲
↲
↲
┆a1┆┆b0┆4.28╞ EXCEPTION REQ↲
↲
╞ ┆84┆This primitive is used by DH when a document stream breaks down.↲
↲
╞ parameters:↲
╞ reason:╞ = 1 ┆84┆(temporarily unable ---) if the reason for the break ↓
┆19┆┆97┆┄┄down was a REPLY NOTOK with code = no resources.↲
╞ ╞ = 5 otherwise.↲
↲
↲
┆a1┆┆b0┆4.29╞ DOCUMENT DISCARD IND↲
↲
╞ ┆84┆Parameters:↲
╞ discard_reason,↲
╞ user_info╞ : transferred to the DS in an IND.UPDATE↲
↲
↲
┆a1┆┆b0┆4.30╞ DOCUMENT RESYNCHRONIZE IND↲
↲
╞ Parameters:↲
╞ resynch_reason,↲
╞ user_info : transferred to DS in an IND.UPDATE↲
↲
↲
┆a1┆┆b0┆4.31╞ DOCUMENT RESYNCH/DISCARD RESP↲
↲
╞ Answer:↲
╞ ┆84┆The same assumption as for DOCUMENT END RESP is made.↲
════════════════════════════════════════════════════════════════════════
↓
┆82┆↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆5.╞ THE DH LCP↲
↲
╞ ┆84┆This chapter describes the LCP (local control probe) for the DH, ↓
┆19┆┆89┆┄┄i.e. the communication with the NCP. The rules for this communi┄↓
┆19┆┆89┆┄┄cations are described in ref. 5.↲
↲
╞ ┆84┆In the following sections the various control operations, sense ↓
┆19┆┆89┆┄┄ope┄rations, and events are described. The precise encoding of ↓
┆19┆┆89┆┄┄these LCP oper┄ations will be specified in another manual.↲
↲
↲
┆a1┆┆b0┆5.1╞ The NC MASK↲
↲
╞ ┆84┆The DH contains an NC MASK. This is a 16 bits word, where some of ↓
┆19┆┆89┆┄┄the bits are attached to the various LCP events, one bit for every ↓
┆19┆┆89┆┄┄event. The setting of these bits controls if a given event will be ↓
┆19┆┆89┆┄┄generated or not.↲
↲
╞ ┆84┆The control operation SET NC MASK updates this mask. The para┄↓
┆19┆┆89┆┄┄meters are↲
↲
╞ ┆a1┆message request↲
╞ update mask : ┆84┆the bits set here are the bits to be updated.↲
╞ update value : ┆84┆the bits selected by update mask contains new ↓
┆19┆┆98┆┄┄values for the corresponding bits in NC MASK, i.e. ↓
┆19┆┆98┆┄┄the following is done:↲
╞ ╞ ┆84┆NC MASK : = (NC MASK and not update mask) or↲
╞ ╞ ╞ (update mask and update value)↲
↲
╞ ┆a1┆message answer↲
╞ Updated NC MASK↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆5.2╞ TU Oriented LCP Operations↲
↲
┆84┆↲
┆a1┆┆b0┆5.2.1╞ Content of a TU Description↲
↲
╞ ┆84┆In all TU oriented LCP events and SENSE answers a TU description ↓
┆19┆┆89┆┄┄is delivered , which is a copy of the most important fields in the ↓
┆19┆┆89┆┄┄corresponding TU description in DH. It has the following content:↲
↲
╞ DS TU number↲
↲
╞ DH TU number╞ Index in the DH TU table↲
╞ ╞ ╞ ┆84┆The t_ref parameter to the S62CP primitives.↲
↲
╞ TU state╞ ╞ See below↲
↲
╞ TI╞ ╞ ┆84┆The terminal identifier for this TU↲
↲
╞ text message:╞ ┆84┆Only meaningful when the TU is (is being) ↓
┆19┆┆9d┆┄┄disabled.↲
↲
╞ The TU state can possess the values:↲
↲
╞ TU idle╞ ╞ ┆84┆A free TU description. When this value is de┄↓
┆19┆┆9d┆┄┄livered in an LCP event, it means that the TU ↓
┆19┆┆9d┆┄┄has just been removed.↲
↲
╞ active↲
↲
╞ wait redef╞ ┆84┆A redefining of the TU awaits that all ↓
┆19┆┆9d┆┄┄sessions belonging to this TU has been ↓
┆19┆┆9d┆┄┄removed.↲
↲
╞ disabling╞ ╞ ┆84┆A disable of the TU awaits all sink sessions ↓
┆19┆┆9d┆┄┄being removed.↲
↲
╞ disabled↲
════════════════════════════════════════════════════════════════════════
↓
╞ wait disable redef ┆84┆Both a redefining and a disable is in progress ↓
┆19┆┆9d┆┄┄and CONF.DISABLE is sent when all sink ↓
┆19┆┆9d┆┄┄sessions have been removed.↲
↲
╞ wait remove╞ ┆84┆A removal of the TU awaits all sessions being ↓
┆19┆┆9d┆┄┄removed.↲
↲
╞ removing╞ ╞ ┆84┆A DEACTIVATE TI is pending at S62CP, because ↓
┆19┆┆9d┆┄┄the TI is to be removed.↲
↲
╞ wait suspend╞ ┆84┆A suspension of the TU awaits all session ↓
┆19┆┆9d┆┄┄being removed.↲
↲
╞ suspending╞ A SUSPEND TI is pending at S62CP.↲
↲
┆a1┆┆b0┆5.2.2╞ The TU State Change LCP Event↲
↲
╞ ┆84┆This LCP event indicates a state change in the TU.↲
↲
╞ Parameters:↲
╞ TU description╞ ┆84┆contains among others, the new state.↲
↲
╞ old state╞ ╞ ┆84┆the state from which the transition was made.↲
↲
╞ result╞ ╞ ┆84┆normally 0, but if an ACTIVATE TI or an ↓
┆19┆┆9d┆┄┄REDEFINE TI was answered by S62CP with a ↓
┆19┆┆9d┆┄┄result code<>ok (an unsuccess full activation ↓
┆19┆┆9d┆┄┄or redefining), this result code is delivered ↓
┆19┆┆9d┆┄┄in result.↲
↲
╞ ┆84┆This event is not generated by all state transitions, however, but ↓
┆19┆┆89┆┄┄only those who enter the states idle, active, suspended or dis┄↓
┆19┆┆89┆┄┄abled.↲
↲
╞ ┆84┆Note the following transitions: idle ->idle (an unsuccessful acti┄↓
┆19┆┆89┆┄┄vation), active->active (redefinition which could be done at once) ↓
┆19┆┆89┆┄┄and disabled->disabled (new REQ.DISABLE).↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆5.2.3╞ The TU Protocol Error LCP Event↲
↲
╞ ┆84┆This informs about a protocol error in the communication with DS ↓
┆19┆┆89┆┄┄concerning TU's.↲
↲
╞ parameters:↲
╞ TU description╞ ┆84┆contains among others the state in which the ↓
┆19┆┆9d┆┄┄error occurred.↲
↲
╞ primitive╞ ╞ ┆84┆two bytes, containg header byte and kind for ↓
┆19┆┆9d┆┄┄the primitive in question.↲
↲
╞ cause╞ ╞ ┆84┆can be "illegal state", block length error or ↓
┆19┆┆9d┆┄┄"block format error".↲
↲
╞ ┆84┆This event is generated when a TU oriented primitive is received ↓
┆19┆┆89┆┄┄from DS in an illegal state or with a wrong format.↲
↲
╞ ┆84┆The definition of a TU oriented primitive is that both CU packet ↓
┆19┆┆89┆┄┄number and DS packet number are zero, and the primitive is not ↓
┆19┆┆89┆┄┄RESP.RESERVE.↲
↲
╞ ┆84┆A REPLY NOTOK has been sent for this TU to TTXSI (and thereby to ↓
┆19┆┆89┆┄┄the involved DS).↲
↲
↲
┆a1┆┆b0┆5.2.4╞ The TU Overview LCP Sense↲
↲
╞ ┆84┆This sense operation gives an overview of one or more, possibly ↓
┆19┆┆89┆┄┄all, TU's in the DH.↲
↲
╞ ┆a1┆sense request↲
╞ parameters:↲
╞ first╞ ╞ ┆84┆The CU TU number for the first TU which should ↓
┆19┆┆9d┆┄┄be sensed.↲
↲
╞ number╞ ╞ ┆84┆The number of TU's which should be sensed.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆All TU's with a CU TU number inside the interval first . . . ↓
┆19┆┆89┆┄┄first+ number - 1 is requested sensed. number = 1 is a sense of ↓
┆19┆┆89┆┄┄one specific entry in the DS TU table. first = 1 and number = ↓
┆19┆┆89┆┄┄something big is an attempt to see all TU's.↲
↲
┆0e┆↓
╞ ┆a1┆sense answer↲
╞ parameters:↲
╞ first╞ ╞ unchanged↲
┆0f┆↓
↲
╞ act number╞ ┆84┆the number of TU's actually sensed.↲
╞ ╞ ╞ ┆84┆The size of an NCP buffer limits how many ↓
┆19┆┆9d┆┄┄entries, which can be delivered.↲
↲
╞ rest╞ ╞ ┆84┆the number of TU's inside the requested ↓
┆19┆┆9d┆┄┄interval, which has not been sensed.↲
↲
╞ entries╞ ╞ ┆84┆the TU descriptions for the sensed TU's. ↓
┆19┆┆9d┆┄┄However, TU's with TU state = idle is not ↓
┆19┆┆9d┆┄┄shown, so "entries" can be empty. actnumber ↓
┆19┆┆9d┆┄┄and rest include these entries too, however.↲
↲
╞ ┆84┆Note that a new TU overview operation with first = old first + act ↓
┆19┆┆89┆┄┄number and number = rest is a request for the rest of the entries ↓
┆19┆┆89┆┄┄inside the interval.↲
↲
↲
┆a1┆┆b0┆5.2.5╞ The Search TU LCP Sense↲
↲
╞ ┆84┆This operation is a search for a TU with a given identification.↲
↲
╞ ┆a1┆sense request↲
╞ parameters:↲
↲
╞ TI╞ : ┆84┆the terminal identification of the requested TU.↲
↲
╞ ┆a1┆sense answer↲
↲
╞ entry╞ : ┆84┆If found, this contains the TU description.↲
↲
↲
┆8c┆┆83┆┆e0┆↓
┆0e┆↓
┆a1┆┆b0┆5.3╞ Packet Oriented LCP Operations↲
↲
↲
┆a1┆┆b0┆5.3.1╞ Content of a Packet Description↲
↲
╞ ┆84┆In all packet oriented LCP operations a ┆a1┆packet description┆e1┆ is ↓
┆19┆┆89┆┄┄delivered, which is a copy of the most important fields in the ↓
┆19┆┆89┆┄┄packet description in DH.↲
┆0f┆↓
↲
╞ ┆84┆Inside the packet description is a ┆a1┆document description┆e1┆. It cor┄↓
┆19┆┆89┆┄┄responds to the document description communicated to and from DS ↓
┆19┆┆89┆┄┄with the primitives IND.READ and IND.WRITE.↲
↲
╞ The content is:↲
↲
╞ document number:╞ ┆84┆an identification of the document file at DS.↲
↲
╞ calling ti,↲
╞ called ti,↲
╞ date and time,↲
╞ additional sess ref number↲
╞ document ref number:┆84┆These 5 fields are the S62CP identification of ↓
┆19┆┆9d┆┄┄the document. Will only be fully defined when ↓
┆19┆┆9d┆┄┄document transfer is started, otherwise some ↓
┆19┆┆9d┆┄┄of all the fields will have a "nil" con┄tent.↲
↲
╞ checkpoint number:╞ ┆84┆For source packets the number of the last ↓
┆19┆┆9d┆┄┄acknowledged checkpoint, i.e. the number of ↓
┆19┆┆9d┆┄┄pages which for sure are stored at the ↓
┆19┆┆9d┆┄┄receiver.↲
↲
╞ ╞ ╞ ┆84┆For sink packets the number of the checkpoint ↓
┆19┆┆9d┆┄┄acknowledged from the DS, i.e. the number of ↓
┆19┆┆9d┆┄┄pages which certainly stored on this side. ↲
╞ ╞ ╞ ┆84┆Note that the corresponding acknowledge must ↓
┆19┆┆9d┆┄┄only has been sent to the remote party if ↓
┆19┆┆9d┆┄┄outstanding writes (see below) are zero.↲
↲
┆8c┆┆83┆┆c8┆↓
╞ continuation:╞ ┆84┆A boolean. If true this part of the document ↓
┆19┆┆9d┆┄┄was started with a CDC and linking with the ↓
┆19┆┆9d┆┄┄first part of the document could not be per┄↓
┆19┆┆9d┆┄┄formed. Used only by receival.↲
↲
╞ finished:╞ ╞ ┆84┆A boolean, indicating if the document transfer ↓
┆19┆┆9d┆┄┄has been terminated.↲
↲
╞ no of pages:╞ ┆84┆Only meaningful for source packets. Contains ↓
┆19┆┆9d┆┄┄the number of pages in the document not ac┄↓
┆19┆┆9d┆┄┄knowledged by the receiver. This field decides ↓
┆19┆┆9d┆┄┄the packet class.↲
↲
╞ ┆84┆The content of the packet description is then↲
↲
╞ CU TU number:╞ ┆84┆Identifies the TU to which the packet belongs.↲
↲
╞ DS packet number,↲
╞ CU packet number:╞ ┆84┆Identification of the packet. The CU number is ↓
┆19┆┆9d┆┄┄the index for the packet in the DH packet ↓
┆19┆┆9d┆┄┄table.↲
↲
╞ DS packet state:╞ ┆84┆The packet state transferred to DS in an ↓
┆19┆┆9d┆┄┄IND.UPDATE, see chapter 7.↲
↲
╞ DH packet state:╞ ┆84┆The state for the packet in DH. The possible ↓
┆19┆┆9d┆┄┄states are described in chapter 6. They can be ↓
┆19┆┆9d┆┄┄regarded as a refinement of the DS packet ↓
┆19┆┆9d┆┄┄state.↲
↲
╞ submit switch╞ ┆84┆= true if a REQ.SUBMIT has been received and ↓
┆19┆┆9d┆┄┄not answered yet by CONF.SUBMIT.↲
↲
╞ regret switch╞ ┆84┆= true if a REQ.REGRET has been received and ↓
┆19┆┆9d┆┄┄not answered by CONF.REGRET.↲
↲
╞ abort switch╞ ┆84┆= true is a REQ.ABORT has been received and ↓
┆19┆┆9d┆┄┄not answered by CONF.ABORT.↲
↲
┆8c┆┆83┆┆d4┆↓
╞ service:╞ ╞ TTX or TLX.↲
↲
╞ options:┆84┆╞ ╞ ┆84┆An 8 bit integer, the corresponding parameter ↓
┆19┆┆9d┆┄┄from REQ.SUBMIT or REQ.REGRET. Indicates f.ex. ↓
┆19┆┆9d┆┄┄whether charge is requested or not.↲
╞ ╞ ╞ ┆84┆This parameter is zero for sink packets.↲
↲
╞ priority:╞ ╞ ┆84┆0 or 1, the priority for the packet.↲
↲
╞ addressee TI:╞ ┆84┆For source packets the terminal identification ↓
┆19┆┆9d┆┄┄used to address the remote terminal.↲
↲
╞ ╞ ╞ ┆84┆For sink packets the transport address used by ↓
┆19┆┆9d┆┄┄the calling terminal (part 4 is missing).↲
↲
╞ cur doc dcr:╞ ┆84┆Current document description, see above.↲
↲
╞ doc seq no:╞ ┆84┆Sequence number inside the packet for the ↓
┆19┆┆9d┆┄┄current document description.↲
↲
╞ outstanding writes:╞ ┆84┆Indicates the number of IND.WRITE sent for ↓
┆19┆┆9d┆┄┄this packet and not answered by RESP.WRITE ↓
┆19┆┆9d┆┄┄yet.↲
↲
╞ write requested:╞ ┆84┆= true if an IND.WRITE has not been sent with ↓
┆19┆┆9d┆┄┄the current document description yet (it has ↓
┆19┆┆9d┆┄┄been updated by DH). This will be due to buf┄↓
┆19┆┆9d┆┄┄fer shortage in DH.↲
╞ ╞ ╞ ┆84┆cleared when a buffer becomes avaible.↲
↲
╞ missing writes:╞ ┆84┆Number of times the following has occured:↲
╞ ╞ ╞ ┆84┆the document description has been updated, and ↓
┆19┆┆9d┆┄┄write requested is already true.↲
┆8c┆┆83┆┆8c┆↓
┆0e┆↓
╞ ╞ ╞ ┆84┆It is set to zero, however, when the following ↓
┆19┆┆9d┆┄┄happens:↲
╞ ╞ ╞ - ┆84┆a RESP.WRITE is received which makes out┄↓
┆19┆┆a0┆┄┄standing writes zero↲
╞ ╞ ╞ and↲
╞ ╞ ╞ - ┆84┆write requested is false.↲
┆0f┆↓
╞ ╞ ╞ ┆84┆When this happens it is assured that the docu┄↓
┆19┆┆9d┆┄┄ment description in DH and DS are the same. ↓
┆19┆┆9d┆┄┄Otherwise it tells (together with outstanding ↓
┆19┆┆9d┆┄┄writes) how much they are out of track.↲
↲
╞ DH close pending:╞ ┆84┆= true if a DH stream close has been sent on ↓
┆19┆┆9d┆┄┄the docu┄ment stream and the answer has not yet ↓
┆19┆┆9d┆┄┄been received.↲
↲
╞ TTXSI close pending:┆84┆= true if a TTXSI stream close for this packet ↓
┆19┆┆9d┆┄┄is pending at DH.↲
↲
╞ connect sess:╞ ┆84┆If a session is connected to the packet this ↓
┆19┆┆9d┆┄┄field contains the session index for this ses┄↓
┆19┆┆9d┆┄┄sion. If no such session exists this field is ↓
┆19┆┆9d┆┄┄zero.↲
↲
╞ user inf:╞ ╞ ┆84┆Contains the user inf field delivered to DS in ↓
┆19┆┆9d┆┄┄an IND.UPDATE.↲
↲
╞ ┆84┆Concerning the format of the last field, see chapter 7.↲
↲
↲
┆a1┆┆b0┆5.3.2╞ The Packet State Change LCP Event↲
↲
╞ ┆84┆This event indicates a change in DS packet state.↲
↲
╞ Parameters:↲
╞ cur dcr:╞ ╞ ┆84┆The packet description.↲
↲
╞ old state:╞ ┆84┆The DS state from which the transition was ↓
┆19┆┆9d┆┄┄made.↲
↲
┆8c┆┆83┆┆d4┆↓
╞ ┆84┆This event is generated at the same time as an IND.UPDATE with a ↓
┆19┆┆89┆┄┄DS state is generated against DS.↲
↲
↲
┆a1┆┆b0┆5.3.3╞ The Packet Protocol Error LCP Event↲
↲
╞ ┆84┆This informs about a protocol error in the communication with DS ↓
┆19┆┆89┆┄┄concerning packets.↲
↲
╞ Parameters:↲
╞ packet description:╞ ┆84┆Contains among others the DH packet state in ↓
┆19┆┆9d┆┄┄which the error occured.↲
↲
╞ primitive:╞ ┆84┆Two bytes, containing header byte and kind for ↓
┆19┆┆9d┆┄┄the primitive in question.↲
↲
╞ cause:╞ ╞ ┆84┆Can be "illegal state" or "block format ↓
┆19┆┆9d┆┄┄error".↲
↲
╞ ┆84┆This event is generated when a packet oriented DS primitive is ↓
┆19┆┆89┆┄┄received in an illegal DH state, or the format is wrong.↲
↲
╞ ┆84┆Note that "illegal state" is also indicated when a RESP.WRITE is ↓
┆19┆┆89┆┄┄received and outstanding write = 0, or a RESP.READ when out┄↓
┆19┆┆89┆┄┄standing read = false.↲
↲
╞ ┆84┆The definition of a packet oriented primitive is that CU packet ↓
┆19┆┆89┆┄┄number and DS packet number both are not zero. If these parameters ↓
┆19┆┆89┆┄┄define a not existing packet a pseudo packet description is given ↓
┆19┆┆89┆┄┄in the event with DH packet state = packet idle and DS packet ↓
┆19┆┆89┆┄┄state = 0.↲
↲
╞ ┆84┆A REPLY NOTOK has been sent for the TU to which the packet be┄↓
┆19┆┆89┆┄┄longs.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆5.3.4╞ The Packet Overview LCP Sense↲
↲
╞ ┆84┆This sense operation gives an overview of one or more, possibly ↓
┆19┆┆89┆┄┄all, packets in the DH.↲
↲
╞ ┆a1┆sense request↲
╞ parameters↲
╞ first, number↲
↲
╞ ┆a1┆sense answer↲
╞ parameters↲
╞ first, act number, rest, entries↲
↲
╞ ┆84┆See section 5.2.4, TU overview, but read CU packet number instead ↓
┆19┆┆89┆┄┄of CU TU number, packets instead of TU's, and packet description ↓
┆19┆┆89┆┄┄instead of TU description.↲
↲
↲
┆0e┆↓
┆a1┆┆b0┆5.4╞ Session Oriented LCP Operations↲
↲
┆84┆↲
┆a1┆┆b0┆5.4.1╞ Content of a Session Descriptor↲
↲
╞ ┆84┆In all session oriented LCP operations a ┆a1┆session descriptor┆e1┆ is ↓
┆19┆┆89┆┄┄delivered which is a copy of the most important fields in the cor┄↓
┆19┆┆89┆┄┄responding session descriptor in DH.↲
┆0f┆↓
↲
╞ The fields are:↲
↲
╞ CU TU number:╞ ┆84┆The TU to which the session belongs.↲
↲
╞ u_sess_ref:╞ ┆84┆┆84┆The index in the DH session table.↲
↲
╞ s_sess_ref:╞ ┆84┆The S62CP identification of the session.↲
↲
╞ sess state:╞ ┆84┆The state of the session, see section 6.3.↲
↲
╞ caller:╞ ╞ ┆84┆= true if the session was initiated on this ↓
┆19┆┆9d┆┄┄side.↲
↲
┆8c┆┆83┆┆e0┆↓
╞ addresse_TI:╞ ┆84┆If caller = true, the corresponding parameter ↓
┆19┆┆9d┆┄┄from SESS START REQ.↲
╞ ╞ ╞ ┆84┆If caller = false, the addressee_ta parameter ↓
┆19┆┆9d┆┄┄from SESS START IND.↲
↲
╞ charge inf req:╞ ┆84┆If caller = true the charge_inf_req parameter. ↓
┆19┆┆9d┆┄┄Otherwise false.↲
↲
╞ service:╞ ╞ ┆84┆The service for the last packet which used the ↓
┆19┆┆9d┆┄┄session.↲
↲
╞ called_ti,↲
╞ calling_ti,↲
╞ add_s_ref:╞ ┆84┆Used to construct document identifications for ↓
┆19┆┆9d┆┄┄documents using this session.↲
↲
╞ res_no:╞ ╞ ┆84┆If a reservation has been made for this ses┄↓
┆19┆┆9d┆┄┄sion, this contains the DS Mem. Res. number ↓
┆19┆┆9d┆┄┄(the CU Mem. Res. number will be the ↓
┆19┆┆9d┆┄┄u_sess_ref value).↲
╞ ╞ ╞ Otherwise = 0.↲
↲
╞ conn_packet:╞ ┆84┆If a packet is connected to the session this ↓
┆19┆┆9d┆┄┄parameter contains the CU packet number. ↓
┆19┆┆9d┆┄┄Otherwise it is zero.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆5.4.2╞ The Reservation LCP Event↲
↲
╞ ┆84┆This event indicates that a IND.RESERVE for this session has been ↓
┆19┆┆89┆┄┄answered by a RESP.RESERVE.↲
↲
╞ ┆84┆The memory pool indicated by res_no can be used for document re┄↓
┆19┆┆89┆┄┄ceived on this session.↲
╞ Parameters:↲
╞ session description:┆84┆Contains, among other, the res_no.↲
↲
╞ result:╞ ╞ ok, busy or failed.↲
╞ size:╞ ╞ ┆84┆The amount of memory actually reserved.↲
↲
↲
┆a1┆┆b0┆5.4.3╞ The Release LCP Event↲
↲
╞ ┆84┆This event indicates that an IND.RELEASE has been sent for a ↓
┆19┆┆89┆┄┄memory pool reserved on behalf of this session.↲
↲
╞ Parameters:↲
╞ session descriptor.↲
↲
↲
┆b0┆┆a1┆5.4.4╞ Reservation Protocol Error.↲
↲
╞ ┆84┆Occurs when a RESP.RES has been received in an illegal state or ↓
┆19┆┆89┆┄┄with an illegal content.↲
↲
╞ parameters:↲
╞ session descriptor↲
╞ cause╞ ╞ "illegal state" or "block format error"↲
↲
╞ ┆84┆If the CU mem. Res. number refers to a non existing session de┄┄s┄↓
┆19┆┆89┆┄┄cription, a pseudo description is given with sess state=session ↓
┆19┆┆89┆┄┄idle.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆a1┆┆b0┆5.4.5╞ The Session Overview LCP Sense↲
↲
╞ ┆84┆This sense operation gives an overview of one or more, possible ↓
┆19┆┆89┆┄┄all, sessions in the DH.↲
↲
╞ ┆a1┆sense request↲
╞ parameters:↲
╞ first, number↲
↲
╞ ┆a1┆sense answer↲
╞ parameters:↲
╞ first, act number, rest, entries↲
↲
╞ ┆84┆See section 5.4.2, but read u_sess_ref instead of CU TU number, ↓
┆19┆┆89┆┄┄sessions instead of TU's, and session description instead of TU ↓
┆19┆┆89┆┄┄description.↲
↲
↲
┆1a┆┆1a┆th the ↓
┆19┆┆9d┆┄┄first part of