Communication configuration of a personal IoT network

Abstract

A method implemented on a user device (UE) that includes servicing a Personal Internet of Things (IoT) Network (PIN) element (PINE) associated with a PIN to provide a direct connection between the PINE and the UE acting as a PINE with gateway functionality (PEGC); receiving Internet Protocol (IP) packets at the UE via a core network (CN); and routing the IP packets to the PINE, taking into account the IP packet headers.

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims priority to (1) U.S. Provisional Patent Application No. 63 / 493,723, entitled "METHOD OF HANDLING COMMUNICATION CONFIGURATION FOR PERSONAL IOT NETWORK", filed on March 31, 2023, and (2) U.S. Provisional Patent Application No. 63 / 495,074, entitled "METHOD OF HANDLING COMMUNICATION CONFIGURATION FOR PERSONAL IOT NETWORK IN 5G SYSTEM", filed on April 7, 2023, and claims the benefit of their filing dates. The entire contents of those provisional applications are hereby expressly incorporated by reference herein.

[0002] This disclosure generally relates to methods, devices, and articles in wireless communication systems such as 3GPP (registered trademark) communication systems, and more particularly to handling personal Internet of Things (IoT) network (PIN) traffic.

Background Art

[0003] This description of the background art is provided to generally illustrate the background of the present disclosure. Within the scope described in this background art section, the achievements of the inventors named herein, as well as aspects of this specification that may not meet the requirements of prior art at the time of filing, are not expressly or implicitly admitted as prior art to the present disclosure.

[0004] Generally, within a personal IoT network (PIN), a PIN element with a gateway function (PEGC) can provide 5G connectivity to PIN elements (PINE) connected to the PEGC (i.e., "behind the PEGC"). The PEGC enables PINEs within the same PIN to communicate with each other across different PEGCs via the 5G core network (CN).

[0005] A PIN may include at least one PEGC. A PEGC may support one or more PINs. A PEGC is a PIN member. A PIN may be a 3GPP user device (UE) (e.g., using sidelink communication via the PC5 interface) or a non-3GPP device connected to a PEGC (e.g., using Wi-Fi, Bluetooth). A non-3GPP device may support IP-based connectivity (e.g., Wi-Fi, Bluetooth Low Energy) or non-IP-based connectivity (e.g., Bluetooth).

[0006] However, direct communication between IP-based and non-IP-based devices is only possible by routing PIN traffic locally through the PEGC. While multiple PEGCs can exist for a single PIN, it is unclear how devices can implement inter-PIN communication across different PEGCs via 5G CN.

[0007] In a scenario where there are multiple PINs within a Public Land Mobile Network (PLMN) and multiple PEGCs within a PIN, there is no clear mechanism in either the PEGC or the CN to identify the PIN and the PINE connected to the PEGC for the purpose of routing PIN traffic to the destination PINE connected to the PEGC. Furthermore, there is no clear mechanism to coordinate PIN communication configuration information among the various network functions (NFs) of the PEGC and CN, and / or functions provided by third-party entities. [Overview of the project] [Means for solving the problem]

[0008] An exemplary embodiment of the technology of the present disclosure is a method implemented in a user device (UE), which includes servicing a PIN element (PINE) associated with a Personal Internet of Things (IoT) network (PIN) to provide a direct connection between the PINE and the UE acting as a PINE with gateway functionality (PEGC), receiving Internet Protocol (IP) packets at the UE via a core network (CN), and routing the IP packets to the PINE, taking into account the headers of the IP packets.

[0009] Another exemplary embodiment of these technologies is a method implemented in the network function (NF) of a core network (CN), which includes receiving a Personal Internet of Things (IoT) network (PIN) communication configuration in the NF, the PIN communication configuration including (i) an identifier for the PIN, (ii) a UE ID that identifies a user device (UE) associated with the PIN and acting as a PIN element with gateway functionality (PINE) (PEGC), and (iii) a PINE ID that identifies the PINE within a PIN subgroup of the PEGC, and the method further includes configuring the CN to route IP packets addressed to the PINE.

[0010] Another exemplary embodiment of these technologies is a user device (UE) comprising a transceiver and processing hardware, the UE being configured to implement one of the methods described above. [Brief explanation of the drawing]

[0011] [Figure 1] This is a block diagram of an exemplary wireless communication system that can implement one or more of the techniques of the present disclosure for processing PINE-to-PINE communication. [Figure 2] Figure 1 is a block diagram of an exemplary protocol stack that enables the UE to communicate with the RAN in Figure 1. [Figure 3]Figure 1 shows a service-based representation of the CN architecture that can be implemented by the system. [Figure 4] Figure 1 shows a reference point-based representation of the CN architecture that can be implemented by the system. [Figure 5] This is a flowchart illustrating an exemplary method for identifying a destination PINE. [Figure 6] This disclosure shows exemplary IPv6 header components that the UE and / or NF may use to route PIN traffic. [Figure 7] This is a messaging diagram illustrating an exemplary process for coordinating UE-based PIN communication configuration information. [Figure 8] This is a flowchart illustrating an exemplary method for adjusting UE-based PIN communication configuration information. [Figure 9] This is a messaging diagram of another exemplary process for coordinating UE-based PIN communication configuration information. [Figure 10] This is a flowchart illustrating an exemplary method for adjusting UE-based PIN communication configuration information. [Figure 11] This is a messaging diagram illustrating an exemplary process for adjusting UDM-based PIN communication configuration information. [Figure 12] This is a flowchart illustrating an exemplary method for adjusting UDM-based PIN communication configuration information. [Figure 13] This is a messaging diagram of another exemplary process for adjusting UDM-based PIN communication configuration information. [Figure 14] This is a flowchart illustrating an exemplary method for adjusting UDM-based PIN communication configuration information. [Figure 15] This is a messaging diagram of another exemplary process for adjusting UDM-based PIN communication configuration information. [Figure 16] This is a flowchart illustrating an exemplary method for adjusting UDM-based PIN communication configuration information. [Figure 17]Message diagram of an exemplary process for adjusting AF-based PIN communication configuration information according to some embodiments. [Figure 18] Flow diagram of an exemplary method for adjusting AF-based PIN communication configuration information. [Figure 19] Message diagram of another exemplary process for adjusting AF-based PIN communication configuration information. [Figure 20A] Message diagram of an exemplary process of PIN communication using frame routing. [Figure 20B] Message diagram following FIG. 20A. [Figure 21] Flow diagram of PIN communication using frame routing.

Best Mode for Carrying Out the Invention

[0012] The devices described below support PIN communication configuration information for communication between PINEs. As will be described in detail below, the PIN communication configuration information includes the information necessary to identify the PINs and PINEs in order to route PIN traffic. The present disclosure further provides how the PIN communication configuration information is generated and adjusted between various NFs of PEGC (e.g., UE) and CN.

[0013] As used herein, communication between PINEs is communication between two PINEs. The communication may be direct communication between PINEs or indirect communication between PINEs.

[0014] As used herein, direct communication between PINEs is communication between two PINEs where neither PEGC, 3GPP RAN, nor UPF is present in between.

[0015] As used herein, indirect communication between PINEs is communication between two PINEs via PEGC or via PEGC and UPF. <00A0102>

[0016] While this disclosure uses a 5G network as an example, you should understand that the principles of this disclosure are generally applicable to 3G, 4G, 6G, and next-generation networks.

[0017] Referring first to Figure 1, the exemplary wireless communication system 100 can implement one or more of the techniques of this disclosure for handling inter-PINE communication. The exemplary wireless communication system 100 includes UEs 102A, 102B, and 102C, PINEs 108A, 108B, and 108C, base stations (BS) 104, base station 106, and a core network (CN) 110 such as a fifth-generation (5G) core (5GC). Base stations 104 and 106 can operate in RAN 105 connected to CN 110. CN 110 can also be implemented as a sixth-generation (6G) core or other suitable core network.

[0018] Base station 104 covers cell 124, and base station 106 covers cell 126. If base station 104 is a gNB, cell 124 is an NR cell. If base station 124 is an ng-eNB, cell 124 is an E-UTRA (evolved universal terrestrial radio access) cell. Similarly, if base station 106 is a gNB, cell 126 is an NR cell, and if base station 126 is an ng-eNB, cell 126 is an E-UTRA cell. Cells 124 and 126 may be in the same Radio Access Network Notice Area (RNA) or different RNAs. Cells 124 and 126 may partially overlap, and as a result, UE 102A, 102B, or 102C may select, reselect, or hand over from one of cells 124 and 126 to the other. In general, RAN105 can contain any number of base stations, each of which can cover one, two, three, or any other suitable number of cells. UE102 can support at least a 5G NR (or simply "NR") air interface to communicate with base stations 104 and 106. Each of base stations 104 and 106 can connect to CN110 via an interface (e.g., S1 or NG interface). Base stations 104 and 106 can also interconnect via an interface (e.g., X2 or Xn interface) for interconnecting NG RAN nodes.

[0019] Several network functions (NFs) that make up the CN110 are described below with reference to Figures 3 and 4. One or more of the CN110's NFs coordinate inter-PINE communication as described below.

[0020] Although not shown in Figure 1 for the sake of simplicity, the CN110 may include processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and non-temporary computer-readable memory for storing instructions executed by the one or more general-purpose processors. Additionally or alternatively, the processing hardware may include a special-purpose processing unit. The processing hardware may be configured to implement the techniques of this disclosure for processing PINE-to-PINE communication.

[0021] The base station 104 includes processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and non-temporary computer-readable memory for storing instructions executed by the one or more general-purpose processors (not shown). Additionally or alternatively, the processing hardware may include a special-purpose processing unit.

[0022] UE102A comprises processing hardware 130A, which may include one or more general-purpose processors such as a CPU, and non-temporary computer-readable memory for storing machine-readable instructions executable on one or more general-purpose processors and / or special-purpose processing units. UE102A also includes a transceiver 132A for communicating with RAN105 via a wireless interface. Furthermore, UE102A includes memory 134A for storing a PEGC module 142A and a PDU controller 140A. Using the PEGC module 142 and the necessary hardware components (which may be included in or in addition to the processing hardware 130A and / or the transceiver 132A), UE102A is a PEGC that can provide data network (DN) connectivity over a network (e.g., a 5G network) for PINEs (such as PINE108A) and / or provide relay functionality for communication between PINEs (such as between PINE108A and 108B, or between PINE108A and 108C). UE102B may be configured similarly to UE102A. UE102B may, among other things, include the PEGC module 142B. UE102C may be configured similarly to UE102A. UE102C may, among other things, include the PEGC module 142C.

[0023] UE102A is configured to support PIN122A. PIN122A is a group of configured and managed PINEs (including PINE108A) that can (1) communicate directly with each other or via PEGCs (including UE108A and 108B), or (2) communicate with devices or servers outside the PIN via a 5G network using PEGCs. Generally speaking, a PIN is managed by a PINE (i.e., PEMC(s)) with management capabilities, including at least one PEGC. If an Application Function (AF) is deployed for the PEMC, PIN management can be achieved with the support of the Application Function (AF). It will be understood that PIN122A may include multiple PINEs supported by multiple PEGCs and multiple PEMCs. It will also be understood that multiple PINEs may be connected to UE102A. In the illustrated example, PIN122A is also supported by UE102B. PIN122B may be configured similarly to PIN122A. In the illustrated example, PIN122B is supported by UE102C and includes PINE122B.

[0024] PINE108A is a 3GPP UE or non-3GPP device and can communicate within PIN120 (via direct or indirect connections between PINs) or outside PIN120 via PEGC and CN (such as CN110). In the illustrated example, PINE108A is connected to UE102A. PINE108B may be configured similarly to PINE108A. In the illustrated example, PINE108B is connected to UE102B. PINE108C may be configured similarly to PINE108A. In the illustrated example, PINE108C is connected to UE102C.

[0025] Figure 2 shows an exemplary protocol stack 200 in which UE102A, 102B, or 102C can communicate with an eNB / ng-eNB230 or gNB232 (e.g., one or more of base stations 104, 106) in a simplified manner. In the exemplary stack 200, the EUTRA physical layer (PHY) 202A provides a transport channel to the EUTRA MAC sublayer 204A, which in turn provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides an RLC channel to the EUTRA PDCP sublayer 208, and optionally to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides a transport channel to the NR MAC sublayer 204B, which in turn provides a logical channel to the NR RLC sublayer 206B. The NR RLC sublayer 206B then provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 can then provide data transfer services to the Service Data Adaptation Protocol (SDAP) 212 or the Radio Resource Control (RRC) sublayer (not shown in Figure 2). In some embodiments, the UE 102A, 102B, or 102C supports both the EUTRA stack and the NR stack, as shown in Figure 2, to support handover between EUTRA base stations and NR base stations, and / or to support DCs through EUTRA and NR interfaces. Furthermore, as shown in Figure 2, the UE 102A or 102B can support layering of the NR PDCP 210 on top of the EUTRA RLC 206A, and the SDAP sublayer 212 on top of the NR PDCP sublayer 210.

[0026] EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 receive packets that may be referred to as Service Data Units (SDUs) (e.g., from the Internet Protocol (IP) layer, which is layered directly or indirectly on top of PDCP layer 208 or 210) and output packets that may be referred to as Protocol Data Units (PDUs) (e.g., to RLC layer 206A or 206B). For simplicity, this disclosure refers to both SDUs and PDUs as “packets,” except where the difference between SDUs and PDUs is relevant.

[0027] On the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide, for example, a signaling radio bearer (SRB) or an RRC sublayer (not shown in Figure 2) for exchanging RRC messages or non-access layer (NAS) messages. On the user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide a data radio bearer (DRB) to support data exchange. The data exchanged on the NR PDCP sublayer 210 may be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0028] Figure 3 is a service-based representation 300 of an exemplary CN architecture that the system in Figure 1 can implement. In representation 300, the overall non-roaming reference architecture of the Policy and Billing Control (PCC) framework for 5GS includes components shown in solid lines, while other components are shown in dashed lines. According to this representation, network functions enable other authorized network functions to access their services. Components outside the PCC framework include the Network Slicing Selection Function (NSSF) 302, Network Repository Function (NRF) 306, Centralized Data Management (UDM) 308, Edge Application Server Discovery Function (EASDF) 310, Network Slice Specific Authentication and Authorization Function (NSSAAF) 312, Authentication Server Function (AUSF) 314, Service Communication Proxy (SCP) 316, and Network Slice Admission Control Function (NSACF) 318. The non-PCC architecture further includes UE102A and 102B, PINE108A and 108B, and (R)AN105.

[0029] The PCC framework within Architecture 300 includes a Central Data Repository (UDR) 352, Network Exposure Function (NEF) 354, Network Data Analysis Function (NWDAF) 356, Application Function (AF) 358, Policy Control Function (PCF) 360, Billing Function (CHF) 362, Access and Mobility Management Function (AMF) 364, Session Management Function (SMF) 366, and User Plane Function (UPF) 370.

[0030] The AMF364 is generally configured to manage the registration, connection, and mobility of UEs (such as UE102A or 102B) and to provide transport for session management (SM) messages between the UE102A or 102B and the SMF366. In some embodiments, the AMF364 is configured to generate logical interface IDs, as described in detail below.

[0031] The SMF366 is generally configured to manage sessions, assign IP addresses to UEs, and provide downlink (DL) notifications. In some embodiments, the SMF366 also includes the following functions for PIN services: namely, providing non-3GPP QoS supplementary information per QoS flow to the UE (e.g., PEGC), assigning IP addresses to the UE, and supporting a PDR configuration with a packet filter set for PIN to the UPF for framed routing based on PIN group information from the UDM308.

[0032] The UDM308 is generally configured to handle user identification, access authorization based on subscription data, and subscription management. In some embodiments, the UDM308 is configured to generate or modify logical interface IDs, as described in detail below. In some embodiments, the UDM308 supports PIN group management processing functionality.

[0033] The UDR352 is generally configured to store subscription-related information, such as subscription data, policy data, structured data for publication, and application data. In some embodiments, the UDR352 is configured to store PIN communication configuration information, as described in detail below.

[0034] The UPF370 is generally configured to handle packet routing and forwarding. In some embodiments, the UPF370 includes the ability to support a PDR configuration with a packet filter set for PINs.

[0035] The NEF354 is typically configured to expose network functions and services to authorized third-party applications.

[0036] In some deployments, AF358 operates within a trusted domain 311, or outside of a trusted domain 311, i.e., in an untrusted domain. Trusted domain 311 is generally located within CN110 and includes components such as UDM308, UDR352, PCF360, AMF364, SMF366, and UPF370. Generally speaking, an AF operating outside of a trusted domain 311 (e.g., operated by an authorized third-party entity) can only access the network functions of CN110 via NEF354, while an AF operating within a trusted domain 311 can directly access at least some of the network functions of CN110, or, in some deployments, access these functions via NEF354. In some deployments, AF358 is included in the PIN application server 390.

[0037] UE102A(PEGC) or AF358 may provide QoS flow parameters to CN110. AF358, which supports PIN services, may also influence traffic routing for PDU sessions for PIN traffic. PIN traffic can be classified into the following types: (1) between two PINEs via the 5G core network when two PINEs connect to different PEGCs, (2) between a PINE and a PEMC via the PEGC and the 5G core network, (3) between a PINE and a DN via the PEGC and the 5G core network, and (4) between a PEGC and a DN via the 5G core network.

[0038] When deployed for PEMC, the UE102A(PEGC) or AF358 can manage PINs and PINEs using user plane traffic, including PIN traffic or non-PIN traffic, "above" (tiered higher) the available connections. Available connections include (1) between two PINEs using direct or indirect PINE-to-PINE communication in the case of PIN / PINE managed by PEMC on a PINE, or (2) between the PINE where the AF358 is located and the DN via PEGC and 5GCN in the case of PIN / PINE managed by AF.

[0039] UE102A may support PDU sessions(s) associated with non-PIN services and PDU sessions(s) associated with PIN services. When the request is for a PIN service, UE102A may include a PIN service instruction in the PDU session establishment request message that triggers PIN session management within the 5G core network.

[0040] A single PEGC may serve multiple PINs. In such a scenario, if PIN traffic passes through the PEGC / 5GC (5G core network), the PEGC may have at least one PDU session for each PIN. Based on the operator's policies and URSP rules, a single PEGC serving multiple PINs may have one PDU session for each PIN, or it may share one PDU session for PIN services. In a scenario where multiple PDU sessions communicate with the same DNN and S-NSSAI for different PINs, the PEGC will indicate the PIN ID as one of the PDU session attributes in the PDU session establishment / modification request.

[0041] A single PIN may be serviced by multiple PDU sessions for a PEGC. Based on operator policies and URSP rules, a single PEGC serving a single PIN may use different PDU sessions for different groups of PINs.

[0042] If a PDU session establishment / modification request is for a PIN service, the SMF may request a PIN subscription for the PEGC from the UDM to (1) perform IP address assignment to the PIN or PINE group of the PIN, and (2) configure the UPF with a PDR that includes a packet filter set indicating the destination PIN, for example, using an external group identifier or IP address group, or the destination group of PINEs within the same PIN. For IP PDU session types, the packet filter set may support packet filtering based on (1) source / destination IP address or IPv6 prefix, (2) source / destination port number, (3) protocol ID / next header type of the IP higher-level protocol, (3) service type (TOS) (IPv4) / traffic class (IPv6) and mask, (4) flow label (IPv6), (5) security parameter index, (6) packet filter direction, and / or (7) any combination of source / destination PIN IP address or IPv6 prefix.

[0043] In the case of indirect communication between PINEs, PEGC may route PIN traffic to the destination PIN (in scenarios where multiple PINs share a PDU session) or to a PIN subgroup (in scenarios where multiple PDU sessions support a single PIN) based on IP header information. Finally, PEGC may forward PIN traffic to the destination PINE (including UEs or non-3GPP devices) based on the destination PINE's IP address information, for example, based on the MAC address mapped from the virtual interface ID in the IPv6 header.

[0044] For PIN traffic, PEGC displays the PIN ID to distinguish PDU sessions that use the same DNN and S-NSSAI for different PINs.

[0045] Figure 4 is a reference point-based representation of an exemplary 5GS architecture. In Figure 4, the non-roaming reference architecture of the PCC framework for 5GS is shown as solid block and connection, while external components and connections of the PCC framework are shown as dashed lines.

[0046] The communication systems shown in Figures 1-4 may include additional, fewer, and / or alternative devices or functions, and may be configured to perform additional, fewer, or alternative actions, including the functions / actions described herein.

[0047] Exemplary techniques for identifying PINs and / or PINEs for PINE-to-PINE communication are described with illustrative reference to Figure 5. These techniques may be used in combination with or independently of the techniques described above, depending on the embodiment or scenario.

[0048] Generally, the CN and UE can use the information presented in the IP packet header to process PIN traffic routing. The IP packet may be an IPv4 packet or an IPv6 packet. Correspondingly, the header may be an IPv4 header or an IPv6 header. The IP payload (either an IPv4 payload or an IPv6 payload) may encapsulate IP packets sent by PINE using IP-based connectivity and non-IP packets sent by PINE using non-IP-based connectivity.

[0049] To support inter-PINE communication within a PIN via CN, some NFs of the CN are configured in the following way in an exemplary embodiment:

[0050] (1) The AF holds group information related to the PIN, UE with PEGC, and PINE. The AF also enables the application to provide PINE-to-PINE communication between PIN group members.

[0051] (2) The CN manages PIN group subscriptions, PIN service subscriptions for UEs with PEGC, PIN service session management, PIN service policies, and traffic routing for PIN communications.

[0052] (3) The UE (PEGC) handles PINE connectivity and PINE session management behind the UE using one or more PINs.

[0053] The UE (PEGC), CN, and AF coordinate using at least one of the following PIN communication configuration information: (1) PIN ID, (2) UE with a PEGC identified by GPSI or SUPI as a PIN group member, and (3) PINE ID associated with the PEGC as a PIN subgroup member.

[0054] In the case of a PIN, the PINE serviced by the UE (PEGC) can use either IP-based connectivity (e.g., Wi-Fi) or non-IP-based connectivity (e.g., Bluetooth). The PINE ID allows the UE with the PEGC connected to the PINE to uniquely identify the PINE within the associated PIN.

[0055] The aforementioned PIN communication configuration information enables inter-PINE communication between IP-based PINEs and non-IP-based PINEs. For example, an IP-based PINE (e.g., a front doorbell connected to a UE with a PEGC via Wi-Fi) can send messages to a non-IP-based PINE (e.g., a pair of earphones connected to the same or different UE with a PEGC via Bluetooth), and / or other IP-based PINEs (a smart home device connected to the same or different UE (PEGC) via Wi-Fi) using the above PIN communication configuration information.

[0056] In some embodiments, the UE (PEGC) locally stores PIN communication configuration information. The UE (PEGC) uses the PIN communication configuration information of the PIN service layer to route IP packets to the destination PIN based on the PINE ID in the IP packet header. The PIN service layer exists between the 3GPP NAS layer and the application layer and is, for example, a PIN connection manager in the operating system (OS) or a PIN service controller in the application processor.

[0057] The UE (PEGC) has routing capabilities to connect the 3GPP network and the PIN and handle PIN communication. For this purpose, the UE can perform static routing between destination PINE addresses and the logical interface IDs of the connected PINEs based on a mapping table stored in the UE. Alternatively, the UE can perform dynamic routing (for example, using DHCP functionality from a pool of assigned IP addresses) to manage the routing table (for example, stored in the UE) between destination PINE addresses and the logical interface IDs of the connected PINEs.

[0058] The logical interface ID may be generated by the UE (e.g., a UE with PEGC), AF, or Central Data Management (UDM), as described in detail below. The logical interface ID may be generated in various ways. For example, the UE, AF, or UDM may (1) use the MAC address of the PINE, which is a 48-bit unique link layer identifier (e.g., a Bluetooth MAC address or a Wi-Fi MAC address), and (2) add "FFFE" in the middle to form a 64-bit logical interface ID. Another example is that the UE, AF, or UDM may (1) use the hashed MAC address of the PINE, and (2) add "FFFE" in the middle to form a 64-bit logical interface ID. In this way, the interface ID maintains its uniqueness and protects the privacy of the PINE. Yet another example is that the UE, AF, or UDM may use a random number generator to generate a 64-bit logical interface ID. A randomly generated logical interface ID protects the privacy of the PINE. The UE, AF, or UDM may create a mapping table between the logical interface ID and the PINE's MAC address to maintain the uniqueness of the logical interface ID and the association between the PINE's MAC address and the logical interface ID.

[0059] Figure 5 is a flowchart illustrating an exemplary method by which a UE (PEGC) (e.g., UE102A, 102B, or 102C) identifies the destination PINE based on information within an IP packet. For simplicity, the process is described using an IPv6 packet as an example. However, these techniques can generally be applied to IPv4 packets or any other suitable version of the IP protocol.

[0060] In block 502, the UE receives an IPv6 packet. The UE may receive IPv6 packets from the PINE via other UEs (PEGCs) on the same PIN. For example, UE102A receives an IP packet from PINE108B via UE102B. Alternatively, the UE may receive an IP packet from the PINE via other UEs (PEGCs) on different PINs. For example, UE102A receives an IP packet from PINE108C via UE102C. In either case, the CN may coordinate the inter-PINE communication, as will be explained in detail below.

[0061] In block 504, the UE processes the IPv6 header of the received IP packet. The IPv6 header contains information about the destination device. The IPv6 header is described in more detail below with reference to Figure 6. In block 506, based on the information about the destination device obtained by processing the IPv6 header, the UE determines whether the IPv6 packet is (a) destined for the UE or (b) destined for a PINE in PIN, of which the UE is a group member. If the IPv6 packet is destined for the UE, in block 508, the UE processes the packet as it would any other IP packet destined for the UE.

[0062] If the IP packet is destined for a PINE connected to the UE, in block 510, the UE obtains the logical interface ID from the processed IPv6 header. In block 512, the UE resolves the identifier of the destination PINE. In some embodiments, the identifier is the MAC address of the destination PINE. Based on how the interface ID was generated as described above, the UE may resolve the MAC address by (1) directly from the interface (e.g., by removing the intermediate "FFFE" from the logical interface ID), (2) based on a hash table (e.g., after removing the intermediate "FFFE" from the logical interface ID), or (3) based on a mapping table stored in the UE. In block 514, based on the MAC address, the UE routes the IP packet to the destination PINE.

[0063] Figure 6 shows the components of an IPv6 header 600. Several exemplary techniques for identifying the destination PIN and destination PINE using the IPv6 header are described below. In general, similar principles can be applied to the IPv4 header or any other suitable version of the IP protocol.

[0064] In some embodiments, the destination PINE can be identified based on the destination address field 616 in the IPv6 header 600. In such embodiments, the PINE ID is the logical interface ID associated with the PINE (either an IP-based PINE or a non-IP-based IP). The IPv6 address (128 bits) of the PINE is constructed using the IPv6 prefix (first 64 bits) and the logical interface ID (last 64 bits) of the PINE. The source address field 614 indicates the IPv6 address of the source PINE ID of the source PINE (e.g., the PINE sending the IP packet). The destination address field 616 indicates the IPv6 address of the destination PINE ID of the destination PINE (e.g., the PINE receiving the IP packet). The following header field 610 indicates an assigned value pointing to a specific extension header in the extension header field 618. The specific extension header indicates the PIN ID of the destination PINE.

[0065] In some embodiments, the destination PINE can be identified based on a specific extension header in the IPv6 header 600. In such embodiments, the source address field 614 indicates the IPv6 address of the source UE (PEGC) (e.g., the UE that receives the IP packet from the source PINE and sends that IP packet to the destination UE). The destination address field 616 indicates the IPv6 address of the destination UE (PEGC) (e.g., the UE that receives the IP packet from the source UE and sends that IP packet to the destination PINE). The following header field 610 indicates an assigned value that points to a specific extension header in the extension header field 618. The specific extension header indicates the PIN ID of the destination PIN, the source PINE ID of the source PINE, and the destination PINE ID of the destination PINE. In these embodiments, the PIN communication configuration information further includes an assigned value for a specific extension header used for the PIN service, which is unique within its Public Land Mobile Network (PLMN) or globally.

[0066] Next, exemplary techniques for adjusting PIN configuration information will be described with illustrative reference to Figures 7 to 10. These techniques can be used in combination with or separately from the techniques described above, depending on the embodiment or scenario.

[0067] A CN (for example, the UDM of the CN) can store PIN communication configuration information. The PIN communication configuration information may be generated and adjusted in various ways, as described below.

[0068] In some embodiments, the UE (PEGC) generates a logical interface ID as the PINE ID. The PINE ID can uniquely identify an interface on the UE using the physical MAC address of the PINE, the hashed MAC address of the PINE, or a random number associated with the PINE, as described above.

[0069] For IP-based PINEs, the UE (PEGC) can obtain the PINE's logical interface ID in various ways. For example, a PINE as an IPv6 host generates a logical interface ID. The PINE then provides this interface ID to the UE using a neighbor discovery protocol. Alternatively, the UE (PEGC) generates a unique logical interface ID for each PINE within a PIN subgroup.

[0070] For non-IP-based PINEs, the UE (PEGC) may obtain the PINE's logical interface ID in various ways. For example, the UE (PEGC) generates a unique logical interface ID for PINEs within a PIN subgroup.

[0071] For PIN subgroups that include both IP-based and non-IP-based PINEs, the UE (PEGC) may generate a unique logical interface ID for each PINE within the PIN subgroup.

[0072] The UE (PEGC) maintains the logical interface ID and PINE ID of each PINE connected to the UE. The UE uses the ID to locally map the ID to the PINE. The UE can adjust the PIN communication configuration information in various ways, as described below.

[0073] Figure 7 is a messaging diagram 700 of an exemplary process for reconciling PIN communication configuration information generated by the UE (i.e., UE-based PIN communication configuration information). The PINE in Figure 7 may be PINE108A, 108B, or 108C. For convenience, PINE108A is referred to as the exemplary PINE in this description. The UE in Figure 7 may be UE102A, UE102B, or UE102C. For convenience, UE102A is referred to as the exemplary UE in this description. The following process is described using one PINE connected to UE102A, but multiple PINEs may be connected to UE102A, in which case it will be understood that multiple PINE IDs and / or logical interface IDs are generated and reconciled.

[0074] First, PINE108A connects to UE(PEGC)102A for PIN services from PIN122A (720). UE102A, AMF364, and UDM308 / UDR352 perform the registration process (721). The registration process may be for an initial request or a mobility registration renewal.

[0075] UE102A generates a logical interface ID as the PINE ID of PINE108A (722). UE102A transmits user plane traffic containing PIN communication configuration information for PIN122A (724). The PIN communication configuration information includes (1) the PIN ID of PIN122A, (2) the UE ID of UE102A (as a PIN group member), where the UE ID is represented by GPSI, and (3) a list of logical interface IDs, i.e., a list of PINE IDs of PINE108A (as a PIN subgroup member). AF358 stores the communication configuration information for PIN122A (726).

[0076] UE102A sends a UL NAS transport message to AMF364364 (728). The UL NAS transport message contains the NAS container for PINE(s)108A. AMF364 sends a Nudm_SDM request message to UDM308 / UDR352 (730). The Nudm_SDM request message contains PIN communication configuration information, which includes (1) the PIN ID of PIN122A, (2) a list of UE IDs of UE(PEGC) (including UE102A) (as PIN group members), where the UE ID is represented by GPSI, and (3) a list of logical interface IDs, i.e., at least one of a list of PINE IDs of PINEs in PIN for each UE in the UE list (including the ID of PINE108A in the list of UE102A) (as PIN subgroup members). UDM308 / UDR352 stores the PIN communication configuration information for PIN122A (732).

[0077] Figure 8 is a flowchart of an exemplary method 800 that can be implemented in UE102A to adjust UE-based PIN communication configuration information.

[0078] First, UE102A connects to PINE(s)108A and provides PIN services to PINE(s)108A. In block 802, UE102A performs the registration process with AMF364 and UDM308 / UDR352 as described in step 721. In block 804, UE102A generates the logical interface ID of PINE108A as described in step 722. In block 806, UE102A sends PIN communication configuration information, including the logical interface ID of PINE108A, to AF358 for storage, as described in steps 724 and 726. In block 808, UE102A sends a request message to UDM308 / UDR352 via AMF364 for storage, as described in steps 728-732. The request message includes PIN communication configuration information, including the logical interface ID of PINE108A. The PIN communication configuration information in blocks 806 and 808 may contain different information, as described with respect to steps 724 and 730, respectively.

[0079] Figure 9 is a messaging diagram of another exemplary process 900 for coordinating UE-based PIN communication configuration information.

[0080] Events 920-926 can be implemented in the same way as events 720-726. AF358 sends an Nnef_ParameterProvision_Create request message, an Nnef_ParameterProvision_Update request message, or an Nnef_ParameterProvision_Delete request message to NEF354 to provision PIN service parameters (e.g., PIN communication configuration information) (928). The sent request message includes, for example, PIN communication configuration information such as: That is, (1) an identifier of the destination UE (including UE102A), where the identifier may be an external identifier or GPSI, (2) the PIN ID of PIN122A, (3) a list of UE IDs of UEs with PEGC (including UE102A) (as a PIN group member), where the UE ID is represented by GPSI, and (4) a list of logical interface IDs, i.e., a list of PINE IDs of the PINs of the PINs of the UEs in the UE list (including the ID of PINE108A in the list for UE102A) (as a PIN subgroup member).

[0081] The NEF354 sends a Numd_SDM request message to the UDM308 / UDR352 (930). The message contains PIN communication configuration information in the form of an Nnef_ParameterProvision_Create request message, an Nnef_ParameterProvision_Update request message, or an Nnef_ParameterProvision_Delete request message. The UDM308 / UDR352 stores the PIN communication configuration information (932).

[0082] The UDM308 / UDR352 sends a Nudm_SDM response message to the NEF354 (934). The NEF354 sends an Nnef_ParameterProvision_Create, Nnef_ParameterProvision_Update, or Nnef_ParameterProvision_Delete response message to the AF358 corresponding to the message received during event 928 (936). By sending two response messages (934, 936), the UDM confirms receipt of the PIN service parameters (e.g., PIN communication configuration information) at the AF358.

[0083] Figure 10 is a flowchart of an exemplary method 1000 that can be performed by AF358 to adjust UE-based PIN communication configuration information.

[0084] AF358 receives PIN configuration information from UE102A as described with respect to event 924 (1002). AF358 stores the received PIN communication configuration information as described with respect to event 926 (1004). AF358 sends a request message to UDM308 / UDR352 to provision PIN service parameters (1006), where the request message contains the PIN communication configuration information for URM308 / UDR352 to store. In embodiments where AF358 is outside the trusted domain 311, AF358 sends the request message via NEF354 as described with respect to events 928 and 930. In embodiments where AF358 is within the trusted domain 311, AF358 sends the request message (e.g., a Nudm_SDM request message) directly to URM308 / UDR352. The PIN communication configuration information for events 1002 and 1006 may contain different information, as described with reference to events 924 and 928, respectively. AF358 receives a response message from URM308 / UDR352 (1) directly or (2) via NEF354, as described with reference to steps 934 and 936 (1008). The response message confirms that URM308 / UDR352 has received the PIN service parameters.

[0085] Next, exemplary techniques for adjusting PIN configuration information will be described with illustrative reference to Figures 11 to 16. These techniques can be used in combination with or separately from the techniques described above, depending on the embodiment or scenario.

[0086] In some embodiments, the UDM of the CN generates a logical interface ID as the PINE ID. The PINE ID can uniquely identify the interface on the UE using the physical MAC address of the PINE, the hashed MAC address of the PINE, or a random number associated with the PINE, as described above.

[0087] The UDM stores subscription information for PIN services to UEs equipped with PEGC. This subscription information includes the maximum allowed number of PINs. Based on the PIN service subscription information for UEs equipped with PEGC, the UDM generates logical interface IDs, where the number of generated logical interface IDs is equal to the stored maximum allowed number of PINs.

[0088] A UE with PEGC maintains a logical interface ID and a PINE ID, and can locally map the logical interface ID and the PINE ID. The UDM coordinates with the UE and AF with PEGC in the process described below. In these processes, an event ID is introduced for network-capable exposure of PIN information via an Nnef_EventExposure request.

[0089] Figure 11 is a messaging diagram of an exemplary process 1100 for adjusting PIN communication configuration information generated by the UDM (i.e., UDM-based PIN communication configuration information).

[0090] Events 1120 and 1121 are executed in the same manner as events 720 and 721, respectively. AF358 sends an Nnef_EventExposure request message to NEF354 (1122). The message includes a destination UE designation, an event ID indicating PIN service information, and at least one of (1) a PIN service designation and (2) a PIN ID. NEF354 sends a Nudm_EventExposure request message to UDM308 / UDR352 (1124). The Nudm_EventExposure request message includes a destination UE designation, an event ID indicating PIN service information, and at least one of (1) a PIN service designation and (2) a PIN ID. By sending these request messages, UDM308 / UDR352 can receive notification of changes in PIN communication configuration information.

[0091] UDM308 / UDR352 generates a logical interface ID as the PINE ID (1126). UDM308 / UDR352 sends a Nudm_EventExposure_Notify message to NEF354 (1128). The message contains PIN communication configuration information, which may include (1) the PIN ID of the PIN, (2) a list of UE IDs of UEs with PEGC (including UE102A) (as PIN group members), where the UE ID is represented by GPSI, and (3) a list of logical interface IDs, i.e., a list of PINE IDs of the PIN of each UE in the UE list (as PIN subgroup members). NEF610 sends an Nnef_EventExposure_Notify message to NEF354 (1130). The message contains PIN communication configuration information. By sending these two messages, UDM308 / UDR352 notifies AF358 of the PIN communication configuration information.

[0092] At the application layer, AF358 sends user plane traffic containing PIN communication configuration information to UE102A (1132), which may include (1) the PIN ID of the PIN, (2) the UE ID of UE102A with PEGC (as a PIN group member), where the UE ID is represented by GPSI, and (3) a list of logical interface IDs, i.e., a list of PINE IDs of the PINEs of the PINs connected to UE604 (as a PIN subgroup member). In step 1134, UE102A stores the PIN communication configuration information. Using the PIN communication configuration information, UE102A maintains a mapping table between the interface ID (i.e., PINE ID) and MAC address of PINE108A.

[0093] Figure 12 is a flowchart of an exemplary method 1220 that can be implemented by UDM308 / UDR352 to adjust UDM-based PIN communication configuration information.

[0094] In block 1202, UDM308 / UDR352 receives a request message from AF358. Depending on whether AF358 is in trusted domain 311, UDM308 / UDR352 may receive the request message directly from AF358 (as described in steps 1122 and 1124) or via NEF354. Upon receiving the request message, UDM308 / UDR352 notifies AF358 if there are any changes to the PIN communication configuration information, including but not limited to generating or changing the logical interface ID of the PINE. In block 1204, UDM308 / UDR352 generates or changes the logical interface ID of the PINE as described in step 1126. In block 1206, UDM308 / UDR352 directly or indirectly sends an alert message to AF358 containing PIN communication configuration information, which includes the generated or modified logical interface ID as described with respect to steps 1128 and 1130.

[0095] Figure 13 is a messaging diagram of another exemplary process 1300 for coordinating UDM-based PIN communication configuration information.

[0096] Events 1320 and 1321 are handled in the same manner as events 720 and 721, respectively. The AMF364 sends a Nudm_SDM_Subscribe request message to the UDM308 / UDR352 so that the AMF364 can receive notification of the PIN change (1321a). The Nudm_SDM_Subscribe request message includes at least one of the PIN service instruction and the PIN ID of the PIN.

[0097] Events 1322-1330 are similar to events 1122-1130, respectively. AF358 stores PIN communication configuration information from the Nnef_EventExposure_Notify message received during event 1330 (1330a).

[0098] The UDM308 / UDR352 sends a Nudm_SDM_Notify message to the AMF364 (1331a). The message contains PIN communication configuration information, which includes (1) the PIN ID of the PIN, (2) the UE ID of the UE604 with PEGC (as a PIN group member), where the UE ID is represented by GPSI, and (3) a list of logical interface IDs, i.e., a list of PINE IDs of the PINs connected to the UE604 (as PIN subgroup members). The AMF364 sends a DL NAS transport message (1331b). The message contains a NAS container for the PIN communication configuration information. Event 1334 may be event 1134.

[0099] Figure 14 is a flowchart of an exemplary method 140s implemented by the UDM308 / UDR352 to coordinate UDM-based PIN communication configuration information.

[0100] In block 1402, UDM308 / UDR352 receives a request message from AMF364 as described in step 1321a. Upon receiving the request message, UDM308 / UDR352 notifies AF358 if there are any changes to PIN122A, including but not limited to the generation or modification of the PINE's logical interface ID.

[0101] In block 1404, UDM308 / UDR352 receives a request message from AF358. Depending on whether AF358 is in trusted domain 311, UDM308 / UDR352 may receive the request message directly from AF358 (as described in steps 1322 and 1324) or via NEF354. Upon receiving the request message, UDM308 / UDR352 notifies AF358 if there are any changes to the PIN communication configuration information, including but not limited to the generation or modification of the PINE logical interface ID.

[0102] In block 1406, UDM308 / UDR352 generates or modifies the logical interface ID of the PINE, as described with respect to step 1326.

[0103] In block 1408, UDM308 / UDR352 directly or indirectly sends an notification message containing PIN communication configuration information to AF358 for storage, the PIN communication configuration information including the generated or modified logical interface ID as described with respect to steps 1328 and 1330.

[0104] In block 1410, UDM308 / UDR352 sends an alert message to AMF364 containing PIN communication configuration information, which includes the generated or modified logical interface ID as described with respect to step 1331a.

[0105] The PIN communication configuration information in blocks 1408 and 1410 may contain different information, as described with respect to steps 1328 and 1331a, respectively.

[0106] Figure 15 is a messaging diagram of another exemplary process 1400 for coordinating UDM-based PIN communication configuration information.

[0107] Events 1520-1530a are similar to events 1320-1330a, respectively. UE102A, AMF364, SMF364, and UDM308 / UDR352 perform the PDU session establishment or modification request procedure (1532). More specifically, UDM308 / UDR352 transmits PIN service subscription information to SMF366. The PIN service subscription information includes PIN communication configuration information, which may include at least one of the following: (1) the PIN ID of the PIN, (2) a list of UE IDs of UEs with PEGC (including UE102A) (as PIN group members), where the UE ID is represented by GPSI, and (3) a list of logical interface IDs, i.e., a list of PINE IDs of PINEs in the PIN of each UE in the UE list (as PIN subgroup members). SMF366 sends a PDU session establishment / modification acceptance message to UE102A (e.g., via AMF364), which includes PIN communication configuration information. Event 1534 is similar to Event 1334.

[0108] Figure 16 is a flowchart of an exemplary method 1600 implemented by the UDM308 / UDR352 to coordinate UDM-based PIN communication configuration information.

[0109] In block 1602, UDM308 / UDR352 receives a request message from AMF364, as described with reference to event 1521a. Upon receiving the request message, UDM308 / UDR352 notifies AF358 if there are any changes to PIN122A, including but not limited to the generation or modification of the PINE's logical interface ID.

[0110] In block 1604, UDM308 / UDR352 receives a request message from AF358. Depending on whether AF358 is in trusted domain 311, UDM308 / UDR352 may receive the request message directly from AF358 (as described in steps 1522 and 1524) or via NEF354. Upon receiving the request message, UDM308 / UDR352 notifies AF358 if there are any changes to the PIN communication configuration information, including but not limited to the generation or modification of the PINE logical interface ID.

[0111] In block 1606, UDM308 / UDR352 generates or modifies the logical interface ID of the PINE, as described with respect to step 1526.

[0112] In block 1608, UDM308 / UDR352 directly or indirectly sends an notification message containing PIN communication configuration information to AF358 for storage, the PIN communication configuration information including the generated or modified logical interface ID as described with respect to steps 1528 and 1530.

[0113] In block 1610, UDM308 / UDR352 sends a message to UE102A containing PIN communication configuration information, which includes the generated or modified logical interface ID as described with respect to step 1532.

[0114] The PIN communication configuration information in blocks 1608 and 1610 may contain different information, as described with respect to steps 1528 and 1532, respectively.

[0115] Next, exemplary techniques for adjusting PIN configuration information will be described with illustrative reference to Figures 17 to 19. These techniques can be used in combination with or separately from the techniques described above, depending on the embodiment or scenario.

[0116] In some embodiments, the AF of the CN generates a logical interface ID as the PINE ID. The PINE ID can uniquely identify the interface on the UE using the physical MAC address of the PINE, the hashed MAC address of the PINE, or a random number associated with the PINE, as described above.

[0117] A UE equipped with PEGC maintains the logical interface ID and PINE ID, and can locally map the logical interface ID and PINE ID. The AF coordinates using the UE and UDM equipped with PEGC in the process described below.

[0118] Figure 17 is a messaging diagram of an exemplary process 1700 for adjusting PIN communication configuration information generated by AF (i.e., AF-based PIN communication configuration information).

[0119] Events 1720 and 1721 are similar to events 720 and 721, respectively. AF358 generates or modifies the interface ID(s) as the PINE ID(s) of the PINE(s)(s)(1722). AF358 sends an Nnef_ParameterProvision_Create request message, an Nnef_ParameterProvision_Update request message, or an Nnef_ParameterProvision_Delete request message to NEF354 to provision PIN service parameters (e.g., PIN communication configuration information)(1723). The transmitted request message includes, for example, PIN communication configuration information such as: (1) an identifier of the destination UE (e.g., UE102A), where the identifier may be an external identifier or GPSI; (2) the PIN ID of PIN122A; (3) a list of UE IDs of UEs (PEGC) (including UE102A) (as PIN group members), where the UE ID is represented by GPSI; and (4) a list of logical interface IDs, i.e., a list of PINE IDs of the PINs of each UE in the UE list (including the PINE ID of PINE108A in the UE list for UE102A) (as PIN subgroup members) (at least some of which are generated by AF358).

[0120] The NEF354 sends a Numd_SDM request message to the UDM308 / UDR352 (1724). The message contains PIN communication configuration information in the form of an Nnef_ParameterProvision_Create request message, an Nnef_ParameterProvision_Update request message, or an Nnef_ParameterProvision_Delete request message. The UDM308 / UDR352 stores the PIN communication configuration information (1726).

[0121] UDM308 / UDR352 sends a Nudm_SDM response message to NEF354 (1728). NEF354 sends an Nnef_ParameterProvision_Create, Nnef_ParameterProvision_Update, or Nnef_ParameterProvision_Delete response message to AF358 corresponding to the message received during event 1723 (1728). By sending two response messages in a single step (1728, 1730), UDM308 / UDR352 confirms receipt of PIN service parameters (e.g., PIN communication configuration information) at AF358. Events 1732 and 1734 are handled in the same manner as events 1132 and 1134, respectively.

[0122] Figure 18 is a flowchart of exemplary method 1800 implemented by AF358 to adjust AF-based PIN communication configuration information.

[0123] In block 1802, AF358 generates or modifies the logical interface ID of PINE as described in step 1722. In block 1804, AF358 sends a request message containing PIN communication configuration information to UDM308 / UDR352, either directly or via NEF354, for storage in UDM308 / UDR352, the PIN communication configuration information including the generated or modified logical interface ID as described in steps 1723-1726. In block 1806, as described in steps 1728 and 1730, AF358 receives a response message from UDM308 / UDR352, either directly or indirectly via NEF354, which allows UDM308 / UDR352 to confirm receipt of the PIN communication configuration information. In block 1808, as described with respect to steps 1732 and 1734, AF358 transmits PIN communication configuration information to UE102A for storage, and the PIN communication configuration information includes PINE information such as the generated or modified logical interface ID.

[0124] Figure 19 shows the messaging of other processes for coordinating AF-based PIN communication configuration information.

[0125] Steps 1920 to 1921a are performed in the same manner as steps 1320 to 1321a. Steps 1922 to 1930 are performed in the same manner as steps 1722 to 1730. Steps 1931a to 1934 are performed in the same manner as steps 1331a to 1334.

[0126] Next, exemplary techniques for coordinating PIN communication using framed routing will be described with illustrative reference to Figures 20A to 21. These techniques can be used in combination with or separately from the techniques described above, depending on the embodiment or scenario.

[0127] In the PIN configuration information adjustment process described above, the UDM can provide the SMF with PIN communication configuration information in order to configure routing rules via the N4 interface for handling PIN communication.

[0128] In the PDU session establishment procedure, the CN and the UE with PEGC in the PIN can handle PIN communication using the following principles (1) to (4): (1) The CN's UDM provides the SMF with PIN communication configuration information; (2) The SMF, based on the PIN communication configuration information from the UDM, configures the UPF via an N4 session request message that includes packet discovery rules (multiple) (PDRs) and forwarding action rules (multiple) (FARs) for routing the discovered PIN traffic. The PDR includes the destination IPv6 prefix associated with the destination PIN group or subgroup, and the destination PINE using the interface ID of the IPv6 address. The FARs for routing discovered PIN traffic to the PIN group in the PIN and the destination UE with PEGC providing services to the N4 session include routing information for the PIN group. As an example, the routing information may include a first IPv6 prefix or a first set of IPv6 prefixes assigned to the UE with PEGC for non-PIN services, and a second IPv6 prefix or a second set of IPv6 prefixes assigned to the destination PIN group / subgroup for PIN services. As another example, routing information may include (a) a first set of IPv6 addresses having the IPv6 prefix of the UE with PEGC for non-PIN services, and (b) a second set of IPv6 addresses having the same IPv6 prefix of the UE with PEGC for PIN services (e.g., using an IPv6 subnet mask). (3) The UPF detects IP packets (e.g., PIN traffic) based on the PDR and routes the detected IP packets to the destination UE with PEGC that serves the PIN group, based on the FAR. (4) The UE with PEGC forwards the IP packets of the QoS flow to the PINE in the PIN group.

[0129] Figures 20A and 20B are messaging diagrams of an exemplary process for PIN communication using framed routing.

[0130] In step 2022, UE102A, AMF364, SMF366, UPF370, and UDM308 / UDR352 perform a registration procedure with PIN communication capability support negotiation. More specifically, UE102A sends a registration request message to AMF364 that includes PIN communication capability. From the registration request message, AMF364 receives subscription information related to UE102A's PIN service. AMF364 then sends a registration acceptance message to UE1104. The registration acceptance message includes PIN instructions and PIN service information for PIN122A (e.g., the maximum allowed number of PINs).

[0131] In step 2024, UE102A, AMF364, SMF366, UPF370, UDM308 / UDR352, and AF358 adjust the PIN communication configuration information. UDM308 / UDR352 stores the PIN communication configuration information (including PIN communication group data) as described with respect to at least some of Figures 7 to 19.

[0132] In step 2026, UE102A sends a PDU session establishment request message or a PDU session modification request message to AMF364. The message includes a PIN instruction and / or a PIN ID associated with the PIN for the PDU session. The message may further include a PDU session ID, a requested PDU session type, a requested SSC mode, 5GSM capabilities, a PCO, an SM PDU DN request container, a packet filter count, a header compression configuration, a maximum data rate for UE integrity protection, a requested always-on PDU session, an RSN, connectivity capabilities, a PIN ID, and / or a PDU session pair ID.

[0133] In step 2028, AMF364 sends an Nsmf_PDUSession_CreateSMContext request message to SMF366. The message includes a PIN instruction and / or PIN ID. In step 2030, SMF366 sends an Nsmf_PDUSession_CreateSMContext response message to AMF364.

[0134] Referring to Figure 20B, in step 2032, SMF366 sends a Nudm_SDM_Subscribe request message to UDM308 / UDR352. The message includes the UE ID of UE102A, a PIN instruction, and / or the PIN ID of PIN122A. In step 2034, UDM308 / UDR352 sends a Nudm_SDM_Subscribe response message to SMF366. The message includes subscription data for the destination UE (e.g., UE102A) identified by SUPI or GPSI, and the destination PIN (e.g., PIN122A) identified by the PIN ID (e.g., external group identifier).

[0135] Simultaneously with or after steps 2032 and 2034, SMF366 performs session management (SM) policy association and modification procedures with PCF360 (not shown) to obtain policy billing and control (PCC) rules. The PCC rules include PIN service policies for the destination UE and destination PINE.

[0136] Based on the subscription data and PCC rules received in step 2034, SMF366 (1) performs a QoS flow bind, (2) configures UPF370 via the N4 interface, and (3) sends an N4 session establishment request message or an N4 session modification request message to UPF370 (in step 2036). The message includes (a) a PDR with destination group address information, and (b) a FAR with routing information to one or more destination UEs (PEGCs) (including UE102A) that serve the PINE of the PIN group. In step 2038, UPF370 acknowledges the request message by sending an N4 session establishment response message or an N4 session modification response message corresponding to the request message received in step 2036.

[0137] In step 2040, SMF366 sends a message to AMF364. The message contains PIN communication configuration information, which includes (1) the PIN ID of the PIN providing the PIN service, (2) a list of UE IDs of UEs with PEGC (including UE102A) (as PIN group members), where the UE ID is represented by GPSI, and (3) a list of logical interface IDs, i.e., a list of PINE IDs of the PINEs of the PINs of each UE in the UE list (as PIN subgroup members). As an example, the list of logical interface IDs is a 64-bit value. As another example, the list of logical interface IDs is represented by several IPv6 addresses. The IPv6 addresses contain information about the logical interface ID in the last 64 bits or the first 64 bits of the IPv6 address. The last or first 64 bits present the IPv6 prefix of the PINE. The last or first 64 bits may be the same as or different from the IPv6 prefix of the UEs with PEGC for non-PIN services.

[0138] In step 2042, the AMF364 sends a PDU session establishment response message or a PDU session modification response message to the UE102A that corresponds to the request message received in step 2026. The response message includes PIN communication configuration information.

[0139] Figure 21 is a flowchart 2100 of an exemplary method implemented by the SMF366 for PIN communication using frame routing.

[0140] In block 2102, SMF366 receives a message from UE102A via AMF364, which includes a PIN instruction and / or the PIN ID of PIN122A, as described with respect to steps 2026 and 2028.

[0141] In block 2104, SMF366 sends a message to URM308 / UDR352, which includes the UE ID of UE102A, a PIN instruction, and / or the PIN ID of PIN122A, as described in step 2032. In block 2016, SMF366 receives a message from URM308 / UDR352, which includes subscription data for the destination UE identified by SUPI or GPSI, and the destination PIN identified by the PIN ID, as described in step 2034.

[0142] In block 2108, SMF366 retrieves PCC rules by performing the PCF360 and SM policy association and modification procedures as described in relation to steps 2032 and 2034.

[0143] In block 2110, SMF366 sends a message to UPF370, which includes destination group information and routing information directed to one or more destination Ue(PEGC) serving the PINE of the PIN group, as described in step 2036.

[0144] In block 2112, SMF366 sends a message to AMF364, which includes PIN communication configuration information as described with respect to step 2040.

[0145] It should be understood that the steps or blocks in Figures 7 through 21 do not need to be performed in the specific order they are described. For example, in Figure 17, step 1726 may be performed after step 1728. It should be understood that fewer or additional steps or blocks may be performed in the process shown in Figures 7 through 21.

[0146] In embodiments where the UDM stores PIN communication configuration information, such information allows the 5G network to authorize PIN communication of PIN group members. The PIN communication configuration information includes PIN information that includes (1) the PIN ID of the PIN, and (2) a list of UEs with PEGCs (as PIN members) that serve the PINE of the PIN. Each UE is identified by its respective UE ID, such as SUPI or GPSI.

[0147] Since PIN traffic needs to be routed to the UE of a specific PIN, the PIN ID is defined to uniquely identify a particular PIN within the PLMN. A PIN includes a group of UEs with PEGCs as PIN members. As an example, the PIN ID is a local identifier such as a Network Access Identifier (NAI). In a globally routable format (e.g., PIN_ID@domain), the domain must be a domain registered for global routing, and the PIN ID may be a static or dynamic identifier. Such identifiers are defined based on service level requirements between the AF and the operator's network. As another example, the PIN ID is an external group identifier. The AF may include a PIN service directive in the PIN ID that triggers a PIN service authorization check in the UDM for AF requests (e.g., requests for PIN service parameter provisioning for a destination PIN group).

[0148] In some embodiments, the PIN is a VN group. In such embodiments, the PIN is identified as an external group identifier, and each PIN member is a VN group member identified by GPSI.

[0149] A new addressing mechanism is needed because PINs can include PINEs serviced by UEs with PEGC using IP-based connectivity (e.g., Wi-Fi) or non-IP-based connectivity (e.g., Bluetooth). This new addressing mechanism differs from IP-based LAN-type services, which do not need to remember the configuration of the device connected to the UE providing the service.

[0150] To distinguish VN groups for LAN-type services from VN groups for PIN services, the UDM may configure instructions to indicate the type of VN group. Table 1 below shows exemplary information stored by the UDM. As shown in the figure, the UDM stores instructions for the type of VN group. The instructions for the type of VN group indicate whether the VN group is for LAN-type services or for PIN services. [Table 1]

[0151] The VN group data for a VN group may further include the service types permitted for that VN group. Table 2 below shows an example of a VN group data description. The VN group data description includes parameters for the VN group type. These parameters indicate the service types permitted for the VN group or PIN group. [Table 2]

[0152] In some embodiments, a PINE connected to a UE with PEGC is identified to support PIN traffic routing from a first PINE to a second PINE. In some embodiments, the UE connected to the first PINE may be the same as or different from the UE connected to the second PINE.

[0153] The UDM may store PIN subgroup information. PIN subgroup information includes information about groups of PINEs associated with PINs served by UEs with PEGC. The PIN subgroup information includes (1) the UE ID of the UE with PEGC, and (2) a list of PINEs. PINEs in the list are served by the UE using either IP-based or non-IP-based connectivity. Table 3 below shows exemplary information that the UDM may store to extend the PIN group information. [Table 3]

[0154] In some embodiments, for PIN services, the AF provides PIN subgroup information as shown in Table 4 below. [Table 4]

[0155] In some embodiments, the URSP includes the information shown in Table 5 below. [Table 5]

[0156] In some embodiments, the URSP includes the information shown in Table 6 below. [Table 6]

[0157] The PDU session ID / PIN ID selection parameter indicates that PIN traffic with a matching PIN ID will be routed through the PDU session associated with the included PDU session ID or PIN ID.

[0158] In embodiments where the UE request includes a PIN ID, the SMF retrieves the PIN group information.

[0159] The following list of embodiments reflects the various embodiments expressly intended by this disclosure.

[0160] Example 1. A method implemented on a user device (UE) that includes providing a service to a Personal Internet of Things (IoT) Network (PIN) element (PINE) associated with a PIN to provide a direct connection between the PINE and the UE, which operates as a PINE with gateway functionality (PEGC); receiving Internet Protocol (IP) packets at the UE via a core network (CN); and routing the IP packets to the PINE, taking into account the headers of the IP packets.

[0161] Example 2. The method according to Example 1, wherein the routing includes determining a PINE identifier (ID) based on the header.

[0162] Example 3. The method according to Example 1 or 2, further comprising obtaining the interface ID of the PINE from the header and determining a mapping between the interface ID and the media access control (MAC) address of the PINE, wherein the routing of the IP packet is based on the MAC address of the PINE.

[0163] Example 4. The method according to Example 3, wherein the determination of the mapping includes using a hash function.

[0164] Example 5. The method according to Example 3, wherein the determination of the mapping includes using a mapping table stored in the memory of the UE.

[0165] Example 6. The method according to Example 3, wherein the interface ID includes the MAC address of the PINE and a predetermined value.

[0166] Example 7. The method according to Example 3, wherein the interface ID includes the hash of the MAC address of the PINE and a predetermined value.

[0167] Example 8. The method according to Example 6 or 7, wherein the interface ID is a 64-bit field and the MAC address is a 48-bit field.

[0168] Example 9. The method according to Example 6, wherein the MAC address is located between the first part of the predetermined value and the second part of the predetermined value, in the middle of the interface ID.

[0169] Example 10. The method according to Example 6, wherein the interface ID is a randomly generated value.

[0170] Example 11. The method according to any one of Examples 1 to 10, wherein the header is an IPv6 header.

[0171] Example 12. The method according to Example 11, wherein the source address field of the IPv6 header indicates the IPv6 address of the source PINE that sent the IP packet.

[0172] Example 13. The method according to Example 11 or 12, wherein the destination address field of the IPv6 header indicates the IPv6 address of the PINE.

[0173] Example 14. The extended header field of the IPv6 header indicates the ID of the PIN, as described in any of Examples 11 to 13.

[0174] Example 15. The method according to Example 11, wherein the source address field of the IPv6 header indicates the IPv6 address of the source UE equipped with PEGC that sent the IP packet.

[0175] Example 16. The method according to Example 11 or 15, wherein the destination address field of the IPv6 header indicates the IPv6 address of the UE.

[0176] Example 17. The method according to Example 11, 15, or 16, wherein the extended header field of the IPv6 header indicates (i) the ID of the PIN, (ii) the PINE ID of the source PINE that sent the IP packet, and (iii) the PINE ID of the PINE.

[0177] Example 18. The method according to Example 1 or 2, further comprising transmitting a PIN communication configuration for routing the IP packets through the CN to the CN.

[0178] Example 19. The method according to Example 18, wherein the transmission of the PIN communication configuration includes transmitting the PIN communication configuration to an application function (AF) using user plane traffic.

[0179] Example 20. The method according to Example 19, further comprising using uplink (UL) non-access layer (NAS) messages to transmit the PIN communication configuration to a centralized data management function.

[0180] Example 21. The method according to any one of Examples 18 to 20, further comprising receiving an interface ID from the PINE using a neighbor discovery protocol and generating a PINE ID using the interface ID.

[0181] Example 22. The method of any one of Examples 18 to 20, further comprising generating a logical interface ID for the PINE in order to uniquely identify the PINE within the PIN subgroup of the PEGC, and generating a PINE ID using the logical interface ID.

[0182] Example 23. The method according to Example 21 or 22, further comprising generating an interface ID for the PINE and including in the PIN communication configuration a PIN ID that identifies the PIN, a UE ID that identifies the UE, and the PINE ID.

[0183] Example 24. The method according to Example 23, wherein the UE ID includes a General Purpose Public Subscription Identifier (GPSI).

[0184] Example 25. The method according to Example 23, wherein the PIN communication configuration includes a list of PINE IDs corresponding to each PINE in the PIN subgroup associated with the PEGC.

[0185] Example 26. The method according to Example 1 or 2, further comprising receiving a PIN communication configuration for routing the IP packets from the CN.

[0186] Example 27. The method according to Example 26, wherein the PIN communication configuration includes (i) a PIN ID that identifies the PIN, (ii) a UE ID that identifies the UE, and (iii) a PINE ID that identifies the PINE within the PIN subgroup of the PEGC.

[0187] Example 28. The method according to Example 26 or 27, further comprising generating a mapping table for mapping the PINE ID to the MAC address of the PINE using the PIN communication configuration.

[0188] Example 29. The PIN communication configuration is received from a Unified Data Management (UDM) or an Access and Mobility Management (AMF) as described in any of Examples 26 to 28.

[0189] Example 30. The PIN communication configuration is received from the application function (AF) and is the method described in any of Examples 26 to 28.

[0190] Example 31. User equipment (UE) including a transceiver and processing hardware, configured to implement the method described in any one of Examples 1 to 30.

[0191] Example 32. A method implemented in a network function (NF) of a core network (CN), the method comprising receiving a personal internet of things (IoT) network (PIN) communication configuration in the NF, the communication configuration comprising (i) an identifier for the PIN, (ii) a UE ID that identifies a user device (UE) that acts as a gateway-enabled PIN element (PINE) (PEGC) and is associated with the PIN, and (iii) a PINE ID that identifies the PINE within a PIN subgroup of the PEGC, the method further comprising configuring the CN to route IP packets addressed to the PINE.

[0192] Example 33. The method according to Example 32, wherein the NF is an application function (AF) and the PIN communication configuration is received from the UE.

[0193] Example 34. The method according to Example 33, further comprising configuring a Unified Data Management (UDM) function with the PIN communication configuration.

[0194] Example 35. The method according to Example 32, wherein the NF is AF, and the PIN communication configuration is received from the UDM.

[0195] Example 36. The PIN communication configuration is received from the UDM via an event publication notification, as described in Example 35.

[0196] Example 37. The method according to Example 35 or 36, wherein the PINE ID included in the PIN communication configuration is generated by the UDM as an interface ID.

[0197] Example 38. The method according to any one of Examples 35 to 37, further comprising transmitting the PIN communication configuration to the UE.

[0198] Example 39. The PIN communication configuration is transmitted to the UE by the UDM, according to any one of Examples 35 to 37.

[0199] Example 40. The method according to Example 32, wherein the NF is a UDM and the PIN communication configuration is received from the AF.

[0200] Example 41. The PIN communication configuration is received from the AF via the Network Exposure Function (NEF) as described in Example 40.

[0201] Example 42. The method according to Example 40 or 41, wherein the AF provisions the UE using a NAS procedure.

[0202] Example 43. The method according to Example 32, wherein the NF is a UDM and the PIN communication configuration is received from the UE.

[0203] Example 44. The PIN communication configuration is received from the UE via the Access and Mobility Management Function (AMF) as described in Example 42.

[0204] Example 45. The method according to any one of Examples 32 to 44, further comprising providing the PIN communication configuration to a Session Management Function (SMF) to configure rules for routing IP traffic to the PINE.

[0205] Example 46. A device including processing hardware, wherein the device is configured to implement a network function (NF) of a core network (CN) of a cellular communication system, and the NF is configured to implement the method described in any of Examples 32 to 45.

Claims

1. A method implemented in user equipment (UE), To provide services to a PIN element (PINE) associated with a Personal Internet of Things (IoT) network (PIN), and to provide a direct connection between the PINE and the UE operating as a PINE with gateway functionality (PEGC), Receiving Internet Protocol (IP) packets at the UE via the core network (CN), Considering the header of the IP packet, the IP packet is routed to the PINE. Methods that include...

2. The method according to claim 1, wherein the routing includes determining a PINE identifier (ID) based on the header.

3. Obtaining the interface ID of the PINE from the header, The further includes determining the mapping between the interface ID and the media access control (MAC) address of the PINE, The routing of the IP packets is based on the MAC address of the PINE. The method according to claim 1 or 2.

4. The method according to any one of claims 1 to 3, wherein the header is an IPv6 header.

5. The method according to claim 4, wherein the source address field of the IPv6 header indicates the IPv6 address of the source PINE that sent the IP packet.

6. The source address field of the IPv6 header indicates the IPv6 address of the source UE equipped with PEGC that sent the IP packet. The method according to claim 4.

7. To transmit a PIN communication configuration for routing the IP packets via the CN to the CN. The method according to claim 1 or 2, further comprising:

8. The PIN communication configuration for routing the aforementioned IP packets is received from the CN. The method according to claim 1 or 2, further comprising:

9. A user device (UE) including a transceiver and processing hardware, configured to implement the method according to any one of claims 1 to 8.

10. A method implemented in the network function (NF) of the core network (CN), wherein the method is The NF receives a Personal Internet of Things (IoT) Network (PIN) communication configuration, wherein the PIN communication configuration includes (i) an identifier for the PIN, (ii) a UE ID that identifies a user device (UE) associated with the PIN and that operates as a PIN element (PINE) (PEGC) with gateway functionality, and (iii) a PINE ID that identifies the PINE within the PIN subgroup of the PEGC. The CN is configured to route IP packets addressed to the PINE. Methods that include...

11. The aforementioned NF is an application function (AF), The PIN communication configuration is received from the UE as user plane data. The method according to claim 10.

12. The aforementioned PIN communication configuration is used to configure a Unified Data Management (UDM) function. The method according to claim 11, further comprising:

13. The aforementioned NF is AF, The aforementioned PIN communication configuration is received from the UDM, The method according to claim 10.

14. The aforementioned NF is UDM, The PIN communication configuration is received from the AF, The method according to claim 10.

15. To provide the PIN communication configuration to the Session Management Function (SMF) in order to configure rules for routing IP traffic to the PINE. The method according to any one of claims 11 to 14, further comprising:

Images