CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No.

62/442,317 filed on January 4, 2017; U.S. Provisional Patent Application No. 62/416,499, filed on November 2, 2016; U.S. Provisional Patent Application No. 62/400,810, filed on September 28, 2016; and U.S. Provisional Patent Application No. 62/334,704, filed on May 11, 2016, the contents of all of which being hereby incorporated by reference as if fully set-forth herein in their respective entirety, for all purposes.

BACKGROUND

[0002] Mobile communications 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, procedures, and instrumentalities (e.g., aspects of entities, interfaces and/or procedures in a wireless transmit/receive unit (WTRU) and/or network layers LI, L2, 13) are disclosed for distributed control in wireless systems, such as 5G flexible radio access technology (RAT) (5gFLEX). Example procedures are provided for WTRU and network operation associated with a distributed control plane architecture, connectionless data transfer and/or dedicated system information acquisition. Distributed control may be provided, for example, by replicating a plurality of access control functions (ACFs) using a plurality of instances in a plurality of different transmission/reception points (TRPs) with multi-connectivity. The plurality of TRPs may concurrently provide control services to a WTRU. Centralized control functions may manage core network connectivity and/or a plurality of user plane instances for the WTRU and/or may facilitate coordination between the plurality of ACF instances for the WTRU in the plurality of different TRPs of the WTRU's configuration. For example, there may be a first

access plane between the WTRU and a first TRP that provides a first ACF for the WTRU, a second access plane between the WTRU and a second TRP that provides a second ACF for the WTRU, a RAN central control plane between the WTRU and a first RAN central control function (RCCF) and/or a RAN central user plane between the WTRU and a RAN central user function (RCUF).

[0004] A WTRU may use assistance information for beamformed system information delivery. Assistance information may be determined and/or transmitted.

[0005] A WTRU may determine when to apply and/or activate on-demand system information. A WTRU may determine when to delete and/or deactivate on-demand system information.

[0006] A WTRU may have saved instructions in memory executable by a processor and/or received from a wireless network via a message (e.g., rules) for triggering a system information ("SI") request procedure. A WTRU may also have saved instructions in memory executable by a processor and/or received from a wireless network via a message for performing an SI request, (e.g., using a random access channel "RACH"), and/or msg3 and/or handling of networks.

[0007] A wireless transmit/receive unit (WTRU) may be in communication with a communication network. The WTRU may comprise a memory. The WTRU may comprise a processor. The processor may be configured to determine to request one or more system information (SI) messages from the communication network. The processor may be configured to determine if a transmission of the one or more SI message from the communication network will utilize at least one beamformed communication based on one or more communication parameters. The WTRU may comprise a transceiver. The transceiver may be configured to receive at least one of the one or more SI messages from the communication network via the at least one beamformed communication.

[0008] A wireless transmit/receive unit (WTRU) may be in communication with a communication network. The WTRU may comprise a memory. The WTRU may comprise a processor. The processor may be configured to determine to request one or more system information (SI) messages from the communication network. The processor may be configured to conduct a beam sweep operation of one or more downlink (DL) beams transmitted from the communication network. The processor may be configured to identify at least one DL beam of the one or more DL beams via which to receive the one or more on-demand SI messages based at least in part on the beam sweep operation. The processor may be configured to determine one or more uplink (UL) resources with which to communicate information for the WTRU reception of the one or more on-demand SI messages. The information for the WTRU reception may include

the at least one DL beam. The processor may be configured to initiate the request for the one or more on-demand SI messages from the communication network. The WTRU may comprise a transceiver. The transceiver may be configured to send the request for the one or more on-demand SI messages to the communication network using the one or more UL resources. The request may include the information for the WTRU reception of the one or more on-demand SI messages. The transceiver may be configured to receive at least one of the one or more on-demand SI messages from the communication network via the at least one DL beam.

[0009] A wireless transmit/receive unit (WTRU) may be in communication with a communication network. The WTRU may comprise a memory. The WTRU may comprise a transceiver. The transceiver may be configured to receive system information (SI) from the communication network at a first-time instance. The WTRU may comprise a processor. The processor may be configured to determine a first-reference identifier (ID) that corresponds to at least some of the SI of the first-time instance. The processor may be configured to determine a first-value identifier (ID) that corresponds to the at least some of the SI of the first-time instance. The processor may be configured to associate the first-reference ID and/or the first-value ID with the at least some of the SI of the first-time instance. The processor may be configured to utilize the at least some of the SI of the first-time instance in communication with the communication network. The processor may be configured to search the memory for stored SI of a previous-time instance that is associated with the same first-reference ID of the at least some of the SI of the first-time instance. The processor may be configured to store the at least some of the SI of the first-time instance upon no stored SI of the previous-time instance associated with the same first-reference ID being found. The processor may be configured to replace stored SI of the previous-time instance associated with the same first-reference ID with the at least some of the SI of the first-time instance upon a value ID associated with the stored SI of the previous-time instance associated with the same first-reference ID being different from the first-value ID.

[0010] A wireless transmit/receive unit (WTRU) may be in communication with a communication network. The WTRU may comprise a memory. The WTRU may comprise a processor. The processor may be configured to determine to request other system information (other-SI) from the communication network. The WTRU may be configured to initiate the request for the other-SI from the communication network as part of a Radom Access Channel (RACH) procedure. The WTRU may comprise a transceiver. The transceiver may be configured to transmit a RACH signal. The RACH signal may include the request for the other-SI in a random access preamble of the RACH signal. The processor may be configured to monitor for a message that includes a minimum SI from the communication network for a

predetermined period of time following the transmission of the RACH signal. The processor may be configured to determine if the requested other-SI is included in the message that includes the minimum SI upon a detection of the message that includes the minimum SI. The processor may initiate one or more retransmissions of the RACH signal the message that includes the minimum SI not being detected, and/or the other-SI is determined to not be included in a detected message that includes the minimum SI.

BRIEF DESCRIPTION OF THE DRAWINGS

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

[0012] FIG. IB is a system diagram of an example WTRU that may be used within the communications system illustrated in FIG. 1 A.

[0013] FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A.

[0014] FIG. ID is a system diagram of another example radio access network and another example core network that may be used within the communications system illustrated in FIG. 1 A.

[0015] FIG. IE is a system diagram of another example radio access network and another example core network that may be used within the communications system illustrated in FIG. 1 A.

[0016] FIG. 2 is an example of transmission bandwidths.

[0017] FIG. 3 is an example of flexible spectrum allocation.

[0018] FIG. 4 is an example of types of assistance modes.

[0019] FIG. 5 is an example of tri -plane architecture.

[0020] FIG. 6 is an example of non-overlapping windows for minimum-system information (SI) and other-SI.

[0021] FIG. 7 is an example of overlapping windows for other-SI and minimum-SI.

[0022] FIG. 8A and 8B together illustrate an example of an on-demand SI request in a beamformed context.

DETAILED DESCRIPTION

[0023] A detailed description of illustrative embodiments will now be described with reference to the various Figures. Although this description provides a detailed example of

possible implementations, it should be noted that the details are intended to be examples and in no way limit the scope of the application.

[0024] FIG. 1A is a diagram of 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 system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like.

[0025] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs), e.g., WTRUs, 102a, 102b, 102c, and/or 102d (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105, a core network 106/107/109, 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 may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0026] The communications system 100 may also include a base station 114a and a base station 1 14b. 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 core network 106/107/109, the Internet 1 10, and/or the 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 site controller, an access point (AP), a wireless router, and the like. While the base stations 1 14a, 1 14b are each depicted as a single element, it will be appreciated that the base stations 1 14a, 1 14b may include any number of interconnected base stations and/or network elements.

[0027] The base station 1 14a may be part of the RAN 103/104/105, 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 within a particular geographic region, which may be referred to as a cell (not shown). 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 some embodiments, the base station 114a may include three transceivers, e.g., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

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

[0029] 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 103/104/105 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 Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0030] In another 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 115/116/117 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE- A).

[0031] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, 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.

[0032] 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, and the like. In some embodiments, 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 another 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, 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 core network 106/107/109.

[0033] The RAN 103/104/105 may be in communication with the core network 106/107/109, 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. For example, the core network 106/107/109 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. 1 A, it will be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UTRA radio technology, the core network

106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0034] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or 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 the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.

[0035] 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 1 14b, which may employ an IEEE 802 radio technology.

[0036] FIG. IB is a system diagram of an example WTRU 102. As shown in FIG. IB, the WTRU 102 may include a processor 1 18, 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 other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB or HeNodeB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. IB and described herein.

[0037] 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 Array (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 1 18 may be coupled to the transceiver 120, which may be coupled to the

transmit/receive element 122. While FIG. IB 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.

[0038] 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 115/1 16/1 17. For example, in some embodiments, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another 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 receive RF and/or 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.

[0039] In addition, although the transmit/receive element 122 is depicted in FIG. IB 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 some embodiments, 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 115/116/117.

[0040] 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 UTRA and IEEE 802.11, for example.

[0041] 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).

[0042] 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 one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0043] 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 115/116/117 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 location-determination implementation while remaining consistent with an embodiment.

[0044] 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 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, and the like.

[0045] FIG. 1C is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 1C, the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0046] As shown in FIG. 1C, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0047] The core network 106 shown in FIG. 1C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0048] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 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.

[0049] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0050] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0051] FIG. ID is a system diagram of the RAN 104 and the core network 107 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 core network 107.

[0052] 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 some embodiments, 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 receive wireless signals from, the WTRU 102a.

[0053] 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 uplink (UL) and/or downlink (DL), and the like. As shown in FIG. ID, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0054] The core network 107 shown in FIG. ID may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0055] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S I 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 also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

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

[0057] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 1 10, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0058] The core network 107 may facilitate communications with other networks. For example, the core network 107 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 core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0059] FIG. IE is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 117. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0060] As shown in FIG. IE, the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number

of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In some embodiments, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0061] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication,

authorization, IP host configuration management, and/or mobility management.

[0062] The communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0063] As shown in FIG. IE, the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0064] The MIP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 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 AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 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. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0065] Although not shown in FIG. IE, RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[0066] In view of Figures 1A-1E, and the corresponding description of Figures 1A-1E, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, Node B 140a-c, RNC 142a-b, MSC 146, SGSN 148, MGW 144, CGSN 150, eNode-B 160a-c, MME 162, Serving Gateway 164, PDN Gateway 166, Base Station 180a-c, ASN Gateway 182, AAA 186, MIP-HA 184, and/or Gateway 188, or the like, may be performed by one or more emulation devices (not shown) (e.g., one or more devices configured to emulate one or more, or all, of the functions described herein).

[0067] The one or more emulation devices may be configured to perform the one or more, or all, functions in one or more modalities. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented/deployed as part of a wired and/or wireless 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 one or more emulation devices may perform the one or more, or all, functions while not being implemented/deployed as part of a wired and/or wireless communication network (e.g., such as in a testing scenario in a testing laboratory and/or a non-deployed (e.g. testing) wired and/or wireless communication network, and/or testing performed on one or more deployed components of a wired and/or wireless communication network). The one or more emulation devices may be test equipment.

[0068] Below is a list of abbreviations and acronyms that may be used herein, by way of example and not limitation.

Af Sub-carrier spacing

5gFlex 5G Flexible Radio Access Technology

5gNB 5GFlex NodeB

ACK Acknowledgement

BLER Block Error Rate

BTI Basic TI (in integer multiple of one or more symbol duration)

CB Contention-Based (e.g. access, channel, resource)

CoMP Coordinated Multi-Point transmission/reception

CP Cyclic Prefix

CP-OFDM Conventional OFDM (relying on cyclic prefix)

CQI Channel Quality Indicator

CN Core Network (e.g. LTE packet core)

CRC Cyclic Redundancy Check

CSG Closed Subscriber Group

CSI Channel State Information

D2D Device to Device transmissions (e.g. LTE Sidelink)

DCI Downlink Control Information

DL Downlink

DM-RS Demodulation Reference Signal

DRB Data Radio Bearer

EPC Evolved Packet Core

FBMC Filtered Band Multi-Carrier

FBMC/OQAM A FBMC technique using Offset Quadrature Amplitude Modulation

FDD Frequency Division Duplexing

FDM Frequency Division Multiplexing

ICC Industrial Control and Communications

ICIC Inter-Cell Interference Cancellation

IP Internet Protocol

LAA License Assisted Access

LBT Listen-Before-Talk

LCH Logical Channel

LCP Logical Channel Prioritization

LLC Low Latency Communications

LTE Long Term Evolution e.g. from 3GPP LTE R8 and up

MAC Medium Access Control

NACK Negative ACK

MC MultiCarrier

MCS Modulation and Coding Scheme

MIMO Multiple Input Multiple Output

MTC Machine-Type Communications

NAS Non-Access Stratum

NR New Radio access technology

NR-eNB A network node that may e.g. schedule NR resources

OFDM Orthogonal Frequency-Division Multiplexing

OOB Out-Of-Band (emissions)

cmax Total available UE power in a given TI

PHY Physical Layer

PRACH Physical Random Access Channel

PDU Protocol Data Unit

PER Packet Error Rate

PLMN Public Land Mobile Network

PLR Packet Loss Rate

PSS Primary Synchronization Signal

QoS Quality of Service (from the physical layer perspective)

RAB Radio Access Bearer

RACH Random Access Channel (or procedure)

RAR Random Access Response

RCU Radio access network Central Unit

RF Radio Front end

RNTI Radio Network Temporary Identifier

RRC Radio Resource Control

RRM Radio Resource Management

RS Reference Signal

RTT Round-Trip Time

SCMA Single Carrier Multiple Access

SDU Service Data Unit

SI System Information

SL Sidelink

SOM Spectrum Operation Mode

ss Synchronization Signal

sss Secondary Synchronization Signal

SRB Signaling Radio Bearer

SWG Switching Gap (in a self-contained subframe)

TB Transport Block

TBS Transport Block Size

TDD Time-Division Duplexing

TDM Time-Division Multiplexing

TI Time Interval (in integer multiple of one or more BTI)

TTI Transmission Time Interval (in integer multiple of one or more TI)

TRP Transmission / Reception Point

TRPG Transmission / Reception Point Group

TRx Transceiver

UFMC Universal Filtered MultiCarrier

UF-OFDM Universal Filtered OFDM

UL Uplink

URC Ultra-Reliable Communications

URLLC Ultra-Reliable and Low Latency Communications

Uu Interface between a NR-eNB/TRP (or equivalent) and a UE

V2V Vehicle to vehicle communications

V2X Vehicular communications

WLAN Wireless Local Area Networks and related technologies (IEEE 802.xx domain)

[0069] Systems may manage (e.g., attempt to minimize) the impact of on-demand other-SI broadcast on an uninterested WTRU. Multi-stage RACH may be used for other-SI request. A

WTRU may handle stored SI and/or may operate in a reduced MSI cell.

[0070] Terms New Radio (NR), 5gFLEX and 5G may be used interchangeably. While examples may refer to 3GPP protocols, subject matter described herein is applicable to other wireless systems (e.g., other wireless technologies, communication and/or control procedures). Terms and definitions do not limit the applicability of disclosed subject matter to other definitions, types of signals, configuration procedures and/or logical associations, e.g., between different user data units.

[0071] An air interface, e.g., for a new radio (NR) access technology in a 5G system, may support a variety of use cases, such as improved broadband performance (IBB), Industrial control and communications (ICC) and/or vehicular applications (V2X) and/or Massive Machine-Type Communications (mMTC). Use cases may have associated support in an air interface (e.g., 5G air interface).

[0072] An air interface may support, for example, ultra-low transmission latency (LLC), ultra-reliable transmission (URC) and/or machine-type communications (MTC) operation (including narrowband operation).

[0073] Support for ultra-low transmission latency (LLC) may comprise, for example, air interface latency such as 1ms RTT and/or TTIs between lOOus to 250us. Support may be provided for ultra-low access latency (e.g., time from initial system access until the completion of the transmission of the first user plane data unit). End-to-end (e2e) latency less than 10ms may be supported, for example, for IC and/or V2X.

[0074] Support for ultra-reliable transmission (URC) may comprise, for example, improved transmission reliability, such as 99.999% transmission success and/or service availability.

Support may be provided for mobility speed in the range of 0-500km/h. Packet Loss Ratio of less than lOe-6 may be supported, for example, for IC and/or V2X.

[0075] Support for MTC operation may comprise, for example, air interface support for narrowband operation (e.g. using less than 200 KHz), extended battery life (e.g., up to 15 years of autonomy) and/or minimal communication overhead for small and/or infrequent data transmissions (e.g., low data rate in the range of 1-100kbps with access latency of seconds to hours).

[0076] A 5gFLEX system may be implemented with OFDM and/or other waveforms for uplink and/or downlink. Description of examples herein is non-limiting. Examples are applicable and/or adaptable to other waveforms and wireless technologies.

[0077] OFDM may be used as a signal format for data transmissions, e.g., in LTE and IEEE 802.11. OFDM may efficiently divide spectrum into multiple parallel orthogonal subbands. A (e.g., one or more, or each) subcarrier may be shaped using a rectangular window in the time domain, which may lead to sinc-shaped subcarriers in the frequency domain. OFDMA may rely on (e.g., perfect) frequency synchronization and/or tight management of uplink timing alignment within the duration of the cyclic prefix, for example, to maintain orthogonality between signals and/or to minimize intercarrier interference. Tight synchronization may be difficult, for example, in a system where a WTRU may be simultaneously connected to one or more, or multiple access points. Additional power reduction may be applied to uplink transmissions, for example, to comply with spectral emission requirements for adjacent bands. Fragmented spectrum may be aggregated for WTRU transmissions.

[0078] OFDM (CP-OFDM) performance may be improved, for example, by more stringent RF requirements for implementations, such as operation using a large amount of contiguous spectrum that might not require aggregation. A CP-based OFDM transmission scheme may provide a downlink physical layer for 5G similar to a 4G system with modifications to pilot signal density and/or location.

[0079] 5gFLEX radio access may be characterized by a very high degree of spectrum flexibility that enables deployment in different frequency bands with different characteristics, which may include different duplex arrangements, different and/or variable sizes of available spectrum, such as contiguous and/or non-contiguous spectrum allocations in the same or different bands. 5gFLEX radio access may support variable timing aspects, such as support for one or more, or multiple TTI lengths and/or asynchronous transmissions.

[0080] Multiple duplexing schemes (e.g., TDD, FDD) may be supported. Supplemental downlink operation may be supported, e.g., for FDD operation, for example, using spectrum aggregation. FDD operation may support full-duplex FDD and/or half-duplex FDD operation. DL/UL allocation may be dynamic (e.g., might not be based on a fixed DL/UL frame configuration), e.g., for TDD operation. The length of a DL and/or a UL transmission interval may be set per transmission opportunity.

[0081] A 5G air interface characteristic and/or capability may enable different transmission bandwidths on uplink and/or downlink ranging, e.g., varying between a nominal system bandwidth to a maximum value corresponding to the system bandwidth.

[0082] Single carrier operation may support a variety and/or range of system bandwidths, such as 5, 10, 20, 40, and/or 80 MHz, and/or 160MHz. Nominal bandwidths may have one or more fixed values. Narrowband transmissions (e.g., 0 to 200 KHz) may be supported within the operating bandwidth for MTC devices.

[0083] System bandwidth may refer to the largest portion of spectrum that may be managed by a network for a given carrier. The spectral portion of a carrier that a WTRU minimally supports for cell acquisition, measurements and/or initial access to the network may correspond to the nominal system bandwidth. A WTRU may be configured with a channel bandwidth that

may be within the range of the entire system bandwidth. A WTRU's configured channel bandwidth may or might not include a nominal part of system bandwidth, e.g., as shown in the example in FIG. 2.

[0084] FIG. 2 is an example of transmission bandwidths. Bandwidth flexibility may be achieved, for example, because (e.g., all) applicable sets of RF requirements for a given maximum operating bandwidth in a band may be met without the introduction of additional allowed channel bandwidths for that operating band, e.g., due to the efficient support of baseband filtering of the frequency domain waveform.

[0085] A WTRU's channel bandwidth for single carrier operation may be configured, reconfigured and/or dynamically changed. Spectrum for narrowband transmissions within the nominal system, system and/or configured channel bandwidth may be allocated.

[0086] A 5G air interface physical layer may be band-agnostic and/or may support operation in licensed bands (e.g., below 5 GHz) and/or unlicensed bands (e.g., in the range 5-6 GHz). Listen before talk (LBT) Cat 4 based channel access framework similar to LTE LAA may be supported, e.g., for operation in unlicensed bands.

[0087] Cell-specific and/or WTRU-specific channel bandwidths for arbitrary spectrum block sizes may be scaled and/or managed (e.g., scheduling, addressing of resources, broadcasted signals, measurements, etc.).

[0088] Downlink control channels and signals may support FDM operation. A WTRU may acquire a downlink carrier, for example, by receiving transmissions using (e.g., only) the nominal part of the system bandwidth. For example, a WTRU might not initially receive transmissions covering the entire bandwidth being managed by the network for the concerned carrier.

[0089] Downlink data channels may be allocated over a bandwidth that may or might not correspond to nominal system bandwidth, e.g., without restrictions other than being within a WTRU's configured channel bandwidth. For example, a network may operate a carrier with a 12 MHz system bandwidth using a 5MHz nominal bandwidth allowing devices supporting 5 MHz maximum RF bandwidth to acquire and/or access the system while potentially allocating +10 to -10 MHz of the carrier frequency to other WTRU's supporting up to 20 MHz worth of channel bandwidth.

[0090] FIG. 3 is an example of flexible spectrum allocation. FIG. 3 shows an example of spectrum allocation where different subcarriers may be (e.g., at least conceptually) assigned to different modes of operation (hereafter Spectrum Operation Mode or SOM). Different SOM may be used to fulfill different requirements for different transmissions. A SOM may include and/or be defined based on one or more of a subcarrier spacing, a TTI length and/or one or more reliability aspects (e.g., HARQ processing aspects, secondary control channel). A SOM may be used to refer to a (e.g., specific) waveform and/or may be related to a processing aspect (e.g., in support of co-existence of different waveforms in the same carrier using FDM and/or TDM and/or coexistence of FDD operation in a TDD band (e.g. with support in a TDM manner or similar)).

[0091] A WTRU may be configured to perform transmissions according to one or more SOMs. For example, a SOM may correspond to transmissions that use at least one of the following: a specific TTI duration, a specific initial power level, a specific HARQ processing type, a specific upper bound for successful HARQ reception/transmission, a specific

transmission mode, a specific physical channel (uplink and/or downlink), a specific waveform type and/or even a transmission according to a specific RAT (e.g., LTE and/or according to a 5G transmission technique). A SOM may correspond to a QoS level and/or a related aspect (e.g., maximum/target latency, maximum/target BLER or similar). A SOM may correspond to a spectrum area and/or to a specific control channel and/or aspect thereof (e.g., search space and/or DCI type). For example, a WTRU may be configured with a SOM for a URC type of service, a LLC type of service and/or an MBB type of service. A WTRU may have a configuration for a SOM for system access and/or for transmission/reception of L3 control signaling (e.g., RRC), for example, in a portion of a spectrum associated with a system, such as in a nominal system bandwidth.

[0092] Spectrum aggregation may be supported (e.g., for single carrier operation). A WTRU may support transmission and/or reception of one or more, or multiple transport blocks over contiguous and/or non-contiguous sets of physical resource blocks (PRBs), e.g., within the same operating band. Mapping of a single transport block to separate sets of PRBs may be supported. Support may be provided for simultaneous transmissions associated with different SOM requirements.

[0093] Multicarrier operation may be supported, for example, using contiguous and/or noncontiguous spectrum blocks within the same operating band and/or across two or more operating bands. Support may be provided for aggregation of spectrum blocks using different modes (e.g., FDD and/or TDD) and/or different channel access procedures (e.g., licensed and/or unlicensed band operation below 6 GHz). Support may be provided for procedures that configure, reconfigure and/or dynamically change a WTRU's multicarrier aggregation.

[0094] A scheduling function may be supported in the MAC layer. Support may be provided for one or more, or multiple (e.g., two) scheduling modes, e.g., network-based scheduling (e.g., for tight scheduling in terms of resources, timing and/or transmission parameters of downlink transmissions, and/or uplink transmissions) and/or WTRU-based scheduling (e.g., for more flexibility in terms of timing and/or transmission parameters). Scheduling information for modes may be valid for one or more TTIs.

[0095] Network-based scheduling may enable a network to tightly manage available radio resources assigned to different WTRUs, which may permit optimal sharing of resources.

Dynamic scheduling may be supported.

[0096] WTRU-based scheduling may enable a WTRU to opportunistically access uplink resources with minimal latency on a per-use basis, for example, within a set of shared and/or dedicated uplink resources assigned (e.g., statically and/or dynamically) by the network. Support may be provided for synchronized and/or unsynchronized opportunistic transmissions. Support may be provided for contention-based transmissions and/or contention-free transmissions.

[0097] Support for opportunistic transmissions (scheduled and/or unscheduled) may be provided, for example, to meet ultra-low latency requirements for 5G and/or power saving requirements for mMTC.

[0098] A WTRU may be configured to receive and/or detect one or more system signatures. A system signature may consist of a signal structure using a sequence. A signal may be similar to a synchronization signal, e.g., similar to LTE PSS and/or SSS. A signature may be specific to (e.g., may uniquely identify) a particular node (and/or transmission/reception point (TRP)) within a given area and/or it may be common to a plurality of nodes (and/or TRPs) within an area, which aspect might not be known and/or relevant to a WTRU. A WTRU may determine and/or detect a system signature sequence. A WTRU may determine one or more parameters associated with the system. For example, a WTRU may further derive an index therefrom and/or may use the index to retrieve associated parameters, e.g., within a table, such as an access table. For example, a WTRU may use received power associated with a signature for open-loop power control, e.g., to set an initial transmission power when a WTRU determines that it may access (and/or transmit) using applicable resources of the system. For example, a WTRU may use the timing of a received signature sequence, e.g., to set the timing of a transmission (e.g., a preamble on a PRACH resource) when the WTRU determines that it may access (and/or transmit) using applicable resources of the system.

[0099] A system signature may consist of any type of signal received by a WTRU for one or more purposes described herein.

[0100] A WTRU may be configured with a list of one or more entries. A list may be referred to as an access table. A list may be indexed, e.g., where an (e.g., one or more, or each) entry may be associated with a system signature and/or to a sequence thereof. An access table may provide initial access parameters for one or more areas. An (e.g., one or more, or each) entry may provide one or more parameters necessary for performing an initial access to the system. Parameters may include one or more of a set of one or more random access parameters (e.g., including applicable physical layer resources, such as PRACH resources) in time and/or frequency, initial power level and/or physical layer resources for reception of a response.

Parameters may (e.g., further) include access restrictions (e.g., PLMN identity and/or CSG information). Parameters may (e.g., further) include routing-related information, such as one or more applicable routing areas. An entry may be associated with (and/or indexed by) a system signature. Such entry may be common to a plurality of nodes (and/or TRPs), for example. A WTRU may receive an access table, for example, via a transmission using dedicated resources (e.g., by RRC configuration) and/or by a transmission using broadcast resources. In the latter case, the periodicity of the transmission of an access table may be relatively long (e.g., up to 10240ms), which may be longer than the periodicity of the transmission of a signature (e.g., in the range of 100ms).

[0101] An access table may consist of any type of system information received by a WTRU for one or more purposes described herein.

[0102] 5gFLEX may support one or more forms of association between data available for transmission and/or available resources for uplink transmissions. Multiplexing of data with different QoS requirements within the same transport block may be supported, for example, when multiplexing does not introduce a negative impact to the service with the most stringent QoS requirement and/or does not introduce an unnecessary waste of system resources.

[0103] A Logical Channel (LCH) may represent a logical association between data packets and/or PDUs. An association may be based on data units being associated with the same bearer (similar to legacy), and/or being associated with the same SOM and/or slice (e.g., a processing path using a set of physical resources). For example, an association may be characterized by one or more of a chaining of processing functions, an applicable physical data (and/or control) channel (and/or instance thereof) and/or an instantiation of a protocol stack with one or more of: a specific portion being centralized (e.g., PDCP and/or anything beyond portions of the physical layer processing such as Radio Front (RF) end); and/or another portion being closer to the edge (e.g. MAC/PHY in the TRP and/or RF) potentially separated by a fronthauling interface. The term LCH as used herein may have a different and/or broader meaning than a similar term for LTE systems.

[0104] A WTRU may be configured to determine a relationship between different data units. A relationship may be based on a matching function (e.g., based on the configuration of one or more field values common to data units that are part of the same logical association). Fields may correspond to fields in a protocol header associated with the data unit(s). For example, a matching function may use a tuple of parameters for fields of the IP headers of a data unit, such as IP source/destination address(es), transport protocol source/destination port(s) and/or transport protocol type, IP protocol version (e.g., IPv4 and/or IPv6), etc.

[0105] For example, data units that are part of the same logical association may share a common radio bearer, processing function, SOM and/or may (e.g., at least conceptually) correspond to the same LCH and/or LCG.

[0106] A Logical Channel Group (LCG) may consist of a group of LCH(s) (and/or equivalent as per the definition above), e.g., where a grouping may be based on one or more criteria. Criteria may be, for example, that one or more LCH(s) may have a similar priority level applicable to one or more, or all LCHs of the same LCG and/or may be associated with the same SOM (and/or type thereof), the same slice (and/or type thereof). For example, an association may characterized by one or more of a chaining of processing functions, an applicable physical data (and/or control) channel (and/or instance thereof) and/or instantiation of a protocol stack, which may include one or more of: a specific portion being centralized (e.g., PDCP and/or anything except RF); and/or another portion being closer to the edge (e.g., MAC/PHY in the TRP and/or RF) that may be separated by a fronthauling interface. The term LCG as used herein may have a different and/or broader meaning than a similar term for LTE systems.

[0107] A radio access network (RAN) slice may include (e.g. one or more, or all) radio access network functions and/or transport network functions and/or resources, e.g., radio resources and/or backhaul/fronthaul resources along with core network functions/resources that may be used and/or required to provide end-to-end services to a user. Network functions may, for example, be virtualized on a general purpose processor, run as network functions on specialized hardware and/or split between specialized hardware and general purpose hardware. A PLMN may consist of one or more network slices. A slice may be equivalent to an operator's single, common and/or general purpose network. A RAN slice may consist of one or more SOMs that may be optimized to support various services that the RAN slice may have to offer.

[0108] For example, WTRUs served within a slice may have, for example, one or more of the following aspects in common: services and/or QoE requirements (e.g. ULLRC, eMBB, MMTC); WTRU categories (e.g., CAT 0 to M and beyond, additional categories may be defined for >6GHz to differentiate beamforming capability); coverage requirements (e.g., normal

coverage, enhanced coverage); PLMN/Operators; support for specific Uu interface (e.g., LTE, LTE-Evo, 5G below 6Ghz, 5G above 6Ghz, Unlicensed); and/or served by same core network slice. The terms "RAN slice" and "slice" may be used interchangeably.

[0109] A Transport Channel (TrCH) may include one or more sets (e.g., a specific set) of processing steps and/or a specific set of functions applied to data information that may affect one or more transmission characteristics over a radio interface.

[0110] LTE may define one or more, or multiple types of TrCH, such as the Broadcast Channel (BCH), the Paging Channel (PCH), the Downlink Shared Channel (DL-SCH), the Multicast Channel (MCH), the Uplink Shared Channel (UL-SCH) and/or the Random Access Channel (which might not carry user plane data). Transport channels for carrying user plane data may include the DL-SCH and/or the UL-SCH for the downlink and for the uplink, respectively.

[0111] An augmented set of requirements may be supported by an air interface for a 5G system. Support may be provided for one or more, or multiple transport channels, e.g., for user and/or control plane data, for one or more WTRU devices. The term TrCH as used herein may have a different and/or broader meaning than a similar term for LTE systems. For example, a transport channel for URLLC (e.g., URLLCH), for mobile broadband (MBBCH) and/or for machine type communications (MTCCH) may be defined for downlink transmission (e.g., DL-URLLCH, DL-MBBCH and/or DL-MTCCH) and/or for uplink transmissions (e.g., UL-URLLCH, UL-MBBCH and/or UL-MTCCH).

[0112] For example, one or more, or multiple TrCH may be mapped to a different set of physical resources (e.g., PhCH) belonging to the same SOM. This may be advantageous, for example, to support simultaneous transmission of traffic with different requirements over the same SOM. An example of this may be transmitting a URLLCH along MTCCH simultaneously when a WTRU is configured with a single SOM.

[0113] A WTRU may be configured with one or more parameters associated with a characterization of how data should be transmitted. A characterization may represent constraints and/or requirements that a WTRU may be expected to meet and/or enforce. A WTRU may perform different operations and/or adjust its behavior as a function of the state associated with the data based on a characterization. Parameters may include, for example, time-related aspects (e.g., Time to Live (TTL) - for a packet, which represents the time before which the packet should be transmitted to meet, acknowledged, etc. to meet latency requirements), rate-related aspects and/or configuration related aspects (e.g., absolute priority). Parameters may (e.g., also) be changed with time while a packet and/or data may be pending for transmission.

[0114] A WTRU may be connected to TRPs, e.g., in standalone mode and/or assisted mode. A group of cells that requires assistance may be referred to as an assisted layer. A group of cells that provides the assistance may be referred to as an assistance layer.

[0115] FIG. 4 is an example of different types of assistance layers, using example WTRUs 401-408. Examples of assistance modes may include, for example one or more of: a WTRU 401 connected to 5Gflex small cell in below-6Ghz band assisted by 5Gflex macro cell in sub-6Ghz band; a WTRU 402 connected to 5Gflex small cell in below-6Ghz band assisted by LTE-Evo macro cell; a WTRU 403 connected to 5Gflex small cell in above-6Ghz band assisted by 5Gflex macro cell in sub-6Ghz band; a WTRU 404 connected to 5Gflex small cell in above-6Ghz band assisted by LTE-Evo macro cell; a WTRU 405 connected to 5Gflex small cell in above-6Ghz band assisted by 5Gflex small cell in below-6Ghz band; a WTRU 407 connected to 5Gflex small cell in below-6Ghz band in standalone mode; a WTRU 406 connected to 5Gflex macro cell in above-6Ghz band in standalone mode and/or a WTRU 408 connected to 5Gflex small cell in above-6Ghz band in standalone mode.

[0116] Deployment scenarios may be supported by one or more procedures described herein. For example, a deployment scenario may be LTE-assisted 5gFLEX Aggregation

(DC/CA/Offload). A WTRU may be configured, for example, using an LTE Control Plane (e.g., with an LTE RRC connection) using an LTE User Plane (e.g., with one or more LTE Uu interfaces). A WTRU may be (e.g., further) configured (e.g., by reception of access table(s) from broadcast and/or dedicated signaling) to operate with one or more additional 5gFLEX Uu(s), for example, using the principles of LTE DC, LTE CA and/or LTE-WLAN offload.

[0117] An example of a deployment scenario may be LTE-assisted 5gFLEX Transport Channel(s) (LTE CP, LTE UP, LTE Uu with one or more 5gFLEX TrCH/Physical channels plugged into LTE Uu). A WTRU may be configured for LTE Uu operation (e.g., using LTE procedure(s)). A WTRU may be (e.g., further) configured with one or more physical layer (e.g. control and/or data) channels for a 5gFLEX Uu of the WTRU's configuration. Downlink (DL) physical channels may co-exist in the DL carrier and/or frequency band. An uplink (UL) carrier may (e.g., also) be common or separate. Cell-specific LTE signals/channels may be viewed as "holes" in the 5gFLEX map of physical layer resources, for example, from the perspective of a WTRU configured with one or more 5gFLEX physical channels.

[0118] An example of a deployment scenario may be LTE-based Stand-alone 5gFLEX operation (LTE CP, LTE L2 at least in part, 5gFLEX PHY). A WTRU may be configured with one or more (e.g., many, most or one or more, or all) of the components of an LTE control plane (e.g., RRC connection, security, etc.) and/or the LTE user plane (e.g., EPS RABs, PDCP, RLC).

A WTRU may be (e.g., further) configured with one or more 5G MAC instance(s). An (e.g., one or more, or each) instance may have one or more 5gFLEX Uu(s). Stated somewhat differently, for example, a WTRU might not be configured with an LTE PCell.

[0119] For example, a deployment scenario may be Stand-alone 5gFLEX operation. A WTRU may be configured with a 5G control plane and/or a 5G user plane. 5gFLEX Uu operation may be supported.

[0120] WTRU states may be modeled. The terms "state" and "mode" may be used interchangeably. Aspects of this disclosure may be applicable independent of state. Some aspects may be applicable for more than one state. Some aspects described herein may be applicable whether or not such states are actually defined.

[0121] A WTRU may operate according to at least one of the following states and/or similar: idle mode, light connected/loosely connected/inactive mode, and/or connected, fully

connected/active mode.

[0122] In WTRU idle mode, from the network's perspective, the WTRU might not have a context with the radio access network ("RAN"). For example, in a distributed architecture, a WTRU might not have context at the edge control function and/or the central control function. From the WTRU's perspective in idle mode, the WTRU may monitor paging from the core network (e.g., at a well-defined DRX cycle). The WTRU may perform measurements and/or autonomous mobility. The WTRU may acquire, store, and/or apply system information valid for at least idle mode operations.

[0123] In WTRU light connected/loosely connected/inactive mode, from the network's perspective, there may exist a WTRU context stored in the RAN. There may also exist a RAN-core connection for the WTRU. For example, in a distributed architecture, a WTRU may have context established at the central control function with limited and/or no context at the edge control function. The WTRU may be tracked (e.g., at a granularity of a logical area greater than or equal to a cell). The WTRU may be reached by the RAN via paging messages that originates in the RAN (e.g., at DRX cycles specific to the light connected state). From the WTRU's perspective, a WTRU might not have an active and/or established connection to the RAN.

Mobility in light connected state may be WTRU controlled. A WTRU may move within a logical area without notifying the network. A WTRU may notify the network when the WTRU determines that the WTRU has moved outside a logical area (e.g., the WTRU would fail to detect the signature/reference signal and/or another property that identifies the concerned area) and/or across a boundary between two different logical areas (e.g., the WTRU would detect a different identity for the current area). Mobility in light connected state may also be network controlled (e.g., to enable handover when data transfer is allowed and/or ongoing).

[0124] In the connected/fully connected/active mode, from the network's perspective, the WTRU may have connectivity with the network (e.g., the WTRU context may be established at the radio access network, and/or WTRU specific connection may be established between RAN and core network). For example, in a distributed architecture, a WTRU may have context established at a central control function and/or one or more edge control functions. A WTRU may have at least one user plane function/component established. WTRU mobility may be tracked at the cell level and/or may be WTRU assisted, network controlled mobility. Network configured WTRU controlled mobility may be used.

[0125] The states described may represent a standalone/independent state, with transition logic in between. Some of the states may have relationships to each other. For example, some states may be functional elements of another state (e.g., where transition between sub-states might not imply significantly different RRC function and/or trigger RRC behavior). For example, a connectionless transfer may be a sub-state and/or an access method for a WTRU in idle or light connected state. In another example, the light connected state may be a RAN controlled state.

[0126] WTRU control aspects may include procedures enabling configuration and/or coherent operation for one or more of the following aspects: a plurality of radio "layers"; a plurality of radio access technologies (e.g., NR, LTE, Wifi, etc.); a plurality of L2 transport and/or user plane components, which may be realized using different network slices and/or sets of physical resources; and/or enhanced connectivity principles such as loosely connected state.

[0127] In the broadcast transmission of on-demand other-SI, the notification of presence of other-SI and/or scheduling indication of other-SI may trigger a reception procedure (e.g., unnecessary) for the WTRUs that are uninterested in the other-SI. Trigger reception procedures in uninterested WTRU's may be energy inefficient.

[0128] Although examples describe procedures, features and elements in particular combinations, the disclosed subject matter encompasses implementation of one or more, or each procedure, feature and/or element in whole or in part, individually or in any combination with and without other procedures, features and/or elements disclosed herein or known.

[0129] A transmission/reception point (TRP) may support, for example, one or more of the following access procedures: LTE/LTE-A/LTE-Evo air interface, an NR access (e.g. based on a flexible 5G air interface and/or similar), a beamformed interface for higher frequencies, a non-3GPP access (e.g. 802.11 family such as WiFi), License Assisted Access (LAA), a narrow band air interface and/or similar. TRP, eNB/NR-eNB, access point, base station and/or the like may be used interchangeably.

[0130] A WTRU may be connected in a number of different manners with a radio system. For example, a WTRU may be configured for transmission to/from one or more TRPs. One or more, or multiple transmissions may be transmitted and/or received concurrently. A WTRU may (e.g. further) be configured for transmissions that may be characterized by varying levels of diversity/reliability, mobility robustness, differentiation in terms of services, etc. Higher level services may involve, for example, the configuration of a plurality of TRPs to achieve service levels. For example, one or more TRPs may support (e.g. only) narrow band transmissions, one or more TRPs may provide best effort offload, one or more TRPs may provide less overhead (e.g. specific signatures, preconfigured bearer), etc. A WTRU may be agnostic to the identity of a TRP and/or the number of TRPs, for example, even when configured with one or more, or multiple TRPs. For example, transmissions to/from different TRPs may be differentiated, for example, based on applicable reference signals (RS), control channels, timing and/or operating carrier/frequencies.

[0131] A distributed approach may be implemented for control plane modeling. A control plane in previous generations of wireless systems (e.g. LTE) may have a suite of protocols (e.g. RRC and/or NAS) use a very centralized and/or monolithic approach, e.g., from a WTRU perspective. A centralized approach may be difficult to scale for next generation systems that may require support for and/or coordination between differentiated services (e.g. very low latency services), multi-connectivity, a larger number of small cells for a given WTRU.

[0132] Distribution of (e.g. certain) functions, for example, towards the edge of a RAN (e.g. in or close to a TRP) may provide a more scalable approach for an NR system. Furthermore, increased isolation between different user plane processing paths (e.g. similar to bearers in EPC/LTE) may facilitate differentiated QoS, management of multi-path bearers (and/or similar) as well as differentiated allocation of network resources in a system and/or (e.g. potentially) sharing of network resources between operators.

[0133] Example procedures disclosed herein may enable a WTRU to be configured with plurality of user plane functions and/or processing paths according to diverse service requirements with support for diverse device types, deployment scenarios and/or other requirements in an NR system. For example, procedures disclosed herein may enable a control plane entity to establish, maintain and/or tear down service specific user plane components as useful, e.g., using a distributed model.

[0134] A separation and protocol/functional split may be provided. A distributed control plane may be modeled, for example, to enable a number of control functions to operate close to the edge of the system. The functions may be replicated, for example, using a number of instances (e.g. in different TRPs with multi-connectivity). Some functions may be centralized (e.g. to manage core network connectivity and/or user plane instances). Consequently, there may be one or more, or multiple different termination points in the access network that concurrently provide control services for a given WTRU. A WTRU may support a

multiplexing/demultiplexing function (e.g. different sets of one or more SRBs) associated with one or more (e.g. specific) control plane contexts/instances/functions and/or a set thereof. A control plane model may (e.g. also) support one or more control plane functions to operate concurrently and/or in parallel, e.g., for functions logically closer to the edge. Centralizing one or more control plane functions may enable and/or facilitate coordination between different control plane instances of the same WTRUs, e.g., coordination between different TRPs of a WTRU's configuration.

[0135] Control plane/user plane (CP/UP) separation may be modeled in a variety of different ways. There may be a variety of potential axes for separation of the different components of a control plane.

[0136] For example, vertical isolation may be provided in a protocol stack (CP and/or UP). Different options may be based on depth of separation. For example, in a partial separation and/or split approach, CP/UP specific higher layers may be followed by one or more common lower layers. For example, in a complete separation, an independent protocol stack may be provided, e.g., all the way down to Ll/PHY. For example, an optimized PHY channel design and/or different DCI/grant level may be provided. A different Spectral Operating Mode/signal structure may be provided.

[0137] For example, horizontal separation may be provided between instances of a (e.g. potentially different) protocol stack. A control plane instance may operate on a user plane instance. A protocol stack may be separated, e.g., by an interface between a central unit (CU) and a remote unit (RU). Functional splits may be based on one or more of the following, for example: transport network profile (e.g. fronthaul and/or backhaul bandwidth, latency, jitter, etc.); specific deployment scenarios; type of service (e.g. eMBB services may utilize centralized processing for cost savings and/or URLLC services may utilize distributed processing to minimize latency); resource availability (e.g. processing resource, specialized hardware); vendor interoperability; and/or dynamic changes to transport network capacity (e.g. when the transport network is shared with one or more, or multiple TRPs and/or operators).

[0138] For example, physical and/or access separation may be provided. Uu termination may be provided for control and/or user plane at different nodes in the RAN (e.g. assisted layer and/or different TRP). For example, CP termination may be at LTE-Evo eNB and/or UP termination may be at NG TRP/RCU, e.g., in assisted mode. For example, an L2 transport and/or termination point for CP may be different from UP, e.g., in standalone mode. For example, an L2 transport and/or termination point for CP may be any TRP while for UP it may be using a restricted set of TRPs, e.g., in standalone mode.

[0139] Modeling described herein may support any of the foregoing separation models and/or other models, alone or in combination. For example, modeling may facilitate having a control plane component and its associated user plane in different RAN slices. Slices may be realized, for example, by physical and/or vertical separation. For example, a multi-plane architecture may support a combination of horizontal separation and/or vertical isolation.

[0140] Examples of elements and/or characteristics may be provided for a distributed control plane architecture.

[0141] A high level generalization (e.g. a conceptual view) of a control plane may be as a set of one or more control function(s). A control function may include processing actions and/or related parameters. Examples of control functions are described herein. A control function may apply to one or more component(s) of a WTRU.

[0142] Components may include, for example, a protocol (e.g. NAS, RRC, PDCP, RLC, MAC, PHY, etc.) and/or a corresponding entity, an implementation aspect (e.g. a power control function, a state of a WTRU, etc.), a set of resources (e.g. a data transport path, a bearer, etc.) and/or a combination thereof (e.g. a set of physical/processing resources, a slice, etc.). Examples of component combinations are described herein.

[0143] A control functions may be characterized as being applicable, for example, according to one or more of the following: a WTRU-specific function; a component-specific function; and/or a plural-component function.

[0144] A WTRU-specific function, for example, such as a control function may be applicable to any aspect(s) and/or component(s) of a WTRU. For example, a function that controls a WTRU' s connectivity to a core network (e.g. in terms of access credentials) may be WTRU-specific. A function may (e.g. from a network perspective) be centralized in a node that supports connectivity to a plurality of TRPs/NR-eNBs. For example, a function may be logically part of a RAN Central Control Function (RCCF), e.g., described below.

[0145] A component-specific function, for example, such as a control function may be applicable to one or more aspects of a WTRU. An aspect may be, for example: a MAC instance;

a signature-specific aspect (e.g. a configuration corresponding to a signature); a TRP-specific aspect (e.g. a configuration corresponding to a TRP; a TRPG-specific aspect (e.g. a configuration corresponding to a TRPG); an LCH (and/or equivalent)-specific aspect (e.g. a configuration corresponding to an LCH); an instance of a component combination (e.g. a bearer, a flow such as a sequence of packets identified by a matching rule (e.g. a tuple, etc.), for example, as described herein; a slice specific aspect (e.g. a configuration) corresponding to a RAN slice and/or a core network slice and/or to an end-to-end network slice (e.g. a core network slice, a slice selection function and/or one or more RAN functions); a spectral operating mode (e.g. a configuration) corresponding to a spectral operating mode, and/or other examples. For example, a WTRU may apply a received configuration to a specific time/frequency resource while using a different configuration for other time/frequency resources in the system.

[0146] For example, a function may be logically part of an Access Control Function (ACF), e.g., for a function dedicated to connectivity to a single TRP/NR-eNB, which may include configuration for a MAC instance and/or physical layer parameters (e.g. single or multiple cells/carriers) for a given WTRU.

[0147] In a plural-component function, for example a control function may be applicable to a plurality of components of a WTRU. For example, a function may be logically part of an Access Control Function (ACF) for a function that may control connectivity for a TRPG and/or for one or more NR-eNB(s), which may include configuration for a single MAC instance (e.g. COMP) and/or for one or more, or multiple MAC instances (e.g. for multi-connectivity) and/or (e.g. required) physical layer parameters for a given WTRU. This may, for example, further include coordination and/or configuration aspects for a WTRU to handle, e.g., with reception of one or more, or multiple responses to a random access within a TRPG, if applicable, for single TRP selection and/or for multiple TRP selection (e.g. for aggregation and/or multiple connectivity).

[0148] Examples may be provided for some (e.g. most) applicable control plane functions, e.g., individually. A function may be described with reference to its applicability to these non-limiting characterizations.

[0149] High-level modeling of a control plane for NR may be provided. Functions and/or components may, for example, be logically grouped.

[0150] A multi-plane architecture may be provided. For example, functions and/or components supporting an NR system may be logically grouped, for example, in terms of an Access Plane (AP), a Central Control Plane (CCP) and/or a Central User Plane (CUP). A description of example realizations of user plane components is described herein.

[0151] Logical grouping of functions may enable different components and/or functions of a system to be isolated from each other. Isolation may (e.g. further) enable components and/or functions to be controlled, configured, modified and/or operated separately from each other. Separation may be applied for components and/or functions associated with a specific WTRU, per TRP/NR-eNB, per TRPG, per TRPGs, per group of NR-eNBs, per LCH (and/or equivalent), per slice, etc. Separation between centralized and access-related grouping may enable coordination between different instances of a function (e.g. system information provisioning, bearer configuration and/or equivalent) and/or between different instances of different functions (e.g. core network connectivity and/or user plane/bearer instances).

[0152] FIG. 5 is an example of logical grouping. There may be an architectural aspect and/or approach to a functional split. For example, FIG. 5 shows an example of a tri-plane architecture.

[0153] Different principles for a functional split between an access control plane and a central control plane may be considered.

[0154] For example, there may be a single access plane per RAT and/or central control per one or more, or multiple RATs. For example, an access control plane may include control functions specific to the access technology (e.g. beamforming control function, control function specific to LTE, non-3GPP control function, etc.). A central control plane may include control functions that are agonistic to an air interface. A common central control plane may be associated with one or more, or multiple TRPs with diverse access technologies, for example, for LTE/LTE-A/LTE-Evo air interface, a flexible 5G air interface, a beamformed air interface for higher frequencies, a non-3GPP access (e.g. 802.1 1 family such as WiFi), License assisted access (LAA), a narrow band air interface, etc.

[0155] For example, there may be one access plane per TRP/cell and/or central control per one or more, or multiple TRPs. For example, an access control plane may include control functions specific to a TRP/cell. A central control plane may include control functions applicable to more than one TRP. This approach may simplify inter-TRP coordination for efficient radio resource management, RAN mobility management and/or self-organizing functions, etc. A central control plane may (e.g. in one or more cases) lead to cost effective deployments, for example, as it might not require additional interface between TRPs.

[0156] For example, an access control plane may be responsible for establishment, maintenance and/or release of a layer 1/layer 2 (Ll/2) connection, allocation of a temporary identifier to identify a WTRU uniquely within a TRP, common and/or dedicated LI and/or L2 resource configuration specific to a TRP, etc. A central control plane may be responsible for configuring L3 signaling flows and/or abstraction thereof (e.g. signaling radio bearers), configuration of higher layer data flows and/or abstraction thereof (e.g. data radio bearers), security functions (e.g. may include key management), radio resource configuration (e.g. may be common across two or more TRPs), mobility functions (e.g. may include WTRU measurement control), handover control, context transfer, paging, etc.

[0157] QoS management functions may be controlled by a central control plane and/or may be enforced by an access control plane. QoS management functions may be part of a user plane control function, if applicable.

[0158] A system information broadcast function may be shared between an access control plane and a central control plane. For example, an access control plane may be responsible for scheduling and/or transmission of TRP specific system information related to accessibility, physical channel configuration, SC-PTM configuration, etc. An access control plane may be responsible for transmission of MIB and/or for handling dedicated system information procedure.

[0159] A central control plane may, for example, determine the contents of system information for cell (re)-selection information, intra-frequency, inter-frequency and/or inter-RAT neighbor information, MBMS information, side link information etc. Common and/or shared channel related configuration may be coordinated between the access control plane and central control plane. For example, a configuration for layer 2 RAN functions located in TRPs may be configured and/or controlled by the access control plane (e.g. for MAC, physical layer) while layer 2 RAN functions placed in the central user plane entity may be configured and/or controlled by the central control plane (e.g. for PDCP, RLC, bearers and/or similar and/or access table for a TRPG, if applicable).

[0160] A service/QoS-based functional location may be provided for a function in an access plane and/or a control plane. For example, control functions that may be time sensitive with a strict deadline may be placed in TRPs while other control functions may be placed in the central control plane. This approach may relax latency requirements on the fronthaul interface between the central unit and the TRPs and/or may enable cost efficient deployments.

[0161] Another example of a functional split may be applied, for example, when RAN level slicing is supported. For example, control functions that are common across two or more slices may be placed in the central control plane while control functions that are specific to a slice may be placed in the access control plane. In this approach, mobility control, WTRU context handling, etc. may be a part of a central control plane while the access control plane may include slice specific system information broadcast, slice specific authentication and/or security management, and/or slice specific QoS enforcement, etc.

[0162] A WTRU may be able to determine how to exchange signaling with different endpoints and/or with specific instances of a function, for example, based on these modeling examples. Such may be realized using different multiplexing procedures such as those described herein.

[0163] Access control functions (e.g. from the perspective of an overall RAN architecture) may be (e.g. conceptually) defined as set of logical functions, parameters and/or procedures that enable a WTRU to be uniquely addressed and/or identified by one or more TRPs. A WTRU may (e.g. further) generate and/or exchange data and/or signaling with those TRPs. Access control functions may provide distributed/edge control and/or user plane functions that may be specific to a TRP and WTRU pair. An (e.g. one or more, or each) access control function may be associated with a scheduler instance controlling one or more TRPs (e.g. over ideal backhaul). Such function may be part of a radio resource control protocol (e.g. RRC). Such function may be performed by a RRC entity e.g. located in a TRP. A WTRU may (e.g. from the WTRU perspective) be configured to associate a specific signaling bearer and/or equivalent (e.g. a transport path/procedure) for control of a MAC entity with the concerned MAC entity. The function may be part of a Medium Access Control (e.g. MAC) protocol. This function may be performed by a MAC entity. The Access Plane function may use transport services of MAC protocols (e.g. as MAC Control Elements, as MAC Control PDUs, and/or similar), for example, when the MAC entity perform the functions associated to the Access Plane.

[0164] An access plane may be considered to be established, for example, when a WTRU may be uniquely identified by access control functions. An access plane may be established, for example, when a WTRU can start transmission of user plane data. An access plane may be established, for example, when a WTRU receives a response that configures a capability for the WTRU to start performing (receiving and/or transmitting) dedicated transmissions, which may include when security is activated (if applicable) for the concerned configuration.

[0165] High level scoping of an access plane may be performed. For example, a WTRU may be configured to access resources associated with one or more radio access network nodes (e.g. TRP(s), TRPG(s) and/or NR-eNB(s)) using one or more of a set of functions, parameters and/or procedures.

[0166] For example, such procedures may include capabilities for a WTRU to perform an initial access (e.g. to establish access plane connectivity), perform a random access procedure and/or similar, for example, to obtain uplink timing alignment and/or further resources for uplink transmission, to select a suitable network node (e.g. based on measurements of downlink signals and/or based on reception of one or more responses to the initial request such as one or more RARs), to obtain a unique identifier (e.g. a dedicated RNTI), to obtain a configuration (e.g. for physical layer operation), to enable transmission of control signaling (e.g. a signaling radio bearer and/or equivalent) and/or to establish a Uu interface and/or equivalent with a

corresponding network node.

[0167] An access plane may terminate a control signaling protocol. An access plane may be provided for component-specific applicability. For example, an access plane may control aspects related to (e.g. at most) an (e.g. one) access network node. For example, an access plane may provide services for control and/or configuration of a physical layer and/or configuration of a MAC instance associated with a (e.g. one) TRP/NR-eNB. Coordination between one or more, or multiple access nodes might not be assumed and/or useful, for example, in this case.

[0168] An access plane may be provided for plural-component applicability. For example, an access plane may control aspects related to one or more access nodes. For example, an access plane may provide services for control and/or configuration for a physical layer for one or more cells and/or configuration of a MAC instance, where (e.g. potentially) one or more, or each may be associated with applicable TRPs/NR-eNBs. For example, an access plane may support coordination of one or more aspects between different network nodes. Coordination may be per TRPG, per area, per signature and/or per set of access parameters. Coordination may be provided, for example, using a (e.g. single) MAC entity (e.g. with a coordinated scheduling function such as carrier aggregation-like assuming ideal interfaces) and/or by a control function that may interface with a WTRU for the configuration of one or more, or multiple MAC instances, e.g., when applicable (e.g. a multi-connectivity approach).

[0169] A central control plane (e.g. a RAN control plane) may be provided. RAN Central Control Functions (RCCF) may include control functions, protocols and/or context that may be WTRU specific and/or applicable to one or more TRPs/ACFs. A central control plane may be considered as an anchor control function that may terminate a control interface towards the core network (e.g. through configuration/setup of routing paths and transport paths, for example, based on tuples configured for a WTRU). An RCCF may (e.g. additionally) include control functions related to selection of a core network slice, CN-RAN interfaces, QoS management, security (e.g. master key management and/or key derivation, which may be per group of TRPs/NR-eNBs), WTRU capability management and/or WTRU reachability within RAN.

[0170] WTRU context may be setup at RCCF (e.g. after CORE/NAS interaction). From RCCF point of view: a WTRU (e.g. from RCCF perspective) may have a known TRP(G) granularity (e.g. when access plane is active).

[0171] Central User Plane control functions may be (e.g. conceptually) defined as set of logical functions, parameters and/or procedures that may enable a WTRU to transfer user plane data with a network. Functions may be applicable to one of more user plane components (e.g. bearers, L2 transport path, flow-based routing entry, slice instance managing such, etc.). One or more functions may be part of the set of central control plane functions and/or may be logically separated therefrom.

[0172] Signaling may be generated and/or exchanged with one or more TRPs that may be part of a concerned user plane component. Central user plane functions may provide control for aspects that may be specific to a service, a slice, a bearer and/or a set of processing steps configured for the transport of one or more (e.g. specific) flows, which may be determined by configured tuples. A (e.g. one or more, or each) control function may be associated with a scheduler instance controlling one or more TRPs (e.g. over ideal backhaul). A WTRU (e.g. from its own perspective) may be configured to associate a specific central user plane instance with a signaling bearer and/or equivalent (e.g. a transport path/procedure) for control of a user plane component with one (e.g. single path/Uu) or more (e.g. multi-path/Uu) applicable MAC entities. A function may use transport services of corresponding MAC protocols, for example, as MAC Control Elements and/or similar.

[0173] An efficient data path may be setup between a TRP and a RAN Central User Function (RCUF) and/or between different RCUFs, e.g., when applicable. Connection oriented and/or connection-less user plane (e.g. WTRU assisted packet-based routing) may be supported.

[0174] RAN central user plane functions may comprise, for example, functions, protocols and/or parameters that may be service and/or data traffic specific.

[0175] There may be interactions between different control functions and components. A timing relation between access plane establishment and central control plane establishment may, for example, depend on a WTRU state. For example, a WTRU in a passive or IDLE state may transition to connected state by (e.g. first) establishing an access plane, e.g., using control signaling interaction with one or more access control functions (ACFs). For example, an access plane may be established as a result of an association procedure between a WTRU and a network. A WTRU may (e.g. then) trigger central control plane establishment, for example, using control signaling interaction with one or more central control functions. For example, a WTRU may establish a central control plane (e.g. only) and/or may establish a central control plane and a central user plane, for example, based on whether the WTRU has signaling traffic and/or data traffic. In an (e.g. another) example, a WTRU may (e.g. directly) transmit data without access plane establishment, for example, when the WTRU (e.g. in a loosely connected state) may have a central control context without an access plane established.

[0176] A WTRU may store a Central control plane context, for example, even after an access plane may be deactivated. Central control functions may (e.g. similarly) retain a WTRU context, for example, even after the access control functions release WTRU context and/or WTRU specific connectivity between access control functions and central control functions. Central control functions may (e.g. additionally) retain WTRU context, for example, even after central user functions release WTRU context and/or WTRU specific connectivity between central user plane functions and core network user plane functions. In other words, for example, a RAN control plane (e.g. SRBs) may exist without an active user plane (e.g. DRBs). For example, a WTRU may attach to a network without a corresponding data bearer establishment. A WTRU may (e.g. be required to) maintain central user plane context, for example, (e.g. only) when the central control plane context is active.

[0177] An access plane may be dynamically activated/deactivated, e.g., by access control functions and/or by central control functions, for example, when a control plane context is active.

[0178] WTRU connectivity may have one or more supported states. For example, a WTRU may operate according to one or more of the following states: idle mode; idle mode with connectionless transfers; and/or connected mode and/or loosely connected mode.

[0179] In an IDLE mode, for example, a WTRU might not have established connectivity with a network (e.g. a WTRU might not have ACF/ACP, RCCF/RCCP and/or RCUF/RCUP established).

[0180] In an IDLE mode with Connectionless Transfers, for example, a WTRU may have some connectivity with a network (e.g. it may have at least one ACF/ACP established with at least one user plane component, e.g., with a default configuration, e.g., for routing and/or security). A WTRU may have RCCF/RCCP established (e.g. a security context, access tables).

[0181] In a connected mode, for example, a WTRU may have complete connectivity with a network (e.g. it may have at least one ACF/ACP, RCCF/RCCP and/or RCUF/RCUP (e.g. when applicable) established with at least one user plane component).

[0182] In a loosely connected mode, for example, a WTRU may have some connectivity with a network (e.g. it may have at least one RCCF/RCCP established, e.g., a security context, access tables).

[0183] Connectionless data transfer may be provided. A WTRU may establish an L3/RRC connection to transmit data PDUs irrespective of the size of the data packet. Establishing a connection may be difficult relative to one or more of: overheads associated with signaling to establish a connection at the RAN and/or Core network before the start of a small packet transfer; overhead associated with tearing down a connection after periods of inactivity; and/or WTRU battery drain to stay in connected mode for extended periods of time.

[0184] A WTRU may (e.g. directly) perform connectionless data transfer in a loosely connected state, for example, using a pre-existing context with a central control plane function. A pre-existing context may include (e.g. at least) a security context, WTRU subscription and/or WTRU capability configuration. A WTRU may (e.g. also) perform connectionless data transfer from an idle connectionless state, e.g., using a pre-existing context with the core network control function. A WTRU may (e.g. in this example) not have a RAN central context established. For example, a WTRU may be associated with (e.g. only) a default slice and/or a core network control function and may still transmit connectionless data. A WTRU may (e.g. in this example) include additional session information with a data PDU.

[0185] Connectionless data transfer may allow a WTRU to transmit data, for example, with one or more following characteristics/properties: without requiring access plane establishment; using modified msgl (e.g. modified RACH preamble + data, multi-user non-orthogonal data channel, etc.); without receiving an explicit grant (e.g. contention based UL shared data channel); after UL synch (e.g. using piggybacked data with and/or as msg3); before UL synch to the network (e.g. using asynchronous access channel); and/or transmitting additional context information associated with the data PDU.

[0186] A WTRU may use a simplified security procedure that may, for example, involve one or more of: using stored context, which may be result of previous network interaction and/or hard coded security context in SIM; and/or explicit indication of security algorithm used.

[0187] A connectionless data transfer mode may allow a WTRU to transmit data PDUs earlier than connection oriented data transmission. Such data PDUs may be referred to as early data PDUs.

[0188] For example, a connectionless data transfer mode may (e.g. also) be used for downlink transmissions. For example, a WTRU may receive data PDUs in the same TTI with a paging message and/or along with the paging message itself. A network may trigger such connectionless downlink transfer, for example, when a WTRU location is known at a fine granularity and/or the size of the data packet is small.

[0189] A WTRU may trigger connectionless data transfer, for example, based on one or more of the following criteria: a service (e.g. low overhead service and/or a low latency service, etc.); a size of a packet (e.g. when the size of the packet is less than a predefined number of bytes); WTRU buffer occupancy (e.g. when a WTRU buffer size is less than a predefined number of bytes); latency experienced by the packet (e.g. when the packet exceeds latency budget); packet filtering (e.g. WTRU may be configured with a packet filter/TFT to identify packets matching specific criteria, such as IP address, protocol, port number, type of service, flow label and/or a preconfigured session ID); absence of valid/configured logical connection (e.g. EPS

bearer/Radio bearer); type of PDUs (e.g. initial signaling messages may use connectionless); WTRU mobility state (e.g. when WTRU speed and/or number of reselections/HO per second exceeds a threshold, which may be used to limit the number of handovers for medium/fast moving WTRU); a WTRU category; and/or an access class.

[0190] For example, a WTRU may (e.g. always) trigger a connectionless transfer, e.g., by default and/or as configured by an access table. A WTRU may (e.g. subsequently) transition to connection oriented transfer, for example, based on WTRU and/or network procedures described herein.

[0191] A WTRU may determine LI and/or L2 configuration for connectionless transfer, for example, using one or more of the following procedures: a WTRU may apply a default configuration; a WTRU may apply a predefined configuration acquired via system broadcast (e.g. access table and/or system signature based) that may be specific to a access control function, to a central control function and/or to a TRP or a group of TRPs; a WTRU may apply a stored configuration (e.g. received upon establishing central control plane context) that may be dedicated for a WTRU or a group of WTRUs where the same configuration may be used across one or more, or multiple TRPs; and/or a WTRU may (e.g. explicitly) request connectionless transfer and/or may obtain specific configuration that may include transmission resources (e.g. contention based/non-orthogonal resources, layer2 configuration, etc.).

[0192] A layer 2 configuration may (e.g. in addition to a physical layer time/frequency resource configuration) include a max data rate restriction, bucket size, RLC mode, PDPC discard timer, security algorithm, etc. For example, specific MAC instances may be configured for connectionless transfer.

[0193] One or more connectionless configuration parameters may be associated with a validity timer. A WTRU may start a validity timer, for example, upon receiving configuration parameters. A WTRU may consider configurations, for example, (e.g. only) when the timer is

running. AWTRU may delete/release configurations, for example, upon the expiration of a validity timer.

[0194] AWTRU may include additional context information with a data PDU, for example, to assist a network with processing and/or routing a data packet to an appropriate destination. Additional context information may be included, for example, in a layer 3 message and/or as a part of a layer 2 header field. For example, a layer3 message type may be defined to identify connectionless data. An IE (e.g. connectionless-data-IE) may be introduced in a layer 3 message (e.g. UL information transfer).

[0195] AWTRU may include one or more types of information as context information in an early data PDU.

[0196] For example, context information may comprise WTRU Identity information, which may comprise, for example, one or more of the following: an L3 identity that may have been allocated by a central control function during a previous interaction; an associated Identity of the central control function and/or an NAS level identity; an implicit indication of a portion of and/or a whole identity, e.g., using the selection of time/frequency resource; and/or a demodulation reference signal and/or unique word that may be a function of WTRU ID.

[0197] For example, context information may comprise a more data left indication and/or last PDU indication, which may indicate whether there are additional PDUs in WTRU buffer along with the early data PDU.

[0198] For example, context information may comprise one or more of: QoS related information, e.g., an indication to treat the early data PDU as a default QoS and/or as a non-default bearer data PDU; a low latency indicator, e.g., to allow a network to use low latency and/or an efficient data path; and/or a low overhead indicator, e.g., to allow a network to use a low overhead mechanism for transfer (e.g. a connectionless transport).

[0199] For example, context information may comprise application description and/or session related information, such as a predefined session ID, e.g., so a network knows which session a data PDU is associated with.

[0200] For example, context information may comprise forwarding/routing/transport layer information (e.g. a general packet radio service tunneling protocol (GTP) tunnel and/or a flow table entry and/or an index to flow table entry.

[0201] For example, context information may comprise security context information.

[0202] For example, context information may comprise destination ID, such as a control plane ID and/or a user plane entity ID, e.g., perhaps depending whether a PDU is a signaling PDU or data PDU.

[0203] For example, context information may comprise user plane entity ID (e.g. when one already exists to avoid signaling towards RAN control plane entity), for example, for a RAN and/or Core user plane entity.

[0204] For example, context information may comprise control plane entity ID (e.g. entity with a valid WTRU context including subscription, security, etc.), for example, for a RAN Control entity and/or a core (e.g. MME ID + WTRU ID within the MME service area).

[0205] For example, context information may comprise slice identity, e.g., when a WTRU is already configured with a specific slice for connectionless transfer.

[0206] A WTRU may receive and/or may process feedback for a connectionless data transfer, where processing may be different from a connection oriented data transfer. A WTRU may (e.g. implicitly) determine the resources for feedback, for example, as a function of UL time/frequency resources used for early data PDU transmission and/or as a function of WTRU ID included in the data PDU.

[0207] Feedback (e.g. for data transmitted using connectionless/early data transfer based mode) may be associated with additional information, including, one or more types of additional information.

[0208] For example, additional information may comprise a WTRU ID for which feedback is sent (e.g., copied from UL Data PDU), e.g., where WTRU may verify the WTRU ID present in the feedback before processing the feedback message.

[0209] For example, additional information may comprise a timing advance (e.g. for async/contention based UL).

[0210] For example, additional information may comprise a power control command.

[0211] For example, additional information may comprise an ACK/NACK, e.g., where additional resources may be granted for retransmission for NACK.

[0212] For example, additional information may comprise a collision/contention indication, e.g., when WTRU action is based on a contention indicator, such as one or more of: when WTRUs can be distinguished at eNB (e.g., by orthogonal DMRS) and/or when WTRU receives other WTRU IDs in the feedback, a WTRU may transmit at next opportunity; and/or when WTRU receives a contention indication, the WTRU may perform, for example, a random back off and/or fallback to connection based data transfer.

[0213] For example, additional information may comprise an indication to trigger access plane establishment and/or fallback to connection oriented mode.

[0214] For example, additional information may comprise additional UL resource grants and/or an Indication to go back to idle mode (and/or implicitly an ACK may be used to go back to idle mode), for example, depending on last PDU indication.

[0215] For example, additional information may comprise a request for WTRU identity and/or additional authentication procedure, e.g., when WTRU context might not be fetched and/or when WTRU may be unknown at the RCCF and/or the security check failure, etc., where a WTRU may respond to the authentication procedure and/or provide additional context information.

[0216] A WTRU may (e.g., in connectionless transfer mode) trigger a transition to connected oriented mode, for example, based on one or more of the following criteria and/or events: when a WTRU spends more than a predefined time in connectionless mode; when a WTRU receives a data packet with more than predefined number of bytes; when a WTRU transmits more than a predefined number of bytes in connectionless mode; when a WTRU buffer size exceeds a threshold; when a latency of buffered data exceeds a threshold; when a number of

NACKs/retransmissions for an early data PDU exceeds a threshold; when a data rate over a predefined time window exceeds threshold; and/or when an activity timer exceeds a threshold, e.g., when an activity timer that may be (e.g. always) running when a WTRU enters

connectionless transfer mode, where the activity timer may be reset to zero and started again, perhaps for example when the time between two consecutive packets exceeds a threshold.

[0217] For example, a WTRU may be configured to report one or more events. A network may determine whether to transition the WTRU to connection oriented mode. A WTRU may events, for example, using a control message and/or signal and/or piggyback indication in a connectionless data PDU. A network may (e.g., also) trigger a transition to connection oriented mode, for example, based on policies, type of services, WTRU subscription, WTRU mobility, etc. For example, a WTRU may transition from connection oriented mode to connectionless mode, for example, based on a network command (e.g., based on inactivity).

[0218] A user plane component may be (e.g., conceptually) represented as a transport path. A transport path may include, for example, one or more of the following: one or more Uu (which may be associated with a specific SOM and/or physical layer QoS) and/or a configuration thereof; a QoS profile (e.g., in terms of maximum latency, jitter, packet loss rate and/or the likes) and/or a configuration thereof; an association with one or more data flows and/or service (e.g., as indicated by a multiplexing function that may be based on logical radio bearer, tuples and/or a configuration thereof); routing table entries (e.g., in the network); a list and/or set of one or more matching rules; and/or a list and/or set of one or more tuples (e.g., to determine what logical path a packet may be directed to).

[0219] A distributed control plane for NR may have functions and/or components, which may be discussed from the perspective of their different applicability.

[0220] For example, a WTRU-specific function may be associated with an anchor control function. An RCCF may manage connectivity of a WTRU with a core network (e.g., PDN connectivity, reachability, etc.).

[0221] For example, a component-specific function may operate on one or more aspects of a single instance of a component for a given WTRU.

[0222] For example, a plural-component function may operate on one or more aspects of one or more, or multiple instances of a component for a given WTRU.

[0223] For example, control functions may be associated with MAC instances that may (e.g. also) map to a set of access control functions.

[0224] For example, control functions may be associated with a single MAC instance.

[0225] System information may be acquired, for example, as a WTRU-specific function, as a component-specific function and/or as a plural-component function.

[0226] A component of System information acquired as a WTRU-specific function, for example may include, a cell, TRP, and/or TRPG and/or groups thereof (e.g. everything a WTRU may find useful). On-Demand procedures, including requests and/or combination with already known Syslnfo (pre-provisioning and/or acquired) may be described. Syslnfo split may be supported. Out-of-band Syslnfo may be supported.

[0227] A component of system information acquired as a Component-specific function may be, for example, a cell and/or a TRP. Syslnfo split may be supported. Out-of-band Syslnfo may be supported.

[0228] A component of system information acquired as a Plural-component function may be, for example, one or more, or multiple cells, one or more, or multiple TRPs, one or more, or multiple TRPGs, and/or one or more, or multiple NR-eNBs, etc. Syslnfo split may be supported. Out-of-band Syslnfo may be supported.

[0229] System information may be acquired, for example, using one or more approaches and/or procedures.

[0230] For example, system information may be acquired by broadcast, e.g., similar to LTE.

[0231] For example, system information may be acquired by splitting information in a first set of information and in a second set of information. Such information may comprise one or more system parameters. Such split of information may be based on one or more characteristics

of the concerned information. Such characteristic may include whether or not the information is essential for accessing the concerned network resources, whether or not the information relates to a feature and/or function available using the concerned network resources, whether or not the information relates to a feature and/or function for low-latency access (e.g. URLLC), whether or not the information may enable specific UE procedures such as camping, measurements, and/or the like. Such first set may be further referred to as "Essential" information and/or such second set may be further referred to as "Non-essential" information. In some solutions, "Essential" information may be referred as Minimum-SI and/or "Non-essential" information may be referred as Other-SI. Such split may be network-controlled and/or vary from one area to another, where essential system information (if any) may be broadcast (e.g. to enable a WTRU to access the system and/or obtain further system information through dedicated resources. Broadcast information may comprise MIB, SIB1 (access-related information e.g. PLMN, TAC, CelllD, p-Max, frequency band indicator), SIB2 (access barring information, RACH parameters, UL power control). The amount of broadcasted system information may vary (e.g., depending on the split between "Essential" and "Non-essential" information). For example, the amount of system information included in the broadcast may be one or more of the following: no broadcasted system information (e.g., pre-provisioning, acquired, and/or on-demand); MIB; MIB + SIB1 ; MIB + SIB1 + SIB2; (v) MIB + SIB1 + SIB2 + combination of remaining SIBs (e.g., SIB3 may be broadcasted to support cell reselection, etc.); and/or other combinations of "Essential" and "Non-essential" information. In some examples, there may be no "Essential" system information broadcasts. On-demand (dedicated) information may comprise obtaining remaining system information through dedicated resources (e.g. triggered through PRACH), where, on-demand acquisition may be based on a service (e.g. camping/paging etc.), WTRU capability, slice, etc.

[0232] For example, system information may be acquired by splitting information across broadcast and dedicated transmissions. A split may be network-controlled and/or may vary from one area to another. A flexible mechanism may be provided to support variable split between broadcast and dedicated information.

[0233] For example, system information may be acquired by system information

modification, which may provide one or more mechanisms, for example: to update the delta, whether pushed and/or on-demand (e.g. WTRU-initiated and/or NW-initiated by control signaling ordering WTRU to start the procedure); and/or to request a specific element of system information (e.g. SIB).

[0234] For example, system information may be acquired by variable acquisition, for example, based on location and/or frequency band (e.g. system information applicable in one location and/or for one carrier may be received in different locations and/or carrier).

[0235] Broadcast information may include specific information components related to specific services, such as a configuration for low latency access and/or for connectionless data transfers.

[0236] Essential information may be broadcast. Essential information may include, for example, MIB, SIB1 (access-related information e.g. PLMN, TAC, CelllD, p-Max, frequency band indicator), SIB2 (access barring information, RACH parameters, UL power control). A WTRU may acquire broadcast system information and/or may request further system

information, e.g., using an on-demand procedure.

[0237] More information (e.g. beyond essential information) may be broadcast, for example, based on capacity /load. For example, more system information may be broadcast, for example, perhaps when the system has the capacity and broadcast capacity is limited. A WTRU may acquire broadcast system information and/or may request further system information, e.g., using an on-demand procedure.

[0238] System information may be modified (e.g. changed and/or updated). For example, system information modification may be triggered by paging for WTRUs in RRC IDLE and/or WTRUs in RRC CONNECTED. A WTRU (e.g. when WTRU receives notification of system information modification) may identify a delta and/or may acquire modified/new system information, for example, by one or more procedures, such as broadcast (e.g. when a delta is broadcast) and/or on-demand (e.g. when a delta is not broadcast).

[0239] Variable acquisition may be based on location and/or frequency band. For example, deployment scenario may include macro and/or micro, wherein system information (e.g. for the macro and/or micro) may be broadcast over the macro. A WTRU may (e.g. when not in coverage of a macro) acquire system information from a micro.

[0240] System information may be variable portioned. Essential system information (if any) may be broadcast, for example, to enable a WTRU to access the system. A WTRU may acquire further system information through dedicated resources.

What is Claimed is:

1. A wireless transmit/receive unit (WTRU) in communication with a communication

network, the WTRU comprising:

a memory;

a processor, the processor configured at least to:

determine to request one or more system information (SI) messages from the communication network; and

determine if a transmission of the one or more SI message from the communication network will utilize at least one beamformed communication based on one or more communication parameters; and

a transceiver, the transceiver configured at least to:

receive at least one of the one or more SI messages from the

communication network via the at least one beamformed communication.

2. The WTRU of claim 1, wherein the one or more communication parameters include a frequency band of the transmission, the processor being further configured to:

compare the frequency band of the transmission to a predetermined threshold; and

determine that the transmission of the one or more SI messages from the communication network utilizes at least one beamformed communication based on the frequency band of the transmission exceeding the predetermined threshold.

3. The WTRU of claim 1, wherein the one or more communication parameters include a characteristic of a downlink signal, the transceiver being further configured to:

receive the downlink signal, the processor being further configured to: identify the characteristic of the downlink signal; and determine that the transmission of the one or more SI messages from the communication network utilizes at least one beamformed communication based on the identified characteristic of the downlink signal.

4. The WTRU of claim 3, wherein the downlink signal includes a reference signal.

5. The WTRU of claim 4, wherein the characteristic of the downlink signal includes one or more of: a type of the reference signal, a system signature, a root signature, a basis sequence, or one or more predefined sequence numbers.

6. The WTRU of claim 5, wherein the type of the reference signal is a synchronization signal.

7. The WTRU of claim 1, wherein the one or more communication parameters include information provided in a broadcast message, the transceiver being further configured to:

receive the broadcast message, the processor being further configured to: identify the information in the broadcast message; and determine that the transmission of the one or more SI messages from the communication network utilizes at least one beamformed communication based on the information in the broadcast message.

8. The WTRU of claim 7, wherein the information provided in the broadcast message is included in at least one of: a master system information block (MIB), or a system information block (SIB), or a system information message.

9. The WTRU of claim 1, wherein the one or more communication parameters include a quality of a downlink signal, the transceiver being further configured to:

receive the downlink signal, the processor being further configured to: measure a quality of the downlink signal; and

determine that the transmission of the one or more SI messages from the communication network utilizes at least one beamformed communication based on the quality of the downlink signal being below a predetermined threshold.

10. The WTRU of claim 9, wherein the downlink signal includes a reference signal, and the quality of the downlink signal includes a received power of a reference signal.

11. The WTRU of claim 1, wherein the processor is further configured to initiate an uplink (UL) request to the communication network for the one or more SI messages.

12. A wireless transmit/receive unit (WTRU) in communication with a communication network, the WTRU comprising:

a memory;

a processor, the processor configured at least to:

determine to request one or more system information (SI) messages from the communication network;

conduct a beam sweep operation of one or more downlink (DL) beams transmitted from the communication network;

identify at least one DL beam of the one or more DL beams via which to receive the one or more on-demand SI messages based at least in part on the beam sweep operation;

determine one or more uplink (UL) resources with which to communicate information for a WTRU reception of the one or more on-demand SI messages, the information for the WTRU reception including the at least one DL beam; and initiate the request for the one or more on-demand SI messages from the communication network; and

a transceiver, the transceiver configured at least to:

send the request for the one or more on-demand SI messages to the communication network using the one or more UL resources, the request including the information for the WTRU reception of the one or more on-demand SI messages; and

receive at least one of the one or more on-demand SI messages from the communication network via the at least one DL beam.

13. The WTRU of claim 12, wherein the one or more UL resources are mapped to the at least one DL beam.

14. The WTRU of claim 12, wherein the processor is further configured such that the one or more UL resources are determined based on at least one of: the at least one DL beam of the one or more DL beams, a mapping between the one or more UL resources and the at least one DL beam of the one or more DL beams, or the requested one or more on- demand SI messages

15. The WTRU of claim 12, wherein the processor is further configured such that the request for the one or more on-demand SI messages is sent as part of a Random Access Channel (RACH) transmission.

16. The WTRU of claim 12, wherein the processor is further configured such that the at least one DL beam of the one or more DL beams is identified based on which of the one or more DL beams at least one of: a synchronization signal, a master system information block (MIB), or essential system information is received in the beam sweep operation.

17. A wireless transmit/receive unit (WTRU) in communication with a communication

network, the WTRU comprising:

a memory;

a transceiver, the transceiver configured at least to:

receive system information (SI) from the communication network at a first-time instance; and

a processor, the processor configured at least to:

determine a first-reference identifier (ID) that corresponds to at least some of the SI of the first-time instance;

determine a first-value identifier (ID) that corresponds to the at least some of the SI of the first-time instance;

associate at least one of: the first-reference ID, or the first-value ID with the at least some of the SI of the first-time instance;

utilize the at least some of the SI of the first-time instance in

communication with the communication network;

search the memory for stored SI of a previous-time instance that is associated with the same first-reference ID of the at least some of the SI of the first-time instance;

store the at least some of the SI of the first-time instance upon no stored SI of the previous-time instance associated with the same first-reference ID being found; and

replace stored SI of the previous-time instance associated with the same first-reference ID with the at least some of the SI of the first-time instance upon a value ID associated with the stored SI of the previous-time instance associated with the same first-reference ID being different from the first-value ID.

18. The WTRU of claim 17, wherein the processor is further configured to interpret that the value ID associated with the stored SI of the previous-time instance associated with the same first-reference ID being different from the first-value ID corresponds the at least some of the SI of the first-time instance being more current than the stored SI of the previous-time instance.

19. The WTRU of claim 17, wherein the processor is further configured to recognize that the first-reference ID corresponds to at least one of: a first-spatial area, or a first-temporal interval.

20. The WTRU of claim 17, wherein the processor is further configured to determine the first-reference ID by identifying the first-reference ID as communicated from the communication network via at least one of: a broadcast message, or dedicated signaling.

21. The WTRU of claim 20, wherein the processor is further configured to determine the first-value ID by identifying a part of the first-reference ID that represents the first-value ID.

22. The WTRU of claim 20, wherein the processor is further configured to determine the first-value ID by identifying the first-value ID as communicated from the communication network via at least one of: a broadcast message, or dedicated signaling.

23. The WTRU of claim 17, wherein the processor is further configured to determine the first-reference ID by deriving the first-reference ID based on one or more characteristics associated with one or more downlink (DL) transmissions.

24. The WTRU of claim 23, wherein the processor is further configured to determine the first-value ID by identifying the first-value ID as expressly communicated from the communication network via at least one of: a broadcast message, or dedicated signaling.

25. The WTRU of claim 17, wherein the at least some of the SI of the first-time instance is at least one of: essential SI, minimum SI message, or on-demand SI.

26. The WTRU of claim 17, wherein the processor is further configured such that to replace the stored SI of the previous-time instance associated with the same first-reference ID

with the at least some of the SI of the first-time instance includes the processor being configured to:

delete from the memory the stored SI of the previous-time instance associated with the same first-reference ID; and

store in the memory the at least some of the SI of the first-time instance.

27. The WTRU of claim 17, wherein the processor is further configured such that to replace the stored SI of the previous-time instance associated with the same first-reference ID with the at least some of the SI of the first-time instance includes the processor being configured to:

overwrite in the memory the stored SI of the previous-time instance associated with the same first-reference ID with the at least some of the SI of the first-time instance.

28. The WTRU of claim 20, wherein the processor is further configured to:

detect that a second-reference ID is being communicated by the communication network in lieu of the first-reference ID;

search the memory for stored SI of a previous-time instance that is associated with the second-reference ID;

utilize the SI of the previous-time instance that is associated with the second-reference ID upon the SI of the previous-time instance that is associated with the second-reference ID being found; and

obtain updated SI from the communication network upon the SI of the previous-time instance that is associated with the second-reference ID not being found.

29. The WTRU of claim 22, wherein the processor is further configured to:

detect that a second-reference ID is being communicated by the communication network in lieu of the first-reference ID;

detect that a second-value ID is being communicated by the

communication network in lieu of the first-value ID;

search the memory for stored SI of a previous-time instance that is associated with the second-reference ID and the second-value ID;

utilize the SI of the previous-time instance that is associated with the second-reference ID and the second-value ID upon the SI of the previous-time instance that is associated with the second-reference ID and second-value ID being found; and

obtain updated SI from the communication network upon the SI of the previous-time instance that is associated with the second-reference ID and the second-value ID not being found.

30. A wireless transmit/receive unit (WTRU) in communication with a communication network, the WTRU comprising:

a memory;

a processor, the processor configured at least to:

determine to request other system information (other-SI) from the communication network;

initiate the request for the other-SI from the communication network as part of a Radom Access Channel (RACH) procedure; and

a transceiver, the transceiver configured at least to:

transmit a RACH signal, the RACH signal including the request for the other-SI in a random access preamble of the RACH signal, the processor being further configured to:

monitor for a message that includes a minimum SI from the

communication network for a predetermined period of time following the transmission of the RACH signal;

determine if the requested other-SI is included in the message that includes the minimum SI upon a detection of the message that includes the minimum SI; and

initiate one or more retransmissions of the RACH signal upon at least one of: the message that includes the minimum SI not being detected, or the other-SI is determined to not be included in a detected message that includes the minimum SI.

31. The WTRU of claim 30, wherein the processor is further configured such that the

predetermined period of time occurs within a random access response time window.

32. The WTRU of claim 31, wherein the processor is further configured to monitor for a predefined identifier in a control channel within the random access response time window.

33. The WTRU of claim 32, wherein the processor is further configured such that the

predefined identifier is specific to the request of the other-SI.

34. The WTRU of claim 32, wherein the processor is further configured such that the

predefined identifier is a Radio Network Temporary Identifier (RNTI).

35. The WTRU of claim 31, wherein the processor is further configured such that the

message that includes the minimum SI is at least one of: one or more random access response messages, the processor being further configured to process the at least one of the one or more random access response messages within the random access response time window.

36. The WTRU of claim 35, wherein a format of the at least one of the one or more random access response messages is specific to the request for the other-SI.

37. The WTRU of claim 30, wherein the processor is further configured to initiate a power ramping of the random access preamble in the one or more retransmissions.

38. The WTRU of claim 30, wherein the processor is further configured to initiate the one or more retransmissions of the RACH signal upon at least one of: no response to the RACH signal being detected in the predetermined period of time; or a limit of a preamble counter associated with the RACH signal not being reached.

39. The WTRU of claim 30, wherein the processor is further configured such that the

message that includes the minimum SI is at least one of: a random access response message that corresponds to the random access preamble of the RACH signal, or a random access response message that does not correspond to the random access preamble of the RACH signal.

40. The WTRU of claim 30, wherein at least one of the one or more retransmissions have been initiated by the processor, the processor being further configured to:

cease an initiation of any further retransmissions of the one or more retransmissions upon:

a detection of the message that includes the minimum SI; and a determination that the requested other-SI is included in the detected message that includes the minimum SI.