 states semantics, i.e. meaning to states (understanding the meaning of a resource state is a prerequisite for defining behav- iour that leads to some wanted result.) Resource models are, however, also the basis for defining good operations, since operations are what cause resource state changes. Thus, service resource models are the most basic and most important models produced in service network modelling. It is important to realize that a service resource model does not (and shall not) define which operations might be needed in the service relation. The service resource model only provides the terminology and rules for how service resource model instances can be changed. Operations are defined separately, based on the entities, relations, properties and rules that exist in the service resource model. Let's look at an example, see Fig. 6.13. Alternative 1: serv1Req(servld,origSAPI,destSAPI) serv1Cnf(-) TNW properties are: serv1Ref(cause(unknownSAPI,servNotAllowed, *congState calledPartyBusy,capNotComp,tnwCong}) Call properties are: Alternative 2: calls #'callid 'teuList checkCapReq(servld,origSAPI,destSAPI) TEU properties are: checkCapCnf(capList,EMPTY) #*TE-SAPI checkCapRef(cause(unknownSAPI,servNotAllowed *subscription destSAPlbusy}) serv2Req(servld,origSAPI,destSAPI) "capability serv2Cnf() serv2Ref(cause(calledPartyBusy,tnwCong}) Fig. 6.13 Operations for requesting a call between a TEC and the TEPC 6 Process Control System Modelling The model shows two possible operation solutions for setting up a call: The straightforward way to set up a call is to define an operation, serv1REQ, that in the Request primitive delivers all parameters that TEPC needs. TECP verifies that the user on the origSAPI is allowed to use servId, by looking in the subscription list for the calling party. If so, TEPC checks that the two parties are compatible (given by the capability lists for the two parties). If so, TEPC tries to set up a call (by using the service of CNPC and of appropriate teleservice resource controllers). The Refus