Modeling Mobile Applications for Proximity-Based Promotion Delivery to Shopping Centers Using Petri Nets

Abstract

This article presents the design and implementation of an API that delivers real-time promotional notifications to mobile devices based on their proximity to shopping centers, calculated using the Haversine formula. Developed in Laravel, the API determines whether a mobile device is within a 600 m radius of any registered shopping center, such as Soriana, GranD, and HEB, and sends the relevant promotional information. The system uses Petri nets to model asynchronous behavior, enabling efficient concurrency management between the mobile application and the API. This structure ensures optimized message delivery, preventing communication collisions and delays. The mobile application, developed in Kotlin, integrates geolocation services to capture and update the user’s location in real time. The results indicate an improvement in response time and proximity detection accuracy, highlighting the effectiveness of the Petri net model for systems requiring concurrent interaction. The combination of Laravel, Kotlin, and formal modeling with Petri nets proves to be an effective and scalable solution for proximity-based mobile applications.

1. Introduction

The use of mobile devices has grown exponentially in the past decade, driving demand for applications that provide users with personalized, real-time information [1,2,3]. One of the most rapidly advancing areas has been geolocation-based mobile applications [4,5], which allow the delivery of relevant content to users based on their physical location [6]. These technologies have been widely adopted in the commercial sector, aiming to enhance user experience by delivering real-time promotions [7]. However, the efficiency and reliability of these applications rely heavily on the effective management of communication between mobile devices and the backend servers that supply necessary data and services [8].

To address these challenges, Petri nets offer a suitable formal modeling tool for systems that require the coordination of multiple asynchronous and concurrent processes [9], as in the case of mobile applications interacting with APIs (Application Programming Interfaces) [10]. Petri nets allow the accurate representation of interactions between network requests, message delivery, and user proximity detection, contributing to a smooth and optimized user experience [11].

This article presents the design and implementation of a mobile application developed in Kotlin, which leverages geolocation services to send its geographic position to an API. The API calculates the proximity between the user and registered shopping centers, such as Soriana, GranD, and HEB, using the Haversine formula [12]. If the user is detected within a radius of 600 m or less from a shopping center, the API, developed using the Laravel framework, sends real-time promotional offers. Additionally, the application features a share button, enabling users to distribute offers among their contacts, thereby extending the reach of the promotions [13]. By utilizing Petri nets to model the system’s asynchronous behavior, communication between the mobile application and the API is optimized, ensuring fast response times and accurate delivery of promotions.

The complexity of developing the mobile application and API lies in handling multiple simultaneous user requests in parallel without affecting response time. To address this challenge, Petri nets are introduced as an appropriate formal modeling tool, enabling the representation and analysis of the system’s asynchronous and distributed behavior. This approach enhances user experience and prevents communication conflicts [14,15].

The main contribution of this study lies in the application of Petri nets for formal modeling in real-time proximity systems, demonstrating their effectiveness not only in optimizing the delivery of relevant content but also as a scalable and robust methodology that can be applied in future mobile application developments in this field. The obtained results show that the proposed system achieves a reduction in response times and improves the accuracy of proximity detection using the Haversine formula, validating the effectiveness of modeling with Petri nets and concurrency management in real-time notification systems.

To guide our research and provide a clear structure for the rest of the article, we pose the following research questions:

• How can an efficient real-time promotional advertisement delivery system be implemented based on the user’s proximity to shopping centers?
• What benefits does the integration of Petri nets offer in modeling mobile applications for managing asynchronous and concurrent behaviors?
• What advantages does the use of Petri nets present for identifying and optimizing bottlenecks in the interaction flow between the mobile application and the API?

These questions address the key aspects of our study, including technical implementation, Petri net modeling, system accuracy, and the advantages of the proposed methodology. Throughout the article, we will explore these issues in detail, presenting our methods, results, and conclusions.

Throughout this article, we will explore these topics in detail, presenting our methods, results, and conclusions. The main contribution of this manuscript can be summarized in the following points:

• Development of an integrated system that combines a mobile application and an API for real-time delivery of promotions based on the user’s proximity to shopping centers.
• Implementation of a formal model using Petri nets to optimize the management of asynchronous and concurrent behaviors in mobile applications.
• Evaluation of the accuracy and response time of the system using the Haversine formula for proximity calculations.
• Demonstration of the effectiveness of combining modern technologies (Kotlin, Laravel) with formal modeling through Petri nets to enhance the performance and scalability of geolocation-based mobile applications.
• Detailed analysis of the T-invariants and the properties of liveness and boundedness of the system modeled with Petri nets, providing insights into its cyclic behavior and robustness.

The rest of the paper is structured as follows: Section 2 provides a review of the state of the art. Section 3 provides a complete description of the materials and methods used. Section 4 presents the analysis and results of the tests performed. Finally, Section 5 concludes the paper and discusses future work.

2. State of the Art

2.1. Geolocation in Mobile Applications

Geolocation is essential for applications that rely on user location [16]. The Haversine formula is commonly used to calculate the distance between two points on the Earth’s surface, which is crucial for determining whether a user is within the proximity range of a shopping center. Previous studies have employed this formula to optimize location-based services and enhance the accuracy of location-based recommendation systems [17,18].

Riabova et al. [4] emphasize the significance of marketing strategies that leverage geolocation and contextual advertising in mobile applications. Their study underscores how these technologies enable businesses to offer highly personalized promotions based on the user’s location.

Landolsi et al. [5] introduced an efficient approach for mobile location tracking and data reduction in proximity detection applications. Their work demonstrates how location tracking algorithms can significantly improve the accuracy of proximity detection and reduce data redundancy, which is crucial for systems such as the one proposed in our study.

2.2. Real-Time Communication and APIs

The design of effective APIs is essential for real-time communication between mobile applications and servers. Frameworks such as Laravel are now commonly adopted for API construction due to their robustness and ease of integration. APIs that handle asynchronous requests provide a smoother user experience, which is crucial for applications requiring constant updates [19].

2.3. Definition of Petri Nets

A Petri net is graphically represented by circles, referred to as places, and rectangles, referred to as transitions, which are interconnected through directed arcs. The dynamic behavior of the modeled system is described by an ordered sequence of transition firings. When a transition is fired, it consumes tokens from its input places and generates new tokens in its output places. The number of tokens required to fire a specific transition, as well as the location of the newly generated tokens, is determined by the directions and weights associated with the input and output arcs. The distribution of tokens across the places of the net is called the marking, which represents the state of the modeled system at a given moment. Let N denote the set of non-negative integers [20,21]. Formally, a Petri net is a five-tuple $PN=(P,T,F,W,{\mathbf{M}}_0)$, where

• P is a finite set of places;
• T is a finite set of transitions, disjoint from P;
• $F\subseteq (P\times T)\cup (T\times P)$ is the set of arcs;
• $W:F\to {\mathbb{N}}^{+}$ is the weight function of the arcs;
• ${\mathbf{M}}_0:P\to \mathbb{N}$ is the initial marking.

The matrices associated with a Petri net are the following:

• Input matrix: $\mathbf{I}:P\times T\to \mathbb{N}$

  $$\mathbf{I}(p,t)=\left\{\begin{array}{cc}W(p,t)\hfill & \mathrm{if}(p,t)\in F\hfill \\ 0\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$
• Output matrix: $\mathbf{O}:P\times T\to \mathbb{N}$

  $$\mathbf{O}(p,t)=\left\{\begin{array}{cc}W(t,p)\hfill & \mathrm{if}(t,p)\in F\hfill \\ 0\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$
• Incidence matrix: $\mathbf{C}=\mathbf{O}-\mathbf{I}$

The transition function $\delta :{\mathbb{N}}^P\times T\to {\mathbb{N}}^P$ defines the dynamics of the Petri net:

$$\delta (\mathbf{M},t)=\mathbf{M}+\mathbf{C}(·,t)\mathrm{if}\mathbf{M}\ge \mathbf{I}(·,t)$$

where

• $\mathbf{M}$ is the current marking;
• $\mathbf{C}$ is the incidence matrix;
• $\mathbf{I}$ is the input matrix;
• t is a transition.

T-invariants are vectors $\mathbf{x}\in {\mathbb{N}}^T$ such that

$$\mathbf{C}·\mathbf{x}=\mathbf{0}$$

P-invariants are vectors $\mathbf{y}\in {\mathbb{N}}^P$ such that

$${\mathbf{y}}^{\mathbf{T}}·\mathbf{C}=\mathbf{0}$$

The dynamics of a Petri net describe the evolution of the marking through the firing of enabled transitions. This process captures the system’s behavior over time, reflecting changes in state as transitions occur.

2.4. Modeling Mobile Systems with Petri Nets

The use of Petri nets as a modeling tool has proven crucial for analyzing and optimizing the behavior of complex mobile applications. Ding and Yang [11] conducted a comprehensive review on modeling mobile computing systems using Petri nets, highlighting their ability to represent key aspects such as concurrency, parallelism, process synchronization, and asynchronous behavior. These characteristics position Petri nets as widely used tools in concurrent and distributed systems, particularly in the context of mobile applications that require continuous asynchronous interaction between the user and the server [22]. In this scenario, modeling system behavior through Petri nets allows for a deeper understanding of the processes involved, as well as effective optimization of concurrency and event synchronization [10].

Yang et al. [23] addressed the modeling and analysis of three critical properties in interactive mobile systems using Petri nets. Their research demonstrates how these tools enable formal verification of these properties, which is essential for ensuring the reliability and robustness of mobile applications. The value of Petri nets lies in their ability to model and analyze complex systems, such as mobile applications interacting with an API in real-time. This approach facilitates the analysis of critical properties such as reachability and deadlock prevention in communication, optimizing the exchange of information between the mobile application and the API. Furthermore, its applicability in modeling proximity systems allows for anticipating and mitigating delays in content delivery, ensuring accurate and timely communication. Velázquez et al. [24] highlighted the flexibility of Petri nets for modeling mobile applications that require efficient management of asynchronous processes, thus laying the groundwork for extending their use in proximity applications, such as those presented in this study.

Khan et al. [25] proposed a one-time password (OTP) scheme based on stochastic Petri nets, specifically designed to enhance security in authentication systems using mobile devices. Their approach leverages Petri net modeling to accurately represent the processes of OTP generation, transfer, and real-time verification, incorporating intermediate mathematical calculations performed by the user.

2.5. Gaps in Existing Research

Through the review of the state of the art, several significant gaps in the existing research have been identified that this study seeks to address:

• Integration of Petri nets in geolocation-based mobile applications: There is a lack of formal models for concurrent and asynchronous mobile systems. This study fills this gap by utilizing Petri nets to optimize the real-time delivery of promotions, providing a formal framework for managing complex interactions in mobile applications.
• Optimization of proximity detection: Although previous studies have addressed location tracking algorithms, there are limitations in the accuracy and efficiency of proximity detection. This work enhances these aspects by implementing the Haversine formula, offering a more precise solution for calculating distances in geolocation-based applications.
• Management of asynchronous behaviors: There is a gap in the efficient management of asynchronous interactions between mobile applications and APIs, crucial for real-time systems. The use of Petri nets in this study directly addresses this need, providing a robust model for handling concurrency and asynchrony.
• Scalability and robustness: Existing solutions often lack scalability for proximity-based mobile applications. This study addresses this limitation by combining modern technologies (Kotlin, Laravel) with formal modeling through Petri nets, offering a more scalable and robust solution.
• Performance analysis in location-based promotion systems: There is a lack of detailed analysis regarding the performance of real-time location-based promotion delivery systems. This study fills this gap by providing a comprehensive performance analysis of the system, including response times and accuracy in proximity detection.

By addressing these gaps, this study significantly contributes to the field of geolocation-based mobile applications and the modeling of concurrent systems, offering innovative solutions and improvements in critical areas of research.

2.6. Mobile Application Development

In mobile application development, Kotlin has gained popularity as an effective programming language for Android due to its ease of use [26]. Applications that integrate geolocation services and APIs for content delivery must consider factors such as response time and communication efficiency to ensure a positive user experience. The implementation of modern architectures, such as REST developed with Laravel on the backend, enables more efficient request handling and enhances scalability [27]. Figure 1 illustrates the communication flow of the REST API, which interacts with a mobile client or device and a database.

The combination of geolocation, Petri nets, and modern mobile development technologies presents a significant opportunity to optimize user interaction with real-time promotion systems. Petri nets not only allow for precise representation of asynchronous interactions but also provide a solid foundation for developing scalable and effective applications in the future.

3. Materials and Methods

3.1. Materials

3.1.1. Development Tools

The following tools were used for the development of the API and the mobile application:

• API: Developed in PHP (version 8.0.2) using the Laravel framework (version 9.2). This framework was chosen for its ease in creating RESTful APIs and its robustness in managing routes and HTTP requests.
• Mobile Application: The application was developed in Kotlin (version 1.9.0) for Android mobile devices to leverage its native capabilities for geolocation and real-time communication.
• Geolocation: For distance calculations, the Haversine formula was implemented in the API, which receives the mobile device’s geographic coordinates and calculates proximity to points of interest stored in a database.
• Database: MySQL (Ver 15.1 Distrib 10.3.39-MariaDB) was used to store the shopping centers’ coordinates and promotional information.
• Petri Nets: Petri nets were used to model the asynchronous behavior of requests between users and the API.

API Development Technology Environment

• Operating System: Ubuntu 20.04;
• Processor: Core i7 2.5 GHz;
• OS Type: 64-bit;
• RAM: 16 GB;
• Hard Drive: 1 TB.

Mobile Application Technology Environment

• Device 1: Huawei smartphone with Android version 9, RAM 4 GB;
• Device 2 (emulated): Pixel 7 Pro with Android version 13, RAM 2 GB.

IDE for Mobile Application Development

• IDE: Android Studio Iguana | 2023.2.1 Canary 7.

IDE for API Development

• IDE: Visual Studio Code version 1.94.2.

The diagram in Figure 2 underscores the distributed nature of the system, highlighting the distinct separation between the mobile frontend and the backend infrastructure. It also illustrates the integration of geolocation services and advanced modeling techniques, which are implemented to ensure efficient performance and a seamless user experience. This architectural design emphasizes the system’s modular approach, facilitating scalability and maintainability while optimizing resource utilization across distributed components. In Figure 2, gray ellipses represent the main components of the system, including Mobile Application, API, MySQL, Laravel, PHP, Kotlin, Android, and Petri Nets. Green ellipses indicate development environment elements: Database, API development, modeling, and Mobile app development.

3.2. Methods

3.2.1. General System Design

The proposed system consists of two main components: a mobile application developed in Kotlin as the frontend and a backend API implemented with Laravel. Communication between these components is carried out through asynchronous HTTP requests, in which the mobile application sends the user’s coordinates to the API in real time. The API responds with relevant promotional advertisements when the user is within a 600 m radius of a registered shopping center.

A structured methodology is followed for the development of the mobile application and its communication with the API, detailing the implementation of key system components and technology integration. In addition to using Petri nets to model the communication flow between the mobile application and the API, ensuring precise, conflict-free interaction, the modeling allows us to visualize the optimal communication flow, making it smooth and efficient and enhancing the user experience. The proposed methodological process is described below.

3.2.2. Haversine Formula for Proximity Calculation

The distance calculation between the user’s location and shopping centers is performed using the Haversine formula, which estimates the distance between two points on the surface of a sphere based on their geographic coordinates (latitude and longitude). Since the Earth is approximately spherical, this formula provides an accurate estimation of the distance in ms [18]. The Haversine formula is defined by Equation (1).

$$d=2r·arcsin\left(\sqrt{{sin}^2\left({\displaystyle \frac{\Delta \phi }{2}}\right)+cos\left({\phi }_1\right)·cos\left({\phi }_2\right)·{sin}^2\left({\displaystyle \frac{\Delta \lambda }{2}}\right)}\right).$$

(1)

The following notations are used:

• d is the distance between the two points.
• r is the Earth’s radius (approximately 6371 km).
• ${\phi }_1$ and ${\phi }_2$ are the latitudes of the two points in radians.
• $\Delta \phi$ is the difference in latitudes, ${\phi }_2-{\phi }_1$.
• $\Delta \lambda$ is the difference in longitudes, ${\lambda }_2-{\lambda }_1$.

Although the Haversine formula provides an accurate estimation of the distance between two points on the Earth’s surface, it has significant limitations when applied in practical contexts involving real road networks. For instance, two points separated by a river without a connecting bridge may have a direct distance of 200 m according to the formula, but the actual distance via the road network could be considerably greater due to the necessity of using alternative routes. This scenario illustrates that the formula does not account for physical or topological constraints of the terrain, which can lead to errors in determining whether a user is within the specified proximity range. Therefore, future implementations could benefit from integrating models based on actual road networks to complement or replace calculations that rely solely on geographic coordinates.

3.2.3. Mobile Application Development (Frontend)

The mobile application was developed in Kotlin, chosen for its resource efficiency and compatibility with Android. The application utilizes Google Location Services to obtain the user’s location. Its primary goal is to capture the user’s real-time location, send the coordinates to the API, and receive relevant promotional offers when the user is within 600 m or less of a shopping center. Latitude and longitude coordinates are transmitted to the API via HTTP requests using the Retrofit library. The user interface includes a dynamically displayed share button that appears upon receiving promotions. This button allows users to share offers through social media or messaging applications, leveraging Android Intents to enable seamless integration with multiple platforms.

API Interaction

• The application makes asynchronous requests to the API using Retrofit to send the coordinates.
• The application receives and displays promotions on the user interface when proximity is detected.

The following dependencies were added to the build.gradle file:

Google Location Services to track the user’s location.

• implementation ("com.google.android.gms:play-services-location:21.3.0")

Retrofit Dependencies for HTTP Requests

• implementation ("com.squareup.retrofit2:retrofit:2.9.0")
• implementation ("com.squareup.retrofit2:converter-gson:2.6.4")

The following permissions were added in the manifest.xml file to allow the application access to the internet and GPS usage:

• <uses-permission android:name="android.permission.INTERNET"/>
• <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/>
• <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

3.2.4. API Development (Backend)

The API was implemented in Laravel, a PHP-based framework that facilitates the development of scalable web applications. The API receives coordinates from mobile devices and compares the user’s location with the stored coordinates of shopping centers. Each request uses the Haversine formula to calculate the distance between the user and each registered shopping center. If the distance is less than or equal to 600 ms, the API sends relevant promotional advertisements.

API Structure

• Endpoints: Also known as API routes, endpoints are the paths accessible by the mobile application. The following endpoint receives the geographic coordinates sent by the mobile application.

Through this endpoint, the show method of the OfferController is used, which performs the proximity calculation.

3.2.5. Proximity Calculation

The show method of the offerController controller receives the geographic coordinates sent by the application and calculates the distance between the shopping center and the mobile device (MD).

Algorithm 1 describes the steps to calculate the distance between the mobile device and the shopping center, taking into account the geographical coordinates. The API receives the coordinates and returns a list of offers from any shopping center located within 600 m or less.

Algorithm 1: Show Nearby Stores.

If the calculated distance is less than or equal to 600 m, the API will send the available offers from the shopping center to the mobile device (MD).

3.2.6. Database

The database was implemented using MariaDB. The stores table contains data on the shopping centers, including the shopping center’s ID and its geographic coordinates (latitude and longitude), as shown in

Table 1. Structure of the stores Table.

Field	Type	Null	Key	Default	Extra
id	bigint (20) unsigned	NO	PRI	NULL	auto_increment
name	varchar (191)	NO		NULL
address	varchar (191)	NO		NULL
phone	varchar (191)	NO		NULL
email	varchar (191)	NO		NULL
altitude	varchar (191)	NO		NULL
latitude	varchar (191)	NO		NULL
created_at	timestamp	YES		NULL
updated_at	timestamp	YES		NULL

Attributes of the stores table.

.

The promotions associated with each shopping center are stored in the items table, as shown in

Table 2. Structure of the items.

Field	Type	Null	Key	Default	Extra
id	bigint (20) unsigned	NO	PRI	NULL	auto_increment
stores_id	bigint (20) unsigned	NO	MUL	NULL
name	varchar (191)	NO		NULL
price	varchar (191)	NO		NULL
discount	varchar (191)	NO		NULL
sale	varchar (191)	NO		NULL
image	varchar (191)	NO		NULL
created_at	timestamp	YES		NULL
updated_at	timestamp	YES		NULL

The items table is related to the stores table through the foreign key stores_id.

. The coordinates are saved in geographic point format to optimize proximity queries.

3.2.7. Modeling with Petri Nets

To model the asynchronous and concurrent nature of the interaction between the user and the API, Petri nets were used as a formal tool that allows for the description of distributed and concurrent systems. The system’s behavior was modeled through places and transitions, representing events such as receiving coordinates, detecting proximity, and sending promotions.

To represent the Petri net, the structure includes the following places (P) and transitions (T), which reflect the flow of interaction between the mobile application, the API, and the geolocation-based promotions, as shown in

Table 3. Places and transitions of the proposed Petri net.

Places	Transitions
P1: Location query	T1: Send location to API
P2: API calculates distance	T2: Proximity check (600 m or less)
P3: Proximity confirmed	T3: API sends offers to mobile device
P4: Read send	T4: Send message
P5: Buffer out	T5: Receive message
P6: Ready receive	T6: Send acknowledgment
P7: Message received	T7: Receive acknowledgment
P8: Acknowledgment sent	T8: Process 1
P9: Buffer in	T9: Process 2
P10: Wait for acknowledgment
P11: Acknowledgment received

.

Communication Flow

The Petri net shown in Figure 3 describes Table 3. The flow starts at P1 with a location query and moves through the network using the following main connections:

• The initial sequence P1 → T1 → P2 represents the transmission of coordinates to the API;
• P2 → T2 → P3 models the proximity verification process;
• Transitions T4, T5, T6, and T7 handle message exchange between buffers (P5 and P9);
• Places P8 and P11 manage communication acknowledgments.

The initial state of the system is represented by the initial marking vector, which specifies the initial distribution of tokens across the places. The initial state is shown in vector (2).

$${\mathbf{M}}_0=[1,0,0,0,0,1,0,0,0,0,0].$$

(2)

The flow of tokens within the net ensures event synchronization and prevents collisions in the communication between the mobile device and the API. The distribution and transition of tokens effectively model the system’s concurrent behavior.

Algorithm 2 represents the operational process of the Petri net for the proximity-based promotion delivery system. It describes the key steps of the system, from obtaining the user’s location to delivering relevant promotions based on proximity.

Algorithm 2: Nearby Promotions.

The input matrix (I) describes the number of tokens consumed in each place when a transition is triggered.

$$\mathbf{I}=\left[\begin{array}{ccccccccc}1& 0& 0& 0& 0& 0& 0& 0& 0\\ 0& 1& 0& 0& 0& 0& 0& 0& 0\\ 0& 0& 1& 0& 0& 0& 0& 0& 0\\ 0& 0& 0& 1& 0& 0& 0& 0& 0\\ 0& 0& 0& 0& 1& 0& 0& 0& 0\\ 0& 0& 0& 0& 1& 0& 0& 0& 0\\ 0& 0& 0& 0& 0& 1& 0& 0& 0\\ 0& 0& 0& 0& 0& 0& 0& 0& 1\\ 0& 0& 0& 0& 0& 0& 1& 0& 0\\ 0& 0& 0& 0& 0& 0& 1& 0& 0\\ 0& 0& 0& 0& 0& 0& 0& 1& 0\end{array}\right]$$

The output matrix (O) describes the number of tokens placed in each place when a transition is triggered.

$$\mathbf{O}=\left[\begin{array}{ccccccccc}0& 0& 0& 0& 0& 0& 0& 1& 0\\ 1& 0& 0& 0& 0& 0& 0& 0& 0\\ 0& 1& 0& 0& 0& 0& 0& 0& 0\\ 0& 0& 1& 0& 0& 0& 0& 0& 0\\ 0& 0& 0& 1& 0& 0& 0& 0& 0\\ 0& 0& 0& 0& 0& 0& 0& 0& 1\\ 0& 0& 0& 0& 1& 0& 0& 0& 0\\ 0& 0& 0& 0& 0& 1& 0& 0& 0\\ 0& 0& 0& 0& 0& 1& 0& 0& 0\\ 0& 0& 0& 1& 0& 0& 0& 0& 0\\ 0& 0& 0& 0& 0& 0& 1& 0& 0\end{array}\right]$$

The incidence matrix (C) is obtained by subtracting the input matrix from the output, solving Equation (3):

$$\mathbf{C}=\mathbf{O}-\mathbf{I}.$$

(3)

3.2.8. Graphical Representation

Figure 4 illustrates the Petri net designed to model the flow of tokens between various states and transitions. This diagram enables the observation of both concurrent and sequential behaviors of the system, providing a valuable tool for identifying bottlenecks and optimizing event flow.

3.2.9. Calculation of T-Invariants

Step 1: Incidence matrix (C)

The T-Invariants are non-negative vectors that satisfy Equation (4), obtained through linear algebra. Given a system with 11 places ($P1,P2,\cdots ,P11$) and 9 transitions ($T1,T2,\cdots ,T9$), the incidence matrix $\mathbf{C}$ describes how transitions affect places. Each row corresponds to a place, and each column corresponds to a transition.

The values in the matrix are as follows:

• 1: A token is added to the place when the transition occurs.
• −1: A token is removed from the place when the transition occurs.
• 0: The transition does not affect the place.

Step 2: Define the linear system

From the incidence matrix C, the following system of homogeneous linear equations is derived, defined by Equation (4):

$$\mathbf{C}·\mathbf{x}=\mathbf{0}.$$

(4)

To obtain the T-invariants, it is necessary to solve Equation (4).

Here, $\mathbf{x}$ is a column vector of size nine (corresponding to the number of transitions). The solution $\mathbf{x}$ describes the combinations of transitions that, when activated, do not alter the total number of tokens in the system.

Step 3: Solve the system

This is a homogeneous system of equations. When solving, we find that all transitions $x_1,x_2,\cdots ,x_9$ are related, as shown in Equation (5):

$$x_1=x_2=x_3=\cdots =x_9$$

(5)

In other words, $x_1,x_2,\cdots ,x_9$ are proportional to each other. This indicates that all transitions can be activated in sequence without altering the total distribution of tokens in the system.

T-Invariants

The resulting T-invariant can be represented as a vector where all elements are equal to the same scalar value k. If a vector x is a solution, any scalar multiple $k·\mathbf{x}$, with k > 0, is also a valid solution. This implies that k serves as a scaling factor for the T-invariant, allowing its magnitude to be adjusted proportionally. Specifically, the vector can be expressed as in Equation (6):

$$\mathbf{x}=k·{[1,1,1,1,1,1,1,1,1]}^T.$$

(6)

where the invariant property of the system is reflected.

This T-invariant indicates that all transitions $T_1,T_2,\cdots ,T_9$ can fire together repeatedly without changing the global state of the Petri net.

T-Invariant Analysis

The fact that all the transitions are related suggests that the net exhibits cyclical behavior. This implies that the system returns to its original state once all transitions have occurred, allowing the transitions to repeat indefinitely. In practical terms, this system models a continuous process that neither consumes nor generates tokens cumulatively.

A single non-trivial T-invariant was obtained, confirming the cyclical behavior of the system. This analysis is useful for understanding the conservation of resources or tokens in a system and for detecting potential repetitive execution cycles.

Liveness

A Petri net is live if, for any initial marking, it is possible to reach a configuration in which any transition can eventually be fired. This means that no transitions become unreachable over time.

• The obtained T-invariant is $\mathbf{x}=[1,1,1,1,1,1,1,1,1]$, indicating that all transitions are related in a way that allows them to activate cyclically, without any becoming permanently inactive.
• This implies that the net exhibits cyclical behavior in which transitions can repeat indefinitely, suggesting that all transitions can fire at some point, fulfilling the liveness condition.

• Therefore, the net is live.

Boundedness

A Petri net is bounded if there exists an upper limit on the number of tokens in any place, regardless of how many times the transitions are fired. Formally, a net is k-bounded if the number of tokens in each place does not exceed a fixed number k.

• The T-invariant is $\mathbf{x}=[1,1,1,1,1,1,1,1,1]$, which suggests that the number of tokens in the places is conserved. Each transition moves a token from one place to another without accumulating tokens in any place.
• There is no excessive accumulation of tokens in any place, so no token limit is exceeded. This implies that the net is 1-bounded, meaning the number of tokens in any place never exceeds 1.

• Therefore, the net is bounded.

The Petri net in Figure 5 represents the complete flow of the proximity-based promotion delivery system, with a token in P8 (Acknowledgment Sent) and P11 (Acknowledgment Received).

The following block diagram illustrates the system’s and subsystems’ architecture and processing flow, structured in hierarchical components as shown in Figure 6. This diagram details the relevant key interactions.

3.2.10. System Evaluation

The system evaluation was conducted by measuring two key metrics:

• API Response Time: The time taken by the API to process a proximity request and send a response with promotions was measured. Tests were conducted in a controlled environment.
• Proximity Detection Accuracy: The accuracy of the Haversine formula was tested to determine its capability to detect whether a user was within a 600 m radius of a shopping center.

Offers are received on MD1 and MD3 if and only if they are within a radius of 600 m or less from the participating shopping centers, as shown in Figure 7.

The block diagram shown in Figure 8 illustrates the architecture and processing flow of a geolocation and promotion delivery system, structured as a hierarchical sequence of interconnected components.

4. Results and Discussions

4.1. Results

The implementation of the mobile application and API for the real-time delivery of promotional ads was evaluated in a controlled environment, simulating user interaction with shopping centers. The following presents the results obtained from the performance metrics and the effectiveness of the system based on the detected proximity.

System Performance

Multiple tests were conducted to evaluate the system’s response time, recording the time from when the user entered the 600 m radius of a shopping center to the reception of a promotional ad. The results are summarized in

Table 4. Response time results and detection accuracy in different tests.

Test	Distance (m)	Response Time (ms)
1	349	131
2	344	136
3	185	126

, which shows the test conducted with the HEB, GranD Toreo, and Soriana Carrera shopping centers in Ciudad Victoria, Tamaulipas.

During the tests, the geographic coordinates of these shopping centers were configured in the API’s database.

The data show that the average response time for ad delivery is approximately 131 ms.

The offers recorded in the API database are for testing purposes. Figure 9 displays the available offers in three different shopping centers (HEB, GranD Toreo, and Soriana Carrera) as seen on a mobile application interface. Each screen represents a specific shopping center, showing the store’s name, the calculated distance between the user and the shopping center, and a list of items on sale. For each item, details include the item name, regular price, discount percentage, and discounted sale price.

• Soriana Carrera (Distance: 349 m): The available items include a professional notebook and school scissors, with their regular and discounted prices. The user’s location (latitude and longitude) and an execution time of 131 ms are also presented.
• HEB (Distance: 344 m): The displayed offers include a soccer ball, a tennis ball, a baseball, and a bath towel, each with respective prices, discounts, and final sale prices. The latitude and longitude coordinates are shown at the bottom, with an execution time of 136 ms.
• GranD Toreo (Distance: 185 m): Offers here include a professional notebook, school scissors, and a soccer ball, with details on regular and sale prices. The geographic coordinates and execution time (126 ms) are also displayed.

Each screen allows the user to retrieve offers with the button labeled “OBTAIN OFFERS” at the bottom, suggesting that the application can fetch real-time data based on the user’s proximity to these shopping centers.

One of the key aspects evaluated was the accuracy of the Haversine formula in detecting proximity. The data demonstrate that the implementation enabled precise identification of when the user was within the configured proximity radius for each shopping center, ensuring timely delivery of promotional advertisements.

4.2. Discussions

The approach proposed in this study demonstrates several significant advantages when compared to recent research in the field of mobile applications based on geolocation and concurrent system modeling.

4.2.1. Accuracy in Proximity Detection

The implementation of the Haversine formula provided precise proximity detection, as evidenced by average response times of 131 ms. This efficiency validates the effectiveness of our approach in delivering real-time promotions. Landolsi et al. [5] demonstrated that effective location-tracking algorithms can significantly enhance proximity detection in mobile applications by reducing data redundancy and improving system responsiveness. Our findings align with these results, underscoring the importance of accurate localization algorithms.

4.2.2. Concurrent System Modeling

Our T-invariant analysis confirmed the system’s ability to maintain a continuous flow of interactions without excessive token accumulation, validating the robustness of the Petri net model. This feature is critical for systems requiring real-time interactions and handling multiple concurrent requests, such as our proximity-based promotion application. Hsieh [15] emphasized the importance of using discrete timed Petri nets to analyze resource failures in cyber-physical systems, ensuring liveness and boundedness. Our approach aligns with these principles, demonstrating the effectiveness of Petri nets in modeling complex mobile systems.

4.2.3. Asynchronous Behavior Management

The system’s ability to handle asynchronous behavior resulted in a seamless user experience, with real-time updates occurring without noticeable interruptions. This represents a significant improvement over traditional systems that may experience delays or communication collisions. Yang et al. [23] addressed the modeling and analysis of critical properties in interactive mobile systems using Petri nets. Our approach aligns with these principles, showcasing the efficacy of Petri nets in managing complex interactions within mobile applications.

4.2.4. Scalability and Robustness

The integration of Petri nets into proximity logic modeling has proven to be a robust and scalable methodology for such applications. Compared to more conventional approaches, such as those presented by Riabova et al. [4] in geolocation-based marketing strategies, our system not only optimizes location-based content delivery but also facilitates future system expansion. This feature is particularly valuable for mobile applications that must quickly adapt to changes in demand or functionality.

The effectiveness of Petri nets in managing asynchronous systems was evidenced by consistent response times and the absence of communication collisions between the mobile application and the API. The network structure allowed for token distribution that accurately reflected the flow of concurrent events, such as receiving coordinates and verifying proximity. This ensured sequential message processing without disrupting other processes, thereby optimizing the user experience.

Petri net modeling provided a clear visualization of potential bottlenecks within the interaction flow. By representing key places and transitions within the system—such as location reception and promotion delivery—areas for improvement were identified in the communication flow. This resulted in greater efficiency in delivering real-time promotions.

This comparative analysis reinforces our study’s contribution to the field, highlighting how combining modern technologies (Kotlin, Laravel) with formal modeling through Petri nets offers significant advantages in terms of performance, accuracy, and scalability for proximity-based mobile applications.

5. Conclusions and Future Works

To address the research questions posed in the introduction, the following conclusions can be drawn based on the results and discussions presented in this article:

• The system efficiently implements real-time delivery of promotional advertisements using the Haversine formula to calculate user proximity to shopping centers. The API developed in Laravel processes mobile device coordinates and sends relevant offers when the user is within a 600 m radius.
• The integration of Petri nets provides significant benefits for modeling the asynchronous and concurrent behaviors of the mobile application. The Petri net model enables an accurate representation of interactions between network requests, message delivery, and user proximity detection, optimizing the user experience.
• The use of Petri nets allows identifying and optimizing bottlenecks in the interaction flow. The network structure facilitates visualization of potential improvement areas in communication flow, leading to greater efficiency in real-time promotion delivery.

The design and implementation of the mobile application for real-time delivery of promotional advertisements has proven to be an effective and efficient solution for communication between shopping centers and users. Through the use of the Haversine formula and geolocation, a system has been established that accurately detects user proximity, allowing the API, developed with Laravel, to send relevant information at timely moments.

Modeling the system’s behavior with Petri nets has been crucial to understanding and optimizing the asynchronous and concurrent nature of interactions. This approach ensures a smooth user experience by minimizing response times and maximizing the relevance of delivered promotions, creating a seamless, uninterrupted user experience.

The Petri net structure has facilitated the identification of potential bottlenecks and has proven invaluable for ensuring the liveness and boundedness of the system, meaning that all transitions remain available at any time without exceeding a reasonable limit on resources. This contributes to the robustness and stability of the system—key elements for applications that require real-time interactions.

The combination of modern technologies, such as Kotlin for the mobile application and Laravel for the backend, with Petri net modeling has proven to be an effective and scalable solution, paving the way for future expansions and improvements in the functionality of similar applications.

In conclusion, this research not only highlights the feasibility of the implemented system but also lays the foundation for future applications in proximity marketing. The integration of formal models, such as Petri nets, in mobile application and web service development offers a valuable approach to improving the efficiency and effectiveness of similar systems in the future.

Regarding limitations to consider, the following are highlighted:

• Standard Petri nets, as used in this study, lack the ability to learn or adapt to dynamic changes in behavioral patterns.
• The API may face scalability issues, particularly if the number of requests increases significantly.
• The mobile application may encounter compatibility problems with older Android versions or devices with limited hardware capabilities.

Regarding future work, the following aspects are proposed:

• Enhancing the Petri net structure by integrating neural components to enable learning capabilities, allowing the system to deliver promotions based on user interests.
• Implementing load distribution technologies to optimize system performance under high demand.
• Conducting tests on a variety of devices to ensure compatibility and optimizing the code for devices with limited hardware resources.
• The share button enables promotions to reach a broader audience. As future work, it is suggested to integrate tracking metrics to evaluate the real-time impact of shared promotions.