We also propose a salt hashing algorithm that encrypts the original keys into a different form to avoid the physical attacks at the end device side. We analyzed the proposed key generation performance in terms of the computation time, the required storage, and the communication overhead. We implemented and tested the proposed key generation protocol using the NS-3 network simulator. The proposed lightweight key generation protocol significantly enhances the security of the original LoRaWAN at a negligible overhead. The proposed protocol reduces the power consumption and transmission time by two times compared with some previous protocols. In addition, the proposed key generation protocol can resist attacks, such as key compromising attacks and replay attacks, and it supports the Perfect Forward Secrecy, which was not supported by LoRaWAN.Recently, many Low Power Wide Area Network (LPWAN) protocols have been proposed for securing resource-constrained Internet of Things (IoT) devices with negligible power consumption. The Long Range Wide Area Network (LoRaWAN) is a low power communication protocol that supports message authentication, integrity, and encryption using two-session preshared secret keys. However, although the LoRaWAN supports some security functions, it suffers from session key generation and key update problems. This motivates us to introduce a new key management protocol that resolves the LoRaWAN problems and supports key updates. The proposed protocol is based on hash chain generation using a one-way hash function. Network entities share a common hash chain of  Currently, it is the Internet of Things (IoT) era, where billions of tiny IoT end devices are maintained and deployed worldwide. According to an Ericsson report , the numHowever, these short-range protocols cannot be deployed for critical applications that require a wide communication range, such as smart cities . AlthougA lot of IoT security protocols have been published to satisfy the requirements of tiny devices with limited storage and power. In , the autMost of the existing LPWAN protocols mainly focus on power issues and communication range issues, while security was a secondary issue that did not have an excellent investment. The security importance in the IoT networks becomes more critical than previously because many threats are related to peoples’ real lives. Moreover, the loss from security events can be severe due to the effective connectivity and scale of the IoT networks. Earlier research on IoT security ,15 has dLoRaWAN protocol specifications  indicateIn LoRaWAN protocol v1.02 , it is pFurther, the original LoRaWAN protocol weakens the end-to-end security and cannot resist replay attacks. The authors of  proposedFurthermore, the authors consider the end device or network server as the target for the desynchronization attacks that can disconnect the end devices from the network. The authors also recommended that the AppNonce support freshness provides the detection against the replay attacks. In addition, they recommend verifying the received Join-Accept message that matches the sent Join-Request message and checking if the session keys have been shared or not. The authors of  attempteIn this paper, we propose a key management protocol that supports the generation of the hashed key using one master secret key that is managed by the network server. The hash chain generation is a lightweight solution to support unique keys per session and support periodic updates for the session keys. We also propose salt encryption for the generated keys to protect the original key from attackers. Physical attacks in the original LoRaWAN can happen as the end devices can be reached easily, and the key material can be accessed. The proposed protocol supports two cases, the first one for low power applications with high security and the second one for extremely low power applications with a medium security level. The proposed protocol enhances the key update mechanism by using n keys for future communication. Storing these keys with salt encryption can hide the original value and can prevent any physical attacks. Any compromising for a salted key can expose any information about the original hidden key and cannot compromise the original master secret key generated by the network server per each end device for future communication between the end device and network server.Proposing a dynamic hash chain key generation that produces short-lived session keys. The use of distinct hash-based random keys for authentication and integrity check can increase the security level and avoid attacks that compromise the key;Proposing salt encryption for the hashed keys to prevent the physical attacks by the self-generation of random values that can hide the original keys from the outside attackers and inside attackers;Preventing replay attacks by adding a timestamp to each transmitted message;Supporting low-overhead key updates to further enhance the security level and prevent the key compromising attacks;Supporting forward secrecy, which means that even if a past key was compromised, it would not allow the attacker to predict future keys;Supporting secure key exchange between the network server and the end devices (encrypting the server’s messages using the stored session keys).The proposed protocol uses the AES protocol in two modes for authentication and encryption and can support a high-security level over the original LoRaWAN. The power consumption in the proposed two cases is slightly different from the original LoRaWAN that consumes lower power than the proposed protocol, due to its communication overhead. The contributions of this paper are summarized as follows:This paper is organized as follows: In , a securTo mitigate this problem, the author suggested extending the size of the DevNonce value to 32 bits. In , the autAnother problem with the LoRaWAN protocol is that the network server generates both session keys. Thus, the network operators can decrypt and capture all the data passing the network server. The authors of  also havSingle point of failure: The network server generates the session keys per session for each end device that can affect network security if the network server is compromised;No perfect forward secrecy: The LoRaWAN system depends on the preloading of two root keys used to generate the session keys. If the long-life root keys  are compromised, the previous session keys can be recovered. Therefore, the original LoRaWAN cannot satisfy the perfect forward secrecy;Physical attacks: Long-term keys and session keys are accessible to the attackers since they are stored in flash memory at the end device. The original LoRaWAN cannot resist the physical attacks;Network operators vulnerabilities: Once the network server generates the application key AppSKey for the application server, the network operators can decrypt the end device data and modify it. Separation of the network server role and application server role is required;No key update in the OTAA: Join procedure in the Over-The-Air Activation (OTAA) mode using the long-term keys (NwkKey and AppKey) to derive the session keys. The generated session keys can be updated by sending a new Join-Request message. However, the long-term root keys cannot be updated. These keys are preloaded at each end device by the manufacturer. The root key update is critical for the devices that join the LoRaWAN network via OTAA;No key update in the ABP: The AppKey and NwkKey are not preloaded on the end device in the Activation By Personalization (ABP) mode. Only session keys  are stored to allow immediate communication between the end device and the network server. The end device uses the same session keys for a lifetime. If the end device is physically attacked, the session keys are compromised, posing security threats at the end device.The most critical security problems of the original LoRaWAN and previous methods are summarized as follows:We summarize the differences between the proposed protocol and the other existing methods in End device: An IoT end device is used for wide-range communication to transfer small data using low-frequency bands. These end devices can be deployed in different fields, such as smart building, factory automation, smart cities, and farm automation;Gateway: An IoT end device with high capabilities to receive data from the end nodes via a LoRaWAN radio link. Then it forwards the collected packets to the corresponding network server via standard IP communication;Network server: It is a LoRaWAN server that controls and manages the whole network. It receives many packets, removes redundancy between them, executes authentication checks to accept or reject the packets, and finally decides which gateway is the most suitable to send an acknowledgment packet back to the end device. In our paper, we consider the Network Server as a trusted third-party agent that is authorized by a Certificate Authority (CA) organization to generate and execute security tasks, manage key generation, and support revoking mechanisms for the malicious nodes. To reduce the communication burden on the Certificate Authority (CA) due to the frequent security message requests of the end devices gateways.LoRaWAN protocol  is desigThe network server authenticates the LoRa messages using the network session key shared previously between the end device and the network server. The LoRaWAN protocol stack consists of the MAC and application layers, while the physical layer uses the LoRa RF. The application layer communication is secured with the application session key shared previously between the application server and the end device. The message format of the original LoRaWAN consists of the MAC payload, MHDR (MAC header), FHDR (frame header), and MIC (Message Integrity Code). The MIC is calculated over the MAC payload using the network session key for authentication purposes. The MAC payload can be a Join-Request message or Join-Accept message, while the size varies between 51 and 222 bytes.New end devices must complete an activation process to join the LoRaWAN network. Two session keys are shared between the end devices and the network server during this activation process. LoRaWAN protocol has two types of activation. The first type is Over-The-Air Activation (OTAA), and the second type is Activation by Personalization (ABP) .The end devices communicate with the network server to start the network joining procedure. In , the actJoin-Request message: The end device begins the network joining procedure by transmitting a Join-Request message. Each end device includes the application identifier (AppEUI), the global end device address (DevEUI), and the random value (DevNonce) in the Join-Request message. The MIC value is calculated over the Join-Request message to ensure message authenticity and integrity. The following formula calculates the MIC code using the AES 128 protocol in the authentication mode:The NwkKey is the network root key previously preshared between the end node and the network server (configured by the manufacturers or at commissioning). The Join-Request message format is shown in Authentication at the network server: The network server performs the security check over the received Join-Request message by checking the freshness of the attached DevNonce to avoid the replay attack. If the DevNonce is not valid or previously used, the network server rejects the joining request. Otherwise, the network server completes the end device authentication process by calculating the MIC over the received Join-Request message. Comparing the calculated MIC with the received MIC to authenticate the end device validity, if both are equal, the network server starts generating the session keys. Both the Network Session Key (NwkSKey) and Application Session Key (App SKey) are derived using Equations (2) and (3) as follows:The network server generates an AppNonce random number. NetID refers to the network ID and separates the geographically duplicated LoRaWAN networks.Join-Accept message: it contains NetID, AppNonce, DevAddr, RxDelay, DLSettings, and CFList. The Device Address DevAddr is a 32bits that is assigned for the end device within the joined network. RxDelay represents the delay between the sending and receiving process. DLSettings represents the configuration of the downlink. The optional field CFList represents the channel frequencies. Once the end device receives the Join-Request message, it encrypts the parameters using AES-128 to generate the network session key, the NwkSKey and the application session key AppSKey. The Join-Accept message structure is shown in Each end device can join any LoRa network in ABP mode without the Over-The-Air activation or any join procedures. Thus, the end device does not need AppEUI, DevEUI, NwkKey, and AppKey, which are crucial components for Over-The-Air activation. In contrast to the OTAA mode, the session keys  and device address (DevAddr) are pre-stored on the end device in the ABP mode. Therefore, each end device can instantly start communication once it is powered.Each end device node communicates with the network server for establishing session keys for message authentication and encryption. The frequent communications between nodes and network servers increase power consumption, increase communication costs, and cause network congestion. The current security problems of the LoRaWAN systems motivate us to propose an enhanced, lightweight key management protocol that allows end devices to save power and reduce communication costs. This section describes the proposed protocol with the following steps—Join procedures, securing the generated hash chain against physical attacks, message authentication, message encryption, and hash chain updates. As mentioned before, the LoRaWAN security systems are based on a pre-shared key structure. The Application Key (AppKey) and the Network Key (NwkKey) are used to generate two session keys (NwkSKey and AppSKey). In both join modes OTAA and ABP, the session key updates are considered as a problem. Once the end devices in the ABP mode cannot update the session key, it requires the AppKey and NwKwy to generate new session keys. Only long-term session keys are preloaded at each end device for long life in the ABP mode. In contrast, in the OTAA mode, the key session updates depend on the long-term root keys that can be compromised at any time. Due to these problems, we propose a lightweight key management protocol that enhances the security level and reduces power consumption.Our proposed key generation method uses the initial communication OTAA mode to join the LoRaWAN network and share the security parameters with the network server for future session communication. Like the original LoRaWAN, each end device sends a Join-Request message, while the server responds with a Join-Accept message; both entities derive the session keys for the current session, as explained in n that is generated by the network server. By iteratively hashing Skn, the end device generates n keys using the cryptography function h(.) of length n. We allow each device to generate n unique signing keys from the shared master secret key. The proposed solution helps the end device avoid using the long-term root keys to update the session keys as the original OTAA mode. Also, it prevents the use of preloaded, long-term session keys as ABP mode. The following section explains the key generation method at the end device and the network server. We also summarize the proposed hash chain generation in LoRaWAN in After the OTAA Authentication between the network server and the end device is complete, both share a common one-way hash function h(.) of length n, a master secret key Skn) for the hash function. After the end device passes the Over-The-Air Authentication phase, the network server securely sends the master secret Skn to the end device and the application server (AS) to generate the typical hash chain. A one-hash function h(.) is defined as z = h(y) for a given input y. It is challenging to predict the primary input y from the hashed output z. Hash chains are first proposed by Lamport  as a building block. AES-CMAC uses a secret key and a variable-length message as inputs to return a fixed-length string as MIC. Our proposed protocol uses the key index only to inform the receiver which key to calculate the MIC over the message. Sending the index of the signing key and a random salt value allows the receiver to find the salted authentication key value. By XORing, the received salt value with the original signing key generates the salted authentication key. Sending only the key index and salt value prevents key compromising attacks; even if the attacker sniffs the index, it cannot expose any information about the originally key. Conventional MIC algorithms require sending the signed key and the MIC value calculated over a message to allow the receiver to verify the message. The proposed algorithm does not require sending the key to improve the security level. Both the end device and server store the same hash chain table of n key elements. Each sender randomly chooses one salted authentication key to sign the message using AES128-CMAC and attaches the index of the key; the salt value is used to hide the authentication key to the message as a pointer to the key. The proposed protocol can significantly improve the computation speed, increase the security level, and reduce the network overhead.The message authentication procedures are as follows: The end device picks a salted authentication key The parameters of Equation (6) are described as follows:The sender Di attaches the obtained Then, it calculates the message integrity code of the received message, If the calculated In the original LoRaWAN, the network server (NS) shares some parameters with each end device to derive the AppSKey using these parameters and the prestored AppKey. After the application session key generation, the NS securely transfers the AppSKey to the application server (AS).n to the application server to start generating the same hash chain for the end device, as shown in In our proposed protocol, the NS sends the h(.), n, and the SkThe message encryption procedures are as follows: At the end device side: Picks a salted encryption key After encryption, the end device sends the message, salt value, and key index to the application server.The application server checks the timestamp It XORings the key value Using salt increases the hashed key’s security, making it hard for an attacker to compromise the used key and prevents the application server from tracking the end device data. To prevent physical attacks on the end devices, we recommend that each end device store only the salted hashed keys and the used salted values.In this section, we discuss the proposed key management security properties and objectives compared with the original LoRaWAN security protocol:n. The end device iteratively hash the Skn to generate n hashed keys used as future session keys instead of using the NwkSKey and AppSKey for the long lifetime. In order to avoid the physical attacks at the end devices side, we propose a salt solution to hide the original session keys, so the end devices only store the salted keys and the salt numbers in the database. If an attacker tries to compromise the stored salted keys, he is unable to expose any information about the original session keys. Our proposed solution allows the end devices to send the key index value as a pointer of the original key that is prestored at the network server and end devices instead of sending the key over the open wireless medium as previous authentication solutions for more security. We sacrifice the storage needed to keep an n hash length of keys at the communicated parts to enhance the security level and optimize the network bandwidth. The network server is considered a trusted third-party agent in our proposed solution to generate the master key for the end devices. It securely shares a master secret seed value with the end device and application server. All entities  use a one-way hash function to generate n hashed keys that can be used for message authentication and encryption. Instead of frequent communication with the network server and application server for deriving new session keys or new session key updates, as in the basic LoRaWAN solution, our proposed key management protocol allows the end devices to securely store the hash chain of n elements using a Hardware Security Module. This solution enhances the security level and prevents the use of two long-life session keys as previous LoRaWAN. Our protocol needs only a one-time Over-The-Air Activation to share a session key between the end device and the network and application server. In the initialization phase, the end devices use the pre-shared session keys (NwkSKey and AppSKey) to share a new master secret key Skn to generate a new hash chain based on an agreement between the network server and the end device. The session key updates can be achieved as follows:The network server generates a new master secret Securely send the All communicated entities generate a new hash chain of length n, then the network server and application server storing the generated hash-chain;The end device salted the generated hashed chain with random numbers to store new encrypted keys and only different salt numbers;The end device stores only the salted authentication keys and sated encryption keys in addition to the updated salted values. The hash chain key updating process is shown in In the basic LoRaWAN security protocol, no key updates happened, which is considered a critical issue. The end devices are using two session keys for a long lifetime for authentication and encryption. Our protocol solves the session key update problem by providing different unique keys every session. The end devices store n keys securely; each key is valid for a short time. Randomly choosing one key from the prestored keys and sending only the key index allows the receiver system to authenticate the message. To enhance the security level of the prestored hash chain, we recommend updating the master secret key SkThe proposed protocol uses the OTAA join procedure of the original LoRaWAN to authenticate the end device node to the network server. After the mutual authentication is complete, the network server shares a secret key to allow the end device to generate the keystream of the hashed elements for future session communication. Each end device stores a length n of hashed keys, n key indices, n salted values for authentication, and n salted values for encryption. The original LoRaWAN allows devices to use two lifetime keys to derive the network session keys and application session keys. However, the proposed protocol allows devices to use different salts for authentication and encryption, which increases the security level of the session keys.n in an encrypted way using the NwkSKey that prevents any attacker from exposing the initial master secret. In contrast to the original LoRaWAN, the key derivation depends on the initial parameters that are transferred between the end device and network server in the Join-Request message and the Join-Accept message. The generation of session keys requires transmitting a new request message to the server, which results in significant overhead at the network server and high power consumption at the end device side. The proposed key generation method does not use the long-term keys for session key generation. However, using the root keys to derive the session keys in the original LoRaWAN exposes the generated session keys for being compromised once the root keys are compromised. Key generation depends on the master secret key generated by the network server. Storing n keys for future communication provides updated session keys that are picked randomly to sign and encrypt the messages.The proposed hash chain key generation includes transferring the master secret key SkIn the original LoRaWAN, all session keys are generated using the root keys that make them vulnerable to sniffing attacks. However, the end device generates a keystream from the initial seed key that is preshared securely between the end device and network server in the proposed key generation method. The end device randomly picks any key from the stored salted hash table that hides the original keys in an encrypted form called salted keys. If any attacker physically accesses the end device, the stored key information is unable to reflect the original key parameters .n securely shared between the end device and network server. This key generates n hashed keys by iteratively hashing it n times using one-way hash functions (sha256). Once the proposed key generation method does not depend on the long-term keys to generate the session keys, finding the past session keys is difficult by compromising the root keys. The end devices store only the encrypted version of the original hashed keys  to avoid sniffing the original keys shared and stored at both the network and application servers. Thus, the proposed key generation supports perfect forward secrecy and backward secrecy.Perfect forward secrecy is a security property where the compromise of long-term (root) keys does not expose the past derived session keys . The proBackward secrecy means that the compromise of the long-term keys cannot affect the generation of the future session keys. The proposed protocol allows the end devices to pick randomly one session key for authentication and then send only the key index to allow the receiver to verify the message. Sniffing the key index does not disclose any information about the key, which guarantees forward secrecy.For the original LoRaWAN, the network server registers the DevNonce included in the uplink messages (Join-Request) to prevent replay attacks. However, the end device for the downlink messages (Join-Accept) does not register the received AppNonce from the network server. Therefore, an attacker may register a (Join-Accept) message, wait for the end device to send another (Join-Request) to respond with the registered (Join-Accept). In this case, the end device and the network server derive different session keys. Our proposed key generation method includes a timestamp in each uplink and downlink transmitted and received message to prove the freshness of the messages and prevent any attacker from transmitting different faked messages. Therefore, we proposed to use timestamps instead of nonces to protect the end device and the network server from replay attacks. We summarize the security properties comparison between the proposed protocol and the original LoRaWAN in In this section, we provide formal security analysis and automatic security verification for the proposed key management protocol and the authentication procedures using AVISPA. Automated Validation of Internet Security Protocols and Applications (AVISPA) is a formal security analysis tool that is used for modeling, design, and verification of security protocols. The High-Level Protocol Specification Language (HLPSL) is used to model the security protocol and then convert it to Intermediate Format (IF) using HLPSL2IF. The converted Intermediate Format is analyzed via the other four sub-modules, and the verification result is derived ,30. The The proposed key management protocol is designed in HLPSL and consists of three different roles . The basic role includes three roles corresponding to three network entities, the Device (D), the Network Server (NS), and the Application Server (AS). We used AVISPA verification to model all network entities and the messages between them. Moreover, the AVISPA checks the security features of the proposed protocol and its ability to defend against some attacks. We define some security goals and intruder knowledge, session parameters, and environment. The network entities’ roles are described in The following security properties and attacks are verified and discussed: mutual authentication, perfect forward secrecy, replay attack, unforgeability, and stolen verifier attack. The verification results using AVISPA confirm that the proposed protocol can support the previously mentioned security functions and resists the replay attack, unforgeability, and the stolen verifier attack. The ATSE module confirms that the proposed protocol is safe based on the defined security goals and the environment parameters. The security verification and message sequence of the proposed protocol are illustrated in Security Verification Discussion:We introduced a common hash chain of n keys that are stored only at the authenticated and authorized network entities . The signing keys used are based on the previously shared master secret and one-way hash function. These parameters are shared between the end device and the network server in an encrypted way to prevent any unauthorized user from intercepting or sniffing them. Any node that joined the network must start with the Over-The-Air Activation mode to do the mutual authentication and share two session keys one key for authentication (network session key), and a second key for encryption (application session key). If any end device receiver passed the initial mutual authentication, it can sign messages, generate valid signatures, and verify signatures. In our protocol, only registered and authorized devices can send the authenticated messages. If the receiver (network server) receives an incorrect signature, initially it calculates the signature over the message and starts comparing the received signature with the calculated signature; if it is not equal, the network server will discard the message. Therefore, the proposed protocol is secure concerning unforgeability.According to the definition of the Stolen Verifier Attack, an attacker can steal the verification data from the server to generate communication data using the stolen verification information and sending it to the server. If it succeeds, the attacker can impersonate the end device information from the next authenticated session. However, in the proposed protocol, each end device generates a unique random number called salt authentication value that XORing it with the original secret key, then stores only the salted results and salted values in the salt table. This proposed salt encryption prevents the key compromising attacks for the end device side and also the server side. When the end device sends a message for the server, it sends a key index value that pointed to the originally used key, the salted value, timestamp, and device address. The end device never sends the actual key, it sends only the index of the used key. Only the server and end devices have the common hash table, so the server starts to search the table for the used key, picks up the key, and XORings it with a received salt value; the result is the key used by the end device to generate the message integrity code signature over the message. The server then compares the received signature with the generated signature and decides to accept the message or reject it. Now, even the network server is unable know the used key without the generated salt value by the end device, which prevents the network server attacks and preserves the end device’s security.Moreover, if any attacker passed to steal the verification data from the server side, it can only control the current session. However, the future sessions are still secure as the end device uses a unique key per session. Therefore, the proposed protocol defends against the Stolen Verifier Attack. Each LoRaWAN end device is embedded with the tamper-proof device (Hardware Security Module), which prevents an attacker from accessing the security material and parameters. Moreover, the stored keys are stored in different forms using salt encryption, which is recommended for hash table security.If anyone gets access to the hardware module, which is impractical, the attacker cannot return the salted keys to the originally used keys, which makes it very difficult for the attacker to sniff the keys or sniff the master secret key that is used to generate the total hash chain. Concerning forward secrecy, which is a security property where the compromise of long-term (root) keys does not expose the past derived session keys, the proposed key generation depends on the master secret key (Skn) that is securely shared between the end device and the network server. This key generates n hashed keys by iteratively hashing it n times using one-way hash functions (sha256). Once the proposed key generation method does not depend on the long-term keys to generate the session keys, finding the past session keys is difficult by compromising the root keys. The end devices store only the encrypted version of the original hashed keys  to avoid sniffing the original keys shared and stored at both the network and application servers. Thus, the proposed key generation supports perfect forward secrecy. Even the end devices did not send the keys, so sniffing of the key index has no meaning and cannot disclose any information about the future session keys or past session keys.After discussing the security analysis of the proposed key generation protocol, we evaluated the proposed solution in terms of computation cost and communication cost. We also compared it with the basic LoRa security solution and some other related work that is proposed to enhance the security level of the Lora architecture. To evaluate the performance of the proposed protocol, we implemented it in an NS3 simulator using a cryptography library called MIRACL and a LoRaWAN module ,32. The Instead of communicating with the network server every session to derive a new session key, as mentioned in the basic LoRa protocol, our protocol allows every end device to store n session keys to reduce the communication overhead and save the network bandwidth. Each end device requires initially joining the LoRa network and sharing one session key and one application key. Then it uses these keys to securely share a standard master secret key and a one-way hash function. The end device uses the shared security parameters to generate n hashed keys, n salt values for authentication, and n salt values for encryption. The computation cost for each end device is calculated only one time at the initialization phase or in the key-update process.The hash chain generation:We assume that hash chain generation can be offline at the initialization phase of joining a new end device to the LoRaWAN network. However, during the runtime, the hash chain generation computation time can be calculated as follows:n.One hash generation using the Sha-256 hash function requires 0.006 ms. According to the LoRaWAN specification , in a 24The salt random number generation:Salts are in place to prevent someone from cracking original keys and can be stored in cleartext in the database. We recommend an offline salt generation for each original key to reduce the network overhead. In some cases, such as key updating due to normal situations or under attacks, each end device must generate the salt numbers during runtime. The calculation time of salt numbers includes generating random numbers and XORing of the generated salts and the original keys. End devices must store only the salts numbers, the key indexes, and the salted keys in the hash chain table. Generating different salts results in different keys for both authentication and encryption. For the star topology, which is the dominant topology for LoRaWAN, each end device shares a different master secret key to generate a different hash chain that allows the devices to communicate with the network server and application server securely. In contrast, the end devices in the mesh topology share a common hash chain to communicate with each other and with the network servers. Sharing a single common hash chain can expose the system for sniffing attacks and key compromising attacks. However, the proposed key management scheme allows end devices to locally generate different salt values to hide the original keys, resulting in different salted keys at each device. This salting process makes the breaking of original keys very complex and hides the original keys in a different version of keys, preventing any attacks that target the sniffing of the original keys or the initial master seed key. The total time required for generating n random salts of 8 bytes size required approximately (0.001 n) ms, where a single random number consumes 0.001 ms. For n = 5000, the total computation time is 0.001 × 5000 = 5 ms. The computation time of the XOR operation of the random salt number and the original hashed keys are neglected since their computation time is negligibly short.Key generation time:Case 1: for n = 5000 (1 year)The total computation time of the proposed key generation method at each end device using the crypto functions execution time in Case 2: for n = 417 (1 month)When the hash chain generation is updated every month, the required number of keys is 417 to allow the end devices to communicate for 1 month. The total computation time for 1 month is:Authentication time:MIC = 0.0167. The verification time at the receiver (network server) requires one search operation for the key using the attached key index as a pointer and one XORing operation to generate the authenticated salted key, then using the key to generate MIC = 0.0167 ms.The computation time required to sign one message is the consumed time to calculate a Message Integrity Code Encryption time:enc = 4.0274ms. The decryption process at the application server side requires one search operation to find the key and XORing the key with the received encrypted salt value to generate the encrypted salt key dec = 4.1524. We summarize the security computation overhead of the proposed protocol in The computation time required to encrypt one message using AES-128 and a salted encryption key This section analyzes the communication cost in terms of message size for the authenticated messages between the end devices and the network server, the encrypted messages between the end devices and application server, and the required storage at each end device for storing the keystream of length n. The message format for the authenticated messages and encrypted messages are shown in Case 1: High-security level for low power consumptionFor hash chain length n = 5000, each hashed element represents an original key with size 32 bytes, so the total hash chain storage is 5000 × 32 = 160,000 bytes. However, the key size is 32 bytes; we use only 16 bytes key size to support AES-128 authentication and encryption;For n salt values used for generating the authentication keys, each salt size is 8 bytes, and the total size is 5000 × 8 = 40,000 bytes;For n salt values used for encryption, each salt size is 8 bytes; the total size is 5000 × 8 = 40,000 bytes;For n key indices that are used as a pointer for each key in the hash table, each key index is 4 bytes, so the total key indices size is 5000 × 4 = 20,000 bytes.First: The initial storage overhead at the end devices is calculated as follows:After generating the salted authentication keys and salted encryption keys, each end device only stores the salted keys, salt values, and key indices. To avoid the physical attacks and prevent any exposure to the original hashed keys, the end device removes all original hashed keys and only keeps the salted authentication and encryption keys.The total final storage is calculated for n = 5000 as follows:The security overhead in the case of authentication is calculated as follows:The structure of the authentication message is shown in The security overhead in the case of the encrypted message is calculated as follows:The message structure of the encrypted message is shown in Second: the security overhead of the authenticated message and encrypted message:Case 2: Medium security-level for extremely low power consumptionBy allowing the end devices to update the stored keys every month, once the required keys per year for standard LoRaWAN networks are 5000 keys, each end device needs to store only 417 keys for 1 month of communication.Due to the IoT devices’ memory and power limitation, the security overhead can be decreased using salt values of size 2 bytes and the key index of size 2 bytes, so the required storage is Using a timestamp of 2 bytes, the security overhead in the case of message authentication is 2 + 2 + 2 + 4 = 10 bytes. In the case of an encrypted message, the overhead is 2 + 2 + 2 = 6 bytes.We summarize the security overhead of the proposed protocol in In this section, we analyze the required power consumption of the end devices due to the security overhead. We used the LoRa energy calculator  to calcuIn LoRaWAN, for a Spreading Factor (SF) of 12 (worst case) and payload size of 51 bytes, the time on the air is 2465 ms, while for payload size, 222 is 8036 ms. The time on the air for a maximum LoRaWAN payload size of 222 bytes is increased by 3 times more than the minimum LoRaWAN payload size of 51. In contrast, the total transmitted packets for an SF of 12 is 32,339 packets with a payload size of 51 bytes, while for a payload size of 222, the number of transmitted packets is 10847. The total transmitted packets are decreased by 3 times for the maximum payload size of 222 bytes. The Time To Live for an SF 12 for the original LoRaWAN with a payload size of 51 bytes is 0.8 years, while for a payload size of 222 bytes, the battery’s lifetime is dropped dramatically for 0.2 years. We conclude that the worst-case scenario for the LoRaWAN with SF (12), the greater packet size, and the shorter battery lifetime.The results for the LoRaWAN in the best-case scenario with an SF of 7 for a payload size 51, 136, and 222 bytes are also shown in The battery life analysis of the proposed protocol low power case and extremely low power case are shown in For an SF of 7 (best case) and a payload size of 51 bytes, the time on the air is 128 ms, the transmitted packets are 255,593, and the TTL is 6.9 years. For a maximum packet size of 222 bytes, the proposed protocol can support a time on the air of 374 ms, the total transmitted packets are 178,373, and the TTL is 4.8 years. For the SF of 7, when the packet size increased by 3 times, the battery life dropped by one time.In the same way, the proposed protocol for extremely low power authentication with a security overhead of 10 bytes is illustrated in We compare the proposed protocol (low power authentication and extremely low power authentication) with the other related LoRaWAN mentioned protocols in terms of time on the air and Time To Live (TTL) for different packet sizes  bytes, as shown in However, reducing the security overhead in extremely low power cases reduces the time on the air compared with the low power cases that extend the battery lifetime.The proposed key management protocol introduces a little computation overhead compared with the original LoRaWAN to enhance the security by generating salts random values and n authentication keys;The two proposed cases outperform the SEO and DO protocols in terms of time on the air and battery life;The proposed key management protocol uses a negligible hash chain generation that supports security with low power consumption;The proposed protocol uses salt encryption that hides the originally generated keys in different forms and prevents physical attacks;The proposed protocol protects the network from replay attacks by including a fresh timestamp per each transmitted message;For various IoT applications, where high-security levels and battery lifetime are traded off, our protocol can be configured as demanded. For example, test results for two cases  are presented;The proposed protocol can be implemented in extremely low power mode. For example, case 2 can further reduce the power consumption over case 1 by reducing the security overhead from 20 bytes to 10 bytes;The proposed protocol enhances the security level of the IoT networks at a little sacrifice in power consumption.The advantages of the proposed protocol are summarized as follows:This paper proposed a key management protocol for LoRaWAN networks that can support session key updates and defense against key attacks. One master secret key is used to generate n secret keys using a one-way hash function h(.). Salt encryption is supported for the generated hashed keys to protect them against the physical attacks in contrast to the LoRaWAN vulnerable to key compromising attacks. This paper presented two case studies for the key management protocol: one case supporting higher security with low power and the other case supporting extremely low power. We compared the two cases against the original LoRaWAN and other related protocols regarding power consumption and time on the air. The proposed cases demonstrated significant security enhancement at the cost of negligible overhead in the power consumption compared with the original LoRaWAN. In addition, the proposed extremely low power case reduces the power consumption by two times compared with SEO protocol  for a pa


In recent years, there has been an immense amount of research into fall event detection. Generally, a fall event is defined as a situation in which a person unintentionally drops down onto a lower surface. It is crucial to detect the occurrence of fall events as early as possible so that any severe fall consequences can be minimized. Nonetheless, a fall event is a sporadic incidence that occurs seldomly that is falsely detected due to a wide range of fall conditions and situations. Therefore, an automated fall frame detection system, which is referred to as the SmartConvFall is proposed to detect the exact fall frame in a video sequence. It is crucial to know the exact fall frame as it dictates the response time of the system to administer an early treatment to reduce the fall’s negative consequences and related injuries. Henceforth, searching for the optimal training configurations is imperative to ensure the main goal of the SmartConvFall is achieved. The proposed SmartConvFall consists of two parts, which are object tracking and instantaneous fall frame detection modules that rely on deep learning representations. The first stage will track the object of interest using a fully convolutional neural network (CNN) tracker. Various training configurations such as optimizer, learning rate, mini-batch size, number of training samples, and region of interest are individually evaluated to determine the best configuration to produce the best tracker model. Meanwhile, the second module goal is to determine the exact instantaneous fall frame by modeling the continuous object trajectories using the Long Short-Term Memory (LSTM) network. Similarly, the LSTM model will undergo various training configurations that cover different types of features selection and the number of stacked layers. The exact instantaneous fall frame is determined using an assumption that a large movement difference with respect to the ground level along the vertical axis can be observed if a fall incident happened. The proposed SmartConvFall is a novel technique as most of the existing methods still relying on detection rather than the tracking module. The SmartConvFall outperforms the state-of-the-art trackers, namely TCNN and MDNET-N trackers, with the highest expected average overlap, robustness, and reliability metrics of 0.1619, 0.6323, and 0.7958, respectively. The SmartConvFall also managed to produce the lowest number of tracking failures with only 43 occasions. Moreover, a three-stack LSTM delivers the lowest mean error with approximately one second delay time in locating the exact instantaneous fall frame. Therefore, the proposed SmartConvFall has demonstrated its potential and suitability to be implemented for a real-time application that could help to avoid any crucial fall consequences such as death and internal bleeding if the early treatment can be administered. Activity recognition technology is a crucial component of many higher-level automated systems. This is especially true for systems that require recognition and analysis modules for daily life-monitoring applications. Moreover, intelligent activity recognition systems have been at the forefront of many research topics over the past few years. These systems have been propelled by the advancement of machine learning and parallel computational technologies. Furthermore, the rapid development of micro electro-mechanical systems (MEMS) has led to a renewed interest in sensor technologies for efficient and low-cost embedded sensors. These factors have significantly contributed to the bountiful development of intelligent activity recognition systems particularly in the academic and industrial sectors. Majority of these activity recognition systems were developed to distinguish between typical and atypical human activities ,2. TypicFall event detection systems are one of the subtopics of activity recognition systems ,4. This In general, a fall incident is recognized as a sporadic event that occurs rarely in comparison to the occurrence of typical human activities. However, unmonitored fall events can pose a serious health risk. These risks may be accompanied by irreversible implications, leading to morbidity and a decrease in the quality of life. Moreover, a fall event can lead to negative consequences for the patient’s financial and psychological states. Ren et al.  have furRecent research trends have grouped fall event detection techniques based on the type of sensor. The three categories are as follows: wearable devices ,14,15,16Due to these limitations, many researchers have proposed an intelligent vision-based approach. This method can detect the occurrence of fall events without the use of wearable sensors or sensor meshes. A vision-based system relies on surveillance cameras, such as closed-circuit television (CCTV) or Internet Protocol (IP) cameras, to provide continuous images for activity monitoring. In vision-based systems, artificial intelligence techniques are incorporated through image pre-processing modules to extract the relevant and meaningful features that enable more accurate fall detection. It is worth mentioning that vision-based systems also suffer from background noise. However, the evolution of artificial intelligence technologies has positively influenced these systems, making them more robust to the presence of background noise. Moreover, with the arrival of the 5G era, a faster data transfer rate can be achieved between the cameras and central processors. This improvement in technology leads to better detection accuracy. Henceforth, a vision-based system is more practical in providing a non-intrusive solution with robust detection capability that does not require any wearable devices and complementary ambient sensors . NowadayNowadays, the deep learning approach has gained a lot of attention in various fields. This is due to the higher level of performance in comparison to standard machine learning techniques . The deeModification of state-of-the-art CNN architecture, namely VGG-M architecture, to produce a more compact architecture that is suitable for single object tracking applications;The strategy in maintaining the multiple-model object appearance of SmartConvFall that is used to handle model drift and noisy updates;Extensive comparison of training configurations that cover the selection of the optimizer, learning rate, mini-batch size, number of training samples, and region of interest schemes to obtain the best object appearance model for SmartConvFall;Designing a fall detection based on the exact instantaneous fall frame by integration of stacked layers of LSTM architecture to model the objects’ trajectories.In addition, most of the vision-based fall detection systems ,51,52,53The latter part of this paper is organized as follows: Generally, a vision-based fall detection system can be broadly categorized into either a standard machine learning approach or a deep learning approach. A basic processing pipeline for most of the vision-based systems is comprised of background subtraction, feature extraction, and fall detection. Each step in the pipeline requires hand-crafted features that were designed by researchers as the input to the machine learning models. On the other hand, a deep learning approach allows the network to be trained in an end-to-end framework with minimal pre-processing steps to obtain the optimal features . In receOne of the earliest fall event classification systems that adopted the CNN methodology was introduced by Yu et al. , in whicSeveral studies have been conducted using motion information as opposed to color information as the input data to CNN classifiers to detect the presence of fall events. Min et al.  devised Previous studies have revealed that an RNN has been implemented in the development of fall classification systems. The work by Lin et al.  employedThe proposed fall frame detection methodology consists of two stage modules, which are object tracking and instantaneous fall frame detection. In this paper, the Fall Detection Dataset (FDD)  that wasn referring to the total number of object appearance models.In this module, a fully CNN-based tracker is implemented to track the objects’ trajectories for each video sequence using a network with three convolutional layers and three fully connected (FC) layers as demonstrated in Specifically, the SmartConvFall is designed to be a model-free tracker, in which the object appearance model only received the ground truth annotations during the first frame. Hence, a model-free tracker requires careful model update procedures using a weak supervision approach to distinguish the tracked objects from the background throughout the contiguous video frames with limited prior knowledge. Moreover, the proposed tracker is constructed as a binary classifier, with the tracked object being represented by the positive class, while the background class is set to be the negative class. Therefore, a set of sampling data, t representing the current frame and The previous bounding box quations  and 3),,Bt−1=[xta is set to a maximum of 10 pixels to ensure each Primarily, the image patches for ith class that is set to only n FC layers are initialized randomly according to the normal distribution.The training process of the first frame is indispensable for a model-free tracker, as it can influence the tracker performance in the subsequent frames. Moreover, the CNN networks of the SmartConvFall implement pre-trained VGG-M weights and biases to overcome the issue of insufficient training data. Searching for the best training configurations is a crucial step to obtain the best-trained object appearance model to be used in the entire tracking process. Hence, several hyperparameter settings are optimized, including the optimizer, learning rate, size of mini-batch, and the number of training samples Equation , with tin FC models. A set of image patches, F is performed to ensure both m recent frames. The model update process involves the selection of the FC model among the n FC models with the highest scores, which will be retrained using the accumulated The tracker needs to be updated periodically to circumvent model drift issues as the object appearance perceived from the camera will change when the tracked object moves from one frame to another. n models for the FC layers. The implementation of n FC models is proposed to handle the changes in the object appearance model and the occlusion issue during the tracking process. The consideration of maintaining a set of n FC models allows the tracker to perform well both during and after occlusion. The appearance model has a higher possibility of being updated with noisy information during occlusion, which can cause model drifting in the event that only a single model is maintained. It is difficult for a single model tracker to find the best match if it has been continuously updated with the occluded appearance information. As such, maintaining a set of n FC models reduces the noisy updates and coherently improves the tracking performances.Basically, the handling of the FC layers of our tracker shares the same fundamentals similar to the TCNN and MDNET-N trackers. However, some remarkable improvements have been made. One of these improvements lies in the implementation of multiple models, denoted by The TCNN tracker implements a tree structure to manage the FC models by maintaining the parent node and deleting the oldest node once a new child node is produced. The tree structure also involves the periodically updated process by accumulating the In this subsection, the implementation of the instantaneous fall frame detection using the LSTM architecture is described. In recent studies, most of the existing fall detection systems are developed to classify the presence of fall events from typical events that occur in a video sequence. Contrarily, our goal is to detect the exact instantaneous fall frame. This specifically refers to the beginning of the ‘critical phase’ in which the fall event occurs, as illustrated in L representing the total number of layers with l represent the current layer; the LSTM is used to relate each The proposed LSTM model is designed as a regression model which combines several LSTM layers on top of each other, as illustrated in Equation . From heV denoting the total number of frames. Four different training configurations are used to train the stacked LSTM model, as summarized in Equation , with V i being the current frame, V being the total number of frames, and T being the timestep. Then, the In this subsection, the decision-making module task is to locate the exact instantaneous fall frame using the stacked LSTM model that has been trained in the previous module. Letting Equation , with ∆YV length, as defined in Equation  Challenge  protocolEquation , with S This section firstly describes the individual results for each training configuration of the object tracking module for the optimal setup of the SmartConvFall tracker. In addition, the proposed SmartConvFall will be benchmarked with state-of-the-art deep learning-based trackers, namely TCNN and MDNET-N, that share similar tracking fundamentals. This section also discusses the final results of the exact instantaneous fall frame detection performance.The tracker training phase in the first frame is crucial to produce a good model-free tracker, whereby a slight error can affect the model performance of the entire tracking process. Therefore, this section discusses the results of the optimal training configurations for our proposed SmartConvFall tracker. The first test examines the impact of the different optimizers, namely Adam, AdaGrad, SGD, AdaDelta, and RMSProp, with a fixed learning rate, mini batch size, and the number of training samples set to 0.001, 128, and 400, respectively. The good performance results of the Adam optimizer explain its capability to update the network parameters while reducing the loss function to zero. Moreover, the Adam optimizer employs an adaptive learning rate protocol for each involved parameter during the model updating process. In fact, the algorithm behind the Adam optimizer combines the uniqueness of the RMSProp and AdaGrad to produce a better optimization technique that can rapidly converge to the optimal settings. Similarly, the RMSProp optimizer also utilizes an adaptive learning rate protocol, yet the learning rate decay is based on the average gradient, which is slightly different from the Adam optimizer that uses previous average gradient information. The adaptive learning rate is also implemented in the algorithm of the AdaGrad optimizer; however, the weight update process causes the learning rate value to continually decrease, which affects the model performance. Meanwhile, the AdaDelta optimizer is an improved version of the AdaGrad, still using a rapid decayed learning rate, which hinders the model from learning the features efficiently. On the other hand, the SGD optimizer requires a longer convergence time, which explains its low performance as compared to the Adam optimizer. Therefore, the Adam optimizer is chosen to be the best optimizer for the SmartConvFall tracker based on the top results of These results explain that an optimal learning rate value plays an indispensable role in producing the best tracker because it controls the step size used in updating the model weights. Moreover, the obtained results also demonstrate that finding the best learning rate is difficult to achieve due to the learning rate decay process that also depends on the optimization technique. Nevertheless, it can be observed that using a high learning rate such as 0.1 produces low-performance results since the tracker is more likely to learn more on the background information. Contrarily, a small learning rate indicates that a small step size is used to update the model weights that cause the tracker to learn more on the tracked object information. Therefore, the learning rate of 0.0001 is selected as the best learning rate to be employed in the tracker model training.This test is performed to scrutinize the impact of different mini-batch sizes on the tracker model training. This experiment corroborates the findings for the optimal selection of mini-batch size, which can eventually affect the tracker model performance. Mini-batch size is introduced during the training process to control the size or the number of training samples for each backpropagation update, whereby the deep learning model can be optimally trained by using a subset of the training data. If the full dataset is used for each parameter update, the weight will not learn much as the model will be globally generalized, whilst, if a small batch size is used, the parameter update will experience extreme fluctuation in the case of noisy data. Furthermore, the selection of mini-batch size is also constrained by the available computer and graphics processing unit memories; as such, a mini-batch size of 256 is the upper limit for this experiment. Additionally, the results for this experiment are also greatly dependent on the distribution of positive and negative training samples for each batch, which will be randomly queued. Note that This subsection investigates the best combination of training sample densities to be used in training the tracker. A dense sampling will result in many repeated samples which will increase the computational burden, while a low sampling number will increase the likelihood of missed detection due to the uneven bounding boxes generation. Each test is conducted using similar settings with an Adam optimizer-based update, a fixed learning rate of 0.0001, and a mini-batch size of 128 for a fair comparison. The training process for a deep learning-based technique requires a large number of training samples due to the usage of complex network architecture as compared to the standard machine learning techniques. However, the main constraint of deploying a deep learning model for tracking applications is limited variations in the training data, whereby only first-frame information is used to train a model-free tracker. Therefore, the transfer learning method is adopted to overcome the limited number of training samples in this work. Through a transfer learning method, pre-trained weights and biases of the VGG-M model are used during the initialization phase. The VGG-M model has been trained using the ImageNet database  which coIn this subsection, the selection of the best region of interest to be tracked by the SmartConvFall tracker is analyzed for optimal appearance representation. The previously determined optimal hyperparameters are the Adam optimizer backpropagation method, a learning rate of 0.0001, a mini-batch size of 128, and 400 training samples being employed to select between head- or body-based regions of interest. The full performance results for all tests are shown in This subsection discusses the simulation results for the exact fall frame (L requires a longer training duration due to the increased model complexity in learning the provided temporal information.Apart from comparing the performance of a single layer of LSTM and RNN, this subsection experiments on various layer configurations of a stacked LSTM network in finding the Therefore, it can be concluded that the F4 configuration, which utilized the information of This section discusses the SmartConvFall tracker performances compared to the state-of-the-art CNN trackers, namely TCNN and MDNET-N trackers. Both TCNN and MDNET-N incorporated a fully CNN-based network as the core tracking mechanism. This mechanism relates the same object between consecutive images. These trackers essentially share similar tracking fundamentals, particularly in regard to the design of convolutional layers. However, they differ in the way of handling and updating the FC layers to differentiate the tracked objects from the background information. For a fair comparison, the optimal settings for the TCNN and MDNET-N trackers have been chosen and selected based on the suggested optimal setup in the original papers. We have also confirmed that both of the models have been trained to convergence. These trackers are initially evaluated using a set of videos from the FDD dataset; the set contains minimal visual noise attributes. Each tracker is subsequently tested by considering two challenging noise attributes, which are occlusion and a cluttered background to mimic real-life usage scenarios. Meanwhile, This paper proposes SmartConvFall for fall detection based on the instantaneous fall frame using two subsequent deep learning models: CNN and LSTM. Our work aims to identify the exact fall frame instantaneously through a regression network rather than to classify a video clip whether it contains a fall event or not. Hence, the performance metric used in this work is the mean error that quantifies the mean differences between the detected frame and its ground truth, instead of the standard performance measure of the classification task, such as recall and precision. Moreover, we have also implemented tracking outputs, which are the movement trajectories as the inputs to the regression network. Therefore, several state-of-the-art CNN-based trackers are used as the performance benchmark. The works in ,59,78 haThe nature of fall events that infrequently happen in real-life scenarios has contributed to another challenge for the vision-based fall detection system. Real-life fall events are scarce and difficult to acquire. However, most of the previous works make an ideal assumption on the training samples. Most of these works have used self-collected fall events videos under a controlled setting, which might pose a different challenge than the actual fall simulations. This will create a situation whereby the fall event can be easily triggered, as most of the posed action is not performed accurately. For example, Han et al.  have incOcclusion and background clutter issues are also critical in vision-based fall detection systems. For instance, a home-like environment often contains many surrounding objects, such as a wardrobe, sofas, and tables. These objects may cause occlusion issues when a person walks behind one of these items. In addition, the object’s appearance may also look too similar to the person of interest, especially the color. These issues can deteriorate the performance of the fall event detection system. Therefore, head tracking/segmentation has been adopted in vision-based fall detection systems. Our work has used the head information as the region of interest to the tracking network so that the challenges by occlusion and background clutter can be minimized. Similarly, Yao et al.  and AdhiAt the same time, we have taken a step further in minimizing these crucial issues. Our study aims to determine the fall frame immediately for each input sequence, which is in contrast to the recent fall detection approaches that only decide the occurrence of a fall event after a period of time. The fall frame detection for our SmartConvFall is achieved through the integration of a stacked LSTM model. Moreover, Mobsite et al.  have alsThis paper presented extensive simulation tests of various network configurations for the proposed SmartConvFall tracker in detecting the exact instantaneous fall frame. The SmartConvFall tracker relies on deep learning representation. This entails a fully CNN-based tracker that is employed to track the object of interest in a video sequence. Moreover, the transfer learning approach was also adopted to improve training accuracy due to limited training data in a model-free tracker. Hence, optimal training configurations are crucial to ensure optimized training settings for the network parameter update. Moreover, we integrated a stacked LSTM model with the output from the tracker to identify the fall incidents. The stacked LSTM managed to effectively model the temporal information of the object’s trajectory contained in human movements. The exact instantaneous fall frame is determined using an assumption that a large movement difference with respect to the ground level along the vertical axis can be observed if a fall incident has occurred. The simulation results have proven that the proposed SmartConvFall tracker outperforms the state-of-the-art CNN-based tracker, which is also suitable to be implemented in a real-time application with less than a 1-second response time of the input video is streamed in a 30 fps format. This significant result emphasizes that our SmartConvFall has produced instantaneous response times. This could help to mitigate the slow response rate issues of the current wearable-based fall detection systems and in opposition with the current vision-based models that only focus on monitoring the presence of falls within the video sequences. Furthermore, the recent fall detection systems only manage to detect the presence of a fall after the patient has fallen and remained on the floor for a prolonged period of time. Henceforth, the short response time produced by our SmartConvFall could help to avoid any crucial fall consequences, including death and internal bleeding. The most important limitation is no existing fall detection system has been developed to specifically detect the instantaneous fall frame through the LSTM architecture. Therefore, our current work is unable to compare the performance evaluations with other related works. We have only managed to make a comparison of instantaneous fall frame detection performances between the LSTM and RNN models. The current work is also limited by the lack of publicly available fall detection datasets, particularly those that utilize the RGB camera to capture the movement of the tracked object in video sequences. Most of the fall detection datasets only provide wearable-based readings, such as accelerometer and gyroscope readings. In future works, an attention mechanism and multi-scale scheme can be integrated into the base SmartConvFall network to produce more robust exact fall frame detection.


PWM (pulse-width modulation) voltage source inverters are used in a wide range of AC power systems where the output voltage must be controlled to follow a sinusoidal reference waveform. In order to achieve precision and fast-tracking control, restrictive sliding mode control (RSMC) provides a fast system state convergence time. However, the RSMC still suffers from the chattering problem, which leads to high harmonic distortion and slow response of the inverter output state. Furthermore, the load of the inverter may be severe load changing and the control parameters become difficult to adjust, worsening the adaptability to achieve the desired control of the inverter output. In this paper, a robust optimal control design comprised of an enhanced restrictive sliding mode control (ERSMC) and density particle swarm optimization (DPSO) algorithm is proposed, and then applied to PWM voltage source inverters. The ERSMC not only has finite time convergence but also provides chatter elimination. The DPSO is highly adaptable for acquiring the control parameters of the ERSMC and finding the best solution in the global domain. The proposed controller is realized for the actual PWM voltage source inverter controlled by a TI DSP-based development platform, so that the inverter output voltage has fast dynamic response and satisfactory steady-state behavior despite high load changing and non-linear disturbances. With the increasing demand for high quality power supplies, PWM voltage source inverters have become an important unit of high-performance power conversion systems such as solar energy systems, wind energy systems and fuel cell systems ,2,3,4. HFrom the (1), the dynamic equation yieldsAssuming that the switching frequency is high enough to ignore the dynamics of the inverter, i.e., that the inverter can be modeled as a constant gain, The block diagram of a PWM voltage source inverter with the proposed controller is shown in Defining This section begins with a review on the problem of nonlinear systems based on the conventional RSMC, and then proceeds to design the proposed controller. Take into account a second-order nonlinear equation given below.The sliding surface for the conventional RSMC can be composed asTo address the issue of not real numbers in the (5) and (6), it is necessary to consider conventional fast RSMC below:The ERSMC sliding surface in response to the error state Equation (3) to secure convergence quickly with no singularity occurring for a restricted time could be expressed asFollowing the procedure in (9) and (10), a control law Proof: The definition of a Lyapunov candidate gives the following:Based on the dynamical system trajectory along from the control law (11) with the use of the Lyapunov candidate, time derivative of the When essed as ,26,27.(From the (16), the probability selection based on particle density can be obtained asThe parameters of the inverter used for the proposed method are listed in This paper presents a DPSO-based ERSMC applied to voltage source inverters capable of producing fast dynamic performance and good steady-state response. The importance of the ERSMC is the restricted system state converging time. The parameters of the ERSMC should be determined to gain the best performance. Traditionally, these parameters are selected via repeated experiments, which are tedious, difficult to realize and time-consuming. The DPSO is employed to optimize the ERSMC parameters to yield better transience and steady-state behaviors. The Lyapunov’s theorem was used to prove the stability of the proposed method. The restricted time accessibility of the sliding surface, asymptotic stability of the feedback system and fast convergence of the state error were demonstrated. The simulations and experiments with DSP prototype voltage source inverter under transient loading and steady-state loading are shown to verify the applicability of the proposed controller. Noticeably, it is advisable to consider the development of three-phase multilevel inverters for increasing output power ,32,33,34


Radical antegrade modular pancreatosplenectomy (RAMPS) is an isolation procedure in pancreatosplenectomy for pancreatic body/tail cancer. Connective tissues around the bifurcation of the celiac axis are dissected, followed by median-to-left retroperitoneal dissection. This procedure has the potential to isolate blood and lymphatic flow to the area of the pancreatic body/tail and the spleen to be excised. This is achieved by division of the inflow artery, transection of the pancreas, and then division of the outflow vein in the early phases of surgery. In cases of pancreatic ductal adenocarcinoma (PDAC), the procedure has been shown to decrease intraoperative blood loss and increase R0 resection rate by complete clearance of the lymph nodes. This trial investigates whether the isolation procedure can prolong the survival of patients with pancreatic ductal adenocarcinoma who undergo distal pancreatosplenectomy (DPS) compared with those that undergo the conventional approach.Patients with PDAC scheduled to undergo DPS are randomized before surgery to undergo either a conventional procedure (arm A) or to undergo the isolation procedure (arm B). In arm A, the pancreatic body, tail, and spleen are mobilized, followed by removal of the regional lymph nodes. The splenic vein is transected at the end of the procedure. The timing of division of the splenic artery (SA) is not restricted. In arm B, regional lymph nodes are dissected, then we transect the root of the SA, the pancreas, then the splenic vein. At the end of the procedure, the pancreatic body/tail and spleen are mobilized and removed. In total, 100 patients from multiple Japanese high-volume centers will be randomized. The primary endpoint is 2-year recurrence-free survival by intention-to-treat analysis. Secondary endpoints include intraoperative blood loss, R0 resection rate, and overall survival.If this trial shows that the isolation procedures can improve survival with a similar R0 rate and with a similar number of lymph node dissections to the conventional procedure, the isolation procedure is expected to become a standard procedure during DPS for PDAC. Conversely, if there were no significant differences in endpoints between the groups, it would demonstrate justification of either procedure from surgical and oncological points of view.UMIN000041381. Registered on 10 August 2020. ClinicalTrials.gov NCT04600063. Registered on 22 October 2020.UMIN Clinical Trials Registry The online version contains supplementary material available at 10.1186/s13063-021-05523-y. Several investigators have advocated the possibility that grasping tumors during pancreatectomy may increase the risk of squeezing and thus shedding cancer cells into the portal vein, retroperitoneum, and/or peritoneal cavity , 2. To oMany gastroenterological surgeons have tried to demonstrate oncological benefits of such non-touch techniques, similar in concept to the isolation technique for resection of several gastrointestinal cancers. The impact of the isolation technique has not yet been demonstrated by scientifically acceptable methods , 4. ConsRadical antegrade modular pancreatosplenectomy (RAMPS) was reported by Strasberg et al. in 2003 as a new antegrade procedure which provides improved visibility and allows removal of N1 nodes. It permits adjustment of the depth of the posterior extent of resection coupled with early rather than late control of the vasculature. Descriptions of the RAMPS procedure indicate the potential of isolation of blood and lymphatic flow to the area of the pancreatic body/tail and spleen to be excised , 6. ThisThe RAMPS method has since been reported to have oncological usefulness as a favorable method for each lymph node dissection and R0 resection in multiple institutions –12, but To confirm the results of the cohort study, we will conduct a multicenter, randomized, placebo-controlled phase II trial of the isolation procedure . We will evaluate whether it affects the recurrence-free survival (RFS) rate compared with conventional procedures after DPS. This trial is registered at the UMIN Clinical Trials Registry (UMIN000041381) and at ClinicalTrials.gov (NCT04600063).The ISOP-DP trial is a Japanese multicenter, randomized, controlled trial. Patients with PDAC are randomized to arm A  or arm B (isolation procedure) during DPS. The ISOP-DP trial is conducted in 11 Japanese high-volume centers  that have been board-certified as training institutions by the Japanese Society of Hepato-Biliary-Pancreatic Surgery. To ensure the high quality of the study, interventions are performed by instructors and expert surgeons certified by the society. This study aims to evaluate the oncological and surgical benefits of the isolation procedure during DPS for patients with PDAC in comparison with the conventional procedure. This study is therefore designed to evaluate the superiority of the isolation procedure (arm B) compared with the conventional procedure (arm A) during DPS in terms of a 2-year recurrence-free survival (RFS) rate. All patients are required to undergo postoperative examination every 3 months for at least 2 years after surgery. Signs of suspected disease recurrence will be closely monitored. The schedule of this trial is shown in Fig. The primary endpoint is the 2-year RFS rate. Secondary endpoints include operative time, intraoperative blood loss volume, and transfusion; incidence of postoperative complications within 90 days after surgery , and intra-abdominal hemorrhage); all-morbidity rate within 90 days after surgery; and mortality rate within 90 days after surgery. We also include the rates of R0 and R1, number of harvested lymph nodes, number of metastatic lymph nodes, lymph node ratio, overall survival (OS) time, RFS time, and local recurrence rate. R0 status is defined as the absence of tumor cell infiltration within 1 mm of the resection margin, and R1 status is defined as the presence of tumor cell infiltration within 1 mm of the resection margin . PostopeClinical trials of isolation and conventional procedures during distal pancreatectomy for pancreatic body/tail cancer have not been widely reported. A two parallel multicenter randomized selection phase II trial compared the conventional procedure with isolation procedure as a basis for a future phase III trial . Its priThe primary population for efficacy analysis will be the intention-to-treat population, defined as all randomized patients. The primary endpoint is the 2-year RFS rate. The primary analysis will be based on the full analysis set (FAS), which consists of all randomized patients except those found to be ineligible after enrollment. The Kaplan-Meier method will be used to estimate the progression-free survival curve and 2-year progression-free survival rate. The regimen with a higher 2-year progression-free survival rate will be considered as the more promising procedure of the two. The Brookmeyer-Crowley method will be used to calculate the 95% confidence interval for the 2-year progression-free survival rate. Although the design of choice cannot confirm the results based on a hypothetical test, it would compare the progression-free survival curves using the log-rank test as a reference. A Cox proportional hazard model will be applied to calculate HRs and 95% confidence intervals adjusted for stratification factors . For evaluation of secondary endpoints, categorical outcomes will be summarized using frequency and percentage for each arm and will be compared using Fisher’s exact test. Mann-Whitney-Wilcoxon test will be used to compare continuous outcomes and will be summarized using the median and interquartile range.Classification of Pancreatic Carcinoma of Japan Pancreas Society (Fourth English Edition) [Table Edition)  and the Edition) . PatientAfter confirmation of eligibility including written informed consent, patients will be randomized in a 1:1 allocation ratio to either arm A  or arm B (isolation approach) with a random block size. Central randomization and registration will be applied, using UMIN Internet Data and Information system for Clinical and Epidemiological research, cloud version (INDICE cloud). After assessment for eligibility at registration, patients will be centrally randomized to either arm A or arm B. To minimize background bias between the two groups, this study is stratified by participating institution according to use of minimally invasive approach (yes or no), and preoperative adjuvant therapy (yes or no). The indication and regimen for preoperative adjuvant therapies depend on the treatment strategies of the participating institutions. We use Pocock and Simon’s minimization method for random assignment and the Mersenne Twister for random number generation  and the pancreatic transection are performed first, followed by division of the splenic vein (mandatory procedure). At that time, the branch from the splenic artery , the branch to the splenic vein , and the short gastric artery and vein are also disconnected as soon as possible (recommended procedure). An operation to lift up the pancreatic neck from the dorsal portal vein or superior mesenteric artery to expose the splenic vein  is allowed. After that, lymph node dissection, such as of hepatoduodenal mesentery (lymph node No.12) , and aroIn the conventional procedure group, first, the pancreatic body and tail and spleen are mobilized by detachment of the retroperitoneum (mandatory procedure). The regional lymph nodes of the pancreatic body/tail, such as the hepatoduodenal mesentery (lymph node No. 12)  and the Classification of Pancreatic Carcinoma of Japan Pancreas Society (Fourth English Edition) [In both groups, the spleen is resected with the pancreas. The direction of the detachment of the pancreatic body/tail from the retroperitoneum is recommended to proceed from the right side to the left side. Lymph node dissection shall be regional lymph node dissection  in the Edition)   is permissible if there is bleeding from portal veins.The method of pancreatic transection or the method of closing the pancreatic stump is left open to the decision of the operators.Splenic vein resection together with the pancreatic parenchyma after isolation of the parenchyma during DPS is acceptable if it can be safely performed.Combined resection of the surrounding organs other than the spleen  is allowable. However, if the surgical procedure is changed to portal vein resection, celiac artery resection, exploratory laparotomy, etc. during the operation, it will be considered as a deviation, and the protocol treatment will be stopped according to the criteria for discontinuing protocol treatment. Patients with protocol deviation must be followed in an intention-to-treat analysis.If essential procedures cannot be performed in either group, it is considered to be a deviation and the protocol treatment is stopped according to the criteria for discontinuing protocol treatment. Whether or not the recommended procedure is performed is not treated as a target of deviation judgment.To guarantee the quality of both procedures, board-certified surgeons from the Japanese Society of Hepato-Biliary-Pancreatic Surgery perform or supervise all surgery. Both procedures are performed in daily practice depending on the case. Before the start of the ISOP-DP trial, all participating surgeons in this trial held consensus meetings to determine the details of the operative techniques for both groups by observing and discussing several operative videos to ensure standardization of the interventions in all institutions at which more than 50 pancreatectomies for pancreatic cancer were performed per year, in accordance with the Japanese Pancreatic Cancer Treatment Guidelines. On the basis of the meetings, we determined that a photographic record after pancreatic transection is necessary for both groups for validation of intervention quality, because the operative techniques of this approach have been certified by the Japanese Society of Hepato-Biliary-Pancreatic Surgery. Central judgment will be conducted for both groups, and the intraoperative images are evaluated to determine whether the procedure is performed according to the protocol by three reviewers ; cases with discrepancies are re-evaluated simultaneously by the three reviewers until a consensus is reached. If there is disagreement among the three reviewers, the majority classification is chosen to settle whether the procedure has been performed according to the protocol. If it is determined that the procedure is not performed according to the protocol, it will be treated as a case that deviates from the protocol.To achieve adequate participant enrollment to reach the target sample size within the study period, 11 Japanese high-volume centers will participate in the ISOP-DP trial.After randomization, the patients will be followed every 3 months, or more often if the patient’s situation requires it, for at least 2 years. Patients in this study will undergo plain/enhanced computed tomography every 3 months to assess postoperative recurrence and metastases. Patients with iodine allergies will undergo plain computed tomography plus enhanced magnetic resonance imaging. The accuracy of the latter study method is not inferior to that of the former , 22. RFSDuring the study, an independent data monitoring committee  will monitor the safety of the trial subjects by qualitative analyses of feasibility, accrual rate, and adverse events, as well as dropouts every 6 months. Data are collected via a case report form using paper and stored and managed securely by the data monitoring committee. To improve the quality of data, after written consent is signed, all baseline assessments will be conducted before randomization. The handling of all cases is managed by subject identification code or anonymized registration number. The correspondence table of the anonymizing codes and names, as well as the consent form containing the name, is kept in separate restricted-access lockable document storage at each participating institution. To promote data quality, missing data will be pursued until received or confirmed as unavailable, or until the trial reaches analysis. No interim analyses are planned in the ISOP-DP trial. The principal investigator has the right to terminate the trial at any time in consultation with the biostatistician. The trial would be terminated if the incidence or severity of adverse events in the trial indicated a potential health hazard caused by the study treatment. The trial is terminated if patient enrollment appears unsatisfactory with respect to quality or quantity, if data recording is severely inaccurate or incomplete, or if external evidence renders it necessary. The procedure for deciding to discontinue the entire study is as follows: the principal investigator must request a review by the Wakayama Medical University Ethics Review Board and make a report. If the principal investigator decides to discontinue the entire research, the principal investigators of the other institutions will be immediately notified of the reason and subsequent actions. The principal investigator of the other institutions contacted informs the subjects of the discontinuation of the entire research and the reason and takes appropriate action immediately. All adverse events observed by the investigators will be recorded up to 90 days after surgery and reported to the principal investigator and clinical trial coordination center. The assignment of the severity or grading should be made by the investigator responsible for the care of the participant. Serious adverse events are defined as those that are life-threatening or result in death. Serious adverse events will be collected and recorded according to good clinical practice throughout the study period. The patients enrolled in this study will receive standard-of-care supportive measures and all other medically necessary interventions as needed.This study is performed in accordance with the Declaration of Helsinki. The protocol has been approved by the Wakayama Medical University Hospital Ethics Committee . The trial protocol has also been registered in the protocol registration system at ClinicalTrials.gov (NCT) and the University Hospital Medical Information Network Clinical Trials Registry (UMIN). All patients will be scheduled only after comprehensive information concerning the nature, scope, and possible consequences of the clinical trial have been provided to them in an understandable way by the investigator. Written informed consent to inclusion in the study will be obtained from each patient before the operation. The procedure, benefits, risks, and data management of this study will be clarified in detail for the patients during the preoperative conversation.The results of the ISOP-DP trial will be submitted to a peer-reviewed journal and will be presented at national and international conferences, regardless of the trial outcomes. Authorship will be agreed in accordance with the ISOP-DP trial publication policy and in line with international guidelines.The oncological impact of the isolation by the so-called non-touch technique remains controversial in digestive surgery –4, 23. TIn an international multicenter study, Korrel et al. reported that Gerota’s fascia resection, R0 resection, and reduction in LNR were factors associated with improved overall survival in DP-treated PDAC , 25, butIf the ISOP-DP trial shows that the isolation procedure can improve recurrence-free survival with a similar R0 rate and a similar number of lymph node dissections to the conventional procedure, the isolation procedure is expected to become a worldwide standard procedure during DPS for PDAC under the concept of isolation technique. Otherwise, if there are no significant differences in endpoints between the groups, it will demonstrate that both procedures may be justified from surgical and oncological points of view.The ISOP-DP trial was opened in October 2020. At the time of submission of this paper (January 2021), the protocol is version 1.0. The completion date is estimated to be September 2025.Additional file 1. Institution list