Mechanism for traffic descriptor determination for personal IOT network (PIN)

Abstract

A wireless transmit / receive unit (WTRU) may receive a traffic descriptor determination rule indicating an association of an uplink individual Internet of Things network (PIN) traffic type with a traffic descriptor. The WTRU may receive a User Equipment Routing Policy (URSP) rule that indicates how to route uplink PIN traffic based on at least one of one or more PIN Identifiers (IDs) and a traffic descriptor. The WTRU may receive an uplink PIN traffic associated with a PIN ID of the one or more PIN IDs. The WTRU may determine a traffic descriptor for the received uplink PIN traffic based on the received traffic descriptor determination rule. The WTRU may use the PIN ID and the determined traffic descriptor to select a protocol data unit (PDU) session for transmission of uplink PIN traffic based on the evaluation of the URSIP rule.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 455,786, filed March 30, 2023, the entire contents of which are incorporated herein by reference. Background Technology

[0002] The Policy Control Function (PCF) can provide one or more WTRU policies for a Radio Transmitter Receiver Unit (WTRU). The PCF can use one or more WTRU policy parts to provide each WTRU policy within one or more WTRU policies. Each WTRU policy part can be identified by a User Equipment Policy Part Identifier (UPSI). User Equipment Routing Policy (URSP) rules can be one type of WTRU policy.

[0003] When a WTRU application initiates traffic, the WTRU can use URSP rules to determine the desired characteristics of the PDU session that will carry the application traffic. Examples of PDU session characteristics include, but are not limited to: Data Network Name (DNN), Single Network Slice Selection Auxiliary Information (S-NSSAI), and / or Service and Session Continuity (SSC) mode associated with the Protocol Data Unit (PDU) session.

[0004] WTRU can use URSP rules as a strategy to determine how to route outgoing traffic. Established PDU sessions can route traffic. Outside of a PDU session, traffic can be offloaded to non-3GPP access. ProSe Layer 3 UEs outside of PDU sessions can route traffic to network trunks. Traffic can trigger the establishment of new PDU sessions.

[0005] Each URSP rule can consist of two parts. The first part of the URSP rule can be a traffic descriptor. The traffic descriptor determines when the rule applies. The URSP rule applies when each component in the traffic descriptor matches the corresponding information from the application. The second part of the URSP rule can be a list of routing descriptors (RSDs). The list of RSDs can contain one or more RSDs. RSDs can be listed in priority order and / or describe the characteristics of the PDU session. The PDU session can carry uplink application data. The characteristics of the PDU session can include SSC mode, DNN, and / or S-NSSAI. RSDs may alternatively include a non-seamless offload indication. A non-seamless offload indication can indicate that traffic can be sent via non-3GPP access (e.g., WiFi) and / or outside of any PDU session. Summary of the Invention

[0006] The Wireless Transmit / Receive Unit (WTRU) can receive traffic descriptor determination rules that indicate the mapping of uplink Personal Internet of Things (PIN) network traffic types to traffic descriptors. The WTRU can receive User Equipment Routing Policy (URSP) rules that indicate how to route uplink PIN traffic based on at least one of one or more PIN identifiers (IDs) and traffic descriptors. The WTRU can receive uplink PIN traffic associated with one of one or more PIN IDs. Based on the received traffic descriptor determination rules, the WTRU can determine a traffic descriptor for the received uplink PIN traffic. Using the PIN ID and the determined traffic descriptor, the WTRU can select a Protocol Data Unit (PDU) session associated with the determined traffic descriptor for transmitting the received uplink PIN traffic, based on an evaluation of the URSP rules. The WTRU can then transmit the uplink PIN traffic to the network via the selected PDU session.

[0007] Traffic descriptor determination rules can include an association between traffic identifiers and corresponding traffic descriptor values. The uplink PIN traffic type of received uplink PIN traffic can be based on the PIN ID. The WTRU can evaluate USRP rules to determine one or more PDU session characteristics. A PDU session for sending uplink PIN traffic can be selected based on one or more PDU session characteristics that match the determined PDU session. Uplink PIN traffic can originate from a PIN element (PINE) and / or an application hosted on the WTRU. The WTRU can determine that no established PDU session matches one or more determined PDU session characteristics. The WTRU can trigger the establishment of the selected PDU session based on the determination that no established PDU session matches one or more determined PDU session characteristics.

[0008] URSP rules can be received from managed PIN elements (PEMC), networks, PIN servers, and / or applications hosted on WTRUs. Uplink PIN traffic types can include one or more of the following: Internet Protocol Multimedia Subsystem (IMS), Internet of Things (IoT) sensor readings, and / or streaming media.

[0009] Traffic descriptors may include one or more of the following: connectivity, PIN element (PINE) ID, source Internet Protocol (IP) address, source port number, fully qualified domain name (FQDN), data network name (DNN), destination IP address, destination port number, operating system (OS) identifier, and / or application identifier.

[0010] WTRU can send a request to the network to establish a selected PDU session.

[0011] The uplink PIN traffic can be the first uplink PIN traffic. The PIN ID can be the first PIN ID. The traffic descriptor can be the first traffic descriptor. The selected PDU session can be the first selected PDU session. The WTRU can receive the second uplink PIN traffic associated with a second PIN ID from one or more PIN IDs. The WTRU can determine the second traffic descriptor for the second uplink PIN traffic based on the received traffic descriptor determination rules. The WTRU can use the second PIN ID and the second traffic descriptor to select a second Protocol Data Unit (PDU) session for sending the second uplink PIN traffic, based on an evaluation of URSP rules. The WTRU can send the second uplink PIN traffic to the network via the second selected PDU session.

[0012] One or more traffic rules (e.g., URSP) can be used to determine the PIN by extending the PIN with one or more additional parameters and / or the PIN ID. One or more additional parameters may include connectivity capabilities (e.g., Internet Protocol Multimedia Subsystem (IMS), Multimedia Subsystem (MMS), and / or Internet connectivity), application descriptors (e.g., Android identifier (OSId) and / or Android application identifier (OSAPPId)) and / or DNN, etc.

[0013] One or more traffic descriptor determination rules for a PIN can be configured by the management user via a graphical user interface (GUI), provided to a PIN element with gateway capabilities (PEGC) via the PIN element's management function (PEMC), and / or configured directly in the PEGC. These traffic descriptor determination rules may include, but are not limited to: association of one or more PINEs with connectivity capabilities; application descriptors; DNNs; PIN-IDs; and / or application differentiation. These traffic descriptor determination rules may be required when multiple applications are running on the PINE. The operation of multiple applications can be achieved by mapping information on port numbers to specific applications running on the PINE.

[0014] By using non-access stratum (NAS) signaling to PEGC and / or PEMC, the network (e.g., Home Policy Control Function (H-PCF)) can provide one or more traffic descriptors to determine rules for the PIN.

[0015] By using the user plane (UP) to PEMC and / or PEGC, the PIN server can provide one or more traffic descriptor determination rules for the PIN (e.g., association of one or more PINEs with connectivity capabilities; application descriptors; DNN; PIN-ID and / or application differentiation).

[0016] The network can provide one or more traffic rules as PIN-specific URSP rules. The network can provide a list of UPSIs associated with the PINID and / or Public Land Mobile Network Identifier (PLMN ID). The UPSIs can be mapped to a policy section that includes the URSP rules. Attached Figure Description

[0017] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments can be implemented.

[0018] Figure 1B The illustration shows that, according to the embodiment, it is possible to... Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system.

[0019] Figure 1C The illustration shows that, according to the embodiment, it is possible to... Figure 1A The diagram illustrates a system diagram of an example radio access network (RAN) and an example core network (CN) used within a communication system.

[0020] Figure 1D The illustration shows that, according to the embodiment, it is possible to... Figure 1A The diagram shows a further example RAN and a further example CN used in the communication system illustrated in the figure.

[0021] Figure 2 This is a diagram depicting an example Personal Internet of Things (PIN) network architecture.

[0022] Figure 3 This is a diagram illustrating an example home automation PIN.

[0023] Figure 4 This is a diagram depicting an example wearable PIN.

[0024] Figure 5 This is a diagram illustrating the application layer support of a Personal Internet of Things (IoT) Network (PINAPP) architecture.

[0025] Figure 6 This is a call flow that describes an example process for using a flow descriptor to extend the PIN.

[0026] Figure 7This is a call flow that describes an example process of PIN-specific User Equipment Rule Selection Policy (URSP) rules.

[0027] Figure 8 This is a call flow that describes an example process of extending the PIN's traffic descriptor using PIN-specific URSP rules. Detailed Implementation

[0028] Figure 1A This diagram illustrates an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), and the like.

[0029] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d can be any type of device configured to operate and / or communicate in a wireless environment. As examples, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and the like. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs.

[0030] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b can be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, Internet 110, and / or other networks 112. As an example, base stations 114a and 114b can be base transceiver stations (BTS), Node-B, eNode B, home node B, home eNode B, gNB, NR NodeB, site controllers, access points (APs), wireless routers, and the like. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b can include any number of interconnected base stations and / or network elements.

[0031] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In embodiments, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0032] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0033] More specifically, as noted above, communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN104 / 113 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117. WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0034] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0035] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technology (such as NR radio access) that can use New Radio (NR) to establish air interface 116.

[0036] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement various radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for example, use a dual connectivity (DC) principle to implement both LTE and NR radio access together. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions sent to / from various types of base stations (e.g., eNBs and gNBs).

[0037] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0038] Figure 1ABase station 114b can be, for example, a wireless router, home node B, home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, and the like. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

[0039] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1A As shown, but to be understood, RAN104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0040] CN 106 / 115 can also be used as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

[0041] Some or all of the WTRUs 102a, 102b, 102c, and 102d in communication system 100 may include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, Figure 1A The WTRU 102c shown can be configured to communicate with base station 114a, which can employ cellular-based radio technology, and with base station 114b, which can employ IEEE 802 radio technology.

[0042] Figure 1B This is a system diagram illustrating example WTRU 102. (Example:) Figure 1B As shown, among other things, WTRU 102 may also include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138. It will be understood that, while remaining consistent with the embodiments, WTRU 102 may include any sub-combination of the foregoing elements.

[0043] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmit / receive element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0044] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF signals and optical signals. It will be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0045] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmit / receive elements 122. More specifically, WTRU 102 may employ MIMO technology. Thus, in one embodiment, WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0046] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 can have multi-mode capability. Therefore, transceiver 120 can include multiple transceivers to enable WTRU 102 to communicate via various RATs, such as NR and IEEE 802.11.

[0047] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from the speaker / microphone 124, keypad 126, and / or display / touchpad 128. The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Furthermore, the processor 118 can access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132) and store data in any type of suitable memory. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identity module (SIM) card, memory stick, secure digital storage (SD) card, and the like. In other embodiments, processor 118 may access memory information that is never physically located on WTRU 102 (such as on a server or home computer (not shown)) and store the data in that memory.

[0048] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0049] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that, while remaining consistent with the embodiments, the WTRU 102 may acquire location information using any suitable location determination method.

[0050] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, and the like. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0051] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit 139 for reducing and / or substantially eliminating self-interference through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0052] Figure 1C The diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As noted above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0053] RAN 104 may include eNode-Bs 160a, 160b, and 160c; however, it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. Each of eNode-Bs 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, eNode-B 160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0054] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the UL and / or DL, and the like. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0055] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. While each of the foregoing elements is depicted as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0056] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, and the like. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0057] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, managing and storing the context of WTRUs 102a, 102b, and 102c, and so on.

[0058] The SGW 164 can connect to the PGW 166, which can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0059] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or can communicate with such an IP gateway. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0060] Despite WTRU in Figure 1A-1D While described as a wireless terminal, in some representative embodiments such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0061] In a representative embodiment, the other network 112 may be a WLAN.

[0062] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneling DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode can function without an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as an "ad-hoc" communication mode in this document.

[0063] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz wide bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, STAs including the AP (e.g., each STA) can listen on the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit in a given BSS at any given time.

[0064] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0065] The Very High Throughput (VHT) STA can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels (which can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be split into two streams by a segment parser. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing are performed separately on each stream. The streams can be mapped onto two 80 MHz channels, and data can be transmitted via the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0066] 802.11af and 802.11ah support sub-1 GHz operating modes. Compared to those used in 802.11n and 802.11ac, 802.11af and 802.11ah reduce channel operating bandwidth and carrier. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support instrument-type control / machine-type communication, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., for maintaining very long battery life).

[0067] WLAN systems that can support multiple channels, as well as channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. A primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, the entire available band can be considered busy even if most of the band remains idle and potentially available.

[0068] In the United States, the available frequency band for 802.11ah is from 902 MHz to 928 MHz. In South Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 916.5 MHz to 927.5 MHz. Depending on the country code, the total bandwidth available for 802.11ah ranges from 6 MHz to 26 MHz.

[0069] Figure 1D The diagram illustrates a system diagram of RAN 113 and CN 115 according to an embodiment. As noted above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 113 may also communicate with CN 115.

[0070] RAN 113 may include gNBs 180a, 180b, and 180c, but it will be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. Each gNB 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement cooperative multipoint (CoMP) technology. For example, WTRU 102a can receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0071] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable numerology. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0072] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate with / be connected to gNBs 180a, 180b, and 180c, and also communicate with / be connected to another RAN (such as eNode-B 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-B 160a, 160b, and 160c can be used as mobility anchors for WTRU 102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRU 102a, 102b, and 102c.

[0073] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, and the like. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0074] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and may include a Data Network (DN) 185a, 185b. While each of the foregoing elements is depicted as part of the CN 115, it will be understood that any one of these elements may be owned and / or operated by an entity other than a CN operator.

[0075] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating NAS signaling, mobility management, and the like. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of services utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra-Reliable Low Latency (URLLC) access, services that rely on Enhanced Massive Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, and / or the like. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0076] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure the routing of traffic passing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and so on. PDU session types can be IP-based, non-IP-based, Ethernet-based, and so on.

[0077] UPF 184a and 184b can be connected via an N3 interface to one or more gNBs 180a, 180b, and 180c in RAN 113. This N3 interface can provide WTRU 102a, 102b, and 102c with access to a packet-switched network (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and so on.

[0078] CN 115 can facilitate communication with other networks. For example, CN 115 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 115 and PSTN 108, or may communicate with such an IP gateway. Additionally, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to local data networks (DNs) 185a and 185b via UPFs 184a and 184b through their N3 interfaces and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0079] Given Figure 1A-1D as well as Figure 1A-1D The corresponding descriptions, and one or more of the functions described herein with reference to one or more of the following items, may be performed by one or more emulation devices (not shown): WTRU102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein. An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0080] Simulation devices can be designed to perform one or more tests on other devices in a laboratory environment and / or a carrier network environment. For example, one or more simulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device for testing purposes and / or can be used to perform tests via over-the-air wireless communication.

[0081] One or more emulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices can be used in test scenarios within test laboratories and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. One or more emulation devices can be test rigs. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) can be used by the emulation devices to transmit and / or receive data.

[0082] A Personal IoT Network (PIN) can be a set of configurable and / or managed PIN elements. Each PIN in the set can communicate with each other directly and / or via a PIN element with gateway capabilities (PEGC), can communicate with a 5G network via at least one PEGC, and / or is managed by at least one PIN element with management capabilities (PEMC).

[0083] The PIN element (PINE) may include WTRU and / or non-3GPP equipment. The PINE may communicate within the PIN (e.g., via PIN direct connection, PEGC, and / or PEGC and / or 5G core (5GC)) and / or outside the PIN via PEGC and / or 5GC.

[0084] A PEGC can be a PIN element capable of providing connectivity to and / or from 5G networks for other PIN elements. A PEGC can act as a relay for communication between PIN elements.

[0085] PEMC can be a PIN element with the ability to manage PINs.

[0086] PINE-to-PINE communication can include communication between two PINEs, including but not limited to direct PINE-to-PINE communication and / or indirect PINE-to-PINE connection.

[0087] A direct PINE-to-PINE connection can be a connection between two PIN elements without any PEGC, 3GPPRAN, or core network entity in between.

[0088] PINE-to-PINE indirect connections can be connections between two PIN elements via PEGC and / or via User Plane Function (UPF).

[0089] PINE-to-PINE routing can include routing traffic between two PINEs via PEGC. These two PINEs can have a direct connection to the PEGC via a non-3GPP access point.

[0090] When PEGC routes traffic between PINE and 5G systems (5GS), PINE-to-network routing may occur. PINE can be directly connected to PEGC via non-3GPP access.

[0091] When traffic is routed between two PINEs via one or more UPFs, a network-local handover for the PINEs may occur. These two PINEs are separately connected to two PEGCs via non-3GPP access.

[0092] As described herein, features described as part of PINE can be implemented in the PIN client; features described as part of PEGC can be implemented in the PIN gateway client; and / or features described as part of PEMC can be implemented in the PIN management client.

[0093] Other functions of PINE can perform functions described as part of a PIN client. Other functions of PEGC can perform functions described as part of a PIN gateway client. Other functions of PEMC can perform functions described as part of a PIN management client.

[0094] A PIN can be determined using traffic rules (e.g., URSP rules) that extend the PIN with one or more additional parameters and / or the PIN ID. One or more additional parameters may include connectivity capabilities (e.g., "ims", "mms", and / or "Internet"), application descriptors (e.g., Android identifier (OSId) and / or Android application identifier (OSAPPId)) and / or DNN.

[0095] The rules for determining the traffic descriptor of a PIN can be configured by the management user via the GUI, provided to the PEGC via the PEMC, and / or configured directly in the PEGC.

[0096] The rules for determining the traffic descriptor of a PIN can include the association between the PINE and connectivity capabilities, application descriptors, DNN, PIN-ID, and / or application differentiation. This includes application differentiation, where multiple applications running on the PINE can be implemented by mapping information on port numbers to specific applications running on the PINE.

[0097] The traffic descriptor determination rules for the PIN can be provided to the PEGC and / or PEMC by the 5G network (H-PCF) via NAS signaling, and provided to the PEMC and / or PEGC by the PIN server via UP.

[0098] 5G networks can provide traffic rules as PIN-specific URSP rules. The network can provide a list of one or more UPSIs associated with the PIN ID and / or PLMN ID. These UPSIs can be mapped to a policy section containing the URSP rules.

[0099] For each newly detected application, the WTRU can evaluate URSP rules in order of rule priority. The WTRU can determine whether the application matches the traffic descriptor of any URSP rule. When the WTRU determines that a URSP rule is applicable to a given application, the WTRU can select a route descriptor (RSD) for that URSP rule in order of RSD priority.

[0100] When the WTRU finds a valid RSD, it can determine whether a PDU session exists that matches all components within the selected RSD. If a matching PDU session exists, the WTRU can associate the application with the existing PDU session (e.g., the WTRU can route detected application traffic on that PDU session). If no existing PDU session matches the RSD, the WTRU can attempt to establish a new PDU session using the values ​​specified by the selected RSD.

[0101] If the RSD includes a non-seamless offload instruction, the WTRU may attempt to transfer data outside of any PDU session using the WLAN access network. WLAN selection policy (SP) rules can be used to select the WLAN access network.

[0102] When traffic from an application is associated with a PDU session, events may cause the WTRU to re-evaluate URSP rules and / or associate traffic from the application with a different PDU session. Examples of events that may trigger URSP re-evaluation include, but are not limited to: implementing a relevant re-evaluation timer and / or the WTRU establishing access to a Wi-Fi network that provides internet access without using 5GS (e.g., non-seamless offloading becomes possible).

[0103] Traffic descriptors can be application descriptors, Internet Protocol (IP) descriptors, domain descriptors, non-IP descriptors, data network names (DNNs), and / or connectivity capabilities. IP descriptors can be destination IP 3-tuples (e.g., IP address and / or IPv6 network prefix, port number, and / or protocol ID of the protocol over IP).

[0104] Figure 2 This is a diagram depicting an example Personal Internet of Things (PIN) network architecture. (Example...) Figure 2 As seen in the diagram, PIN 200 is a set of configured and / or managed PIN elements 204a, 204b. Each PIN 200 in this set can communicate with each other directly and / or via PEGC 206. PIN 202 can communicate with the 5G network via at least one PEGC 206 and / or be managed by at least one PEMC 208. PINEs 204a, 204b are WTRU and / or non-3GPP devices that can communicate within PIN 202 (e.g., via direct PIN connection, via PEGC 206, or via PEGC 206 and / or 5GC 250) and / or outside the PIN (e.g., via PEGC 206 and / or 5GC 250). PEGC 206 is a PINE with the capability to provide connectivity to and / or from the 5G network for other PINEs 204a, 204b and / or to relay communication between PINEs 204a, 204b. PEMC 208 is a PINE with the ability to manage PIN202. A 5G system can consist of a Radio Access Network (RAN) and / or 5G core network elements such as Access and Mobility Management Functions (AMF), Session Management Functions (SMF), and User Plane Functions (UPF). Control plane signaling between the WTRU and / or the network can occur between the WTRU and the AMF and / or between the AMF and / or the SMF. User plane signaling between the WTRU and / or the network is routed via the UPF entities of the 5G core network. The RAN can handle radio interfaces (e.g., Next Generation Radio Access Network (NG-RAN)).

[0105] Existing PINs can make one or more architectural assumptions. For example, a 3GPP WTRU can act as a PEGC and / or PEMC. A PIN can include one or more PEGCs. A PIN can include one or more PEMCs, and / or, at any given time, any of the PEMCs can control the PIN. PINEs assume the use of non-3GPP access (e.g., Wi-Fi and / or Bluetooth) for direct communication. PEMCs can communicate directly with PEGCs using ProSe (e.g., 5G ProSe). PEGCs and / or PEMCs can belong to the same PLMN, Non-Public Network (NPN), and / or Independent Non-Public Network (SNPN). A single PEGC can support more than one PIN at a time. PEGCs can support multi-hop P2P (e.g., communication between PINE chains) and / or P2N relay (e.g., communication from one PINE to another and / or via an intermediate PINE to the network).

[0106] Figure 3 This is a diagram illustrating the example home automation PIN 300. (As shown...) Figure 3 As seen in the image, the Internet of Things (IoT) features are designed for devices that can communicate using traditional cellular networks. For bulk operations, IoT-capable devices may require better power performance and / or higher network efficiency.

[0107] When multiple IoT devices are deployed in a private environment, IoT-capable WTRUs can be organized in a Personal IoT Network (PIN) 300. For example, in a home environment, a residential gateway 310 can manage devices such as motion sensors 302, smart optical repeaters 304, smart plugs 306a, 306b, 306c, printers 308, cellular phones 310, smart keys 312, smart locks 314, smart door sensors 316, and / or similar devices. These devices can communicate with each other. In this case, all the devices in the home constitute a PIN. Each device is called a PIN element (PINE), and different PINEs have different capabilities. For example, a residential gateway 320 can have a PIN element with gateway capabilities (PEGC) to provide connectivity between PINEs and / or 5G networks and / or connectivity between PINEs. A PIN element with management capabilities (PEMC) is a PINE that allows an authorized administrator to configure and / or manage the PIN. The residential gateway 320, acting as a PEGC, can also support PIN management functions. Furthermore, the residential gateway can act as a PEMC.

[0108] Figure 4 This is a diagram depicting an example wearable PIN. (Example) Figure 4As seen in the diagram, multiple wearable devices (e.g., AirPods 404a, 404b; VR / AR glasses 406a, 406b; and / or smartwatches 408a, 408b) can also constitute another type of PIN, such as wearable PINs 402a, 402b. In this type of PIN, smartphones 408a, 408b can act as, for example, PEGC and / or PEMC. For example, AirPods 404a, VR / AR glasses 406a, and / or smartwatches 408a can communicate with each other in PIN 402a. AirPods 404b can communicate directly with other PINEs (e.g., VR / AR glasses 406b within PIN 402b). For example, AirPods 406b can use Bluetooth connectivity to communicate with other PINEs. PIN 402a can communicate with PIN 402b via a 5G network 420.

[0109] PINs can also support application layer protocols. PINs can be based on the PIN application layer functional model.

[0110] Figure 5 This document describes an example application architecture for enabling application-layer support for the Personal Internet of Things (IoT) Network (PINAPP) 500. Application entities such as PIN clients 502a, 502b, and 502c in the PINE, PIN gateway client 504 in the PEGC 506, PIN management client 508 in the PEMC 510, and / or PIN server 512 in the data network 550 are part of the PINAPP 500 architecture. These application entities can enable desired features within the PIN. This document describes how these entities and / or PIN nodes operate to enable the features of the PINAPP 500.

[0111] Establishing multiple PDU sessions at the PEGC 506 on each PIN can cause issues. The PEGC 506 can provide connections to and / or from a network (e.g., a 5G network) and / or one or more PINEs. The PEGC 506 can support multiple PDU sessions per PIN, while traffic differentiation may not support this functionality.

[0112] The PEGC 506 can route traffic from the PINE to the data network 550. The PEGC 506 uses PDU sessions to route traffic to and from the data network. The data network to which the PEGC 506 sends traffic is determined by the PEGC 506 based on the characteristics of the traffic. Traffic characteristics can include any combination of the traffic's source address, destination address, source device (e.g., PINEID), and / or type of traffic (e.g., Internet Protocol Multimedia Subsystem (IMS), IoT sensor readings, streaming media).

[0113] Traffic within a PIN may have different characteristics. PEGC may need to route traffic from the PIN to different data networks based on these characteristics. PEGC may need to establish multiple PDU sessions to carry traffic from the PIN.

[0114] When a PEGC is able to send uplink data from a PIN to different data networks, it may be desirable for the PEGC to determine which PDU session should be used to send the uplink data. In other words, a way to isolate traffic based on the desired service type is needed. For example, IMS traffic from a PIN might need to go to an IMS PDU session associated with a first DNN / Single Network Slice Selection Aid Information (S-NSSAI) combination. Internet traffic from the same PIN might need to go to an Internet PDU session associated with a second DNN / S-NSSAI combination.

[0115] When PEGC receives traffic from a PINE, PEGC can determine whether the traffic should be routed to another PINE and / or data network via a PDU session.

[0116] This document provides mechanisms and / or enhancements for scenarios where PEGC supports different types of uplink traffic originating from PINE. Additional examples describing how this traffic is matched accordingly with different PDU sessions at PEGC are also provided.

[0117] This document provides enhancements to the URSP framework. These enhancements may be specific to the case where URSP rules are used to route traffic associated with a PIN. The enhancements may extend the traffic descriptor to better account for the characteristics of the traffic and / or accordingly match traffic to different PDU sessions at the PEGC.

[0118] The Policy Control Function (PCF) can send one or more policy sections to the PEGC, including URSP rules applicable to the PIN. In other words, the PEGC can receive URSP rules that are not specific to any PIN in a separate policy section from the PIN-applied policy section. The PCF can send a mapping table to the PEGC. The PEGC can use the mapping table to determine which policy sections are associated with each PIN. When the PEGC detects uplink traffic associated with a PIN, it can examine which policy sections are linked to the PIN ID in the mapping table. The PEGC can use these URSP rules to determine the PDU session used to route the uplink traffic. For example, URSP rules can instruct how to route uplink traffic (e.g., PIN traffic) based on one or more PIN IDs and / or at least one traffic descriptor. In other words, the mapping table can indicate the association between (one or more) PIN IDs and policy section identifiers.

[0119] A PEGC can be configured with one or more traffic descriptor determination rules. These rules provide information about mapping PIN traffic to traffic descriptors. The PEGC can receive one or more traffic descriptor determination rules. Alternatively, one or more traffic descriptor determination rules can be received from the network (e.g., via NAS signaling). Alternatively, one or more traffic descriptor determination rules can be received from a PIN server via application-layer signaling. Alternatively, one or more traffic descriptor determination rules can be configured by applications hosted on the PEGC (e.g., a GUI and / or a PEGC client).

[0120] PEGC can accept one or more URSP rules. The traffic descriptor portion of one or more URSP rules may include one or more of the following: PIN ID and / or connectivity, PINE ID, source IP address, source port number, fully qualified domain name (FQDN), DNN, destination IP address, destination port number, OS identifier, and / or application identifier.

[0121] PEGC can receive uplink traffic associated with a PIN. The uplink data may have originated from a PINE client.

[0122] PEGC can determine the traffic descriptor associated with uplink traffic. PEGC can use one or more traffic descriptor determination rules to determine the traffic descriptor associated with uplink traffic. PEGC can determine the PIN ID associated with uplink traffic. PEGC can use both the PIN ID and the traffic descriptor to evaluate URSP rules.

[0123] PEGC can determine one or more PDU session characteristics based on URSP rule evaluation. If PEGC has already established a PDU session that matches one or more PDU session characteristics, PEGC can use that PDU session to send uplink traffic to the network.

[0124] Alternatively, if the PEGC has not yet established a PDU session matching one or more PDU session characteristics, the PEGC may send a PDU session establishment request to the network. The PDU session establishment request may include one or more PDU session characteristics. The PEGC can then use the PDU session to send uplink traffic to the network.

[0125] PEGC can receive one or more URSP rules in the policy section and / or in information elements that include a mapping table. The mapping table can indicate which PIN ID(s) are associated with the policy section. The mapping table can also include a PLMN ID, which indicates that URSP rules can be applied to PIN traffic when PEGC registers in the PLMN.

[0126] PEGC can use one or more traffic descriptor determination rules to determine the traffic descriptors associated with uplink traffic. PEGC can determine PIN IDs and / or mapping tables to determine one or more URSP rules applicable to uplink traffic. PEGC can use both URSP rules and / or traffic descriptors to evaluate the determined URSP rules. URSP rule evaluation can lead to the determination of PDU session characteristics.

[0127] A PEGC can be a PINE capable of providing connectivity to and from 5G networks for other PINEs. A PEGC can act as a relay for communication between PINEs. One or more PINEs can use a PDU session established by the PEGC for uplink (UL) data traffic destined for an external data network. PIN elements (PINEs) may have different traffic requirements. Therefore, mapping traffic originating from all PINEs to the same PDU session may be inappropriate. For example, traffic differentiation can be performed at the PEGC level by routing different traffic via different PDU sessions.

[0128] To differentiate traffic, the traffic descriptor portion of a PIN's URSP rule can be extended to include the PIN ID and / or one or more additional parameters, such as a connectivity indicator, application descriptor, DNN, destination address, source address, and / or source device identifier (e.g., PINE ID). PEGC can use a combination of the PINE ID and / or at least one other parameter in the traffic descriptor to determine which URSP rule applies to that traffic.

[0129] PEGC can identify one or more traffic descriptor components of uplink traffic originating from an application running on PINE. PEGC can use one or more traffic descriptor identification rules to identify one or more traffic descriptor components of uplink PIN traffic. These one or more traffic descriptor identification rules can be implemented using different means. For example, PEGC can have one or more traffic descriptor identification rules configured via a GUI (e.g., rules for determining the traffic description of PIN traffic); configured via messages received from PEMC; provided by H-PCF (e.g., via NAS signaling); and / or configured by a PEGC client (e.g., the PEGC client configures traffic rules based on information from PINE and / or from the PIN server).

[0130] One or more traffic descriptor determination rules can associate traffic descriptors with uplink traffic. In some systems, traffic descriptor determination rules may not be supported. For example, in those systems, applications may provide traffic descriptors (e.g., connectivity capabilities, DNN, and / or FQDN) to the Mobile Terminal (MT) portion of the WTRU. For example, in those systems, the MT portion of the PEGC may determine the traffic descriptor based on the destination IP address and / or port number of the uplink traffic. The traffic descriptor can then be used in URSP rule evaluation. These methods may be unsuitable where the PEGC needs to determine traffic descriptors for uplink traffic originating from a PINE and / or a PEGC client. A PINE may include non-3GPP devices that generate non-IP-based traffic. Therefore, the PINE may not provide traffic descriptors to the PEGC and / or may not provide IP addresses to the PEGC.

[0131] WTRUs (e.g., PEGC) can use traffic descriptor determination rules to determine traffic descriptors for uplink traffic originating from PINE and / or PEGC clients. Traffic descriptor determination rules can take the form of a table with identifiers and / or traffic descriptor values.

[0132] Traffic descriptors determine that identifiers in rules can be associated with uplink traffic. This identifier can be a PINE ID, indicating that all traffic from the identified PINE matches the rule. An identifier can be a PINE client ID and / or a PEGC client ID, indicating that traffic from the identified client (e.g., all traffic) matches the rule. An identifier can be a PIN ID, indicating that traffic from the identified PIN (e.g., all traffic) matches the rule. An identifier can be an identifier indicating that traffic from this type of device (e.g., all traffic) matches the rule. An identifier can be a location indicating that traffic (e.g., all traffic) matches the rule when the PEGC is in the identified location. Combinations of these identifier values ​​can be used to identify traffic. For example, a combination of PIN ID and / or location can indicate traffic associated with a PINE (e.g., all traffic). When the PEGC is in the indicated location, the PIN's client can match.

[0133] The traffic descriptor value in a traffic descriptor determination rule can indicate the traffic descriptor value to be associated with the identified traffic (e.g., associated with an identifier in the traffic descriptor determination rule). Traffic descriptor values ​​can be IP addresses, FQDNs, connectivity values, OSids, application IDs, descriptors for destination information of non-IP traffic, and / or DNNs.

[0134] When multiple applications run on one or more PINEs, the PINEs can transmit application IDs to the PEGC. For example, a PINE client can transmit a mapping of port numbers to one or more specific application IDs. Different PDU sessions can serve different applications running on the PINE. The PIN server can provide and / or configure this information to the PEGC.

[0135] Figure 6 This is a call flow 600 describing an example procedure for using a traffic descriptor to extend the PIN. At 620, PIN 602 can be set (e.g., successfully set) with multiple PINEs 604a, 604b, PEMC 606, and PEGC 608. A PDU session may not yet have been established to access the network 610 (e.g., 5GC, AMF, SMF, PCF, and / or User Data Management (UDM)). Figure 6 All of them are referred to as network 610) to send PIN traffic to the data network.

[0136] At 624, PEGC 608 can receive one or more traffic descriptor determination rules. PEMC 606 can provide one or more traffic descriptor determination rules to PEGC 608. The traffic configuration of PIN 602 can provide information about traffic originating from different PIN elements, and / or may include PINE 604a, 604b mapped to connectivity capabilities (e.g., Internet Protocol Multimedia Subsystem (IMS), Multimedia Subsystem (MMS), and / or Internet connection), application descriptors (OSId and / or (one or more) OSAppId), and / or DNN, etc. For example, one or more traffic descriptor determination rules received at 624 can indicate the mapping of uplink PIN traffic types to traffic descriptors. PEGC 608 can use the traffic configuration to map traffic originating from the PINE to the corresponding PDU session established with the network (e.g., a 5G network). PEGC 608 can consider URSPs with extended traffic descriptor portions provided by the network.

[0137] At 628, the home network 610 (e.g., PCF) can provide one or more traffic descriptor determination rules to PEGC 608 via NAS signaling. Network 610 (e.g., PCF) can also send URSP rules to PIN 602 at 628.

[0138] At 632, the PIN server 636 (e.g., the PIN application function (AF)) can provide one or more traffic descriptor determination rules to the PEGC 608 via the user plane. The PEGC 608 can receive one or more traffic descriptor determination rules using an established PDU.

[0139] At 640, the GUI and / or PEGC client can configure one or more traffic descriptor determination rules. As described herein, one or more traffic descriptor determination rules may include traffic configuration information related to the PIN, the association between the PINE and connectivity capabilities, application descriptors, DNNs, and / or PIN-IDs. One or more traffic descriptor determination rules can describe how to differentiate applications in scenarios where multiple applications are running on the same PINE. This differentiation can be achieved via mapping information based on the port numbers used by the specific application running on the PINE (e.g., source and / or destination port numbers for uplink / downlink (UL / DL) traffic, respectively). PEGC 608 may have URSP rules provided by network 610 (e.g., PCF) for mapping traffic to PDU sessions. When traffic descriptors are determined, PEGC can use the traffic descriptors and / or URSP rules to determine which PDU session to use and / or what characteristics of the PDU session to establish.

[0140] At 644, UL traffic can be sent from PINE-1 602 to PEGC 608. Additionally or alternatively, uplink traffic can originate from applications within PEGC 608 (e.g., PEGC clients).

[0141] The PEGC 608 can evaluate UL traffic from PINE-1 602. Evaluating UL traffic may include using one or more traffic descriptor determination rules to determine the traffic descriptor associated with the UL traffic, and / or using the PIN ID and / or traffic descriptor to determine the characteristics of the PDU session used to carry the UL traffic (e.g., DNN, S-NSSAI, and / or Service and Session Continuity (SSC) mode). The PEGC 608 can use the PIN ID and the determined traffic descriptor to select the PDU session for sending uplink PIN traffic based on the evaluation of USRP rules.

[0142] At point 648, if PEGC 608 has already established a PDU session matching the identified characteristics (e.g., DNN, S-NSSAI, and / or SSC patterns), PEGC 608 can use the established PDU session to send uplink traffic. Alternatively, if PEGC 608 determines that no existing PDU session matches the identified characteristics (e.g., DNN, S-NSSAI, and / or SSC patterns), PEGC 608 can use the identified characteristics to trigger the establishment of a new PDU session with the network. Furthermore, PEGC 608 can associate PINE-1 604a application uplink traffic with this new PDU session.

[0143] At position 652, UL traffic can be sent from PINE-2 604b to PEGC 608. Additionally or alternatively, uplink traffic can originate from an application within PEGC 608 (e.g., a PEGC client). The initiator of U traffic may differ from the source of uplink traffic generated by PINE-1 604a.

[0144] At 656, PEGC 608 can evaluate UL traffic from PINE-2 604b by using one or more traffic descriptor determination rules to determine the traffic descriptor associated with UL traffic. PEGC 608 can also use PIN ID and / or traffic descriptor to determine the characteristics of the PDU session used to carry uplink traffic (e.g., DNN, S-NSSAI, and / or SSC mode). The evaluation of one or more traffic descriptor determination rules by PEGC 608 may result in the determination of a different traffic descriptor than that determined for traffic from PINE-1 604a. Different traffic descriptors can be determined because the characteristics of traffic received from PINE-2 604b (e.g., source or destination IP address, traffic type, connectivity, DNN / S-NSSAI, etc.) may differ from the characteristics of traffic received from PINE-1 604a. When PEGC 608 uses the traffic descriptor (e.g., a second traffic descriptor) determined at 656 to determine the characteristics (e.g., DNN, S-NSSAI, and / or SSC modes) of a PDU session carrying UL traffic received from PINE-2 604b, PEGC 608 may determine one or more characteristics different from the PDU session characteristics (e.g., a second PDU session characteristic). These PDU session characteristics (e.g., the second PDU session characteristic) may be determined based on the UL traffic received from PINE-1 604a (e.g., a second DNN, a second S-NSSAI, and / or a second SSC mode).

[0145] If the PEGC 608 has already established a PDU session that matches the characteristics of the second PDU session, the PEGC 608 can determine to use the established PDU session to send uplink traffic. If the PEGC 608 determines that no PDU session matches the characteristics of the second PDU session, the PEGC 608 can use the determined characteristics (e.g., second DNN, second S-NSSAI, and / or second SSC mode) to trigger the establishment of a new PDU session with the network. The PEGC 608 can associate PINE-2 604b application UL traffic with this new PDU session.

[0146] At position 660, the PEGC 608 can be associated with multiple PDU sessions. Each PDU session can accommodate different types of UL traffic originating from different PINE 604a and 604b and / or applications with different traffic requirements.

[0147] The URSP provided by the network can include a list of PIN IDs (instead of a single PIN ID). PIN IDs on the list can share the same traffic descriptor portion. PIN IDs can be helpful when multiple PINs share the same PDU session and / or are served by the same PEGC service.

[0148] A PEGC can be a PIN element with the ability to provide connectivity to and / or from a network (e.g., a 5G network) for other PINEs and / or to relay communication between PINEs. PINEs can use PDU sessions established by the PEGC to send and / or receive data traffic to and / or from a data network. Each PINE may have different traffic requirements. Therefore, traffic originating from all PINEs may not map to the same PDU session. Thus, traffic differentiation may be required at the PEGC level, for example, by routing different traffic via different PDU sessions.

[0149] A network (e.g., H-PCF) can provide one or more PIN-specific URSP rules for a PIN. PIN-specific URSP rules can provide the necessary traffic differentiation at the PEGC and / or PIN level. These PIN-specific URSP rules can be provided to the PEGC upon successful registration with the network and / or after the PEGC provides the PIN identifier to the network (e.g., as part of a registration request message).

[0150] Example triggers for H-PCF to send PIN-specific URSP rules to PEGC may include one or more of the following: A PIN-specific URSP rule from H-PCF may be sent to PEGC in the NAS registration acceptance in response to PEGC providing a PIN ID in a NAS registration request. A PIN-specific URSP rule from H-PCF may be sent to PEGC in a NAS WTRU configuration update message. H-PCF may trigger this message upon receiving notification from PEGC, UDM, and / or User Data Repository (UDR), that the subscription has been updated, and / or upon receiving a request from the AF managing the PIN. Additionally or alternatively, PIN-specific URSP rules may be provided by H-PCF using other NAS signaling messages and / or via Roaming Bootstrap (SoR).

[0151] PIN-specific URSP rules can be sent to PEGC in the policy section, without any non-PIN-specific URSP rules. The message used to send PIN-specific URSP rules to PEGC may also include information elements indicating which PIN ID(s) are associated with which policy section(s). The information elements may indicate a mapping from PIN ID to UPSI. PEGC may associate PLMN IDs with PIN-specific URSP rules. When a PIN-specific URSP rule is received, the PLMN ID to be associated with the PIN-specific URSP rule may be an HPLMID and / or a PLMN ID registered with PEGC. Additionally or alternatively, the information element carrying mapping information may include one or more PLMN IDs, one or more PIN IDs, and / or one or more UPSIs.

[0152] When a PEGC registers with an associated PLMN and / or its equivalent PLMN, the PEGC may consider PIN-specific URSP rules to be valid. When the PEGC changes the PLMN, the PEGC may trigger a re-evaluation of the URSP rules. When the PEGC evaluates the URSP rules and / or determines that no PIN-specific URSP rules are associated with a PIN in the PEGC's currently registered PLMN, the PEGC may decide to block any uplink traffic from the PIN. Blocking uplink traffic indicates that no uplink PIN traffic is directed toward the PDU session. In roaming scenarios, H-PCF provides this information via the Visit Policy Control Function (V-PCF).

[0153] If the PIN is dynamic, where PIN elements are added to and / or removed from the PIN, the PIN-specific URSP can be re-evaluated each time the PIN configuration changes (e.g., when a PIN element is added to and / or removed from the PIN).

[0154] Figure 7 This is a call flow example 700 that describes the PIN-specific URSP rules. Figure 7 An example procedure is illustrated where the PCF is triggered to send PIN-specific URSP rules to the PEGC during the registration process. The PCF can also trigger the WTRU configuration update procedure and use the UE configuration update message to send PIN-specific URSP rules to the PEGC. The PCF can trigger the WTRU configuration update procedure because the PCF receives updated service parameters from the UDM, UDR, and / or AF.

[0155] At 716, PEGC 704 can trigger a registration request message (e.g., initial, mobility, and / or periodic) including a PIN ID to network 708 (e.g., 5GC, AMF, SMF, PCF, and / or UDM). Additionally or alternatively, at 720, network 708 can check the PIN-specific URSP rules with PIN server 712. Additionally or alternatively, at 724, PIN server 712 can provide network 708 with parameters for creating PIN-specific URSP rules via a Network Exposure Function (NEF) interface. At 728, network 708 can respond with a registration accept message, which may include a policy container containing the PIN-specific URSP rules provided by network 708.

[0156] like Figure 6 As described above, the PEGC can be configured with traffic descriptor determination rules. The PEGC can evaluate UL traffic based on the PIN element. Evaluating UL traffic can include using traffic descriptor determination rules to determine the traffic descriptor associated with the UL traffic. Evaluating UL traffic can also include using PIN-specific URSP rules provided by the network to match the UL traffic to the appropriate URSP rule. If the PEGC has already established a PDU session that matches the determined characteristics (e.g., DNN, S-NSSAI, and / or SSC patterns), the PEGC can determine to use the established PDU session to send uplink traffic. If the PEGC determines that no PDU session matches the determined characteristics (e.g., DNN, S-NSSAI, and SSC patterns), the PEGC can use the determined characteristics (e.g., DNN, S-NSSAI, and SSC patterns) to trigger the establishment of a new PDU session with the network. The PEGC can also associate PINE-1 application uplink traffic with this new PDU session.

[0157] The Attached Data Network can internally and / or externally route PIN traffic to the PIN. Upon receiving traffic from a PINE, PEGC can determine whether the traffic is intended for another PINE within the same PIN or for an external data network.

[0158] PEGC can consider traffic (e.g., all traffic) subject to URSP rule evaluation. URSP rules can instruct how uplink PIN traffic is routed based on one or more identifiers and / or at least one traffic descriptor. The structure of the RSD within the URSP can be enhanced to indicate that traffic matching the traffic descriptor is internally routed to the PIN. The RSD can further indicate the destination address of the traffic (e.g., the destination IP address of another PINE within the PIN). PCF can provide enhanced URSP for PEGC. The AF of the PIN can be supplemented by PCF via NEF with PIN traffic configuration (e.g., the source and / or destination IP addresses of the PINE, the PINE ID and / or the updated RSD, etc.).

[0159] Additionally or alternatively, PEGC can be configured with rules to detect whether traffic should be routed within the PIN (e.g., sent to another PINE within the PIN) or routed to the data network via a PDU session. One or more traffic descriptor determination rules can determine whether traffic should be routed within the PIN (e.g., sent to another PINE within the PIN) and / or routed to the data network via a PDU session. For example, a traffic descriptor determination rule can indicate that a specific traffic descriptor value is associated with traffic. The presence of a specific traffic descriptor value can indicate that traffic should be routed to another PINE within the PIN. The destination address of the traffic can be a part of the traffic (e.g., an IP address), determined based on the content of the traffic descriptor determination rules, and / or based on a specific implementation. When PEGC determines that traffic should be routed to the data network via a PDU session, PEGC can use URSP rules to evaluate and determine which PDU session should carry the traffic.

[0160] Figure 8 This is an example of a call flow describing a process 800 that uses PIN-specific URSP rules to extend the PIN's traffic descriptor. Figure 8 Another example process is described, in which the PCF triggers and sends a PIN-specific URSP rule to the PEGC during the registration process. Figure 8 The process further describes how it combines PEGC and its configuration with traffic descriptor determination rules.

[0161] At 814, PEGC 808 can send a registration request message (e.g., initial, mobility, and / or periodic) to network 810 (e.g., AMF, SMF, PCF, and / or UDM). At 816, the registration request message may include a PIN ID. Network 810 can check the PIN 802-specific URSP rules with PIN server 812. At 818, PIN server 812 can provide network 810 with one or more parameters via the NEF interface that can be used to create PIN-specific URSP rules. At 820, network 810 can respond to the registration request message with a registration accept message. The registration request message may include a policy container containing the PIN 802-specific URSP rules provided by network 810.

[0162] At 822, PIN 802 can be configured with multiple PINE 804a, 804b, PEMC 806, and / or PEGC 808. PEGC 808 can be configured with traffic descriptor determination rules regarding the association of PIN 802, PINE 804a, 804b with connectivity, application descriptors, DNN, and / or application differentiation when multiple applications are running on PINE 804a, 804b.

[0163] PEGC 808 may have one or more traffic descriptor determination rules (e.g., rules for determining the traffic description of PIN 802 traffic) configured via messages received from PEMC 806.

[0164] One or more traffic descriptor determination rules can be provided by H-PCF, for example, via NAS signaling.

[0165] One or more traffic descriptor determination rules can be configured by the PEGC client. The PEGC client can configure one or more traffic descriptor determination rules based on information from PINE 804a, 804b and / or from PIN server 812.

[0166] At 824, UL traffic can be sent from PINE-1 804a to PEGC 808. Additionally or alternatively, uplink traffic can originate from applications within PEGC 808 (e.g., PEGC clients).

[0167] At 826, the PEGC 808 can evaluate UL traffic from PINE-1. Evaluating UL traffic may involve using traffic descriptor determination rules to determine the traffic descriptor associated with the UL traffic. Evaluating UL traffic may also involve using the PIN ID and / or traffic descriptor to determine the characteristics (e.g., DNN, S-NSSAI, and / or SSC modes) of the PDU session used to carry the UL traffic. If the PEGC 808 has already established a PDU session matching the determined characteristics, the PEGC 808 can determine to use the established PDU session to send the UL traffic. If the PEGC 808 determines that no PDU session matching the determined characteristics does not exist, the PEGC 808 can use the determined characteristics to trigger the establishment of a new PDU session with the network. Furthermore, the PEGC 808 can associate the PINE-1 804a-applied UL traffic with this new PDU session.

[0168] At 828, UL traffic can be sent from PINE-2 804b to PEGC 808. Additionally or alternatively, UL traffic can originate from applications within PEGC 808 (e.g., PEGC clients). The initiator of UL traffic may differ from the source of UL traffic generated by PINE-1 804a.

[0169] At 830, the PEGC 808 can evaluate UL traffic from PINE-2 804b by using one or more traffic descriptor determination rules to determine the traffic descriptor associated with UL traffic and / or by using the PIN ID. Furthermore, the PEGC 808 can evaluate the traffic descriptor to determine the characteristics (e.g., DNN, S-NSSAI, and / or SSC modes) of the PDU session carrying the UL traffic. The evaluation of the traffic descriptor determination rules by the PEGC 808 may result in the determination of a different traffic descriptor than that determined for UL traffic from PINE-1 804a.

[0170] The characteristics of traffic received from PINE-2 804b (e.g., source or destination IP address, traffic type, connectivity, and / or DNN / S-NSSAI, etc.) may differ from those of traffic received from PINE-1 804a. Therefore, different traffic descriptors can be determined. When PEGC 808 uses a traffic descriptor determined for UL traffic from PINE-2 804b (e.g., a second traffic descriptor) to determine the characteristics (e.g., DNN, S-NSSAI, and SSC modes) of a PDU session carrying UL traffic received from PINE-2 804b, PEGC 808 can determine one or more characteristics (e.g., second PDU session characteristics) that differ from the PDU session characteristics determined for UL traffic received from PINE-1 804a (e.g., a second DNN, a second S-NSSAI, and / or a second SSC mode).

[0171] If PEGC 808 has already established a PDU session that matches the characteristics of the second PDU session, PEGC 808 can determine to use the established PDU session to send uplink traffic. If PEGC 808 determines that no PDU session matches the characteristics of the second PDU session, PEGC 808 can use the determined characteristics (e.g., second DNN, second S-NSSAI, and / or second SSC mode) to trigger the establishment of a new PDU session with network 810. Furthermore, PEGC 808 can associate PINE-2804b application UL traffic with this new PDU session.

[0172] At position 832, the PEGC 808 can be associated with multiple PDU sessions. Each PDU session can accommodate different types of UL traffic originating from different PINE 804a and 804b and / or applications with different traffic requirements.

Claims

1. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: Receive traffic descriptor determination rules, which indicate the association between uplink personal Internet of Things (PIN) network traffic types and traffic descriptors; Receive User Equipment Routing Policy (URSP) rules, which indicate how to route uplink PIN traffic based on at least one of one or more PIN identifiers (IDs) and traffic descriptors; Receive uplink PIN traffic associated with one or more PIN IDs; Based on the received traffic descriptor determination rules, determine the traffic descriptor for the received uplink PIN traffic; Using the PIN ID and the determined traffic descriptor, based on the evaluation of URSP rules, a Protocol Data Unit (PDU) session associated with the determined traffic descriptor is selected for sending uplink PIN traffic; as well as Send the received uplink PIN traffic to the network via the selected PDU session.

2. The method of claim 1, wherein the traffic descriptor determination rule includes an association between traffic identifiers and corresponding traffic descriptor values.

3. The method of claim 1, further comprising evaluating USRP rules to determine one or more PDU session characteristics, wherein a PDU session for sending uplink PIN traffic is selected based on one or more PDU session characteristics that match the determined PDU session.

4. The method of claim 3, further comprising: It was determined that no established PDU session matched the characteristics of one or more identified PDU sessions; as well as Based on the determination that no established PDU session matches one or more of the identified PDU session characteristics, the establishment of the selected PDU session is triggered.

5. The method of claim 1, wherein the uplink PIN traffic originates from a PIN element (PINE) or an application hosted on a WTRU.

6. The method of claim 1, wherein URSP rules are received from a managed PIN element (PEMC), a network, a PIN server, or an application hosted on a WTRU.

7. The method of claim 1, wherein the uplink PIN traffic type includes one or more of the following: Internet Protocol Multimedia Subsystem (IMS), Internet of Things (IoT) sensor readings, or streaming media.

8. The method of claim 1, wherein the traffic descriptor includes one or more of the following: connectivity, PIN element (PINE) ID, source Internet Protocol (IP) address, source port number, fully qualified domain name (FQDN), data network name (DNN), destination IP address, destination port number, operating system (OS) identifier, or application identifier.

9. The method of claim 1, further comprising sending a request to the network to establish a selected PDU session.

10. The method of claim 1, wherein the uplink PIN traffic is first uplink PIN traffic, the PIN ID is a first PIN ID, the traffic descriptor is a first traffic descriptor, and the selected PDU session is a first selected PDU session, the method further comprising: Receive second uplink PIN traffic associated with a second PIN ID from one or more PIN IDs; The second traffic descriptor for the second uplink PIN traffic is determined based on the received traffic descriptor determination rules. Using the second PIN ID and the second traffic descriptor, a second Protocol Data Unit (PDU) session is selected for sending the second uplink PIN traffic based on the evaluation of the URSP rules; as well as Send the second uplink PIN traffic to the network via the second selected PDU session.

11. A wireless transmit / receive unit (WTRU) including a processor, the processor being configured to: Receive traffic descriptor determination rules, which indicate the association between uplink personal Internet of Things (PIN) network traffic types and traffic descriptors; Receive User Equipment Routing Policy (URSP) rules, which indicate how to route uplink PIN traffic based on at least one of one or more PIN identifiers (IDs) and traffic descriptors; Receive uplink PIN traffic associated with one or more PIN IDs; Based on the received traffic descriptor determination rules, determine the traffic descriptor for the received uplink PIN traffic; Using the PIN ID and the determined traffic descriptor, based on the evaluation of URSP rules, a Protocol Data Unit (PDU) session associated with the determined traffic descriptor is selected for sending uplink PIN traffic; as well as Send the received uplink PIN traffic to the network via the selected PDU session.

12. The WTRU of claim 11, wherein the traffic descriptor determination rule includes an association between a traffic identifier and a corresponding traffic descriptor value.

13. The WTRU of claim 11, wherein the processor is further configured to evaluate USRP rules to determine one or more PDU session characteristics, wherein a PDU session for sending uplink PIN traffic is selected based on one or more PDU session characteristics that match the determined PDU session.

14. The WTRU of claim 13, wherein the processor is further configured to: It was determined that no established PDU session matched one or more of the identified PDU session characteristics; and Based on the determination that no established PDU session matches one or more of the identified PDU session characteristics, the establishment of the selected PDU session is triggered.

15. The WTRU of claim 11, wherein the uplink PIN traffic originates from a PIN element (PINE) or an application hosted on the WTRU.

16. The WTRU of claim 11, wherein URSP rules are received from a managed PIN element (PEMC), a network, a PIN server, or an application hosted on the WTRU.

17. The WTRU of claim 11, wherein the uplink PIN traffic type includes one or more of the following: Internet Protocol Multimedia Subsystem (IMS), Internet of Things (IoT) sensor readings, or streaming media.

18. The WTRU of claim 11, wherein the traffic descriptor includes one or more of the following: connectivity, PIN element (PINE) ID, source Internet Protocol (IP) address, source port number, fully qualified domain name (FQDN), data network name (DNN), destination IP address, destination port number, operating system (OS) identifier, or application identifier.

19. The WTRU of claim 11, wherein the processor is further configured to send a request to the network to establish a selected PDU session.

20. The WTRU of claim 11, wherein the uplink PIN traffic is a first uplink PIN traffic, the PIN ID is a first PIN ID, the traffic descriptor is a first traffic descriptor, and the selected PDU session is a first selected PDU session, and the processor is further configured to: Receive second uplink PIN traffic associated with a second PIN ID from one or more PIN IDs; The second traffic descriptor for the second uplink PIN traffic is determined based on the received traffic descriptor determination rules. Using the second PIN ID and the second traffic descriptor, a second Protocol Data Unit (PDU) session is selected for sending the second uplink PIN traffic based on the evaluation of the URSP rules; as well as Send the second uplink PIN traffic to the network via the second selected PDU session.

Images