Devices behind a user equipment (UE)

Abstract

A policy control function, PCF, node (16e5) is provided. The PCF node (16e5) is configured to: receive a request message associated with a third generation partnership projection, 3GPP, network, where the request message comprising at least one identifier associated with at least one non-3GPP device (24) that is in communication with a 3GPP UE (22); reject a request associated with the request message for a cause associated with at least one of the at least one identifier: being absent from a network; or causing a number of identifiers associated with non-3GPP devices (24) to exceed a threshold; and indicate, to a session management function, SMF, node (16e4), the cause.

Description

[0001] DEVICES BEHIND A USER EQUIPMENT (UE)

[0002] FIELD

[0003] The present disclosure relates to wireless communications, and in particular, to cross link interference mitigation using resource muting.

[0004] BACKGROUND

[0005] The Third Generation Partnership Project (3 GPP) has developed and is developing standards for Fourth Generation (4G) (also referred to as Long Term Evolution (LTE)) and Fifth Generation (5G) (also referred to as New Radio (NR)) wireless communication systems. Such systems provide, among other features, broadband communication between network nodes, such as base stations, and mobile user equipments (UE), as well as communication between network nodes and between UEs. The 3GPP is also developing standards for Sixth Generation (6G) wireless communication networks.

[0006] 5G systems may include 5G Core (5GC) (network and / or network nodes) where multiple devices (e.g., non-3GPP devices) can connect to a Data Network (DN) via 5GC by connecting to the UE or residential gateway RG. For ease of understanding, UE in the present disclosure may refer to the UE and / or the RG.

[0007] 3GPP technical report (TR) 23.700-32 VI.0.0 describes Key Issue #4 which relates to identifying non-3GPP Devices connecting behind a UE or 5G-RG, and 3GPP Release 19 SA2 work item SP-240971 is also about this Key Issue. The work item UIA_ARC covers the optional restriction within the 5G System (5GS) on maximum number of simultaneously active Device Identifiers per UE / 5G-RG for devices whose traffic need to be differentiated. This is based on the assumption of the UE or 5G-RG has the information about maximum number of simultaneously active Device Ids, but how the UE or 5G-RG gets the information has not been discussed yet. How the UE or 5G-RG gets / allocates the Device Ids are out of SA2 scope (it might be discussed in stage 3).

[0008] However, 3GPP TR 23.700-32 subclause 6.32.3.2 states that the UE / 5G-RG receives the maximum number of simultaneously active Device Ids in the REGISTRATION ACCEPT message:

[0009] An operator may provision a maximum number of simultaneously active N3DBU IDs in the UE / 5G-RG subscription data. As described in clause 6.32.2 and clause 6.32.3.1, the UE / 5G-RG receives a list of subscribed N3DBU IDs and the allowed maximum number of simultaneously active N3DBU in the Registration Accept. UE / 5G-RG should enforce an N3DBU ID is only allowed to be actively used by one non-3GPP device at any time. If the limit of maximum simultaneously active N3DBU IDs is reached, the UE / 5G-RG either denies further non- 3 GPP device connections requesting N3DBU ID or routes the traffic through the PDU Session that matches the default URSP rule based on the policy (to support backward compatibility).

[0010] Issue 1: Although 3GPP stage 2 has provided information about how the network should restrict the maximum number of simultaneously active Device Ids for the not well behaved UE / 5G-RG, the current 3 GPP stage 2 has not discussed how the UE or 5G-RG gets the information about maximum number of simultaneously active Device Ids behind it. 3GPP TR 23.700-32 subclause 6.32.3.2 states that the UE / 5G-RG receives the maximum number of simultaneously active Device Ids and the list of subscribed device IDs in the REGISTRATION ACCEPT message. There are other alternatives for the UE / 5G-RG to receive the maximum number of simultaneously active Device Ids and the list of the subscribed device IDs.

[0011] Issue 2: The UE / 5G-RG includes the Device Id(s) in the PDU SESSION ESTABLISHMENT REQUEST message or PDU SESSION MODIFICATION REQUEST message. The network function, e.g., SMF / PCF, compares the received Device Id(s) and the subscribed device IDs for this UE / 5G-RG, which may be mismatched.

[0012] Further, for providing differentiated policies and charging for devices behind the UE, traffic of such devices should be identified in 5GC. This is the topic of the ongoing study in 3GPP WG2 (e.g., 3GPP TR 23.700-32 Vl.0.0, KI4: Identifying non-3GPP Devices Connecting behind a UE or 5G-RG).

[0013] It is concluded in the mentioned study (e.g., 3GPP TR 23.700-32 Vl.0.0) that the required QoS parameters for each device should be stored in a Unified Data Repository (UDR), where an identifier of the device (Device ID) is used for binding these parameters to the device. UE should send to the Session Management Function (SMF) the Device ID and its address via Non-access Stratum (NAS) session management signaling. The SMF then provides this information to PCF to provide differentiated policy and charging decisions. The UE can also use DHCPv6 messages to send the Device ID to the SMF. Furthermore, it is stated in the conclusion (clause 8.4 of 3GPP TR 23.700-32 Vl.0.0) that “The optional restriction within the 5GS on max number of simultaneously active Device Identifiers per UE / 5G-RG for device whose traffic need to be differentiated will be handled at the normative stage.” Currently, there exist some methods to enable 5GC to monitor and limit the concurrent usage of a certain resource. These methods can be extended to monitor the number of connected (as used herein, “connected” refers to a connection in the communication signal / session sense, and not necessarily a physical connection / attachment) devices to the UE and are as follows:

[0014] 1. PCF-based method: Multiple Policy Control Functions (PCFs) add / subtract the resource usage from a record in Unified Data Repository (UDR), which is initially set to the maximum of the allowed usage. Such a method is applied to other scenarios such as: Monitoring the data rate per Network Slice in clause 6.2.1.10 of 3GPP TS 23.503 V19.0.0 and Monitoring the data rate per Group by using Quality of Service (QoS) parameters, clause 6.2.1.11.

[0015] 2. NWDAF-based method: PCF queries the Network Data Analytics Function (NWDAF) to find out the dispersion analytics of a certain resource. This method is used, e.g., in clause 6.1.4.2 of TS 23.503 V19.0.0 (Eimitation of data rate per network slice with assistance of the NWDAF), where the PCF calculates the utilized data rate of the network slice by using the Data volume dispersed and Duration. The UDR stores the Maximum Slice Data Rate per S-NSSAI. When the utilized data rate of the network slice is getting close to or is exceeding the Maximum Slice Data Rate for this single Network Slice Selection Assistance Information (S-NSSAI) obtained from the UDR, the PCF may apply a policy decision to strengthen the traffic restrictions for individual Packet Data Unit (PDU) Sessions or Policy and Charging Control (PCC) rules.

[0016] 3. Selecting the same PCF: The SMF selects the same PCF for all the PDU sessions that are subject to monitoring, e.g., clause 6.2.1.9 of 3GPP TS 23.503 V19.0.0 (Monitoring the data rate per Network Slice for a UE).

[0017] 4. AMF based solution: The AMF can obtain the maximum number of devices from the subscription data and then ensures that the number of devices that request traffic identification in 5GC do not exceed this maximum number (see solution 33 in 3GPP TR 23.700-32 Vl.0.0.

[0018] However, in the PCF-based method, if one of the PCFs crashes before updating the record in UDR, this record would contain the wrong number and there is no clear way to correct this error. Therefore, this solution is not robust against PCF malfunctions. Furthermore, a single device can connect to multiple PDU sessions. Further, although two separated requests from UE should be made, it should be counted as one device in 5GC. The NWDAF-based approach requires the network to implement NWDAF, which may be a strong requirement for some operators. Further, selecting the same PCF may require to deploy a PCF that can support all of the slices the devices may want to connect to, e.g., not an acceptable requirement to comply with. In addition, the AMF based method impacts the AMF and, as a consequence, impacts the VPLMN that supports the feature.

[0019] A device, such as a non-Third Generation Partnership (3 GPP) device, may connect to a 3GPP core network via a 3GPP gateway, such as, for example, a 3GPP user equipment (UE) or 3 GPP Fifth Generation Residential Gateway (5G-RG).

[0020] Release 19 SA2 work item (see reference [3]) introduced the possibility of identifying the non-3GPP devices connecting “behind” a 3GPP gateway — i.e., connecting to the core network via a 3GPP gateway. As used herein the term “gateway” should be construed broadly to cover any communication device capable of wireless communication with a base station or other access point, including, but not limited to, 3GPP UEs, smartphones, computers, gateways, sensors, appliances, vehicles, etc.

[0021] It has been agreed that, in the scenario in which a non-3GPP device connects behind a gateway, the gateway sends to a Session Management Function (SMF) during a PDU session modification procedure message containing an identifier for the non-3GPP device. The message may also include a MAC address, a virtual local area network (VLAN) tag ID (Ethernet PDU Session Type), and / or an IP Address and port ranges (IP PDU Session Type) associated with the non-3GPP device identifier.

[0022] SA2 also agreed to the Change Request (CR) 1310 (3GPP document no. S2- 2412780) against 3GPP TS 23.503 to the PCC enhancement to support the identified non- 3GPP devices. The following statement is included in CR 1310:

[0023] “If the Non-3GPP Device Identifier is not included within the Non-3GPP Device Identifier Information as specified in clause 5.2.12.2.1 of TS 23.502 for the UE, then the PCF indicates to the SMF that the corresponding Non-3GPP Device Identifier is not available for the UE. In case of PDU Session Modification, the PCF shall reject PDU Session Modification. When PDU Session Modification is rejected, a cause code is used to notify the UE that the Non-3GPP Device Identifier is not available for the UE. ”

[0024] It is possible that there can be more than one non-3GPP devices behind a gateway (e.g., 3GPP UE or 5G-RG). To make it more efficient, multiple non-3GPP devices can be added in one PDU session modification procedure by the gateway, and it might be the case that one or more of those non-3GPP devices are rejected by the network.

[0025] SUMMARY

[0026] Some embodiments advantageously provide methods, systems, and apparatuses for limiting the number (e.g., setting a maximum number) of devices connected to a UE.

[0027] Some embodiments provide solutions in 5GC to enable the 5GC to limit the number of simultaneously connected devices. Some other embodiments provide a mechanism so that the UE or 5G-RG gets the information about maximum number of simultaneously active Device Ids behind the UE or 5G-RG.

[0028] In some embodiments, the UDM / UDR has the maximum number of simultaneously active Device Ids for the UE / 5G-RG via subscription data. Some other embodiments provide methods (alternatives) for the UE / 5G-RG to address Issue 1, i.e., to get information about the maximum number of simultaneously active Device Ids behind the UE or 5G RG and the list of the subscribed device IDs per UE or 5G-RG (e.g., except the alternative stated in 3GPP TR 23.700-32 subclause 6.32.3.2). The alternative may be as follows:

[0029] Alternative Al: The network sends the maximum number of simultaneously active Device Ids behind the UE or 5G-RG the subscribed device IDs per UE or 5G-RG via NAS transport procedure in a container, e.g., define a new container or reuse the existing container UE parameters update transparent container or possibly Steering of roaming transparent container.

[0030] Alternative A2: The network sends the maximum number of simultaneously active Device Ids behind the UE or 5G-RG, and the list of the subscribed device IDs per UE or 5G-RG via 5GSM NAS messages, e.g., in PDU SESSION ESTABLISHMENT ACCEPT message or PDU SESSION MODIFICATION COMMAND message.

[0031] Alternative A3: The operator configures the maximum number of simultaneously active Device Ids behind the UE or 5G-RG, and the list of the subscribed device IDs per UE or 5G-RG, in the 0AM DM configuration.

[0032] Alternative A4: the operator configures the maximum number of simultaneously active Device Ids behind the UE or 5G-RG, and the list of the subscribed device IDs per UE or 5G-RG, in a new parameter in USIM. Alternative A5: The SMF provides the maximum number of simultaneously active Device Ids, and the list of the subscribed device IDs per UE or 5G- RG, via a new sub option (Max_ devices and list_devices) of the Vendor- specific Information Option in a Dynamic Host Configuration Protocol version 6 (DHCPv6) message, e.g., reply to information request message. The existing 3GPP Vendor-Id registered with Intelligent Automotive Network Applications (IANA) can be used for enterprise number field.

[0033] The following table shows a comparison of example Alternatives: Table 1. - Comparison of Alternatives

[0034] In some embodiments, the alternatives in 3GPP TR 23.700-32 s.c. 6.32.3.2, i.e., alternatives Al and A2 may require control plane signaling from the network to UE / 5G- RG to transport the maximum number of simultaneously active Device Ids. In some other embodiments, alternative A5 may require enhanced control plane signaling between SMF and UDM and also the SMF and UE / 5G-RG to support DHCPv6 relay options to transport the maximum number of simultaneously active Device Ids. In some embodiments, alternatives A3 and A4 may not require the signaling from the network to UE / 5G-RG but may require the operator to configure the NAS configuration MO or the configuration on the USIM.

[0035] In some other embodiments, alternative Al (Steering of roaming transparent container) and alternatives A2, A3, A4, and A5 may not require or have AMF impact and thereby, not impacting the Visited Public Land Mobile Network (VPLMN) in the roaming case, which makes deployment easier. In some embodiments, if the change for maximum number of simultaneously active Device Ids does not occur often, alternatives Al, A2, A3 may be preferred. Otherwise, if the maximum number of simultaneously active Device Ids changes frequently, the alternatives A2 and A5 may be used.

[0036] With respect to Issue 2, if any of the received Device Id(s) are not in the subscribed device IDs, the SMF / PCF can reject the PDU SESSION ESTABLISHMENT REQUEST message or PDU SESSION MODIFICATION REQUEST message, a rejection cause and the corresponding Device Id(s) can be included in the rejection message. In some embodiments, with respect to Issue 2, the UE / 5G-RG can get the information of which Device Ids are not included in the list of subscribed device IDs, and UE / 5G-RG should not include these un-subscribed device IDs in the future.

[0037] One or more embodiments allow the UE or 5G-RG to get the maximum number of simultaneously active Device Ids allowed behind the UE or 5G-RG, and the list of the subscribed device IDs per UE or 5G-RG, except the alternative stated in 3GPP TR 23.700- 32 subclause 6.32.3.2

[0038] Some embodiments provide methods (alternatives) as follows:

[0039] • Alternative Bl: In this method (e.g., Robust PCF-based solution), the maximum number of connected devices and the list of Device IDs that are connected to the UE / RG is kept in UDR as part of UE Policy Data. In addition, to the device ID and the PCF ID may be added to the record. Each PCF can update the list based on the information obtained by SMF regarding connection of a new device or disconnection of a device. Furthermore, the PCF can read and remove records from the list if it is not consistent with the state it has from the user (e.g., due to PCF crash).

[0040] • Alternative B2: UDM-based method:

[0041] Alternative B2a: A new record is introduced in UE context in SMF data in UDM that contains the list of Device IDs for each PDU session. The SMF requests the UDM to add / remove a device from this list. The UDM calculates the number of connected devices by obtaining the list of Device IDs for all UE’s PDU sessions (optionally using a dedicated Data Network Name (DNN)). If the number of Device IDs (including the one SMF requests to add) exceeds the Maximum number of Connected devices (stored as parameter in the subscription data), the UDM rejects the SMF request.

[0042] Alternative B2b: The SMF registers and / or updates the PDU session registration in UDM for a given UE / SUPI as in the baseline. The SMF includes the Device ID(s) connected via the UE / SUPI within the registration / update request. The Maximum number of devices is included in the Subscription Data and UDM accepts the SMF registration / update request if the total number of devices connected via the UE / SUPI across all established PDU Sessions from the UE / SUPI does not reach the maximum number of devices.

[0043] • Alternative B3: Binding Support Function (BSF)-based solution: A new record is introduced in the BSF that contains the list of Device IDs for each PDU session. The PCF requests the BSF to add / remove a device from this list. Each PCF can update the list of devices per PDU Session based on the information obtained by SMF regarding connection of a new device or disconnection of a device. Furthermore, the PCF can read and remove records from the list if it is not consistent with the state it has from the user (e.g., due to PCF crash).

[0044] • Alternative B4: The same SMF is selected to ensure that the number of connected device does not exceed the Maximum number of devices which is a parameter stored in UDM in subscription data.

[0045] In some embodiments, a new record in UDR is provided. The record includes a list of maximum number of connected devices, Device ID and PCF ID which is updated by the PCFs serving the PDU Session (Alternative B 1). A new record in the UDR may include the list of the maximum number of connected devices, and the extension of the information about the PCF serving a PDU Session in the BSF by including the list of Device IDs which is updated by the PCFs serving the PDU Session (Alternative B l). Further, A new rejection indication (e.g., SM Policy Association Establishment failure if the new device ID is included in the PDU session establishment procedure, or if the SM Policy Association Modification failure if the new device ID is included in the PDU session modification procedure) may be transmitted from PCF to SMF for the maximum number of device IDs exceeded (Alternatives B1 / B3). A new rejection indication may also be transmitted from UDM to SMF (Alternative B2). A new record in UDM may be included in the UE context in SMF data, which may include the list of connected devices for each PDU session (Alternative B2a). In addition, a new record may be included in UDM in the UE’s subscription data, which may include the maximum number of connected devices (Alternatives B2, B4). Enhanced signaling may be provided between SMF and UDM and additional logic in UDM may also be provided to control maximum number of devices (Alternative B2). Furthermore, a new 5GSM rejection cause value may be provided for the SMF to reject the PDU session establishment / modification to add new device identifier (Alternatives B l, B2, B3, B4).

[0046] The alternatives are robust solutions. For example, alternatives B l, B3 are a robust solution since it allows PCF to remove the erroneous data in UDR which may exists due to PCF crash. Further, the robustness of alternative B2 may be ensured via the existing mechanisms to maintain the UE context in SMF data in UDM. Furthermore, the solutions are not dependent on NWDAF and do not require AMF impact.

[0047] According to one aspect of the present disclosure, a method implemented by a policy control function, PCF, node is provided. A request message associated with a third generation partnership projection, 3GPP, network is received, where the request message comprises at least one identifier associated with at least one non-3GPP device that is in communication with a 3GPP UE. A request associated with the request message is rejected for a cause associated with at least one of the at least one identifier: being absent from a network; or causing a number of identifiers associated with non-3GPP devices (24) to exceed a threshold. The cause is indicated to a session management function, SMF, node.

[0048] According to one or more embodiments of this aspect, the cause for rejecting the request corresponds to the at least one of the at least one identifier associated with the at least one non-3GPP device being unavailable.

[0049] According to one or more embodiments of this aspect, the cause for rejecting the request corresponds to the at least one of the at least one identifier associated with the at least one non-3GPP device causing a number of identifiers associated with non-3GPP devices connected to the 3 GPP UE to exceed a maximum number of non-3GPP device identifiers that corresponds to the threshold.

[0050] According to one or more embodiments of this aspect, the request associated with the request message is a request for quality of service, QoS, differentiation for network traffic associated with the at least one of the at least one identifier associated with at least one non-3GPP device.

[0051] According to one or more embodiments of this aspect, the request message is a session management, SM, policy association establishment message or a SM policy association modification message associated with quality of service, QoS, differentiation for at least one non-3GPP device connected to the 3 GPP UE.

[0052] According to one or more embodiments of this aspect, the indication of the cause, to the SMF node, is provided by a cause code that is configured to notify the 3GPP UE of the cause for rejecting the request.

[0053] According to one or more embodiments of this aspect, identifiable non-3GPP devices control data in a unified data repository, UDR, node is updated based on the request message.

[0054] According to one or more embodiments of this aspect, information of subscribed identifiers is received from a united data repository, UDR, node. The cause for rejecting the request is associated with the request message is based on the at least one of the at least one identifier associated with the at least one non-3GPP device not being present in the information of subscribed identifiers.

[0055] According to another aspect of the present disclosure, a policy control function, PCF, node is provided. The PCF node is configured to: receive a request message associated with a third generation partnership projection, 3GPP, network, where the request message comprises at least one identifier associated with at least one non-3GPP device that is in communication with a 3 GPP UE; reject a request associated with the request message for a cause associated with at least one of the at least one identifier being absent from a network; or causing a number of identifiers associated with non-3GPP devices (24) to exceed a threshold; and indicate, to a session management function, SMF, node, the cause.

[0056] According to one or more embodiments of this aspect, the cause for rejecting the request corresponds to the at least one of the at least one identifier associated with the at least one non-3GPP device being unavailable.

[0057] According to one or more embodiments of this aspect, the cause for rejecting the request corresponds to the at least one of the at least one identifier associated with the at least one non-3GPP device causing a number of identifiers associated with non-3GPP devices connected to the 3 GPP UE to exceed a maximum number of non-3GPP device identifiers that corresponds to the threshold.

[0058] According to one or more embodiments of this aspect, the request associated with the request message is a request for quality of service, QoS, differentiation for network traffic associated with the at least one of the at least one identifier associated with at least one non-3GPP device. According to one or more embodiments of this aspect, the request message is a session management, SM, policy association establishment message or a SM policy association modification message associated with quality of service, QoS, differentiation for at least one non-3GPP device connected to the 3 GPP UE.

[0059] According to one or more embodiments of this aspect, the indication of the cause, to the SMF node, is provided by a cause code that is configured to notify the 3GPP UE of the cause for rejecting the request.

[0060] According to one or more embodiments of this aspect, the PCF node is configured to update identifiable non-3GPP devices control data in a unified data repository, UDR, node based on the request message.

[0061] According to one or more embodiments of this aspect, the PCF node is configured to receive, from an unified data repository, UDR, node, information of subscribed identifiers; and the cause for rejecting the request is associated with the request message being based on the at least one of the at least one identifier associated with the at least one non-3GPP device not being present in the information of subscribed identifiers.

[0062] Certain challenges presently exist. For instance, the current 3GPP stage 2 describes using a cause code to notify a gateway that a non-3GPP device identifier is not- available for the gateway, which means that the SMF includes a 5GSM cause code in a PDU SESSION MODIFICATION REJECT message to reject a PDU SESSION MODIFICATION REQUEST message from the gateway. As noted above, more than one non-3GPP device identifier can be included in one PDU SESSION MODIFICATION REQUEST message, and, if only one or some of the non-3GPP device identifiers are rejected (e.g., not- authorized), and the PDU SESSION MODIFICATION REQUEST message is rejected then the available non-3GPP device identifiers would be rejected as well, and the gateway would have no information indicating which non-3GPP device identifier(s) are rejected (z.e., not-available) and, hence, which are available. To indicate to the gateway which identifiers are not-available, a new IE can be added to the PDU SESSION MODIFICATION REJECT message, and the new IE can be used to convey to the gateway information indicating the unavailable 3GPP device identifier(s).

[0063] Additionally, the gateway might include other information which needs to be modified with the change of non-3GPP device identifier(s) in the same PDU session modification procedure, and by the 5GSM cause code in PDU SESSION MODIFICATION REJECT message, if there is no issue on the change of the other information, the UE has to trigger another PDU session modification procedure again for the change of the other information.

[0064] Another problem is that, after the gateway has added a non-3GPP device connected behind the gateway on a PDU session, it might happen that the non-3GPP device identifier for the non-3GPP device is removed due to a subscription change in a Unified Data Repository (UDR); however, it is not specified in the current 3GPP specifications how the UE is informed about this.

[0065] Accordingly, in one aspect there is provided a method performed by a gateway (e.g., a UE) for providing at least a first device (e.g., a first non-3GPP device) and a second device (a second non-3GPP device) with access to a core network. The method includes transmitting a session related message (e.g., PDU session modification request) comprising: a first device identifier (ID) for identifying the first device and a second device ID for identifying the second device. The method also includes receiving a response message responsive to the session related message, wherein the response message responsive to the session related message comprises information indicating: i) whether the first device ID is an authorized device ID and ii) whether the second device ID is an authorized device ID.

[0066] In another aspect there is provided a method performed by a network function, NF, of a core network, The method includes receiving a first message comprising: a first device identifier (ID) for identifying a first device behind a gateway and a second device ID for identifying a second device behind the gateway. The method also includes transmitting a response message responsive to the first message, wherein the response message responsive to the first message comprises information indicating: i) whether the first device ID is an authorized device ID and ii) whether the second device ID is an authorized device ID.

[0067] In another aspect there is provided a method performed by a gateway for providing at least a first device (e.g., a first non-3GPP device) with access to a core network. The method includes transmitting a session related message (e.g., PDU session modification request) comprising: a first device identifier (ID) for identifying the first device. The method also includes, after transmitting the session related message, receiving a first message comprising information indicating that the first device ID is an authorized device ID. The method also includes, after receiving the first message, receiving a second message (e.g., PDU session modification command) comprising information indicating that the first device ID is no longer an authorized device ID. In another aspect the method performed by the NF includes, after a gateway has transmitted a session related message comprising a first device identifier (ID) for identifying a first device behind the gateway, receiving a first message comprising first information indicating that the first device ID is no longer an authorized device ID. The method also includes, after receiving the first message, transmitting a second message comprising the first information indicating that the first device ID is no longer an authorized device ID or second information indicating that the first device ID is no longer an authorized device ID.

[0068] In another aspect there is provided a computer program comprising instructions which when executed by processing circuitry of an apparatus causes the apparatus to perform any of the methods disclosed herein. In one embodiment, there is provided a carrier containing the computer program wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium. In another aspect there is provided an apparatus that is configured to perform the methods disclosed herein. The apparatus may include memory and processing circuitry coupled to the memory.

[0069] An advantage of certain embodiments disclosed herein is that they allow a network function in the core network to notify the gateway which non-3GPP device identifier(s) are not- available in one or more of the following scenarios: (1) for the scenario of the UE request to add a plurality of non-3GPP devices connecting behind it in one PDU SESSION MODIFICATION REQUEST and the network reject some of the non-3GPP devices, and (2) for the scenario of network notifying the gateway (e.g., the gateway UE or 5G-RG) which non-3GPP device identifier(s) which were added before are now not-available anymore due to a subscription change.

[0070] BRIEF DESCRIPTION OF THE DRAWINGS

[0071] A more complete understanding of the present embodiments, and the attendant advantages and features thereof, will be more readily understood by reference to the following detailed description when considered in conjunction with the accompanying drawings wherein:

[0072] FIG. 1 is a schematic diagram of an example network architecture illustrating a communication system according to the principles in the present disclosure;

[0073] FIG. 2 is a block diagram of a device, a UE, and one or more network nodes according to some embodiments of the present disclosure; FIG. 3 is a flowchart of an example process in a network node according to some embodiments of the present disclosure;

[0074] FIG. 4 is a flowchart of another example process in a network node according to some embodiments of the present disclosure;

[0075] FIG. 5 is a flowchart of an example process in a network node according to some embodiments of the present disclosure;

[0076] FIG. 6 is a flowchart of another example process in a network node according to some embodiments of the present disclosure;

[0077] FIG. 7 is a flowchart of an example process in a network node according to some embodiments of the present disclosure;

[0078] FIG. 8 is a flowchart of another example process in a network node according to some embodiments of the present disclosure;

[0079] FIG. 9 shows an example of a process in one or more network nodes, UE, and / or device according to some embodiments of the present disclosure;

[0080] FIG. 10 shows another example of a process in one or more network nodes, UE, and / or device according to some embodiments of the present disclosure;

[0081] FIG. 11 shows an example configuration according to some embodiments of the present disclosure;

[0082] FIG. 12 shows another example of a process in one or more network nodes, UE, and / or device according to some embodiments of the present disclosure;

[0083] FIG. 13 shows an example process where Device Id(s) are included in one or more messages according to some embodiments of the present disclosure;

[0084] FIG. 14 shows an example process where Device Id(s) are included in one or more messages according to some embodiments of the present disclosure;

[0085] FIG. 15 shows an example procedure for PDU session modification and establishment according to some embodiments of the present disclosure;

[0086] FIG. 16 shows another example procedure for PDU session modification and establishment according to some embodiments of the present disclosure;

[0087] FIG. 17 shows an example procedure for PDU session modification for restricting the number of devices according to some embodiments of the present disclosure;

[0088] FIG. 18 shows an example procedure for controlling the number of devices;

[0089] FIG. 19 shows another example procedure for controlling the number of devices;

[0090] FIG. 20 illustrates a system according to some embodiments; FIG. 21 is a message flow diagram illustrating a message flow according to some embodiments;

[0091] FIG. 22 is a message flow diagram illustrating a message flow according to some embodiments;

[0092] FIG. 23 is a flowchart illustrating a process according to some embodiments;

[0093] FIG. 24 is a flowchart illustrating another process according to some embodiments;

[0094] FIG. 25 is a flowchart illustrating another process according to some embodiments;

[0095] FIG. 26 is a flowchart illustrating another process according to some embodiments;

[0096] FIG. 27 is a block diagram of a network node according to some embodiments;

[0097] FIG. 28 is a block diagram of a gateway according to some embodiments; and FIG. 29 is a signaling diagram of an example SMF signaling and functions according to some embodiments.

[0098] DETAILED DESCRIPTION

[0099] Before describing in detail example embodiments, it is noted that the embodiments reside primarily in combinations of apparatus components and processing steps related to limiting the number (e.g., setting a maximum number) of devices connected to a UE. Accordingly, components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

[0100] As used herein, relational terms, such as “first” and “second,” “top” and “bottom,” and the like, may be used solely to distinguish one entity or element from another entity or element without necessarily requiring or implying any physical or logical relationship or order between such entities or elements. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the concepts described herein. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and / or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. In embodiments described herein, the joining term, “in communication with” and the like, may be used to indicate electrical or data communication, which may be accomplished by physical contact, induction, electromagnetic radiation, radio signaling, infrared signaling or optical signaling, for example. One having ordinary skill in the art will appreciate that multiple components may interoperate, and modifications and variations are possible of achieving the electrical and data communication.

[0101] In some embodiments described herein, the term “coupled,” “connected,” and the like, may be used herein to indicate a connection, although not necessarily directly, and may include wired and / or wireless connections.

[0102] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the concepts described herein. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and / or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0103] The term “network node” used herein can be any kind of network node comprised in a radio network which may further comprise any of base station (BS), radio base station, base transceiver station (BTS), base station controller (BSC), radio network controller (RNC), g Node B (gNB), evolved Node B (eNB or eNodeB), Node B, multistandard radio (MSR) radio node such as MSR BS, multi-cell / multicast coordination entity (MCE), integrated access and backhaul (IAB) node, relay node, donor node controlling relay, radio access point (AP), transmission points, transmission nodes, Remote Radio Unit (RRU) Remote Radio Head (RRH), a core network node (e.g., mobile management entity (MME), self-organizing network (SON) node, a coordinating node, positioning node, MDT node, etc.), an external node (e.g., 3rd party node, a node external to the current network), nodes in distributed antenna system (DAS), a spectrum access system (SAS) node, an element management system (EMS), an AMF, an RG, W-AGF, SMF, user plane function (UPF), authentication server function (AUSF), user data management (UDM), an SMF, a UDR, a PCF, any other core network node, etc. The network node may also comprise test equipment. The term “radio node” used herein may be used to also denote a UE or a radio network node. In some embodiments, the non-limiting terms user equipment (UE) and wireless device (WD) may be used interchangeably. The UE herein can be any type of wireless device capable of communicating with a network node or another UE over radio signals and / or with another device (e.g., AUN3 device) and / or with another network node via a wired or wireline connection. The UE may also be a radio communication device, target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine communication (M2M), low-cost and / or low-complexity UE, a sensor equipped with UE, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, Customer Premises Equipment (CPE), an Internet of Things (loT) device, or a Narrowband loT (NB-IOT) device, etc. In some embodiments, a UE may refer to a residential gateway (RG).

[0104] Similarly, the non-limiting terms device and AUN3 may be used interchangeably. An AUN3 device may refer to an authenticable Non-3GPP device, e.g., a device that may be authenticated such as by any component of a network including core network nodes, access network nodes, etc., and that is not considered to or does not support communication with network components based on 3GPP standards. In some embodiments, an AUN3 device may refer to a device that does not support NAS signaling, is connected to a core network (e.g., 5GC) via a UE (e.g., RG) and can be authenticated by the core network (e.g., 5GC) over the UE (e.g., RG). Further, a device may be configured to communicate with a UE such as an RG via wireline connection (i.e., wired connection), which may be configured to communicate with other network components such as access nodes, core network nodes, etc.

[0105] Also, in some embodiments the generic term “radio network node” is used. It can be any kind of a radio network node which may comprise any of base station, radio base station, base transceiver station, base station controller, network controller, RNC, evolved Node B (eNB), Node B, gNB, Multi-cell / multicast Coordination Entity (MCE), IAB node, relay node, access point, radio access point, Remote Radio Unit (RRU) Remote Radio Head (RRH).

[0106] Note that although terminology from one particular wireless system, such as, for example, 3GPP LTE and / or New Radio (NR), may be used in this disclosure, this should not be seen as limiting the scope of the disclosure to only the aforementioned system. Other wireless systems, including without limitation Wide Band Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMax), Ultra Mobile Broadband (UMB) and Global System for Mobile Communications (GSM), may also benefit from exploiting the ideas covered within this disclosure.

[0107] Note further, that functions described herein as being performed by a wireless device or a network node may be distributed over a plurality of wireless devices and / or network nodes. In other words, it is contemplated that the functions of the network node and wireless device described herein are not limited to performance by a single physical device and, in fact, can be distributed among several physical devices.

[0108] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0109] Referring again to the drawing figures, in which like elements are referred to by like reference numerals, there is shown in FIG. 1 a schematic diagram of a communication system 10, according to an embodiment, such as a 3GPP-type cellular network that may support standards such as LTE and / or NR (5G), which comprises a network 12 (e.g., wireless access network, wireline access network, etc.) and a network 14 (e.g., core network). The network 12 comprises a plurality of network nodes 16a, 16b, 16c, and 16d. Network nodes 16a, 16b, 16c may NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 18a, 18b, 18c (referred to collectively as coverage areas 18). Network node 16d may an access node and may comprise and W- AGF and / or be associated with a wireline 5G access network (W-5GAN), etc. Each network node 16a, 16b, 16c, 16d is connectable to the network 14 (and / or network node 16d comprised in network 14) over a wired or wireless connection 20. Network node 16e in core network 14 may be one or more core network nodes such as an AMF 16el, UDM 16e2, UDR 16e3, SMF 16e4, PCF 16e5, etc. (collectively referred to as network node 16e). Network nodes 16a, 16b, 16c, 16d, 16e may be referred to collectively as network nodes 16.

[0110] Connections 95a, 95b, 95c, 95d are shown and may be collectively referred to as connection 95. A first wireless device (UE) 22a located in coverage area 18a is configured to connect (wirelessly and / or via wired connection 95a) to, or be paged by, the corresponding network node 16a. A second UE 22b in coverage area 18b is connectable (wirelessly and / or via wired connection 95b) to the corresponding network node 16b. A third UE 22c is connectable (wirelessly and / or via wired connection 95c) to the corresponding network node 16d. In some embodiments, connection 95c is a wired / wireline connection configured to provide a wired signal path between UE 22 and network node 16d. In some other embodiments, a wired / wireline connection may be configured to provide access to one or more devices via the wired signal path, where the one or more devices may access features and functions associated with the connection and / or corresponding network. UE 22c is also connectable (wirelessly and / or via wired connection 95d) to device 24 (which may be an AUN-3 device, a non-3GPP device, etc.). Device 24 in this configuration may be referred to as being “behind” UE 22c, i.e., device 24 may be configured to communicate with network node 16d and / or other nodes such as network node 16e via UE 22c (e.g., RG).

[0111] In some embodiments, connection 95c and / or connection 95d may be referred to as non-3GPP access. While a plurality of UEs 22a, 22b, 22c (collectively referred to as UE 22) are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding network node 16. Note that although only three UEs 22 and five network nodes 16 are shown for convenience, the communication system may include many more UEs 22 and network nodes 16.

[0112] Also, it is contemplated that a UE 22 can be in simultaneous communication and / or configured to separately communicate with more than one network node 16 and more than one type of network node 16. For example, a UE 22 can have dual connectivity with a network node 16 that supports LTE and the same or a different network node 16 that supports NR. As an example, UE 22 can be in communication with an eNB for LTE / E-UTRAN and a gNB for NR / NG-RAN.

[0113] A network node 16 is configured to include a NN management unit 32 which is configured to perform one or more network node 16 functions such as determining network access (e.g., restrict, grant network access such as registration requests). A UE 22 is configured to include a UE management unit 34 which is configured to perform one or more UE functions described herein.

[0114] Example implementations, in accordance with an embodiment, of the UE 22, network node 16 and device 24 discussed in the preceding paragraphs will now be described with reference to FIG. 2. In a communication system 10, a device 24 comprises hardware (HW) 38 including a communication interface 40 configured to set up and maintain a wired or wireless connection 95 with an interface of a different communication device of the communication system 10, such as UE 22, network node 16, etc. The device 24 further comprises processing circuitry 42, which may have storage and / or processing capabilities. The processing circuitry 42 may include a processor 44 and memory 46. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 42 may comprise integrated circuitry for processing and / or control, e.g., one or more processors and / or processor cores and / or FPGAs (Field Programmable Gate Array) and / or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 44 may be configured to access (e.g., write to and / or read from) memory 46, which may comprise any kind of volatile and / or nonvolatile memory, e.g., cache and / or buffer memory and / or RAM (Random Access Memory) and / or ROM (Read-Only Memory) and / or optical memory and / or EPROM (Erasable Programmable Read-Only Memory).

[0115] Processing circuitry 42 may be configured to control any of the methods and / or processes described herein and / or to cause such methods, and / or processes to be performed, e.g., by device 24. Processor 44 corresponds to one or more processors 44 for performing device 24 functions described herein. The device 24 includes memory 46 that is configured to store data, programmatic software code and / or other information described herein. In some embodiments, the software 48 and / or the device application 50 may include instructions that, when executed by the processor 44 and / or processing circuitry 42, causes the processor 44 and / or processing circuitry 42 to perform the processes described herein with respect to device 24. The instructions may be software associated with the device 24.

[0116] The software 48 may be executable by the processing circuitry 42. The software 48 includes a device application 50. The device application 50 may be operable to provide a service to a user. In providing the service to the user, the device application 50 may provide user data and / or allow the user to make a request to access and / or connection to a network node 16 and / or UE 22, etc. The “user data” may be data and information described herein as implementing the described functionality. The processing circuitry 42 of the device 24 may include a device management unit 54 configured to which is configured to perform one or more device 24 functions.

[0117] The communication system 10 further includes a network node 16 provided in a communication system 10 and including hardware 58 enabling it to communicate with the device 24, the UE 22, and other network nodes 16 (such as via wired or wireless connection 96). The hardware 58 may include a communication interface 60 for setting up and maintaining a wired or wireless connection 95 with an interface of a different communication device of the communication system 10, as well as a radio interface 62 for setting up and maintaining at least a wireless connection 64 with a UE 22 located in a coverage area 18 served by the network node 16. The radio interface may include one or more antennas 76. The radio interface 62 may be formed as or may include, for example, one or more RF transmitters, one or more RF receivers, and / or one or more RF transceivers. The communication interface 60 may be configured to facilitate a connection 66 to the device 24 and wired connection 96 to the UE 22. The connection 66 may be direct or it may pass through a network 14 of the communication system 10 and / or through one or more intermediate networks outside the communication system 10.

[0118] In the embodiment shown, the hardware 58 of the network node 16 further includes processing circuitry 68. The processing circuitry 68 may include a processor 70 and a memory 72. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 68 may comprise integrated circuitry for processing and / or control, e.g., one or more processors and / or processor cores and / or FPGAs (Field Programmable Gate Array) and / or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 70 may be configured to access (e.g., write to and / or read from) the memory 72, which may comprise any kind of volatile and / or nonvolatile memory, e.g., cache and / or buffer memory and / or RAM (Random Access Memory) and / or ROM (Read-Only Memory) and / or optical memory and / or EPROM (Erasable Programmable Read-Only Memory).

[0119] Thus, the network node 16 further has software 74 stored internally in, for example, memory 72, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by the network node 16 via an external connection. The software 74 may be executable by the processing circuitry 68. The processing circuitry 68 may be configured to control any of the methods and / or processes described herein and / or to cause such methods, and / or processes to be performed, e.g., by network node 16. Processor 70 corresponds to one or more processors 70 for performing network node 16 functions described herein. The memory 72 is configured to store data, programmatic software code and / or other information described herein. In some embodiments, the software 74 may include instructions that, when executed by the processor 70 and / or processing circuitry 68, causes the processor 70 and / or processing circuitry 68 to perform the processes described herein with respect to network node 16. For example, processing circuitry 68 of the network node 16 may include a NN management unit 32 which is configured to perform one or more network node 16 functions.

[0120] The communication system 10 further includes the UE 22 already referred to. The UE 22 may have hardware 80 that may include a radio interface 82 configured to set up and maintain a wireless connection 64 with a network node 16 serving a coverage area 18 in which the UE 22 is currently located and / or communication interface 83 configured to set up and maintain wired connection 95 with a network node 16. The radio interface 82 may be formed as or may include, for example, one or more RF transmitters, one or more RF receivers, and / or one or more RF transceivers.

[0121] The hardware 80 of the UE 22 further includes processing circuitry 84. The processing circuitry 84 may include a processor 86 and memory 88. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 84 may comprise integrated circuitry for processing and / or control, e.g., one or more processors and / or processor cores and / or FPGAs (Field Programmable Gate Array) and / or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 86 may be configured to access (e.g., write to and / or read from) memory 88, which may comprise any kind of volatile and / or nonvolatile memory, e.g., cache and / or buffer memory and / or RAM (Random Access Memory) and / or ROM (Read-Only Memory) and / or optical memory and / or EPROM (Erasable Programmable Read-Only Memory).

[0122] Thus, the UE 22 may further comprise software 90, which is stored in, for example, memory 88 at the UE 22, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by the UE 22. The software 90 may be executable by the processing circuitry 84. The software 90 may include a UE application 92. The UE application 92 may be operable to provide a service to a human or non-human user via the UE 22. The UE application 92 may interact with the user to generate the user data that it provides.

[0123] The processing circuitry 84 may be configured to control any of the methods and / or processes described herein and / or to cause such methods, and / or processes to be performed, e.g., by UE 22. The processor 86 corresponds to one or more processors 86 for performing UE 22 functions described herein. The UE 22 includes memory 88 that is configured to store data, programmatic software code and / or other information described herein. In some embodiments, the software 90 and / or the UE application 92 may include instructions that, when executed by the processor 86 and / or processing circuitry 84, causes the processor 86 and / or processing circuitry 84 to perform the processes described herein with respect to UE 22. For example, the processing circuitry 84 of the UE 22 may include a UE management unit 34 which is configured to perform one or more UE functions such as transmit a registration request, etc.

[0124] In some embodiments, the inner workings of the network node 16, UE 22, and device 24 may be as shown in FIG. 2 and independently, the surrounding network topology may be that of FIG. 1.

[0125] The wireless connection 64 and wired connection 95 between the UE 22 and the network node 16 is in accordance with the teachings of the embodiments described throughout this disclosure. In some embodiments, connections 64, 64 may refer to one or more connections 95 shown in FIG. 1.

[0126] Although FIGS. 1 and 2 show various “units” such as NN management unit 32, and UE management unit 34 as being within a respective processor, it is contemplated that these units may be implemented such that a portion of the unit is stored in a corresponding memory within the processing circuitry. In other words, the units may be implemented in hardware or in a combination of hardware and software within the processing circuitry.

[0127] FIG. 3 is a flowchart of an example process in a network node 16. One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 68 (including the node management unit 32), processor 70, and / or radio interface 62. Network node 16 such as via processing circuitry 68 and / or processor 70 and / or radio interface 62 is configured to determine (Block S100) a maximum number of devices and a list of device identifiers (IDs) associated with at least one of the one or more devices that are connected to the UE 22. The maximum number is kept in a second network node 16 of the at least one other network node 16 as part of UE Policy Data. The second network node 16 includes a Unified Data Repository (UDR) 16e3.

[0128] In some embodiments, the method further includes adding a device ID and a Policy Control Function (PCF) ID to a record.

[0129] In some other embodiments, one or both of: (A) each PCF update the list based on information obtained by a Session Management Function (SMF) 16e4 regarding connection of a new device or disconnection of a device; and (B) at least one PCF 16e5 being configured to read and remove records from the list if the records are not consistent with a state associated with a user. FIG. 4 is a flowchart of an example process in a network node 16. One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 68 (including the node management unit 32), processor 70, and / or radio interface 62. Network node 16 such as via processing circuitry 68 and / or processor 70 and / or radio interface 62 is configured to create (Block S102) a record in UE context in Session Management Function (SMF) data in the second network node 16 that has a list of device identifiers (IDs) for each Packet Data Unit (PDU) session.

[0130] In some embodiments, an SMF network node 16 requests the UDM 16e2 to add and / or remove a device from the list, and the method further includes one or both of: (A) calculating a number of connected devices by obtaining the list of device IDs for one or more PDU sessions associated with the UE 22 and / or one or more other UEs 22; and (B) if a number of device IDs exceeds a maximum number of connected devices, rejecting the SMF network node request.

[0131] FIG. 5 is a flowchart of another example process in a network node 16. One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 68 (including the node management unit 32), processor 70, and / or radio interface 62. Network node 16 such as via processing circuitry 68 and / or processor 70 and / or radio interface 62 is configured to accept (Block S104) the SMF registration and / or update request if a total number of devices connected via the UE 22 across established PDU Sessions from the UE does not reach the maximum number of devices 24.

[0132] FIG. 6 is a flowchart of yet another example process in a network node 16. One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 68 (including the node management unit 32), processor 70, and / or radio interface 62. Network node 16 such as via processing circuitry 68 and / or processor 70 and / or radio interface 62 is configured to create (Block S106) a BSF record that contains a list of device identifiers (IDs) for each Packet Data Unit (PDU) session, a Policy Control Function (PCF) network node 16 (also referred to as PCF 16e5 or PCF node 16e5) requesting third network node 16 to add and / or remove a device 24 from the list.

[0133] In some embodiments, one or both of: (A) each PCF network node 16 updates the list per PDU Session based on information obtained by a Session Management Function (SMF) network node 16 regarding connection of a new device 24 or disconnection of a device 24; and (B) the PCF network node 16 is configured to read and remove records from the list if not consistent with the state the PCF network node 16 has from a corresponding user.

[0134] FIG. 7 is a flowchart of another example process in network node 16. One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 68 (including the node management unit 32), processor 70, and / or radio interface 62. Network node 16 such as via processing circuitry 68 and / or processor 70 and / or radio interface 62 is configured to select (Block S108) a same Session Management Function (SMF) network node 16 to ensure that a number of connected devices 24 does not exceed a maximum number of devices 24, the maximum number being a parameter stored in a Unified Data Management (UDM) network node in subscription data.

[0135] FIG. 8 is a flowchart of another example process in a PCF node 16e5 (e.g., one type of network node 16e). One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 68 (including the node management unit 32), processor 70, and / or radio interface 62. PCF node 16e5 is configured to receive (Block SI 10) a request message associated with a third generation partnership projection, 3GPP, network, where the request message comprises at least one identifier associated with at least one non-3GPP device 24 that is in communication with a 3GPP UE 22, as described herein. PCF node 16e5 is configured to reject (S 112) a request associated with the request message for a cause associated with at least one of the at least one identifier being absent from a network; or causing a number of identifiers associated with non-3GPP devices (24) to exceed a threshold, as described herein. PCF 16e5 is configured to indicate (Block S I 14), to a session management function, SMF, node 16e4, the cause, as described herein. According to one or more embodiments, the cause for rejecting the request corresponds to the at least one of the at least one identifier associated with the at least one non-3GPP device 24 being unavailable.

[0136] According to one or more embodiments, the cause for rejecting the request corresponds to the at least one of the at least one identifier associated with the at least one non-3GPP device 24 causing a number of identifiers associated with non-3GPP devices connected to the 3 GPP UE to exceed a maximum number of non-3GPP device identifiers that corresponds to the threshold.

[0137] According to one or more embodiments, the request associated with the request message is a request for quality of service, QoS, differentiation for network traffic associated with the at least one of the at least one identifier associated with at least one non-3GPP device 24.

[0138] According to one or more embodiments, the request message is a session management, SM, policy association establishment message or a SM policy association modification message associated with quality of service, QoS, differentiation for at least one non-3GPP device connected to the 3GPP UE 22.

[0139] According to one or more embodiments, the indication of the cause, to the SMF node 16e4, is provided by a cause code that is configured to notify the 3GPP UE 22 of the cause for rejecting the request.

[0140] According to one or more embodiments, the PCF node 16e5 is configured to update identifiable non-3GPP devices control data in a unified data repository, UDR, node 16e3 based on the request message.

[0141] According to one or more embodiments, the PCF node 16e5 is configured to receive, from an unified data repository, UDR, node 16e3, information of subscribed identifiers; and the cause for rejecting the request is associated with the request message being based on the at least one of the at least one identifier associated with the at least one non-3GPP device 24 not being present in the information of subscribed identifiers.

[0142] Having described the general process flow of arrangements of the disclosure and having provided examples of hardware and software arrangements for implementing the processes and functions of the disclosure, the sections below provide details and examples of arrangements for limiting the number (e.g., setting a maximum number) of devices 24 connected to a UE 22. In some embodiments, the term “network” is used and may refer to any component of system 10 such as a network node 16.

[0143] Some embodiments relate to a maximum number of device IDs behind a UE 22.

[0144] Issue 1:

[0145] With reference to the detailed alternatives as described above:

[0146] Alternative Al: The network sends the maximum number of simultaneously active Device Ids behind the UE or 5G-RG, and the list of the subscribed device IDs per UE or 5G-RG, via NAS transport procedure in a container, e.g., define a new container or reuse the existing container UE parameters update transparent container or steering of roaming transparent container to carry the information of maximum number of simultaneously active Device Ids.

[0147] Alternative A2: FIG. 9 shows an example of Alternative A2. Steps 1-3 are a use case where UE / 5G-RG receives the maximum number of simultaneously active Device Ids behind the UE 22 or 5G-RG, and the list of the subscribed device IDs per UE 22 or 5G- RG, by NAS transport procedure. Steps 4-6 are about the use case in which, when the maximum number of simultaneously active Device Ids, and the list of the subscribed device IDs per UE 22 or 5G-RG, are changed from UDR 16e3, the network sends the updated value to the UE / 5G-RG during NAS transport procedure. New IE or parameter are shown.

[0148] The network sends the maximum number of simultaneously active Device Ids behind the UE 22 (or 5G-RG), and the list of the subscribed device IDs per UE 22 (or 5G- RG), via 5GSM NAS messages, e.g., in PDU SESSION ESTABLISHMENT ACCEPT message or PDU SESSION MODIFICATION COMMAND message.

[0149] Alternative A3: FIG. 10 shows an example of Alternative 3. Steps 1-3 relate to a use case where UE 22 (or 5G-RG) receives the maximum number of simultaneously active Device Ids behind the UE 22 (or 5G-RG), and the list of the subscribed device IDs per UE 22 (or 5G-RG), during PDU session establishment procedure. Steps 4-6 are about the use case in which, when the maximum number of simultaneously active Device Ids, and the list of the subscribed device IDs per UE 22 (or 5G-RG), are changed from UDR, the network sends the updated value to the UE / 5G-RG during PDU session modification procedure. The new IE or parameter are shown.

[0150] Note: the SMF can get the information of maximum number of simultaneously active Device Ids behind the UE 22 (or 5G-RG), and the list of the subscribed device IDs per UE 22 or 5G-RG, from PCF as well.

[0151] The operator configures the maximum number of simultaneously active Device Ids behind the UE 22 or 5G-RG, and the list of the subscribed device IDs per UE 22 or 5G- RG, in the 0AM DM configuration.

[0152] FIG. 11 shows an example configuration which includes adding a new NAS configuration MO parameter for "maximum number of simultaneously active Device Ids behind the UE" and MO parameter for “list of the subscribed device IDs per UE or 5G- RG” in 3GPP TS24.368.

[0153] Alternative 4: The operator configures the maximum number of simultaneously active Device Ids behind the UE 22 or 5G-RG, list of the subscribed device IDs per UE 22 or 5G-RG in a new parameter in US IM.

[0154] In 3GPP TS 31.102, add a new Elementary File, e.g., EFActiveDevidsUEmax (Active Device Ids behind the UE maximum value) indicating the maximum number of simultaneously active Device Ids behind the UE 22 or 5G-RG, and add a new Elementary File, e.g. EFustDevids (list of the subscribed device IDs per UE or 5G-RG) indicating the list of the subscribed device IDs per UE 22 or 5G-RG.

[0155] Alternative 5: SMF 16e4 sends the maximum number of simultaneously active Device IDs behind the UE 22 (or 5G-RG), and the list of the subscribed device IDs per UE 22 or 5G-RG, via a DHCPv6 message. To do so, the SMF 16e4 includes a new sub option for the vendor-specific option (option 17), Max_device and list_devices, in the DHCPv6 message sent to UE / 5G-RG. The existing 3GPP Vendor-Id registered with IANA can be used for enterprise number field.

[0156] FIG. 12 shows an example of Alternative 6. In steps 1-3, the SMF 16e4 obtains the maximum number of simultaneously active Device Ids behind the UE 22 or 5G-RG and the list of the subscribed device IDs per UE 22 or 5G-RG, during PDU session establishment procedure from UDM 16e2 or PCF 16e5. In Step 4, the UE 22 uses DHCPv6 information request message to request this parameter. The SMF 16e4 then includes this parameter in the reply message using vendor- specific option (the SMF 16e4 transmits and receives DHCPv6 messages through the user plane via UPF as per current standards.). If the value for the maximum number of simultaneously active Device IDs behind the UE / 5G-RG or the list of the subscribed device IDs per UE 22 or 5G-RG is updated (steps 5 and 6) in the lifetime of the PDU session, the SMF 16e4 sends a reconfigure message to UE / 5G-RG to prompt the UE 22 to send information request message. Then, similarly as in step 4, the maximum number of simultaneously active Device IDs behind the UE / 5G-RG or the list of the subscribed device IDs per UE or 5G- RG is transmitted to UE 22 or 5G-RG in the reply message (step 7).

[0157] Issue 2:

[0158] If any of the received Device Id(s) are not in the subscribed device IDs, the SMF 16e4 / PCF 16e5 can reject the PDU SESSION ESTABLISHMENT REQUEST message or PDU SESSION MODIFICATION REQUEST message, a rejection cause and the corresponding Device Id(s) can be included in the rejection message. FIGS. 13 and 14 show example processes where Device Id(s) are included in one or more messages. On FIG. 13, at step la. PDU session establishment request / modification (Device Ids) is transmitted to the SMF 16e4. At step 2a. SM Policy Association Establishment / Modification request is transmitted to the PCF 16e5. The PCF 16e5 transmits SM Policy Association Establishment / Modification response to SMF 16e4 at step 2b, and at step lb, PDU session establishment accept / reject, including Device Ids not subscribed, is transmitted by the SMF 16e4. On step 1 of FIG. 14, at step la. PDU session establishment request / modification (Device Ids) is transmitted to the SMF 16e4. At step lb, PDU session establishment accept / reject, including Device Ids not subscribed, is transmitted by the SMF 16e4.

[0159] Some embodiments provide an apparatus, method, and / or system configured to limit the number of devices connected to UE 22.

[0160] Alternative Bl: robust PCF-based solution

[0161] New data records:

[0162] One or more embodiments involve having the Connected Devices Control Data in policy data in UDR 16e3 as follows:

[0163] Table 2. (or Table 2.7.1-1) - Data keys: Data keys

[0164] Table 3. (or Table 2.7.1-2) - Identifiable Non-3GPP Devices Control Data

[0165] FIGS. 15 and 16 (also referred to as Figure 2.7.1-3 and Figure 2.7.1.4) show the procedure for PDU session modification and establishment, which enable PCF 16e5 to limit the number of connected devices to UE 22.

[0166] PDU session modification (FIG. 15):

[0167] Step 1. The device 24 is connected to or disconnected from the UE / RG 22

[0168] Step 2. The UE / RG 22 sends a PDU session modification request to network node 16b (SMF 16e4 (via network node 16a (AMF 16el)) and adds the Device ID, device address, and an indication of whether the device is connected or disconnected to the request.

[0169] Step 3. The network node 16b (SMF 16e4) requests SM policy association and includes the Device ID, device address, and indication of connection to the request. Step 4 — 5. The network node 16c (PCF 16e5) uses SUPI to obtain the Identifiable Non-3GPP Devices Control Data.

[0170] Step 6. The network node 16c (PCF 16e5) may use the PCF ID to check if this list is consistence with its local data. Furthermore, the PCF 16e5 calculates the number of connected devices. If the calculated number exceeds the maximum number of identifiable non-3GPP device Ids, the network node 16c (PCF 16e5) may reject the SM policy association request and indicate the cause of rejection to be maximum number of devices reached. The network node 16b (SMF 16e4) may then rejects the PDU session modification request by providing the cause.

[0171] Step 7. The network node 16c (PCF 16e5) updates the Identifiable Non-3GPP Devices Control Data in network node 16d (UDR 16e3). If the device is connected, it adds the Device ID and also the PCF ID that is handling PDU sessions. If a device is disconnected from all of the PDU sessions that is handled by a network node 16c (PCF 16e5), the network node 16c (PCF 16e5) removes its ID from the List of PCF IDs associated with the Device ID in the Identifiable Non-3GPP Devices Control Data. Furthermore, if the device ID is not associated with any other PCF ID, the network node 16c (PCF 16e5) removes the Device ID from the Identifiable Non-3GPP Devices Control Data. If the network node 16c (PCF 16e5) finds any inconsistency in step 6, it updates the UDR information based on its own local data.

[0172] Step 8 — 9. The network node 16c (PCF 16e5) uses the SUPI and optionally the Device ID to obtain device QoS profile. The network node 16c (PCF 16e5) may apply changes to the PCC rules based on the QoS profile.

[0173] Step 10. The network node 16c (PCF 16e5) responds to the network node 16b (SMF 16e4). It may update the PCC rules based on the Device information obtained from network node 16d (UDR 16e3) to provide / remove QoS and charging differentiation.

[0174] Step 11 The network node 16b (SMF 16e4) may initiate PDU session modification to provide differentiated QoS.

[0175] PDU session establishment (FIG. 16):

[0176] If the UE / RG 22 decided to create a new PDU session to provide connection for the Device, the following procedure is used.

[0177] Step 1. Device 24 is connected to the UE 22.

[0178] Step 2. The UE 22 sends PDU session establishment request and includes the Device ID and the device address in the request. Step 3. The network node 16a (AMF 16el) includes the Device ID and device address in the SM Create Context request.

[0179] Step 4. The network node 16b (SMF 16e4) includes the Device ID and device address in the SM policy association establishment request.

[0180] Step 5. The same as in FIG. 15.

[0181] Step 6-7. As per current specification.

[0182] PDU session release:

[0183] The PDU session release may follow the current specification as described in Figure 4.3.4.2-1 of 3GPP TS 23.502 with the following differences:

[0184] In SM Policy Association Termination (Figure 4.3.4.2-1 of TS 23.502), the PCF updates the Identifiable Non-3GPP Devices Control Data in the same way as described in step 7 of Figure 2.7.1.3 (FIG. 15 above).

[0185] Alternative B2: UDM-based solution:

[0186] New data records:

[0187] This solution is based on new parameters in the UE subscription data as follows.

[0188] Table 4 (or Table 2.7.1-5) - UE subscription data

[0189] PDU session Modification:

[0190] FIG. 17 shows the steps of PDU session modification for restricting the number of devices.

[0191] Steps 1 — 2 : same as FIG. 15. Step 3: The network node 16b (SMF 16e4) requests to add (if the device is connected) or remove (if the device is disconnected) the device ID from the List of connected Device IDs in the UE context in SMF data. Nudr_UECM_Update is used.

[0192] Step 4: If network node 16b (SMF 16e4) requests to add a Device ID, the UDM 16e2 checks if the number of connected devices 24 with the inclusion of the new Device ID is more than the Maximum number of connected device or not. The network node 16d (UDM 16e2) can do this by querying UDR 16e3 as follows:

[0193] Alternative B2a: the network node 16d (UDM 16e2) queries the UDR 16e3 for the List of connected devices across all the PDU sessions for the SUPI. If a dedicated DNN is used for PDU sessions that carry device traffic, that DNN can be used by the UDM 16e2 to make the search space smaller.

[0194] Alternative B2b: the network node 16d (UDM 16e2) queries the UDR 16e3 for the smfRegistrations resource which includes the list of the PDU sessions established by the UE / SUPI.

[0195] The network node 16d (UDM 16e2) checks that the total number of devices connected across all established PDU sessions for the SUPI does not exceed the max number of devices 24 defined by the subscription data.

[0196] Step 5: If in the previous step the network node 16d (UDM 16e2) decided that the new device 24 cannot be added, the network node 16d (UDM 16e2) rejects the SMF request with a new cause code and the network node 16b (SMF 16e4) rejects the UE request for PDU session modification with a new cause code as per current standards and the rest of the steps are skipped.

[0197] Step 6. The network node 16b (SMF 16e4) includes the Device ID, device address, and indication of connection to the SM policy association request to network node 16c (PCF 16e5). The network node 16c (PCF 16e5) may query the UDR 16e3 with the SUPI and optionally the Device ID to obtain the device’s QoS parameters. The network node 16c (PCF 16e5) performs changes to PCC rules to add / remove differentiated QoS and charging for the device.

[0198] Step 7. As per current specifications.

[0199] PDU session establishment:

[0200] FIG. 18 shows an example call flow for controlling the number of devices:

[0201] Alternative B2 PDU session establishment.

[0202] Steps 1: The device 24 is connected Step 2. As per current standards. The UE 22 adds the Device ID and device address in the PDU session establishment request, which is relayed to network node 16b (SMF 16e4) by network node 16a (AMF 16el).

[0203] Step 3. The network node 16b (SMF 16e4) adds the Device ID in the PDU session registration as a new parameter.

[0204] Step 4. same as step 4 in FIG. 17.

[0205] Step 5. The network node 16c (UDM 16e2) indicates if the device is added or not to the Fist of connected Device IDs.

[0206] Step 6. If the network node 16c (UDM 16e2) rejects registering the device in the previous step (with a new cause code indicating that the maximum number of devices has been reached) the SMF 16e4 rejects the PDU session establishment request with a new cause code (or it initiates to release the PDU session) otherwise other steps in the PDU session establishment are performed.

[0207] Alternative B3: BSF-based solution

[0208] Extension of existing BSF information storing the PCF Id that serves a PDU Session

[0209] Description: Registers the tuple (UE address(es), SUPI, GPSI, MBS session ID, DNN, S-NSSAI, PCF address(es), PCF instance id, PCF Set ID, level of Binding, list of DevicelDs (new)) for a PDU Session.

[0210] Inputs, Required: [Required, if PCF registration is for a PDU Session], UE address(es), PCF address(es), DNN [Required, if PCF registration is for a PDU Session], S-NSSAI [Required, if PCF registration is for a PDU Session], MBS session ID as defined in TS 23.247

[0078] [Required, if PCF registration is for an MBS Session].

[0211] Inputs, Optional: GPSI, PCF instance ID and PCF Set ID, level of Binding (see clause 6.3.1.0 of TS 23.501 [2]), list of DevicelDs and per Device ID the device information(new) (only if PCF registration is for a PDU Session).

[0212] Service Operation name: Nbsf_Management_Update

[0213] Description: Replaces the list of UE address(es) for a PDU Session or replace PCF id or PCF address(es) for a PDU Session or for a UE 22, or replaces the list of DevicelDs for the PDU Session (new).

[0214] NOTE 1: For example, PCF-2 may update its PCF id when level of binding is

[0215] NF Instance and PCF-1 fails and PCF-2 is the new NF Instance handling the PDU Session or the UE.

[0216] Inputs, Required: Binding Identifier for the PDU Session. UE address can contain IP address / prefix or Ethernet address as defined in 3GPP TS 23.501.

[0217] NOTE 2: For support of time sensitive communication and time synchronization (as described in clause 5.28.3.2 of 3GPP TS 23.501) the UE address contains the DS-TT port MAC address for Ethernet type PDU Session.

[0218] Inputs, Optional: UE address(es), PCF id, PCF address(es). List of DevicelDs and per Device ID the device information (new).

[0219] Outputs, Required: Result indication.

[0220] Outputs, Optional: None.

[0221] PDU session establishment:

[0222] If the UE / RG decided to create a new PDU session to provide connection for the Device, the following procedure is used

[0223] FIG. 19 shows an example call flow for controlling the number of devices: Alternative Bl- PDU session establishment.

[0224] Step 1. The same as in FIG. 16.

[0225] Step 2. The UE / RG 22 sends PDU session establishment request and includes the Device ID and the device address in the request.

[0226] Step 3. The network node 16a (AMF 16el) includes the Device ID and device address in the SM Create Context request.

[0227] Step 4. The network node 16b (SMF 16e4) includes the Device ID and device address in the SM policy association establishment request.

[0228] Step 5. The network node 16c (PCF 16e5) uses Nbsf_Management_Register to register the PCFid serving the PDU Session, and also stores the device id and device address as part of the PDU session information in network node 16d (BSF).

[0229] Step 6-7. As per current specification.

[0230] PDU session release:

[0231] The PDU session release will follow the current specification as described in Figure 4.3.4.2-1 of TS 23.502 with the following differences:

[0232] In SM Policy Association Termination (Figure 4.3.4.2-1 of TS 23.502), the PCF 16e5 removes the PCF serving the PDU Session from BSF, and the list of devices is also removed as part of the cleanup of the PDU Session data in the BSF.

[0233] Alt.4: Selecting the same SMF 16e4: In this alternative the same SMF 16e4is selected for all the PDU sessions the required device identification (this can be done by, e.g., using a dedicated DNN for this feature).

[0234] The following enhancement is done to the subscription data:

[0235] Table 5 (or Table 2.7.1-5) - UE subscription data

[0236] All the procedures PDU session establishment / modification and release are the same as per current specification with the difference:

[0237] The SMF 16e4 obtains the Maximum number of Connected devices from UDR 16e3 during the PDU session establishment (Step 4 of Figure 4.3.2.2.1-1 in 3GPP TS 23.502)

[0238] The SMF 16e4 maintains the number of connected devices 24 to UE 22 that required identification and rejects the PDU session establishment / modification containing the device ID if the number of devices exceeds the maximum.

[0239] DHCPv6:

[0240] For all the provided alternatives, the PDU session request and PDU session modification can be replaced by the DHCPv6 messages in user plane sent between the SMF 16e4 and UE 22. The DHCPv6 messages contain the Device ID in the INTERFACE- ID option or REMOTE_ID option. The cause for rejection can be sent by SMF 16e4 via a new Status Codes for the DHCPv6 message. The device address is known by SMF 16e4 as it allocates the address as a DHCPv6 server based on the request from the UE 22. The UE 22 can indicate the device disconnection by sending a release message and including the device ID.

[0241] Some Examples

[0242] Embodiment Al. A method in a first network node 16 configured to communicate with a user equipment (UE 22) and / or at least one other network node, the UE 22 being configurable to communicate with one or more devices 24, the first network node 16 being a Policy Control Function (PCF) network node 16e5, the method comprising: determining a maximum number of devices and a list of device identifiers (IDs) associated with at least one of the one or more devices that are connected to the UE 22, the maximum number being kept in a second network node of the at least one other network node 16 as part of UE Policy Data, the second network node comprising a Unified Data Repository (UDR 16e3).

[0243] Embodiment A2. The method of Embodiment Al, wherein the method further includes: adding a device ID and a Policy Control Function (PCF) ID to a record.

[0244] Embodiment A3. The method of Embodiment A2, wherein one or both of: each PCF update the list based on information obtained by a Session Management Function (SMF 16e4) regarding connection of a new device or disconnection of a device 24; and at least one PCF 16e5 being configured to read and remove records from the list if the records are not consistent with a state associated with a user.

[0245] Embodiment Bl. A first network node 16 configured to communicate with a user equipment (UE 22) and / or at least one other network node 16, the UE 22 being configurable to communicate with one or more devices 24, the first network node 16 being a Policy Control Function (PCF) network node 16e5, the first network node 16 configured to, and / or comprising a radio interface and / or comprising processing circuitry configured to perform one or more steps corresponding to any one of Embodiments Al -A3.

[0246] Embodiment Cl. A method in a second network node 16 configured to communicate with a user equipment (UE 22) and / or at least one other network node 16, the UE 22 being configurable to communicate with one or more devices 24, the second network node 16 being a Unified Data Management (UDM) network node 16e2, the method comprising: creating a record in UE context in Session Management Function (SMF) data in the second network node that has a list of device identifiers (IDs) for each Packet Data Unit (PDU) session.

[0247] Embodiment C2. The method of Embodiment Cl, wherein an SMF network node 16e4 requests the UDM 16e2 to add and / or remove a device from the list, and the method further includes one or both of: 31 calculating a number of connected devices by obtaining the list of device IDs for one or more PDU sessions associated with the UE 22 and / or one or more other UEs 22; and if a number of device IDs exceeds a maximum number of connected devices 24, rejecting the SMF network node 16e4 request.

[0248] Embodiment DI. A second network node 16 configured to communicate with a user equipment (UE 22) and / or at least one other network node 16, the UE 22 being configurable to communicate with one or more devices 24, the second network node 16 being a Unified Data Management (UDM) network node 16e2, the second network node 16 configured to, and / or comprising a radio interface and / or comprising processing circuitry configured to perform one or more steps corresponding to any one of Embodiments Cl and C2.

[0249] Embodiment El. A method in a second network node 16 configured to communicate with a user equipment (UE 22) and / or at least one other network node 16, the UE 22 being configurable to communicate with one or more devices 24, the second network node 16 being a Unified Data Management (UDM) network node 16e2, an Session Management Function (SMF) network node 16e4 registering and / or updating a Packet Data Unit (PDU) session registration in the UDM network node 16e2 for at least one UE 22, the SMF network node 16e4 including device identifiers (IDs) of devices connected via the UE 22 within a registration / update request, a maximum number of devices being included in subscription data, the method comprising: accepting the SMF registration and / or update request if a total number of devices 24 connected via the UE 22 across established PDU Sessions from the UE 22 does not reach the maximum number of devices 24.

[0250] Embodiment Fl. A second network node 16 configured to communicate with a user equipment (UE 22) and / or at least one other network node 16, the UE 22 being configurable to communicate with one or more devices 24, the second network node 16 being a Unified Data Management (UDM) network node 16e2, an Session Management Function (SMF) network node 16e4 registering and / or updating a Packet Data Unit (PDU) session registration in the UDM network node 16e2 for a UE 22, the SMF network node 16e4 including device identifiers (IDs) of devices connected via the UE 22 within a registration / update request, a maximum number of devices being included in subscription data, the second network node 16 being configured to, and / or comprising a radio interface and / or comprising processing circuitry configured to perform one or more steps corresponding to Embodiment El.

[0251] Embodiment Gl. A method in a third network node 16 configured to communicate with a user equipment (UE 22) and / or at least one other network node 16, the UE 22 being configurable to communicate with one or more devices 24, the third network node 16 being a Binding Support Function (BSF) network node, the method comprising: creating a BSF record that contains a list of device identifiers (IDs) for each Packet Data Unit (PDU) session, a Policy Control Function (PCF) network node 16e5 requesting third network node 16 to add and / or remove a device 24 from the list.

[0252] Embodiment G2. The method of Embodiment Gl, wherein one or both of: each PCF network node 16e5 updates the list per PDU Session based on information obtained by a Session Management Function (SMF) network node 16e4 regarding connection of a new device or disconnection of a device 24; and the PCF network node 16e5 being configured to read and remove records from the list if not consistent with the state the PCF network node 16e5 has from a corresponding user.

[0253] Embodiment Hl. A third network node 16 configured to communicate with a user equipment (UE 22) and / or at least one other network node 16, the UE 22 being configurable to communicate with one or more devices 24, the third network node 16 being a Binding Support Function (BSF) network node, the third network node 16 being configured to, and / or comprising a radio interface and / or comprising processing circuitry configured to perform one or more steps corresponding to any one of Embodiments Gl and G2.

[0254] Embodiment II. A method in a fourth network node 16 configured to communicate with a user equipment (UE 22) and / or at least one other network node 16, the UE 22 being configurable to communicate with one or more devices 24, the method comprising: selecting a same Session Management Function (SMF) network node 16e4 to ensure that a number of connected devices does not exceed a maximum number of devices, the maximum number being a parameter stored in a Unified Data Management (UDM) network node 16e2 in subscription data.

[0255] Embodiment JI. A fourth network node 16 configured to communicate with a user equipment (UE 22) and / or at least one other network node 16, the UE 22 being configurable to communicate with one or more devices 24, the fourth network node 16 being configured to, and / or comprising a radio interface and / or comprising processing circuitry configured to perform one or more steps corresponding to Embodiment Hl.

[0256] STANDARDIZING THE PROPOSED SOLUTIONS

[0257] One or more examples described below provide non-limiting examples of how certain aspects of the proposed solutions could be implemented within the framework of a specific communication standard. In particular, the description below provide nonlimiting examples of how the proposed solutions could be implemented within the framework of a 3GPP TSG RAN standard. The changes described below are merely intended to illustrate how certain aspects of the proposed solutions could be implemented in a particular standard. However, the proposed solutions could also be implemented in other suitable manners, both in the 3 GPP Specification and in other specifications or standards.

[0258] First Change Request

[0259] * * * * pirst change * * * *

[0260] 6.1.x Identifiable Non-3GPP Devices Control Data

[0261] Identifiable Non-3GPP Devices Control Data is used by the PCF to limit the number of devices connected to the UE, for which the UE request device identification in 5GC by sending their corresponding Device ID.

[0262] The Maximum number of identifiable non-3GPP device ids can be configured by the operator and represents the maximum number of non-3GPP devices that are connected to a UE and require device identification.

[0263] During SM policy association establishment / modification, the PCF may read the Identifiable Non-3GPP Devices Control Data and check the number of simultaneously connected devices using the Device IDs and compare it with the Maximum number of identifiable non-3GPP device ids. If the number of connected devices is more than the Maximum number of identifiable non-3GPP device ids, then the PCF can reject the request.

[0264] Multiple PCFs that handle PDU Sessions of the UE update the Identifiable Non-3GPP Devices Control Data associated with the UE’s SUPI by adding the Device ID and also the PCF ID that is handling PDU sessions. If a device is disconnected from all of the PDU sessions that is handled by a PCF, the PCF removes its ID from the List of PCF IDs associated with the Device ID in the Identifiable Non-3GPP Devices Control Data. Furthermore, if the device ID is not associated with any other PCF ID, the PCF removes the Device ID from the Identifiable Non-3GPP Devices Control Data.

[0265] NOTE: In a deployment, an operator may choose to have a single PCF instance serving a UE. In case multiple PCFs are responsible for UE’s PDU Sessions, they can read and update the Identifiable Non-3GPP Devices Control Data in the UDR using the conditional requests with preconditions for the update of Identifiable Non-3GPP Devices Control Data. This mechanism using Etags is defined in Table 5.2.2.2-2 of TS 29.500

[0035] to ensure a proper update of UDR data in case of simultaneous access from different PCFs.

[0266] * * * * Second change * * * *

[0267] 6.2.1.3 Policy control subscription information management

[0268] The PCF may request subscription information at PDU Session establishment, PDU Session modification, during AM Policy Association Establishment procedure and during the UE Policy Association Establishment procedure.

[0269] The PCF may receive notifications on changes in the subscription information. Upon reception of a notification, the PCF shall make the policy control decisions necessary to accommodate the change in the subscription and shall update the SMF and / or the AMF if needed.

[0270] NOTE 1: How the PCF provisions / retrieves information related with policy control subscription data is defined in TS 23.501 [2].

[0271] The policy control subscription profile information provided by the UDR during the UE Policy Association Establishment procedure using Nudr service for Data Set "Policy Data" and Data Subset "UE context policy control data" is described in Table 6.2.1.3-1:

[0272] Table 6.2.1.3-1: UE context policy control subscription information

[0273] NOTE 2: S-NSSAI subscription information can be part of UE context policy control subscription information and Session Management Subscription data / Slice Selection Subscription data. UDR implementation and the provisioning system are responsible for keeping the consistency of this information when both Data Sets are stored in the same UDR. The provisioning system is responsible for keeping the consistency of this information when both Data Sets are stored in different UDRs.

[0274] The policy control subscription profile information provided by the UDR at PDU Session establishment, using Nudr service for Data Set "Policy Data" and Data Subset "PDU Session policy control data" is described in Table 6.2.1.3-2.

[0275] Table 6.2.1.3-2: PDU Session policy control subscription information

[0276] NOTE 3: Subscribed UE-Slice-MBR can be part of the Access and Mobility

[0277] Subscription data as described in clause 5.2.3.3.1 of TS 23.502 [3] and can be part of the PDU Session policy control subscription information as described in Table 6.2.1.3-2. UDR implementation and the provisioning system are responsible for keeping the consistency of this information when both Data Sets are stored in the same UDR. The provisioning system is responsible for keeping the consistency of this information when both Data Sets are stored in different UDRs.

[0278] Table 6.2.1.3-3: Remaining allowed usage subscription information The Allowed services may comprise any number of service identifiers allowed for the subscriber in the PDU Session.

[0279] The PCF maps those service identifiers into PCC rules according to local configuration and operator policies.

[0280] The Subscriber category may comprise any number of identifiers associated with the subscriber (e.g. gold, silver, etc.). Each identifier associates operator defined policies to the subscriber that belong to that category.

[0281] The Usage monitoring related information may comprise any number of usage monitoring control instances associated with the subscriber. In each usage monitoring control instance is mandatory to include the Monitoring key. The Reset period only applies to usage monitoring control instances that periodically reset the allowed usage (e.g. daily, monthly, etc.). If the Reset period is not specified, the usage monitoring control instance ends when the allowed data is consumed or when the End date is reached. The usage monitoring related information is used by the PCF instead of the respective information for the subscriber category.

[0282] The policy subscription profile may be extended with operator-specific information. Operator-specific extensions may be added both to any specific part of the policy control subscription information (e.g. to the subscriber category part), or as a new optional information block.

[0283] Handling of operator specific policy data by the PCF is out of scope of this specification in this release.

[0284] The latest list of PSIs and list of PSIs for the VPEMN ID(s) and its content delivered to the UE provided by the UDR during the UE Policy Association Establishment procedure using Nudr service for Data Set "Policy Data" and Data Subset "Policy Set Entry" is described in Table 6.2.1.3-4.

[0285] Table 6.2.1.3-4: Policy Set Entry The network slice specific policy control information is per S-NSSAI information stored by the UDR and updated by the PCF during PDU Session Establishment or Modification procedure using Nudr service for Data Set "Policy Data" and Data Subset "Network Slice Specific Control Data" is described in Table 6.2.1.3-5:

[0286] Table 6.2.1.3-5: Network slice specific policy control information

[0287] The policy control subscription profile information is per SUPI information, provided by the UDR using Nudr service for Data Set "Policy Data" and Data Subset " Access and Mobility policy control data" is described in Table 6.2.1.3-6: Table 6.2.1.3-6: Access and Mobility policy control subscription information

[0288] The 5G VN group specific policy control information is per group information stored by the UDR and updated by the PCF during PDU Session Establishment or Modification procedure using Nudr service for Data Set "Policy Data" and Data Subset "5G VN Group Specific Control Data" is described in Table 6.2.1.3-7:

[0289] Table 6.2.1.3-7: 5G VN Group specific policy control information

[0290]

[0291] The Identifiable Non-3GPP Devices Control Data is per SUPI information stored in the UDR and updated by the PCF using Nudr service for Data Set "Policy Data" and Data Subset " Identifiable Non-3GPP Devices Control Data " is described in Table 6.2.1.3-8: Table 6.2.1.3-8: Identifiable Non-3GPP Devices Control Data

[0292] * * * * Second change * * * * changes * * * * Second Change Request

[0293] * * * * pirst change * * * *

[0294] 4.15.6.10 Application guidance for URSP determination

[0295] This clause describes the procedures to allow an AF to provide guidance for URSP determination to 5G system via NEF. The AF may belong to the operator or to an external party. The PCF may be in the Home PLMN, as it is the PCF that determines the URSP for the UE, or in the VPLMN and then the Application guidance for URSP determination is provided to the PCF in the HPLMN via the PCF of the VPLMN. The PCF in the VPLMN translates the Service Parameters values provided by the AF for inbound roamer to values applicable to the HPLMN, e.g., S-NSSAI as described in TS 23.503

[0020] .

[0296] NOTE 1: The operator can negotiate with external party (typically a Corporate represented by an AF) dedicated DNN(s) and / or S-NSSAI(s) for the traffic of UE(s) of this external party. UE(s) of the external party can be identified by a group identifier.

[0297] The guidance for URSP determination may be used to provide 5GC with guidance for the URSPs depending on the UE location. This is further described in TS 23.548

[0074] . For providing guidance for URSP determination, the procedure defined in clause 4.15.6.7 is performed with the following considerations:

[0298] 1) Service Description indicates an AF Identifier.

[0299] 2) Service Parameters.

[0300] Information on the AF guidance for URSP determination which consists of a list of URSP rules that associate an application traffic descriptor with requested features for the candidate PDU sessions the application traffic may use:

[0301] - An application traffic descriptor, whose definition corresponds to that of the URSP Traffic Descriptors (as defined for the URSP rule in TS 23.503

[0020] Table 6.6.2.1-2). When AF provides application guidance for URSP determination for PIN, the application traffic descriptor shall include PIN ID. When AF provides application guidance for URSP determination for non-3GPP devices behind UE / 5G-RG, the application traffic descriptor shall include Connectivity Group ID.

[0302] - one or more sets of Route selection parameters, each parameter may correspond to:

[0303] (DNN, S-NSSAI). This may be provided by the AF or determined by the NEF based on the AF Identifier when it is not provided by the AF and the AF provides only one instance of AF guidance for URSP determination. In the case of AF guidance for URSP determination for PIN or for non-3GPP devices behind UE, this shall be provided by the AF.

[0304] - Requested PDU session type.

[0305] - a default Route selection precedence value to be used for the application traffic when Route selection precedence with a corresponding spatial validity condition is not provided.

[0306] - Route selection precedence with a corresponding spatial validity condition that indicates where the Route selection parameters apply. This may correspond to a geographical area (e.g., a civic address or shapes).

[0307] NOTE 2: The different sets of Route selection parameters indicate different sets of PDU Session information (DNN, S-NSSAI) that can be associated with applications matching the application traffic descriptor. Each set is meant to apply for a specific (set of) spatial validity condition. Each set is associated with a Route selection precedence to cope with the case where multiple spatial validity conditions overlap.

[0308] - VPLMN ID(s) that indicates the PLMN(s) where the AF guidance on URSP determination and all its RSD(s), applies.

[0309] If the AF provides a geographical area as spatial validity condition, it is up to the NEF to transform this information into 3GPP identifiers (e.g., TAI(s)).

[0310] An AF sets the Requested PDU session type if the AF requests to change the PDU session type of the URSP rules.

[0311] NEF may, based on local configuration, complement missing service parameters.

[0312] Additionally, based on operator's local policy, NEF may request UDM for service specific authorization for the service parameters for an individual UE (e.g., to authorize the Corporate or MTC provider represented by the AF and the requested DNN, S-NSSAI for the related UE) before storing the service parameters into the UDR. If the request is targeting a group of UEs, NEF may also request UDM for service specific authorization for the group related data (see table 4.15.6.3b-l), i.e. the DNN, S-NSSAI associated to the group. If the request is targeting any UE (all UEs), NEF authorizes the request based on local policy (e.g., based on AF Id) without requesting for any service specific authorization from UDM. NEF requests UDM for service specific authorization for the service parameters provisioned via the Nudm_ServiceSpecificAuthorisation_Create service operation as defined in clause 4.15.6.7a. If a group of UEs or any UE is requested, each individual UE authorization is performed at a later stage by PCF.

[0313] NOTE 3: The operator needs to ensure the consistency between the group related data and the UE group members subscription data, i.e. if a group is authorized for a given DNN / S-NSSAI as defined in the group related data, it needs to be ensured that all UE members of the group are provisioned with such DNN / S- NSSAI, since no individual UE check is required to be done by NEF against UDM.

[0314] NOTE 4: AF guidance for application traffic is not related with 5G VN group.

[0315] 3) The Target UE identifier(s) that may be a specific UE, identified by a GPSI, or a group of UE(s), identified by an Extemal-Group-ID, or any UE of the PLMN of the NEF, or the PLMN ID(s) of inbound roamers that the AF request may be associated with.

[0316] The information on the AF guidance for URSP determination provided by the AF may be associated to: a) UEs of the PLMN (of the NEF) when roaming in other PLMNs. In this case, the AF guidance for URSP determination targets to a specific UE, a group of UEs or any UE of the PLMN. In this case, the AF guidance for URSP determination associated to a specific UE, a group of UEs or any UE of the PLMN shall be also associated with the corresponding VPLMN(s) where the AF guidance for URSP determination shall be applied if the UE roams to that VPLMN(s). The list of VPLMN ID(s) is included in the Service Parameters. b) An inbound roamer from one or more PLMN(s). In this case, the AF targets the AF guidance for URSP determination only with the inbound roamers of corresponding PLMN(s). The PLMN ID is included in the Service Parameters.

[0317] NOTE 5: Wildcarding of "PLMN ID of inbound roamers" will be handled by stage 3.

[0318] 4) Subscription to events.

[0319] The AF may subscribe to notifications about the outcome of the UE Policies delivery due to application guidance for URSP determination.

[0320] The usage of the AF guidance for application traffic is described in clause 6.6 of

[0321] TS 23.548

[0074] , * * * * Second change * * * *

[0322] 5.2.12.2.1 General

[0323] The operations defined for Nudr_DM service use following set of parameters defined in this clause:

[0324] - Data Set Identifier: uniquely identifies the requested set of data within the UDR (see clause 4.2.5).

[0325] - Data Subset Identifier: it uniquely identifies the data subset within each Data Set Identifier. As specified in the procedures in clause 4, e.g., subscription data can consist of subsets particularised for specific procedures like mobility, session, etc.

[0326] - Data Keys defined in Table 5.2.12.2.1-1

[0327] For Nudr_DM_Subscribe and Nudr_DM_Notify operations:

[0328] - The Target of Event Reporting is made up of a Data Key and possibly a Data Sub Key both defined in Table 5.2.12.2.1-1. When a Data Sub Key is defined in the table but not present in the Nudr_DM_Subscribe this means that all values of the Data Sub Key are targeted.

[0329] - The Data Set Identifier plus (if present) the (set of) Data Subset Identifier(s) corresponds to a (set of) Event ID(s) as defined in clause 4.15.1

[0330] An NF Service Consumer may include an indicator when it invokes Nudr_DM Query / Create / Update service operation to subscribe the changes of the data, to avoid a separate Nudr_DM_Subscribe service operation.

[0331] Depending on the use case, it is possible to use a Data Key and / or one or multiple Data sub keys to further identify the corresponding data, as defined in Table 5.2.12.2.1-1 below.

[0332] Table 5.2.12.2.1-1: Data keys Subscription Data

[0333] (see clause 5.2.3.3.1)

[0334]

[0335]

[0336] The content of the UDR storage for (Data Set Id= Application Data, Data Subset Id = AF Trafficinfluence request information) is specified in clause 5.6.7, Table 5.6.7- 1 of TS 23.501 [2]. This information is written by the NEF and read by the PCF(s). PCF(s) may also subscribe to changes onto this information. changes * * * *

[0337] FIG. 20 illustrates a system 100 according to an embodiment. In the embodiment shown, system 100 includes a gateway 102 (e.g., a residential gateway, a UE, or other gateway) that is operable to communicate with a data network 110 (e.g., a public data network such as the Internet and / or a private data network) via a core network 107 (e.g. a 3GPP 5G core network or other core network). In the embodiment shown, gateway 102 communicates with network functions (NFs) included in core network 107 via a radio access network (RAN) 105. Advantageously, gateway 102 is further configured to provide a gateway service to other devices (e.g., devices that do not have the credentials to use core network 107) so that the other devices (i.e., devices 101 and 103 in the embodiment shown) can communicate with data network 110 and / or core network 107. In one embodiment, devices 101 and 103 may communicate with gateway 102 using a short range radio link, such as, for example, a Bluetooth(R) link or a WiFi(R) link or other short range radio technology or wired technology.

[0338] As noted above, there is currently an issue because, if gateway 102 seeks to add two or more non-3GPP device identifiers (IDs) to a PDU session, gateway 102 may transmit to a network function (NF) in core network 107 a request message (e.g., PDU SESSION MODIFICATION REQUEST message) containing the plurality of device IDs and may, in response, receive a reject message. In such a scenario, the gateway will not have enough information to determine which of the multiple device IDs are authorized and which are not. To solve this issue, the NF may respond to the PDU session request message by transmitting to the gateway a message (e.g., PDU SESSION MODIFICATION REJECT message or PDU SESSION MODIFICATION COMMAND message) comprising information indicating (explicitly or implicitly) the rejected device IDs. In this way, the gateway will have sufficient information to determine which device IDs are authorized and which are not. More specifically, in one embodiment, a new IE can be introduced in the PDU SESSION MODIFICATION REJECT message and this new IE can be used for providing the information indicating the rejected device IDs. This new IE together with the specific 5GSM cause code enables the gateway to obtain information about which non-3GPP device IDs are rejected (e.g., not authorized) and shall not add them in a following PDU session modification procedure.

[0339] In another embodiment, a new IE can be introduced in the PDU SESSION MODIFICATION COMMAND message and this new IE can be used for providing the information indicating the rejected device IDs.

[0340] As also noted above, another problem is that, after the gateway has added a non- 3GPP device connected behind the gateway on a PDU session, it might be the case that the non-3GPP device identifier for the non-3GPP device is removed due to, for example, a subscription change in a UDR of core network 107. In the current 3GPP specifications, however, it is not specified how the gateway can be informed about change. To solve this issue, the SMF may transmit to the gateway a message (e.g., PDU SESSION MODIFICATION COMMAND message) comprising information indicating (explicitly or implicitly) the device IDs that are no longer authorized. In this way, the gateway will have sufficient information to determine which device IDs are authorized and which are not. Additional Embodiments

[0341] FIG. 21 is a message flow diagram illustrating an embodiment. In the example shown in FIG. 21, gateway (GW) 102 first establishes a PDU session according to known PDU session establishment procedures. Next, GW 102 seeks to add two or more non- 3GPP device IDs to the established PDU session. GW 102 accomplishes this by transmitting to core network (CN) 107 a session modification request message m203, which may be a PDU SESSION MODIFICATION REQUEST message. Message m203 includes, among other things, the plurality of device IDs that GW 102 seeks to add to the PDU session. Non-3GPP device connection information about an IP address / port range etc. may also be included in message m203.

[0342] Message m203 is received by an NF 202 within CN 107. In this example, NF 202 is a Session Management Function (SMF). After receiving message m203, SMF 202 sends to an NF in CN 107 a message m205 comprising the non-3GPP device IDs that were included in message m203. In this example, NF 202 is a Policy Control Function (PCF). Message m205 may be an HTTP POST request message, such as an Npcf_SMPolicyControl_Update request message. After receiving message m205, PCF 204 transmits to an NF 206 (e.g., a UDR) in CN 107 a message m207 comprising a subscription identifier (e.g., a Subscription Permanent Identifier (SUPI)) and a data set identifier indicating that PCF 204 seeks to obtain subscription information associated with the subscription identifier. Message m207 may be Nudr_DM_Query message or an Nudr_DM_Update request message. Although not shown in FIG. 21, the subscription identifier included in message m207 may have been included in message m203 and message m205. Hence, SMF 202 may obtain the subscription identifier from message m203 and PCF 204 may obtain the subscription identifier from message m205.

[0343] In response to receiving message m207, UDR 206 uses the subscription identifier included in message m207 to obtain requested subscription information associated with the subscription identifier. In this example, the subscription information includes a list of authorized non-3GPP device IDs for GW 102. After obtaining the subscription information, UDR 206 responds to message m207 by transmitting to PCF 204 a response message m209 comprising the list of authorized non-3GPP device IDs.

[0344] After receiving message m209 from UDR 206, PCF 204 transmits to SMF 202 a response message m211 responsive to message m205. In one embodiment, message m211 includes the list of device IDs that are included in message m209 or a subset of the list of device IDs that are included in message m209. But in another embodiment, message m211 includes a list of unauthorized device IDs.

[0345] For example, in one embodiment, in response to receiving response message m209, PCF 204 compares the non-3GPP device identifiers for the GW with the ones received from the SMF, and gets the information that one or more of the non-3GPP device identifiers are not-authorized. That is, in one embodiment, for example, in response to receiving message m209, PCF 204, for each device ID included in the list of device IDs included in message m205 from SMF 202, determines whether the device ID is included in the list of device IDs included in message m209 from UDR 206. If a device ID included in the list from message m205 is not included in the list from message m209, then that device ID is an unauthorized device ID. Accodingly, in this way, PCF 204 may determine which device IDs included in the list from SMF 202 are authorized device IDs and which are not.

[0346] In another embodiment, in response to receiving message m209, PCF 204, determines the device IDs that are included in the list of device IDs in message m205 and also in the list of authorized devices in message m209. This set of device IDs is then the set of device IDs included in message m211. Hence, in this embodiment, message m211 may include a subset of the list of device IDs that are included in message m209.

[0347] In any of the above cases, response message m211 may be an HTTP response message, such as an Npcf_SMPolicyControl_Update response message.

[0348] After receiving response message m211, SMF 202, transmits to GW 102 a response message m213 responsive to request message m203. In one embodiment, response message m213 includes the list of authorized device IDs (i.e. the list of device IDs that are included in message m209). But in another embodiment, response message m213 includes a list of unauthorized device IDs. In the embodiment in which response message m211 includes the list of unauthorized device IDs, response message m213 will also include the list of unauthorized device IDs.

[0349] In the embodiment in which response message m211 includes a list of authorized device IDs, then, in one embodiment, response message m213 includes the list of authorized device IDs, but in another embodiment, response message m213 includes a list of unauthorized device IDs. For example, in this latter case, in response to receiving message m211, SMF 202, for each device ID included in the list of device IDs included in message m203 from GW 102, determines whether the device ID is included in the list of device IDs included in message m211 from PCF 204. If a device ID included in the list from message m203 is not included in the list from message m211, then that device ID is an unauthorized device ID. Accodingly, in this way, SMF 204 may determine which device IDs included in the list from GW 102 are authorized device IDs and which are not.

[0350] In any event, message m213 includes information indicating which device IDs from the list of device IDs included in message m203 are authorized and which are not. More specifically, when message m213 includes the list of unauthorized device IDs, message m213 indicates explicitly the device IDs that are not authorized and indicates implicitly the device IDs that are authorized — i.e., any device ID included in the list contained in message m203 that is not included in the list of unauthorized device IDs is, therefore, an authorized device ID. Likewise, when message m213 includes the list of authorized device IDs, message m213 indicates implicitly the device IDs that are unauthorized — i.e., any device ID included in the list contained in message m203 that is not included in the list of authorized device IDs is, therefore, an unauthorized device ID.

[0351] In one embodiment, assuming one or more of the device IDs included in the list of device IDs included in message m203 are not authorized, then response message m213 may be a PDU SESSION MODIFICATION REJECT message with a specific 5GSM cause code and with an IE containing the list of device IDs. This IE may be named the “Non-3GPP device connection notify” IE or the “Non-3GPP device connection failure” IE.

[0352] In another embodiment, assuming one or more of the device IDs included in the list of device IDs included in message m203 are not authorized, then response message m213 may be a PDU SESSION MODIFICATION COMMAND message with an IE containing the list of device IDs. This IE may be named the “Non-3GPP device connection notify” IE or the “Non-3GPP device connection failure” IE.

[0353] After receiving response message m213, for each device behind GW 102 that is indicated as being unauthorized by the information in message m213, GW 102 “disconnects” the device — i.e., GW 102 ceases providing gateway services to the device so that the device can no longer access CN 107. For instance, when message m213 includes a list of unauthorized device IDs, for each device identified by a device ID included in the list of unauthorized device IDs, GW 102 disconnects the device. And when message m213 does not include a list of unauthorized device IDs, but instead a list of all authorized device IDs, then, for each device connected to GW that is not identified by a device ID included in the list of all authorized device IDs, GW disconnects the device. Further, when message m213 does not include a list of unauthorized device IDs, but instead a list of a subset of all authorized device IDs, then, for each device connected to GW that is not identified by a device ID included in the list of the subset of authorized device IDs and that is identified by a device ID included in the list included in message m203, GW disconnects the device.

[0354] Then the network-requested PDU session modification procedure continues. That is, for example, if the network sends PDU SESSION MODIFICATION COMMAND with a list of unauthorized device IDs (or otherwise indicating the unauthorized device IDs), the GW will disconnect the devices identified by the unauthorized device IDs and handle the PDU SESSION MODIFICATION COMMAND as normally— i.e., the GW will apply actions associated with other IES of the PDU SESSION MODIFICATION COMMAND and then send the PDU SESSION MODIFICATION COMPLETE message m215.

[0355] FIG. 22 is a message flow diagram illustrating another embodiment. In the example shown in FIG. 22, gateway 102 has established a PDU session, a list of non- 3GPP device identifiers connecting to GW 102 have been added to one or ore PDU sessions, and PCF 204 has stored the device IDs that have been added to the PDU session(s) and has subscribed to UDR 206 to be notified whenever a device ID for GW 102 is removed from GW 102’ s subscrliption information.

[0356] In this scenarion, in response to one or more of the non-3GPP device ID being removed from the GW in UDR 206, UDR 206 sends to PCF 204 a notificaiton message m3O3. The notification message m3O3 includes a list of authorized device IDs for GW 102.

[0357] After receiving message m3O3 from UDR 206, PCF 204 transmits to SMF 202 a notification message m305. In one embodiment, notification message m305 includes the list of device IDs that are included in message m3O3 or a subset of the list of device IDs that are included in message m3O3. But in another embodiment, message m305 includes a list of unauthorized device IDs.

[0358] For example, in one embodiment, in response to receiving notification message m3O3, PCF 204 compares the non-3GPP device identifiers for the GW with the stored device IDs assocaited with GW 102, and gets the information that one or more of the stored non-3GPP device identifiers are not-authorized. That is, in one embodiment, for example, in response to receiving message m3O3, PCF 204, for each stored device ID associated with GW 102, determines whether the device ID is included in the list of device IDs included in message m3O3 from UDR 206. If such a stored device ID is not included in the list from message m3O3, then that device ID is an unauthorized device ID. Accodingly, in this way, PCF 204 may determine which device IDs that GW 102 has added to one of its PDU sessions are authorized device IDs and which are not.

[0359] In another embodiment, in response to receiving message m3O3, PCF 204, determines the stored device IDs associated with GW 102 that are in the list of authorized devices in message m3O3. This set of device IDs is then the set of device IDs included in message m305. Hence, in this embodiment, message m305 may include a subset of the list of device IDs that are included in message m3O3.

[0360] In any of the above cases, message m305 may be an HTTP message, such as an Npcf_SMPolicyControl_UpdateNotify message or an Npcf_SMPolicyControl_Update Response message.

[0361] After receiving message m305, SMF 202, transmits to GW 102 a message m307 that includes the list of device IDs that is included in message m305. In one embodiment, message m307 is a PDU SESSION MODIFICATION COMMAND message with an IE containing the list of device IDs. After receiving message m307, for each device behind GW 102 that is indicated as being unauthorized by the information in message m307, GW 102 “disconnects” the device — i.e., GW 102 ceases providing gateway services to the device so that the device can no longer access CN 107.

[0362] Then the network-requested PDU session modification procedure continues.

[0363] FIG. 23 is a flow chart illustrating a process 400, according to an embodiment, that is performed by a gateway for providing at least a first device (e.g., a first non-3GPP device) and a second device (a second non-3GPP device) with access to a core network. Process 400 may begin in step s402. Step s402 comprises transmitting a session related message (e.g., PDU session modification request) comprising: a first device identifier (ID) for identifying the first device and a second device ID for identifying the second device. Step s404 comprises receiving a response message responsive to the session related message, wherein the response message responsive to the session related message comprises information indicating: i) whether the first device ID is an authorized device ID and ii) whether the second device ID is an authorized device ID.

[0364] FIG. 24 is a flow chart illustrating a process 500, according to an embodiment, that is performed by a NF of CN 107 (e.g., the SMF or the PCF). Process 500 may begin in step s502. Step s502 comprises receiving a first message comprising: a first device identifier (ID) for identifying a first device behind a gateway and a second device ID for identifying a second device behind the gateway. Step s504 comprises transmitting a response message responsive to the first message, wherein the response message responsive to the first message comprises information indicating: i) whether the first device ID is an authorized device ID and ii) whether the second device ID is an authorized device ID.

[0365] FIG. 25 is a flow chart illustrating a process 600, according to an embodiment, that is performed by a gateway for providing at least a first device (e.g., a first non-3GPP device) with access to a core network. Process 600 may begin in step s602. Step s602 comprises transmitting a session related message (e.g., PDU session modification request) comprising: a first device identifier (ID) for identifying the first device. Step s604 comprises, after transmitting the session related message, receiving a first message comprising information indicating that the first device ID is an authorized device ID. Step s606 comprises, after receiving the first message, receiving a second message (e.g., PDU session modification command) comprising information indicating that the first device ID is no longer an authorized device ID. FIG. 26 is a flow chart illustrating a process 700, according to an embodiment, that is performed by a NF of CN 107. Process 700 may begin in step s702. Step s702 comprises, after a gateway has transmitted a session related message comprising a first device identifier (ID) for identifying a first device behind the gateway, receiving a first message comprising first information indicating that the first device ID is no longer an authorized device ID. Step s704 comprises, after receiving the first message, transmitting a second message comprising the first information indicating that the first device ID is no longer an authorized device ID or second information indicating that the first device ID is no longer an authorized device ID.

[0366] FIG. 27 is a block diagram of a network node 800, according to some embodiments, which can be used to implement any one or more of the network function (NFs) described herein, such as, for example, SMF 202, PCF 204, and / or UDR 206. In embodiments where an NF consists of software, network node 800 may run the NF or execute a virtual machine that runs the NF. As shown in FIG. 27, network node 800 may comprise: processing circuitry (PC) 802, which comprises one or more processors (P) 855 (e.g., one or more general purpose microprocessors and / or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like), which processors may be co-located in a single housing or in a single data center or may be geographically distributed (e.g., network node 800 may be a distributed, cloud computing system comprising two or more computers or it may be a monolithic computing system consisting of a single computer); at least one network interface 848 (e.g., a physical interface or air interface) comprising a transmitter (Tx) 845 and a receiver (Rx) 847 for enabling network node 800 to transmit data to and receive data from other nodes connected to network 107 to which network interface 848 is connected (physically or wirelessly) (e.g., network interface 848 may be coupled to an antenna arrangement comprising one or more antennas for enabling network node 800 to wirelessly transmit / receive data); and a data storage unit (a.k.a., “data storage system”) 808, which may include one or more non-volatile storage devices and / or one or more volatile storage devices. In embodiments where PC 802 includes a programmable processor, a computer readable storage medium (CRSM) 842 may be provided. CRSM 842 may store a computer program (CP) 843 comprising computer readable instructions (CRI) 844. CRSM 842 may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the CRI 844 of computer program 843 is configured such that when executed by PC 802, the CRI causes network node 800 to perform steps described herein (e.g., steps described herein with reference to the flow charts). In other embodiments, network node 800 may be configured to perform steps described herein without the need for code. That is, for example, PC 802 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and / or software.

[0367] FIG. 28 is a block diagram of GW 102, according to some embodiments. As shown in FIG. 28, GW 102 may comprise: processing circuitry (PC) 902, which comprises one or more processors (P) 955 (e.g., one or more general purpose microprocessors and / or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like); communication circuitry 948, which is coupled to an antenna arrangement 949 comprising one or more antennas and which comprises a transmitter (Tx) 945 and a receiver (Rx) 947 for enabling GW 102 to transmit data and receive data (e.g., wirelessly transmit / receive data); and a data storage unit (a.k.a., “data storage system”) 908, which may include one or more non-volatile storage devices and / or one or more volatile storage devices. In embodiments where PC 902 includes a programmable processor, a computer readable storage medium (CRSM) 942 may be provided. CRSM 942 may store a computer program (CP) 943 comprising computer readable instructions (CRI) 944. CRSM 942 may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the CRI 944 of computer program 943 is configured such that when executed by PC 902, the CRI causes GW 102 to perform steps described herein (e.g., steps described herein with reference to the flow charts). In other embodiments, GW 102 may be configured to perform steps described herein without the need for code. That is, for example, PC 902 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and / or software.

[0368] Summary of Various Embodiments

[0369] Scenario 1 - from Gateway perspective

[0370] Al. A method performed by a gateway (e.g., a UE) for providing at least a first device (e.g., a first non-3GPP device) and a second device (a second non-3GPP device) with access to a core network, the method comprising: transmitting a session related message (e.g., PDU session modification request) comprising: a first device identifier (ID) for identifying the first device and a second device ID for identifying the second device; and receiving a response message responsive to the session related message, wherein the response message responsive to the session related message comprises information indicating: i) whether the first device ID is an authorized device ID and ii) whether the second device ID is an authorized device ID.

[0371] A2. The method of embodiment Al, wherein the information indicating: i) whether the first device ID is an authorized device ID and ii) whether the second device ID is an authorized device ID is a list of unauthorized device IDs; or the information indicating: i) whether the first device ID is an authorized device ID and ii) whether the second device ID is an authorized device ID is list of authorized device IDs.

[0372] A3. The method of embodiment Al or A2, wherein for each device ID included in the session related message that is an unauthorized device ID, the response message comprises the device ID; or for each device ID included in the session related message that is an authorized device ID, the response message comprises the device ID.

[0373] A4. The method of embodiment Al, A2, or A3, wherein the session related message is a first session modification request message, the response message comprises information indicating that: i) the first device ID is an authorized device ID and ii) the second device ID is an unauthorized device ID, and the method further comprises, as a result of determining that the response message comprises information indicating that the second device ID is an unauthorized device ID, disconnecting a device identified by the second device ID.

[0374] A5. The method of embodiment A4, wherein the method further comprises, as a result of determining that the response message comprises information indicating that the second device ID is an unauthorized device ID, transmitting a second session modification request message comprising the first device ID and not comprising the second device ID.

[0375] A6. The method of any one of embodiments A1-A5, wherein the response message is a session modification command message or a session modification reject message.

[0376] A7. The method of any one of embodiments A1-A6, wherein the gateway is a user equipment (UE), or the gateway is a residential gateway (e.g., a 5G-RG).

[0377] Scenario 1 - from core network NF perspective

[0378] Bl. A method performed by a network function, NF, of a core network, the method comprising: receiving a first message comprising: a first device identifier (ID) for identifying a first device behind a gateway and a second device ID for identifying a second device behind the gateway; and transmitting a response message responsive to the first message, wherein the response message responsive to the first message comprises information indicating: i) whether the first device ID is an authorized device ID and ii) whether the second device ID is an authorized device ID.

[0379] B2. The method of embodiment Bl, wherein the NF is a Session Management Function (SMF), the first message is a session modification request message, and the response message is a session modification command message or a session modification reject message.

[0380] B3. The method of embodiment Bl, wherein the NF is a Policy Control Function (PCF).

[0381] B4. The method of embodiment Bl or B3, wherein the method further comprises: after receiving the first message, transmitting a third message requesting subscription information for the gateway; and receiving a response message responsive to the third message, wherein the response message comprises a list of authorized device IDs.

[0382] B5. The method of embodiment B4, wherein the method further comprises using the list of authorized device IDs to generate a list of unauthorized device IDs, and the information indicating: i) whether the first device ID is an authorized device ID and ii) whether the second device ID is an authorized device ID is the generated list of unauthorized device IDs.

[0383] B6. The method of embodiment B5, wherein using the list of authorized device IDs to generate a list of unauthorized device IDs comprises: determining that the first device ID is not included in the list of authorized device

[0384] IDs; and 1 as a result of determining that the first device is not included in the list of authorized device IDs, adding the first device ID to the list of unauthorized device IDs.

[0385] Scenario 2 - from Gateway perspective

[0386] Cl. A method performed by a gateway for providing at least a first device (e.g., a first non-3GPP device) with access to a core network, the method comprising: transmitting a session related message (e.g., PDU session modification request) comprising: a first device identifier (ID) for identifying the first device; after transmitting the session related message, receiving a first message comprising information indicating that the first device ID is an authorized device ID; and after receiving the first message, receiving a second message (e.g., PDU session modification command) comprising information indicating that the first device ID is no longer an authorized device ID.

[0387] C2. The method of embodiment Cl, wherein the method further comprises, as a result of determining that the second message comprises information indicating that the first device ID is no longer an authorized device ID, disconnecting a device identified by the first device ID.

[0388] C3. The method of embodiment C2, wherein the session related message is a first session modification request message, and the method further comprises, as a result of determining that the second message comprises information indicating that the first device ID is no longer an authorized device ID, transmitting a second session modification request message, and the second session modification request message does not include the first device ID.

[0389] Scenario 2 - from core network NF perspective

[0390] DI. A method performed by a network function, NF, of a core network, the method comprising: after a gateway has transmitted a session related message comprising a first device identifier (ID) for identifying a first device behind the gateway, receiving a first message comprising first information indicating that the first device ID is no longer an authorized device ID; and after receiving the first message, transmitting a second message comprising the first information indicating that the first device ID is no longer an authorized device ID or second information indicating that the first device ID is no longer an authorized device ID.

[0391] D2. The method of embodiment DI, wherein the first information indicating that the first device ID is no longer an authorized device ID is a list of authorized device IDs, and the first device ID is not included in the list of authorized device IDs.

[0392] D3. The method of embodiment D2, wherein the second message comprises each device ID included in the list of authorized device IDs or a subset of the device IDs included in the list of authorized device IDs.

[0393] D4. The method of embodiment D2, wherein the second message comprises the second information indicating that the first device ID is no longer an authorized device ID, the second information is a list of unauthorized device IDs, and the first device ID is included in the list of unauthorized device IDs.

[0394] El. A computer program (943) comprising instructions (944) which when executed by processing circuitry (902) of a gateway causes the gateway to perform the method of any one of embodiments A1-A5 or C1-C3.

[0395] E2. A computer program (843) comprising instructions (844) which when executed by processing circuitry (802) of a network node causes the network node to perform the method of any one of embodiments B 1-B6 or D1-D4.

[0396] E3. A carrier containing the computer program of embodiment El or E2, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium (842, 942).

[0397] While various embodiments are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[0398] As used below transmitting a message “to” or “toward” an intended recipient encompasses transmitting the message directly to the intended recipient or transmitting the message indirectly to the intended recipient (i.e., one or more other nodes are used to relay the message from the source node to the intended recipient). Likewise, as used below receiving a message “from” a sender encompasses receiving the message directly from the sender or indirectly from the sender (i.e., one or more nodes are used to relay the message from the sender to the receiving node). Further, as used below “a” means “at least one” or “one or more.” Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.

[0399] References:

[0400] [1] 3GPP TS 23.501 (2024-12): Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 19).

[0401] [2] 3GPP TS 23.503 (2024-12): Technical Specification Group Services and System Aspects; Policy and charging control framework for the 5G System (5GS); Stage 2 (Release 19).

[0402] [3] InterDigital Inc., “New WID on User Identities and Authentication Architecture,” 3GPP Document No. SP-240971, 3GPP TSG SA Meeting #104, Shanghai, China, June 18 - 21, 2024.

[0403] [4] 3GPP S2-2411269

[0404] [5] 3GPP S2-2411020

[0405] [6] 3GPP S2-2412780

[0406] Additional Description - 3 GPP Change Request

[0407] Title of Change Request: Non-3GPP device identifier rejection

[0408] Reason for Change

[0409] As states in 23.503:

[0410] If the Non-3GPP Device Identifier is not included within the Non-3GPP Device Identifier Information as specified in clause 5.2.12.2.1 of TS 23.502 [3] for the UE, then the PCF indicates to the SMF that the corresponding Non-3GPP Device Identifier is not available for the UE. In case ofPDU Session Modification, the PCF shall reject PDU Session Modification. When PDU Session Modification is rejected, a cause code is used to notify the UE that the Non-3GPP Device Identifier is not available for the UE.

[0411] When the identifiers of one or more non-3GPP devices connecting behind the UE or 5G-RG are not included in the subscription data in UDR, the SMF shall be rejected the request to add these non-3GPP device connecting behind the UE or 5G-RG.

[0412] There are 2 alternatives for SMF to reject the PDU SESSION MODIFICATION REQUEST message:

[0413] Alt-1: SMF includes the 5GSM cause code about the non-3GPP device identifier not available / authorized in the PDU SESSION MODIFICATION REJECT message; Alt-2: SMF includes an IE about the non-3GPP device identifier not available / subscribed.

[0414] The Alt-2 is preferred since:

[0415] In Alt-1, the whole PDU session modification is rejected, the UE might include other information which needs to be modified with the change of non-3GPP device identifier(s), if there is no issue on the change of the other information, the UE has to trigger another PDU session modification procedure again for the change of the other information;

[0416] More than one non-3GPP device identifiers can be included in one PDU SESSION MODIFICATION REQUEST message, if only one or some of them are not available / authorized in UDR, the other available non-3GPP device identifiers are rejected as well, and UE has no clue about which non-3GPP device identifier(s) are not available / subscribed, to let UE know which one is not available / authorized, an new IE for the unavailable 3GPP device identifier(s) needs to be introduced in the PDU SESSION MODIFICATION REJECT message;

[0417] The non-3GPP device identifiers might be disconnected due to the subscription change in UDR, if the UE has added the non-3GPP device identifiers in the PDU session modification procedure before, the NW shall trigger the Network-requested PDU session modification procedure to notify UE to remove the non-3GPP device identifiers, to fulfil this use case, the Alt-2 is preferred.

[0418] Given the above, it is proposed to use Alt-2, to introduce an IE to convey the non- 3GPP device identifier(s) not available / authorized from SMF to the UE in PDU SESSION MODIFICATION COMMAND message. Accordingly, this disclosure introduces an IE in PDU SESSION MODIFICATION COMMAND message to convey the non-3GPP device identifier(s) not available / authorized from SMF to the UE.

[0419] First Change

[0420] 6.3.2.1 General

[0421] The purpose of the network-requested PDU session modification procedure is to enable the network to modify a PDU session, re-negotiate header compression configuration associated to a PDU session, convey a port management information container, to trigger EAS rediscovery, provide updated DNS server address(es) due to the newly selected local DNS server or the newly selected EASDF, provide updated ECS configuration information, remove joined UE from one or more multicast MBS sessions associated with a PDU session, update ATSSS parameters (e.g. ATSSS rules), update the MBS service area or the security information of multicast MBS session that the UE has joined, [[or to]] inform about the result of service-level AA procedure or C2 authorization for UAS services, or notify that one or more non-3GPP device(s) connecting or connected through the UE are not authorized.

[0422] Next Change

[0423] 6.3.2.2 Network-requested PDU session modification procedure initiation

[0424] In order to initiate the network-requested PDU session modification procedure, the SMF shall create a PDU SESSION MODIFICATION COMMAND message.

[0425] If the authorized QoS rules of the PDU session is modified or is marked as to be synchronised with the UE, the SMF shall set the Authorized QoS rules IE of the PDU SESSION MODIFICATION COMMAND message to the authorized QoS rules of the PDU session. The SMF shall ensure that the number of the packet filters used in the authorized QoS rules of the PDU Session does not exceed the maximum number of packet filters supported by the UE for the PDU session. The SMF may bind service data flows for which the UE has requested traffic segregation to a dedicated QoS flow for the PDU session, if possible. Otherwise the SMF may bind the service data flows to an existing QoS flow. The SMF shall use only one dedicated QoS flow for traffic segregation. If the UE has requested traffic segregation for multiple service data flows with different QoS handling, the SMF shall bind all these service data flows to a single QoS flow. If the SMF allows traffic segregation for service data flows in a QoS rule, then the SMF shall create a new authorized QoS rule for these service data flows and shall delete packet filters corresponding to these service data flows from the other authorized QoS rules.

[0426] If the authorized QoS flow descriptions of the PDU session is modified or is marked as to be synchronised with the UE, the SMF shall set the Authorized QoS flow descriptions IE of the PDU SESSION MODIFICATION COMMAND message to the authorized QoS flow descriptions of the PDU session.

[0427] If SMF creates a new authorized QoS rule for a new QoS flow, then SMF shall include the authorized QoS flow description for that QoS flow in the Authorized QoS flow descriptions IE of the PDU SESSION MODIFICATION COMMAND message, if: a) the newly created authorized QoS rules is for a new GBR QoS flow; b) the QFI of the new QoS flow is not the same as the 5QI of the QoS flow identified by the QFI; c) the new QoS flow can be mapped to an EPS bearer as specified in subclause 4.11.1 of 3GPP TS 23.502 [9]; or d) the new QoS flow is established for the PDU session used for relaying, as specified in subclause 5.6.2.1 of 3GPP TS 23.304 [6E],

[0428] NOTE 0: In cases other than above listed cases, it is up to the SMF implementation to include the authorized QoS flow description of the new QoS flow for the new authorized QoS rule in the Authorized QoS flow descriptions IE of the PDU SESSION MODIFICATION COMMAND message.

[0429] If the session- AMBR of the PDU session is modified, the SMF shall set the selected Session- AMBR IE of the PDU SESSION MODIFICATION COMMAND message to the session-AMBR of the PDU session.

[0430] If interworking with EPS is supported for the PDU session and if the mapped EPS bearer contexts of the PDU session is modified, the SMF shall set the Mapped EPS bearer contexts IE of the PDU SESSION MODIFICATION COMMAND message to the mapped EPS bearer contexts of the PDU session. If the association between a QoS flow and the mapped EPS bearer context is changed, the SMF shall set the EPS bearer identity parameter in Authorized QoS flow descriptions IE of the PDU SESSION MODIFICATION COMMAND message to the new EPS bearer identity associated with the QoS flow.

[0431] NOTE 0A: The SMF can include multiple mapped EPS bearer context fields with the same EPS bearer identity in the Mapped EPS bearer contexts IE of the PDU SESSION MODIFICATION COMMAND message in cases, e.g. the packet filters need to be modified and the modification requires more than one TFT operation codes or the mapped traffic flow template needs to be modified and the modification exceeds the maximum size of the TFT IE.

[0432] If the network-requested PDU session modification procedure is triggered by a UE-requested PDU session modification procedure and the PDU SESSION MODIFICATION REQUEST message includes a 5GSM capability IE, the SMF shall: a) if the RQoS bit is set to:

[0433] 1) "Reflective QoS supported", consider that the UE supports reflective QoS for this PDU session; or

[0434] 2) "Reflective QoS not supported", consider that the UE does not support reflective QoS for this PDU session; and; b) if the MH6-PDU bit is set to:

[0435] 1) "Multi-homed IPv6 PDU session supported", consider that this PDU session is supported to use multiple IPv6 prefixes; or 2) "Multi-homed IPv6 PDU session not supported", consider that this PDU session is not supported to use multiple IPv6 prefixes.

[0436] If the SMF considers that reflective QoS is supported for QoS flows belonging to this PDU session, the SMF may include the RQ timer IE set to an RQ timer value in the PDU SESSION MODIFICATION COMMAND message.

[0437] If a port management information container needs to be delivered (see 3GPP TS 23.501 [8] and 3GPP TS 23.502 [9]) and the UE has set the TPMIC bit to "Transfer of port management information containers supported" in the 5GSM capability IE, the SMF shall include a Port management information container IE in the PDU SESSION MODIFICATION COMMAND message.

[0438] For a PDN connection established when in SI mode, upon an inter-system change from S 1 mode to N1 mode, if the network-requested PDU session modification procedure is triggered by a UE-requested PDU session modification procedure and a UE -requested PDU session modification procedure has not been successfully performed yet, the PDU session type is "IPv4", "IPv6", "IPv4v6" or "Ethernet" and the PDU SESSION MODIFICATION REQUEST message includes a Maximum number of supported packet filters IE, the SMF shall consider this number as the maximum number of packet filters that can be supported by the UE for this PDU session. Otherwise the SMF considers that the UE supports 16 packet filters for this PDU session.

[0439] For a PDN connection established when in SI mode, upon an inter-system change from SI mode to N1 mode, if the network-requested PDU session modification procedure is triggered by a UE-requested PDU session modification procedure and a UE-requested PDU session modification procedure has not been successfully performed yet, the SMF shall consider that the maximum data rate per UE for user-plane integrity protection supported by the UE for uplink and the maximum data rate per UE for user-plane integrity protection supported by the UE for downlink are valid for the lifetime of the PDU session.

[0440] For a PDN connection established when in SI mode, upon an inter-system change from SI mode to N1 mode, if the network-requested PDU session modification procedure is triggered by a UE-requested PDU session modification procedure and a UE-requested PDU session modification procedure has not been successfully performed yet, and the SMF determines, based on local policies or configurations in the SMF and the Always-on PDU session requested IE in the PDU SESSION MODIFICATION REQUEST message (if available), that either: a) the requested PDU session needs to be an always-on PDU session, the SMF shall include the Always-on PDU session indication IE in the PDU SESSION MODIFICATION COMMAND message and shall set the value to "Always-on PDU session required"; or b) the requested PDU session shall not be an always-on PDU session and:

[0441] 1) if the UE included the Always-on PDU session requested IE, the SMF shall include the Always-on PDU session indication IE in the PDU SESSION MODIFICATION COMMAND message and shall set the value to "Always-on PDU session not allowed"; or

[0442] 2) if the UE did not include the Always-on PDU session requested IE, the SMF shall not include the Always-on PDU session indication IE in the PDU SESSION MODIFICATION COMMAND message.

[0443] For a PDN connection established when in SI mode, upon an inter-system change from S 1 mode to N1 mode, if the network-requested PDU session modification procedure is triggered by a UE-requested PDU session modification procedure, a UE-requested PDU session modification procedure has not been successfully performed yet, the UE supports EDC and the network allows the use of EDC, then the SMF shall include the Extended protocol configuration options IE in the PDU SESSION MODIFICATION COMMAND message with the EDC usage allowed indicator.

[0444] For a PDN connection established when in SI mode, upon an inter-system change from S 1 mode to N1 mode, if the network-requested PDU session modification procedure is triggered by a UE-requested PDU session modification procedure, a UE-requested PDU session modification procedure has not been successfully performed yet, the UE supports EDC and the network requires the use of EDC, then the SMF shall include the Extended protocol configuration options IE in the PDU SESSION MODIFICATION COMMAND message with the EDC usage required indicator.

[0445] If a QoS flow for URLLC is created in a PDU session and the SMF has not provided the Always-on PDU session indication IE with the value set to "Always-on PDU session required" in the UE-requested PDU session establishment procedure or a network- requested PDU session modification procedure for the PDU session, the SMF shall include the Always-on PDU session indication IE in the PDU SESSION MODIFICATION COMMAND message and shall set the value to "Always-on PDU session required". For a PDN connection, upon an inter-system change from S 1 mode to N1 mode, if the network-requested PDU session modification procedure is triggered by a UE -requested PDU session modification procedure and a UE-requested PDU session modification procedure has not been successfully performed yet, the PDU session is a single access PDU session over 3GPP access with IP PDU session type, the SMF may decide to provide the protocol description associated with the PDU session and may include the Protocol description IE in the PDU SESSION MODIFICATION COMMAND message.

[0446] If the value of the RQ timer is set to "deactivated" or has a value of zero, the UE considers that RQoS is not applied for this PDU session and remove the derived QoS rule(s) associated with the PDU session, if any.

[0447] If the network-requested PDU session modification procedure is triggered by a UE-requested PDU session modification procedure, the SMF shall set the PTI IE of the PDU SESSION MODIFICATION COMMAND message to the PTI of the PDU SESSION MODIFICATION REQUEST message received as part of the UE-requested PDU session modification procedure.

[0448] If the network-requested PDU session modification procedure is triggered by a UE-requested PDU session modification procedure and the UE has included the Requested MBS container IE in the PDU SESSION MODIFICATION REQUEST message with the MBS operation set to "Join multicast MBS session", the SMF: a) shall include the TMGI for the multicast MBS session IDs that the UE is allowed to join, if any, in the Received MBS container IE, shall set the MBS decision to "MBS join is accepted" for each of those Received MBS information, may include the MBS start time to indicate the time when the multicast MBS session starts, and shall include the MBS security container in each of those Received MBS information if security protection is applied for that multicast MBS session and the control plane security procedure is used as specified in annex W.4.1.2 in 3GPP TS 33.501

[0024] , and shall use separate QoS flows dedicated for multicast by including the Authorized QoS flow descriptions IE if no separate QoS flows dedicated for multicast exist or if the SMF wants to establish new QoS flows dedicated for multicast;

[0449] NOTE 1: The network determines whether security protection applies or not for the multicast MBS session as specified in 3GPP TS 33.501

[0024] . b) shall include the TMGI for multicast MBS session IDs that the UE is rejected to join, if any, in the Received MBS container IE, shall set the MBS decision to "MBS join is rejected" for each of those Received MBS information, shall set the Rejection cause for each of those Received MBS information with the reason of rejection and, if the Rejection cause is set to "multicast MBS session has not started or will not start soon", may include an MBS back-off timer value; and c) may include in the Received MBS container IE the MBS service area for each multicast MBS session and include in it the MBS TAI list, the NR CGI list or both, that identify the service area(s) for the local MBS service;

[0450] NOTE 2: For a multicast MBS session that has multiple MBS service areas, the MBS service areas are indicated to the UE using MBS service announcement as described in 3GPP TS 23.247

[0053] , which is out of scope of this specification, in the PDU SESSION MODIFICATION COMMAND message. If the UE has set the Type of multicast MBS session ID to "Source specific IP multicast address" in the Requested MBS container IE for certain multicast MBS session(s) in the PDU SESSION MODIFICATION REQUEST message, the SMF shall include the Source IP address information and Destination IP address information in the Received MBS information together with the TMGI for each of those multicast MBS sessions.

[0451] NOTE 3: Including the Source IP address information and Destination IP address information in the Received MBS information in that case is to allow the UE to perform the mapping between the requested multicast MBS session ID and the provided TMGI.

[0452] NOTE 4: In SNPN, TMGI is used together with NID to identify an MBS Session.

[0453] If: a) the SMF wants to remove joined UE from one or more multicast MBS sessions; or b) the network-requested PDU session modification procedure is triggered by a UE- requested PDU session modification procedure and the UE has included the Requested MBS container IE in the PDU SESSION MODIFICATION REQUEST message with the MBS operation set to "Leave multicast MBS session", the SMF shall include the multicast MBS session IDs that the UE is removed from, if any, in the Received MBS container IE in the PDU SESSION MODIFICATION COMMAND message and shall set the MBS decision to "Remove UE from multicast MBS session" for each of those Received MBS information. The SMF may include the updated MBS service area in each of the Received MBS information, if any. The SMF may delete the QoS flows associated for the multicast by including the Authorized QoS flow descriptions IE in the PDU SESSION MODIFICATION COMMAND message. If the UE is removed from multicast MBS session due to the MBS session release, the SMF shall set the Rejection cause to "multicast MBS session is released". The SMF shall include the Rejection cause for each of the Received MBS information, if any, and set its value with the reason of removing the UE from the corresponding multicast MBS session.

[0454] NOTE 5: based on operator's policy, e.g. after a locally configured time period, the SMF is allowed to trigger the removal of joined UE from a multicast MBS session when the UE moves outside all the MBS service area(s) of that multicast MBS session.

[0455] If the SMF wants to update the MBS security information of an multicast MBS session that the UE has joined, the SMF shall include the corresponding multicast MBS session ID and the MBS security container in the Received MBS container IE in the PDU SESSION MODIFICATION COMMAND message, and shall set the MBS Decision to "MBS security information update" in the Received MBS information.

[0456] If the SMF wants to update the MBS service area of an multicast MBS session that the UE has joined, the SMF shall include the corresponding multicast MBS session ID and the updated MBS service area in the Received MBS container IE in the PDU SESSION MODIFICATION COMMAND message, and shall set the MBS decision to "MBS service area update" in the Received MBS information.

[0457] NOTE 6: The MBS service area of a multicast MBS session is also allowed to be updated to the UE using the MBS service announcement as described in 3GPP TS 23.247

[0053] , which is out of scope of this specification.

[0458] If the network needs to update ATSSS parameters (see subclause 5.2.4 of 3GPP TS 24.193 [13B]), the SMF shall include the ATSSS container IE with the updates of ATSSS parameters in the PDU SESSION MODIFICATION COMMAND message.

[0459] If the network-requested PDU session modification procedure is not triggered by a UE -requested PDU session modification procedure, the SMF shall set the PTI IE of the PDU SESSION MODIFICATION COMMAND message to "No procedure transaction identity assigned".

[0460] If the selected SSC mode of the PDU session is "SSC mode 3" and the SMF requests the relocation of SSC mode 3 PDU session anchor with multiple PDU sessions as specified in 3GPP TS 23.502 [9], the SMF shall include 5GSM cause #39 "reactivation requested", in the PDU SESSION MODIFICATION COMMAND message, and may include the PDU session address lifetime in a PDU session address lifetime parameter in the Extended protocol configuration options IE of the PDU SESSION MODIFICATION COMMAND message. If the selected SSC mode of the PDU session is "SSC mode 3", the S-NSSAI or the mapped S-NSSAI associated with the PDU session needs to be replaced and the SMF determines that the PDU session needs to be re-established on the alternative S-NSSAI, the SMF shall include the Alternative S-NSSAI IE and 5GSM cause #39 "reactivation requested" in the PDU SESSION MODIFICATION COMMAND message. If the selected SSC mode of the PDU session is "SSC mode 3", the replaced S- NSSAI is available and the SMF determines that the PDU session needs to be reestablished on the replaced S-NSSAI, the SMF shall include and 5GSM cause #39 "reactivation requested" and include the replaced S-NSSAI in the PDU SESSION MODIFICATION COMMAND message.

[0461] NOTE 7: The relocation of SSC mode 3 PDU session anchor with multiple PDU sessions can also be initiated by the SMF in case of the SMF is requested by the AMF to release the PDU session due to the network slice instance of the PDU session is changed as specified in subclause 5.15.5.3 of 3GPP TS 23.501 [8],

[0462] The SMF shall send the PDU SESSION MODIFICATION COMMAND message, and the SMF shall start timer T3591 (see example in FIG. 29).

[0463] NOTE 8: If the SMF requests the relocation of SSC mode 3 PDU session anchor with multiple PDU sessions as specified in 3GPP TS 23.502 [9], the reallocation requested indication indicating whether the SMF is to be reallocated or the SMF is to be reused is provided to the AMF.

[0464] If the control plane CIoT 5GS optimization is enabled for a PDU session and the IP header compression configuration IE was included in the PDU SESSION ESTABLISHMENT REQUEST message or the PDU SESSION MODIFICATION REQUEST message, and the SMF supports control plane CIoT 5GS optimization and IP header compression for control plane CIoT 5GS optimization, the SMF may include the IP header compression configuration IE in the PDU SESSION MODIFICATION COMMAND message to re-negotiate IP header compression configuration associated to the PDU session.

[0465] If the control plane CIoT 5GS optimization is enabled for a PDU session and the Ethernet header compression configuration IE was included in the PDU SESSION ESTABLISHMENT REQUEST message or the PDU SESSION MODIFICATION REQUEST message, and the SMF supports control plane CIoT 5GS optimization and Ethernet header compression for control plane CIoT 5GS optimization, the SMF may include the Ethernet header compression configuration IE in the PDU SESSION MODIFICATION COMMAND message to re-configure Ethernet header compression configuration associated with the PDU session.

[0466] If the network-requested PDU session modification procedure is associated with C2 authorization procedure, the SMF shall send the PDU SESSION MODIFICATION COMMAND message by including the Service-level-AA container IE containing: a) the service-level- AA response with the value of C2AR field set to the "C2 authorization was successful"; b) if a payload is provided from the UAS-NF, the service-level-AA payload with the value set to the payload; and c) if a payload type associated with the payload is provided from the UAS-NF, the service-level-AA payload type with the value set to the payload type; and d) if the CAA-level UAV ID is provided from the UAS-NF, the service-level device ID set to the CAA-level UAV ID.

[0467] NOTE 9: The C2 authorization pay load in the service-level-AA pay load can include one, some or all of the pairing information for C2 communication, and the pairing information for direct C2 communication,

[0468] NOTE 9A: The C2 authorization payload in the service-level-AA payload can include the security information for C2 session as specified in TS 33.256 [24B].

[0469] If the service-level-AA procedure is triggered for the established PDU session for UAS services with re-authentication purpose, and the SMF is provided by the UAS-NF with the successful UUAA-SM result, the SMF shall transmit a PDU SESSION MODIFICATION COMMAND message to the UE, where the PDU SESSION MODIFICATION COMMAND message shall include the Service-level-AA container IE containing: a) the service-level-AA response with the value of SLAR field set to "Service level authentication and authorization was successful"; b) if received the CAA-level UAV ID from the UAS-NF, the service-level device ID with the value set to the CAA-level UAV ID; c) if received a payload from the UAS-NF, the service-level-AA payload with the value set to the payload; and d) if received a payload type associated with the payload, the service-level-AA payload type with the value set to the payload type. If the SMF needs to provide new ECS configuration information to the UE and the UE has indicated support for ECS configuration information provisioning in the PDU SESSION ESTABLISHMENT REQUEST message or while in SI mode, then the SMF may include the Extended protocol configuration options IE in the PDU SESSION MODIFICATION COMMAND message with: a) at least one of ECS IPv4 Address(es), ECS IPv6 Address(es), ECS FQDN(s); b) at least one associated ECSP identifier; c) optionally, spatial validity conditions associated with the ECS address; d) optionally, ECS authentication methods associated with the ECS address; and e) optionally, ECS supported PLMNs information list, including the associated ECSP information for which the EDN configuration information can be provided by the ECS.

[0470] NOTE 10: The IP address(es), FQDN(s), or both are associated with the ECSP identifier and replace previously provided ECS configuration information associated with the same ECSP identifier, if any.

[0471] If the SMF needs to provide DNS server address(es) to the UE and the UE has provided the DNS server IPv4 address request, the DNS server IPv6 address request or both of them, in the PDU SESSION ESTABLISHMENT REQUEST message or a PDU SESSION MODIFICATION REQUEST message, then the SMF shall include the Extended protocol configuration options IE in the PDU SESSION MODIFICATION COMMAND message with one or more DNS server IPv4 address(es), one or more DNS server IPv6 address(es) or both of them.

[0472] If the SMF needs to trigger EAS rediscovery and the UE has indicated support of the EAS rediscovery in the PDU SESSION ESTABLISHMENT REQUEST message or the PDU SESSION MODIFICATION REQUEST message, then the SMF shall include the Extended protocol configuration options IE in the PDU SESSION MODIFICATION COMMAND message: a) with the EAS rediscovery indication without indicated impact; or b) with the following:

[0473] 1) one or more EAS rediscovery indication(s) with impacted EAS IPv4 address range, if the UE supports EAS rediscovery indication(s) with impacted EAS IPv4 address range; 2) one or more EAS rediscovery indication(s) with impacted EAS IPv6 address range, if the UE supports EAS rediscovery indication(s) with impacted EAS IPv6 address range;

[0474] 3) one or more EAS rediscovery indication(s) with impacted EAS FQDN, if the UE supports EAS rediscovery indication(s) with impacted EAS FQDN; or

[0475] 4) any combination of the above.

[0476] When UE has requested P-CSCF IPv6 address or P-CSCF IPv4 address and the SMF has provided P-CSCF address(es) during the PDU session establishment procedure, if the network-requested PDU session modification procedure is triggered for P-CSCF restoration, the SMF shall include the P-CSCF IP address(es) in the Extended protocol configuration options IE in the PDU SESSION MODIFICATION COMMAND message as specified in subclause 5.8.2.2 of 3GPP TS 23.380

[0054] .

[0477] If the S-NSSAI or the mapped S-NSSAI of the PDU session needs to be replaced and the SMF determines that the PDU session needs to be retained, the SMF shall include the Alternative S-NSSAI IE in the PDU SESSION MODIFICATION COMMAND message. If the replaced S-NSSAI is available and the SMF determines that the PDU session needs to be retained, the SMF include replaced S-NSSAI in the PDU SESSION MODIFICATION COMMAND message.

[0478] If the SMF includes the authorized QoS flow descriptions and the SMF determines to provide the N3QAI to the UE, the SMF shall include the N3QAI IE in the PDU SESSION MODIFICATION COMMAND message.

[0479] If the PDU session was a single access PDU session established over 3GPP access with IP PDU session type and based on operator policy the SMF determines to provide the protocol description for UL PDU set handling to the UE, the SMF may include the Protocol description IE in the PDU SESSION MODIFICATION COMMAND message. If: the UE has included the Non-3GPP device connection information IE in the PDU SESSION MODIFICATION REQUEST message with the operation code set to "add new non-3GPP device identifier", and one or more of the non-3GPP device identifiers are is not authorized, e.g. the non-3GPP device identifier is not included in the UDR as specified in clause 5.2.12.2.1 of3GPP TS 23.502 [9]; or one or more non-3GPP device identifiers are removed in the UDR due to subscription change; the SMF shall include the Non-3GPP device connection notify IE with the one or more non-3GPP device identifiers which are not authorized in the PDU SESSION MODIFICATION COMMAND message.

[0480] Next Change

[0481] 6.3.2.3 Network-requested PDU session modification procedure accepted by the UE

[0482] Upon receipt of the PDU SESSION MODIFICATION COMMAND message, if the UE provided a DNN during the PDU session establishment, the UE shall stop timer T3396, if it is running for the DNN provided by the UE. If the UE did not provide a DNN during the PDU session establishment and the request type was different from "initial emergency request" and different from "existing emergency PDU session", the UE shall stop the timer T3396 associated with no DNN if it is running. If the PDU SESSION MODIFICATION COMMAND message was received for an emergency PDU session, the UE shall not stop the timer T3396 associated with no DNN if it is running. In an SNPN, the timer T3396 to be stopped includes: b) the timer T3396 applied for all the equivalent SNPNs, associated with the RSNPN or an equivalent SNPN, and with the selected entry of the "list of subscriber data" or the selected PLMN subscription, if running; and a) the timer T3396 applied for the registered SNPN, associated with the RSNPN, and, if the UE supports access to an SNPN using credentials from a credentials holder, associated with the selected entry of the "list of subscriber data" or the selected PLMN subscription, if running.

[0483] Upon receipt of the PDU SESSION MODIFICATION COMMAND message, if the UE provided an S-NSSAI and a DNN during the PDU session establishment, the UE shall stop timer T3584, if it is running for the [S-NSSAI of the PDU session, DNN] combination provided by the UE. If the UE provided a DNN and did not provide an S- NSSAI during the PDU session establishment, the UE shall stop timer T3584, if it is running for the same [no S-NSSAI, DNN] combination provided by the UE. If the UE provided an S-NSSAI and did not provide a DNN during the PDU session establishment, the UE shall stop timer T3584, if it is running for the same [S-NSSAI, no DNN] combination provided by the UE. If the UE provided neither a DNN nor an S-NSSAI during the PDU session establishment, the UE shall stop timer T3584, if it is running for the same [no S-NSSAI, no DNN] combination provided by the UE. The timer T3584 to be stopped includes: a) in a PLMN:

[0484] 1) the timer T3584 applied for all the PLMNs, if running; and

[0485] 2) the timer T3584 applied for the registered PLMN, if running; or b) in an SNPN:

[0486] 1) the timer T3584 applied for all the equivalent SNPNs, and associated with the RSNPN or an equivalent SNPN and with the selected entry of the "list of subscriber data" or the selected PLMN subscription, if running; and

[0487] 2) the timer T3584 applied for the registered SNPN, associated with the RSNPN and, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both, associated with the selected entry of the "list of subscriber data" or the selected PLMN subscription, if running.

[0488] Upon receipt of the PDU SESSION MODIFICATION COMMAND message, if the UE provided an S-NSSAI during the PDU session establishment, the UE shall stop timer T3585, if it is running for the S-NSSAI of the PDU session. If the UE did not provide an S-NSSAI during the PDU session establishment and the request type was different from "initial emergency request" and different from "existing emergency PDU session", the UE shall stop the timer T3585 associated with no S-NSSAI if it is running. The timer T3585 to be stopped includes: a) in a PLMN:

[0489] 1) the timer T3585 applied for all the PLMNs and for the access over which the PDU SESSION MODIFICATION COMMAND is received, if running;

[0490] 2) the timer T3585 applied for all the PLMNs and for both 3GPP access type and non-3GPP access type, if running;

[0491] 3) the timer T3585 applied for the registered PLMN and for the access over which the PDU SESSION MODIFICATION COMMAND is received, if running; and

[0492] 4) the timer T3585 applied for the registered PLMN and for both 3GPP access type and non-3GPP access type, if running; or b) in an SNPN:

[0493] 1) the timer T3585 applied for all the equivalent SNPNs and for the access over which the PDU SESSION AUTHENTICATION COMMAND message is received, associated with the RSNPN or an equivalent SNPN and with the selected entry of the "list of subscriber data" or the selected PLMN subscription, if running; 2) the timer T3585 applied for all the equivalent SNPNs and for both 3GPP access type and non-3GPP access type, associated with the RSNPN or an equivalent SNPN and with the selected entry of the "list of subscriber data" or the selected PLMN subscription, if running;

[0494] 3) the timer T3585 applied for the registered SNPN and for the access over which the PDU SESSION AUTHENTICATION COMMAND message is received, associated with the RSNPN and, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both, associated with the selected entry of the "list of subscriber data" or the selected PLMN subscription, if running; and

[0495] 4) the timer T3585 applied for the registered PLMN and for both 3GPP access type and non-3GPP access type, associated with the RSNPN and, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both, associated with the selected entry of the "list of subscriber data" or the selected PLMN subscription, if running.

[0496] If the PDU SESSION MODIFICATION COMMAND message was received for an emergency PDU session, the UE shall not stop the timer T3585 associated with no S- NSSAI if it is running.

[0497] NOTE 1 : Upon receipt of the PDU SESSION MODIFICATION COMMAND message for a PDU session, if the UE provided a DNN (or no DNN) and an S-NSSAI (or no S-NSSAI) when the PDU session is established, timer T3396 associated with the DNN (or no DNN, if no DNN was provided by the UE) is running, and timer T3584 associated with the DNN (or no DNN, if no DNN was provided by the UE) and the S-NSSAI of the PDU session (or no S-NSSAI, if no S-NSSAI was provided by the UE) is running, then the UE stops both the timer T3396 and the timer T3584.

[0498] NOTE 2: Upon receipt of the PDU SESSION MODIFICATION COMMAND message for a PDU session, if the UE provided a DNN (or no DNN) and an S-NSSAI (or no S-NSSAI) when the PDU session is established, timer T3585 associated with the S-NSSAI of the PDU session (or no S- NSSAI, if no S-NSSAI was provided by the UE) is running, and timer T3584 associated with the DNN (or no DNN, if no DNN was provided by the UE) and the S-NSSAI of the PDU session (or no S-NSSAI, if no S-NSSAI was provided by the UE) is running, then the UE stops both the timer T3585 and the timer T3584.

[0499] If the PDU SESSION MODIFICATION COMMAND message includes the Authorized QoS rules IE, the UE shall process the QoS rules sequentially starting with the first QoS rule.

[0500] If the PDU SESSION MODIFICATION COMMAND message includes the Authorized QoS rules IE with the Rule operation code is set to "Delete existing QoS rule" for one or more QoS rules, the UE shall delete the protocol descriptions associated with the QoS rules, if any.

[0501] If the PDU SESSION MODIFICATION COMMAND message includes the Mapped EPS bearer contexts IE, the UE shall process the mapped EPS bearer contexts sequentially starting with the first mapped EPS bearer context.

[0502] If the PDU SESSION MODIFICATION COMMAND message includes the Authorized QoS flow descriptions IE, the UE shall process the QoS flow descriptions sequentially starting with the first QoS flow description.

[0503] The UE shall replace the stored authorized QoS rules, authorized QoS flow descriptions and session- AMBR of the PDU session with the received value(s), if any, in the PDU SESSION MODIFICATION COMMAND message.

[0504] If the PDU SESSION MODIFICATION COMMAND message includes a Mapped EPS bearer contexts IE, the UE shall check each mapped EPS bearer context for different types of errors as follows:

[0505] NOTE 3: An error detected in a mapped EPS bearer context does not cause the UE to discard the Authorized QoS rules IE and Authorized QoS flow descriptions IE included in the PDU SESSION MODICATION COMMAND message, if any. a) Semantic error in the mapped EPS bearer operation: 1) operation code = "Create new EPS bearer" and there is already an existing mapped EPS bearer context with the same EPS bearer identity associated with any PDU session.

[0506] 2) operation code = "Delete existing EPS bearer" and there is no existing mapped EPS bearer context with the same EPS bearer identity associated with the PDU session that is being modified.

[0507] 3) operation code = "Modify existing EPS bearer" and there is no existing mapped EPS bearer context with the same EPS bearer identity associated with the PDU session that is being modified.

[0508] 4) operation code = "Create new EPS bearer" or "Modify existing EPS bearer" and the resulting mapped EPS bearer context has invalid mandatory parameters or missing mandatory parameters (e.g., mapped EPS QoS parameters or traffic flow template for a dedicated EPS bearer context).

[0509] In case 1, if the existing mapped EPS bearer context is associated with the PDU session that is being modified, the UE shall not diagnose an error, further process the create request and, if it was process successfully, delete the old EPS bearer context. In case 2, the UE shall not diagnose an error, further process the delete request and, if it was processed successfully, consider the mapped EPS bearer context as successfully deleted.

[0510] Otherwise, after sending the PDU SESSION MODIFICATION COMPLETE for the ongoing PDU session modification procedure, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #85 "Invalid mapped EPS bearer identity". b) if the mapped EPS bearer context includes a traffic flow template, the UE shall check the traffic flow template for different types of TFT IE errors as follows:

[0511] 1) Semantic errors in TFT operations: i) TFT operation = "Create new TFT" when there is already an existing TFT for the EPS bearer context. ii) When the TFT operation is an operation other than "Create a new TFT" and there is no TFT for the EPS bearer context. iii)TFT operation = "Delete packet filters from existing TFT" when it would render the TFT empty. iv)TFT operation = "Delete existing TFT" for a dedicated EPS bearer context. In case iv, after sending the PDU SESSION MODIFICATION COMPLETE for the ongoing PDU session modification procedure, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #41 "semantic error in the TFT operation".

[0512] In the other cases the UE shall not diagnose an error and perform the following actions to resolve the inconsistency:

[0513] In case i, the UE shall further process the new activation request to create a new TFT and, if it was processed successfully, delete the old TFT.

[0514] In case ii, the UE shall:

[0515] - process the new request and if the TFT operation is "Delete existing TFT" or "Delete packet filters from existing TFT", and if no error according to items 2, 3, and 4 was detected, consider the TFT as successfully deleted;

[0516] - process the new request as an activation request, if the TFT operation is "Add packet filters in existing TFT" or "Replace packet filters in existing TFT".

[0517] In case iii, if the packet filters belong to a dedicated EPS bearer context, the UE shall process the new deletion request and, if no error according to items 2, 3, and 4 was detected, after sending the PDU SESSION MODIFICATION COMPLETE for the ongoing PDU session modification procedure, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #41 "semantic error in the TFT operation".

[0518] In case iii, if the packet filters belong to the default EPS bearer context, the UE shall process the new deletion request and if no error according to items 2, 3, and 4 was detected then delete the existing TFT, this corresponds to using match-all packet filter for the default EPS bearer context. ) Syntactical errors in TFT operations: i) When the TFT operation = "Create new TFT", "Add packet filters in existing TFT", "Replace packet filters in existing TFT" or "Delete packet filters from existing TFT" and the packet filter list in the TFT IE is empty. ii) TFT operation = "Delete existing TFT" or "No TFT operation" with a nonempty packet filter list in the TFT IE. iii)TFT operation = "Replace packet filters in existing TFT" when the packet filter to be replaced does not exist in the original TFT. iv)TFT operation = "Delete packet filters from existing TFT" when the packet filter to be deleted does not exist in the original TFT. v) Void. vi)When there are other types of syntactical errors in the coding of the TFT IE, such as a mismatch between the number of packet filters subfield, and the number of packet filters in the packet filter list.

[0519] In case iii, the UE shall not diagnose an error, further process the replace request and, if no error according to items 3 and 4 was detected, include the packet filters received to the existing TFT.

[0520] In case iv, the UE shall not diagnose an error, further process the deletion request and, if no error according to items 3 and 4 was detected, consider the respective packet filter as successfully deleted.

[0521] Otherwise, after sending the PDU SESSION MODIFICATION COMPLETE for the ongoing PDU session modification procedure, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #42 "syntactical error in the TFT operation".

[0522] NOTE 3a: An implementation that strictly follows packet filter list as defined in subclause 10.5.6.12 in 3GPP TS 24.008

[0012] might not detect case 2) ii).

[0523] 3) Semantic errors in packet filters: i) When a packet filter consists of conflicting packet filter components which would render the packet filter ineffective, i.e. no IP packet will ever fit this packet filter. How the UE determines a semantic error in a packet filter is outside the scope of the present document. ii) When the resulting TFT, which is assigned to a dedicated EPS bearer context, does not contain any packet filter applicable for the uplink direction among the packet filters created on request from the network.

[0524] After sending the PDU SESSION MODIFICATION COMPLETE for the ongoing PDU session modification procedure, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #44 "semantic errors in packet filter(s)".

[0525] 4) Syntactical errors in packet filters: i) When the TFT operation = "Create new TFT", "Add packet filters to existing TFT", or "Replace packet filters in existing TFT" and two or more packet filters in the resultant TFT would have identical packet filter identifiers. ii) When the TFT operation = "Create new TFT", "Add packet filters to existing TFT" or "Replace packet filters in existing TFT", and two or more packet filters among all TFTs associated with this PDN connection would have identical packet filter precedence values. iii)When there are other types of syntactical errors in the coding of packet filters, such as the use of a reserved value for a packet filter component identifier.

[0526] In case i, if two or more packet filters with identical packet filter identifiers are contained in the new request, after sending the PDU SESSION MODIFICATION COMPLETE for the ongoing PDU session modification procedure, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #45 "syntactical error in packet filter(s)". Otherwise, the UE shall not diagnose an error, further process the new request and, if it was processed successfully, delete the old packet filters which have the identical packet filter identifiers.

[0527] In case ii, if the old packet filters do not belong to the default EPS bearer context, the UE shall not diagnose an error, shall further process the new request and, if it was processed successfully, shall delete the old packet filters which have identical filter precedence values.

[0528] In case ii, if one or more old packet filters belong to the default EPS bearer context, after sending the PDU SESSION MODIFICATION COMPLETE for the ongoing PDU session modification procedure, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #45 "syntactical errors in packet filter(s)".

[0529] Otherwise, after sending the PDU SESSION MODIFICATION COMPLETE for the ongoing PDU session modification procedure, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #45 "syntactical error in packet filter(s)". And if a new EPS bearer identity parameter in Authorized QoS flow descriptions IE is received for a QoS flow which can be transferred to EPS, the UE shall update the association between the QoS flow and the mapped EPS bearer context, based on the new EPS bearer identity and the mapped EPS bearer contexts. If the "Delete existing EPS bearer" operation code in the Mapped EPS bearer contexts IE was received, the UE shall discard the association between the QoS flow and the corresponding mapped EPS bearer context and delete the corresponding mapped EPS bearer context.

[0530] If: a) the UE detects different errors in the mapped EPS bearer contexts as described above which requires sending a PDU SESSION MODIFICATION REQUEST message to delete the erroneous mapped EPS bearer contexts; and b) optionally, if the UE detects errors in QoS rules that require to delete at least one QoS rule as described in subclause 6.3.2.4 which requires sending a PDU SESSION MODIFICATION REQUEST message to delete the erroneous QoS rules; the UE, after sending the PDU SESSION MODIFICATION COMPLETE message for the ongoing PDU session modification procedure, may send a single PDU SESSION MODIFICATION REQUEST message to delete the erroneous mapped EPS bearer contexts, and optionally to delete the erroneous QoS rules. The UE shall include a 5GSM cause IE in the PDU SESSION MODIFICATION REQUEST message.

[0531] NOTE 4: The 5GSM cause to use cannot be different from #41 "semantic error in the

[0532] TFT operation", #42 "syntactical error in the TFT operation", #44 "semantic error in packet filter(s)", #45 "syntactical errors in packet filter(s)", #83 "semantic error in the QoS operation", #84 "syntactical error in the QoS operation", or #85 "Invalid mapped EPS bearer identity". The selection of a 5GSM cause is up to UE implementation.

[0533] Upon receipt of a PDU SESSION MODIFICATION COMMAND message and a PDU session ID, using the NAS transport procedure as specified in subclause 5.4.5, if the UE accepts the PDU SESSION MODIFICATION COMMAND message, the UE considers the PDU session as modified and the UE shall create a PDU SESSION MODIFICATION COMPLETE message.

[0534] If the PDU SESSION MODIFICATION COMMAND message contains the PTI value allocated in the UE-requested PDU session modification procedure, the UE shall stop the timer T3581. The UE should ensure that the PTI value assigned to this procedure is not released immediately. NOTE 5: The way to achieve this is implementation dependent. For example, the UE can ensure that the PTI value assigned to this procedure is not released during the time equal to or greater than the default value of timer T3591.

[0535] While the PTI value is not released, the UE regards any received PDU SESSION MODIFICATION COMMAND message with the same PTI value as a network retransmission (see subclause 7.3.1).

[0536] If the selected SSC mode of the PDU session is "SSC mode 3" and the PDU SESSION MODIFICATION COMMAND message includes 5GSM cause #39 "reactivation requested", the UE can provide to the upper layers the PDU session address lifetime if received in the PDU session address lifetime parameter of the Extended protocol configuration options IE of the PDU SESSION MODIFICATION COMMAND message. After the completion of the network-requested PDU session modification procedure: a) if the PDU session is an MA PDU session:

[0537] 1) established over both 3GPP access and non-3GPP access, and:

[0538] - the UE is registered over both 3GPP access and non-3GPP access in the same PLMN:

[0539] - the UE should re-initiate a UE -requested PDU session establishment procedure as specified in subclause 6.4.1 over the access the PDU SESSION MODIFICATION COMMAND message is received; or

[0540] - the UE is registered over both 3GPP access and non-3GPP access in different PLMNs:

[0541] - the UE should re-initiate UE-requested PDU session establishment procedures as specified in subclause 6.4.1 over both accesses. The UE should re-initiate the UE-requested PDU session establishment procedure over the access the PDU SESSION MODIFICATION COMMAND message is received first; or

[0542] 2) established over only single access:

[0543] - the UE should re-initiate a UE-requested PDU session establishment procedure as specified in subclause 6.4.1 over the access the user plane resources were established; or b) if the PDU session is a single access PDU session: the UE should re-initiate a UE -requested PDU session establishment procedure as specified in subclause 6.4.1 over the access the PDU session was associated with; and for the re-initiated UE-requested PDU session establishment procedure(s) the UE should set a new PDU session ID different from the PDU session ID associated with the present PDU session and should set: a) the PDU session type to the PDU session type associated with the present PDU session; b) the SSC mode to the SSC mode associated with the present PDU session; c) the DNN to the DNN associated with the present PDU session; d) the S-NSSAI to:

[0544] 1) the S-NSSAI associated with (if available in roaming scenarios) a mapped S- NSSAI if provided in the UE-requested PDU session establishment procedure of the present PDU session; or

[0545] 2) the S-NSSAI received in the PDU SESSION ESTABLISHMENT ACCEPT message of the existing PDU session if the UE received the Alternative S-NSSAI IE in the PDU SESSION MODIFICATION COMMAND message; and e) the alternative S-NSSAI to the S-NSSAI associated with (if available in roaming scenarios) a mapped S-NSSAI if received in the Alternative S-NSSAI IE of the PDU SESSION MODIFICATION COMMAND message.

[0546] If the UE has indicated support for CIoT 5GS optimizations and receives a small data rate control parameters container in the Extended protocol configuration options IE in the PDU SESSION MODIFICATION COMMAND message, the UE shall store the small data rate control parameters value and use the stored small data rate control parameters value as the maximum allowed limit of uplink user data for the PDU session in accordance with 3GPP TS 23.501 [8]. If the UE has a previously stored small data rate control parameter value for the PDU session, the UE shall replace the stored small data rate control parameters value for the PDU session with the received small data rate control parameters value in the Extended protocol configuration options IE in the PDU SESSION MODIFICATION COMMAND message.

[0547] If the UE has indicated support for CIoT 5GS optimizations and receives an additional small data rate control parameters for exception data container in the Extended protocol configuration options IE in the PDU SESSION MODIFICATION COMMAND message, the UE shall store the additional small data rate control parameters for exception data value and use the stored additional small data rate control parameters for exception data value as the maximum allowed limit of uplink exception data for the PDU session in accordance with 3GPP TS 23.501 [8]. If the UE has a previously stored additional small data rate control parameters for exception data value for the PDU session, the UE shall replace the stored additional small data rate control parameters for exception data value for the PDU session with the received additional small data rate control parameters for exception data value in the Extended protocol configuration options IE in the PDU SESSION MODIFICATION COMMAND message.

[0548] The UE shall include the PDU session ID of the old PDU session which is about to get released in the old PDU session ID IE of the UL NAS TRANSPORT message that transports the PDU SESSION ESTABLISHMENT REQUEST message.

[0549] NOTE 6: The UE is expected to maintain the PDU session for which the PDU SESSION MODIFICATION COMMAND message including 5GSM cause #39 "reactivation requested" is received during the time indicated by the PDU session address lifetime value or until receiving an indication from upper layers (e.g. that the old PDU session is no more needed).

[0550] If the selected PDU session type of the PDU session is "Unstructured", the UE supports inter-system change from N1 mode to SI mode, the UE does not support establishment of a PDN connection for the PDN type set to "non-IP" in SI mode, and the parameters list field of one or more authorized QoS flow descriptions received in the Authorized QoS flow descriptions IE of the PDU SESSION MODIFICATION COMMAND message contains an EPS bearer identity (EBI), then the UE shall locally remove the EPS bearer identity (EBI) from the parameters list field of such one or more authorized QoS flow descriptions. After sending the PDU SESSION MODIFICATION COMPLETE message for the ongoing PDU session modification procedure, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #85 "Invalid mapped EPS bearer identity".

[0551] If the selected PDU session type of the PDU session is "Ethernet", the UE supports inter-system change from N1 mode to SI mode, the UE does not support establishment of a PDN connection for the PDN type set to "non-IP" in S 1 mode, the UE, the network or both of them do not support Ethernet PDN type in S 1 mode, and the parameters list field of one or more authorized QoS flow descriptions received in the Authorized QoS flow descriptions IE of the PDU SESSION MODIFICATION COMMAND message contains an EPS bearer identity (EBI), the UE shall locally remove the EPS bearer identity (EBI) from the parameters list field of such one or more authorized QoS flow descriptions. After sending the PDU SESSION MODIFICATION COMPLETE message for the ongoing PDU session modification procedure, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #85 "Invalid mapped EPS bearer identity".

[0552] For a UE which is registered for disaster roaming services and for a PDU session which is not a PDU session for emergency services: a) if the parameters list field of one or more authorized QoS flow descriptions received in the Authorized QoS flow descriptions IE of the PDU SESSION MODIFICATION COMMAND message contains an EPS bearer identity (EBI), then the UE shall locally remove the EPS bearer identity (EBI) from the parameters list field of such one or more authorized QoS flow descriptions; and b) the UE shall locally delete the contents of the Mapped EPS bearer contexts IE if it is received in the PDU SESSION MODIFICATION COMMAND message.

[0553] If the Always-on PDU session indication IE is included in the PDU SESSION MODIFICATION COMMAND message and: a) the value of the IE is set to "Always-on PDU session required", the UE shall consider the established PDU session as an always-on PDU session; or b) the value of the IE is set to "Always-on PDU session not allowed", the UE shall not consider the established PDU session as an always-on PDU session.

[0554] If the UE does not receive the Always-on PDU session indication IE in the PDU SESSION MODIFICATION COMMAND message: a) if the network-requested PDU session modification procedure is triggered by a UE- requested PDU session modification procedure upon an inter-system change from S 1 mode to N1 mode for a PDN connection established when in S 1 mode, the UE shall not consider the modified PDU session as an always-on PDU session; or b) otherwise:

[0555] 1) if the UE has received the Always-on PDU session indication IE with the value set to "Always-on PDU session required" for this PDU session, the UE shall consider the PDU session as an always-on PDU session; or

[0556] 2) otherwise the UE shall not consider the PDU session as an always-on PDU session. If the PDU SESSION MODIFICATION COMMAND message contains a Port management information container IE, the UE shall forward the contents of the Port management information container IE to the DS-TT (see 3GPP TS 23.501 [8] and 3GPP TS 23.502 [9]).

[0557] If the UE receives a Serving PLMN rate control IE in the PDU SESSION MODIFICATION COMMAND message, the UE shall store the Serving PLMN rate control IE value, replacing any existing value, and use the stored serving PLMN rate control value as the maximum allowed limit of uplink control plane user data for the corresponding PDU session in accordance with 3GPP TS 23.501 [8].

[0558] If the PDU SESSION MODIFICATION COMMAND message includes the Received MBS container IE, for each of the Received MBS informations: a) if MBS decision is set to "MBS join is accepted", the UE shall consider that it has successfully joined the multicast MBS session. The UE shall store the received TMGI and shall use it for any further operation on that multicast MBS session. The UE shall store the received MBS service area associated with the received TMGI, if any, and provide the received TMGI to lower layers. The UE may provide the MBS start time if it is included in the Received MBS information to upper layers; b) if MBS decision is set to "MBS join is rejected", the UE shall consider the requested join as rejected. The UE shall store the received MBS service area associated with the received TMGI, if any. If the received Rejection cause is set to "User is outside of local MBS service area", the UE shall not request to join the same multicast MBS session if neither current TAI nor CGI of the current cell is part of the received MBS service area. If the received Rejection cause is set to "multicast MBS session has not started or will not start soon" and an MBS back-off timer value is included with value that indicates neither zero nor deactivated, the UE shall start a back-off timer T3587 with the value provided in the MBS back-off timer value for the received TMGI, and shall not attempt to join the multicast MBS session with the same TMGI, the Source IP address information of the TMGI, or the Destination IP address information of the TMGI until the expiry of T3587. If the MBS back-off timer value indicates that this timer is deactivated, the UE shall not attempt to join the multicast MBS session with the same TMGI until the UE is switched off, the USIM is removed, or the entry in the "list of subscriber data" for the current SNPN is updated. If the MBS back-off timer value indicates zero, the UE may attempt to join the MBS session with the same TMGI; c) if the MBS decision is set to "Remove UE from multicast MBS session", the UE shall consider that it has successfully left the multicast MBS session, and if the received Rejection cause is set to "multicast MBS session is released", the UE shall consider the multicast MBS session as released. Then the UE shall indicate to lower layers to delete the stored TMGI; d) if the MBS decision is set to "MBS service area update", the UE shall store the received MBS service area associated with the received TMGI and replace the current MBS service area with the received one. or e) if the MBS decision is set to "MBS security information update", the UE shall replace the current MBS security information with the MBS security information received in the MBS security container associated with the received TMGI.

[0559] If the UE has indicated support for ECS configuration information provisioning in the SESSION ESTABLISHMENT REQUEST message or while in SI mode, then upon receiving a) one or more ECS IPv4 address(es), ECS IPv6 address(es), ECS FQDN(s); b) one or more associated ECSP identifier(s); c) optionally spatial validity conditions associated with the ECS address; d) optionally, ECS authentication methods associated with the ECS address; and e) optionally, ECS supported PLMNs information list, including the associated ECSP information for which the EDN configuration information can be provided by the ECS. in the Extended protocol configuration options IE of the PDU SESSION MODIFICATION COMMAND message, then the UE shall pass them to the upper layers.

[0560] If the UE supports receiving DNS server addresses in protocol configuration options and receives one or more DNS server IPv4 address(es), one or more DNS server IPv6 address(es) or both of them, in the Extended protocol configuration options IE of the PDU SESSION MODIFICATION COMMAND message, then the UE shall pass the received DNS server IPv4 address(es), if any, and the received DNS server IPv6 address(es), if any, to upper layers.

[0561] NOTE 7: The received DNS server address(es) replace previously provided DNS server address(es), if any.

[0562] If the UE supports the EAS rediscovery and receives: a) the EAS rediscovery indication without indicated impact; or b) the following: 1) one or more EAS rediscovery indication(s) with impacted EAS IPv4 address range, if supported by the UE;

[0563] 2) one or more EAS rediscovery indication(s) with impacted EAS IPv6 address range, if supported by the UE;

[0564] 3) one or more EAS rediscovery indication(s) with impacted EAS FQDN, if supported by the UE; or

[0565] 4) any combination of the above; in the Extended protocol configuration options IE of the PDU SESSION MODIFICATION COMMAND message, then the UE shall pass the EAS rediscovery indication and the received impacted EAS IPv4 address range(s), if supported and included, the received EAS IPv6 address range(s), if supported and included, and the received EAS FQDN(s), if supported and included, to upper layers.

[0566] NOTE 8: The upper layers handle the EAS rediscovery indication and the impacted EAS IPv4 address range(s), if any, the impacted EAS IPv6 address range(s), if any, and the received EAS FQDN(s), if any, according to 3GPP TS 23.548 [10A],

[0567] Upon receipt of PDU SESSION MODIFICATION COMMAND message, if the network-requested PDU session modification procedure is triggered by a UE -requested PDU session modification procedure, the Service-lev el- AA container IE is included, then the UE shall forward the service-level-AA contents of the Service-lev el- A A container IE to the upper layers.

[0568] If the UE supports EDC and receives the EDC usage allowed indicator in the Extended protocol configuration options IE of the PDU SESSION MODIFICATION COMMAND message, the UE shall indicate to upper layers that network allows the use of EDC.

[0569] If the UE supports EDC and receives the EDC usage required indicator in the Extended protocol configuration options IE of the PDU SESSION MODIFICATION COMMAND message, the UE shall indicate to upper layers that network requires the use of EDC.

[0570] NOTE 9: Handling of indication that network allows the use of EDC or that network requires the use of EDC is specified in 3GPP TS 23.548

[0182] .

[0571] If the Alternative S-NSSAI IE is included in the PDU SESSION MODIFICATION COMMAND message, the UE shall replace the S-NSSAI or the mapped S-NSSAI associated with the PDU session according to the Alternative S-NSSAI IE. The S-NSSAI for the established PDU session shall be the S-NSSAI to be replaced and the alternative S- NSSAI on the UE side.

[0572] If the Protocol description IE is included in the PDU SESSION MODIFICATION COMMAND message, for each existing QoS rule, a) for the protocol description field with the value of the length of protocol description field set to 1 for the associated QoS rule, the UE shall delete any previously stored protocol description for the QoS rule indicated by the QRI field of the protocol description field; and b) for the protocol description field with the value of the length of protocol description field greater than 1 for the associated QoS rule, the UE shall, store the associated protocol description if there is no stored protocol description or replace any previously stored protocol description with the new received protocol description when there is stored protocol description for the QoS rule.

[0573] The UE may use the protocol description information associated with the QoS rule(s) provided by the Protocol description IE to identify PDUs belonging to PDU sets for the uplink direction.

[0574] NOTE 10: Whether and how to use the protocol description information to identify PDU sets is up to the UE implementation.

[0575] Upon receipt of a PDU SESSION MODIFICATION COMMAND message with the Non-3GPP device connection notify IE, the UE supporting the Non-3GPP device connection information IE shall disconnect one or more non-3GPP devices identified by the one or more non-3GPP device identifier(s) included in the Non-3GPP device connection notify IE.

[0576] The UE shall transport the PDU SESSION MODIFICATION COMPLETE message and the PDU session ID, using the NAS transport procedure as specified in subclause 5.4.5.

[0577] After sending the PDU SESSION MODIFICATION COMPLETE message, if the "Create new EPS bearer" operation code in the Mapped EPS bearer contexts IE was received in the PDU SESSION MODIFICATION COMMAND message and there is neither a corresponding Authorized QoS flow descriptions IE in the PDU SESSION MODIFICATION COMMAND message nor an existing QoS flow description corresponding to the EPS bearer identity included in the mapped EPS bearer context, the UE shall send a PDU SESSION MODIFICATION REQUEST message including a Mapped EPS bearer contexts IE to delete the mapped EPS bearer context. After sending the PDU SESSION MODIFICATION COMPLETE message, if for the PDU session being modified, there are mapped EPS bearer context(s) but none of them is associated with the default QoS rule, the UE shall locally delete the mapped EPS bearer context(s) and shall locally delete the stored EPS bearer identity (EBI) in all the QoS flow descriptions of the PDU session, if any.

[0578] If a port management information container needs to be delivered (see 3GPP TS 23.501 [8] and 3GPP TS 23.502 [9]), the UE shall include a Port management information container IE in the PDU SESSION MODIFICATION COMPLETE message.

[0579] Upon receipt of a PDU SESSION MODIFICATION COMPLETE message, the SMF shall stop timer T3591 and shall consider the PDU session as modified. If the selected SSC mode of the PDU session is "SSC mode 3" and the PDU SESSION MODIFICATION COMMAND message included 5GSM cause #39 "reactivation requested", the SMF shall start timer T3593. If the PDU Session Address Lifetime value is sent to the UE in the PDU SESSION MODIFICATION COMMAND message then timer T3593 shall be started with the same value, otherwise it shall use a default value. If the

[0580] PDU SESSION MODIFICATION COMPLETE message contains a Port management information container IE, the SMF shall handle the contents of the Port management information container IE as specified in 3GPP TS 23.501 [8] and 3GPP TS 23.502 [9].

[0581] Next Change 8.3.9.1 Message Definition

[0582] The PDU SESSION MODIFICATION COMMAND message is sent by the SMF to the UE to indicate a modification of a PDU session. See table 8.3.9.1.1.

[0583] Message type: PDU SESSION MODIFICATION COMMAND

[0584] Significance: dual Direction: network to UE

[0585] Table 8.3.9.1.1: PDU SESSION MODIFICATION COMMAND message content

[0586] NOTE: It is possible for networks compliant with version 15.2.1 or earlier versions of this specification to send the Mapped EPS bearer contexts IE with IEI of value "7F" for this message. 8.3.9.yy Non-3GPP device connection notify

[0587] This IE shall be included when the network needs to notify the UE that one or more non-3GPP device identifier(s) are not authorized.

[0588] 9.11.4.xx Non-3GPP device connection notify

[0589] The purpose of the Non-3GPP device connection notify information element is for SMF to provide one or more non-3GPP device identifier(s) are not authorized.

[0590] The Non-3GPP device connection notify information element is coded as shown in figure 9.11.4.XX.1 and table 9.11.4.xx.l.

[0591] The Non-3GPP device connection notify is a type 4 information element with a minimum length of 4 octets. 8 7 6 5 4 3 2 1

[0592] As will be appreciated by one of skill in the art, the concepts described herein may be embodied as a method, data processing system, computer program product and / or computer storage media storing an executable computer program. Accordingly, the concepts described herein may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects all generally referred to herein as a “circuit” or “module.” Any process, step, action and / or functionality described herein may be performed by, and / or associated to, a corresponding module, which may be implemented in software and / or firmware and / or hardware. Furthermore, the disclosure may take the form of a computer program product on a tangible computer usable storage medium having computer program code embodied in the medium that can be executed by a computer. Any suitable tangible computer readable medium may be utilized including hard disks, CD-ROMs, electronic storage devices, optical storage devices, or magnetic storage devices.

[0593] Some embodiments are described herein with reference to flowchart illustrations and / or block diagrams of methods, systems and computer program products. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer (to thereby create a special purpose computer), special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0594] These computer program instructions may also be stored in a computer readable memory or storage medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instruction means which implement the function / act specified in the flowchart and / or block diagram block or blocks.

[0595] The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0596] It is to be understood that the functions / acts noted in the blocks may occur out of the order noted in the operational illustrations. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality / acts involved. Although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

[0597] Computer program code for carrying out operations of the concepts described herein may be written in an object oriented programming language such as Python, Java® or C++. However, the computer program code for carrying out operations of the disclosure may also be written in conventional procedural programming languages, such as the "C" programming language. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0598] Many different embodiments have been disclosed herein, in connection with the above description and the drawings. It will be understood that it would be unduly repetitious and obfuscating to literally describe and illustrate every combination and subcombination of these embodiments. Accordingly, all embodiments can be combined in any way and / or combination, and the present specification, including the drawings, shall be construed to constitute a complete written description of all combinations and subcombinations of the embodiments described herein, and of the manner and process of making and using them, and shall support claims to any such combination or subcombination.

[0599] Abbreviations that may be used in the preceding description include:

[0600] 5GC 5G Core

[0601] 5G-RG 5G residential gateway

[0602] AMF Access & Mobility Management Function

[0603] MO Management Object

[0604] NAS Non-Access Stratum

[0605] SMF Session Management Function

[0606] RG Residential Gateway

[0607] PCF Policy Control function UE User Equipment

[0608] UDM Unified Data Management

[0609] UDR Unified Data Repository

[0610] UPF User Plane Function It will be appreciated by persons skilled in the art that the embodiments described herein are not limited to what has been particularly shown and described herein above. In addition, unless mention was made above to the contrary, it should be noted that all of the accompanying drawings are not to scale. A variety of modifications and variations are possible in light of the above teachings without departing from the scope of the following claims.

Claims

CLAIMS1. A method implemented by a policy control function, PCF, node (16e5), the method comprising: receiving (S 110) a request message associated with a third generation partnership projection, 3GPP, network, the request message comprising at least one identifier associated with at least one non-3GPP device (24) that is in communication with a 3GPP UE (22); rejecting (S 112) a request associated with the request message for a cause associated with at least one of the at least one identifier: being absent from a network; or causing a number of identifiers associated with non-3GPP devices (24) to exceed a threshold; indicating (SI 14), to a session management function, SMF, node (16e4), the cause.

2. The method of Claim 1, wherein the cause for rejecting the request corresponds to the at least one of the at least one identifier associated with the at least one non-3GPP device (24) being unavailable.

3. The method of Claim 1, wherein the cause for rejecting the request corresponds to the at least one of the at least one identifier associated with the at least one non-3GPP device (24) causing a number of identifiers associated with non-3GPP devices connected to the 3 GPP UE to exceed a maximum number of non-3GPP device identifiers that corresponds to the threshold.

4. The method of any one of Claims 1-3, wherein the request associated with the request message is a request for quality of service, QoS, differentiation for network traffic associated with the at least one of the at least one identifier associated with at least one non-3GPP device (24).

5. The method of any one of Claims 1-4, wherein the request message is a session management, SM, policy association establishment message or a SM policy association modification message associated with quality of service, QoS, differentiation for at least one non-3GPP device connected to the 3 GPP UE (22).

6. The method of any one of Claims 1-5, wherein the indication of the cause, to the SMF node (16e4), is provided by a cause code that is configured to notify the 3GPPUE (22) of the cause for rejecting the request.

7. The method of any one of Claims 1-6, further comprising updating identifiable non-3GPP devices control data in a unified data repository, UDR, node ( 16e3) based on the request message.

8. The method of any one of Claims 1-7, further comprising receiving, from an unified data repository, UDR, node ( 16e3), information of subscribed identifiers; and the cause for rejecting the request is associated with the request message being based on the at least one of the at least one identifier associated with the at least one non- 3GPP device (24) not being present in the information of subscribed identifiers.

9. A policy control function, PCF, node (16e5) configured to: receive a request message associated with a third generation partnership projection, 3GPP, network, the request message comprising at least one identifier associated with at least one non-3GPP device (24) that is in communication with a 3GPP UE (22); reject a request associated with the request message for a cause associated with at least one of the at least one identifier: being absent from a network; or causing a number of identifiers associated with non-3GPP devices (24) to exceed a threshold; indicate, to a session management function, SMF, node (16e4), the cause.

10. The PCF node ( 16e5) of Claim 9, wherein the cause for rejecting the request corresponds to the at least one of the at least one identifier associated with the at least one non-3GPP device (24) being unavailable.

11. The PCF node ( 16e5) of Claim 9, wherein the cause for rejecting the request corresponds to the at least one of the at least one identifier associated with the at least one non-3GPP device (24) causing a number of identifiers associated with non-3GPPdevices connected to the 3 GPP UE to exceed a maximum number of non-3GPP device identifiers that corresponds that corresponds to the threshold.

12. The PCF node (16e5) of any one of Claims 9-11, wherein the request associated with the request message is a request for quality of service, QoS, differentiation for network traffic associated with the at least one of the at least one identifier associated with at least one non-3GPP device (24).

13. The PCF node (16e5) of any one of Claims 9-12, wherein the request message is a session management, SM, policy association establishment message or a SM policy association modification message associated with quality of service, QoS, differentiation for at least one non-3GPP device connected to the 3GPP UE (22).

14. The PCF node (16e5) of any one of Claims 9-13, wherein the indication of the cause, to the SMF node (16e4), is provided by a cause code that is configured to notify the 3GPP UE (22) of the cause for rejecting the request.

15. The PCF node (16e5) of any one of Claims 9-14, wherein the PCF node( 16e5) is configured to update identifiable non-3GPP devices control data in a unified data repository, UDR, node (16e3) based on the request message.

16. The PCF node (16e5) of any one of Claims 9-15, wherein the PCF node (16e5) is configured to receive, from an unified data repository, UDR, node ( 16e3), information of subscribed identifiers; and the cause for rejecting the request is associated with the request message being based on the at least one of the at least one identifier associated with the at least one non- 3GPP device (24) not being present in the information of subscribed identifiers.

Images