Patent Description:
One of the main new features in <NUM>th Generation (<NUM>) Security is the separation of the activation between the Control and User Plane (UP) security in the Access Stratum (AS) as described in <NUM>rd Generation Partnership Project (3GPP) Technical Specification (TS) <NUM> v15. Activation in this context means the starting point of the ciphering and integrity protection on the air interface between the user equipment (UE) and the Radio Access Network (RAN) (Node), i.e. gNB or ng-eNB. Like in the previous generation system (namely, the Evolved Packet System, EPS), Control Plane (CP) security is activated by a run of the AS Security Mode Command (SMC) procedure which is a roundtrip of radio resource control (RRC) messages between the UE and the RAN node. The procedure allows the negotiation of the cryptographic algorithms, the establishment of the ciphering and integrity protection keys, and the activation of the secure mode of the protocol.

The activation of the UP security takes place during the protocol data unit (PDU) Session establishment procedure which is a Non-Access Stratum (NAS) procedure between the UE and the Session Management Function (SMF) in the core network (CN). The activation is based on the UP Security Policy, which is a PDU Session-specific parameter determined by the SMF and signaled to the RAN node during the procedure run. The UP Security Policy indicates whether integrity or/and ciphering are to be activated for the session being set-up. The RAN node will then take a decision and signal the decision to the UE via RRC signaling. The result is that, based on the so-called decision, all the Data Radio Bearers (DRBs) serving the PDU Session in question will have the same ciphering and integrity protection activation status, i.e. either all off or all on. See TS <NUM> v15.

The PDU Session-specific nature of the UP Security Policy advantageously provides flexibility for tailoring security on a session by session basis. This flexibility nonetheless complicates security considerations in some contexts, such as in the case of <NUM> Local Area Network (5GLAN) group communication.

Prior art patent documents: <CIT> discloses group based context and security for massive loT devices; <CIT> discloses a method and device for selecting a security algorithm of a group of devices.

It is an object of the invention to enable improved security related to group communication, e.g., 5GLAN group communication.

Some embodiments herein secure the user plane path of a session for a device, e.g., by applying confidentiality protection and/or integrity protection to the user plane path. Notably, some embodiments secure the user plane path of the session for the device, taking into account the device's participation in group communication, e.g., <NUM> Local Area Network (5GLAN) group communication. One or more embodiments for example secure the user plane path of the session for the device to an extent that is applicable for each device participating in the group communication. The user plane path of the session for the device may for instance be secured to the same extent, or to at least the same minimum extent, as that to which the user plane path of the session for each other device participating in the group communication is to be secured. Such effectively enforces a security policy that is commonly applicable to devices participating in group communication, e.g., a policy that the user plane path of the session for each device participating in the group communication is to be secured to the same extent, or to at least the same minimum extent. Securing the user plane path of the session for each device participating in the group communication to the same extent, or to at least the same minimum extent, advantageously safeguards the group communication as a whole against attack. Indeed, with the group communication traversing each of the user plane paths for respective devices in the group, the user plane path that is secured to the least extent dictates the extent to which the group communication is actually protected against attack. Some embodiments thereby advantageously ensure that the security applied by any one device in the group does not disproportionately jeopardize the security for the whole group.

More particularly, embodiments herein include a method performed by a network node in a wireless communication network, according to claim <NUM>. Additional embodiments are defined in the dependent claims.

Embodiments herein also include corresponding apparatus, computer programs, and carriers such as non-transitory computer-readable mediums. Embodiments for instance include a network node configured for use in a wireless communication network. The network node is configured (e.g., via communication circuitry and processing circuitry) to receive, at the network node, a request to establish a session for a device in a group. The network node may further be configured to determine a user plane security policy for the session, based on a user plane security policy for the group. The user plane security policy for the group may specify a policy for securing a user plane path of a session for any device in the group. In some embodiments, the network node is also configured to transmit, from the network node to an access node of the wireless communication network, control signaling indicating the determined user plane security policy.

<FIG> shows a wireless communication network <NUM> (e.g., a <NUM> network) according to some embodiments. As shown, devices <NUM>-<NUM> and <NUM>-<NUM> each establish a respective session <NUM>-<NUM>, <NUM>-<NUM> (e.g., a Protocol Data Unit, PDU, session) towards a particular data network (DN), identified by a particular Data Network Name (DNN) <NUM>. This particular DNN <NUM> is associated with a particular group <NUM>. The group <NUM> may for instance be a <NUM> Local Area Network (5GLAN) group. Belonging to the same group <NUM>, devices <NUM>-<NUM> and <NUM>-<NUM> are able to privately communicate with each other. <FIG> in this regard shows that the devices <NUM>-<NUM>, <NUM>-<NUM> may exchange group communication <NUM> amongst themselves privately. The group <NUM> in this sense may represent a restricted set of devices <NUM>-<NUM>, <NUM>-<NUM> configured to privately communicate amongst each other via the respective sessions <NUM>-<NUM>, <NUM>-<NUM> for the devices <NUM>-<NUM>, <NUM>-<NUM>. Where the group <NUM> is a 5GLAN group, for example, the group <NUM> may represent a restricted set of devices <NUM>-<NUM>, <NUM>-<NUM> configured to privately communicate amongst each other via a <NUM> LAN type service.

Communication, such as private communication, amongst devices <NUM>-<NUM> and <NUM>-<NUM> in the group <NUM> may be achieved in some embodiments by anchoring the user plane paths of the devices' sessions <NUM>-<NUM>, <NUM>-<NUM> in the same user plane node (e.g., implementing a User Plane Function, UPF) or in multiple interconnected user plane nodes. <FIG> for example shows that the user plane paths of the devices' sessions <NUM>-<NUM>, <NUM>-<NUM> are anchored in user plane node(s) <NUM>. Privacy of communication among members of the group is achieved by e.g. encryption of traffic among the group member devices, and the traffic does not necessarily have to be sent via UPFs.

The user plane paths of the devices' sessions <NUM>-<NUM>, <NUM>-<NUM> may each be secured. For example, each user plane path may be secured by applying integrity protection and/or confidentiality protection (i.e., encryption) to group communications <NUM> transported on that path. In some embodiments in this regard, individual user plane security policies <NUM>-<NUM>, <NUM>-<NUM> for the respective sessions <NUM>-<NUM>, <NUM>-<NUM> govern the extent to which the user plane paths of the respective sessions <NUM>-<NUM>, <NUM>-<NUM> are to be secured. That is, user plane security policy <NUM>-<NUM> for session <NUM>-<NUM> governs the extent to which the user plane path of the session <NUM>-<NUM> for device <NUM>-<NUM> is to be secured, whereas user plane security policy <NUM>-<NUM> for session <NUM>-<NUM> governs the extent to which the user plane path of the session <NUM>-<NUM> for device <NUM>-<NUM> is to be secured. Each user plane security policy <NUM>-<NUM>, <NUM>-<NUM> may for instance specify whether integrity protection on the user plane path is required or not needed (or preferred), and/or specify whether confidentiality protection (i.e., encryption) on the user plane path is required or not needed (or preferred).

A network node <NUM> (e.g., implementing a Session Management Function, SMF in a <NUM> core network) may determine the individual user plane security policies <NUM>-<NUM>, <NUM>-<NUM> for the respective sessions <NUM>-<NUM>, <NUM>-<NUM>, i.e., the policies <NUM>-<NUM>, <NUM>-<NUM> that are to respectively apply to and secure the user plane paths of the devices' sessions <NUM>-<NUM>, <NUM>-<NUM>. The network node <NUM> may for instance make this determination when the sessions <NUM>-<NUM>, <NUM>-<NUM> are being set up. The network node <NUM> in some embodiments then signals the user plane security policies <NUM>-<NUM>, <NUM>-<NUM> to the radio access network (RAN) (not shown), so that the RAN can put the policies <NUM>-<NUM>, <NUM>-<NUM> into effect for the respective sessions <NUM>-<NUM>, <NUM>-<NUM>.

Notably, some embodiments secure the user plane path of the session for a any given device, taking into account that device's participation in the group <NUM>. One or more embodiments for example secure the user plane path of the session <NUM>-<NUM> for device <NUM>-<NUM> to an extent that is applicable for every device participating in the group <NUM>. The user plane path of the session <NUM>-<NUM> for the device <NUM>-<NUM> may for instance be secured to the same extent, or to at least the same minimum extent, as that to which the user plane path of the session for every other device participating in the group <NUM> is to be secured. For example, the user plane path of the session <NUM>-<NUM> for the device <NUM>-<NUM> may be secured to the same extent, or to at least the same minimum extent, as that to which the user plane path of the session <NUM>-<NUM> for device <NUM>-<NUM> is secured.

Such effectively enforces a security policy <NUM> that is commonly applicable to devices <NUM>-<NUM>, <NUM>-<NUM> participating in the group <NUM>. This security policy <NUM> may be referred to for convenience as a group user plane security policy, i.e., a user plane security policy for the group <NUM>. The group user plane security policy <NUM> may for instance specify that the user plane path of the session <NUM>-<NUM>, <NUM>-<NUM> for each device <NUM>-<NUM>, <NUM>-<NUM> participating in the group <NUM> is to be secured to the same extent, or to at least the same minimum extent. Broadly, then, the user plane security policy <NUM> for the group <NUM> specifies a policy for securing a user plane path of a session for any device in the group <NUM>, e.g., such that the user plane path of the session for each device in the group <NUM> is to be secured based on the user plane security policy <NUM> for the group <NUM>.

Securing the user plane path of the session <NUM>-<NUM>, <NUM>-<NUM> for each device <NUM>-<NUM>, <NUM>-<NUM> participating in the group <NUM> to the same extent, or to at least the same minimum extent, advantageously safeguards the group communication <NUM> as a whole against attack. Indeed, with the group communication <NUM> traversing each of the user plane paths for respective devices <NUM>-<NUM>, <NUM>-<NUM> in the group <NUM>, the user plane path that is secured to the least extent dictates the extent to which the group communication <NUM> is actually protected against attack. Some embodiments thereby advantageously ensure that the security applied by any one device in the group <NUM> does not disproportionately jeopardize the security for the whole group.

The group user plane security policy <NUM> may do so for instance by specifying that the user plane security policy for the session of any device in the group <NUM> is to be the same as the user plane security policy for the session of any other device in the group. For example, the group user plane security policy <NUM> may indicate that the individual user plane security policies <NUM>-<NUM>, <NUM>-<NUM> are to be the same, e.g., by specifying the same policy for integrity protection and/or the same policy for confidentiality protection. That is, the individual user plane security policies <NUM>-<NUM>, <NUM>-<NUM> are to each specify the same choice for whether integrity protection is required or not needed (or preferred), and/or are to each specify the same choice for whether confidentiality protection is required or not needed (or preferred). According to such a group user plane security policy <NUM>, then, the network node <NUM> may determine the user plane security policy <NUM>-<NUM> for securing the user plane path of the session <NUM>-<NUM> for device <NUM>-<NUM> to be the same as the user plane security policy <NUM>-<NUM> for securing the user plane path of the session <NUM>-<NUM> for device <NUM>-<NUM>.

In other embodiments, the group user plane security policy <NUM> may specify that user plane security for a session of any device in the group <NUM> is to specify a minimum level of security. For example, the group user plane security policy <NUM> may indicate that the individual user plane security policies <NUM>-<NUM>, <NUM>-<NUM> are to each specify a minimum level of integrity protection and/or a minimum level confidentiality protection. In this case, different choices for whether integrity protection is required or not needed (or, in some embodiments, preferred) may represent different levels of integrity protection, where the choice of "required" provides a higher level of integrity protection than "not needed" (and, in some embodiments, "preferred" may provide a lower level of integrity protection than "required" but a higher level of integrity protection than "not needed"). Similarly, different choices for whether confidentiality protection is required or not needed (or, in some embodiments, preferred) may represent different levels of confidentiality protection, where the choice of "required" provides a higher level of confidentiality protection than "not needed" (and, in some embodiments, "preferred" may provide a lower level of confidentiality protection than "required" but a higher level of confidentiality protection than "not needed"). According to such a group user plane security policy <NUM>, then, the network node <NUM> may determine the user plane security policy <NUM>-<NUM> for the session <NUM>-<NUM> is to specify a level of integrity protection and/or a level of confidentiality protection that is at least as high as the level of integrity protection and/or the level of confidentiality protection specified by the user plane security policy <NUM>-<NUM> for the session <NUM>-<NUM>. For example, if the user plane security policy <NUM>-<NUM> for securing the user plane path of the session <NUM>-<NUM> for device <NUM>-<NUM> specifies "required" for integrity protection and "not needed" for confidentiality protection, the network node <NUM> may determine the user plane security policy <NUM>-<NUM> for securing the user plane path of the session <NUM>-<NUM> for device <NUM>-<NUM> is to specify "required" for integrity protection" and either "not needed" or "required" (or, in some embodiments, "preferred") for confidentiality protection.

Generally, then, no matter the particular implementation of the group user plane security policy <NUM>, the network node <NUM> according to some embodiments determines the user plane security policy <NUM>-<NUM> for securing the session <NUM>-<NUM> for device <NUM>-<NUM>, based on the user plane security policy <NUM> for the group <NUM>. And, similarly, the network node <NUM> determines the user plane security policy <NUM>-<NUM> for the session <NUM>-<NUM> for device <NUM>-<NUM>, also based on the user plane security policy <NUM> for the group <NUM>.

Note that, in some embodiments, the user plane security policy <NUM> for the group <NUM> is specified and/or stored in the same way as a user plane security policy <NUM>-<NUM>, <NUM>-<NUM> for a session <NUM>-<NUM>, <NUM>-<NUM> or an individual device <NUM>-<NUM>, <NUM>-<NUM>, except that it applies commonly for the group <NUM>. In one or more embodiments, for instance, the user plane security policy <NUM> for the group <NUM> specifies whether integrity protection on the user plane path of the session for every device in the group <NUM> is required or not needed (or, in some embodiments, preferred), and/or specifies whether confidentiality protection (i.e., encryption) on the user plane path of the session for every device in the group <NUM> is required or not needed (or, in some embodiments, preferred). In this case, the network node <NUM> determines the user plane security policy <NUM>-<NUM> or <NUM>-<NUM> for a device in the group to be the same as the user plane security policy <NUM> for the group <NUM>. In other embodiments, the user plane security policy <NUM> for the group <NUM> indicates whether a minimum level of integrity protection to be specified by the user plane security policy for the session of any device in the group <NUM> is "required" or "not needed" (or, in some embodiments, "preferred"), and/or specifies whether a minimum level of confidentiality protection (i.e., encryption) to be specified by the user plane security policy for the session of any device in the group <NUM> is "required" or "not needed" (or, in some embodiments, "preferred"). In this case, the network node <NUM> may check the user plane security policy <NUM>-<NUM> or <NUM>-<NUM> for a device in the group <NUM> against the user plane security policy <NUM> for the group <NUM>, and accept or reject the setup of the session for the device depending on whether the user plane security policy <NUM>-<NUM> or <NUM>-<NUM> meets the minimum level of security specified by the group user plane security policy <NUM>. In these and other embodiments, then, the group user plane security policy <NUM> may be obtained from, or stored in, a data structure such as a database.

In other embodiments, though, the user plane security policy <NUM> for the group <NUM> simply constitutes one or more rules at the network node <NUM>, e.g., specifying how the user plane security policies <NUM>-<NUM>, <NUM>-<NUM> for the devices <NUM>-<NUM>, <NUM>-<NUM> in the group <NUM> are to relate to one another and/or to a minimum security level requirement. The user plane security policy <NUM> for the group <NUM> may for example just constitute a rule at the network node <NUM> indicating that the user plane security policies <NUM>-<NUM>, <NUM>-<NUM> for the respective sessions <NUM>-<NUM>, <NUM>-<NUM> of devices <NUM>-<NUM>, <NUM>-<NUM> in the group <NUM> are to be the same as one another.

Regardless, the network node <NUM> in some embodiments may receive or otherwise obtain the user plane security policy <NUM> for the group <NUM>. The network node <NUM> may for instance obtain the user plane security policy <NUM> for the group <NUM> from another node (not shown), such as a node implementing an application function (AF), a node in a data network (DN), a node in an operations and support system (OSS), a node implementing a unified data management (UDM) function, or a node implementing a policy control function (PCF). In other embodiments, the network node <NUM> may itself generate the user plane security policy <NUM> for the group <NUM>, e.g., dynamically on-the-fly. No matter how the network node <NUM> obtains the policy <NUM> for the group <NUM>, the network node <NUM> may do so during a procedure for establishing a session for a device in the group. Indeed, it is during this procedure that the network node <NUM> may determine the user plane security policy for securing the user plane path of the session to be established.

In view of the above modifications and variations, <FIG> depicts a method performed by a network node <NUM> (e.g., implementing an SMF) in a wireless communication network <NUM> (e.g., a <NUM> network). The method in some embodiments includes receiving, at the network node <NUM>, a request to establish a session <NUM>-<NUM> for a device <NUM>-<NUM> in a group <NUM> (e.g., a 5GLAN group) (Block <NUM>). The request may for example indicate a data network name (DNN) associated with the group <NUM>. Regardless, the method in some embodiments may include determining a user plane security policy <NUM>-<NUM> for the session <NUM>-<NUM> (i.e., the user plane security policy <NUM>-<NUM> for securing a user plane path of the session <NUM>-<NUM>), based on a user plane security policy <NUM> for the group <NUM> (i.e., a group user plane security policy <NUM>) (Block <NUM>). The user plane security policy <NUM> for the group <NUM> may specify a policy for securing a user plane path of a session for any device in the group <NUM>. In other words, the user plane security policy <NUM> for the group <NUM> may specify a policy for securing user plane paths of any respective sessions <NUM>-<NUM>, <NUM>-<NUM> for devices <NUM>-<NUM>, <NUM>-<NUM> in the group <NUM>. In some embodiments, the method further includes transmitting, from the network node <NUM> to an access node of the wireless communication network <NUM>, control signaling indicating the determined user plane security policy <NUM>-<NUM> (Block <NUM>).

<FIG> depicts a method in accordance with other particular embodiments. The method includes transmitting, to a network node <NUM> in a wireless communication network <NUM>, a user plane security policy <NUM> for a group <NUM> (i.e., a group user plane security policy <NUM>) (Block <NUM>). The user plane security policy <NUM> for the group <NUM> may specify a policy for securing a user plane path of a session for any device in the group <NUM>. In other words, the user plane security policy <NUM> for the group <NUM> may specify a policy for securing user plane paths of any respective sessions <NUM>-<NUM>, <NUM>-<NUM> for devices <NUM>-<NUM>, <NUM>-<NUM> in the group <NUM>. Regardless, the method may also include obtaining the group user plane security policy <NUM> (Block <NUM>).

In some embodiments, according to the user plane security policy <NUM> for the group <NUM>, a user plane security policy for a session of any device in the group <NUM> is to be the same as a user plane security policy for a session of any other device in the group <NUM>. In other embodiments, according to the user plane security policy <NUM> for the group <NUM>, a user plane security policy for a session of any device in the group <NUM> is to specify a minimum level of security.

In some embodiments, the user plane security policy <NUM> for the group <NUM> indicates: whether confidentiality protection is required or not needed for securing a user plane path of a session for any device in the group <NUM>; and/or whether integrity protection is required or not needed for securing a user plane path of a session for any device in the group <NUM>. In other embodiments, the user plane security policy <NUM> for the group <NUM> indicates: whether confidentiality protection is required, preferred, or not needed for securing a user plane path of a session for any device in the group <NUM>; and/or whether integrity protection is required, preferred, or not needed for securing a user plane path of a session for any device in the group <NUM>.

In some embodiments, the group <NUM> is a 5GLAN group. Alternatively or additionally, the group <NUM> is a restricted set of devices <NUM>-<NUM>, <NUM>-<NUM> configured to privately communicate amongst each other via the respective sessions for the devices <NUM>-<NUM>, <NUM>-<NUM>. Alternatively or additionally, the group <NUM> is a restricted set of devices configured to privately communicate amongst each other via a <NUM> local area network (LAN) type service.

Although referred to as a group user plane security policy <NUM> in some embodiments, the policy <NUM> may also be referred to as a local area network (LAN) user plane security policy or simply a network user plane security policy.

Note that the apparatuses described above may perform the methods herein and any other processing by implementing any functional means, modules, units, or circuitry. In one embodiment, for example, the apparatuses comprise respective circuits or circuitry configured to perform the steps shown in the method figures. The circuits or circuitry in this regard may comprise circuits dedicated to performing certain functional processing and/or one or more microprocessors in conjunction with memory. For instance, the circuitry may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory may include program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein, in several embodiments. In embodiments that employ memory, the memory stores program code that, when executed by the one or more processors, carries out the techniques described herein.

<FIG> for example illustrates a network node <NUM> (e.g., network node <NUM>) as implemented in accordance with one or more embodiments. As shown, the network node <NUM> includes processing circuitry <NUM> and communication circuitry <NUM>. The communication circuitry <NUM> (e.g., radio circuitry) is configured to transmit and/or receive information to and/or from one or more other nodes, e.g., via any communication technology. The processing circuitry <NUM> is configured to perform processing described above, e.g., in <FIG>, such as by executing instructions stored in memory <NUM>. The processing circuitry <NUM> in this regard may implement certain functional means, units, or modules.

<FIG> illustrates a node <NUM> as implemented in accordance with one or more embodiments. As shown, the node 500includes processing circuitry <NUM> and communication circuitry <NUM>. The communication circuitry <NUM> is configured to transmit and/or receive information to and/or from one or more other nodes, e.g., via any communication technology. The processing circuitry <NUM> is configured to perform processing described above, e.g., in <FIG>, such as by executing instructions stored in memory <NUM>. The processing circuitry <NUM> in this regard may implement certain functional means, units, or modules.

A computer program comprises instructions which, when executed on at least one processor of an apparatus, cause the apparatus to carry out any of the respective processing described above. A computer program in this regard may comprise one or more code modules corresponding to the means or units described above.

Additional embodiments will now be described. At least some of these embodiments may be described as applicable in certain contexts and/or wireless network types for illustrative purposes, but the embodiments are similarly applicable in other contexts and/or wireless network types not explicitly described. In some embodiments below, for example, a <NUM> wireless communication network exemplifies wireless communication network <NUM>, a 5GLAN exemplifies a group <NUM>, and a wireless device or user equipment exemplifies a device in a group.

The <NUM>th Generation (<NUM>) System will support verticals such as factories and enterprises deploying their own <NUM> Systems for connectivity either independently or via an operator e.g. offering the service in a restricted network. For example, in the context of an enterprise environment, equipment like smartphones and laptops may communicate with each other within a <NUM> local area network (5GLAN) Group. Key issues to be addressed in this regard include group management aspects, as well as how the connections are setup in order for the members of a group to communicate with each other. See, e.g., the <NUM>rd Generation Partnership Project (3GPP) Technical Report (TR) <NUM> v16.

In one solution, each user equipment (UE) member of a group is identified by the Generic Public Subscription Identifier (GPSI) which is a public identifier to be used with entities external to the <NUM> Core (5GC) (see 3GPP TS <NUM> v15. For example, during the secondary authentication procedure, specific GPSI, whenever available, is sent from the 5GC, and more precisely the Session Management Function (SMF), to the Data Network (DN) in order to identify a specific UE (see TS <NUM> v15.

Each 5GLAN group is associated with a specific Data Network Name (DNN) (See TS <NUM> v15. The DNN is signaled during the Protocol Data Unit (PDU) Session establishment procedure from a UE to the Core Network (CN) in order to identify with which DN the UE wants to establish a User Plane (UP) connection. See TS <NUM> v15. In the 5GLAN solution, all the PDU Sessions towards a particular DNN, and thus related to a particular group, are managed by the same SMF. From a UE perspective, in order to communicate with a particular 5GLAN Group, the UE must establish a PDU Session indicating the DNN associated with that particular group. The CN will then make sure that the same SMF handling that group is the one selected for managing this member session.

However, it becomes problematic if for a given group it is allowed to use different UP Security Policies with the UE members during group communication sessions. As a consequence, the security properties of the group communication are determined by the security properties of the weakest communication path. In other words, if a communication path between a UE_1, involved in the group session, and a RAN node N_1 is unencrypted while all the other communication paths between all other UEs and the RAN nodes are encrypted, the effect is that an attacker listening to the radio communication between the UE_1 and N_1 will be able to capture all the group communication data unencrypted although the other UEs encrypt the data.

Certain aspects of the present disclosure and their embodiments may provide solutions to these or other challenges. Some embodiments ensure that UEs participating in a group (e.g., in a Vertical LAN setup) will be configured in a such a way that all of them will have the same security policy or the same security properties for the communication links between UEs that belong to the same group (and a DNN). According to some embodiments, then, each 5GLAN group includes among other already existing attributes, a 5GLAN Group User Plane Security Policy (GUPSP). In some embodiments, the GUPSP is dynamically created and managed by an AF or external entity in DN or operator OSS entity, etc. upon the creation of the 5GLAN group. A specific GUPSP setting can be interpreted as the same for all UE PDU sessions or as the minimum security policy for each UE PDU session. Upon change of the GUPSP by the entities stated above (AF, OSS entity, etc) the active PDU sessions could remain as is or invalidated depending on operator policies. The SMF could perform these actions upon the PDU establishment and enforcement of the same or minimum policy upon consulting the GUPSP stored in the same node as the 5GLAN group description.

Certain embodiments may provide one or more of the following technical advantage(s). Some embodiments may ensure that security policies for devices in a group (e.g., 5GLAN group) protect user plane communications to the same extent (or to the same minimum extent in some embodiments), so that the security policy for one device in the group does not jeopardize security for the whole group.

In view of the embodiments above, the present disclosure generally includes the following embodiments, e.g., which may address one or more of the issues disclosed herein. Some embodiments include a method performed by a network node (e.g., implementing an SMF) in a wireless communication network (e.g., a <NUM> network). The method in some embodiments includes receiving, at the network node, a request to establish a session for a device in a group (e.g., a 5GLAN group). The method in some embodiments may include determining a user plane security policy for securing a user plane path of the session, based on a group user plane security policy specifying a policy for securing user plane paths of any respective sessions for devices in the group. In some embodiments, the method further includes transmitting, from the network node to an access node of the wireless communication network, control signaling indicating the determined user plane security policy.

More particularly, the 5GLAN services are intended to allow UEs belonging to the same 5GLAN group to communicate with each other. In some embodiments, a <NUM> LAN-type service is a service over the <NUM> system offering private communication using Internet Protocol (IP) and/or non-IP type communications. Here, private communication refers to communication between two or more UEs belonging to a restricted set of UEs. In this context, <NUM> LAN-type services with <NUM> capabilities (e.g. performance, long distance access, mobility, security) allow a restricted set of UEs to communicate amongst each other.

In some embodiments, the 5GS offers the <NUM> LAN-type service by establishing a user plane composed of one UPF or multiple interconnected UPFs. In some embodiments, the user plane of a <NUM> LAN-type service has two parts, the Access UP and the Backbone UP. The Access UP contains the UP paths of PDU Sessions. The Backbone UP contains UPFs and Nx connections in between, or Backbone UP bridges the UP paths in the Access UP and the physical LAN (if it exists) in the DN. The Nx connections in the Backbone UP are managed by the 5GC. Traffic routing over Nx in the Backbone UP is configured at the <NUM> LAN-type service level (i.e. per hop).

<FIG> shows the user plane architecture of 5GLAN communication framework according to some embodiments.

In some embodiments, private communication (of <NUM> LAN-type service) is achieved by shared anchor UPF or by interconnecting two anchor UPFs via an Nx interface. The combination of two anchor UPFs and the Nx interface in between is called an Nx connection.

For example, UE A establishes a PDU session targeting 5GLAN group A, and UE B establishes another PDU session targeting the same group. The user plane of the private communication between UE A and UE B are established by connecting the anchor UPF of UE A's PDU session and that of UE B's PDU session, as shown in <FIG>, when the two anchor UPFs are not the same UPF.

In some embodiments, UPF can support more than one <NUM> LAN-type service. To enable 5GLAN communication and isolation for respective <NUM> LAN-type services, i.e., traffic routing between UE PDU Sessions accessing to the same <NUM> LAN-type service, the UPF shall associate the traffic from the path of PDU Session to packet handling rules of the corresponding <NUM> LAN-type service e.g., based on VLAN Tag, UE address, session tunnel information, the packet handling rules are used to route the traffic to the correct UP path based on target address within the Backbone UP of the <NUM> LAN-type service.

In some embodiments, when the SMF identifies that the UE PDU Session is accessing to the <NUM> LAN-type service, in order to bind the UE PDU Session to the <NUM> LAN-type service, the SMF shall configure packet handling rules for the <NUM> LAN-type service and the UE PDU Session in the UPF to enable traffic differentiation for proper handling (e.g. marking, steering). <NUM> LAN-type service can span over wide area mobile network. The <NUM> network shall coordinate UE PDU sessions that access the same <NUM> LAN-type service in the cases illustrated in <FIG>. In these cases, the packet handling rules for the <NUM> LAN-type service and related PDU Sessions, if required, the Nx connection are used to connect two or more PDU Sessions accessing to the same <NUM> LAN-type service.

Case <NUM>: Private data communication within one UPF, the only SMF configures the only UPF the packet handling rules for the <NUM> LAN-type service and PDU Sessions.

Case <NUM>: Private data communication across UPFs managed by the same SMF, the only SMF configures UPF1 the packet handling rules for the <NUM> LAN-type service and the PDU Sessions anchored at UPF1, while configures UPF2 the packet handling rules for the <NUM> LAN-type service and the PDU Sessions anchored at UPF2.

Case <NUM>: Private data communication across UPFs managed by different SMFs, the SMF1 configures UPF1 the packet handling rules for the <NUM> LAN-type service and the PDU Sessions anchored at UPF1, while the SMF2 configures UPF2 the packet handling rules for the <NUM> LAN-type service and the PDU Sessions anchored at UPF2.

Case <NUM>: Private data communication in case of relocating UPFs due to UE mobility, the SMF unbinds the handover PDU Session to the 5GLAN-type service in the UPF2 and configures UPF1 the packet handling rules for the <NUM> LAN-type service and the handover PDU Session.

In some embodiments, a Private DNN uniquely identifies a 5GLAN group and all the member UEs of the same group need to establish a PDU Session towards the same Private DNN for 5GLAN group communication. Reserved special labels in the DNN syntax can easily indicate whether it's a Private DNN. Private DNNs might be preconfigured in the network and the group member UEs. They may be also dynamically created on demand by the operator or the group owners/administrators, as part of the 5GLAN group creation. When a new Private DNN is created on demand, the information may be propagated into the concerned network entities (e.g. AMF, SMF, UDR, etc.) in the core network and group member UEs may receive the Private DNN information, together with the related configurations such as the Service Area configuration, via NAS procedures (e.g. Registration or UE Configuration Update).

In some embodiments, a 5GLAN group member UE establishes a dedicated PDU Session towards the target Private DNN before it can communicate with the group. The legacy PDU Session management procedures can be reused for group communication. According to the Private DNN, the network selects the appropriate network functions (e.g. SMFs and UPFs) for the UEs of the same group. For example, all the UEs of the same group and in the same local area may be assigned the same SMF and UPF, as shown in <FIG>.

In the figure there are two 5GLAN groups: 5GLAN Group <NUM> which consists of UE1 and U2, and 5GLAN Group <NUM> which consists of UE2 AND UE3. UE2 is in both Group <NUM> and Group <NUM>. Each UE establishes the PDU Session (dotted line) towards the Private DNN corresponding to its group. The real group traffic <NUM> and <NUM> goes between UPFs selected for the group, under the control of the SMF or App Server, without going to the DN.

One solution in 3GPP Technical Report (TR) <NUM> v16. <NUM> assumes that a UE can belong to multiple 5GLAN groups, each associated to a unique DNN. This solution does not depend of the specific details of the <NUM> LAN groups such as their identifiers.

Another assumption is that the 5GLAN group is assumed to be created and configured by the operator or an Application Function via exposure, Key Issue <NUM> as described in TR <NUM> v16. Some embodiments herein can be adapted accordingly and do not depend on how groups are created or managed should that be either by an external entity to 3GPP network or by the operator.

Some embodiments herein are based on a Group User Plane Security Policy (GUPSP) intended to define the User Plane Security Policy to be applied for the PDU Sessions pertaining to a given 5GLAN group. Observe that some embodiments focus on the Group User Plane Security Policy, not the User Plane Security Policy defined in TS <NUM> v15. Some embodiments include mechanisms for how to determine the GUPSP, how to maintain and signal the GUPSP between the different network entities, and how to use the GUPSP to derive the corresponding individual User Plane Security Policy, in the sense of <NUM> v15. <NUM>, during the setup of the PDU Sessions by the member UEs.

For the purpose of the realization of some embodiments, it is assumed that a 3GPP entity (e.g. UDM) includes the following table for each 5GLAN group.

This group of embodiments relates to the definition of the GUPSP, that is how the GUPSP information is encoded; and the GUPSP semantics, i.e. how the GUPSP information is interpreted since both aspects can in fact be independent. For the latter aspect, the GUPSP can be interpreted to indicate that the User Plane Security Policy is fixed. More precisely the effect of such a fixed GUPSP is that all the PDU Sessions pertaining to group are allocated the same fixed User Plane Security Policy based on the GUPSP for the group in question.

However, as defined now in TS <NUM> v15. <NUM>, The User Plane Security Policy can be overridden by the target RAN node. In one embodiment, this is prevented so that the activation status of the integrity and confidentiality protection for all the PDU Sessions is the same for all the member UEs. This could be realized by defining the GUPSP similarly to the how the User Plane Security Policy is defined except that the "Preferred" value as described below is not allowed:
In some embodiments, then, each 5GLAN group specification should include (among other specified information in the relevant standards) a group User Plane Security Policy with the following options.

The same setting in the group User Plane Security Policy applies to all UE's part of the same 5GLAN group. The effect of this is that the security activation status of all the group related PDU Sessions that are established is the same. These options create the following set of possible group security policies which are denoted by SP={NONE, integrity protection(IP) only, encryption (ENC) only, IP and ENC}.

In one example, a group UP security policy having encryption as "required" would mean that all the PDU sessions should be encrypted i.e. a new PDU session establishment request by a UE in the group would be accepted only if the radio network can enable encryption for this PDU session. Otherwise the PDU session will be rejected, i.e. the UE will not be part of the group communication. Similarly, a group UP security policy having encryption as "not required" would mean that all the PDU sessions are unencrypted, i.e. a new PDU session establishment request by a UE in the group would be accepted.

In another embodiment the GUPSP is interpreted in a way that the User Plane Security Policy is assigned in a way to guarantee a minimal level of security. This of course requires that there is a predefined ordering over the set of possible values of the User Plane Security Policy. For example, this order can be defined in the following way. First, assume the following order over the policy values:.

The GUPSP for a given 5GLAN group could then be defined using all the values for both encryption and integrity protection. However, now when the SMF allocates the User Plane Security Policy for a PDU Session pertaining to the group, it shall not allocate a value less than the threshold indicated in the GUPSP. If the GUPSP indicates "Preferred" for integrity protection, then the SMF cannot set the integrity protection in the User Plane Security policy to "Not Needed". On the other hand, it is allowed to set it to "Preferred" or "Required".

In one example, then, a group UP security policy having encryption as "preferred" would mean that a new PDU session establishment request by a UE in the group would be accepted but the integrity protection would be enabled if the radio network can do it. If the radio network cannot do it integrity protection would be disabled.

The first group of embodiments relates to the configuration of the GUPSP. In one embodiment, this can be configured alongside the other 5GLAN group information by the group management entity, i.e. either AF or external entity in DN or operator OSS entity, etc. upon the creation of the 5GLAN group.

In one embodiment, the GUPSP is stored in one of the <NUM> Core functions, e.g. SMF or PCF and signaled to the SMF during the PDU Session establishment procedure. In another embodiment it is stored outside the <NUM> Core. For example, it can be stored in the DN and signaled to the SMF during PDU Session establishment procedure.

In yet another embodiment, the GUPSP is determined by the SMF on the fly during the establishment of the first PDU Session pertaining to a certain group.

The first embodiment in this group proposes that when UEs join a specific 5GLAN group the security properties of the PDU sessions are pre-configured to one specific value out of the set SP.

Another embodiment proposes that when the security policy is changed for a specific 5GLAN group, the network notifies the UEs to change their behavior only for an upgrade of the security policy e.g. a) from NONE->IP only or NONE->ENC only or NONE->IP & ENC, b) IP only -> ENC only or IP only -> IP and ENC, D) ENC only -> IP AND ENC. All other changes do not create any signaling. This could be done in order to reduce disruptions in case of time sensitive communications. As a result, as long as the security of the PDU sessions operate at the same or better level, no change is attempted in order to avoid PDU Session re-establishment.

Another embodiment proposes that when the policy is changed for a specific 5GLAN, the network notifies the UEs to change their behavior immediately either the policy is an upgrade or a downgrade. This could be done in order to preserve energy for constrained devices and for the parts of the UP information exchange which don't require stronger protection than necessary.

It may be the case that not all the UEs may be capable of supporting all the possible security policies and as a result UEs may reject the group security policy. In such case another embodiment is to recommend to the operator or the AF a split of the original group of UEs in N (e.g. up to <NUM> since the possible security policies can be <NUM> with these examples) different 5GLAN groups with respect to which security policies they could support, and recommend that the operator modifies the original single 5GLAN group with one GUPSP into N 5GLAN groups with respective GUPSP and reviews their deployment setup. In this way the operator may be become aware of the UE limitations and decide to either upgrade the UE capabilities or accept the group splitting.

Consider security activation for a UE belonging to a 5GLAN group. <FIG> shows the security activation for one UE based on the GUPSP according to some embodiments. The overall flow is based on the PDU Session establishment procedure described in detail in TS <NUM> v15. At one point in the establishment procedure, the SMF determines the UP Security Policy for the session being setup. Some embodiments introduce the concept of GUPSP which is used to determine the session security policy. One example is that this GUPSP information is retrieved from the UDM as illustrated in <FIG> (step <NUM>). Another example could be that the GUPSP is retrieved from an entity in the DN with which this session is established. As illustrated (step <NUM>), a GPSI-to-SUPI translation is made by the UDM but may in another embodiment be made by the SMF itself.

<FIG> show the first steps for UE1 as in <FIG>, in addition to the re-configuration of the 5GLAN procedure and some alternative actions based on the different said embodiments. Again, the illustrated GPSI-to-SUPI translation (step <NUM>) is in one embodiment made by the UDM and in another embodiment made by the SMF.

Although the subject matter described herein may be implemented in any appropriate type of system using any suitable components, the embodiments disclosed herein are described in relation to a wireless network, such as the example wireless network illustrated in <FIG>. For simplicity, the wireless network of <FIG> only depicts network <NUM>, network nodes <NUM> and 1260b, and WDs <NUM>, 1210b, and 1210c. In practice, a wireless network may further include any additional elements suitable to support communication between wireless devices or between a wireless device and another communication device, such as a landline telephone, a service provider, or any other network node or end device. Of the illustrated components, network node <NUM> and wireless device (WD) <NUM> are depicted with additional detail. The wireless network may provide communication and other types of services to one or more wireless devices to facilitate the wireless devices' access to and/or use of the services provided by, or via, the wireless network.

Thus, particular embodiments of the wireless network may implement communication standards, such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), Narrowband Internet of Things (NB-loT), and/or other suitable <NUM>, <NUM>, <NUM>, or <NUM> standards; wireless local area network (WLAN) standards, such as the IEEE <NUM> standards; and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave and/or ZigBee standards.

As used herein, wireless device (WD) refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other wireless devices. Unless otherwise noted, the term WD may be used interchangeably herein with user equipment (UE). Communicating wirelessly may involve transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information through air. In some embodiments, a WD may be configured to transmit and/or receive information without direct human interaction. For instance, a WD may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the network. Examples of a WD include, but are not limited to, a smart phone, a mobile phone, a cell phone, a voice over IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless cameras, a gaming console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-embedded equipment (LEE), a laptop-mounted equipment (LME), a smart device, a wireless customer-premise equipment (CPE). a vehicle-mounted wireless terminal device, etc.. A WD may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-everything (V2X) and may in this case be referred to as a D2D communication device. As yet another specific example, in an Internet of Things (IoT) scenario, a WD may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another WD and/or a network node. The WD may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the WD may be a UE implementing the 3GPP narrow band internet of things (NB-IoT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances (e.g. refrigerators, televisions, etc.) personal wearables (e.g., watches, fitness trackers, etc.). In other scenarios, a WD may represent a vehicle or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation. A WD as described above may represent the endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. Furthermore, a WD as described above may be mobile, in which case it may also be referred to as a mobile device or a mobile terminal.

WD <NUM> may include multiple sets of one or more of the illustrated components for different wireless technologies supported by WD <NUM>, such as, for example, GSM, WCDMA, LTE, NR, WiFi, WiMAX, NB-loT, or Bluetooth wireless technologies, just to mention a few.

UE <NUM> may be any UE identified by the <NUM>rd Generation Partnership Project (3GPP), including a NB-loT UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE.

Network connection interface <NUM> may be configured to provide a communication interface to network 1343a. Network 1343a may encompass wired and/or wireless networks such as a local-area network (LAN), a wide-area network (WAN), a computer network, a wireless network, a telecommunications network, another like network or any combination thereof. For example, network 1343a may comprise a Wi-Fi network.

In <FIG>, processing circuitry <NUM> may be configured to communicate with network 1343b using communication subsystem <NUM>. Network 1343a and network 1343b may be the same network or networks or different network or networks. Communication subsystem <NUM> may be configured to include one or more transceivers used to communicate with network 1343b.

Network 1343b may encompass wired and/or wireless networks such as a local-area network (LAN), a wide-area network (WAN), a computer network, a wireless network, a telecommunications network, another like network or any combination thereof. For example, network 1343b may be a cellular network, a Wi-Fi network, and/or a near-field network.

Other objectives, features and advantages of the enclosed embodiments will be apparent from the description.

Some of the embodiments contemplated herein are described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein. The disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

Claim 1:
A method performed by a network node (<NUM>, <NUM>) which implements a Session Management Function in a <NUM> core network of a wireless communication network (<NUM>), the method comprising:
receiving (<NUM>), at the network node (<NUM>, <NUM>), a request to establish a session (<NUM>-<NUM>) for a user equipment, UE, in a <NUM> Local Area network, 5GLAN, group (<NUM>);
determining (<NUM>) a user plane security policy (<NUM>-<NUM>) for the session (<NUM>-<NUM>) based on a user plane security policy (<NUM>) for the 5GLAN group (<NUM>), wherein the user plane security policy (<NUM>) for the 5GLAN group (<NUM>) specifies a policy for securing a user plane path of a session for any UE in the 5GLAN group (<NUM>), and wherein a user plane security policy for a session of any UE in the group (<NUM>) is to be the same as a user plane security policy for a session of any other UE in the 5GLAN group (<NUM>); and
transmitting (<NUM>), from the network node (<NUM>, <NUM>) to an access node of the wireless communication network (<NUM>), control signaling indicating the determined user plane security policy (<NUM>-<NUM>).