<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Distributed management system for infocommunication networks based on TM Forum Framework</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Natalya Yu. Bratchenko</string-name>
          <email>nb20062@rambler.ru</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Darya V. Gosteva</institution>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2018</year>
      </pub-date>
      <abstract>
        <p>The existing management systems for networks and communication services do not guarantee in full an e cient rendering of next-generation infocommunication services. The Open Digital Architecture (ODA) is expected to simplify dramatically and automate main business processes. A key principle of the ODA is using the component approach with the logic of microservices and Open APIs. The concept of Frameworx gives an exact description for the components of business processes in terms of their functions, associated information and other characteristics. The performance of a distributed operational management system depends on the quality of solving several tasks as follows: the distribution of program components among processor modules; the prioritization of business processes with parallel execution; the elimination of dead states and interlocks during execution; the reduction of system cost to integrate separate components of business processes. The deadlocks of parallel business processes are eliminated using an interpretation of the classical le sharing example with two processes and also the methodology of colored Petri nets, with implementation in CPN Tools. This paper develops a model of a distributed operational management system for next-generation communication networks that assesses the e ciency of operational activities for a communication company.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>Due to high competition in the eld of telecommunications, network convergence processes and the need for
new business models, it is important to develop methods of operational cost reduction and risk decrease in
digital business management. Tele Management Forum (TM Forum) [TMF18], an international non-commercial
association of telecommunication companies and their suppliers, is helping the member organizations to perform
transformation into successful digital companies.</p>
      <p>Copyright c by the paper's authors. Copying permitted for private and academic purposes.</p>
      <p>The existing management systems for networks and communication services [SW11, LTK07, GI14] do not
guarantee in full an e cient rendering of next-generation infocommunication services. TM Forum experts
proposed the Open Digital Architecture (ODA) [ODA18], which is expected to replace traditional Operation Support
Systems/Business Support Systems (OSSs/BSSs) as well as to simplify dramatically and automate main
business processes (BPs). The ODA functionality (see Fig. 1) is intended to execute business processes without any
human interference using advanced technologies, including arti cial intelligence. A key principle of the ODA is
using the component approach with the logic of microservices and Open APIs.</p>
    </sec>
    <sec id="sec-2">
      <title>Methods</title>
      <sec id="sec-2-1">
        <title>Frameworx TM Forum</title>
        <p>The ODA project (see Fig. 1) is implemented using the concept of Frameworx TM Forum, known earlier as New
Generation Operations Systems and Software (NGOSS). This concept de nes a modern standardization approach
for the business processes of a communication company [Fra18]. Frameworx gives an exact description for the
components of BPs in terms of their functions, associated information and other characteristics. Frameworx
consists of the following frameworks (see Fig. 2).</p>
        <p>1. The Business Process Framework (formally Enhanced Telecom Operations Map or eTOM) describes the
structure of business processes of telecommunication companies.
2. The Information Framework (formally Shared Information/Data Model or SID) de nes an approach to the
description and usage of all data engaged in the business processes of a communication company.
3. The Application Framework (formally Telecom Applications Map or TAM) describes a typical structure of
the Information Framework components for communication companies.
4. The Integration Framework contains a set of standards that support the integration and interoperability
between applications de ned in the Applications Framework, with a basic element in form of a standardized
interface; a set of similar interfaces de nes a service (API service).
5. The Business Metrics is a standardized model of business indicators that unites over a hundred of standard
measurable indicators for assessing di erent activities of an infocommunications supplier.
6. The Best Practices includes practical recommendations and case studies based on the experience of using
Frameworx models in di erent activities of telecommunication companies.</p>
        <p>The structural description of BPs in eTOM relies on the hierarchical decomposition principle. Consider the
decomposition procedure for BP 1.4.6.3 (Correct &amp; Resolve Service Problem); there are four decomposition levels
here, as illustrated in Fig. 3.</p>
        <p>The rst decomposition level of eTOM contains eight large blocks:
1.1 Market/Sales Management Domain;
1.2 Product Management Domain;</p>
        <sec id="sec-2-1-1">
          <title>1.3 Customer Management Domain;</title>
        </sec>
        <sec id="sec-2-1-2">
          <title>1.4 Service Management Domain (shown in Fig. 3);</title>
        </sec>
        <sec id="sec-2-1-3">
          <title>1.5 Resource Management Domain;</title>
        </sec>
        <sec id="sec-2-1-4">
          <title>1.6 Engaged Party Domain;</title>
        </sec>
        <sec id="sec-2-1-5">
          <title>1.7 Enterprise Domain;</title>
        </sec>
        <sec id="sec-2-1-6">
          <title>1.8 Common Process Patterns Domain.</title>
          <p>The second decomposition level separates out the groups of processes that repre-sent large stages of end-to-end
business processes in eTOM. Block 1.4 Service Management Domain at level 2 is divided into eight groups (see
Fig. 3) and includes, including, block 1.4.6 Problem Management Service.</p>
          <p>The described levels are logical because the resulting speci cation does not yield a sequence of actions. The
third and lower decomposition levels are physical, since their elements correspond to speci c actions that can be
combined in ows.</p>
          <p>The processes of the third level decomposition can be used to construct ideal models without possible failures
during their execution and other peculiarities. Block 1.4.6 Problem Management Service level 3 is divided into
seven process groups (see Fig. 3) and includes, including, block 1.4.6.3 Correct &amp; Resolve Service Problem.</p>
          <p>Block 1.4.6.3 Correct &amp; Resolve Service Problem on the decomposition level 4 is divided into seven processes
(see Fig. 3):</p>
        </sec>
        <sec id="sec-2-1-7">
          <title>1.4.6.3.1 Reassign / Recon gure Failed Service;</title>
        </sec>
        <sec id="sec-2-1-8">
          <title>1.4.6.3.2 Manage Service Restoration;</title>
        </sec>
        <sec id="sec-2-1-9">
          <title>1.4.6.3.3 Implement Service Problem Work Arounds;</title>
        </sec>
        <sec id="sec-2-1-10">
          <title>1.4.6.3.4 Invoke Support Service Problem Management Processes;</title>
        </sec>
        <sec id="sec-2-1-11">
          <title>1.4.6.3.5 Review Major Service Problem;</title>
        </sec>
        <sec id="sec-2-1-12">
          <title>1.4.6.3.6 Monitor Service Alarms Events;</title>
        </sec>
        <sec id="sec-2-1-13">
          <title>1.4.6.3.7 Categorize Service Alarm Event.</title>
          <p>Using the speci cation elements obtained at the fourth level, it is possible to construct a detailed model of a
business process for automated management (see Fig. 4).</p>
          <p>The above approaches to management system design based on a set of modules implement the microservice
architecture principles, which is used to create program systems composed of numerous multiple services
interacting with each other. These modular components are intended for independent development, testing and
deployment, which facilitates the creation of new services or deep update of the existing ones if necessary. Other
advantages of such modules are cost reduction, speed increase and customer service improvement. The
microservice architecture guarantees independent scalability, faster market entry for new services, and higher e ciency
of management.
A distributed management system (DMS) for infocommunication networks can be de ned as a set of modules
or program components (PCs) executed by processor modules (PMs). Each PC implements a corresponding
microservice or business component (BC) that is described within Frameworx. PMs can be implemented in form
of physical devices or virtual resources. PCs interact with each other through the network adapters of PMs using
the capabilities of real or virtual networks. Any service in this management system is implemented by assigning
a certain set of PCs located on separate PMs for execution of a given BP.</p>
          <p>Clearly, the performance of a distributed operational management system depends on the quality of solving
several tasks as follows:
the distribution of PCs among PMs (as a rule, the number of sets of PCs is much greater than the number
of PMs), in this case, we assume that the real sequence of control transfers between PCs is approximated
by the absorbing Markov chain;
the prioritization of BPs with parallel execution as well as the elimination of dead states and interlocks
during execution;
the reduction of system cost to unite separate components of BPs.</p>
          <p>A successful solution of these tasks yields an optimal DMS in terms of the criterion</p>
          <p>L
= min X Pk
k=1
tk ( ; S; Q);
with the following notations: tk as the execution time of the kth BP;</p>
          <p>as a distribution method of PCs among PMs;
S as a service schedule of requests;
Q as an integration method for separate solutions of PMs;
L as the number of BPs served by the system;</p>
          <p>nally, Pk as the execution priority of the kth BP.</p>
          <p>To distribute PCs over PMs, consider n PCs (f1; : : : ; fn) and also d PMs. Assume each two PCs, fi and
fj , are exchanging joint requests with a known frequency P (i; j). The average number of control transmissions
between the i and j PCs can be obtained by taking measurements by the software monitor. We derive an
expression for the average number of transitions between PCs in the process of service implementation.</p>
          <p>Decompose the set of PCs into d groups = fF1; F2; : : : ; Fdg so that
n
[ fi =
i=1
d
[ Fi
i=1
and</p>
          <p>Fk \ Fl = ;;
k 6= l;
The frequency of con icts on the kth PM is de ned by</p>
        </sec>
        <sec id="sec-2-1-14">
          <title>Then the total frequency of con icts makes up</title>
          <p>Ck =</p>
          <p>X p (i; j):
i; j
C =</p>
          <p>d d
X Ck = X X p (i; j):
k=1</p>
          <p>All PCi, i = 1; : : : ; n, are decomposed into d groups using a system of operators R =
fRi t; i = 1; : : : ; n; t = 1; : : : ; dg that formalizes the transition of PCi to another class t, performing the
operation Ri t . As a result, i t ( ) = C (Ri t ) C ( ), where i t ( ) is the increment of the optimal decomposition
criterion.</p>
          <p>Denote by ii tq ( ) the increment of the values i t ( ) under transition to a new decomposition Rj q , where
Rj q 2 R, i.e.,
ii tq ( ) =
i t (Ri q )</p>
          <p>i t ( ) ; i = 1; : : : ; n; q = 1; : : : ; d:
Consequently,
i t (Ri q ) =
i t ( ) +
ij tq ( ) ;
ij tq ( ) = [P (i; j) + P (j; i)] ( t q + s u + s q
t u) ;</p>
          <p>For this criterion, the sequential improvement algorithm
where s and u are the indexes of groups for the PCs fi and fj (initial decomposition);
1; if t = q;
t and q are the indexes of their new groups (after transition); nally, t q = 0; if t 6= q:
i t (Rj q ) =
i t ( ) +
ij tq ( )
obtained under the assumption that the sequence of control transmissions between the PCs is described by the
Markov chain, gives a rational distribution of PCs among PMs.
2.3</p>
        </sec>
      </sec>
      <sec id="sec-2-2">
        <title>Elimination of dead states and interlocks</title>
        <p>DMSs for infocommunication networks have complex operation algorithms with parallel processes. Note that
some processes are interdependent because they share the same resources (e.g., hardware components, software
tools, current information). Due to resource sharing, it is necessary to organize the interaction of parallel
processes: their independent execution may cause errors, dead states or interlocks [Lee06, SL05, OAA09].</p>
        <p>The dead states and interlocks occurring in parallel business processes are eliminated by scheduling. The
e ciency of elimination is assessed using the indicator
where S means a schedule and ti (S) the service time of the ith request, subject to the constraint</p>
        <p>Tmin (S) = min fti (S)g ;
The notations are the following: p as the index of the request of type i;
(p + 1) as the index of the request of type j;
L as the serial number of the PM;
ZLi and ZLj as the time cost to execute the requests of types i and j on the Lth PM;</p>
        <p>nally, tj L as the time to execute the request of type j on the Lth PM.</p>
        <p>Let li j = max nZLi</p>
        <p>ZLj + tj Lo. Then the optimal service schedule of all requests is de ned by the condition</p>
        <p>The deadlocks of parallel business processes are eliminated using an interpretation of the classical le
sharing example with two processes [BS88, Piy86] and also the methodology of colored Petri nets [Jen13], with
implementation in CPN Tools [JKW07, CPN18].</p>
        <p>Consider the parallel implemented BPs, which consist of a sequence of operations t1; : : : ; tk performed by
PCs so that each operation corresponds to a transition in a Petri net (see Fig. 5). The user interface of the
CPN Tools environment determines the Petri net marking. Contained in certain positions, the markers are
highlighted in green, indicating their number, color and delay time value (for example, 1`1 @ 0). Transitions are
also highlighted in green, the triggering of which are currently allowed.</p>
        <p>A certain number of asynchronous parallel processes are competing for the right of resource use (RES). When
a process holds a resource, the sequence of its operations is performed and the resource is considered to be busy.
Since the same resource can be required for several processes, there may exist dead states and interlocks for
them, as shown in Fig. 6. This condition occurs in the model under consideration after a certain number of
allowed transitions are triggered (see Fig. 6). We see that at the moment there are no transitions in the network,
the operation of which is allowed.</p>
        <p>Our analysis of the model will employ the reachable label graph of the Petri net, see Fig. 7. The states of
a Petri net from which all paths of the reachable label graph lead to a dead state (in our case, S33) are called
pre-dead states (in our case, S22, S23, and S32). A set composed of the dead and pre-dead states is called the set
of forbidden states [BS88]. Obviously, for a faster execution of processes, it is necessary to eliminate all con icts
using the available system parallelism as much as possible. Consider some ways to eliminate process interlocks
and dead states.</p>
        <p>The rst approach is to use a well-timed forced locking of processes [BS88]. To this e ect, de ne the minimal
number of processes to be locked and also the minimal number of states to preserve this interlock. Then transform
the reachable label graph by removing all the edges that connect dangerous and forbidden states. This procedure
yields a graph containing the safe states only.</p>
        <p>In our example, the state S11 is the root of two dangerous segments, S21 S31 and S12 S13 (see Fig. 8).
The well-timed forced locking of undesired processes can be implemented by introducing an input position cb for
the transitions t2 and t8 in the Petri net (see Fig. 9). In this case, following the activation of the transition t2
(t8) and further evolvement of the process bp1 (bp2, respectively), the label is removed from the position cb and
the process bp2 (bp1, respectively) is locked.</p>
        <p>In accordance with the transformed reachable label graph (see Fig. 8), the state S31 (S13) is the last state of
the chosen dangerous segment. So the lock can be lifted after the activation of the transition t4 (t10, respectively).
To this end, the position cb must be the output position for the transitions t4 and t10, as illustrated in Fig. 9.</p>
        <p>The transformed reachable label graph (see Fig. 8) contains the position cb in all states except for the ones
corresponding to dangerous segments. The states S12; S13; S21, and S31, which are dangerous in the original
graph, become safe lock states while the state S11 becomes the con ict state. In addition, the forbidden states
S22; S32; S23, and S33 turn out to be unreachable in the transformed graph. Simulation results for the transformed
Petri net during 100 steps testify to the e ciency of this well-timed forced locking procedure, see Fig. 10.</p>
        <p>The second approach to eliminate the dead states and interlocks of processes is to allocate additional resources
required for their simultaneous execution, as shown in Fig. 11. In this case, the positions c1 and c2 have single
labels, which corresponds to two units of homogeneous resource.</p>
        <p>Next, the third approach to eliminate the dead states and interlocks of processes is to capture simultaneously
all the resources required for a process (see Fig. 12). For lifting the interlock of the rst process, a position c21
is added to the original network that holds the second resource.</p>
        <p>The last (fourth) approach to eliminate the dead states and interlocks is to arrange the capture of resources.
Serial numbers are assigned for all types of resources and a capture discipline is de ned for all processes. In
the transformed model, this approach is implemented by reassigning serial numbers for resources and specifying
choice rules for the transitions t2; t4, and t8; t10 (see Fig. 13).</p>
        <p>The developed models eliminate the interlocks of parallel processes. The methodology of colored Petri nets
is used to analyze the complete state space of the model in order to improve the reliability of the computing
system and also to satisfy requirements. The suggested methods and software solutions accelerate and simplify
program development, being nely integrated into the standard software approaches and methods and ready to
be applied in practice.
3</p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>Conclusions</title>
      <p>This paper has considered formal problems of distributed operational management and support system design for
communication companies and main approaches to solve them. A recursive convergent algorithm to distribute
program components for an associated microservice or business component using Frameworx and also a service
schedule of requests with the minimal number of delayed requests and colored Petri nets have been presented.
All these add up to an e cient design of distributed operational management systems for future-generation
telecommunication networks.
[SW11]
[Fra18]
[Lee06]
[SL05]
[BS88]
[Piy86]
[Jen13]
[OAA09] M. Olszewski, J. Ansel, S. Amarasinghe. Kendo: e cient deterministic multithreading in software.</p>
      <p>ACM Sigplan Notices, 44(3):97{108, March 2009. doi: 10.1145/1508284.1508256.</p>
      <p>L. Bic, A. C. Shaw. The logical design of operating systems.. 2nd ed. Prentice-Hall, Inc. Upper Saddle
River, NJ, USA, 1988.</p>
      <p>E. I. Piyl. Ustranenie vzaimnoi blokirovki parallel'nykh protsessov pri statisticheskom raspredelenii
resursov [Deadlock elimination for parallel processes with statistical allocation of resources]. Network
protocols and management in distributed computing systems: a compilation. The USSR Academy of
Sciences. Moscow, Nauka, 116{125, 1986. (in Russian).</p>
      <p>K. Jensen. Coloured Petri nets: basic concepts, analysis methods and practical use. Vol. 1. Springer
Science &amp; Business Media, 2013.
[JKW07] K. Jensen, L. M. Kristensen, L. Wells. Coloured Petri Nets and CPN Tools for modelling and validation
of concurrent systems. International Journal on Software Tools for Technology Transfer, 9(3{4):213{
254, March 2007.
[CPN18] CPN Tools Homepage. http://cpntools.org/. last accessed May 3, 2018.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          <article-title>[TMF18] TM Forum Homepage</article-title>
          . http://www.tmforum.org/.
          <source>last accessed May 3</source>
          ,
          <year>2018</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          <string-name>
            <given-names>J.</given-names>
            <surname>Simoes</surname>
          </string-name>
          ,
          <string-name>
            <surname>S. Wahle.</surname>
          </string-name>
          <article-title>The future of services in next generation networks</article-title>
          .
          <source>IEEE Potentials</source>
          ,
          <volume>30</volume>
          (
          <issue>1</issue>
          ):
          <volume>24</volume>
          {
          <fpage>29</fpage>
          ,
          <year>February 2011</year>
          . doi:
          <volume>10</volume>
          .1109/MPOT.
          <year>2010</year>
          .
          <volume>939761</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [LTK07]
          <string-name>
            <given-names>T.</given-names>
            <surname>Lechler</surname>
          </string-name>
          ,
          <string-name>
            <given-names>B. J.</given-names>
            <surname>Taylor</surname>
          </string-name>
          ,
          <string-name>
            <surname>B. Klingenberg.</surname>
          </string-name>
          <article-title>The Telecommunications Carriers' Dilemma: Innovation vs</article-title>
          .
          <source>Network Operation. Management of Engineering and Technology</source>
          , Portland International Center,
          <volume>2940</volume>
          {
          <fpage>2947</fpage>
          ,
          <year>August 2007</year>
          . doi:
          <volume>10</volume>
          .1109/PICMET.
          <year>2007</year>
          .
          <volume>4349638</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          <string-name>
            <given-names>V. V.</given-names>
            <surname>Gluhov</surname>
          </string-name>
          ,
          <string-name>
            <given-names>I. V.</given-names>
            <surname>Ilin</surname>
          </string-name>
          .
          <article-title>Project portfolio structure in a telecommunications company</article-title>
          .
          <source>Internet of Things, Smart Spaces, and Next Generation Networks and Systems</source>
          ,
          <volume>509</volume>
          {
          <fpage>518</fpage>
          ,
          <year>August 2014</year>
          . doi:
          <volume>10</volume>
          .1007/978-3-
          <fpage>319</fpage>
          -10353-2
          <fpage>46</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [ODA18]
          <article-title>Open Digital Architecture</article-title>
          . http://www.tmforum.org/resources/whitepapers/open-digitalarchitecture/.
          <source>last accessed May 3</source>
          ,
          <year>2018</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          <string-name>
            <surname>Frameworx TM</surname>
          </string-name>
          <article-title>Forum</article-title>
          . https://www.tmforum.org/tm-forum-frameworx-
          <volume>2</volume>
          /. last accessed
          <issue>May 3</issue>
          ,
          <year>2018</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          <string-name>
            <given-names>E. A.</given-names>
            <surname>Lee</surname>
          </string-name>
          .
          <article-title>The problem with threads</article-title>
          .
          <source>Computer</source>
          ,
          <volume>39</volume>
          (
          <issue>5</issue>
          ):
          <volume>33</volume>
          {
          <fpage>42</fpage>
          , May
          <year>2006</year>
          . doi:
          <volume>10</volume>
          .1109/
          <string-name>
            <surname>MC</surname>
          </string-name>
          .
          <year>2006</year>
          .
          <volume>180</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          <string-name>
            <given-names>H.</given-names>
            <surname>Sutter</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Larus</surname>
          </string-name>
          .
          <article-title>Software and the concurrency revolution</article-title>
          .
          <source>Queue</source>
          ,
          <volume>3</volume>
          (
          <issue>7</issue>
          ):
          <volume>54</volume>
          {
          <fpage>62</fpage>
          ,
          <year>September 2005</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          <source>doi: 10.1145/1095408</source>
          .1095421.
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>