home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1993 July / Disc.iso / ccitt / 1988 / troff / 6_9_03.tro < prev    next >
Encoding:
Text File  |  1991-12-13  |  84.3 KB  |  3,668 lines
  1. .rs
  2. .\" Troff code generated by TPS Convert from ITU Original Files
  3. .\"                 Not Copyright ( c) 1991 
  4. .\"
  5. .\" Assumes tbl, eqn, MS macros, and lots of luck.
  6. .TA 1c 2c 3c 4c 5c 6c 7c 8c
  7. .ds CH
  8. .ds CF
  9. .EQ
  10. delim @@
  11. .EN
  12. .nr LL 40.5P
  13. .nr ll 40.5P
  14. .nr HM 3P
  15. .nr FM 6P
  16. .nr PO 4P
  17. .nr PD 9p
  18. .po 4P
  19.  
  20. .rs
  21. \v | 5i'
  22. .sp 2P
  23. .LP
  24. \fBRecommendation\ Q.775\fR 
  25. .RT
  26. .sp 2P
  27. .sp 1P
  28. .ce 1000
  29. \fBGUIDELINES\ FOR\ USING\ TRANSACTION\ CAPABILITIES\fR 
  30. .EF '%    Fascicle\ VI.9\ \(em\ Rec.\ Q.775''
  31. .OF '''Fascicle\ VI.9\ \(em\ Rec.\ Q.775    %'
  32. .ce 0
  33. .sp 1P
  34. .ce 1000
  35. \fR \fI(Melbourne, 1988)\fR 
  36. .sp 9p
  37. .RT
  38. .ce 0
  39. .sp 1P
  40. .LP
  41. \fB1\fR     \fBIntroduction\fR 
  42. .sp 1P
  43. .RT
  44. .sp 1P
  45. .LP
  46. 1.1
  47.     \fIGeneral\fR 
  48. .sp 9p
  49. .RT
  50. .PP
  51. The purpose of this Recommendation is to provide guidelines to
  52. potential users of Transaction Capabilities (TC\(hyusers). The examples 
  53. given are illustrations only; they indicate how an application may use 
  54. TCAP, not how TCAP must be used in all cases. The technical basis of this 
  55. document are 
  56. Recommendations\ Q.771 to\ Q.774; in case of misalignment, these should be
  57. considered as the primary reference.
  58. .PP
  59. The main purpose of TCAP is to provide support for interactive
  60. applications in a distributed environment. TCAP is based on
  61. Recommendations\ X.219 and\ X.229 (ROSE) enhanced as necessary to provide the
  62. services needed by TC\(hyusers. Interactions between distributed application
  63. entities are modelled by Operations. An operation is invoked by an
  64. (originating) entity: the other (destination) entity attempts to execute the
  65. operation and possibly returns the outcome of this attempt.
  66. .PP
  67. The semantics of an operation (represented by its name and parameters) 
  68. is not relevant to TCAP; TCAP provides facilities which are independent 
  69. of any particular operation. The TC\(hyuser, when defining an application, 
  70. must:
  71. .RT
  72. .LP
  73.     1)
  74.     select operations;
  75. .LP
  76.     2)
  77.     select TCAP facilities to support these operations. Such
  78. facilities include the handling of individual operations, and
  79. the ability to have a number of related operations attached to
  80. an association between TC\(hyusers, called a dialogue;
  81. .LP
  82.     3)
  83.     define the application script.
  84. .PP
  85. This Recommendation describes the selection process of defining
  86. and using operations. The operations appearing hereafter are fictitious, and
  87. are taken for illustration purposes only. Also described are the facilities
  88. offered by TCAP for handling one or a sequence of operations in a dialogue. 
  89. The definition of specific sequences of operations belongs to the application 
  90. protocol definition and is beyond the scope of this Recommendation; however,
  91. Chapter\ 4 gives a brief indication of what information an application
  92. specification should contain.
  93. .PP
  94. TCAP services are made accessible to TC\(hyusers via primitives; these
  95. primitives model the interface between TCAP and its users, but do not constrain 
  96. any implementation of this interface. 
  97. .RT
  98. .sp 1P
  99. .LP
  100. 1.2
  101.     \fIEnvironment\fR 
  102. .sp 9p
  103. .RT
  104. .PP
  105. TCAP defines the end\(hyto\(hyend protocol between TC\(hyusers which may 
  106. be located in a Signalling System No.\ 7 network, and/or another network 
  107. supporting TCAP protocols. 
  108. .PP
  109. Two broad categories of users have been considered (see
  110. Recommendation\ Q.771, \(sc\ 1.3.2). Only the first category is considered 
  111. here, 
  112. i.e.\ those which are real\(hytime sensitive users, and do not need to exchange
  113. large amounts of data. It is considered that for these users, protocols 
  114. defined for OSI layers\ 4 to\ 6 in the X\ series of Recommendations would 
  115. result in 
  116. excessive overheads and hence are not used. A basic service has been specified, 
  117. using a connectionless network service approach. Other categories of users 
  118. might require connection\(hyoriented network and higher layer services.
  119. .PP
  120. As a result, TCAP cannot support all kinds of applications, and a
  121. number of applications will still require more elaborate services such as
  122. specified in the X\ series of Recommendations. Besides indicating what 
  123. TCAP can do, this Recommendation indicates what the connectionless approach 
  124. cannot do, in order to help the application designer choose how to support 
  125. an 
  126. application.
  127. .RT
  128. .sp 2P
  129. .LP
  130. \fB2\fR     \fBOperations\fR 
  131. .sp 1P
  132. .RT
  133. .sp 1P
  134. .LP
  135. 2.1
  136.     \fIDefinition\fR 
  137. .sp 9p
  138. .RT
  139. .PP
  140. An operation is invoked by an originating TC\(hyuser to request a
  141. destination TC\(hyuser to perform a given action.
  142. .PP
  143. A class is attached to an operation. This indicates whether either a successful 
  144. outcome (result), or an unsuccessful outcome (error), or both, or 
  145. none have to be reported by the destination. The outcome is reported in a
  146. result.
  147. .bp
  148. .PP
  149. As well as the class, the definition of the operation includes a timer 
  150. value indicating when the operation should be completed. This value is 
  151. not 
  152. indicated to the remote TC\(hyuser; it is assumed that the application at both
  153. ends has a common understanding of the operations in use.
  154. .PP
  155. An \fBoperation\fR is defined by:
  156. .RT
  157. .LP
  158.     \(em
  159.      its operation code and the type of any parameters associated with the 
  160. operation request; 
  161. .LP
  162.     \(em
  163.     its class;
  164. .LP
  165.     \(em
  166.      if the class requires report of success, the possible results corresponding 
  167. to successful executions are defined by a list of parameters; 
  168. .LP
  169.     \(em
  170.      if the class requires report of failure, the possible results corresponding 
  171. to situations where the operation could not be executed 
  172. completely by the remote TC\(hyuser. Each such situation is identified by a
  173. specific error cause; the list of these error causes is part of the operation 
  174. definition. Diagnostic information can be added to the error cause: if 
  175. present, it is part of the definition; 
  176. .LP
  177.     \(em
  178.      the list of possible linked operations, if replies consisting of linked 
  179. operations are allowed for this operation. Linked operations have to be 
  180. described separately; 
  181. .LP
  182.     \(em
  183.      a timer value indicating the interval by which the operation has to be 
  184. completed. This timer value is used to manage the component ID 
  185. associated with the operation invocation.
  186. .sp 2P
  187. .LP
  188. 2.2
  189.     \fIExamples\fR 
  190. .sp 1P
  191. .RT
  192. .sp 1P
  193. .LP
  194. 2.2.1
  195.     \fISimple operations\fR 
  196. .sp 9p
  197. .RT
  198. .PP
  199. \fINote\fR \ \(em\ The operation invocation should fit into one message, 
  200. and so should a report of unsuccessful outcome. Reports of success may 
  201. be segmented using Return Result\(hyNot last and Return Result\(hyLast. 
  202. .RT
  203. .sp 1P
  204. .LP
  205.     \fIClass 1 (both success and failure reported):\fR 
  206. .sp 9p
  207. .RT
  208. .PP
  209. Translate a freephone number into a called subscriber number;
  210. return the called number if the translation can be performed, otherwise
  211. indicate why it cannot; time allocated: 2\ seconds.
  212. .PP
  213. No reply being received when the timer expires indicates an abnormal situation 
  214. (e.g.\ the operation invocation may have been lost): the local TC\(hyuser 
  215. is informed (operation cancel by TCAP). 
  216. .RT
  217. .sp 1P
  218. .LP
  219.     \fIClass 2 (only failure reported):\fR 
  220. .sp 9p
  221. .RT
  222. .PP
  223. Perform a routine test and send a reply only in case something went wrong; 
  224. time allocated: 1\ minute. 
  225. .PP
  226. In the case of a class 2 operation, the TC\(hyuser is informed if no
  227. result has been received when the timer expires. This is interpreted as a
  228. successful outcome, even if the invocation was lost. This aspect should be
  229. considered when selecting class\ 2.
  230. .RT
  231. .sp 1P
  232. .LP
  233.     \fIClass 3 (only success reported):\fR 
  234. .sp 9p
  235. .RT
  236. .PP
  237. Perform a test: this corresponds to a pessimistic view, where
  238. failure is considered as the default option, not requiring any reply.
  239. .PP
  240. Timer expiry is indicated to the TC\(hyuser: this should be interpreted 
  241. by the TC\(hyuser as a failure of the operation (but is considered normal 
  242. by TC, which considers that the operation has terminated). This aspect 
  243. should be 
  244. considered when selecting class\ 3.
  245. .RT
  246. .sp 1P
  247. .LP
  248.     \fIClass 4 (neither success, nor failure reported):\fR 
  249. .sp 9p
  250. .RT
  251. .PP
  252. Send a warning, without expecting a reply or acknowledgement of any kind.
  253. .PP
  254. In this case, a result never arises from the invocation of the
  255. operation. The TC\(hyuser relies upon TCAP and the network to deliver the
  256. invocation. Notification of the timer expiry is a local matter.
  257. .PP
  258. The diagrams in Figure 1/Q.775 illustrate possible sequences of
  259. primitives as seen by the TC\(hyuser originating an operation.
  260. .bp
  261. .RT
  262. .LP
  263. .rs
  264. .sp 47P
  265. .ad r
  266. \fBFigure 1/Q.775, (N), p.\fR 
  267. .sp 1P
  268. .RT
  269. .ad b
  270. .RT
  271. .LP
  272. .bp
  273. .sp 1P
  274. .LP
  275.     \fIComparison with ROSE (Recommendation X.219) operation classes\fR :
  276. .sp 9p
  277. .RT
  278. .PP
  279. ROSE provides for five classes of operations: classes 2 to 5,
  280. called
  281. asynchronous classes, are identical to classes\ 1 to\ 4 of TCAP. ROSE's 
  282. class\ 1 is a synchronous class; it has no counterpart in TCAP, where full\(hyduplex 
  283. exchanges of components are considered. However, a TC\(hyuser can decide to
  284. operate in a synchronous manner (see \(sc\ 3.2.1).
  285. .RT
  286. .sp 2P
  287. .LP
  288. 2.2.2
  289.     \fIMore sophisticated operations\fR 
  290. .sp 1P
  291. .RT
  292. .sp 1P
  293. .LP
  294.     \fIOperations with segmented results\fR 
  295. .sp 9p
  296. .RT
  297. .PP
  298. A successfull result may be divided into several segments, each of which 
  299. is indicated to the originator of the operation by one primitive. This 
  300. facility, using the TC\(hyRESULT\(hyNL primitive, can be used by TC\(hyusers 
  301. to overcome the absence of segmentation in the underlying layers. The last 
  302. segment is 
  303. indicated by the 
  304. TC\(hyRESULT\(hyL primitive.
  305. .PP
  306. The report of an error cannot be segmented.
  307. .PP
  308. Apart from abnormal situations, responses are delivered to the remote TC\(hyuser 
  309. in the order in which they have been passed to TCAP by the sending 
  310. TC\(hyuser.
  311. .PP
  312. TC cannot identify a specific segment in the case of a segmented
  313. result.
  314. .PP
  315. Example E1: An operation requests the execution of a test. The result of 
  316. a correct execution is segmented in three parts\ P1, P2 and\ P3 to be returned 
  317. to the originator. 
  318. .PP
  319. A possible primitive sequence for example E1 is given in
  320. Table\ 1/Q.775
  321. .RT
  322. .ce
  323. \fBH.T. [T1.775]\fR 
  324. .ce
  325. TABLE\ 1/Q.775
  326. .ps 9
  327. .vs 11
  328. .nr VS 11
  329. .nr PS 9
  330. .TS
  331. center box;
  332. cw(78p) | cw(78p) .
  333. TC USER A    TC USER B
  334. _
  335. .T&
  336. lw(78p) | lw(78p) .
  337.  {
  338. TC\(hyINVOKE req
  339. (Test, Class = 1)
  340.  }     {
  341. .
  342. TC\(hyINVOKE ind
  343. (Test)
  344. TC\(hyRESULT\(hyNL req
  345. (P1)
  346.  }
  347. _
  348. .T&
  349. lw(78p) | lw(78p) .
  350. TC\(hyRESULT\(hyNL ind (P1)    . TC\(hyRESULT\(hyNL req (P2)
  351. _
  352. .T&
  353. lw(78p) | lw(78p) .
  354. TC\(hyRESULT\(hyNL ind (P2)    . TC\(hyRESULT\(hyL req (P3)
  355. _
  356. .T&
  357. lw(78p) | lw(78p) .
  358. TC\(hyRESULT\(hyL ind (P3)    
  359. _
  360. .TE
  361. .nr PS 9
  362. .RT
  363. .ad r
  364. \fBTableau 1/Q.775 [T1.775], p.\fR 
  365. .sp 1P
  366. .RT
  367. .ad b
  368. .RT
  369. .LP
  370. .bp
  371. .PP
  372. The diagram in Figure 2/Q.775 illustrates possible sequences of
  373. primitives seen by the originator of an operation (class\ 1) with segmented
  374. results.
  375. .LP
  376. .rs
  377. .sp 31P
  378. .ad r
  379. \fBFigure 2/Q.775, (N), p.\fR 
  380. .sp 1P
  381. .RT
  382. .ad b
  383. .RT
  384. .sp 1P
  385. .LP
  386.     \fILinked operations\fR 
  387. .sp 9p
  388. .RT
  389. .PP
  390. Another extension to the basic operation scheme is the ability to link 
  391. an operation invocation to another operation invocation. 
  392. .PP
  393. Typically, this facility covers situations where the destination of
  394. the original (linked\(hyto) operation requires additional information in 
  395. order to process this operation: this is the case where menu facilities 
  396. are used (menu facilities allow a user to make a sequence of choices, each 
  397. being dependent on the previous ones). 
  398. .PP
  399. Example E2: The operation is the execution of a test with several
  400. options; before the test is executed, these options are offered for selection 
  401. to the test originator (TC\(hyuser\ A). Two operations are nested: operation\ 
  402. 1 is the test; operation\ 2 is the option selection. TC\(hyuser\ A first 
  403. responds to 
  404. operation\ 2 before TC\(hyuser\ B can perform the test with the indicated
  405. option(s).
  406. .bp
  407. .PP
  408. A possible primitive sequence for example E2 is given in
  409. Table\ 2/Q.775.
  410. .RT
  411. .ce
  412. \fBH.T. [T2.775]\fR 
  413. .ce
  414. TABLE\ 2/Q.775
  415. .ps 9
  416. .vs 11
  417. .nr VS 11
  418. .nr PS 9
  419. .TS
  420. center box;
  421. cw(80p) | cw(148p) .
  422. TC USER A    TC USER B
  423. _
  424. .T&
  425. lw(80p) | lw(74p) | lw(74p) .
  426.  {
  427. TC\(hyINVOKE req
  428. (Test, Class = 1)
  429.  }     {
  430. .
  431. TC\(hyINVOKE ind
  432. (Test)
  433. TC\(hyINVOKE req
  434. (Option\(hyselection, Class = 1)
  435.  }     {
  436. Operation 1 begin
  437. Operation 2 begin
  438.  }
  439. _
  440. .T&
  441. lw(80p) | lw(74p) | lw(74p) .
  442.  {
  443. TC\(hyINVOKE ind
  444. (Option\(hyselection)
  445. TC\(hyRESULT\(hyL req
  446. (Options)
  447.  }     {
  448. .
  449. TC\(hyRESULT\(hyL ind
  450. (Options)
  451. TC\(hyRESULT\(hyL req
  452. (Test\(hyresult)
  453.  }    . Operation 2 end
  454. _
  455. .T&
  456. lw(80p) | lw(74p) | lw(74p) .
  457.  {
  458. TC\(hyRESULT\(hyL ind
  459. (Test\(hyresult)
  460.  }        Operation 1 end
  461. _
  462. .TE
  463. .nr PS 9
  464. .RT
  465. .ad r
  466. \fBTableau 2/Q.775 [T2.775], p.\fR 
  467. .sp 1P
  468. .RT
  469. .ad b
  470. .RT
  471. .PP
  472. There is no limit to the number of operation invocations which may be linked 
  473. to a given operation invocation. 
  474. .PP
  475. Note that when an operation B is linked to another operation A, they do 
  476. not have to be nested. The only condition is that the invocation of\ B 
  477. should take place before the outcome of\ A is reported; however, operation\ 
  478. B does not have to terminate before operation\ A. 
  479. .RT
  480. .sp 2P
  481. .LP
  482. 2.3
  483.     \fIComponent\(hyrelated facilities offered to TC\(hyusers\fR 
  484. .sp 1P
  485. .RT
  486. .sp 1P
  487. .LP
  488. 2.3.1
  489.     \fIInvocation\fR 
  490. .sp 9p
  491. .RT
  492. .PP
  493. So far, operations have been considered from the static point of
  494. view. Invocation introduces a dynamic aspect: a specific invocation of an
  495. operation has to be differentiated from other possible concurrent invocations 
  496. of the same or of another operation. 
  497. .PP
  498. Each particular activation of an operation is identified by a
  499. component ID. This component ID must be non ambiguous. It is selected by the
  500. TC\(hyuser which originates the operation invocation, and passed to the
  501. destination TC\(hyuser, which will reflect it in its reply(ies): therefore it
  502. correlates the replies to an invocation, and the invocation itself.
  503. .PP
  504. The TC\(hyuser is free to assign any value to the component ID (index,
  505. address, . |  | ).
  506. .PP
  507. The component ID associated with an invocation becomes reusable when the 
  508. last or only segment of a result is received, or when certain abnormal 
  509. situations are indicated by TCAP; however, the value should not be reallocated 
  510. immediately for another operation activation, as immediate reallocation 
  511. would prevent the correct handling of some situations (see below). 
  512. .bp
  513. .PP
  514. The period during which a component ID is released, but cannot be
  515. reallocated, is called the freezing period.
  516. .PP
  517. As component IDs receive their value dynamically at the time the
  518. operation is invoked, their value cannot appear in the specification of the
  519. application protocols; rather, a \*Qlogical\*U value, to which a real value is
  520. substituted at execution time, should be indicated in order to identify an
  521. operation in a single flow.
  522. .PP
  523. Taking component IDs into consideration, the sequence of primitives
  524. for example E2 above becomes as shown in Table\ 3/Q.775.
  525. .RT
  526. .ce
  527. \fBH.T. [T3.775]\fR 
  528. .ce
  529. TABLE\ 3/Q.775
  530. .ps 9
  531. .vs 11
  532. .nr VS 11
  533. .nr PS 9
  534. .TS
  535. center box;
  536. cw(78p) | cw(78p) .
  537. TC USER A    TC USER B
  538. _
  539. .T&
  540. lw(78p) | lw(78p) .
  541.  {
  542. TC\(hyINVOKE req
  543. (1, Test, Class = 1)
  544.  }     {
  545. .
  546. TC\(hyINVOKE ind
  547. (1, Test)
  548. TC\(hyINVOKE req
  549. (2, 1, Option\(hyselection, Class = 1)
  550.  }
  551. _
  552. .T&
  553. lw(78p) | lw(78p) .
  554.  {
  555. TC\(hyINVOKE ind
  556. (2, 1, Option\(hyselection)
  557. TC\(hyRESULT\(hyL req
  558. (2, Options)
  559.  }     {
  560. .
  561. TC\(hyRESULT\(hyL ind
  562. (2, Options)
  563. TC\(hyRESULT\(hyL req
  564. (1, Test\(hyresult)
  565.  }
  566. _
  567. .T&
  568. lw(78p) | lw(78p) .
  569.  {
  570. TC\(hyRESULT\(hyL ind
  571. (1, Test\(hyresult)
  572.  }    
  573. _
  574. .TE
  575. .nr PS 9
  576. .RT
  577. .ad r
  578. \fBTableau 3/Q.775 [T3.775], p.\fR 
  579. .sp 1P
  580. .RT
  581. .ad b
  582. .RT
  583. .LP
  584. where the first parameter of a primitive indicates an invoke ID. When both
  585. parameters have to be present, the second one is the linked ID. This is 
  586. a pure notational convention. 
  587. .sp 1P
  588. .LP
  589. 2.3.2
  590.     \fICancel\fR \fI(by the TC\(hyuser)\fR 
  591. .sp 9p
  592. .RT
  593. .PP
  594. The TC\(hyuser requesting invocation of an operation may stop the
  595. activity associated with the corresponding component\ ID, for any reason it
  596. finds appropriate. However, cancel should in principle be reserved for 
  597. abnormal situations: the normal method for terminating an operation is 
  598. to receive a 
  599. result or to terminate on timer expiry.
  600. .PP
  601. Cancelling has local effect only: it does not prevent the remote
  602. TC\(hyuser from sending replies to a cancelled operation. When received, these
  603. replies will be rejected by TCAP, as illustrated in the following, which
  604. represents a sequence of primitives for the example\ E1 defined above, where
  605. TC\(hyuser\ A cancels the test after receiving the first segment of the
  606. result.
  607. .PP
  608. In Table 4/Q.775, part P2 is not received by TC\(hyuser\ A: TCAP detects 
  609. a reject situation before delivering it, and any attempt by TC\(hyuser\ 
  610. B to send 
  611. more replies is rejected at A's side.
  612. .bp
  613. .RT
  614. .ce
  615. \fBH.T. [T4.775]\fR 
  616. .ce
  617. TABLE\ 4/Q.775
  618. .ps 9
  619. .vs 11
  620. .nr VS 11
  621. .nr PS 9
  622. .TS
  623. center box;
  624. cw(78p) | cw(78p) .
  625. TC USER A    TC USER B
  626. _
  627. .T&
  628. lw(78p) | lw(78p) .
  629.  {
  630. TC\(hyINVOKE req
  631. (1, Test, Class = 1)
  632.  }     {
  633. .
  634. TC\(hyINVOKE ind
  635. (1, Test)
  636. TC\(hyRESULT\(hyNL req
  637. (1, P1)
  638.  }
  639. _
  640. .T&
  641. lw(78p) | lw(78p) .
  642.  {
  643. TC\(hyRESULT\(hyNL ind
  644. (1, P1)
  645. Cancel decision:
  646. TC\(hyCANCEL req
  647. (1)
  648. TC\(hyL\(hyREJECT ind
  649. (1, Problem Code)
  650. ....
  651.  }     {
  652. .
  653. TC\(hyRESULT\(hyNL req
  654. (1, P2)
  655. ....
  656.  }
  657. _
  658. .TE
  659. .nr PS 9
  660. .RT
  661. .ad r
  662. \fBTableau 4/Q.775 [T4.775], p.\fR 
  663. .sp 1P
  664. .RT
  665. .ad b
  666. .RT
  667. .LP
  668. .sp 3
  669. .sp 1P
  670. .LP
  671. 2.3.3
  672.     \fIReject\fR \fI(by the TC\(hyuser)\fR 
  673. .sp 9p
  674. .RT
  675. .PP
  676. A TC\(hyuser may decide to reject a component for any reason it finds appropriate, 
  677. e.g.\ application protocol error, parameter missing in an operation or 
  678. a reply,\ etc. 
  679. .PP
  680. TCAP covers a number of cases, identified by the list of Problem Codes 
  681. in Recommendation\ Q.773. In any of these cases, which correspond to situations 
  682. where an operation or a reply is not correctly formatted, the TC\(hyuser 
  683. may use the reject facility. Alternately, he may decide to return a failure 
  684. indication (error component), which allows more detailed error and diagnostic 
  685. information.
  686. .PP
  687. Reject of an operation invocation, or of a result, affect the whole
  688. operation: no more replies will be accepted for this invocation. Reject of a
  689. linked operation does not affect the linked\(hyto operation.
  690. .PP
  691. This is illustrated in Table\ 5/Q.775 where, in example E2, TC\(hyuser\ 
  692. A did not expect the option selection process (it may be an optional feature), 
  693. and rejects the operation with the Problem Code \*QUnexpected Linked Operation\*U. 
  694. TC\(hyuser\ B may then decide to execute the test assuming a default 
  695. option.
  696. .bp
  697. .RT
  698. .ce
  699. \fBH.T. [T5.775]\fR 
  700. .ce
  701. TABLE\ 5/Q.775
  702. .ps 9
  703. .vs 11
  704. .nr VS 11
  705. .nr PS 9
  706. .TS
  707. center box;
  708. cw(78p) | cw(78p) .
  709. TC USER A    TC USER B
  710. _
  711. .T&
  712. lw(78p) | lw(78p) .
  713.  {
  714. TC\(hyINVOKE req
  715. (1, Test, Class = 1)
  716.  }     {
  717. .
  718. TC\(hyINVOKE ind
  719. (1, Test)
  720. TC\(hyINVOKE req
  721. (2, 1, Option\(hyselection, Class = 1)
  722.  }
  723. _
  724. .T&
  725. lw(78p) | lw(78p) .
  726.  {
  727. TC\(hyINVOKE ind
  728. (2, 1, Option\(hyselection)
  729. TC\(hyU\(hyREJECT req
  730. (2, Problem Code)
  731.  }    
  732. _
  733. .T&
  734. lw(78p) | lw(78p) .
  735.      {
  736. TC\(hyU\(hyREJECT ind
  737. (2, Problem Code)
  738. TC\(hyRESULT\(hyL req
  739. (1, Test\(hyresult)
  740.  }
  741. _
  742. .T&
  743. lw(78p) | lw(78p) .
  744.  {
  745. TC\(hyRESULT\(hyL ind
  746. (1, Test\(hyresult)
  747.  }    
  748. _
  749. .TE
  750. .nr PS 9
  751. .RT
  752. .ad r
  753. \fBTableau 5/Q.775 [T5.775], p.\fR 
  754. .sp 1P
  755. .RT
  756. .ad b
  757. .RT
  758. .LP
  759. .sp 3
  760. .PP
  761. When an operation invocation is rejected, the TC\(hyuser may decide to 
  762. reinvoke it (e.g.\ the invoke component was corrupted); this would be a 
  763. new invocation (new Invoke ID). It may also decide to abort the dialogue. 
  764. A very 
  765. simple dialogue (a question and a response) may not define any recovery
  766. mechanisms, except when the operation is of critical importance (e.g.\ a
  767. database update).
  768. .sp 2P
  769. .LP
  770. 2.4
  771.     \fIComponent\(hyrelated abnormal situations\fR 
  772. .sp 1P
  773. .RT
  774. .sp 1P
  775. .LP
  776. 2.4.1
  777.     \fIComponent loss\fR 
  778. .sp 9p
  779. .RT
  780. .PP
  781. TCAP assumes a very low probability of message loss in the network; if 
  782. this probability is too high for an application, it should use the 
  783. connection\(hyoriented network service approach. If some protocol information
  784. needs an upgraded quality of service (e.g.\ charging information), the
  785. application should introduce its own mechanisms to obtain higher reliability
  786. for this information.
  787. .bp
  788. .RT
  789. .sp 1P
  790. .LP
  791.     \fILoss of an operation invocation\fR 
  792. .sp 9p
  793. .RT
  794. .PP
  795. The Table 6/Q.775 sequence illustrates the case, in example E1,
  796. where no response to the test is received before the time limit
  797. expires.
  798. .RT
  799. .ce
  800. \fBH.T. [T6.775]\fR 
  801. .ce
  802. TABLE\ 6/Q.775
  803. .ps 9
  804. .vs 11
  805. .nr VS 11
  806. .nr PS 9
  807. .TS
  808. center box;
  809. cw(78p) | cw(78p) .
  810. TC USER A    TC USER B
  811. _
  812. .T&
  813. lw(78p) | lw(78p) .
  814.  {
  815. TC\(hyINVOKE req
  816. (1, Test, Class = 1)
  817.  }    
  818. _
  819. .T&
  820. lw(78p) | lw(78p) .
  821.  {
  822. Time limit:
  823. TC\(hyL\(hyCANCEL ind
  824. (1)
  825.  }    
  826. _
  827. .TE
  828. .nr PS 9
  829. .RT
  830. .ad r
  831. \fBTableau 6/Q.775 [T6.775], p.\fR 
  832. .sp 1P
  833. .RT
  834. .ad b
  835. .RT
  836. .PP
  837. When a class 1 operation is lost, the TC\(hyuser is informed when the timer 
  838. asociated with the operation expires. When a class\ 1 operation with a 
  839. single result is lost, TCAP cannot indicate whether either the operation
  840. invocation, or the reply, was lost. If the application needs to discriminate
  841. between these two cases, it should do it in the application protocol
  842. (e.g.\ using the time\(hystamping or acknowledging the operation invocation 
  843. before replying to it). 
  844. .PP
  845. For a class 2 operation, loss will be considered as a success (whether 
  846. the invocation, or the failure report, was lost). This, considering the 
  847. probability of loss, may be acceptable for non critical operations
  848. (e.g.\ statistical measurements).
  849. .PP
  850. For a class 3 operation, loss is treated in the same way as operation failure, 
  851. whether the invocation, or the success report, has been lost. 
  852. .PP
  853. For a class 4 operation, loss will not be visible to TCAP.
  854. .RT
  855. .sp 1P
  856. .LP
  857.     \fILoss of a result\fR 
  858. .sp 9p
  859. .RT
  860. .LP
  861.     \(em
  862.     Loss of a non final result is never detected by TCAP.
  863. .LP
  864.     \(em
  865.     Loss of a final result will eventually be indicated to the
  866. TC\(hyuser when the time limit is reached, but cannot always be
  867. unambiguously interpreted as the loss of a reply; of no non final
  868. result has been received, it may be that the invocation was
  869. lost.
  870. .sp 1P
  871. .LP
  872.     \fILoss of a linked operation\fR 
  873. .sp 9p
  874. .RT
  875. .PP
  876. The loss of a linked operation has the same effect as the loss of a non\(hylinked 
  877. operation. It has no effect on the linked\(hyto operation. 
  878. .RT
  879. .sp 1P
  880. .LP
  881.     \fILoss of a reject component\fR 
  882. .sp 9p
  883. .RT
  884. .PP
  885. This case should be extremely infrequent, and no application should try 
  886. to recover from such a situation. If the lost reject concerns an operation 
  887. invocation, then when the operation timed out the TC\(hyuser which invoked 
  888. the 
  889. operation will consider that the invocation (or the reply) was lost, and 
  890. react accordingly; if it concerns a reply, the originator of the reply 
  891. will consider that it was correct: it will be up to the originator of the 
  892. operation to detect the loss. 
  893. .RT
  894. .sp 1P
  895. .LP
  896. 2.4.2
  897.     \fIComponent duplication\fR 
  898. .sp 9p
  899. .RT
  900. .PP
  901. As message duplication is very infrequent in the Signalling System No.\ 
  902. 7 network, scripts for No.\ 7 applications need not define sophisticated 
  903. scenarios in anticipation of such situations. However, any application 
  904. in which duplication would be unacceptable should either define its own 
  905. duplication 
  906. detection mechanism or use a connection\(hyoriented service.
  907. .bp
  908. .RT
  909. .sp 1P
  910. .LP
  911.     \fIDuplicate operation invocation\fR 
  912. .sp 9p
  913. .RT
  914. .PP
  915. When an operation invocation is duplicated (by the service
  916. provider), the destination TC\(hyuser (B) may, or may not, detect the
  917. duplication:
  918. .RT
  919. .LP
  920.     \(em
  921.      TC\(hyuser B detects the duplication: the best it can do in this case 
  922. is to ignore the duplicate; rejection could be interpreted by the remote 
  923. TC\(hyuser as rejection of the original invocation; 
  924. .LP
  925.     \(em
  926.     TC\(hyuser B does not detect the duplication: this may happen
  927. when there is a master\(hyslave relationship between\ A and\ B, and\ B 
  928. executes the operation with no knowledge of the context. 
  929. .PP
  930. Assuming the second case in exaple E1, a possible sequence could be as 
  931. given in Table\ 7/Q.775. 
  932. .ce
  933. \fBH.T. [T7.775]\fR 
  934. .ce
  935. TABLE\ 7/Q.775
  936. .ps 9
  937. .vs 11
  938. .nr VS 11
  939. .nr PS 9
  940. .TS
  941. center box;
  942. cw(80p) | cw(148p) .
  943. TC USER A    TC USER B
  944. _
  945. .T&
  946. lw(80p) | lw(74p) | lw(74p) .
  947.  {
  948. TC\(hyINVOKE req
  949. (1, Test, Class = 1)
  950. TC\(hyRESULT\(hyNL ind
  951. (1, P1)
  952. TC\(hyRESULT\(hyNL ind
  953. (1, P1)
  954. A detects an abnormal situation and rejects:
  955. TC\(hyU\(hyREJECT req
  956. (1, Problem Code)
  957. TC detects an abnormal situation and rejects P2:
  958. TC\(hyL\(hyREJECT ind
  959. (1, Problem Code)
  960.  }     {
  961. .
  962. TC\(hyINVOKE ind
  963. (1, Test)
  964. TC\(hyINVOKE ind
  965. (1, Test)
  966. TC\(hyRESULT\(hyNL req
  967. (1, P1)
  968. TC\(hyRESULT\(hyNL req
  969. (1, P1)
  970. TC\(hyRESULT\(hyNL req
  971. (1, P2)
  972. TC\(hyU\(hyREJECT ind
  973. (1, Problem Code)
  974.  }     {
  975. .
  976. Undetected duplication of invocation
  977.  }
  978. _
  979. .T&
  980. lw(80p) | lw(74p) | lw(74p) .
  981.      {
  982. TC\(hyR\(hyREJECT ind
  983. (1, Problem Code)
  984.  }    
  985. _
  986. .TE
  987. .nr PS 9
  988. .RT
  989. .ad r
  990. \fBTableau 7/Q.775 [T7.775], p.\fR 
  991. .sp 1P
  992. .RT
  993. .ad b
  994. .RT
  995. .LP
  996. .bp
  997. .PP
  998. In this sequence, TC\(hyuser B considers two independent test
  999. invocations, and responds to each of them. The first result P1 is accepted;
  1000. TC\(hyuser A detects that P1 is received a second time, and rejects it; this
  1001. terminates the operation, and causes result P2 to be rejected when received
  1002. (reject by TCAP). Therefore, both activities at B's side will terminate on
  1003. receipt of rejects.
  1004. .sp 1P
  1005. .LP
  1006.     \fIDuplicate non\(hyfinal result\fR 
  1007. .sp 9p
  1008. .RT
  1009. .PP
  1010. If a non\(hyfinal result is duplicated, TCAP cannot detect it, and
  1011. will deliver it twice to the TC\(hyuser. Detection of this situation is left to
  1012. the application.
  1013. .RT
  1014. .sp 1P
  1015. .LP
  1016.     \fIDuplicate final result\fR 
  1017. .sp 9p
  1018. .RT
  1019. .PP
  1020. If a final result is duplicated, TCAP can detect the situation: the second 
  1021. final result is considered as abnormal (the operation has been 
  1022. terminated by the first \*Qfinal\*U result), and TCAP rejects it.
  1023. .PP
  1024. Table 8/Q.775 shows a sequence for example E1 where the third segment of 
  1025. the result is duplicated (by the network). 
  1026. .RT
  1027. .ce
  1028. \fBH.T. [T8.775]\fR 
  1029. .ce
  1030. TABLE\ 8/Q.775
  1031. .ps 9
  1032. .vs 11
  1033. .nr VS 11
  1034. .nr PS 9
  1035. .TS
  1036. center box;
  1037. cw(78p) | cw(78p) .
  1038. TC USER A    TC USER B
  1039. _
  1040. .T&
  1041. lw(78p) | lw(78p) .
  1042.  {
  1043. TC\(hyINVOKE req
  1044. (1, Test, Class = 1)
  1045. TC\(hyRESULT\(hyNL ind
  1046. (1, P1)
  1047. TC\(hyRESULT\(hyNL ind
  1048. (1, P2)
  1049. TC\(hyRESULT\(hyL ind
  1050. (1, P3)
  1051. Duplication of P3:
  1052. TC\(hyL\(hyREJECT ind
  1053. (1, Problem Code)
  1054.  }     {
  1055. .
  1056. TC\(hyINVOKE ind
  1057. (1, Test)
  1058. TC\(hyRESULT\(hyNL req
  1059. (1, P1)
  1060. TC\(hyRESULT\(hyNL req
  1061. (1, P2)
  1062. TC\(hyRESULT\(hyL req
  1063. (1, P3)
  1064.  }
  1065. _
  1066. .T&
  1067. lw(78p) | lw(78p) .
  1068.      {
  1069. TC\(hyR\(hyREJECT ind
  1070. (1, Problem Code)
  1071.  }
  1072. _
  1073. .TE
  1074. .nr PS 9
  1075. .RT
  1076. .ad r
  1077. \fBTableau 8/Q.775 [T8.775], p.\fR 
  1078. .sp 1P
  1079. .RT
  1080. .ad b
  1081. .RT
  1082. .PP
  1083. Comment: Discarding of duplicates in all cases by TCAP would
  1084. probably appear as a nicer issue. However, it should be noted that:
  1085. .LP
  1086.     1)
  1087.      it would require another degree of complexity in TCAP, which contradicts 
  1088. the basic characteristics of TCAP in the 
  1089. connectionless approach;
  1090. .LP
  1091.     2)
  1092.     it corresponds to a situation which is
  1093. extremely infrequent, at least in the No.\ 7
  1094. network.
  1095. .PP
  1096. To cover these situations when required by an application, it
  1097. would be better to use a connection\(hyoriented network service approach, since
  1098. duplication could then be detected and handled at the lower layers.
  1099. .bp
  1100. .sp 1P
  1101. .LP
  1102. 2.4.3
  1103.     \fIComponent missequencing\fR 
  1104. .sp 9p
  1105. .RT
  1106. .PP
  1107. For TCAP, the order of segmented results is not relevant: if the
  1108. order is important to the TC\(hyuser, appropriate mechanisms should be 
  1109. defined in the application protocol (e.g.\ by introducing a numbering scheme 
  1110. to identify 
  1111. intermediate replies in a parameter of these replies, or by using a
  1112. connection\(hyoriented service).
  1113. .PP
  1114. Due to missequencing, a non final result may arive after a final
  1115. result: when this occurs the non final result is rejected by TCAP.
  1116. .PP
  1117. The sequence in Table\ 9/Q.775 illustrates what happens in example E1 when 
  1118. the last part of the result is received before the second one: both 
  1119. TC\(hyusers are informed.
  1120. .RT
  1121. .ce
  1122. \fBH.T. [T9.775]\fR 
  1123. .ce
  1124. TABLE\ 9/Q.775
  1125. .ps 9
  1126. .vs 11
  1127. .nr VS 11
  1128. .nr PS 9
  1129. .TS
  1130. center box;
  1131. cw(78p) | cw(78p) .
  1132. TC USER A    TC USER B
  1133. _
  1134. .T&
  1135. lw(78p) | lw(78p) .
  1136.  {
  1137. TC\(hyINVOKE req
  1138. (1, Test, Class = 1)
  1139.  }     {
  1140. .
  1141. TC\(hyINVOKE ind
  1142. (1, Test)
  1143. TC\(hyRESULT\(hyNL req
  1144. (1, P1)
  1145.  }
  1146. _
  1147. .T&
  1148. lw(78p) | lw(78p) .
  1149.  {
  1150. TC\(hyRESULT\(hyNL ind
  1151. (1, P1)
  1152. TC\(hyRESULT\(hyL ind
  1153. (1, P3)
  1154. Missequenced result:
  1155. reject
  1156. TC\(hyL\(hyREJECT ind
  1157. (1, Problem Code)
  1158.  }     {
  1159. .
  1160. TC\(hyRESULT\(hyNL req
  1161. (1, P2)
  1162. TC\(hyRESULT\(hyL req
  1163. (1, P3)
  1164.  }
  1165. _
  1166. .T&
  1167. lw(78p) | lw(78p) .
  1168.      {
  1169. TC\(hyR\(hyREJECT ind
  1170. (1, Problem Code)
  1171.  }
  1172. _
  1173. .TE
  1174. .nr PS 9
  1175. .RT
  1176. .ad r
  1177. \fBTableau 9/Q.775 [T9.775], p.\fR 
  1178. .sp 1P
  1179. .RT
  1180. .ad b
  1181. .RT
  1182. .PP
  1183. If a linked operation invocation is received after the final
  1184. result of the linked\(hyto operation (as a result of a missequencing), 
  1185. the linked operation is rejected. 
  1186. .PP
  1187. TCAP assumes a very low probability of missequencing; if the
  1188. supporting network is not satisfactory in this respect, the connection\(hyoriented 
  1189. network service approach should be considered. 
  1190. .RT
  1191. .sp 1P
  1192. .LP
  1193. 2.4.4
  1194.     \fIReject of a component by TCAP\fR 
  1195. .sp 9p
  1196. .RT
  1197. .PP
  1198. A general principle when TCAP receives a component (operation
  1199. invocation or reply) which is either not formatted correctly, or received 
  1200. out of context (e.g.\ a reply without a prior operation invocation), is 
  1201. to reject 
  1202. it, which means that:
  1203. .RT
  1204. .LP
  1205.     1)
  1206.     the destination of the faulty component is first informed of
  1207. the situation; TCAP provides whatever information is available
  1208. on the nature of the component being rejected
  1209. .LP
  1210.     2)
  1211.     in reaction to this, the TC\(hyuser may decide to abort,
  1212. continue, or end the dialogue. In the last two cases, when the
  1213. TC\(hyuser notifies TCAP of its decision, the peer TC\(hyuser is
  1214. informed of the reject.
  1215. .bp
  1216. .PP
  1217. Possible cases of reject by TCAP have been encountered in the
  1218. previous sections. Whenever the component\ ID is recognised, rejection 
  1219. by TCAP causes the termination of the operation: a possible recovery is 
  1220. a new 
  1221. invocation of the terminated operation. When the rejected component is not
  1222. identifiable, only the local TC\(hyuser is informed, and abort of the dialogue 
  1223. may be the appropriate reaction. 
  1224. .sp 1P
  1225. .LP
  1226. 2.4.5
  1227.     \fIOperation timer expiry\fR 
  1228. .sp 9p
  1229. .RT
  1230. .PP
  1231. When TCAP informs the TC\(hyuser of timer expiry (TC\(hyL\(hyCANCEL
  1232. indication), it indicates that no more information related to the operation
  1233. invocation (in particular, no reject) can be received. If the peer entity 
  1234. still sends information in relation with this invocation, this information 
  1235. will be 
  1236. discarded when received, provided that the component\ ID of the cancelled
  1237. operation has not been reallocated. Premature reallocation of component\ ID
  1238. values is normally avoided by correctly setting timer values: in order to
  1239. .PP
  1240. compensate for uncertainties in the amount of time required to send information 
  1241. from TC\(hyuser to another without accounting for the absolute worst case 
  1242. (which is also in general the most unlikely), an implementation\(hydependent 
  1243. mechanism 
  1244. avoiding premature reallocation of component IDs is required.
  1245. .PP
  1246. Timer expiry indication corresponds to an abnormal situation only in the 
  1247. case of a class\ 1 operation. The TC\(hyuser is then aware that either 
  1248. the 
  1249. invocation, or the reply, was lost. If no undesirable side effects arise,
  1250. another invocation of the same operation can take place after timer expiry.
  1251. This is illustrated by the sequence in Table\ 10/Q.775 for example\ E1.
  1252. .RT
  1253. .ce
  1254. \fBH.T. [T10.775]\fR 
  1255. .ce
  1256. TABLE\ 10/Q.775
  1257. .ps 9
  1258. .vs 11
  1259. .nr VS 11
  1260. .nr PS 9
  1261. .TS
  1262. center box;
  1263. cw(78p) | cw(78p) .
  1264. TC USER A    TC USER B
  1265. _
  1266. .T&
  1267. lw(78p) | lw(78p) .
  1268.  {
  1269. TC\(hyINVOKE req
  1270. (1, Test, Class = 1)
  1271.  }    . TC\(hyINVOKE ind (1, Test)
  1272. _
  1273. .T&
  1274. lw(78p) | lw(78p) .
  1275.  {
  1276. Timer expiry:
  1277. TC\(hyL\(hyCANCEL ind
  1278. (1)
  1279. TC\(hyINVOKE req
  1280. (2, Test, Class = 1)
  1281.  }    
  1282. _
  1283. .TE
  1284. .nr PS 9
  1285. .RT
  1286. .ad r
  1287. \fBTableau 10/Q.775 [T10.775], p.\fR 
  1288. .sp 1P
  1289. .RT
  1290. .ad b
  1291. .RT
  1292. .PP
  1293. Timer expiry for a class 2 operation indicates that no failure was received 
  1294. nor will be accepted for this invocation: it is a definite indication of 
  1295. success (for class\ 2). A parallel situation applied to class\ 3 in case 
  1296. of 
  1297. failure. The indication of timer expiry for a class\ 4 operation is a local
  1298. decision.
  1299. .sp 2P
  1300. .LP
  1301. \fB3\fR     \fBDialogues\fR 
  1302. .sp 1P
  1303. .RT
  1304. .PP
  1305. Whenever one of the operation handling primitives considered in \(sc\ 2 
  1306. is issued, a request is passed to TCAP, but nothing is sent to the remote 
  1307. TC\(hyuser until a primitive requesting transmission is issued. These primitives, 
  1308. and their relation with operation handling primitives, are considered 
  1309. now.
  1310. .bp
  1311. .RT
  1312. .sp 1P
  1313. .LP
  1314. 3.1
  1315.     \fIGrouping of components in a message\fR 
  1316. .sp 9p
  1317. .RT
  1318. .PP
  1319. The effect of TC\(hyuser issuing a component handling primitive
  1320. (unless this primitive has local effect only), is to build a \fBcomponent\fR 
  1321. to be included in a \fBmessage\fR . The message is not transmitted until 
  1322. the TC\(hyuser 
  1323. requests it.
  1324. .PP
  1325. Note that a component may also be generated as a result of a TCAP
  1326. reject: in this case this component is put in the next message for the 
  1327. dialogue unless it is aborted. 
  1328. .PP
  1329. Provided that the maximum size of a message is not exceeded, several components 
  1330. can be grouped and sent to the remote end as a single message, 
  1331. thereby saving transmission overhead. This is done under control of the
  1332. TC\(hyuser, which explicitly specifies when it wants (a) component(s) to be
  1333. sent.
  1334. .PP
  1335. Example E3, as given in Table\ 11/Q.775, shows the beginning of a
  1336. dialogue with a network service centre where a switch requests instructions
  1337. (operation\ 1) and receives a request to connect the call to a given destination 
  1338. address, and a request to send information (e.g.\ announcement or message 
  1339. to be displayed) to the calling party. Both components are contained in 
  1340. a single 
  1341. message.
  1342. .RT
  1343. .LP
  1344. .sp 1
  1345. .ce
  1346. \fBH.T. [T11.775]\fR 
  1347. .ce
  1348. TABLE\ 11/Q.775
  1349. .ps 9
  1350. .vs 11
  1351. .nr VS 11
  1352. .nr PS 9
  1353. .TS
  1354. center box;
  1355. cw(78p) | cw(78p) .
  1356. TC USER A    TC USER B
  1357. _
  1358. .T&
  1359. lw(78p) | lw(78p) .
  1360.  {
  1361. TC\(hyINVOKE req
  1362. (1, Provide\(hyInstructions, Class = 1)
  1363. TC\(hyBEGIN req
  1364. (control parameters)
  1365.  }    
  1366. _
  1367. .T&
  1368. lw(78p) | lw(78p) .
  1369.      {
  1370. TC\(hyBEGIN ind
  1371. (control parameters)
  1372. TC\(hyINVOKE ind
  1373. (1, Provide\(hyinstructions)
  1374. TC\(hyINVOKE req
  1375. (2, 1, Connect\(hyCall)
  1376. TC\(hyRESULT\(hyL req
  1377. (1, Send\(hyInfo)
  1378. TC\(hyCONTINUE req
  1379. (control parameters)
  1380.  }
  1381. _
  1382. .T&
  1383. lw(78p) | lw(78p) .
  1384.  {
  1385. TC\(hyCONTINUE ind
  1386. (control parameters)
  1387. TC\(hyINVOKE ind
  1388. (2, 1, Connect\(hyCall)
  1389. TC\(hyRESULT\(hyL ind
  1390. (1, Send\(hyInfo)
  1391.  }    
  1392. _
  1393. .TE
  1394. .nr PS 9
  1395. .RT
  1396. .ad r
  1397. \fBTableau 11/Q.775 [T11.775], p.\fR 
  1398. .sp 1P
  1399. .RT
  1400. .ad b
  1401. .RT
  1402. .LP
  1403. .sp 1
  1404. .bp
  1405. .PP
  1406. TC\(hyBEGIN and TC\(hyCONTINUE are transmission primitives described in 
  1407. \(sc\ 3.2 below. 
  1408. .PP
  1409. There may be one transmission primitive for each component, but the
  1410. separation of primitives allows the grouping of components within a message.
  1411. In addition, the information contained in the parameters of the transmission
  1412. primitives (e.g.\ addressing information) applies to all the components 
  1413. included in the message. 
  1414. .PP
  1415. At the originating side, the primitive requesting transmission appears 
  1416. after a component handling primitive; this indicates that transmission 
  1417. of the preceeding components has to take place immediately; it avoids indicating 
  1418. specific components to be transmitted with a given transmission primitive, 
  1419. and allows transmission primitives without any associated component. 
  1420. .PP
  1421. At the destination side, the primitive requesting transmission appears 
  1422. first: it contains control information which is necessary for TCAP to deliver 
  1423. each of the components (if any) in the message; the last component of the 
  1424. message is indicated to the TC\(hyuser by the \*QLast Component\*U parameter. 
  1425. The 
  1426. components are delivered to the destination TC\(hyuser in the same order 
  1427. as they were passed to TCAP by the originating TC\(hyuser. 
  1428. .RT
  1429. .sp 1P
  1430. .LP
  1431. 3.2
  1432.     \fIDialogue handling facilities\fR 
  1433. .sp 9p
  1434. .RT
  1435. .PP
  1436. When two TC\(hyusers co\(hyoperate in an application, more than one
  1437. operation invocation is generally required. The resulting flow of components
  1438. has to be identified so that:
  1439. .RT
  1440. .LP
  1441.     1)
  1442.     components of the same flow can be related
  1443. .LP
  1444.     2)
  1445.     flows corresponding to several instances of the same
  1446. application can be identified and allowed to run in parallel.
  1447. .PP
  1448. Each such flow is identified, for the TC\(hyuser, by a dialogue and a corresponding 
  1449. Dialogue ID\ parameter. The dialogue handling facility provided 
  1450. for this purpose is the structured dialogue.
  1451. .PP
  1452. When only a single message is required to complete a distributed
  1453. application, the Unidirectional message of the unstructured dialogue may be
  1454. used. The originator does not expect a report of the outcome of the operation 
  1455. (i.e.\ may only invoke class\ 4 operations), but may receive a report of 
  1456. a 
  1457. protocol error if one occurs.
  1458. .RT
  1459. .sp 2P
  1460. .LP
  1461. 3.2.1
  1462.     \fIStructured dialogue\fR 
  1463. .sp 1P
  1464. .RT
  1465. .sp 1P
  1466. .LP
  1467. 3.2.1.1
  1468.     \fIGeneral\fR 
  1469. .sp 9p
  1470. .RT
  1471. .PP
  1472. The use of dialogues allows several flows of components to co\(hyexist 
  1473. between two TC\(hyusers. The Dialogue ID\ parameter is used in both operation 
  1474. handling and transmission (dialogue) handling primitives to determine which
  1475. component(s) pertain(s) to which dialogue.
  1476. .PP
  1477. The Dialogue ID parameter is represented (by convention) by the first parameter 
  1478. in these primitives, starting with letter\ D. Each TC\(hyuser has its own 
  1479. reference for a given dialogue. Local references (those used on the interface) 
  1480. are represented here; mapping of these local references onto protocol 
  1481. references included in messages is done by TCAP.
  1482. .PP
  1483. Three primitives have been defined for handling dialogues under normal 
  1484. circumstances; they indicate dialogue begin (TC\(hyBEGIN), continuation 
  1485. (TC\(hyCONTINUE) or end (TC\(hyEND). Each of these primitives may be used 
  1486. to request transmission of 0, 1 or several components; these components 
  1487. may contain 
  1488. information relating to one or several operations.
  1489. .bp
  1490. .PP
  1491. Table 12/Q.775 illustrates a possible sequence for example E2, where the 
  1492. test request starts the dialogue, which ends when the test result has been 
  1493. sent. 
  1494. .RT
  1495. .ce
  1496. \fBH.T. [T12.775]\fR 
  1497. .ce
  1498. TABLE\ 12/Q.775
  1499. .ps 9
  1500. .vs 11
  1501. .nr VS 11
  1502. .nr PS 9
  1503. .TS
  1504. center box;
  1505. cw(78p) | cw(78p) .
  1506. TC USER A    TC USER B
  1507. _
  1508. .T&
  1509. lw(78p) | lw(78p) .
  1510.  {
  1511. TC\(hyINVOKE req
  1512. (D1, 1, Test, Class = 1)
  1513. TC\(hyBEGIN req
  1514. (D1, Address)
  1515.  }    
  1516. _
  1517. .T&
  1518. lw(78p) | lw(78p) .
  1519.      {
  1520. TC\(hyBEGIN ind
  1521. (D2, Address)
  1522. TC\(hyINVOKE ind
  1523. (D2, 1, Test)
  1524. TC\(hyINVOKE req
  1525. (D2, 2, 1, Option\(hyselection, Class = 1)
  1526. TC\(hyCONTINUE req
  1527. (D2)
  1528.  }
  1529. _
  1530. .T&
  1531. lw(78p) | lw(78p) .
  1532.  {
  1533. TC\(hyCONTINUE ind
  1534. (D1)
  1535. TC\(hyINVOKE ind
  1536. (D1, 2, 1, Option\(hyselection)
  1537. TC\(hyRESULT\(hyL req
  1538. (D1, 2, Options)
  1539. TC\(hyCONTINUE\(hyreq
  1540. (D1)
  1541. TC\(hyEND ind
  1542. (D1, normal)
  1543. TC\(hyRESULT\(hyL ind
  1544. (D1, 1, Test\(hyresult)
  1545.  }     {
  1546. .
  1547. TC\(hyCONTINUE ind
  1548. (D2)
  1549. TC\(hyRESULT\(hyL ind
  1550. (D2, 2, Options)
  1551. TC\(hyRESULT\(hyL req
  1552. (D2, 1, Test\(hyresult)
  1553. TC\(hyEND req
  1554. (D2)
  1555.  }
  1556. _
  1557. .TE
  1558. .nr PS 9
  1559. .RT
  1560. .ad r
  1561. \fBTableau 12/Q.775 [T12.775], p.\fR 
  1562. .sp 1P
  1563. .RT
  1564. .ad b
  1565. .RT
  1566. .LP
  1567. .bp
  1568. .PP
  1569. Any grouping of components is allowed in the messages of a
  1570. dialogue: TCAP does not check, for instance, that a message terminating a
  1571. dialogue does not include operation invocations of class\ 1. Full\(hyduplex
  1572. exchange of components is assumed: if a TC\(hyuser wants to introduce some
  1573. restrictions, e.g.\ working in a synchronous mode as defined in ROSE, it 
  1574. would have to introduce the necessary procedures itself. 
  1575. .sp 1P
  1576. .LP
  1577. 3.2.1.2
  1578.     \fIExchange of messages\fR 
  1579. .sp 9p
  1580. .RT
  1581. .PP
  1582. Transmission of messages is accomplished with the quality of
  1583. service of the underlying layer services: no flow control or error recovery
  1584. mechanisms are provided by TCAP.
  1585. .RT
  1586. .LP
  1587.     \(em
  1588.     The first dialogue handling primitive of a dialogue must
  1589. indicate dialogue begin (TC\(hyBEGIN). Further messages must not be sent 
  1590. from the side originating the dialogue until a message is received in the 
  1591. backward 
  1592. direction, indicating dialogue continuation.
  1593. .LP
  1594.     \(em
  1595.     If a TC\(hyuser tries to send a large number of messages in a
  1596. short amount of time, no flow control mechanism in TCAP will prevent it.
  1597. .LP
  1598.     \(em
  1599.     SCCP class 1 in\(hysequence delivery can be requested as an
  1600. option, indicated by the Quality of Service parameter. Note that this option
  1601. may not be available end to end when interworking with a network which 
  1602. does not provide it. 
  1603. .sp 1P
  1604. .LP
  1605. 3.2.1.3
  1606.     \fIDialogue end\fR 
  1607. .sp 9p
  1608. .RT
  1609. .PP
  1610. TCAP places no restriction on the ability for a TC\(hyuser to request dialogue 
  1611. end. It follows that messages may be lost if no precautions are taken in 
  1612. the application on when the dialogue may end. In particular, if the 
  1613. application protocol allows both TC\(hyusers to issue TC\(hyEND primitives 
  1614. at about the same time, and if these primitives trigger transmission of 
  1615. components, it is likely that some (if not all) of these components will 
  1616. not be delivered to their respective destination TC\(hyusers. 
  1617. .PP
  1618. It is up to the application to define, if necessary, its own rules
  1619. concerning the right to end a dialogue: TCAP will not check them. Any message 
  1620. received for a terminated dialogue is discarded if it requests dialogue 
  1621. end, 
  1622. and otherwise causes the dialogue to be aborted at the remote entity.
  1623. .PP
  1624. The differences between the three ways of ending a dialogue are as
  1625. follows.
  1626. .RT
  1627. .sp 1P
  1628. .LP
  1629.     \fIPrearranged end\fR 
  1630. .sp 9p
  1631. .RT
  1632. .PP
  1633. A typical application is the access to a distributed database,
  1634. where the requesting user (TC\(hyuser\ A) does not know where the information 
  1635. it 
  1636. seeks is located. TC\(hyuser\ A broadcasts a request to each location which 
  1637. might have the information required, and will eventually receive a response 
  1638. from the TC\(hyuser which holds this information. Prearranged end avoids 
  1639. messages from the other destinations saying: \*QI do not have this information\*U. 
  1640. Only the 
  1641. responding destination may continue the dialogue (if so wished); all other
  1642. destination will, by convention, end the dialogue locally; the originator of
  1643. the requests will also end the dialogues with the non\(hyresponding destinations 
  1644. locally, when it receives the response to its request. Note that the convention 
  1645. is between applications: TCAP does not check that it is respected, nor 
  1646. is it 
  1647. indicated in the TCAP protocol.
  1648. .PP
  1649. Example E4 in Table 13/Q.775 illustrates this situation, with two
  1650. destinations B1 and B2; two dialogues (D1, D2) and (D3, D4) are started; B1
  1651. happens to own the requested information, and decides to continue the
  1652. dialogue.
  1653. .bp
  1654. .RT
  1655. .ce
  1656. \fBH.T. [T13.775]\fR 
  1657. .ce
  1658. TABLE\ 13/Q.775
  1659. .ps 9
  1660. .vs 11
  1661. .nr VS 11
  1662. .nr PS 9
  1663. .TS
  1664. center box;
  1665. cw(80p) | cw(74p) | cw(74p) .
  1666. TC USER A    TC USER B1    TC USER B2
  1667. _
  1668. .T&
  1669. lw(80p) | lw(74p) | lw(74p) .
  1670.  {
  1671. TC\(hyINVOKE req
  1672. (D1, 1, Question)
  1673. TC\(hyBEGIN req
  1674. (D1, Address)
  1675. TC\(hyINVOKE req
  1676. (D3, 1, Question)
  1677. TC\(hyBEGIN req
  1678. (D3, Address)
  1679. TC\(hyCONTINUE ind
  1680. (D1)
  1681. TC\(hyRESULT\(hyL ind
  1682. (D1, 1, Response)
  1683. \ D1 goes on
  1684. \ D3 ends locally
  1685. TC\(hyEND req
  1686. (D3, local)
  1687.  }     {
  1688. .
  1689. TC\(hyBEGIN ind
  1690. (D2, Address)
  1691. TC\(hyINVOKE ind
  1692. (D2, 1, Question)
  1693. TC\(hyRESULT\(hyL req
  1694. (D2, 1, Response)
  1695. TC\(hyCONTINUE req
  1696. (D2)
  1697. ......
  1698.  }     {
  1699. .
  1700. TC\(hyBEGIN ind
  1701. (D4, Address)
  1702. TC\(hyINVOKE ind
  1703. (D4, 1, Question)
  1704. B2 does not have the information:
  1705. TC\(hyEND req
  1706. (D4, local)
  1707.  }
  1708. _
  1709. .TE
  1710. .nr PS 9
  1711. .RT
  1712. .ad r
  1713. \fBTableau 13/Q.775 [T13.775], p.\fR 
  1714. .sp 1P
  1715. .RT
  1716. .ad b
  1717. .RT
  1718. .LP
  1719. .sp 2
  1720. .PP
  1721. Prearranged end may also be used when a TC\(hyuser wants to send
  1722. information, and does not expect a reply of any kind afterwards.
  1723. .sp 1P
  1724. .LP
  1725.     \fIBasic end\fR 
  1726. .sp 9p
  1727. .RT
  1728. .PP
  1729. When a TC\(hyuser issues the TC\(hyEND request primitive, it causes
  1730. transmission of any pending components to the remote end. TCAP does not 
  1731. check that all operation invocations have received a response when dialogue 
  1732. end is 
  1733. requested: no notification is given to the TC\(hyuser that any pending 
  1734. operation invocations have not received a final result. 
  1735. .PP
  1736. At the receiving end, the dialogue is considered terminated when all the 
  1737. components received within the message indicating the end have been 
  1738. delivered to the TC\(hyuser.
  1739. .bp
  1740. .PP
  1741. Example: the dialogue ends when the test in example E1,
  1742. Table\ 14/Q.775, receives a response.
  1743. .RT
  1744. .ce
  1745. \fBH.T. [T14.775]\fR 
  1746. .ce
  1747. TABLE\ 14/Q.775
  1748. .ps 9
  1749. .vs 11
  1750. .nr VS 11
  1751. .nr PS 9
  1752. .TS
  1753. center box;
  1754. cw(78p) | cw(78p) .
  1755. TC USER A    TC USER B
  1756. _
  1757. .T&
  1758. lw(78p) | lw(78p) .
  1759.  {
  1760. ......
  1761. TC\(hyEND ind
  1762. (D1)
  1763. TC\(hyRESULT\(hyNL ind
  1764. (D1, 1, P1)
  1765. TC\(hyRESULT\(hyNL ind
  1766. (D1, 1, P2)
  1767. TC\(hyRESULT\(hyL ind
  1768. (D1, 1, P3)
  1769. End of dialogue for A
  1770.  }     {
  1771. ......
  1772. TC\(hyRESULT\(hyNL req
  1773. (D2, 1, P1)
  1774. TC\(hyRESULT\(hyNL req
  1775. (D2, 1, P2)
  1776. TC\(hyRESULT\(hyL req
  1777. (D2, 1, P3)
  1778. TC\(hyEND req
  1779. (D2, normal)
  1780. End of dialogue for B
  1781.  }
  1782. _
  1783. .TE
  1784. .nr PS 9
  1785. .RT
  1786. .ad r
  1787. \fBTableau 14/Q.775 [T14.775], p.\fR 
  1788. .sp 1P
  1789. .RT
  1790. .ad b
  1791. .RT
  1792. .sp 1P
  1793. .LP
  1794.     \fIAbort by the TC\(hyuser\fR 
  1795. .sp 9p
  1796. .RT
  1797. .PP
  1798. The abort facility allows the TC\(hyuser to stop the dialogue at any time. 
  1799. A typical case is when the user abandons the service. The main 
  1800. differences between this and normal ending are:
  1801. .RT
  1802. .LP
  1803.     \(em
  1804.      any components for which transmission is pending are not sent to the 
  1805. peer entity; 
  1806. .LP
  1807.     \(em
  1808.     peer\(hyto\(hypeer information can be indicated at the time the
  1809. abort is issued, and this is delivered to the remote TC\(hyuser.
  1810. .PP
  1811. The sequence given in Table\ 15/Q.775 shows a user abandonment in   example E2.
  1812. .sp 1P
  1813. .LP
  1814. 3.2.1.4
  1815.     \fIMessage\(hyrelated abnormal situations\fR 
  1816. .sp 9p
  1817. .RT
  1818. .PP
  1819. These are considered independently from the effects of such events in the 
  1820. Component sub\(hylayer. 
  1821. .RT
  1822. .sp 1P
  1823. .LP
  1824.     \fIMessage loss\fR 
  1825. .sp 9p
  1826. .RT
  1827. .PP
  1828. TCAP provides no protection against message loss. Three cases are   identified:
  1829. .RT
  1830. .LP
  1831.     1)
  1832.     the message begins a new dialogue: the dialogue will exist
  1833. at the originating side only, and no message will be allowed in
  1834. either direction. Eventually, an implementation\(hydependent
  1835. mechanism of TCAP ends the dialogue at the originating end;
  1836. .LP
  1837.     2)
  1838.     the message continues an existing dialogue: loss is not
  1839. detected. TCAP will react (or not) to the loss of included
  1840. components as indicated in \(sc\ 2.4.1 above;
  1841. .LP
  1842.     3)
  1843.     the message ends a dialogue: TCAP will eventually react if
  1844. this message contained a response to a class\ 1 operation:
  1845. otherwise an implementation\(hydependent mechanism may end the
  1846. dialogue at the destination end.
  1847. .bp
  1848. .LP
  1849. .ce
  1850. \fBH.T. [T15.775]\fR 
  1851. .ce
  1852. TABLE\ 15/Q.775
  1853. .ps 9
  1854. .vs 11
  1855. .nr VS 11
  1856. .nr PS 9
  1857. .TS
  1858. center box;
  1859. cw(78p) | cw(78p) .
  1860. TC USER A    TC USER B
  1861. _
  1862. .T&
  1863. lw(78p) | lw(78p) .
  1864.  {
  1865. TC\(hyINVOKE req
  1866. (D1, 1, Test, Class = 1)
  1867. TC\(hyBEGIN req
  1868. (D1, Address)
  1869.  }    
  1870. _
  1871. .T&
  1872. lw(78p) | lw(78p) .
  1873.      {
  1874. TC\(hyBEGIN ind
  1875. (D2, Address)
  1876. TC\(hyINVOKE ind
  1877. (D2, 1, Test)
  1878. TC\(hyINVOKE req
  1879. (D2, 2, 1, Option\(hyselection, Class = 1)
  1880. TC\(hyCONTINUE req
  1881. (D2)
  1882.  }
  1883. _
  1884. .T&
  1885. lw(78p) | lw(78p) .
  1886.  {
  1887. TC\(hyCONTINUE ind
  1888. (D1)
  1889. TC\(hyINVOKE ind
  1890. (D1, 2, 1, Option\(hyselection)
  1891. User abandon:
  1892. TC\(hyU\(hyABORT req
  1893. (D1, Cause)
  1894.  }    
  1895. _
  1896. .T&
  1897. lw(78p) | lw(78p) .
  1898.      {
  1899. TC\(hyU\(hyABORT ind
  1900. (D2, Cause)
  1901.  }
  1902. _
  1903. .TE
  1904. .nr PS 9
  1905. .RT
  1906. .ad r
  1907. \fBTableau 15/Q.775 [T15.775], p.\fR 
  1908. .sp 1P
  1909. .RT
  1910. .ad b
  1911. .RT
  1912. .LP
  1913. .sp 2
  1914. .sp 1P
  1915. .LP
  1916.     \fIMessage duplication\fR 
  1917. .sp 9p
  1918. .RT
  1919. .PP
  1920. Duplication of a BEGIN message causes two transactions to be
  1921. opened, as indicated below: each of these transactions has its own local\ ID,
  1922. and the same destination ID. The TC\(hyuser eventually detects that something 
  1923. is wrong, and both dialogues are aborted. 
  1924. .bp
  1925. .PP
  1926. The sequence given in Table 16/Q.775 illustrates a duplication of the BEGIN 
  1927. message in Example\ E2. 
  1928. .RT
  1929. .ce
  1930. \fBH.T. [T16.775]\fR 
  1931. .ce
  1932. TABLE\ 16/Q.775
  1933. .ps 9
  1934. .vs 11
  1935. .nr VS 11
  1936. .nr PS 9
  1937. .TS
  1938. center box;
  1939. cw(78p) | cw(78p) .
  1940. TC USER A    TC USER B
  1941. _
  1942. .T&
  1943. lw(78p) | lw(78p) .
  1944.  {
  1945. TC\(hyINVOKE req
  1946. (D1, 1, Test, Class = 1)
  1947. TC\(hyBEGIN req
  1948. (D1, Address)
  1949.  }    
  1950. _
  1951. .T&
  1952. lw(78p) | lw(78p) .
  1953.  {
  1954. .
  1955. TC\(hyCONTINUE ind
  1956. (D1)
  1957. TC\(hyINVOKE ind
  1958. (D1, 2, 1, Option\(hyselect)
  1959.  }     {
  1960. TC\(hyBEGIN ind
  1961. (D2, Address)
  1962. TC\(hyINVOKE ind
  1963. (D2, 1, Test)
  1964. Duplicated BEGIN:
  1965. TC\(hyBEGIN ind
  1966. (D3, Address)
  1967. TC\(hyINVOKE ind
  1968. (D3, 1, Test)
  1969. Response to the first Begin
  1970. TC\(hyINVOKE req
  1971. (D2, 2, 1, Option\(hyselect, Class = 1)
  1972. TC\(hyCONTINUE req
  1973. (D2)
  1974. Response to the second Begin
  1975. TC\(hyINVOKE ind
  1976. (D3, 2, 1, Option\(hyselect, Class = 1)
  1977. TC\(hyCONTINUE req
  1978. (D3)
  1979.  }
  1980. _
  1981. .T&
  1982. lw(78p) | lw(78p) .
  1983.  {
  1984. TC\(hyCONTINUE ind
  1985. (D1)
  1986. TC\(hyINVOKE ind
  1987. (D1, 2, 1, Option\(hyselect)
  1988. TC\(hyuser considers that this invocation is abnormal, and may reject it, or
  1989. abort one of the dialogues:
  1990. TC\(hyU\(hyABORT req
  1991. (D1, Cause)
  1992.  }    
  1993. _
  1994. .T&
  1995. lw(78p) | lw(78p) .
  1996.      {
  1997. TC\(hyU\(hyABORT ind
  1998. (D3, Cause)
  1999.  }
  2000. _
  2001. .TE
  2002. .nr PS 9
  2003. .RT
  2004. .ad r
  2005. \fBTableau 16/Q.775 [T16.775], p.\fR 
  2006. .sp 1P
  2007. .RT
  2008. .ad b
  2009. .RT
  2010. .LP
  2011. .bp
  2012. .PP
  2013. At that moment, there is still one dialogue (with local ID D2) at TC\(hyuser 
  2014. B's side, but no dialogue at A's side. TC\(hyuser\ B will receive an 
  2015. indication from TCAP when operation\ 2 of dialogue D2 timeouts with no reply
  2016. (TC\(hyL\(hyCANCEL ind), and may then decide to abort D2. Note that the 
  2017. situation 
  2018. would be more difficult to detect, had TC\(hyuser\ B not invoked a class 1
  2019. operation.
  2020. .PP
  2021. Duplication of a CONTINUE message is not detected by TCAP.
  2022. .PP
  2023. When an END message is duplicated, the second message is received with 
  2024. an ID which does not correspond to an active dialogue: TCAP reacts by 
  2025. discarding the duplicate message.
  2026. .RT
  2027. .sp 1P
  2028. .LP
  2029.     \fIMissequencing of messages\fR 
  2030. .sp 9p
  2031. .RT
  2032. .PP
  2033. When the missequenced messages involve neither the beginning, nor the end 
  2034. of a dialogue, missequencing is not detected by TCAP, and may result in 
  2035. component missequencing, to which TCAP would react as indicated in \(sc\ 
  2036. 2.5.3 
  2037. above.
  2038. .PP
  2039. When a message indicating dialogue continuation arrives after a
  2040. message indicating the end of the same dialogue, it is not delivered, and
  2041. causes TCAP to abort the dialogue; the TC\(hyuser will probably detect the loss
  2042. when receiving a premature dialogue end indication. If the application 
  2043. needs to recover from this case, a new dialogue should be started. 
  2044. .RT
  2045. .sp 1P
  2046. .LP
  2047.     \fIMessage corruption\fR 
  2048. .sp 9p
  2049. .RT
  2050. .PP
  2051. When receiving a corrupted message, TCAP reacts as indicated in
  2052. Recommendation\ Q.774.
  2053. .PP
  2054. Table 17/Q.775 shows the sequence of primitives when TCAP decides to abort 
  2055. the dialogue after receiving a corrupted message in example\ E2. 
  2056. .RT
  2057. .ce
  2058. \fBH.T. [T17.775]\fR 
  2059. .ce
  2060. TABLE\ 17/Q.775
  2061. .ps 9
  2062. .vs 11
  2063. .nr VS 11
  2064. .nr PS 9
  2065. .TS
  2066. center box;
  2067. cw(78p) | cw(78p) .
  2068. TC USER A    TC USER B
  2069. _
  2070. .T&
  2071. lw(78p) | lw(78p) .
  2072.  {
  2073. TC\(hyINVOKE req
  2074. (D1, 1, Test, Class = 1)
  2075. TC\(hyBEGIN req
  2076. (D1, Address)
  2077.  }    
  2078. _
  2079. .T&
  2080. lw(78p) | lw(78p) .
  2081.      {
  2082. TC\(hyBEGIN ind
  2083. (D2, Address)
  2084. TC\(hyINVOKE ind
  2085. (D2, 1, Test)
  2086. TC\(hyINVOKE req
  2087. (D2, 2, 1, Option\(hyselect, Class = 1)
  2088. TC\(hyCONTINUE req
  2089. (D2)
  2090.  }
  2091. _
  2092. .T&
  2093. lw(78p) | lw(78p) .
  2094.  {
  2095. Corrupted message:
  2096. TC\(hyABORT ind
  2097. (D1, Cause)
  2098.  }    . TC\(hyABORT ind (D2, Cause)
  2099. _
  2100. .TE
  2101. .nr PS 9
  2102. .RT
  2103. .ad r
  2104. \fBTableau 17/Q.775 [T17.775], p.\fR 
  2105. .sp 1P
  2106. .RT
  2107. .ad b
  2108. .RT
  2109. .LP
  2110. .bp
  2111. .sp 1P
  2112. .LP
  2113. 3.2.1.5
  2114.     \fIRelations between dialogue handling and operation handling\fR 
  2115. .sp 9p
  2116. .RT
  2117. .PP
  2118. Depending on the moment when the dialogue end is requested, the
  2119. TCAP facilities associated with an operation will be available until the 
  2120. end of the dialogue, or not. The following gives some guidelines on when 
  2121. dialogue end can be requested; if these are not respected, TCAP will not 
  2122. refuse the request for dialogue end. 
  2123. .PP
  2124. The problems that may result from the collision of messages requesting 
  2125. dialogue end have been considered above. 
  2126. .PP
  2127. Normal end should not be requested when:
  2128. .RT
  2129. .LP
  2130.     \(em
  2131.     there are operation invocations pending for the dialogue;
  2132. .LP
  2133.     \(em
  2134.     the application protocol anticipates that replies being
  2135. transmitted with the termination request could be rejected.
  2136. .PP
  2137. In addition, a request for dialogue end must not trigger
  2138. transmission of operation invocations, since no reply could be received for
  2139. these operations.
  2140. .PP
  2141. Many applications might not define recovery scenarios in response to a 
  2142. rejected reply. This legitimises the transmission of replies or of class\ 
  2143. 4 
  2144. operations in a message indicating dialogue end. The other applications 
  2145. should either use the connection\(hyoriented network service approach, 
  2146. or end the 
  2147. dialogue with a message containing no component, that would be sent only 
  2148. when a reject indication can no longer be received. 
  2149. .RT
  2150. .sp 1P
  2151. .LP
  2152. 3.2.2
  2153.     \fIUnstructured dialogue\fR 
  2154. .sp 9p
  2155. .RT
  2156. .PP
  2157. A Unidirectional message will contain either only class\ 4 operation invocations 
  2158. or reports of protocol errors in such invocations. Multiple 
  2159. components can be transmitted in a Unidirectional message provided that the
  2160. maximum size of a message is not exceeded.
  2161. .RT
  2162. .sp 2P
  2163. .LP
  2164. \fB4\fR     \fBApplication service elements\fR \fBand\fR 
  2165. \fBapplication\fR 
  2166. \fBentities\fR 
  2167. .sp 1P
  2168. .RT
  2169. .sp 1P
  2170. .LP
  2171. 4.1
  2172.     \fIIntroduction\fR 
  2173. .sp 9p
  2174. .RT
  2175. .PP
  2176. This material supplements preceding material providing guidelines on the 
  2177. usage of TC by describing what needs to be included in an Application 
  2178. Entity (AE) specification. This material is based on CCITT
  2179. Recommendations\ X.219 and X.229 and requires further study.
  2180. .PP
  2181. CCITT Recommendation Q.700, \(sc\ 3.2.3.6, describes how Application
  2182. Service Elements (ASEs) and Application Entities (AEs) are structured and 
  2183. how an AE is addressed in Signalling System No.\ 7. 
  2184. .PP
  2185. This section illustrates that architecture, considering the functional 
  2186. decomposition of an application, and describes how AEs, ASEs, operations 
  2187. and 
  2188. errors should be defined.
  2189. .RT
  2190. .sp 1P
  2191. .LP
  2192. 4.2
  2193.     \fIDecomposition of\fR 
  2194. \fIfunctionality\fR 
  2195. .sp 9p
  2196. .RT
  2197. .PP
  2198. Application process functions communicate through one or more
  2199. Application Entities (AEs). The combination of two peer AEs plus their
  2200. interaction is called the Application Context. An AE consists of communications 
  2201. for one or more functions of an application. Each communications function 
  2202. forms an ASE which is an integrated set of actions and may be used in more 
  2203. than an 
  2204. AE. TCAP is itself an ASE which is used by other ASEs as well as being 
  2205. common to AEs (see \(sc\ 3.2.3.6/Q.700). An ASE identifies one or more 
  2206. operations and 
  2207. specifies how those operations are used; that is, which peer entity may 
  2208. invoke which operations, and in what order. Operations may be selected 
  2209. from one or 
  2210. more libraries.
  2211. .PP
  2212. An ASE provides a service to the user of the ASE. An ASE is used by
  2213. two complementary AEs: the consumer of the service and the supplier of the
  2214. service. The consumer of the service is the end that initiates the AE to AE
  2215. communication. An ASE user is thus generally asymmetric.
  2216. .bp
  2217. .PP
  2218. Within an ASE, the mechanism for providing the ASE service is the
  2219. invocation of operations by the service requestor on the service provider. 
  2220. Each operation provides a part of the service in an inherently asymmetric 
  2221. manner 
  2222. since it is invoked by one AE and executed by the peer AE. An ASE generally
  2223. includes more than one operation. An ASE user is, in general, not limited to
  2224. either invoking or performing operations, but may both invoke or perform the
  2225. same or different operations. Also, an ASE user may exist at a pair of nodes
  2226. such that either node may request the same service from the other node. That
  2227. is, the AEs at the nodes may be symmetric, both invoking and executing the
  2228. same operations.
  2229. .PP
  2230. \fINote\fR \ \(em\ Primitives which provide a standard service interface 
  2231. for the access of ASEs within AEs are for further study. 
  2232. .PP
  2233. Figure 3/Q.775 illustrates the decomposition of this functionality and 
  2234. provides examples. 
  2235. .RT
  2236. .LP
  2237. .sp 2
  2238. .rs
  2239. .sp 21P
  2240. .ad r
  2241. \fBFigure 3/Q.775, (N), p.\fR 
  2242. .sp 1P
  2243. .RT
  2244. .ad b
  2245. .RT
  2246. .LP
  2247. .sp 2
  2248. .sp 1P
  2249. .LP
  2250. 4.3
  2251.     \fIHow to specify an AE\fR 
  2252. .sp 9p
  2253. .RT
  2254. .PP
  2255. CCITT Recommendation Q.700, \(sc\ 3.2.3.6, describes how two Signalling 
  2256. System No.\ 7 Application Processes communicate via Application Entities, 
  2257. and 
  2258. also the structure of an AE.
  2259. .PP
  2260. The application designer should provide a definition for each type of AE. 
  2261. It should contain: 
  2262. .RT
  2263. .LP
  2264.     \(em
  2265.     A general description of the services supported by the
  2266. combination of the two peer AEs and communicating by a dialogue.
  2267. (In Recommendation\ X.229 terminology, this corresponds to the
  2268. \*QApplication Context\*U).
  2269. .LP
  2270.     \(em
  2271.     A definition of the complete application protcol between the
  2272. peer AEs by:
  2273. .LP
  2274.     \(em
  2275.     identifying each ASE constituting the AE, and
  2276. .LP
  2277.     \(em
  2278.     indicating which of the peer AEs initiates the
  2279. service.
  2280. .LP
  2281.     \(em
  2282.     Any special constraints to ensure that peer AEs with
  2283. different versions are compatible.
  2284. .bp
  2285. .PP
  2286. A formal specification of the application context using the
  2287. Recommendation\ X.229 APPLICATION\(hyCONTEXT macro is for further study.
  2288. .PP
  2289. Since each AE constitutes a single coding domain for operation and
  2290. error code values (addressed by SCCP subsystem number in a connectionless
  2291. network service environment), each operation or error code value must be 
  2292. unique within the AE (see \(sc\ 4.5). 
  2293. .RT
  2294. .sp 1P
  2295. .LP
  2296. 4.4
  2297.     \fIHow to specify an ASE\fR 
  2298. .sp 9p
  2299. .RT
  2300. .PP
  2301. The definition of an ASE is part of the stage 3 of the service
  2302. description methodology, as defined by Recommendation\ I.220.
  2303. .PP
  2304. The ASE description should provide:
  2305. .RT
  2306. .LP
  2307.     \(em
  2308.     A general description of the ASE and its procedures.
  2309. .LP
  2310.     \(em
  2311.     The information flows between the entities which are
  2312. communicating to support the service, based on stage\ 2, with additions and
  2313. enhancements that are needed as part of the protocol design.
  2314. .LP
  2315.     \(em
  2316.      A detailed description of the ASE protocol. This includes the sequence 
  2317. in which operations may be invoked, and the reaction to abnormal 
  2318. situations. The definition should include how protocol version interwork.
  2319. Dialogue begin, continuation and end should be specified. This section 
  2320. should describe the interaction between the ASE and the TCAP component 
  2321. sub\(hylayer 
  2322. expressed in terms of the primitive interface.
  2323. .LP
  2324.     \(em
  2325.     SDL diagrams.
  2326. .PP
  2327. Recommendation X.229 (ROSE) defines an APPLICATION\(hySERVICE\(hyELEMENT 
  2328. macro which may be used to specify an ASE formally. It identifies which 
  2329. operations are contained in the AE and how they are invoked. The use of this
  2330. macro in Signalling System No.\ 7 is for further study.
  2331. .sp 2P
  2332. .LP
  2333. 4.5
  2334.     \fIHow to specify operations and errors\fR 
  2335. .sp 1P
  2336. .RT
  2337. .sp 1P
  2338. .LP
  2339. 4.5.1
  2340.     \fIInformation needed to specify operations and errors\fR 
  2341. .sp 9p
  2342. .RT
  2343. .PP
  2344. To specify an operation, the following items must be
  2345. defined:
  2346. .RT
  2347. .LP
  2348.     \(em
  2349.     The operation name.
  2350. .LP
  2351.     \(em
  2352.     The operation code. This may be local or global. See
  2353. \(sc\ 4.5.2.
  2354. .LP
  2355.     \(em
  2356.     The operation class. A value in the range 1 to 4 as defined   in \(sc\ 2.2.1.
  2357. .LP
  2358.     \(em
  2359.      The parameters accompanying the operation invocation (input parameters). 
  2360. Further essential information to supplement that provided in the parameters 
  2361. with the original invocation may be requested using linked 
  2362. operations.
  2363. .LP
  2364.     \(em
  2365.     The parameters that may be returned as the result of a
  2366. successful outcome (Return Result), whenever the operation reports success
  2367. (possitive output parameters). The way these parameters are actually passed 
  2368. (in a single component or several) is no part of the operation description. 
  2369. .LP
  2370.     \(em
  2371.     The error codes and associated parameters that may be
  2372. returned as the result of an unsuccessful outcome (Return Error) of the
  2373. operation execution, whenever this operation reports failure (negative 
  2374. output parameters). An error code must be present when reporting failure, 
  2375. and all the possible values be defined as part of the operation description. 
  2376. .LP
  2377.     \(em
  2378.     The allowed linked operations (see \(sc\ 2.2.2).
  2379. .LP
  2380.     \(em
  2381.     The timer value for completion of the operation.
  2382. .PP
  2383. The operation description consists of a Table indicating the eight items 
  2384. above, together with a short prose description of what the operation 
  2385. does. A formal definition using Annex\ A/Q.773 OPERATION and ERROR macros 
  2386. should also be included to unambiguously indicate which parameters are 
  2387. mandatory, 
  2388. which are optional with default values as applicable, and which individual,
  2389. sets or sequences of parameters are legal as input, positive output, and
  2390. negative output. The OPERATION and ERROR type (macro) definitions are exported 
  2391. from the TCAP definitions (Annex\ A/Q.773) and need to be imported into 
  2392. the ASE being defined in order to define operations and errors. 
  2393. .bp
  2394. .PP
  2395. The syntax of the OPERATION MACRO (reproduced from Annex\ A/Q.773) is as 
  2396. follows: 
  2397. .RT
  2398. .sp 1P
  2399. .LP
  2400. OPERATION MACRO ::=
  2401. .sp 9p
  2402. .RT
  2403. .LP
  2404. BEGIN
  2405. .LP
  2406. TYPE NOTATION ::=
  2407.     Parameter Result Errors Linked Operations
  2408. .LP
  2409. VALUE NOTATION ::=
  2410.     valu { ALUE CHOIC {
  2411. value(VALUE CHOICE
  2412. localValue INTEGER,
  2413. value(VALUE CHOICE
  2414. globalValue OBJECT IDENTIFIER\ } 
  2415. .sp 1P
  2416. .LP
  2417. Parameter ::=
  2418.     \*QPARAMETER\*U Named Type\ |  empty
  2419. .sp 9p
  2420. .RT
  2421. .LP
  2422. Result ::=
  2423.     \*QRESULT\*U ResultType\ |  empty
  2424. .LP
  2425. ResultType ::=
  2426.     NamedType\ |  empty
  2427. .LP
  2428. Errors ::=
  2429.     \*QERRORS\*U \* { *UErrorNames\* } *U\ |  empty
  2430. .LP
  2431. LinkedOperations ::=
  2432.     \*QLINKED\*U \* { *ULinkedOperationNames\* } *U\ |  empty
  2433. .LP
  2434. ErrorNames ::=
  2435.     ErrorList\ |  empty
  2436. .LP
  2437. ErrorList ::=
  2438.     Error\ |  ErrorList \*Q,\*U Error
  2439. .LP
  2440. Error ::=
  2441.      value (ERROR)\ \(em\(em\ \fIshall reference an error value\fR |  type\ 
  2442. \(em\(em\ \fIshall reference an error type if no error value\fR 
  2443. |  type\ 
  2444. \(em\(em\ \fIis specified\fR 
  2445. .sp 1P
  2446. .LP
  2447. LinkedOperationNames\ ::=
  2448.     OperationList\ |  empty
  2449. .sp 9p
  2450. .RT
  2451. .LP
  2452. OperationList ::=
  2453.     Operation\ |  OperationList \*Q,\*U Operation
  2454. .LP
  2455. Operation ::=
  2456.     value (OPERATION)\ \(em\(em\ \fIshall reference an operation value\fR 
  2457. |  type\ \(em\(em\ \fIshall reference an operation type if no error value\fR 
  2458. |  type\ 
  2459. \(em\(em\ \fIis specified\fR 
  2460. .sp 1P
  2461. .LP
  2462. NamedType ::=
  2463.     identifier type\ |  type
  2464. .sp 9p
  2465. .RT
  2466. .LP
  2467. END
  2468. .sp 1P
  2469. .LP
  2470. ERROR MACRO ::=
  2471. .sp 9p
  2472. .RT
  2473. .LP
  2474. BEGIN
  2475. .LP
  2476. TYPE NOTATION ::=
  2477.     Parameter
  2478. .LP
  2479. VALUE NOTATION ::=
  2480.     value (VALUE CHOIC {
  2481. valu { ALUE CHOICE
  2482. localValue INTEGER,
  2483. valu { ALUE CHOICE
  2484. globalValue OBJECT IDENTIFIER\ } 
  2485. .sp 1P
  2486. .LP
  2487. Parameter ::=
  2488.     \*QPARAMETER\*U NamedType\ |  empty
  2489. .sp 9p
  2490. .RT
  2491. .LP
  2492. NamedType ::=
  2493.     identifier type\ |  type
  2494. .LP
  2495. END
  2496. .PP
  2497. The use of local and global values is explained in \(sc\ 4.5.2.
  2498. .PP
  2499. As an example, the CUGCheck2 operation, which is used to check whether 
  2500. an incoming call is compatible with the CUG characteristics of the called 
  2501. party, is described here in both (abbreviated) formal notation, and in 
  2502. the form of a table. 
  2503. .RT
  2504. .sp 1P
  2505. .LP
  2506. 4.5.2
  2507.     \fIExample of operation description\fR 
  2508. .sp 9p
  2509. .RT
  2510. .PP
  2511. (\fINote\fR \ \(em\ Arbitrary section numbers are used in this
  2512. example.)
  2513. .bp
  2514. .RT
  2515. .sp 2P
  2516. .LP
  2517. 3.4.3.1
  2518.     \fIDescription of operations\fR 
  2519. .sp 1P
  2520. .RT
  2521. .sp 1P
  2522. .LP
  2523. 3.4.3.1.1
  2524.     \fICUG check 1\fR 
  2525. .sp 9p
  2526. .RT
  2527. .PP
  2528. This operation is used between the originating exchange of a call and a 
  2529. dedicated point for CUG validation check of the calling user. 
  2530. .RT
  2531. .sp 1P
  2532. .LP
  2533. 3.4.3.1.2
  2534.     \fICUG check 2\fR 
  2535. .sp 9p
  2536. .RT
  2537. .PP
  2538. This operation is used between the terminating exchange of a call and a 
  2539. dedicated point for CUG validation check of the called user. 
  2540. .RT
  2541. .sp 2P
  2542. .LP
  2543. 3.4.3.2
  2544.     \fIParameters of operations and outcomes\fR 
  2545. .sp 1P
  2546. .RT
  2547. .sp 1P
  2548. .LP
  2549. 3.4.3.2.1
  2550.     \fICUG Check 1\fR 
  2551. .sp 9p
  2552. .RT
  2553. .LP
  2554. .sp 3
  2555. .ce
  2556. \fBH.T. [T18.775]\fR 
  2557. .ps 9
  2558. .vs 11
  2559. .nr VS 11
  2560. .nr PS 9
  2561. .TS
  2562. center box;
  2563. cw(72p) | cw(72p) | cw(30p) | cw(54p) .
  2564. CUG Check 1    Timer = x sec    Class = 1    Code = 00000001
  2565. _
  2566. .T&
  2567. lw(144p) | cw(30p) | cw(54p) .
  2568. Parameters with Invoke    Opt/Man    Reference
  2569. _
  2570. .T&
  2571. lw(144p) | cw(30p) | cw(54p) .
  2572.  {
  2573. CallingUserIndex
  2574. CUGCallIndicator
  2575. CallingPartyNumber
  2576.  }    O M M    3.4.3.3.1 3.4.3.3.2 3.4.3.3.3
  2577. _
  2578. .T&
  2579. lw(144p) | cw(30p) | cw(54p) .
  2580. Parameters with Return Result        
  2581. _
  2582. .T&
  2583. lw(144p) | cw(30p) | cw(54p) .
  2584.  {
  2585. CUGInterlockCode
  2586. CUGCallIndicator
  2587.  }    O M    3.4.3.3.5 3.4.3.3.2
  2588. _
  2589. .T&
  2590. lw(144p) | cw(30p) | cw(54p) .
  2591. Linked Operations        
  2592. _
  2593. .T&
  2594. lw(144p) | cw(30p) | cw(54p) .
  2595. Not applicable        
  2596. _
  2597. .T&
  2598. lw(144p) | cw(30p) | cw(54p) .
  2599. Errors        
  2600. _
  2601. .T&
  2602. lw(144p) | cw(30p) | cw(54p) .
  2603. UnsuccessfulCheck        3.4.3.3.7
  2604. _
  2605. .TE
  2606. .nr PS 9
  2607. .RT
  2608. .ad r
  2609. \fBTableau du \(sc\ 3.4.3.2.1, [T18.775], p.\fR 
  2610. .sp 1P
  2611. .RT
  2612. .ad b
  2613. .RT
  2614. .LP
  2615. .sp 3
  2616. .LP
  2617. cUGCheck1\ \ \ OPERATION
  2618.     PARAMETER
  2619.     SEQUENC { | allingUserIndex OPTIONAL,
  2620. cUGCallIndicator,
  2621. SEQUENC { |
  2622. callingPartyNumber\ }
  2623.     RESULT
  2624.     SEQUENC { | UGInterlockCode OPTIONAL,
  2625. cUGCallIndicator\ }
  2626.     ERRORS
  2627.     SEQUENCE
  2628. { | nsuccessfulCheck\ }
  2629.     ::= 1
  2630. .bp
  2631. .sp 1P
  2632. .LP
  2633. 3.4.3.2.2
  2634.     \fICUG check 2\fR 
  2635. .sp 9p
  2636. .RT
  2637. .ce
  2638. \fBH.T. [T19.775]\fR 
  2639. .ps 9
  2640. .vs 11
  2641. .nr VS 11
  2642. .nr PS 9
  2643. .TS
  2644. center box;
  2645. cw(72p) | cw(72p) | cw(30p) | cw(54p) .
  2646. CUG Check 2    Timer = x sec    Class = 1    Code = 00000010
  2647. _
  2648. .T&
  2649. lw(144p) | cw(30p) | cw(54p) .
  2650. Parameters with Invoke    Opt/Man    Reference
  2651. _
  2652. .T&
  2653. lw(144p) | cw(30p) | cw(54p) .
  2654.  {
  2655. CUGInterlockCode
  2656. CUGCallIndicator
  2657. CalledPartyNumber
  2658.  }    M M M    3.4.3.3.5 3.4.3.3.2 3.4.3.3.4
  2659. _
  2660. .T&
  2661. lw(144p) | cw(30p) | cw(54p) .
  2662. Parameters with Return Result        
  2663. _
  2664. .T&
  2665. lw(144p) | cw(30p) | cw(54p) .
  2666.  {
  2667. CalledUserIndex
  2668. CUGCallIndicator
  2669.  }    O M    3.4.3.3.6 3.4.3.3.2
  2670. _
  2671. .T&
  2672. lw(144p) | cw(30p) | cw(54p) .
  2673. Linked Operations        
  2674. _
  2675. .T&
  2676. lw(144p) | cw(30p) | cw(54p) .
  2677. Not applicable        
  2678. _
  2679. .T&
  2680. lw(144p) | cw(30p) | cw(54p) .
  2681. Errors        
  2682. _
  2683. .T&
  2684. lw(144p) | cw(30p) | cw(54p) .
  2685. UnsuccessfulCheck        3.4.3.3.7
  2686. _
  2687. .TE
  2688. .nr PS 9
  2689. .RT
  2690. .ad r
  2691. \fBTableau du \(sc\ 3.4.3.2.2, [T19.775], p.\fR 
  2692. .sp 1P
  2693. .RT
  2694. .ad b
  2695. .RT
  2696. .LP
  2697. cUGCheck 2\ \ \ OPERATION
  2698.     PARAMETER
  2699.     SEQUENC { | UGInterlockCode, cUGCallIndicator,
  2700. SEQUENC { |
  2701. calledPartyNumber\ }
  2702.     RESULT
  2703.     SEQUENC { | alledUserIndex OPTIONAL, cUGCallIndicator\ }
  2704.     ERRORS
  2705.     SEQUENCE
  2706. { | nsuccessfulCheck\ }
  2707.     ::= 2
  2708. .sp 1P
  2709. .LP
  2710. 3.4.3.3
  2711.     \fIParameter coding\fR 
  2712. .sp 9p
  2713. .RT
  2714. .LP
  2715. 3.4.3.3.1\ \ The CallingUserIndex is the local index at the calling user to
  2716. identify a particular CUG he belongs to.
  2717. .ce
  2718. \fBH.T. [T20.775]\fR 
  2719. .ps 9
  2720. .vs 11
  2721. .nr VS 11
  2722. .nr PS 9
  2723. .TS
  2724. center box;
  2725. cw(144p) | cw(72p) .
  2726. CallingUserIndex    Code = 10000001
  2727. _
  2728. .T&
  2729. lw(72p) | lw(144p) .
  2730. Contents    Meaning
  2731. _
  2732. .T&
  2733. lw(72p) | lw(144p) .
  2734. IA5 Character String     {
  2735. One IA5 character represents one digit of the CUG index
  2736. value
  2737.  }
  2738. _
  2739. .TE
  2740. .nr PS 9
  2741. .RT
  2742. .ad r
  2743. \fBTableau du \(sc\ 3.4.3.3, [T20.775], p.\fR 
  2744. .sp 1P
  2745. .RT
  2746. .ad b
  2747. .RT
  2748. .LP
  2749. callingUserIndex ::=
  2750.     [1]\ IMPLICIT LocalIndex
  2751.     LocalIndex ::=
  2752.     IA5\ STRING
  2753.     \(em\(em\ \fIThe maximum number of digits is four.\fR .bp
  2754. .sp 1P
  2755. .LP
  2756. 3.4.3.3.2\ \ The CUGCallIndicator indicates whether the call is requested 
  2757. or designated as a CUG call and whether outgoing access is requested or 
  2758. allowed.
  2759. .sp 9p
  2760. .RT
  2761. .ce
  2762. \fBH.T. [T21.775]\fR 
  2763. .ps 9
  2764. .vs 11
  2765. .nr VS 11
  2766. .nr PS 9
  2767. .TS
  2768. center box;
  2769. cw(144p) | cw(72p) .
  2770. CUGCallIndicator    Code = 10000010
  2771. _
  2772. .T&
  2773. cw(72p) | lw(144p) .
  2774. Contents    Meaning
  2775. _
  2776. .T&
  2777. cw(72p) | lw(144p) .
  2778.  {
  2779. 00000000
  2780. 00000001
  2781. 00000010
  2782. 00000011
  2783.  }     {
  2784. Non\(hyCUG call
  2785. Non\(hyCUG call
  2786. CUG call with outgoing access
  2787. CUG call without outgoing access
  2788.  }
  2789. _
  2790. .TE
  2791. .nr PS 9
  2792. .RT
  2793. .ad r
  2794. \fBTableau du \(sc\ 3.4.3.3.2, [T21.775], p.\fR 
  2795. .sp 1P
  2796. .RT
  2797. .ad b
  2798. .RT
  2799. .LP
  2800. cUGCallIndicator ::=
  2801.     [2]\ IMPLICIT CallIndicator
  2802. .LP
  2803. CallIndicator ::=
  2804.     INTEGE {
  2805.     nonCUGCall (0),
  2806. nonCUGCall (1),
  2807. outgoingAccessAllowedCUGCall (2),
  2808. outgoingAccessNotAllowedCUGCall (3)\ }
  2809. .sp 1P
  2810. .LP
  2811. 3.4.3.3.3\ \ The CallingPartyNumber is the network (e.g.\ E.164) number 
  2812. of the calling party. It is expressed in the same manner as the ISUP Calling 
  2813. party 
  2814. number in \(sc\ 3.7 of Recommendation\ Q.763. The code of this parameter is
  2815. \*Q10000011\*U.
  2816. .sp 9p
  2817. .RT
  2818. .ce
  2819. \fBH.T. [T22.775]\fR 
  2820. .ps 9
  2821. .vs 11
  2822. .nr VS 11
  2823. .nr PS 9
  2824. .TS
  2825. center box;
  2826. cw(144p) | cw(72p) .
  2827. CallingPartyNumber    Code = 10000011
  2828. _
  2829. .T&
  2830. lw(72p) | lw(144p) .
  2831. Contents    Meaning
  2832. _
  2833. .T&
  2834. lw(216p) .
  2835.  {
  2836. \(em | (em encoded per \(sc 3.7/Q.763
  2837.  }
  2838. _
  2839. .TE
  2840. .nr PS 9
  2841. .RT
  2842. .ad r
  2843. \fBTableau du \(sc\ 3.4.3.3.3, [T22.775], p.\fR 
  2844. .sp 1P
  2845. .RT
  2846. .ad b
  2847. .RT
  2848. .LP
  2849. callingPartyNumber ::=\ [3]\ IMPLICIT OCTET STRING
  2850.     \(em\(em\ \fIcontents encoded per \(sc\ 3.7/Q.793\fR 
  2851. .sp 1P
  2852. .LP
  2853. 3.4.3.3.4\ \ The CalledPartyNumber is the network (e.g.\ E.164) number 
  2854. of the called party. It is expressed in the same manner as the ISUP Called 
  2855. party 
  2856. number in \(sc\ 3.6 of Recommendation\ Q.763. The code of this parameter is
  2857. \*Q10000100\*U.
  2858. .sp 9p
  2859. .RT
  2860. .ce
  2861. \fBH.T. [T23.775]\fR 
  2862. .ps 9
  2863. .vs 11
  2864. .nr VS 11
  2865. .nr PS 9
  2866. .TS
  2867. center box;
  2868. cw(144p) | cw(72p) .
  2869. CalledPartyNumber    Code = 10000100
  2870. _
  2871. .T&
  2872. lw(72p) | lw(144p) .
  2873. Contents    Meaning
  2874. _
  2875. .T&
  2876. lw(216p) .
  2877.  {
  2878. \(em | (em encoded per \(sc 3.6/Q.763
  2879.  }
  2880. _
  2881. .TE
  2882. .nr PS 9
  2883. .RT
  2884. .ad r
  2885. \fBTableau du \(sc\ 3.4.3.3.4, [T23.775], p.\fR 
  2886. .sp 1P
  2887. .RT
  2888. .ad b
  2889. .RT
  2890. .LP
  2891. calledPartyNumber ::=\ [4]\ IMPLICIT OCTET STRING
  2892.     \(em\(em\ \fIcontents encoded per \(sc\ 3.6/Q.793\fR .bp
  2893. .sp 1P
  2894. .LP
  2895. 3.4.3.3.5\ \ The CUGInterlockCode is the code to uniquely identify a CUG
  2896. inside the network. It is expressed in the same manner as the ISUP CUG
  2897. interlock code in \(sc\ 3.13 of Recommendation\ Q.763. The code of this 
  2898. parameter is \*Q10000101\*U. 
  2899. .sp 9p
  2900. .RT
  2901. .LP
  2902. .sp 1
  2903. .ce
  2904. \fBH.T. [T24.775]\fR 
  2905. .ps 9
  2906. .vs 11
  2907. .nr VS 11
  2908. .nr PS 9
  2909. .TS
  2910. center box;
  2911. cw(144p) | cw(72p) .
  2912. CUGInterlockCode    Code = 10000101
  2913. _
  2914. .T&
  2915. lw(72p) | lw(144p) .
  2916. Contents    Meaning
  2917. _
  2918. .T&
  2919. lw(216p) .
  2920.  {
  2921. \(em | (em encoded per \(sc 3.13/Q.763
  2922.  }
  2923. _
  2924. .TE
  2925. .nr PS 9
  2926. .RT
  2927. .ad r
  2928. \fBTableau du \(sc\ 3.4.3.3.5, [T24.775], p.\fR 
  2929. .sp 1P
  2930. .RT
  2931. .ad b
  2932. .RT
  2933. .LP
  2934. .sp 1
  2935. .LP
  2936. CUGInterlockCode ::=\ [5]\ IMPLICIT OCTET STRING
  2937.     \(em\(em\ \fIcontents encoded per \(sc\ 3.13/Q.793\fR 
  2938. .sp 1P
  2939. .LP
  2940. 3.4.3.3.6\ \ The CalledUserIndex is the local index at the called user to
  2941. identify a particular CUG he belongs to. Refer to \(sc\ 3.4.3.3.1. The 
  2942. code of this parameter is \*Q10000110\*U. 
  2943. .sp 9p
  2944. .RT
  2945. .LP
  2946. .sp 1
  2947. .ce
  2948. \fBH.T. [T25.775]\fR 
  2949. .ps 9
  2950. .vs 11
  2951. .nr VS 11
  2952. .nr PS 9
  2953. .TS
  2954. center box;
  2955. cw(144p) | cw(72p) .
  2956. CalledUserIndex    Code = 10000110
  2957. _
  2958. .T&
  2959. lw(72p) | lw(144p) .
  2960. Contents    Meaning
  2961. _
  2962. .T&
  2963. lw(72p) | lw(144p) .
  2964. IA5 Character String     {
  2965. One IA5 character represents one digit of the CUG Index
  2966. value
  2967.  }
  2968. _
  2969. .TE
  2970. .nr PS 9
  2971. .RT
  2972. .ad r
  2973. \fBTableau du \(sc\ 3.4.3.3.6, [T25.775], p.\fR 
  2974. .sp 1P
  2975. .RT
  2976. .ad b
  2977. .RT
  2978. .LP
  2979. .sp 1
  2980. .LP
  2981. CalledUserIndex ::=\ [6]\ IMPLICIT LocalIndex
  2982. .sp 1P
  2983. .LP
  2984. 3.4.3.3.7
  2985.     \fIErrors\fR 
  2986. .sp 9p
  2987. .RT
  2988. .LP
  2989. .sp 1
  2990. .ce
  2991. \fBH.T. [T26.775]\fR 
  2992. .ps 9
  2993. .vs 11
  2994. .nr VS 11
  2995. .nr PS 9
  2996. .TS
  2997. center box;
  2998. cw(144p) | cw(72p) .
  2999. UnsuccessfulCheck    Code = 00000001
  3000. _
  3001. .T&
  3002. lw(144p) | lw(72p) .
  3003. Parameters    
  3004. _
  3005. .T&
  3006. lw(144p) | lw(72p) .
  3007. Cause    3.4.3.3.8
  3008. _
  3009. .TE
  3010. .nr PS 9
  3011. .RT
  3012. .ad r
  3013. \fBTableau du \(sc\ 3.4.3.3.7, [T26.775], p.\fR 
  3014. .sp 1P
  3015. .RT
  3016. .ad b
  3017. .RT
  3018. .LP
  3019. .sp 1
  3020. .LP
  3021. unsuccessfulCheck
  3022.     ERROR
  3023.     PARAMETER
  3024.     { | ause\ }
  3025.     ::= 1
  3026. .bp
  3027. .sp 1P
  3028. .LP
  3029. 3.4.3.3.8\ \ The Cause indicates the reason why the CUG check is
  3030. unsuccessful.
  3031. .sp 9p
  3032. .RT
  3033. .ce
  3034. \fBH.T. [T27.775]\fR 
  3035. .ps 9
  3036. .vs 11
  3037. .nr VS 11
  3038. .nr PS 9
  3039. .TS
  3040. center box;
  3041. cw(144p) | cw(84p) .
  3042. Cause    Code = 10000111
  3043. _
  3044. .T&
  3045. lw(84p) | lw(144p) .
  3046. Contents binary (decimal)    Meaning
  3047. _
  3048. .T&
  3049. lw(84p) | lw(144p) .
  3050. 00110010 (50)     {
  3051. Requested facility not subscribed
  3052.  }
  3053. .T&
  3054. lw(84p) | lw(144p) .
  3055. 00110101 (53)     {
  3056. Outgoing calls barred within CUG
  3057.  }
  3058. .T&
  3059. lw(84p) | lw(144p) .
  3060. 00110111 (55)     {
  3061. Incoming calls barred within CUG
  3062.  }
  3063. .T&
  3064. lw(84p) | lw(144p) .
  3065. 00111110 (62)     {
  3066. InconsistencyInDesignatedOutgoingAccessInformationAndSubscriberClass
  3067.  }
  3068. .T&
  3069. lw(84p) | lw(144p) .
  3070. 01010110 (90)    Non\(hyexistent CUG
  3071. .T&
  3072. lw(84p) | lw(144p) .
  3073. 01010111 (87)    Called user not member of CUG
  3074. .T&
  3075. lw(84p) | lw(144p) .
  3076. 01011000 (88)    Incompatible destination
  3077. .T&
  3078. lw(84p) | lw(144p) .
  3079. 10000000 (110)    Inconsistency in data
  3080. _
  3081. .TE
  3082. .nr PS 9
  3083. .RT
  3084. .ad r
  3085. \fBTableau du \(sc\ 3.4.3.3.8, [T27.775], p.\fR 
  3086. .sp 1P
  3087. .RT
  3088. .ad b
  3089. .RT
  3090. .LP
  3091. cause ::=
  3092.     [7]\ IMPLICIT CauseCode
  3093. .LP
  3094. CauseCode ::=
  3095.     INTEGE {
  3096.     requestedFacilityNotSubscribed (50),
  3097. outgoingCallsBarredWithinCUG(53),
  3098. incomingCallsBarredWithinCUG(55),
  3099. inconsistencyInDesignatedOutgoingAccessInformationAndsubscriberClass(62),
  3100. nonExistentCUG(90),
  3101. calledUserNotMemberOfCUG(87),
  3102. incompatibleDestination(88),
  3103. inconsistencyInData(110)\ }
  3104. .sp 1P
  3105. .LP
  3106. 4.5.3
  3107.     \fIAllocation and management of operation and error codes\fR 
  3108. .sp 9p
  3109. .RT
  3110. .PP
  3111. The simple approach is to provide one module containing the
  3112. definition of the operations and errors it uses as a self\(hycontained local
  3113. domain.
  3114. .PP
  3115. Before defining a new operation, the application designer should check 
  3116. all modules to see whether a similar operation already exists. To avoid 
  3117. redefining the operation in a number of modules, methods are required which
  3118. allow a module to import the definition of the operations it uses from other
  3119. modules. If the opertion does not exist, the designer should specify it
  3120. locally.
  3121. .PP
  3122. \fIExample:\fR  | Operation code 00000010 has one meaning for ASE1, and
  3123. probably a completely different meaning for ASE2; two domains are
  3124. involved.
  3125. .PP
  3126. Note that many domains may be used by one ASE; however, for
  3127. simplicity, it is assumed in the following that an ASE uses only one
  3128. domain.
  3129. .PP
  3130. In addition to its local operation, an ASE may need to make use of
  3131. operations which are already defined in another domain. There are two methods 
  3132. for doing so: 
  3133. .RT
  3134. .LP
  3135.     \(em
  3136.     import operation and error types from other modules;
  3137. .LP
  3138.     \(em
  3139.     import operation and error values from other
  3140. modules.
  3141. .sp 1P
  3142. .LP
  3143. 4.5.3.1
  3144.     \fIImport of types\fR 
  3145. .sp 9p
  3146. .RT
  3147. .PP
  3148. The definition of an operation type includes the notational aspects (see 
  3149. the OPERATION MACRO above), without allocating the code values. 
  3150. .PP
  3151. It may be desirable to import the type of an already existing
  3152. operation, however the importing module may want to allocate its own local
  3153. codepoint to the imported operation or error. The imported operation or 
  3154. error becomes a member of the local domain of that module. 
  3155. .bp
  3156. .PP
  3157. If two different modules import a given operation by type, its
  3158. codepoint in each of the importing local domains is generally
  3159. different.
  3160. .PP
  3161. Importing by type allows a common description of operations.
  3162. A module importing by types only uses a single domain (its local
  3163. domain), as represented in Figure\ 4/Q.775.
  3164. .RT
  3165. .LP
  3166. .rs
  3167. .sp 11P
  3168. .ad r
  3169. \fBFigure 4/Q.775, (N), p.\fR 
  3170. .sp 1P
  3171. .RT
  3172. .ad b
  3173. .RT
  3174. .sp 1P
  3175. .LP
  3176. 4.5.3.2
  3177.     \fIImport of values\fR 
  3178. .sp 9p
  3179. .RT
  3180. .PP
  3181. When operation values are imported, the type and the coding are the same 
  3182. in the exporting and importing ASEs. 
  3183. .PP
  3184. A module importing operations or errors by value makes use
  3185. of:
  3186. .RT
  3187. .LP
  3188.     \(em
  3189.     a local domain for its local operations and
  3190. .LP
  3191.     \(em
  3192.     the exporting domains for its imported operations.
  3193. .PP
  3194. A global value is required in the second case to avoid ambiguity between 
  3195. local codepoints and imported codepoints, as represented in 
  3196. Figure\ 5/Q.77.
  3197. .LP
  3198. .rs
  3199. .sp 12P
  3200. .ad r
  3201. \fBFigure 5/Q.775, (N), p.\fR 
  3202. .sp 1P
  3203. .RT
  3204. .ad b
  3205. .RT
  3206. .sp 1P
  3207. .LP
  3208. 4.6
  3209.     \fIApplying the concept to service protocols\fR 
  3210. .sp 9p
  3211. .RT
  3212. .PP
  3213. The first step, before assigning operation codes, is to examine the service 
  3214. ASEs (each an integrated set of actions) and assign them to AEs. The 
  3215. extremes are, on one hand, that all service ASEs are assigned to one AE 
  3216. and, on the other hand, that each AE is composed of only one service ASE. 
  3217. The likely 
  3218. case is several groupings of service ASEs.
  3219. .PP
  3220. Each AE should be identified by a SSN, but not necessarily a fixed SSN 
  3221. specified in Recommendation\ Q.713. Within an AE, an operation code assignment 
  3222. scheme is used, so that no two operations can have the same operation 
  3223. code.
  3224. .RT
  3225. .LP
  3226. .bp
  3227. .LP
  3228. \fBMONTAGE:\ \fR PAGE 134 = PAGE BLANCHE
  3229. .sp 1P
  3230. .RT
  3231. .LP
  3232. .bp
  3233. .sp 1P
  3234. .ce 1000
  3235. \v'3P'
  3236. SECTION\ 2
  3237. .ce 0
  3238. .sp 1P
  3239. .ce 1000
  3240. \fBTEST\ SPECIFICATION\fR 
  3241. .ce 0
  3242. .sp 1P
  3243. .sp 2P
  3244. .LP
  3245. \fBRecommendation\ Q.780\fR 
  3246. .RT
  3247. .sp 2P
  3248. .ce 1000
  3249. \fBSIGNALLING\ SYSTEM\ NO.\ 7\ TEST\ SPECIFICATION\fR 
  3250. .EF '%    Fascicle\ VI.9\ \(em\ Rec.\ Q.780''
  3251. .OF '''Fascicle\ VI.9\ \(em\ Rec.\ Q.780    %'
  3252. .ce 0
  3253. .sp 1P
  3254. .ce 1000
  3255. \fBGENERAL\ DESCRIPTION\fR 
  3256. .ce 0
  3257. .sp 1P
  3258. .LP
  3259. \fB1\fR     \fBGeneral\fR 
  3260. .sp 1P
  3261. .RT
  3262. .PP
  3263. This Recommendation is an introductory Recommendation to the test specifications 
  3264. of Signalling System\ No.\ 7. The test specifications are 
  3265. contained in Recommendations\ Q.781\(hyQ.783. This Recommendation defines 
  3266. the scope and purpose of the test specification and identifies guidelines 
  3267. that are either specific to the particular protocol under test, or are 
  3268. more general. In 
  3269. addition it identifies functional requirements imposed by the test
  3270. specification.
  3271. .RT
  3272. .sp 2P
  3273. .LP
  3274. \fB2\fR     \fBGeneal principles of test specifications\fR 
  3275. .sp 1P
  3276. .RT
  3277. .PP
  3278. The test specification aims at testing protocol conformance in a
  3279. given implementation. This is independent of a given implementation and does
  3280. not generally imply any modification of the signalling point under test.
  3281. However, it is recognized that certain tests require capabilities of the 
  3282. system that are not explicitly defined in the relevant Recommendation, 
  3283. and these 
  3284. capabilities may not be present in all implementations. As a consequence,
  3285. certain tests may not be possible in all implementations.
  3286. .RT
  3287. .sp 2P
  3288. .LP
  3289. \fB3\fR     \fBScope of the test specification\fR 
  3290. .sp 1P
  3291. .RT
  3292. .PP
  3293. The test specification is intended to cover all aspects of
  3294. Signalling System\ No.\ 7. However the initial Recommendations cover the 
  3295. message transfer part\ Q.701\(hyQ.707, and the telephone user part\ Q.721\(hyQ.724. 
  3296. The test 
  3297. specification is not a definition of the protocol, this is contained in
  3298. Recommendations\ Q.701\(hyQ.707 and Q.721\(hyQ.724 as appropriate.
  3299. .RT
  3300. .sp 2P
  3301. .LP
  3302. \fB4\fR     \fBField of application\fR 
  3303. .sp 1P
  3304. .RT
  3305. .PP
  3306. The test specification applies in the international network, and if appropriate 
  3307. in the national network. In the international network, the actual tests 
  3308. to be performed will be the subject of appropriate bilateral agreements 
  3309. beween the two or more Administrations/RPOAs concerned. 
  3310. .RT
  3311. .sp 2P
  3312. .LP
  3313. \fB5\fR     \fBMethod of application\fR 
  3314. .sp 1P
  3315. .RT
  3316. .PP
  3317. The test specification fulfils the requirements for both validation testing 
  3318. and compatibility testing. See \(sc\(sc\ 5.1 and 5.2 for an explanation 
  3319. of 
  3320. these terms.
  3321. .PP
  3322. All tests in the test specification are validation tests (VAT), and in 
  3323. addition those marked with an asterisk are also compatibility tests 
  3324. (CPT).
  3325. .bp
  3326. .RT
  3327. .sp 1P
  3328. .LP
  3329. 5.1
  3330.     \fIValidation testing\fR 
  3331. .sp 9p
  3332. .RT
  3333. .PP
  3334. The function of validation testing is to check that a given
  3335. implementation conforms to the relevant CCITT Recommendations of the Signalling 
  3336. System. These validation tests could apply both in the national and 
  3337. international networks. The validation test is a pre\(hyrequisite of compatibility 
  3338. testing (see \(sc\ 5.2) and is performed under the responsibility of each 
  3339. Administration/RPOA. These tests will generally be performed without the
  3340. cooperation of another Administration/RPOA, although this is not precluded
  3341. should this arrangement prove convenient. Validation testing will be performed 
  3342. on a signalling point that is not in service. 
  3343. .PP
  3344. The validation test is performed on one signalling point.
  3345. .PP
  3346. It is suggested that the validation test, or subset, is repeated when the 
  3347. implementation is upgraded or modified in any functional way. 
  3348. .PP
  3349. Validation testing may require the use of a simulator to check the
  3350. operation of the signalling point under test. The specification of this
  3351. simulator is not explicitly covered by these Recommendations although the
  3352. general requirements are implicit in the test specification.
  3353. .PP
  3354. In validation testing, the signalling point under test is called
  3355. SP\*QA\*U.
  3356. .RT
  3357. .sp 1P
  3358. .LP
  3359. 5.2
  3360.     \fICompatibility testing\fR 
  3361. .sp 9p
  3362. .RT
  3363. .PP
  3364. The objective of compatibility testing is to check for the correct interworking 
  3365. of two implementations. To perform compatibility testing the two nodes 
  3366. involved are interconnected. The specification is written for the 
  3367. interconnection of two given implementations for the first time. For subsequent 
  3368. interconnections of the same two implementations a subset of tests may 
  3369. prove 
  3370. sufficient. These tests will not only be performed on a new signalling 
  3371. point, but also on a signalling point already in service. 
  3372. .PP
  3373. Each Recommendation identifies a list of tests that may be suitable
  3374. for compatibility testing, but the actual tests to be performed will be
  3375. bilaterally agreed between the Administrations/RPOAs concerned.
  3376. .PP
  3377. Certain of the tests identified in the test list as compatibility test 
  3378. may disturb the operation of the exchange, whereas others may not. Any 
  3379. tests 
  3380. which may cause disturbance to the exchange should be carefully selected to
  3381. meet the operational criteria of the two Administrations/RPOAs.
  3382. .PP
  3383. The satisfactory completion of compatibility testing should be
  3384. bilaterally agreed.
  3385. .PP
  3386. When a change to the signalling network is made, tests selected from those 
  3387. identified as compatibility tests may be appropriate. In general the 
  3388. tests performed under these circumstances will be the minimum number to 
  3389. ensure that compatibility between points in the network is still maintained. 
  3390. .PP
  3391. In compatibility testing, each signalling point may in turn consider itself 
  3392. to be SP\*QA\*U, i.e.\ tests are performed on both signalling points 
  3393. involved.
  3394. .RT
  3395. .sp 1P
  3396. .LP
  3397. 5.3
  3398.     \fITest configuration\fR 
  3399. .sp 9p
  3400. .RT
  3401. .PP
  3402. For both validation and compatibility testing the point under test is connected 
  3403. to the test environment and becomes part of the \*Qtest 
  3404. configuration\*U. The test configuration satisfies all of the following
  3405. three criteria:
  3406. .RT
  3407. .LP
  3408.     \(em
  3409.     The point under test will be connected by one or more
  3410. signalling linksets (real or simulated), which may or may not be
  3411. interconnected.
  3412. .LP
  3413.     \(em
  3414.      The capability of generation and reception of test traffic, where applicable. 
  3415. .LP
  3416.     \(em
  3417.     The ability to perform the described test, notably the
  3418. facility to store and analyze messages to the appropriate degree.
  3419. .sp 2P
  3420. .LP
  3421. \fB6\fR     \fBFunctional requirements imposed by the test specification\fR 
  3422. .sp 1P
  3423. .RT
  3424. .PP
  3425. The functional description that follows is intended to identify the functional 
  3426. requirements imposed by the test specification. It does not imply 
  3427. any physical partitioning of equipment in real systems. See also
  3428. Recommendation\ Q.701, \(sc\ 2.2.1.
  3429. .RT
  3430. .sp 1P
  3431. .LP
  3432. 6.1
  3433.     \fILevel 1\fR 
  3434. .sp 9p
  3435. .RT
  3436. .PP
  3437. The test specification assumes the availability of a suitable
  3438. signalling data link with the parameters identified in the relevant
  3439. Q\ Recommendations, e.g.\ Q.702 (referring to Recommendation\ G.821).
  3440. .PP
  3441. In validation testing the signalling data link may be a
  3442. pseudo\(hysignalling data link, in which case it should preferably have
  3443. similar/identical
  3444. characteristics to the signalling data links likely to be encountered in
  3445. service. Simulation of deterioration of the transmission link may not be
  3446. necessary if the emulator includes the capability to simulate abnormal
  3447. conditions on the signalling data link.
  3448. .PP
  3449. In compatibility testing the signalling data link is the actual
  3450. signalling data link that will be used in service.
  3451. .bp
  3452. .RT
  3453. .sp 1P
  3454. .LP
  3455. 6.2
  3456.     \fILevel 2\fR 
  3457. .sp 9p
  3458. .RT
  3459. .PP
  3460. The level 2 test environment consists of four items (see
  3461. Figure\ 1/Q.780):
  3462. .RT
  3463. .LP
  3464.     \(em
  3465.     the level 3 simulator;
  3466. .LP
  3467.     \(em
  3468.     the test simulator;
  3469. .LP
  3470.     \(em
  3471.     the signalling link monitor (see \(sc 7);
  3472. .LP
  3473.     \(em
  3474.     the signalling data link.
  3475. .sp 1P
  3476. .LP
  3477. 6.2.1
  3478.     \fILevel 3 simulator\fR 
  3479. .sp 9p
  3480. .RT
  3481. .PP
  3482. During the level 2 tests it is necessary to inject signalling
  3483. messages and indications to and from the level\ 2 under test. It is desirable
  3484. that the level\ 3 function used is the actual level\ 3 of the MTP with some
  3485. additional functions for test purposes.
  3486. .RT
  3487. .sp 1P
  3488. .LP
  3489. 6.2.2
  3490.     \fITest simulator\fR 
  3491. .sp 9p
  3492. .RT
  3493. .PP
  3494. During level 2 testing it is necessary to inject some abnormal
  3495. signal units (as well as normal signal units) to fully test the level\ 
  3496. 2 under test, the test simulator should have this function. In addition 
  3497. the simulator should have the capability to receive and check signal units 
  3498. from the level\ 2 under test. The generation of certain abnormal sequences 
  3499. of signal units should also be a capability of the test simulator. 
  3500. .RT
  3501. .sp 1P
  3502. .LP
  3503. 6.3
  3504.     \fILevel 3\fR 
  3505. .sp 9p
  3506. .RT
  3507. .PP
  3508. The level 3 test specification assumes that the level 2 has already been 
  3509. tested satisfactorily. However, certain tests will in addition explicitly 
  3510. test the level\ 2/3 interface. 
  3511. .PP
  3512. The level 3 test environment consists of 3 items (see
  3513. Figure\ 2/Q.780):
  3514. .RT
  3515. .LP
  3516.     \(em
  3517.     the simulator of upper levels;
  3518. .LP
  3519.     \(em
  3520.     simulated network including test simulator and signalling
  3521. data links;
  3522. .LP
  3523.     \(em
  3524.     the signalling link monitor(s) (see \(sc 7).
  3525. .sp 1P
  3526. .LP
  3527. 6.3.1
  3528.     \fISimulator of upper levels\fR 
  3529. .sp 9p
  3530. .RT
  3531. .PP
  3532. During level 3 testing it is necessary to inject signalling
  3533. messages into level\ 3 for testing, e.g.\ message loss during changeover. 
  3534. It is desirable that the simulator used should be as close as possible 
  3535. to the actual upper level to be used. In addition an MML interface is assumed. 
  3536. The level\ 3 
  3537. under test must use an already tested level\ 2.
  3538. .RT
  3539. .sp 1P
  3540. .LP
  3541. 6.3.2
  3542.     \fISimulated network including test simulator\fR 
  3543. .sp 9p
  3544. .RT
  3545. .PP
  3546. During level 3 testing it is necessary to inject some abnormal
  3547. messages (as well as normal messages) to check the level\ 3 under test, the
  3548. simulated network including test simulator should have this function. In
  3549. addition the test simulator should have the capabilities to receive and 
  3550. check messages from the level\ 3 under test. The generation of certain 
  3551. abnormal 
  3552. sequences of messages should also be a capability of the test simulator. The
  3553. test simulator must include an already tested level\ 2.
  3554. .RT
  3555. .sp 1P
  3556. .LP
  3557. 6.4
  3558.     \fITUP\fR 
  3559. .sp 9p
  3560. .RT
  3561. .PP
  3562. The TUP test specification assumes a tested MTP for compatibility tests 
  3563. but no assumption is made about message transfer between the TUP under 
  3564. test and the TUP tester for validation tests.
  3565. .PP
  3566. The TUP test environment consists of three items (see
  3567. Figure\ 3/Q.780):
  3568. .RT
  3569. .LP
  3570.     \(em
  3571.     the TUP tester;
  3572. .LP
  3573.     \(em
  3574.     a stable signalling relation and telephone circuits;
  3575. .LP
  3576.     \(em
  3577.     a monitor of TUP messages and telephone circuits.
  3578. .sp 1P
  3579. .LP
  3580. 6.4.1
  3581.     \fITUP tester\fR 
  3582. .sp 9p
  3583. .RT
  3584. .PP
  3585. The TUP tester is required to simulate TUP protocol operations and some 
  3586. exchange call control operations. 
  3587. .bp
  3588. .RT
  3589. .sp 1P
  3590. .LP
  3591. 6.4.2
  3592.     \fIMonitor\fR 
  3593. .sp 9p
  3594. .RT
  3595. .PP
  3596. The monitor is required to monitor and record TUP message sequences and 
  3597. to monitor the result of call control operations on the controlled 
  3598. telephone circuits. This includes checking that tones are correctly received
  3599. and that speech/information transfer is possible.
  3600. .RT
  3601. .sp 2P
  3602. .LP
  3603. \fB7\fR     \fBSignalling link monitor(s)\fR 
  3604. .sp 1P
  3605. .RT
  3606. .PP
  3607. The test specification assumes the availability of a signalling
  3608. link monitor and a suitable access point for connection of the monitor as
  3609. specified in Recommendation\ Q.702, \(sc\ 4.
  3610. .PP
  3611. The test specification does not attempt to specify what a signalling link 
  3612. monitor should be, but instead the functional requirements are identified 
  3613. in general terms. A signalling link monitor will be used for decoding of 
  3614. signal unit sequences during testing and to give the operator confidence 
  3615. that the 
  3616. signalling protocol has been correctly observed.
  3617. .PP
  3618. The requirements imposed on a signalling link monitor will be
  3619. different for the two types of testing. For validation testing detailed
  3620. decoding down to a field level will be required, but for compatibility 
  3621. testing decoding down to a message level may be adequate. 
  3622. .PP
  3623. In addition it should be noted that compatibility testing will be a
  3624. function performed numerous times on a signalling point, whereas validation
  3625. testing will be performed once only, except under certain circumstances of
  3626. upgrading of the signalling point.
  3627. .PP
  3628. \fINote\fR \ \(em\ It should be oserved that implementations may include a
  3629. signalling link monitor as an intrinsic part of the signalling point, however, 
  3630. for validation testing this cannot necessarily be relied upon. In addition, 
  3631. the test specification does not attempt to perform the function of testing 
  3632. the 
  3633. accuracy of any signalling link monitor implemented in the signalling point,
  3634. however, certain conclusions will inevitably be made from the performance of
  3635. validation testing.
  3636. .RT
  3637. .LP
  3638. .rs
  3639. .sp 20P
  3640. .ad r
  3641. \fBFigure 1/Q.780, (N), p.\fR 
  3642. .sp 1P
  3643. .RT
  3644. .ad b
  3645. .RT
  3646. .LP
  3647. .bp
  3648. .LP
  3649. .rs
  3650. .sp 27P
  3651. .ad r
  3652. \fBFigure 2/Q.780, (N), p.\fR 
  3653. .sp 1P
  3654. .RT
  3655. .ad b
  3656. .RT
  3657. .LP
  3658. .rs
  3659. .sp 20P
  3660. .ad r
  3661. \fBFigure 3/Q.780, (N), p.\fR 
  3662. .sp 1P
  3663. .RT
  3664. .ad b
  3665. .RT
  3666. .LP
  3667. .bp
  3668.