BACKGROUND

Wireless telecommunication networks may include User Equipment (UE) (e.g., smartphones, tablet computers, laptop computers, etc.) Radio Access Networks (RANs) (that often include one or more base stations), and a core network. A UE may connect to the core network by communicating with a base station and registering with the core network. After a UE is connected to the network, the UE may be in a mode of operation referred to as a Radio Resource Control (RRC) connected state, where the base station has allocated certain resources (e.g., radio bearers) to the UE.

When the UE is less active with the network, the UE may enter a different state of operation. An example of such a state may include a RRC idle mode, where radio bears are no longer assigned to the UE. During RRC idle mode, the UE may remain registered with the core network, but the connection specifically between the base station and the UE may be terminated so that the base station may use those radio resources to another UE. Thus, while in RRC idle mode, the UE may be "known" to the core network, but not to the base station.

The UE may transition from RRC idle mode to RRC connected mode by reconnecting to a base station (the same base station or another base station) of the wireless telecommunication network. This may include performing an RRC connection setup procedure. The UE may initiate the procedure by sending a RRC Connection Request to the network. The base station may respond to the request by sending an RRC Connection Setup message to the UE, and the procedure may be completed by the UE sending a RRC Connection Setup Complete message back to the base station. By completing the RRC connection setup procedure, the UE may once again be assigned radio bearers for communicating with the base station.

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 determining whether a particular enhanced Node B (eNB) is a genuine eNB or a fake eNB;

Fig. 3 is an example of eNB verification information that may be obtained and stored by

User Equipment (UE);

Fig. 4 is an example of eNB verification information that may be maintained by a Mobility Management Entity (MME);

Fig. 5 is an example of provisioning a network to authenticate eNBs;

Fig. 6 is an example of determining whether an eNB is authentic;

Fig. 7 illustrates example components of a device in accordance with some embodiments;

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

Fig. 9 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 EMB ODFMENT S

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.

In a wireless telecommunication network, User Equipment (UE) (e.g., a smartphone, tablet computer, laptop computer, etc.) may connect to a core network via enhanced Node Bs (eNBs) of a Radio Access Network (RAN). After a UE is connected, the UE may be in a Radio Resource Control (RRC) connected mode. Later (e.g., when the UE is no longer communicating with the network) the UEs may enter a RRC idle mode, where the UE is still registered with the core network but the wireless connection between the eNB and the UE is terminated. The UE may transition from the RRC idle mode to the RRC connected mode by initiating an RRC connection setup procedure involving an eNB of the network. However, the RRC connection setup procedure may include certain vulnerabilities with respect to network security.

For example, the UE may be within a signal range of a wireless access point being operated by a third party (sometimes referred to as a "fake eNB"). The fake eNB may receive the RRC Connection Request from the UE and begin communicating with the UE in a manner that mimics an actual, genuine, or otherwise authentic eNB of the wireless telecommunication network. For example, the fake eNB may send an RRC Connection Setup message back to the UE with the specific intent of causing the UE to connect via a downgraded service (e.g., a 2nd Generation (2G) level of service instead of a Long-Term Evolution (LTE) or a 5th Generation (5G) level of service). As a result, the UE may complete the RRC connection setup procedure by connecting to the network via the downgraded service.

This may expose the UE to security vulnerabilities of the downgraded service (which may not exist in a superior service) in addition to exposing the UE to other types of attacks. For instance, the fake eNB may send the UE a redirect message (e.g., an RRC Connection Release message) that causes the UE to connect to a different core network (e.g., a Global System for Mobile Communications (GSM) network) that may be operated by the third party or otherwise compromised from a security perspective. In the examples discussed above, the fake eNB may sometimes be referred to as a "man-in-the-middle," and causing the UE to be transferred to a vulnerable or downgraded service may sometimes be referred to as a bidding down attack.

Some approaches to addressing fake eNBs have been proposed. In one approach, the UE may determine whether an eNB is genuine (i.e., authentic, not a fake eNB) by determining whether information is being wirelessly communicated in the Uplink (UL) direction. However, this proposal assumes that the UL traffic originates from other UEs. As such, a fake eNB may circumvent this approach by broadcasting phony UL traffic throughout the coverage area. The UE may detect the phony UL traffic, erroneously conclude that the fake eNB is genuine, and proceed to become a victim of a bidding down attack from the fake eNB.

The techniques described herein may enable a UE to detect fake eNBs and connect to genuine eNBs by verifying the authenticity of eNBs during cell selection and reselection. A UE may initially connect to a network by establishing a connection with an eNB and registering with the core network. In response, the network may assign a hash value to the UE and provide the UE with a copy of the hash value and a corresponding hash function. The UE may subsequently enter an RRC idle state, which may include the radio resources assigned to the UE being released (and possibly reassigned to another UE). However, the UE may remain registered with the core network, and the network (e.g., a Mobility

Management Entity (MME)) may track the location of the UE via UE-to-e B communications (in the Uplink (UL) direction) and/or Tracking Area (TA) procedures performed by the UE. For instance, when the UE initially registers with the core network, the MME may know the location of the UE based on the eNB through which the UE communicates with the core network and/or TA information received from the UE. Thereafter, the UE may periodically send updated TA information to the MME (e.g., according to a schedule) and/or when the UE enters a new TA. Each time the UE sends TA information to the MME, the UE and the MME may store copies of the TA information for later use. The TA information stored by the UE and the MME may be a historical list of TA identifiers corresponding to TAs that the UE has visited.

Later, the UE may detect an eNB selection event, which may include a prompt for the UE to select, and connect to, an eNB. The eNB selection event may include a transition from the RRC idle state to an RRC connected mode or a redirect message from the eNB. In response, the UE may send a request, to the eNB, for verification information regarding the eNB. The request may include a request for a hash function to be applied to some or all of the TA information the UE has been sending to the core network. The eNB may relay the request to an MME of the core network, and in accordance with the request, the MME may apply the same hash function (that was previously provided to the UE) to the TA information described in the request and the hash value previously provided to the UE.

The result of the hash function (sometimes referred to herein as a "TA hash") may be sent to the UE, and the UE may operate to verify whether the TA hash is authentic. For example, since the UE previously received a copy of the hash function and hash value, and has been storing local copies of the TA information sent to the MME, the UE may independently apply the hash function to the hash value and TA information. The UE may then compare the TA hash from the MME to the TA hash from the UE to verify whether the results match. When the results match, the UE may conclude that the eNB is genuine, authentic, etc., since a fake eNB would not be able to communicate with the MME and return an authentic TA hash. When the results do not match, the UE may conclude that the eNB is fake or otherwise untrustworthy and may not proceed with the eNB selection event (e.g., ignore the cell redirect message, select another eNB authenticate and connect to, etc.).

Fig. 1 illustrates an example environment 100 in which systems and/or methods described herein may be implemented. Environment 100 may include UEs 110 (referred to individually as UE 110 and collectively as UEs 110), a wireless telecommunication network, and an external network. The wireless telecommunications network may be, or may include, radio access networks (RANs) that include one or more base stations, some or all of which may take the form of enhanced NodeBs (eNBs) 120 (referred to individually as eNB 120 and collectively as eNBs 120) via which UEs 110 may communicate with the EPC network.

The EPC network may include Serving Gateway (SGW) 130, PDN Gateway (PGW) 140, Mobility Management Entity (MME) 150, Home Subscriber Server (HSS) 160, Policy and Charging Rules Function (PCRF) 170. As shown, the EPC network may enable UEs 110 to communicate with an external network, such as a Public Land Mobile Networks (PLMN), a Public Switched Telephone Network (PSTN), and/or an Internet Protocol (IP) network (e.g., the Internet). Environment 100 may also include one or more fake eNBs 180 that may be connected to one or more alternative core networks.

The quantity of devices and/or networks, illustrated in Fig. 1, is provided for explanatory purposes only. In practice, environment 100 may include 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, while not shown, environment 100 may include devices that facilitate or enable communication between various components shown in environment 100, such as routers, modems, gateways, switches, hubs, etc.

Alternatively, or additionally, one or more of the devices of environment 100 may perform one or more functions described as being performed by another one or more of the devices of environment 100. Additionally, the devices of environment 100 may interconnect with each other and/or other devices via wired connections, wireless connections, or a combination of wired and wireless connections. In some embodiments, one or more devices of environment 100 may be physically integrated in, and/or may be physically attached to, one or more other devices of environment 100. Also, while "direct" connections may be shown between certain devices in Fig. 1, some of said devices may, in practice, communicate with each other via one or more additional devices and/or networks.

UE 110 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 110 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 110 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.

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 the EPC. eNB 120 may be capable of participating in an RRC setup procedure to enable UE 110 to establish a connection with eNB 120 and register with the EPC. Processes and operations described herein as being performed by, or otherwise involving eNB 120, may also or alternatively be performed by (or otherwise involve) one or more other types of access nodes, which may include base stations (BSs),

NodeBs, next Generation NodeBs (gNBs), RAN nodes, and so forth, and may comprise ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell).

SGW 130 may aggregate traffic received from one or more eNBs 120 and may send the aggregated traffic to an external network or device via PGW 140. SGW 130 may aggregate traffic received from one or more PGWs 140 and send the aggregated traffic to one or more eNBs 120. SGW 130 may operate as an anchor for the user plane during inter-eNB handovers and as an anchor for mobility between different telecommunication networks. PGW 140 may include one or more network devices that aggregate traffic received from one or more SGWs 130 and send the aggregated traffic to an external network. PGW 140 may also, or alternatively, receive traffic from the external network and may send the traffic toward UE 110 (via SGW 130 and/or eNB 120).

MME 150 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 150 may perform operations to register UE 110 with the wireless telecommunications network, to establish bearer channels (e.g., traffic flows) associated with a session with UE 110, to hand off UE 110 to a different eNB, MME, or another network, and/or to perform other operations. MME 150 may perform policing operations on traffic destined for and/or received from UE 110.

HSS 160 may include one or more devices that may manage, update, and/or store, in a memory associated with HSS 160, profile information associated with a subscriber (e.g., a subscriber associated with UE 110). The profile information may identify applications and/or services that are permitted for and/or accessible by the subscriber; a Mobile Directory Number (MDN) associated with the subscriber; bandwidth or data rate thresholds associated with the applications and/or services; and/or other information. The subscriber may be associated with UE 110. Additionally, or alternatively, HSS 160 may perform authentication, authorization, and/or accounting operations associated with the subscriber and/or a communication session with UE 110.

PCRF 170 may receive information regarding policies and/or subscriptions from one or more sources, such as subscriber databases and/or from one or more users. PCRF 170 may provide these policies to PGW 140 or another device so that the policies can be enforced. As depicted, in some embodiments, PCRF 170 may communicate with PGW 140 to ensure that charging policies are properly applied to locally routed sessions within the telecommunications network.

Fake eNB 180 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). Fake eNB 180 may include a wireless access point (e.g., an eNB, micro cell device, wireless router, etc.) that is owned and/or operated by a third party (i.e., an organization other than the service provider of the wireless telecommunication network). Fake eNB 180 may be capable of mimicking one or more functions of eNB 120, such as a RRC connection setup procedure. Fake eNB 180 may also, or alternatively, be capable of performing bidding down attacks that may cause UEs 110 to communicate with the wireless telecommunication network via a downgraded service (e.g., 2G service) instead of an LTE or 5G level of service. Additionally, or alternatively, fake eNB 180 may cause UEs 110 to be redirected to another core network, such as the alternative core network (which may be a 2G or GSM network). Fake eNB 180 may use RRC connection setup procedures (e.g., when UE 110 is transitioning from RRC idle mode to RRC connected mode) to perform bidding down attacks and or cause UEs 110 to be redirected to the alternative core network.

Fig. 2 is a flowchart of an example process 200 for determining whether a particular eNB 120 is a genuine eNB or a fake eNB. Process 200 may be implemented by UE 110. Fig. 2 is described below with reference to Figs. 3 and 4.

Process 200 may include monitoring, while in RRC idle mode, a current TA of UE 110 and communicating TA information to MME 150 (block 210). TA information, as described herein, may include information identifying a geographic location or area, such as a TA of the wireless telecommunication network, a coverage area of a particular eNB, a geographic location where coverage areas from multiple eNBs overlap, etc. In some embodiments, TA information may include a Tracking Area Identifier (TAI), which may consist of correspond to a Public Land Mobile Networks (PLMN) and a Tracking Area Code (TAC). In some embodiments, TA information may include a TAI, PLMN, TAC, and/or another form of information identifying a geographic location or area. For example, UE 110 may initially connect to a wireless

telecommunication network by performing an RRC connection setup procedure with a particular eNB 120 of the network. The RRC connection setup procedure may include eNB 120 allocating wireless resources (e.g., Access Spectrum (AS) resource) to be allocated to UE 110, such that UE 110 and eNB 120 may use to communicate with one another. After the RRC connection setup procedure, UE 110 may be an RRC connected mode and may be registered with the EPC of eNB 120.

At some point thereafter, UE 110 may transition to an RRC idle mode, which may include a release of the wireless resources (e.g., radio bearers) allocated to UE 110. While in the RRC idle mode, UE 110 may remain registered with the EPC but eNB 120 may be unaware of UE 110. Additionally, UE 110 may periodically perform a TA procedure, whereby UE 110 may determine one or more eNBs 120, of the wireless telecommunication, that UE 110 is capable of communicating with. The eNBs 120 of the TA update procedure may change over time since UE 110 may perform TA update procedures as UE 110 move about the coverage area of the network. UE 110 may maintain a local record of TA information and communicate TA information to MME 150. The TA information stored by the UE and the MME may be a historical list of TA identifiers corresponding to TAs that the UE has visited.

The TA information may include the one or more e Bs 120 that UE 110 is able to communicate with at the location where UE 110 performs the TA procedure. The TA

information may also include, and/or be obtained in combination with, a time at which the TA information was collected by UE 110. Additionally, or alternative, as UE 110 may collect multiple sets of TA information over a period of time, UE 110 may associate each set of TA information with a time at which the TA information was collected by UE 110 and/or chronological identifier (e.g., 1, 2, 3, etc., or first, second, third, etc.) that defines a chronology with which the sets of TA information were collected. Additionally, while UE 110 may obtain TA information and report the TA information to MME 150 on a periodic basis (e.g., in accordance with preselected timer, schedule, etc.) UE 110 may also, or alternatively, obtain TA information, store a copy of the TA information locally, and send another copy of the TA information to MME 150 each time UE 110 moves to a different TA.

Fig. 3 is an example of e B verification information that may be obtained and stored by UE 110. The information (and arrangement thereof) of Fig. 3 is provided as a non-limiting example. In practice, UE 110 150 may maintain less, additional, and/or alternative information that shown in Fig. 3. Additionally, the information stored by UE 110 may be arranged in distinct ways, which may include distinct types of data structures and storage techniques.

As shown, the eNB verification information maintained by UE 110 may include records of TA information obtained by UE 110 over a period of time and/or a key or has value. Each record of TA information may include TA information (TAl, TA2, etc.) obtained by UE 110 and a time or chronological indicator (e.g., Tl ... Tn) indicating the time or order in which each set of TA information was obtained. In some embodiments, the number of records of TA information stored by UE 110 may be limited or otherwise restricted (e.g., to a particular quantity, storage duration, so long as UE 110 remains registered with the EPC, etc.) so that, for example, UE 110 may not maintain an overabundance, unnecessary, or otherwise undesirable quantity of TA information.

The hash value may include a sequence or string of information that UE 1 10 may later use (in combination with TA information) to verify whether a particular eNB 120 is fake or genuine. In some embodiments, UE 110 may receive, from the wireless telecommunication network (e.g., eNB 120, MME 150, and/or HSS 160), the hash value as part or as a result of initially connecting to the wireless telecommunication network. In some embodiments, the wireless telecommunication network (e.g., eNB 120, MME 150, and/or HSS 160) may update (e.g., change) and distribute the hash value to UEs 110 connected to the network. In some embodiments, the wireless telecommunication network (e.g., eNB 120, MME 150, and/or HSS 160) may dynamically determine and distribute hash values to UEs 110 such that the hash value for each UE 110 or different groups of UEs 110 may be assigned a unique hash value. In some embodiments, UE 110 may also, or alternatively, maintain other types of information, such as information identifying a particular hash function that UE 110 may later use to verify whether a particular eNB 120 is authentic. In some embodiments, UE 110 may negotiate with the network to receive or identify a hash function to use for authenticating eNBs. In some embodiments, UE 110 may receive multiple hash functions from the network and subsequently receive an indication of which hash function to use at a particular time, for a particular eNB authentication, etc. For example, UE 110 may store local copies of distinct hash functions that may be applied to authenticating an eNB, and UE 110 may receive, from eNB 120, MME 150, etc., (e.g., along with the hash value) an indication of which hash function is to be applied to the authentication of a particular eNB 120.

Returning to Fig. 2, process 200 may also include detecting an eNB selection event (block 220). For example, UE 110 may detect a message, operation, procedure, etc., that involves or prompts UE 110 to select or otherwise connect to eNB 120. An eNB selection event may be, or be part of, UE 110 performing an RRC connection setup procedure whereby UE 110 is to select and/or establish a connection with eNB 120 (e.g., transitioning from a RRC idle mode to a RRC connected mode). Additionally, or alternatively, an eNB selection event may include UE 110 receiving a redirect message (e.g., from eNB 120, fake eNB 180, etc.) prompting UE

110 to connect to another access point (e.g., eNB 120, fake eNB 180, etc.). The redirect message may be received during the RRC connection setup procedure. In some embodiments, an eNB selection event may include another type of operation or procedure that involves UE 110 selecting (e.g., establishing a connection with) an access point of the wireless telecommunication network. Process 200 may also include requesting, from MME 150 and based on the TA of UE 110, verification of eNB 120 of the selection event (block 230). For example, in response to detecting the eNB selection event, UE 110 may communicate a request, to MME 150, for information that UE 110 may use to verify whether a particular eNB 120 is genuine. The request may include information identifying UE 110 (e.g., a telephone number, International Mobile Subscriber Identity (FMSI), etc.), a request for MME 150 to perform a hash function, and information identifying one or more types of information upon which the hash function is to be performed. Examples of such information may include information identifying one or more TA records corresponding to UE 110 (e.g., the most recent TA record, a TA record associated with a particular time, a set of TA records (e.g., the last X number of TA records, TA records corresponding to an interval of time (also referred to herein as an interval parameter) (e.g., the last 30 minutes), etc.)). A TA record, as described herein, may sometimes be referred to as a "set of TA information. "

In some embodiments, UE 110 may provide additional, or alternative, information, such as information identifying a particular hash function and/or value (e.g., a unique identifier associated with a particular hash function and/or value, a timestamp associated with a particular hash function and/or value (e.g., a time when the hash function or value was created by MME 150, communicated to and/or UE 110) etc.). In some embodiments, since UE 110 may communicate the request while UE 110 is in RRC idle mode and, therefore, does not have an RRC connection to eNB 120, UE 110 may send the request to MME 150 via a Common Control Network Function (CCNF) where a Non- Access Stratum (NAS) context of UE 110 may be held. In response to the request, MME 150 may perform the hash function using the information indicated by UE 110 and may return the result of the hash function to UE 110.

Fig. 4 is an example of eNB verification information that may be maintained by MME 150. The information (and arrangement thereof) of Fig. 4 is provided as a non-limiting example. In practice, MME 150 may maintain less, additional, and/or alternative information that shown in Fig. 4. Additionally, the information stored by MME 150 may be arranged in distinct ways, which may include distinct types of data structures and storage techniques.

As shown, the eNB verification information maintained by MME 150 may include records of TA information associated with different UEs 110 and/or a key or has value for each UE 110. Each record of TA information may include TA information (TAl, TA2, etc.) obtained from the corresponding UE 110 and a time or chronological indicator (e.g., Tl ... Tn) indicating the time or order in which each set of TA information was obtained by UE 110. As shown, the number of TA records associated with each UE 110 may vary (e.g., Tax, TAy, etc.). In some embodiments, the number of records of TA information stored by MME 150 may be limited (e.g., to a particular quantity, storage duration, so long as the UE remains registered with the network, etc.) so that, for example, the techniques described herein do not cause MME to maintain an overabundance, unnecessary, or otherwise undesirable quantity of TA information.

Additionally, the hash value associated with each UE 110 may vary (e.g., 76as76... , 786sdgf7... , etc.) such that each UE 110 or group of UEs 110 (e.g., UEs 110 that receive a hash value at a particular time or within a period of time) may have a unique hash value. The hash values stored by MME 110 may include a sequence or string of information that MME 150 may later use (in combination with TA information) to apply to a hash function, the result of which may be sent to UE 110 for verifying whether a particular e B 120 is genuine. In some embodiments, MME 150 may determine, assign, and provide the hash value to each UE 110 after (or as part of) UE 110 initially registering with the network. In some embodiments, MME 150 may periodically update (e.g., change) and distribute hash values to UEs 110. In some embodiments, MME 150 may also, or alternatively, maintain other types of information, such as information identifying a particular hash function associated with each UE 110.

Returning to Fig. 2, process 200 may also include receiving, from MME 150, verification information for eNB 120 (block 240). For instance, in response to sending MME 150 the request for verification information, UE 110 may receive information that UE 110 may use to determine whether eNB 120 is a genuine eNB 120 or a fake eNB 180. The verification information, as described herein, may be the product of MME 150 applying TA information and a hash key to a preselected hash function (a copy which UE 110 may have received as part, or as a result, of initially registering with the network.

Process 200 may also include determining, based on the verification information from MME 150, whether eNB 120 is a genuine eNB or a fake eNB (block 250). For instance, since UE 110 may have a copy of the TA information, hash value, and hash function that MME 150 used to generate the verification information, UE 110 may independently calculate verification information by applying the same TA information and hash value to the hash function. As such, UE 110 may have two sets of verifications information— one set received from MME 150 and the other set produced independently by UE 110. Thus, UE 110 may determine whether eNB 120 is genuine by comparing the two sets of verification information to one another. If the verification information matches, UE 110 may determine that eNB 120 is a genuine eNB since a fake eNB would not have access to MME 150 and thus could not return verification information that matches the verification information independently produced by UE 110. So, even if fake eNB 180 attempts to fool UE 110 by providing some type of verification information, the verification information provided by fake eNB 180 would not be a match since fake eNB 180 would not have copies of the hash function, hash value, and/or TA information.

When UE 110 determines that eNB 120 is fake (block 260 - No) process 200 may include terminating the eNB selection procedure (block 270). The eNB selection procedure may be part of a transition, of UE 110, from RRC idle mode to RRC connected mode, a cell redirect procedure, etc.; however, when UE 110 determines that the eNB 120 with which UE 110 is communicating is not authentic or genuine, UE 110 may terminate or otherwise ignore the procedure, thereby avoiding a "man-in-the-middle" attack, bidding down attack, etc. When UE 110 determines that eNB 120 is genuine (block 260 - Yes), process 200 may include proceeding with the eNB selection procedure (block 280). For instance, whether the eNB selection procedure is part of a transition, of UE 110, from RRC idle mode to RRC connected mode, a cell redirect procedure, etc., when UE 110 determines that the eNB 120 with which UE 110 is communicating is authentic or genuine, UE 110 may proceed with the procedure since the procedure is not part a "man-in-the-middle" attack, bidding down attack, etc.

Fig. 5 is an example of provisioning a network to authenticate eNBs. As shown, the example of Fig. 5 may include UE 110, eNB 120, and MME 150. The example of Fig. 5 is provided as a non -limiting example. In practice, the example of Fig. 5 may include fewer, additional, alternative, operations or functions. Additionally, one or more of the operations or functions of Fig. 5 may be performed by fewer, additional, or alternative devices, which may include one or more of the devices described above with reference to Fig. 1.

As shown, UE 110 may initially connect to a wireless telecommunication network by connecting to eNB 150 (via an RRC connect procedure) and registering with the core network (e.g., MME 150) (at 505). During or subsequent to the initial connection procedure, UE 110 may send a request to MME 150 for a hash function and/or hash value designated for eNB verification (at 510), and MME 150 may respond accordingly (at 515). In some embodiments, MME 150 may automatically send the hash function and/or hash value to UE 505, instead of waiting for a response from UE 505 before doing so.

Assume that at some point UE 110 transitions from an RRC connected state to an RRC idle state (at 520). As such, eNB 150 may release the radio resources used to communicate with UE 110 (at 525) but UE 110 remains registered with MME 150 (at 530). While in the RRC idle state, UE 110 may perform one or more TAU procedures (at 535) and provide TA information resulting from the TAU procedures to MME 150 (at 540). Copies of the TA information may be stored by both UE 110 and MME 150 for later use (at 545 and 550).

Fig. 6 is an example of determining whether an eNB is authentic. As shown, the example of Fig. 6 may include UE 110, eNB 120, and MME 150. The example of Fig. 5 is provided as a non-limiting example. In practice, the example of Fig. 5 may include fewer, additional, alternative, operations or functions. Additionally, one or more of the operations or functions of Fig. 5 may be performed by fewer, additional, or alternative devices, which may include one or more of the devices described above with reference to Fig. 1. For purposes of explaining Fig. 6, assume that UE 110 and MME 150 have each been storing TA information corresponding to UE 110 (as described above with reference to Fig. 5).

As shown, UE 110 may detect an eNB selection event (at 610). As described herein, the eNB selection event may be part of UE 110 transitioning from an RRC idle mode to RRC connected mode, a response to receiving a redirect message from an eNB (e.g., eNB 120 or fake eNB 180), or another scenario in which UE 110 is to select a new or different eNB. In response, UE 110 may communicate a request (e.g., a Verify-Request message) to eNB 120 (at 620). The request may include information (e.g., UE-dT) describing TA information that MME 150 should apply to the hash function for the purpose of generating eNB verification information. As described herein, the TA information specified by UE 110 (i.e., UE-dT) may be the most recent TA record from UE 110, a TA record associated with a specific timestamp, a set of TA records (e.g., the last X number of TA records, TA records corresponding to an interval of time (also referred to herein as an interval parameter) (e.g., the last 30 minutes), etc.)). For instance, UE- dT may represent TA information generated over a period of time (dT) and associated with a particular UE 110. The request from UE 110 may also, or alternatively, include an identifier of UE 110, a particular hash value, an identifier of a particular hash function, etc. eNB 120 may respond to the request by sending a message (e.g., a GET message) to MME 150 regarding the hash information requested by UE 110 (at 630). In some embodiments, the message from eNB 120 may include the TA information (UE-dT) from UE 110. The message may also, or alternatively, include an identifier of UE 110, a hash value provided by UE 110, an identifier of a particular hash function, etc.

MME 150 may respond to the message from eNB 120 by generating eNB verification information in accordance with the message. For example, MME 150 may identify local copies of TA information indicated in the message, determine a specific hash value associated with UE 110, and apply a hash function the TA information and the hash value in order to produce eNB verification information (also referred to herein as a "TA hash "). MME 150 may provide the TA hash to eNB 120 (at 640), and eNB 120 may provide to the TA hash to UE 110 (at 650). To do so, eNB 120 may include the hash result in a Verify- Accept message.

UE 110 may respond to the TA hash information from MME 150 may verifying the authenticity of the TA hash information (at 660). For example, as described above, UE 110 may independently perform a hash function based on the same inputs (e.g., the same hash value and TA information) as MME 150 and then comparing the results of both hash functions to one another. When the results do not match and/or when eNB 120 fails respond appropriately to the Verif -Request message from UE 110, UE 110 may conclude that the eNB is fake, or otherwise untrustworthy, and terminate or ignore the eNB selection event. When the results match each other, UE 110 may conclude that eNB 120 is a genuine eNB of the wireless telecommunication network and may proceed in accordance with the eNB selection event (e.g., an RRC connection procedure, a cell redirect procedure, etc.) (at 670).

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. 7 illustrates example components of a device 700 in accordance with some embodiments. In some embodiments, the device 700 may include application circuitry 702, baseband circuitry 704, Radio Frequency (RF) circuitry 706, front-end module (FEM) circuitry 708, one or more antennas 710, and power management circuitry (PMC) 712 coupled together at least as shown. The components of the illustrated device 700 may be included in a UE or a RAN node. In some embodiments, the device 700 may include less elements (e.g., a RAN node may not utilize application circuitry 702, and instead include a processor/controller to process IP data received from an EPC). In some embodiments, the device 700 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 702 may include one or more application processors. For example, the application circuitry 702 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 700. In some embodiments, processors of application circuitry 702 may process IP data packets received from an EPC.

The baseband circuitry 704 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 704 may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 706 and to generate baseband signals for a transmit signal path of the RF circuitry 706. Baseband processing circuity 704 may interface with the application circuitry 702 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 706. For example, in some embodiments, the baseband circuitry 704 may include a third generation (3G) baseband processor 704A, a fourth generation (4G) baseband processor 704B, a fifth generation (5G) baseband processor 704C, or other baseband processor(s) 704D 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 704 (e.g., one or more of baseband processors 704A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 706. In other

embodiments, some or all of the functionality of baseband processors 704A-D may be included in modules stored in the memory 704G and executed via a Central Processing Unit (CPU) 704E. 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 704 may include Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 704 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 704 may include one or more audio digital signal processor(s) (DSP) 704F. The audio DSP(s) 704F 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 704 and the application circuitry 702 may be implemented together such as, for example, on a system on a chip (SOC).

In some embodiments, the baseband circuitry 704 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 704 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 704 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

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

In some embodiments, the receive signal path of the RF circuitry 706 may include mixer circuitry 706a, amplifier circuitry 706b and filter circuitry 706c. In some embodiments, the transmit signal path of the RF circuitry 706 may include filter circuitry 706c and mixer circuitry 706a. RF circuitry 706 may also include synthesizer circuitry 706d for synthesizing a frequency for use by the mixer circuitry 706a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 706a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 708 based on the synthesized frequency provided by synthesizer circuitry 706d. The amplifier circuitry 706b may be configured to amplify the down-converted signals and the filter circuitry 706c 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 704 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 706a 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 706a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 706d to generate RF output signals for the FEM circuitry 708. The baseband signals may be provided by the baseband circuitry 704 and may be filtered by filter circuitry 706c.

In some embodiments, the mixer circuitry 706a of the receive signal path and the mixer circuitry 706a 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 706a of the receive signal path and the mixer circuitry 706a 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 706a of the receive signal path and the mixer circuitry 706a may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 706a of the receive signal path and the mixer circuitry 706a 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 706 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 704 may include a digital baseband interface to communicate with the RF circuitry 706.

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 706d 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 706d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

The synthesizer circuitry 706d may be configured to synthesize an output frequency for use by the mixer circuitry 706a of the RF circuitry 706 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 706d 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 704 or the applications processor 702 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 702.

Synthesizer circuitry 706d of the RF circuitry 706 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 706d 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 706 may include an IQ/polar converter.

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

In some embodiments, the FEM circuitry 708 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 706). The transmit signal path of the FEM circuitry 708 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 706), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 710). In some embodiments, the PMC 712 may manage power provided to the baseband circuitry 704. In particular, the PMC 712 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMC 712 may often be included when the device 700 is capable of being powered by a battery, for example, when the device is included in a UE. The PMC 712 may increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.

While Fig. 7 shows the PMC 712 coupled only with the baseband circuitry 704.

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

In some embodiments, the PMC 712 may control, or otherwise be part of, various power saving mechanisms of the device 700. For example, if the device 700 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 700 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 700 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 700 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 700 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 702 and processors of the baseband circuitry 704 may be used to execute elements of one or more instances of a protocol stack. For example, processors of the baseband circuitry 704, alone or in combination, may be used execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the application circuitry 704 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. 8 illustrates example interfaces of baseband circuitry in accordance with some embodiments. As discussed above, the baseband circuitry 704 of Fig. 7 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 812 (e.g., an interface to send/receive data to/from memory external to the baseband circuitry 704), an application circuitry interface 814 (e.g., an interface to send/receive data to/from the application circuitry 702 of Fig. 7), an RF circuitry interface 816 (e.g., an interface to send/receive data to/from RF circuitry 706 of Fig. 7), a wireless hardware connectivity interface 818 (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 820 (e.g., an interface to send/receive power or control signals to/from the PMC 712).

Fig. 9 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. 9 shows a diagrammatic representation of hardware resources 900 including one or more processors (or processor cores) 910, one or more memory/storage devices 920, and one or more communication resources 930, each of which may be communicatively coupled via a bus 940. For embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor 902 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 900 The processors 910 (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 912 and a processor 914.

The memory/storage devices 920 may include main memory, disk storage, or any suitable combination thereof. The memory/storage devices 920 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 930 may include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices 904 or one or more databases 906 via a network 908. For example, the communication resources 930 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 950 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 910 to perform any one or more of the methodologies discussed herein. The instructions 950 may reside, completely or partially, within at least one of the processors 910 (e.g., within the processor's cache memory), the memory/storage devices 920, or any suitable combination thereof. Furthermore, any portion of the instructions 950 may be transferred to the hardware resources 900 from any combination of the peripheral devices 904 or the databases 906. Accordingly, the memory of processors 910, the memory/storage devices 920, the peripheral devices 904, and the databases 906 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 baseband apparatus for a User Equipment (UE) device may comprise: a radio frequency (RF) interface to RF circuitry; and one or more processors to: transmit, via the RF interface and to an enhanced Node B (eNB), a message requesting verification that the eNB is an authentic eNB; receive, in response to the message, a first value from the eNB; calculate a second value based on a plurality of Tracking Area (TA) identifiers that were previously associated with the UE; and authenticate the eNB when the first value matches the second value.

In example 2, the subject matter of example 1, or any of the examples herein, wherein the second value is determined based on a hash of the plurality of TA identifiers.

In example 3, the subject matter of example 1, or any of the examples herein, wherein the TA identifiers are obtained while the UE is in a Radio Resource Control (RRC) idle state.

In a fourth example, an enhanced Node B (eNB) 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: receive, from a User Equipment (UE) registered with the wireless telecommunication network, a first message requesting verification that the eNB is an authentic eNB; communicate, in response to receiving the first message, a second message, to a Mobility Management Entity (MME) of the wireless telecommunication network, requesting information for authenticating the eNB; receive, in response to the second message and from the MME, the information being based on a plurality of Tracking Area (TA) identifiers that were previously associated with the UE; and relay the information to the UE.

In example 5, the subject matter of example 4, or any of the examples herein, wherein the second value is determined based on a hash of the plurality of TA identifiers.

In example 6, the subject matter of example 4, or any of the examples herein, wherein the TA identifiers correspond to the UE being in a Radio Resource Control (RRC) idle state.

In example 7, the subject matter of examples 1 or 4, or any of the examples herein, wherein the message includes an interval parameter corresponding to an amount of TA identifiers that are to be used to calculate the second value.

In example 8, the subject matter of example 7, or any of the examples herein, wherein the plurality of TA identifiers corresponds to a historical list of TA identifiers to which the UE was associated. In example 9, the subject matter of example 4, or any of the examples herein, wherein the interval parameter is selected, by the UE, such that at least some of the TA identifiers, to which the UE has connected, are not known by the eNB.

In a tenth example, a computer-readable medium containing program instructions for causing one or more processors, associated with a User Equipment (UE), to: cause a message to be transmitted, to an enhanced Node B (eNB), requesting verification that the eNB is an authentic eNB; receive, in response to the message, a first value from the eNB; calculate a second value based on a plurality of Tracking Area (TA) identifiers that were previously associated with the UE; and authenticate the eNB when the first value matches the second value.

In example 11, the subject matter of example 10, or any of the examples herein, wherein the second value is determined based on a hash of the plurality of TA identifiers.

In example 12, the subject matter of example 10, or any of the examples herein, wherein the TA identifiers are obtained while the UE is in a Radio Resource Control (RRC) idle state.

In example 13, the subject matter of example 10, or any of the examples herein, wherein the message includes an interval parameter corresponding to an amount of TA identifiers that are to be used to calculate the second value.

In example 14, the subject matter of example 13, or any of the examples herein, wherein the plurality of TA identifiers corresponds to a historical list of TA identifiers to which the UE was associated.

In example 15, the subject matter of example 13, or any of the examples herein, wherein the interval parameter is selected, by the UE, such that at least some of the TA identifiers, to which the UE has connected, are not known by the eNB.

In a sixteenth example, a computer-readable medium containing program instructions for causing one or more processors, associated with a User Equipment (UE), to: register with a core network of a wireless telecommunication network; receive an indication of a hash function to use to authenticate enhanced Node Bs (eNBs) of the wireless telecommunication network; obtain Tracking Area (TA) information associated with the UE being located in a geographic area; store a first copy of the TA information locally; communicate a second copy of the TA information to the core network; detect a prompt to establish a connection with an eNB; communicate, to the eNB, a request for authentication information regarding the eNB; receive, in response to the request, a first set of authentication information; determine a second set of authentication information based on the hash function and the first copy of the TA information; when the first set of authentication information matches the second set of authentication information, establish a connection with the eNB, and when the first set of authentication information does not match the second set of authentication information, ignore the prompt.

In example 17, the subject matter of example 16, or any of the examples herein, wherein the TA information includes a TA identifier (TAI) of the wireless telecommunication network.

In example 18, the subject matter of example 16, or any of the examples herein, wherein the TA information is obtained while the UE is in a Radio Resource Control (RRC) idle state.

In example 19, the subject matter of example 16, or any of the examples herein, wherein the prompt to establish the connection with the eNB includes a transition, by the UE, from an RRC idle state to an RRC connected state.

In example 20, the subject matter of example 16, or any of the examples herein, wherein the prompt to establish the connection with the eNB includes receiving a redirect message identifying the eNB.

In example 21, the subject matter of example 16, or any of the examples herein, wherein: the request for authentication information defines a plurality of TA records upon which the authentication information is to be based; and the second set of authentication information is based on a corresponding plurality of TA records stored locally by the UE.

In a twenty-second example, a method may comprise: registering, by a User Equipment (UE), with a core network of a wireless telecommunication network; receiving, by the UE, an indication of a hash function to use to authenticate enhanced Node Bs (eNBs) of the wireless telecommunication network; obtaining, by the UE, Tracking Area (TA) information associated with the UE being located in a geographic area; storing, by the UE, a first copy of the TA information locally; communicating, by the UE, a second copy of the TA information to the core network; detecting, by the UE, a prompt to establish a connection with an eNB; communicating, by the UE and to the eNB, a request for authentication information regarding the eNB; receiving, by the UE and in response to the request, a first set of authentication information; determining, by the UE, a second set of authentication information based on the hash function and the first copy of the TA information; when the first set of authentication information matches the second set of authentication information, establishing, by the UE, a connection with the eNB, and when the first set of authentication information does not match the second set of authentication information, ignoring, by the UE, the prompt.

In example 23, the subject matter of example 22, or any of the examples herein, wherein the TA information includes a TA identifier (TAI) of the wireless telecommunication network.

In example 24, the subject matter of example 22, or any of the examples herein, wherein the TA information is obtained while the UE is in a Radio Resource Control (RRC) idle state.

In example 25, the subject matter of example 22, or any of the examples herein, wherein the prompt to establish the connection with the eNB includes a transition, by the UE, from an RRC idle state to an RRC connected state.

In example 26, the subject matter of example 22, or any of the examples herein, wherein the prompt to establish the connection with the eNB includes receiving a redirect message identifying the eNB.

In example 27, the subject matter of example 22, or any of the examples herein, wherein: the request for authentication information defines a plurality of TA records upon which the authentication information is to be based; and the second set of authentication information is based on a corresponding plurality of TA records stored locally by the UE.

In a twenty-eighth example, a User Equipment (UE) may comprise: means for registering with a core network of a wireless telecommunication network; means for receiving an indication of a hash function to use to authenticate enhanced Node Bs (eNBs) of the wireless

telecommunication network; means for obtaining Tracking Area (TA) information associated with the UE being located in a geographic area; means for storing a first copy of the TA information locally; means for communicating a second copy of the TA information to the core network; means for detecting a prompt to establish a connection with an enhanced Node B (eNB); means for communicating, to the eNB, a request for authentication information regarding the eNB; means for receiving, in response to the request, a first set of authentication information; means for determining a second set of authentication information based on the hash function and the first copy of the TA information; when the first set of authentication information matches the second set of authentication information, means for establishing a connection with the eNB, and when the first set of authentication information does not match the second set of authentication information, means for ignoring the prompt. In example 29, the subject matter of example 28, or any of the examples herein, wherein the TA information includes a TA identifier (TAI) of the wireless telecommunication network.

In example 30, the subject matter of example 28, or any of the examples herein, wherein the TA information is obtained while the UE is in a Radio Resource Control (RRC) idle state.

In example 31, the subject matter of example 28, or any of the examples herein, wherein the prompt to establish the connection with the eNB includes a transition, by the UE, from an RRC idle state to an RRC connected state.

In example 32, the subject matter of example 28, or any of the examples herein, wherein the prompt to establish the connection with the eNB includes receiving a redirect message identifying the eNB .

In example 33, the subject matter of example 28, or any of the examples herein, wherein: the request for authentication information defines a plurality of TA records upon which the authentication information is to be based; and the second set of authentication information is based on a corresponding plurality of TA records stored locally by the UE.

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, 5 and 6 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.