Introduction to Queueing Theory

The means, adopted in this research, to model a network of UXVs operations supported by the presence of a mothership is QT. It is a mathematical representation of waiting lines, i.e. queues. Appropriate performance measures from the application of QT can be used in meaningful decision-making activities. Designing a queueing system normally involves making one or a combination of decisions about what type and number of resources should be allocated, in order to provide the relevant service within certain time limitations [Hillier and Lieberman, 2001]. Since such problems in decision-making can be formulated in terms of a queueing model, this becomes a powerful tool capable of providing valuable information for scheduling and designing queueing systems based on evaluating the system’s performance [Bhat, 2008].

QT models are mathematical models of real life systems. They have been beneficially employed in both the manufacturing and service domains, including production lines, transport systems (e.g. airports, road networks), telecommunications and the internals of computers [Bhat, 2008] [Suri et al., 2007]. Such models can be constructed to predict/evaluate the performance of a queueing network system and also contribute to understanding the behaviour of such systems. The performance measures describe the queue length (i.e. number of customers waiting in the queue) and the total time for the completion of the particular service (i.e. actual service time plus the waiting time) [Bhat, 2008]. A recently published application of QT describes modelling (i.e.

simulation rather than numerical modelling) of the road network system between Maidstone and Dover (i.e. M20/A20 motorway), in order to assess the congestion impact on the M20/A20 caused by a potential check time increase at Port of Dover and Eurotunnel (the Folkestone entrance). The congestion impact has been assessed by quantifying the queue formation and travel time. The results showed that even 1 or 2 minutes of extra check times at the two early points would result in a significant increase of congestion, with queues extending up to 30 miles from Dover/Eurotunnel

103 towards Maidstone and travel time approaching 5 hours in peak hours, which currently takes approximately 1 hour [Han et al., 2018].

Queueing systems can represent systems that provide a particular service and may model any system where the arriving customers look for a service of some kind and depart once the appropriate service has been provided [Bose, 2002]. A simple queueing model can be described by two distinct areas: the waiting and the service area, as shown in Figure 26, where a fleet of UXVs is the example. Such a model may be used to represent a number of customers (i.e. UXVs) that arrive at a waiting area, where they queue up if all servers are busy and eventually get served from an available server (i.e. facility) and thereafter leave when the required service (such as the service activities listed as UXVs tasks in Table 7) has been obtained. It is relevant that both the service and waiting areas entail requirements for physical space. These space demands depend on the type and number of available service facilities at the node service area, whereas for the node queueing area the space needs are defined by the estimation of the queue length. This is a function of:-

i. The number of customers to be served at the particular service facility;

ii. The number of service facilities available;

iii. The actual service time (i.e. type) of the specific service facility.

Figure 26: Simple queueing model [Adapted from Bose, 2002]

It is regarded as quite common for customers to require service from more than one facility. Usually in real-world systems, customers can be served by more than one node, where the nodes (i.e. service facilities) are arranged in a network structure. This network structure is considered as a collection of service nodes, which are interconnected with a path/route [Robertazzi, 1994]. Once a customer is served at one node, it can then either leave the network or join another service node, where they queue up to obtain the next appropriate service. Therefore, each node of the network

104 system representing UXV tasks, shown in Figure 23, can be described by a simple queueing model that, along with the other nodes, forms a queueing network of interconnected nodes.

The ideal situation can be thought of as the one where both the arrivals and service processes proceed strictly according to a prearranged procedure, thus no queue is formed in front of the service node and no queueing delays are incurred. However, in practice this is very unlikely to happen due to external factors (i.e. uncertainties), and also due to the limitations with regards to the system’s capacity (i.e. availability of space and number of servers) [Bhat, 2008]. In the case of a UXV mothership, the arrival of UXVs at the service points is not likely to follow a planned schedule, due to unpredictable operational requirements, while the mothership’s capacity is not infinite, since the ship is designed to accommodate a specific number UXVs and a finite amount of support systems and equipment. In addition to this, the need for a mothership to perform UXV-related tasks as quickly as possible for a potential mission scenario, within the limited ship’s capacity, leads to the likelihood of formation of queues ahead of the service points.

Thus, in the occurrence of a mission, the fleet of UXVs should be able to be deployed in the theatre of operations as quickly as possible. The vehicles should be first launched from the mothership by employing LARSs. A well dock, for example, would allow the almost concurrent launching of multiple USVs when compared to side cranage or a stern ramp systems. Although different types of LAR methods might allow more vehicles to be launched at the same time than others, the limited number of LARSs on-board a mothership to serve such a big number of vehicles (i.e. fleet) is likely to cause queueing delays and queue formation. This would happen as a consequence of the vehicles piling up while waiting for an available server (i.e. LARS) to get served (i.e. launched) during the overall launching process. Besides the nature of the restricted number of launching service facilities, the urgency caused due to an imminent mission (i.e. activities do not follow a strictly scheduled plan), would also contribute to queueing ahead of the LARSs. However, any effort to schedule (i.e.

control) the UXVs launching process, in order to avoid any on-board queue formations, would mean the total time to perform such controlled launching activities would be much longer. This would then be counter to the urgency of the mission, due

105 to the pauses imposed in the sequence of activities ahead of launching the vehicles from the ship (i.e. non-continuous launching process).

However, in the case of a node where the number of servers is always greater or equal to the maximum number of customers that seek service at this particular node, this is described as the node having an infinite server queueing discipline [Bruell and Balbo, 1821]. In such a case, none of the customers will ever experience a queueing delay at this specific node. Hence, this node’s total time to serve a customer would equal the actual service time, as the waiting (i.e. queueing) time is zero. However, such an ideal scenario is unlikely to apply to in the case of a UXV mothership, given that the number of on-board facilities is restricted (i.e. ship size limitations), and also given the fleet scenario concept of this research, the number of service facilities on-board a mothership would be smaller than the number of vehicles in the fleet.