d models (SW1, SW2, AR, CR and CNU) that it has in common with the resource controllers. Each resource controller handles one particular resource or type of resource in the network. Resource controllers do not know how resources are interconnected in the network. This must be known by the CNPC and TEPC, and is abstracted into the connection network model (CNW) and in the teleservice network model (TNW). The CNPC does not know which users exist (identified by TE-SAPIs), which serv- ices each user can handle, which services a user is allowed to use, which teleserv- 6 Process Control System Modelling ice resources are needed for the call or if a user is busy or not. This is instead known by the TEPC, and is abstracted into the teleservice network model (TNW). Thus, the CNW is an abstraction of the real connection network, and the TNW an abstraction of the real teleservice network (based on the CNW and on TRs). Models on the three levels must be formally related SO that, e.g. a service request that refers to the TNW can be mapped on requests referring to the CNW and TR controllers, and requests referring to the CNW can be mapped on requests referring the SWs, ARs and CRs. There is obviously a hierarchical dependency between abstractions on these three levels. We say that the structure of service resource models defines an abstraction hierarchy that is reflected by the control structure of the PCS. As a matter of fact, this characterizes all service networks, and is one of the unique fea- tures of service networks, compared to other types of models in the integration hierarchy. The behaviour of the service network is based on its abstraction hierarchy, i.e. the relations between service resource models. We therefore need to make these models explicit. Figure 6.8 provides, in an intuitive notation, the service resource models for all resource controllers in the connection network. SW1, SW2: Switch properties are: *#swld{SW1,SW2} *congestionState *blockingState Position properties are: *#posld{1..1920} Path properties a