Patent Description:
Integrity and confidentiality of traffic between a User Equipment (UE) and Network may create a cost for processing power, and may also reduce the battery life, at a UE. Operating with no security may enable the deployment of devices with longer battery life and less processing power.

However, sending unprotected communications over the air can introduce security risks to the network and to the UE, including but not limited to eavesdropping; originator spoofing; injection of invalid data; or denial of service (DoS) attacks.

Unprotected connections may allow for possible corruption of the data on route, which may have an impact on the network infrastructure or performance.

Due to such risks, network operators are hesitant to allow connections to their network that are unprotected. <CIT> relates to a method in which a set of device security profiles for loT devices can be retrieved from a database. The publication "<NPL> discusses allowing IP range in windows Firewall.

Accordingly, there is provided a method, a network element, and a non-transitory computer readable medium as defined in the claims.

The present disclosure provides a method at a network element for monitoring user plane traffic for a user equipment, the method comprising: configuring a set of characteristics and a range of values for each of the set of characteristics for user plane traffic between the user equipment and the network element; monitoring user plane traffic for the user equipment at the network element, the monitoring determining whether at least one characteristic of the user plane traffic falls outside of the configured range of a values, resulting in a characteristic violation; and if the at least one characteristic of the user plane traffic falls outside the configured range of a values, performing an action resulting from the characteristic violation.

The present disclosure further provides a network element for monitoring user plane traffic for a user equipment, the network element comprising: a processor; and a communications subsystem, wherein the network element is configured to: configure a set of characteristics and a range of values for each of the set of characteristics for user plane traffic between the user equipment and the network element; monitor user plane traffic for the user equipment at the network element, the monitoring determining whether at least one characteristic of the user plane traffic falls outside of the configured range of a values, resulting in a characteristic violation; and if the at least one characteristic of the user plane traffic falls outside the configured range of a values, perform an action resulting from the characteristic violation.

The present disclosure further provides a computer readable medium for storing program instructions for monitoring user plane traffic for a user equipment, which when executed by a processor of a network element cause the network element to: configure a set of characteristics and a range of values for each of the set of characteristics for user plane traffic between the user equipment and the network element; monitor user plane traffic for the user equipment at the network element, the monitoring determining whether at least one characteristic of the user plane traffic falls outside of the configured range of a values, resulting in a characteristic violation; and if the at least one characteristic of the user plane traffic falls outside the configured range of a values, perform an action resulting from the characteristic violation.

A wide array of user equipment (UE) types will use fifth generation (<NUM>), or beyond, services. Such UEs may include Internet of Things (loT) devices, some of which may have very limited processing power and memory. As such, a one size fits all security mechanism will not serve all device types well and can be quite costly relative to the market for which the device is targeted.

Therefore, in accordance with the embodiments below, there is provided a mechanism primarily designed to support loT devices connecting to wide-area cellular networks, where the security overheads for transmission are reduced, typically resulting in lower processing power requirements and longer battery life for the device.

While the embodiments described below are provided for <NUM> networks and devices, in some cases the solutions provided could be used with fourth generation networks or could be used with future networks beyond <NUM>. The present disclosure is therefore not limited to <NUM> networks and devices.

Reference is now made to <FIG>, which shows an example Evolved Packet Core network in a <NUM> network. In the embodiment of <FIG>, a UE <NUM> communicates over the network using an Access Node (AN) <NUM>. The AN <NUM> is typically an evolved Node B (eNB).

AN <NUM> communicates with an Evolved Packet Core (EPC), which in part comprises a Mobility Management Entity (MME) <NUM>, Home Subscriber Server (HSS) <NUM>, Serving Gateway (S-GW) <NUM> and Packet Data Network (PDN) Gateway (P-GW) <NUM>.

MME <NUM> controls operation of device <NUM> through signaling messages using HSS <NUM>.

S-GW <NUM> acts as a router and forwards data to the P-GW <NUM> over an S5/S8 interface.

P-GW <NUM> provides the interface between the <NUM> network and other networks such as the Internet or private networks. P-GW <NUM> is connected to a public data network PDN over an SGi interface.

Those skilled in art will appreciate that wireless network may be connected to other systems, possibly including other networks, not explicitly shown in <FIG>.

In the embodiment of <FIG>, control plane traffic flows between the UE <NUM>, AN <NUM>, MME <NUM> and HSS <NUM>.

Further, user plane traffic flows between UE <NUM>, AN <NUM>, SGW <NUM> and P-GW <NUM>.

Specifically, reference is made to <FIG>, which shows communications between the various layers at the UE <NUM> and eNB <NUM>.

In particular, for control plane traffic <NUM>, communication from the UE proceeds from the Radio Resource Control (RRC) layer <NUM>, through the Packed Data Convergence Protocol (PDCP) layer <NUM>, Radio Link Control (RLC) layer <NUM>, Message Authentication Control (MAC) layer <NUM> and to the Physical (PHY) layer <NUM>.

Similarly, at the eNB <NUM>, the control plane data from the UE <NUM> proceeds through a PHY layer <NUM>, MAC layer <NUM>, RLC layer <NUM>, PDCP layer <NUM> and to RRC layer <NUM>. It may then flow to the MME.

For user plane traffic <NUM>, the traffic flows to and from an application (APP) layer <NUM> at UE <NUM>. The traffic may flow through PDCP layer <NUM>, RLC layer <NUM>, MAC layer <NUM> and to PHY layer <NUM>.

At the eNB <NUM>, the traffic flows through PHY layer <NUM>, MAC layer <NUM>, RLC layer <NUM> to PDCP <NUM>. It may then be forwarded through the S-GW/P-GW <NUM> to the Internet <NUM>. At a server reached through Internet <NUM>, an application layer <NUM> may receive the user plane traffic <NUM>.

In <NUM> networks, there will likely be numerous options for a UE to select the type of service it wishes to receive from a network. One element of the options that can be negotiated between the UE and a network may be the type of security that is applied to the service. These security features, possibly occurring at the radio bearer interface between the UE and a next Generation Node B (gNB) might be, for example, the use or non-use of integrity protection, the use or non-use of confidentiality (encryption), the selection of integrity algorithm and the selection of encryption algorithm.

The security applied to the UE to Network connection may be based at least in part around the mutual authentication of the UE device and UE user to verify they are who they claim to be and have permission to access the network. This part of the connection security is called mutual authentication. The protection of the communications exchanged between the UE and Network from manipulation or spoofing is referred to as integrity. Integrity may primarily be achieved using, for example, keyed hashes or signatures. The protection of the communications between the UE and Network from eavesdropping is referred to as confidentiality. Confidentiality may be primarily achieved using, for example, encryption. Confidentiality and integrity are the two basic components which when combined provide a highly secure communications link from source to destination.

In Long Term Evolution (LTE), also referred to <NUM>, and <NUM> networks integrity and confidentiality operation over the radio interface (over-the-air) are defined for the Control Plane and User Plane traffic to ensure the security of communications across this interface. Table <NUM> below shows the defined options for application of integrity and confidentiality in <NUM> and <NUM>.

In the example of Table <NUM>, integrity ensures the UE is the expected entity, and confidentiality indicates that the communications are encrypted to prevent eavesdroppers from reading the communication.

<NUM> confidentiality and integrity is for example provided for in the <NPL>. In particular, clause <NUM>. <NUM> provides for such integrity and confidentiality. Sections of 3GPP TS <NUM> are reproduced in Appendix A below.

<NUM> confidentiality and integrity is for example provided for in <NPL>. Further, <NPL>" also provides for such confidentiality and integrity.

In current 3GPP networks, including second generation (<NUM>), third generation (<NUM>) and LTE, integrity and confidentiality protection is achieved by use of a shared key (K) between the UE and Network. For example, authentication details for an Enhanced Packet System (EPS) are found in 3GPP TS <NUM>, section <NUM>, reproduced in Appendix B of the present disclosure.

Generally, the security applied to a UE to Network radio connection is the strongest security that can be supported mutually by the UE and Network equipment. In particular, the Network would attempt to use the strongest security possible to offer protection to the UE as well as protect the network equipment from attack.

User Plane confidentiality is provided by encryption at the PDCP layer <NUM> or <NUM>. It is at the PDCP layer <NUM> or <NUM> where the use or non-use of confidentiality for the User Plane is realized. The decision to configure the PDCP layer to use or not use confidentiality may be made at the RRC layer <NUM> (in the eNB <NUM>) or some other equipment, possibly the MME. The PDCP layer <NUM> or <NUM> supports User Data integrity using MAC, where each message arriving at the PDCP layer would be integrity protected.

Typically, higher layer protocols (above the PDCP layer) apply security to the communication transmission, although this is not necessary in order for the embodiments of the present disclosure. The higher layer security could be for example Transport Layer Security (TLS) or Datagram TLS (DTLS), Secure Socket Layer (SSL), Hypertext Transfer Protocol Secure (HTTPS), and Internet Protocol Security (IPSec). Further, if security at the higher layers is not applied then the embodiments of the present disclosure could be used to provide improved security to those unprotected transmissions.

Based on the above, the security impact on the network infrastructure and user data traffic based on the selection of the optional aspects of the User Plane usage of integrity and confidentiality shown in Table <NUM> are addressed by the embodiments described below.

Therefore, in some cases, the embodiments of the present disclosure may be part of the Policy Framework for <NUM> by providing oversight on the traffic characteristics of a UE.

The present disclosure provides a network operator with more information about the use of a network service by a UE. Provided the observed transmissions comply with the described behavior of a UE, the network operator should have confidence the traffic from the UE has not been modified on-route or that the UE has not been tampered.

Specifically, good security is the combination of integrity and confidentiality on a data stream. Removing one or the other or both impacts aspects of security.

For example, integrity can protect the receiver from the tampering of the data payload, since the data payload or a portion of it is used to generate the integrity signature. Integrity can also protect against DoS attacks as additional or duplicated packets arriving at a destination would not pass the Integrity check. Integrity also ensures the connection was not hijacked by an attacker spoofing as the true originator/user of the data connection.

Confidentiality protects the data from eavesdropping and can provide some tampering protection. For example, a packet that failed the Confidentiality check because the data payload had been changed could be discarded.

Table <NUM> below illustrates a combination of security features and how they can protect against or expose a vulnerability. Tampering includes both the data payload and/or the Protocol Control Information (PCI or packet metadata). When confidentiality is disabled and it is not applied at a higher layer, all PCI is exposed, including critical information such as source and destination Internet Protocol (IP) address.

Certain types of devices, particularly those employed in loT type applications, may not require a great amount of security protection if the data they are exchanging is of low value. This can be the case for many loT types of devices, where the cost of the device and its lifetime in service are larger issues than the value of an individual data exchange. Some examples of data and application that may have low value include:.

These devices would normally be running a specific application which connects to only one destination and may also operate a security protocol at a higher layer or in the application itself. Therefore, radio layer security may be an additional, unnecessary cost.

For <NUM>, integrity protection for user data is optional at the radio layer. Therefore it is possible to have a user data session between UE and eNB operating with no integrity and no confidentiality protection.

Therefore, the present disclosure addresses the problem where low cost devices with minimal built-in security functions supporting integrity and confidentiality can be allowed to connect to a Public Land Mobile Network (PLMN) and not introduce security risks to the network infrastructure or other network users. It specifically addresses the scenario where no security (integrity off, confidentiality off) is applied to the OTA transmissions. The security issues addressed by the present disclosure apply to the user plane and include tampering, misuse of the connection, and denial of service attacks.

The embodiments described herein also can be used for other security benefits that are outside the scope of the UE to Network radio interface. The parameters configured in the embodiments of the present disclosure can observe device and application characteristics such as data transmission frequency, data volume, and device location (geo-fencing), data source and destination address. If, for example, the device had been stolen and moved to another location and then is used to carry other data, the embodiments of the present disclosure could detect these changes in the device data transmission behavior and/or device location.

The present disclosure therefore provides for the configuring, at a given network node, a set of characteristics and ranges of values for each of these characteristics. The present disclosure further provides for the monitoring of the user plane traffic to observe the set of characteristics to identify any anomalous behavior when one or more of the characteristics is out of the configured range. The present disclosure further provides for the invoking of appropriate actions upon observing anomalous behavior.

Reference is now made to <FIG>. The embodiment of <FIG> shows an example fourth-generation network configuration similar to that of <FIG>. Like numerals to those of <FIG> are used in the embodiment of <FIG>.

In the embodiment of <FIG>, however, the P-GW <NUM> is chosen as a network node responsible for identifying any anomalous behavior. In this regard, a security policy enforcement function (SPEF) <NUM> is added to P-GW <NUM>. A set of characteristics and a range of values for each of these characteristics are configured at the SPEF <NUM> of P-GW <NUM>.

The embodiment of <FIG> is, however, merely one example and the SPEF <NUM> could be implemented on different network nodes. Further, in some embodiments, different functionality within the SPEF could be implemented on different network nodes. Therefore, the use of the SPEF <NUM> on the P-GW <NUM> is merely provided as an example.

Reference is now made to <FIG>, which shows an example of a <NUM> network. In particular, in the embodiment of <FIG>, a UE <NUM> communicates with a (Radio) Access Network ((R)AN) <NUM>. (R)AN <NUM> may further be referred to as a next generation Node B (gNB).

UE <NUM> may further communicate with an access and mobility management function (AMF) <NUM>.

AMF <NUM> communicates with the authentication server function (AUSF) <NUM> and further with a Unified Data Management (UDM) module <NUM>.

Further, AMF <NUM> also communicates with the session management function (SMF) <NUM>.

A policy control function (PCF) <NUM> is responsible for policy control and communicates with SMF <NUM> and with the application function (AF) <NUM>.

(R)AN <NUM> further communicates with AMF <NUM> and with a user plane function (UPF) <NUM>. UPF <NUM> is similar to the P-GW <NUM> from the embodiments of <FIG> and <FIG>.

UPF <NUM> communicates with the data network <NUM>, which may be network operator services, the Internet, third-party services, among other options.

In accordance with the embodiment of <FIG>, SPEF <NUM> is added to the UPF <NUM>. In this way, the SPEF <NUM> may identify any anomalous behavior by monitoring user plane traffic.

As indicated above, the embodiments of the present disclosure provide for three aspects. In a first aspect, the SPEF is configured. In a second aspect, the SPEF monitors user plane traffic to observe the set of characteristics and identify any anomalous behavior. In a third aspect, the detected anomalous behavior is acted on by invoking appropriate actions at a network element. Each are described below.

In accordance with one embodiment of the present disclosure, an SPEF may be configured with a set of characteristics for communications between a user equipment and a network. Such characteristics are primarily related to the data communication in the user plane. The characteristics are known beforehand and/or can be set beforehand and therefore a session may be monitored by network infrastructure against observed behavior of transmissions.

Where deviation from the predefined characteristics is identified, this would indicate a possible security issue.

One set of characteristics is provided below in Table <NUM>.

In Table <NUM> above, SPE refers to Security Policy Enforcement. The names of the security policy enforcement specified in Table <NUM> are however merely examples. Other enforcement characteristics could be defined at the SPEF.

In the Table <NUM> above, a location characteristic could be set which may include location, movement or speed behavior, or other information regarding the physical location of the UE. The Cell ID or Global Navigation Satellite System (GNSS) coordinates can be used to verify the location of the UE and crosscheck its position with a network value contained in the user profile for the UE to ensure the UE is in the location it should be, or in the region of its expected operation. A device found to be operating outside of its expected location could be flagged as a possible stolen device.

Further, volume information may be set estimating the payload data volume that would be sent from a UE or to a UE.

Time of day information may be set including when expected transmissions to or from the UE may occur.

A number of expected simultaneous connections can also be set. The expected duration of such connections may be a further characteristic that could be monitored.

Further, in some embodiments the estimated frequency of data transmission may be known. Thus, for example, if a weather beacon was expected to transmit every <NUM> minutes, such frequency could be set with this characteristic.

A datatype for the type of data that would be sent from the UE could also be known or set as a characteristic of the data that is expected from that UE.

Beacons may have a particular destination that they report to. For example, utilizing the weather beacon example, the weather beacon may send data to a particular server and to no other location. In this case, a characteristic could be the normal destination address for the communications.

A further characteristic that may be set may be the number of bytes that are expected to be transmitted in communications. For example, again using the weather beacon system, the UE may send a data packet that has a relatively known size and therefore upper limits on the size of the transmission could be set as a characteristic.

Further, capabilities for the UE could be set, indicating for example that the UE will send data and not SMS, multimedia packets, voice packets among others.

Many of the above parameters are related to traffic flow. Further, if packet payload inspection is used, many of the above parameters may be used with payload contents.

As described below, the above characteristics and ranges can be used by the network to compare the observed traffic against the parameters provided. If the observed traffic falls within the perimeter ranges provided, the network can have confidence of the traffic is valid.

A change in traffic flow can be viewed as a possible threat to the network. For example, changes to traffic with regard to frequency or volume may be associated with a denial of service attack, traffic changes to connection duration, data type, location, time of day, capability, source or destination IP address, byte counts, among others could indicate tampering. As described below, the network can then take appropriate action.

Further, in some embodiments, a device found operating outside of its expected parameters could simply be a malfunctioning device. Operators can then take measures to protect the network from a badly behaving or corrupted device and device owners may be notified of the problem.

The characteristics and ranges of Table <NUM> above may be preconfigured in the node that holds the subscription information. For example, in 3GPP network architecture, the functionality may reside in the PCF in <NUM> networks or the HSS in <NUM> networks.

Alternatively, the information with regard to the characteristics may be obtained directly from a UE for each session. In one embodiment, information from the UE regarding the characteristics may be provided only in integrity protected messages to ensure the validity of the parameters.

For example, during an ATTACH procedure, a UE is authenticated and can possibly securely send expected characteristics of the session in an integrity protected message. Since only an authenticated UE can send an integrity protected message, the parameter values included in the message can be trusted by the network. Based on the information, the set of characteristics and a range of values corresponding to the characteristics may be determined. These values may then, for example, be configured in the SPEF of the P-GW for <NUM> networks and in the UPF for <NUM> networks.

For example, reference is now made to <FIG>, which shows the configuration of characteristics at the UPF in a <NUM> network.

In particular, in the embodiment of <FIG>, a next-generation UE (NG-UE) <NUM> communicates with a <NUM> network, including AMF <NUM>, SMF <NUM>, UPF with SPEF <NUM> and Security Enforcement Access Framework (SEAF) <NUM>.

As seen in block <NUM>, the UE is attached with the network. This step involves mutual authentication of the network and the UE.

Optionally, in block <NUM>, the UE may provide the expected characteristics of the session in a secure and integrity protected message. An example of such integrity protected message is a PDU session establishment request message <NUM> from the UE.

Message <NUM> may include an identity as well as a data network name (DNN). In one embodiment, the UE security capability, including user plane security capabilities, is stored in the AMF during the ATTACH. Alternatively, the NG-UE <NUM> may provide its user plane security capabilities in message <NUM>.

Subsequently, at block <NUM>, the AMF determines an SMF based on the DNN provided by NG-UE <NUM>.

The AMF <NUM>, once it has chosen an appropriate SMF, triggers the session establishment procedure by sending a PDU session establishment request to the SMF, shown by message <NUM>. Message <NUM> includes the UE identity, DNN and security capability.

SMF <NUM> may then retrieve a security policy from PCF <NUM>, as shown by arrow <NUM>. In one embodiment, the security policy may include a set of characteristics and the range of values for each characteristic, as shown in the first two columns of Table <NUM> above.

Alternatively, the SMF <NUM> may determine the characteristics and ranges based on a policy retrieved from the PCF. In other embodiments, some or all of the values may also be attained directly from the UE during the ATTACH or PDU session establishment request <NUM>. In this case, the values are passed to the SMF <NUM> from AMF <NUM>.

At block <NUM>, the SMF may check whether the NG-UE <NUM> is authorized to establish the requested PDU session and it determines the user plane security termination.

If the NG-UE <NUM> is authorized to establish the PDU session and UPF security termination is required for the PDU session, the SMF <NUM> may request a key for the UPF. The SMF <NUM> provides the SEAF <NUM> with the UE identity, DNN and SMF identity in message <NUM>.

The SEAF derives a UPF Key (KUPF) from the KSEAF by incorporating the parameters received from the SMF <NUM> and a locally managed counter (for example CNTUPF) for UPF Key derivation. The key derivation is shown at block <NUM>.

The SEAF <NUM> then sends a key response message <NUM> to the SMF <NUM>. The key response includes the KUPF and CNTUPF used for the key derivation. Thus, the counter at block <NUM> is sent back.

On receiving message <NUM>, SMF <NUM> sends a PDU session configuration request to the UPF containing the security configuration information for the PDU session. This may include, for example, the ciphering and/or integrity protection algorithm, including the KUPF and traffic characteristics for the PDU session. This is sent in message <NUM> in the embodiment of <FIG>.

The UPF with the SPEF <NUM> installs the KUPF for the session as part of the PDU session configuration and derives subsequent keys such as KUPFEnc and KUPFInt. Such keys are derived based on security configuration information. The keys are associated with a key ID, which may also be incorporated in the key derivation. However, if integrity and confidentiality protection are not applied to the PDU session and the KUPF is null, there may be no derivation of the subsequent keys. Further, the UPF configures the security policy enforcement function with the traffic characteristic parameters received from the PCF from this PDU session. The key install is shown at block <NUM> in the embodiment of <FIG>.

The UPF then sends a PDU session configuration response <NUM> to the SMF <NUM> containing a PDU session ID, key ID and other parameters if they exist, used for the key derivation.

The SMF <NUM> then sends a PDU session establishment response to the NG-UE <NUM> via the AMF <NUM>, shown by message <NUM>. This response message includes all key materials such as CNTUPF, key ID, among others, that are needed for the NG-UE <NUM> to derive the same keys as the UPF.

NG-UE <NUM> derives KUPF and subsequent keys based on the session establishment response at block <NUM>.

The NG-UE <NUM> then sends a PDU session establishment complete message <NUM> to the SMF <NUM> via AMF <NUM>.

After the completion of sending the message <NUM>, NG-UE <NUM> and the UPF protect the user plane the packets based on the PDU session security configuration terminating at the UPF, which includes the SPEF.

Changes to 3GPP TR <NUM> which may accommodate the above are shown, for example, in Appendix C below. The additions to the TR are shown in bold.

Similarly, the characteristics could be provided to the P-GW with a SPEF in a <NUM> network. For example, reference is now made to <FIG>.

In the embodiment of <FIG>, a UE <NUM> communicates with eNB <NUM>. Further, network elements include MME <NUM>, S-GW <NUM>, P-GW <NUM> and Policy and Charging Rules Function (PCRF) <NUM>.

At the outset, UE <NUM> makes an ATTACH request to eNB <NUM>, as shown by message <NUM>.

The eNB <NUM> forwards the ATTACH request to MME <NUM>, as shown by message <NUM>.

Thereafter, an ATTACH procedure, as for example defined in 3GPP TS <NUM>, and namely steps <NUM>-<NUM> in Section <NUM>. <NUM> is performed, as shown by block <NUM> in the embodiment of <FIG>.

If the subscription context does not indicate that the APN is for a PDN connection, MME <NUM> selects a serving gateway <NUM>. It then sends a Create Session Request <NUM>. Such Create Session Request may include various session request information, including security policy enforcement parameters.

Once serving gateway <NUM> receives request <NUM>, it may then send a Create Session Request with standard information, as well as security policy enforcement parameters, to P-GW <NUM>, shown as request <NUM>.

The P-GW <NUM> may then perform an IP-CAN session establishment procedure with PCRF <NUM>, as for example defined in 3GPP TS <NUM>, and thereby obtains default Policy and Charging Control (PCC) rules for the UE. This is shown with arrow <NUM> in the embodiment of <FIG>.

The P-GW <NUM> creates a new entry in its EPS bearer context table and generates a Charging ID for the default bearer. The new entry allows the P-GW <NUM> to route user plane PDUs between the S-GW<NUM> and the packet data network. If the SPEF parameters are present, the SPEF function will be invoked in the P-GW <NUM> and will commence monitoring the user plane PDUs for the UE <NUM>.

The P-GW <NUM> will return to S-GW <NUM> a Create Session Response, shown as response <NUM>.

If the ATTACH is not based on a handover then first downlink data, shown by arrow <NUM> may be received. At this point, S-GW <NUM> may send a Create Session Response to MME <NUM>, as shown by message <NUM>.

Upon being configured with a set of characteristics and their valid ranges, as for example described with regard to <FIG> and <FIG> above, the SPEF may start monitoring the mobile originated and mobile terminated traffic. If one or more characteristics of the user plane data are beyond the configured range, the SPEF may detect an anomaly, which may indicate a possible security vulnerability and may trigger an appropriate action based on the cause of the identified anomaly.

The monitoring may be for particular characteristics. In one embodiment, monitoring can occur by having each of the characteristics configured at the SPEF monitored separately. In other embodiments, the monitoring can occur for a plurality of characteristics.

Examples of monitoring are shown below with regard to the embodiments of <FIG>, <FIG> and <FIG>. However, the embodiments in these figure are merely provided for illustration, and other examples of monitoring for particular characteristics would be apparent to those skilled in the art having regard to the present disclosure.

Referring to <FIG>, the embodiment shows a process at the SPEF for monitoring for data volume. In particular, the process of <FIG> starts at block <NUM> and proceeds to block <NUM> in which new data packets that are destined for a UE or are from a UE are received.

The process then proceeds to block <NUM> in which a calculation is done on the cumulative amount of data that has been received by a UE or is sent to the UE for a particular time period. For example, if the configuration for a UE has been set with a characteristic that expects a certain amount of data for the UE for each given day, the calculation at block <NUM> may calculate the cumulative data for that time period. In other embodiments, the time period may be one hour, a number of minutes, one week, one month, among other time periods.

The process then proceeds to block <NUM> in which a check is made to determine whether the amount of data received in the time period exceeds a threshold for the expected amount of data from the UE or to the UE. For example, if the UE is expected to send less than <NUM> MB of data per day and the cumulative amount of data sent from the UE has exceeded the <NUM> MB, then the check at block <NUM> is affirmative and the process proceeds to block <NUM>.

At block <NUM>, if the amount of data has exceeded the threshold, then an appropriate action is invoked related to the cause of high volume data. Example actions are described below.

Conversely, if the amount of data is less than the threshold, then the process proceeds from block <NUM> back to block <NUM> in which the process waits for the next data to be received for or from the UE.

From block <NUM> the process proceeds to block <NUM> and ends.

Thus, in accordance with the embodiment of <FIG>, a network element may monitor data traffic to or from a UE to ensure that the amount of data does not exceed a threshold for a time period.

Reference is now made to <FIG>, which shows a process for monitoring location of a UE at the SPEF. In particular, the process starts at block <NUM> and proceeds to block <NUM> in which a new data packet has been received that is destined for a UE or a new data packet has been received from a UE.

The process then proceeds to block <NUM> in which the location of the UE is determined. For example, in one embodiment the location may be determined based on the cell identifier of the UE. This may, for example, be the Radio Access Network Identifier (RAN ID) or the eNB identifier for the N3 interface in one embodiment. However, location may be determined in a variety of ways and the obtaining of the location of block <NUM> could use different methods.

From block <NUM> the process proceeds to block <NUM> in which the check is made to determine whether the cellular identifier is within a list of cellular identifiers configured as a characteristic for that particular UE. For example, if a UE is meant to be a stationary UE such as a parking meter, then the movement of the UE to a different cell ID may indicate that the UE has been stolen or is being spoofed.

From block <NUM>, if the cell ID is within the list of parameters for the location characteristic, the process proceeds back to block <NUM> to wait for new packet data to or from the UE.

Conversely, if the cell ID is not within the list of cell ID parameters, as determined at block <NUM>, then the process proceeds to block <NUM> in which appropriate actions are invoked related to the cause of an unexpected UE location. Examples of actions are described below.

From block <NUM> the process proceeds to block <NUM> and ends.

Thus, based on <FIG>, the SPEF may monitor the location of a UE to ensure that the location for the UE is expected.

Reference is now made to <FIG>, which shows a process at an SPEF for data type monitoring functionality. In particular, the process of <FIG> starts at block <NUM> and proceeds to block <NUM> in which a new data packet destined for a UE or a new packet from a UE is received.

The process then proceeds to block <NUM> in which a data type is identified for the data packet. For example, the data type may be identified by inspecting the Differentiated Services Code Point (DSCP) field in the IP header or by identifying whether the packet is a Transmission Control Protocol/User Datagram Protocol (TCP/UDP) type packet.

Other methods for defining the data type are also possible and the present disclosure is not limited to any particular method for identifying the datatype at block <NUM>.

From block <NUM> the process proceeds to block <NUM> and checks whether the data type is the correct data type. The check could use parameters associated with data type characteristics that have been configured for the UE. Such parameters allow the SPEF to determine whether the UE is allowed to send the packet with the datatype identified at block <NUM>.

If the datatype is the correct datatype, the process proceeds to block <NUM> in which the process waits for the next data packet to or from the UE.

Conversely, if the datatype at block <NUM> is identified to be an incorrect datatype, then the process proceeds to block <NUM> in which an appropriate action related to a cause is invoked, where the cause is set to unexpected datatype. For example, in the parking meter example, the parking meter may be expected to send TCP packets. However, if a Short Message Service (SMS) message is received then this could be identified as an incorrect datatype and an action invoked at block <NUM> made be reflective of this. Actions are described below.

The process proceeds to block <NUM> and ends.

Thus the embodiment of <FIG> shows an example process for monitoring datatypes for traffic originating from a UE or traffic destined to a UE.

The examples of <FIG>, <FIG> and <FIG> are provided for illustration. Similar processes could be used for the different characteristics configured at the SPEF for the UE to determine whether or not the user plane traffic is within parameters specified for such characteristics.

Upon detecting one or more anomalies in user plane traffic, the SPEF may trigger an appropriate action specific to the detected set of anomalies. Some actions may include simple user plane functionality such as dropping packets while other actions may include control plane functionality such as triggering specific 3GPP control plane procedures.

Various example actions are provided below. However, the list of actions is merely provided for illustration, and other actions could also be performed. The actions described below are therefore not limiting.

Reference is made to <FIG>. In a first example of an action, control plane nodes such as the SMF <NUM>, AMF <NUM> and PCF <NUM> may be involved in executing the action. In particular, the action in the example of <FIG> involves policy updates with the PCF <NUM>.

In the example of <FIG>, the UPF with the SPEF <NUM> may identify an anomaly and the cause of the anomaly at block <NUM>. Based on the anomaly and cause, the UPF may then send a message <NUM> to the SMF <NUM> indicating that a security anomaly has been detected. The message <NUM> may include a cause, as well as a user equipment identifier.

SMF <NUM> may then forward the contents of message <NUM> to AMF <NUM>, shown as message <NUM>, with the cause and the user equipment identifier.

Upon receiving the message <NUM>, AMF <NUM> may update the policy record in the PCF <NUM>, shown with policy update <NUM>. The updating may trigger further actions such as notifying the user, requiring user plane security, among other actions, as provided below.

Reference is now made to <FIG>, which shows an action that may be invoked by control plane nodes SMF <NUM>, AMF <NUM> and the UPF with the SPEF <NUM>. In the example of <FIG>, the UE <NUM> receives a notification.

In the example of <FIG>, the UPF with the SPEF <NUM> identifies an anomaly in a cause, shown at block <NUM>. The UPF may then send a message <NUM> to SMF <NUM>, indicating that a security anomaly has been detected. Message <NUM> may include a cause and a user equipment identifier.

SMF <NUM> may then forward the contents of message <NUM> to the AMF <NUM>, shown as message <NUM>.

AMF <NUM> may then forward, to the UE <NUM>, a message indicating that a vulnerability has been detected and cause of the vulnerability. This is shown as message <NUM> in the embodiment of <FIG>. Message <NUM> may be a secure Network Access Stratum (NAS) message in one embodiment. Thus, message <NUM> may be encrypted and/or integrity protected to ensure that only the authentic UE is informed about the detected vulnerability, since only the authentic UE will have the keys needed for integrity and decryption.

In another embodiment, only one user plane node such as the UPF may be involved with the action. Reference is now made to <FIG> which shows a UPF with the SPEF <NUM> being involved with user plane traffic. Further, messages may be forwarded through SMF <NUM>, AMF <NUM>, and the gNB <NUM>. Further, the UE <NUM> receives control plane messages.

In the embodiment of <FIG>, the UPF with the SPEF <NUM> identifies an anomaly and a cause at block <NUM> and may then drop the packets to and from the UE at block <NUM>.

In one embodiment, this may be the end of the action.

In other embodiments, the UPF may optionally trigger to the gNB to drop the packets from the UE, which could save the traffic hitting the core network nodes between the RAN node and the UPF. In this case, a control plane node such as the AMF <NUM> and the SMF <NUM> may need to be involved with such functionality.

In particular, in the embodiment of <FIG>, the UPF may send a message <NUM> to drop packets from the UE, including a user equipment identifier and a cause. Message <NUM> may be sent to SMF <NUM>.

SMF <NUM> may then forward the contents of message <NUM>, shown as message <NUM>, to AMF <NUM>.

AMF <NUM> may then forward the contents of message <NUM>, shown as message <NUM>, to gNB <NUM>.

On receiving message <NUM>, the gNB <NUM> may discard user plane (UP) traffic from the UE and/or invoke the RRC release procedure for the UE, as shown at block <NUM>. In the latter case, if an RRC release is invoked then the RRC release is sent to the UE, as shown by arrow <NUM> and the UE may then enter an IDLE mode, as shown by block <NUM>.

In a further action, a procedure may be initiated by a RAN node such as the gNB in <NUM> networks. However, a trigger to initiate the procedure may come from any core network node.

Reference is now made to <FIG>. In the embodiment of <FIG>, the SPEF may cause the RAN node to trigger a counter check procedure upon detecting a specific anomaly.

In the embodiment of <FIG>, UE <NUM> may communicate with a RAN node such as gNB <NUM>. Further, core network node such as AMF <NUM> and SMF <NUM> may be involved in communication with UPF and SPEF <NUM>.

The UPF with SPEF <NUM> may identify an anomaly and a cause, as shown by block <NUM>, and may in one embodiment drop the user plane packets to and from the UE as shown by block <NUM>.

Further, in the embodiment of <FIG>, the UPF with the SPEF <NUM> may signal a security anomaly has been detected, along with a cause and a user equipment identifier, and send this as a message <NUM> to the SMF <NUM>.

The SMF <NUM> may forward the contents of message <NUM>, shown as message <NUM>, to the AMF <NUM>.

AMF <NUM> may then forward the contents of message <NUM> to the gNB <NUM>, as shown by message <NUM>.

On receiving message <NUM>, the gNB <NUM> may initiate a counter check procedure. If the counter check fails, the RRC connection may be released and this may be indicated to the AMF <NUM> and one embodiment. Further, if the counter check succeeds, the gNB <NUM> may indicate the success to the AMF <NUM>.

The initial counter check procedure is shown by block <NUM> in the embodiment of <FIG>.

Based on the check at block <NUM>, if the counter check fails, an RRC release may be initiated as shown by arrow <NUM> in <FIG>.

On receiving the RRC release, the UE may enter an idle mode, shown by Block <NUM>.

In still a further action, upon detecting an anomaly, the SPEF may trigger an authentication procedure for the UE. Reference is now made to <FIG>.

In the embodiment of <FIG>, an NAS authentication procedure is triggered by the AMF. Specifically, UE <NUM> communicates with AMF <NUM>. Further, the core network includes SMF <NUM> and user plane data is monitored by UPF with SPEF <NUM>.

The UPF with the SPEF <NUM> identifies an anomaly and cause, as shown by block <NUM>, and based on the detected anomaly and cause provides a message <NUM> to the SMF <NUM> indicating that a security anomaly has been detected. Message <NUM> may include a cause and a user equipment identifier.

SMF <NUM> then forwards the contents of message <NUM> to the AMF <NUM>, shown as message <NUM>.

Based on message <NUM>, AMF <NUM> initiates an authentication procedure. In particular, an authentication request message <NUM> may be sent to UE <NUM>.

In response, an authentication response message <NUM> may be provided from the UE <NUM> back to AMF <NUM>.

AMF <NUM> verifies the response in message <NUM> to determine whether authentication has passed or failed. Further, the absence of a response may also indicate authentication has failed. The authentication check is shown at block <NUM> in the embodiment of <FIG>.

If the authentication fails, a DETACH procedure may be initiated for the UE. One example DETACH procedure is described below with regards to <FIG>.

Conversely, if the authentication succeeds, the session is continued and an indication may be sent to the SPEF via the SMF <NUM>.

Thus, if the authentication is successful then the UE is re-authenticated as shown by message <NUM> between AMF <NUM> and SMF <NUM>. SMF <NUM> then forwards the contents of message <NUM> to the UPF <NUM>, shown as message <NUM>.

A further action that may occur would be to trigger a DETACH procedure for the UE upon detecting an anomaly. In this case, a genuine UE may perform a new ATTACH procedure, including authentication, subsequent to the DETACH procedure.

Reference is now made to <FIG>. In particular, in the embodiment of <FIG>, UE <NUM> communicates with the network using gNB <NUM>. The core network includes AMF <NUM> and SMF <NUM>. Further, UPF with SPEF <NUM> provides for user plane traffic.

The UPF with the SPEF <NUM> identifies an anomaly and a cause at block <NUM>. The UPF with the SPEF <NUM> then signals a security anomaly has been detected, including the cause and a user equipment identifier, in message <NUM> to the SMF <NUM>.

SMF <NUM> may then forward the contents of message <NUM> to AMF <NUM>, shown as message <NUM>.

AMF <NUM> may then send a DETACH ACCEPT message <NUM> to the gNB <NUM>, which may cause an RRC release <NUM> with the UE <NUM>.

As indicated above, a genuine UE <NUM> could then perform an ATTACH procedure with the authentication security.

One example DETACH procedure is shown with regards to <FIG> below.

In a further action, the SPEF may trigger the radio node to switch on the encryption and/or integrity protection of data. Such trigger may be a temporary trigger in some embodiments. Reference is now made to <FIG>.

UE <NUM> communicates using gNB <NUM>. Further, the core network includes AMF <NUM> and SMF <NUM>. A UPF with SPEF <NUM> provides for user plane traffic.

In the embodiment of <FIG>, the UPF with the SPEF <NUM> identifies an anomaly and a cause at block <NUM> and provides a message <NUM> to SMF <NUM> indicating that a security anomaly has been detected. Message <NUM> may include a cause and a user equipment identifier.

AMF <NUM> may then trigger a session modification to turn on encryption or integrity protection, as shown by message <NUM>, with gNB <NUM>.

Based on the receipt of message <NUM>, gNB <NUM> may then cause an RRC-reconfiguration. The RRC reconfiguration <NUM> may include the data radio bearer being reconfigured to use encryption and/or integrity protection.

Once UE <NUM> receives the RRC reconfiguration <NUM>, only a genuine UE can succeed in switching encryption and/or integrity protection on, since this requires the UE to be in possession of the appropriate security keys.

In the actions shown with regard to <FIG> and <FIG> above, the UE is caused to DETACH. This may be accomplished in various ways.

One example of a detach for a <NUM> network is provided with regard to <FIG>. In particular, the embodiment of <FIG> shows a <NUM> network causing a new DETACH notification <NUM> to be sent between a P-GW <NUM> and an MME <NUM>. For example, the DETACH notification <NUM> may to be sent from the SPEF associated with P-GW <NUM>.

DETACH notification <NUM> provides an indication that the observed traffic behavior is outside an expected range.

On receiving the DETACH notification <NUM>, the MME may perform a DETACH procedure as, for example, described in 3GPP TR <NUM> and in particular in section <NUM>. <NUM> of that TR. Such DETACH procedure is shown by block <NUM> in the embodiment of <FIG>.

Based on the DETACH procedure, the P-GW <NUM> will receive a delete session request and send a delete session response for the requested user data PDU's session (not shown).

Upon conclusion of the DETACH procedure at block <NUM>, the MME <NUM> sends a final DETACH acknowledgement, shown by message <NUM>, to the P-GW <NUM>. In particular, the DETACH acknowledgement <NUM> may be sent to the SPEF associated with the P-GW <NUM>.

One example of changes to 3GPP TR <NUM> that could be made for the above detach procedure are shown in Appendix E below.

For a <NUM> network, a similar detach procedure could be utilized.

The above therefore provides for the ability to reduce processing power and increase battery life of potentially millions of UEs deployed in loT applications by removing the need to run integrity and confidentiality at the radio interface. Further, a reduction is created in over the air data transfer that is needed to support integrity, which results in more bandwidth available for the network to support other customers.

The embodiments further offer protection to the network for potential misuse of the radio interface against spoofing and DoS attacks.

The embodiments described above can also provide protection for a device owner or user if the device was stolen and/or the subscription used fraudulently.

Further, a malfunctioning device may be detected in accordance with the embodiments described above, thus protecting the network and device owner or user.

The modules, mobile entities, and user equipments and devices described above may be any computing device or network node. Such computing device or network node may include any type of electronic device, including but not limited to, mobile devices such as smartphones or cellular telephones. Examples can further include fixed or mobile user equipments, such as internet of things (IoT) devices, endpoints, home automation devices, medical equipment in hospital or home environments, inventory tracking devices, environmental monitoring devices, energy management devices, infrastructure management devices, vehicles or devices for vehicles, fixed electronic devices, among others. Vehicles includes motor vehicles (e.g., automobiles, cars, trucks, buses, motorcycles, etc.), aircraft (e.g., airplanes, unmanned aerial vehicles, unmanned aircraft systems, drones, helicopters, etc.), spacecraft (e.g., spaceplanes, space shuttles, space capsules, space stations, satellites, etc.), watercraft (e.g., ships, boats, hovercraft, submarines, etc.), railed vehicles (e.g., trains and trams, etc.), and other types of vehicles including any combinations of any of the foregoing, whether currently existing or after arising.

One simplified diagram of a computing device is shown with regard to <FIG>. The computing device of <FIG> could be any UE, Mobile Entity (ME), network node such as UPF, SPEF, or other node as described above.

In <FIG>, device <NUM> includes a processor <NUM> and a communications subsystem <NUM>, where the processor <NUM> and communications subsystem <NUM> cooperate to perform the methods of the embodiments described above. Communications subsystem <NUM> may, in some embodiments, comprise multiple subsystems, for example for different radio technologies.

Processor <NUM> is configured to execute programmable logic, which may be stored, along with data, on device <NUM>, and shown in the example of <FIG> as memory <NUM>. Memory <NUM> can be any tangible, non-transitory computer readable storage medium. The computer readable storage medium may be a tangible or in transitory/non-transitory medium such as optical (e.g., CD, DVD, etc.), magnetic (e.g., tape), flash drive, hard drive, or other memory known in the art.

Alternatively, or in addition to memory <NUM>, device <NUM> may access data or programmable logic from an external storage medium, for example through communications subsystem <NUM>.

Communications subsystem <NUM> allows device <NUM> to communicate with other devices or network elements and may vary based on the type of communication being performed. Further, communications subsystem <NUM> may comprise a plurality of communications technologies, including any wired or wireless communications technology.

Communications between the various elements of device <NUM> may be through an internal bus <NUM> in one embodiment. However, other forms of communication are possible.

Further, if the computing station is a user equipment, one example user equipment is described below with regard to <FIG>.

User equipment <NUM> may comprise a two-way wireless communication device having voice or data communication capabilities or both. User equipment <NUM> generally has the capability to communicate with other computer systems. Depending on the exact functionality provided, the user equipment may be referred to as a data messaging device, a two-way pager, a wireless e-mail device, a smartphone, a cellular telephone with data messaging capabilities, a wireless Internet appliance, a wireless device, a mobile device, a mobile entity, an embedded cellular modem or a data communication device, as examples.

Where user equipment <NUM> is enabled for two-way communication, it may incorporate a communication subsystem <NUM>, including a receiver <NUM> and a transmitter <NUM>, as well as associated components such as one or more antenna elements <NUM> and <NUM>, local oscillators (LOs) <NUM>, and a processing module such as a digital signal processor (DSP) <NUM>. As will be apparent to those skilled in the field of communications, the particular design of the communication subsystem <NUM> will be dependent upon the communication network in which the user equipment is intended to operate.

Network access requirements will also vary depending upon the type of network <NUM>. In some networks, network access is associated with a subscriber or user of the user equipment <NUM>. A user equipment may be provided with an embedded or a removable user identity module (RUIM) or a subscriber identity module (SIM) card or a UMTS SIM (USIM) in order to operate on a network. The USIM/SIM/RUIM interface <NUM> is normally similar to a card-slot into which a USIM/SIM/RUIM card can be inserted and ejected. The USIM/SIM/RUIM card can have memory and hold many key configurations <NUM>, and other information <NUM> such as identification, and subscriber related information. In other cases, rather than a network <NUM>, user equipment <NUM> may communicate with a non-access node, such as a vehicle, roadside infrastructure, another user equipment, or other peer-to-peer communication.

When required network registration or activation procedures have been completed, user equipment <NUM> may send and receive communication signals over the network <NUM>. As illustrated in <FIG>, network <NUM> can include multiple base stations communicating with the user equipment.

Signals received by antenna <NUM> through communication network <NUM> are input to receiver <NUM>, which may perform such common receiver functions as signal amplification, frequency down conversion, filtering, channel selection and the like. Analog to digital (A/D) conversion of a received signal allows more complex communication functions such as demodulation and decoding to be performed in the DSP <NUM>. In a similar manner, signals to be transmitted are processed, including modulation and encoding for example, by DSP <NUM> and input to transmitter <NUM> for digital to analog (D/A) conversion, frequency up conversion, filtering, amplification and transmission over the communication network <NUM> via antenna <NUM>. DSP <NUM> not only processes communication signals, but also provides for receiver and transmitter control. For example, the gains applied to communication signals in receiver <NUM> and transmitter <NUM> may be adaptively controlled through automatic gain control algorithms implemented in DSP <NUM>.

User equipment <NUM> generally includes a processor <NUM> which controls the overall operation of the device. Communication functions, including data and voice communications, are performed through communication subsystem <NUM>. Processor <NUM> also interacts with further device subsystems such as the display <NUM>, flash memory <NUM>, random access memory (RAM) <NUM>, auxiliary input/output (I/O) subsystems <NUM>, serial port <NUM>, one or more keyboards or keypads <NUM>, speaker <NUM>, microphone <NUM>, other communication subsystem <NUM> such as a short-range communications subsystem or DSRC subsystem, and any other device subsystems generally designated as <NUM>. Serial port <NUM> could include a USB port, On-Board Diagnostics (OBD) port or other port known to those in the art.

Some of the subsystems shown in <FIG> perform communication-related functions, whereas other subsystems may provide "resident" or on-device functions. Notably, some subsystems, such as keyboard <NUM> and display <NUM>, for example, may be used for both communication-related functions, such as entering a text message for transmission over a communication network, and device-resident functions such as a calculator or task list.

Operating system software used by the processor <NUM> may be stored in a persistent store such as flash memory <NUM>, which may instead be a read-only memory (ROM) or similar storage element (not shown). Those skilled in the art will appreciate that the operating system, specific device applications, or parts thereof, may be temporarily loaded into a volatile memory such as RAM <NUM>. Received communication signals may also be stored in RAM <NUM>.

As shown, flash memory <NUM> can be segregated into different areas for both computer programs <NUM> and program data storage <NUM>, <NUM>, <NUM> and <NUM>. These different storage types indicate that each program can allocate a portion of flash memory <NUM> for their own data storage requirements. Processor <NUM>, in addition to its operating system functions, may enable execution of software applications on the user equipment. A predetermined set of applications that control basic operations, including potentially data and voice communication applications for example, will normally be installed on user equipment <NUM> during manufacturing. Other applications could be installed subsequently or dynamically.

Applications and software may be stored on any computer readable storage medium. The computer readable storage medium may be a tangible or in transitory/non-transitory medium such as optical (e.g., CD, DVD, etc.), magnetic (e.g., tape) or other memory known in the art.

One software application may be a personal information manager (PIM) application having the ability to organize and manage data items relating to the user of the user equipment such as, but not limited to, e-mail, messages, calendar events, voice mails, appointments, and task items. Further applications, including productivity applications, social media applications, games, among others, may also be loaded onto the user equipment <NUM> through the network <NUM>, an auxiliary I/O subsystem <NUM>, serial port <NUM>, short-range communications subsystem <NUM> or any other suitable subsystem <NUM>, and installed by a user in the RAM <NUM> or a non-volatile store (not shown) for execution by the processor <NUM>. Such flexibility in application installation increases the functionality of the device and may provide enhanced on-device functions, communication-related functions, or both.

In a data communication mode, a received signal such as a text message or web page download will be processed by the communication subsystem <NUM> and input to the processor <NUM>, which may further process the received signal for output to the display <NUM>, or alternatively to an auxiliary I/O device <NUM>.

A user of user equipment <NUM> may also compose data items such as messages for example, using the keyboard <NUM>, which may be a complete alphanumeric keyboard or telephone-type keypad, either physical or virtual, among others, in conjunction with the display <NUM> and possibly an auxiliary I/O device <NUM>. Such composed items may then be transmitted over a communication network through the communication subsystem <NUM>.

Where voice communications are provided, overall operation of user equipment <NUM> is similar, except that received signals may typically be output to a speaker <NUM> and signals for transmission may be generated by a microphone <NUM>. Alternative voice or audio I/O subsystems, such as a voice message recording subsystem, may also be implemented on user equipment <NUM>. Although voice or audio signal output is preferably accomplished primarily through the speaker <NUM>, display <NUM> may also be used to provide an indication of the identity of a calling party, the duration of a voice call, or other voice call related information for example.

Serial port <NUM> in <FIG> may be implemented in a user equipment for which synchronization with a user's desktop computer (not shown) may be desirable, but is an optional device component. Such a port <NUM> may enable a user to set preferences through an external device or software application and may extend the capabilities of user equipment <NUM> by providing for information or software downloads to user equipment <NUM> other than through a wireless communication network. As will be appreciated by those skilled in the art, serial port <NUM> can further be used to connect the user equipment to a computer to act as a modem or for charging a battery on the user equipment.

Other communications subsystems <NUM>, such as a short-range communications subsystem, is a further component which may provide for communication between user equipment <NUM> and different systems or devices, which need not necessarily be similar devices. For example, the subsystem <NUM> may include an infrared device and associated circuits and components or a Bluetooth™ or Bluetooth™ Low Energy communication module to provide for communication with similarly enabled systems and devices. Subsystem <NUM> may further include non-cellular communications such as Wi-Fi or WiMAX, or near field communications, and in accordance with the embodiments above such radio may be capable of being split in some circumstances.

While operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be employed. Moreover, the separation of various system components in the implementation described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a signal software product or packaged into multiple software products.

While the above detailed description has shown, described, and pointed out the fundamental novel features of the disclosure as applied to various implementations, it will be understood that various omissions, substitutions, and changes in the form and details of the system illustrated may be made by those skilled in the art. In addition, the order of method steps are not implied by the order they appear in the claims.

Typically, storage mediums can include any or some combination of the following: a semiconductor memory device such as a dynamic or static random access memory (a DRAM or SRAM), an erasable and programmable read-only memory (EPROM), an electrically erasable and programmable read-only memory (EEPROM) and flash memory; a magnetic disk such as a fixed, floppy and removable disk; another magnetic medium including tape; an optical medium such as a compact disk (CD) or a digital video disk (DVD); or another type of storage device. Note that the instructions discussed above can be provided on one computer-readable or machine-readable storage medium, or alternatively, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly a plurality of nodes. Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). The storage medium or media can be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions can be downloaded over a network for execution.

In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.

Ciphering may be provided to RRC-signalling to prevent UE tracking based on cell level measurement reports, handover message mapping, or cell level identity chaining. RRC signalling confidentiality is an operator option.

All S1 and X2 messages carried between RN and DeNB shall be confidentiality-protected.

NOTE <NUM>: Encryption is subject to national regulation.

Synchronization of the input parameters for ciphering shall be ensured for the protocols involved in the ciphering.

The NAS signalling may be confidentiality protected. NAS signalling confidentiality is an operator option.

NOTE <NUM>: RRC and NAS signalling confidentiality protection is recommended to be used.

When authentication of the credentials on the UICC during Emergency Calling in Limited Service Mode, as defined in the TS <NUM> [<NUM>], can not be successfully performed, the confidentiality protection of the RRC and NAS signaling, and user plane shall be omitted (see clause <NUM>). This shall be accomplished by the network by selecting EEA0 for confidentiality protection of NAS, RRC and user plane.

User plane confidentiality protection over the access stratum shall be done at PDCP layer and is an operator option.

NOTE <NUM>: User plane confidentiality protection is recommended to be used.

NOTE <NUM>: Confidentiality protection for RRC and UP is applied at the PDCP layer, and no layers below PDCP are confidentiality protected. Confidentiality protection for NAS is provided by the NAS protocol.

User data sent via MME may be confidentiality protected.

NOTE <NUM>: Confidentiality protection of user data sent via MME is recommended to be used.

Synchronization of the input parameters for integrity protection shall be ensured for the protocols involved in the integrity protection.

Integrity protection, and replay protection, shall be provided to NAS and RRC-signalling.

All NAS signaling messages except those explicitly listed in TS <NUM> [<NUM>] as exceptions shall be integrity-protected. All RRC signaling messages except those explicitly listed in TS <NUM> [<NUM>] as exceptions shall be integrity-protected.

When authentication of the credentials on the UICC during Emergency Calling in Limited Service Mode, as defined in the TS <NUM> [<NUM>], can not be successfully performed, the integrity and replay protection of the RRC and NAS signaling shall be omitted (see clause <NUM>). This shall be accomplished by the network by selecting EIA0 for integrity protection of NAS and RRC. EIA0 shall only be used for unauthenticated emergency calls.

User plane packets between the eNB and the UE shall not be integrity protected on the Uu interface. User plane packets between the RN and the UE shall not be integrity protected. All user plane packets carrying S1 and X2 messages between RN and DeNB shall be integrity-protected. Integrity protection for all other user plane packets between RN and DeNB may be supported.

All user data packets sent via the MME shall be integrity protected.

The user plane data is ciphered by the PDCP protocol between the UE and the eNB as specified in TS <NUM> [<NUM>].

The use and mode of operation of the <NUM>-EEA algorithms are specified in Annex B. The input parameters to the <NUM>-bit EEA algorithms as described in Annex B are an <NUM>-bit cipher key KUPenc as KEY, a <NUM>-bit bearer identity BEARER which value is assigned as specified by TS <NUM> [<NUM>], the <NUM>-bit direction of transmission DIRECTION, the length of the keystream required LENGTH and a bearer specific, time and direction dependent <NUM>-bit input COUNT which corresponds to the <NUM>-bit PDCP COUNT.

This subclause applies only to the user plane on the Un interface between RN and DeNB:
The user plane data is integrity-protected by the PDCP protocol between the RN and the DeNB as specified in TS <NUM> [<NUM>]. Replay protection shall be activated when integrity protection is activated. Replay protection shall ensure that the receiver only accepts each particular incoming PDCP COUNT value once using the same AS security context.

The use and mode of operation of the <NUM>-EIA algorithms are specified in Annex B. The input parameters to the <NUM>-bit EIA algorithms as described in Annex B are a <NUM>-bit integrity key KUPint as KEY, a <NUM>-bit bearer identity BEARER which value is assigned as specified by TS <NUM> [<NUM>], the <NUM>-bit direction of transmission DIRECTION, and a bearer specific, time and direction dependent <NUM>-bit input COUNT which corresponds to the <NUM>-bit PDCP COUNT.

The supervision of failed UP integrity checks shall be performed both in the RN and the DeNB. In case of failed integrity check (i.e. faulty or missing MAC-I) is detected after the start of integrity protection, the concerned message shall be discarded. This can happen on the DeNB side or on the RN side.

NOTE: The handling of UP integrity check failures by an RN is an implementation issue. TS <NUM> [<NUM>] intentionally does not mandate any action for a failed integrity check (not even sending an indication of failure to higher layers). Consequently, depending on the implementation, the message failing integrity check is, or is not, silently discarded. This is in contrast to the handling of a failed RRC integrity check by a UE, cf. the NOTE in clause <NUM>. <NUM> of the present document.

NOTE <NUM>: Authentication data in this subclause stands for EPS Authentication vector(s).

EPS AKA is the authentication and key agreement procedure that shall be used over E-UTRAN.

A Rel-<NUM> or later USIM application on a UICC shall be sufficient for accessing E-UTRAN, provided the USIM application does not make use of the separation bit of the AMF in a way described in TS <NUM> [<NUM>] Annex F. Access to E-UTRAN with a <NUM> SIM or a SIM application on a UICC shall not be granted.

An ME that has E-UTRAN radio capability shall support the USIM-ME interface as specified in TS <NUM>.

EPS AKA shall produce keying material forming a basis for user plane (UP), RRC, and NAS ciphering keys as well as RRC and NAS integrity protection keys.

NOTE <NUM>: Key derivation requirements of AS and NAS keys can be found in subclause <NUM>.

The MME sends to the USIM via ME the random challenge RAND and an authentication token AUTN for network authentication from the selected authentication vector. It also includes a KSIASME for the ME which will be used to identify the KASME (and further keys derived from the KASME) that results from the EPS AKA procedure.

At receipt of this message, the USIM shall verify the freshness of the authentication vector by checking whether AUTN can be accepted as described in TS <NUM>. If so, the USIM computes a response RES. USIM shall compute CK and IK which are sent to the ME. If the USIM computes a Kc (i.e. GPRS Kc) from CK and IK using conversion function c3 as described in TS <NUM>, and sends it to the ME, then the ME shall ignore such GPRS Kc and not store the GPRS Kc on USIM or in ME. If the verification fails, the USIM indicates to the ME the reason for failure and in the case of a synchronisation failure passes the AUTS parameter (see TS <NUM>).

An ME accessing E-UTRAN shall check during authentication that the "separation bit" in the AMF field of AUTN is set to <NUM>. The "separation bit" is bit <NUM> of the AMF field of AUTN.

NOTE <NUM>: This separation bit in the AMF can not be used anymore for operator specific purposes as described by TS <NUM>, Annex F.

NOTE <NUM>: If the keys CK, IK resulting from an EPS AKA run were stored in the fields already available on the USIM for storing keys CK and IK this could lead to overwriting keys resulting from an earlier run of UMTS AKA. This would lead to problems when EPS security context and UMTS security context were held simultaneously (as is the case when security context is stored e.g. for the purposes of Idle Mode Signaling Reduction). Therefore, "plastic roaming" where a UICC is inserted into another ME will necessitate an EPS AKA authentication run if the USIM does not support EMM parameters storage.

UE shall respond with User authentication response message including RES in case of successful AUTN verification and successful AMF verification as described above. In this case the ME shall compute KASME from CK, IK, and serving network's identity (SN id) using the KDF as specified in clause A. SN id binding implicitly authenticates the serving network's identity when the derived keys from KASME are successfully used.

NOTE <NUM>: This does not preclude a USIM (see TS <NUM>) in later releases having the capability of deriving KASME.

Otherwise UE shall send an authentication failure message with a CAUSE value indicating the reason for failure. In case of a synchronisation failure of AUTN (as described in TS <NUM>), the UE also includes AUTS that was provided by the USIM. Upon receipt of an authentication failure message, the MME may initiate further identity requests and authentications towards the UE. (see TS <NUM>).

The MME checks that the RES equals XRES. If so the authentication is successful. If not, depending on type of identity used by the UE in the initial NAS message, the MME may initiate further identity requests or send an authentication reject message towards the UE (see TS <NUM> [<NUM>]).

Figure <NUM>. <NUM>-<NUM> describes EPS AKA procedure, which is based on UMTS AKA (see TS <NUM>[<NUM>]). The following keys are shared between UE and HSS:
K is the permanent key stored on the USIM on a UICC and in the Authentication Centre AuC.

CK, IK is the pair of keys derived in the AuC and on the USIM during an AKA run. CK, IK shall be handled differently depending on whether they are used in an EPS security context or a legacy security context, as described in subclause <NUM>.

As a result of the authentication and key agreement, an intermediate key KASME shall be shared between UE and MME i.e. the ASME for EPS.

UEs that select to establish a data session that does not use UP integrity or confidentiality may provide a means for an attacker to use the session to attack the network at the RAN or higher layers.

A data session with no integrity or confidentiality protection could be hijacked by an attacker. We are primarily interested in threats to the network, since if the UE has selected a data session with no integrity or confidentiality it is assumed it has accepted those risks such as eavesdroppoing. Threats to the network are the interest in this key issue, an unprotected data session could allow an attacker to;.

The security requirement is to protect the network at a layer beyond the RAN or above the PDCP layer, but to also not reduce to the benefits to the application/UE that may be gained by a UP session that does not invoke integrity and confidentiality.

A reqirement to protect the network in a way that is passive to the UP data connection user, but to ensures the network can be aware of a mis-use of its service.

This solution proposes a UP session Security Policy Enforcement Function (SPEF) in the UPF and is a solution for key issue #<NUM> in <NUM>.

The network operator uses a set of parameters associated with the UE traffic characteristics to provide the UPF with the parameters it needs to ensure the UE is behaving within the limits of the expected characteristics. These values can be manually configured into the PCF or SPCF (or the UE Subscription Information in the HSS in LTE). These values can be, but are not limited to:.

These values are used by the SPEF in the UPF to monitor the traffic over a specific PDU session from a specific UE. If the observed traffic characteristics fall out of the range of acceptable values, the SPEF and signal the AMF to terminate the connection or reset the connection using integrity and/or confidentiality protection.

This solution is based on the <NUM> architecture where the UP security terminates in the UPF.

A NG-UE requests a PDU session establishment for a DN (Data Network) using a NAS message. When the AMF receives the PDU session establishment from the NG-UE, the AMF determines an SMF based on the DNN (Data Network Name) and forwards the session establishment to the SMF along with the NG-UE identity and DNN. The SMF interacts with the PCF to obtain the requirements for the PDU session.

The SMF obtains a key (i.e., KUPF) for the UPF security from the SEAF and provides the key (KUPF) to the UPF as a part of the PDU session configuration at the UPF so that the UPF can apply UPF security for the NG-UE. Included in this PDU session configuration at the UPF are the parameters for monitoring the traffic characteristics of the NG-UE. The SMF also provides the session information and key derivation parameters to the NG-UE so that the NG-UE derives the same key as UPF and starts UPF security protection. In the case of a PDU session with no Integrity or Confidentiality the key provided to the UPF (KUPF) would be null.

After completion of the step <NUM>, the NG-UE and UPF protect the UP packets based on the PDU session security configuration terminating at UPF, which would include the SPEF.

This CR adds parameters to the Create Session Request message sent from the MME to the Serving Gateway and to the PDN-GW which will carry the parameters needed by the SPEF in the PDN-GW. The MME obtains the SPEF from the HSS subscription context for the UE.

If an ESM container was not included in the Attach Request, steps <NUM>, <NUM>,<NUM>,<NUM>,<NUM> are skipped.

The Serving GW creates a new entry in its EPS Bearer table and sends a Create Session Request (IMSI, MSISDN, APN, Serving GW Address for the user plane, Serving GW TEID of the user plane, Serving GW TEID of the control plane, RAT type, Default EPS Bearer QoS, PDN Type, PDN Address, subscribed APN-AMBR, EPS Bearer Identity, Protocol Configuration Options, Handover Indication, ME Identity, User Location Information (ECGI), UE Time Zone, User CSG Information, MS Info Change Reporting support indication, PDN Charging Pause Support indication, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum APN Restriction, Dual Address Bearer Flag, Serving Network, Security Policy Enforcement Parameters) message to the PDN GW indicated by the PDN GW address received in the previous step. After this step, the Serving GW buffers any downlink packets it may receive from the PDN GW without sending a Downlink Data Notification message to the MME until it receives the Modify Bearer Request message in step <NUM> below. The MSISDN is included if received from the MME.

If dynamic PCC is deployed and the Handover Indication is not present, the PDN GW performs an IP-CAN Session Establishment procedure as defined in TS <NUM> [<NUM>], and thereby obtains the default PCC rules for the UE. This may lead to the establishment of a number of dedicated bearers following the procedures defined in clause <NUM>. <NUM> in association with the establishment of the default bearer, which is described in Annex F.

NOTE <NUM>: While the PDN GW/PCEF may be configured to activate predefined PCC rules for the default bearer, the interaction with the PCRF is still required to provide e.g. the UE IP address information to the PCRF.

NOTE <NUM>: If the IP address is not available when the PDN GW performs the IP-CAN Session Establishment procedure with the PCRF, the PDN GW initiates an IP-CAN Session Modification procedure to inform the PCRF about an allocated IP address as soon as the address is available. In this version of the specification, this is applicable only to IPv4 address allocation.

The P-GW creates a new entry in its EPS bearer context table and generates a Charging Id for the Default Bearer. The new entry allows the P-GW to route user plane PDUs between the S-GW and the packet data network, and to start charging. The way the P-GW handles Charging Characteristics that it may have received is defined in TS <NUM>. If the SPEF parameters are present the SPEF function will be invoked in the PDN-GW and will commence monitoring the user plan PDUs for this UE.

The Serving GW returns a Create Session Response (PDN Type, PDN Address, Serving GW address for User Plane, Serving GW TEID for S1-U User Plane, Serving GW TEID for control plane, EPS Bearer Identity, EPS Bearer QoS, PDN GW addresses and TEIDs (GTP-based S5/S8) or GRE keys (PMIP-based S5/S8) at the PDN GW(s) for uplink traffic, Protocol Configuration Options, Prohibit Payload Compression, APN Restriction, Cause, MS Info Change Reporting Action (Start), Presence Reporting Area Action, CSG Information Reporting Action (Start), APN-AMBR, Delay Tolerant Connection) message to the new MME. For Control Plane CloT EPS optimisation, the Serving GW address for S11-U User Plane and Serving GW TEID are used by the MME to forward UL data to the SGW. If the 3GPP PS Data Off UE Status was present in the Create Session Request PCO and the PGW supports 3GPP PS Data Off feature, the PGW shall include the 3GPP PS Data Off Support Indication in the Create Session Response PCO.

This CR adds a Detach message sent to the MME from the SPEF in the PDN-GW indicating the observed traffic from a UE is outside the expected range.

The proposed changes are based on <NUM> section <NUM>. <NUM> MME-initiated Detach procedure.

The MME-initiated Detach procedure when initiated by the MME is illustrated in Figure <NUM>. <NUM>-<NUM>.

Claim 1:
. A method at a network element (<NUM>, <NUM>) for monitoring user plane traffic for a user equipment (<NUM>, <NUM>), the method comprising:
receiving, from the user equipment, a set of characteristics and a range of values for each of the set of characteristics for user plane traffic between the user equipment and the network element;
monitoring user plane traffic for the user equipment at the network element, the monitoring determining whether at least one characteristic of the user plane traffic falls outside of the range of values, resulting in a characteristic violation; and
if the at least one characteristic of the user plane traffic falls outside the range of values, performing an action resulting from the characteristic violation;
wherein the receiving is performed during a network registration procedure (<NUM>, <NUM>) between the user equipment and the network element.