Partial user plane protection in mobile networks

Abstract

An apparatus of a mobile network, the apparatus comprising: a session management function (SMF) comprising: a means for determining a user plane (UP) security policy for a packet data unit (PDU) session of user equipment (UE), wherein the user plane security policy includes user plane security parameters that specify at least one of an integrity protection portion of a user plane packet to be integrity protected and an encryption portion of the user plane packet to be encrypted; and a means for providing the user plane security policy to a radio access network (RAN) node that serves the UE, indicating the user plane security parameters. The user plane security parameters of the user plane security policy may comprise: a full integrity protection parameter indicating that the entire user plane packet is to be integrity protected; and a full encryption parameter indicating that the entire user plane packet is to be encrypted. The integrity protection portion and the encryption portion may comprise one or more headers of the user plane packet. The SMF may further comprise means for determining the user plane security policy based on user plane protection preferences received from the UE during establishment of the PDU session.

Description

Technical Field Tliis disclosure is related to the field of communication systems and, in particular, to next generation networks. Background Next generation networks, such as Fifth Generation (5G) and beyond (e.g., Sixth Generation (6G)), denote the next major phase of mobile telecommunications standards beyond Fourth Generation (4G) standards. In comparison to 4G networks, next generation networks may be enhanced in terms of radio access and network architecture to deliver faster data rates and more reliability. With mobile networks widely used across the country and the world, communications may be intercepted or suffer from other kinds of attacks. To ensure security and privacy, the 3rd Generation Partnership Project (3GPP) has set forth security mechanisms for mobile networks, and the security procedures performed within the mobile networks. Due to the importance of security in 5G systems and beyond, it is desirable to continue to develop improved security mechanisms. Summary Described herein are enhanced security mechanisms for mobile networks, such as a 5G network and beyond. A session management function (SMF) determines an enhanced user plane (UP) security policy for a session of user equipment (UE), and distributes the enhanced UP security policy to the UE and the radio access network (RAN) serving the UE. The enhanced UP security policy specifies partial UP protection for the session. For example, the enhanced UP security policy may specify partial integrity protection of UP traffic by applying integrity protection to a specific portion of a UP packet. The enhanced UP security policy may specify partial confidentiality protection (e.g., ciphering / encryption) of UP traffic by applying encryption to a specific portion of the UP packet. One technical benefit of partial UP protection is that double protection is avoided, such as when other security’ mechanisms are activated for the session. Another technical benefit is compute resources and energy may be conserved in the UE and / or RAN without compromising UP security. In an embodiment (also referred to as an aspect), a session management function comprises a means for determining a user plane security policy for a packet data unit session of user equipment. The user plane security policy includes user plane security parameters that specify at least one of an integrity protection portion of a user plane packet to be integrity protected and an encryption portion of the user plane packet to be encry pted. The session management function further comprises a means for providing the user plane security policy to a radio access network node that serves the user equipment, indicating the user plane security parameters. In an embodiment (also referred to as an aspect), a radio access network node comprises a means for receiving a user plane security policy provided by a session management function for a packet data unit session of user equipment. The user plane security policy includes user plane security parameters that specify at least one of an integrity protection portion of a user plane packet to be integrity protected and an encryption portion of the user plane packet to be encrypted. The radio access network node further comprises a means for providing the user plane security policy from the radio access network node to the user equipment indicating the user plane security policy. The radio access network node further comprises a means for activating user plane confidentiality and user plane integrity protection per each data radio bearer of the packet data unit session according to the user plane security policy by applying integrity protection to the integrity protection portion of user plane packets and / or encryption or decryption to the encryption portion of the user plane packets based on the user plane security parameters. In an embodiment (also referred to as an aspect), user equipment comprises a means for receiving a user plane security policy provided by a radio access network node for a packet data unit session. The user plane security policy includes user plane security parameters that specify at least one of an integrity protection portion of a user plane packet to be integrity protected and an encryption portion of the user plane packet to be encrypted. The user equipment further comprises a means for activating user plane confidentiality and user plane integrity protection per each data radio bearer of the packet data unit session according to the user plane security policy by applying integrity protection to the integrity protection portion of user plane packets and / or encryption or decryption to the encryption portion of the user plane packets based on the user plane security parameters. In an embodiment (also referred to as an aspect), a method of user plane security in a mobile network is disclosed. The method comprises determining, in a session management function of the mobile network, a user plane security policy for a packet data unit session of user equipment. The user plane security policy includes user plane security parameters that specify at least one of an integrity protection portion of a user plane packet to be integrity protected and an encryption portion of the user plane packet to be encry pted. The method further comprises providing the user plane security policy from the session management function to a radio access network node that serves the user equipment, indicating the user plane security parameters. In an embodiment (also referred to as an aspect), the method comprises receiving, at the radio access network node, the user plane security policy provided by the session management function, providing the user plane security policy from the radio access network node to the user equipment indicating the user plane security policy, and activating, at the radio access network node, user plane confidentiality and user plane integrity protection per each data radio bearer of the packet data unit session according to the user plane security policy by applying integrity protection to the integrity protection portion of user plane packets and / or encry ption or decryption to the encryption portion of the user plane packets based on the user plane security parameters. In an embodiment (also referred to as an aspect), the method comprises receiving, at the user equipment, the user plane security policy provided by the radio access network node, and activating, at the user equipment, user plane confidentiality and user plane integrity protection per each data radio bearer of the packet data unit session according to the user plane security' policy by applying integrity protection to the integrity protection portion of user plane packets and / or encry ption or decryption to the encryption portion of the user plane packets based on the user plane security parameters. Other embodiments may include computer readable media, other systems or apparatus, or other methods as described below. Also, one or more embodiments as described above may be combinable as described herein. The above summary provides a basic understanding of some aspects of the specification. This summary is not an extensive overview of the specification. It is intended to neither identity’ key or critical elements of the specification nor delineate any scope of the particular embodiments of the specification, or any scope of the claims. Its sole purpose is to present some concepts of the specification in a simplified form as a prelude to the more detailed description that is presented later. Description of the Drawings Some embodiments of the invention are now described, by way of example only, and yvith reference to the accompanying drawings. Hie same reference number represents the same element or the same type of element on all drawings. FIG. 1 illustrates a high-level architecture of a 5G system. FIG. 2 illustrates a non-roaming architecture of a 5G system. FIG. 3 illustrates security mechanisms yvithin a 5G system. FIGS. 4A-4B illustrate the primary' authentication procedure that provides mutual authentication between user equipment and the network. FIG. 5 illustrates non-access stratum (NAS) and access stratum (AS) security procedures. FIGS. 6A-6B illustrate a UP security mechanism. FIG. 7 illustrates a key hierarchy of a 5G system. FIG. 8 illustrates the NAS functional layer and the AS functional layer in a 5G system. FIG. 9 is a block diagram of a Session Management Function (SMF) in an illustrative embodiment. FIG. 10 is a block diagram of a Radio Access Network (RAN) node in an illustrative embodiment. FIG. 11 is a block diagram of User Equipment (UE) in an illustrative embodiment. FIGS. 12A-12B are message diagrams illustrating enhanced UP security mechanisms in an illustrative embodiment. FIG. 13 is a flow chart illustrating a method of conveying an enhanced UP security policy in an illustrative embodiment. FIGS. 14A-14D illustrate an enhanced UP security policy in illustrative embodiments. FIG. 15 illustrates a User Plane (UP) packet in an illustrative embodiment. FIG. 16 is a flow chart illustrating a method of establishing UP security in an illustrative embodiment. FIG. 17 is a flow chart illustrating a method of establishing UP security in an illustrative embodiment. FIG. 18 illustrates a “Up Security Info” datatype. FIG. 19 illustrates a “UpSecurity” data type. FIG. 20 illustrates a “Uplntegrity” enumeration. FIG. 21 illustrates a “UpConfidentiality” enumeration. FIG. 22 illustrates a revised “UpSecurity” data type in an illustrative embodiment. FIG. 23 illustrates another revised “UpSecurity” data type in an illustrative embodiment. FIG. 24 illustrates another revised “UpSecurity” data type in an illustrative embodiment. FIG. 25 illustrates a UE accessing an external application service in an illustrative embodiment. FIG. 26 illustrates a UP packet in an illustrative embodiment. FIG. 27 illustrates an enhanced UP security policy in an illustrative embodiment. FIG. 28 illustrates another revised “UpSecurity” data type in an illustrative embodiment. FIG. 29 is a message diagram illustrating enhanced UP security7 mechanisms in an illustrative embodiment. FIGS. 30-31 illustrate extensions to a Security Indication Information Element (IE) in illustrative embodiments. FIGS. 32-33 illustrate a revised RadioBearerConfig Information Element (IE) in illustrative embodiments. Description of Embodiments The figures and the following description illustrate specific exemplary embodiments. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the embodiments and are included within the scope of the embodiments. Furthermore, any examples described herein are intended to aid in understanding the principles of the embodiments, and are to be construed as being without limitation to such specifically recited examples and conditions. As a result, the inventive concept(s) is not limited to the specific embodiments or examples described below, but by the claims and their equivalents. FIG. 1 illustrates a high-level architecture of a 5G system 100. A 5G system (5GS) 100 is a communication system (e.g., a 3GPP system) comprising a 5G Access Network ((R)AN) 102 (referred to generally herein as a RAN) and a 5G core network (5GC) 104 that communicate with 5G User Equipment (UE) 106. The RAN 102 and 5GC 104 together may be referred to as a 5G network 101, a 5G mobile network, a 5G communication network, a next generation network, etc. Although the term “5G” is used herein as an example, any next generation networks beyond 4G are considered, such as 6G. Thus, a “mobile network" and the concepts described herein apply to 5G and beyond. RAN 102 provides radio or wireless connectivity to a UE 106, and connects the UE 106 to the 5GC 104. RAN 102 may comprise a Next Generation Radio Access Network (NG-RAN), a non-3GPP access network, and / or another type of RAN connecting to 5GC 104. RAN 102 may support Evolved-UMTS Terrestrial Radio Access Network (E-UTRAN) access (e.g., through an eNodeB (eNB), gNodeB (gNB), and / or ng-eNodeB (ng-eNB)), Wireless Local Area Network (WLAN) access, satellite radio access, new Radio Access Technologies (RAT), etc. A 5G access network may also support fixed access. 5GC 104 interconnects RAN 102 with a data network (DN) 108. 5GC 104 is comprised of Network Functions (NF) 110, which may be implemented either as a network element on dedicated hardware, as a software instance running on dedicated hardware, as a virtualized function instantiated on an appropriate platform (e.g., a cloud infrastructure), etc. Data network 108 may be an operator external public or private data network, or an intra-operator data network (e.g., for IP Multimedia Subsystem (IMS) services). A UE 106 (also referred to as a mobile terminal) includes a 5G capable device configured to register with 5GC 104 to access services. UE 106 may include an end user device, such as a mobile phone (e.g., smartphone), a tablet, a computer with a mobile broadband adapter, etc. UE 106 may be enabled for voice services, data services, Machine-to-Machine (M2M) or Machine Type Communications (MTC) services, and / or other services. FIG. 2 illustrates a non-roaming architecture 200 of a 5G system 100. The architecture 200 in FIG. 2 is a service-based representation, as is further described in 3GPP TS 23.501 (Release 18), which is incorporated by reference as if fully included herein. Architecture 200 is comprised of Network Functions (NF) for a 5GC 104, and the NFs for the control plane (CP) are separated from the user plane (UP). The control plane of the 5GC 104 includes an Authentication Server Function (AUSF) 210, an Access and Mobility Management Function (AMF) 212, a Session Management Function (SMF) 214, a Policy Control Function (PCF) 216, a Unified Data Management (UDM) 218, a Network Slice Selection Function (NSSF) 220, and an Application Function (AF) 222. The control plane of the 5GC 104 further includes a Network Exposure Function (NEF) 224, a NF Repository Function (NRF) 226, a Service Communication Proxy (SCP) 228, a Network Slice Admission Control Function (NSACF) 230, a Network Slice-specific and SNPN Authentication and Authorization Function (NSSAAF) 232, and an Edge Application Server Discovery Function (EASDF) 234. The user plane of the 5GC 104 includes one or more User Plane Functions (UPF) 240 that communicate with data network 108. A UE 106 is able to access the control plane and the user plane of the 5GC 104 through RAN 102. There are a large number of subscribers that are able to access services from a carrier or home network operator that implements a mobile network comprising a 5G system 100, such as in FIGS. 1 -2. Communications between the subscribers (i.e., through a UE) and the mobile network are protected by security mechanisms, such as the ones standardized by the 3GPP. Subscribers and the carrier expect security guarantees from the security mechanisms. FIG. 3 illustrates security mechanisms 300 within a 5G system 100. One of the security mechanisms 300 is primary authentication and key agreement between the network (e.g., AMF 212 / UDM 218) and the UE 106. Other security mechanisms 300 are used to protect signaling between the network and the UE 106. For example, a security mechanism 300 is used to protect Non-Access Stratum (NAS) signaling between the AMF 212 and the UE 106. Other security mechanisms 300 are used to protect Access Stratum (AS) communications between a RAN node (e.g., gNB 302) and the UE 106, such as Radio Resource Control (RRC) signaling between a gNB 302 and the UE 106, and User Plane (UP) traffic (also referred to as UP data) between the gNB 302 and the UE 106. Within the network, a security mechanism 300 may be used to protect IP connectivity between the gNB 302 and the 5GC 104 (e.g., AMF 212 / UPF 240), such as Internet Protocol Security (IPSec). Yet another security mechanism 300 is used for roaming and interconnect security, such as to protect control plane signaling between a Security Edge Protection Proxy (SEPP) 310 and another network 301 (e.g., a visited 5G network), and / or to protect user plane data between the UPF 240 and the other network 301. There may be additional security mechanisms 300 defined or used, which are not discussed for the sake of brevity. FIGS. 4A-4B illustrate the primary authentication procedure that provides mutual authentication between the UE 106 and the network (e.g., AMF 212 / UDM 218). The purpose of the primary authentication and key agreement procedures is to enable mutual authentication between UE 106 and the home network of the UE 106, and provide keying material that can be used between the UE 106 and the serving network in subsequent security procedures (e.g., NAS and AS security procedures). The home network (e.g., Home Public Land Mobile Network (HPLMN)) represents an operator network or carrier network through which a subscriber (e.g., UE 106) has a subscription for services. The serving network has radio access equipment able to communicate with the UE 106 via radio signals. The keying material generated by the primary authentication and key agreement procedure results in an anchor key (called the Kseaf key) provided by the AUSF 210 of the home network to the Security Anchor Function (SEAF) of the serving network. The SEAF provides authentication functionality via the AMF 212 in the serving network, and supports primary authentication using a Subscription Concealed Identifier (SUCI) that contains the concealed Subscription Permanent Identifier (SUPI). The SUPI is a globally unique 5G identifier allocated to each subscriber in the 5G system 100. The SUCI is composed of a SUPI type, a Home Network Identifier (HN-ID) identifying the home network of the subscriber, a Routing Indicator (RID) that is assigned to the subscriber by the home network operator and provisioned in the Universal Subscriber Identity Module (USIM) of the UE 106, a Protection Scheme Identifier, a Home Network Public Key Identifier, and a Scheme Output. The anchor key (Kseaf) is derived from an intermediate key called the Kausf key. The Kausf key is established between the UE 106 and the home network (AUSF 210) resulting from the primary authentication procedure. FIG. 4A is a signaling diagram that illustrates initiation of primary' authentication, such as described in 3GPP TS 33.501 (Release 18), which is incorporated by reference as if fully included herein. The UE 106 transmits an N1 message 411 (i.e., an initial NAS message) to the serving network 406 (e.g., the AMF 212 of the serving network 406), such as a Registration Request. The serving network 406 may also be referred to as a serving PLMN, a visited-PLMN (VPLMN), etc., in a roaming scenario. The UE 106 uses the SUCI or a 5G Global Unique Temporary’ Identifier (5G-GUTI) in the Registration Request. SEAF 402 of the AMF 212 may initiate an authentication with the UE 106 during any procedure establishing a signaling connection with the UE 106. SEAF 402 invokes the NausfyUEAuthentication service toyvard the home network 404 (e.g., HPLMN) by sending a Nausf_UEAuthentication_Authenticate Request message 412 to AUSF 210 to initiate an authentication. The Nausf_UEAuthentication_Authenticate Request message 412 includes the SUCI or SUPI, and the serving network name (SN-Name). Upon receiving the Nausf L EAuthentication Authenticate Request message 412, AUSF 210 checks that the requesting SEAF 402 in the serving network 406 is entitled to use the serving network name (SNN) in the Nausf_UEAuthentication_Authenticate Request message 412 by comparing the serving network name with the expected serving network name. When the serving network 406 is authorized to use the serving network name, AUSF 210 sends a NudmUEAuthenticationGet Request message 413 to UDM 218 of the home network. The Nudm UEAuthentication Get Request message 413 includes the SUCI or SUPI, and the serving network name. Upon reception of the Nudm LEAuthentication Get Request message 413, UDM 218 identifies the SUPI (if received), or invokes a Subscription Identifier De-concealing Function (SIDF) that de-conceals the SUPI from the SUCI (if received). UDM 218 (or an Authentication credential Repository and Processing Function (ARPF) of UDM 218) selects or chooses the authentication method for primary authentication based on the SUPI. FIG. 4B is a signaling diagram that illustrates a primary authentication procedure, such as described in 3GPP TS 33.501. In this example, 5G Authentication and Key Agreement (AKA) is described, but similar concepts apply for Extensible Authentication Protocol AKA prime (EAP-AKA). For a NudmUEAuthenticationGet Request 413, UDM 218 creates a 5G Home Environment Authentication Vector (5G HE AV) for the selected authentication method. UDM 218 derives the Kausf key and calculates an expected response (XRES*) to a challenge. UDM 218 creates the 5G HE AV comprising an authentication token (AUTN), the expected response (XRES*), the Kausf key, and a random challenge (RAND). UDM 218 then sends aNudmUEAuthenticationGet Response message 414 to AUSF 210 with the 5G HE AV to be used for authentication (e.g., 5G AKA in FIG. 4B). In case the SUCI was included in the Nudm UEAuthentication Get Request 413, UDM 218 includes the SUPI in the Nudm UEAuthentication Get Response message 414 after deconcealment of the SUPI from the SUCI. If a subscriber has an Authentication and Key Management for Application (AKMA) subscription, UDM 218 may include an AKMA indication and the RID in the Nudm UEAuthentication Get Response message 414. In response to the Nudm_UEAuthentication_Get Response message 414, AUSF 210 stores the expected response (XRES*) temporarily with the received SUCI or SUPI. AUSF 210 then generates a 5G Authentication Vector (5G AV) from the 5G HE AV received from UDM 218, by computing a hash expected response (HXRES*) from the expected response (XRES*) and the Kseaf key from the Kausf key, and replacing the XRES* with the HXRES* and the Kausf key with the Kseaf key in the 5G HE AV. AUSF 210 removes the Kseaf key to generate a 5G Serving Environment Authentication Vector (5G SE AV) that includes the authentication token (AUTN), hash expected response (HXRES*), and the random challenge (RAND). AUSF 210 sends a Nausf UEAuthentication Authenticate Response message 415 to SEAF 402 that includes the 5G SE AV. In response, SEAF 402 sends the authentication token (AUTN) and the random challenge (RAND) to the UE 106 in a NAS message Authentication Request message 416. Although not shown in FIG. 4B, the UE 106 includes Mobile Equipment (ME) and a USIM. The ME receives the authentication token (AUTN) and the random challenge (RAND) in the NAS message Authentication Request message 416, and forwards the authentication token (AUTN) and the random challenge (RAND) to the USIM. Tire USIM of the UE 106 verifies the freshness of the received values by checking whether the authentication token (AUTN) can be accepted. If so, the USIM computes a response (RES), a cipher key (CK), and an integrity key (IK) based on the random challenge (RAND), and returns the response (RES), the CK key, and the IK key to the ME. The ME of the UE 106 computes RES* from RES, and calculates the Kausf key from CK||IK and the Kseaf key from the Kausf key. The UE 106 sends a NAS message Authentication Response message 417 to SEAF 402 that includes RES*. In response, SEAF 402 computes FIRES* from RES*, and compares HRES* and HXRES*. If they coincide, SEAF 402 considers the authentication successful from the serving network point of view. SEAF 402 sends RES*, as received from the UE 106, in a Nausf_UEAuthentication_Authenticate Request message 418 to AUSF 210. When AUSF 210 receives the Nausf UEAuthentication Authenticate Request message 418 including a RES* as authentication confirmation, AUSF 210 stores the Kausf key based on the home network operator’s policy, and compares the received RES* with the stored XRES*. If the RES* and XRES* are equal, then AUSF 210 considers the authentication successful from the home network point of view. AUSF 210 informs UDM 218 about the authentication result (not shown). AUSF 210 also sends a Nausf_UEAuthentication_Authenticate Response message 419 to SEAF 402 indicating whether or not the authentication was successful from the home network point of view. If the authentication was successful, the Kseaf key is sent to SEAF 402 in the Nausf UEAuthcntication Aiithenticatc Response message 419. In case AUSF 210 received the SUCI from SEAF 402 in the authentication request, AUSF 210 includes the SUPI in the NausfUEAuthenticationAuthenticate Response message 419 if the authentication was successful. As described above, 5G divides UE management into the Non-Access Stratum (NAS) and the Access Stratum (AS). The NAS layer protocol manages the connection between a UE 106 and 5GC 104 (i.e., AMF 212), and the AS layer protocol manages the radio layer between a UE 106 and the RAN 102 (e.g., gNB 302) using RRC protocol. NAS security ensures that NAS signaling between a UE 106 and AMF 212 is protected on the control plane, and AS security ensures that RRC messages on the control plane and user plane traffic (e.g., IP packets) on the user plane are protected. FIG. 5 illustrates NAS and AS security procedures, such as described in 3GPP TS 33.501 (sections 6.4 and 6.7, respectively). For NAS security, a NAS security mode command procedure is performed to establish a NAS security context between the UE 106 and the AMF 212. Each AMF 212 is configured via network management with lists of algorithms that are allowed for usage. Presently, there is one list for NAS integrity algorithms and one for NAS ciphering algorithms that are ordered according to a priority decided by the operator. To establish the NAS security context, AMF 212 selects one NAS ciphering algorithm and one NAS integrity protection algorithm, and derives the NAS integrity key and the NAS encry ption key (e.g., KNASmt and KuASenc) for the selected algorithms. AMF 212 initiates the NAS security mode command procedure by sending a NAS Security Mode Command message 511 to the UE 106. AMF 212 activates NAS integrity protection before sending the NAS Security Mode Command message 511. The NAS Security Mode Command message 511 contains the previously received UE security capabilities, the selected NAS algorithms, a key set identifier (i.e., ngKSI (next generation key set identifier)), and a message authentication code (NAS-MAC) generated by the AMF 212 for integrity protection of the NAS Security Mode Command message 511. The NAS Security Mode Command message 511 is integrity protected (but not ciphered) with the NAS integrity key based on the Kamf key indicated by the ngKSI. AMF 212 activates NAS uplink de-ciphering after sending the NAS Security Mode Command message 511. On receipt of the NAS Security Mode Command message 511, the UE 106 verifies the integrity of the NAS Security Mode Command using the indicated NAS integrity algorithm and the NAS integrity key based on the Kamf key indicated by the ngKSI. The UE 106, with the received algorithms, generates the NAS integrity key and the NAS encryption key in the same manner as AMF 212. If verification is successful, the UE 106 begins NAS integrity protection and ciphering / deciphering with the security context indicated by the ngKSI. The UE 106 sends a NAS Security Mode Complete message 512 to AMF 212 that is ciphered and integrity protected. If the verification of the NAS Security Mode Command message 511 is not successful, the UE 106 replies with aNAS Security Mode Reject message (not shown). AMF 212 de-ciphers and checks the integrity of the received NAS Security Mode Complete message 512 using the key and algorithm indicated in the NAS Security7 Mode Command message 511. AMF 212 activates NAS downlink ciphering after receiving the NAS Security Mode Complete message 512. AS security includes RRC security and User Plane (UP) security. For RRC security, RRC integrity protection and RRC confidentiality protection are provided by the Packet Data Convergence Protocol (PDCP) layer between a UE 106 and a gNB 302. The 5GC 104 supports a PDU connectivity service that provides exchange of PDUs between UE 106 and a data network 108 (identified by a Data Network Name (DNN)) over tire user plane. Security of user plane traffic in 5G networks is controlled by the UP security policy. The SMF 214 provides the UP security policy for a Packet Data Unit (PDU) session to the gNB 302 (or ng-eNB) during the PDU session establishment procedure. The UP security policy indicates whether UP confidentiality protection and / or UP integrity protection are activated for Data Radio Bearers (DRBs) belonging to that PDU session. An AS security mode command procedure is performed to establish an AS security context between the UE 106 and the NG-RAN 502. When the AS security context is to be established in the gNB 302, AMF 212 sends the UE 5G security capabilities with ciphering and integrity protected algorithms and the K8nb key in an NG Application Protocol (NGAP) Initial Context Setup message 513 to the NG-RAN 502 (e.g., gNB 302). Presently, each gNB 302 is configured via network management with lists of algorithms that are allowed for usage. There is one list for integrity algorithms and one for ciphering algorithms that are ordered according to a priority decided by the operator. The gNB 302 selects the AS integrity algorithm and the AS ciphering algorithm which has the highest priority from its configured list and present in the UE 5G security capabilities received from AMF 212. The gNB 302 derives the RRC integrity key (KRRCint), the UP integrity key (Kupint), the RRC ciphering key (Krrc?enc), and the UP ciphering key (Kupenc) for the selected AS algorithms. The gNB 302 starts integrity protection for RRC messages. The gNB 302 sends an integrity protected AS Security Mode Command message 514 to the UE 106, which contains the selected AS integrity algorithm and AS ciphering algorithm, and the message authentication code (MAC-I) generated by the gNB 302 for integrity protection of the AS Security Mode Command message 514. RRC downlink ciphering at the gNB 302 starts after sending the AS Security Mode Command message 514. On receipt of the AS Security Mode Command message 514, the UE 106 derives the RRC integrity key (KRRCint) and the RRC ciphering key (KRRCenc) similar to the gNB 302 based on the selected AS integrity algorithm and AS ciphering algorithm. UE 106 verifies the AS Security Mode Command integrity and, if successful, starts RRC integrity protection and RRC downlink deciphering. The UE 106 then sends an AS Security Mode Complete message 515 with integrity protection to the gNB 302. The AS Security Mode Complete message 515 contains the MAC-I generated by the UE 106 for integrity protection of the AS Security-- Mode Complete message 515. The RRC uplink ciphering at the UE 106 starts after sending the AS Security Mode Complete message 515. Integrity of the AS Security Mode Complete message 515 is verified at the gNB 302, and the gNB 302 starts RRC uplink deciphering. FIGS. 6A-6B illustrate a UP security mechanism. For UP security, SMF 214 stores a UP security policy regarding integrity protection and encryption for the user plane of a PDU session. In general, integrity protection is a mechanism where the receiver of data is able to verify that the received data was actually sent by the sender (i.e., unaltered by an intermediary). For example, a sender may use an integrity algorithm (NIA) to compute a message authentication code (MAC), which is appended to a message when sent. A receiver computes an expected MAC (XMAC) on the message received in the same way as the sender computed its MAC on the message sent, and verifies the data integrity by comparing the computed MAC to the received MAC. Encryption or ciphering is a process of encoding data so that it may not be accessed by unauthorized parties. For example, a sender may use a ciphering or encryption algorithm (NEA) to encry pt a plaintext block with an associated encryption key to produce a ciphertext block. The plaintext may be recovered, such as at a receiver, by decrypting the ciphertext block in a similar manner with the encryption key. SMF 214 is configured to provide the UP security policy for the PDU session to NG-RAN 502 (e.g., gNB 302) during the PDU session establishment procedure, as specified in 3GPP TS 23.502 (Release 18), which is incorporated by reference as if fully included herein. The UP security policy indicates whether UP confidentiality protection and / or UP integrity protection is activated or not for all DRBs belonging to that PDU session. The UP security policy is used to activate UP confidentiality protection and / or UP integrity protection in the UE 106 and NG-RAN 502 for all DRBs belonging to the PDU session. FIG. 6A illustrates an abbreviated version of the PDU session establishment procedure. PDU session establishment is the process of establishing a user plane data path between a UE 106 and the 5GC 104. A PDU session is a logical connection or association between a UE and a data network, such as the internet or a private network. For the PDU session establishment procedure, AMF 212 receives a PDU session establishment request 611, such as from UE 106, requesting establishment of a new PDU session. AMF 212 selects an SMF 214, and sends a Nsmf_PDUSession_CreateSMContext Request 612 to the SMF 214 indicating the PDU Session ID along with other information. SMF 214 creates a session management (SM) context for the PDU session, which includes determining and / or storing a UP security policy 620 for integrity' protection and encryption of the user plane for the PDU session. SMF 214 replies to AMF 212 with a Nsmf_PDUSession_CreateSMContext Response 613. As described above, the SMF 214 provides the UP security policy 620 for a PDU session to the gNB 302 during the PDU session establishment procedure. Thus, SMF 214 invokes the Namf_Communication_NlN2MessageTransfer service operation, and sends a Namf_Communication_NlN2MessageTransfer message 614 to AMF 212. Tire Namf_Communication_NlN2MessageTransfer message 614 includes N2 SM information, which carries information that the AMF 212 forwards to the NG-RAN 502. Tire N2 SM infonnation includes UP security enforcement information 622 determined by the SMF 214, as described in section 5.10.3 of 3GPP TS 23.501. The UP security enforcement information 622 provides the NG-RAN 502 with the UP security policy 620 for the PDU session. The UP security enforcement infonnation 622 indicates whether UP integrity protection is: “Required” (i.e., UP integrity protection shall apply for all traffic on the PDU Session), “Preferred” (i.e., UP integrity protection should apply for all traffic on the PDU Session), or “Not Needed” (i.e., UP integrity protection shall not apply on the PDU Session). The UP security enforcement infonnation 622 also indicates whether UP confidentiality protection is: “Required” (i.e., UP confidentiality protection shall apply for all traffic on the PDU Session), “Preferred” (i.e., UP confidentiality protection should apply for all traffic on the PDU Session), or “Not Needed” (i.e., UP confidentiality shall not apply on the PDU Session). SMF 214 determines, at PDU session establishment, the UP security enforcement information 622 for the user plane of a PDU session based on the subscribed UP security policy which is part of SM subscription information received from UDM 218, the UP security policy stored locally in the SMF 214 that is used when UDM 218 does not provide UP security policy information, and / or the maximinn supported data rate per UE for integrity protection for the DRBs, provided by the UE 106 in the integrity protection maximum data rate Information Element (IE) during PDU Session Establishment. Once determined at the establishment of the PDU session, the UP security enforcement information 622 applies for the life time of the PDU session. The UP security enforcement information 622 is communicated from SMF 214 to the NG-RAN 502 for enforcement as part of PDU session related information. If the UP integrity protection is determined to be “Required” or “Preferred”, SMF 214 also provides the maximum supported data rate per UE for integrity protection. In response to the Namf_Communication_NlN2MessageTransfer message 614, AMF 212 sends an N2 PDU Session Request 615 to the NG-RAN 502. The N2 PDU Session Request 615 includes the N2 SM information received from the SMF 214, such as the UP security enforcement information 622. In FIG. 6B, NG-RAN 502 may issue an AN-specific signaling exchange with the UE 106 that is related with the information received from SMF 214. For example, the gNB 302 may initiate the RRC Connection Reconfiguration procedure, which is used to add DRBs for the PDU session. The RRC Connection Reconfiguration procedure is performed after RRC security has been activated as part of the AS security mode command procedure. The gNB 302 sends an RRC Connection Reconfiguration message 616 to the UE 106 for UP security activation. The RRC Connection Reconfiguration message 616 contains indications for the activation of UP integrity protection and UP ciphering for each DRB according to the UP security policy 620. If UP integrity protection is activated for a DRB as indicated in the RRC Connection Reconfiguration message 616 and the gNB 302 does not have the Kupint key, then the gNB 302 derives the Kupmt key and UP integrity protection for the DRB starts at the gNB 302. Similarly, if UP ciphering is activated for the DRB as indicated in the RRC Connection Reconfiguration message 616 and the gNB 302 does not have the Kupenc key, then the gNB 302 derives the Kupenc key and UP ciphering for the DRB starts at the gNB 302. According to 3GPP TS 33.501 (section 6.6.1), the gNB 302 shall activate UP confidentiality and / or UP integrity protection per each DRB, according to the received UP security policy 620. When the UP security policy 620 indicates “Required” or “Not Needed”, the gNB 302 shall not overrule the UP security policy 620 provided by SMF 214. If the gNB 302 cannot activate UP confidentiality' and / or UP integrity protection when the received UP security policy 620 is “Required”, the gNB 302 rejects establishment of UP resources for the PDU session and indicates a reject-cause to SMF 214. When the received UP security policy 620 is “Not Needed”, the establishment of the PDU session proceeds. On receipt of the RRC Connection Reconfiguration message 616, the UE 106 verifies the RRC Connection Reconfiguration integrity protection. If successful, the UE 106 performs the following. When UP integrity protection is activated for a DRB as indicated in the RRC Connection Reconfiguration message 616 and the UE 106 does not have the Kupint key, the UE 106 derives the Kupint key and UP integrity protection for the DRB starts at the UE 106. Similarly, when UP ciphering is activated for the DRB as indicated in the RRC Connection Reconfiguration message 616 and the UE 106 does not have the Kupenc key, the UE 106 derives tire Kupenc key and UP ciphering for the DRB starts at the UE 106. The UE 106 sends an RRC Connection Reconfiguration Complete message 617 to the gNB 302. FIG. 7 illustrates a key hierarchy 700 of a 5G system 100, such as in 3GPP TS 33.501 (section 6.2). The keys related to authentication include the following keys: K701, and CK / IK 702. The key hierarchy 700 includes the following keys: Kausf 703, Kseaf 704, Kamf 705, KNASmt 706, KNASenc 707, Knsiwf 708, KgNB 709, KRRCint 710, Krkcok 711, Kupint 712, and Kupenc 713. The keys for AUSF 210 in the home network 404 include the Kausf key 703 derived by the ME of a UE 106 and AUSF 210 from CK, IK in case of EAP-AKA', or by the ME and the ARPF of UDM 218 from CK, IK 702 in case of 5G AKA. The Kseaf key 704 is the anchor key derived by the ME and AUSF 210 from the Kausf key 703. The key for AMF 212 in the serving network 406 is the Kamf key 705 derived by the ME and the SEAF 402 from the Kseaf key 704. The keys for NAS signaling (i.e., of a NAS security context) include the KNASmt key 706 derived by the ME and AMF 212 from the Kamf key 705, which is used for integrity protection of NAS signaling with a particular integrity algorithm. The keys for NAS signaling also include the K^senc key 707 derived by the ME and AMF 212 from the Kamf key 705, which is used for encryption of NAS signaling with a particular encry ption algorithm. The key for the NG-RAN is the KgNB key 709 derived by the ME and AMF 212 from the Kamf key 705. For an AS security context, the keys for RRC signaling include the KRRcmt key 710 derived by the ME and the gNB 302 from the Ksnb key 709, which is used for integrity protection of RRC signaling with a particular integrity algorithm. The keys for RRC signaling further include the KRRCenc key 711 derived by the ME and the gNB 302 from the K8nb key 709, which is used for encryption of RRC signaling with a particular encryption algorithm. The keys for UP traffic include the Kupmt key 712 derived by the ME and the gNB 302 from the K8nb key 709, which is used for integrity protection of UP traffic between the ME and the gNB 302 with a particular integrity algorithm. The keys for UP traffic further include the Kupenc key 713 derived by the ME and the gNB 302 from the Ksnb key 709, which is used for encryption of UP traffic with a particular encryption algorithm. For non-3GPP access, the Knsiwf key 708 is derived by the ME and the AMF 212 from the Kamf key 705 for non-3GPP access. There are other keys as part of the key hierarchy 700 of a 5G system 100, which are not discussed for the sake of brevity. FIG. 8 illustrates the NAS functional layer 802 and the AS functional layer 804 in a 5G system 100. The UE 106 is operatively coupled to 5G network 101. The NAS functional layer 802 is between the UE 106 and AMF 212 (or Mobility Management Entity (MME)), and therefore, NAS signaling 812 may be exchanged between the UE 106 and AMF 212. The AS functional layer 804 is between the UE 106 and a RAN node 800 (e.g., gNB 302). RRC signaling 814 may be exchanged between the UE 106 and the RAN node 800 via one or more Signaling Radio Bearers (SRB) 816. Additionally, when a PDU session 830 is established, UP traffic 818 may be exchanged between the UE 106 and the RAN node 800 via one or more Data Radio Bearers (DRB) 820. For example, the UP traffic 818 may comprise UP packets 822, such as IP packets 824. Although it is mandated in 5G that the UE 106 and gNB 302 support integrity protection and encryption of UP traffic 818, the use of integrity protection and encryption is not mandated for the user plane. Presently, many mobile networks use encryption for the user plane, but no integrity protection. Presumedly, pervasive usage of integrity protection on the user plane would significantly reduce the overall achievable transmission throughput. While applying integrity protection to all UP traffic 818 may be possible from a processing power viewpoint, it would further significantly increase energy consumption per transmitted bit and potentially cause overheating in UEs, which can further reduce UE performance. Provided herein are enhanced UP security mechanisms for UP protection (i.e., integrity protection and confidentiality protection) on the user plane. The enhanced UP security mechanisms provide for partial UP protection of UP traffic 818 (i.e., partial integrity protection and / or partial confidentiality protection). More particularly, an enhanced UP security policy is set forth to specify or indicate an incomplete or partial segment, part, or portion of a UP packet 822 to be integrity protected and / or a portion of the UP packet 822 to be encrypted. In other words, the enhanced UP security policy specifies which part of a UP packet 822 is to be integrity protected and which part is to be encrypted, as opposed to applying integrity' protection and / or encryption to the full or complete UP packet 822. Enhanced UP security mechanisms are described in further detail below. In general, the mechanisms are implemented via one or more network functions (e.g., SMF 214), one or more RAN nodes 800 (e.g., gNB 302), and a UE 106. Block diagrams ofthese elements are provided below. FIG. 9 is a block diagram of an SMF 214 in an illustrative embodiment. SMF 214 is a network element or network function configured provide management of PDU sessions. In this embodiment, SMF 214 comprises tire following subsystems: a network interface component 902, and a session management controller 904 that operate on one or more platforms. Network interface component 902 may comprise circuitry, logic, hardware, means, etc., configured to exchange control plane messages or signaling with other network elements and / or UEs. Network interface component 902 may operate using a variety of protocols or reference points. Session management controller 904 may comprise circuitry, logic, hardware, means, etc., configured to support operations, procedures, or functions of an SMF. One or more of the subsystems of SMF 214 may be implemented on a hardware platform comprised of analog and / or digital circuitry. One or more of the subsystems of SMF 214 may be implemented on one or more processors 930 that execute instructions 934 (i.e., computer readable code) for software that are loaded into memory 932. One or more of the subsystems of SMF 214 may be implemented on a cloud-computing platform or another type of processing platform. SMF 214 may comprise various other components not specifically illustrated in FIG. 9. FIG. 10 is a block diagram of a RAN node 800 in an illustrative embodiment. RAN node 800 comprises a server, device, apparatus, equipment (including hardware), system, network element, means, etc., of a RAN 102 (or NG-RAN) that provides connectivity between a UE 106 and a core network (e.g., 5GC 104). In this embodiment, RAN node 800 comprises the following subsystems: a radio interface component 1002, a network interface component 1004, and a node controller 1006 that operate on one or more platforms. Radio interface component 1002 may comprise circuitry, logic, hardware, means, etc., configured to exchange messages or signaling with UEs via the air interface. Radio interface component 1002 may be configured for 5G NR, LTE, WiFi, Bluetooth, etc. Network interface component 1004 may comprise circuitry, logic, hardware, means, etc., configured to exchange messages or signaling with other network elements or network functions, such as of a 5GC 104. Network interface component 1004 may operate using a variety of protocols or reference points. Node controller 1006 may comprise circuitry, logic, hardware, means, etc., configured to support operations or procedures performed in a RAN node 800 of a mobile network. As illustrated in FIG. 10, RAN node 800 may represent a gNB 302, a component of a gNB 302 (e.g., a Centralized Unit (CU), a Distributed Unit (DU), and / or a Radio Unit (RU)), or another type of base station or NG base station. One or more of the subsystems of RAN node 800 may be implemented on a hardware platform comprised of analog and / or digital circuitry. One or more of the subsystems of RAN node 800 may be implemented on one or more processors 1030 that execute instructions 1034 (i.e., computer readable code) for software that are loaded into memory 1032. A processor 1030 comprises an integrated hardware circuit configured to execute instructions 1034 to provide the functions of RAN node 800. Processor 1030 may comprise a set of one or more processors or may comprise a multiprocessor core, depending on the particular implementation. Memoiy 1032 is a non-transitory computer readable storage medium for data, instructions, applications, etc., and is accessible by processor 1030. Memory 1032 is a hardware storage device capable of storing information on a temporary basis and / or a permanent basis. Memory 1032 may comprise a random-access memory, or any other volatile or non-volatile storage device. RAN node 800 may comprise various other components not specifically illustrated in FIG. 10. FIG. 11 is a block diagram of a UE 106 in an illustrative embodiment. From a functional standpoint, the UE 106 is composed of at least two parts: Mobile Equipment (ME) 1100 and a Universal Subscriber Identity Module (USIM) 1160. ME 1100 comprises a radio interface component 1102, one or more processors 1104, a memory 1106, and a user interface component 1108. The UE 106 may also comprise a battery 1110. Radio interface component 1102 is a hardware component or means that represents the local radio resources of the UE 106, such as a Radio Frequency (RF) unit 1120 (e.g., one or more radio transceivers) and one or more antennas 1122. Radio interface component 1102 may be configured for 5G New Radio (NR), Long Term Evolution (LTE), WiFi, Bluetooth, etc. Processor 1104 represents the internal circuitry, logic, hardware, means, etc., that provides the functions of the UE 106. Processor 1104 may be configured to execute instructions 1140 for software that are loaded into memory' 1106. Processor 1104 may execute an Operating System (OS) 1134 for the UE 106 that manages hardware and software resources, and one or more application clients 1135 for an application. Processor 1104 may also execute a security controller 1136, which comprises a component or means for performing security mechanisms within the UE 106 (i.e., within the ME 1100), such as integrity protection mechanisms and / or encryption mechanisms. User interface component 1108 is a hardware component for interacting with an end user. For example, user interface component 1108 may comprise a display 1150, screen, touch screen, and / or the like (e.g., a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display, etc.). User interface component 1108 may include a keyboard or keypad, a tracking device (e.g., a trackball or trackpad), a speaker, a microphone, etc. USIM 1160 is an integrated circuit that provides security and integrity functions for the UE 106. USIM 1160 includes or is provisioned with a subscription profile associated with a subscription of a subscriber. A subscription profile may include a variety of information, such as subscription credentials (e.g., SUPI) used to uniquely identify a subscription and to mutually authenticate the UE 106 and a network. The UE 106 may comprise various other components not specifically illustrated in FIG. 11. FIGS. 12A-12B are message diagrams illustrating enhanced UP security mechanisms in an illustrative embodiment. FIG. 13 is a flow chart illustrating a method 1300 of conveying an enhanced UP security policy in an illustrative embodiment. Tire steps of method 1300 will be described with reference to SMF 214, but those skilled m the art will appreciate that method 1300 may be performed in other systems or devices. The steps of the flow charts described herein are not all inclusive and may include other steps not shown, and the steps may be performed in an alternative order. In FIG. 12A and FIG. 13, SMF 214 determines, receives, establishes, or otherwise obtains an enhanced UP security policy 1220 for a PDU session 830 of a UE 106 (step 1302). An enhanced UP security policy 1220 defines partial UP protection for a PDU session 830, and includes UP security parameters that specify or indicate a portion of a UP packet 822 to be integrity protected and / or a portion to be encrypted. SMF 214 may determine, at PDU session establishment, the enhanced UP security policy 1220 for the user plane of the PDU session 830 based on the subscribed UP security policy, the UP security policy stored locally in the SMF 214, the maximum supported data rate per UE for integrity protection for the DRBs provided by the UE 106, and / or other information. SMF 214 may take the UE capabilities into account to decide the partial UP protection. FIGS. 14A-14D illustrate an enhanced UP security policy 1220 in illustrative embodiments. In general, enhanced UP security policy 1220 is the security policy for integrity protection and encryption for the user plane of a PDU session 830. In FIG. 14A, enhanced UP security policy 1220 includes one or more UP security parameters 1422 (also referred to as attributes, Information Elements (IE), enhanced UP security parameters, etc.). The UP security parameters 1422 may include one or more limited, qualified, bounded, or partial UP integrity protection parameters 1424 (e.g., partial UP integrity protection parameters 1424-1, 1424-2, etc.) that specify or indicate partial integrity7 protection for UP traffic 818. For example, the partial UP integrity protection parameters 1424 specify a portion of a UP packet 822 to be integrity protected, such as particular bytes in each UP packet 822 of the UP traffic 818. The UP security parameters 1422 may include one or more limited, qualified, bounded, or partial UP encryption parameters 1426 (e.g., partial UP encryption parameters 1426-1, 1426-2, etc.) that specify or indicate partial confidentiality protection for UP traffic 818. For example, the partial UP encry ption parameters 1426 specify a portion of a UP packet 822 to be encrypted, such as particular bytes in each UP packet 822 of the UP traffic 818. The partial UP integrity protection parameters 1424 and the partial UP encryption parameters 1426 are referred to as “bounded” or “partial”, as they designate UP protection for a portion of a UP packet 822 as opposed to a fiill or entire UP packet 822. Enhanced UP security policy 1220 may include additional parameters, such as parameters presently defined for a UP security policy 620 in 5G. For example, enhanced UP security policy 1220 may further include a parameter indicating the maximum integrity protected data rate supported by the UE 106 for uplink, a parameter indicating the maximum integrity protected data rate supported by the UE 106 for downlink, a parameter indicating a security result associated to the PDU session 830, etc. One technical benefit is the enhanced UP security policy 1220 provides for partial UP protection of the UP traffic 818. FIG. 15 illustrates a UP packet 822 in an illustrative embodiment. Partial UP integrity protection parameters 1424 may specify a portion (also referred to as an integrity protection portion 1524) of the UP packet 822 to be integrity protected. Partial UP encryption parameters 1426 may specify a portion (also referred to as an encryption portion 1526) of the UP packet 822 to be encrypted. The integrity protection portion 1524 and the encryption portion 1526 may be the same or different depending on the enhanced UP security policy 1220. The UP security parameters 1422may vary depending on desired implementation. In FIG. 14B, for example, the partial UP integrity protection parameters 1424 may include a start integrity protection parameter 1432 indicating the first byte of a UP packet 822 to be integrity protected, and an integrity protection size parameter 1434 indicating a number of bytes of the UP packet 822 to be integrity protected starting with the first byte. Tire partial UP encryption parameters 1426 may include a start encryption parameter 1436 indicating a first byte of a UP packet 822 to be encrypted, and an encryption size parameter 1438 indicating a number of bytes of the UP packet 822 to be encrypted starting with the first byte. In an embodiment, the size (i.e., number of bytes) may be selected as a multiple of the typical block size for cryptographic algorithms (i.e., integrity protection algorithm and encryption algorithm). For example, the size may be a multiple of 16 bytes, to cover block sizes of 64-bit, 128-bit, 256-bit, etc., as used in integrity protection and encryption algorithms. One technical benefit is the enhanced UP security policy 1220 indicates specific bytes of UP packets 822 targeted for UP protection. In FIG. 14C, for example, the partial UP integrity protection parameters 1424 may include a start integrity protection parameter 1442 indicating the first byte of a UP packet 822 to be integrity protected, and a stop integrity protection parameter 1444 indicating a last byte of the UP packet 822 to be integrity protected. The partial UP encryption parameters 1426 may include a start encry ption parameter 1446 indicating a first byte of a UP packet 822 to be encrypted, and a stop enciy ption parameter 1448 indicating a last byte of the UP packet 822 to be encrypted. One technical benefit is the enhanced UP security policy 1220 indicates specific bytes of UP packets 822 targeted for UP protection. In FIG. 14D, for example, the UP security parameters 1422 may include a full integrity protection parameter 1452 indicating that the entire UP packet 822 is to be integrity protected. The UP security parameters 1422 may include a full encryption parameter 1456 indicating that the entire UP packet 822 is to be encrypted. One technical benefit is the enhanced UP security' policy 1220 may indicate when full UP protection is desirable for a UP packet 822. FIGS. 14B-14D show examples of the UP security parameters 1422, and other types of parameters are considered herein to specify which part of a UP packet 822 is to be integrity protected and which part is to be encrypted. For example, one set of UP security7 parameters 1422 may define how much data of a UP packet 822 requires protection, and another set of UP security7 parameters 1422 may extend the number of bytes protected in the UP packet 822. This may allow for both ‘‘Required” and “Preferred” to be signaled at the same time, with the preferred protection range extended compared to the required protection range. Also, different combinations of the parameters described above may be implemented as desired. In FIG. 12A and FIG. 13, SMF 214 sends, transfers, or otherwise provides the enhanced UP security policy 1220 to the RAN node 800 that serves the UE 106 of the PDU session 830 (step 1304), indicating the enhanced UP security parameters 1422. SMF 214 may provide the enhanced UP security policy 1220 to RAN node 800 during PDU session establishment. In FIG. 12B, for example, SMF 214 may send the enhanced UP security policy 1220 toward RAN node 800 through AMF 212. SMF 214 may send a message transfer request 1201 to AMF 212 containing the enhanced UP security-policy 1220 (optional step 1308 in FIG. 13), such as an Xamf Communication \ lN2MessagcTransfcr message 614. In response to the message transfer request 1201, AMF 212 may send a PDU session request 1202 to RAN node 800 containing the enhanced UP security policy 1220, such as an N2 PDU Session Request 615. One technical benefit is the enhanced UP security policy 1220, determined by SMF 214 and provided to the RAN node 800, allows for partial UP protection, where integrity protection and / or confidentiality protection are targeted to specific portions of a UP packet 822 as opposed to applying integrity protection and / or encryption to the entirety (i.e., entire length) of a UP packet 822. This avoids redundant or unnecessary UP protection when security gains are minimal. Further, partial UP protection may decrease the burden on compute resources in the UE 106 and RAN node 800, and reduce energy consumption and heating within the UE 106. FIG. 16 is a flow chart illustrating a method 1600 of establishing UP security in an illustrative embodiment. The steps of method 1600 will be described with reference to RAN node 800 in FIG. 10, but those skilled in the art will appreciate that method 1600 may be performed in other systems or devices. RAN node 800 receives the enhanced UP security policy 1220 provided by SMF 214 (step 1602). In FIG. 12B, for example, RAN node 800 may receive a PDU session request 1202 from AMF 212 containing the enhanced UP security policy 1220, and extract the enhanced UP security policy 1220 (i.e., extract the enhanced UP security parameters 1422) from the PDU session request 1202 (optional step 1608). RAN node 800 sends, transfers, or otherwise provides the enhanced UP security policy 1220 to the UE 106 of the PDU session 830 (step 1604) over the air interface. In FIG. 12B, for example, RAN node 800 may send the enhanced UP security policy 1220 to UE 106 in an RRC message / signaling 1203 (optional step 1610), such as an RRC Connection Reconfiguration message 616. RAN node 800 activates UP confidentiality and / or UP integrity protection per each DRB 820 of the PDU session 830 according to the enhanced UP security policy 1220 (step 1606). Thus, RAN node 800 may apply UP integrity protection (i.e., generate a MAC-I) or verify UP integrity protection (i.e., verify a MAC-I) to a portion 1524 (i.e., integrity protection portion) of a UP packet 822, and / or apply encryption / decryption to a portion 1526 (i.e., encryption portion) of a UP packet 822 based on the UP security parameters 1422 defined in the enhanced UP security policy 1220. One technical benefit is the RAN node 800 is able to receive an enhanced UP security- policy 1220 determined by SMF 214, and provide for partial UP protection of UP traffic 818 based on the enhanced UP security policy 1220. FIG. 17 is a flow chart illustrating a method 1700 of establishing UP security in an illustrative embodiment. The steps of method 1700 will be described with reference to UE 106 in FIG. 11, but those skilled in the art will appreciate that method 1700 may be performed in other systems or devices. UE 106 receives the enhanced UP security policy 1220 provided by RAN node 800 (step 1702). In FIG. 12B, for example, UE 106 may receive an RRC message 1203 from RAN node 800 containing the enhanced UP security policy 1220, and extract the enhanced UP security policy 1220 (i.e., extract the enhanced UP security parameters 1422) from the RRC message 1203 (optional step 1706). UE 106 activates UP confidentiality and / or UP integrity protection per each DRB 820 of the PDU session 830 according to die enhanced UP security policy 1220 (step 1704). Thus, UE 106 may apply UP integrity protection (i.e., generate a MAC-I) or verify UP integrity protection (i.e., verify a MAC-1) to a portion 1524 (i.e., integrity protection portion) of a UP packet 822, and / or apply encryption / decryption to a portion 1526 (i.e., encry ption portion) of a UP packet 822 based on the UP security parameters 1422 defined in the enhanced UP security policy 1220. One technical benefit is the UE 106 is able to receive an enhanced UP security policy 1220 from RAN node 800, and provide for partial UP protection of UP traffic 818 based on the enhanced UP security policy 1220. In handover of the PDU session 830 from one RAN node 800 to another, the enhanced UP security policy 1220 is provided to the new RAN node 800. When UP protection changes at handover (e.g., due to the new RAN node 800 having different capabilities), new parameters may be included in the reconfiguration. The enhanced UP security policy 1220 as described herein may be a revision or extension to UP security information presently set forth or standardized, such as by the 3GPP. For example, 3GPP TS 29.502 (Release 18), which is incorporated by reference as if fully included herein, defines UP security information in section 6.1.6.2.59. FIG. 18 illustrates a “UpSecuritylnfo” data type 1800 as in 3GPP TS 29.502. The “UpSecurityinfo” data type 1800 includes the following attributes or lEs: “upSecurity”, “maxIntegrityProtectedDataRateUl”, “maxIntegrityProtectedDataRateDl”, and “securityResult”. The “upSecurity” IE 1802 indicates the security policy for integrity protection and encryption for the user plane of a PDU session. The “maxIntegrityProtectedDataRateUl” IE 1804 is present if the “upSecurity” IE 1802 is present and indicates that integrity protection is preferred or required. When present, the “maxIntegrityProtectedDataRateUl” IE 1804 indicates the maximum integrity protected data rate supported by the UE 106 for uplink. Ilie “maxIntegrityProtectedDataRateDl” IE 1806 is present if the “upSecurity” IE 1802 is present and indicates that integrity protection is preferred or required. When present, the “maxintegrityProtectedDataRateDI” IE 1806 indicates the maximum integrity protected data rate supported by the UE 106 for downlink. The “security Re suit” IE 1808 is included if available, and contains the security result associated to the PDU session. Certain lEs for transmitting user plane security policy information are further described in 3GPP TS 38.413 (Release 18), which is incorporated by reference as if fully included herein. The “upSecurity” IE 1802 is of datatype “UpSecurity” defined in 3GPP TS 29.571 (Release 18), which is incorporated by reference as if fully included herein. FIG. 19 illustrates a “UpSecurity” datatype 1900 as in section 5.4.4.11 of 3GPP TS 29.571. The “UpSecurity” data ty pe 1900 includes the following attributes or IEs: “uplntegr” and “upConfid”. Hie “uplntegr” IE 1902 indicates whether UP integrity protection is required, preferred, or not needed for all the traffic on the PDU session. The “upConfid” IE 1904 indicates whether UP confidentiality protection is required, preferred, or not needed for all the traffic on the PDU session. The “uplntegr” IE 1902 is of data type “Uplntegrity”, which is defined in section 5.4.3.4 of 3GPP TS 29.571. FIG. 20 illustrates a “Uplntegrity” enumeration 2000 as in 3GPP TS 29.571. The “Uplntegrity” enumeration 2000 indicates whether UP integrity protection is required, preferred, or not needed for all the traffic on the PDU Session. The “Uplntegrity” enumeration 2000 includes the following enumeration values: a “REQUIRED” value 2002 indicating UP integrity protection shall apply for all the traffic on the PDU session, a “PREFERRED” value 2004 indicating UP integrity protection should apply for all the traffic on the PDU session, and a "‘NOT^NEEDED” value 2006 indicating UP integrity protection shall not apply on the PDU session. The “upConfid” IE 1904 is of data type “UpConfidentiality”, which is defined in section 5.4.3.5 of 3GPP TS 29.571. FIG. 21 illustrates a “UpConfidentiality” enumeration 2100 as in 3GPP TS 29.571. The “UpConfidentiality” enumeration 2100 indicates whether UP confidentiality protection is required, preferred, or not needed for all the traffic on the PDU Session. The “UpConfidentiality” enumeration 2100 includes the following enumeration values: a “REQUIRED” value 2102 indicating UP confidentiality protection shall apply for all the traffic on the PDU session, a “PREFERRED” value 2104 indicating UP confidentiality protection should apply for all the traffic on the PDU session, and a “NOT NEEDED” value 2106 indicating UP confidentiality protection shall not apply on the PDU session. In an embodiment, the UP security parameters 1422 described above may comprise a revision or extension to the “UpSecurity” data type 1900. FIGS. 22-24 illustrate examples of extensions to the “UpSecurity” data type 1900 to add enhanced UP security parameters 1422 of the enhanced UP security policy 1220. Tire extensions are described in relation to specific data types. Elowever, the enhanced UP security parameters 1422 as described below may be used as extensions to other data types or Information Elements (IEs) as desired. For example, one or more of the enhanced UP security parameters 1422 may be used as an extension to the Security Indication IE defined in 3GPP TS 38.413 in section 9.3.1.27. Also, different combinations of the enhanced UP security parameters 1422 may be used as an extension to a data type or IE. FIG. 22 illustrates a revised “UpSecurity” data type 2200 in an illustrative embodiment. The revised “UpSecurity” data type 2200 may include the following additional parameters, attributes, or IEs: “startlntegrityProt”, “sizelntegrityProt”, “startEncryption”, and “sizeEncryption” representing enhanced UP security parameters 1422. The “startlntegrityProt” IE 2206 is an integer value indicating the first byte of a UP packet to be integrity protected. The “sizelntegrityProt” IE 2208 is an integer value indicating the number of bytes to be integrity protected, starting with the first byte indicated by the “startlntegrityProt” IE 2206. The “startEncryption” IE 2210 is an integer value indicating the first byte of a UP packet to be encrypted. The “sizeEncryption” IE 2212 is an integer value indicating the number of bytes to be encrypted, starting with the first byte indicated by the “startEncryption” IE 2210. These parameters are applicable in case UP protection is “REQUIRED” or “PREFERRED”. In an embodiment, specific or predefined values of these parameters (or additional flags) may indicate that UP protection is to be applied to the full or complete UP packet 822. For example, a predefined value for the “startlntegrityProt” IE 2206 and / or the “sizelntegrityProt” IE 2208, such as “-1”, may indicate that the full UP packet 822 is to be integrity protected. A predefined value for the “startEncryption” IE 2210 and / or the “sizeEncryption” IE 2212 may indicate that the full UP packet 822 is to be encrypted. FIG. 23 illustrates another revised “UpSecurity” data type 2300 in an illustrative embodiment. The revised “UpSecurity” datatype 2300 may include the following additional parameters, attributes, or IEs: “startlntegrityProt”, “stopintegrity Prot”, “startEncryption”, and “stopEncryption” representing enhanced UP security parameters 1422. The “startlntegrityProt” IE 2306 is an integer value indicating the first byte of a UP packet to be integrity protected. The “stopIntegrityProt” IE 2308 is an integer value indicating the last byte of a UP packet to be integrity protected. The “startEncryption" IE 2310 is an integer value indicating the first byte of a UP packet to be encrypted. The “stopEncryption” IE 2312 is an integer value indicating the last byte of a UP packet 822 to be encrypted. These parameters are applicable in case UP protection is “REQUIRED” or “PREFERRED”. In an embodiment, specific or predefined values of these parameters (or additional flags) may indicate that UP protection is to be applied to the full or complete UP packet 822. For example, a predefined value for the “startlntegrityProt” IE 2306 and / or the “stopIntegrityProt” IE 2308, such as “-1”, may indicate that the full UP packet 822 is to be integrity protected. A predefined value for the “startEncryption” IE 2310 and / or the “stopEncry ption” IE 2312 may indicate that the full UP packet 822 is to be encrypted. FIG. 24 illustrates another revised “UpSecurity” data type 2400 in an illustrative embodiment. The revised “UpSecurity” data type 2400 may include the following additional parameters, attributes, or IEs: “fullPacketintegrityProt”. and “fullPacketEncryption” representing enhanced UP security parameters 1422. The “fullPacketlntegrityProt” IE 2414 is a Boolean value indicating whether UP integrity protection is required for the full or entire UP packet 822. The “fullPacketEncryption” IE 2416 is a Boolean value indicating whether UP confidentiality protection is required for the full or entire UP packet 822. One technical benefit of the revisions disclosed in FIGS. 22-24 is SMF 214 is able to transmit or provide an enhanced UP security policy 1220 to other elements, such as RAN node 800. FIG. 25 illustrates a UE 106 accessing an external application service in an illustrative embodiment. In this example, 5G system 100 includes a RAN 102 and a 5GC 104 as discussed above. RAN 102 includes one or more RAN nodes 800, which are equipment, hardware, means, etc., of a RAN 102 that serves a UE 106 (e.g., a gNB, a gNB-CU, a gNB-DU, and / or another type of node implemented in a RAN). As described above, Network Functions (NF) for 5GC 104 are separated into the control plane (CP) 2520 and the user plane (UP) 2522. The control plane 2520 includes AUSF 210, AMF 212, SMF 214, UDM 218, and AF 222. The user plane 2522 includes one or more UPFs 240. UE 106 is able to access the control plane 2520 and the user plane 2522 through RAN 102. In this example, an application service 2510 (also referred to as a third-party application service) is implemented in an external data network 108, such as by an Application Service Provider (ASP), and is accessible to UE 106 through the 5G system 100. An ASP is an entity-- (including physical or virtual resources) that offers users or subscribers access to applications and related services over one or more networks. Examples of application service 2510 offered by an ASP include, but are not limited to, gaming, Augmented reality (AR) and / or Virtual Reality (VR), audio or video streaming (e.g., of mass events such as concerts, sport tournaments, etc.), network-assisted control of autonomously guided vehicles (AGV), network-assisted control of mobile robots in a factoryetc. In this example, the application service 2510 is provided or implemented on one or more application servers 2512. UE 106 hosts an application client 1135, which is an application (e.g., stand-alone application), component, executable code, means, etc., that runs on UE 106, and is configured to access an application service 2510. For example, application client 1135 interacts with control plane NFs (e.g., AF 222) to establish an application session with the application service 2510. With the application session established, data may be exchanged between the application client 1135 and the application service 2510 over the user plane 2522 through one or more RAN nodes 800 and one or more UPFs 240. For example, data in the form of UP packets 822 may be exchanged between tire application client 1135 and the application service 2510 on a PDU session 830. In an embodiment, an Authentication, Authorization, and Accounting (AAA) server 2514 of the ASP may be involved in establishing end-to-end (e2e) protection for the UP packets 822 exchanged on the PDU session 830 between the application client 1135 and the application service 2510. In many cases, the external data network 108 is a public network, such as the Internet. So, many applications apply e2e protection, using readily available security protocols such as Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), or Secure Real-time Transport Protocol (SRTP). As an example, most of the web traffic today uses Hypertext Transfer Protocol Secure (HTTPS), i.e. HTTP over TLS. Similarly, many smartphone applications use e2e protection by TLS between the application client and the respective application server. However, protocols such as (D)TLS and SRTP operate above the IP layer. Consequently, lower layer headers, specifically IP headers, are not protected. Without mobile network UP security, eavesdroppers on the radio interface would be able to observe which servers a UE 106 contacts at which time, and how much data it exchanges with these servers. Further, attackers could modify header information, such as changing the IP destination address, of a UP packet 822 sent by the UE 106, to the IP address of a server owned by the attacker. In an embodiment, the enhanced UP security policy 1220 may provide UP protection for one or more headers in a UP packet 822, such as an IP header. FIG. 26 illustrates a UP packet 822 in an illustrative embodiment. UP packet 822 may include one or more headers 2610 and associated payload. In an embodiment, UP packet 822 includes an IP packet 824. IP packet 824 includes an IP header 2604 and an IP transport payload 2606. The IP transport payload 2606 carries data for higher layers, such as the application layer where e2e protection applies. Thus, the IP header 2604 may not be protected even if the IP transport payload or parts of the IP transport payload are protected via the e2e protection mechanism. The enhanced UP security policy 1220 may provide UP protection for one or more headers 2610 in a UP packet 822, such as the IP header 2604. In FIG. 14B, for example, the start integrity protection parameter 1432 and the integrity protection size parameter 1434 may target the IP header 2604 for integrity protection, and the start enciyption parameter 1436 and the encryption size parameter 1438 may target the IP header 2604 for encryption. In FIG. 14C, for example, the start integrity protection parameter 1442 and the stop integrity protection parameter 1444 may target the IP header 2604 for integrity protection, and the start encryption parameter 1446 and the stop encryption parameter 1448 may target the IP header 2604 for encryption. One technical benefit is headers 2610 within a UP packet 822 are protected from potential attack. FIG. 27 illustrates an enhanced UP security policy 1220 m an illustrative embodiment. The partial UP integrity protection parameters 1424 may include a header integrity protection parameter 2762 indicating that integrity protection is required for a header (e.g., IP header 2604) of a UP packet 822. The partial UP encryption parameters 1426 may include a header encryption parameter 2766 indicating that encryption is required for a header (e.g., IP header 2604) of a UP packet 822. When the header integrity protection parameter 2762 and the header encryption parameter 2766 are included, the start / size or start / stop parameters may also be included to indicate the position of the header 2610 in the UP packet 822. Thus, the IP header 2604, for example, represents the portion of the UP packet 822 to be integrity protected, and the portion of the UP packet 822 to be encrypted as described above. FIG. 28 illustrates another revised “UpSecurity” datatype 2800 in an illustrative embodiment. The revised “UpSecurity” datatype 2800 may include the following additional parameters, attributes, or IEs: “startintegrityProt”, “sizeIntegrityProt”, “startEncn ption”, "sizeEncryption” as illustrated in FIG. 22. The revised “UpSecurity” data type 2800 may further include the following IEs: “upHeaderlntegr” and “upHeaderConfid” The “upHeaderlntegr” IE 2814 is a Boolean value indicating whether UP integrity protection is required for a header (e.g., IP header 2604) of a UP packet 822. The “upHeaderConfid” IE 2816 is a Boolean value indicating whether UP encryption is required for a header (e.g., IP header 2604) of a UP packet 822. SMF 214, as described above, determines the enhanced UP security policy 1220 for a PDU session 830. In an embodiment, SMF 214 may receive and / or process one or more of the enhanced UP security parameters 1422 from the external data network 108 (see optional step 1306 in FIG. 13), such as from AAA server 2514. SMF 214 may therefore determine the enhanced UP security policy 1220 based, at least partially, on the enhanced UP security parameters 1422 provided by the external data network 108. One technical benefit is the DN operator may be in a good position to decide whether partial UP protection of UP packets 822 (e.g., IP headers 2604) makes sense, and what part of the UP packet 822 should be protected (e.g., what header size is expected). In an embodiment, more flexibility may be enabled by letting the UE 106 indicate UP protection preferences within a PDU session 830 to the mobile network. This would enable scenarios where UP protection is valid for only a certain period of time, such as in cases where the UE 106 knows that the UP traffic 818 needing to be protected will start soon but will also end at a specific point. FIG. 29 is a message diagram illustrating enhanced UP security mechanisms in an illustrative embodiment. To request a PDU session, UE 106 sends a PDU session establishment request 611 to AMF 212 requesting establishment of a new PDU session. UE 106 may provide a UP protection preference indicator 2926 in the PDU session establishment request 611. AMF 212, in turn, may provide the UP protection preference indicator 2926 to SMF 214, such as in the NsmfPDLSession (j Request 612. SMF 214 may then determine the enhanced UP security policy 1220 based, at least partially, on the UP protection preference indicator 2926. In order to convey the enhanced UP security policy 1220 to a RAN node 800, a revision or extension may be made to the Security Indication IE defined in 3GPP TS 38.413. FIGS. 30-31 illustrate extensions to the Security Indication IE 3000 in illustrative embodiments. The Security Indication IE 3000 contains the UP integrity- protection indication and confidentiality protection indication, which indicates the requirements on UP integrity protection and ciphering for corresponding PDU sessions, respectively. Additionally, the Security Indication IE 3000 contains the maximum integrity protected data rate per UE for integrity protection for DRBs. The enhancements provide additional parameters for partial UP protection. FIGS. 30-31 illustrate a revised Security Indication IE 3000 in illustrative embodiments. As in 3GPP TS 38.413, the revised Security Indication IE 3000 includes the following attributes or IEs: “Integrity Protection Indication”, “Confidentiality Protection Indication”, “Maximum Integrity Protected Data Rate Uplink”, and “Maximum Integrity Protected Data Rate Downlink”. The “Integrity Protection Indication” IE 3002 indicates whether UP integrity protection is required, preferred, or not needed for a PDU Session. The “Confidentiality Protection Indication” IE 3004 indicates whether UP confidentiality protection is required, preferred, or not needed for a PDU Session. The “Maximum Integrity Protected Data Rate Uplink” IE 3006 indicates the maximum integrity protected data rate supported by the UE 106 for uplink. Hie “Maximum Integrity Protected Data Rate Downlink” IE 3008 indicates the maximum integrity protected data rate supported by the UE 106 for downlink. In FIG. 30, the revised Security Indication IE 3000 may include the following additional parameters, attributes, or IEs: “startlntegrityProt”, “sizeIntegrityProt”, "startEncryption", and “sizeEncryption” representing enhanced UP security parameters 1422. The “startlntegrityProt” IE 3010 is an integer value indicating the first byte of a UP packet to be integrity protected. The “sizelntegrityProt” IE 3012 is an integer value indicating the number of bytes to be integrity protected, starting with the first byte indicated by the “startlntegrityProt” IE 3010. The “startEncryption” IE 3014 is an integer value indicating the first byte of a UP packet to be encry pted. The “sizeEncryption” IE 3016 is an integer value indicating the number of bytes to be encry pted, starting with the first byte indicated by the “startEncryption” IE 3014. In FIG. 31, the revised Security7 Indication IE 3000 may include the following additional parameters, attributes, or IEs: “startlntegrityProt”, “stopIntegrityProt”, “startEncryption”, and “stopEncryption” representing enhanced UP security parameters 1422. The “startlntegrityProt” IE 3110 is an integer value indicating the first byte of a UP packet to be integrity protected. The "stopIntegrity Prot" IE 3112 is an integer value indicating the last byte of a UP packet to be integrity protected. The “startEncryption” IE 3114 is an integer value indicating the first byte of a UP packet to be encrypted. The “stopEncryption” IE 3116 is an integer value indicating the last byte of a UP packet 822 to be encrypted. The revised Security Indication IE 3000 may include additional or alternative IEs as desired, such as “fullPacketlntegrityProt” and “fullPacketEncryption” IEs as discussed above in FIG. 24. One technical benefit of the revisions disclosed in FIGS. 30-31 is the RAN node 800 is able to receive an enhanced UP security policy 1220. Thus, upon receiving a PDU session request 1202 as in FIG. 12B, for example, RAN node 800 is able to process tire enhanced UP security parameters 1422 included in the additional lEs, and activate partial UP protection accordingly. In order to convey the enhanced UP security policy 1220 to a UE 106, a revision or extension may be made to the SecurityConfig IE defined in 3GPP TS 3 8.3 31 (Release 18), which is incorporated by reference as if fully included herein. 3GPP TS 38.331 specifies the message structure and message definitions of an RRC message. The SecurityConfig IE in 3GPP TS 38.331 indicates the security algorithm and key to use for the signaling and DRBs configured with the list in the RadioBearerConfig IE, which is used to add, modify, and release signaling and / or data radio bearers. The enhancements provide additional parameters for partial UP protection. FIGS. 32-33 illustrate a revised RadioBearerConfig IE 3200 in illustrative embodiments. As in 3GPP TS 38.331, the revised RadioBearerConfig IE 3200 includes a security configuration IE 3202, which indicates the security algorithm and key to use for the signaling and data radio bearers configured with the list in RadioBearerConfig IE 3200. The security configuration IE 3202 includes the following fields or lEs: “securityAlgorithmConfig” and “keyToUse”. The “securityAlgorithmConfig” IE indicates the security algorithm for the signaling and data radio bearers. The “keyToUse" IE indicates if the bearers configured with the list in RadioBearerConfig IE 3200 are using the master key or the secondary key for deriving ciphering and / or integrity protection keys. In FIG. 32, the revised security configuration IE 3202 may include the following additional fields, parameters, attributes, or lEs: “startlntegrityProt”, “size Integrity Prof ’, “startEncryption”, and “sizeEncryption” representing enhanced UP security parameters 1422. The “startlntegrityProt” IE 3204 is an integer value indicating the first byte of a UP packet to be integrity protected. The “sizeintegrityProt” IE 3206 is an integer value indicating the number of bytes to be integrity protected, starting with the first byte indicated by the “startlntegrityProt” IE 3204. The “startEncryption” IE 3208 is an integer value indicating the first byte of a UP packet to be encrypted. The “sizeEncryption” IE 3210 is an integer value indicating the number of bytes to be encrypted, starting with the first byte indicated by the “startEncryption” IE 3208. In FIG. 33, the revised security configuration IE 3202 may include the following additional fields, parameters, attributes, or lEs: “startlntegrityProt”, “stopIntegrityProt”, “startEncryption”, and “stopEncry ption” representing enhanced UP security parameters 1422. The “startlntegrityProt” IE 3304 is an integer value indicating the first byte of a UP packet to be integrity protected. The “stopIntegrityProt” IE 3306 is an integer value indicating the last byte of a UP packet to be integrity protected. The “startEncryption” IE 3308 is an integer value indicating the first byte of a UP packet to be encrypted. The “stopEncry ption” IE 3310 is an integer value indicating the last byte of a UP packet 822 to be encrypted. The revised security configuration IE 3202 may include additional or alternative IEs or fields as desired, such as “fiillPacketlntegrityProt” and “fullPacketEncryption” IEs as discussed above in FIG. 24. One technical benefit of the revisions disclosed in FIGS. 32-33 is the UE 106 is able to receive an enhanced UP security policy 1220. Thus, upon receiving an RRC message 1203 as in FIG. 12B, for example, UE 106 is able to process the enhanced UP security parameters 1422 included in the additional IEs, and activate partial UP protection accordingly. Any of the various elements or modules shown in the figures or described herein may be implemented as hardware, software, firmware, or some combination of these. For example, an element may be implemented as dedicated hardware. Dedicated hardware elements may be referred to as “processors”, “controllers”, or some similar terminology. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, a network processor, application specific integrated circuit (ASIC) or other circuitry, field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), non-volatile storage, logic, or some other physical hardware component or module. Also, an element may be implemented as instructions executable by a processor or a computer to perform the functions of the element. Some examples of instructions are software, program code, and firmware. The instructions are operational when executed by the processor to direct the processor to perform the functions of the element. The instructions may be stored on storage devices that are readable by the processor. Some examples of the storage devices are digital or solid-state memories, magnetic storage media such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media. As used in this application, the term “circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry'); (b) combinations of hardware circuits and software, such as (as applicable): (i) a combination of analog and / or digital hardware circuit(s) with software / firmware; and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memon (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions); and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation. This definition of circuitry applies to all uses of this term m this application, including in any 5 claims. As a further example, as used in this application, the term circuitry-' also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in 10 server, a cellular network device, or other computing or network device. Although specific embodiments were described herein, the scope of the disclosure is not limited to those specific embodiments. The scope of the disclosure is defined by the following claims and any equivalents thereof.

Claims

1. An apparatus of a mobile network, the apparatus comprising:a session management function (214) comprising:a means (904) for determining a user plane security policy (1220) for a packet data unit session (830) of user equipment (106), wherein the user plane security policy includes user plane security parameters (1422) that specify at least one of an integrity protection portion (1524) of a user plane packet (822) to be integrity protected and an encryption portion (1526) of the user plane packet to be encrypted; anda means (904) for providing the user plane security policy to a radio access network node (800) that serves the user equipment, indicating the user plane security parameters.

2. The apparatus of claim 1, wherein the user plane security parameters of the user plane security policy comprise:a start integrity protection parameter (1432) indicating a first byte of the user plane packet to be integrity protected; andan integrity protection size parameter (1434) indicating a number of bytes of the user plane packet to be integrity protected starting with the first byte to be integrity protected.

3. The apparatus of any of claims 1 and 2, wherein the user plane security parameters of the user plane security policy comprise:a start encryption parameter (1436) indicating a first byte of the user plane packet to be encrypted; andan encryption size parameter (1438) indicating a number of bytes of the user plane packet to be encrypted starting with the first byte to be encrypted.

4. The apparatus of claim 3, wherein:the number of bytes in at least one of the integrity protection size parameter and the enctyption size parameter is a multiple of a block size for a cryptographic algorithm.

5. The apparatus of claim 1, wherein the user plane security parameters of the user plane security policy comprise:a start integrity protection parameter (1442) indicating a first byte of the user plane packet to be integrity protected; anda stop integrity protection parameter (1444) indicating a last byte of the user plane packet to be integrity protected.

6. The apparatus of any of claims 1 and 5, wherein the user plane security parameters of the user plane security policy comprise:a start encryption parameter (1446) indicating a first byte of the user plane packet to be encrypted; anda stop encryption parameter (1448) indicating a last byte of the user plane packet to be encrypted.

7. The apparatus of any of claims 1 to 6, wherein:a first predefined value for one of the user plane security parameters indicates that the entire user plane packet is to be integrity protected; anda second predefined value for one of the user plane security parameters indicates that the entire user plane packet is to be encrypted.

8. The apparatus of any of claims 1 to 6, wherein the user plane security parameters of the user plane security policy comprise:a full integrity protection parameter (1452) indicating that the entire user plane packet is to be integrity protected; anda full encryption parameter (1456) indicating that the entire user plane packet is to be encrypted.

9. The apparatus of any of claims 1 to 8, wherein:the packet data unit session is between tire user equipment and an external data network (108); andthe session management function further comprises:a means (904) for receiving one or more of the user plane security parameters of the user plane security policy from the external data network.

10. The apparatus of any of claims 1 to 9, wherein:the integrity protection portion and the encryption portion comprise one or more headers (2610) of the user plane packet.

11. The apparatus of any of claims 1 to 10, wherein the session management function further comprises:a means (904) for determining the user plane security policy based on user plane protection preferences (2926) received from the user equipment during establishment of the packet data unit session.

12. A method of user plane security in a mobile network, the method comprising:determining (1302), in a session management function of the mobile network, a user plane security policy for a packet data unit session of user equipment, wherein the user plane security policy includes user plane security parameters that specify at least one of an integrity protection portion of a user plane packet to be integrity protected and an encryption portion of the user plane packet to be encrypted; andproviding (1304) the user plane security policy from the session management function to a radio access network node that serves the user equipment, indicating the user plane security parameters.

13. The method of claim 12, wherein the user plane security parameters of the user plane security policy comprise:a start integrity protection parameter indicating a first byte of the user plane packet to be integrity protected; andan integrity protection size parameter indicating a number of bytes of the user plane packet to be integrity protected starting with the first byte to be integrity protected.

14. The method of any of claims 12 and 13, wherein the user plane security parameters of the user plane security policy comprise:a start encryption parameter indicating a first byte of the user plane packet to be enciypted; andan encryption size parameter indicating a number of bytes of the user plane packet to be encrypted starting with the first byte to be encrypted.

15. The method of claim 12, wherein the user plane security parameters of the user plane security policy comprise:a start integrity protection parameter indicating a first bvtc of the user plane packet to be integrity protected; anda stop integrity protection parameter indicating a last byte of the user plane packet to be integrity protected.

16. The method of any of claims 12 and 15, wherein the user plane security parameters of the user plane security policy comprise:a start encryption parameter indicating a first byte of the user plane packet to be encrypted; anda stop encryption parameter indicating a last byte of the user plane packet to be encrypted.

17. The method of any of claims 12 to 16, wherein:a first predefined value for one of the user plane security parameters indicates that the entire user plane packet is to be integrity protected; anda second predefined value for one of the user plane security parameters indicates that the entire user plane packet is to be encrypted.

18. The method of any of claims 12 to 17, wherein:the integrity protection portion and the encryption portion comprise one or more headers of the user plane packet.

19. The method of claim 12, further comprising:receiving (1602), at the radio access network node, the user plane security policy provided by the session management function;providing (1604) the user plane security policy from the radio access network node to the user equipment indicating tine user plane security policy; andactivating (1606), at the radio access network node, user plane confidentiality and user plane integrity protection per each data radio bearer of the packet data unit session according to the user plane security policy by applying integrity protection to the integrity protection portion of user plane packets and / or encryption or decryption to the encryption portion of the user plane packets based on the user plane security7 parameters.

20. The method of claim 19, further comprising:receiving (1702), at the user equipment, the user plane security policy provided by the radio access network node; andactivating (1704), at the user equipment, user plane confidentiality and user plane integrity protection per each data radio bearer of the packet data unit session according to the user plane security policy by applying integrity' protection to the integrity protection portion of user plane packets and / or encryption or decryption to the encryption portion of the user plane packets based on the user plane security parameters.

Images