conReq(conId15, conREQ CNU1,CNU5) userConRelORD pending state) nwConRelC_REP conRet(conlà15, conCnf(conId15) cause{...}) lie: conld15No CNU1andCNU5 nwConRelRepCnf longerNeeded Connected (conld15,cause) CNW service states, user side: AR1andAR5 AR1andAR5 notConnected pending state) Connected {TR-SAPI CNU1} {TR-SAPICNU1} conTo {conld conld15} {TR-SAPI CNU5} {TR-SAPI CNU5} conTo Identifiers: TR-SAPI, conld Values: CNU1, CNU5, conld15 Fig. 6.23 A possible service behaviour of TEPC in the interface towards CNPC The diagrams in Fig. 6.16 and 6.23 and the object resource model in TEPC are the ingredients we need for defining the behaviour of TEPC. Figure 6.24 shows the part of the PCS service network model that concerns TEPC, and all the prerequi- sites for describing the behaviour of the TEPC. The TEPC is serving many TECs in parallel, but we will describe the behaviour for setting up a call between TECA, identified by TE-SAPI=A, and a TECE identified by TE-SAPI=E. Note that an additional operation, servINVITE, is added to the operation list for S1. This opera- tion is needed on the called side for offering the call. If, e.g. TECA is the caller, TECA will use the operation servREQUEST to call TECE, and TECE will be offered the call to TECA by TEPC with servINVITE. In reality, the two TECs will most likely be physically separated, however, this is of no concern to the service network, as regards communication between the TECs and the TEPC. Although we will want to design the TEPC as a modular sys- tem of communicating service objects (in order to enhance performance of the TEPC), this is a modification of the model in Fig. 6.24 that we will be dealing with later (see Sect. 6.2.7). 6.2 A Service Network Modelling Case (TE-SAPI=A) (TE-SAPI=E) S1 operations: servREQUEST servINVITE TEPC object resource model userServIntORDER See Fig. 6.20 userServRelORDER See Fig. 6.10 nwServRelC_REPORT S1 behaviour: See Fig. 6.15 (left) See Fig. 6.9 S2 operations: conREQ userConRelORD nwConRelC_REP S2 behaviour: See Fig. 6.22 Fig. 6.24 The 