Patent Description:
This section introduces aspects that may be helpful in facilitating a better understanding of the inventions.

Fourth generation (<NUM>) wireless mobile telecommunications technology, also known as Long Term Evolution (LTE) technology, was designed to provide high capacity mobile multimedia with high data rates particularly for human interaction. Next generation or fifth generation (<NUM>) technology is intended to be used not only for human interaction, but also for machine type communications in so-called Internet of Things (IoT) networks.

While <NUM> networks are intended to enable massive IoT services (e.g., very large numbers of limited capacity devices) and mission-critical IoT services (e.g., requiring high reliability), improvements over legacy mobile communication services are supported in the form of enhanced mobile broadband (eMBB) services providing improved wireless Internet access for mobile devices.

Security management is an important consideration in any communication system. For example, security of communications between user equipment initially accessing a communication network or seeking to move from a source communication network to a target communication network are examples of security management in both <NUM> and <NUM> networks. However, security of such communications presents several challenges, particularly when malicious actors attempt to gain access to communication networks.

The document <CIT> discloses that a location management device function is provided in an access network, and a base station identifies and authenticates a terminal device permitted to perform base station loopback communication on the basis of identification information on the terminal device received from the terminal device. With this configuration, provided is a communication control method and the like for the base station device that has lost connectivity to a core network, to permit only specific terminals to perform base station loopback communication.

The document <CIT> discloses a method for use in a mobile radio communications network connection procedure and including the step of rejecting at a mobile radio communications device a handover request from a network responsive to determination of support of the security algorithm associated with the handover, and for a mobile radio communications device arranged to determine support of security algorithms as proposed by the network, preferably at AS level, within a handover command, and to provide notification to the network of rejection of the connection due to non-support of the algorithm.

Illustrative embodiments provide improved techniques for security management in communication systems.

According to the present invention, there are provided apparatuses, methods and a non-transitory computer-readable storage medium, as defined by the claims.

These and other features and advantages of embodiments described herein will become more apparent from the accompanying drawings and the following detailed description.

Embodiments will be illustrated herein in conjunction with example communication systems and associated techniques for providing security management in communication systems. It should be understood, however, that the scope of the claims is not limited to particular types of communication systems and/or processes disclosed. Embodiments can be implemented in a wide variety of other types of communication systems, using alternative processes and operations. For example, although illustrated in the context of wireless cellular systems utilizing 3GPP system elements such as a 3GPP EPC system (<NUM>) and 3GPP next generation system (<NUM>), the disclosed embodiments can be adapted in a straightforward manner to a variety of other types of communication systems.

In accordance with illustrative embodiments implemented in <NUM> and <NUM> communication system environments, one or more 3GPP technical specifications (TS) and technical reports (TR) provide explanation of user equipment and network nodes and/or operations that interact in one or more illustrative embodiments. For example, illustrative embodiments use and/or modify system architectures and methodologies described in 3GPP Technical Specification (TS) <NUM>, V15. <NUM>, entitled "Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for <NUM> System (5GS)," and in 3GPP TS <NUM>, V15. <NUM>, entitled "Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS),". Other 3GPP TS/TR documents provide other conventional details that one of ordinary skill in the art will realize. However, while illustrative embodiments are well-suited for implementation associated with the above-mentioned 3GPP standards, alternative embodiments are not necessarily intended to be limited to any particular standards.

Currently in wireless communication systems such as 3GPP <NUM> or <NUM> networks, when a user device (user equipment or UE) first attaches to a network, the user device indicates its security capabilities such as supported encryption algorithms and supported integrity algorithms to the network. Upon receiving the device security capabilities, the network then selects the algorithms to be used based at least in part on both the supported security algorithms indicated by the user device and the network supported security algorithms.

<FIG> illustrates a system <NUM> where a UE <NUM> indicates security capabilities <NUM> when accessing a <NUM> core network via 3GPP access. The system <NUM> includes the UE <NUM>, a 3GPP access network <NUM>, an NG radio access network (NG-RAN) <NUM>, an access management function (AMF) <NUM>, elements <NUM> that provide the functionality of a <NUM> home subscriber service (HSS) in the <NUM> network including an authentication server function (AUSF) <NUM>, user data management (UDM) <NUM> and user data repository (UDR) <NUM>, a session management function (SMF) <NUM>, a policy control function (PCF) <NUM>, a user plane function (UPF) <NUM> and a data network (DN) <NUM>. <FIG> also illustrates the reference points representing interactions between such elements (e.g., the N12 reference point between the AMF <NUM> and AUSF <NUM>, the N13 reference point between the AUSF <NUM> and the UDM <NUM>, etc.). The UE <NUM> provides an indication of security capabilities <NUM> to the AMF <NUM> via the 3GPP access network <NUM> and NG-RAN <NUM> as illustrated.

<FIG> illustrates a system <NUM> where the UE <NUM> indicates security capabilities <NUM> when accessing a <NUM> core network via non-3GPP access. The system <NUM> includes many of the same elements as system <NUM> (e.g., the UE <NUM>, AMF <NUM>, AUSF <NUM>, UDM <NUM>, UDR <NUM>, SMF <NUM>, PCF <NUM>, UPF <NUM> and DN <NUM>). The UE <NUM> in the system <NUM>, however, access the <NUM> core network over a non-3GPP access network <NUM> and non-3GPP interworking function (N3IWF) <NUM> via reference point NWu to provide the indication of security capabilities <NUM>.

<FIG> illustrates a system <NUM> where the UE <NUM> indicates security capabilities <NUM> when accessing a <NUM> core network (e.g., <NUM> evolved packet core (EPC)) via 3GPP access. The system <NUM> includes the UE <NUM>, a 3GPP access network <NUM>, an evolved universal terrestrial access network (E-UTRAN) <NUM>, a mobility management element (MME) <NUM>, HSS <NUM>, serving general packet radio service (GPRS) support node (SGSN) <NUM>, serving gateway (SGW) <NUM>, packet data network (PDN) gateway (PGW) <NUM>, policy and charging rules function (PCRF) <NUM> and DN <NUM>. <FIG> also illustrates the reference points representing interactions between such elements (e.g., the S6a reference point between the MME <NUM> and HSS <NUM>, the S4 reference point between the SGSN <NUM> and SGW <NUM>, etc.). The UE <NUM> provides an indication of security capabilities <NUM> to the MME <NUM> via the 3GPP access network <NUM> and E-UTRAN <NUM> as illustrated.

Besides the normal encryption algorithms and integrity algorithms, there is a need for the UE <NUM> to indicate support of a NULL encryption algorithm (NEA0) and a NULL integrity algorithm (NIA0). These NULL algorithms (NEA0, NIA0) are used to enable UE that cannot be authenticated by the network due to various reasons to establish emergency sessions. If the AMF <NUM> in the <NUM> network (or MME <NUM> in the <NUM> network) allows unauthenticated UE in a limited service state to establish an emergency session, then the AMF <NUM> (or MME <NUM>) can select the NULL encryption algorithm (NEA0) and the NULL integrity algorithm (NIA0) as the integrity and encryption algorithms in order to establish the emergency session.

Before describing further details of the above-mentioned and other methodologies according to illustrative embodiments, illustrative configurations of a UE and a network node will first be described.

<FIG> is a block diagram of a system <NUM> including a UE <NUM> and a network node (e.g., a network element, a network function or another network entity) <NUM> configured to provide security management functionality in one or more illustrative embodiments. It is to be appreciated that the network node <NUM> may represent any network element, network function or other network entity that is configured to provide security management functionality as described herein. By way of example, but not limited thereto, network node <NUM> may be an AMF in a <NUM> network (e.g., AMF <NUM>) or an MME in a <NUM> network (e.g., MME <NUM>). Network node <NUM> is considered an example of what is more generally referred to herein as a "security management node. " UE <NUM>, in illustrative embodiments, attaches to <NUM> network via a gNB (<NUM>) or attaches to <NUM> network via an eNB (<NUM>).

The UE <NUM> comprises a processor <NUM> coupled to a memory <NUM> and interface circuitry <NUM>. The processor <NUM> of UE <NUM> includes a security management processing module <NUM> that may be implemented at least in part in the form of software executed by the processor <NUM>. The security management processing module <NUM> performs security management functionality as described in conjunction with subsequent figures and otherwise herein. The memory <NUM> of UE <NUM> includes a security management storage module <NUM> that stores data generated or otherwise used during security management operations.

The network node <NUM> comprises a processor <NUM> coupled to a memory <NUM> and interface circuitry <NUM>. The processor <NUM> of the network node <NUM> includes a security management processing module <NUM> that may be implemented at least in part in the form of software executed by the processor <NUM>. The processing module <NUM> performs security management functionality as described in conjunction with subsequent figures and otherwise herein. The memory <NUM> of the network node <NUM> includes a security management storage module <NUM> that stores data generated or otherwise used during security management operations.

The processors <NUM> and <NUM> of the respective UE <NUM> and network node <NUM> may comprise, for example, microprocessors, application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs) or other types of processing devices or integrated circuits, as well as portions or combinations of such elements. Such integrated circuit devices, as well as portions or combinations thereof, are examples of "circuitry" as that term is used herein. A wide variety of other arrangements of hardware and associated software or firmware may be used in implementing the illustrative embodiments.

The memories <NUM> and <NUM> of the respective UE <NUM> and network node <NUM> may be used to store one or more software programs that are executed by the respective processors <NUM> and <NUM> to implement at least a portion of the functionality described herein. For example, security management operations and other functionality as described in conjunction with subsequent figures and otherwise herein may be implemented in a straightforward manner using software code executed by processors <NUM> and <NUM>.

A given one of the memories <NUM> or <NUM> may therefore be viewed as an example of what is more generally referred to herein as a computer program product or still more generally as a processor-readable storage medium that has executable program code embodied therein. Other examples of processor-readable storage media may include disks or other types of magnetic or optical media, in any combination. Illustrative embodiments can include articles of manufacture comprising such computer program products or other processor-readable storage media.

The memory <NUM> or <NUM> may more particularly comprise, for example, an electronic random-access memory (RAM) such as static RAM (SRAM), dynamic RAM (DRAM) or other types of volatile or non-volatile electronic memory. The latter may include, for example, non-volatile memories such as flash memory, magnetic RAM (MRAM), phase-change RAM (PC-RAM) or ferroelectric RAM (FRAM). The term "memory" as used herein is intended to be broadly construed, and may additionally or alternatively encompass, for example, a read-only memory (ROM), a disk-based memory, or other type of storage device, as well as portions or combinations of such devices.

The interface circuitries <NUM> and <NUM> of the respective UE <NUM> and network node <NUM> illustratively comprise transceivers or other communication hardware or firmware that allows the associated system elements to communicate with one another in the manner described herein.

It is apparent from <FIG> that UE <NUM> is configured for communication with network node <NUM> and vice-versa via their respective interface circuitries <NUM> and <NUM>. This communication involves UE <NUM> sending data to the network node <NUM>, and the network node <NUM> sending data to the UE <NUM>. Other network elements may be operatively coupled between, as well as to, UE <NUM> and network node <NUM>. For example, in illustrative embodiments, UE <NUM> and network node <NUM> communicate through an access point such as an eNB in a <NUM> network or a gNB in a <NUM> network. The term "data" as used herein is intended to be construed broadly so as to encompass any type of information that may be sent between the UE <NUM> and the network node <NUM> of a core network including, but not limited to, requests, notifications, tokens, identifiers, keys, indicators, user data, control data, other messages, etc..

It is to be appreciated that the particular arrangement of components shown in <FIG> is an example only, and numerous alternative configurations are used in other embodiments. For example, any UE and/or network node can be configured to incorporate additional or alternative components and to support other communication protocols.

Other system elements may each also be configured to include components such as a processor, memory and network interface. These elements need not be implemented on separate stand-alone processing platforms, but could instead, for example, represent different functional portions of a single common processing platform.

Further detailed descriptions of the above-mentioned and other methodologies according to illustrative embodiments will now be described.

Currently, for <NUM> networks, the network assumes that user devices will send their supported encryption algorithms and integrity algorithms during UE registration and handover to N1 mode, and that the user devices will format the UE security capabilities bitmap correctly. <FIG> shows an example of the UE security capabilities <NUM> (e.g., a set of <NUM> system (5GS) encryption and integrity algorithms including the NULL encryption and integrity algorithms NEA0 and NIA0 as well as 5GS encryption and integrity algorithms such as <NUM>-NEA1, <NUM>-NEA2, <NUM>-NEA3, <NUM>-NIA1, <NUM>-NIA2, <NUM>-NIA3, etc.) which are formatted as shown in bitmap <NUM>.

A similar assumption is made for <NUM> networks, where the network assumes that user devices will send their supported encryption algorithms and integrity algorithms during UE attach and handover to S1 mode, and that the user devices will format the UE security capabilities bitmap correctly. <FIG> shows an example of the UE security capabilities <NUM> (e.g., a set of evolved packet system (EPS) encryption and integrity algorithms including the NULL encryption and integrity algorithms EEA0 and EIA0 as well as EPS encryption and integrity algorithms such as <NUM>-EEA1, <NUM>-EEA2, <NUM>-EEA3, <NUM>-EIA1, <NUM>-EIA2, <NUM>-EIA3, etc.) which are formatted as shown in bitmap <NUM>.

In a <NUM> network, the AMF (e.g., AMF <NUM>) selects an encryption algorithm and an integrity algorithm based at least in part on the 5GS encryption and integrity algorithms supported by the UE (e.g., UE <NUM>) and the operator configuration. Similarly, in a <NUM> network, the MME (e.g., MME <NUM>) selects an encryption algorithm and an integrity algorithm based at least in part on EPC encryption and integrity algorithms supported by the UE (e.g., UE <NUM>) and the operator configuration.

The above processing, however, covers or handles only "normal" cases. For "abnormal" cases, handling has not been defined. This results in various field issues, such as cases of attacks where illegal all-zero security capabilities were provided by malicious UE leading to a wrong selection of integrity and encryption algorithms (e.g., EEA7, EIA7). Further, there could be other unacceptable or unsupported algorithm combinations indicated by a UE (e.g., UE <NUM>) which the network is not able to support. Accordingly, there is a need to define mechanisms for handling such abnormal cases, including to prevent the above-described security attacks from malicious UE.

In addition, for a <NUM> network, when the UE indicates security capabilities during a mobility scenario, related handling on the network side could be different depending on whether there has been a change between the UE-indicated security capabilities (e.g., provided by the UE to a target AMF as part of a mobility registration request) and the UE security capabilities retrieved from a source AMF. Such network-side handling has not been defined. Similarly, network-side handling needs to be defined for UE security capability indications during mobility events in a <NUM> network (e.g., as part of handling tracking area update requests from a UE).

Illustrative embodiments provide methods for abnormal case handling, to prevent security attacks from malicious UE and to handle other abnormal cases. Illustrative embodiments enable the communication network to reject the UE's request to access the network if the indicated security capabilities from the UE do not meet one or more designated criteria of the communication network. The designated criteria may include, for example, determining whether one or more encryption and integrity algorithms supported by the UE match one or more encryption algorithms supported by the communication network. In the description below, the security capabilities of the UE not meeting the one or more designated criteria of the communication network is also referred to as the security capabilities of the UE being invalid or unacceptable. In some cases, the security capabilities of the UE are valid but not acceptable (e.g., such as where the communication network does not support encryption and/or integrity algorithms indicated by the UE security capabilities). In other cases, the security capabilities may be invalid and unacceptable (e.g., if the security capabilities of the UE are acceptable to the communication network, the UE security capabilities are assumed to be valid).

Some embodiments provide methods to enable a <NUM> network to reject a user device (e.g., during registration, including both initial registration and mobility registration) if the UE 5GS security capabilities (e.g., 5GS encryption algorithms or 5GS integrity algorithms) indicated by the user device are not acceptable. This is accomplished by adding logic to enable the <NUM> network to check the UE's security capability indication during UE registration (e.g., for both initial registration and mobility registration requests) and to reject the registration request if the indicated UE security capability is not acceptable. Further, a new failure or reject cause code can be defined to enable the network to indicate to the UE that the registration or handover failure is due to the device security capability not being acceptable or alternatively a generic failure cause code can be used to signal attach or handover failure to the UE. In addition, corresponding UE behavior and back-off handling mechanisms are specified as described in further detail below. Methods are also provided for handling UE security capability indications and changes during mobility in the <NUM> network.

In other embodiments, methods are provided to enable a <NUM> network to reject a user device if the indicated UE EPS security capabilities (e.g., EPS encryption algorithms or EPS integrity algorithms) indicated by the user device are not acceptable. This is accomplished by adding logic to enable the <NUM> network to check the UE security capability indication during UE attach (e.g., for both initial attach and mobility tracking area update), and to reject the attach request if the indicated UE security capability is not acceptable. Further, a new failure cause code can be defined to enable the network to indicate to the UE that the attach or handover failure is due to the device security capability not being acceptable or alternatively a generic failure cause code can be used to signal attach or handover failure to the UE. In addition, corresponding UE behavior and back-off handling mechanisms are specified as described in further detail below. Methods are also provided for handling UE security capability indications and changes during mobility in the <NUM> EPC network.

It is to be appreciated that in some <NUM> embodiments, the AMF (e.g., AMF <NUM>) is configured to provide the functionality that enables the improved security management described herein, while in some <NUM> embodiments the MME (e.g., MME <NUM>) is configured to do the same. In other embodiments, however, one or more other network nodes or entities are configured to provide part or all of the functionality that enables improved security management as described herein. Further, the UE (e.g., UE <NUM>) is also configured to provide corresponding functionality for enabling the improved security management described herein.

Methods for enabling a <NUM> network to reject a UE during initial registration if the indicated 5GS security capabilities of the UE (e.g., 5GS encryption algorithms, 5GS integrity algorithms, combinations thereof) are not acceptable will now be described. Logic is added (e.g., in the AMF <NUM>) to enable the <NUM> network to check the UE security capability indication during UE registration, and to reject the request if the UE security capabilities are not acceptable (e.g., due to the supported 5GS encryption algorithms, 5GS integrity algorithms, or combinations thereof indicated by the UE not being acceptable to the <NUM> network). When initiating an initial registration request, the UE (e.g., UE <NUM>) indicates support for different 5GS encryption and integrity algorithms in the UE security capability information element (IE) of the registration request message. If the UE-indicated 5GS encryption or integrity algorithms (or combinations thereof) are not valid or acceptable to the <NUM> network, the <NUM> network rejects the initial registration request. To do so, the <NUM> network sets the 5GS mobility management (5GMM) cause value to "UE security capabilities invalid or unacceptable" or a generic failure cause code (e.g. UE security capabilities mismatch or Protocol error, unspecified, etc.) and assigns a back-off timer Txxxx.

The UE-indicated 5GS encryption or integrity algorithms may be unacceptable to the <NUM> network for various reasons. <FIG> shows examples of different cases where the 5GS encryption algorithm bitmap <NUM> is unacceptable to the <NUM> network. Bitmap <NUM>-<NUM> illustrates a first case, where the 5GS encryption algorithm bits are all zero (e.g., no 5GS encryption algorithms are supported by the UE). Bitmap <NUM>-<NUM> illustrates a second case, where the 5GS integrity algorithm bits are all zero (e.g., no 5GS integrity algorithms are supported by the UE). Bitmap <NUM>-<NUM> illustrates a third case, where the bit for a mandatory 5GS encryption algorithm is zero (e.g., <NUM>-NEA1 is not supported by the UE). Bitmap <NUM>-<NUM> illustrates a fourth case, where the bit for a mandatory 5GS integrity algorithm is zero (e.g., <NUM>-NIA1 is not supported by the UE). It should be appreciated, however, that various other unsupported cases are possible. For example, in some cases the 5GS encryption algorithm bitmap <NUM> will indicate that the UE does not support a valid combination of 5GS encryption and integrity algorithms (e.g., the UE supports <NUM>-NEA1 but not <NUM>-NIA1).

A new failure cause code can be defined to enable the network to indicate to the UE that the registration or handover failure is due to the UE-indicated security capability not being acceptable or alternatively a generic failure cause code can be used to signal attach or handover failure to the UE. The 5GMM cause IE indicates the reason why a 5GMM request from a UE is rejected by the network. <FIG> shows an example 5GMM cause IE <NUM>. A new failure cause code, can be defined to signal registration or handover failure to the UE due to the UE security capabilities not being acceptable or a generic failure cause code (e.g., UE security capabilities mismatch or Protocol error, unspecified, etc.) to signal attach or handover failure to the UE. The 5GMM cause is sent to the UE if the network detects that the security capabilities indicated by the UE are unacceptable (e.g., one of cases <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM> described above, or another case of invalid or unacceptable UE-indicated support for 5GS encryption and integrity algorithms). The 5GMM failure cause is signaled using the 5GMM cause IE <NUM> as shown in table <NUM> in <FIG>.

UE behavior and back-off handling mechanisms will now be described. If the UE's registration request cannot be accepted by the network due to the UE-indicated security capabilities not being valid or acceptable, the AMF sends a registration reject message to the UE that includes an appropriate 5GMM cause value (e.g., the new 5GMM cause value described above "UE security capabilities invalid or unacceptable" or a generic failure cause code). When the UE receives the registration reject message including the 5GMM cause value indicating that the UE security capabilities are invalid or unacceptable, the UE takes the following actions. The UE will abort the registration procedure (e.g., either an initial registration procedure or a mobility registration procedure) and reset the registration attempt counter. The UE also sets the 5GS update status to "5U2 NOT UPDATED" and enters the state "5GMM-DEREGISTERED. ATTEMPTING-REGISTRATION.

If the registration reject message includes a timer value (e.g., a Txxxx value IE) that indicates that the timer is neither zero nor deactivated, the UE will stop the timer Txxxx if it is running. If the registration reject message is integrity protected, the UE starts the timer Txxxx with the value provided in the Txxxx value IE. If the registration reject message is not integrity protected, the UE starts the timer Txxxx with a random value from a default range (e.g., <NUM> to <NUM> minutes). The UE stays in the current serving cell, and applies the normal cell reselection process. The initial registration procedure is started, if still needed, with updated UE security capability indication in UE network capability IE when the timer Txxxx expires or is stopped. Optionally, the UE may enter state 5GMM-DEREGISTERED. PLMN-SEARCH in order to perform a public land mobile network (PLMN) selection.

If the UE is operating in single-registration mode, the UE handles the EPS mobility management (EMM) parameters EMM state, EPS update status and attach attempt counter for the case when the EPS attach request procedure is rejected with the EMM cause set to the same value (e.g., "UE security capabilities invalid or unacceptable").

<FIG> and <FIG> illustrate a message flow <NUM> for a security management procedure in a <NUM> network that results in a successful initial registration. In step <NUM>, UE <NUM> sends a registration request to AMF <NUM>. The registration request includes various parameters, such as a <NUM> key set identifier (ngKSI), a mobile identity, UE security capabilities, and a registration type. In the message flow <NUM>, the registration type is assumed to comprise an initial registration. In step <NUM>, the AMF <NUM> selects encryption and integrity algorithms (e.g., among those supported by the UE <NUM> as indicated in the UE security capabilities included in the step <NUM> registration request). In step <NUM>, authentication is performed by the UE <NUM>, the AMF <NUM> and the AUSF <NUM>.

The AMF <NUM> in step <NUM> generates a non-access stratum (NAS) security context. The NAS security context is based at least in part on various parameters, such as the selected encryption and integrity algorithms from step <NUM>, the UE security capability, ngKSI, and keys. The AMF <NUM> in step <NUM> sends a secure mode command to the UE <NUM>, where the secure mode command includes the selected NAS security algorithms and replayed UE security capabilities.

The UE <NUM> in step <NUM> generates the NAS security context, based at least in part on the same parameters discussed above with respect to step <NUM> (e.g., the selected 5GS encryption and integrity algorithms, UE security capabilities, ngKSI and keys). The UE <NUM> in step <NUM> sends a secure mode complete message to the AMF <NUM>. Following this, the AMF <NUM> in step <NUM> sends a registration accept message to the UE <NUM>. The UE <NUM> responds to the AMF <NUM> in step <NUM> with a registration complete message.

<FIG> illustrates a message flow <NUM> for a security management procedure in a <NUM> network that results in an unsuccessful initial registration (e.g., when the UE security capabilities indicate that no 5GS encryption algorithms are supported by the UE <NUM>, or that the 5GS encryption algorithms supported by the UE <NUM> are not supported by the AMF <NUM>). The message flow <NUM> begins with the UE <NUM> sending a registration request to the AMF <NUM> in step <NUM>. The step <NUM> registration request, similar to the registration request in step <NUM> of message flow <NUM>, includes ngKSI, a mobile identity, UE security capabilities and a registration type (which is assumed to be an initial registration in the message flow <NUM>).

In step <NUM>, the AMF <NUM> determines that the UE security capabilities in the registration request are not acceptable. This may be a result of the UE security capabilities indicating that no 5GS encryption algorithms are supported by the UE <NUM> (e.g., case <NUM>-<NUM> in <FIG> where the bitmap includes all zeros for the 5GS encryption algorithms), or that the 5GS encryption algorithms supported by the UE <NUM> cannot be supported by the AMF <NUM> (e.g., case <NUM>-<NUM> in <FIG> where the bitmap includes a zero for a mandatory 5GS encryption algorithm). As a result of the step <NUM> determination, the AMF <NUM> sends a registration reject message to the UE <NUM> in step <NUM>. The registration reject message includes the 5GMM cause "UE security capabilities invalid or unacceptable" along with a timer value as described above. In step <NUM>, the UE <NUM> handles the registration reject message. UE <NUM> processing or handling of the registration reject message will be described in further detail below in conjunction with <FIG>.

<FIG> illustrates a message flow <NUM> for a security management procedure in a <NUM> network that results in an unsuccessful initial registration (e.g., when the UE security capabilities indicate that no 5GS integrity algorithms are supported by the UE <NUM>, or that the 5GS integrity algorithms supported by the UE <NUM> are not supported by the AMF <NUM>). The message flow <NUM> begins with the UE <NUM> sending a registration request to the AMF <NUM> in step <NUM>. The step <NUM> registration request, similar to the registration request in step <NUM> of message flow <NUM> and the registration request in step <NUM> of message flow <NUM>, includes ngKSI, a mobile identity, UE security capabilities and a registration type (which is assumed to be an initial registration in the message flow <NUM>).

In step <NUM>, the AMF <NUM> determines that the UE security capabilities in the registration request are not acceptable. This may be a result of the UE security capabilities indicating that no 5GS integrity algorithms are supported by the UE <NUM> (e.g., case <NUM>-<NUM> in <FIG> where the bitmap includes all zeros for the 5GS integrity algorithms), or that the 5GS integrity algorithms supported by the UE <NUM> cannot be supported by the AMF <NUM> (e.g., case <NUM>-<NUM> in <FIG> where the bitmap includes a zero for a mandatory 5GS integrity algorithm). As a result of the step <NUM> determination, the AMF <NUM> sends a registration reject message to the UE <NUM> in step <NUM>. The registration reject message includes the 5GMM cause "UE security capabilities invalid or unacceptable" along with a timer value as described above. In step <NUM>, the UE <NUM> handles the registration reject message. UE <NUM> processing or handling of the registration reject message will be described in further detail below in conjunction with <FIG>.

Methods for handling UE security capability indications and change during mobility events in a <NUM> network will now be described. A mobility event may include handover from a source AMF to a target AMF. The target AMF checks the UE security capability indication during mobility, and rejects the mobility request (e.g., a registration request with registration type mobility) if the UE security capabilities are not acceptable.

When initiating a mobility registration request, the UE (e.g., UE <NUM>) indicates supported 5GS encryption and integrity algorithms in the UE security capability IE in the registration request message. The target AMF performs UE security context retrieval from the source AMF, as indicated by the UE's <NUM> globally unique temporary identity (<NUM>-GUTI). The target AMF receives from the source AMF the UE's security context, which includes security keys, the UE's security capabilities, and selected security algorithms. If the UE security capabilities are unchanged (e.g., the UE security capabilities received in the UE registration request message are the same as the UE security capabilities received from the source AMF), and if the previously selected security algorithms received from the source AMF can be supported by the target AMF, the target AMF reuses the existing keys from the received security context.

If the UE security capabilities are changed (e.g., the UE security capabilities received in the UE registration request message are different than the UE security capabilities received from the source AMF), the target AMF performs additional processing to determine whether to reject the mobility registration request. If the UE-indicated 5GS encryption and integrity algorithms are valid, and either the UE or the target AMF cannot support the previously-selected security algorithms, the target AMF selects new security algorithms and re-authenticates the UE to establish new security contexts. If the UE-indicated 5GS encryption and integrity algorithms are not valid or not acceptable, the target AMF rejects the UE's mobility registration request. The target AMF, or more generally target network, sets the 5GMM cause value to "UE security capabilities invalid or unacceptable" or a generic failure cause code (e.g., UE security capabilities mismatch or Protocol error, unspecified, etc./) and assigns a back-off timer Txxxx in a manner similar to that described above in the context of handling the initial registration request. The UE behavior and back-off handling mechanisms in response to the rejection of the mobility registration request are similar to those described above in the context of the rejection of the initial registration request.

<FIG> illustrate a message flow <NUM> for a security management procedure in a <NUM> network that results in a successful mobility registration. In step <NUM>, the UE <NUM> sends a registration request to the target AMF <NUM>-<NUM>. The registration request includes various parameters, such as ngKSI, a mobile identity, UE security capabilities, and a registration type (e.g., which is assumed to be mobility registration in the message flow <NUM>). In step <NUM>, the target AMF <NUM>-<NUM> obtains from the source AMF <NUM>-<NUM> the 5GS security context previously established for the UE <NUM>. The 5GS security context includes a key Kamf, the UE security capabilities previously reported by the UE <NUM> to the source AMF <NUM>-<NUM>, and the security algorithms (e.g., 5GS encryption and integrity algorithms) selected by the source AMF <NUM>-<NUM> for the UE <NUM>.

In step <NUM>, the target AMF <NUM>-<NUM> verifies whether the UE security capabilities have changed (e.g., whether the UE security capabilities indicated in the step <NUM> registration request are the same as the security capabilities retrieved from the source AMF <NUM>-<NUM>), and verifies whether the previously-selected security algorithms from the source AMF <NUM>-<NUM> are valid and supported by the target AMF <NUM>-<NUM>. In step <NUM>, if the UE security capabilities are unchanged and the previously-selected security algorithms received from the source AMF <NUM>-<NUM> are valid and can be supported by the target AMF <NUM>-<NUM>, the message flow <NUM> proceeds to step <NUM> where Kamf and the received security context are reused. Otherwise, the message flow <NUM> proceeds to step <NUM>.

The target AMF <NUM>-<NUM> in step <NUM> selects new security algorithms. Step <NUM> is performed in response to various conditions, such as the UE security capabilities being changed, or the previously-selected security algorithms not being acceptable to the target AMF <NUM>-<NUM>. The target AMF <NUM>-<NUM> in step <NUM> decides to re-authenticate the UE <NUM> if new algorithms are selected in step <NUM>, or if the target AMF <NUM>-<NUM> otherwise decides to re-authenticate the UE <NUM> based at least in part on local policy of the target AMF <NUM>-<NUM> (or more generally, the target network). The message flow <NUM> then proceeds to step <NUM>, where the UE <NUM>, target AMF <NUM>-<NUM> and AUSF <NUM> perform authentication. The processing of steps <NUM> through <NUM> may be skipped in some instances (e.g., where the security capabilities are unchanged and the previously-selected security algorithms are acceptable to the target AMF <NUM>-<NUM>), and thus these steps are shown in dashed outline in <FIG>.

The message flow <NUM> proceeds with steps <NUM> through <NUM>, which are similar to steps <NUM> through <NUM>, respectively, in the message flow <NUM>. The target AMF <NUM>-<NUM> generates the NAS security context in step <NUM> and sends the secure mode command to the UE <NUM> in step <NUM>. The UE <NUM> generates the NAS security context in step <NUM> and sends the secure mode complete message to the target AMF <NUM>-<NUM> in step <NUM>. The target AMF <NUM>-<NUM> sends a registration accept message to the UE <NUM> in step <NUM>, and the UE <NUM> sends a registration complete message to the target AMF <NUM>-<NUM> in step <NUM>.

<FIG> illustrates a message flow <NUM> for a security management procedure in a <NUM> network that results in an unsuccessful mobility registration. The mobility registration may be unsuccessful due to the UE security capabilities changing to 5GS encryption and integrity algorithms that are invalid, not supported or otherwise unacceptable to the target AMF <NUM>-<NUM>. The message flow <NUM> begins with step <NUM>, where the UE <NUM> sends a registration request to the target AMF <NUM>-<NUM>. The step <NUM> registration request, similar to the registration request <NUM> in message flow <NUM>, includes parameters such as ngKSI, a mobile identity, UE security capabilities, and a registration type indicating mobility registration. In step <NUM>, the target AMF <NUM>-<NUM> retrieves the 5GS security context from the source AMF <NUM>-<NUM> in a manner similar to that described above with respect to step <NUM> of message flow <NUM>.

The target AMF <NUM>-<NUM> in step <NUM> verifies the UE security capabilities and selected algorithms retrieved from the source AMF <NUM>-<NUM> in step <NUM>. The target AMF <NUM>-<NUM> in step <NUM> determines that the UE security capabilities have changed, and that the 5GS encryption or integrity algorithms (or combinations thereof) indicated by the UE <NUM> in the step <NUM> registration request are invalid, not supported or otherwise not acceptable to the target AMF <NUM>-<NUM> (or, more generally, the target network). The target AMF <NUM>-<NUM> sends a registration reject message to the UE <NUM> in step <NUM>. The registration reject message includes the 5GMM cause "UE security capabilities invalid or unacceptable" along with a timer value. In step <NUM>, the UE <NUM> handles the registration reject message. UE <NUM> processing or handling of the registration reject message will be described in further detail below in conjunction with <FIG>.

<FIG> illustrates a security management procedure in a <NUM> network for UE handling following an unsuccessful initial registration (e.g., step <NUM> in message flow <NUM> or step <NUM> in message flow <NUM>) or mobility registration (e.g., step <NUM> in message flow <NUM>). In step <NUM>, the UE <NUM> aborts the registration procedure (which is an initial registration procedure in message flows <NUM> and <NUM>, and a mobility registration procedure in message flow <NUM>). The UE <NUM> resets the registration attempt counter in step <NUM>, and sets the 5GS update status to "5U2 NOT UPDATED" in step <NUM>. The UE <NUM> then enters the state "5GMM-DEREGISTERED. ATTEMPTING-REGISTRATION" in step <NUM>. The UE <NUM> performs backoff based at least in part on the received timer value (e.g., from the registration reject message in step <NUM>, <NUM> or <NUM>). The UE <NUM> performs cell reselection or PLMN selection in step <NUM>.

Methods for enabling a <NUM> network to reject a user device if the indicated UE EPS security capabilities (e.g., EPS encryption algorithms, EPS integrity algorithms, combinations thereof) are not acceptable will now be described. Logic is added (e.g., in a MME such as MME <NUM>) to enable the <NUM> network to check the UE security capability indication during UE attach and handover, and to reject the request if the UE security capabilities are not acceptable (e.g., due to the supported EPS encryption algorithms, EPS integrity algorithms, or combinations thereof indicated by the UE not being acceptable to the <NUM> network). When initiating an attach request, the UE (e.g., UE <NUM>) indicates supported EPS encryption and integrity algorithms in the UE network capability IE in the attach request message. If the UE-indicated EPS encryption or integrity algorithms (or combinations thereof) are not valid or acceptable to the <NUM> network, the <NUM> network rejects the attach request. To do so, the <NUM> network sets the EPS mobility management (EMM) cause value to "UE security capabilities invalid or unacceptable" or a generic failure cause code (e.g., UE security capabilities mismatch or Protocol error, unspecified, etc.) and assigns a back-off timer Txxxx.

The UE-indicated EPS encryption or integrity algorithms can be unacceptable by the <NUM> network for various reasons. <FIG> shows examples of different cases where the EPS encryption algorithm bitmap <NUM> is unacceptable to the <NUM> network. Bitmap <NUM>-<NUM> illustrates a first case, where the EPS encryption algorithm bits are all zero (e.g., no EPS encryption algorithms are supported by the UE). Bitmap <NUM>-<NUM> illustrates a second case, where the EPS integrity algorithm bits are all zero (e.g., no EPS integrity algorithms are supported by the UE). Bitmap <NUM>-<NUM> illustrates a third case, where the bit for a mandatory EPS encryption algorithm is zero (e.g., <NUM>-EEA1 is not supported by the UE). Bitmap <NUM>-<NUM> illustrates a fourth case, where the bit for a mandatory EPS integrity algorithm is zero (e.g., <NUM>-EIA1 is not supported by the UE). It should be appreciated, however, that various other unsupported cases are possible. For example, in some cases the EPS encryption algorithm bitmap <NUM> will indicate that the UE does not support a valid combination of EPS encryption and integrity algorithms (e.g., the UE supports <NUM>-EEA1 but not <NUM>-EIA1).

A new cause code can be defined to enable the network to indicate to the UE that the registration or handover failure is due to the UE-indicated security capabilities not being acceptable or alternatively a generic failure cause code can be used to signal attach or handover failure to the UE. The EMM cause IE indicates the reason why an EMM request from a UE is rejected by the network. <FIG> shows an example EMM cause IE <NUM>. A new failure cause code, is defined to signal attach or handover failure to the UE due to the UE security capabilities not being acceptable or alternatively a generic failure cause code can be used to signal attach or handover failure to the UE. The EMM cause is sent to the UE if the network detects that the security capabilities indicated by the UE are unacceptable (e.g., one of cases <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM> described above, or another cause of invalid or unacceptable UE-indicated support for EPS encryption and integrity algorithms). The EMM cause is signaled using the EMM cause IE <NUM> as shown in table <NUM> in <FIG>.

UE behavior and back-off handling mechanisms will now be described. If the UE's attach request cannot be accepted by the network due to the UE-indicated security capabilities not being valid or acceptable, the MME sends an attach reject message to the UE including an appropriate EMM cause value (e.g., the new EMM cause value described above, "UE security capabilities invalid or unacceptable"). When the UE receives an attach reject message including the EMM cause value indicating that the UE security capabilities are invalid or unacceptable, the UE takes the following actions. The UE will abort the attach procedure (e.g., either an initial attach or a mobility attach via a tracking area update request) and reset the attach attempt counter. The UE also sets the EPS update status to "EU2 NOT UPDATED" and enters state "EMM-DEREGISTERED. ATTEMPTING-TO-ATTACH.

If the attach reject message includes a timer value (e.g., a Txxxx value IE) that indicates that the timer is neither zero nor deactivated, the UE will stop the timer Txxxx if it is running. Otherwise, the UE will start the timer Txxxx with a random value from a default range (e.g., <NUM> to <NUM> minutes). The UE stays in the current serving cell and applies the normal cell reselection process. When timer Txxxx expires or is stopped, the UE may reattempt an attach procedure with updated UE security capability indication in UE network capability IE.

<FIG> and <FIG> illustrate a message flow <NUM> for a security management procedure in a <NUM> network that results in a successful initial attach. The message flow <NUM> begins with the UE <NUM> sending an attach request to MME <NUM> in step <NUM>. The attach request includes various parameters including a key set identifier (KSI), a mobile identity, UE network capabilities (e.g., supported security algorithms) and an attach type (which is assumed to be an initial attach in the message flow <NUM>). In step <NUM>, the MME <NUM> selects encryption and integrity algorithms from among those indicated as supported by the UE in the attach request that are valid and acceptable to the <NUM> network. Authentication is then performed in step <NUM> by the UE <NUM>, the MME <NUM>, and the home environment (HE) <NUM> (e.g., a home PLMN of the subscriber of UE <NUM>).

The MME <NUM> in step <NUM> generates a NAS security context. The NAS security context is based at least in part on various parameters, such as the selected EPS encryption and integrity algorithms, the UE security capabilities, KSI, and keys. The MME <NUM> in step <NUM> sends a secure mode command to the UE <NUM>, where the secure mode command includes the selected NAS security algorithms and replayed UE security capabilities.

The UE <NUM> in step <NUM> generates the NAS security context, based at least in part on the same parameters discussed above with respect to step <NUM> (e.g., the selected EPS encryption and integrity algorithms, UE security capability, KSI and keys). The UE <NUM> in step <NUM> sends a secure mode complete message to the MME <NUM>. Following this, the MME <NUM> in step <NUM> sends an attach accept message to the UE <NUM>. The UE <NUM> responds to the MME <NUM> in step <NUM> with an attach complete message.

<FIG> illustrates a message flow <NUM> for a security management procedure in a <NUM> network that results in an unsuccessful initial attach (e.g., when the UE security capabilities indicate that no EPS encryption algorithms are supported by the UE <NUM>, or that the EPS encryption algorithms supported by the UE <NUM> are not supported by the MME <NUM>). The message flow <NUM> begins with the UE <NUM> sending an attach request to the MME <NUM> in step <NUM>. The step <NUM> attach request, similar to the attach request in step <NUM> of message flow <NUM>, includes KSI, a mobile identity, UE network capabilities (e.g., supported security algorithms) and an attach type (e.g., EPS attach, or combined EPS/international mobile subscriber identity (IMSI) attach, etc. in the message flow <NUM>).

In step <NUM>, the MME <NUM> determines that the UE security capabilities in the attach request are not acceptable. This may be a result of the UE security capabilities indicating that no EPS encryption algorithms are supported by the UE <NUM> (e.g., case <NUM>-<NUM> in <FIG> where the bitmap includes all zeros for the EPS encryption algorithms), or that the EPS encryption algorithms supported by the UE <NUM> cannot be supported by the MME <NUM> (e.g., case <NUM>-<NUM> in <FIG> where the bitmap includes a zero for a mandatory EPS encryption algorithm). As a result of the step <NUM> determination, the MME <NUM> sends an attach reject message to the UE <NUM> in step <NUM>. The attach reject message includes the EMM cause "UE security capabilities invalid or unacceptable" along with a timer value as described above. In step <NUM>, the UE <NUM> handles the attach reject message. UE <NUM> processing or handling of the attach reject message will be described in further detail below in conjunction with <FIG>.

<FIG> illustrates a message flow <NUM> for a security management procedure in a <NUM> network that results in an unsuccessful initial attach (e.g., when the UE security capabilities indicate that no EPS integrity algorithms are supported by the UE <NUM>, or that the EPS integrity algorithms supported by the UE <NUM> are not supported by the MME <NUM>). The message flow <NUM> begins with the UE <NUM> sending an attach request to the MME <NUM> in step <NUM>. The step <NUM> attach request, similar to the attach request in step <NUM> of message flow <NUM> and the attach request in step <NUM> of message flow <NUM>, includes KSI, a mobile identity, UE network capabilities (e.g., supported security algorithms) and an attach type (which is assumed to be an initial attach in the message flow <NUM>).

In step <NUM>, the MME <NUM> determines that the UE security capabilities in the attach request are not acceptable. This may be a result of the UE security capabilities indicating that no EPS integrity algorithms are supported by the UE <NUM> (e.g., case <NUM>-<NUM> in <FIG> where the bitmap includes all zeros for the EPS integrity algorithms), or that the EPS integrity algorithms supported by the UE <NUM> cannot be supported by the MME <NUM> (e.g., case <NUM>-<NUM> in <FIG> where the bitmap includes a zero for a mandatory EPS integrity algorithm). As a result of the step <NUM> determination, the MME <NUM> sends an attach reject message to the UE <NUM> in step <NUM>. The attach reject message includes the EMM cause "UE security capabilities invalid or unacceptable" along with a timer value as described above. In step <NUM>, the UE <NUM> handles the attach reject message. UE <NUM> processing or handling of the attach reject message will be described in further detail below in conjunction with <FIG>.

Methods for handling UE security capability indications and changes during mobility in a <NUM> EPC network will now be described. A mobility event may include handover from a source MME to a target MME (e.g., in conjunction with a tracking area update message sent from the UE to the target MME). The target MME checks the UE security capability indication during mobility, and rejects the mobility request if the UE security capabilities are not acceptable.

When initiating a mobility tracking area update (TAU) request, the UE (e.g., UE <NUM>) indicates supported EPS encryption and integrity algorithms in the UE security capability IE in the TAU request message. The target MME performs UE security context retrieval from the source MME, as indicated by the UE's globally unique temporary identity (GUTI). The target MME receives from the source MME the UE's security context, which includes security keys, the UE's security capabilities, and selected security algorithms. If the UE security capabilities are unchanged (e.g., the UE security capabilities received in the UE's TAU request message are the same as the UE security capabilities received from the source MME), and if the previously selected security algorithms received from the source MME can be supported by the target MME, the target MME reuses the existing keys from the received security context.

If the UE security capabilities are changed (e.g., the UE security capabilities received in the UE's TAU request message are different than the UE security capabilities received from the source MME), the target MME performs additional processing to determine whether to reject the TAU request. If the UE-indicated EPS encryption and integrity algorithms are valid, and either the UE or the target MME cannot support the previously-selected security algorithms, the target MME selects new security algorithms and re-authenticates the UE to establish new security contexts. If the UE-indicated EPS encryption and integrity algorithms are not valid or not acceptable, the target MME rejects the UE's TAU request. The target MME, or more generally target network, sets the EMM cause value to "UE security capabilities invalid or unacceptable" or a generic failure cause code (e.g., UE security capabilities mismatch or Protocol error, unspecified, etc.) and assigns a back-off timer Txxxx in a manner similar to that described above in the context of handling the initial attach request. The UE behavior and back-off handling mechanisms in response to the rejection of the TAU request are similar to those described above in the context of the rejection of the initial attach request.

<FIG> illustrate a message flow <NUM> for a security management procedure in a <NUM> EPC network that results in a successful mobility event. In step <NUM>, the UE <NUM> sends a TAU request to the target MME <NUM>-<NUM>. The TAU request includes various parameters, such as KSI, a mobile identity, UE network capability (e.g., security algorithms), and an EPS update type (e.g., tracking area (TA) updating, or combined TA and location area (LA) TA/LA updating with IMSI attach, etc. in the message flow <NUM>). In step <NUM>, the target MME <NUM>-<NUM> obtains from the source MME <NUM>-<NUM> the EPS security context previously established for the UE <NUM>. The EPS security context includes a key KASME, the UE security capabilities previously reported by the UE <NUM> to the source MME <NUM>-<NUM>, and the security algorithms (e.g., EPS encryption and integrity algorithms) selected by the source MME <NUM>-<NUM> for the UE <NUM>.

In step <NUM>, the target MME <NUM>-<NUM> verifies whether the UE security capabilities have changed (e.g., whether the UE security capabilities indicated in the step <NUM> TAU request are the same as the security capabilities retrieved from the source MME <NUM>-<NUM>), and verifies whether the previously-selected security algorithms from the source MME <NUM>-<NUM> are valid and supported by the target MME <NUM>-<NUM>. In step <NUM>, if the UE security capabilities are unchanged and the previously-selected security algorithms received from the source MME <NUM>-<NUM> are valid and can be supported by the target MME <NUM>-<NUM>, the message flow <NUM> proceeds to step <NUM> where KASME and the received security context are reused. Otherwise, the message flow <NUM> proceeds to step <NUM>.

The target MME <NUM>-<NUM> in step <NUM> selects new security algorithms. Step <NUM> is performed in response to various conditions, such as the UE security capabilities being changed, or the previously-selected security algorithms not being acceptable to the target MME <NUM>-<NUM>. The target MME <NUM>-<NUM> in step <NUM> decides to re-authenticate the UE <NUM> if new algorithms are selected in step <NUM>, or if the target MME <NUM>-<NUM> otherwise decides to re-authenticate the UE <NUM> based at least in part on local policy of the target MME <NUM>-<NUM> (or more generally, the target network). The message flow <NUM> then proceeds to step <NUM>, where the UE <NUM>, target MME <NUM>-<NUM> and HE <NUM> perform authentication. The processing of steps <NUM> through <NUM> may be skipped in some instances (e.g., where the security capabilities are unchanged and the previously-selected security algorithms are acceptable to the target MME <NUM>-<NUM>), and thus these steps are shown in dashed outline in <FIG>.

The message flow <NUM> proceeds with steps <NUM> through <NUM>, which are similar to steps <NUM> through <NUM>, respectively, in the message flow <NUM>. The target MME <NUM>-<NUM> generates the NAS security context in step <NUM> and sends the secure mode command to the UE <NUM> in step <NUM>. The UE <NUM> generates the NAS security context in step <NUM> and sends the secure mode complete message to the target MME <NUM>-<NUM> in step <NUM>. The target MME <NUM>-<NUM> sends a tracking area update accept message to the UE <NUM> in step <NUM>, and the UE <NUM> sends a tracking area update complete message to the target MME <NUM>-<NUM> in step <NUM>.

<FIG> illustrates a message flow <NUM> for a security management procedure in a <NUM> EPC network that results in an unsuccessful mobility event. The mobility event may be unsuccessful due to the UE security capabilities changing to EPS encryption and integrity algorithms that are invalid, not supported or otherwise unacceptable to the target MME <NUM>-<NUM>. The message flow <NUM> begins with step <NUM>, where the UE <NUM> sends a TAU request to the target MME <NUM>-<NUM>. The step <NUM> TAU request, similar to the TAU request <NUM> in message flow <NUM>, includes various parameters, such as KSI, a mobile identity, UE network capability (e.g., security algorithms), and a EPS update type (e.g., TA updating, or combined TA/LA updating with IMSI attach, etc. in the message flow <NUM>). In step <NUM>, the target MME <NUM>-<NUM> retrieves the EPS security context from the source MME <NUM>-<NUM> in a manner similar to that described above with respect to step <NUM> of message flow <NUM>.

The target AMF <NUM>-<NUM> in step <NUM> verifies the UE security capabilities and selected algorithms retrieved from the source MME <NUM>-<NUM> in step <NUM>. The target MME <NUM>-<NUM> in step <NUM> determines that the UE security capabilities have changed, and that the EPS encryption or integrity algorithms (or combinations thereof) indicated by the UE <NUM> in the step <NUM> TAU request are invalid, not supported or otherwise not acceptable to the target MME <NUM>-<NUM> (or, more generally, the target network). The target MME <NUM>-<NUM> sends a TAU reject message to the UE <NUM> in step <NUM>. The attach reject message includes the EMM cause "UE security capabilities invalid or unacceptable" along with a timer value. In step <NUM>, the UE <NUM> handles the attach reject message. UE <NUM> processing or handling of the attach reject message will be described in further detail below in conjunction with <FIG>.

<FIG> illustrates a security management procedure in a <NUM> EPC network for UE handling following an unsuccessful initial attach (e.g., step <NUM> in message flow <NUM> or step <NUM> in message flow <NUM>) or mobility tracking area update (e.g., step <NUM> in message flow <NUM>). In step <NUM>, the UE <NUM> aborts the attach procedure (which is an initial attach procedure in message flows <NUM> and <NUM>, and a mobility or TAU procedure in message flow <NUM>). The UE <NUM> resets the attach attempt counter in step <NUM>, and sets the EPS update status to "EU2 NOT UPDATED" in step <NUM>. The UE <NUM> then enters the state "EMM-DEREGISTERED. ATTEMPTING-TO-ATTACH" in step <NUM>. The UE <NUM> performs backoff based at least in part on the received timer value (e.g., from the attach reject message in step <NUM>, <NUM> or <NUM>). The UE <NUM> performs cell reselection or PLMN selection in step <NUM>.

The particular processing operations and other system functionality described in conjunction with the message flow diagrams of <FIG> and <FIG> are presented by way of illustrative example only, and should not be construed as limiting the scope of the disclosure in any way. Alternative embodiments can use other types of processing operations and messaging protocols. For example, the ordering of the steps may be varied in other embodiments, or certain steps may be performed at least in part concurrently with one another rather than serially. Also, one or more of the steps may be repeated periodically, or multiple instances of the methods can be performed in parallel with one another.

Claim 1:
An apparatus comprising means for:
receiving, from a user equipment, a request indicating one or more security capabilities of the user equipment, wherein the request is an initial access request or mobility request;
determining whether the indicated one or more security capabilities meet one or more designated criteria of a communication network;
rejecting the request by the user equipment responsive to determining that the indicated one or more security capabilities do not meet the one or more designated criteria of the communication network; and
sending, to the user equipment, a rejection notification comprising a failure cause code or value based at least in part on the determination that the indicated one or more security capabilities do not meet the one or more designated criteria of the communication network, wherein the failure cause code or value indicates to the user equipment that the initial access request or mobility request has failed due to the one or more security capabilities being invalid or unacceptable to the communication network,
wherein the indicated one or more security capabilities comprise an indication of one or more encryption and/or integrity algorithms supported by the user equipment, and
wherein determining that the indicated one or more security capabilities do not meet the one or more designated criteria of the communication network comprises determining that the indicated one or more encryption and/or integrity algorithms are invalid or unacceptable to the communication network.