Kapsch: Reconfiguration of Mobile Phone Networks - Case Studies - Knowledge-based Configuration: From Research to Business Cases, FIRST EDITION (2014)

Knowledge-based Configuration: From Research to Business Cases, FIRST EDITION (2014)

Part IV. Case Studies

Chapter 19. Kapsch: Reconfiguration of Mobile Phone Networks

Iulia Nicaa, Franz Wotawaa, Roland Ochenbauerb, Christian Schoberb, Harald Hofbauerc and Sanja Boltekc, aGraz University of Technology, Graz, Austria, bKapsch Business Com, Vienna, Austria, cKapsch Carrier Com, Vienna, Austria


Often needed together, simulation and configuration play an important role in industry, from the early development stages as well as after deployment as part of system maintenance. Changes of a system’s structure or behavior over time are required because of changing requirements due to new customer needs. For example, the current worldwide willingness to adopt smart power grid technologies raises new challenges regarding the necessary adaptations in the structure and functionality of the existing mobile phone networks. In this chapter, we motivate the importance of both simulation and (re) configuration of mobile phone networks in the context of machine-to-machine communication, in order to deal with future markets of intelligent transportation systems and smart metering. We discuss our SIMOA approach for simulation and (re) configuration that is based on a system model and system requirements. The approach has the following advantages: it is flexible and adaptable to various systems and needs, it determines the system’s capabilities to handle certain requirements, and suggests system adaptations in cases where the requirements cannot be satisfied.


Knowledge-based Configuration; Model-based Configuration; Machine-to-Machine Communication; Configuration Application; Modelling for Configuration; Knowledge Representation Language; Smart Metering


The work presented in this paper has been supported by the BRIDGE research project Simulation and Configuration of Mobile networks with M2M Applications (SIMOA), which is funded by the FFG.

19.1 Introduction

The machine-to-machine (M2M) communication market is expected to grow in the coming years and to become the largest customer of mobile phone network operators. The application scenarios of M2M communication are many faceted. Currently, the field of main application of M2M communication is smart metering, providing a direct link between power suppliers and electricity meters at home, and on tracking of vehicles and goods in the transportation industry. In this chapter, we focus on the first scenario (linking electricity meters at home).

These smart metering application scenarios not only provide advantages for companies but also additional benefits for the customers. For example, smart metering solutions have the potential to avoid blackouts by limiting power consumption far before a blackout might occur. Another example is image emission reduction in the electricity sector. More and more people produce and consume energy independently and feed unspent energy into the network. One hope in this context is to reach greater energy efficiency through short meter-reading intervals, as these allow the customers to control their energy consumption throughout the day. Energy network operators are then able to collect consumption data more frequently and to provide this data to end consumers in a transparent way. To complete all these tasks, intelligent communication solutions are needed, which are able to handle increased data volumes over the wireless networks and especially over mobile GPRS/UMTS networks. Originally, communication infrastructures were not designed to fulfill the requirements of the mentioned M2M communication scenarios.

The Kapsch Smart Energy Management System for metering and building automation offers a future-proof, open, and manufacturer-independent solution, which fits the needs of all the groups involved: from end consumers, building owners, and facility managers to network operators and energy suppliers. In this context, functionalities that support a detailed analysis of alternative smart metering scenarios are highly requested. In order to support such functionalities, simulations of various parts of a mobile network such as cell, backbone, and data storage have to be conducted. The major purpose of such a simulation is to check whether a network configuration can support a set of given user requirements. In order to simulate the dynamics of a mobile network, we treat each part of the mobile network, which is to be simulated, as a state machine with a predefined number of states. For example, in one particular state a component might be active whereas in another one this is not the case. Another example is a network configuration that may change from state to state in order to handle different communication requirements.

If a simulation fails (the requirements cannot be fulfilled by the mobile network), a working reconfiguration of the given system has to be delivered. In particular, adding too many M2M devices to a cell configuration might lead to an unacceptable reduction of service availability, which can only be handled by changing the default value of the parameters in the cell (for instance, by increasing the number of serving frequencies) or by extending the communication network via adding new mobile phone cells.1 A cell configuration contains one base station, a number of metering devices, and a base load value.

The major contributions of the chapter are the following: (1) we provide important insights into the principles of knowledge-based reconfiguration in the domain of M2M communication networks, and (2) we discuss major business cases that are related to the application of (re) configuration technologies in the context of mobile phone networks and M2M applications.

The remainder of this chapter is organized as follows. In Section 19.2 we discuss in more detail the major requirements regarding the support of M2M communication scenarios. Afterward, we introduce an application scenario and give an overview of the SIMOA approach (Section 19.3). In Section 19.4 we discuss relevant business cases that are related to the application of SIMOA technologies. With Section 19.5 we conclude this chapter.

19.2 Domain Requirements

Unlike today’s mobile networks, the future GPRS (General Packet Radio Service) networks used in Automatic Meter Management (AMM) communication have to support the following requirements:

• The GPRS networks have to be highly reliable and extensible.

• There must be a large IP address pool available.

• There is a required data amount specified for AMM communication.

• The amount of data communicated via a GPRS network varies depending on the AMM readout frequency2 and the used communication protocols, such as the DLMS/COSEM or the IEC61107 protocol.

These requirements are of great importance for the configuration process. The user should be able to add a large number of devices in the network and the device type is either already defined in the knowledge base or a new type can be additionally defined. The last two requirements limit the space of possible reconfigurations by means of constraints stated over the data amount transferred in the network.

Figure 19.1 illustrates a simplified cell from a smart grid,3 taking into consideration the GPRS data communication on the one side and the electric power transmission from the power generation station to smart meters on the other side (depicted in gray). Note that SIMOA simulation and (re) configuration focuses on GPRS data communication settings.

FIGURE 19.1 Schematic representation of a Smart Grid Cell containing a base transceiver station (BTS), one P2P smart meter, three PLC smart meters, connected to one Data concentrator, and a Mobile phone. The base station facilitates at cell level the data transfer from the P2P meter and data concentrator to the central meter management office, called AMM application.

As depicted in Figure 19.1, IP-enabled meters (Point-to-Point (P2P) individually addressable smart meters), which are connected directly to the WAN (Wide Area Network) using GPRS, communicate with the AMM application, without requiring data concentrators4 in the field. The meters connected to data concentrators are called PLC (Power Line Carrier) meters. The usage of P2P meters becomes inevitable when the connection distance between a meter and a data concentrator is too large (more than 300 meters). In the simulation process we have to take into account the following variants of M2M terminals in a specific cell: (1) only P2P meters, (2) only data concentrators with PLC meters, and (3) both P2P meters and data concentrators with PLC meters.

In Figure 19.1, the Smart Grid (GPRS) cell comprises the following parts:

• Base Transceiver Station (BTS): Facilitates the wireless communication between user equipment (mobile phones, smart meters, etc.) and the network. The BTS has the equipment for encrypting and decrypting communications, spectrum filtering tools, antennas, and so on. Typically a BTS has several transceivers (TRXs) that allow it to serve several different frequencies and allocates a number of time slots for the M2M communication in the cell.

• P2P meters and Data Concentrators: These are described by configurable attributes that represent fixed or variable data amounts (derived from the chosen transfer protocols), network topology (determined by the distance between BTS and data concentrators/P2P meters), and in the case of data concentrators, the number of PCL meters connected to them.

• GPRS base load represented by the Mobile phone in Figure 19.1 and which represents all the non-smart-metering traffic in the cell.

It is worth noting that the structure of mobile phone networks varies and that communication requirements depend on the M2M application scenario. A typical AMM scenario is, for instance, the transfer of the daily load profiles5 from the meters to the AMM application within a defined time period. In this case, the traffic from the cell to the AMM application is investigated. Given, for instance, a GPRS cell with M2M communication capabilities comprising, among others, P2P meters, data concentrators, and mobile phones, we are interested in checking if the defined cell can handle the transfer of the load profiles or not. If the transfer is not possible (because there are insufficient time slots allocated for M2M communication in the cell or the transfer rate is too low due to the given channels encodings), a reconfiguration of the cell is required. This task comprises the identification of the inconsistent requirement(s) in the default configuration as, for instance, the assignment of an insufficient number of time slots for M2M communication, and changing the values of the corresponding attributes such that the new configuration is consistent. In another scenario, a large number of smart metering devices has to be simultaneously shut down by the power supply company in order to avoid a blackout. In this case, a pre-specified maximum delay (e.g., 2 minutes) between issuing the command and receiving it on side of the smart metering device must not be exceeded.

Hence, a solution for showing that a communication network fulfills the requirements of M2M application scenarios and taking counter measures in case of detected shortcomings has to be flexible and adaptable.

19.3 SIMOA Approach

From the application domain we are able to derive the requirements for a tool that provides change operations for the given mobile network taking into account future usage scenarios. The future usage scenarios are determined by the communication needs of M2M applications (see, for example, the two scenarios discussed in the previous section). In the following, we discuss tool requirements with regard to the knowledge representation language, simulation features, reconfiguration, and optimization functionalities.

Language. In order to support the discussed scenarios, we need information about the structure and behavior of mobile networks and related usage scenarios. Due to the huge variety of networks and usage scenarios, a modeling language has to be provided for formalizing the information. This language has to allow for stating the structure of a system and the behavior of its components. Temporal aspects, such as changes in network access over time, have to be captured as well. Moreover, in case of optimization requirements, the language has to provide means for stating optimality criteria.

Simulation. The first step to evaluate whether an available mobile network is capable of handling all requests imposed by a future M2M application is to simulate the network behavior using the M2M communication requirements. Example requirements might be maximum delays of replies of remote machines on messages sent or the required amount of data to be sent at the same time. If the simulation returns that the network cannot handle certain requirements of the M2M application, someone is interested in finding a reconfiguration of the network that allows for fulfilling the requirements. The simulation itself should be based on the introduced modeling language. In the area of dynamic systems modeling and simulation, we mention Matlab/Simulink and Modelica.6Although both of them are complex languages, capable of modeling a great variety of components, they are less appropriate for (re) configuration purposes, because they cannot handle underconstrained problems where a variety of solutions is possible.

Reconfiguration. Changing an existing network for fulfilling communication scenarios imposed by M2M applications can be done on several levels. Certain parameters of mobile phone cells can be changed in order to provide more channels. New cells can be added to the network, thus changing the network topology. In our application all such possible changes should be reported. The same modeling language that is used for simulation should also be used for providing configuration information.

Optimization. Since there is very likely more than one reconfiguration for handling future communication requirements, an optimal solution would be of great interest. Depending on who the user is, different optimality criteria are to be fulfilled. For instance, a mobile operator would prefer the reconfiguration that offers the best quality of service, whereas a customer would pick the solution with least costs for communication. Therefore, a requirement is that various optimality criteria can be specified and that it is possible to search for reconfigurations fulfilling the optimality criteria.

To handle simulation, reconfiguration, and optimization based on the same underlying information we have adopted a model-based approach. In particular, we have designed a modeling language (SIMOL) that allows for specifying structure and behavior of systems as well as (re) configuration information and requirements. It is also necessary that the language can be used by non-AI experts. This is due to the fact that both the considered network as well as the M2M application requirements change over time and have to be adapted.

The SIMOA approach is model-based and capable of fulfilling all the mentioned requirements. The approach is based on the SIMOL programming language (Nica and Wotawa, 2012), which is an object-oriented language with a Java-like syntax, and on the MINION constraint solver (Gent et al., 2006).

As depicted in Figure 19.2, the resulting SIMOL tool architecture comprises three modules that are connected and interchange information: the SIMOL compiler, which maps the SIMOL program to a set of constraints (the MINION program) and also generates a symbol table that allows for mapping the variables used in the SIMOL program to the variables used in the constraint representation; the CSP solver, that computes a solution for the CSP problem; and the Mapping module, which takes the solutions coming from the constraint solver and changes the variable names to the names used in the original SIMOL program by using the previously generated symbol table. In this context, the reconfiguration core is represented by the CSP representation (MINION program) and the constraint solver; that is, the constraint solver is responsible for determining reconfigurations. The CSP solutions in Figure 19.2 are mapped to the actual reconfigurations, depicted by Solutions in Figure 19.2. A solution to a CSP problem is an assignment of values to variables such that no constraint is violated (see also Hotz et al., 20147).

FIGURE 19.2 The SIMOA tool architecture.

Due to this architecture, the SIMOA tool is general and can be used to solve various tasks. The only requirement is that the domain and the case-specific knowledge are specified using SIMOL.

In Figure 19.3 we depict the UML diagram for a GPRS cell used in the SIMOL model and thus within our current implementation. As we can see, a cell owns one BTS component, a limited number of P2P Meter and Data Concentrator components, and a Base Loadcomponent. Moreover, the GPRS Cell has one attribute that refers to the possible GPRS/UMTS base load (gbase) the non-smart-metering-related data transfer, which is in fact defined in the value attribute of the Base Load component. A P2P Meter component type is described by the distance between the P2P meter and the BTS (mdist), the used codeset (codeset; the channel encoding that influences the amount of data to be transferred within one second), and by the various parameters corresponding to the protocol suites used to retrieve data from a smart device (dbr billing reads, iptlogin M2M gateway logins, etc.). Many of these attributes are to be found in the definition of the Data Concentrator type, but mostly with values depending on the number of PLC meters connected to the concentrator. Both PLC Meter and P2P Meter types are derived from the generic type Smart Meter. A BTS component has two attributes: the number of frequencies (fpc) and the number of time slots (availableTimeSlots), which the BTS allocates for M2M communication in a cell. Note that, unlike the other attributes depicted in Figure 19.3, these two can be automatically reconfigured in case of a failed simulation. In order to do that, two “fake” component types FPC (Frequencies Per Cell) and ATS (Available Time Slots) are introduced in the model (see Figure 19.3). They are “attributes-seen-as-components” types and, when linked to the actual attributes fpc and availableTimeSlots, they are able to reconfigure the given system.

FIGURE 19.3 UML diagram for the GPRS cell model.

For defining the model depicted in Figure 19.3, SIMOL makes use of component types, as illustrated in Figure 19.4. Each defined component possesses a set of attributes and introduces constraints in the system. Besides the constraints stated inside theconstraints{…} block definition, also depicted as general constraints (see Figure 19.4, lines 30–36), SIMOL is able to capture the temporal aspects of the real system by means of state-specific constraints and transition constraints. While general constraints are satisfied in all the states, state-specific constraints are satisfied only in a certain state. The latter ones are provided in an additional observations file that contains at least the initial constraints (for the cell in the initial state). The transition constraints between two consecutive states appear in the transition{…} block and are implemented by means of the next operator (see Figure 19.4, lines 37–42).

FIGURE 19.4 A SIMOL program. For reasons of space limitations, we omitted the attributes dbr,dlpr,doa,iptlogin, etc. in Line 3, their initialization in the constraints section of the Cell component, and also the definition of the ATS component from Figure 19.3.

In our case, the GPRS cell model will be seen as a state machine with a predefined, bounded, number of states, where each state corresponds to different code-sets (attribute codeset) assigned to P2P Meter and Data Concentrator components. Thus, depending on themdist attribute, which represents the distance between the BTS and the current meter m, the m.codeset value can be increased or decreased by following the transition constraints of the GPRS Cell component, as explained in Nica et al. (2012). Based on these transition constraints, the SIMOL compiler will generate for every state the new corresponding constraints.

Components of type “attributes-seen-as-components” have more than one functional mode: the default functional mode and the nondefault modes. For each mode, a set of constraints will be defined (see, e.g., lines 9–20), where the value attribute of the FPCcomponent has to be equal to 1 by default or in the set {2..4} in mode x1. In the unknown mode, no constraint is defined because the behavior of some FPC instances may become unimportant in a certain reconfiguration. For instance, when thinking of the possibility to deactivate smart metering devices, there is no contribution of inactive devices to the overall system behavior. Hence, in this case, no constraints can be defined for the mode representing an inactive component.

By means of combining the previously defined constraints with the multiple inheritance mechanism and the inner component instances declarations, we manage to model three basic categories of configuration knowledge (Rossi et al., 2006): the catalog knowledge, the structural knowledge, and the component constraints. For further details on SIMOL, see Nica and Wotawa (2012).

In the current implementation, the SIMOA reconfiguration algorithm makes use of nondefault functional modes and attribute-to-component extensions for determining reconfigurations.

In SIMOA, the representation of a reconfiguration problem is based on the following definition.


Reconfiguration problem

A tuple image represents a reconfiguration problem where image denotes the configuration knowledge; that is, the system structure and the provided functionality as well as general system constraints, image denotes the desired new system requirements, image is a set of attributes that can be changed, and image represents the set of all functional modes defined for the elements in image.

This definition is almost equivalent to the definition of the diagnosis problem accordingly to (Reiter (1987)) and indeed the relationship between diagnosis and reconfiguration has been already pointed out (e.g., Crow and Rushby, 1991; Provan and Chen, 1999;Stumptner and Wotawa, 1998). Unlike Crow and Rushby (1991) and Provan and Chen (1999), we do not interleave diagnosis and reconfiguration in our approach (the constraint solver determines reconfigurations directly, i.e., without using any previously computed diagnoses). The slight difference to Stumptner and Wotawa (1998) is that in this work we rely purely on consistency-based reasoning ignoring fault models, which is sufficient for our purpose.

As we have already seen, SIMOL can be used to describe image, and image. The assignment of attributes/components (COMP) to functional modes (MODES) can be defined as follows.


Mode assignment

Given the set of configurable attributes image and the set of all functional modes image. A mode assignment image is a function image mapping each component to one of its modes.

A solution to the reconfiguration problem can be easily formalized using the definition of diagnosis introduced by Reiter (1987).



Given a reconfiguration problem image. A mode assignment image is a valid reconfiguration iff image is satisfiable.

Summarizing, attributes of a component can be also defined as components with at least one attribute, its changing value. This allows for searching the right functional mode in the context of reconfiguration. Note that the idea behind the “fake” components in SIMOL is to support more complex scenarios, where, for instance, we want to define new component instances inside a constraints block corresponding to a nondefault mode.

19.4 Business Cases

For (re) configuration in the context of M2M applications there are many business opportunities supported using the presented SIMOA approach. We discuss three of the business cases where configuration technology can be effectively used in the context of mobile phone networks and M2M applications.

• For M2M application providers there is the opportunity to clarify whether their requirements regarding the mobile phone network capabilities (e.g., bandwidth or available communication slots) can be fulfilled. Moreover, they are able to specify certain future scenarios to predict and ensure availability of their services. Hence, M2M application providers gain the advantage of being able to show their customers that the services they offer can be carried out (also in the future) and this is the key differentiator to the competitors.

Mobile network providers can exploit (re) configuration technologies to adapt and change network parameters and the topology to fit the need of M2M application providers. Via optimization, the least expensive solution or the one that maximizes revenue can be computed. Hence, mobile operators gain the advantage of being able to react almost immediately to requirements demanded by their customers when using reconfiguration technology based on models. Moreover, when using model-based approaches, adaptations caused by topological changes or technology changes are rather straightforward. Costs of adaptations of parts of the models are lower compared to developing a new configurator from scratch for each configuration problem.

• There is also a business opportunity for network equipment vendors. The SIMOA tools allow for computing reconfigurations of networks in order to meet future requirements. Hence, they can actively promote products and services to network service providers, which are based on well-founded results obtained using system models and requirements. Because of the flexibility of modeling, SIMOA is not restricted to one customer and can be easily adapted to handle different networks, network components, and services.

In addition to these business cases there are two advantages of model-based configuration worth mentioning. One is the fact that the obtained results (used either to verify whether a system meets given requirements or to compute reconfigurations) are well founded because they are based on system models. Another advantage is that system changes can be easily incorporated into the system models. Hence, there is no need to change the underlying simulation and configuration engine. Moreover, changes are typically local at the level of components and do not influence larger parts of the model. Although the initial modeling of an application might be demanding and more expensive, the overall costs of model-based systems considering the costs of necessary maintenance activities are usually smaller compared to very specific solutions, for example, using rule-based systems methodologies.

19.5 Conclusion

The SIMOA tool has been developed as part of the project Simulation and configuration of mobile networks for M2M applications (SIMOA) that deals with the study of principles for the simulation, (re) configuration, and optimization of mobile networks. The focus of the project is to investigate and solve problems in wireless networks under the assumption of a future user behavior and growing M2M applications. In particular, we are interested in reconfiguring a mobile network in case of bottlenecks caused by requirements coming from future M2M applications. The result of the suggestions for reconfiguration coming from the tool might be changes in the structure or the parameters of the mobile network. It is worth noting that only a flexible approach like model-based configuration is capable of handling the needs and requirements coming from the application domain.

Summarizing, today’s configuration technology offers a lot of benefits for the M2M application domain: (1) providing evidence that a certain application scenario can be carried out in a current mobile phone network given the system model and the requirements; (2) suggesting reconfigurations for changing the system’s parameters or structure in order to meet requirements; (3) being flexible enough for adaptation to different usage scenarios. The latter is of particular interest in order to save investments and to cope with the fast-paced M2M application domain.


1. Crow J, Rushby J. Model-based reconfiguration: toward an integration with diagnosis. In: Ninth National Conference on Artificial Intelligence (AAAI-91). Anaheim, CA: The MIT Press; 1991:836–841.

2. Gent IP, Jefferson C, Miguel I. MINION: a fast, scalable, constraint solver. In: Brewka G, Coradeschi S, Perini A, Traverso P, eds. Proceedings of the 2006 Conference on ECAI 2006: 17th European Conference on Artificial Intelligence August 29–September 1, 2006, Riva del Garda, Italy. Amsterdam, The Netherlands: IOS Press; 2006;98–102.

3. Hotz L, Felfernig A, Stumptner M, Ryabokon A, Bagley C, Wolter K. Configuration knowledge representation and reasoning. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:41–72. (Chapter 6).

4. Nica I, Wotawa F. The SiMoL modeling language for simulation and (re)configuration. In: SOFSEM 2012: Theory and Practice of Computer Science, Proceedings of the 38th International Conference (SOFSEM’12), Špindlerů v Mlýn, Czech Republic. 2012;661–672. Lecture Notes in Computer Science vol. 7147.

5. Nica I, Wotawa F, Ochenbauer R, Schober C, Hofbauer H, Boltek S. Model-based simulation and configuration of mobile phone networks – the SIMOA approach. In: 20th European Conference on Artificial Intelligence (ECAI 2012), Workshop on Artificial Intelligence for Telecommunications and Sensor Networks, Montpellier, France. 2012;12–17.

6. Provan G, Chen Y-L. Model-based diagnosis and control reconfiguration for discrete event systems: an integrated approach. In: Proceedings of the 38th IEEE Conference on Decision and Control, vol 2, Phoenix, AZ. 1999:1762–1768.

7. Reiter R. A theory of diagnosis from first principles. Artificial Intelligence. 1987;32(1):57–95.

8. Rossi F, vanBeek P, Walsh T, eds. Handbook of Constraint Programming Foundations of Artificial Intelligence. The Netherlands: Elsevier; 2006.

9. Stumptner M, Wotawa F. Model-based reconfiguration. In: Gero JS, Sudweeks F, eds. Artificial Intelligence in Design ’98. The Netherlands: Kluwer Academic Publishers; 1998:45–64.

1When adding a new mobile phone cell to a network, in fact, a new base station is added to the system and the transfer data is redistributed to the cells.

2The AMM readout frequency refers to the meter reading interval; i.e., for instance, an electricity meter can record the power consumption every 15 minutes.

3A smart grid is a power transmission network, which makes use of supplier and consumer information and communication infrastructure to improve the overall network performance in terms of efficiency, reliability, and sustainability in an automated way.

4A data concentrator is a device that is connected with several smart meters via a wire. In this case, all connected smart meters communicate to the AMM application over the data concentrator. Data concentrators are used, for example, in buildings with a large number of apartments where the costs for the additional wiring is low.

5This profile contains the amounts of power consumption recorded every 15 minutes.

6www.mathworks.com, www.modelica.com.

7Chapter 6.