Establishing MA PDU sessions over access

Abstract

Systems, methods, and instrumentalities described herein relate to establishing a multi-access (MA) protocol data unit (PDU) session on an access branch. The WTRU may include a processor configured to perform one or more actions. The device may send an MA PDU session setup request on a first branch to a first network node. The device may receive an MA PDU session setup response message from the first network node in response to the MA PDU session setup request. The device may determine a second network to be used for a second branch. The device may determine that the WTRU should register with the second network based on the MA PDU session configuration information. When it is determined that the WTRU should register with the second network, the device may send a registration message to the second network node.

Description

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

[0002] Mobile communication using wireless communication continues to evolve. The fifth generation can be called 5G. The previous generation (traditional) mobile communication can be, for example, the fourth generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0003] This document describes systems, methods, and means related to establishing Multiple Access (MA) Protocol Data Unit (PDU) sessions via an access tributary. In the example, a Wireless Transmit / Receive Unit (WTRU) may include a processor configured to perform methods for establishing an MA PDU session. An MA PDU session establishment request may be sent to a first network node on a first tributary. The first network node may be associated with a first network. In response to the MA PDU session establishment request, an MA PDU session establishment response message may be received from the first network node. For example, the MA PDU session establishment response message may indicate MA PDU session configuration information. A second network may be used for a second tributary. The WTRU may register with the second network based on the MA PDU session configuration information. For example, when it is determined that the WTRU should register with the second network, a registration message may be sent to a second network node. The second network node may be associated with a second network.

[0004] In the example, a second MA PDU session establishment request can be sent to a second network node using a second tributary to establish an MA PDU session on the second tributary. The WTRU can receive an MA PDU policy (MAPP). The MAPP can indicate one or more MA PDU session types. An MA PDU session type can be selected from one or more MA PDU session types. The MA PDU session type can be associated with access options, mobile network options, and / or subscription options. The MA PDU session type can be selected based on at least one MA PDU session selection factor. The MA PDU session selection factor can include at least one of the following: existing MA PDU sessions, existing connections via Radio Access Technology (RAT), WTRU, capabilities, WTRU status, Quality of Service (QoS) characteristics of the applied service, or an indication of the MA PDU session type determined by the network. The MA PDU session establishment request can indicate MA PDU session auxiliary information. The MA PDU session auxiliary information can include at least one of WTRU capabilities, WTRU preferences, or network decisions. The registration message can further indicate the identifier of the first network or an indication of the MA PDU session associated with the first network.

[0005] This document describes systems, methods, and means for providing DualSteer Multiple Access (MA) Protocol Data Unit (PDU) session establishment. In the example, the WTRU can perform one or more of the following actions: MA PDU sessions can be implemented on multiple (e.g., two) 3GPP access tributaries. MA PDU session types can be selected. A MA PDU session of the selected MA PDU session type can be established on a first tributary. For example, a connection can be established on a second tributary based on the MA PDU session type. A MA PDU session of the selected MA PDU session type can be established on the second tributary. For example, enhanced control plane signaling can be enhanced if / while one or more (e.g., specific) MA PDU session types are in progress.

[0006] This document describes systems, methods, and means for establishing MA PDU sessions on a first tributary. In the example, the WTRU can perform one or more of the following operations to establish an MA PDU session on the first tributary. The WTRU and the network can support multiple MA PDU session types, such as different access options (e.g., 3GPP, non-3GPP), different mobile network options (e.g., single mobile network, multiple / two mobile networks), and / or different subscription options (e.g., single subscription, dual subscription). The WTRU operating to establish MA PDU sessions on multiple (e.g., two) 3GPP tributaries can receive a MAPDU policy (MAPP), which may include information allowing the WTRU to determine which MA PDU session type to select. The WTRU can make the MA PDU session type decision based on, for example, MA PDU session selection factors. The WTRU can send a PDU session establishment request message to mobile network 1 on the first tributary. This message may include MA PDU session (MAPS) auxiliary information. The WTRU can receive a PDU session establishment response message, which may include MAPS configuration information. The WTRU can determine the RAT and / or mobile network combination to be used for the second tributary. For example, based on information received in the PDU session establishment response message, the WTRU can determine whether to register with the determined mobile network for the second tributary.

[0007] MAPP can instruct the application flow to (e.g., a specific) MA PDU session type. MA PDU session selection factors may include at least one of ongoing connections, user or WTRU preferences, QoS characteristics, etc. MAPS auxiliary information may include at least one of network decisions, ongoing connections, WTRU capabilities, etc. MAPS configuration information may include at least one of the accepted MA PDU session types, timer values, indications of whether it is a preferred MN that can request registration, etc.

[0008] In the example, the SMF can perform one or more of the following operations to establish an MA PDU session on the first tributary. The WTRU and the network can support multiple MA PDU session types, such as different access options (e.g., 3GPP, non-3GPP), different mobile network options (e.g., single mobile network, two mobile networks), and / or different subscription options (e.g., single subscription, dual subscription). The SMF in the mobile network can receive a PDU session establishment request message from the WTRU (e.g., for establishing the first tributary of the MA PDU session), which may include MAPS auxiliary information. For example, based on the MA PDU session type requested by the WTRU, based on the MAPS auxiliary information provided by / received from the WTRU, and / or based on the WTRU's subscription information, the SMF can determine the MA PDU session type to be used for the MA PDU session. The SMF can send a PDU session establishment response message, which may include MAPS configuration information.

[0009] In the example, the device (e.g., WTRU) may support multiple MA PDU session types. The device may receive a MA PDU policy (MAPP). The device may select an MA PDU session type from multiple supported MA PDU session types, at least in part, based on the MAPP. The device may send an MA PDU session establishment request to a first mobile network on a first tributary. The device may receive an MA PDU session establishment response message in response to the MA PDU session establishment request. The device may determine a second mobile network and radio access technology (RAT) to be used for a second tributary. The device may determine whether to register with the second mobile network based on information received in the MA PDU session establishment response message. The device may establish an MA PDU session on the second tributary based on the determination of whether to register with the second mobile network. The MA PDU session establishment request may include MA PDU session auxiliary information. The MAPP may instruct the WTRU to select an MA PDU session type. The device may select the MA PDU session based at least in part on at least one MA PDU session selection factor.

[0010] The systems, methods, and means described herein may relate to establishing a connection on a second tributary. In the examples, devices (e.g., network nodes, WTRUs, etc.) may be configured to perform one or more of the following actions: A first radio access network (e.g., RAN1) node may perform one or more of the following actions to establish a connection on the second tributary (e.g., a secondary tributary). The WTRU may have registered with a first mobile network (e.g., mobile network 1). The WTRU may have established an MA PDU session on the first tributary (e.g., the primary tributary). The MA PDU session may not request (e.g., require) the WTRU to register with a second mobile network (e.g., mobile network 2) via the second tributary. The first RAN node may receive a first control plane message that may include, for example, an indication that the WTRU wishes to establish a connection to a second (e.g., selected) RAN node (e.g., RAN2 node) in the mobile network. The control plane message may indicate that the WTRU is requesting auxiliary information for the second tributary. The first RAN node can send an N2 message to the Access and Mobility Management Function (AMF) of the first mobile network (e.g., AMF1) to request the establishment of a connection to a second RAN node (e.g., a selected RAN node) and / or to create an NG Application Protocol (NGAP) WTRU-Transport Network Layer Association (TNLA) binding for the second RAN node. The first RAN node can receive a transparent container from the second RAN node, which may include access and non-access stratum (NAS) configurations for the WTRU via a second RAT (e.g., RAT2). The first RAN node can forward the transparent container to the WTRU in a second control plane message (e.g., an RRCReconfiguration message).

[0011] Second branch auxiliary information may indicate one or more of the following: the access branch may be used as the identifier of the second branch, the second RAN node (e.g., RAN2 node), and / or the identifier of AMF1.

[0012] In the example, the WTRU may perform one or more of the following actions to establish a connection on the second tributary. The WTRU may have registered with a first mobile network (e.g., mobile network 1). The WTRU may have (e.g., already) established an MA PDU session on the first tributary. The MA PDU session may not request (e.g., require) the WTRU to register with a second mobile network (e.g., mobile network 2) via the second tributary. The WTRU may determine to establish a connection to the second tributary, for example, based on one or more connection triggering events. The WTRU may send a first control plane message to a first RAN node, which may be associated with the first tributary (e.g., RAN1 node). The control plane message may include, for example, an indication that the WTRU wishes to establish a connection to a second RAN node (e.g., a selected RAN node or RAN2 node) and / or second tributary auxiliary information. The WTRU may receive a second control plane message (e.g., an RRCReconfiguration message) from the RAN1 node, which may include a transparent container from the second RAN node (e.g., RAN2 node). For example, based on the access stratum and NAS configuration included in the transparent container, the WTRU may establish a signaling connection to the second RAN node (e.g., RAN2 node).

[0013] For example, a connection triggering event may include one or more of the following: initiation of an MA PDU session on the first branch, receipt of a PDU session establishment response on the first branch, and / or a NAS message on the first branch.

[0014] In the example, a device (e.g., a RAN node (RAN1) in a first network) may receive a first message including information instructing the WTRU to seek to establish a connection to a selected RAN node in a second mobile network and second tributary assistance information. The device may then send a second message to the AMF in the first mobile network, requesting to establish a connection to the selected RAN node in the second mobile network. The second tributary assistance information may include a second tributary indication indicating that the connection is a second tributary and an AMF identifier identifying the AMF in the first mobile network. The device may use the second tributary indication and the AMF identifier to select a Transport Network Layer (TNL) association between the RAN node and the AMF in the second mobile network. The device may then create a binding between the WTRU and the TNL association.

[0015] The systems, methods, and means described herein may relate to providing MAPDU session rules to the SMF of a second mobile network (Mobile Network 2). In the example, the WTRU can provide assistance by performing one or more of the following: The WTRU may be a MUSIM-capable WTRU. The WTRU may have registered with a first mobile network (Mobile Network 1). The MAPDU session may request (e.g., require) the WTRU to register with Mobile Network 2 via a second tributary. The WTRU may have a separate subscription for registering with Mobile Network 2. Mobile Network 1 and Mobile Network 2 may not have a business relationship (e.g., lack of (standardized) inter-mobile network communication). The WTRU may be configured with a Multi-Universal Subscriber Identity Module (MUSIM) controller. The WTRU may send a PDU session establishment request message to Mobile Network 1. The WTRU may receive a NAS container from the SMF of Mobile Network 1 (SMF1), for example, in a PDU session establishment response message. The NAS container may include information related to the MA PDU session configured through Mobile Network 1. The NAS container may be provided to the MUSIM controller. The MUSIM controller can provide a NAS container to the NAS layer (NAS2) of the second subscriber identity module (SIM2). The WTRU can determine the RAT and / or mobile network for the second tributary. The WTRU (e.g., the MUSIM controller) can instruct the NAS layer of SIM2 that the WTRU needs to establish an MA PDU session for mobile network 2 on the second tributary. The MUSIM controller can provide, for example, NAS containers and / or MA PDU session support information received from SMF1. The WTRU can send a PDU session establishment request message for mobile network 2 on the second tributary. This message may include the received NAS container. The WTRU can receive a PDU session establishment acceptance message for mobile network 2 on the second tributary. The WTRU can transmit and / or receive services through the MA PDU session.

[0016] In the example, a device (e.g., a WTRU) can send a first MA PDU session establishment request to a first mobile network on a first tributary via a first Universal Subscriber Identity Module (USIM). The device can receive a first MA PDU session establishment response message in response to the first MA PDU session establishment request, wherein the first MA PDU session establishment response message includes MA PDU session information for the first network. The device can provide the MA PDU session information for the first network to the MUSIM controller. The device can determine the second mobile network and RAT to be used for the second tributary. The device can provide an indication to the second USIM via the MUSIM controller that the WTRU seeks to establish an MA PDU session for the second mobile network on the second tributary. The device can send a second MA PDU session establishment request to the second mobile network on the second tributary via the second USIM. The MA PDU session information for the first network can be received in a NAS container from the SMF in the first mobile network. This indication can include the MA PDU session information and MA PDU session support information for the first network. The second MA PDU establishment request can include MA PDU session information for the first network. 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 may be implemented; Figure 1B The illustration shows a method according to one embodiment. Figure 1A The illustrated system diagram shows an example wireless transmit / receive unit (WTRU) used in a communication system. Figure 1C The illustration shows a method according to one embodiment. Figure 1A The illustrated system diagram shows an example radio access network (RAN) and an example core network (CN) used in the communication system. Figure 1D The illustration shows a method according to one embodiment. Figure 1A The illustrated system diagram shows yet another example RAN and yet another example CN used in the communication system; Figure 2 The illustration shows an example of service data flow via dual connections.

[0018] Figure 3 The illustration shows a sample program for configuring and using an MA PDU session.

[0019] Figure 4 The illustration shows an example of MA PDU session type 1.

[0020] Figure 5 The illustration shows an example of MA PDU session type 2.

[0021] Figure 6 Examples of MA PDU session types 3 and 4 are illustrated.

[0022] Figure 7 The illustration shows an example of MA PDU session type 5.

[0023] Figure 8 The illustration shows an example of MA PDU session type 6.

[0024] Figure 9 The illustration shows an example of MA PDU session type 7.

[0025] Figure 10 The illustration shows an example of registration to the second branch MN.

[0026] Figure 11 The diagram illustrates an example architecture for MUSIM WTRU. Detailed Implementation

[0027] Figure 1A This is a schematic diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multi-access system that provides content such as voice, data, video, messages, and broadcasts to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing 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 Spread Spectrum OFDM (ZT UWDTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0028] 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 should 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 may be any type of device configured to operate and / or communicate in a wireless environment. For example, 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 industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs.

[0029] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may 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, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), node B, eNode B, home node B, home eNode B, gNB, NR node B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0030] 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. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0031] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116. Air interface 116 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.

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

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

[0034] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can establish an air interface 116 using a new radio (NR).

[0035] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can jointly implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0036] 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., 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), etc.

[0037] For example, Figure 1ABase station 114b can be a wireless router, home node B, home eNodeB, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, etc. 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 one 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 be directly connected to the Internet 110. Therefore, base station 114b may not need to access the Internet 110 via CN 106 / 115.

[0038] 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, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. 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 in Figure 1A Although not shown, it should be understood that 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 may 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.

[0039] CN 106 / 115 can also serve 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.

[0040] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the 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 may employ cellular-based radio technology, and to communicate with base station 114b, which may employ IEEE 802 radio technology.

[0041] Figure 1B This is a system diagram illustrating example WTRU 102. (Example:) Figure 1B As shown, among other things, WTRU 102 may include, in particular, 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, etc. It should be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0042] 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, etc. 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, which may be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0043] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) over 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 one embodiment, transmitting / receiving element 122 can be, for example, a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF and optical signals. It should be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0044] 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 on air interface 116.

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

[0046] 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 therefrom. 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 and store information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. 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, etc. In other embodiments, the processor 118 can access and store information from memory that is not physically located on WTRU 102 (e.g., a server or home computer (not shown)).

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

[0048] 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, information from the GPS chipset 136, the WTRU 102 may receive location information on the air interface 116 from base stations (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0049] 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 videos), 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, etc. 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, attitude sensors, biosensors, and / or humidity sensors.

[0050] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., signals associated with specific subframes for 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 to reduce and / or substantially eliminate self-interference via hardware (e.g., chokes) or via signal processing by a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., signals associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0051] Figure 1C This diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As described 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.

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

[0053] 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 UL and / or DL, etc. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other on the X2 interface.

[0054] 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 described as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0055] The MME 162 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface and can act 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, etc. 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.

[0056] 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, and managing and storing the context of WTRUs 102a, 102b, and 102c.

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

[0058] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRU 102a, 102b, and 102c with access to a circuit-switched network such as PSTN 108, facilitating communication between WTRU 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRU 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.

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

[0060] In a representative embodiment, another network 112 may be a WLAN.

[0061] 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 access or interface with a distributed system (DS) or another type of wired / wireless network that transmits traffic to 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 an external BSS can be sent to the AP for delivery to the appropriate destination. For example, traffic between STAs within the BSS can be transmitted via the AP, where the source STA can send traffic to the AP, and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be transmitted 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 Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have 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 is sometimes referred to here as the "ad-hoc" communication mode.

[0062] 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 a fixed width (e.g., a wide bandwidth of 20 MHz) 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, each STA, including the AP, can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0063] 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.

[0064] Very High Throughput (VHT) STAs 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, the data passes through a segment resolver, which splits the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0065] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV whitespace (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support metering-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0066] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as the primary channel. The bandwidth of the primary channel can be 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 the STA among all STAs operating in the BSS that supports the minimum bandwidth operating mode. In the example of 802.11ah, for STAs that support (e.g., only support) the 1 MHz 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 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings may 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 available band remains idle and can be available.

[0067] 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. The total available bandwidth for 802.11ah is 6 MHz to 26 MHz, depending on the country code.

[0068] Figure 1D This diagram illustrates a system diagram of RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0069] RAN 113 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c on 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, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, 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 one embodiment, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0070] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable digitization. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ for 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 a variable number of OFDM symbols and / or a continuously variable absolute time).

[0071] 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 utilize 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 / connect with gNBs 180a, 180b, and 180c, while also communicating / connecting with another RAN such as eNode-Bs 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, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0072] 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 user plane data to User Plane Functions (UPF) 184a and 184b, and routing control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other on the Xn interface.

[0073] 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 possibly a Data Network (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0074] AMF 182a and 182b can connect to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act 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 SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service types used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency Time (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, and / or so on. 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.

[0075] 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 services through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0076] UPF 184a and 184b can be connected to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface. This N3 interface provides 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. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0077] CN 115 can facilitate communication with other networks. For example, CN 115 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 115 and PSTN 108. Furthermore, 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 may be connected to local data networks (DNs) 185a and 185b via the N3 interface to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

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

[0079] Simulation devices can be designed to perform tests on one or more other devices in laboratory and / or carrier network environments. 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 perform tests using over-the-air wireless communication.

[0080] One or more simulation devices may perform one or more functions, including all functions, rather than being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices may be used to test test scenarios in laboratory and / or non-deployment (e.g., testing) wired and / or wireless communication networks to implement the testing of one or more components. One or more simulation devices may be test devices. Simulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0081] The term "timer" in this document can refer to time, time period, time tracking, time period tracking, combinations thereof, and / or the like. The term "timer expiration" in this document can refer to determining that the time may have occurred or that the time period may have expired.

[0082] This document describes systems, methods, and means related to establishing Multiple Access (MA) Protocol Data Unit (PDU) sessions on an access tributary. In the example, a Wireless Transmit / Receive Unit (WTRU) may include a processor configured to perform methods for establishing a MA PDU session. A MA PDU session establishment request may be sent to a first network node on a first tributary. The first network node may be associated with a first network. In response to the MA PDU session establishment request, an MA PDU session establishment response message may be received from the first network node. For example, the MA PDU session establishment response message may indicate an MA PDU policy (MAPP). A second network may be used for a second tributary. The WTRU may register with the second network based on the MAPP. For example, when it is determined that the WTRU should register with the second network, a registration message may be sent to a second network node. The second network node may be associated with a second network.

[0083] In the example, a second MA PDU session establishment request can be sent to a second network node using a second tributary to establish an MA PDU session on the second tributary. The MAPP can indicate one or more MA PDU session types. Access options associated with the second network can be selected based on the MA PDU session type from one or more MA PDU session types. Access options can be selected based on the MA PDU session type and / or at least MA PDU session selection factors. MA PDU session selection factors can include at least one of the following: existing MA PDU sessions, existing connections via Radio Access Technology (RAT), WTRU capabilities, WTRU status, Quality of Service (QoS) characteristics of the application service, or an indication of the MA PDU session type determined by the network. The MA PDU session establishment request can indicate MA PDU session auxiliary information. The MA PDU session auxiliary information can be associated with a first network. The MA PDU session auxiliary information can include the identifier of the first network or the MA PDU session type associated with the first network.

[0084] One or more devices (e.g., a Radio Transmit / Receive Unit (WTRU)) can be configured to perform at least one of the following actions: MA PDU sessions can be enabled on multiple (e.g., two) 3GPP access tributaries. A MA PDU session type can be selected. A MA PDU session of the selected MA PDU session type can be established on a first tributary. For example, a connection can be established on a second tributary based on the MA PDU session type. A MA PDU session of the selected MA PDU session type can be established on the second tributary. For example, enhanced control plane signaling can be enhanced if / while one or more (e.g., specific) MA PDU session types are in progress.

[0085] This article describes the systems, methods, and means related to establishing MA PDU sessions on the first branch.

[0086] One or more devices (e.g., WTRU) can be configured to perform at least one of the following actions as described herein. In the example, the WTRU can perform at least one of the following actions to establish an MA PDU session on the first tributary. The WTRU and / or the network can support multiple MA PDU session types, such as different access options (e.g., 3GPP, non-3GPP), different mobile network options (e.g., a single mobile network, multiple (e.g., two) mobile networks), and / or different subscription options (e.g., single subscription, dual subscription, and / or so on).

[0087] A WTRU used to establish MA PDU sessions on multiple (e.g., two) 3GPP tributaries can receive an MA PDU policy (MAPP). The MAPP may include information allowing the WTRU to determine the type of MA PDU session to select. The WTRU can make the MA PDU session type decision based on MA PDU session selection factors. The WTRU may send a PDU session establishment request message to a mobile network (e.g., mobile network 1) on the first tributary. This message may include MA PDU session (MAPS) auxiliary information. The WTRU can receive a PDU session establishment response message. The PDU session establishment response message may include MAPS configuration information. The WTRU can determine the RAT and / or mobile network combination to be used for the second tributary. The WTRU may determine whether to register with the mobile network determined for the second tributary based on the information received in the PDU session establishment response message.

[0088] MAPP can instruct the application flow to (e.g., a specific) MA PDU session type mapping.

[0089] MA PDU session selection factors may include at least one of the following: ongoing connection, user preference, WTRU preference, QoS characteristics, and / or others.

[0090] MAPS auxiliary information may include at least one of the following: network decisions, ongoing connections, WTRU capabilities, and / or more.

[0091] MAPS configuration information may include at least one of the following: the accepted MA PDU session type, timer value, indication of whether (e.g., preferred) MN can request (e.g., can be required) registration, and / or so on.

[0092] One or more devices (e.g., SMF) can be configured to perform at least one of the following actions (e.g., operations). In the example, the SMF can perform at least one of the following actions to establish a MAPDU session on a first tributary. The WTRU and the network can support multiple MA PDU session types, such as, for example, different access options (e.g., 3GPP, non-3GPP), different mobile network options (e.g., single mobile network, multiple (e.g., two) mobile networks), and / or different subscription options (e.g., single subscription, dual subscription). The SMF (e.g., configured as a part of the mobile network) can receive a PDU session establishment request message from the WTRU (e.g., to establish the first tributary of the MA PDU session). The PDU session establishment request may include MAPS auxiliary information. The SMF can determine the MA PDU session type to be used for the MA PDU session based on the MA PDU session type requested by the WTRU, the MAPS auxiliary information provided and / or received from the WTRU, and / or the subscription information for the WTRU. The SMF can send a PDU session establishment response message. The PDU session establishment message may include MAPS configuration information.

[0093] An apparatus may include a processor configured to perform one or more actions as described herein. In an example, the apparatus (e.g., a WTRU) may support multiple MA PDU session types. The apparatus may receive a MAPP. The apparatus may select an MA PDU session type from multiple supported MA PDU session types, at least in part based on the MAPP. The apparatus may send an MA PDU session establishment request to a first mobile network on a first tributary. The apparatus may receive an MA PDU session establishment response message in response to the MA PDU session establishment request. The apparatus may determine a second mobile network and a RAT to be used for a second tributary. The apparatus may determine whether to register with the second mobile network based on information received in the MA PDU session establishment response message. The apparatus may establish an MA PDU session on the second tributary based on the determination of whether to register with the second mobile network. The MA PDU session establishment request may include MA PDU session auxiliary information. The MAPP may indicate to the WTRU whether an MA PDU session type can be selected. The apparatus may select an MA PDU session, at least in part based on at least one MA PDU session selection factor.

[0094] This article describes the systems, methods, and means related to establishing connections on the second branch.

[0095] One or more devices (e.g., network nodes, WTRUs) can be configured to perform at least one of the following actions as described herein. In an example, a first radio access network (e.g., RAN1) node can perform at least one of the following actions to establish a connection on a second tributary (e.g., a secondary tributary). The WTRU may have registered with a first mobile network (e.g., mobile network 1). The WTRU may have established an MA PDU session on the first tributary (e.g., the primary tributary). The MA PDU session may not request (e.g., require) the WTRU to register with a second mobile network (e.g., mobile network 2) via the second tributary. The first RAN node can receive a first control plane message. This first control plane message may include an indication that the WTRU wishes to establish a connection to a second (e.g., selected) RAN node (e.g., RAN2 node) in the mobile network. The control plane message may indicate that the WTRU may be requesting auxiliary information for the second tributary. The first RAN node can send an N2 message to the AMF (e.g., AMF1) of the first mobile network. The N2 message may request the establishment of a connection to a second RAN node (e.g., a selected RAN node) and / or the creation of an NG Application Protocol (NGAP) WTRU-Transport Network Layer Association (TNLA)-binding for the second RAN node (e.g., it may be referred to as a UE-TNLA-binding). The first RAN node may receive a transparent container from the second RAN node. The transparent container from the second RAN node may include access layer and / or non-access layer (NAS) configurations for the WTRU via a second RAT (e.g., RAT2). The first RAN node may forward the transparent container to the WTRU in a second control plane message (e.g., an RRCReconfiguration message).

[0096] The second branch auxiliary information may indicate at least one of the following: the access branch may be used as the identifier of the second branch, the second RAN node (e.g., RAN2 node), and / or the identifier of AMF1.

[0097] The WTRU may perform at least one of the following actions to establish a connection on the second tributary: The WTRU may have registered with a first mobile network (e.g., mobile network 1). The WTRU may have (e.g., already) established an MA PDU session on the first tributary. The MA PDU session may not request (e.g., require) the WTRU to register with a second mobile network (e.g., mobile network 2) via the second tributary. The WTRU may determine whether to establish a connection with the second tributary based on one or more connection trigger events. The WTRU may send a first control plane message to a first RAN node. The first control plane message may be associated with the first tributary (e.g., RAN1 node). The first control plane message may include an indication that the WTRU wishes to establish a connection to a second RAN node (e.g., a selected RAN node or RAN2 node), and / or may include second tributary auxiliary information. The WTRU may receive a second control plane message (e.g., an RRCReconfiguration message) from the RAN1 node. The second control plane message may include a transparent container from the second RAN node (e.g., RAN2 node). The WTRU may establish a signaling connection to the second RAN node (e.g., RAN2 node) based on the access stratum and NAS configuration included in the transparent container.

[0098] Connection triggering events may include at least one of the following: initiation of an MA PDU session on the first branch, receipt of a PDU session establishment response on the first branch, and / or a NAS message on the first branch.

[0099] An apparatus may include a processor configured to perform one or more actions. In an example, the apparatus (e.g., a RAN node in a first network (RAN1)) may receive a first message including information instructing a WTRU to send a request (e.g., a proclamation) to establish a connection to a selected RAN node in a second mobile network, and second tributary assistance information. The apparatus may send a second message to an AMF in the first mobile network requesting the establishment of a connection to the selected RAN node in the second mobile network. The second tributary assistance information may include a second tributary indication indicating that the connection is a second tributary, and an AMF identifier identifying the AMF in the first mobile network. The apparatus may use the second tributary indication and the AMF identifier to select a Transport Network Layer (TNL) association between the RAN node and the AMF in the second mobile network. The apparatus may create a binding between the WTRU and the TNL association.

[0100] This article describes systems, methods, and means related to second branches (e.g., auxiliary branches) registered to mobile networks.

[0101] One or more devices (e.g., WTRU) can be configured to perform at least one of the following actions. In the example, the WTRU can perform at least one of the following actions to establish a connection on the second tributary. The WTRU can be a WTRU supporting a Multiple Universal Subscriber Identity Module (MUSIM). The WTRU may have registered with a first mobile network (Mobile Network 1). The WTRU may have (e.g., already) established an MA PDU session on the first tributary. The MA PDU session can request (e.g., require) the WTRU to register with a second mobile network (e.g., Mobile Network 2) via the second tributary. The WTRU may have (e.g., a separate) subscription for registering with the second mobile network (e.g., Mobile Network 2). The WTRU may have a MUSIM controller. The WTRU can determine that the mobile network used for the second tributary is the second mobile network (e.g., Mobile Network 2). The WTRU (e.g., the MUSIM controller) can indicate to the Non-Access (NAS) layer of the second Subscriber Identity Module (SIM2) that the WTRU needs to register with the second mobile network (e.g., Mobile Network 2). The MUSIM controller can provide MA PDU session support information. The WTRU can establish a connection to the RAN node of the second tributary (e.g., RAN2 node) by sending control plane messages. Control plane messages may include registration request messages. The WTRU can receive registration acceptance messages from the AMF of mobile network 2 (e.g., AMF2). Registration acceptance messages may include registration restriction information and / or instructions for simplifying dual subscription behavior. The WTRU (e.g., MUSIM controller) can indicate to the NAS layer of SIM2, based on the activity of the MA PDU session at the WTRU (e.g., dynamically), whether / when to initiate registration to the second mobile network (e.g., mobile network 2) and / or whether / when to terminate registration to the second mobile network (e.g., mobile network 2). The WTRU can deregister and / or re-register to the second mobile network (e.g., mobile network 2) based on the activity of the MA PDU session at the WTRU.

[0102] MA PDU session support information may include at least one of the following: MA PDU session indication, (e.g., other) MN identifier, and / or (e.g., other) AMF identifier.

[0103] Registration restriction information may include one or more of the following: time value, schedule, and / or volume value.

[0104] Simplified dual subscription can provide an indication of a business relationship on a mobile network. Simplified dual subscription can be established using a simplified MA PDU session.

[0105] A device may include a processor configured to perform one or more actions. In an example, the device (e.g., a WTRU) may establish an MA-PDU session in a first mobile network via a first tributary. The device may instruct the Universal Subscriber Identity Module (USIM) via a MUSIM controller to request the WTRU to register an MA PDU session with a second mobile network. The device may receive a registration acceptance message from the second mobile network, which may include an indication of dual subscription behavior based on the relationship between the first and second mobile networks. This indication may include MA PDU session support information indicating the MA PDU session, an identifier of the second mobile network, and / or an identifier of the first mobile network. The device may instruct the USIM via the MUSIM controller whether / when to initiate and / or terminate registration with the second mobile network based on the WTRU MA PDU session activity.

[0106] This document describes systems, methods, and means related to providing MA PDU session rules to the SMF of a second mobile network (Mobile Network 2). One or more devices (e.g., WTRUs) may (e.g., be configured to) perform one or more of the actions described herein. In an example, the WTRU may provide assistance by performing one or more of the following actions described herein. The WTRU may be a MUSIM-enabled WTRU. The WTRU may have registered with a first mobile network (Mobile Network 1). The MA PDU session may request (e.g., require) the WTRU to register with Mobile Network 2 via a second tributary. The WTRU may have (e.g., a separate) subscription for registering with Mobile Network 2. Mobile Network 1 and Mobile Network 2 may not have a business relationship (e.g., lack of (standardized) inter-mobile network communication). The WTRU may be configured with a MUSIM controller. The WTRU may send a PDU session establishment request message to Mobile Network 1. The WTRU may receive a NAS container (e.g., in a PDU session establishment response message) from the SMF (SMF1) of Mobile Network 1. The NAS container may include information related to the MA PDU session configured through Mobile Network 1. A NAS container can be provided to the WTRU (e.g., the MUSIM controller). The WTRU (e.g., the MUSIM controller) can provide the NAS container to the NAS layer of the second subscriber identification module (e.g., NAS2 of SIM2). The WTRU can determine the RAT and / or mobile network for the second tributary. The WTRU (e.g., the MUSIM controller) can instruct the NAS layer of SIM2 that the WTRU needs to establish an MA PDU session for mobile network 2 on the second tributary. The WTRU (e.g., the MUSIM controller) can provide the NAS container and / or MA PDU session support information received from SMF1. The WTRU can send a PDU session establishment request message for mobile network 2 on the second tributary. The PDU session establishment request message may include the received NAS container. The WTRU can receive a PDU session establishment acceptance message for mobile network 2 on the second tributary. The WTRU can transmit and / or receive services through the MA PDU session.

[0107] An apparatus may include a processor configured to perform one or more actions. The apparatus (e.g., a WTRU) may send a first MA PDU session establishment request to a first mobile network via a first USIM on a first tributary. The apparatus may receive a first MA PDU session establishment response message in response to the first MA PDU session establishment request. The first MA PDU session establishment response message may include MA PDU session information of the first network. The apparatus may provide the MA PDU session information of the first network to a MUSIM controller. The apparatus may determine a second mobile network and RAT to be used for a second tributary. The apparatus (e.g., the WTRU) may (e.g., via a MUSIM controller to a second USIM) provide an indication that the apparatus (e.g., the WTRU) requests (e.g., seeks) to establish an MA PDU session for the second mobile network on the second tributary. The apparatus may send a second MA PDU session establishment request to the second mobile network on the second tributary (e.g., via a second USIM). The MA PDU session information of the first network may be received in a NAS container from an SMF in the first mobile network. This indication may include MA PDU session information and MA PDU session support information of the first network. The second MA PDU session establishment request may include MADU session information from the first network.

[0108] This document describes systems, methods, and means related to establishing an MA PDU session on a first tributary. One or more devices (e.g., a WTRU) can be configured to perform one or more of the following actions to establish a MA PDU session on the first tributary. The WTRU and / or the network can support one or more MA PDU session types, such as different access options (e.g., 3GPP, non-3GPP), different mobile network options (e.g., a single mobile network, multiple (e.g., two) mobile networks), and / or different subscription options (e.g., single subscription, dual subscription, and / or so on). The WTRU operating to establish MA PDU sessions on multiple (e.g., two) 3GPP tributaries can receive a MAPP. The MAPP can include information that allows the WTRU to determine the MA PDU session type to select. The WTRU can make the MA PDU session type decision based on MA PDU session selection factors. The WTRU can send a PDU session establishment request message to mobile network 1 on the first tributary. This message can include MA-PDU session (MAPS) auxiliary information. The WTRU can receive a PDU session establishment response message. The PDU session establishment response message can include MAPS configuration information. The WTRU can determine the RAT and / or mobile network combination to be used for the second tributary. The WTRU can determine whether to register with the mobile network determined for the second tributary based on information received in the PDU session establishment response message.

[0109] MAPP can instruct the application flow to (e.g., a specific) MA PDU session type mapping.

[0110] MA PDU session selection factors may include at least one of the following: ongoing connection, user preference, WTRU preference, QoS characteristics, and / or others.

[0111] MAPS auxiliary information may include at least one of the following: network decisions, ongoing connections, WTRU capabilities, and / or more.

[0112] MAPS configuration information may include at least one of the following: the accepted MA PDU session type, timer value, indication of whether (e.g., preferred) MN requests (e.g., requires) registration, and / or so on.

[0113] One or more devices (e.g., SMFs) may (e.g., be configured to) perform one or more of the following actions. In the example, the SMF may perform one or more of the following actions to establish a MAPDU session on a first tributary. The WTRU and the network may support multiple MA PDU session types, such as different access options (e.g., 3GPP, non-3GPP), different mobile network options (e.g., a single mobile network, multiple (e.g., two) mobile networks), and / or different subscription options (e.g., single subscription, dual subscription, and / or so on). The SMF, configured as part of the mobile network, may receive a PDU session establishment request message from the WTRU (e.g., to establish the first tributary of the MA PDU session). The PDU session establishment request message may include MAPS assistance information. The SMF may determine the MA PDU session type to be used for the MA PDU session based on the MA PDU session type requested by the WTRU, the MAPS assistance information provided and / or received from the WTRU, and / or subscription information to the WTRU. The SMF may send a PDU session establishment response message. The PDU session establishment response message may include MAPS configuration information.

[0114] This document describes systems, methods, and means related to establishing a connection on a second tributary. One or more devices (e.g., a radio access network (RAN), a WTRU) can be configured to perform one or more of the following actions. In an example, a first RAN (e.g., RAN1) node can perform one or more of the following actions to establish a connection on the second tributary: The WTRU may have registered with a first mobile network (Mobile Network 1). The WTRU may have (e.g., already) established an MA PDU session on the first tributary. The MA PDU session may not request (e.g., require) the WTRU to register with a second mobile network (Mobile Network 2) via the second tributary. The RAN1 node can receive a first access stratum control plane message. The first access stratum control plane message may include an indication that the WTRU wishes to establish a connection to (e.g., a selected) RAN node (e.g., RAN2 node) in Mobile Network 2 and / or second tributary assistance information. RAN1 node can send an N2 message to the AMF (e.g., AMF1) of the first mobile network 1 to request the establishment of a connection to the selected RAN2 node and / or to create an NG Application Protocol (NGAP) WTRU-Transport Network Layer Association (TNLA) binding for the RAN2 node. RAN1 node can receive a transparent container from the RAN2 node. The transparent container from the RAN2 node can include access layer and NAS configurations for the WTRU via RAT2. RAN1 node can forward the transparent container to the WTRU in a second control plane message (e.g., an RRCReconfiguration message).

[0115] Second branch auxiliary information can indicate at least one of the following: the access branch can be used as the second branch, the identifier of the RAN2 node, or the identifier of AMF1.

[0116] The WTRU may perform one or more of the following actions to establish a connection on the second tributary. The WTRU may have already registered with Mobile Network 1. The WTRU may have already established an MA PDU session on the first tributary. The MA PDU session may not request (e.g., require) the WTRU to register with Mobile Network 2 via the second tributary. The WTRU may establish a connection to the second tributary based on one or more connection trigger events (e.g., determine). The WTRU may send a first control plane message to the RAN node (RAN1 node) of the first tributary. The control plane message may include an indication that the WTRU wishes to establish a connection to (e.g., a selected) RAN node (RAN2 node) and / or second tributary auxiliary information. The WTRU may receive a second control plane message (e.g., an RRCReconfiguration message) from the RAN1 node. The second control plane message may include a transparent container from the RAN2 node. The WTRU may establish a signaling connection to the RAN2 node based on the access stratum and NAS configuration included in the transparent container.

[0117] Connection triggering events may include at least one of the following: initiation of an MA PDU session on the first branch, receipt of a PDU session establishment response on the first branch, and / or a NAS message on the first branch.

[0118] This document describes systems, methods, and means related to registration to a second tributary mobile network. One or more devices (e.g., WTRU) may (e.g., be configured to) perform one or more of the following actions. In the example, the WTRU may perform one or more of the following actions to establish a connection on the second tributary. The WTRU may be a MUSIM-enabled WTRU. The WTRU may have registered with a first mobile network (Mobile Network 1). The WTRU may have (e.g., already) established an MA PDU session on the first tributary. The MA PDU session may request (e.g., require) the WTRU to register to a second mobile network (Mobile Network 2) via the second tributary. The WTRU may have (e.g., a separate) subscription for registering to Mobile Network 2. The WTRU may have a MUSIM controller. The WTRU may determine that the mobile network for the second tributary may be Mobile Network 2. The WTRU (e.g., the MUSIM controller) may indicate to the NAS layer of the second Subscriber Identity Module (SIM2) that the WTRU needs to register to Mobile Network 2. The MUSIM controller may provide MA PDU session support information. The WTRU can establish a connection to the RAN node (RAN2 node) of the second tributary by sending control plane messages. Control plane messages may include registration request messages. The WTRU can receive registration acceptance messages from the AMF (AMF 2) of mobile network 2. Registration acceptance messages may include registration restriction information and / or instructions for simplified dual subscription behavior. The WTRU (e.g., the MUSIM controller) can (e.g., dynamically) indicate to the NAS layer of SIM2 whether / when to initiate registration to mobile network 2. The WTRU (e.g., the MUSIM controller) can (e.g., dynamically) indicate to the NAS layer of SIM2 whether / when to terminate registration to mobile network 2 (e.g., based on the activity of the MA PDU session at the WTRU). The WTRU can deregister and reregister to mobile network 2 based on the activity of the MA PDU session at the WTRU.

[0119] MA PDU session support information may include at least one of the following: MA PDU session indication, other MN identifiers and / or other AMF identifiers.

[0120] Registration restriction information may include at least one of the following: time value, schedule, and / or capacity value.

[0121] Simplified dual subscription can provide an indication of a business relationship on a mobile network. Simplified dual subscription can be established using a simplified MA PDU session.

[0122] This document describes systems, methods, and means related to providing MA PDU session rules to the SMF of a second mobile network (Mobile Network 2). One or more devices (e.g., WTRUs) can be configured to perform one or more of the following actions (e.g., operations). In the example, the WTRU can provide assistance by performing one or more of the following: The WTRU can be a MUSIM-enabled WTRU. The WTRU may have registered with a first mobile network (Mobile Network 1). The MA PDU session can request (e.g., require) the WTRU to register with Mobile Network 2 via a second tributary. The WTRU may have a (e.g., separate) subscription for registering with Mobile Network 2. Mobile Network 1 and Mobile Network 2 may not have a business relationship (e.g., lack of (standardized) inter-mobile network communication). The WTRU can be configured with a MUSIM controller. The WTRU can send a PDU session establishment request message to Mobile Network 1. The WTRU can receive a NAS container (e.g., in a PDU session establishment response message) from the SMF (SMF1) of Mobile Network 1. The NAS container can include information related to the MA PDU session configured through Mobile Network 1. The NAS container can be provided to the MUSIM controller. The MUSIM controller can provide a NAS container to the NAS layer of the second subscriber identification module (e.g., NAS2 of SIM2). The WTRU can determine the RAT and / or mobile network for the second tributary. The WTRU (e.g., the MUSIM controller) can instruct the NAS layer of SIM2 that the WTRU needs to establish an MA PDU session for mobile network 2 on the second tributary. The MUSIM controller can provide NAS containers and / or MA PDU session support information received from SMF1. The WTRU can send a PDU session establishment request message for mobile network 2 on the second tributary. This message may include the received NAS container. The WTRU can receive a PDU session establishment acceptance message for mobile network 2 on the second tributary. The WTRU can transmit and / or receive services through the MA PDU session.

[0123] Session and Mobility Management: WTRUs can provide their Session Management (SM) and / or Mobility Management (MM) capabilities to the core network. For example, a WTRU may send its MM core network capability information to the AMF during the initial registration procedure and / or mobility registration update procedure (e.g., within a NAS message). WTRUs may provide 5GSM core network capabilities in PDU session establishment and / or modification requests. Messages (e.g., these following messages) may include the WTRU's Access Service Bootstrapping, Handover, and Split (ATSSS) capabilities.

[0124] The WTRU may (e.g., upon request or by requirement) perform registration with the network (e.g., if the WTRU needs access to a service that requires registration). The WTRU may perform registration based on one or more actions, such as by performing one or more of the following: Public Land Mobile Network (PLMN) selection or Independent Non-Public Network (SNPN) selection, cell selection and / or reselection, and / or registration.

[0125] The WTRU can select a mobile network using either PLMN selection or SNPN selection. The network can be public or non-public. The WTRU can follow rules to determine how to select from available networks at a given location, and / or to determine whether / when to seek a higher-priority network.

[0126] WTRUs can use cell selection and / or reselection procedures to camp on cells.

[0127] WTRUs can use a registration process to notify the network of their presence and / or provide rough location information.

[0128] Traffic can be split across multiple (e.g., two) 3GPP access tributaries. The WTRU can support carrier aggregation (CA). CA can be provided via (e.g., a single) 3GPP access (e.g., New Radio (NR) or Long Term Evolution (LTE)) while allowing the WTRU to receive (e.g., via) two or more cells. Cells can (e.g., each) operate on different frequency carriers. The use of multiple (e.g., two) cells can be managed (e.g., entirely) within the RAN.

[0129] The WTRU can support dual connectivity (DC). The DC allows the WTRU to receive and / or transmit on multiple (e.g., two) 3GPP access points (e.g., or 3GPP access tributaries). The access points can be NR (gNB) or LTE (eNB). The deployment can have a first tributary on LTE and a second tributary on NR. The DC deployment can support multiple (e.g., two) tributaries on NR. These multiple (e.g., two) tributaries can be on different frequency bands (e.g., FR1 and FR2). The WTRU can employ a DC using a radio frequency (RF) front-end to support both types of access. Within the DC, one tributary can be a primary tributary (e.g., it can be part of the primary cell group (MCG),) and / or the other tributary can be a secondary tributary (e.g., it can be part of the secondary cell group (SCG)).

[0130] The WTRU can support communication over satellite links. Communication over satellite links allows the WTRU to receive and / or transmit data via transparent satellite and / or repeater links (e.g., utilizing satellites and / or repeaters in different orbits such as Geostationary Orbit (GEO), Medium Earth Orbit (MEO), Low Earth Orbit (LEO), and / or High Altitude Platform Station (HAPS)). The WTRU can communicate via transparent satellites and / or repeaters using an RF front end.

[0131] The WTRU can support various combinations of dual connectivity and carrier aggregation. The WTRU can have dual connectivity via multiple (e.g., two) 3GPP access tributaries. (e.g., each) tributary can use carrier aggregation. (e.g., the set of cells on one access tributary) can be referred to as a cell group. The WTRU can have dual connectivity with one or more (e.g., two) tributaries via transparent satellite and / or repeater links. At least one of the following scenarios can be supported: Tributary 1: NR and Tributary 2: GEO satellite; Tributary 1: NR and Tributary 2: LEO and / or MEO satellite; and / or Tributary 1: GEO satellite and Tributary 2: LEO / MEO satellite.

[0132] A WTRU with a DC (Distributed Data Unit) can allow operation on multiple (e.g., two) 3GPP access tributaries. The WTRU (e.g., in the DC) can be configured to map data radio bearers (DRBs) across multiple (e.g., two) access tributaries. The WTRU can be configured with MCG (Multi-Channel Group) bearers, where traffic from data bearers traverses the primary tributary. The WTRU can be configured with SCG (Multi-Channel Group) bearers, where traffic from data bearers traverses the secondary tributary. The WTRU can be configured with split bearers, where traffic from data bearers can be split between the primary and secondary tributaries. Processing above the Radio Link Control (RLC) layer (e.g., all processing) can be in the primary tributary. Processing below the Packet Data Convergence (PDCP) layer (e.g., all processing) can be in the primary tributary or the secondary tributary.

[0133] Figure 2 The diagram illustrates an example of service data flow over a dual-connection setup. Figure 2Examples of how downlink service data flows (SDFs) can propagate on a network (e.g., a 5G network) and / or how they can be transmitted on data radio bearers are illustrated. An SDF can be mapped to a QoS flow at an ingress point (e.g., a UPF). Traffic on a QoS flow can reach a RAN node, where it can be mapped to a DRB and transmitted via the radio interface. An SDF can be mapped to (e.g., a single) QoS flow. A QoS flow can be mapped to (e.g., a single) DRB. A DRB can be transmitted on a single tributary or split across multiple (e.g., two) tributaries. Different SDFs can (e.g., as a result) depend on a DC. Different SDFs can be transmitted on different 3GPP accesses. A (e.g., a single) SDF in a DRB may not be split, switched, bootstrap, and / or replicated on multiple (e.g., two) different 3GPP accesses.

[0134] The selection of access tributaries can be determined by the PDCP layer (e.g., primarily based on estimated data volume, much like how much data a WTRU might have to transmit). The estimated data volume measurement can reflect (e.g., all) traffic in the DRB. There may be no mechanism (e.g., as a result) to control the selection of access tributaries for each SDF, and / or different metrics may be used for selection.

[0135] SDFs can be split, switched, bootstrap, and / or replicated across multiple (e.g., two) tributaries. Multiple tributaries can be 3GPP tributaries. At least one of the following can be provided: upper-layer bootstrap, split, and / or switchover of WTRU services (e.g., belonging to the same data session) across multiple (e.g., two) 3GPP access links. A single subscription to a PLMN can exist. A single PLMN, a PLMN plus a (standalone) non-public network (NPN), multiple (e.g., two) PLMNs, and / or the same or different RATs (e.g., 3GPP RATs, such as NR, NTN, plus NR, NTN, or LTE) can exist.

[0136] Multiple (e.g., two) networks (e.g., for PLMN+, PLMN and / or NPN scenarios) can be managed by the same operator or different operators (e.g., there are commercial agreements between them).

[0137] ATSSS may rely on the concept of MA connections. An MA connection can include establishing an MA PDU session, where traffic from a serving data flow can be transmitted on a first network (e.g., a 3GPP) access tributary, a second network (e.g., a non-3GPP) access tributary, or both access tributaries. One or more rules (e.g., session rules) can be configured and / or applied to establish a PDU session. The applied rules may depend on whether the WTRU is registered on both accesses, and if so, whether the registration is to the same PLMN; whether the WTRU is registered on both accesses, and if so, whether the registration is to different PLMNs (e.g., whether the registration is associated with different PLMNs); and / or whether the WTRU can register on one of the accesses.

[0138] Bootstrapping functionality can be used as part of ATSSS. Bootstrapping functionality refers to the logic used to implement service switching, bootstrapping, and / or splitting. Bootstrapping functionality can include or be based on: Multipath Transmission Control Protocol (MPTCP), Multipath QUIC, and / or ATSSS Lower Layer (ATSSS-LL). MPTCP functionality can be used for TCP services. MPQUIC functionality can be used for UDP services. MPQUIC can be a multipath extension of QUIC, which is an encrypted, connection-oriented protocol operating at the transport layer of the OSI model. ATSSS-LL bootstrapping functionality can be used for Ethernet, TCP, or UDP services.

[0139] Booting modes can be provided in ATSSS based on booting functionality. Booting modes can include at least one of the following: active-standby mode, minimum latency mode, load balancing mode, priority-based mode, and / or redundant booting mode. Booting modes can instruct WTRUs (e.g., and / or UPFs) whether / when to switch, boot, split, and / or replicate uplink traffic (e.g., and / or downlink traffic) from one access tributary to another.

[0140] A bootstrapping mode can be provided (e.g., a single one) for service data flows. The Policy Control Function (PCF) can provide bootstrapping mode configuration to the WTRU in an ATSSS rule and / or to the UPF (e.g., in an N4 rule). The PCF can make decisions based on QoS parameters (e.g., requirements) from the AF and / or based on the WTRU's capabilities. The PCF can (e.g., if necessary) decide to change the bootstrapping mode configuration used for service data flows (e.g., based on changes to QoS requirements).

[0141] A WTRU can have one or more identities. A Subscription Permanent Identifier (SUPI) can be a globally unique identifier assigned to each subscriber in a network (e.g., 5G). SUPI values ​​can be provided in the USIM and / or Unified Data Management (UDM) and / or User Data Repository (UDR) functions (e.g., in the 5G core). The SUPI can be an International Mobile Subscriber Identifier (IMSI) or a Network Access Identifier (NAI). The IMSI version of the SUPI can include one or more (e.g., three) digits. In the example, one or more (e.g., the first three) digits can represent a Mobile Country Code (MCC). One or more digits (e.g., the next two or three) can represent a Mobile Network Code (MNC) (e.g., identifying a network operator or PLMN). One or more digits (e.g., the remaining digits) can represent a Mobile Subscriber Identifier Number (MSIN).

[0142] The Subscription Hidden Identifier (SUCI) can be a privacy-protected identifier that includes a hidden SUPI. The SUCI may include the home network's PLMN ID (e.g., in the MCC and / or MNC). The MCC and / or MNC may be transmitted in plaintext.

[0143] A globally unique temporary identifier (GUTI) can be assigned by the AMF. The AMF can assign a new GUTI to a WTRU at any time. The GUTI may include, for example, a globally unique AMF ID (GUAMI) and a temporary mobile subscriber identity (TMSI). The GUAMI can identify the assigned AMF. The TMSI can identify the WTRU within the AMF, for example, uniquely. The GUAMI may include a PLMNID and / or an AMF identifier (for example, a concatenation of them).

[0144] A WTRU, which can be considered a MUSIM device, can have multiple USIMs in operation at similar times (e.g., simultaneously, concurrently). Each USIM can allow the WTRU to obtain service from different mobile networks. An example use case for a MUSIM device could be a professional with separate business and personal numbers. Instead of carrying two phones, the professional could use a single phone with multiple (e.g., two) USIM cards.

[0145] The terminal behavior regarding the simultaneous processing of multiple USIMs may depend on the WTRU's capabilities (e.g., a WTRU with a single Rx / single Tx, a WTRU with dual Rx / single Tx, and / or a WTRU with dual Rx / dual Tx). Dual Rx allows the MUSIM WTRU to receive traffic from multiple (e.g., two) networks simultaneously. A single Rx allows the MUSIM WTRU to receive traffic from one network at a time (e.g., once). A single Tx allows the MUSIM WTRU to transmit traffic to one network at a time (e.g., once).

[0146] Multiple (e.g., two) USIMs can operate independently of each other. Each USIM (e.g., each USIM) can utilize (e.g., requiring the WTRU to have) a dedicated non-access stratum and access stratum protocol stack. Coordination (e.g., depending on the WTRU's capabilities) can be used to allow the WTRU to obtain services from multiple mobile networks. Coordination may not depend on mobile network interactions. The WTRU can (e.g., as a result) act as an intermediary between multiple (e.g., two) mobile networks.

[0147] Subscriptions to multiple (e.g., two) network operators via a MUSIM device can be designated as dual subscriptions. Different subscriptions to network operators (e.g., each, not involving a MUSIM device) can be designated as single subscriptions.

[0148] AMF can use an interface (e.g., the N14 interface) for AMF reassignment and / or AMF-to-AMF information transfer. This interface can be within a PLMN or between PLMNs (e.g., in the example of inter-PLMN mobility).

[0149] For inter-PLMN mobility, the source AMF can select one or more AMF instances in the target PLMN (e.g., by querying the target PLMN-level NRF via the source PLMN-level Network Repository (NRF) using the target PLMN ID). The target PLMN-level NRF can return the AMF instance address based on the target operator configuration. The AMF can select a different AMF (e.g., after a handover procedure).

[0150] The ATSSS function allows the WTRU to split, bootstrap, switch, and / or replicate Service Data Flow (SDF) traffic on multiple network types (e.g., 3GPP access and non-3GPP access). The DC can allow the WTRU to have a first SDF on a first (e.g., 3GPP) access and a second SDF traffic on a second (e.g., 3GPP) access. Splitting, bootstrap, switching, and / or replicating SDF traffic may or may not be permitted. Access supporting the DC can be terrestrial and / or non-terrestrial (e.g., via PLMN and SNPN).

[0151] Dual Steer can extend ATSSS functionality by allowing the WTRU to split, bootstrap, switch, and / or replicate SDF traffic on multiple (e.g., two) 3GPP network accesses (e.g., non-terrestrial 3GPP and SNPN).

[0152] Dual-boot functionality can include a WTRU with multiple (e.g., two) network (e.g., 3GPP) access tributaries. The access tributaries can be different RATs (e.g., LTE and NR), different RAT types (e.g., terrestrial and satellite), different PLMNs and / or different PLMN types (e.g., Home PLMN (HPLMN), NPN and / or Visitor PLMN (VPLMN)).

[0153] MA PDU sessions can be established with multiple (e.g., two) network (e.g., 3GPP) access tributaries and used for uplink and / or downlink traffic transmission.

[0154] Depending on the radio access options (e.g., 3GPP access tributaries, non-3GPP access tributaries), mobile network options (e.g., a single mobile network for multiple access tributaries and / or one mobile network per access tributary), and different subscription options (e.g., a single subscription for multiple access tributaries and / or a dual subscription for each access tributary), the WTRU can use one or more MA PDU session types for MA PDU sessions. The WTRU and / or the network can select between different MA PDU session types.

[0155] For example, after the WTRU may have established an MA PDU session on the first access tributary of the first mobile network, the WTRU can connect to the second access tributary. The WTRU can then register with the mobile network of the second access tributary (e.g., in a dual subscription scenario).

[0156] In the example, the MA PDU session can rely on dual subscription. The WTRU can connect to the second access tributary. The WTRU can establish an MA PDU session on the second tributary to receive configuration for the MA PDU session (e.g., considering that mobile networks may not be able to communicate with each other).

[0157] A MA PDU session can refer to a PDU session with multiple (e.g., two) access tributaries. These access tributaries can use different access technologies. An MA PDU session can be of the ATSSS type, where one access tributary can be a first-type network (e.g., a 3GPP access tributary), and the other access tributary can be a second-type network (e.g., a non-3GPP access tributary). An MA PDU session can be of the dual-boot type, where multiple access tributaries are in the same type of network (e.g., a 3GPP access tributary). The RAN nodes of the access tributaries can be connected to the same mobile network or different mobile networks.

[0158] A tributary can refer to a path between the WTRU and the network. In the example, 3GPP tributaries and / or non-3GPP tributaries can be understood as tributaries from the general network to the WTRU tributary example.

[0159] A 3GPP tributary can refer to a transmission path between a WTRU and the network. This transmission path may rely on a 3GPP RAT (e.g., WCDMA, LTE, and / or NR technologies). The RAT can be on licensed, unlicensed, and / or reserved frequency bands. A 3GPP tributary can be via a terrestrial or satellite link. A 3GPP tributary can be directly from the WTRU to the base station (e.g., via the Uu interface). A 3GPP tributary can also be indirectly from the WTRU to the base station (e.g., via one or more relay WTRUs).

[0160] A non-3GPP tributary can refer to a transport path between the WTRU and the network. This transport path may rely on a non-3GPP RAT (e.g., WiFi). The RAT may be on licensed, unlicensed, or reserved frequency bands. Non-3GPP tributaries may rely on non-3GPP interoperability functions (N3IWF), trusted non-3GPP gateway functions (TGNF), or residential gateways (e.g., 5G RG).

[0161] A mobile network (MN) can refer to a PLMN, NPN, or (e.g., any) network infrastructure that manages one or more access nodes and WTRUs. Access nodes can provide connectivity to the WTRU via wireless or wired mechanisms.

[0162] The home MN can refer to the home mobile network of the WTRU (e.g., HPLMN). The home MN can maintain subscription information for the WTRU. User plane services can be transferred from the visited mobile network to the home MN (e.g., in a home routing mobility scenario).

[0163] A visited MN can refer to a visited mobile network of a WTRU (e.g., a VPLMN). A WTRU can (e.g., if / when roaming) obtain service from a visited MN. In some examples (e.g., local breakout mobility scenarios), user plane services can be transferred from the visited MN to the data network.

[0164] A RANx node can refer to a RAN node on a RATx. A RAN node can be a gNB, eNB, and / or others (e.g., for a 3GPP RAT).

[0165] NFy can refer to the network function (NF) in the mobile network y. NF can be SMF, AMF, PCF, UDM and / or etc.

[0166] If / when MNs have a business relationship, they can communicate with each other. For example, multiple MNs can communicate between multiple (e.g., two) Security Edge Protection Agents (SEPPs) using one or more interfaces (e.g., N32 interfaces). SEPPs can perform message filtering and censorship on the control plane interface between MNs.

[0167] MAPS rules can refer to rules used by WTRU and / or UPF for an MA PDU session. These rules can be a superset of ATSSS rules. The rules may include bootstrap functions, boot modes, and / or other configuration information that can be used in the MA PDU session (e.g., the address of a Performance Management Function (PMF)).

[0168] A linked SA PDU session can refer to a single access PDU session used to provide connectivity for a second tributary. Linked SA PDU sessions can be used to transfer IP services between the WTRU and PSA UPF.

[0169] This document describes an example of dual-boot functionality (e.g., where both access tributaries are 3GPP access tributaries). The example described herein applies to other multi-tribute scenarios, including ATSSS functionality (e.g., where one access tributary can be 3GPP and the other access tributary can be non-3GPP).

[0170] MA PDU sessions can be implemented on multiple (e.g., two) 3GPP access tributaries. The MA PDU session type can be selected. A MA PDU session of the selected MA PDU session type can be established on the first tributary. A connection can be established on the second tributary based on the MA PDU session type. A MA PDU session of the selected MA PDU session type can be established on the second tributary. Enhanced control plane signaling can be enhanced if / while one or more (e.g., certain) MA PDU session types are in progress.

[0171] The benefits provided by one or more examples described herein may include enabling the WTRU to select the MA PDU session type. These benefits may include enabling the WTRU to establish MA PDU sessions of the selected type on multiple (e.g., two) 3GPP access tributaries based on the tributary's RAT (e.g., LTE, NR), tributary RAT type (e.g., terrestrial, satellite), tributary PLMN, tributary PLMN type (e.g., HPLMN, NPN, VPLMN), and / or subscriptions on the tributary. Potential reductions in control plane signaling (e.g., in paging) may be provided for the second access tributary.

[0172] MA PDU sessions can be established and operated. An MA PDU session allows the WTRU and UPF to transmit one or more SDF services (e.g., uplink and / or downlink) on multiple (e.g., two) access tributaries. (E.g., each) an access tributary can be a 3GPP tributary or a non-3GPP tributary. (E.g., each) an access tributary can be a part of the same MN or a part of different MNs. Multiple alternatives can exist to implement an MA PDU session. (E.g., each) an example can be referred to as an MA PDU session type. This document describes one or more (e.g., several) of various MA PDU session types.

[0173] Figure 3 The illustration shows a sample program used to configure and use an MA PDU session. Figure 3 As shown, an MA PDU session can be configured for use with and associated with an SDF (e.g., with an accompanying description). A WTRU can register in MN1. MN1 can be a home MN or a visited MN. A WTRU can register in MN2, or it can choose not to register in MN2.

[0174] At point 1, a policy can be provided to the WTRU, for example, as part of the WTRU Routing Policy (URSP). The WTRU can use this policy to determine which MA PDU session type to use for the SDF. The WTRU can (e.g., if / when the WTRU initiates a new flow) determine whether the WTRU needs to initiate a new MA PDU session. The WTRU can (e.g., also) determine the MA PDU session type (e.g., as described herein).

[0175] At point 2, the WTRU can establish an MA PDU session on the first tributary. The WTRU can provide the network with MA PDU session assistance information (MAP AI) (e.g., supporting MA PDU session types as described herein).

[0176] At point 3, WTRU can determine the RAT and / or MN combination to be used for the second branch. The MN of the second branch can be represented as MN2.

[0177] At point 4, the WTRU can establish a connection on the second branch. Based on the MA PDU session type and / or existing connection, the WTRU can register with MN2. The WTRU can use instructions regarding the MA PDU session in MN2 to perform registration updates (e.g., as described herein).

[0178] At point 5, the WTRU can establish MA PDU sessions on the second branch. The WTRU can provide MAP AI to the network (e.g., as described in this article) to support the MA PDU session type.

[0179] At point 6, WTRU and UPF can use the selected MA PDU session type to deliver user plane traffic. Control plane signaling enhancements (e.g., as described herein) can be provided for (e.g., certain) MA PDU session types.

[0180] MA PDU session types can be based on different access options (e.g., 3GPP, non-3GPP), different MN options (e.g., single MN, multiple (e.g., two) MNs), different subscription options (e.g., single subscription, dual subscription) and / or so on.

[0181] WTRU and UPF can have a variety (e.g., many) possibilities for establishing MA PDU sessions. MA PDU sessions can have at least one of the following types: type 1, type 2, type 3, type 4, type 5, type 6 and / or type 7.

[0182] Figure 4 The illustration shows an example of MA PDU session type 1. Type 1 can involve (e.g., one) 3GPP tributary and (e.g., one) non-3GPP tributary. Multiple (e.g., two) tributaries can be on the same MN or on different MNs. Type 1 can be referred to as MA PDU session type 1 (e.g., as...). Figure 4 (As shown in the example).

[0183] Figure 5 The illustration shows an example of MA PDU session type 2. Type 2 can involve multiple (e.g., two) 3GPP tributaries on the same MN. Multiple (e.g., two) 3GPP tributaries can be connected to the same MN. Type 2 can be referred to as MA PDU session type 2 (e.g., as...). Figure 5 (As shown in the example). A WTRU can have a separate registration on (e.g., each) access segment. A WTRU can have a single registration used on multiple (e.g., two) access tributaries.

[0184] Figure 6 Examples of MA PDU session types 3 and 4 are illustrated. Type 3 (e.g., a single subscription with a requested (e.g., a required second registration)) can involve multiple (e.g., two) 3GPP tributaries on different MNs using the single subscription. (e.g., each) a 3GPP tributary can be connected to a different MN. The WTRU can have a single subscription (e.g., a single subscription to the home MN). In the example, MN1 can be the home MN, and MN2 can be the visiting MN. In the example, MN2 can be the home MN, and MN1 can be the visiting MN. In the example, MN1 and MN2 can both be visiting MNs. Different MNs can (e.g., are assumed to) have a business relationship with themselves. The WTRU can (e.g., needs to register to an MN (e.g., a visiting MN or a home MN) to use the MN for an MA PDU session. Type 3 can be referred to as a Type 3 MA PDU session (e.g., as... Figure 6 (As shown in the example). Figure 6 The second UPF (UPF2) between the 3GPP Access Tributary 2 node and the PSA UPF is shown. The second UPF (UPF2) can be located at the N9 interface of the visited MN that has a PDU Session Anchor (PSA) UPF.

[0185] Type 4 (e.g., a single subscription without a requested (e.g., required) second registration) can involve multiple (e.g., two) 3GPP tributaries on different MNs using a single subscription. (e.g., each) a 3GPP tributary can be connected to a different MN. The WTRU can have a single subscription (e.g., to the home MN). In the example, MN1 can be the home MN, and MN2 can be the visited MN. In the example, MN2 can be the home MN, and MN1 can be the visited MN. In the example, MN1 and MN2 can both be visited MNs. Different MNs can have business relationships with each other. In the example (e.g., a Type 4 MA PDU session type), the WTRU may not need to (e.g., firstly) register to the visited MN to use the MN for an MA PDU session. Type 4 can be referred to as a Type 4 MA PDU session (e.g., as... Figure 6 (As shown in the example).

[0186] Figure 7The illustration depicts an example of MA PDU session type 5. Type 5 (e.g., dual subscription to a cooperating MN) can involve multiple (e.g., two) 3GPP tributaries on different MNs using dual subscription. (e.g., each) a 3GPP tributary can be connected to a different MN. The WTRU can be a MUSIM-enabled WTRU. For example, one SIM can be connected to a first MN, while another SIM can be connected to a second MN. The different MNs can (e.g., are assumed to be) have a business relationship, allowing the WTRU to use the services of both MNs. In the example (e.g., type 5 MA PDU session type), the WTRU can (e.g., need to) register to both MNs. MNs can communicate to facilitate interaction between MNs. The WTRU can (e.g., are assumed to be) have MUSIM controller functionality. MUSIM functionality can allow interaction between activities on multiple (e.g., two) SIMs. Type 5 can be referred to as a type 5 MA PDU session (e.g., as...). Figure 7 (As shown in the example).

[0187] Figure 8 The illustration shows an example of MA PDU session type 6. Type 6 (e.g., dual subscription to a non-cooperative MN) can involve multiple (e.g., two) 3GPP tributaries on different MNs using dual subscription. (e.g., each) a 3GPP tributary can be connected to a different MN. The WTRU can be a MUSIM-enabled WTRU. In the example, (e.g., one) SIM can be connected to a first MN, while a second (e.g., another) SIM can be connected to a second MN. The different MNs may (e.g., are assumed to be) without a business relationship. In the example (e.g., type 6 MA PDU session type), the WTRU may (e.g., need to) register with both MNs. If the MNs have no business relationship, there may be no inter-MN communication. The WTRU may (e.g., are assumed to be) have MUSIM controller functionality. MUSIM controller functionality can facilitate interaction between activities on multiple (e.g., two) SIMs. Type 6 can be referred to as a type 6 MA PDU session (e.g., as...). Figure 8 (As shown in the example).

[0188] Figure 9An example of MA PDU session type 7 is illustrated. Type 7 (e.g., SA PDU session of the second tributary) can involve multiple (e.g., two) access tributaries on the same or different MNs, where the second access tributary uses a linked SA PDU session to establish a connection (e.g., IP connection) between the WTRU and the PSA UPF. The PDU session on the first access tributary can be a MA PDU session. The PDU session on the first tributary can include a UPF and WTRU configured to route (or receive) traffic on the second tributary using the connection established on the linked SA PDU session. The access tributary of type 7 MA PDU session can be a 3GPP or non-3PPP access tributary. The mobile network of each (e.g., each) access tributary can be the same mobile network or different mobile networks. For different mobile networks, the WTRU can have (e.g., a single) subscription to different mobile networks, or the WTRU can have dual subscriptions to different mobile networks. Type 7 can be referred to as a type 7 MA PDU session (e.g., as...). Figure 9 (As shown in the example).

[0189] MA PDU session type 1 can be referred to as the ATSSS type. Other MA PDU session types can be considered different versions of the dual-boot type. Although examples are described with reference to the seven types (types 1-7), these examples can be applied to other MA PDU session types, such as the ATSSS-lite version. In the example ATSSS-lite version, the MA PDU session can have one 3GPP tributary and one non-3GPP tributary. The non-3GPP tributary may not be connected to (e.g., any) MN.

[0190] Figure 6-8 The PDU session anchor (PSA) UPF shown (e.g., for MA PDU session types 3 to 6) can be a part of the home MN (e.g., referred to as the home route) or a part of the visited MN (e.g., referred to as the local route).

[0191] A WTRU (e.g., for type 5 and / or type 6 MA PDU sessions) can be a MUSIM-enabled WTRU. A WTRU can be configured (e.g., always) to register with one or more (e.g., two) MNs. A WTRU can register with a second MN (e.g., only) if / when the MA PDU session requires it (e.g., if MUSIM capabilities can (e.g., only) be used for the second 3GPP access tributary of the MA PDU session). The MUSIM controller can instruct the NAS layer of SIM2 whether / when to initiate registration to the second MN and / or whether / when to terminate registration to the second MN (e.g., based on the activity of the MA PDU session at the WTRU).

[0192] The WTRU can (for example, determine) initiate an MA PDU session. The WTRU can determine and / or select the type of MA PDU session to be provided in the MA PDU session.

[0193] The WTRU may be provided with a MAPP. The MAPP may include information that allows the WTRU to determine which MA PDU session type to select. The MAPP may be a portion of the URSP obtained in the registration accept message, the PDU session establishment message, and / or the modification accept message. This policy (e.g., the MAPP) may bind (e.g., a specific) application flow to (e.g., a specific) MA PDU session type. This policy may inform the WTRU that the PDU session can be an MA PDU session. This policy (e.g., the MAPP) may leave the session type decision to the WTRU and / or the network. The WTRU may determine which MA PDU session type to use based on at least one of the following MA PDU session selection factors: existing MA PDU session, existing connection on a second 3GPP RAT, existing connection on a non-3GPP RAT, WTRU capabilities, internal state, (e.g., measured) metrics, QoS characteristics of the application service, and / or network preferences.

[0194] The WTRU can determine which MA PDU session type to use based on existing MA PDU sessions. If the WTRU (e.g., has already) made an MA PDU session active using one of the session types, the WTRU can (e.g., select) use the same MA PDU session type (e.g., the same type) (e.g., this can allow the WTRU to save power by not initiating a transmission on a new access tributary).

[0195] The WTRU can determine which MA PDU session type to use based on existing connections on the second 3GPP RAT. If the WTRU is using (e.g., has already used) the second 3GPP RAT, the WTRU can (e.g., preferably and / or determine) use MA PDU session types 2-6. In the example, the DC feature or Dual Active Protocol Stack (DAPS) feature can allow the WTRU to save power by not initiating new non-3GPP access.

[0196] The WTRU can determine which MA PDU session type to use based on existing connections on a non-3GPP RAT. If the WTRU is (e.g., has been) using a non-3GPP RAT, the WTRU can (e.g., preferably and / or determine) use MA PDU session type 1 (e.g., this can allow the WTRU to save power by not initiating a new 3GPP access).

[0197] The WTRU can determine which MA PDU session type to use based on its capabilities. If the WTRU does not support MUSIM (for example, the WTRU is not configured with MUSIM capability and / or a MUSIM controller), the WTRU can select from MA PDU session types 1-4.

[0198] The WTRU can determine which MA PDU session type to use based on its internal state. If the WTRU is power-constrained, it can select the MA PDU session type that minimizes power consumption. The WTRU can determine that power usage is lower than on non-3GPP access and, as a result, prefer and / or select MA PDU session type 1.

[0199] The WTRU can determine which MA PDU session type to use based on (e.g., measured) metrics. In the example, the WTRU may have information about signal quality on non-3GPP links and / or second 3GPP links. The WTRU can (e.g., determine) which session type maximizes signal quality. In the example, the WTRU may have information about congestion on non-3GPP links and / or second 3GPP links. The WTRU can (e.g., determine) which session type minimizes (e.g., on non-3GPP links and / or on second 3GPP links).

[0200] The WTRU can determine which MA PDU session type to use based on the QoS characteristics of the application service. The WTRU can determine the application's QoS request (e.g., required) (e.g., guaranteed) bit rate. The WTRU can select the MA PDU session type that provides (e.g., better) support for the (e.g., guaranteed) bit rate. The WTRU can select a first access over a second access based on QoS characteristics (e.g., always select one access over another). The WTRU can (e.g., always) select a session type where the second tributary is a 3GPP tributary (e.g., MA PDU session type 2-6) to reduce and / or minimize latency.

[0201] The WTRU can determine which MA PDU session type to use based on network preferences. For example, a network may have preferences regarding session type options. This preference can be provided to the WTRU in a NAS message (e.g., using a registration accept message or a PDU session establishment accept message).

[0202] WTRU can select the MA PDU session type based on MAPP (e.g., MA PDU policy) and / or MA PDU session selection factors.

[0203] MAPP can have a set of MAPP rules. This set of MAPP rules can correspond to ATSSS rules (e.g., the MAPP rule set can be provided to the WTRU along with other ATSSS rules). MAPP and / or ATSSS rules can include one or more MN IDs. The MN ID can indicate which MN to use. MN IDs can be ordered by network preferences. If there is more than one WTRU and / or if the WTRU is a wildcard, the WTRU can select an MN ID. MAPP and / or ATSSS rules can include one or more MA PDU session types. MAPP and / or ATSSS rules can include indications for minimizing power consumption. MAPP and / or ATSSS rules can include minimum signal quality.

[0204] MA PDU sessions can be established on the first tributary. The WTRU can provide information to the mobile network on the first access tributary to assist in establishing MA PDU sessions with multiple (e.g., two) 3GPP access tributaries.

[0205] The WTRU can determine whether (e.g., if the WTRU needs to) initiate an MA PDU session. The WTRU can determine the MA PDU session type. The WTRU can establish an MA PDU session on the first access tributary. The WTRU can include MAPS auxiliary information in the PDU session establishment request message to MN1. The MAPS auxiliary information can include at least one of the following: the selected MA PDU session type, the MA PDU session, network decisions, a list of MN IDs that the WTRU can use for the MA PDU session, a metric (e.g., a metric of measurement), MA PDU session type user preferences, WTRU preferences, WTRU capabilities, an active second SIM, active non-3GPP and / or active 3GPP.

[0206] MAPS auxiliary information may include the selected MA PDU session type. The MA PDU session type may be one of the seven MA PDU session types described herein (e.g., types 1-7).

[0207] MAPS auxiliary information may include the MA PDU session. The MA PDU session can provide an indication that the requested PDU session request is for the MA PDU session.

[0208] MAPS auxiliary information can include network decisions. Network decisions can provide the network with an indication of which MAPDU session type the network can select.

[0209] MAPS auxiliary information may include a list of MN IDs that the WTRU can (e.g., is able to) use for an MA PDU session.

[0210] MAPS auxiliary information may include (e.g., measured) metrics. The WTRU can provide an indication of the current power state. The network may prefer one or more (e.g., certain) MA PDU session types, depending on whether the WTRU is in at least one of the following: power-limited, connected to mains power, operating on battery, having a battery state below a threshold, having a battery state above a threshold, and / or so on.

[0211] MAPS ancillary information may include user preferences for MA PDU session types. A user may prefer a first (e.g., one) MA PDU session type over a second (e.g., another). In the example, a user can provide preferences for WTRUs on a graphical user interface. Preferences (e.g., supply) can be provided to MN1 in the MAPS ancillary information.

[0212] MAPS auxiliary information can include WTRU preferences. If the network selects an MA PDU session type, the WTRU can indicate these preferences. In the example, the WTRU might prefer MA PDU session types with MUSIM, or (e.g., only) rely on MA PDU session types with non-3GPP access. The WTRU can indicate that it prefers MA PDU session types that minimize or maximize metrics. In the example, the network might select MA PDU session types that minimize WTRU power consumption, maximize WTRU throughput, and / or minimize roaming costs.

[0213] MAPS auxiliary information may include one or more WTRU functions. WTRU may indicate the ability to support one or more (e.g., certain) MA PDU session types.

[0214] MAPS auxiliary information may include an active second SIM (e.g., the WTRU has an indication that the second SIM is active). The WTRU (e.g., also) may include an identifier of the MN to which the second SIM can register.

[0215] MAPS auxiliary information may include active non-3GPP connections (e.g., an indication of whether the WTRU has an ongoing non-3GPP connection). The WTRU (also, for example) may include an identifier of the WTRU via its MN having a non-3GPP connection. The network can use this information to favor MA PDU session types that support a second tributary (e.g., a non-3GPP-based second tributary).

[0216] MAPS auxiliary information may include active 3GPP. Active 3GPP may include an indication of whether the WTRU (WTRU) has a connection on the second 3GPP tributary (e.g., already has). The WTRU (WTRU) may also indicate how the second tributary is used. In the example, the WTRU may indicate that the second tributary is used to support DC or DAPS. The network can use this information (e.g., MAPS auxiliary information) to favor MA PDU session types that support the second tributary (e.g., 3GPP-based second tributary).

[0217] SMF1 can use the provided MAPS auxiliary information to determine the configuration of MA PDU sessions with multiple (e.g., two) 3GPP access tributaries. Configuration information for MA PDU sessions with multiple (e.g., two) 3GPP access tributaries can be provided to the WTRU.

[0218] SMF1 can determine the MA PDU session type and / or the MAPS configuration for the session type based on the MA PDU session type requested by the WTRU, the MAPS auxiliary information provided by the WTRU, and / or the WTRU's subscription information.

[0219] SMF1 can respond to WTRU with PDU session establishment acceptance. PDU session establishment acceptance may include at least one of the following MAPS configuration information: accepted MA PDU session type, MAPS rules, (e.g., preferred) radio access type, (e.g., preferred) frequency band type, (e.g., preferred) MN and / or timer value.

[0220] PDU session establishment acceptance can indicate MAPS rules. MAPS rules can indicate rules related to configured boot functions, boot modes, performance monitoring, and / or others.

[0221] PDU session establishment acceptance can indicate the preferred radio access type. The preferred radio access type can be for a second tributary (e.g., 3GPP or non-3GPP, terrestrial or satellite, direct or indirect).

[0222] The PDU session establishment acceptance can indicate (e.g., preferred) frequency band type. The frequency band type can be the preferred frequency band type for the second tributary (e.g., licensed, unlicensed, reserved). The SMF (e.g., also) can provide an indication of the frequency band.

[0223] PDU session establishment acceptance may indicate (e.g., preferred) MN. PDU session establishment acceptance may include (e.g., preferred) MN or (e.g., preferred) list of MNs. SMF may provide an indication for each MN (e.g., for each preferred MN) whether that (e.g., preferred) MN requests (e.g., requires) registration.

[0224] PDU session establishment acceptance can indicate a timer value. This timer value can provide an indication to the WTRU to wait for the timer value (amount) before establishing a connection for the second tributary. The timer value can instruct the WTRU to wait for a command (e.g., an explicit command) from the network before establishing a connection for the second tributary. The timer value (e.g., a delay indicated by the timer) can allow MN1 to delay and / or control whether / when the WTRU initiates one or more (e.g., two) tributaries using an MA PDU session. The timer value (e.g., the delay) can be useful if the first and second tributaries are on the same mobile network.

[0225] In the example, MAPS auxiliary information can be an extension of the WTRU ATSSS capability. The extended ATSSS functionality can be routed to the PCF via the SMF. The PCF can make decisions regarding MAPS configuration information. MAPS configuration information can be included in the extended ATSSS rules. The PCF can set the extended ATSSS rules.

[0226] The WTRU can establish a connection via the selected second tributary. The WTRU can determine the RAT and / or MN combination to be used for the second tributary. Once the WTRU has determined to initiate an MA PDU session and knows and / or determines the MA PDU session type, it can determine the RAT and / or MN combination. The WTRU NAS layer can request (e.g., demand) the access layer to find the RAT and / or MN combination for the second tributary. The access layer can report the found RAT and / or MN combination. The NAS layer (e.g., the WTRU) can make a selection. The WTRU can select the RAT and / or MN. The RAT selected by the WTRU can be referred to as RAT2. The MN selected by the WTRU can be referred to as MN2. The WTRU can (e.g., as part of establishing a connection via RAT2) synchronize with the RAN node of RAT2 and / or establish a signaling connection to the RAN node of RAT2. Establishing a connection via RAT2 can be equivalent to establishing an RRC connection to the gNB (e.g., if RAT2 is an NR). WTRU can (e.g., if required) register with MN2 via the second branch, or WTRU can (e.g., if registration is not required) notify AMF1 that WTRU wants to establish a connection via RAT2.

[0227] The WTRU can decide whether to perform registration via the second branch. In the example, the WTRU may not need to register via the second branch. If MN2 is the same as MN1 (e.g., the second branch passes through the same MN as the first branch), registration may not be required. The resulting MA PDU session can (e.g., in the example where MN2 is the same as MN1) be MA PDU session type 2. If MN2 is different from MN1, registration may not be required. In the example, MN2 can behave as if it is visiting MN. The resulting PDU session (e.g., if MN2 behaves as if it is visiting MN) can be MA PDU session type 4.

[0228] The WTRU can determine whether (e.g., whether the WTRU needs to) perform registration through MN2. In the example, if MN2 == MN1, the WTRU can be configured not to perform registration. The WTRU can determine that registration to MN2 is unnecessary based on information included in the WTRU's USIM (e.g., such as in an operator-controlled PLMN selector with access technology parameters). The home MN operator can include in the parameters an indication of (e.g., each) PLMN to indicate whether registration to the MN is requested (e.g., required), such as whether the MN is used as a second branch of an MA PDU session. (E.g., additionally and / or alternatively) This determination can be made based on information received in a previous MA PDU session establishment response. The previous MA PDU session establishment response can indicate that the preferred MN requests (e.g., requires) registration.

[0229] Registration to the second branch MN may not be requested (e.g., required). WTRU can be triggered to establish a connection to RAT2. RAT2 connection triggering may be different from the triggering that WTRU can use to establish a connection to RAT1. RAT2 connection triggering may be different from the triggering that WTRU can use to establish a connection to RAT2 via DC and / or DAPS.

[0230] One or more connection triggering events can trigger the WTRU to establish a connection via RAT2 (e.g., if / when the WTRU does not need to register via the second branch).

[0231] In the example connection triggering event, after sending an MA PDU session establishment request via the first tributary, the WTRU can (e.g., initiate) establish a connection to RAT2. The WTRU may have (e.g., already) determined a preferred RAN and / or MN combination for the MA PDU session. The WTRU can establish a connection via RAT2 based on sending the MA PDU session establishment request (at the time of sending the MA PDU session establishment request) (e.g., also initiate).

[0232] In an example connection triggering event, for instance, after receiving an MA PDU session establishment response from the first tributary, the WTRU can (e.g., initiate) establish a connection to RAT2. The WTRU can use the information in the response to select a combination of RAT and / or MN.

[0233] In the example connection triggering event, after receiving a NAS message from the network indicating a connection to the second tributary, the WTRU can establish a connection to RAT2. The WTRU may have already received a PDU session establishment response from the network. The WTRU may have selected a combination of RAT and / or MN for the second tributary. The network can send a NAS message to the WTRU. The NAS message can signal and / or instruct the WTRU to establish (e.g., initiate establishment) a connection to RAT2. This instruction can allow MN1 to control whether / when the WTRU establishes multiple (e.g., two) tributaries for an MA PDU session.

[0234] In the example, the WTRU may not request (e.g., require) registration through the second access. AMF1 can be notified that the WTRU may have established a connection to RAT2 for an MA PDU session. A TNL association can be established between the RAN2 node and AMF1.

[0235] AMF1 can be notified that WTRU has established a connection to RAT2 using one or more of the following options described herein.

[0236] In the example option for notifying AMF1, the WTRU can initiate a connection to the RAN2 node by sending an access stratum control plane message. In the example, if RAT2 is a 3GPP access network, the WTRU can initiate an RRC connection by sending an RRCSetupRequest message or an RRCSetupComplete message. The access stratum control plane message can include at least one of the following: a WTRU identifier (e.g., the identifier of the WTRU), a second tributary indication (e.g., an access tributary that can be used as an indication of a second tributary), an AMF identifier (e.g., the identifier of AMF1, indicating that the AMF serves the WTRU through RAT1, such as GUAMI), and / or a NAS message sent by RAN2 to the AMF.

[0237] RAN2 nodes can receive access stratum control plane messages. RAN2 nodes can use a second tributary indicator and / or an AMF identifier to select a TNL association between the RAN2 node and (e.g., an AMF identified by the AMF identifier). RAN2 nodes can use the second tributary indicator and / or the AMF identifier to create a binding between the WTRU and TNL associations. Selecting a TNL association between the RAN2 node and the AMF and / or creating a binding between the WTRU and TNL associations can be referred to as creating an NGAP WTRU-TNLA-binding during RRC connection establishment.

[0238] In the example option for notifying AMF1 (e.g., it could be similar to the first option), the WTRU can initiate a connection to the RAN2 node by sending an access stratum control plane message. The RAN2 node can receive the control plane message. The RAN2 node can be configured to send a NAS message. The NAS message can be included in the received access stratum control plane message (e.g., to AMF1). The RAN node can create an NGAP WTRU-TNLA-binding. The NAS message can be a registration request message, a service request message, or (e.g., a new) NAS message. The NAS message can contain information informing AMF1 that the WTRU has established a connection to RAT2 for the MA PDU session.

[0239] In the example option for notifying AMF1, the WTRU can establish a connection with the RAN2 node. The WTRU can send an access stratum control plane message to the RAN1 node. The access stratum control plane message destined for the RAN1 node can indicate that the WTRU has established a connection to the RAN2 node and / or that the connection can be used as a second tributary. The access stratum control plane message can be a UE Assistance Information message. The access stratum control plane message can include second tributary assistance information. The second tributary assistance information can include at least one of the following: a second tributary indication (e.g., which can indicate that the access tributary is used as a second tributary), and / or a RAN node identifier (e.g., which can help identify the RAN2 node). The RAN node identifier can include at least one of the following: NR Cell Global Identifier (NCGI), NR Cell ID (NCI), gNB ID, Physical Cell ID (PCI), and / or frequency.

[0240] A RAN1 node may send an N2 message to AMF1 (e.g., in response to receiving an indication that a WTRU has established a connection to a RAN2 node). The N2 message may request the creation of an NGAP WTRU-TNLA-binding for the RAN2 node. The request to create an NGAP WTRU-TNLA-binding for the RAN2 node may be an N2 MA PDU request. AMF1 may select a TNL association from the available TNL associations of the RAN2 node. AMF1 may send an N2 MA PDU request to the RAN2 node via the TNL association. The RAN2 node may (e.g., in response to the N2 MA PDU request) create an NGAP WTRU-TNLA-binding for the WTRU based on the TNL association selected by AMF1.

[0241] In the example option for notifying AMF1, the WTRU may not establish a connection with the RAN2 node. The WTRU may (e.g., after selecting a RAT and / or MN for the second tributary) send an access stratum control plane message to the RAN1 node. This message may indicate to the RAN1 node that the WTRU wishes to establish a connection to the selected RAN2 node (e.g., indicating that the connection can be used as a second tributary). The control plane message may be a UE Assistance Information message. The control plane message may include second tributary assistance information.

[0242] RAN1 node can send an N2 message to AMF1 (e.g., in response to receiving an access stratum control plane message from the WTRU). The N2 message can request the establishment of a connection to the RAN2 node and / or create an NGAP WTRU-TNLA-binding for the RAN2 node. The N2 message can be an N2 MA PDU request. AMF1 can select a TNL association from the available TNL associations of the RAN2 node. AMF1 can send an N2 MA PDU request to the RAN2 node via the TNL association. The RAN2 node can determine whether it can accept a connection for the WTRU.

[0243] RAN2 nodes (e.g., if RAN2 nodes can accept connections for WTRUs) can prepare access layer and NAS configurations for WTRUs via RAT2. RAN2 nodes can send NAS configurations to RAN1 nodes using a transparent container. RAN2 nodes can create NGAP WTRU-TNLA-bindings for WTRUs based on the TNL association selected by AMF1. RAN1 nodes can forward the transparent container to WTRUs (e.g., in another control plane message using the RRCReconfiguration message).

[0244] RAN2 node and AMF1 can have one or more TNL associations. These TNL associations can include one or more of the example options described herein, such as informing AMF1 that a connection to RAT2 has been established for the WTRU. RAN2 node can (e.g., in an example where no TNL association exists or an existing TNL association is not used) select AMF (AMF2) in MN2 and / or create an NGAP WTRU-TNLA-binding for the WTRU by selecting a TNL association from the available TNL associations allowed by AMF2. Any N2 messages between RAN2 node and AMF1 can be sent to AMF2 (e.g., via the selected TNL association). N2 messages can be sent from AMF2 to AMF1 via the N14 reference point. The N14 reference point can be implemented by a service-based interface of the AMF (represented by the Namf service-based interface).

[0245] Registration to the second tributary MN can be requested (e.g., required) (e.g., using a single subscription). In the example, if / when the WTRU requests (e.g., requires) registration through the second access and the WTRU has a single subscription to both mobile networks, the registration procedure (e.g., for the second tributary MN) and / or the WTRU behavior (e.g., when registering to the second tributary MN) can be optimized. If / when the obtained MA PDU session type is 3 or 4 and the WTRU needs to register through the second tributary, the WTRU can request (e.g., require) registration through the second access, and / or the WTRU can have a single subscription to both mobile networks.

[0246] Figure 10 The illustration shows an example of registration to the second branch MN. Registration to the second branch MN can begin at a point where the WTRU has already established a connection to the RAN2 node. In this example, registration to the second branch MN can begin at a point where the WTRU has already established a connection to the RAN2 node, which corresponds to... Figure 3 4.

[0247] like Figure 10 As shown, at point 1, the WTRU can initiate a connection to the RAN2 node by sending a control plane message. If RAT2 is a 3GPP access network, the WTRU can initiate an RRC connection (e.g., by sending an RRCSetupRequest message or an RRCSetupComplete message). The WTRU can include a registration request message in the control plane message. The registration request message can include at least one of the following: MA PDU session secondary tributary (e.g., only) indication, other MN identifiers (e.g., MN1 identifier), other AMF identifiers (e.g., AMF1), and / or registration validity timer.

[0248] MA PDU session secondary tributary (e.g., only) indication can indicate registration (e.g., only) for providing secondary tributaries to MA PDU sessions. A network can use the secondary tributary (e.g., only) indication to restrict network resource usage for connections.

[0249] Other MN identifiers can provide the identifier for MN1. The MN identifier can be the PLMN ID of MN1.

[0250] Other AMF identifiers can provide the identifier for AMF1. An AMF identifier can be the GUAMI of AMF1.

[0251] A registration validity timer can be a timer indicating how long registration can be valid and / or requested (e.g., demanded). MN2 can use validity timer information to (e.g., implicitly) unregister the WTRU via MN. The validity timer can be applied if / when there is no ongoing MA PDU session. The WTRU can start the validity timer after the last MA PDU session ends. If the validity timer expires and the WTRU does not start a new MA PDU session, the WTRU can be unregistered.

[0252] At point 2, the RAN2 node can select the AMF. The RAN2 node can use information from the control plane messages and / or registration request messages to determine whether MN2 is the same as MN1. If MN2 is the same as MN1, the RAN2 node can select AMF1. If MN2 is different from MN1, the RAN2 node can select AMF2.

[0253] At point 3, the RAN2 node can create an NGAP WTRU-TNLA-binding for the WTRU. The NGAP WTRU-TNLA-binding for the WTRU can be created by selecting a TNL association from the available TNL associations allowed by the AMF2's initial message. The RAN2 node can forward WTRU messages (e.g., registration requests) to the AMF2. WTRU messages can be forwarded via the selected TNL association.

[0254] At point 4, AMF2 can determine whether to accept or reject the registration request. (See again...) Figure 10In section 4, AMF2 may reject a registration request based on information included in the request and / or based on the current load in the network. If the WTRU uses MN2 as a second tributary, AMF2 may decide that it does not want to allow the WTRU to register (e.g., decides to block WTRU registration). If there is high load in MN2, high load on the access network, and / or high load in the core network, AMF2 may decide to block WTRU registration. AMF2 may decide to reject registration to give priority to its own subscribers. MN2 may have commercial arrangements with multiple partner MNs. One or more of these arrangements may be more advantageous to MN2 (e.g., in terms of pricing). If other MN identifiers identify one of the less advantageous MNs, MN2 may decide to reject the registration request.

[0255] At point 5, AMF2 can accept registration requests. AMF2 can respond to WTRU with a registration acceptance message. The registration acceptance message may include registration configuration information, which includes at least one of periodic registration, mobility registration update, inactivity timer, MN search, and / or registration restrictions.

[0256] The registration acceptance message may include periodic registration. Periodic registration can indicate whether the WTRU wants to perform periodic registration via MN2. If the WTRU wants to perform periodic registration via MN2, the registration acceptance message may include an indication of the periodic value.

[0257] The registration acceptance message may include a mobility registration update. A mobility registration update can instruct the WTRU whether to perform a mobility registration update. If the WTRU changes its registration region, it can use the second branch without performing a registration update.

[0258] The registration acceptance message may include an inactive timer. An inactive timer can indicate a timer that can be used (e.g., implicitly) to unregister the WTRU from MN2 (e.g., based on inactivity). The timer can be started if / when the WTRU enters the CM_IDLE (CM idle) state.

[0259] The registration acceptance message can include an MN search. An MN search can instruct the WTRU whether to perform a search for a better MN for the second branch of the MA PDU session.

[0260] Registration acceptance messages may include registration restrictions (e.g., conditions). The use of an MN can be restricted to a period of time, a schedule, for traffic volume, and / or for a geographic region. A WTRU may (e.g., only) use a second branch within a configured time period, during a configured schedule, for a configured volume of data traffic being delivered, and / or if / when within a configured region. A geographic region can be relative to one or more registration regions or geofences. Different restrictions can be imposed on the WTRU for uplink and downlink.

[0261] At point 6, the WTRU can receive registration acceptance messages. The WTRU can follow modified registration behavior to register via the second branch.

[0262] In the example modified registration behavior, the WTRU can be configured not to perform a mobility registration update. The WTRU may not send a registration update if / when it selects a new tracking area (TA) outside its registration area.

[0263] In the example modified registration behavior, WTRU can be configured not to search for higher-priority MNs used as second branches.

[0264] In the example modified registration behavior, WTRU can be configured to unregister from MN2 (e.g., based on registration restrictions) or suspend registration to MN2. For example, WTRU can use MN2 for a configured amount of time.

[0265] A WTRU can request (e.g., require) registration to a second tributary MN (e.g., using dual subscription). A WTRU can request (e.g., require) registration via a second access. A WTRU can have dual subscriptions to both MNs. A WTRU can determine if the MNs have a business relationship. If the MNs have a business relationship, the WTRU can follow (e.g., simplified) MA PDU session behavior. If / when the obtained MA PDU session type is 5 or 6, and / or the WTRU needs to register to MN2 to use the second tributary in the MA PDU session, the WTRU can follow (e.g., simplified) MA PDU session behavior.

[0266] Figure 11 The diagram illustrates an example architecture for a MUSIM WTRU. The WTRU can be MUSIM-enabled (e.g., where SIM1 is connected to MN1 and SIM2 is connected to MN2). Figure 11An example architecture for a WTRU supporting MUSIM is shown. The WTRU can have a protocol stack for each USIM (e.g., each USIM). Coordination between multiple (e.g., two) protocol stacks can be achieved through MUSIM controller functions. MUSIM controller functions can be able to access the protocol stacks of multiple USIMs. MA PDU functions for splitting, bootstrapping, switching, and / or replicating services across user plane protocol stacks can be hosted in a common PDU layer. Figure 11 The MA PDU function in the PDU layer is shown. The MA PDU function (e.g., may also be located above the IP layer).

[0267] In the example of MA PDU session type 5, MN1 and MN2 may have a business relationship. Multiple (e.g., two) mobile networks (e.g., MN1 and MN2) may (e.g., be able to) communicate with each other to facilitate and / or simplify MA PDU operations (e.g., a simplified dual subscription behavior).

[0268] This article describes a sample procedure that can be started after the WTRU has established a connection to the RAN2 node (e.g., once the WTRU has established a connection to the RAN2 node).

[0269] At point 1, the WTRU MUSIM controller can instruct NAS2 that the WTRU needs to register with MN2. The MUSIM controller can provide NAS2 with MA PDU session support information. The MA PDU session support information may include at least one of the following: a MA PDU session indication (e.g., which may indicate that registration is for an MA PDU session), an MN identifier (e.g., which may identify MN2 (e.g., the PLMN ID of MN2)), or another MN identifier (e.g., which may identify MN1, such as the PLMN ID of MN1).

[0270] At point 2, the WTRU can initiate a connection to the RAN2 node (e.g., by sending a control plane message). The WTRU can initiate an RRC connection by sending an RRCSetupRequest message or an RRCSetupComplete message (e.g., if RAT2 is a 3GPP access network). The WTRU can include a registration request message in the control plane message. The registration request message can include at least one of the following: MA PDU session indication, other MN identifiers, other AMF identifiers, or a registration validity timer.

[0271] MA PDU session indications can provide indications that registration is for an MA PDU session.

[0272] Other MN identifiers can be identifiers of MN1, such as the PLMN ID of MN1.

[0273] Other AMF identifiers can be identifiers of AMF1, such as AMF1's GUAMI.

[0274] A registration validity timer can be a timer that indicates how long a registration can be valid and / or requested (e.g., required). MN2 can use timer information to (e.g., implicitly) deregister a WTRU on the mobile network.

[0275] At point 3, the RAN2 node can create an NGAP WTRU-TNLA-binding (e.g., a UE-TNLA-binding) for the WTRU. The NGAP WTRU-TNLA-binding for the WTRU can be created by selecting a TNL association from the available TNL associations allowed by the AMF2's registration message. The RAN2 node can then forward WTRU messages to the AMF2 via the selected TNL association.

[0276] At point 4, AMF2 can determine whether MN2 has a business relationship with MN1. AMF2 can determine whether to accept or reject the registration request. AMF2 can reject the registration request based on information included in the request and / or based on the current load in the network. In the example, if the WTRU uses MN2 as a second tributary, AMF2 can decide that it does not want to allow the WTRU to register. In the example, MN2 may have a business arrangement with one or more (e.g., multiple) partner MNs. One or more of these arrangements may be more advantageous to MN2 (e.g., in terms of pricing). If other MN identifiers identify one of the less advantageous MNs, MN2 can decide to reject the registration request. If AMF2 determines that MN2 does not have a business relationship with MN1, AMF2 can determine that MN2 is incompatible and / or AMF2 can reject the registration. In the example, the WTRU may attempt to connect to the same PLMN via multiple (e.g., two) SIMs. If AMF2 determines that MN2 does not have a business relationship with MN1, AMF2 can determine that the MN cannot establish an MA PDU session (e.g., an MA PDU session of session type 6).

[0277] At point 5, AMF2 can accept registration requests. AMF2 can respond to WTRU with a registration acceptance message. The registration acceptance message can include at least one of the following: periodic registration, mobility registration update, inactivity timer, MN search, registration restriction, or simplified dual subscription behavior indication.

[0278] Periodic registration can indicate whether the WTRU should perform periodic registration on MN2. Registration acceptance messages (e.g., may also) include indications of periodic values ​​(e.g., if the WTRU should perform periodic registration on MN2).

[0279] Mobility registration update can instruct the WTRU whether to perform a mobility registration update. The WTRU can use a second branch without performing a registration update (e.g., if the WTRU changes its registration region).

[0280] An inactive timer can be used (e.g., implicitly) to unregister the WTRU from MN2 (e.g., based on inactivity). The timer can be started if / when the WTRU enters the CM_IDLE state.

[0281] The MN search can instruct the WTRU whether to perform a search for (e.g., better) the MN for the second branch of the MA PDU session.

[0282] Registration restrictions (e.g., conditions) can indicate whether the use of the MN can be subject to one or more restrictions, such as a specific time period, a specific schedule, for a specific volume of traffic, for a specific geographic area, and / or so on. The WTRU can (e.g., only) use the second branch within a configured amount of time, during a configured schedule, for a configured volume of data traffic being delivered, and / or so on (e.g., if / when the WTRU is in a configured area). The geographic area can be relative to the registration area or a geofence. Different restrictions can be imposed on the WTRU for uplink and downlink.

[0283] Simplified dual-subscription behavior can indicate whether MN2 has a business relationship with MN1. Business relationships can allow WTRU to follow simplified MA PDU session behavior (e.g., as described herein).

[0284] At point 6, the WTRU can receive registration acceptance messages. For registration via the second branch, the WTRU can follow the modified registration behavior.

[0285] WTRU may not know whether MN2 and MN1 have a business relationship (e.g., whether WTRU is registered to MN2). This can trigger WTRU to initiate a registration update procedure. The registration update procedure can determine whether WTRU can apply simplified dual-subscription behavior.

[0286] MA PDU sessions can be established on the second branch. For example, if the WTRU requests (e.g., requires) registration through the second access, and / or if the WTRU has dual subscriptions to multiple mobile networks, the SMF2 can obtain the MAPS rules.

[0287] If the WTRU has already established a connection on the second tributary and / or if the WTRU has performed registration via MN2, the WTRU can establish an MA PDU session on the second tributary. Establishing an MA PDU session on the second tributary may involve providing updated MAPS rules to the WTRU, providing updated MAPS rules to the UPF, and / or configuring the RAN2 node to handle the MA PDU session on the second tributary.

[0288] A dual subscription and / or business relationship can be used to establish an MA PDU session on the second branch. The examples described herein may apply if / when the obtained MA PDU session is type 5. MN1 and MN2 may have a business relationship and / or multiple (e.g., two) mobile networks may (e.g., are assumed to be) able to communicate with each other to facilitate MA PDU operation (e.g., for MA PDU session type 5).

[0289] At point 1, the MUSIM controller can request NAS2 to establish an MA PDU session on the second branch. The MUSIM controller can provide at least one of the following: PDU session ID, other MN WTRU identifier, or location ID.

[0290] The PDU session ID can be used to set the PDU session ID of the MA PDU session established on the first branch.

[0291] Other MN WTRU identifiers can be the identifiers of the WTRUs on the first branch. In the example, the identifier could be the SUCI or 5G-GUTI of the WTRU on MN1. If the WTRUs have different identifiers on multiple (e.g., two) MNs, the identifiers can be requested (e.g., required).

[0292] A location ID can help MN2 select a suitable UPF2 (e.g., make UPF2 close to UPF1). The location ID can reside in the ID space known to MN1 and MN2 (e.g., as part of a business agreement), or it can be public information. In the example, the location ID can be a private location identifier agreed upon between MN1 and MN2 (e.g., a string or fully qualified domain name (FQDN), country code, IPX code, geographic location, and / or etc.). A location ID can be a combination of location IDs.

[0293] If a PDU session ID (e.g., already in use) is in PLMN2, the MUSIM controller can determine a new PDU session ID. The MUSIM controller can provide this information to NAS1 and / or NAS2. NAS1 can use this information to tear down an MA PDU session and re-establish it with the new PDU session ID, or to modify the PDU session ID of an already established MA PDU session. NAS2 can include this information in the PDU session establishment request.

[0294] At point 2, NAS2 can send a PDU session establishment request to SMF2. The WTRU may include MAPS auxiliary information. This information can be expanded to include other MN WTRU identifiers. These other MN WTRU identifiers can be provided by NAS2.

[0295] At point 3, SMF2 can identify SMF1 from other MN WTRU identifiers. SMF2 can retrieve MAPS configuration information from SMF1 (e.g., via the N16 interface).

[0296] At point 4, SMF2 can provide the received MAPS configuration information to the WTRU. SMF2 can configure a UPF in MN2 (e.g., called UPF2) to provide connectivity to UPF1. UPF1 can be a PSA UPF for MA PDU sessions in MN1.

[0297] In the example, SMF2 may (e.g., needs to) modify the MAPS configuration received from SMF1. MN2 may not support boot modes or boot functions included in the MAPS configuration. SMF2 may modify the MAPS configuration before providing it to the WTRU. SMF2 may provide a new MAPS configuration to SMF1. SMF1 may (e.g., needs to) reconfigure the MAPS configuration in the PSA UPF in response.

[0298] A dual subscription can be used to establish an MA PDU session on the second tributary even without a business relationship. The examples described herein may apply if / when the obtained MA PDU session is type 6. If MN1 and MN2 have no business relationship and / or multiple (e.g., two) mobile networks do not communicate directly, the WTRU may provide information to SMF2 (e.g., allow SMF2 to configure UPF2 (e.g., the UPF in MN2 for the second tributary)).

[0299] In the WTRU-based alternative, MN1 can provide information to the WTRU, and / or the WTRU can forward that information to SMF2.

[0300] At point 1, SMF1 can provide a NAS container to the WTRU (e.g., when establishing an MA PDU session via MN1). The NAS container can include information about the MA PDU session configured on MN1. Information about the MA PDU session configured on MN1 can include at least one of the PSA UPF address in MN1 or the WTRU's MAPS rules. The PSA UPF address in MN1 can include the UPF's IP address or tunnel information.

[0301] NAS containers can be provided in (for example, new) NAS messages, PDU session establishment accept messages, or DL ​​NAS TRANSPORT messages. PDU accept messages can be received if / when an MA PDU session is established via MN1.

[0302] At point 2, the NAS container can be received by NAS1 (e.g., the NAS layer for SIM1). NAS1 can provide the NAS container to the MUSIM controller.

[0303] At point 3, the MUSIM controller can include the NAS container received from NAS1 in the request to establish an MA PDU session via MN2.

[0304] At point 4, NAS2 can send a PDU session establishment request to SMF2. This request may include NAS containers received from NAS1.

[0305] At point 5, SMF2 can (for example, upon receiving a NAS container) determine whether to accept the MA PDU establishment request. If SMF2 determines to accept the MA PDU establishment request, SMF2 can configure a UPF (called UPF2) in MN2 to provide connectivity to UPF1.

[0306] In the example based on application function (AF), an MN can use an AF to act as an intermediary between multiple (e.g., two) MNs. For example, MN1 can provide (e.g., necessary) information to the AF. The AF can then forward the information to SMF2.

[0307] At point 1, SMF1 can (e.g., when establishing an MA PDU session via MN1) provide the address of the mediator application function to the WTRU. In the example, SMF1 can provide the address of the mediator application function to NAS1 (e.g., the NAS layer of SIM1).

[0308] At point 2, SMF1 can provide the intermediary AF with MA PDU session information (e.g., via network exposure). The provided MA PDU session information may include at least one of the following: WTRU identity, PSA UPF address in MN1, and / or WTRU's MAPS rules.

[0309] A WTRU identity can be a WTRU identity. A WTRU identity can be a (e.g., a new) identifier shared across MNs.

[0310] The address of the PSA UPF in MN1 can include the IP address of the UPF or tunnel information.

[0311] At point 3, NAS1 layer can provide the AF address to the MUSIM controller.

[0312] At point 4, the MUSIM controller may include the address of the intermediary AF (e.g., in a request to establish an MA PDU session via MN2).

[0313] At point 5, NAS2 can send a PDU session establishment request to SMF2. This request may include the address of the intermediary AF received from NAS1.

[0314] At point 6, SMF2 can (e.g., upon receiving the address of the mediator AF) communicate with the mediator AF to retrieve the address of the PSAUPF and / or the MAPS rules for the WTRU. SMF2 can (e.g., upon receiving the address of the AF) communicate with the AMF to retrieve MA PDU session information. SMF2 can (e.g., upon receiving MA PDU session information) determine whether to accept the MA PDU establishment request. If SMF2 determines to accept the MA PDU establishment request, SMF2 can configure a UPF (referred to as UPF2) in MN2 to provide connectivity to UPF1.

[0315] A MA PDU session can be established using a linked single-access PDU session. A linked single-access PDU session is applicable if / when the obtained MA PDU session is type 7. MN1 and MN2 can be different mobile networks or the same mobile network. This document describes an example where MN1 and MN2 are different mobile networks.

[0316] At point 1, when establishing an MA PDU session via MN1, SMF1 can provide extended MAPS configuration information. The extended MAPS configuration information can include MAPS configuration information as defined herein. The extended MAPS configuration information can include the address of the PSA UPF in MN1. This address can correspond to a second tributary (e.g., referred to herein as the PSA UPF second tributary address). The address of the PSA UPF in MN1 can include the IP address or tunnel information of the UPF, or it can include an IP address:port number. This IP address can allow the WTRU to establish an end-to-end connection to the PSA UPF (e.g., via an IP connection). The extended MAPS configuration information can include a Data Network Name (DNN). The DNN can be set to a data network that can access the PSA UPF. Sending the DNN may be useful if MN is part of a private data network providing connectivity between UPFs. The extended MAPS configuration information can include the MA PDU session type. The MA PDU session type can be type 7 (e.g., indicating to the WTRU that the MA PDU session depends on an SA PDU session on a link on access tributary 2).

[0317] Extended MAPS configuration information can be included in the NAS container from SMF1. The NAS container can be provided in (e.g., in a new) NAS message, in a PDU session establishment accept message (e.g., if / when a MA PDU session is established via MN1), or in a DL NAS TRANSPORT message. NAS container information can also be included in the ATSSS rules from SMF1.

[0318] At point 2, the WTRU can determine the SA PDU session to establish the link. The request to establish the SA PDU can be triggered from the PDU layer. The PDU layer can host MA PDU functionality. The WTRU can initiate an SA PDU session from an MA PDU session. The WTRU can be configured with URSP rules that trigger the establishment of the linked SAPDU session (referred to as the second branch in this document) if / when a request is made from the PDU layer of the MA PDU session.

[0319] At point 3, the WTRU can send an SA PDU session establishment request. The SA PDU session establishment request may include an indication of the DNN that is set as included in the extended MAPS configuration information, and / or the PDU session that the PDU session is to act as a link.

[0320] At point 4 (e.g., upon receiving an SA PDU session establishment request), SMF2 can determine whether to accept the SA PDU session establishment request (e.g., based on WTRU subscription information, which may indicate support for SA PDU sessions). SMF2 can select a UPF in MN2 (referred to as UPF2), which may be located close to the PSA UPF (e.g., physically, topologically, or in terms of latency). SMF2 can use the second tributary address of the PSA UPF or other locators in the extended MAPS configuration information to select the appropriate UPF2.

[0321] At point 5, SMF2 can send QoS rules to WTRU, QoS profiles to the second tributary RAN node, and / or packet detection rules (PDR) to UPF2. SMF2 can send a selected address to WTRU (e.g., the IP address of the WTRU using the SA PDU session).

[0322] At point 6, the WTRU can notify SMF1 of its address via a linked SA PDU session (e.g., as received at point 5).

[0323] At point 7, SMF1 informs the PSA UPF of the WTRU's address via the linked SA PDU session. The PSA UPF can use this information to decide whether to accept an incoming PDU. In the example, SMF1 can update the PDR at the PSA UPF so that traffic from the WTRU via the linked SA PDU session is correctly identified. The PSA UPF can use this information to route traffic received by the WTRU from the WTRU identified by its address via the linked SAPDU session to the PDU layer that handles the WTRU's MA PDU function.

[0324] The WTRU can use MAPS rules to route uplink traffic via MA PDU sessions on access tributary 1 or SA PDU sessions linked on access tributary 2. If / when the WTRU sends a PDU on the second tributary of an MA PDU session, the PDU layer on the WTRU can encapsulate the PDU in an external MPTCP or MPQUIC PDU, the destination IP address of which is set to the PSA UPF second tributary IP address, and / or the PDU layer on the WTRU can send the external PDU on access tributary 2. At the PSA UPF, uplink traffic from multiple (e.g., two) PDU sessions can be combined. The UPF can use MAPS rules to route downlink traffic via MA PDU sessions on access tributary 1 or SA PDU sessions linked on access tributary 2. At the WTRU, downlink traffic from two PDU sessions can be combined.

[0325] MA PDU sessions can be ongoing operations. MA PDU session types 2-4 can be optimized. WTRUs can use (e.g., only) MN2 as a second branch (e.g., for MA PDU sessions configured as MA PDU session types 3 or 4). WTRUs can (e.g., for these types) be configured (e.g., only) to be paged via the first branch (e.g., via MN1). If a WTRU is configured to be paged via the first branch, MN2 may not know the location of the WTRU.

[0326] The WTRU can (e.g., is required) perform RRC connections (e.g., for MO services used in MA PDU sessions) on multiple (e.g., two) access tributaries. RRC connections on access tributaries allow the MN to know the location of the WTRU. Tributaries (e.g., N3 and N9 tributaries) can be updated to reflect the new location of the WTRU.

[0327] A WTRU can be paged from MN1 on the primary tributary (e.g., for MT service only). This paging request can trigger the WTRU to initiate an RRC connection on (e.g., both) access tributaries. The WTRU can send a paging response message on the first tributary. The WTRU can send (e.g., a new) NAS message on the second tributary. The new NAS message can indicate that the second tributary can be used for dual boot and / or ATSSS transport.

[0328] In the example, an MA PDU session can be configured as MA PDU session type 2 or 3. WTRU can have a single registration.

[0329] The AMF can determine which access tributary to use for transmitting NAS messages. The AMF can determine which access tributary to use for transmitting NAS messages using at least one of the following options: the AMF can send NAS signaling on a first tributary, the AMF can send NAS signaling on a second tributary, the AMF can replicate NAS signaling on both access tributaries, and the AMF can make the determination based on metrics (e.g., the AMF can use a tributary with minimum latency, maximum throughput, highest capacity, and / or so on), the RAT type used on the access tributary, and / or the type of NAS message.

[0330] When the AMF determines which access tributary to use for transmitting NAS messages based on the RAT type used on the access tributary, the NAS messages can use the access tributary of the RAT type. In the example, one or more NAS messages can use the RAT type. One or more NAS messages can use the terrestrial RAT type, while other NAS messages can use the satellite RAT type.

[0331] When the AMF determines which access tributary to use to transmit NAS messages based on the type of NAS message, it may send one or more (e.g., some) NAS messages on the first tributary, one or more (e.g., some) NAS messages on the second tributary, and / or may copy one or more (e.g., some) NAS messages on multiple (e.g., two) access tributaries.

[0332] Although the above features and elements are described in specific combinations, each feature or element may be used alone without other features and elements of the preferred embodiment, or in various combinations with or without other features and elements.

[0333] While the implementation described herein may take into account 3GPP-specific protocols, it is understood that the implementation described herein is not limited to this scenario and can be applied to other wireless systems. For example, although the solution described herein takes into account LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it is understood that the solution described herein is not limited to this scenario and can also be applied to other wireless systems.

[0334] The processes described above can be implemented in computer programs, software, and / or firmware incorporated in computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, internal hard disks and removable disks), magneto-optical media, and / or optical media (such as CD-ROM discs and / or digital versatile discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver used in WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), the wireless transmit / receive unit (WTRU) comprising: The processor is configured as follows: A Multi-Access Protocol Data Unit (MA PDU) session establishment request is sent to a first network node on the first branch, wherein the first network node is associated with a first network; In response to the MA PDU session establishment request, an MA PDU session establishment response message is received from the first network node, wherein the MA PDU session establishment response message indicates MA PDU session configuration information; Determine the second network to be used for the second branch; Based on the MA PDU session configuration information, it is determined whether the WTRU should register with the second network; and When it is determined that the WTRU should register with the second network, a registration message is sent to the second network node, wherein the second network node is associated with the second network.

2. The WTRU according to claim 1, wherein, The processor is further configured to: The second branch is used to send a second MA PDU session establishment request to the second network node in order to establish an MA PDU session on the second branch.

3. The WTRU according to claim 1, wherein, The processor is further configured to: Receive MA PDU policy (MAPP), wherein the MAPP indicates one or more MA PDU session types; and Select an MA PDU session type from one or more of the MA PDU session types, wherein the MA PDU session type is associated with access options, mobile network options, and subscription options.

4. The WTRU according to claim 3, wherein, The processor is configured to select the MA PDU session type based at least on MA PDU session selection factors.

5. The WTRU according to claim 4, wherein, The MA PDU session selection factors include at least one of the following: existing MA PDU sessions, existing connections via Radio Access Technology (RAT), WTRU capabilities, the status of the WTRU, the Quality of Service (QoS) characteristics of the application service, or an indication of the MA PDU session type determined by the first network.

6. The WTRU according to claim 1, wherein, The MA PDU session establishment request indicates MA PDU session assistance information, wherein the MA PDU session assistance information includes at least one of WTRU capabilities, WTRU preferences, or network decisions.

7. The WTRU according to claim 1, wherein, The registration message further indicates the identifier of the first network, or indicates the purpose of the registration message for an MA PDU session associated with the first network.

8. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: A Multi-Access Protocol Data Unit (MA PDU) session establishment request is sent to a first network node on the first branch, wherein the first network node is associated with a first network; In response to the MA PDU session establishment request, an MA PDU session establishment response message is received from the first network node, wherein the MA PDU session establishment response message indicates MA PDU session configuration information; Determine the second network to be used for the second branch; Based on the MA PDU session configuration information, it is determined whether the WTRU should register with the second network; and When it is determined that the WTRU should register with the second network, a registration message is sent to the second network node, wherein the second network node is associated with the second network.

9. The method according to claim 8, wherein, The method further includes: The second branch is used to send a second MA PDU session establishment request to the second network node in order to establish an MA PDU session on the second branch.

10. The method according to claim 8, wherein, The method further includes: Receive MP PDU policy (MAPP), wherein the MAPP indicates one or more MA PDU session types; and Select an MA PDU session type from one or more of the MA PDU session types, wherein the MA PDU session type is associated with access options, mobile network options, and subscription options.

11. The method according to claim 10, wherein, The method further includes: The selection of the MA PDU session type is based at least on MA PDU session selection factors.

12. The method according to claim 11, wherein, The MA PDU session selection factors include at least one of the following: existing MA PDU sessions, existing connections via Radio Access Technology (RAT), WTRU capabilities, the status of the WTRU, the Quality of Service (QoS) characteristics of the application service, or an indication of the MA PDU session type determined by the first network.

13. The method according to claim 8, wherein, The MA PDU session establishment request indicates MA PDU session assistance information, wherein the MA PDU session assistance information includes at least one of WTRU capabilities, WTRU preferences, or network decisions.

14. The method according to claim 8, wherein, The registration message further indicates the identifier of the first network, or indicates the purpose of the registration message for an MA PDU session associated with the first network.

Images