Patent Description:
To receive services from a network, an unknown user equipment (UE) needs to register with the network or otherwise become known to the network. This is accomplished using a network attach procedure. As part of the attach procedure, the UE sends its international mobile subscriber identity (IMSI) number. The IMSI is a unique identification that the UE uses on all networks it communicates with (or which communicate on its behalf). The UE sends the IMSI with the attach request that is received at a mobility management entity (MME).

In an attempt to protect the IMSI from eavesdroppers and tracking, a temporary mobile subscriber identity (TMSI) can be used after initially authenticating the UE. The TMSI is local to a specific area and, therefore, must be reassigned in each area. Further, the TMSI is first assigned after the UE provides the IMSI for initial authentication (and so that the assignment of the TMSI can be associated with the UE's real identity). Sometimes a globally unique temporary UE identity (GUTI) is provided in the initial attach request instead of IMSI. Where the UE sends a GUTI instead its IMSI, the MME requests identification from other network elements that may have interacted with the UE previously. If the UE is known to other network elements, those other network elements respond with the IMSI. If the UE is not known, the MME then asks the UE to provide its IMSI for identification that is later used for update procedures with a location register.

Under any of the approaches above, the IMSI is still vulnerable. The IMSI is either included in the initial attach request or must be provided later in order to be authenticated. Thus, the IMSI maybe monitored passively via the over-the-air traffic and used to determine a user identity. Oftentimes the IMSI in the attach request is in plaintext, rendering the IMSI even more vulnerable to monitoring. Even in scenarios where the UE does not send the IMSI, the MME still obtains the actual IMSI from other network elements, and several different network elements may store the actual IMSI (e.g., the MME, a serving gateway (S-GW), and/or a PDN gateway (P-GW)). This leaves the IMSI vulnerable and dependent on the trustworthiness of the serving network.

<NPL>, discloses that for the very first connection, the UE initiates an attach procedure by transmitting an attach request to the MME. It includes the DMSI. At the end of the procedure, a GUTI is allocated by the MME.

Preferred embodiments of the invention are stipulated in the dependent claims.

In an example helpful for understanding the invention, a method for network access by a user equipment (UE) includes sending, from the UE, a privacy mobile subscriber identity (PMSI) in place of an international mobile subscriber identity (IMSI) to identify the UE with an initial attach message to a server on a network, receiving, from the server, an authentication request that includes a next PMSI, the next PMSI being a different value derived from the PMSI, and sending, from the UE, an acknowledgment of receipt of the next PMSI to the server.

In an example helpful for understanding the invention, a user equipment includes a memory configured to store a privacy mobile subscriber identity (PMSI), a transceiver configured to send the PMSI in place of an international mobile subscriber identity (IMSI) to identify the UE with an initial attach message to a server on a network and receive, from the server, an authentication request that includes a next PMSI, the next PMSI being a different value derived from the PMSI, and a processor configured to generate an acknowledgment of receipt, wherein the transceiver is further configured send the acknowledgement of receipt to the server.

In an example helpful for understanding the invention, computer-readable medium having program code recorded thereon includes code for causing a user equipment (UE) to send a privacy mobile subscriber identity (PMSI) in place of an international mobile subscriber identity (IMSI) to identify the UE with an initial attach message to a server on a network, code for causing the UE to receive, from the server, an authentication request that includes a next PMSI, the next PMSI being a different value derived from the PMSI, and code for causing the UE to send an acknowledgment of receipt of the next PMSI to the server.

In an example helpful for understanding the invention a method for setting up network access with a server on a network includes receiving, from a user equipment (UE) via one or more network elements in an intervening serving network, a privacy mobile subscriber identity (PMSI) in place of an international mobile subscriber identity (IMSI) to identify the UE from an initial attach message, determining, by the server, a next PMSI based on the PMSI, transmitting, from the server, an authentication request that includes the next PMSI, and receiving, from the UE, an acknowledgement of receipt that includes confirmation of the next PMSI.

In an example helpful for understanding the invention, a server includes a database configured to store a plurality of privacy mobile subscriber identities (PMSI) of user equipment (UE), a transceiver configured to receive, via one or more network elements in an intervening serving network from a UE, a privacy mobile subscriber identity (PMSI) in place of an international mobile subscriber identity (IMSI) to identify the UE from an initial attach message, and a processor configured to determine a next PMSI for the UE based on the PMSI, wherein the transceiver is further configured to transmit an authentication request that includes the next PMSI and receive an acknowledgement of receipt that includes confirmation of the next PMSI.

In an example helpful for understanding the invention, a computer-readable medium having program code recorded thereon includes code for causing a server to receive, from a user equipment (UE) via one or more network elements in an intervening serving network, a privacy mobile subscriber identity (PMSI) in place of an international mobile subscriber identity (IMSI) to identify the UE from an initial attach message, code for causing the server to determine a next PMSI based on the PMSI, code for causing the server to transmit an authentication request that includes the next PMSI, and code for causing the server to receive, from the UE, an acknowledgement of receipt that includes confirmation of the next PMSI.

The techniques described herein may be used for various wireless communication networks such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA and other networks. An OFDMA network may implement a radio technology such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE <NUM> (Wi-Fi), IEEE <NUM> (WiMAX), IEEE <NUM>, Flash-OFDMA, etc. UTRA and E-UTRA are part of Universal Mobile Telecommunication System (UMTS). 3GPP Long Term Evolution (LTE) and LTE-Advanced (LTE-A) are new releases of UMTS that use E-UTRA. The techniques described herein may be used for the wireless networks and radio technologies mentioned above as well as other wireless networks and radio technologies, such as a next generation (e.g., <NUM>th Generation (<NUM>)) network. Embodiments of this disclosure are directed to any type of modulation scheme that may be used on any one or more of the above-recited networks and/or those yet to be developed.

Embodiments of the present disclosure introduce systems and techniques to protect a user equipment's international mobile subscriber identity by providing a privacy mobile subscriber identity (PMSI) instead. In an embodiment, the UE initiates an attach request to a serving network. Instead of providing the IMSI or associated information that some element on the serving network can still use to access to the IMSI, the UE provides with the attach request the PMSI. The PMSI is then used throughout the process, such that the IMSI is not required between the UE and the server. In an embodiment, each PMSI (both for each UE and for different iterations for a specific UE) is unique from the others. This protects the IMSI from eavesdropping and from any potentially malicious elements in the serving network. Continuing with this example, elements of the serving network pass on the PMSI as part of an authentication information request to a server on the UE's home network (e.g., a home subscriber server (HSS)). The HSS locates the PMSI to identify the corresponding UE and provides an authentication information response to the network element. As part of the response, the HSS also derives a next PMSI that the UE will use for a subsequent attach request, checks for PMSI collisions, and provides the next PMSI and a PMSI tracking index to the network elements in the serving network for passing along to the UE.

The next PMSI and PMSI tracking index can be provided in encrypted form. In encrypted form, the next PMSI and PMSI tracking index remain protected from potentially malicious network elements in the serving network and from eavesdropping. The UE receives the encrypted next PMSI and PMSI tracking index and is able to decrypt them. The UE derives its own copy of the next PMSI to confirm that the UE and HSS are synchronized. After confirming that the next PMSI is synchronized between the UE and HSS, the UE sends an acknowledgment token to the server. The UE and the server then each update local copies of the current and next PMSI values. The HSS does not need to store every iteration of the PMSI for the UE. Instead, the HSS can arrive at any iteration of the PMSI based on an initial PMSI value and a desired PMSI tracking index value.

In a further embodiment, the initial PMSI may be agreed upon between the UE and the HSS. In an embodiment, the initial PMSI is agreed upon at subscriber registration, such that the initial PMSI is provisioned to a SIM card of the UE and registered to the HSS. In another embodiment, the UE is not provisioned with the PMSI at subscriber registration but rather initiates over-the-air registration with the HSS. The UE may generate an initial PMSI value and, after encrypting the initial PMSI value using the public key of the HSS (or other shared key between the UE and the HSS), send the proposed initial PMSI to the HSS. The HSS may decrypt the initial PMSI from the UE with a corresponding private key and determine whether the PMSI collides with any other existing PMSI values registered with the HSS. Upon confirming there are no collisions, the HSS may acknowledge the initial PMSI to the UE and store it for use when the UE later initiates its first attach request.

<FIG> illustrates a wireless communication network <NUM> in accordance with various aspects of the present disclosure. The wireless communication network <NUM> may include a number of UEs <NUM>, as well as a number of base stations <NUM>. A single UE <NUM> and single base station <NUM> have been illustrated in <FIG> for simplicity of illustration and explanation only. The base station <NUM> may include an evolved Node B (eNodeB). A base station may also be referred to as a base transceiver station or an access point.

The base station <NUM> communicates with the UE <NUM> as shown. A UE <NUM> may communicate with the base station <NUM> via an uplink and a downlink. The downlink (or forward link) refers to the communication link from the base station <NUM> to the UE <NUM>. The uplink (or reverse link) refers to the communication link from the UE <NUM> to the base station <NUM>.

UEs <NUM> may be dispersed throughout the wireless network <NUM>, and each UE <NUM> may be stationary or mobile. The UE <NUM> may also be referred to as a terminal, a mobile station, a subscriber unit, etc. The UE <NUM> may be a cellular phone, a smartphone, a personal digital assistant, a wireless modem, a laptop computer, a tablet computer, etc. The wireless communication network <NUM> is one example of a network to which various aspects of the disclosure apply.

Also illustrated in <FIG> is a mobility management entity (MME) <NUM>. The MME <NUM> may be in charge of control plane functions related to subscribers (e.g., UE <NUM>) and session management. For example, the MME <NUM> may provide mobility session management as well as support for handovers to other networks, roaming, and subscriber authentication. The MME <NUM> may assist in selection of an S-GW during an initial attach of the UE <NUM>, non-access stratum (NAS) signaling, NAS signaling security, P-GW selection, bearer management functions including dedicated bearer establishment, lawful interception of signaling traffic, and other functions to name just a few examples. The MME <NUM> and the base station <NUM> may be in the same serving network <NUM> (e.g., part of an evolved packet core (EPC)). As will be recognized, the serving network <NUM> includes many other network elements that are not shown in <FIG> for simplicity of discussion of aspects of the present disclosure.

The MME <NUM> communicates with a server <NUM> in a home network <NUM>. In an embodiment, the server <NUM> is a home subscriber server (HSS), which among other things maintains the home location register (HLR) that is in charge of storing and updating one or more databases that maintain user subscription information. Among other things, the server <NUM> in the home network <NUM> has a copy of the IMSI (user identification/addressing) for the UE <NUM>. The server <NUM> may also maintain user profile information that identifies service subscription states and/or quality-of-service (QoS) information (e.g., maximum allowed bit rate, allowed traffic class, etc.). The server <NUM> may also include authentication functions, such as managing security information generation from user identity keys and provision of the security information to the HLR (and other network entities). With the security information, network-UE authentication may be performed. One server <NUM> is illustrated in <FIG> for purposes of simplicity of illustration and explanation. The home network <NUM> may include multiple HSS. For example, the number of HSS may depend upon the number of mobile subscribers, equipment capacity, and network organization. The MME <NUM> may communicate with the server <NUM> via the network <NUM>, which may be a direct or indirect connection of various types as will be recognized.

As will be described in more detail below with respect to subsequent figures including the protocol diagram illustrating some signaling aspects between a UE, serving network, and home network (and associated server) for supporting identity privacy in wireless networks, the UE <NUM> may communicate with the serving network <NUM> and the home network <NUM> using a privacy mobile subscriber identity (PMSI) to the exclusion of an IMSI. The PMSI may be a unique number that is associated specifically with the UE <NUM> and that is maintained by both the UE <NUM> and the server <NUM>. In embodiments of the present disclosure, the PMSI may include an initial PMSI that is agreed upon and kept at both the UE <NUM> and the server <NUM>. A particular value for the UE <NUM>'s PMSI may be used once, such that each subsequent time the UE <NUM> initiates an attach request a new PMSI value is provided as part of the request. The UE <NUM> and the server <NUM> may store only the initial PMSI agreed upon and an index. As a result, any PMSI value may be subsequently derived based on the initial PMSI and a shared knowledge of a specific index value to describe how many derivation iterations should be performed to arrive at a specific PMSI at both the UE <NUM> and the server <NUM> (e.g., such that the UE <NUM> and the server <NUM> remain in agreement as to the particular PMSI that is used for a given session).

In an example, the UE <NUM> may send, as part of its initial attach request to the base station <NUM>, its PMSI instead of IMSI. The base station <NUM> then forwards the attach request with the UE's PMSI to the MME <NUM>. The MME <NUM> includes the PMSI in an authentication information request to the server <NUM> in the home network <NUM>. The server <NUM> is able to identify the UE <NUM> based on the PMSI provided in the initial attach request/authentication information request from the MME <NUM>, so that the IMSI does not have to be provided to the serving network <NUM>. Communication back to the UE <NUM> from the server <NUM> would also be based on/include the PMSI instead of IMSI as well. Use of PMSI instead of IMSI at all of these stages in the communication path reduces the risk of over-the-air eavesdropping between the UE <NUM> and the base station <NUM> and eliminates the availability of the UE <NUM>'s IMSI from any network elements in the serving network <NUM>, since the PMSI would be stored instead of the IMSI.

<FIG> is a block diagram of an exemplary UE <NUM> according to embodiments of the present disclosure. The UE <NUM> may have any one of many configurations described above. The UE <NUM> may include a processor <NUM>, a memory <NUM>, a PMSI module <NUM>, a transceiver <NUM>, and an antenna <NUM>. These elements may be in direct or indirect communication with each other, for example via one or more buses.

The processor <NUM> may include a central processing unit (CPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a controller, a field programmable gate array (FPGA) device, another hardware device, a firmware device, or any combination thereof configured to perform the operations described herein with reference to the UE <NUM> introduced above with respect to <FIG> and discussed in more detail below.

The memory <NUM> may include a cache memory (e.g., a cache memory of the processor <NUM>), random access memory (RAM), magnetoresistive RAM (MRAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), flash memory, solid state memory device, hard disk drives, other forms of volatile and non-volatile memory, or a combination of different types of memory. In an embodiment, the memory <NUM> includes a non-transitory computer-readable medium. The instructions <NUM> may include instructions that, when executed by the processor <NUM>, cause the processor <NUM> to perform the operations described herein with reference to the UE <NUM> in connection with embodiments of the present disclosure. Instructions <NUM> may also be referred to as code. The terms "instructions" and "code" should be interpreted broadly to include any type of computer-readable statement(s). For example, the terms "instructions" and "code" may refer to one or more programs, routines, sub-routines, functions, procedures, etc. "Instructions" and "code" may include a single computer-readable statement or many computer-readable statements.

The PMSI module <NUM> may be used for various aspects of the present disclosure. For example, the PMSI module <NUM> may be involved in the initial provisioning of the PMSI for the specific UE <NUM>. In an embodiment, the PMSI is provisioned to the UE <NUM> at the same time as the IMSI for the UE <NUM>. For example, in some instances the PMSI is provisioned along with the IMSI during subscriber registration with an HSS, such as the server <NUM> in <FIG>. This provisioning may occur in a SIM card on the UE <NUM> at the time of manufacture. In another embodiment, the IMSI may be provisioned before the PMSI is agreed upon between the UE <NUM> and the server <NUM>. For example, the UE <NUM> and the server <NUM> may agree upon a first (initial) PMSI over-the-air after the IMSI has already been provisioned for the UE <NUM>. When the PMSI is agreed upon over-the-air, the UE <NUM> may generate a proposed initial PMSI (as will be discussed in more detail with respect to <FIG> below) and encrypt the proposed initial PMSI with a public key provided by the server <NUM>. In this way, the proposed initial PMSI transmitted by the UE <NUM> may be protected from eavesdropping and potentially compromised network elements in the serving network <NUM>. The server <NUM> maintains a corresponding private key and is able to decrypt the proposed initial PMSI. The server <NUM> may check the proposed initial PMSI against one or more databases to verify that there are no collisions with any other UE's PMSI maintained by the server <NUM> or otherwise within the home network <NUM>.

The PMSI module <NUM> may additionally be involved in PMSI acknowledgement. As stated above, a particular PMSI value (based on an initial PMSI) may be used only for a predetermined number of attach requests (e.g., one, two, three, or more) such that different PMSI value is provided for subsequent attach requests. In response to an attach request from the UE <NUM>, the server <NUM> may generate a "next PMSI" - the next PMSI value to be used in a subsequent session - and share the next PMSI with the UE <NUM> as part of an authentication request in response to the initial attach request. The UE <NUM>'s PMSI module <NUM> may calculate its own next PMSI value based on the stored initial PMSI and incremented index (as discussed further below) and compare the local calculated next PMSI with the next PMSI received from the server <NUM>. If there is a match, the PMSI module <NUM> may cause the UE <NUM> to generate a response acknowledging the next PMSI to the server <NUM>. If there is not a match, then the PMSI module <NUM> may update its local index with an index received from the server <NUM> with the next PMSI such that after recomputation the values match.

The transceiver <NUM> may include a modem subsystem <NUM> and a radio frequency (RF) unit <NUM>. The transceiver <NUM> is configured to communicate bidirectionally with other devices, such as base stations <NUM>. The modem subsystem <NUM> may be configured to modulate and/or encode the data from the PMSI module <NUM> according to a modulation and coding scheme (MCS), e.g., a low-density parity check (LDPC) coding scheme, a turbo coding scheme, a convolutional coding scheme, etc. The RF unit <NUM> may be configured to process (e.g., perform analog to digital conversion or digital to analog conversion, etc.) modulated/encoded data from the modem subsystem <NUM> (on outbound transmissions) or of transmissions originating from another source such as a base station <NUM>. Although shown as integrated together in transceiver <NUM>, the modem subsystem <NUM> and the RF unit <NUM> may be separate devices that are coupled together at the UE <NUM> to enable the UE <NUM> to communicate with other devices.

The RF unit <NUM> may provide the modulated and/or processed data, e.g. data packets (or, more generally, data messages which may contain one or more data packets and other information, including PMSI values), to the antenna <NUM> for transmission to one or more other devices. This may include, for example, transmission of data messages to the base station <NUM> according to embodiments of the present disclosure. The antenna <NUM> may further receive data messages transmitted from the base station <NUM> and provide the received data messages for processing and/or demodulation at the transceiver <NUM>. Although <FIG> illustrates antenna <NUM> as a single antenna, antenna <NUM> may include multiple antennas of similar or different designs in order to sustain multiple transmission links.

<FIG> is a block diagram of an exemplary server <NUM> according to embodiments of the present disclosure. The server <NUM> may include a processor <NUM>, a memory <NUM>, a PMSI module <NUM>, a database <NUM>, and a transceiver <NUM>. These elements may be in direct or indirect communication with each other, for example via one or more buses. As mentioned above with respect to <FIG>, the server <NUM> may be an HSS that provides home location register and authentication functionality, to name just two examples.

The processor <NUM> may include a CPU, a DSP, an ASIC, a controller, a FPGA device, another hardware device, a firmware device, or any combination thereof configured to perform the operations described herein with reference to the server <NUM> introduced in <FIG> above.

The memory <NUM> may include a cache memory (e.g., a cache memory of the processor <NUM>), RAM, MRAM, ROM, PROM, EPROM, EEPROM, flash memory, a solid state memory device, one or more hard disk drives, other forms of volatile and non-volatile memory, or a combination of different types of memory. In an embodiment, the memory <NUM> includes a non-transitory computer-readable medium. The instructions <NUM> may include instructions that, when executed by the processor <NUM>, cause the processor <NUM> to perform the operations described herein with reference to the server <NUM> in connection with embodiments of the present disclosure.

The PMSI module <NUM> may be used for various aspects of the present disclosure. For example, the PMSI module <NUM> may be involved in the initial provisioning of the PMSI for the specific UE <NUM>. In an embodiment, the PMSI is provisioned and stored in the database <NUM> at the same time as the IMSI for the UE <NUM>, for example during subscriber registration. In another embodiment, the IMSI may be provisioned before the PMSI is agreed upon between the server <NUM> and the UE <NUM>. For example, the server <NUM> may agree upon a first (initial) PMSI over-the-air from the UE <NUM> after the IMSI has already been provisioned for the UE <NUM>. When agreed upon over-the-air, the server <NUM> may receive a proposed initial PMSI generated by, and received from, the UE <NUM> (as will be discussed in more detail with respect to <FIG> below). The proposed initial PMSI may have been encrypted with a public key provided by the server <NUM> to the UE <NUM>. As a result, the server <NUM> may decrypt the proposed initial PMSI using a corresponding private key. In this way, the PMSI may be protected from eavesdropping and potentially compromised network elements in the serving network <NUM>. The server <NUM> may check the proposed initial PMSI against PMSI values in the database <NUM> to verify that there are no collisions with any other UE's PMSI maintained by the server <NUM> or otherwise within the home network <NUM>.

The PMSI module <NUM> may additionally be involved the initial attach procedure with the UE <NUM>. The server <NUM> may receive the PMSI provided with the initial attach request from the UE and check the PMSI against the PMSI values stored in the database <NUM>. In response to the attach request from the UE <NUM>, the server <NUM> may generate a next PMSI and transmit the next PMSI to the UE <NUM> as part of an authentication request response to the initial attach request. In response to receiving a response acknowledging the next PMSI from the UE <NUM>, the PMSI module <NUM> updates the PMSI values stored in the database <NUM>. For example, the current PMSI value becomes a previous PMSI value and the next PMSI value becomes the current PMSI value utilized for a subsequent interaction, such as a subsequent attach request from the UE <NUM>.

For purposes of discussion, reference is made herein to four PMSI values: (<NUM>) an initial PMSI, which is the initial agreed-upon PMSI value that the UE <NUM> and the server <NUM> use to derive subsequent PMSI values; (<NUM>) a current PMSI, which is the PMSI value used in the current attach request procedure (e.g., the first time the UE <NUM> sends an initial attach request the current PMSI may equal the initial PMSI, while in other embodiments the PMSI may be iterated one or more times so that the initial PMSI is kept more secure even during the initial attach request); (<NUM>) a prior or previous PMSI, which is the PMSI preceding the current PMSI (e.g., the PMSI used in the previous attach request and/or the PMSI used to arrive at the current PMSI); and (<NUM>) a next PMSI, which is the PMSI following the current PMSI (e.g., the PMSI derived by both the UE <NUM> and the sever <NUM> for agreement on what the PMSI should be for the next attach procedure that the UE <NUM> initiates with any given serving network <NUM>).

The database <NUM> may include one or more databases maintained by the server <NUM>, for example the HLR mentioned above with respect to <FIG>. The database <NUM> may track subscriber information such as user identification and addressing (including, for example, the IMSI, PMSI (including initial PMSI, current PMSI, previous PMSI, and/or next PMSI) PMSI tracking index, and mobile telephone number of all or a subset of the subscribers), profile information (e.g. service subscription states), as well as security information associated with each subscriber (e.g., security keys).

The transceiver <NUM> enables the server <NUM> to communicate to transmit and receive data from external sources, such as other network elements within the home network <NUM> or the serving network <NUM>. The transceiver <NUM> may enable wireless and/or wired communications. The transceiver <NUM> may include, for example, an Ethernet connection, a WiFi connection, or other types of modem and/or RF subsystems as will be recognized.

<FIG> is a block diagram illustrating an exemplary transmitter system <NUM> (e.g., a base station <NUM>) and a receiver system <NUM> (e.g., a UE <NUM>) in a MIMO system <NUM>, according to certain aspects of the present disclosure. At the transmitter system <NUM>, traffic data for a number of data streams is provided from a data source <NUM> to a transmit (TX) data processor <NUM>. The traffic data may include all manner of traffic, including authentication requests from one or more MME entities according to aspects of the present disclosure.

In a downlink transmission, for example, each data stream is transmitted over a respective transmit antenna. The TX data processor <NUM> formats, codes, and interleaves the traffic data for each data stream based on a particular coding scheme selected for that data stream to provide coded data.

The coded data for each data stream may be multiplexed with pilot data using OFDM techniques. The pilot data, e.g., a pilot sequence, is typically a known data pattern that is processed in a known manner and may be used at the receiver system to estimate the channel response or other channel parameters. Pilot data may be formatted into pilot symbols. The number of pilot symbols and placement of pilot symbols within an OFDM symbol may be determined by instructions performed by processor <NUM>.

The multiplexed pilot and coded data for each data stream is then modulated (i.e., symbol mapped) based on a particular modulation scheme (e.g., BPSK, QSPK, M-PSK, or M-QAM) selected for that data stream to provide modulation symbols. The data rate, coding, and modulation for each data stream may be determined by instructions performed by processor <NUM>. The number of pilot symbols and placement of the pilot symbols in each frame may also be determined by instructions performed by processor <NUM>, for example as described above with respect to <FIG>. The transmitter system <NUM> further includes a memory <NUM>, for example as described above with respect to <FIG> as well.

The modulation symbols for all data streams are then provided to a TX MIMO processor <NUM>, that may further process the modulation symbols (e.g., for OFDM). TX MIMO processor <NUM> then provides NT modulation symbol streams to NT transmitters (TMTR) <NUM>a through <NUM>t. In some embodiments, TX MIMO processor <NUM> applies beamforming weights to the symbols of the data streams and to the antenna from which the symbol is being transmitted. The transmitter system <NUM> includes embodiments having only one antenna or having multiple antennas.

NT modulated signals from transmitters <NUM>a through <NUM>t are then transmitted from NT antennas <NUM>a through <NUM>t, respectively. The techniques described herein apply also to systems with only one transmit antenna. Transmission using one antenna is simpler than the multi-antenna scenario. For example, there may be no need for TX MIMO processor <NUM> in a single antenna scenario.

At receiver system <NUM>, the transmitted modulated signals are received by NR antennas <NUM>a through <NUM>r and the received signal from each antenna <NUM> is provided to a respective receiver (RCVR) <NUM>a through <NUM>r. Each receiver <NUM> conditions (e.g., filters, amplifies, and downconverts) a respective received signal, digitizes the conditioned signal to provide samples, and further processes the samples to provide a corresponding "received" symbol stream. The techniques described herein also apply to embodiments of receiver system <NUM> having only one antenna <NUM>.

An RX data processor <NUM> then receives and processes the NR received symbol streams from receivers <NUM>a through <NUM>r based on a particular receiver processing technique to provide NT detected symbol streams. The RX data processor <NUM> then demodulates, deinterleaves, and decodes as necessary each detected symbol stream to recover the traffic data for the data stream. The recovered traffic may include, for example, information in an authentication information request from an MME according to aspects of the present disclosure. The processing by RX data processor <NUM> can be complementary to that performed by TX MIMO processor <NUM> and TX data processor <NUM> at transmitter system <NUM>.

Information provided by the RX data processor <NUM> allows the processor <NUM> to generate reports such as channel state information (CSI) and other information to provide to the TX Data Processor <NUM>. Processor <NUM> formulates a reverse link message comprising the CSI and/or pilot request to transmit to the transmitter system.

The processor <NUM> may be implemented for example as described above with respect to the processors described in <FIG>. In addition to reverse link messages, the receiver system <NUM> may transmit other various types of information including attach requests, acknowledgement tokens, and other information for establishing a communication session as well as data during the communication session. The message can be processed by a TX data processor <NUM>, modulated by a TX MIMO processor <NUM>, conditioned by transmitters <NUM>a through <NUM>r, and transmitted back to transmitter system <NUM>. As shown, the TX data processor <NUM> may also receive traffic data for a number of data streams from a data source <NUM>.

At transmitter system <NUM>, the modulated signals from receiver system <NUM> are received by antennas <NUM>, conditioned by receivers <NUM>, demodulated by a demodulator <NUM>, and processed by a RX data processor <NUM> to extract the reverse link message transmitted by the receiver system <NUM>. As a result, data may be sent and received between the transmitter system <NUM> and the receiver system <NUM>. The transmitter system <NUM> may also be used to transmit information it receives from the receiver system <NUM> to other network elements within its serving network and receive information from one or more other network elements in the serving network, as will be recognized. The embodiment illustrated in <FIG> is exemplary only, and embodiments of the present disclosure are applicable to other transmitter/receiver systems not illustrated in <FIG>.

<FIG> is a protocol diagram illustrating some signaling aspects between a UE, serving network, and home network (and server) for supporting identity privacy in wireless networks according to an example helpful for understanding the invention. For simplicity of discussion, reference will be made to the elements shown in <FIG> (e.g., UE <NUM>, base station <NUM> as eNB, MME <NUM>, and server <NUM> as HSS) in describing the actions in the protocol diagram of <FIG>. Further for simplicity, discussion will focus on those aspects of the protocol flow that describe aspects of embodiments of the present disclosure instead of all aspects of the attach procedure (e.g., discussion will focus on aspects in addition to, or different from, the 3GPP Standard with some overlap, such as found in TS <NUM>. <NUM>, or other attach procedures).

In action <NUM>, the UE <NUM> accesses the current PMSI stored in the UE <NUM>. Where it is the first time that the UE <NUM> is attempting to attach to the serving network <NUM>, the current PMSI may correspond to the initial PMSI (e.g., where the PMSI is provisioned at the same time as the UE <NUM>'s IMSI, or where the PMSI was agreed upon later but before the attach request). In embodiments where prior attach procedures have occurred, or where necessitated by PMSI collisions at the server <NUM>, the current PMSI stored in the UE <NUM> is the next PMSI that was agreed upon between the UE and the server <NUM> during the prior attach procedure. The UE <NUM> may store one or more PMSI values, including initial PMSI, current PMSI, previous PMSI, and/or next PMSI. In some instances, the current PMSI is stored as a value distinct from the prior PMSI value(s).

In some embodiments, the UE <NUM> derives the current PMSI from a previous PMSI and a PMSI tracking index. For example, the PMSI tracking index may be initialized at zero with the initial PMSI, and each time that the UE <NUM> and the server <NUM> successfully complete an attach procedure, the PMSI tracking index may be incremented by a fixed value (e.g., <NUM>) at both the UE <NUM> and the server <NUM>. Thus, each of the UE <NUM> and the server <NUM> may store [initial PMSI, PMSI tracking index] that can be used to arrive at any iteration of the PMSI currently in use. Each may also store [current PMSI, PMSI tracking index] and rely upon the PMSI tracking index to determine whether reference needs to be made to the initial PMSI instead (e.g., where the index values do not match between the UE <NUM> and the server <NUM>).

In action <NUM>, the UE <NUM> sends an initial attach request to the serving network <NUM>, for example by transmitting the initial attach request to the base station <NUM>, which then forwards on to the MME <NUM>. The initial attach request includes the current PMSI instead of the IMSI (or any other value that one or more elements within the serving network <NUM> could use to associate with the IMSI of UE <NUM>).

After the MME <NUM> receives the initial attach request during action <NUM>, in action <NUM> the MME <NUM> takes the information in the initial attach request and sends an authentication information request to the server <NUM>. The authentication information request may include the current PMSI and a sequence number that refers to the serving network <NUM> being accessed by the UE <NUM>.

At action <NUM>, after the server <NUM> has received the authentication information request during action <NUM>, the server <NUM> checks the PMSI included in the authentication information request and (among other things) checks the PMSI against one or more databases. As part of action <NUM>, the server <NUM> decrypts the PMSI (where PMSI has been encrypted). For example, the server <NUM> may decrypt the PMSI using a private key associated with a public key utilized to encrypt the PMSI. The server <NUM> compares the PMSI to the values stored, for example, in the database <NUM> described in <FIG> above. When the server <NUM> finds a match between PMSI values, the server <NUM> may also check for the IMSI corresponding to the current PMSI received from the UE <NUM>.

When there is a match of PMSI values, as part of action <NUM> the server <NUM> (e.g., the PMSI module <NUM>) cane derive the next PMSI for inclusion in an authentication response to the MME <NUM>. In an embodiment, the next PMSI is derived as follows. The PMSI tracking index is incremented by a fixed amount, <NUM> for example, and concatenated to the current PMSI value stored in the database <NUM> (and as identified in the authentication information request from the MME <NUM>). This value is included as an input into another derivation function, together with a KPMSI value. The KPMSI is the PMSI generation key. For example, KPMSI may be created by using a key derivation function (KDF) that has an original key K (e.g., an EPS master key) and a PMSI derivation context CTX as inputs (e.g., KPMSI = KDF(K, CTX)). CTX may be a context, e.g. a string such as "PMSI generation" - by using the context in key generation, the same key K may be used to generated different keys, such as by incorporating different contexts to result in differing key generation results.

The KPMSI value and the PMSI concatenated with the index are hashed together in a function (e.g., (result = HMAC(KPMSI, PMSI | index), where | is the concatenation operator)). The result of the function may be truncated so that the output of the HMAC function (a keyed-hash message authentication code) is limited to a fixed number of digits (e.g., <NUM>-<NUM> digits). The truncated result may then be concatenated with the mobile network code (MNC) and the mobile country code (MCC) and the resulting value becomes the next PMSI. This value, as a result of the truncation, may be in an embodiment <NUM> digits long, though it will be recognized that other lengths (both longer and shorter) are possible without departing from the scope of the present disclosure. The overall operation may be described in an embodiment as follows: <MAT>.

Generally speaking, the server <NUM> may store the PMSI (e.g., initial and/or current PMSI) with the PMSI tracking index. The PMSI tracking index enables the server <NUM> to compute the current PMSI from the initial PMSI by repeatedly hashing the initial PMSI x number of times, where x equals the PMSI tracking index value. The PMSI tracking index is also useful for accounting as well as for collision avoidance. For example, the server <NUM> may check the generated next PMSI against other known PMSI values to verify that there are no collisions with any other UE's PMSI. Where there is a collision the server <NUM> may increment the index (e.g. by <NUM>) and repeat equation (<NUM>) with the new PMSI-concatenated-index value.

At action <NUM>, the server <NUM> takes the information generated and incorporates it into an authentication information response to be sent to the MME <NUM>. The next PMSI may be encrypted for added security in the authentication information response, e.g. so that the MME <NUM> is not able to discern the next PMSI between the UE <NUM> and the server <NUM>. For example, the next PMSI may be encrypted with an anonymity key that is derived from KPMSI and a random number (RAND) (e.g., anonymity key = function(KPMSI, RAND)).

The anonymity key is derived by placing the KPMSI and a random number RAND into a key derivation function as inputs. The key derivation function may be any derivation function that is consistent with the 3GPP standard (or future equivalent/similar standard), for example f5*. In an embodiment, the key derivation function may be an HMAC function. Thus, in an embodiment the anonymity key may be derived by HMAC(KPMSI, RAND). In an alternative embodiment, the anonymity key may be a key encryption key (KEK) where the initial serving network <NUM> authentication is enabled.

As part of action <NUM>, the server <NUM> can send the authentication information response to the MME <NUM>. The authentication information response may include, among other things, an authentication vector and the next PMSI/PMSI tracking index in encrypted form (as encrypted by the anonymity function whose derivation is described above). In an embodiment, the authentication vector may itself include an authentication token, expected response, random number, and local master key KASME. Thus, in addition to what may be traditionally included for the authentication vector, embodiments of the present disclosure also include a next PMSI and PMSI tracking index for synchronization with the UE <NUM>. The MME <NUM> may store the authentication vector but, in some embodiments, does not store the encrypted PMSI/PMSI tracking index.

At action <NUM>, the MME <NUM> engages in mutual authentication with the UE <NUM> by sending an authentication request to the UE <NUM>. The authentication request takes information obtained from the authentication information response of action <NUM>. For example, the MME <NUM> may keep the expected response as part of the authentication and passes on the authentication token, random number, eUTRAN key set identifier (eKSI), as well as the encrypted next PMSI and PMSI tracking index.

At action <NUM>, the UE <NUM> (in addition to traditional mutual authentication procedures with the MME <NUM>) confirms the next PMSI and generates an acknowledgement token for return to the server <NUM>. In this regard, the UE <NUM> decrypts the encrypted next PMSI and PMSI tracking index values from the authentication request received in action <NUM>. The UE <NUM> is able to decrypt the next PMSI and PMSI tracking index values because the UE <NUM> has the shared secret key CTX (the PMSI derivation key) that the server <NUM> (but not the MME <NUM>) also has.

The UE <NUM> derives the next PMSI on its own in order to compare against the next PMSI generated by the server <NUM> to confirm they are in sync. The UE <NUM> may derive the next PMSI by hashing the current PMSI with the next PMSI tracking index. Alternatively, the UE <NUM> may derive the next PMSI by repeatedly hashing the initial PMSI x number of times, where x equals the PMSI tracking index value (either as saved locally with the UE <NUM> or as decrypted from the server <NUM>). The UE <NUM> then compares the locally derived next PMSI with the next PMSI received from the server <NUM>. If the values match, then the UE <NUM> may proceed with generating an acknowledgement token.

If the two next PMSI values do not match (e.g., where the UE <NUM> used its own version of the PMSI tracking index), then the UE <NUM> and the server <NUM> are not in sync. This may occur, for example, in situations where a message from the UE <NUM> or to the UE <NUM> was dropped while in transit. In this scenario, the UE <NUM> may update its PMSI tracking index to correspond to the PMSI tracking index received and decrypted from the server <NUM>. The UE <NUM> may then re-derive the next PMSI and compare again to the next PMSI received and decrypted from the server <NUM>.

With the next PMSI confirmed, which will be used as the current PMSI value for a subsequent attach procedure, the UE <NUM> may proceed with generating the acknowledgment token. The acknowledgment token may be generated by concatenating an encrypted sequence number (used for synchronization) and a MAC-A value. The encryption aspect involves encrypting a sequence number that is shared between the UE <NUM> and the server <NUM>. The encryption may be performed by another anonymity key that, in an embodiment, is different from the anonymity key described above at action <NUM> (e.g., the anonymity key here is derived using a different function that is consistent with 3GPP standard or other standard). For example, the anonymity key used to encrypt the sequence number may, itself, be generated by any of a variety of key derivation functions that take, as inputs, the KPMSI described above and a random number.

The MAC-A value concatenated to the encrypted sequence number is generated from a message authentication function (e.g., f1*) that takes as inputs another anonymity key (e.g., different from any of the other anonymity keys described above), the sequence number concatenated with a random number and an Authentication Management Field (AMF) value. The anonymity key used as an input in the message authentication function may be generated by another key derivation function that takes as inputs the KPMSI and a random number. These functions and specific inputs are described for simplicity of discussion. As will be recognized, other functions and inputs to those functions may be used without departing from the scope of the present disclosure.

At action <NUM>, the UE <NUM> sends the acknowledgment token generated at action <NUM> back to the MME <NUM> and the server <NUM> as a PMSI acknowledgment message. The PMSI acknowledgment message may include the authentication token generated and described above with respect to action <NUM>, as well as a random number (e.g., the same random number used in the key derivation function(s) above). In an embodiment, the PMSI acknowledgment message may be piggybacked with other aspects of the attach procedure (e.g., the ciphered options response message) from the UE <NUM> to the MME <NUM> not described in detail here. At the MME <NUM>, the PMSI acknowledgement message may be piggybacked from the MME <NUM> to the server <NUM> with another message (e.g., an update location request) sent to the server <NUM>.

At action <NUM>, upon receipt of the acknowledgment token the server <NUM> updates the previous PMSI with the current PMSI value and the current PMSI with the next PMSI value (that has been confirmed with the UE <NUM>, and, therefore, is synchronized). This is useful so that the PMSI value used in the attach procedure may still be used between the server <NUM>, the serving network <NUM>, and the UE <NUM> during the established session, for example during handoff to other MMEs so that the location of UE <NUM> may be properly updated with the server <NUM> without disclosing the IMSI of UE <NUM>. The attach procedure may then continue to include other aspects that are traditionally performed, although any use of IMSI is replaced by use of PMSI in accordance with the present disclosure.

After successful authentication of the UE <NUM>, e.g. as described above with respect to <FIG>, the server <NUM> may be required by law in some jurisdictions to disclose the IMSI for the UE <NUM> to a requesting serving network, such as serving network <NUM> illustrated in <FIG>. According to aspects of the present disclosure, the server <NUM> may in these circumstances still supply the PMSI in place of IMSI to protect against the possibility of one or more malicious network elements, such as a malicious MME <NUM>.

Such a request may appear as follows (though not illustrated in <FIG>). The MME <NUM> may send an IMSI request of UE <NUM> to the server <NUM>. According to embodiments of the present disclosure, since the IMSI of UE <NUM> was not received by the MME <NUM> during the attach procedure (or handover) but rather a PMSI, the MME <NUM> includes the received PMSI associated with UE <NUM> together with a KIMSI encryption key. The KIMSI encryption key may be generated as the result from a function, such as an HMAC function that has KASME (Access Security Management Entity) and an IMSI retrieval key as inputs. The KASME is an MME <NUM> base key that is known to both the MME <NUM> and the server <NUM>.

In response to the IMSI request, the server <NUM> provides an IMSI response. In an embodiment, the server <NUM> sends the PMSI with no other ability for the MME <NUM> to arrive at the IMSI. This may be possible, for example, because the server <NUM> still maintains the association between PMSI and IMSI for the UE <NUM> that is the subject of the IMSI request and therefore, for all intents PMSI provides the requested validation since the server <NUM> will be able to access the same information using PMSI as using IMSI. In another embodiment, the server <NUM> responds with the PMSI as well as an encrypted version of the IMSI. For example, the server <NUM> may take both PMSI and IMSI and encrypt them using KIMSI. As a result, the IMSI may be correctly decrypted only by the MME <NUM> that validly owns the KASME.

Turning now to <FIG>, a flowchart illustrates an exemplary method <NUM> for a UE initiating an attach process using a PMSI in accordance with various aspects of the present disclosure. The method <NUM> may be implemented in UE <NUM> that is in communication with serving network <NUM> (e.g., base station <NUM> and MME <NUM> to illustrate just two network elements of serving network <NUM>). The method <NUM> will be described with respect to a specific UE <NUM> for simplicity of discussion, though it will be recognized that the aspects described herein may be applicable to a plurality of UEs <NUM>. It is understood that additional steps can be provided before, during, and after the steps of method <NUM>, and that some of the steps described can be replaced or eliminated for other embodiments of the method <NUM>.

At step <NUM>, the UE <NUM> accesses the current PMSI that will be used for the initial attach request at step <NUM>. As discussed above with respect to <FIG>, the current PMSI may be the initial PMSI stored at the UE <NUM> (e.g., in memory <NUM>) if it is the first attach attempt for the UE <NUM>. In other embodiments where prior attach procedures have occurred, the current PMSI is the next PMSI confirmed between the server <NUM> and the UE <NUM> during the prior attach procedure.

At step <NUM>, once the current PMSI is retrieved the UE <NUM> sends an initial attach request to the current serving network (e.g., <NUM> as illustrated in <FIG>). The initial attach request includes the retrieved current PMSI, instead of the IMSI or other value that could be used to reconstruct the IMSI of UE <NUM>, as well as other information. The initial attach request may be received by the base station <NUM>, which forwards the request on to MME <NUM>. After the MME <NUM> receives the initial attach request, the MME <NUM> takes the information in the initial attach request and sends an authentication information request, with the PMSI instead of IMSI, to the server <NUM>.

At step <NUM>, the UE <NUM> receives an authentication request from the MME <NUM> (e.g., via the base station <NUM>) in the serving network <NUM> (for example as described above at action <NUM> of <FIG>). The authentication request can include an encrypted next PMSI and PMSI tracking index from the server <NUM>, which the MME <NUM> may be unable to access because it does not have the appropriate key to decrypt.

At step <NUM>, the UE <NUM> decrypts the next PMSI and PMSI tracking index values received as part of the authentication request from the MME <NUM>. The UE <NUM> is able to decrypt the next PMSI and PMSI tracking index values because the UE <NUM> has the shared secret key that the server <NUM> used in generating the anonymity key that was used to encrypt the values, as described above with respect to actions <NUM> and <NUM> of <FIG>.

At step <NUM>, the UE <NUM> derives the next PMSI value on its own (i.e., without relying upon the next PMSI and PMSI tracking index received at step <NUM>). In an embodiment, the UE <NUM> derives the next PMSI value based on a previous PMSI value and PMSI tracking index value stored at the UE <NUM> (e.g., in memory <NUM>). In another embodiment, the UE <NUM> derives the next PMSI value based on the initial PMSI value stored with the UE <NUM> and the current value of the PMSI tracking index (e.g., hashing the PMSI value a number of times equal to the current value of the PMSI tracking index).

At step <NUM>, the UE <NUM> (e.g., the processor <NUM> in cooperation with the PMSI module <NUM>) compares the locally derived next PMSI value with the received and decrypted next PMSI value.

At decision step <NUM>, if the locally derived next PMSI value and the received and decrypted next PMSI value do not match, then the method <NUM> proceeds to step <NUM> where the UE <NUM> updates its local version of PMSI tracking index to equal the value of the received and decrypted PMSI tracking index from the server <NUM>. The method <NUM> then proceeds from step <NUM> back to step <NUM>, where the process continues as described above.

Returning to decision step <NUM>, if the locally derived next PMSI value and the received and decrypted next PMSI value do match, then the method <NUM> proceeds to step <NUM>.

At step <NUM>, the UE <NUM> (e.g., the processor <NUM> in cooperation with the PMSI module <NUM>) generates an acknowledgment token to be sent to the server <NUM>, for example as described above with respect to action <NUM> of <FIG>.

At step <NUM>, the UE <NUM> sends the generated acknowledgement token to the server <NUM>, for example via one or more network elements of the serving network <NUM>. The UE <NUM> also updates its local PMSI values, for example by updating the previous PMSI to reflect the current PMSI value (the PMSI used in the current attach procedure) and the current PMSI to reflect the synchronized next PMSI value. The UE <NUM> and the serving network <NUM> may continue with establishing a communication session as will be recognized.

<FIG> is a flowchart illustrating an exemplary method <NUM> for a server in an attach process using a PMSI according to an example helpful for understanding the invention. The method <NUM> may be implemented in server <NUM> that is in communication with serving network <NUM> (e.g., MME <NUM> to illustrate just one network element example of serving network <NUM>). The method <NUM> will be described with respect to a server <NUM> for simplicity of discussion, though it will be recognized that the aspects described herein may be applicable to a plurality of servers <NUM>. It is understood that additional steps can be provided before, during, and after the steps of method <NUM>, and that some of the steps described can be replaced or eliminated for other embodiments of the method <NUM>.

At step <NUM>, the server <NUM> receives an authentication information request from the serving network <NUM>, for example the MME <NUM>, which includes the current PMSI provided to the MME <NUM> by the UE <NUM> instead of its IMSI. As described above with respect to action <NUM>, the MME <NUM> sends the authentication information request based on an initial attach request the MME <NUM> received from the UE <NUM>.

At step <NUM>, the server <NUM> (e.g., the processor <NUM> in cooperation with the PMSI module <NUM> and database <NUM>) checks the received PMSI against the PMSI values already maintained at the server <NUM> (or accessible by the server <NUM> elsewhere) to identify the specific UE <NUM> that corresponds to the received PMSI, for example as described above with respect to action <NUM> of <FIG>.

At step <NUM>, after finding a match the server <NUM> increments a PMSI tracking index associated with the received PMSI located in the database <NUM> (or accessible by the server <NUM> elsewhere). The PMSI tracking index is maintained by the server <NUM> and kept associated with the UE's PMSI record. The PMSI tracking index enables the server <NUM> to compute any iteration of the UE <NUM>'s PMSI based on the initial PMSI agreed upon between the UE <NUM> and the server <NUM>, as described above. This ability to arrive at any iteration of the PMSI value also enables the server <NUM> to accomplish various accounting and charging purposes. The server <NUM> also uses the PMSI tracking index to address situations where collisions occur between a possible next PMSI value derived by the server <NUM> and another PMSI value already maintained at the server <NUM> for another UE <NUM>. In an embodiment, the PMSI tracking index may be incremented by a value of <NUM> by way of example.

At step <NUM>, the server <NUM> (for example the processor <NUM> in cooperation with the PMSI module <NUM>) derives a next PMSI. The server <NUM> may derive the next PMSI based on the current PMSI received in the authentication information request at step <NUM> as well as the incremented PMSI tracking index from step <NUM>, for example as described above with respect to action <NUM> in <FIG>. Similarly, the server may derive the next PMSI based on the initial PMSI and a PMSI tracking index value.

At decision step <NUM>, the server <NUM> checks the next PMSI derived at step <NUM> against other known PMSI values to verify that there are no collisions with any other UE's PMSI. If there is a collision, the method <NUM> proceeds back to step <NUM>, where the PMSI tracking index is incremented again and then the next PMSI derived at step <NUM> with the new PMSI tracking index value.

Returning to decision step <NUM>, if there are no collisions then the method <NUM> proceeds to step <NUM>. At step <NUM>, the server <NUM> encrypts the next PMSI and incremented PMSI tracking values, for example as described above with respect to action <NUM> of <FIG>. As discussed in <FIG>, the encrypted next PMSI and PMSI tracking index values may be included with an authentication information response together with an authentication vector.

At step <NUM>, the server <NUM> transmits the authentication information response that includes the encrypted next PMSI and PMSI tracking index values to the MME <NUM>. The MME <NUM> can then engage in mutual authentication with the UE <NUM>. As part of that mutual authentication, the MME <NUM> can transmit the encrypted next PMSI and PMSI tracking index values without having decrypted the information at the MME <NUM>.

After the UE <NUM> confirms the next PMSI value, for example according to one or more of steps <NUM>-<NUM> of <FIG>, the method <NUM> proceeds to step <NUM>. At step <NUM>, once the UE <NUM> has confirmed the next PMSI value or otherwise has completed synchronization (e.g., by sending a new proposed next PMSI value, requesting a new next PMSI value, or adjusting its local PMSI tracking index to reflect the value of the received and decrypted PMSI tracking index), the server <NUM> receives an authentication token from the UE <NUM> via the MME <NUM>. In response, the server <NUM> then updates its PMSI information (e.g., the server <NUM> updates the previous PMSI to reflect the current PMSI value (the PMSI used in the current attach procedure) and the current PMSI to reflect the synchronized next PMSI value). The UE <NUM> and the serving network <NUM> may continue with establishing a communication session as will be recognized.

Turning now to <FIG>, a flowchart illustrates an exemplary method <NUM> for PMSI initialization with respect to a UE in accordance with the claimed invention. The method <NUM> may be implemented in UE <NUM> that is in communication with base station <NUM> and MME <NUM>. The method <NUM> will be described with respect to a single UE <NUM> for simplicity of discussion, though it will be recognized that the aspects described herein may be applicable to a plurality of UEs <NUM>. It is understood that additional steps can be provided before, during, and after the steps of method <NUM>, and that some of the steps described can be replaced or eliminated for other embodiments of the method <NUM>.

At step <NUM>, the UE <NUM> starts the initialization process. This may occur at the time of provisioning of the UE <NUM> (e.g., programming the SIM card of the UE <NUM> with IMSI and PMSI values according to aspects of the present disclosure) or at some later time.

At decision step <NUM>, the UE <NUM> determines whether it already has a PMSI that was initialized at the time of provisioning. This may be done, for example, in cooperation between the processor <NUM>, memory <NUM>, and PMSI module <NUM>. If the PMSI has already been initialized, then the method <NUM> proceeds to step <NUM> where the initial PMSI is stored and the PMSI initialization method <NUM> ends. If the PMSI has not already been initialized, then the method <NUM> proceeds to step <NUM>.

At step <NUM>, the processor <NUM> and the PMSI module <NUM> cooperate together and generate a proposed initial PMSI. The proposed initial PMSI may be based upon any variety of factors. In an embodiment, the proposed initial PMSI may be based upon the UE <NUM>'s IMSI, for example based on one or more hashing functions and/or iterations combined with a random or pseudo-random number. In another embodiment, the PMSI is not based upon the IMSI of the UE <NUM> but rather a random or pseudo-random number, to name just a few examples, so that any eavesdroppers would be unable to derive the IMSI from the PMSI.

At step <NUM>, the processor <NUM> and the PMSI module <NUM> cooperate together and encrypt the proposed initial PMSI generated at step <NUM>. In an embodiment, the PMSI is encrypted using a public key that the server <NUM> shared with the UE <NUM> at some time previously. The server <NUM> has a corresponding private key for decrypting the PMSI upon receipt.

At step <NUM>, the UE <NUM> transmits, via the transceiver <NUM>, the encrypted PMSI to the server <NUM>, for example via the base station <NUM> and/or the MME <NUM>.

At step <NUM>, the UE <NUM> receives (via the transceiver <NUM>) a response from the server <NUM> acknowledging receipt of the proposed initial PMSI.

At decision step <NUM>, the processor <NUM> and the PMSI module <NUM> cooperate together and determine whether the response received from the server <NUM> indicates that the server <NUM> accepted the proposed initial PMSI. If the response indicates that the server <NUM> accepted the proposed initial PMSI, then the method <NUM> proceeds to step <NUM> where the initial PMSI is stored and method <NUM> ends. If the response indicates that the server <NUM> did not accept the proposed initial PMSI, then the method <NUM> returns to step <NUM> to generate a new proposed initial PMSI that is different from the one just rejected. The proposed initial PMSI may be rejected, for example, where there is a collision between the PMSI and any other PMSI of another associated UE already stored, e.g. in the database <NUM> of the server <NUM>.

The method <NUM> may repeat until a PMSI is arrived that is agreeable to both the UE <NUM> and the server <NUM>. In an alternative embodiment, if at decision step <NUM> the UE <NUM> determines that the server <NUM> did not accept the proposed initial PMSI, the UE <NUM> may also look at the response from the server <NUM> (the same or a different response as at step <NUM>) to identify whether the server <NUM> sent its own proposed initial PMSI for the UE <NUM>. In this embodiment, the UE <NUM> may check the proposed initial PMSI from the server <NUM> to determine if it is acceptable or not to the UE <NUM>. Barring any issues, the UE <NUM> may accept the proposed initial PMSI from the server <NUM> and notify the server <NUM> of the acceptance. Once an initial PMSI is agreed upon, the initial PMSI is stored at the UE <NUM> for subsequent use and the method <NUM> ends at step <NUM>.

<FIG> is a flowchart illustrating an exemplary method <NUM> for an attach process using a PMSI with respect to a server according to an example helpful for understanding the invention. The method <NUM> will be described with respect to a single server <NUM> and single UE <NUM> for simplicity of discussion, though it will be recognized that the aspects described herein may be applicable to any number of servers <NUM> and/or UEs <NUM>. It is understood that additional steps can be provided before, during, and after the steps of method <NUM>, and that some of the steps described can be replaced or eliminated for other embodiments of the method <NUM>.

At step <NUM>, the server <NUM> receives an encrypted, proposed initial PMSI from a UE <NUM>, for example via the transceiver <NUM>.

At step <NUM>, the server <NUM> decrypts the received PMSI, for example by the processor <NUM>, memory <NUM>, and PMSI module <NUM> in cooperation. In an embodiment, the received PMSI was encrypted with a public key at the UE <NUM> that corresponds to a private key kept at or for the server <NUM>.

At step <NUM>, the server <NUM> compares the received, decrypted PMSI with other PMSI values that already exist for other UEs at the database <NUM> (or in any other database at the server <NUM> or elsewhere that maintain information for a plurality of UEs and which are accessible by the server <NUM>).

At step <NUM>, the server <NUM> determines whether there are any collisions between the received, proposed initial PMSI and any other PMSI values stored or otherwise accessible by the server <NUM>.

At decision step <NUM>, the server <NUM> decides to accept the proposed initial PMSI or not, based on the determination at step <NUM>. If the server <NUM> accepts the proposed initial PMSI, the method <NUM> proceeds to step <NUM> where the server <NUM> sends an acknowledgement of acceptance of the initial PMSI to the UE <NUM>, and stores the initial PMSI at the server <NUM> in the database <NUM> so that it is associated with the UE <NUM> (e.g., as part of the record the server <NUM> keeps for the UE <NUM>).

If at decision step <NUM> the server <NUM> determines that it does not accept the proposed initial PMSI, the method <NUM> proceeds to step <NUM> where the server <NUM> requests a new PMSI from the UE <NUM>, which the server <NUM> transmits to the UE <NUM> and awaits a response. In an alternative embodiment, the server <NUM> may instead generate on its own accord a proposed initial PMSI (in response to decision step <NUM>) and transmit that with the denial to the UE <NUM>.

Also, as used herein, including in the claims, " or " as used in a list of items (for example, a list of items prefaced by a phrase such as "at least one of" or "one or more of") indicates an inclusive list such that, for example, a list of [at least one of A, B, or C] means A or B or C or AB or AC or BC or ABC (i.e., A and B and C).

Embodiments of the present disclosure include a user equipment (UE) comprising means for sending a privacy mobile subscriber identity (PMSI) in place of an international mobile subscriber identity (IMSI) to identify the UE with an initial attach message to a serving network; means for receiving, from the serving network, an authentication request that includes a next PMSI determined by a server in communication with the serving network, the next PMSI being derived from the PMSI; and means for sending an acknowledgment of receipt of the next PMSI to the server via the serving network.

The UE further includes means for deriving the PMSI from a previous PMSI, wherein the previous PMSI comprises an initial PMSI. The UE further includes means for deriving the PMSI from a previous PMSI, wherein the previous PMSI comprises a PMSI value derived from an initial PMSI. The UE further includes means for determining, by the UE, the PMSI for network access based on an initial PMSI. The UE further includes means for receiving the initial PMSI during a subscriber registration of the UE with the server. The UE further includes means for provisioning the initial PMSI after a subscriber registration via an over-the-air communication with the server. The UE further includes means for generating a proposed PMSI; means for encrypting the generated PMSI using a server public key, wherein the server maintains a corresponding server private key; and means for receiving acknowledgement from the server to use the generated PMSI as the initial PMSI. The UE further includes means for determining a UE-based next PMSI; and means for comparing the UE-based next PMSI to the next PMSI received as part of the authentication request to determine if there is a match. The UE further includes means for generating an acknowledgement token in response to determining there is a match, the acknowledgement of receipt comprising the acknowledgement token; and means for storing the confirmed next PMSI at the UE for use in a next attach message. The UE further includes means for decrypting the next PMSI in the authentication request using an anonymity key, wherein the anonymity key is derived from a secret key shared between the UE and the server.

Embodiments of the present disclosure further include a server comprising means for receiving, from a user equipment (UE) via one or more network elements in an intervening serving network, a privacy mobile subscriber identity (PMSI) in place of an international mobile subscriber identity (IMSI) to identify the UE from an initial attach message; means for determining, by the server, a next PMSI based on the PMSI; means for transmitting, from the server, authentication information to the serving network that includes the next PMSI, wherein the next PMSI is relayed by the serving network to the UE as part of authentication; and means for receiving, from the UE via the serving network, an acknowledgement of receipt that includes confirmation of the next PMSI.

The server further includes means for deriving the next PMSI from a previous PMSI, wherein the previous PMSI comprises an initial PMSI. The server further includes means for deriving the next PMSI from a previous PMSI, wherein the previous PMSI comprises a PMSI value derived from an initial PMSI. The server further includes means for determining, by the server, the PMSI for network access based on an initial PMSI. The server further includes means for receiving, at the server, the initial PMSI during a subscriber registration of the UE with the server. The server further includes means for receiving, from the UE, a proposed initial PMSI; means for decrypting, by the server, the proposed initial PMSI using a server private key that was encrypted at the UE by a corresponding server public key; and means for transmitting, to the UE, an acknowledgement of the proposed initial PMSI as the initial PMSI. The server further includes means for deriving an anonymity key from a secret key shared between the server and the UE; means for encrypting the next PMSI in the authentication information using the derived anonymity key; means for receiving, as part of the acknowledgment, an acknowledgement token acknowledging the next PMSI; and means for storing the next PMSI in place of the PMSI at the server for use in responding to a subsequent initial attach message from the UE. The server further includes means for detecting a collision between the next PMSI and another existing PMSI associated with a different UE; and means for incrementing a PMSI index and determining a new next PMSI based on the next PMSI and the incremented PMSI index. The server further includes means for receiving, from a mobility management entity (MME) on the serving network separate from a home network that the server is on, a request for the IMSI of the UE; and means for sending, in response to the request, the PMSI of the UE used in the initial attach message instead of the IMSI of the UE. The server further includes means for searching one or more databases for a match to the PMSI included with the initial attach message; and means for sending, in response to not locating a match, a notice for the UE to modify a PMSI index maintained at the UE for generation of an updated PMSI at the UE.

Embodiments of the present disclosure further include a method for network access by a user equipment (UE), comprising determining, by the UE, to attach at a serving network; and sending, from the UE, an initial attach message to the serving network including a temporary identifier (ID) in place of a permanent ID for the UE, wherein a security context with an authentication server (HSS) of the serving network is established based on the temporary ID.

The method further includes receiving, from the HSS of the serving network, an authentication request that includes a next temporary ID determined by the HSS, the next temporary ID being derived from the temporary ID included in the initial attach message. The method further includes sending, from the UE, an acknowledgement of receipt of the next temporary ID to the HSS via the serving network.

Embodiments of the present disclosure further include a user equipment comprising a memory configured to store a temporary identifier (ID); a processor configured to determine to attach at a serving network; and a transceiver configured to send an initial attach message to the serving network including the temporary ID in place of a permanent ID for the UE, wherein a security context with an authentication server (HSS) of the serving network is established based on the temporary ID.

The UE further includes wherein the transceiver is further configured to receive, from the HSS of the serving network, an authentication request that includes a next temporary ID determined by the HSS, the next temporary ID being derived from the temporary ID included in the initial attach message. The UE further includes wherein the processor is further configured to generate an acknowledgement of receipt, and the transceiver is further configured to send the acknowledgment of receipt to the HSS via the serving network.

Embodiments of the present disclosure further include a method for setting up network access with a server on a network, comprising receiving, from a user equipment (UE) via a serving network, an initial attach message including a temporary identifier (ID) in place of a permanent ID for the UE; and establishing a security context based on the temporary ID.

The method further includes determining a next temporary ID based on the temporary ID included in the initial attach message. The method further includes transmitting, from the server, authentication information that includes the next temporary ID to the UE via the serving network as part of authentication. The method further includes receiving, from the UE via the serving network, an acknowledgement of receipt that includes confirmation of the next temporary ID.

Embodiments of the present disclosure further include a server comprising a transceiver configured to receive, from a user equipment (UE) via a serving network, an initial attach message including a temporary identifier (ID) in place of a permanent ID for the UE; and a processor configured to establish a security context based on the temporary ID.

The server further comprises wherein the processor is further configured to determine a next temporary ID based on the temporary ID included in the initial attach message. The server further comprises wherein the transceiver is further configured to transmit authentication information that includes the next temporary ID to the UE via the serving network as part of authentication. The server further comprises wherein the transceiver is further configured to receive, from the UE via the serving network, an acknowledgement of receipt that includes confirmation of the next temporary ID.

Claim 1:
A method, comprising:
initiating (<NUM>), by a user equipment, UE, registration with a serving network;
in response to determining (<NUM>) that the UE has no proposed privacy mobile subscriber identity, PMSI, initialized, generating (<NUM>), by the UE, a PMSI to be used instead of an international mobile subscriber identity, IMSI;
encrypting (<NUM>), by the UE, the generated PMSI;
transmitting (<NUM>), by the UE to the serving network, the proposed PMSI over the air; and
storing and using, by the UE, the proposed PMSI as an initial PMSI for an initial attach message in response to receiving (<NUM>) an acknowledgment message from the serving network indicating acceptance of the proposed PMSI.