Establishing a ma pdu session over an access

Abstract

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

Description

ESTABLISHING A MA PDU SESSION OVER AN ACCESSCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 532,025, filed August 10, 2023, the contents of which are hereby incorporated by reference herein.BACKGROUND

[0002] Mobile communications using wireless communication continue to evolve. A fifth generation may be referred to as 5G. A previous (legacy) generation of mobile communication may be, for example, fourth generation (4G) long term evolution (LTE).SUMMARY

[0003] Systems, methods, and instrumentalities are described herein related to establishing a multiaccess (MA) protocol data unit (PDU) session over an access leg. In examples, a wireless transmit / receive unit (WTRU) may include a processor that may be configured to perform a method for MA PDU session establishment. A MA PDU session establishment request may be sent over a first leg to a first network node. The first network node may be associated with a first network. An MA PDU session establishment response message may be received from the first network node in response to the MA PDU session establishment request. 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 leg. A WTRU may register with the second network based on the MA PDU session configuration information. A registration message may be sent to a second network node when, for example, it is determined that the WTRU should register with the second network. The second network node may be associated with the second network.

[0004] In examples, a second MA PDU session establishment request may be sent to the second network node using the second leg to establish the MA PDU session over the second leg. A WTRU may receive a MA PDU policy (MAPP). The MAPP may indicate one or more MA PDU session types. A MA PDU session type may be selected from the one or more MA PDU session types. The MA PDU session type may be associated with an access option, a mobile network option, and / or a subscription option. The MA PDU session type may be selected based on at least an MA PDU session selection factor. The MA PDU session selection factor may include at least one of an existing MA PDU session, an existingconnectivity over a Radio Access Technology (RAT), a WTRU, capability, a state of the WTRU, a Quality of Service (QoS) characteristic of application traffic, or an indication of the MA PDU session type determined by the network. The MA PDU session establishment request may indicate MA PDU session assistance information. The MA PDU session assistance information may include at least one of a WTRU capability, a WTRU preference, or a network decision. The registration message may further indicate an identification of the first network or an indication that the registration message is for an MA PDU session associated with the first network.

[0005] Systems, methods, and instrumentalities are described herein for providing DualSteer multiaccess (MA) protocol data unit (PDU) session establishment. In an example, a WTRU may perform one or more of the following actions. An MA PDU session may be enabled over multiple (e.g., two) 3GPP access legs. An MA PDU session type may be selected. An MA PDU session of the selected MA PDU session type may be established over a first leg. Connectivity may be established over the second leg, for example, based on the MA PDU session type. An MA PDU session of the selected MA PDU session type may be established over the second leg. Enhanced control plane signaling may be enhanced, for example, if / when an MA PDU session of one or more (e.g., certain) MA PDU session types is ongoing.

[0006] Systems, methods, and instrumentalities are described herein for establishing a MA PDU session over a first leg. In an example, a WTRU may perform one or more of the following operations to establish an MA PDU session over a first leg. The WTRU and network may 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). A WTRU, operating to establish an MA PDU session over multiple (e.g., two) 3GPP legs, may receive an MA PDU policy (MAPP), which may include information to allow the WTRU to determine which of the MA PDU session types to choose. The WTRU may make an MA PDU session type decision based on, for example, MA PDU session selection factors. The WTRU may send a PDU session establishment request message over the first leg to mobile network 1 . The message may include MA PDU session (MAPS) assistance information. The WTRU may receive a PDU session establishment response message, which may include MAPS configuration information. The WTRU may determine the RAT and / or mobile network combination to use for the second leg. The WTRU may determine whether to register with the determined mobile network for the second leg, for example, based on information received in the PDU session establishment response message.

[0007] A MAPP may indicate the mapping of an application flow to a (e.g., a specific) MA PDU session type. MA PDU session selection factors may include at least one of an ongoing connectivity, a user or WTRU preference, QoS characteristics, and / or the like. MAPS assistance information may include at leastone of a network decision, an ongoing connectivity, a WTRU capability, and / or the like. MAPS configuration information may include at least one of an accepted MA PDU session type, a timer value, an indication of whether a preferred MN that may request registration, and / or the like.

[0008] In an example, an SMF may perform one or more of the following operations to establish an MA PDU session over a first leg. A WTRU and network may 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). An SMF in a mobile network may receive a PDU session establishment request message from a WTRU (e.g., to establish the first leg of an MA PDU session), where the message may include MAPS assistance information. The SMF may determine the MA PDU session type to use for the MA PDU session, for example, based on the MA PDU session type requested by the WTRU, based on the MAPS assistance information provided by / received from the WTRU, and / or based on subscription information for the WTRU. The SMF may send a PDU session establishment response message, which may include the MAPS configuration information.

[0009] In an example, a device (e.g., a WTRU) may support a plurality of MA PDU session types. The device may receive an MA PDU policy (MAPP). The device may select an MA PDU session type from the plurality of supported MA PDU session types based, at least in part, on the MAPP. The device may send an MA PDU session establishment request over a first leg to a first mobile network. 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 use for a second leg. 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 the MA PDU session over the second leg based on the determination of whether to register with the second mobile network. The MA PDU session establishment request may include MA PDU session assistance information. The MAPP may indicate the WTRU may select the 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] Systems, methods, and instrumentalities described herein may be related to establishing connectivity over a second leg. In an example, a device (e.g., a network node, a WTRU, and the like) may be configured to do one or more of the following actions. A first radio access network (e.g., RAN1) node may perform one or more of the following operations to establish connectivity over a second leg (e.g., a secondary leg). A WTRU may have registered with a first mobile network (e.g., mobile network 1). The WTRU may have established an MA PDU session over a first leg (e.g., a primary leg). The MA PDUsession may not request (e.g., require) the WTRU to register over the second leg to a second mobile network (e.g., mobile network 2). The first RAN node may receive a first control plane message, which may include, for example, an indication that the WTRU wishes to establish a connection to a second (e.g., selected) RAN node in a mobile network (e.g., a RAN2 node). The control plane message may indicate that the WTRU is requesting second leg assistance information. The first RAN node may send an N2 message to the access and mobility management function (AMF) of the first mobile network (e.g., AMF1) requesting the establishment of a connection to the second RAN node (e.g., the 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. The first RAN node may receive a transparent container from the second RAN node, which may include the access stratum and non-access stratum (NAS) configuration for the WTRU over 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).

[0011] Second leg assistance information may indicate, for example, one or more of the following: that the access leg may be used as a second leg, an identifier of the second RAN node (e.g., RAN2 node), and / or an identifier of the AMF1.

[0012] In an example, a WTRU may perform one or more of the following operations to establish connectivity over the second leg. The WTRU may have registered with the first mobile network (e.g., mobile network 1). The WTRU may have (e.g., already) established an MA PDU session over the first leg. The MA PDU session may not request (e.g., require) the WTRU to register over the second leg to the second mobile network (e.g., mobile network 2). A WTRU may determine to establish connectivity to the second leg, for example, based on one or more connectivity trigger events. The WTRU may send a first control plane message to a first RAN node, which may be associated with the first leg (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., selected RAN node or RAN2 node) and / or second leg assistance information. The WTRU may receive a second control plane message (e.g., RRCReconfiguration message) from the RAN1 node, which 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), for example, based on the access stratum and NAS configuration included in the transparent container.

[0013] Connectivity trigger events may include, for example, one or more of the following: a start of the MA PDU session over the first leg, reception of a PDU session establishment response over the first leg, and / or a NAS message over the first leg.

[0014] In an example, a device (e.g., a RAN node in a first network (RAN1)) may receive a first message comprising information indicating that a WTRU seeks to establish a connection to a selected RAN node in a second mobile network and second leg assistance information. The device may send a second message to an AMF in the first mobile network requesting the establishment of the connection to the selected RAN node in the second mobile network. The second leg assistance information may comprise a second leg indication indicating that the connection is a second leg and an AMF identifier identifying the AMF in the first mobile network. The device may use the second leg indication and the AMF identifier to select a transport network layer (TNL) association between the RAN node in the second mobile network and the AMF. The device may create a binding between the WTRU and the TNL association.

[0015] Systems, methods, and instrumentalities described herein may be related to providing MA PDU session rules to an SMF of a second mobile network (mobile network 2). In an example, a WTRU may 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 MA PDU session may request (e.g., require) the WTRU to register over the second leg to mobile network 2. The WTRU may have a separate subscription for registering to mobile network 2. Mobile network 1 and mobile network 2 may not have a business relationship (e.g., a lack of (standardized) inter-mobile network communication). A 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), e.g., in the PDU session establishment response message. The NAS container may include information related to the MA PDU session configured over mobile network 1 . The NAS container may be provided to the MUSIM controller. The MUSIM controller may provide the NAS container to the NAS layer of the second subscriber identification module (SIM2) (NAS2). The WTRU may determine the RAT and / or mobile network for the second leg. The WTRU (e.g., MUSIM controller) may indicate to the NAS layer of SIM2 that the WTRU needs to establish an MA PDU session over the second leg for mobile network 2. The MUSIM controller may provide, for example, MA PDU session support information and / or the NAS container received from SMF1. The WTRU may send a PDU session establishment request message over the second leg for mobile network 2. The message may include the received NAS container. The WTRU may receive a PDU session establishment accept message over the second leg for mobile network 2. The WTRU may transmit and / or receive traffic over the MA PDU session.

[0016] In an example, a device (e.g., a WTRU) may send, by a first universal subscriber identity module (USIM), a first MA PDU session establishment request over a first leg to a first mobile network. The device may receive a first MA PDU session establishment response message in response to the first MA PDUsession establishment request, wherein the first MA PDU session establishment response message comprises MA PDU session information for the first network. The device may provide the MA PDU session information for the first network to a MUSIM controller. The device may determine a second mobile network and RAT to use for a second leg. The device may provide, by the MUSIM controller to a second USIM, an indication that the WTRU seeks to establish the MA PDU session over the second leg for the second mobile network. The device may send, by the second USIM, a second MA PDU session establishment request over the second leg to the second mobile network. The MA PDU session information for the first network may be received in a NAS container from an SMF in the first mobile network. The indication may comprise the MA PDU session information for the first network and MA PDU session support information. The second MA PDU establishment request may comprise the MA PDU session information for the first network.BRIEF DESCRIPTION OF THE DRAWINGS

[0017] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented;

[0018] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0019] FIG. 1 C is a system diagram illustrating an example radio access network (RAN) and an example core network (ON) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0020] FIG. 1 D is a system diagram illustrating a further example RAN and a further example ON that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0021] FIG. 2 illustrates an example of Service Data Flows Over Dual Connectivity.

[0022] FIG. 3 illustrates an example procedure to configure and use MA PDU session.

[0023] FIG. 4 illustrates an example of an MA PDU session type 1 .

[0024] FIG. 5 illustrates an example of MA PDU session type 2.

[0025] FIG. 6 illustrates an example of MA PDU session type 3 and type 4.

[0026] FIG. 7 illustrates an example of MA PDU session type 5.

[0027] FIG. 8 illustrates an example of MA PDU session type 6.

[0028] FIG. 9 illustrates an example of MA PDU session type 7.

[0029] FIG. 10 illustrates an example of registration to a second leg MN.

[0030] FIG. 11 illustrates an example architecture of a MUSIM WTRU.EXAMPLE NETWORKS FOR IMPLEMENTATION OF THE EMBODIMENTS

[0031] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 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 OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0032] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a ON 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or a “STA”, may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0033] The communications systems 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will beappreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

[0035] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0036] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 1 13 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 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).

[0037] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0038] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using New Radio (NR).

[0039] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

[0040] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0041] The base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

[0042] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, whichmay be utilizing a NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0043] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 may include circuit- switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

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

[0045] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0046] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0047] The transmit / receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

[0049] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.

[0050] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The 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. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0051] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include oneor 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, and the like.

[0052] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable locationdetermination method while remaining consistent with an embodiment.

[0053] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0054] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the 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 either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

[0055] FIG. 1 C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0056] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0057] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0058] The CN 106 shown in FIG. 1 C 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 are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0059] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0060] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter- eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0061] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0062] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Inaddition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0063] Although the WTRU is described in FIGS. 1 A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0064] In representative embodiments, the other network 112 may be a WLAN.

[0065] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and / or referred to as peer-to- peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11 z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad- hoc” mode of communication.

[0066] When using the 802.11 ac infrastructure mode of operation or a similar mode of actions, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0067] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0068] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz, and / or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0069] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11 ah relative to those used in 802.11 n, and 802.11 ac. 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non- TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control / Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0070] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, 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 sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0071] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. InJapan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

[0072] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0073] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0074] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and / or lasting varying lengths of absolute time).

[0075] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to another RAN such aseNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0076] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E- UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards access and mobility management function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0077] The CN 115 shown in FIG. 1 D 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. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0078] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0079] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providingdownlink data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernetbased, and the like.

[0080] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may 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, providing mobility anchoring, and the like.

[0081] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0082] In view of Figures 1A-1 D, and the corresponding description of Figures 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: 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, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0083] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or in an operator network environment. For example, the one or more emulation devices may perform the 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 in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and / or may performing testing using over-the-air wireless communications.

[0084] The one or more emulation devices may perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example,the emulation devices may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be testing equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0085] Reference to a timer herein may refer to a time, a time period, a tracking of time, a tracking of a period of time, a combination thereof, and / or the like. Reference to a timer expiration herein may refer to determining that the time may have occurred or that the period of time may have expired.

[0086] Systems, methods, and instrumentalities are described herein related to establishing a multiaccess (MA) protocol data unit (PDU) session over an access leg. In examples, a wireless transmit / receive unit (WTRU) may include a processor that may be configured to perform a method for multi-access protocol data unit (MA PDU) session establishment. A multi-access protocol data unit (MA PDU) session establishment request may be sent over a first leg to a first network node. The first network node may be associated with a first network. An MA PDU session establishment response message may be received from the first network node in response to the MA PDU session establishment request. 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 leg. A WTRU may register with the second network based on the MAPP. A registration message may be sent to a second network node when, for example, it is determined that the WTRU should register with the second network. The second network node may be associated with the second network.

[0087] In examples, a second MA PDU session establishment request may be sent to the second network node using the second leg to establish the MA PDU session over the second leg. The MAPP may indicate one or more MA PDU session types. An access option associated with the second network may be selected based on an MA PDU session type from the one or more MA PDU session types. The access option may be selected based on the MA PDU session type and / or at least an MA PDU session selection factor. The MA PDU session selection factor may include at least one of an existing MA PDU session, an existing connectivity over a Radio Access Technology (RAT), a WTRU capability, a state of the WTRU, a Quality of Service (QoS) characteristic of application traffic, or an indication of the MA PDU session type determined by the network. The MA PDU session establishment request may indicate MA PDU session assistance information. The MA PDU session assistance information may be associated with the first network. The MA PDU session assistance information may include an identification of the first network or a MA PDU session type associated with the first network.

[0088] One or more devices (e.g., a wireless transmit / receive unit (WTRU)) may be configured to execute at least one of the following actions. An MA PDU session may be enabled over multiple (e.g., two) 3GPP access legs. An MA PDU session type may be selected. An MA PDU session of the selected MA PDU session type may be established over a first leg. Connectivity may be established over the second leg, for example, based on the MA PDU session type. An MA PDU session of the selected MA PDU session type may be established over the second leg. Enhanced control plane signaling may be enhanced, for example, if / when an MA PDU session of one or more (e.g., certain) MA PDU session types is ongoing.

[0089] Systems, methods, and instrumentalities are described herein related to establishing an MA PDU session over a first leg.

[0090] One or more devices (e.g., a WTRU) may be configured to execute at least one of the following actions as described herein. In examples, a WTRU may perform at least one of the following actions to establish an MA PDU session over a first leg. The WTRU and / or network may 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 (e.g., two) mobile networks), and / or different subscription options (e.g., single subscription, dual subscription, and / or the like).

[0091] A WTRU operating to establish an MA PDU session over multiple (e.g., two) 3GPP legs may receive an MA PDU policy (MAPP). A MAPP may include information to allow the WTRU to determine an MA PDU session type to choose. The WTRU may make an MA PDU session type decision based on MA PDU session selection factors. The WTRU may send a PDU session establishment request message over the first leg to a mobile network (e.g., mobile network 1). The message may include MA PDU session (MAPS) assistance information. The WTRU may receive a PDU session establishment response message. The PDU session establishment response message may include MAPS configuration information. The WTRU may determine the RAT and / or mobile network combination to use for the second leg. The WTRU may determine whether to register with the determined mobile network for the second leg based on information received in the PDU session establishment response message.

[0092] A MAPP may indicate the mapping of an application flow to a (e.g., a specific) MA PDU session type.

[0093] MA PDU session selection factors may include at least one of the following: an ongoing connectivity, a user preference, a WTRU preference, QoS characteristics, and / or the like.

[0094] MAPS assistance information may include at least one of the following: a network decision, ongoing connectivity, a WTRU capability, and / or the like.

[0095] MAPS configuration information may include at least one of the following: an accepted MA PDU session type, a timer value, an indication of whether a (e.g., preferred) MN that may request (e.g., may require) registration, and / or the like.

[0096] One or more devices (e.g., a SMF) may be configured to execute at least one of the following actions (e.g., operations). In examples, an SMF may perform at least one of the following (e.g., actions) operations to establish an MA PDU session over a first leg. A WTRU and network may support multiple MA PDU session types, such as, for example, with 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). An SMF (e.g., configured as part of a mobile network) may receive a PDU session establishment request message from a WTRU (e.g., to establish the first leg of an MA PDU session). The PDU session establishment request may include MAPS assistance information. The SMF may determine the MA PDU session type to use for the MA PDU session based on the MA PDU session type requested by the WTRU, the MAPS assistance information provided by and / or received from the WTRU, and / or subscription information for the WTRU. The SMF may send a PDU session establishment response message. The PDU session establishment message may include the MAPS configuration information.

[0097] A device may include a processor configured to perform one or more actions as described herein. In examples, a device (e.g., a WTRU) may support a plurality of MA PDU session types. The device may receive a MAPP. The device may select an MA PDU session type from the plurality of supported MA PDU session types based, at least in part, on the MAPP. The device may send an MA PDU session establishment request over a first leg to a first mobile network. 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 RAT to use for a second leg. 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 the MA PDU session over the second leg based on the determination of whether to register with the second mobile network. The MA PDU session establishment request may include MA PDU session assistance information. The MAPP may indicate whether the WTRU may select the 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.

[0098] Systems, methods, and instrumentalities are described herein related to establishing connectivity over a second leg.

[0099] One or more devices (e.g., a network node, a WTRU) may be configured to execute at least one of the following actions as described herein. In examples, a first radio access network (e.g., RAN1) nodemay perform at least one of the following actions to establish connectivity over a second leg (e.g., a secondary leg). A WTRU may have registered with a first mobile network (e.g., mobile network 1). The WTRU may have established an MA PDU session over a first leg (e.g., a primary leg). The MA PDU session may not request (e.g., require) the WTRU to register over the second leg to a second mobile network (e.g., mobile network 2). The first RAN node may receive a first control plane message. The first control plane message may include an indication that the WTRU wishes to establish a connection to a second (e.g., selected) RAN node in a mobile network (e.g., a RAN2 node). The control plane message may indicate that the WTRU may be requesting second leg assistance information. The first RAN node may send an N2 message to the AMF of the first mobile network (e.g., AMF1). The N2 message may request the establishment of a connection to the second RAN node (e.g., the 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., which 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 the access stratum and / or non-access stratum (NAS) configuration for the WTRU over 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).

[0100] Second leg assistance information may indicate at least one of the following: that the access leg may be used as a second leg, an identifier of the second RAN node (e.g., RAN2 node), and / or an identifier of the AMF1.

[0101] A WTRU may perform at least one of the following operations to establish connectivity over the second leg. The WTRU may have registered with the first mobile network (e.g., mobile network 1). The WTRU may have (e.g., already) established an MA PDU session over the first leg. The MA PDU session may not request (e.g., require) that the WTRU register over the second leg to the second mobile network (e.g., mobile network 2). A WTRU may determine whether to establish connectivity with the second leg based on one or more connectivity 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 leg (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., selected RAN node or RAN2 node) and / or may include second leg assistance information. The WTRU may receive a second control plane message (e.g., 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.

[0102] Connectivity trigger events may include at least one of the following: a start of the MA PDU session over the first leg, reception of a PDU session establishment response over the first leg, and / or a NAS message over the first leg.

[0103] A device may include a processor configured to perform one or more actions. In examples, a device (e.g., a RAN node in a first network (RAN1)) may receive a first message including information indicating that a WTRU may send a request (e.g., seeks) to establish a connection to a selected RAN node in a second mobile network, and second leg assistance information. The device may send a second message to an AMF in the first mobile network requesting the establishment of the connection to the selected RAN node in the second mobile network. The second leg assistance information may include a second leg indication indicating that the connection is a second leg, and an AMF identifier identifying the AMF in the first mobile network. The device may use the second leg indication and the AMF identifier to select a transport network layer (TNL) association between the RAN node in the second mobile network and the AMF. The device may create a binding between the WTRU and the TNL association.

[0104] Systems, methods, and instrumentalities are described herein related to registering to a second leg (e.g., a secondary leg) of a mobile network.

[0105] One or more devices (e.g., a WTRU) may be configured to execute at least one of the following actions. In examples, a WTRU may perform at least one of the following operations (e.g., actions) to establish connectivity over a second leg. The WTRU may be a multi-universal subscriber identity module (MUSIM) capable 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 over the first leg. The MA PDU session may request (e.g., require) that the WTRU register over the second leg to the second mobile network (e.g., mobile network 2). The WTRU may have a (e.g., a separate) subscription for registering to the second mobile network (e.g., mobile network 2). A WTRU may have a MUSIM controller. The WTRU may determine that the mobile network to use for the second leg is the second mobile network (e.g., mobile network 2). The WTRU (e.g., MUSIM controller) may indicate to the non-access stratum (NAS) layer of the second subscriber identification module (SIM2) that the WTRU needs to register to the second mobile network (e.g., mobile network 2). The MUSIM controller may provide MA PDU session support information. The WTRU may establish connectivity to the RAN node of the second leg (e.g., RAN2 node) by sending a control plane message. The control plane message may include the registration request message. The WTRU may receive the registration accept message from the AMF of mobile network 2 (e.g., AMF2). The registration accept message may include registration restriction information and / or an indication for simplified dual subscription behavior. The WTRU (e.g., MUSIM controller) may (e.g., dynamically) indicate to the NAS layer of SIM2 if / when to initiate a registration to the second mobile network (e.g., mobilenetwork 2) and / or if / when to terminate a registration to the second mobile network (e.g., mobile network 2) based on the activity of an MA PDU session at the WTRU. The WTRU may deregister and / or reregister to the second mobile network (e.g., mobile network 2) based on the activity of an MA PDU session at the WTRU.

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

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

[0108] Simplified dual subscription behavior may provide an indication that the mobile networks have a business relationship. Simplified dual subscription behavior may take advantage of a simplified MA PDU session establishment.

[0109] A device may include a processor configured to perform one or more actions. In examples, a device (e.g., a WTRU) may establish a MA-PDU session over a first leg in a first mobile network. The device may indicate, by a MUSIM controller to a universal subscriber identity module (USIM), that the WTRU seeks to register with a second mobile network for the MA PDU session. The device may receive a registration accept message from the second mobile network that may include an indication for dual subscription behavior based on a relationship between the first and second mobile networks. The 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 indicate, by the MUSIM controller to the USIM, if / when to initiate and / or terminate the registration with the second mobile network based on WTRU MA PDU session activity.

[0110] Systems, methods, and instrumentalities are described herein related to providing MA PDU session rules to a SMF of a second mobile network (mobile network 2). One or more devices (e.g., a WTRU) may (e.g., be configured to) execute one or more of the following actions as described herein. In examples, a WTRU may provide assistance by performing one or more of the following as described herein. The WTRU may be a MUSIM capable 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 over the second leg to mobile network 2. The WTRU may have a (e.g., a separate) subscription for registering to mobile network 2. Mobile network 1 and mobile network 2 may not have a business relationship (e.g., a lack of (standardized) inter-mobile network communication). A 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 from the SMF of mobile network 1 (SMF1) (e.g., in the PDU session establishment response message). The NAS container may include information related to the MA PDUsession configured over mobile network 1 . The NAS container may be provided to the WTRU (e.g., the MUSIM controller). The WTRU (e.g., the MUSIM controller) may provide the NAS container to the NAS layer of the second subscriber identification module (e.g., NAS2 of the SIM2). The WTRU may determine the RAT and / or mobile network for the second leg. The WTRU (e.g., MUSIM controller) may indicate to the NAS layer of SIM2 that the WTRU needs to establish an MA PDU session over the second leg for mobile network 2. The WTRU (e.g., the MUSIM controller) may provide MA PDU session support information and / or the NAS container received from SMF1 . The WTRU may send a PDU session establishment request message over the second leg for mobile network 2. The PDU session establishment request message may include the received NAS container. The WTRU may receive a PDU session establishment accept message over the second leg for mobile network 2. The WTRU may transmit and / or receive traffic over the MA PDU session.

[0111] A device may include a processor configured to perform one or more actions. A device (e.g., a WTRU) may send, by a first USIM, a first MA PDU session establishment request over a first leg to a first mobile network. The device 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 for the first network. The device may provide the MA PDU session information for the first network to a MUSIM controller. The device may determine a second mobile network and a RAT to use for a second leg. The device (e.g., a WTRU) may provide (e.g., by the MUSIM controller to a second USIM) an indication that the device (e.g., the WTRU) requests (e.g., seeks) to establish the MA PDU session over the second leg for the second mobile network. The device may send (e.g., by the second USIM) a second MA PDU session establishment request over the second leg to the second mobile network. The MA PDU session information for the first network may be received in a NAS container from an SMF in the first mobile network. The indication may include the MA PDU session information for the first network and MA PDU session support information. The second MA PDU session establishment request may include the MA PDU session information for the first network.

[0112] Systems, methods, and instrumentalities are described herein related to establishing a MA PDU session over a first leg. One or more devices (e.g., a WTRU) may be configured to execute one or more of the following actions to establish an MA PDU session over a first leg. The WTRU and / or network may support one or more MA PDU session types, such as 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, and / or the like). A WTRU operating to establish an MA PDU session over multiple (e.g., two) 3GPP legs may receive a MAPP. A MAPP may include information to allow the WTRU to determine an MA PDU session type to choose. TheWTRU may make an MA PDU session type decision based on MA PDU session selection factors. The WTRU may send a PDU session establishment request message over the first leg to mobile network 1 . The message may include MA-PDU session (MAPS) assistance information. The WTRU may receive a PDU session establishment response message. The PDU session establishment response message may include MAPS configuration information. The WTRU may determine the RAT and / or mobile network combination to use for the second leg. The WTRU may determine whether to register with the determined mobile network for the second leg based on information received in the PDU session establishment response message.

[0113] A MAPP may indicate mapping of an application flow to an (e.g., a specific) MA PDU session type.

[0114] MA PDU session selection factors may include at least one of the following: ongoing connectivity, a user preference, a WTRU preference, QoS characteristics, and / or the like.

[0115] MAPS assistance information may include at least one of the following: a network decision, ongoing connectivity, a WTRU capability, and / or the like.

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

[0117] One or more devices (e.g., a SMF) may (e.g., be configured to) execute one or more of the following actions. In examples, an SMF may perform one or more of the following operations (e.g., actions) to establish an MA PDU session over the first leg. A WTRU and network may 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 (e.g., two) mobile networks), and / or different subscription options (e.g., single subscription, dual subscription, and / or the like). An SMF configured as part of a mobile network may receive a PDU session establishment request message from a WTRU (e.g., to establish the first leg of a MA PDU session). The PDU session establishment request message may include MAPS assistance information. The SMF may determine the MA PDU session type to use for the MA PDU session based on the MA PDU session type requested by the WTRU, the MAPS assistance information provided by and / or received from the WTRU, and / or the subscription information for the WTRU. The SMF may send a PDU session establishment response message. A PDU session establishment response message may include the MAPS configuration information.

[0118] Systems, methods, and instrumentalities are described herein related to establishing connectivity over a second leg. One or more devices (e.g., a radio access network (RAN), a WTRU) may be configured to execute one or more of the following actions. In examples, a first RAN (e.g., RAN1) node may performone or more of the following operations (e.g., actions) to establish connectivity over a second leg. A WTRU may have registered with a first mobile network (mobile network 1). The WTRU may have (e.g., already) established an MA PDU session over a first leg. The MA PDU session may not request (e.g., require) the WTRU to register over the second leg to a second mobile network (mobile network 2). A RAN1 node may 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 a (e.g., selected) RAN node in mobile network 2 (e.g., a RAN2 node) and / or second leg assistance information. The RAN1 node may send an N2 message to the AMF of the first mobile network 1 (e.g., AMF1) requesting the establishment of a connection to the selected RAN2 node and / or the creation of an NG application protocol (NGAP) WTRU- transport network layer association (TNLA)-binding for the RAN2 node. The RAN1 node may receive a transparent container from the RAN2 node. The transparent container from the RAN2 node may include the access stratum and NAS configuration for the WTRU over RAT2. The RAN1 node may forward the transparent container to the WTRU in a second control plane message (e.g., an RRCReconfiguration message).

[0119] Second leg assistance information may indicate at least one of that the access leg may be used as a second leg, an identifier of the RAN2 node, or an identifier of the AMF1 .

[0120] A WTRU may perform one or more of the following operations (e.g., actions) to establish connectivity over the second leg. The WTRU may have (e.g., already) registered with mobile network 1. The WTRU may have (e.g., already) established an MA PDU session over the first leg. The MA PDU session may not request (e.g., require) the WTRU to register over the second leg to mobile network 2. A WTRU may (e.g., determine to) establish connectivity to the second leg based on one or more connectivity trigger events. The WTRU may send a first control plane message to a RAN node of a first leg (RAN1 node). The control plane message may include an indication that the WTRU wishes to establish a connection to a (e.g., selected) RAN node (RAN2 node) and / or second leg assistance information. The WTRU may receive a second control plane message (e.g., 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.

[0121] Connectivity trigger events may include at least one of the following: a start of the MA PDU session over the first leg, reception of a PDU session establishment response over the first leg, and / or a NAS message over the first leg.

[0122] Systems, methods, and instrumentalities are described herein related to registering to a second leg mobile network. One or more devices (e.g., a WTRU) may (e.g., be configured to) execute one or moreof the following actions. In examples, a WTRU may perform one or more of the following operations (e.g., actions) to establish connectivity over a second leg. The WTRU may be a MUSIM capable 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 over the first leg. The MA PDU session may request (e.g., require) the WTRU to register over the second leg to the second mobile network (mobile network 2). The WTRU may have a (e.g., a separate) subscription for registering to mobile network 2. A WTRU may have a MUSIM controller. The WTRU may determine that the mobile network to use for the second leg may be mobile network 2. The WTRU (e.g., MUSIM controller) may indicate to the NAS layer of the second subscriber identification module (SIM2) that the WTRU needs to register to mobile network 2. The MUSIM controller may provide MA PDU session support information. The WTRU may establish connectivity to the RAN node of the second leg (RAN2 node) by sending a control plane message. The control plane message may include the registration request message. The WTRU may receive the registration accept message from the AMF of mobile network 2 (AMF2). The registration accept message may include registration restriction information and / or an indication for simplified dual subscription behavior. The WTRU (e.g., MUSIM controller) may (e.g., dynamically) indicate to the NAS layer of SIM2 if / when to initiate a registration to the mobile network 2. The WTRU (e.g., MUSIM controller) may (e.g., dynamically) indicate to the NAS layer of SIM2 if / when to terminate a registration to the mobile network 2 (e.g., based on the activity of an MA PDU session at the WTRU). The WTRU may deregister and reregister to mobile network 2 based on the activity of an MA PDU session at the WTRU.

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

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

[0125] Simplified dual subscription behavior may provide an indication that the mobile networks have a business relationship. Simplified dual subscription behavior may take advantage of simplified MA PDU session establishment.

[0126] Systems, methods, and instrumentalities are described herein related to providing MA PDU session rules to an SMF) of a second mobile network (mobile network 2). One or more devices (e.g., a WTRU) may be configured to execute one or more of the following actions (e.g., operations). In examples, a WTRU may 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 MA PDU session may request (e.g., require) the WTRU to register over the second leg to mobile network 2. The WTRU may have a (e.g., a separate) subscription for registering to mobile network 2. Mobile network 1and mobile network 2 may not have a business relationship (e.g., a lack of standardized inter-mobile network communication). A 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 from the SMF of mobile network 1 (SMF1) (e.g., in the PDU session establishment response message). The NAS container may include information related to the MA PDU session configured over the mobile network 1. The NAS container may be provided to the MUSIM controller. The MUSIM controller may provide the NAS container to the NAS layer of the second subscriber identification module (e.g., NAS2 of the SIM2). The WTRU may determine the RAT and / or mobile network for the second leg. The WTRU (e.g., MUSIM controller) may indicate to the NAS layer of SIM2 that the WTRU needs to establish an MA PDU session over the second leg for mobile network 2. The MUSIM controller may provide MA PDU session support information and / or the NAS container received from SMF1 . The WTRU may send a PDU session establishment request message over the second leg for mobile network 2. The message may include the received NAS container. The WTRU may receive a PDU session establishment accept message over the second leg for mobile network 2. The WTRU may transmit and / or receive traffic over the MA PDU session.

[0127] Session and mobility management: WTRUs may provide their session management (SM) and / or mobility management (MM) capabilities to the core network. A WTRU may send the WTRU’s MM core network capability information, for example, to an AMF during an initial registration procedure and / or mobility registration update procedure (e.g., within a NAS message). A WTRU may provide a 5GSM core network capability in PDU session establishment and / or modification requests. A message (e.g., these latter messages) may include the WTRU’s access traffic steering, switching, and splitting (ATSSS) capabilities.

[0128] A WTRU may (e.g., be requested or required to) perform registration to a network (e.g., if the WTRU needs access to services requiring registration). A WTRU may perform a registration based on one or more actions, such as by performing at least one of the following: public land mobile network (PLMN) selection or standalone non-public network (SNPN) selection, cell selection and / or reselection, and / or registration.

[0129] A WTRU may select a mobile network by using PLMN selection or SNPN selection. A network may be a public network or a non-public network. The WTRU may follow rules to determine how to select from the available networks at a given location and / or to determine if / when to look for higher priority networks.

[0130] A WTRU may use a cell selection and / or reselection procedure to camp on a cell.

[0131] A WTRU may use a registration procedure to inform a network about the WTRU presence and / or to provide coarse location information.

[0132] Traffic may be split across multiple (e.g., two) 3GPP access legs. WTRUs may support carrier aggregation (CA). CA may be provided over a (e.g., single) 3GPP access (e.g., new radio (NR) or long term evolution (LTE)), while allowing the WTRU to receive (e.g., over) two or more cells. The cells may (e.g., each) be on different frequency carriers. The use of the multiple (e.g., two) cells may be managed (e.g., entirely) in the RAN.

[0133] WTRUs may support dual connectivity (DC). DC may allow a WTRU to receive and / or transmit over multiple (e.g., two) 3GPP accesses (e.g., or 3GPP access legs). The accesses may be NR (gNB) or LTE (eNB). A deployment may have a first leg over LTE and a second leg over NR. A deployment of DC may support multiple (e.g., two) legs over NR. The multiple (e.g., two) legs may be on different bands (e.g., FR1 and FR2). A WTRU may employ DC using the Radio Frequency (RF) front end to support both accesses. In DC, a leg may be a master leg (e.g., that may be part of a master cell group (MCG)), and / or the other leg may be a secondary leg (e.g., that may be part of a secondary cell group (SCG)).

[0134] WTRUs may support communication over satellite links. Communication over satellite links may allow a WTRU to receive and / or transmit data over transparent satellite and / or repeater links (e.g., with a satellite and / or repeater in different orbits such as geostationary orbits (GEO), medium-earth orbits (MEO), low-earth orbits (LEO), and / or a high-altitude platform station (HAPS)). A WTRU may use the RF front end to communicate over the transparent satellite and / or repeater.

[0135] WTRUs may support various combinations of dual connectivity and carrier aggregation. A WTRU may have dual connectivity over multiple (e.g., two) 3GPP access legs. A (e.g., each) leg may use carrier aggregation. The set of cells on an (e.g., one) access leg may be referred to as a cell group. A WTRU may have dual connectivity with one or more (e.g., both) legs over transparent satellite and / or repeater links. At least one of the following scenarios may be supported: Leg1 : NR and Leg2: GEO satellite; Leg1 : NR and Leg2: LEO and / or MEO satellite; and / or Leg1 : GEO satellite and Leg2: LEO / MEO satellite.

[0136] WTRUs with DC may allow operation over multiple (e.g., two) 3GPP access legs. A WTRU (e.g., in DC) may be configured with how a data radio bearer (DRB) is mapped over the multiple (e.g., two) access legs. A WTRU may be configured with an MCG bearer, where traffic from a data bearer goes over the master leg. A WTRU may be configured with an SCG bearer, where traffic from a data bearer goes over the secondary leg. A WTRU may be configured with a split bearer, where traffic from a data bearer may be split between the master leg and the secondary leg. Processing (e.g., all processing) above the radio link control (RLC) layer may be in the master leg. Processing (e.g., all processing) below a packet data convergence layer (PDCP) layer may be in the master leg or in the secondary leg.

[0137] FIG. 2 illustrates an example of Service Data Flows Over Dual Connectivity. FIG. 2 shows an example of how downlink service data flows (SDFs) may travel over the network (e.g., 5G network) and / ormay be transmitted over a data radio bearer. SDFs may be mapped to QoS flows at the ingress point (e.g., UPF). Traffic over the QoS flows may arrive at the RAN nodes, where the traffic may be mapped to DRBs and transmitted over the radio interface. An SDF may be mapped to a (e.g., single) QoS flow. A QoS flow may be mapped to a (e.g., single) DRB. A DRB may be sent over a single leg, or the DRB may be split across multiple (e.g., two) legs. Different SDFs may (e.g., as a result) rely on DC. Different SDFs may be transmitted over different 3GPP accesses. An (e.g., a single) SDF in a DRB may not be split, switched, steered, and / or duplicated over multiple (e.g., two) different 3GPP accesses.

[0138] The choice of an access leg may be determined by the PDCP layer (e.g., mostly based on the estimated data volume, as in how much data the WTRU may have to transmit). The estimated data volume measure may reflect (e.g., all) traffic in the DRB. There may not be (e.g., as a result) a mechanism to control the choice of access leg per SDF, and / or to use a different metric to make the choice.

[0139] An SDF may be split, switched, steered, and / or duplicated over multiple (e.g., two) legs. The multiple legs may be 3GPP legs. At least one of the following may be provided: support of upper layer steering, split, and / or switching of WTRU traffic (e.g., pertaining to the same data session) across multiple (e.g., two) 3GPP access links. There may be a single subscription to a PLMN. There may be a single PLMN, a PLMN plus (standalone) Non-Public Network (NPN), multiple (e.g., two) PLMNs, and / or same or different RATS (e.g., 3GPP RATs, such as NR, NTN, plus NR, NTN, or LTE).

[0140] Multiple (e.g., two) networks (e.g., for the PLMN plus, PLMN, and / or NPN scenarios) may be managed by the same operator or by different operators (e.g., with a business agreement among them).

[0141] ATSSS may rely on the concept of MA connectivity. MA connectivity may include setting up an MA PDU session, where traffic from a service data flow may be sent over a first network (e.g., 3GPP) access leg, a second network (e.g., non-3GPP) access leg, or both access legs. One or more rules (e.g., session rules) may be configured and / or applied to establish a PDU session. The one or more rules applied may depend on whether a 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 (e.g., associated with) different PLMNs, and / or whether the WTRU may be registered on one of the accesses.

[0142] Steering functionalities may be used as part of ATSSS. Steering functionality refers to the logic that may be used to enable the switching, steering, and / or splitting of the traffic. Steering functionalities may include or be based on: multi-path transmission control protocol (MPTCP), multi-path QUIC, and / or ATSSS low layer (ATSSS-LL). MPTCP functionality may be used for TCP traffic. MPQUIC functionality may be used for UDP traffic. MPQUIC may be a multipath extension for QUIC, which is an encryptedconnection-oriented protocol that operates at the Transport Layer of the OSI model. ATSSS-LL steering functionality may be used for Ethernet, TCP, or UDP traffic.

[0143] Steering modes may be provided in ATSSS based on steering functionalities. Steering modes may include at least one of the following: active-standby mode, smallest delay mode, load balancing mode, priority based mode, and / or redundant steering mode. Steering modes may indicate to the WTRU (e.g., and / or UPF) if / when to switch, steer, split, and / or duplicate uplink traffic (e.g., and / or downlink traffic) from one access leg to another access leg.

[0144] A (e.g., single) steering mode may be provided for a service data flow. The policy control function (PCF) may provide the steering mode configuration to the WTRU in the ATSSS rules and / or to the UPF (e.g., in the N4 rules). The PCF may make decisions based on the QoS parameters (e.g., requirements) from the AF and / or based on the capability of the WTRU. A PCF may (e.g., if necessary) decide to change a steering mode configuration for a service data flow (e.g., based on a change in QoS requirements).

[0145] A WTRU may have one or more identities. A subscription permanent identifier (SUPI) may be a global (e.g., globally unique) identifier allocated to a (e.g., each) subscriber in a network (e.g., 5G). A SUPI value may be provisioned in a USIM and / or a unified data management (UDM) and / or user data repository (UDR) function (e.g., in 5G Core). A SUPI may be an international mobile subscriber identifier (IMSI) or a network access identifier (NAI). An IMSI version of a SUPI may include one or more (e.g., three) digits. In examples, one or more (e.g., the first three) digits may represent the mobile country code (MCC). One or more digits (e.g., the next two or three digits) may represent the mobile network code (MNC) (e.g., identifying the network operator or PLMN). One or more digits (e.g., the remaining digits) may represent the mobile subscriber identification number (MSIN).

[0146] A subscription concealed identifier (SUCI) may be a privacy preserving identifier including a concealed SUPI. A SUCI may include a PLMN ID of a home network (e.g., in MCC and MNC). The MCC and / or MNC may be transmitted in plain text.

[0147] A globally unique temporary identifier (GUTI) may be allocated by an AMF. The AMF may assign a new GUTI to the WTRU at a (e.g., any) time. The GUTI may include a (e.g., a globally unique AMF ID (GUAMI) and a temporary mobile subscriber identity (TMSI). The GUAMI may identify the assigned AMF. The TMSI may identify the WTRU within (e.g., uniquely within) the AMF. The GUAMI may include (e.g., be a concatenation of) the PLMN ID and / or the AMF identifier.

[0148] A WTRU, which may be considered a MUSIM device, may have multiple USIMs in operation at a similar time (e.g., simultaneously, concurrently). A (e.g., each) USIM may allow the WTRU to obtain a service from a different mobile network. An example use case for MUSIM devices may be professionalswith separate business and personal numbers. Instead of carrying two phones, the professionals may use a (e.g., single) phone with multiple (e.g., two) USIM cards.

[0149] Terminal behavior with respect to the simultaneous handling of multiple USIMs may depend on WTRU capabilities (e.g., a WTRU with single Rx / single Tx, a WTRU with dual Rx / single Tx, and / or a WTRU with dual Rx / dual Tx). Dual Rx may allow a MUSIM WTRU to (e.g., simultaneously) receive traffic from multiple (e.g., two) networks. Single RX may allow a MUSIM WTRU to receive traffic from one network at a (e.g., one) time. Single Tx may allow a MUSIM WTRU to transmit traffic to one network at a (e.g., one) time.

[0150] Multiple (e.g., two) USIMs may run independently of each other. A USIM (e.g., each USIM) may utilize (e.g., require that the WTRU have) a dedicated non-access stratum and access stratum protocol stacks. Coordination may be used (e.g., depending on WTRU capabilities) to allow a WTRU to obtain service to multiple mobile networks. Coordination may not rely on mobile network interactions. A WTRU may (e.g., as a result) act like a mediator between the multiple (e.g., two) mobile networks.

[0151] Subscriptions to multiple (e.g., two) network operators through a MUSIM device may be designated as a dual subscription. A (e.g., each) distinct subscription to a network operator (e.g., not involving a MUSIM device) may be designated as a single subscription.

[0152] The AMF may use an interface (e.g., an N14 interface) for AMF re-allocation and / or AMF to AMF information transfer. The interface may be an intra-PLMN or an inter-PLMN (e.g., in the example of inter- PLMN mobility).

[0153] For inter-PLMN mobility, a source AMF may select one or more AMF instances in the target PLMN (e.g., by querying a target PLMN level network repository function (NRF) via the source PLMN level NRF with a target PLMN ID). The target PLMN level NRF may return an AMF instance address based on the target operator configuration. The AMF may select a different AMF (e.g., after the handover procedure).

[0154] ATSSS functionality may allow a WTRU to split, steer, switch, and / or duplicate traffic of a service data flow (SDF) over multiple types of networks (e.g., 3GPP access and non-3GPP access). DC may allow a WTRU to have a first SDF over a first (e.g., 3GPP) access and a second SDF flow over a second (e.g., 3GPP) access. Splitting, steering, switching, and / or duplication traffic of an SDF may or may not be allowed. Access supported for DC may be terrestrial and / or non-terrestrial (e.g., over PLMNs and SNPNs).

[0155] DualSteer may extend ATSSS functionality by allowing a WTRU to split, steer, switch, and / or duplicate traffic of an SDF over multiple (e.g., two) 3GPP network accesses (e.g., non-terrestrial 3GPP and SNPN).

[0156] DualSteer functionality may include a WTRU with multiple (e.g., two) network (e.g., 3GPP) access legs. The access legs may be over 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)).

[0157] An MA PDU session with multiple (e.g., two) network (e.g., 3GPP) access legs may be established and used for the transmission of uplink and / or downlink traffic.

[0158] A WTRU may use one or more MA PDU session types for an MA PDU session depending on radio access options (e.g., 3GPP access leg, non-3GPP access leg), mobile network options (e.g., single mobile network for multiple access legs and / or one mobile network per access leg), different subscription options (e.g., single subscription for multiple access legs and / or dual subscription one for each access leg). A WTRU and / or network may choose between the different MA PDU session types.

[0159] A WTRU may connect to a second access leg, for example, after the WTRU may have established an MA PDU session over a first access leg of a first mobile network. A WTRU may register with the mobile network of the second access leg (e.g., for a dual subscription scenario).

[0160] In examples, an MA PDU session may rely on dual subscription. A WTRU may connect to a second access leg. The WTRU may establish an MA PDU session over the second leg to receive a configuration for the MA PDU session (e.g., considering that the mobile networks may not communicate with each other).

[0161] A MA PDU session may refer to a PDU session with multiple (e.g., two) access legs. The access legs may be over different access technologies. An MA PDU session may be of an ATSSS type where one access leg may be a first type of network (e.g., a 3GPP access leg) and the other access leg may be a second type of network (e.g., a non-3GPP access leg). An MA PDU session may be of a DualSteer type where the multiple access legs are the same type of network (e.g., 3GPP access legs). The RAN nodes of the access legs may be connected to the same mobile network or to different mobile networks.

[0162] A leg may refer to a path between a WTRU and a network. In examples, a 3GPP leg and / or a non-3GPP leg may be read as a leg for generic network to WTRU leg examples.

[0163] A 3GPP leg may refer to a transmission path between a WTRU and a network. The transmission path may rely on 3GPP RAT (e.g., WCDMA, LTE, and / or NR technologies). The RAT may be on licensed, unlicensed, and / or reserved bands. A 3GPP leg may be over terrestrial or satellite links. A 3GPP leg may be direct from a WTRU to a base station (e.g., over the Uu interface). A 3GPP leg may be indirect from a WTRU to a base station (e.g., via one or more relay WTRUs).

[0164] A non-3GPP leg may refer to a transmission path between a WTRU and a network. The transmission path may rely on a non-3GPP RAT (e.g., WiFi). The RAT may be on licensed, unlicensed, or reserved bands. A non-3GPP leg may rely on a non-3GPP InterWorking function (N3IWF), a trusted non- 3GPP gateway function (TGNF), or a residential gateway (e.g., 5G RG).

[0165] A mobile network (MN) may refer to a PLMN, an NPN, or a (e.g., any) network infrastructure that manages one or more access nodes and WTRUs. Access nodes may provide connectivity to the WTRUs through a wireless or wired mechanism.

[0166] A home MN may refer to a home mobile network for a WTRU (e.g., an HPLMN). A home MN may maintain subscription information for a WTRU. User plane traffic may be transferred from the visited mobile network to the home MN (e.g., in a home routed mobility scenario).

[0167] A visited MN may refer to a visited mobile network for a WTRU (e.g., a VPLMN). A WTRU may (e.g., if / when roaming) obtain service from a visited MN. In some examples (e.g., a local breakout mobility scenario), user plane traffic may be transferred to the data network from the visited MN.

[0168] An RANx node may refer to a RAN node over RATx. A RAN node may be a gNB, eNB, and / or the like (e.g., for a 3GPP RAT).

[0169] An NFy may refer to a network function (NF) in mobile network y. The NF may be SMF, AMF, PCF, UDM, and / or the like.

[0170] MNs may communicate with each other if / when MNs have a business relationship. For example, multiple MNs may use one or more interfaces (e.g., an N32 interface) to communicate between multiple (e.g., two) security edge protection proxies (SEPPs). The SEPP may perform message filtering and policing on inter-MN control plane interfaces.

[0171] MAPS rules may refer to the rules used by the WTRU and / or the UPF for the MA PDU session. The rules may be a superset of the ATSSS rules. The rules may include steering functionalities, steering modes, and / or other configuration information that may be used in an MA PDU session (e.g., the address of a performance management function (PMF)).

[0172] A linked SA PDU session may refer to a single access PDU session that is used to provide connectivity for the second leg. A linked SA PDU session may be used to transfer IP traffic between a WTRU and a PSA UPF.

[0173] Examples are described herein with respect to DualSteer functionality (e.g., where both access legs are 3GPP access legs). Examples described herein are applicable to other multi-leg scenarios, including ATSSS functionality (e.g., where one access leg may be 3GPP and another access leg may be non-3GPP).

[0174] An MA PDU session may be enabled over multiple (e.g., two) 3GPP access legs. An MA PDU session type may be selected. An MA PDU session of the selected MA PDU session type may be established over a first leg. Connectivity may be established over the second leg based on the MA PDU session type. An MA PDU session of the selected MA PDU session type may be established over thesecond leg. Enhanced control plane signaling may be enhanced if / when an MA PDU session of one or more (e.g., certain) MA PDU session types is ongoing.

[0175] Benefits provided by one or more examples described herein may include enabling a WTRU to select an MA PDU session type. Benefits provided by one or more examples described herein may include enabling a WTRU to establish an MA PDU session of the selected type over multiple (e.g., two) 3GPP access legs based on a RAT for a leg (e.g., LTE, NR), a RAT type for a leg (e.g., terrestrial, satellite), a PLMN for a leg, a PLMN type for a leg (e.g., HPLMN, NPN, VPLMN), and / or a subscription on a leg. The second access leg may be provided with a potential reduction in control plane signaling (e.g., in terms of paging).

[0176] An MA PDU session may be established and operated. An MA PDU session may allow a WTRU and UPF to transfer traffic (e.g., uplink and / or downlink) of one or more SDFs over multiple (e.g., two) access legs. An (e.g., each) access leg may be a 3GPP leg or a non-3GPP leg. An (e.g., each) access leg may be part of the same MN or part of different MNs. There may be multiple alternatives to realize an MA PDU session. An (e.g., each) example may be referred to as an MA PDU session type. One or more (e.g., several) of the various MA PDU session types are described herein.

[0177] FIG. 3 illustrates an example procedure to configure and use a MA PDU session. As shown in FIG. 3, a MA PDU session may be configured for and used with SDFs (e.g., with an accompanying description). The WTRU may be registered in MN1 . MN1 may be the home MN or a visited MN. The WTRU may or may not be registered in MN2.

[0178] At 1 , the WTRU may be provided a policy, for example, as part of the WTRU route selection policy (URSP). The WTRU may use the policy to determine which MA PDU session type to use for the SDF. The WTRU may (e.g., if / when the WTRU starts a new flow) determine if the WTRU needs to start a new MA PDU session. The WTRU may (e.g., also) determine the MA PDU session type (e.g., as described herein).

[0179] At 2, the WTRU may establish an MA PDU session over a first leg. The WTRU may provide MA PDU session assistance information (MAP Al) to the network (e.g., in support of the MA PDU session types as described herein).

[0180] At 3, the WTRU may determine a RAT and / or MN combination to use for the second leg. The MN for the second leg may be denoted as MN2.

[0181] At 4, the WTRU may establish connectivity over the second leg. The WTRU may register with MN2 depending on the MA PDU session type and / or existing connectivity. The WTRU may perform a registration update with an indication about the MA PDU session in MN2 (e.g., as described herein).

[0182] At 5, the WTRU may establish an MA PDU session over the second leg. The WTRU may provide MAP Al to the network in support of the MA PDU session types (e.g., as described herein).

[0183] At 6, the WTRU and the UPF may transfer user plane traffic using the selected MA PDU session type. Control plane signaling enhancements may be provided for (e.g., certain) MA PDU session types (e.g., as described herein).

[0184] MA PDU session types may 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 the like.

[0185] A WTRU and UPF may have multiple (e.g., many) possibilities for establishing an MA PDU session. An MA PDU session may have at least one of the following types: type 1 , type 2, type 3, type 4, type 5, type 6, and / or type 7.

[0186] FIG. 4 illustrates an example of an MA PDU session type 1. Type 1 may involve a (e.g., one) 3GPP leg and a (e.g., one) non-3GPP leg. The multiple (e.g., two) legs may be on the same MN or on different MNs. Type 1 may be referred to as MA PDU session type 1 (e.g., as shown by example in FIG. 4).

[0187] FIG. 5 illustrates an example of MA PDU session type 2. Type 2 may involve multiple (e.g., two) 3GPP legs on the same MN. The multiple (e.g., two) 3GPP legs may connect to the same MN. Type 2 may be referred to as MA PDU session type 2 (e.g., as shown by example in FIG. 5). The WTRU may have a separate registration over an (e.g., each) access leg. The WTRU may have a single registration that the WTRU uses over the multiple (e.g., both) access legs.

[0188] FIG. 6 illustrates an example of MA PDU session type 3 and type 4. Type 3 (e.g., single subscriptions with a requested (e.g., required second registration)) may involve multiple (e.g., two) 3GPP legs on different MNs using a single subscription. A (e.g., each) 3GPP leg may connect to a different MN. A WTRU may have a single subscription (e.g., to a home MN). In examples, MN1 may be a home MN and MN2 may be a visited MN. In examples, MN2 may be a home MN and MN1 may be a visited MN. In examples, MN1 and MN2 may be visited MNs. The different MNs may (e.g., be assumed to) have a business relationship between themselves. The WTRU may (e.g., need to first) register to an MN (e.g., a visited MN or a home MN) to use the MN for a MA PDU session. Type 3 may be referred to as MA PDU session of type 3 (e.g., as shown by example in FIG. 6). FIG. 6 shows a second UPF (UPF2) between the 3GPP access Ieg2 node and the PSA UPF. The second UPF (UPF2) may be in a visited MN with an N9 interface to the PDU session anchor (PSA) UPF.

[0189] Type 4 (e.g., single subscriptions without requested (e.g., required) second registration) may involve multiple (e.g., two) 3GPP legs on different MNs using a single subscription. A (e.g., each) 3GPP leg may connect to a different MN. A WTRU may have a single subscription (e.g., to a home MN). In examples,MN1 may be a home MN and MN2 may be a visited MN. In examples, MN2 may be a home MN and MN1 may be a visited MN. In examples, MN1 and MN2 may be visited MNs. The different MNs may have a business relationship between themselves. In examples (e.g., of a type 4 MA PDU session type), the WTRU may not need to (e.g., first) register to a visited MN to use the MN for an MA PDU session. Type 4 may be referred to as MA PDU session of type 4 (e.g., as shown by example in FIG. 6).

[0190] FIG. 7 illustrates an example of MA PDU session type 5. Type 5 (e.g., dual subscription to cooperating MNs) may involve multiple (e.g., two) 3GPP legs on different MNs using a dual subscription. A (e.g., each) 3GPP leg may connect to a different MN. A WTRU may be a MUSIM capable WTRU. For example, one SIM may connect to a first MN while another SIM may connect to a second MN. The different MNs may (e.g., be assumed to) have a business relationship, allowing a WTRU to use the services of both MNs. In examples (e.g., of a type 5 MA PDU session type), a WTRU may (e.g., need to) register to both MNs. The MNs may communicate to facilitate inter-MN interactions. The WTRU may (e.g., be assumed to) have MUSIM controller functionality. MUSIM functionality may allow interaction between the activity over the multiple (e.g., two) SIMs. Type 5 may be referred to as MA PDU session of type 5 (e.g., as shown by example in FIG. 7).

[0191] FIG. 8 illustrates an example of MA PDU session type 6. Type 6 (e.g., dual subscription to noncooperating MNs) may involve multiple (e.g., two) 3GPP legs on different MNs using a dual subscription. A (e.g., each) 3GPP leg may connect to a different MN. A WTRU may be a MUSIM capable WTRU. In examples, a (e.g., one) SIM may connect to a first MN while a second (e.g., the other) SIM may connect to a second MN. The different MNs may (e.g., be assumed) not have a business relationship. In examples (e.g., of a type 6 MA PDU session type), the WTRU may (e.g., need to) register with both MNs. There may not be inter-MN communication, if the MNs do not have a business relationship. The WTRU may (e.g., be assumed to) have MUSIM controller functionality. MUSIM controller functionality may facilitate an interaction between the activity over the multiple (e.g., two) SIMs. Type 6 may be referred to as MA PDU session of type 6 (e.g., as shown by example in FIG. 8).

[0192] FIG. 9 illustrates an example of MA PDU session type 7. Type 7 (e.g., SA PDU session for the second leg) may involve multiple (e.g., two) access legs on the same or different MNs, where the second access leg is using a linked SA PDU session to establish connectivity (e.g., IP connectivity) between the WTRU and the PSA UPF. The PDU session over the first access leg may be a MA PDU session. The PDU session over the first leg may include the WTRU and the UPF configured to route (or to receive) traffic over the second leg using the connectivity established over the linked SA PDU session. The access legs for a type 7 MA PDU session type may be 3GPP or non-3PPP access legs. The mobile network for an (e.g., each) access leg may be the same mobile network or different mobile networks. For different mobilenetworks, the WTRU may have a (e.g., single) subscription to the different mobile networks or the WTRU may have dual subscriptions to the different mobile networks. Type 7 may be referred to as MA PDU session of type 7 (e.g., as shown by example in FIG. 9).

[0193] MA PDU session type 1 may be referred to as ATSSS type. The other MA PDU session types may be considered different versions of a DualSteer type. Although examples are described with reference to seven types (type 1 - 7), the examples may be applicable to other MA PDU session types, such as an ATSSS-lite version. In an example ATSSS-lite version, an MA PDU session may have one 3GPP leg and one non-3GPP leg. The non-3GPP leg may not be connected to an (e.g., any) MN.

[0194] The PDU session anchor (PSA) UPF shown in FIGS. 6-8 (e.g., for MA PDU session types 3 to 6) may be part of a home MN (e.g., referred to as home routed) or part of a visited MN (e.g., referred to as a local breakout).

[0195] A WTRU (e.g., for MA PDU session of type 5 and / or type 6) may be a MUSIM capable WTRU. A WTRU may be configured to (e.g., always) register with one or more (e.g., both) MNs. A WTRU may register with the second MN (e.g., only) if / when needed for a MA PDU session (e.g., if the MUSIM capability may be used (e.g., only) for the second 3GPP access leg of a MA PDU session). A MUSIM controller may indicate to the NAS layer of SIM2 if / when to initiate a registration to the second MN and / or if / when to terminate a registration to the second MN (e.g., based on the activity of an MA PDU session at the WTRU).

[0196] A WTRU may (e.g., determine to) start an MA PDU session. A WTRU may determine and / or select an MA PDU session type to provide in an MA PDU session.

[0197] A WTRU may be provided with a MAPP. A MAPP may include information to allow the WTRU to determine which of the MA PDU session types to choose. The MAPP may be part of a URSP, obtained in a registration accept message, obtained in a PDU session establishment message, and / or obtained in a modification accept message. The policy (e.g., MAPP) may tie an (e.g., a specific) application flow to a (e.g., specific) MA PDU session type. The policy may inform the WTRU that the PDU session may be an MA PDU session. The policy (e.g., MAPP) may leave the decision of the session type to the WTRU and / or to the network. A WTRU may determine which MA PDU session type to use based on at least one of the following MA PDU session selection factors: an existing MA PDU session, an existing connectivity over a second 3GPP RAT, an existing connectivity over a non-3GPP RAT, a WTRU capability, an internal state, a (e.g., measured) metric, a QoS characteristic of the application traffic, and / or a network preference.

[0198] A WTRU may determine which MA PDU session type to use based on an existing MA PDU session. A WTRU may (e.g., choose to) use the MA PDU session type (e.g., the same type) if the WTRU(e.g., already) has an MA PDU session active using one of the session types (e.g., which may allow the WTRU to save power by not starting transmission over a new access leg).

[0199] A WTRU may determine which MA PDU session type to use based on existing connectivity over a second 3GPP RAT. A WTRU may (e.g., prefer to and / or determine to) use MA PDU session type 2-6 if the WTRU is (e.g., already) using a second 3GPP RAT. In examples, a DC feature or a dual active protocol stack (DAPS) feature may allow the WTRU to save power by not starting a new non-3GPP access.

[0200] A WTRU may determine which MA PDU session type to use based on an existing connectivity over a non-3GPP RAT. A WTRU may (e.g., prefer to and / or determine to) use MA PDU session type 1 if the WTRU is (e.g., already) using a non-3GPP RAT (e.g., which may allow the WTRU to save power by not starting a new 3GPP access).

[0201] A WTRU may determine which MA PDU session type to use based on a WTRU capability. A WTRU may select from MA PDU session types 1-4 if the WTRU does not support MUSIM (e.g., the WTRU is not configured with MUSIM capabilities and / or a MUSIM controller).

[0202] A WTRU may determine which MA PDU session type to use based on an internal state. A WTRU may select an MA PDU session type that minimizes power consumption if the WTRU is power limited. The WTRU may determine that the power usage is lower over the non-3GPP access and, as a result, favor and / or select MA PDU session type 1 .

[0203] A WTRU may determine which MA PDU session type to use based on a (e.g., measured) metric. In examples, a WTRU may have information as to the signal quality of the non-3GPP link and / or the second 3GPP link. The WTRU may (e.g., determine to) use a session type that may maximize the signal quality. In examples, the WTRU may have information as to the congestion over the non-3GPP link and / or the second 3GPP link. The WTRU may (e.g., determine to) use a session type that may minimize the congestion (e.g., over the non-3GPP link and / or over the second 3GPP link).

[0204] A WTRU may determine which MA PDU session type to use based on a QoS characteristic of the application traffic. The WTRU may determine that the QoS of the application requests (e.g., requires) a (e.g., guaranteed) bit rate. The WTRU may select an MA PDU session type that provides (e.g., better) support for a (e.g., guaranteed) bit rate. The WTRU may select a first access over a second access (e.g., always select one access over another) based on a QoS characteristic. A WTRU may (e.g., always) select a session type where the second leg is a 3GPP leg (e.g., MA PDU session types 2-6) to reduce and / or minimize the delay.

[0205] A WTRU may determine which MA PDU session type to use based on a network preference. For example, a network may have a preference as to the session type option. The preference may be providedto the WTRU in an NAS message (e.g., with a registration accept message or a PDU session establishment accept message).

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

[0207] A MAPP may have a set of MAPP rules. The set of MAPP rules may correspond to ATSSS rules (e.g., the set of MAPP rules may be provided to the WTRU along with other ATSSS rules). MAPP and / or ATSSS rules may include one or more MN IDs. MN IDs may indicate which MN is to be used. MN IDs may be ordered by network preference. MN IDs may be chosen by the WTRU if more than one WTRU exists and / or if a WTRU is a wildcard. MAPP and / or ATSSS rules may include one or more MA PDU session types. MAPP and / or ATSSS rules may include an indication to minimize power consumption. MAPP and / or ATSSS rules may include a minimum signal quality.

[0208] An MA PDU session may be established over a first leg. A WTRU may provide information to a mobile network over the first access leg to assist in establishing an MA PDU session with multiple (e.g., two) 3GPP access legs.

[0209] A WTRU may determine whether to (e.g., that the WTRU needs to) start an MA PDU session. The WTRU may determine the MA PDU session type. The WTRU may establish an MA PDU session over a first access leg. The WTRU may include MAPS assistance information in a PDU session establishment request message to MN1 . MAPS assistance information may include at least one of: a selected MA PDU session type, a MA PDU session, a network decision, a list of MN IDs that the WTRU may use for the MA PDU session, metrics (e.g., measured metrics), an MA PDU session type user preference, a WTRU preference, a WTRU capability, an active second SIM, an active non-3GPP, and / or an active 3GPP.

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

[0211] MAPS assistance information may include an MA PDU session. An MA PDU session may provide an indication that a requested PDU session request is for an MA PDU session.

[0212] MAPS assistance information may include a network decision. A network decision may provide an indication to the network that the network may choose an MA PDU session type.

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

[0214] MAPS assistance information may include (e.g., measured) metrics. A WTRU may provide an indication of the current power status. The network may prefer one or more (e.g., certain) MA PDU session types depending on whether the WTRU is at least one of: power limited, connected to a mains powersupply, operating over battery, has battery status less than a threshold, has battery status above a threshold, and / or the like.

[0215] MAPS assistance information may include an MA PDU session type user preference. A user may prefer a first (e.g., one) MA PDU session type over a second (e.g., another). In examples, a user may provide a preference to the WTRU over a graphical user interface. The preference may be provided (e.g., supplied) to MN1 in the MAPS assistance information.

[0216] MAPS assistance information may include a WTRU preference. A WTRU may indicate a preference if the network selects the MA PDU session type. In examples, a WTRU may favor an MA PDU session type with MUSIMs, or an MA PDU session type that relies (e.g., only) on non-3GPP access. A WTRU may indicate that the WTRU prefers an MA PDU session type that minimizes or maximizes a metric. In examples, the network may choose an MA PDU session type that minimizes WTRU power consumption, maximizes WTRU throughput, and / or minimizes roaming costs.

[0217] MAPS assistance information may include one or more WTRU capabilities. A WTRU may indicate a capability to support one or more (e.g., certain) MA PDU session types.

[0218] MAPS assistance information may include an active second SIM (e.g., an indication that the WTRU has a second SIM that is active). The WTRU may (e.g., also) include an identifier of the MN with which the second SIM may be registered.

[0219] MAPS assistance information may include an active non-3GPP (e.g., an indication if the WTRU has ongoing non-3GPP connectivity). The WTRU may (e.g., also) include an identifier of the MN over which the WTRU has non-3GPP connectivity. The network may use the information to favor an MA PDU session type that supports a second leg (e.g., a non-3GPP based second leg).

[0220] MAPS assistance information may include an active 3GPP. An active 3GPP may include an indication if the WTRU (e.g., already) has connectivity over a second 3GPP leg. The WTRU may (e.g., also) indicate how the second leg is used. In examples, the WTRU may indicate that the second leg is being used to support DC or DAPS. The network may use the information (e.g., the MAPS assistance information) to favor an MA PDU session type that supports a second leg (e.g., a 3GPP based second leg).

[0221] SMF1 may use the provided MAPS assistance information to determine the configuration of the MA PDU session with multiple (e.g., two) 3GPP access legs. Configuration information for the MA PDU session with multiple (e.g., two) 3GPP access legs may be provided to the WTRU.

[0222] SMF1 may 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 provided MAPS assistance information from the WTRU, and / or subscription information for the WTRU.

[0223] SMF1 may respond to the WTRU with a PDU session establishment accept. The PDU session establishment accept may include at least one of the following MAPS configuration information: an accepted MA PDU session type, MAPS rules, a (e.g., preferred) radio access type, a (e.g., preferred) band type, (e.g., preferred) MNs, and / or a timer value.

[0224] A PDU session establishment accept may indicate MAPS rules. MAPS rules may indicate rules related to the configured steering functionality, steering mode, performance monitoring, and / or the like.

[0225] A PDU session establishment accept may indicate a preferred radio access type. A preferred radio access type may be for a second leg (e.g., 3GPP or non-3GPP, terrestrial or satellite, direct or indirect).

[0226] A PDU session establishment accept may indicate a (e.g., preferred) band type. A band type may be a preferred band type for a second leg (e.g., licensed, unlicensed, reserved). The SMF may (e.g., also) provide an indication of the band.

[0227] A PDU session establishment accept may indicate (e.g., preferred) MNs. The PDU session establishment accept may include a (e.g., preferred) MN or a list of (e.g., preferred) MNs. The SMF may (e.g., for each preferred MN) for an MN, provide an indication whether the (e.g., preferred) MN requests (e.g., requires) registration.

[0228] A PDU session establishment accept may indicate a timer value. The timer value may provide an indication to tell the WTRU to wait the timer value (amount) before establishing a connection for the second leg. A timer value may indicate to the WTRU to wait for a command (e.g., an explicit command) from the network before establishing a connection for the second leg. A timer value (e.g., a delay indicated by the timer) may allow MN1 to delay and / or control if / when the WTRU starts using one or more (e.g., both) legs of the MA PDU session. A timer value (e.g., a delay) may be useful if the first leg and the second leg are over the same mobile network.

[0229] In examples, MAPS assistance information may be an extension of the WTRU ATSSS capabilities. Extended ATSSS capabilities may go to the PCF via the SMF. The PCF may make the decision as to the MAPS configuration information. The MAPS configuration information may be included in extended ATSSS rules. The PCF may set the extended ATSSS rules.

[0230] A WTRU may establish connectivity over the selected second leg. A WTRU may determine the RAT and / or MN combination to use for the second leg. The RAT and / or MN combination may be determined once the WTRU has determined to start an MA PDU session and knows and / or determines the MA PDU session type. The WTRU NAS layer may request that (e.g., ask) the access stratum to find RAT and / or MN combinations to use for the second leg. The access stratum may report the found RAT and / or MN combinations. The NAS layer (e.g., the WTRU) may make a selection. The WTRU may select a RATand / or an MN. The WTRU-selected RAT may be referred to as RAT2. The WTRU-selected MN may be referred to as MN2. The WTRU may (e.g., as part of establishing connectivity over RAT2) synchronize to the RAN node of RAT2 and / or establish a signaling connection to the RAN node of RAT2. Establishing connectivity over RAT2 may be equivalent to establishing an RRC connection to the gNB (e.g., if RAT2 is NR). The WTRU may (e.g., need to) register to MN2 over the second leg, or the WTRU may (e.g., for example, if no registration is required) inform AMF1 that the WTRU wants to establish connectivity over RAT2.

[0231] A WTRU may decide whether to perform registration over a second leg. In examples, the WTRU may not need to register over the second leg. A registration may not be needed if MN2 is the same as MN1 (e.g., the second leg is over the same MN as the first leg). The resulting MA PDU session may (e.g., in the example where MN2 is the same as MN1) be an MA PDU session type 2. A registration may not be needed if MN2 is different from MN1. In examples, MN2 may act like a visited MN. The resulting PDU session (e.g., if MN2 acts like a visited MN) may be an MA PDU session type 4.

[0232] A WTRU may determine whether to (e.g., decide if the WTRU needs to) perform a registration over MN2. In examples, a WTRU may be configured to not perform a registration if MN2 == MN1 . A WTRU may determine that registration to MN2 is not necessary based on information included in the WTRU's USIM (e.g., such as in an operator controlled PLMN selector with access technology parameter). The home MN operator may include an indication for a (e.g., each) PLMN in the parameter to indicate if registration to the MN is requested (e.g., required), for example, if the MN is used for the second leg of a MA PDU session. A determination may (e.g., additionally and / or alternatively) be made from information received in a prior MA PDU session establishment response. A prior MA PDU session establishment response may indicate that a preferred MN requests (e.g., requires) registration.

[0233] A registration may not be requested (e.g., required) to a second leg MN. A WTRU may be triggered to establish connectivity to RAT2. RAT2 connectivity triggers may be different from triggers that may be used by the WTRU to establish connectivity to RAT 1 . RAT2 connectivity triggers may be different from triggers that may be used by the WTRU to establish connectivity to RAT2 in DC and / or DAPS.

[0234] One or more connectivity trigger events may trigger a WTRU to establish connectivity over RAT2 (e.g., if / when the WTRU does not need to register over the second leg).

[0235] In an example connectivity trigger event, a WTRU may (e.g., start to) establish connectivity to RAT2 after sending an MA PDU session establishment request over the first leg. The WTRU may have (e.g., already) determined a preferred RAN and / or MN combination for the MA PDU session. The WTRU may (e.g., also start to) establish connectivity over RAT2 based on (e.g., upon) sending the MA PDU session establishment request.

[0236] In an example connectivity trigger event, a WTRU may (e.g., start to) establish connectivity to RAT2, for example, after receiving an MA PDU session establishment response from the first leg. The WTRU may use the information in the response to select a RAT and / or MN combination.

[0237] In an example connectivity trigger event, a WTRU may establish connectivity to RAT2 after receiving an NAS message from the network to connect to the second leg. The WTRU may have received a PDU session establishment response from the network. The WTRU may have selected the RAT and / or MN combination to use for the second leg. The network may send an NAS message to the WTRU. The NAS message may signal and / or indicate to the WTRU, to establish (e.g., start establishing) connectivity to RAT2. The indication may allow MN1 to control if / when the WTRU establishes the multiple (e.g., both) legs of the MA PDU session.

[0238] In examples, a WTRU may not request (e.g., require) registration over the second access. AMF1 may be informed that the WTRU may have established connectivity to RAT2 for a MA PDU session. A TNL association may be established between a RAN2 node and AMF1.

[0239] AMF1 may be informed that the WTRU has established connectivity to RAT2 using one or more of the following options described herein.

[0240] In an example option of informing AMF1 , a WTRU may start a connection to a RAN2 node by sending an access stratum control plane message. In examples, if RAT2 is a 3GPP access network, a WTRU may start an RRC connection by sending an RRCSetupRequest message or an RRCSetupComplete message. The access stratum control plane message may include at least one of the following: a WTRU identifier (e.g., an identifier of the WTRU), a second leg indication (e.g., an indication that the access leg may be used as a second leg), an AMF identifier (e.g., an identifier of AM F1, referring to AMF serving the WTRU over RAT1 , such as a GUAMI), and / or an NAS message that RAN2 sends to AMF.

[0241] The RAN2 node may receive the access stratum control plane message. The RAN2 node may use the second leg indication and / or the AMF identifier to select a TNL association between the RAN2 node and the AMF (e.g., identified by the AMF identifier). The RAN2 node may use the second leg indication and / or the AMF identifier to create a binding between the WTRU and the TNL association. Selecting a TNL association between the RAN2 node and the AMF and / or creating a binding between the WTRU and the TNL association may be referred to as creating an NGAP WTRU-TNLA-binding during RRC connection setup.

[0242] In an example option of informing AMF1 (e.g., which may be similar to the first option) the WTRU may start a connection to the RAN2 node by sending an access stratum control plane message. The RAN2 node may receive the control plane message. The RAN2 node may be configured to send an NASmessage. The NAS message may be included in the received access stratum control plane message (e.g., to AMF1). The RAN node may create the NGAP WTRU-TNLA-binding. The NAS message may be a registration request message, a service request message, or a (e.g., a new) NAS message. The NAS message may have information that informs AMF1 that the WTRU has established connectivity to RAT2 for an MA PDU session.

[0243] In an example option of informing AMF1 , the WTRU may establish a connection with the RAN2 node. The WTRU may send an access stratum control plane message to a RAN1 node. The access stratum control plane message to the RAN1 node may indicate that the WTRU has established a connection to the RAN2 node and / or that the connection may be used as a second leg. The access stratum control plane message may be a UEAssistancelnformation message. The access stratum control plane message may include second leg assistance information. Second leg assistance information may include at least one of the following: a second leg indication (e.g., which may indicate that the access leg is used as a second leg), and / or a RAN node identifier (e.g., which may help to identify the RAN2 node). A RAN node identifier may include at least one of an NR cell global identifier (NCGI), an NR Cell ID (NCI), a gNB ID, a Physical Cell ID (PCI), and / or a frequency.

[0244] The RAN1 node may (e.g., in response to receiving an indication that the WTRU established a connection to the RAN2 node) send an N2 message to AMF1 . 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 for the RAN2 node. AMF1 may send an N2 MA PDU request to the RAN2 node over 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 .

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

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

[0247] The RAN2 node (e.g., if the RAN2 node may accept the connection for the WTRU) may prepare the access stratum and NAS configuration for the WTRU over RAT2. The RAN2 node may use a transparent container to send the NAS configuration to the RAN1 node. The RAN2 node may create an NGAP WTRU-TNLA-binding for the WTRU based on the TNL association selected by AMF1 . The RAN1 node may forward the transparent container to the WTRU (e.g., in another control plane message using an RRCReconfiguration message).

[0248] The RAN2 node and AMF1 may have one or more TNL associations. The one or more TNL associations may include one or more of the example options of informing AMF1 that the WTRU established connectivity to RAT2 as described herein. The RAN2 node may (e.g., in examples where a TNL association does not exist or where an existing TNL association is not used) select an 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 permitted for AMF2. An (e.g., any) N2 message between the RAN2 node and AMF1 may be sent to AMF2 (e.g., via the selected TNL association). The N2 message may be sent from AMF2 to AMF1 via an N14 reference point. The N14 reference point may be realized by the service based interface of the AMF, denoted by Namf service-based interface.

[0249] Registration may be requested (e.g., required) to a second leg MN (e.g., using a single subscription). In examples, if / when the WTRU requests (e.g., requires) registration over the second access and the WTRU has a single subscription to access both mobile networks, the registration procedure (e.g., for the second leg MN) and / or the WTRU behavior (e.g., when registered to the second leg MN) may be optimized. The WTRU may request (e.g., require) registration over the second access and / or the WTRU may have a single subscription to access both mobile networks if / when the resulting MA PDU session type is 3 or 4 and the WTRU needs to register over the second leg.

[0250] FIG. 10 illustrates an example of registration to a second leg MN. An example of registration to a second leg MN may begin at a point where the WTRU has established a connection to the RAN2 node. In an example, registration to a second leg MN may begin at a point where the WTRU has established a connection to the RAN2 node, which may correspond to 4 in FIG. 3.

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

[0252] An MA PDU session secondary leg (e.g., only) indication may indicate that the registration is (e.g., only) to provide a secondary leg to an MA PDU session. The network may use the secondary leg (e.g., only) indication to limit the network resource usage for the connection.

[0253] The other MN identifier may provide an identifier of MN1 . The MN identifier may be the PLMN ID of MN1.

[0254] The other AMF identifier may provide an identifier of AMF1 . The AMF identifier may be the GUAMI of AMFI .

[0255] A registration validity timer may be a timer indicating how long the registration may be valid and / or requested (e.g., required). MN2 may use the validity timer information to (e.g., implicitly) deregister the WTRU over the MN. The validity timer may apply if / when there is not an ongoing MA PDU session. The WTRU may start the validity timer after the last MA PDU session ends. The WTRU may be deregistered if the validity timer expires without the WTRU starting a new MA PDU session.

[0256] At 2, the RAN2 node may select an AMF. The RAN2 node may use information in the control plane message and / or the registration request message to determine if MN2 is the same as MN1 . The RAN2 node may select AMF1 if MN2 is the same as MN1 . The RAN2 node may select AMF2 if MN2 is different from MN1.

[0257] At 3, the RAN2 node may create an NGAP WTRU-TNLA-binding for the WTRU. The NGAP WTRU-TNLA-binding for the WTRU may be created by selecting a TNL association from the available TNL associations permitted for the initial message for AMF2. The RAN2 node may forward the WTRU message (e.g., registration request) to AMF2. The WTRU message may be forwarded via the selected TNL association.

[0258] At 4, AMF2 may determine whether to accept or reject the registration request. Referring again to 4 in FIG. 10, AMF2 may reject the registration request based on the information included in the request and / or based on the current load in the network. AMF2 may decide that AMF2 does not want to allow WTRUs to register (e.g., decide to prevent WTRUs from registering) if the WTRUs use MN2 as a second leg. AMF2 may decide to prevent WTRUs from registering if there is a high load in MN2, a high load on the access network, and / or a high load in the core network. AMF2 may decide to reject the registration to give priority to its own subscribers. MN2 may have business arrangements with a number of partner MNs. One or more of the arrangements may be more favorable to MN2 (e.g., in terms of pricing). MN2 may decide to reject a registration request if the other MN identifier identifies one of the less favorable MNs.

[0259] At 5, AMF2 may accept the registration request. AMF2 may respond to the WTRU with a registration accept message. The registration accept message may include registration configuration information, including at least one of periodic registrations, mobility registration updates, an inactivity timer, an MN search, and / or registration restrictions.

[0260] A registration accept message may include periodic registrations. Periodic registrations may indicate if the WTRU is to perform periodic registrations over MN2. The registration accept message may include an indication of a periodicity value if the WTRU is to perform periodic registration over MN2.

[0261] A registration accept message may include mobility registration updates. Mobility registration updates may indicate if the WTRU is to perform mobility registration updates. A WTRU may use the second leg without performing registration updates if the WTRU changes registration areas.

[0262] A registration accept message may include an inactivity timer. An inactivity timer may indicate a timer that may be used to (e.g., implicitly) deregister the WTRU from MN2 (e.g., based on inactivity). The timer may be started if / when the WTRU enters a CMJDLE state.

[0263] A registration accept message may include an MN search. An MN search may indicate if a WTRU is to perform a search for better MNs for the second leg of the MA PDU session.

[0264] A registration accept message may include registration restrictions (e.g., conditions). The use of the MN may be restricted to a period of time, to a schedule, for an amount of traffic, and / or for a geographic area. The WTRU may (e.g., only) use the second leg for the configured amount of time, during the configured schedule, for the configured amount of data traffic transferred, and / or if / when in the configured area. The geographic area may be in terms of registration area(s) or a geofence. The WTRU may be provided different restrictions for the uplink and the downlink.

[0265] At 6, the WTRU may receive a registration accept message. The WTRU may follow modified registration behavior for the registration over the second leg.

[0266] In an example modified registration behavior, the WTRU may be configured to not perform mobility registration updates. The WTRU may not send a registration update if / when the WTRU selects a new tracking area (TA) outside the WTRU's registration area.

[0267] In an example modified registration behavior, the WTRU may be configured to not search for higher priority MNs for use as a second leg.

[0268] In an example modified registration behavior, the WTRU may be configured to de-register from MN2 (e.g., based on the registration restriction) or pause the registration to MN2. For example, the WTRU may use MN2 for the configured amount of time.

[0269] Registration may be requested (e.g., required) to a second leg MN (e.g., using a dual subscription). A WTRU may request (e.g., require) registration over the second access. The WTRU may have a dual subscription to access both MNs. The WTRU may determine whether the MNs have a business relationship. The WTRU may follow a (e.g., simplified) MA PDU session behavior if the MNs have a business relationship. The WTRU may follow a (e.g., simplified) MA PDU session behavior if / when the resulting MA PDU session type is 5 or 6, and / or the WTRU needs to register to MN2 to use the second leg in an MA PDU session.

[0270] FIG. 11 illustrates an example architecture of a MUSIM WTRU. The WTRU may be MUSIM capable (e.g., with SIM1 connected to MN1 and SIM2 connected to MN2). An example architecture for a MUSIM capable WTRU is shown in FIG. 11 . The WTRU may have a protocol stack for a USIM (e.g., each USIM). Coordination between the multiple (e.g., two) protocol stacks may be enabled by MUSIM controller functionality. MUSIM controller functionality may have access to the protocol stack of the multiple USIMs. The MA PDU functionality that splits, steers, switches, and / or duplicates traffic across the user plane protocol stacks may be hosted in a common PDU layer. FIG. 11 shows the MA PDU functionality in the PDU layer. MA PDU functionality may (e.g., also) be located above the IP layer.

[0271] In examples of an MA PDU session type 5, MN1 and MN2 may have a business relationship. The 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 the MA PDU operation (e.g., referred to as simplified dual subscription behavior).

[0272] An example procedure may begin after (e.g., once) the WTRU has established a connection to RAN2 node is described herein.

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

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

[0275] An MA PDU session indication may provide an indication that the registration is for an MA PDU session.

[0276] The other MN identifier may be an identifier of MN1 , such as the PLMN ID of MN1 .

[0277] The other AMF identifier may be an identifier of AMF1 , such as the GUAMI of AMF1 .

[0278] A registration validity timer may be a timer indicating how long the registration may be valid and / or requested (e.g., required). MN2 may use the timer information to (e.g., implicitly) deregister the WTRU over the mobile network.

[0279] At 3, the RAN2 node may create an NGAP WTRU-TNLA-binding (e.g., UE-TNLA-binding) for the WTRU. The NGAP WTRU-TNLA-binding for the WTRU may be created by selecting a TNL association from the available TNL associations permitted for the registration message for AMF2. The RAN2 node may forward the WTRU message to the AMF2 via the selected TNL association.

[0280] At 4, AMF2 may determine if MN2 has a business relationship with MN1 . AMF2 may determine whether to accept or reject the registration request. AMF2 may reject the registration request based on information included in the request and / or based on the current load in the network. In examples, AMF2 may decide that it does not want to allow WTRUs to register if the WTRUs use MN2 as a second leg. In examples, MN2 may have business arrangements with one or more (e.g., a number of) partner MNs. One or more of the arrangements may be more favorable to MN2 (e.g., in terms of pricing). MN2 may decide to reject a registration request if the other MN identifier identifies one of the less favorable MNs. If AMF2 determines that MN2 has no business relationship with MN1, AMF2 may determine that the MNs are incompatible and / or AMF2 may reject the registration. In examples, the WTRU may be trying to connect to the same PLMN over the multiple (e.g., two) SIMs. If AMF2 determines that MN2 has no business relationship with MN1 , AMF2 may determine that the MN is not capable of establishing an MA PDU session (e.g., of session type 6).

[0281] At 5, AMF2 may accept the registration request. AMF2 may respond to the WTRU with a registration accept message. The registration accept message may include at least one of the following information: periodic registrations, mobility registration updates, an inactivity timer, an MN search, a registration restriction, or a simplified dual subscription behavior indication.

[0282] Periodic registrations may indicate if the WTRU is to perform periodic registrations over MN2. The registration accept message may (e.g., also) include an indication of the periodicity value (e.g., if the WTRU is to perform periodic registration over MN2).

[0283] Mobility registration updates may indicate if the WTRU is to perform mobility registration updates. A WTRU may use the second leg without performing registration updates (e.g., if the WTRU changes registration areas).

[0284] An inactivity timer may be used to (e.g., implicitly) deregister the WTRU from MN2 (e.g., based on inactivity). The timer may be started if / when the WTRU enters a CMJDLE state.

[0285] A MN search may indicate if the WTRU is to perform a search for (e.g., better) MNs for the second leg of the MA PDU session.

[0286] A registration restriction (e.g., condition) may indicate whether the use of the MN may be restricted by one or more restrictions, such as a certain period of time, to a certain schedule, for a certain amount of traffic, for a certain geographic area, and / or the like. The WTRU may (e.g., only) use the second leg for the configured amount of time, during the configured schedule, for the configured amount of data traffic transferred, and / or the like, for example, if / when the WTRU is in the configured area. The geographic area may be in terms of registration areas or a geofence. The WTRU may be provided different restrictions for the uplink and the downlink.

[0287] Simplified dual subscription behavior may indicate whether MN2 has a business relationship with MN1 . A business relationship may allow the WTRU to follow a simplified MA PDU session behavior (e.g., as described herein).

[0288] At 6, the WTRU may receive the registration accept message. The WTRU may follow a modified registration behavior for the registration over the second leg.

[0289] The WTRU may not know if MN2 and MN1 have a business relationship (e.g., if the WTRU is registered to MN2). The WTRU may be triggered to initiate a registration update procedure. The registration update procedure may determine whether the WTRU may apply the simplified dual subscription behavior.

[0290] An MA PDU session may be established over a second leg. For example, if a WTRU requests (e.g., require) registration over the second access and / or if the WTRU has a dual subscription to access multiple mobile networks, an SMF2 may obtain the MAPS rules.

[0291] If the WTRU has established connectivity over the second leg and / or if the WTRU has performed registration over MN2, the WTRU may establish the MA PDU session over the second leg. Establishing the MA PDU session over the second leg 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 over the second leg.

[0292] An MA PDU session may be established over a second leg with dual subscription and / or a business relationship. Examples described herein may apply if / when the resulting MA PDU session is type 5. MN1 and MN2 may have a business relationship and / or the multiple (e.g., two) mobile networks may (e.g., be assumed to) be able to communicate with each other to facilitate the MA PDU operation (e.g., for MA PDU session type 5).

[0293] At 1 , the MUSIM controller may ask NAS2 to establish an MA PDU session over the second leg. The MUSIM controller may provide at least one of the following: a PDU session ID, the other MN WTRU identifier, or a location ID.

[0294] A PDU session ID may be used to set the PDU session ID for the MA PDU session established over the first leg.

[0295] The other MN WTRU identifier may be the identifier of the WTRU over the first leg. In examples, the identifier may be the SUCI or 5G-GUTI of the WTRU on MN1. The identifier may be requested (e.g., required) if the WTRU has different identities over the multiple (e.g., two) MNs.

[0296] A location ID may help MN2 to select a proper UPF2 (e.g., so that the UPF2 is close to UPF1). The location ID may be in an ID space known by MN1 and MN2 (e.g., as part of a business agreement), or the location ID may be public information. In examples, the location ID may be a private location identifier agreed on between MN1 and MN2 (e.g., a string or a fully qualified domain name (FQDN), a country code, an IPX code, a geographic location, and / or the like). A location ID may be a combination of location IDs.

[0297] If the PDU session ID is (e.g., already) used in PLMN2, the MUSIM controller may determine a new PDU session ID. The MUSIM controller may provide the information to NAS1 and / or NAS2. NAS1 may use the information to tear down the MA PDU session and reestablish the MA PDU session with the new PDU session ID, or modify the PDU session ID of the (e.g., already) established MA PDU session. NAS2 may include the information in the PDU session establishment request.

[0298] At 2, NAS2 may send a PDU session establishment request to SMF2. The WTRU may include the MAPS assistance information. The information may be extended to include the other MN WTRU identifier. The other MN WTRU identifier may be provided by NAS2.

[0299] At 3, SMF2 may determine SMF1 from the other MN WTRU identifier. SMF2 may retrieve the MAPS configuration information from SMF1 (e.g., over an N16 interface).

[0300] At 4, SMF2 may provide the received MAPS configuration information to the WTRU. SMF2 may configure a UPF in MN2 (e.g., referred to as UPF2) to provide connectivity to UPF1 . UPF1 may be the PSA UPF for the MA PDU session in MN1 .

[0301] In examples, SMF2 may (e.g., need to) modify the MAPS configuration received from SMF1 . MN2 may not be able to support a steering mode or steering functionality included in the MAPS configuration. SMF2 may modify the MAPS configuration before providing the MAPS configuration to the WTRU. SMF2 may provide the new MAPS configuration to SMF1. SMF1 may (e.g., in response, need to) reconfigure the MAPS configuration in the PSA UPF.

[0302] An MA PDU session may be established over a second leg with dual subscription without a business relationship. Examples described herein may apply if / when the resulting MA PDU session is type 6. If MN1 and MN2 do not have a business relationship, and / or the multiple (e.g., two) mobile networks do not communicate directly, the WTRU may provide information to SMF2 (e.g., to allow SMF2 to configure UPF2 (e.g., the UPF in MN2 used for the second leg)).

[0303] In a WTRU based alternative, MN1 may provide information to the WTRU and / or the WTRU may forward the information to SMF2.

[0304] At 1 , SMF1 may provide a NAS container to the WTRU (e.g., upon establishing an MA PDU session over MN1). The NAS container may include information about the MA PDU session configured over MN1 . The information about the MA PDU session configured over MN1 may include at least one of an address of PSA UPF in MN1 or MAPS rules for the WTRU. An address of PSA UPF in MN1 may include the IP address or tunnel information for the UPF.

[0305] The NAS container may be provided in a (e.g., new) NAS message, the PDU session establishment accept message, or in a DL NAS TRANSPORT message. The PDU acceptance message may be received if / when establishing the MA PDU session over MN1 .

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

[0307] At 3, the MUSIM controller may include the NAS container received from NAS1 in the request to establish an MA PDU session over MN2.

[0308] At 4, NAS2 may send a PDU session establishment request to SMF2. The request may include the NAS container received from NAS1 .

[0309] At 5, SMF2 may (e.g., upon receiving the NAS container) determine whether to accept the MA PDU establishment request. If the SMF2 determines to accept the MA PDU establishment request, SMF2 may configure a UPF in MN2 (referred to as UPF2) to provide connectivity to UPF1 .

[0310] In an application function (AF) based example, the MNs may use an AF to act as a mediator between the multiple (e.g., two) MNs. For example, MN1 may provide the (e.g., necessary) information to an AF. The AF may forward the information to SMF2.

[0311] At 1 , an SMF1 may (e.g., upon establishing an MA PDU session over MN1) provide the address of the mediator application function to the WTRU. In examples, the SMF1 may provide the address of the mediator application function to NAS1 (e.g., the NAS layer of SIM 1 ).

[0312] At 2, SMF1 may provide the MA PDU session information to the mediator AF (e.g., via the network exposure function). The provided MA PDU session information may include at least one of the following: a WTRU identity, an address of PSA UPF in MN1 , and / or MAPS rules for the WTRU.

[0313] A WTRU identity may be an identity of the WTRU. A WTRU identity may be an (e.g., a new) identifier that is common across MNs.

[0314] An address of the PSA UPF in MN1 may include the IP address or tunnel information for the UPF.

[0315] At 3, the NAS1 layer may provide the address of the AF to the MUSIM controller.

[0316] At 4, the MUSIM controller may include the address of the mediator AF (e.g., in the request to establish an MA PDU session over MN2).

[0317] At 5, NAS2 may send a PDU session establishment request to SMF2. The request may include the address of the mediator AF received from NAS1 .

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

[0319] An MA PDU session may be established by using a linked single access PDU session. A linked single access PDU session may apply if / when the resulting MA PDU session is type 7. MN1 and MN2 may be different mobile networks or the same mobile network. Described herein is an example where MN1 and MN2 are different mobile networks.

[0320] At 1 , upon establishing a MA PDU session over MN1, SMF1 may provide an extended MAPS configuration information. The extended MAPS configuration information may include MAPS configuration information as defined herein. The extended MAPS configuration information may include the address of PSA UPF in MN1 . The address may correspond to the second leg (e.g., referred to herein as PSA UPF second leg address). The address of PSA UPF in MN1 may include the IP address or tunnel information for the UPF, or it may include an IP address: port number. The IP address may allow a WTRU to establish an end-to-end connection to PSA UPF (e.g., over IP connectivity). The extended MAPS configuration information may include a data network name (DNN). A DNN may be set to the data network where the PSA UPF may be accessed. Sending a DNN may be useful if the MNs are part of a private data network providing connectivity between UPFs. The extended MAPS configuration information may include the MAPDU session type. The MA PDU session type may be type 7 (e.g., indicating to the WTRU that the MA PDU session relies on a linked SA PDU session over access leg 2).

[0321] The extended MAPS configuration information may be included in a NAS container from SMF1 . The NAS container may be provided in a (e.g., new) NAS message, in a PDU session establishment accept message (e.g., received if / when establishing the MA PDU session over MN1), or in a DL NAS TRANSPORT message. The NAS container information may be included in an ATSSS rule from SMF1.

[0322] At 2, the WTRU may determine to establish a linked SA PDU session. The triggering of a request to establish a linked SA PDU may come from the PDU layer. The PDU layer may host the MA PDU functionality. The WTRU may initiate a SA PDU session from within the MA PDU session. The WTRU may be configured with a URSP rule that triggers the establishment of the linked SA PDU sessions (referred to herein as the second leg) if / when requested from the PDU layer of the MA PDU session.

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

[0324] At 4 (e.g., upon receiving the SA PDU session establishment request) SMF2 may determine whether to accept the SA PDU session establishment request (e.g., based on the WTRU subscription information, which may indicate support for SA PDU sessions). SMF2 may select a UPF in MN2 (referred to as UPF2) that may be located (e.g., physically, topologically, or latency-wise) close to the PSA UPF. SMF2 may select a UPF using the PSA UPF second leg address or other locator in extended MAPS configuration information to identify a suitable UPF2.

[0325] At 5, SMF2 may send the QoS rules to the WTRU, the QoS profile to the second leg RAN node, and / or the packet detection rules (PDRs) to UPF2. SMF2 may send the selected address to the WTRU (e.g., for example the IP address for the WTRU using SA PDU session).

[0326] At 6, the WTRU may notify SMF1 about the address of the WTRU over the linked SA PDU session (e.g., as received at 5).

[0327] At 7, SMF1 notifies the PSA UPF about the address of the WTRU over the linked SA PDU session. The PSA UPF may use the information to decide whether to accept incoming PDUs. In examples, SMF1 may update the PDRs at the PSA UPF so that traffic from the WTRU over the linked SA PDU session is properly identified. The PSA UPF may use the information to route the traffic received from the WTRU that is identified by the address of the WTRU over the linked SA PDU session, to the PDU layer handling the MA PDU functionality for the WTRU.

[0328] The WTRU may use the MAPS rules to route uplink traffic over the MA PDU session of access leg 1 , or the linked SA PDU session over access leg 2. If / when the WTRU sends a PDU over the secondleg of the MA PDU session, the PDU layer on the WTRU may encapsulate the PDU in an outer MPTCP or MPQUIC PDU that has its destination IP address set to the PSA UPF second leg IP address, and / or the PDU layer on the WTRU may send the outer PDU over access leg 2. At the PSA UPF, the uplink traffic from the multiple (e.g., two) PDU sessions may be combined. The UPF may use the MAPS rules to route downlink traffic over the MA PDU session of access leg 1 or the linked SA PDU session over access leg 2. At the WTRU, the downlink traffic from the two PDU sessions may be combined.

[0329] An MA PDU session may be an ongoing operation. MA PDU sessions type 2-4 may be optimized. A WTRU may use MN2 (e.g., only) to act as a second leg (e.g., for an MA PDU session that is configured as an MA PDU session type 3 or 4). A WTRU may (e.g., for these types) be configured to be paged (e.g., only) over the first leg (e.g., over MN1). If a WTRU is configured to be paged over the first leg, MN2 may not know the location of the WTRU.

[0330] The WTRU may (e.g., be required to) perform an RRC connection over the multiple (e.g., both) access legs (e.g., for MO traffic of the MA PDU session). The RRC connection over the access legs may allow the MNs to know the location of the WTRU. The legs (e.g., N3 and N9 legs) may be updated to reflect the new location of the WTRU.

[0331] The WTRU may be paged (e.g., only) on the primary leg from MN1 (e.g., for MT traffic). The paging request may trigger the WTRU to start an RRC connection over (e.g., both) the access legs. The WTRU may send the paging response message over the first leg. The WTRU may send a (e.g., a new) NAS message over the second leg. The (e.g., new) NAS message may indicate that the second leg may be used for DualSteer and / or ATSSS transmissions.

[0332] In examples, a MA PDU session may be configured as an MA PDU session type 2 or 3. A WTRU may have a single registration.

[0333] The AMF may determine which access leg to use for transmission of NAS messages. The AMF may determine which access leg to use for transmission of NAS messages using at least one of the following options: the AMF may send NAS signaling on a first leg, the AMF may send NAS signaling on a second leg, the AMF may duplicate NAS signaling on both access legs, the AMF may make a determination based on a metric (e.g., the AMF may use the leg with the smallest delay, the largest throughput, highest capacity, and / or the like), based on the RAT type used on the access leg, and / or based on the type of NAS message.

[0334] When the AMF determines which access leg to use for transmission of NAS messages based on the RAT type used on the access leg, the NAS messages may use the access leg of a RAT type. In examples, one or more NAS messages may use RAT types. One or more NAS messages may use a terrestrial RAT type, while other NAS messages may use a satellite RAT type.

[0335] When the AMF determines which access leg to use for transmission of NAS messages based on the type of NAS message, one or more (e.g., some) NAS messages may be sent on a first leg, one or more (e.g., some) NAS messages may be sent on a second leg, and / or one or more (e.g., some) NAS messages may be duplicated on multiple (e.g., both) access legs.

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

[0337] Although the implementations described herein may consider 3GPP specific protocols, it is understood that the implementations described herein are not restricted to this scenario and may be applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR) or 5G specific protocols, it is understood that the solutions described herein are not restricted to this scenario and are applicable to other wireless systems as well.

[0338] The processes described above may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and / or wireless connections) and / or computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, 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 compact disc (CD)-ROM disks, and / or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

Claims1. A wireless transmit / receive unit (WTRU) comprising: a processor configured to: send a multi-access protocol data unit (MA PDU) session establishment request over a first leg to a first network node, wherein the first network node is associated with a first network; receive an MA PDU session establishment response message from the first network node in response to the MA PDU session establishment request, wherein the MA PDU session establishment response message indicates MA PDU session configuration information; determine a second network to use for a second leg; determine that the WTRU should register with the second network based on the MA PDU session configuration information; and send a registration message to a second network node when it is determined that the WTRU should register with the second network, wherein the second network node is associated with the second network.

2. The WTRU of claim 1, wherein the processor is further configured to: send a second MA PDU session establishment request to the second network node using the second leg to establish an MA PDU session over the second leg.

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

4. The WTRU of claim 3, wherein the processor being configured to select the MA PDU session type is based on at least an MA PDU session selection factor.

5. The WTRU of claim 4, wherein the MA PDU session selection factor includes at least one of an existing MA PDU session, an existing connectivity over a Radio Access Technology (RAT), a WTRU capability, a state of the WTRU, a Quality of Service (QoS) characteristic of application traffic, or an indication of the MA PDU session type determined by the first network.

6. The WTRU of 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 a WTRU capability, a WTRU preference, or a network decision.

7. The WTRU of claim 1, wherein the registration message further indicates an identification of the first network or an indication that the registration message is for an MA PDU session associated with the first network.

8. A method performed by a wireless transmit / receive unit (WTRU) comprising: sending a multi-access protocol data unit (MA PDU) session establishment request over a first leg to a first network node, wherein the first network node is associated with a first network; receiving an MA PDU session establishment response message from the first network node in response to the MA PDU session establishment request, wherein the MA PDU session establishment response message indicates MA PDU session configuration information; determining a second network to use for a second leg; determining that the WTRU should register with the second network based on the MA PDU session configuration information; and sending a registration message to a second network node when it is determined that the WTRU should register with the second network, wherein the second network node is associated with the second network.

9. The method of claim 8, wherein the method further comprises: sending a second MA PDU session establishment request to the second network node using the second leg to establish an MA PDU session over the second leg.

10. The method of claim 8, wherein the method further comprises: receiving an MP PDU policy (MAPP), wherein the MAPP indicates one or more MA PDU session types; and selecting an MA PDU session type from the one or more MA PDU session types, wherein the MA PDU session type is associated with an access option, a mobile network option, and a subscription option.11 . The method of claim 10, wherein the method further comprises: selecting the MA PDU session type is based on at least an MA PDU session selection factor.

12. The method of claim 11 , wherein the MA PDU session selection factor includes at least one of an existing MA PDU session, an existing connectivity over a Radio Access Technology (RAT), a WTRU capability, a state of the WTRU, a Quality of Service (QoS) characteristic of application traffic, or an indication of the MA PDU session type determined by the first network.

13. The method of 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 a WTRU capability, a WTRU preference, or a network decision.

14. The method of claim 8, wherein the registration message further indicates an identification of the first network or an indication that the registration message is for an MA PDU session associated with the first network.

Images