Abstract: A device described herein may maintain a set of models that associate a plurality of sets of input cryptography configurations with respective sets of output cryptography configurations; receive information indicating a first set of cryptography configurations associated with a particular system; compare the first set of cryptography configurations with one or more sets of input cryptography configurations of the set of models; identify, based on the comparing, a particular set of input cryptography configurations included in the set of models; identify a particular set of output cryptography configurations that are indicated in the set of models as being associated with the identified particular set of input cryptography configurations; and provide the particular set of output cryptography configurations to the particular system, wherein the particular system modifies or replaces the first set of cryptography configurations with the particular set of output cryptography configurations.

Abstract: A first key management entity (KME) in a mobile edge network engages in quantum key distribution (QKD) with a second KME in a far network to generate a secret cryptographic key that is shared between the first KME and the second KME. The first KME determines a key identifier (ID) for associating with the cryptographic key, and sends the key ID to the second KME for association with the secret cryptographic key at the second KME. The first KME receives a session request from a first session endpoint for a session across at least one of the mobile edge network or the far network. The first KME sends the key ID and the cryptographic key to the first session endpoint for establishing an encrypted session across the at least one of the mobile edge network or the far network.

Abstract: A device may include a processor configured to obtain a quantum key generated using quantum random numbers received from a quantum random number generator. The processor may be further configured to obtain a digital signature for a uniform resource locator (URL) associated with the obtained quantum key, wherein the digital signature is received from a security device configured to provide the quantum key to a user equipment (UE) device; receive a request from an application server to function as a proxy for a secure session with the UE device; authenticate the secure session with the UE device using the quantum key and the digital signature; and proxy the secure session between the UE device and the application server.

Abstract: A system can include a producer device to receive reference data from a reference station. The system can include a queue device to store a reference message, corresponding to the reference data, in a message queue. The system can include a mapping device to store mapping information indicating that the message queue is associated with the reference station. The system can include a consumer device to identify the message queue as being associated with a microservice to be provided to a client device based on a microservice request. The message queue can be identified based on the mapping information. The consumer device can obtain the reference message from the message queue, generate corrections data associated with the client device, and provide the corrections data.

Abstract: A first key management entity (KME) in a mobile edge network engages in quantum key distribution (QKD) with a second KME in a far network to generate a secret cryptographic key that is shared between the first KME and the second KME. The first KME determines a key identifier (ID) for associating with the cryptographic key, and sends the key ID to the second KME for association with the secret cryptographic key at the second KME. The first KME receives a session request from a first session endpoint for a session across at least one of the mobile edge network or the far network. The first KME sends the key ID and the cryptographic key to the first session endpoint for establishing an encrypted session across the at least one of the mobile edge network or the far network.

Abstract: A first device may receive, from a second device associated with an emergency motor vehicle (EMV), EMV-tracking information and a communication that the EMV is in emergency response mode and may determine, based on the EMV-tracking information, that the EMV is approaching an intersection. The first device may receive, from a third device associated with a user vehicle, user-tracking information. The first device may determine, based on the user-tracking information, that the user vehicle is approaching the intersection. The first device may determine, based on the EMV-tracking information and the user-tracking information, whether the EMV is predicted to collide with the user vehicle. The first device may provide, to the second device and based on the determination of whether the EMV is predicted to collide with the user vehicle, a first notification including information regarding safety of the EMV proceeding through the intersection.

Abstract: A device may include a processor configured to obtain a quantum key generated using quantum random numbers received from a quantum random number generator. The processor may be further configured to obtain a digital signature for a uniform resource locator (URL) associated with the obtained quantum key, wherein the digital signature is received from a security device configured to provide the quantum key to a user equipment (UE) device; receive a request from an application server to function as a proxy for a secure session with the UE device; authenticate the secure session with the UE device using the quantum key and the digital signature; and proxy the secure session between the UE device and the application server.

Abstract: A first device may receive, from a second device associated with an emergency motor vehicle (EMV), EMV-tracking information and a communication that the EMV is in emergency response mode and may determine, based on the EMV-tracking information, that the EMV is approaching an intersection. The first device may receive, from a third device associated with a user vehicle, user-tracking information. The first device may determine, based on the user-tracking information, that the user vehicle is approaching the intersection. The first device may determine, based on the EMV-tracking information and the user-tracking information, whether the EMV is predicted to collide with the user vehicle. The first device may provide, to the second device and based on the determination of whether the EMV is predicted to collide with the user vehicle, a first notification including information regarding safety of the EMV proceeding through the intersection.

Abstract: A first device may receive, from a second device associated with an emergency motor vehicle (EMV), EMV-tracking information and a communication that the EMV is in emergency response mode and may determine, based on the EMV-tracking information, that the EMV is approaching an intersection. The first device may receive, from a third device associated with a user vehicle, user-tracking information. The first device may determine, based on the user-tracking information, that the user vehicle is approaching the intersection. The first device may determine, based on the EMV-tracking information and the user-tracking information, whether the EMV is predicted to collide with the user vehicle. The first device may provide, to the second device and based on the determination of whether the EMV is predicted to collide with the user vehicle, a first notification including information regarding safety of the EMV proceeding through the intersection.

Abstract: A system can include a producer device to receive reference data from a reference station. The system can include a queue device to store a reference message, corresponding to the reference data, in a message queue. The system can include a mapping device to store mapping information indicating that the message queue is associated with the reference station. The system can include a consumer device to identify the message queue as being associated with a microservice to be provided to a client device based on a microservice request. The message queue can be identified based on the mapping information. The consumer device can obtain the reference message from the message queue, generate corrections data associated with the client device, and provide the corrections data.

Abstract: A first device may receive, from a second device associated with an emergency motor vehicle (EMV), EMV-tracking information and a communication that the EMV is in emergency response mode and may determine, based on the EMV-tracking information, that the EMV is approaching an intersection. The first device may receive, from a third device associated with a user vehicle, user-tracking information. The first device may determine, based on the user-tracking information, that the user vehicle is approaching the intersection. The first device may determine, based on the EMV-tracking information and the user-tracking information, whether the EMV is predicted to collide with the user vehicle. The first device may provide, to the second device and based on the determination of whether the EMV is predicted to collide with the user vehicle, a first notification including information regarding safety of the EMV proceeding through the intersection.

Abstract: A system can include a producer device to receive reference data from a reference station. The system can include a queue device to store a reference message, corresponding to the reference data, in a message queue. The system can include a mapping device to store mapping information indicating that the message queue is associated with the reference station. The system can include a consumer device to identify the message queue as being associated with a microservice to be provided to a client device based on a microservice request. The message queue can be identified based on the mapping information. The consumer device can obtain the reference message from the message queue, generate corrections data associated with the client device, and provide the corrections data.

Abstract: A first device may receive, from a second device associated with an emergency motor vehicle (EMV), EMV-tracking information and a communication that the EMV is in emergency response mode and may determine, based on the EMV-tracking information, that the EMV is approaching an intersection. The first device may receive, from a third device associated with a user vehicle, user-tracking information. The first device may determine, based on the user-tracking information, that the user vehicle is approaching the intersection. The first device may determine, based on the EMV-tracking information and the user-tracking information, whether the EMV is predicted to collide with the user vehicle. The first device may provide, to the second device and based on the determination of whether the EMV is predicted to collide with the user vehicle, a first notification including information regarding safety of the EMV proceeding through the intersection.

Abstract: A system can include a producer device to receive reference data from a reference station. The system can include a queue device to store a reference message, corresponding to the reference data, in a message queue. The system can include a mapping device to store mapping information indicating that the message queue is associated with the reference station. The system can include a consumer device to identify the message queue as being associated with a microservice to be provided to a client device based on a microservice request. The message queue can be identified based on the mapping information. The consumer device can obtain the reference message from the message queue, generate corrections data associated with the client device, and provide the corrections data.

Abstract: A device may receive information associated with a reliable multicast service, that permits retransmission of multicast datagrams to be provided. The device may receive information associated with a plurality of network devices associated with providing the reliable multicast service. The device may configure the plurality of network devices to provide the reliable multicast service and may monitor the plurality of network devices. The device may detect an event associated with the reliable multicast service and may provide an instruction, to one or more network devices of the plurality of network devices, to modify the reliable multicast service based on detecting the event.

Abstract: A network device receives a first application programming interface (API) call from an application. The first API call requests a micro-service of a blockchain-based technology. The blockchain-based technology includes use of a shared ledger among participating nodes in a distributed consensus network. The micro-service provides a function for the application. The network device sends, in response to the first API call, a second API call to one of the participating nodes. The second API call initiates a framework module of a multiple of framework modules in the participating nodes. The network device receives, from the one of the participating nodes, a response to the second API call, the response indicating consensus of the participating nodes. The network device generates, based on the response to the second API call, a reply to the first API call.

Abstract: A device receives a user election of participation in a distributed cache service, and receives user selection of one or more devices, that are each associated with the user, to register with the distributed cache service as participant nodes. The device determines an amount of available storage offered to the cache service for each of the one or more participant nodes, and determines an available bandwidth of a respective network connection associated with each of the one or more participant nodes. The device admits selected devices of the one or more participant nodes into the distributed cache service based on the available storage and the available bandwidth, and interleaves storage of multiple chunks of content across a subset of the participant nodes admitted into the distributed cache service. The device enables client access to the multiple chunks of content interleaved across the subset of the participant nodes.

Abstract: A network device receives a first application programming interface (API) call from an application. The first API call requests a micro-service of a blockchain-based technology. The blockchain-based technology includes use of a shared ledger among participating nodes in a distributed consensus network. The micro-service provides a function for the application. The network device sends, in response to the first API call, a second API call to one of the participating nodes. The second API call initiates a framework module of a multiple of framework modules in the participating nodes. The network device receives, from the one of the participating nodes, a response to the second API call, the response indicating consensus of the participating nodes. The network device generates, based on the response to the second API call, a reply to the first API call.

Abstract: A device receives a user election of participation in a distributed cache service, and receives user selection of one or more devices, that are each associated with the user, to register with the distributed cache service as participant nodes. The device determines an amount of available storage offered to the cache service for each of the one or more participant nodes, and determines an available bandwidth of a respective network connection associated with each of the one or more participant nodes. The device admits selected devices of the one or more participant nodes into the distributed cache service based on the available storage and the available bandwidth, and interleaves storage of multiple chunks of content across a subset of the participant nodes admitted into the distributed cache service. The device enables client access to the multiple chunks of content interleaved across the subset of the participant nodes.

Abstract: A device may receive information associated with a reliable multicast service, that permits retransmission of multicast datagrams to be provided. The device may receive information associated with a plurality of network devices associated with providing the reliable multicast service. The device may configure the plurality of network devices to provide the reliable multicast service and may monitor the plurality of network devices. The device may detect an event associated with the reliable multicast service and may provide an instruction, to one or more network devices of the plurality of network devices, to modify the reliable multicast service based on detecting the event.