WO2018093948A1

WO2018093948A1 - Systems and methods to handle emergency calls in multi core operator network environment

Info

Publication number: WO2018093948A1
Application number: PCT/US2017/061869
Authority: WO
Inventors: Deepak DASH; Anuroop Sobhan MADUPU; Nitin Gowda BASAVARAJAPPA
Original assignee: Intel IP Corporation
Priority date: 2016-11-18
Filing date: 2017-11-15
Publication date: 2018-05-24

Abstract

An enhanced Node B (eNB) may be connected to multiple Public Land Mobile Networks (PLMNs). Some of the PLMNs may support a particular network service (e.g., emergency calls) while others may not. The eNB may communicate with Mobility Management Entities (MMEs) of the PLMNs to create a list regarding the capacity of the PLMNs support the particular network service. The eNB may communicate the list to User Equipment (UE) to enable the UE to make emergency calls that are directed to PLMNs that support the particular network service. Alternatively, the eNB may store a local copy of the list and, upon receiving a request from a UE to access the particular network service, use the list to route the request to a PLMN that supports the particular network service.

Description

SYSTEMS AND METHODS TO HANDLE EMERGENCY CALLS IN MULT I CORE

OPERATOR NETWORK ENVIRONMENT

RELATED APPLICATIONS

The present application claims the benefit of U.S. Provisional Patent Application No. 62/424,245, which was filed on November 18, 2016, the contents of which are hereby incorporated by reference as though fully set forth herein.

BACKGROUND

A Public Land Mobile Network (PLMN) may include a wireless telecommunication network that is owned and operated by a particular company or organization often referred to as an operator. A PLMN may be identified by a combination of a Mobile Country Code (MCC) and a Mobile Network Code (MNC). User Equipment (UE) (e.g., smartphones, tablet computers, laptop computers, etc.) may connect to a PLMN by communicating with a Radio Access Network (RAN) that often include one or more base stations and a core network.

A single RAN may be connected to PLMNs of different operators, such that UEs may connect to different PLMNs via the same RAN. A UE may indicate the PLMN to which the UE is to connect by communicating a MCC and MNC (which may be stored in a Subscriber Identification Module (SIM) card of the UE) to the RAN, and the RAN may direct traffic from the UE to the appropriate PLMN. This functionality may enable subscribers of different operators to use the same RAN but still connect to their respective operator networks (e.g., PLMNs).

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments described herein will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals may designate like structural elements. Embodiments are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings.

Fig. 1 illustrates an example environment in which systems and/or methods described herein may be implemented; Fig. 2 is a flowchart of an example process for enabling UEs to setup Internet Protocol Multimedia Subsystem (IMS) emergency calls with an appropriate Public Land Mobile Network (PLMN);

Fig. 3 is an example of a table representing Mobility Management Entity (MME) of PLMNs that support IMS emergency calls;

Fig. 4 is an example of a table representing PLMNs that support IMS emergency calls; Fig. 5 is another example of a table representing PLMNs that support IMS emergency calls;

Fig. 6 is an example of a process for enabling User Equipment (UE) to establish an IMS emergency call with an appropriate PLMN based on a list of PLMNs provided to UE;

Fig. 7 is another example of a process for enabling UE to establish an IMS emergency call with an appropriate PLMN based on a list of PLMNs stored by enhanced Node B (eNB);

Fig. 8 illustrates example components of a device in accordance with some embodiments; Fig. 9 illustrates example interfaces of baseband circuitry in accordance with some embodiments; and

Fig. 10 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. Therefore, the following detailed description is not to be taken in a limiting sense, and the scope of embodiments is defined by the appended claims and their equivalents.

A wireless telecommunication network may include an enhanced Node B (eNB) that is connected to core networks that correspond to different Public Land Mobile Networks (PLMNs). A network that includes an eNB connected to PLMNs of different operators may be referred to as a Multi Operator Core Network (MOCN). User Equipment (UE) (e.g., smartphones, tablet computers, laptop computers, etc.) may connect to a particular PLMN, of a MOCN, by providing the eNB with an identifier of that PLMN (e.g., a PLMN identifier (ID)). An example, of such an identifier may include a Mobile Country Code (MCC) and a Mobile Network Code (MNC) of the PLMN, which may be stored in a Subscriber Identification Module (SIM) card of the UE.

In some scenarios, a UE may attempt to connect to a MOCN without an appropriate PLMN identifier. For example, a UE without a SIM card may still be used to initiate an emergency call. In another example, a roaming UE (e.g., a UE with a SIM card that does not correspond to any of the PLMNs to which the eNB is connected) may attempt to connect to the network. These are examples of the UE operating in a "limited mode" or "limited service mode," where the UE cannot obtain normal calling and data services from the network. In either scenario, the services requested by the UE (e.g., the emergency call, roaming service, etc.) may be delayed or dropped by the network. For instance, since different PLMNs may support different types of network services, if the eNB forwards an emergency call request to a PLMN that does not support Internet Protocol Multimedia Subsystem (IMS) services, the call may be dropped, and the UE may have to continue trying different PLMNs until the call is sent to a PLMN that supports emergency calls.

The techniques described herein may enable a wireless telecommunication network to connect UEs to appropriate PLMNs within a MOCN environment. An eNB may identify PLMNs connected to the eNB, create a list of the PLMNs, and identify the capabilities and services supported by each PLMN (e.g., emergency calls, location services, extended services, etc.). In one example, the eNB may create a prioritized list the PLMNs regarding a particular capability and/or service. For example, a prioritized list for emergency calls may include a list of PLMNs with PLMNs that support emergency calls located at/near the top of the list. The eNB may distribute the prioritized list by broadcasting the list to UEs in the network. The eNB may broadcast the list via System Information (e.g., one or more System Information Blocks (SIBs)). Prioritized lists for other capabilities and/or services may also be created and broadcasted to UEs. As such, when a UE requires support for a particular service, the UEs may select the prioritized list corresponding to the service, and select an appropriate PLMN (e.g., by default) by selecting a PLMN indicated at or near the top of the prioritized list.

In a second example, instead of prioritizing the list of PLMNs, the eNB may indicate which PLMNs in the list support which capabilities and services (e.g., emergency calls, location services, extended services, etc.). When the UEs require support for a particular service, the UEs may use the list to identify a PLMN capable of supporting the service, and direct

communications toward the identified PLMN. In a third example, instead of broadcasting a list of PLMNs to UEs, the eNB may store a local copy of the list, which, depending on the embodiment, may be prioritized according to the first example or annotated according to the second example. When support for a particular service is required by a UE, the eNB may use the list to direct communications from the UE, regarding the particular service, to an appropriate PLMN (e.g., a PLMN that supports the particular service).

While one or more of the techniques, described herein, may be described within a context of an emergency call, such descriptions are provided as non-limiting examples of the techniques described herein. In practice, one or more of the techniques described herein may be applicable to one or more additional and/or alternative capabilities and/or services that may be supported by a PLMN, in addition to procedures (e.g., message, communications, etc.) to access the capabilities and/or services. Examples of such capabilities and services may include location services, extended services, Internet Protocol Multimedia Subsystem (IMS) voice over PS session indicator (IMS VoPS) services, S l-U data transfer services, header compression services, extended protocol configuration operation services, etc. Such capabilities and/or services may be individually referred to herein as a network service, particular network service, etc., and collectively as network services or the like. As such, while some of the examples described herein may involve emergency calls and whether a PLMN supports emergency calls, the techniques described herein may applied to any PLMN specific capability, function, or service.

Fig. 1 illustrates an example environment 100 in which systems and/or methods described herein may be implemented. Environment 100 may include UEs 1 10 (referred to individually as UE 1 10 and collectively as UEs 1 10) and a wireless telecommunication network with multiple PLMNs 160 (referred to individually as PLMN 160 and collectively as PLMNs 160). The wireless telecommunication network may be, or may include, a RAN that includes one or more base stations, some or all of which may take the form of eNB 120 via which UEs 1 10 may communicate with PLMNs 160. Each PLMN 160 may include a core network (such as Evolved Packet Core (EPC)) with a management device (such as a Mobility Management Entity (MME) 130). One or more of the core networks may include an Internet Protocol Multimedia Subsystem (IMS) 150 that may help deliver IP multimedia services, such as Voice over IP (VoIP) services, video calling services, etc., to UEs 1 10. In some embodiments, PLMNs 160 with IMS 150 may support emergency IMS calls from UEs 1 10. Some or all of the wireless telecommunication network may operate based on the 3 GPP Wireless Communication Standard.

The quantity of devices and/or networks, illustrated in Fig. 1, is provided for explanatory purposes only. In practice, there may be additional devices and/or networks; fewer devices and/or networks; different devices and/or networks; or differently arranged devices and/or networks than illustrated in Fig. 1. For example, EPC 140 may also, or alternatively, include a Serving Gateway (SGW), Packet Data Network (PDN) Gateway (PGW), and Policy Charging and Rules Function (PCRF). Similarly, IMS 150 may include a Home Subscriber Server (HSS)/ Authentication, Authorization, Accounting (AAA) server, Telephone Application Server (TAS), Call Session Control Function (CSCF), etc.

Furthermore, one or more of EPCs 140 may be connected to an external network, which may include one or more wired and/or wireless networks. The external network may include a cellular network, another PLMN, a Second Generation (2G) network, a Third Generation (3G) network, a Fourth Generation (4G) network, a Fifth Generation (5G) network, and/or another network. Additionally, or alternatively, the external network may include a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network ("PSTN")), an ad hoc network, an intranet, PDN (e.g., the Internet), a fiber optic-based network, and/or a combination of these or other types of networks.

In some implementations, some or all of the wireless telecommunication network of Fig. 1 may be provided by one or more cellular network providers. That is, in some such implementations, network devices within, or associated with, the wireless telecommunication network, may be provided by the one or more cellular network providers. In some implementations, the wireless telecommunication network may be communicatively coupled to one or more other networks, such as the Internet.

UE 1 10 may include a portable computing and communication device, such as a personal digital assistant (PDA), a smart phone, a cellular phone, a laptop computer with connectivity to the wireless telecommunications network, a tablet computer, etc. UE 1 10 may also include a non-portable computing device, such as a desktop computer, a consumer or business appliance, or another device that may connect to a RAN of the wireless telecommunications network. UE 1 10 may also include a computing and communication device that may be worn by a user (also referred to as a wearable device) such as a watch, a fitness band, a necklace, glasses, an eyeglass, a ring, a belt, a headset, or another type of wearable device. In some embodiments, UE 110 may also, or alternatively, include an Internet-of-Things (IoT) device capable of communicating with the EPC via eNBs 120. Examples of an IoT device may include an appliance, a vending machine, an Automated Teller Machine (ATM), a utilities meter, and an environmental measuring device (for measuring temperature, pressure, humidity, precipitation, seismic activity, etc.) and more.

In some embodiments, UE 110 may be capable of performing one or more of the operations described herein. For example, UE 110 may receive a list of PLMN IDs for making IMS emergency calls. In some embodiments, UE 110 may be configured to use the PLMN ID at the top of the list of PLMN IDs by default. Additionally, or alternatively, UE 110 may be capable of scanning the list a PLMN capable of supporting IMS emergency calls and using the PLMN to setup an IMS emergency call.

eNB 120 may include one or more network devices that receives, processes, and/or transmits traffic destined for and/or received from UE 110 (e.g., via an air interface). eNB 120 may be connected to a network device, such as a site router, that functions as an intermediary for information communicated between eNB 120 and EPCs 140. eNB 120 may be capable of identifying PLMNs 160, determining which PLMNs 160 are capable of supporting an emergency call, creating a list that indicates (either implicitly or explicitly) which PLMNs 160 support emergency calls, and providing the list to UEs 110. eNB 120 may also, or alternatively, store a local copy of the list and use the list to route emergency calls from UEs 110 to EPCs 140 that support emergency calls.

MME 130 may include one or more computation and communication devices that act as a control node for eNB 120 and/or other devices that provide the air interface for the wireless telecommunications network. For example, MME 130 may be responsible for registration management and mobility management of UE 110. Mobility management may indicate mobility between multiple registration areas. MME 130 may be a Non-Access-Status (NAS) level control plan entity. Hence, MME 130 may not control handovers at the radio level. Instead, radio-level handovers may be handled by eNBs 120. MME 130 may help in establishing a data plane in the telecommunication network. Actual user data may not flow through MME 130 (with the exception of certain communications, such as except Simple Messaging Service (SMS) communications). Rather, such data flows may occur from eNBs 120 to SGWs and PGWs. MME 130 may help eNBs 120 establish a connection with SGWs. In some embodiments, MME 150 may be capable of determining whether the PLMN of the MME is capable of supporting emergency calls and/or notifying eNB 120 of such capabilities.

Fig. 2 is a flowchart of an example process 200 for enabling UEs 1 10 to setup IMS emergency calls with an appropriate PLMN 160. Process 200 may be implemented by eNB 120. Fig. 2 is described below with reference to Figs. 3-5.

As shown, process 200 may include identifying PLMNs 160 that support emergency calls (block 210). For example, eNB 120 may identify each PLMN 160 to which eNB 120 is connected and/or communicate with one or more devices, of each PLMN 160, to determine which (if any) of the PLMNs support emergency calls. The indicator may include a Boolean value, such as true/false value, a yes/no value, a 1/0 value, etc.

In some embodiments, eNB 120 may identify PLMNs 160 by sending a request (e.g., an S I Setup Request message) to MME 130 of EPC 140 about whether the PLMN 160 of that MME 130 supports IMS emergency calls. In some embodiments, this may include MME 130 returning a particular indicator, such as an MME IMS Emergency Support Indicator, to eNB 120. The indicator may include a Boolean value, such as true/false value, a yes/no value, a 1/0 value, etc. The indicator may also, or alternatively include another type of value, such as a pre-selected alphanumeric string or code. eNB 120 may associate each indicator with an identifier (e.g., a PLMN ID) of the PLMN 160 in order to track whether the PLMN 160 supports emergency calls. In some embodiments, PLMN 160 may have multiple MMEs 130, and some of the MMEs 130 may support MS emergency calls while others MMEs 130 do not. As such, eNB 120 may collect MMECs, along with PLMN IDs, since whether a PLMN 160 supports IMS emergency calls may vary between MMEs 130. In some embodiments, the request from eNB 120 (e.g., the S I Setup Request message) to MME 130 may also, or alternatively, be used to determine other types of capabilities associated with MME 130, such as whether MME 130 (and/or the network to which MME 130 is associated) is capable of supporting IMS emergency calls, etc. The particular capabilities associated with MME 130 (which may include the particular capabilities of the PLMN of MME 130) may be broadcasted to UEs 1 10 in one or more SIBs.

In some embodiments, eNB 120 may identify PLMNs that support emergency calls by executing a scanning function for identifying the PLMNs 160 to which eNB 120 is connected. In some embodiments, the scanning function may be executed periodically, according to a pre- set schedule and/or in response to a request from a network administrator. In some embodiments, eNB 120 may be configured to automatically identify PLMNs that support emergency calls in response to one or more prompts, such as an initial communication involving a new PLMN device. Additionally, or alternatively, eNB 120 may receive (e.g., from another device, a network administrator, etc.) with a list of the PLMNs 160 that eNB 120 is communicate with and determine whether the PLMNs support emergency calls. In some embodiments, eNB 120 may also identify the PLMNs 160 that do not support emergency calls.

Fig. 3 is an example of a table representing MMEs 130 of PLMNs 160 that support IMS emergency calls. The table of Fig. 3 may represent information, collected by eNB 120, while determining which PLMNs and MMEs support emergency calls. As shown, the table of Fig. 4 may include rows that include a PLMN ID attribute, an MME Code (MMEC) attribute, and an Emergency Call Support attribute.

The PLMN ID attribute (PLMN_1, PLMN_2, etc.) indicate the PLMNs 160 to which eNB 120 is connected. The MMEC attribute (MME l, MME_2, etc.) may indicate the MMEs 130 of each PLMN 160. The Emergency Call Support attribute (Yes/No) may indicate whether a particular MME 130 of a particular PLMN 160 supports IMS emergency calls. As shown, eNB 120 is only connected to one MME 130 for the PLMNs 160 of PLMN l and PLMN_2, and neither of these MMEs 130 support IMS emergency calls. By contrast, eNB 120 is connected to two MMEs 130 (MME l and MME 2) of the PLMN 160 of PLMN 3, and both MMEs 130 support IMS emergency calls. The PLMN 160 of PLMN 4 also includes two MMEs 130, though only one of the two MMEs 130 (i.e., MME_2) supports IMS emergency calls. The example of Fig. 3 includes PLMN IDs and MMECs for mapping support for IMS emergency calls. In some embodiments, additional, fewer, and/or alternative types of information may be used to map network support for emergency calls. Examples of such information may include MME Identifiers (MMEIs), MME Group IDs (MMEGIs), Globally Unique MME IDs

(GUMMEIs), etc.

Process 200 may also include creating a list of PLMNs that support emergency calls (block 220). For example, eNB 120 may compile a list, table, or another type of data structure that indicates the PLMNs 160 that support emergency calls. In some embodiments, eNB 120 may do so by arranging PLMN IDs in a certain manner, such as creating a list that prioritizes PLMN IDs according to which PLMNs 160 support emergency calls. In some embodiments, eNB 120 may do so by creating a table that marks, flags, or otherwise explicitly indicates which

PLMNs 160 support emergency calls.

Fig. 4 is an example of a table representing PLMNs that support IMS emergency calls.

As shown, the table of Fig. 4 includes rows of PLMN IDs (PLMN_1, PLMN_2, etc.) that each have a corresponding priority position (1, 2, etc.). As described herein, PLMN IDs may include information corresponding to a PLMN (e.g., an MNC and MCC).

Assume that PLMN_3 and PLMN_4 correspond to PLMNs 160 that support emergency calls, while PLMN_1 and PLMN_2 correspond to PLMNs 160 that do not support emergency calls. In some embodiments, the PLMN IDs may instead be MME identifiers, such as MME Codes (MMEC). Each PLMN ID may correspond to a different PLMN 160, and the

corresponding priority attribute may indicate a position of priority, of a PLMN ID, with respect to other PLMN IDs. The PLMN IDs may first be ranked in accordance with whether the corresponding PLMN supports emergency calls, and then in accordance with alphabetical order.

PLMN_3 and PLMN_4 are therefore listed first and second, respectively while PLMN_1 and PLMN_2 are listed third and fourth, respectively. As such, eNB 120 may create a table of

PLMN IDs and prioritize the list based on whether the corresponding PLMN supports emergency calls.

Fig. 5 is another example of a table representing PLMNs that support IMS emergency calls. As shown, the table of Fig. 5 includes rows of PLMN IDs (PLMN_1, PLMN_2, etc.) that have each been associated with an "Emergency Call Support" attribute. Each PLMN ID may include information corresponding to a PLMN (e.g., an MNC and MCC). The "Emergency Call Support" attribute may indicate whether the corresponding PLMN 160 supports IMS emergency calls. For instance, according to the example of Fig. 5, the PLMNs 160 corresponding to the PLMN IDs of PLMN l, PLMN_2, and PLMN_4, do not support emergency calls but the PLMN 160 corresponding to PLMN_3 does support emergency calls. As such, eNB 120 may create a list, table, or other data structure that explicitly indicates whether each PLMN 160 supports IMS emergency calls.

The quantity, type, and arrangement of the information, illustrated in Figs. 4 and 5, is provided for explanatory purposes only. In practice, the information, and/or the manner in which the information is arranged, may vary. For instance, while the example of Fig. 4 includes a table or rows with two attributes each, eNB 120 may create a different arrangement of prioritized information in order to represent which PLMNs, in a particular MOCN environment, are suitable for emergency calls. For example, eNB 120 may not explicitly indicate the priority of each PLMN ID. Instead, the priority may be inferred from the sequential position of one PLMN ID with respect to another. Alternatively, eNB 120 may assign an explicit priority to each PLMN ID but not arrange the PLMN IDs in a sequence that necessarily that reflects the priority.

In another example, eNB 120 may only include PLMN IDs for PLMNs 160 that support emergency calls, and the PLMN IDs may be prioritized according to which (of those PLMNs 160) the UE 110 should first attempt to setup an emergency call. In yet another example, the quantity of PLMN IDs in the table of Fig. 4 or 5 may be limited to a specific quantity.

Additionally, while the tables of Figs. 4 and 5 include certain titles or labels, such as Prioritized PLMN IDs, PLMN ID, PLMN List, etc., eNB 120 may not use titles or labels when creating a list that indicates which PLMNs 160 support IMS emergency calls.

Returning now to Fig. 2, process 200 may include using the list of PLMNs to enable UEs 110 to setup emergency calls (block 230). For example, in some embodiments, eNB 120 may enable UEs 110 to setup IMS emergency calls by communicating the list to UEs 110. As described in detail below with reference to Fig. 6, UEs 110 may later use the list to identify an appropriate PLMN 160 for establishing an IMS emergency call, and send a request (that identifies the appropriate PLMN 160) to eNB 120. In some embodiments, eNB 120 may communicate the list to UEs 110 as system information via a shared channel. For example, eNB 120 may broadcast the information via one or more SIBs in a Physical Downlink Shared Channel (PDSCH), such as SIB1 via a "SystemlnformationBlockType 1 " message, SIB2 via a

"Systemlnformation (SI)" message, etc. As such, eNB 120 may broadcast the list in such a way so that UEs 110 may receive the list without having first having established a bearer with eNB 120 and/or becoming registered with a core network of a PLMN 160.

In some embodiments, eNB 120 may enable UEs 110 to setup IMS emergency calls by storing a local copy of the list of PLMNs. Later, when UE 110 sends a request for an IMS emergency call, eNB 120 may consult the list to determine the PLMN 160 to which the request should be routed. In some embodiments, eNB 120 may assist UEs 110 with IMS emergency calls by broadcasting the list of PLMNs and storing a local copy. In such embodiments, when eNB 120 receives a request for an IMS emergency call, eNB 120 may determine whether the request already includes PLMN information. If so, eNB 120 may verify whether the PLMN information is appropriate (by comparing the PLMN information in the request with PLMN information of the list stored locally by eNB 120) and/or route or otherwise forward the request in accordance with the PLMN information. If the request does not include PLMN information, eNB 120 may reference the locally stored copy of the list of PLMNs, determine an appropriate PLMN for setting up the emergency all, and route the request to the appropriate PLMN.

As described herein, eNB 120 may help setup an IMS emergency call by performing an MME selection function. For example, eNB 120 may route a request for an emergency call to an appropriate PLMN by identifying MMEs 130 of the PLMN 160 that support IMS emergency calls and selecting a particular MME 130 to handle the call. In some embodiments, eNB 120 may select from among multiple MMEs 130 based on one or more parameters (e.g., whether the MME 130 serves the UE's location, whether the UE is likely to switch to a different MME 130 because of the service area corresponding to the MME 130, one or more load balancing functions between MMEs 130, etc.). In some embodiments, eNB 120 may help UE 110 setup an IMS emergency call regardless of whether UE 110 previously selected or registered with a PLMN 160 that supports IMS emergency calls. For example, UE 110 may perform an Radio Resource Control (RRC) connection setup procedure involving a PLMN 160 that does not support IMS emergency calls. If the UE 110 is later used to initiate an emergency call, the techniques described herein may cause eNB 120 to dynamically route the call to an appropriate (i.e., different) PLMN 160.

While one or more of the techniques, described herein, may be described within a context of an emergency call, such descriptions are provided as non-limiting examples of the techniques described herein. In practice, one or more of the techniques described herein may be applicable to one or more additional and/or alternative capabilities or services that may be supported by a PLMN. Examples of such capabilities and services may include location services, extended services, Internet Protocol Multimedia Subsystem (IMS) voice over PS session indicator (IMS VoPS) services, etc. As such, while some of the examples described herein may involve emergency calls and whether a PLMN supports emergency calls, the techniques described herein may applied to any PLMN specific capability, function, or service.

Fig. 6 is an example of a process for enabling UE 110 to establish an IMS emergency call with an appropriate PLMN 160 based on a list of PLMNs provided to UE 110. As shown, the example of Fig. 6 may include UE 110, eNB 120, MME 130-1, and MME 130-3. MME 130-1 may correspond to a PLMN 160 that does not support IMS emergency calls, while MME 130-3 may correspond to a PLMN 160 that does support IMS emergency calls. The example of Fig. 6 is provided as a non-limiting example. In practice, the example of Fig. 6 may include fewer, additional, and/or alternative, operations or functions. Additionally, one or more of the operations or functions of Fig. 6 may be performed by fewer, additional, and/or alternative devices, which may include one or more of the devices described above with reference to Fig. 1. eNB 120 may communicate an SI Setup Request message (or another type of SI message) to MME 130-1 (at 610). The message may include (but may not be limited to) a request for MME 130-1 to indicate whether MME 130-1 (or the PLMN 160 of MME 130-1) supports IMS emergency calls. In some implementations, the message may also include a request for other types of information, such as information identifying the PLMN (e.g., a MNC and MCC), MME 130-1 (e.g., a MMEC), etc.

MME 130-1 may respond by sending a SI Setup Response message to eNB 120 (at 620). The response from MME 130-1 may include an indication of whether IMS emergency calls are supported (e.g., an IMS Emergency Support Indicator). Since MME 130-1 corresponds to a PLMN that does not support IMS emergency messages, the IMS Emergency Support Indicator from MME 130 may be set to FALSE. eNB 120 may initiate another setup procedure involving MME 130-3 (at 630); however, the SI Setup Response from MME 130-3 may include an (e.g., an IMS Emergency Support Indicator of TRUE, indicating that the PLMN of MME 130-3 supports IMS emergency calls (at 640).

After the setup procedures with MME 110-1 and MME 130-3 (and any other MMEs connected to eNB 120) eNB 120 may create a list of PLMNs that support IMS emergency calls (at 650). As described above with reference to Fig. 4, eNB 120 may create the list of PLMNs by indicating the PLMNs and/or MMEs 130 to which eNB 120 is connected, and prioritizing the list according to the PLMNs that support IMS emergency calls. Alternatively, as described above with reference to Fig. 5, eNB 120 may create the list of PLMNs by indicating the PLMNs and/or MMEs 130 to which eNB 120 is connected, and explicitly indicating which PLMNs support IMS emergency calls.

eNB 120 may communicate the list of PLMNs to UE 110 (at 660). eNB 120 may do so by including the list in a SIB (e.g., SIB1, SIB2, etc.) and broadcasting the list to UE 110 via a shared channel. Subsequent to receiving the list, UE 110 may initiate an IMS emergency call (at 670). As shown, this may include selecting a PLMN (and/or MME) from the list of PLMNs. In some embodiments (e.g., when the list is a prioritized list) UE 110 may be configured to select the first PLMN in the lists. In some embodiments (e.g., when the list is not prioritized and/or explicitly indicates PLMNs that support emergency calls) UE 110 may browse the list of PLMNs to identify and select a PLMN that supports IMS emergency calls. Thereafter, UE 110 may create an Attach Request message for setting up an IMS emergency call, indicate the selected PLMN in the Attach Request, and send the Attach Request to the selected PLMN 160 (at 680). The Attach Request may include a Request Type indicator that is set to "Emergency. " As shown, eNB 120 may receive the Attach Request, perform an MME Selection Function based on the Attach Request, and forward the Attach Request to MME 130-3. The Attach Request may initiate an Emergency Attach procedure, whereby MME 130-3 may apply MME Emergency Configuration Data to enable UE 110 to establish an emergency bearer for the call.

Fig. 7 is another example of a process for enabling UE 110 to establish an IMS emergency call with an appropriate PLMN 160 based on a list of PLMNs stored by eNB 120. As shown, the example of Fig. 6 may include UE 110, eNB 120, MME 130-1, and MME 130-3. MME 130-1 may correspond to a PLMN 160 that does not support IMS emergency calls, while MME 130-3 may correspond to a PLMN 160 that does support IMS emergency calls. The example of Fig. 7 is provided as a non-limiting example. In practice, the example of Fig. 7 may include fewer, additional, and/or alternative, operations or functions. Additionally, one or more of the operations or functions of Fig. 7 may be performed by fewer, additional, and/or alternative devices, which may include one or more of the devices described above with reference to Fig. 1.

In this example, eNB 120 may assist UE 110 with setting up an IMS emergency call regardless of the state of the UE 110. For example, UE 110 may have already completed an RRC Connection Setup procedure and selected a PLMN (indicated in the RRC Connection Setup Complete message) that does not support IMS emergency calls (e.g., PLMN of MME 130-1).

Alternatively, UE 110 may be operating without a SIM card or be roaming and therefore may not be associated with a PLMN of eNB 120. As such, the example of Fig. 7 may be applicable to UE 110 regardless of whether UE 110 is already connected to the network.

As shown, eNB 120 may perform SI Setup Procedures involving MME 130-1 and MME 130-3, and create a list of PLMNs that support IMS emergency calls. The operations for these procedures (at 710-750) are described above with respect to Fig. 6 (at 610-650). As such, when UE 1 10 may initiate an emergency call, UE 1 10 may do so by sending an Attach Request (that indicates "Emergency") to the PLMN to which UE 1 10 already camped (e.g., with which UE 1 10 already completed an attach procedure, which does not support IMS emergency calls).

Nevertheless, when eNB 120 receives the request, eNB 120 may determine that the request is for an emergency call and ensure that the request is sent to a PLMN that supports IMS emergency calls (at 770). For example, eNB 120 may dynamically compare the PLMN of the Attach Request with the PLMNs of the list of PLMNs previously created by eNB 120. When the PLMN of the Attach Request supports IMS emergency calls, eNB 120 may route the Attach Request without changing the PLMN in the Attach Request. When the PLMN of the Attach Request does not support IMS emergency calls, eNB 120 may determine (based on the list of PLMNs) a PLMN that supports IMS emergency calls (e.g., MME 130-3) and route the Attach Request to the PLMN from the list.

As mentioned above, the example of Fig. 7 may be applicable to a scenario in which UE 1 10 had previously completed an RRC Connection Setup procedure and selected a PLMN that did not support IMS emergency calls. As such, when UE 1 10 sends an Attach Request to eNB 120 for an IMS emergency call, eNB 120 may route the request to a PLMN that is different than the PLMN that UE 1 10 previously selected. As such, as the IMS emergency call is setup and/or the resulting IMS emergency call is ongoing, UE 110 may receive a message (e.g., an Attach Accept, message, Tracking Area Update (TAU) Accept message, etc.) corresponding to a PLMN (e.g., 130-3) that is different than the PLMN selected during the RRC Connection Setup procedure (e.g., 130-1). In such a scenario, UE 1 10 may consider the new PLMN (e.g., the PLMN of MME 130-3) as the PLMN for the emergency call and/or subsequent registration activities and messages (e.g., a subsequent Registration Accept message). For instance, UE 1 10 may not initiate a new or additional registration procedure with the new PLMN (e.g., the PLMN of MME 130-3).

, or otherwise respond to, consider the PLMN identified by eNB 120 (e.g., the PLMN of MME 130-3) for emergency calls as as the PLMN for

As used herein, the term "circuitry," "processing circuitry," or "logic" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some embodiments, the circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, circuitry may include logic, at least partially operable in hardware.

Embodiments described herein may be implemented into a system using any suitably configured hardware and/or software. Fig. 8 illustrates example components of a device 800 in accordance with some embodiments. In some embodiments, the device 800 may include application circuitry 802, baseband circuitry 804, Radio Frequency (RF) circuitry 806, front-end module (FEM) circuitry 808, one or more antennas 810, and power management circuitry (PMC) 812 coupled together at least as shown. The components of the illustrated device 800 may be included in a UE or a RAN node. In some embodiments, the device 800 may include less elements (e.g., a RAN node may not utilize application circuitry 802, and instead include a processor/controller to process IP data received from an EPC). In some embodiments, the device 800 may include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (I/O) interface. In other embodiments, the components described below may be included in more than one device (e.g., said circuitries may be separately included in more than one device for Cloud-RAN (C-RAN) implementations).

The application circuitry 802 may include one or more application processors. For example, the application circuitry 802 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with or may include memory/ storage and may be configured to execute instructions stored in the memory/ storage to enable various applications or operating systems to run on the device 800. In some embodiments, processors of application circuitry 802 may process IP data packets received from an EPC.

The baseband circuitry 804 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 804 may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 806 and to generate baseband signals for a transmit signal path of the RF circuitry 806. Baseband processing circuity 804 may interface with the application circuitry 802 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 806. For example, in some embodiments, the baseband circuitry 804 may include a third generation (3G) baseband processor 804 A, a fourth generation (4G) baseband processor 804B, a fifth generation (5G) baseband processor 804C, or other baseband processor(s) 804D for other existing generations, generations in development or to be developed in the future (e.g., second generation (2G), sixth generation (6G), etc.). The baseband circuitry 804 (e.g., one or more of baseband processors 804 A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 806. In other

embodiments, some or all of the functionality of baseband processors 804 A-D may be included in modules stored in the memory 804G and executed via a Central Processing Unit (CPU) 804E. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments,

modulation/demodulation circuitry of the baseband circuitry 804 may include Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 804 may include convolution, tail-biting convolution, turbo, Viterbi, or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

In some embodiments, the baseband circuitry 804 may include one or more audio digital signal processor(s) (DSP) 804F. The audio DSP(s) 804F may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry 804 and the application circuitry 802 may be implemented together such as, for example, on a system on a chip (SOC).

In some embodiments, the baseband circuitry 804 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 804 may support communication with an evolved universal terrestrial radio access network (EUTRAN) or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 804 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

RF circuitry 806 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 806 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 806 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 808 and provide baseband signals to the baseband circuitry 804. RF circuitry 806 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 804 and provide RF output signals to the FEM circuitry 808 for transmission.

In some embodiments, the receive signal path of the RF circuitry 806 may include mixer circuitry 806a, amplifier circuitry 806b and filter circuitry 806c. In some embodiments, the transmit signal path of the RF circuitry 806 may include filter circuitry 806c and mixer circuitry 806a. RF circuitry 806 may also include synthesizer circuitry 806d for synthesizing a frequency for use by the mixer circuitry 806a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 806a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 808 based on the synthesized frequency provided by synthesizer circuitry 806d. The amplifier circuitry 806b may be configured to amplify the down-converted signals and the filter circuitry 806c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down- converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry 804 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 806a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 806a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 806d to generate RF output signals for the FEM circuitry 808. The baseband signals may be provided by the baseband circuitry 804 and may be filtered by filter circuitry 806c. In some embodiments, the mixer circuitry 806a of the receive signal path and the mixer circuitry 806a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuitry 806a of the receive signal path and the mixer circuitry 806a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 806a of the receive signal path and the mixer circuitry 806a may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 806a of the receive signal path and the mixer circuitry 806a of the transmit signal path may be configured for super-heterodyne operation.

In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 806 may include analog-to-digital converter (ADC) and digital-to-analog converter (D AC) circuitry and the baseband circuitry 804 may include a digital baseband interface to communicate with the RF circuitry 806.

In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.

In some embodiments, the synthesizer circuitry 806d may be a fractional-N synthesizer or a fractional N/N+l synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 806d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

The synthesizer circuitry 806d may be configured to synthesize an output frequency for use by the mixer circuitry 806a of the RF circuitry 806 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 806d may be a fractional N/N+l synthesizer.

In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either the baseband circuitry 804 or the applications processor 802 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the applications processor 802.

Synthesizer circuitry 806d of the RF circuitry 806 may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DP A). In some embodiments, the DMD may be configured to divide the input signal by either N or N+l (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuitry 806d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some

embodiments, the RF circuitry 806 may include an IQ/polar converter.

FEM circuitry 808 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 810, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 806 for further processing. FEM circuitry 808 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 806 for transmission by one or more of the one or more antennas 810. In various embodiments, the amplification through the transmit or receive signal paths may be done solely in the RF circuitry 806, solely in the FEM 808, or in both the RF circuitry 806 and the FEM 808.

In some embodiments, the FEM circuitry 808 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include an LNA to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 806). The transmit signal path of the FEM circuitry 808 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 806), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 810).

In some embodiments, the PMC 812 may manage power provided to the baseband circuitry 804. In particular, the PMC 812 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMC 812 may often be included when the device 800 is capable of being powered by a battery, for example, when the device is included in a UE. The PMC 812 may increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.

While Fig. 8 shows the PMC 812 coupled only with the baseband circuitry 804.

However, in other embodiments, the PMC 812 may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry 802, RF circuitry 806, or FEM 808.

In some embodiments, the PMC 812 may control, or otherwise be part of, various power saving mechanisms of the device 800. For example, if the device 800 is in an RRC Connected state, where it is still connected to the RAN node as it expects to receive traffic shortly, then it may enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the device 800 may power down for brief intervals of time and thus save power.

If there is no data traffic activity for an extended period of time, then the device 800 may transition off to an RRC Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device 800 goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. The device 800 may not receive data in this state, in order to receive data, it must transition back to RRC Connected state.

An additional power saving mode may allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours). During this time, the device is totally unreachable to the network and may power down completely. Any data sent during this time incurs a large delay and it is assumed the delay is acceptable. Processors of the application circuitry 802 and processors of the baseband circuitry 804 may be used to execute elements of one or more instances of a protocol stack. For example, processors of the baseband circuitry 804, alone or in combination, may be used execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the application circuitry 804 may utilize data (e.g., packet data) received from these layers and further execute Layer 4 functionality (e.g., transmission communication protocol (TCP) and user datagram protocol (UDP) layers). As referred to herein, Layer 3 may comprise a radio resource control (RRC) layer, described in further detail below. As referred to herein, Layer 2 may comprise a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer, described in further detail below. As referred to herein, Layer 1 may comprise a physical (PHY) layer of a UE/RAN node, described in further detail below.

Fig. 9 illustrates example interfaces of baseband circuitry in accordance with some embodiments. As discussed above, the baseband circuitry 804 of Fig. 8 may comprise processors 804A-804E and a memory 804G utilized by said processors. Each of the processors 804A-804E may include a memory interface, respectively, to send/receive data to/from the memory 804G.

The baseband circuitry 804 may further include one or more interfaces to

communicatively couple to other circuitries/devices, such as a memory interface 912 (e.g., an interface to send/receive data to/from memory external to the baseband circuitry 804), an application circuitry interface 914 (e.g., an interface to send/receive data to/from the application circuitry 802 of Fig. 8), an RF circuitry interface 916 (e.g., an interface to send/receive data to/from RF circuitry 806 of Fig. 8), a wireless hardware connectivity interface 918 (e.g., an interface to send/receive data to/from Near Field Communication (NFC) components,

Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components), and a power management interface 920 (e.g., an interface to send/receive power or control signals to/from the PMC 812).

Fig. 10 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically, Fig. 10 shows a diagrammatic representation of hardware resources 1000 including one or more processors (or processor cores) 1010, one or more memory/storage devices 1020, and one or more communication resources 1030, each of which may be communicatively coupled via a bus 1040. For embodiments where node virtualization (e.g., FV) is utilized, a hypervisor 1002 may be executed to provide an execution environment for one or more network slices/ sub-slices to utilize the hardware resources 1000 The processors 1010 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) such as a baseband processor, an application specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor 1012 and a processor 1014.

The memory/storage devices 1020 may include main memory, disk storage, or any suitable combination thereof. The memory/storage devices 1020 may include, but are not limited to any type of volatile or non-volatile memory such as dynamic random access memory

(DRAM), static random-access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, solid-state storage, etc.

The communication resources 1030 may include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices 1004 or one or more databases 1006 via a network 1008. For example, the communication resources 1030 may include wired communication components (e.g., for coupling via a Universal Serial Bus (USB)), cellular communication components, NFC components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components.

Instructions 1050 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1010 to perform any one or more of the methodologies discussed herein. The instructions 1050 may reside, completely or partially, within at least one of the processors 1010 (e.g., within the processor's cache memory), the memory/ storage devices 1020, or any suitable combination thereof. Furthermore, any portion of the instructions 1050 may be transferred to the hardware resources 1000 from any combination of the peripheral devices 1004 or the databases 1006. Accordingly, the memory of processors 1010, the memory/storage devices 1020, the peripheral devices 1004, and the databases 1006 are examples of computer-readable and machine-readable media. A number of examples, relating to embodiments of the techniques described above, will next be given.

In a first example, a base station of a wireless telecommunication network may comprise a non-transitory computer-readable memory device storing processor-executable instructions; and one or more processors configured to execute the processor-executable instructions, wherein execution of the processor-executable instructions, by the one or more processors, causes the one or more processors to: obtain a plurality of network identifiers associated with a plurality of Public Land Mobile Network (PLMNs) in communication with the base station; obtain indications of whether each of the PLMNs, of the plurality of PLMNs, support a particular network service; and communicate, with User Equipment (UE) attached to the base station, an indication, based on the plurality of network identifiers and the obtained indications, of an ability of each PLMN, of the plurality of PLMNs, to support the particular network service.

In example 2, the subject matter of example 1, or any of the examples herein, wherein the particular network service includes Internet Protocol Multimedia Subsystem (IMS) emergency calls.

In example 3, the subject matter of example 1, or any of the examples herein, wherein the one or more processors is further to: receive a request to access the particular network service, the request including an identifier, of the plurality of identifiers, of a particular PLMN of the plurality of PLMNs.

In example 4, the subject matter of example 3, or any of the examples herein, wherein the one or more processors is further to: route the request to the particular PLMN.

In example 5, the subject matter of example 1, or any of the examples herein, wherein the indication includes a list of the plurality of network identifiers and a corresponding indicator of the plurality of indicators.

In a sixth example, a base station of a wireless telecommunication network may comprise a non-transitory computer-readable memory device storing processor-executable instructions; and one or more processors configured to execute the processor-executable instructions, wherein execution of the processor-executable instructions, by the one or more processors, causes the one or more processors to: determine an ability of each Public Land Mobile Network (PLMN), of a plurality PLMNs in communication with the base station, to support a particular network service; determine, based on the ability of each PLMN to support the particular network service, a relative priority of each PLMN to support the particular network service; create, based on the relative priority of each PLMN, an arrangement of network identifiers corresponding to the plurality of PLMNs, such that a network identifier associated with a PLMN of a highest priority occupies a position, within the arrangement, that is reserved for User Equipment (UEs) to select by default when requesting access to the network service; and communicate the arrangement of network identifiers to a UE.

In example 7, the subject matter of example 6, or any of the examples herein, wherein the network identifiers are arranged according to descending priority with respect to an order in which the UEs are configured to use the network identifiers to access the particular network service.

In example 8, the subject matter of example 6, or any of the examples herein, wherein the one or more processors is further to: receive a request to access the particular network service, the request including the network identifier associated with the PLMN of the highest priority.

In example 9, the subject matter of example 8, or any of the examples herein, wherein the one or more processors is further to: route the request to the PLMN of the highest priority.

In example 10, the base station of example 1 or 6, wherein the network identifier each correspond to a particular Mobility Management Entity (MME) of a particular PLMN network.

In example 11, the base station of example 1 or 6, wherein the one or more processors is further to: obtain the plurality of network identifiers and the plurality of indicators by communicating with a plurality of Mobility Management Entities (MMEs) corresponding to the plurality of PLMNs.

In a twelfth example, a User Equipment (UE) may comprise: a non-transitory computer- readable memory device storing processor-executable instructions; and one or more processors configured to execute the processor-executable instructions, wherein execution of the processor- executable instructions, by the one or more processors, causes the one or more processors to: receive a list of Public Land Mobile Networks Identifiers (PLMN IDs) corresponding to a wireless telecommunication network; store the list of PLMN IDs in a local memory; select, from the list of PLMN IDs, a PLMN ID corresponding to a PLMN that supports a particular network service; and use the selected PLMN ID to access the particular network service via the wireless telecommunication network. In example 13, the subject matter of example 12, or any of the examples herein, wherein the list of PLMN IDs include a prioritized list of PLMN IDs such that PLMN ID corresponding to PLMNs that support the particular network service are arranged toward a top of the list and PLMN IDs of PLMNs that do not support the particular network service are arranged toward a bottom of the list.

In example 14, the subject matter of example 13, or any of the examples herein, wherein the PLMN ID selected by the UE is located at the top of the list of PLMN IDs.

In example 15, the subject matter of example 12, or any of the examples herein, wherein: the list of PLMN IDs include indicators of which PLMN IDs, of the PLMN IDs, correspond to PLMNs that support the particular network service, and the processor is to select the PLMN ID based on the indicators.

In example 16, the subject matter of example 12, or any of the examples herein, wherein: the particular network service includes an IMS emergency call, and to initiate the IMS emergency call, the processor is to: include the PLMN ID in an Attach Request with a Request Type indicator of Emergency; and communicate the Attach Request to an enhanced Node B (eNB) of the wireless telecommunication network.

In example 17, the subject matter of example 12, or any of the examples herein, wherein the list of PLMN IDs are received as part of System Information Blocks (SIBs) transmitted by an enhanced Node B (eNB) of the wireless telecommunication network.

In an eighteenth example, a computer-readable medium may comprise program instructions for causing one or more processors, associated with an enhanced Node B (eNB), to: determine an ability of each Public Land Mobile Network (PLMN), of a plurality PLMNs in communication with the base station, to support a particular network service; determine, based on the ability of each PLMN to support the particular network service, a relative priority of each PLMN to support the particular network service; create, based on the relative priority of each PLMN, an arrangement of network identifiers corresponding to the plurality of PLMNs, such that a network identifier associated with a PLMN of a highest priority occupies a position, within the arrangement, that is reserved for User Equipment (UEs) to select by default when accessing the particular network service; and communicate the arrangement of network identifiers to a UE.

In example 19, the subject matter of example 18, or any of the examples herein, wherein the network identifiers are arranged according to descending priority with respect to an order in which the UEs are configured to use the network identifiers to access the particular network service.

In example 20, the subject matter of example 18, or any of the examples herein, wherein the one or more processors is further to: receive a request to access the particular network service, the request including the network identifier associated with the PLMN of the highest priority.

In example 21, the subject matter of example 20, or any of the examples herein, wherein the one or more processors is further to: route the request to the PLMN of the highest priority.

In example 22, the subject matter of example 18, or any of the examples herein, wherein the network identifier each correspond to a particular Mobility Management Entity (MME) of a particular PLMN network.

In example 23, the subject matter of example 18, or any of the examples herein, wherein the one or more processors is further to: obtain the plurality of network identifiers and the plurality of indicators by communicating with a plurality of Mobility Management Entities (MMEs) corresponding to the plurality of PLMNs.

In a twenty-fourth example, a method performed by an enhanced Node B (eNB) may comprise: determining, by the eNB, an ability of each Public Land Mobile Network (PLMN), of a plurality PLMNs in communication with the base station, to support a particular network service; determining, by the eNB and based on the ability of each PLMN to support the particular network service, a relative priority of each PLMN to support the particular network service; creating, by the eNB and based on the relative priority of each PLMN, an arrangement of network identifiers corresponding to the plurality of PLMNs, such that a network identifier associated with a PLMN of a highest priority occupies a position, within the arrangement, that is reserved for User Equipment (UEs) to select by default when accessing the particular network service; and communicating, by the eNB, the arrangement of network identifiers to a UE.

In example 25, the subject matter of example 24, or any of the examples herein, wherein the network identifiers are arranged according to descending priority with respect to an order in which the UEs are configured to use the network identifiers to access the particular network service. In example 26, the subject matter of example 24, or any of the examples herein, further comprising: receiving a request to access the particular network service, the request including the network identifier associated with the PLMN of the highest priority.

In example 27, the subject matter of example 26, or any of the examples herein, further comprising: routing the request to the PLMN of the highest priority.

In example 28, the subject matter of example 24, or any of the examples herein, wherein the network identifier each correspond to a particular Mobility Management Entity (MME) of a particular PLMN network.

In example 29, the subject matter of example 24, or any of the examples herein, further comprising: obtaining the plurality of network identifiers and the plurality of indicators by communicating with a plurality of Mobility Management Entities (MMEs) corresponding to the plurality of PLMNs.

In a thirtieth example, an enhanced Node B (eNB) of a wireless telecommunication network may comprise: means for determining an ability of each Public Land Mobile Network (PLMN), of a plurality PLMNs in communication with the base station, to support a particular network service; means for determining, based on the ability of each PLMN to support the particular network service, a relative priority of each PLMN to support the particular network service; means for creating, based on the relative priority of each PLMN, an arrangement of network identifiers corresponding to the plurality of PLMNs, such that a network identifier associated with a PLMN of a highest priority occupies a position, within the arrangement, that is reserved for User Equipment (UEs) to select by default when accessing the particular network service; and means for communicating the arrangement of network identifiers to a UE.

In example 31, the subject matter of example 30, or any of the examples herein, wherein the network identifiers are arranged according to descending priority with respect to an order in which the UEs are configured to use the network identifiers to access the particular network service.

In example 32, the subject matter of example 30, or any of the examples herein, further comprising: means for receiving a request to access the particular network service, the request including the network identifier associated with the PLMN of the highest priority.

In example 33, the subject matter of example 32, or any of the examples herein, further comprising: means for routing the request to the PLMN of the highest priority. In example 34, the subject matter of example 30, or any of the examples herein, wherein the network identifier each correspond to a particular Mobility Management Entity (MME) of a particular PLMN network.

In example 35, the subject matter of example 30, or any of the examples herein, further comprising: means for obtaining the plurality of network identifiers and the plurality of indicators by communicating with a plurality of Mobility Management Entities (MMEs) corresponding to the plurality of PLMNs.

In a thirty-sixth example, base station of a wireless telecommunication network, the base station may comprise: an interface to radio frequency (RF) circuitry; and one or more processors that are controlled to: obtain a plurality of network identifiers associated with a plurality of Public Land Mobile Network (PLMNs) in communication with the base station; obtain indications of whether each of the PLMNs, of the plurality of PLMNs, support a particular network service; and communicate, via the interface to the RF circuitry, with User Equipment (UE) attached to the base station, an indication, based on the plurality of network identifiers and the obtained indications, of an ability of each PLMN, of the plurality of PLMNs, to support the particular network service.

In example 37, the subject matter of example 36, or any of the examples herein, wherein the particular network service includes Internet Protocol Multimedia Subsystem (IMS) emergency calls.

In example 38, the subject matter of example 36, or any of the examples herein, wherein the one or more processors is further controlled to: receive a request to access the particular network service, the request including an identifier, of the plurality of identifiers, of a particular PLMN of the plurality of PLMNs.

In example 39, the subject matter of example 36, or any of the examples herein, wherein the one or more processors is further controlled to: route the request to the particular PLMN.

In example 40, the subject matter of example 36, or any of the examples herein, wherein the indication includes a list of the plurality of network identifiers and a corresponding indicator of the plurality of indicators.

In a forty-first example, a User Equipment (UE) of a wireless telecommunication network, may comprise: an interface to radio frequency (RF) circuitry; and one or more processors that are controlled to: receive, via the interface to the RF circuitry, a list of Public Land Mobile Networks Identifiers (PLMN IDs) corresponding to the wireless telecommunication network; store the list of PLMN IDs in a local memory; select, from the list of PLMN IDs, a PLMN ID corresponding to a PLMN that supports a particular network service; and use the selected PLMN ID to access, via the interface to the RF circuitry, the particular network service via the wireless telecommunication network.

In example 42, the subject matter of example 41, or any of the examples herein, wherein the list of PLMN IDs include a prioritized list of PLMN IDs such that PLMN ID corresponding to PLMNs that support the particular network service are arranged toward a top of the list and PLMN IDs of PLMNs that do not support the particular network service are arranged toward a bottom of the list.

In example 43, the subject matter of example 42, or any of the examples herein, wherein the PLMN ID selected by the UE is located at the top of the list of PLMN IDs.

In example 44, the subject matter of example 41, or any of the examples herein, wherein: the list of PLMN IDs include indicators of which PLMN IDs, of the PLMN IDs, correspond to PLMNs that support the particular network service, and the processor is further controlled to: select the PLMN ID based on the indicators.

In example 45, the subject matter of example 41, or any of the examples herein, wherein: the particular network service includes an IMS emergency call, and to initiate the IMS emergency call, the processor is controlled to: include the PLMN ID in an Attach Request with a Request Type indicator of Emergency; and communicate the Attach Request to an enhanced Node B (eNB) of the wireless telecommunication network.

In example 46, the subject matter of example 41, or any of the examples herein, wherein the list of PLMN IDs are received as part of System Information Blocks (SIBs) transmitted by an enhanced Node B (eNB) of the wireless telecommunication network.

In the preceding specification, various embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense. For example, while series of signals and/or operations have been described with regard to Figs. 2, 6 and 7 the order of the signals/operations may be modified in other implementations. Further, non-dependent signals may be performed in parallel.

It will be apparent that example aspects, as described above, may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement these aspects should not be construed as limiting. Thus, the operation and behavior of the aspects were described without reference to the specific software code— it being understood that software and control hardware could be designed to implement the aspects based on the description herein.

Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to be limiting. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification.

No element, act, or instruction used in the present application should be construed as critical or essential unless explicitly described as such. An instance of the use of the term "and," as used herein, does not necessarily preclude the interpretation that the phrase "and/or" was intended in that instance. Similarly, an instance of the use of the term "or," as used herein, does not necessarily preclude the interpretation that the phrase "and/or" was intended in that instance. Also, as used herein, the article "a" is intended to include one or more items, and may be used interchangeably with the phrase "one or more." Where only one item is intended, the terms "one," "single," "only," or similar language is used.

Claims

WHAT IS CLAIMED IS:

1. An apparatus of a base station, the apparatus comprising:

an interface to radio frequency (RF) circuitry; and

one or more processors to:

obtain a plurality of network identifiers associated with a plurality of Public Land Mobile Network (PLMNs) in communication with the base station;

obtain indications of whether each of the PLMNs, of the plurality of PLMNs, support a particular network service; and

communicate, via the interface to the RF circuitry, with User Equipment (UE) attached to the base station, an indication, based on the plurality of network identifiers and the obtained indications, of an ability of each PLMN, of the plurality of PLMNs, to support the particular network service.

2. The apparatus of claim 1, wherein the particular network service includes Internet Protocol Multimedia Subsystem (IMS) emergency calls.

3. The apparatus of claim 1, wherein the one or more processors is further to:

receive a request to access the particular network service, the request including an identifier, of the plurality of identifiers, of a particular PLMN of the plurality of PLMNs.

4. The apparatus of claim 3, wherein the one or more processors is further to:

route the request to the particular PLMN.

5. The apparatus of claim 1, wherein the indication includes a list of the plurality of network identifiers and a corresponding indicator of the plurality of indicators.

6. An apparatus of a User Equipment (UE), the apparatus comprising:

an interface to radio frequency (RF) circuitry; and

one or more processors that are to:

receive, via the interface to the RF circuitry, a list of Public Land Mobile Networks Identifiers (PLMN IDs) corresponding to a wireless telecommunication network; store the list of PLMN IDs in a local memory;

select, from the list of PLMN IDs, a PLMN ID corresponding to a PLMN that supports a particular network service; and

use the selected PLMN ID to access, via the interface to the RF circuitry, the particular network service via the wireless telecommunication network.

7. The apparatus of claim 6, wherein the list of PLMN IDs include a prioritized list of PLMN IDs such that PLMN ID corresponding to PLMNs that support the particular network service are arranged toward a top of the list and PLMN IDs of PLMNs that do not support the particular network service are arranged toward a bottom of the list.

8. The apparatus of claim 7, wherein the PLMN ID selected by the UE is located at the top of the list of PLMN IDs.

9. The apparatus of claim 6, wherein:

the list of PLMN IDs include indicators of which PLMN IDs, of the PLMN IDs, correspond to PLMNs that support the particular network service, and

the processor is further to:

select the PLMN ID based on the indicators.

The apparatus of claim 6, wherein:

the particular network service includes an IMS emergency call, and

to initiate the IMS emergency call, the processor are to:

include the PLMN ID in an Attach Request with a Request Type indicator of Emergency; and

communicate the Attach Request to an enhanced Node B (eNB) of the wireless telecommunication network.

11. The apparatus of claim 6, wherein the list of PLMN IDs are received as part of

Information Blocks (SIBs) transmitted by an enhanced Node B (eNB) of the wireless telecommunication network.

12. An apparatus of a base station, the apparatus comprising:

a non-transitory computer-readable memory device storing processor-executable instructions; and

one or more processors configured to execute the processor-executable instructions, wherein execution of the processor-executable instructions, by the one or more processors, causes the one or more processors to:

determine an ability of each Public Land Mobile Network (PLMN), of a plurality PLMNs in communication with the base station, to support a particular network service; determine, based on the ability of each PLMN to support the particular network service, a relative priority of each PLMN to support the particular network service;

create, based on the relative priority of each PLMN, an arrangement of network identifiers corresponding to the plurality of PLMNs, such that a network identifier associated with a PLMN of a highest priority occupies a position, within the arrangement, that is reserved for User Equipment (UEs) to select by default when requesting access to the network service; and

communicate the arrangement of network identifiers to a UE.

13. The apparatus of claim 12, wherein the network identifiers are arranged according to descending priority with respect to an order in which the UEs are configured to use the network identifiers to access the particular network service.

14. The apparatus of claim 12, wherein the one or more processors is further to:

receive a request to access the particular network service, the request including the network identifier associated with the PLMN of the highest priority.

15. The apparatus of claim 14, wherein the one or more processors is further to:

route the request to the PLMN of the highest priority.

16. An apparatus as in claims 1 or 12, wherein the network identifier each correspond to a particular Mobility Management Entity (MME) of a particular PLMN network.

17. An apparatus as in claims 1 or 12, wherein the one or more processors is further to:

obtain the plurality of network identifiers and the plurality of indicators by

communicating with a plurality of Mobility Management Entities (MMEs) corresponding to plurality of PLMNs.

18. A computer-readable medium containing program instructions for causing one or more processors, associated with an enhanced Node B (eNB), to:

determine an ability of each Public Land Mobile Network (PLMN), of a plurality PLMNs in communication with the base station, to support a particular network service;

determine, based on the ability of each PLMN to support the particular network service, a relative priority of each PLMN to support the particular network service;

create, based on the relative priority of each PLMN, an arrangement of network identifiers corresponding to the plurality of PLMNs, such that a network identifier associated with a PLMN of a highest priority occupies a position, within the arrangement, that is reserved for User Equipment (UEs) to select by default when accessing the particular network service; and

communicate the arrangement of network identifiers to a UE.

19. The computer-readable medium of claim 18, wherein the network identifiers are arranged according to descending priority with respect to an order in which the UEs are configured to use the network identifiers to access the particular network service.

20. The computer-readable medium of claim 18, wherein the one or more processors is further to:

21. The computer-readable medium of claim 20, wherein the one or more processors is further to:

route the request to the PLMN of the highest priority.

22. The computer-readable medium of claim 18, wherein the network identifier each correspond to a particular Mobility Management Entity (MME) of a particular PLMN network.

23. The computer-readable medium of claim 18, wherein the one or more processors is further to:

obtain the plurality of network identifiers and the plurality of indicators by

communicating with a plurality of Mobility Management Entities (MMEs) corresponding to the plurality of PLMNs.