Abstract: A system described herein may provide a technique for location-based handling of discovery requests in a service-based network in which different instances of network functions (“NFs”) may be deployed in geographically diverse locations. For example, a Network Repository Function (“NRF”) may maintain location information for the various NF instances and may respond to discovery requests by identifying particular NF instances based on locations associated with the discovery requests. For example, such discovery requests may include a “preferred-locality” parameter or some other indication of location associated with the discovery request, based on which the NRF may identify one or more NF instances to provide in response to the discovery request.

Abstract: A system described herein may provide a technique for location-based handling of discovery requests in a service-based network in which different instances of network functions (“NFs”) may be deployed in geographically diverse locations. For example, a Network Repository Function (“NRF”) may maintain location information for the various NF instances and may respond to discovery requests by identifying particular NF instances based on locations associated with the discovery requests. For example, such discovery requests may include a “preferred-locality” parameter or some other indication of location associated with the discovery request, based on which the NRF may identify one or more NF instances to provide in response to the discovery request.

Abstract: A system described herein may provide a technique for location-based handling of discovery requests in a service-based network in which different instances of network functions (“NFs”) may be deployed in geographically diverse locations. For example, a Network Repository Function (“NRF”) may maintain location information for the various NF instances and may respond to discovery requests by identifying particular NF instances based on locations associated with the discovery requests. For example, such discovery requests may include a “preferred-locality” parameter or some other indication of location associated with the discovery request, based on which the NRF may identify one or more NF instances to provide in response to the discovery request.

Abstract: A system described herein may provide a technique for location-based handling of discovery requests in a service-based network in which different instances of network functions (“NFs”) may be deployed in geographically diverse locations. For example, a Network Repository Function (“NRF”) may maintain location information for the various NF instances and may respond to discovery requests by identifying particular NF instances based on locations associated with the discovery requests. For example, such discovery requests may include a “preferred-locality” parameter or some other indication of location associated with the discovery request, based on which the NRF may identify one or more NF instances to provide in response to the discovery request.

Abstract: A device may determine that a user device is to receive an update. The device may determine that the user device is not registered to a network associated with receiving the update. The device may provide a registration notification request based on determining that the user device is not registered to the network. The registration notification request may include information identifying the user device. The device may receive a response to the registration notification request. The response may indicate that the user device is registered to the network. The device may provide, based on receiving the response, an update message associated with the update. The update message may be destined for the user device and may include information indicating that the user device is to receive the update. The device may provide the update to the user device after providing the update message.

Abstract: A device may receive a first session initiation protocol (SIP) message from another device, and may determine a first timestamp associated with the first SIP message. The first timestamp may represent a receipt time of the first SIP message by the device. The device may determine a second timestamp associated with a second SIP message. The second timestamp may represent a transmission time of the second SIP message by the device, and may be a response to the first SIP message. The device may determine a device latency value representing a difference between the second timestamp and the first timestamp. The device may provide the second SIP message to the other device at the transmission time. The second SIP message may include the device latency value.

Abstract: Systems and methods for a notification triggered device management session are described. A request for a device management session for a mobile station is received at a device management server. In response to determining that the mobile station is not connected to a cellular network, a home subscriber server is signaled to update a user equipment profile for the mobile station to indicate that the mobile station has a pending device management session. Upon connection of the mobile station to a first network, the mobile station is signaled to connect to the device management server for the device management session using a call session control function. The mobile station is connected with the device management server using the first network. The device management session is run using the first network connection between the mobile station and the device management server.

Abstract: A device may receive a first session initiation protocol (SIP) message from another device, and may determine a first timestamp associated with the first SIP message. The first timestamp may represent a receipt time of the first SIP message by the device. The device may determine a second timestamp associated with a second SIP message. The second timestamp may represent a transmission time of the second SIP message by the device, and may be a response to the first SIP message. The device may determine a device latency value representing a difference between the second timestamp and the first timestamp. The device may provide the second SIP message to the other device at the transmission time. The second SIP message may include the device latency value.

Abstract: Systems and methods for a notification triggered device management session are described. A request for a device management session for a mobile station is received at a device management server. In response to determining that the mobile station is not connected to a cellular network, a home subscriber server is signaled to update a user equipment profile for the mobile station to indicate that the mobile station has a pending device management session. Upon connection of the mobile station to a first network, the mobile station is signaled to connect to the device management server for the device management session using a call session control function. The mobile station is connected with the device management server using the first network. The device management session is run using the first network connection between the mobile station and the device management server.

Abstract: A device may determine that a user device is to receive an update. The device may determine that the user device is not registered to a network associated with receiving the update. The device may provide a registration notification request based on determining that the user device is not registered to the network. The registration notification request may include information identifying the user device. The device may receive a response to the registration notification request. The response may indicate that the user device is registered to the network. The device may provide, based on receiving the response, an update message associated with the update. The update message may be destined for the user device and may include information indicating that the user device is to receive the update. The device may provide the update to the user device after providing the update message.

Abstract: A drilling motor includes an upper end connection adapted to connect to a drill string, and a lower end connection adapted to connect to a drill bit, a thrust bearing assembly having a plurality of stages assembled in a stack, each stage including at least one rotating inner bearing subassembly configured to contact at least one corresponding stationary outer bearing subassembly, wherein axial loads among the plurality of stages are substantially equal under normal operating conditions.