Recommendations for Using QPN Formalism for Preparation of Incoming Request Stream Generator in Modeled System

Abstract

Simulation models are elements of science that use software tools to solve complex mathematical problems. They are beneficial in areas such as performance engineering and communications systems. Nevertheless, to achieve more accurate results, researchers should use more detailed models. Having an analysis of the system operations in the early modeling phases could help one make better decisions relating to the solution. In this paper, we introduce the use of the QPME tool, based on queueing Petri nets, to model the system stream generator. This formalism was not considered during the first tool development. As a result of the analysis, an alternative design model is proposed. By comparing the behavior of the proposed generator against the one already developed, a better adjustment of the stream to the customer’s needs was obtained. The study results show that appropriately adjusting queueing Petri net models can help produce better streams of data (tokens).

1. Related Work

Performance evaluation is applied in communications system development and assessment. In recent years, most of the works focused on systems that were very efficient, and able to handle numerous incoming requests. The topic of stream preparation was omitted.

Authors model systems in different ways [1,2]. On the one hand, there are formal models used to analyze performance [3,4]. On the other hand, to describe systems, they use simulation models: QNs [5,6], CPN [5,7] or QPN [8,9,10]. In recent years, most works focused on web systems [4,6,11,12], which are very efficient, and able to handle numerous incoming requests. Moreover, QPNs are useful models in regard to specifying and verifying, e.g., protocol behaviors [13].

Usually some kind of workload generator is applied to analyze the behavior of the modeled system. A survey of such generators for general purpose web-based systems is presented in [14]. Specialized traffic models may be considered for different systems, e.g., for industrial networks [15] or streaming video data, both for input [16] and output streams [17]. In such models, an input stream generator is usually a part of the workload generator. Such an arrival stream generator produces a stream of random input data according to the expected distribution. Petri net models of the system typically are built based on predefined structures–patterns [18,19]; in such an approach, a stream generator is one of the integral components.

We created a stream generator (SG) client model using queueing Petri nets (QPNs), which guarantee performance analysis [12]. QPNs provide greater modeling power than queueing net (QN) and Petri net (PN) models. We used two types of formal models that were exploited in one model. Queueing Petri nets have the advantages of queueing nets (e.g., the network efficiency and evaluation of the system performance) and Petri nets (e.g., logical assessment of the system correctness). To the best of our knowledge, none of the existing techniques presented in the literature enable the preparation of such a stream. Falko Bause et al. in [20] describe these kinds of Petri nets, named QPNs. Kounev et al. [21] provide an introduction to QPNs.

The modeling approach presented in this paper differs from that of previous works [9], in regard to performance analysis, because we modeled different stream behaviors; they are similar to [7], but we prepared the SG based on another formalism. This approach could be treated as an extension of the paper [7].

In [7], colored Petri nets (CPNs) were used to model the SG. Two different ways were considered to impose restrictions on mapping between users and resources—transition guards or arc expressions. In this paper, QPNs are used instead of CPNs. Appropriate mapping in the output stream was achieved by means of transition modes and firing weights.

2. QPN Model

2.1. QPNs

QPNs can be seen as an extension of stochastic PNs. The main idea of QPNs is to add queueing and timing aspects to the net places and timed transitions. QPNs allow queues to be integrated into the places of a PN. Places (QPN) are divided into two types: ordinary and queued. A place that contains an integrated queue is called a queueing place. Queueing places contain two components: the queue and the depository of tokens that complete their service at a queue. Tokens are used to model requests and enter the queueing place through the firing of input transitions. The different possibilities of firing a transition are referred to as modes. Modes have firing weights (probabilities) that influence which mode is chosen. Tokens are inserted into a queueing place according to the queue’s scheduling strategy. Timed queueing places have service distributions. In the queueing place, if a server is available, arriving tokens are first serviced. If a server is not available, the tokens have to wait in the waiting area. The time it takes to service a token is defined through a statistical distribution. After service, the tokens are immediately moved to a depository, where they become available for output transitions. When a transition fires, tokens are removed from some places and new tokens are created at others. Figure 1 shows the notation used for ordinary places and queueing places. For more details, refer to [5].

To analyze any QPN it is necessary to determine:

• Set of places;
• Set of queueing places with scheduling strategy;
• Set of immediate or timed transitions (QPNs allow transitions to fire in different modes (transition colors));
• Initial marking (number of tokens);
• Incidence function (routing probability) is defined per color/mode basis;
• Arcs with firing weights as relative firing frequency of the mode;
• Token color function specifies the types of tokens that can reside in the place and allows transitions to fire in different modes.

The color function assigns a set of colors to each transition. Incidence functions are defined on a per color basis.

QPN model was used to check the behavior of the token and it was developed using the QPME tool [22].

2.2. Mathematical Model of QPN

In [23], the general model of QPN was defined and some symbols were introduced. This is briefly summarized in this subsection.

Queueing Petri nets have the advantages of QNs (e.g., evaluation of the system performance, the network efficiency) and PNs (e.g., logical assessment of the system correctness). The main idea of QPNs is to add queueing and timing aspects to the net places. QPN is a tuple (1).

$$QPN=(PL,TR,CO,IN,MA,QU,WE)$$

(1)

where:

• $PL=\{p_1,p_2,\cdots ,p_k\}$ is a finite and non-empty set of places;
• $TR=\{t_1,t_2,\cdots ,t_l\}$ is a finite and non-empty set of transitions;
• $PL\cap TR=⌀$;
• $CO$ is a color function defined from $PL\cup TR$ into finite and non-empty sets (specify the types of tokens that can reside in the place and allow transitions to fire in different modes);
• $IN(p,t)$ are the backward and forward incidence functions defined in $PL\times TR$, such that $IN(p,t)\in [CO\left(t\right)⟶CO{\left(p\right)}_{MS}],\forall (p,t)\in PL\times TR$ (specify the interconnections between places and transitions; the subscript $MS$ denotes multisets. $CO{\left(p\right)}_{MS}$ denotes the set of all finite multisets of $CO\left(p\right)$);
• $MA\left(p\right)$ is an initial marking defined on $PL$, such that $MA\left(p\right)\in CO\left(p\right),\forall p\in PL$ (specify how many tokens are contained in each place).
• $QU=(Q{U}_1,Q{U}_2,(q_1,\cdots ,q_{\left|PL\right|}))$, where:

  -

  $Q{U}_1\subseteq PL$ is a set of timed queueing places;

  -

  $Q{U}_2\subseteq PL$ is a set of immediate queueing places;

  -

  $Q{U}_1\cap Q{U}_2=⌀$;

  -

  $(q_1,\cdots ,q_{\left|PL\right|})$ is an array with a description of places (if $p_i$ is a queueing place, $q_i$ denotes the description of a queue with all colors of $CO\left(p_i\right)$ into consideration, or if $p_i$ is the ordinary place ($p_i$) equals $null$).

• $WE=(W{E}_1,W{E}_2,(w_1,\cdots ,w_{\left|TR\right|}))$, where:

  -

  $W{E}_1\subseteq TR$ is a set of timed transitions;

  -

  $W{E}_2\subseteq TR$ is a set of immediate transitions;

  -

  $W{E}_1\cap W{E}_2=⌀$, $W{E}_1\cup W{E}_2=TR$;

  -

  $W=(w_1,\cdots ,w_{\left|TR\right|})$ is an array (entry $w_j\in [CO\left(t_j\right)⟼{\mathbb{R}}^{+}]$, such that $\forall c\in CO\left(t_j\right):w_j\left(c\right)\in {\mathbb{R}}^{+}$) of:

  *

  rate of a negative exponential distribution specifying the firing delay due to color $c\in CO\left(t_j\right)$, if $t_j\in W{E}_1$;

  *

  firing weight specifying the relative firing frequency due to color $c\in CO\left(t_j\right)$, if $t_j\in W{E}_2$.

2.3. Stream Generator

In this article, we present the modified version of the SG model shown in [7], which is based on QPNs. This is a simple way to model a user stream, who generates requests transferred to the system.

The model allows us to freely join the $u1$ or $u2$ user tokens with the $r1$ or $r2$ resource tokens. Thus, any distribution in $Stream$ can be obtained in this way.

The logic lies in the firing of transitions with weights and handling of the token colors. The following cases are considered:

• In a simple SG, any user can use any resource in the stream generation process.
• In other cases, any stream can be generated based on a predetermined weight value.

We get the populations with the expected distribution of the output stream (approximately):

• Simple model $(\frac{1}{4},\frac{1}{4},\frac{1}{4},\frac{1}{4})$;
• Varied models, e.g., $(\frac{1}{10},\frac{1}{5},\frac{3}{10},\frac{2}{5})$; $(\frac{1}{7},\frac{2}{7},\frac{1}{7},\frac{3}{7})$; $(\frac{1}{4},\frac{1}{4},0,\frac{1}{2})$; $(\frac{1}{5},\frac{1}{5},0,\frac{3}{5})$; $(0,\frac{1}{4},0,\frac{3}{4})$; $(0,0,\frac{1}{4}$, $\frac{3}{4})$; $(0,0,0,1)$.

The stream preparation technique presented here provides a framework for a model that can be used in system performance modeling. For technical details on the simulation tool, we refer the reader to [22].

3. Testing in QPME Tool

Every system model could be divided into parts: the client and the system [9]. We started modeling the first part, called SG.

3.1. Mathematical Model of SG in QPN

Based on the definition in Section 2.1, we define the following QPN model (2) of SG.

$$QP{N}_{SG}=(PL,TR,CO,IN,MA,QU,WE)$$

(2)

where:

• Set of places $PL=\{Res,Stream\}$.
• Set of transitions $TR=\left\{Generator\right\}$.
• Color function $CO\left(p_i\right)$ for colors $c=\{u1,u2,r1,r2,u1r1,u1r2,u2r1,u2r2\}$. where:

  -

  $u1$ and $u2$-user-classes;

  -

  $r1$ and $r2$-resources;

  -

  $u1r1$, $u1r2$, $u2r1$, $u2r2$-stream.

• Incidence functions specify the interconnections between places and transitions $IN(p,t)$.
• Initial marking specify how many tokens are contained in each place $MA\left(p\right)=\left\{Users\right(u1=1,u2=1),Res(r1=1,r2=1),Stream(u1r1=u1r2=u2r1=u2r2=0\left)\right\}$.
• $QU=(Q{U}_1,Q{U}_2,(-/M/\infty /I{S}_{Users},null,null))$, where:

  -

  $Q{U}_1=\left\{Users\right\}$;

  -

  $Q{U}_2=⌀$;

• $WE=(W{E}_1,W{E}_2,W)$, where:

  -

  $W{E}_1=⌀$;

  -

  $W{E}_2=TR$, where the $Generator$ transition is immediate;

  -

  $W=(w\left(mod{e}_1\right),w\left(mod{e}_2\right),w\left(mod{e}_3\right),w\left(mod{e}_4\right))$, for simple model $W=(1,1,1,1)$ and for exemplary varied models $W=(1,2,3,4)$, $W=(1,2,1,3)$, $W=(1,1,0,2)$, $W=(1,1,0,3)$, $W=(0,1,0,3)$, $W=(0,0,1,3)$, $W=(0,0,0,1)$, where:

  *

  Color function $\forall c\in CO\left(t_j\right):w_j\left(c\right)\in {\mathbb{R}}^{+}$;

  *

  Colors $c=\{mod{e}_1,mod{e}_2,mod{e}_3,mod{e}_4\}$;

  *

  $Generator$ transition modes $mod{e}_1,...,mod{e}_4$.

3.2. Simulation Model

The SG model is shown in Figure 2. SG is represented in the model by a set of places ($Res$ and $Stream$), queueing place ($Users$), and immediate transition $Generator$ (All transition cases of the model are shown in

Table 1. Firing modes of $Generator$ transition.

Transition	Mode	Action
$Generator$	$mod{e}_1$	input{$u1$} ⟶ output{$u1r1$}
		input{$r1$} ⟶ output{$u1r1$}
$Generator$	$mod{e}_2$	input{$u1$} ⟶ output{$u1r2$}
		input{$r2$} ⟶ output{$u1r2$}
$Generator$	$mod{e}_3$	input{$u2$} ⟶ output{$u2r1$}
		input{$r1$} ⟶ output{$u2r1$}
$Generator$	$mod{e}_4$	input{$u2$} ⟶ output{$u2r2$}
		input{$r2$} ⟶ output{$u2r2$}

).

Table 2. Places used in the model.

Place	Token	Queue	Description
$Users$	$\{u1,u2\}$	$-/M/\infty /IS$	Queueing place used to model concurrent clients.
$Res$	$\{r1,r2\}$	null	Ordinary place used to model resource.
$Stream$	$\{u1r1,u1r2,$	null	Ordinary place used to model the generated stream.
	$u2r1,u2r2\}$

provides details on the places used in the model. Requests and resources are modeled by tokens of different colors. $Users$ generates tokens of user requests $u1$ and $u2$ at the given rate. $Res$ generates different available resources as $r1$ or $r2$ tokens. Every request goes to the system. After acquiring a resource $r1$ or $r2$ from the $Res$ place, the requests are placed into the $Stream$ place of the model. The $Stream$ place consists of $r1u1$, $r1u2$, $r2u1$, and $r2u2$ tokens. In Table 1 we concentrate only on the $Stream$ place and generated new tokens.

Table 3. Token colors.

Token Color	Place	Description
$u1$	$Users$	First user
$u2$		Second user
$r1$	$Res$	First resource
$r2$		Second resource
$u1r1$	$Stream$	First user and first resource
$u1r2$		First user second resource
$u2r1$		Second user and first resource
$u2r2$		Second user and second resource

defines the token colors that we use.

The used queue is described by Kendall notation ($A/B/K/L$), where A denotes the probability distribution function that specifies the interarrival time of tokens (−means different requests interarrival time), B is the probability distribution function of a service time (M means exponential (Markovian) distribution of the request service time), K determines the maximum number of requests that can arrive in a queue (in this case, it is ∞) and L-scheduling strategy (in this case, it is the infinite server).

$Users$ has an infinite server queue with an initial population of request tokens. The transition $Generator$ is configured to fire these tokens into the system (modeled as $Stream$ place). Firing the $Generator$ transition (Figure 3) creates a token in the $Stream$ place, assigns one of the resources to one of the users. $Stream$ is an ordinary place that contains the resulting stream of the mean token population.

The method used to model restrictions of the user/resource mapping involves the appropriate selection of firing weights (Figure 4). In this model, $Stream$ tokens are generated based on this value. We assign different firing weights to the prepared modes of these transitions so that they have various probabilities of being fired when multiples of them are enabled at the same time. We use the notation (3) to denote firing modes (Table 1) (The symbols $input$ and $output$ are used here to refer to the input and output places of transitions, respectively). After the token is destroyed in an input place by the transition $Generator$, a new token is created in an output place.

$$p_i\left\{c\right\}⟶p_{i+1}\left\{c^{\prime }\right\}$$

(3)

where:

• A c token is removed from place $p_i$;
• A $c^{\prime }$ token is deposited in place $p_{i+1}$.

The modeling approach was tested with different input firing weight values to demonstrate its effectiveness and practical applicability.

4. Stream Generator Results

In this section, we present an evaluation of our modeling approach. In many models, it is typical to distribute the data in random order. However, we need predefined distributions in some cases. The modeling approach was described in the previous section, and it allows simulating any input data distribution. The QPME tool generates a report showing the predicted SG population for the individual model configuration.

Table 4. Token colors (simple model).

Modes	Firing Weight w	Token Color	Mean Token Population for $Stream$
$mod{e}_1$	1.0	$u1r1$	25,172.11
$mod{e}_2$	1.0	$u1r2$	24,858.411
$mod{e}_3$	1.0	$u2r1$	24,733.689
$mod{e}_4$	1.0	$u2r2$	25,095.054

and

Table 5. Token colors (varied models).

Modes	Firing Weight w	Token Color	Mean Token Population for $Stream$
$mod{e}_1$	1.0	$u1r1$	9978.882
$mod{e}_2$	2.0	$u1r2$	19,827.981
$mod{e}_3$	3.0	$u2r1$	29,978.301
$mod{e}_4$	4.0	$u2r2$	39,679.93
$mod{e}_1$	1.0	$u1r1$	14,195.611
$mod{e}_2$	2.0	$u1r2$	28,625.108
$mod{e}_3$	1.0	$u2r1$	14,308.058
$mod{e}_4$	3.0	$u2r2$	42,688.806
$mod{e}_1$	1.0	$u1r1$	24,931.845
$mod{e}_2$	1.0	$u1r2$	25,170.6
$mod{e}_3$	0.0	$u2r1$	0.0
$mod{e}_4$	2.0	$u2r2$	50,286.744
$mod{e}_1$	1.0	$u1r1$	20,154.555
$mod{e}_2$	1.0	$u1r2$	19,958.521
$mod{e}_3$	0.0	$u2r1$	0.0
$mod{e}_4$	3.0	$u2r2$	60,068.627
$mod{e}_1$	0.0	$u1r1$	0.0
$mod{e}_2$	1.0	$u1r2$	24,933.095
$mod{e}_3$	0.0	$u2r1$	0.0
$mod{e}_4$	3.0	$u2r2$	75,169.879
$mod{e}_1$	0.0	$u1r1$	0.0
$mod{e}_2$	0.0	$u1r2$	0.0
$mod{e}_3$	1.0	$u2r1$	24,894.468
$mod{e}_4$	3.0	$u2r2$	75,242.374
$mod{e}_1$	0.0	$u1r1$	0.0
$mod{e}_2$	0.0	$u1r2$	0.0
$mod{e}_3$	0.0	$u2r1$	0.0
$mod{e}_4$	1.0	$u2r2$	99,950.075

present the results for each token in $Stream$ place. We can find the mean token population for $Stream$ place. Table 4 shows the token population for a simple case with firing weights equal $1.0$ for every mode ($mod{e}_1$, $mod{e}_2$, $mod{e}_3$, $mod{e}_4$). We observe that, as expected, the mean token population is evenly distributed for tokens ($u1r1$, $u1r2$, $u2r1$, $u2r2$). The first four lines of Table 5 show the token population for the case with firing weights equal to $1.0$, $2.0$, $3.0$, and $4.0$ for individual modes. Other examples can be found in the following lines of Table 5. In all cases, the sum of all tokens in $Stream$ place is about 100,000, as shown in Table 4 and Table 5.

It can be observed that the quantities of the generated tokens in the $Stream$ place for each mode i are consistent with the appropriate firing weights w. This relation for n modes can be denoted as follows (4).

$$\frac{token{s}_{mod{e}_i}}{{\sum }_{j=1}^{n}token{s}_{mod{e}_j}}\approx \frac{w\left(mod{e}_i\right)}{{\sum }_{j=1}^{n}w\left(mod{e}_j\right)}$$

(4)

Thus, various distributions of the tokens in the stream can easily be modeled by appropriate changes in the firing weights, according to the designer’s needs. The model is general and covers special cases where one of the users is not allowed to use a particular resource. This restriction is modeled by setting the appropriate firing weight to zero.

5. Conclusions

In this paper, we used queueing Petri net formalism as an analysis technique to prepare the SG of incoming requests in the early phases of system development. Performance engineering is a field of study that solves performance problems using simulators. This field suffers from a lack of guidelines and software solutions for client behavior modeling. Modeling a system and performance analysis in the early stages of system construction ensures the best performance. This approach is a complex modeling tool for a proper selection input stream to the modeled system.

Various models of SG in miscellaneous classes of Petri nets may be considered. Our approach gradually evolves from CPN into QPN. Transition modes and firing weights, which are distinctive elements of QPN formalism, are beneficial. They can be used to model the probability of choosing appropriate binding of the transition; thus, manifold distributions of the tokens in the output stream can be generated in a comprehensive, logical manner. The model of SG presented in Section 3 is simple but flexible, able to produce the stream according to the designer’s needs, as shown in Section 4.

In this paper, the system client was taken into account. Its original design was performed using QPN models. Future research might confirm that the specific client behavior could be achieved by developing a model with a proposed SG.