el(crA) AnotInCall E-nwServRel(crE) AnotInCall Some abstract service primitives: Parameters: Values: servRequest(servid OPT,destSAPI OPT,callRef) servId service identifier servInvite(servld,origSAPIOPT,callRef) origSAPI originating TE-SAPI conRequest(conld,TR-SAPI,TR-SAPI destSAPi destination TE-SAPI conConfirm(conld,SET OF Chan OPT) callRef call reference crA and crE Chan::=(TR-SAPI,chld} conld connection identifier conld15 OPT optional parameter TR-SAPI CNU1 and CNU5 Fig. 6.25 The behaviour of TEPC in providing the teleservice X to users identified by TE-SAPI A and E; A is the calling party Activities in transition 1: When receiving the servReq from TECA, TEPC accesses the object resource model (see Fig. 6.21) to check the TNW congestion state. It also checks if TECA's and/or TECE's access routes are blocked. If no congestion or blocking, TEPC accesses the object resource model with TE-SAPI=A and servid=x, to see if TECA is allowed to use the service (accord- ing to the property subscription for TE-SAPI=A). If so, TEPC must find out if TECE can take another connection. TEPC sees from the subscription if TECE is an ISDN subscriber (can take two connections) or another type of subscriber (takes only one connection). By looking into the object resource model, TEPC can find out how many connections are already used to the corresponding CNU. If TECE can take another connection, TEPC accesses the object resource model with TE-SAPI=A and TE-SAPI=E, to see if the two Terminal Systems are com- patible for servld=x (according to the property capability for both TE-SAPIs). 6.2 A Service Network Modelling Case If so, TEPC analyses if a teleservice resource is needed for servld=x, consider- ing the capabilities of TECA and TECE (no resource is needed in this scenario). TEPC now knows that the precondition for this transition is true. TEPC then creates a calld=y for the call, assigns the call reference crE for TECE and relates y to crA and crE in the TNW. TEPC sets the statelnCall attribute to inCall for crA, and to pending 