Automatic path selection for devices in roaming data networks

A user device may be provisioned with a list of paths for connecting to a network. A method may include determining that the user device has attached to a visited network and sending the visited network an indication of connectivity capabilities associated with the network. The method may include receiving an indication of one or more paths established from the visited network to the network based on capabilities of the visited network. The one or more paths may be included in the list of paths. The method may include transmitting data to or from the user device via a first path of the one or more paths.

BACKGROUND

As the deployment of Internet of Things (IoT) devices continues to increase both domestically and globally, communications networks increasingly need to interact with different networks that employ different technologies. When a user device travels from a home communications network to a roaming communications network, the home communications network may have to navigate roaming devices between the communications networks and ensure that the connectivity and features are properly configured in both communications networks using different technologies. This may result in issues for a service provider.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

IoT devices in general and Narrow band IoT (NB-IoT) and long-term evolution (LTE) Category M (Cat-M) devices, specifically, continue to become more popular with increased deployment in both the United States and in global markets. Service capability exposure function (SCEF)-based non-internet protocol (IP) data delivery (NIDD) is a preferred data delivery mechanism for IoT and other user devices operating in home networks or roaming in foreign networks. NIDD services provide efficient communication channels for exchanging data between small/mobile devices and application servers. NIDD protocols may exchange data over a control plane delivery path, and thus can avoid having to set up a full packet data network (PDN) bearer which may be used in conventional IP-based data exchanges. NIDD protocols may also provide header compression and operation optimization to allow effective transmission of transactional data with small frame sizes. Such protocols may be useful in IoT applications (e.g., sensors, machines to machines, etc.) where user equipment devices (UEs) may communicate small quantities of data (e.g., periodically triggered measurements from sensors) with application servers.

Not all communications networks employ the same types of technologies and some communications networks do not have the capabilities to employ particular types of technologies (e.g., NIDD). For example, some networks may implement a simple NB-IoT support via Data over Non-Access Stratum (NAS) protocol. Data over NAS (DoNAS) may, however, be an inefficient solution with a low technical bearer. When a user device roams to a network that employs a different type of technology than the device's home network, the user device may behave differently. It may be challenging to manage, track and interact with the user device due to the differences in technology.

Deployment of SCEF-based communication channels may prove challenging due to the complexity of the end-to-end service call flows involving almost all of the evolved packet system (EPS) core network entities. Due to the potential challenges, outbound roaming devices frequently fail to establish the SCEF roaming service. Instead, current roaming solutions may involve a static and lengthy roaming agreement between networks with different configurations on both networks. Therefore, traffic to a user device in different roaming networks may have to travel via different paths.

In addition, the configurations may be different for each different roaming network. An outbound roaming user device may need to be configured for either DoNAS roaming or SCEF-based roaming statically. The end result may be an increased complexity and a lower quality of service. In addition, the carrier's operational overhead may be increased and the customer satisfaction may be decreased.

Embodiments presented herein address the aforementioned issues by configuring a user device with a preferred path setup profile in order to attach to a preferred communication path in the roaming network based on technologies available in the roaming network. In addition, the home network may perform path detection when a user device is in a roaming network to identify the best path to the user device in the roaming network. Additionally, embodiments herein may help improve downlink data by selecting an alternate path to the user device from the preferred path setup profile if there is poor quality or a delivery failure in a path.

FIG. 1is a diagram illustrating an exemplary network environment100consistent with an embodiment. As shown inFIG. 1, environment100may include endpoint user equipment devices (UEs)110-A to110-N (referred to herein collectively as “UEs110” and individually as “UE110”), an access network120, a wide area network (WAN)140, and an application server (AS)150.

UEs110may include any device with long-range (e.g., cellular or mobile wireless network) wireless communication functionality. In some implementations, UEs110may communicate using machine-to-machine (M2M) communication, such as machine-type communication (MTC), a type of M2M communication standardized by the 3rdGeneration Partnership Project (3GPP), and/or another type of M2M communication. UEs110may be embodied as Internet of things (IoT) devices, which may include health monitoring devices, asset tracking devices (e.g., a system monitoring the geographic location of a fleet of vehicles, etc.), sensors (e.g., utility sensors, traffic monitors, etc.)

UE110may also include a handheld wireless communication device (e.g., a mobile phone, a smart phone, a tablet device, etc.); a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch computer device, etc.); a laptop computer, a tablet computer, or another type of portable computer; a desktop computer, or a digital media player (e.g., APPLE TV, GOOGLE CHROMECAST, AMAZON FIRE TV, etc.); a smart television; a portable gaming system; a global positioning system (GPS) device; a home appliance device; a home monitoring device; and/or any other type of computer device with wireless communication capabilities and a user interface. UE110may also include any type of customer premises equipment (CPE) such as a set top box, a wireless hotspot (e.g. an LTE or 5G wireless hotspot), a femto-cell, etc. UE110may include capabilities for voice communication, mobile broadband services (e.g., video streaming, real-time gaming, premium Internet access etc.), best effort data traffic, and/or other types of applications.

Access network120may provide access to WAN140for UEs110. Access network120may enable UEs110to connect to WAN140for IP services and/or non-IP data delivery (NIDD) services, mobile telephone service, Short Message Service (SMS), Multimedia Message Service (MMS), multimedia broadcast multicast service (MBMS), Internet access, cloud computing, and/or other types of data services.

Access network120may establish or may be incorporated into a packet data network connection between UE110and WAN140via one or more access point names (APNs). For example, access network120may establish a non-IP connection between UE110and WAN140. Furthermore, through an APN, access network120may enable UE110to communicate with AS150via WAN140.

In some implementations, access network120may include a Long Term Evolution (LTE) access network (e.g., an evolved packet core (EPC) network). In other implementations, access network120may include a Code Division Multiple Access (CDMA) access network. For example, the CDMA access network may include a CDMA enhanced High Rate Packet Data (eHRPD) network (which may provide access to an LTE access network).

Furthermore, access network120may include an LTE Advanced (LTE-A) access network and/or a Fifth Generation (5G) access network or other advanced network that includes functionality such as 5G new radio (NR) base stations; carrier aggregation; advanced or massive multiple-input and multiple-output (MIMO) configurations (e.g., an 8×8 antenna configuration, a 16×16 antenna configuration, a 256×256 antenna configuration, etc.); cooperative MIMO (CO-MIMO); relay stations; Heterogeneous Networks (HetNets) of overlapping small cells and macrocells; Self-Organizing Network (SON) functionality; MTC functionality, such as 1.4 MHz wide enhanced MTC (eMTC) channels (also referred to as category Cat-M1), Low Power Wide Area (LPWA) technology such as Narrow Band (NB) IoT (NB-IoT) technology, and/or other types of MTC technology; and/or other types of LTE-A and/or 5G functionality.

As described herein, access network120may include base stations130-A to130-N (referred to herein collectively as “base stations130” and individually as “base station130”). Each base station130may service a set of UEs110. For example, base station130-A may service UEs110-A and110-B, and base station130-N may service UE110-N. Base station130may include a 5G base station (e.g., a gNodeB) that includes one or more radio frequency (RF) transceivers (also referred to as “cells” and/or “base station sectors”) facing particular directions. For example, base station130may include three RF transceivers and each RF transceiver may service a 120° sector of a 360° field of view. Each RF transceiver may include an antenna array. The antenna array may include an array of controllable antenna elements configured to send and receive 5G NR wireless signals via one or more antenna beams. The antenna elements may be digitally controllable to electronically tilt, or adjust the orientation of, an antenna beam in a vertical direction and/or horizontal direction. In some implementations, the antenna elements may additionally be controllable via mechanical steering using one or more motors associated with each antenna element. The antenna array may serve k UEs110and may simultaneously generate up to k antenna beams. A particular antenna beam may service multiple UEs110. In some implementations, base station130may also include a 4G base station (e.g., an eNodeB).

WAN140may include any type of wide area network, a metropolitan area network (MAN), an optical network, a video network, a satellite network, a wireless network (e.g., a CDMA network, a general packet radio service (GPRS) network, and/or an LTE network), an ad hoc network, a telephone network (e.g., the Public Switched Telephone Network (PSTN) or a cellular network), an intranet, or a combination of networks. Some or all of WAN140may be managed by a provider of communication services that also manages access network120and/or UEs110. WAN140may allow the delivery of IP and/or non-IP services to/from UE110, and may interface with other external networks. WAN140may include one or more server devices and/or network devices, or other types of computation or communication devices. In some implementations, WAN140may include an IP Multimedia Sub-system (IMS) network (not shown inFIG. 1). An IMS network may include a network for delivering IP multimedia services and may provide media flows between UE110and external IP networks or external circuit-switched networks (not shown inFIG. 1).

Application server (AS)150may include one or more devices, such as computer devices, databases, and/or server devices, that facilitate non-IP data delivery services. Such services may include supporting IoT applications such as alarms, sensors, medical devices, metering devices, smart home devices, wearable devices, retail devices, etc. Other services may be also be supported such as communications applications (e.g., short message service (SMS), etc.), automotive applications, aviation applications, etc. AS150may communicate with UEs110over access network120using IP and/or non-IP bearer channels. While only one AS150is shown inFIG. 1, in various embodiments, multiple application servers may be associated with different entities and used within environment100. Application servers150may be supported by service providers associated with various organizations (e.g., companies, non-profits, collaborative enterprises, etc.).

AlthoughFIG. 1shows exemplary components of environment100, in other implementations, environment100may include fewer components, different components, differently arranged components, or additional functional components than depicted inFIG. 1. Additionally or alternatively, one or more components of environment100may perform functions described as being performed by one or more other components of environment100.

FIG. 2is a block diagram of an exemplary networking system200including access network120based on the LTE standard. Access network120may include an LTE network with an evolved Packet Core (ePC)210and eNodeB220(corresponding, for example, to base station130). UE110and eNodeB220may exchange data over a radio access technology (RAT) based on LTE air channel interface protocols. In the embodiment shown inFIG. 2, ePC210may operate in conjunction with an evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Network (eUTRAN) that includes at least one eNodeB220. Networking system200may further include an Internet Protocol (IP) network and/or a non-IP network, which may be embodied separately or included in a backhaul network (not shown) and/or in WAN140. As shown inFIG. 2, AS150may be connected to WAN140over a wired or wireless connection, using, for example, transmission control protocol/internet protocol (TCP/IP) and/or using a non-IP based protocol.

EPC210may include one or more devices that are physical and/or logical entities interconnected via standardized interfaces. EPC210provides wireless packet-switched services and wireless packet connectivity to user devices to provide, for example, data, voice, and/or multimedia services. EPC210may further include a mobility management entity (MME)250, a serving gateway (SGW)260, a home subscriber server (HSS)270, a packet data network gateway (PGW)280, a Policy and Charging Rules Function (PCRF)290, and a SCEF295. It is noted thatFIG. 2depicts a representative networking system200with exemplary components and configuration shown for purposes of explanation. Other embodiments may include additional or different network entities in alternative configurations than which are exemplified inFIG. 2.

Further referring toFIG. 2, eNodeB220may include one or more devices and other components having functionality that allows UE110to wirelessly connect via the RAT of eNodeB220. ENodeB220may interface with ePC210via a S1 interface, which may be split into a control plane S1-MME interface224and a data plane S1-U interface225. EnodeB220may interface with MME250via S1-MME interface224, and interface with SGW260via S1-U interface225. S1-U interface226may be implemented, for example, using General Packet Radio Services (GPRS) Tunneling Protocol (GTP). S1-MME interface224may be implemented, for example, with a protocol stack that includes a Non-Access Stratum (NAS) protocol and/or Stream Control Transmission Protocol (SCTP).

MME250may implement control plane processing for both the primary access network and the secondary access network. For example, through eNodeB220, MME250may implement tracking and paging procedures for UE110, may activate and deactivate bearers for UE110, and may authenticate a user of UE110to provide normal coverage service for operating in normal UE device mode. MME250may also select a particular SGW260for a particular UE110. MME250may interface with other MMEs (not shown) in ePC210and may send and receive information associated with UEs110, which may allow one MME250to take over control plane processing of UEs serviced by another MME250, if the other MME becomes unavailable.

SGW260may provide an access point to and from UE110, may handle forwarding of data packets for UE110, and may act as a local anchor point during handover procedures between eNodeBs220. SGW260may interface with PGW280through an S5/S8 interface245. S5/S8 interface245may be implemented, for example, using GTP.

PGW280may function as a gateway to WAN140through a SGi interface255. WAN140may provide various services (e.g., over the top voice services) to UE110. A particular UE110, while connected to a single SGW260, may be connected to multiple PGWs280, one for each packet network with which UE110communicates.

Alternatively, UE110may exchange data with WAN140though a WI-FI wireless access point (WAP)(not shown). The WI-FI WAP may be part of a local area network, and access WAN140through a wired connection via a router. Alternatively, the WI-FI WAP may be part of a mesh network (e.g., 802.11s). The WI-FI WAP may operate in accordance with any type of WI-FI standard (e.g., any IEEE 802.11x network, where x=a, b, c, g, and/or n), and/or include any other type of wireless network technology for covering larger areas, and may include a mesh network (e.g., IEEE 802.11s) and/or or a WIMAX IEEE 802.16. The WI-FI WAP may also be part of a wide area network (WiMAX) or a mesh network (802.11s).

MME250may communicate with SGW260through an S11 interface235. S11 interface235may be implemented, for example, using GTPv2. S11 interface235may be used to create and manage a new session for a particular UE110. S11 interface235may be activated when MME250needs to communicate with SGW260, such as when the particular UE110attaches to ePC210, when bearers need to be added or modified for an existing session for the particular UE110, when a connection to a new PGW280needs to be created, or during a handover procedure (e.g., when the particular UE110needs to switch to a different SGW260).

HSS270may store information associated with UE110and/or information associated with users of UE110. For example, HSS270may store user profiles that include registration, authentication, and access authorization information. MME250may communicate with HSS270through an S6a interface265. S6a interface265may be implemented, for example, using a Diameter protocol.

Routing table285may be a network or computational device that may store information associated with available paths to UE110in a roaming network. SCEF295may interface with routing table285to determine the best path for transmitting data to UE110. In addition, SCEF295may access routing table285to determine an additional path for transmitting data to UE110in the event that a preferred path is unavailable. In alternative implementations in which access network120and/or WAN140include a 5G network, a network exposure function (NEF) may perform processing similar to SCEF295described herein.

PCRF290provides policy control decision and flow based charging control functionalities. PCRF290may provide network control regarding service data flow detection, gating, quality of service (QoS) and flow based charging, etc. PCRF290may determine how a certain service data flow shall be treated, and may ensure that user plane traffic mapping and treatment is in accordance with a user's subscription profile based, for example, on a specified QoS class identifier (QCI). PCRF290may communicate with PGW280using a Gx interface280. Gx interface280may be implemented, for example, using a Diameter protocol.

SCEF295may include a network or computational device that provides exposure of 3GPP network service capabilities to third party applications. Specifically, SCEF295may provide network events through application programming interfaces (APIs) to external applications which may reside on application servers150and/or UEs110. Exposure of the various events may include, for example: UE110reachability; UE110loss of connectivity; UE110location reporting; UE110roaming status; communication failure; and change of international mobile equipment identifier—international mobile subscriber identifier (IMEI-IMSI) association. SCEF295may facilitate NIDD services through a non-IP packet data network (PDN) established through SCEF295. In one implementation, SCEF295may exchange control plane signaling with MME250(via a T6a interface269using Diameter protocol) and/or HSS270(via an Sh or S6t interface267). In one implementation, SCEF295may be included as part of a control plane bearer path between UE device110and AS150. According to an implementation described herein, SCEF295may act as a gateway for connecting UE110to AS150. Generally, SCEF205may expose application-programming interfaces (APIs) for multiple application servers (such as AS150) to access network services to communicate with UEs110. SCEF295may communicate with MME250via a modified T6a interface relative to a standardized T6a interface.

WhileFIG. 2shows exemplary components of networking system200, in other implementations, networking system200may include fewer components, different components, differently arranged components, or additional components than depicted inFIG. 2. Additionally or alternatively, one or more components of networking system200may perform functions described as being performed by one or more other components of networking system200.

FIG. 3is a block diagram showing exemplary components of a network device300according to an embodiment. Network device300may include one or more network elements illustrated inFIG. 2, such as, for example, UE110, MME250, and/or HSS270, SCEF295, etc. In some embodiments, there may be a plurality of network devices300providing functionality of one or more network elements. Alternatively, once network device300may perform the functionality of any plurality of network elements. Network device300may include a bus310, a processor320, a memory330, storage device340, a network interface350, input device360, and an output device370.

Bus310includes a path that permits communication among the components of network device300. Processor320may include any type of single-core processor, multi-core processor, microprocessor, latch-based processor, and/or processing logic (or families of processors, microprocessors, and/or processing logics) that interprets and executes instructions. In other embodiments, processor320may include an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and/or another type of integrated circuit or processing logic. For example, processor320may be an x86 based CPU, and may use any operating system, which may include varieties of the Windows, UNIX, and/or Linux operating systems. Processor320may also use high-level analysis software packages and/or custom software written in any programming and/or scripting languages for interacting with other network entities are communicatively coupled to WAN140.

Memory330may include any type of dynamic storage device that may store information and/or instructions, for execution by processor320, and/or any type of non-volatile storage device that may store information for use by processor320. For example, memory330may include a random access memory (RAM) or another type of dynamic storage device, a read only memory (ROM) device or another type of static storage device, and/or a removable form of memory, such as a flash memory. Storage device340may include any type of on-board device suitable for storing large amounts of data, and may include one or more hard drives, solid state drives, and/or various types of redundant array of independent disks (RAID) arrays. In an embodiment, storage device340may store profile data associated with UEs110.

Network interface350may include a transceiver that enables network device300to communicate with other devices and/or systems in network environment100. Network interface350may be configured to exchange data with WAN140over wired communications (e.g., conductive wire, twisted pair cable, coaxial cable, transmission line, fiber optic cable, and/or waveguide, etc.), or a combination of wireless. In other embodiments, network interface350may interface with wide area network140using a wireless communications channel, such as, for example, radio frequency (RF), infrared, and/or visual optics, etc. Network interface350may include a transmitter that converts baseband signals to RF signals and/or a receiver that converts RF signals to baseband signals. Network interface350may be coupled to one or more antennas for transmitting and receiving RF signals. Network interface350may include a logical component that includes input and/or output ports, input and/or output systems, and/or other input and output components that facilitate the transmission/reception of data to/from other devices. For example, network interface350may include a network interface card (e.g., Ethernet card) for wired communications and/or a wireless network interface (e.g., a WI-FI) card for wireless communications. Network interface350may also include a universal serial bus (USB) port for communications over a cable, a Bluetooth® wireless interface, a radio frequency identification device (RFID) interface, a near field communications (NFC) wireless interface, and/or any other type of interface that converts data from one form to another form.

As described below, network device300may perform certain operations relating to automatic path selection. Network device300may perform these operations in response to processor320executing software instructions contained in a computer-readable medium, such as memory330and/or storage device340. The software instructions may be read into memory330from another computer-readable medium or from another device. The software instructions contained in memory330may cause processor320to perform processes described herein. Alternatively, hardwired circuitry may be used in place of, or in combination with, software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software. In an embodiment, the software instructions and/or hardware circuitry may perform the process exemplified by the diagram inFIG. 4, the signal flows inFIGS. 5A-5C, and the flow chart shown inFIG. 6.

AlthoughFIG. 3shows exemplary components of network device300, in other implementations, network device300may include fewer components, different components, additional components, or differently arranged components than depicted inFIG. 3.

FIG. 4is a diagram illustrating an exemplary network environment400consistent with an embodiment. As shown inFIG. 4, environment400may include UE110, AS150, home network420, and visiting network430. Home network420may include HSS270and SCEF295. Visiting network430may include visiting MME450. Visiting MME450may perform the same functions as the functions described above with respect to MME250. Although home network420and visiting network430may include additional components (such as components described above with respect toFIG. 2), some components are not shown inFIG. 4for the sake of simplicity.

As shown inFIG. 4, UE110may travel to visiting network430. For example, a user of UE110may travel internationally and may attach to visiting network430. When UE110attaches to visiting network430, SCEF295may send the visiting network430a connectivity profile and the capabilities of home network420and HSS270may provision the subscriber of UE110. For example, SCEF295may send peering end-system information for connection and authentication and a service level agreement (SLA), which may indicate which services are allowed.

UE110may be configured to store a list of connectivity options or capabilities for connecting to AS150via SCEF295(412). The preferred list may include multiple options for connecting to home network420in order of connection preference. As shown inFIG. 4, the first and most preferred option for connecting to home network420may include a non-IP or NIDD option. The non-IP option may be the most efficient way to deliver data between AS150and UE110. The second option for connecting to home network420may include an IP or DoNAS option. The third option may include an option to attach without a PDN using Short Messaging Service (SMS) only. When attaching using the third option, a PDN and a user plane may not be set up and only the SMS capability may be available. UE110may have the preferred list of options pre-loaded so that when UE110travels to visiting network430, UE110may be able to send and/or receive data using one or two of the options from the list.

Continuing withFIG. 4, visiting MME450may download a subscription profile from HSS270on home network420(414). For example, visiting MME450may download subscriber data including both IP and non-IP PDNs. Visiting MME450may further determine which path or paths to set up based on the capabilities of visiting network430(416). For example, if visiting network430does not have NIDD capabilities, visiting MME450may determine to set up paths using the second and third options on the list of connection options (i.e., IP and SMS).

When the paths have been established, SCEF295may receive a notification identifying establishment of the path(s) (418). SCEF295may record the registration of the path(s) along with session information and an identifier (ID) of visiting network430. In addition, SCEF295may add a path for UE110to routing table285for mobile terminating (MT) and mobile originating (MO) data. Although SCEF295may receiving a notification that multiple paths are able to be established, UE110may not set up all of the connections. For example, if visiting MME450determines that three paths (i.e., NIDD, IP, and SMS) paths can be established, UE110may determine to set up connections based on two of the paths. In this case, SCEF295may record information associated with the two paths that have been set up.

When information regarding the established paths has been recorded by SCEF295, SCEF295may deliver or receive MT or MO data based on the best delivery path (419). For example, if an NIDD path and a DoNAS path have been set up, SCEF295may deliver data from AS150and to UE110via the NIDD path.

In addition, because each path traverses SCEF295, SCEF295may be able to monitor the established paths and deliver data via a different path, if necessary. For example, if one of the paths fails, SCEF295may deliver data via a different path. For example, if the NIDD path was established and being used to deliver data and the NIDD path fails (e.g., due to a misconfiguration, a change in the roaming agreement, poor performance, or for another reason), SCEF295may deliver the data via the IP path or the SMS path (if the IP path is not available).

As another example, if the NIDD path has failed and the SMS path is available, SCEF295may send a message to UE110via the SMS path requesting that UE110set up PDN user plane connectivity. In this example, UE110may set up a new path to SCEF295via the user plane in order to send and receive data. In this way, alternative path options may be available to UE110and UE110may be able to send and receive data even in the case of path failure.

As described above, because home network420may configure the transport connectivity based on the roaming agreement with visiting network430and UE110may be configured with all the capabilities for home network420, there may be multiple options for sending data if a path fails. In addition, since UE110may be configured with a list of paths in a preferred order (non-IP or NIDD, IP or DoNAS, then SMS), SCEF295may choose the next preferred path in the event of a path failure. In addition, SCEF295may send an SMS message to instruct UE110to set up a PDN when necessary.

As shown inFIG. 4, UE110may be provisioned in HSS270and UE110may set up a connectivity based on the preferred list of options stored on UE110. Based on the registration with visiting network430and the capabilities of visiting network430, SCEF295may detect what type of connectivity UE110can set up with visiting network430. In addition, since more than one type of connection may be set up, SCEF295may be able to send data via alternative routes in the event of a path failure.

FIGS. 5A-5Care diagrams showing exemplary message flows within a networking system200for transmitting data between AS150and UE110in visiting network430.FIG. 5Ashows exemplary messaging flows for setting up a non-IP connection,FIG. 5Bshows exemplary messaging flows for setting up an IP connection, andFIG. 5Cshows exemplary messaging flows for setting up an SMS connection.

The most efficient way to deliver data between AS150and UE110on visiting network430may be using a non-IP or NIDD path. Therefore, when establishing a connection with visiting network430, home network420may first attempt to establish the connection via a non-IP path based on the capabilities of visiting network430. As shown inFIG. 5A, UE110may be enrolled with SCEF295(502) and SCEF295may send HSS270a message indicating that the roaming status of UE110should be monitored (504). UE110may attach to visiting network430(506) and visiting MME450may download subscriber data from HSS270on home network420(508). After receiving subscriber data, visiting MME450may determine that a non-IP or NIDD path via, for example, a T6/T7 interface is supported (510) and the non-IP PDN may be established (512). SCEF295may receive an indication that the non-IP path has been established (514) and SCEF295may update routing table285with the path information and an ID of visiting network430(516). When the non-IP path has been created and SCEF295has stored the information associated with the non-IP path, AS150may send data, such as MT data, to UE110via SCEF295(518). In addition, UE110may send data, such as MO data, to AS150via the established non-IP path via SCEF295(520).

When visiting network430does not have the capabilities to establish a connection via the non-IP or NIDD path, home network420may attempt to establish an IP or DoNAS path, as shown inFIG. 5B. As shown inFIG. 5B, UE110may be enrolled with SCEF295(522) and SCEF295may send HSS270a message indicating that the roaming status of UE110should be monitored (524). UE110may attach to visiting network430(526) and visiting MME450may download subscriber data from HSS270on home network420(528).

Visiting MME450may indicate that visiting network430does not have the capabilities to establish a non-IP path or that a T6/T7 interface is not supported (530) and an511u-based IP path may be established between visiting network430and home network420(532). SCEF295may receive an indication that the IP path has been established (534) and SCEF295may update routing table285with the path information and an ID of visiting network430(536). When the IP path has been created and SCEF295has stored the information associated with the IP path, AS150may send data, such as MT data, via a DoNAS path to UE110via SCEF295(538). In addition, UE110may send data, such as MO data, via the DoNAS path to AS150via SCEF295(540).

Turning toFIG. 5C, when visiting network430lacks the capabilities to establish a non-IP path and an IP path, an SMS path may be established without a PDN. As shown in FIG.5C, UE110may be enrolled with SCEF295(542) and SCEF295may send HSS270a message indicating that the roaming status of UE110should be monitored (544). UE110may attach to visiting network430(546) and visiting MME450may download subscriber data from HSS270on home network420(548). Visiting MME450may determine that visiting network430does not have the capabilities to establish a non-IP path or that a T6/T7 interface is not supported (550). Visiting MME450may further determine that visiting network430does not support an IP or DoNAS path (552). Because the non-IP path and the IP path cannot be established, an SMS path may be established between visiting network430and home network420(554). UE110may send a message to SCEF295indicating that UE110is reachable only via SMS and that no user plane, T7 interface, or S11u interface has been set up or is available (556). SCEF295may update routing table285with the path information and an ID of visiting network430(558). When the SMS path has been created and SCEF295has stored the information associated with the SMS path, AS150may send data, such as MT data, via the SMS path to UE110via SCEF295(560). In addition, UE110may send data, such as MO data, via the SMS path to AS150via SCEF295(562).

FIG. 6is a flow chart showing an exemplary process600for forming a connection between AS150and UE110on roaming network430via SCEF295. Process600may be performed by SCEF295, HSS270, and/or other components of home network420.

Process600may begin by provisioning UE110with connectivity capabilities of home network420(block602). For example, UE110may be configured to store a list of options for connecting to AS150via SCEF295in home network420when UE110is roaming in visiting network430. In one implementation, the list may indicate a preferred order for connecting to AS150. For example, the list may indicate that, based on the capabilities of roaming network430, a preferred order of connection may include connecting via a non-IP path, connecting via an IP path, and connecting via an SMS path.

When UE110travels to and forms a connection with visiting network430, home network420may transmit a subscription profile to visiting network430(block604). For example, HSS270may transmit the subscription profile to visiting MME450. In one implementation, the subscription profile may include information associated with IP and non-IP PDNs. The subscription profile may include capabilities associated with home network420for forming connections with visiting network430.

Based on the received subscription profile, visiting network430may set up a path based on the capabilities of visiting network430and SCEF295may receive an indication of the established connection (block606). For example, SCEF295may receive an identifier associated with visiting network430, an indication of paths that can be set up based on the capabilities of visiting network430, and an indication of established connections. SCEF295may store the information in routing table285. In one implementation, the available paths and established connections may be stored in routing table285in an order of preference.

Process600may continue by attempting to deliver data to UE110via an established path (block608). For example, SCEF295may receive MT data from AS150and may attempt to deliver the data to UE110via the best available path identified in routing table285. SCEF295may determine whether the delivery was successful (block610). If the data delivery was successful (block610—yes), SCEF295may provide an indication to AS150that the data was successfully delivered to UE110(block612).

If the data was not successfully delivered to UE110(block610—no), SCEF295may determine an alternate route for delivering the data to UE110(block614). In one implementation, SCEF295may determine that the data was not successfully delivered to UE110because the connection has failed. For example, if SCEF295has been sending data to UE110via a non-IP or NIDD path, SCEF295may determine that the T6/T7 interface has failed and that the data should be sent via a different route. In this case, SCEF295may determine from routing table285that the next best available path is the IP or DoNAS path. As another example, if the non-IP and the IP paths have failed (or if visiting network430does not support the non-IP path and the IP path has failed), SCEF295may determine from routing table285that the best option is sending data via the SMS path. In this example, SCEF295may determine to send the data to UE110via the SMS path.

When SCEF295has determined an alternate route for sending the data to UE110, SCEF295may attempt to deliver the data via the alternate path (block608) and determine whether the delivery was successful (block610). If the delivery was successful (block610—yes), SCEF295may provide an indication to AS150that the data was successfully delivered to UE110(block612). If the delivery was not successful (block610—no), SCEF295may determine another path for sending the data to UE110(block614).

Implementations described above with regard toFIG. 6allow SCEF295to detect the path(s) to UE110and automatically select a new path to UE110if there is a failure in a connection. SCEF295may automatically determine a new path based on the path list stored in routing table285that indicates the preferred order of paths for delivering data to UE110. The path list stored in routing table285may be based on a preferred path list stored in UE110. In addition, when non-IP and IP paths are unavailable or when visiting network430lacks the capabilities to form non-IP or IP connections, SCEF295may communicate with UE110using an SMS-only path. SCEF295may further offer a unified application programming interface (API) for data delivery for home-based or roaming UEs110. In addition, since data traveling between AS150and UE110traverses SCEF295, SCEF295may handle the routing without the need for AS150to know which communication path is being used to deliver the data between UE110and AS150.

The process described with regard toFIG. 6may provide an end-to-end solution for transmitting data between UE110and AS150via SCEF295. The signaling procedures include dynamic routing options between AS150, SCEF295in home network420, and UE110in visiting network430. In addition, the process described above may help improve downlink data by selecting an alternate path if there is poor quality or a failure in a given path by implementing retry logic using an alternate communication path. Further, the process described above may improve the billing and real-time usage control via SCEF295. For example, SCEF295having visibility to all roaming interface options could be beneficial for reporting and billing.

Implementations described herein allow SCEF295and/or an NEF in a 5G network to detect the path availability in real-time and automatically maintain up to date routing information for the applications to reach UEs110. In addition, implementations described herein allow the network to automatically retry multiple delivery attempts over alternative (e.g., less preferred) path(s) if an initial delivery fails via an initial preferred delivery path. In some implementations, SCEF295(or an NEF in a 5G network) may generate alarms to provisioning systems and/or personnel associated with the provisioning systems based on errors in realization of roaming peering connectivity SLAs or parameterization in various involved network elements. Implementations described herein also allow SCEF295and/or an NEF in a 5G network to initiate an alternative path in concert with UE110when UE110operates in an optimized mode (e.g., attach without a PDN), which may be used in various situations, such as for low power wide area network devices that desire to remain in a minimal run-time resource mode and set up a path on demand.

The foregoing description of implementations provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Various preferred embodiments have been described with reference to the accompanying drawings. It will be evident that modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. For example, while series of messages, states, and/or blocks have been described with regard toFIGS. 5A-5C and 6, the order of the messages, states, and/or blocks may be modified in other embodiments. Further, non-dependent messaging and/or processing blocks may be performed in parallel. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.

The terms “comprises” and/or “comprising,” as used herein specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components, or groups thereof. Further, the term “exemplary” (e.g., “exemplary embodiment,” “exemplary configuration,” etc.) means “as an example” and does not mean “preferred,” “best,” or likewise.