## 3 Proposed Model
### Model Phases
If the energy level of the receiver's node drops below a predetermined minimum threshold, a \"DENIED_LOW_RESOURCES\" response is sent to the sender, resulting in the termination of the connection. Conversely, if the energy level is deemed sufficient, the receiver applies specific criteria to determine which messages should be accommodated within its buffer. As outlined in Algorithm 5, if the receiver has ample energy and the message is not already in the buffer, several checks are conducted, primarily focusing on the message's size. If the message size exceeds the buffer capacity, it is rejected. However, if the available free buffer space meets or exceeds the message size, the message is accepted. In cases where the free buffer space is insufficient for the message size, the receiver systematically removes the oldest messages from the buffer until adequate space is available to accommodate the incoming message. Upon accepting the message, the receiver sends a \"RCV_OK\" packet to the sender, containing the message ID, confirming successful reception and readiness for subsequent transmission. ```
1.ReceiverSideProcessing():
2.ReceiveMetadataFromSender()
3.CheckNodeEnergy()
4.IfEnergyBelowThreshold():
5.SendDenialResponse()
6.Else:
7.ProcessIncontingMessages()
8.ProcessIncomingMessages():
9.For each message metadata received:
10.CheckMessageAcceptanceCriteria()
11.IfMessageAccepted():
12.AcceptMessageAndSendConformation()
13.Else:
14.ContinuToNextMessage()
15.CheckMessageAcceptanceCriteria():
16.IfMessageInBuffer():
17.Returnfalse
18.IfMessageSizeExceedsBufferCapacity():
19.Returnfalse
20.IfFreeBufferSpaceSufficient():
21.Returntrue
22.Else:
23.DeleteOldestMessagesUntilSpaceAvailable()
24.Returntrue
25.DeleteOldestMessagesUntilSpaceAvailable():
26.WhileFreeBufferSpaceLessThamMessageSize():
27.DeleteOldestMessageFromBuffer()
28.AcceptMessageAndSendConformation():
29.SendResponseToSender(\"RCV_OK\",MessageID)
30.ReceiveMetadataFromSender():
31.Receive metadatamessage from sender
32.CheckNodeEnergy():
33.Check energy level of receiver's node
34.EnergyBelowThreshold():
35.Determine if energy level falls below minimum threshold
36.SendDenialResponse():
37.Send response to sender indicating insufficient resources (\"DENIED_LOW_RESOURCES\")

## 4 Performance Evaluation

The simulator employed in the proposed research is the ONE (Opportunistic Network Environment) simulator, distinguishing itself from other Delay-Tolerant Networking (DTN) simulators [27; 28]. Initial conditions are established to replicate the DakNet scenario, where three rural cities lack traditional communication infrastructure, relying solely on opportunistic networking. IoT nodes, representing pedestrian groups and trans, are deployed within each city, and their movements and interactions are simulated over a designated time period. At the beginning of the simulation, IoT nodes are initialized with specific characteristics and parameters. Each node is assigned attributes such as its mobility pattern (random walk, correlated walk), speed, pause time, buffer size, and communication range. Initial positions of nodes within the cities are determined based on the simulation environment's layout and configuration. Nodes establish connections opportunistically when they come within communication range of each other. While conventional DTN simulators predominantly focus on simulating routing protocols, our approach integrates mobility modeling with DTN routing within the simulations. Connectivity among nodes is established based on various factors, including their geographical locations, communication ranges, and bit rates. The simulations encompass diverse categories of groups, such as vehicles and pedestrians, each characterized by a unique set of parameters. These parameters encompass attributes like message buffer size, radio range, and mobility model, which collectively contribute to the realism and accuracy of the simulated scenarios.