l node of its own. Centralized control solutions to a PCS might be a reasonable solution to embed- ded systems or locally distributed systems, but it certainly is not for telecom net- works. Here we must deal with a constantly changing picture of a large quantity of resources (switches, routes and teleservice resources) and many users, all distrib- uted over wide areas. It would be devastating for the fault tolerance of the network, as well as on the load and response time, if all resource system state changes had to be recorded at a central point. Instead of providing useful services to network users, the PCS would have time to do nothing but handle centralized object resource models, and process messages to and from resource controllers. The solu- tion to this problem is to partition the object resource models, and allocate the parts to parts of the TEPC and CNPC. This also requires that the parts of TEPC and CNPC keep each other informed about state changes that regard abstracted resource models, such as the CNW, TNW and core routes. Let's see what this means for, e.g. the CNPC. Figure 6.29 suggests a solution to decentralized control 6.2 A Service Network Modelling Case for CNPC, where the CNPC is separated into two objects, called the master-CNPC and the slave-CNPC. Operations: cnuConnREQ cnuDiscORD devStateC_REP blockDevORD deblockDevORD CNPC, master CNPC, slave master-ORM slave-ORM master slave AR and "SW1" AccRoute CoreRoute AccRoute Controller Manager Manager Manager Controller AR1..AR3 CR1,IR1 AR4..AR6 Fig. 6.29 A decentralized control solution to the CNPC The two parts of CNPC must share knowledge about the original object resource model of CNPC. Each part can take full responsibility for its own access routes and switch, but they need some common knowledge regarding the CNW. However, sharing information about routes and switches to some extent can be useful as well. For example, if one of the access routes that connects PN2 to its terminal systems becomes blocked due to some fault, there are two choic