Techniques for flexible subnets

Abstract

The invention relates to techniques for flexible subnets. The application relates to devices and components including apparatuses, systems, and methods for employing a subnet to communicate with a cellular network.

Description

[0001] Related Applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 583,173, filed on September 15, 2023, entitled “TECHNOLOGIES FOR FLEXIBLESUBNETWORKS,” and U.S. Non-Provisional Patent Application No. 18 / 806,601, filed on August 15, 2024, entitled “TECHNOLOGIES FOR FLEXIBLE SUBNETWORKS,” the entire contents of which are incorporated herein. Technical Field

[0003] The present application relates to the field of wireless technology, and in particular to technology for enabling flexible subnets. Background Art

[0004] The 3rd Generation Partnership Project (3GPP) Technical Specifications (TS) define the air interface for the radio access network. These 3GPP TSs specify that the base station controls the resource management, admission control, mobility, and scheduling that occur within the radio access network. While centralized control of the air interface provides some advantages, it also reduces deployment flexibility. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 A network environment according to some embodiments is illustrated.

[0006] Figure 2 Configurations according to some embodiments are illustrated.

[0007] Figure 3 is a signaling diagram according to some embodiments.

[0008] Figure 4 Configurations according to some embodiments are illustrated.

[0009] Figure 5 is a signaling diagram according to some embodiments.

[0010] Figure 6 is a signaling diagram according to some embodiments.

[0011] Figure 7 is a signaling diagram according to some embodiments.

[0012] Figure 8 is a signaling diagram according to some embodiments.

[0013] Fig. 9 A network environment with aspects of a subnet tunneling protocol according to some embodiments is illustrated.

[0014] Fig.10 Options for a subnet tunneling protocol layer according to some embodiments are illustrated.

[0015] Fig.11 is an operational flow / algorithm structure according to some implementation schemes.

[0016] Fig.12 is another operational flow / algorithm structure according to some embodiments.

[0017] Fig.13 is another operational flow / algorithm structure according to some embodiments.

[0018] Fig.14 is an example UE according to some embodiments.

[0019] Fig.15 is an example base station according to some embodiments. DETAILED DESCRIPTION

[0020] The following specific embodiments relate to the accompanying drawings. The same reference numerals may be used to identify the same or similar elements in different drawings. In the following description, specific details, such as specific structures, architectures, interfaces, technologies, etc., are set forth for the purpose of illustration rather than limitation, so as to provide a thorough understanding of various aspects of various embodiments. However, it is obvious to those skilled in the art who benefit from the present disclosure that various aspects of various embodiments can be practiced in other examples that are separated from these specific details. In some cases, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the descriptions of various embodiments due to unnecessary details. For the purposes of this document, the phrases "A / B" and "A or B" refer to (A), (B), or (A and B); the phrase "(A)B" refers to (B) or (A and B), i.e., A is optional; and the phrase "based on A" refers to "based at least in part on A", for example, it can be "based only on A" or it can be "based in part on A".

[0021] The following is a glossary of terms that may be used in this disclosure.

[0022] As used herein, the term "circuit" refers to, is part of, or includes a hardware component such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) or a memory (shared, dedicated, or group) configured to provide the described functions, an application specific integrated circuit (ASIC), a field programmable device (FPD) (e.g., a field programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high capacity PLD (HCPLD), a structured ASIC, or a programmable system on chip (SoC)), a digital signal processor (DSP), etc. In some embodiments, the circuit may execute one or more software or firmware programs to provide at least some of the described functions. The term "circuit" may also refer to a combination of one or more hardware elements and a program code for performing the functions of the program code (or a combination of circuits used in an electrical or electronic system). In these embodiments, the combination of hardware elements and program code may be referred to as a specific type of circuit.

[0023] As used herein, the term "processor circuit" refers to, is part of, or includes a circuit capable of sequentially and automatically performing a series of arithmetic or logical operations or recording, storing, or transmitting digital data. The term "processor circuit" may refer to an application processor, a baseband processor, a central processing unit (CPU), a graphics processing unit, a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, or any other device capable of executing or otherwise operating computer-executable instructions (such as program code, software modules, and / or functional processes).

[0024] As used herein, the term "interface circuit" refers to a circuit that enables, is a part of, or includes information exchange between two or more components or devices. The term "interface circuit" may refer to one or more hardware interfaces, such as a bus, an I / O interface, a peripheral component interface, a network interface card, etc.

[0025] As used herein, the term "user equipment" or "UE" refers to a device that has radio communication capabilities and can describe a remote user of network resources in a communication network. In addition, the terms "user equipment" or "UE" may be considered synonymous and may be referred to as a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. In addition, the term "user equipment" or "UE" may include any type of wireless / wired device or any computing device that includes a wireless communication interface.

[0026] As used herein, the term "computer system" refers to any type of interconnected electronic devices, computer devices, or components thereof. Additionally, the term "computer system" or "system" may refer to various components of a computer that are communicatively coupled to one another. Furthermore, the term "computer system" or "system" may refer to multiple computer devices or multiple computing systems that are communicatively coupled to one another and configured to share computing resources or networked resources.

[0027] As used herein, the term "resource" refers to a physical or virtual device, a physical or virtual component within a computing environment, or a physical or virtual component within a specific device, such as a computer device, a mechanical device, a memory space, a processor / CPU time, a processor / CPU usage, a processor and accelerator load, a hardware time or usage, an electrical power, an input / output operation, a port or a network socket, a channel / link allocation, a throughput, a memory usage, a storage, a network, a database and an application, a unit of work, etc. "Hardware resources" may refer to computing, storage or network resources provided by physical hardware elements. "Virtualized resources" may refer to computing, storage or network resources provided by a virtualized infrastructure to an application, a device, a system, etc. The term "network resources" or "communication resources" may refer to resources that a computer device / system can access via a communication network. The term "system resources" may refer to any kind of shared entity that provides a service, and may include computing resources or network resources. System resources may be considered as a set of coherent functions, network data objects or services that can be accessed through a server, wherein such system resources reside on a single host or multiple hosts and can be clearly identified.

[0028] As used herein, the term "channel" refers to any tangible or intangible transmission medium for communicating data or data streams. The term "channel" may be synonymous or equivalent to "communication channel", "data communication channel", "transmission channel", "data transmission channel", "access channel", "data access channel", "link", "data link", "carrier", "radio frequency carrier" or any other similar term representing a path or medium through which data is communicated. In addition, as used herein, the term "link" refers to a connection made between two devices for transmitting and receiving information.

[0029] As used herein, the terms "instantiate," "instantiate," and the like refer to the creation of an instance. "Instance" also refers to a specific occurrence of an object, which may occur, for example, during the execution of program code.

[0030] The term "connected" may mean that two or more elements at a common communication protocol layer have an established signaling relationship with each other through a communication channel, link, interface, or reference point.

[0031] As used herein, the term "network element" refers to physical or virtualized equipment or infrastructure for providing wired or wireless communication network services. The term "network element" may be considered synonymous with or referred to as a networked computer, networking hardware, network equipment, network node, virtualized network function, etc.

[0032] The term "information element" refers to a structural element that contains one or more fields. The term "field" refers to the individual contents of an information element, or a data element that contains the contents. An information element may include one or more additional information elements.

[0033] Figure 1 A network environment 100 according to some embodiments is illustrated. The network environment 100 may include a base station 108 that provides one or more serving cells with which a user equipment (UE) may communicate using a cellular network. The base station 108 may be part of a radio access network (RAN) coupled to a core network (CN) 116.

[0034] The UE and the base station 108 may communicate over an air interface compatible with fifth-generation (5G), sixth-generation (6G) (or later) system standards as provided by 3GPP technical specifications.

[0035] The network environment 100 may include a management node (MN) 104 communicatively coupled to a base station 108 via a physical connection provided by a serving cell of the base station 108. The MN 104 may be a UE that provides a coordination role within the subnet 106.

[0036] Subnet 106 may include multiple UEs coupled to MN 104. For example, subnet 106 may include UE 1, UE 2, and UE 3. Each of these UEs may include a physical connection with MN 104 and a virtual connection with BS 108. Network environment 100 may also include UE 4 having a physical connection with base station 108.

[0037] As used herein, a physical connection may refer to a direct wireless connection between two devices at the physical layer of a network protocol stack. As used herein, a virtual connection may refer to a logical link between two devices. The logical link may include a connection at a layer above the physical layer of a network protocol stack.

[0038] Subnet 106 can be controlled by MN 104 independently of a wider network (e.g., a RAN controlled by base station 108 or CN 112). For example, subnet 106 can utilize technology independent of RAN technology. Subnet 106 can use licensed or unlicensed spectrum, with resources granted, scheduled, or otherwise controlled by MN 104, independent of direct control by base station 108.

[0039] MN 104 may form a subnet 106 for UEs without (or with limited) configuration or knowledge by base station 108. Base station 108 may communicate with MN 104 via a physical connection, and may logically communicate with UEs of subnet 106 via a virtual connection. In some embodiments, the subnet topology and mobility within subnet 106 may be transparent to the wider network (e.g., base station 108), which may reduce the complexity of the wider network. MN 104 may control various aspects of subnet 106, including, for example, routing and resource management. MN 104 may provide quality of service (QoS) with reliable end-to-end (E2E) links. This may be achieved by utilizing a fair scheduling mechanism for all UEs across subnet 106 and relative to other UEs of network environment 100.

[0040] The control plane (CP) and user plane (UP) aspects of the subnet 106 can facilitate flexible and efficient communication of the components of the subnet 106. For example, the CP entity can be flexibly deployed on the MN 104 or the local device, and can be transferred between subnet nodes. These deployments can be transparent to the wider network. Regarding the UP aspect, the higher layers can be terminated at the local device (e.g., protocol data unit (PDU) session / Internet protocol (IP) address), and the lower layers can be terminated at the MN 104 and can be subnet-specific within the subnet 106 according to the technology used (e.g., licensed vs. unlicensed, device-to-device (D2D), etc.).

[0041] In some embodiments, the UE may be associated with a wider network. For example, the UEs of subnet 106 may remain registered with the wider network and have some aspects managed by base station 108. For example, base station 108 may include a UE context and may control resource and mobility decisions with respect to the wider network (e.g., handovers between base stations such as a cellular network).

[0042] In some embodiments, the UE may be able to move seamlessly between the subnet 106 and a wider network controlled by the base station 108. For example, the network environment 100 may include a UE 4 that is able to transition into and out of the subnet 106.

[0043] MN 104 may cooperate with base station 108 to establish subnet 106. MN 104 and base station 108 may each include a MN interface configuration to facilitate establishment of subnet 106 and downlink / uplink signaling.

[0044] In some aspects, the role of subnet 106 and the coordination role of MN 104 with respect to its subnet 106 can be completely transparent to the wider network. Thus, base station 108 may be unaware of subnet 106, and the wider network may be unaware that MN 104 is the middleman. In essence, MN 104 may act as a subnet UE. This may be accomplished by MN 104 performing communications with base station 108 using the cell radio network temporary identifier (C-RNTI) of the subnet UE. Thus, base station 108 may communicate with various subnet UEs, but is actually physically connected to MN 104.

[0045] This type of communication may present various challenges to be addressed. For example, MN 104 may need to have the ability to instantiate multiple UP / CP entities for all impersonated devices, and may need to be able to send / receive in parallel on behalf of each impersonated device. MN 104 may need to ensure that its device capabilities are not exceeded when performing these services.

[0046] In this case, base station 108 may serve each subnet UE via a direct physical connection terminated at MN 104. Base station 108 may maintain an independent context for each subnet UE and may maintain individual processes (e.g., layer 3 (L3), layer 1 (L1), channel state information (CSI) measurement / reporting, location area (LA), tracking area (TA), etc.) for each subnet UE. This may require the same base station and bandwidth resources as in the case without subnets. Therefore, this case may have limited aggregation benefits or optimizations due to the use of subnet 106.

[0047] In other aspects of the present disclosure, base station 108 may be aware of MN 104 and its role in managing local devices. This may include new CP and UP functionality. With respect to UP functionality, the data plane for a particular subnet UE may be handled in a transparent manner through the physical connection of the MN-base station interface. Various embodiments describe aspects of the MN-base station interface that facilitate deployment of flexible subnets.

[0048] In a first aspect of the disclosure, a virtual UE connection may be provided via a single physical connection over the MN-BS interface.

[0049] In a first aspect, the subnet UEs may register with a wider network. The wider network may manage at least some features of the subnet 106 at a higher level. In this embodiment, the base station 108 may maintain a UE context for each UE that has a virtual or physical connection with the base station 108. The base station 108 may maintain the UE context when the UE is inside or outside the subnet 106.

[0050] The wider network may control resources and mobility decisions for UEs globally (eg, regarding handovers between different base stations).

[0051] Base station 108 may know which UEs are part of subnet 106 controlled by MN 104. Base station 108 may send information to subnet UEs through MN 104. For example, a wider network may send paging, user data, non-access stratum (NAS) control information, etc. through a virtual connection between base station 108 and subnet UEs. Signaling for the virtual connection may be performed through a first physical connection on an MN-BS interface (e.g., between MN 104 and base station 108) and a second physical connection on an MN-UE interface (e.g., between MN 104 and subnet UEs). Therefore, base station 108 may only require one physical connection with MN 104 to provide services to MN 104 and all subnet UEs. Physical layer operations (e.g., channel estimation, CSI measurement, link adaptation, timing advance (TA), L3 measurement reporting, etc.) performed on one physical connection may be utilized across MN 104 and subnet UEs. In contrast, communications with UEs (e.g., UE 4) outside subnet 106 may involve various physical layer operations for various physical connections.

[0052] The single physical connection to MN 104 may limit the maximum capacity / bandwidth of all UEs managed by MN 104. This may impact the scheduler of base station 108, since it must serve subnet UEs as virtual UEs via MN 104. This may involve the need to serve MN 104 more frequently than non-subnet UEs. In addition, the bandwidth provided to MN 104 may need to be shared among the UEs managed by the MN.

[0053] Relying on one physical connection between MN 104 and base station 108 may allow reducing UE context and related processing efforts for base station 108 and subnet UEs, since all link related information (L1 configuration, etc.) may be derived from the MN context.

[0054] Figure 21. Configuration 200 stored at base station 108 to facilitate communications within network environment 100 is illustrated in accordance with some embodiments. Configuration 200 may include MN context 204 associated with MN 104 and UE context 208 associated with subnet UE. MN context 204 may include parameters for physical layer operations associated with a physical connection between MN 104 and base station 108. These parameters may include, for example, L1 configuration, measurement configuration, and security context to allow encryption / integrity verification of communications over the physical connection (e.g., at the physical layer). UE context 208 may include parameters for communications over a virtual connection between subnet UE and base station 108. These parameters may include, for example, SN UE ID (SN_UEID) and security context to allow encryption / integrity verification of communications over the virtual connection (e.g., at a layer above the physical layer).

[0055] In some embodiments, the UE context 208 may not include parameters applied to physical layer operations. Therefore, the UE context 208 may also be referred to as a partial UE context 208.

[0056] SN_UEID may be the identity of a subnet UE that is valid in the RAN when the subnet UE is connected to the base station 108 via the subnet 106. The SN_UEID may be used to identify / address the subnet UE from the RAN / BS side. In the case where multiple subnets are coupled to one base station, the SN_UEID may also be used to identify a specific subnet. The SN_UEID may additionally / alternatively be used for routing within the subnet 106 (e.g., between the MN 104 and a specific subnet UE) or even for local inter-subnet communications (e.g., device-to-device (D2D) communications between subnet UEs (e.g., UE2<->UE3)).

[0057] The base station 108 may use the SN UE ID to link the UE context 208 to the MN context 204. This link may be updated when the UE enters or leaves the subnet 106 as appropriate.

[0058] It may be noted that if the subnet UE is in a radio resource control (RRC) idle mode, the subnet UE may have no or little direct interaction with the RAN. In this case, the base station 108 may not need to maintain a valid SN UE ID, because the MN 104 may handle communications to the subnet UE without RAN involvement. For example, the MN 104 may listen to paging messages directed to the idle subnet UE.

[0059] In some embodiments, when a subnet UE enters RRC connected mode through subnet 106, base station 108 may assign a SN_UEID to the subnet UE.

[0060] To allow the base station 108 to properly direct data to / from the subnet UE, the base station 108 may maintain an identity mapping 212. The identity mapping 212 may map the SN_UEID to an identity of the subnet UE used in a wider network, such as a temporary mobile subscriber identity (TMSI). The SN UE ID may be mapped to the TMSI in a 1:1 manner. As shown, SN_UEID 'X' may be mapped to TMSI 'B', and SN_UEID 'Y' may be mapped to TMSI 'C'.

[0061] Figure 3 is a signaling diagram 300 illustrating UE 4 entering subnet 106 according to some embodiments.

[0062] The signaling diagram 300 may include that, at 304, UE 4 sends a connection establishment request via SN to MN 104. The connection establishment request via SN may be a request to enter subnet 106. Entering subnet 106 may include having a physical connection with MN 104 and a virtual connection with base station 108. In some embodiments, the request may be sent when UE 4 has a physical connection with base station 108 and wants to transfer the physical connection to MN 104 while maintaining the virtual connection with base station 108. In some embodiments, the request may be sent when UE 4 does not have any connection with base station 108 and wants a physical connection established with MN 104 and a virtual connection established with base station 108.

[0063] In some embodiments, UE 4 may autonomously determine its intent to enter subnet 106. For example, UE 4 may actively determine to enter subnet 106 based on its own without the instruction or control of base station 108.

[0064] The signaling diagram 300 may include the MN 104 forwarding the connection establishment request via the SN to the base station 108 at 308. By forwarding the request, the MN 104 informs the base station 108 that the UE 4 joins the subnet 106 and requests a connection via the MN 104.

[0065] At 312, base station 108 may generate a SN UE ID to be assigned to UE 4. As shown, SN_UEID for UE 4 may be 'X'.

[0066] At 316, base station 108 may update the mapping table. The mapping table may be updated to associate UE 4 with MN 104. For example, the MN context may be associated with the UE 4 context. The update of the mapping table may additionally / alternatively associate the SN_UEID assigned to UE 4 with another ID of UE 4 (e.g., TMSI).

[0067] Figure 4 A configuration 400 stored at a base station 108 to describe updates to a mapping table is illustrated according to some embodiments. The configuration 400 may include a MN context 404 associated with the MN 104 and a UE context 408 associated with the UE 4. Similar to the configuration 200, the MN context 404 may include parameters for physical layer operations associated with a physical connection between the MN 104 and the base station 108, and the UE context 408 may include parameters for communications over a virtual connection between the UE 4 and the base station 108.

[0068] In some embodiments, configuration 400 may also include UE context 416, which may represent a full UE context. UE context 416 may provide parameters that may be used to provide connectivity at both the physical layer and higher logical layers to UE 4. This may be used when UE 4 has a physical connection with base station 108. In some embodiments, when UE 4 enters subnet 106, partial UE context 408 may be generated from full UE context 416 and linked to MN context 404 through SN UE ID.

[0069] When the SN_UEID is generated, the identity mapping 412 may also be updated to link the SN_UEID 'X' to TMSI 'B' or another UE identity.

[0070] The signaling diagram 300 may also include, at 320, the base station 108 sending the assigned SN_UEID to the MN 104. At 324, the MN 104 may then forward the assigned SN_UEID to the UE 4. The UE 4 may store the SN_UEID at 328 for use in later communications.

[0071] Figure 5 is a signaling diagram 500 illustrating UE 1 sending data through subnet 106 according to some embodiments.

[0072] Signaling diagram 500 may include, at 504, UE 1 performing connection setup with base station 108 via MN 104. Connection setup may assign SN_UEID 'Y' to UE 1 in a manner similar to that described above with respect to signaling diagram 300.

[0073] The signaling diagram 500 may further include, at 508 , UE 1 marking uplink data with SN_UEID=Y. The uplink data may be associated with an RRC message to be transmitted by UE 1 to base station 108 via MN 104 .

[0074] The signaling diagram 500 may also include: at 512, transmitting local subnet data. This may be used to provide uplink data to the MN 104. In some embodiments, the local subnet data transmission may be performed on resources scheduled by the MN 104 in a licensed or unlicensed spectrum. In some embodiments, the UE 1 may perform a clear channel assessment (CCA) to identify available resources shared by the subnet UEs. The UE 1 may then use the available resources to provide data to the MN 104.

[0075] Upon receiving the uplink data, MN 104 may transmit data tagged with SN_UEID=Y to base station 108 at 516. MN 104 may transmit the data on uplink resources scheduled by base station 108. The data may be transmitted using the identity of MN 104 (e.g., C-RNTI of MN 104).

[0076] The signaling diagram 500 may also include the base station 108 mapping the received data to the associated UE based on the SN_UEID tag at 520. For example, the base station 108 may use the SN_UEID to map the data received with the C-RNTI of the MN 104 to the correct UE context of UE 1. Then, at 524, the base station 108 may perform UE 1 related processing to process the tagged data based on the parameters of the UE 1 context. For example, if the tagged data is in an RRC message, the base station 108 may know which UE it was received from and act accordingly, for example, reply with an RRC reconfiguration message.

[0077] If base station 108 receives (or generates) downlink data directed to UE 1, base station 108 may map the UE ID associated with the downlink data as received by base station 108 to SN_UEID 'Y' based on identity mapping 412. At 528, base station 108 may then tag the UE 1 data with SN_UEID = Y. In some examples, the downlink data may be associated with an RRC message that base station 108 is to transmit to UE 1 via MN 104.

[0078] The base station 108 may access the UE 1 context based on SN_UEID=Y and identify the linked MN context.Then, at 532, the base station 108 may transmit the tag data to the MN 104 using the MN context.

[0079] MN 104 and UE 1 may perform a local subnet data transfer at 536 to provide data from MN 104 to UE 1. The local subnet data transfer may be performed on subnet resources scheduled by MN 104.

[0080] At 540 , UE 1 may unpack and process the message received from MN 104 .

[0081] Figure 6 is a signaling diagram 600 illustrating a UE 4 moving out of a subnet 106 according to some embodiments. In the signaling diagram 600, the UE 4 is included leaving the subnet 106 and using its SN_UEID to indicate its subnet identity during RACH / connection setup.

[0082] Signaling diagram 600 may include, at 604, UE 4 performing connection setup with base station 108 via MN 104. Connection setup may assign SN_UEID 'X' to UE 4 in a manner similar to that described above with respect to signaling diagram 300.

[0083] At 608 , UE 4 may move out of subnet 106 .

[0084] The signaling diagram 600 may include, at 612, the UE 4 and the base station 108 performing initial signaling of a random access channel (RACH) procedure. The initial signaling may include the UE 4 sending a random access (RA) preamble to the base station 108 in a message 1 (MSG1) transmission. The RA preamble may be selected by the UE 4 from a pool of preambles in a contention-based random access (CBRA) procedure, or may be specifically assigned to the UE 4 in a contention-free random access (CFRA) procedure. The base station 108 may respond with a random access response, which may be referred to as a message 2 (MSG2) transmission, which provides an uplink resource allocation.

[0085] The signaling diagram 600 may also include UE 4 transmitting a common control channel (CCCH) transmission, which may be referred to as a message 3 (MSG3) transmission, at 616. The MSG3 transmission may be marked with SN_UEID=X.

[0086] At 620, base station 108 may map the MSG3 transmission based on the SN_UEID tag. For example, base station 108 may determine that the MSG3 transmission is associated with UE 4 based on the SN_UEID 'X' tag.

[0087] Base station 108 may access the partial UE context associated with SN_UEID 'X' (e.g., UE context 408) and the MN context linked to the partial UE context (e.g., MN context 404). Then, at 624, base station 108 may create an independent UE context for UE 4 (e.g., UE 4 context 416) based on a combination of parameters from the MN context and the partial UE context.

[0088] Then, at 628, base station 108 may perform UE 1 related processing based on the parameters of the independent UE context for UE 4.

[0089] The signaling process may also include, at 632, continuing the RACH process. This may include the base station 108 transmitting a contention resolution message (MSG4), which the UE 4 may decode to determine that the MSG3 transmission was successfully received by the base station 108. The base station 108 may update the RRC state machine, followed by an RRC reconfiguration that establishes a physical connection between the base station 108 and the UE 4, and the SN_UEID assigned to the UE 4 may be released.

[0090] In a second aspect of the disclosure, base station 108 may provide MN 104 with a UE-specific uplink grant for MN 104 .

[0091] Figure 7 is a signaling diagram 700 illustrating a UE-specific uplink grant to the MN 104 according to some embodiments.

[0092] The signaling diagram 700 may include, at 704, UE 1 buffering data to be transmitted in the uplink.

[0093] The signaling diagram 700 includes two options for a buffer status report (BSR) that may be used for data transmission.

[0094] In a first option, which may be referred to as an early BSR option, at 708, UE 1 may transmit a BSR to MN 104. The BSR may indicate the amount of data in a buffer of UE 1. The BSR may additionally / alternatively indicate other characteristics of the data in the buffer, including, for example, the length of time the data has resided in the buffer, the amount of time left to transmit the data in time, etc.

[0095] At 712, MN 104 may forward the UE 1 BSR to base station 108. After transmitting the BSR, at 716, MN 104 may receive uplink data from UE 1 via a local subnet data transmission. The local subnet data transmission may be performed as described elsewhere herein. Upon receiving the data, at 720, MN 104 may buffer the UE 1 data.

[0096] A second option, which may be referred to as a BSR option, may include, at 724, the MN 104 receiving uplink data from the UE 1 via a local subnet data transmission. The local subnet data transmission may be performed as described elsewhere herein. Upon receiving the data, at 728, the MN 104 may buffer the UE 1 data. At 732, the MN 104 may transmit a UE 1 BSR to the base station 108. The BSR may indicate the amount of UE 1 data in the buffer of the MN 104. The BSR may additionally / alternatively indicate other characteristics of the data in the buffer, including, for example, the length of time that the UE 1 data has resided in the buffer, the amount of time left to transmit the UE 1 data in a timely manner, etc. The UE 1 BSR transmitted at 732 may identify the buffering characteristics of the UE 1 data independently of data that may be buffered at the MN 104 for other subnet UEs. While this may take up more memory resources of the MN 104 to allow for per-UE UL buffers, this may also enable UE-specific uplink grants as described below.

[0097] Upon receiving the UE 1 BSR (at 712 or 732), the base station 108 may schedule UE 1. The scheduling of UE 1 may include generating an uplink grant of resources to be used for transmitting UE 1 data. Then, at 740, the signaling diagram 700 may include: At 740, the base station 108 transmits a UL grant for UE 1 to the MN 104. The base station 108 may send the UE-specific UL grant via downlink control information (DCI) or a medium access control (MAC) control element (CE). At 744, the MN 104 may transmit UE 1 data (e.g., an uplink transport block (TB) from UE 1).

[0098] In this way, MN 104 can act as multiple subnet UEs and appropriately utilize UE-specific grants provided by base station 108 for data from subnet UEs. The allocation of grants between subnet UEs is under the control of the wider network, but is implemented by MN 104.

[0099] Signaling diagram 700 illustrates an embodiment in which UE data is buffered at MN 104, which compiles and forwards a per-UE BSR to base station 108. In some instances, this may increase latency for uplink transmissions. In other embodiments, UE data may be scheduled by MN 104 on demand.

[0100] On-demand scheduling may include forwarding a per-UE BSR from the SN UE to the MN 104, and then to the base station 108. The base station 108 then schedules a per-UE UL grant and provides the grant to the MN 104. The MN may then pull the corresponding data from the SN UE and prepare for UL transmission to the base station 108. On-demand scheduling may benefit from a more flexible / dynamic / relaxed UL grant delay.

[0101] Figure 8 is a signaling diagram 800 illustrating that UE data may be scheduled on demand by MN 104 according to some embodiments. Signaling diagram 800 may include: At 804, UE 1 and MN 104 perform measurements of subnets. These measurements may determine the channel quality / capacity of the physical connection between UE 1 and MN 104. In some embodiments, the SN measurements may determine the latency and bandwidth characteristics of the physical connection.

[0102] Signaling diagram 800 may also include, at 808, MN 104 determining UE 1 scheduling constraints and transmitting the scheduling constraints to base station 108. Scheduling constraints may provide, for example, relaxed N2 capabilities for initial transmissions. N2 capabilities may provide the minimum time required by a UE between reception of a UL grant and its scheduled UL resources.

[0103] The scheduling constraints may accommodate local link conditions (e.g., the path between the MN 104 and the UE 4) and the time required for the MN 104 to pull data from within the subnet and deliver it to the base station 108. For example, if the local link is BW limited or has poor quality, the MN 104 may incorporate multiple transmissions and / or potential retransmission (ReTx) attempts into the UE 4's N2 capabilities associated with the MN.

[0104] In some embodiments, MN 104 may also consider its own N2 capabilities to derive the N2 capabilities associated with each UE. In some instances, base station 108 may be provided with one N2 capability that has the N2 capabilities of both UE 1 and MN 104. In other embodiments, separate N2 capabilities may be provided.

[0105] In some embodiments, the scheduling constraints may provide different sets of N2 capabilities per UE. For example, one set may provide independent N2 capabilities of UE 1 (which may be used when base station 108 has a physical connection with UE 1) and N2 capabilities associated with the MN (which may be used when UE 1 is connected through subnet 106).

[0106] N2 capability reporting can be periodic or event driven. This can help adapt to changing conditions in the subnet 106.

[0107] In some embodiments, the scheduling constraints may additionally / alternatively include other per-UE restrictions that may facilitate predictable subnet scheduling. For example, in some embodiments, the scheduling constraints may include a limit on the peak throughput of UE 1. This may be done, for example, by setting a maximum transport block size to encourage more frequent but smaller TB transmissions.

[0108] In some embodiments, the scheduling constraints may additionally / alternatively include other per-UE restrictions to address subnet characteristics or reduce MN complexity. For example, the scheduling constraints may include one or more time division duplex (TDD) modes that may be used by a particular subnet UE or a restriction on the number of subnet UEs to be scheduled in parallel.

[0109] In some embodiments, scheduling constraints may be most useful for an indirect connection between the base station 108 and the target UE to accommodate traversal through one or more intermediate nodes and additional latency when scheduling data residing in a UE buffer.

[0110] At 812, the base station 108 may store the UE 1 scheduling constraints.

[0111] At 816, UE 1 may have buffered data to transmit in an uplink transmission. At 820, UE 1 may send a UE 1 BSR to MN 104. The BSR may be similar to that described elsewhere herein. At 824, MN 104 may forward the UE 1 BSR to base station 108.

[0112] At 828, base station 108 may schedule UE 1. In performing the scheduling, BS 108 may consider whether UE 1 is operating as a standalone UE (in which case standalone N2 capabilities will be used) or through subnet 106 (in which case N2 capabilities associated with the MN may be used). Then, at 832, base station 108 may transmit an uplink grant for UE 1. The UL grant may schedule UL resources to be used for transmitting UE 1 data.

[0113] At 836, MN 104 and UE 1 may perform a local subnet data transfer. This may be performed similarly as described elsewhere herein. In some embodiments, the subnet data transfer may allow for multiple segment transmissions and potential hybrid automatic repeat request (HARQ) retransmissions on subnet 106. This may enable MN 104 to accurately and completely collect UE 1 data.

[0114] If UE 1 data is ready for transmission in the UL resources scheduled by the UL grant, the signaling diagram may proceed to MN 104 transmitting UE 1 data (e.g., uplink TB) to base station 108 at 840. If UE 1 data is not ready for transmission in the uplink resources scheduled by the uplink grant, MN 104 may ignore the grant and send padding bits to base station 108 to indicate that a wider network may reuse these resources.

[0115] In some embodiments, HARQ retransmissions may be enabled on the connection between the MN 104 and the base station 108. For example, at 844, the MN 104 may buffer the UE 1 data in a HARQ buffer of the MN 104. If the base station 108 does not successfully receive the transmission, it may schedule a HARQ retransmission at 848 and transmit an indication of the HARQ retransmission to the MN 104 at 852. Then, at 856, the MN 104 may transmit the UE 1 data (e.g., UL TB) from the HARQ buffer to the base station 108.

[0116] Although signaling diagram 800 applies to uplink transmissions, similar concepts can also be applied to downlink transmissions. For example, the scheduling delay (e.g., k0 parameter) between the DCI indicating the physical downlink shared channel (PDSCH) and the actual transmission can be more flexible / dynamic to allow the MN 104 to have indicated incoming DL transmissions to the corresponding target UE or to reserve downstream capacity.

[0117] In a third aspect of the disclosure, the MN 104 and the base station 108 may employ a subnet tunneling protocol to facilitate subnet operations.

[0118] Fig. 9 A network environment 100 with Sub-Network Tunneling Protocol (SN-TP) aspects is illustrated according to some embodiments.

[0119] A subnet UE may have multiple QoS flows (QFIs), which, if each QFI is mapped 1:1 to a DRB, are aggregated into many data radio bearers (DRBs) / logical channel (LC) entities in the MN 104 and the base station 108. Therefore, some embodiments aggregate different subnet UEs or UE QoS flows into fewer (or even one) DRBs / RLC channels / LC entities between the MN 104 and the base station 108. This can help limit the complexity of the MN 104 in terms of the number of DRBs / LC entities it must provide for each device in the subnet 106.

[0120] SN-TP signaling may be used to carry UE / QoS flow mapping information per packet between MN 104 and base station 108. SN-TP signaling may be performed between SN-TP layers on MN 104 and base station 108. For example, in the downlink, the SN-TP layer at base station 108 may add SN-TP information to packets of UE-specific data planes (e.g., UE 1 data plane, UE 2 data plane, and UE 3 data plane). The SN-TP information that may be added in the SN-TP header may indicate which UE is targeted and which QoS flow to use. MN 104 may access the SN-TP information from the SN-TP header and determine how to forward data to the UE through the subnet. In the uplink, the SN-TP layer at MN 104 may map the information provided by the SN (which may include information about the QoS flow used in subnet 106) to the SN-TP information. The SN-TP information may be added to the SN-TP header of the uplink packet. The SN-TP information may provide an indication to the base station 108 of the DRB / LC to which uplink data from the subnet UEs will be mapped.

[0121] The SN-TP layer may be placed at various locations within the network protocol stack, depending on where within the subnet 106 the subnet UE traffic is to be aggregated. Fig.10 Two options for implementing the SN-TP layer according to some embodiments are illustrated.

[0122] In the first option 1000, the SN-TP layer is placed above the RLC layer. This can enable multiplexing of SN traffic into a single RLC channel, a single RLC channel for each UE within the subnet 106, or a single RLC channel for each UE RLC channel. In some examples, placing the SN-TP layer above the RLC layer can enable aggregating all DRBs of a UE into a single DRB for the UE.

[0123] Deploying the SN-TP layer on top of the RLC layer may enable various aggregation options, each of which may include benefits and challenges.

[0124] A first aggregation option may include aggregating all DRBs / QFIs for all UEs into one RLC channel. The resulting benefits may include only needing to support one additional RLC channel between the MN 104 and the base station 108. The resulting challenges may include that such aggregation may create inter-UE dependencies (e.g., RLC retransmissions of UE packets may cause head-of-line blocking for other UEs).

[0125] A second aggregation option may include aggregating all DRBs / QFIs for a single UE into one RLC channel. A resulting benefit may be reduced / eliminated inter-UE dependencies within the RLC, as each UE may have its own channel, and per-UE prioritization may be enabled to ensure end-to-end (E2E) QoS over the subnet 106. A resulting challenge may involve inter-DRB dependencies for traffic from different DRBs for a single UE, or the number of RLC channels scaling with the subnet size. A possible mitigation may be to group UEs into multiple RLC channels (e.g., n:1).

[0126] A third aggregation option may include aggregating all QFIs across UEs into one RLC channel. The resulting benefit may be that multiple RLC channels are bound to multiple QFIs used in a subnet. The resulting challenge may be that it creates inter-UE dependencies (RLC retransmissions of UE packets with QFI=x may cause head-of-line blocking of other UE QFI=x packets).

[0127] In the second option 1004, the SN-TP layer is placed below the RLC layer. This allows the independent UE LCs to be multiplexed into a common per-UE TB. In this way, different HARQ processes can be maintained for different subnet UEs.

[0128] Although Fig.10 Two options for SN-TP layer placement are shown, but other arrangements may be used in other embodiments. For example, the SN-TP layer may be placed above PDCP or above SDAP.

[0129] In some embodiments, the arrangement of the SN-TP layer may be based on the capabilities of the MN 104 or base station 108. The arrangement may be agreed upon during the formation of the subnet 106 or reconfigured during the lifetime of the subnet 106. For example, when the latency requirements of a certain subnet UE require isolation on the Uu interface, the arrangement of the SN-TP layer may be reconfigured.

[0130] Depending on where the SN-TP layer is deployed, it may carry different mapping information between the MN 104 and the base station 108 in order to identify the correct UE-related protocol entity. For example, if the SN-TP layer is above the RLC as shown in Option 1, the SN-TP layer may provide SN-TP information such as UE ID and resource bearer (e.g., DRB) ID. And, if the SN-TP layer is below the RLC as shown in Option 2, the SN-TP layer may provide SN-TP information such as UE ID and LC ID.

[0131] Embodiments of the present disclosure are associated with a variety of benefits compared to integrated access and backhaul (IAB) / sidelink (SL) relays. Some of these benefits may be due to the ability of the subnet to use any technology and licensed / unlicensed spectrum. This may provide greater flexibility because the MN 104 and base station 108 may negotiate certain characteristics (e.g., scheduling constraints, maximum bandwidth), and then the MN 104 may deploy the subnet 106 without further constraints from the wider network.

[0132] Compared to IAB / SL relay, intra-subnet link scheduling, node configuration, and mobility may not be visible to the wider network. This can increase subnet transparency and reduce complexity in the wider network. Although base station 108 can maintain an anchor point for subnet UEs, base station 108 can schedule subnet UEs behind MN 104 in the same way as if the UE was directly connected to base station 108. Subnet 106 is not controlled by the wider network and its internals are transparent. Topology changes in subnet 106 do not rely on the wider network, and in some cases, the wider network may only be aware of subnet operations in the case of inter-MN mobility or UE entering / leaving subnet 106.

[0133] The complexity of MN 104 may be lower than that of an IAB node. MN 104 may have a relatively simple scheduler directed by base station 108. The main logic of fair scheduling across different users remains in base station 108 and does not change.

[0134] In some embodiments, MN controlled subnets move subnet formation / control towards the UE. In these embodiments, the use case may change from a network operator owned use case to a UE / subscriber owned use case.

[0135] Compared to IAB / SL relay, the QoS of the MN-controlled subnet can be managed by the base station from outside the subnet without full control of the subnet. In IAB, the base station handles the aggregated traffic from its child IAB nodes and configures and controls all IAB nodes along the path. In SL relay, the base station schedules PC5 links along the path (mode 1), or UEs communicate autonomously in a D2D manner (mode 2), and there is no MN-controlled subnet.

[0136] In the subnet controlled by the MN, the base station of the RAN can maintain E2E QoS for each UE and each UE's LC. This can be done by scheduling UEs individually while abstracting subnet characteristics (e.g., bandwidth limitations and latency / scheduling constraints) to the wider network.

[0137] Fig.111100 according to some embodiments. For example, the operation flow / algorithm structure 1100 may be performed by a base station (such as base station 108, base station 1500) or a component thereof (eg, processor 1504).

[0138] The operation flow / algorithm structure 1100 may include receiving a connection establishment request at 1104. The connection establishment request may be received from a MN of a subnet. The connection establishment request may request that the UE be admitted to a RAN controlled by a base station via the subnet.

[0139] The operation flow / algorithm structure 1100 may also include: at 1108, assigning the SN_UEID to the UE. In some embodiments, the SN_UEID assigned to the UE may be populated in a partial UE context that may be derived from the full UE context. In addition to the SN_UEID, the partial UE context may also include a security context associated with the UE. The security context may be used to protect communications transmitted over a virtual connection between a base station and the UE. The partial UE context may be linked to the context of the MN from which the connection establishment request was received. The MN context may include parameters applicable to communications over a direct connection with the MN. These parameters may include, for example, L1 configuration, measurement configuration, and a security context associated with the MN.

[0140] In some implementations, the SN_UEID assigned to the UE may also be linked with the UE's ID (eg, the UE's TMSI) used in communications via the wider network.

[0141] The operation flow / algorithm structure 1100 may further include outputting an indication of the SN_UEID at 1112. The indication may be output for transmission to the MN from which the communication establishment request was received.

[0142] After transmitting the indication of the SN_UEID, the base station may receive a transmission from the MN. The transmission may be received based on the C-RNTI of the MN and may include data and an indication of the SN_UEID. The base station may use the SN_UEID to identify partial UE context and other UE IDs (e.g., the UE's TMSI), and may forward data based on the context and other UE IDs.

[0143] The base station may receive data directed to the UE from an external network. The data may be associated with another UE ID (e.g., the TMSI of the UE). The base station may map the other UE ID to the SN_UEID and access the partial UE context and the linked MN context based on the mapping. The base station may then transmit the data to the UE via the MN based on the partial UE context and the MN context. The transmission may include an indication of the SN_UEID so that the MN can route the data to the UE through the subnet.

[0144] In some embodiments, the base station may receive a RACH transmission (e.g., a MSG3 transmission) with an indication of the SN_UEID. The base station may identify the partial UE context and the MN context based on the SN_UEID and generate an independent UE context by combining parameters from the two contexts. The base station may then transmit a response to the RACH transmission (e.g., a MSG4 transmission) to establish a direct connection with the UE.

[0145] Fig.12 12 is an operational flow / algorithm structure 1200 according to some embodiments. The operational flow / algorithm structure 1200 may be performed by a MN (such as MN 104, UE 1400) or a component thereof (eg, processor 1404).

[0146] The operational flow / algorithm structure 1200 may include: at 1204, transmitting a BSR indicating the status of an uplink transmission buffer associated with a subnet UE. In some embodiments, the uplink transmission buffer may be on the MN. The MN may receive data from the subnet UE and store the data in an uplink transmission buffer dedicated to the subnet UE. The MN may then generate a BSR based on its uplink transmission buffer. In other embodiments, the uplink transmission buffer may be on the subnet UE. In this case, the MN may receive the BSR from the subnet UE and forward the BSR to the base station. The MN may then receive data from the subnet UE.

[0147] The operational flow / algorithm structure 1200 may also include receiving an uplink grant at 1208. The uplink grant may schedule resources to be used for uplink transmission of data from the subnet UE. In some embodiments, the scheduled resources may be dedicated to data from the subnet UE.

[0148] The operational flow / algorithm structure 1200 may also include, at 1212, outputting data for transmission using resources indicated by the uplink grant.

[0149] In some embodiments, the MN may determine the scheduling constraints for the subnet UEs and provide an indication of the scheduling constraints to the base station. This may be based on the condition of the link between the MN and the subnet UE. The scheduling constraints may provide a time value required between the reception of an uplink grant and the transmission of uplink data. In some embodiments, the scheduling constraints may be scheduling constraints associated with the MN that apply when the UE is connected to the subnet, and the MN may also provide independent scheduling constraints that apply when the UE has a direct connection with the base station. The transmission of the indication of the scheduling constraints may be based on a detected event. The event may be a periodic event (e.g., expiration of a timer) or a condition (e.g., a change in the characteristics of the subnet).

[0150] Fig.13 1300 according to some embodiments. For example, the operation flow / algorithm structure 1300 may be performed by a base station (such as base station 108, base station 1500) or a component thereof (eg, processor 1504).

[0151] The operational flow / algorithm structure 1300 may include receiving traffic for one or more subnet UEs, at 1304. In some embodiments, the traffic may be received via multiple QoS flows.

[0152] The operation flow / algorithm structure 1300 may also include: at 1308, aggregating the traffic into LCs or radio bearers (RBs) (e.g., DRBs or signaling radio bearers (SRBs)). In some embodiments, the aggregation of the traffic may be performed by generating packets with SN-TP headers. Each SN-TP header may include mapping information associated with the LC or RB. In some instances, the mapping information may map the QoS flow to the LC / RB. The mapping information may include an identity associated with the UE (e.g., UE ID) and an indication of the LC or RB (e.g., LC / RB ID). The UE ID may be a SN_UEID or an identity used at a wider network layer.

[0153] The operation flow / algorithm structure 1300 may also include, at 1312, outputting the traffic for transmission to the MN via the LC or the RB.

[0154] In some embodiments, the operation flow / algorithm structure 1300 may be implemented by the SN-TP layer of the base station. The SN-TP layer may be above or below the RLC layer of the base station. The location of the SN-TP layer may be dynamically configured based on, for example, the desired goals of a particular situation.

[0155] Although Figures 11 to 13 The order of operations may be implied, but it should be understood that in other embodiments, these operations are performed in a different order, or one or more of these operations can be performed simultaneously. In addition, it should be understood that in other embodiments, one or more additional operations may be included in the operational flow / algorithm structure, or one or more of these operations may be omitted.

[0156] Fig.14An example UE 1400 according to some embodiments is illustrated. UE 1400 can be any mobile or non-mobile computing device, such as, for example, a mobile phone, a computer, a tablet, an industrial wireless sensor (e.g., a microphone, a carbon dioxide sensor, a pressure sensor, a humidity sensor, a thermometer, a motion sensor, an accelerometer, a laser scanner, a fluid level sensor, an inventory sensor, a voltage / current meter, an actuator, etc.), a video surveillance / monitoring device (e.g., a camera, a camcorder, etc.), a wearable device (e.g., a smart watch), a loose IoT device.

[0157] UE 1400 may include a processor 1404, RF interface circuitry 1408, memory / storage 1412, a user interface 1416, a sensor 1420, a driver circuit 1422, a power management integrated circuit (PMIC) 1424, antenna structures 1426, and a battery 1428. The components of UE 1400 may be implemented as an integrated circuit (IC), a portion of an integrated circuit, a discrete electronic device, or other module, logic, hardware, software, firmware, or a combination thereof. Fig.14 The block diagram of UE 1400 is intended to show a high-level view of certain of the components of UE 1400. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other implementations.

[0158] Components of UE 1400 may be coupled to various other components via one or more interconnects 1432, which may represent any type of interface, input / output, bus (local, system, or extension), transmission line, trace, optical connection, etc., which allows various circuit components (on a common or different chip or chipset) to interact with each other.

[0159] The processor 1404 may include processor circuits, such as, for example, a baseband processor circuit (BB) 1404A, a central processor unit circuit (CPU) 1404B, and a graphics processor unit circuit (GPU) 1404C. The processor 1404 may include any type of circuit or processor circuit that executes or otherwise operates computer-executable instructions (such as program codes, software modules, or functional processes from the memory / storage device 1412) to cause the UE 1400 to perform operations, such as reference Figures 11 to 13 Or those operations described elsewhere herein. In some embodiments, the instructions may implement the SN-TP layer to perform some or all of these operations.

[0160] In some embodiments, the baseband processor circuit 1404A can access the communication protocol stack 1436 in the memory / storage device 1412 to communicate through a 3GPP compatible network. Generally speaking, the baseband processor circuit 1404A can access the communication protocol stack to: perform user plane functions at the PHY layer, MAC layer, RLC layer, SN-TP layer, PDCP layer, SDAP layer, and PDU layer; and perform control plane functions at the PHY layer, MAC layer, RLC layer, SN-TP layer, PDCP layer, RRC layer, and non-access layer. In some embodiments, the PHY layer operations can be additionally / alternatively performed by components of the RF interface circuit 1408.

[0161] The baseband processor circuit 1404A may generate or process baseband signals or waveforms that carry information in a 3GPP-compliant network.

[0162] The memory / storage 1412 may include one or more non-transitory computer-readable media including instructions (e.g., the communication protocol stack 1436) that may be executed by one or more processors in the processor 1404 to cause the UE 1400 to perform various operations described herein. The memory / storage 1412 includes any type of volatile or non-volatile memory that may be distributed throughout the UE 1400. In some embodiments, some of the memory / storage 1412 may be located on the processor 1404 itself (e.g., L1 cache and L2 cache), while other memory / storage 1412 is located external to the processor 1404 but accessible via a memory interface. The memory / storage 1412 may include any suitable volatile or non-volatile memory, such as, but not limited to, dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory, or any other type of memory device technology.

[0163] The RF interface circuit 1408 may include a transceiver circuit and a radio frequency front end module (RFEM), which allows the UE 1400 to communicate with other devices through a radio access network. The RF interface circuit 1408 may include various components arranged in a transmission path or a reception path. These components may include, for example, switches, mixers, amplifiers, filters, synthesizer circuits, control circuits, etc.

[0164] In the receive path, the RFEM may receive the radiated signal from the air interface via the antenna structure 1426 and proceed to filter and amplify the signal (using a low noise amplifier). The signal may be provided to the transceiver's receiver, which down-converts the RF signal to a baseband signal that is provided to the baseband processor of the processor 1404.

[0165] In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM may amplify the signal through a power amplifier before the RF signal is radiated across the air interface via the antenna structure 1426.

[0166] In various embodiments, the RF interface circuit 1408 may be configured to transmit / receive signals in a manner compatible with NR access technology.

[0167] The antenna structure 1426 may include antenna elements to convert electrical signals into radio waves to travel through the air and convert received radio waves into electrical signals. These antenna elements may be arranged into one or more antenna panels. The antenna structure 1426 may have antenna panels that are omnidirectional, directional, or a combination thereof to enable beamforming and multiple input / multiple output communications. The antenna structure 1426 may include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, phased array antennas, and the like. The antenna structure 1426 may have one or more panels that are designed for a specific frequency band including a band in FR1 or FR2.

[0168] The user interface 1416 includes various input / output (I / O) devices designed to enable the user to interact with the UE 1400. The user interface 1416 includes input device circuits and output device circuits. The input device circuit includes any physical or virtual components for accepting input, especially including one or more physical or virtual buttons (e.g., reset button), physical keyboard, keypad, mouse, touch pad, touch screen, microphone, scanner, headset, etc. The output device circuit includes any physical or virtual components for showing information or otherwise conveying information (such as sensor readings, actuator positions, or other similar information). The output device circuit may include any number or combination of audio or visual displays, especially including one or more simple visual outputs / indicators (e.g., binary state indicators (such as light emitting diodes "LEDs") and multi-character visual outputs) or more complex outputs (such as display devices or touch screens (e.g., liquid crystal displays (LCDs), LED displays, quantum dot displays, projectors, etc.)), where the output of characters, graphics, multimedia objects, etc. is generated or produced by the operation of the UE 1400.

[0169] Sensors 1420 may include devices, modules, or subsystems whose purpose is to detect events or changes in their environment, and to send information about the detected events (sensor data) to some other device, module, subsystem, etc. Examples of such sensors include, among others: an inertial measurement unit including an accelerometer, gyroscope, or magnetometer; a microelectromechanical system or nanoelectromechanical system including a three-axis accelerometer, a three-axis gyroscope, or a magnetometer; a level sensor; a flow sensor; a temperature sensor (e.g., a thermistor); a pressure sensor; a barometric pressure sensor; a gravity meter; an altimeter; an image capture device (e.g., a camera or a lensless aperture); a light detection and ranging sensor; a proximity sensor (e.g., an infrared radiation detector, etc.); a depth sensor; an ambient light sensor; an ultrasonic transceiver; a microphone or other similar audio capture device; and the like.

[0170] The driver circuit 1422 may include software and hardware elements for controlling specific devices embedded in, attached to, or otherwise communicatively coupled to the UE 1400. The driver circuit 1422 may include various drivers to allow other components to interact with or control various input / output (I / O) devices that may be present in or connected to the UE 1400. For example, the driver circuit 1422 may include: a display driver for controlling and allowing access to a display device, a touch screen driver for controlling and allowing access to a touch screen interface, a sensor driver for obtaining sensor readings of the sensor 1420 and controlling and allowing access to the sensor 1420, a driver for obtaining an actuator position of an electromechanical component or controlling and allowing access to an electromechanical component, a camera driver for controlling and allowing access to an embedded image capture device, and an audio driver for controlling and allowing access to one or more audio devices.

[0171] The PMIC 1424 may manage the power provided to various components of the UE 1400. Specifically, with respect to the processor 1404, the PMIC 1424 may control power source selection, voltage scaling, battery charging, or DC-DC conversion.

[0172] In some embodiments, the PMIC 1424 may control or otherwise be part of various power saving mechanisms of the UE 1400. For example, if the platform UE is in the RRC_Connected state, in which the platform is still connected to the RAN node because it expects to receive traffic soon, then after a period of inactivity, the platform may enter a state known as discontinuous reception mode (DRX). During this state, the UE 1400 may be powered off for short time intervals, thereby saving power. If there is no data traffic activity for an extended period of time, the UE 1400 may transition to the RRC_Idle state, in which the UE is disconnected from the network and no operations are performed, such as channel quality feedback, handover, etc. The UE 1400 enters a very low power state and performs paging, in which the UE wakes up again periodically to listen to the network and then powers off again. The UE 1400 may not receive data in this state; in order to receive data, the platform must transition back to the RRC_Connected state. Additional power saving modes may prevent the device from using the network for a time exceeding the paging interval (from a few seconds to a few hours). During this time, the device is completely unable to connect to the network and can be completely powered off. Any data sent during this time will incur significant latency, and it is assumed that latency is acceptable.

[0173] The battery 1428 can power the UE 1400, but in some examples, the UE 1400 can be installed and deployed in a fixed location and can have a power source coupled to the power grid. The battery 1428 can be a lithium-ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some specific implementations, such as in vehicle-based applications, the battery 1428 can be a typical lead-acid car battery.

[0174] Fig.15 An example base station 1500 is illustrated in accordance with some embodiments. The base station 1500 may include a processor 1504, an RF interface circuit 1508, a core network (CN) interface circuit 1512, a memory / storage 1516, and antenna structures 1526.

[0175] Components of base station 1500 may be coupled to various other components via one or more interconnects 1528 .

[0176] The processor 1504, RF interface circuit 1508, memory / storage 1516 (including communication protocol stack 1510), antenna structure 1526 and interconnect 1528 may be similar to those of reference Fig.14 Like named elements are shown and described.

[0177] Processor 1504 may include any type of circuit or processor circuitry that executes or otherwise operates computer-executable instructions (such as program code, software modules, or functional processes from memory / storage device 1516) to cause base station 1500 to perform operations, such as reference Figures 11 to 13 Or those operations described elsewhere herein.

[0178] The CN interface circuit 1512 may provide a connection to a core network (e.g., a 5GC using a 5th generation core network (5GC) compatible network interface protocol such as a carrier Ethernet protocol or some other suitable protocol). The network connection may be provided to / from the base station 1500 via optical fiber or wireless backhaul. The CN interface circuit 1512 may include one or more dedicated processors or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the CN interface circuit 1512 may include multiple controllers for providing connections to other networks using the same or different protocols.

[0179] It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of the authorized use should be clearly stated to users.

[0180] For one or more embodiments, at least one of the components described in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, or methods described in the following example section. For example, the baseband circuit described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples described below. For another example, the circuits associated with the UE, base station, network element, etc. described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples described below in the example section.

[0181] Example

[0182] In the following sections, additional exemplary embodiments are provided.

[0183] Embodiment 1 includes a method to be implemented by a base station of a radio access network (RAN), the method comprising: receiving a connection establishment request from a management node (MN) of a subnet, the connection establishment request being used to request that a user equipment (UE) be admitted to the RAN via the subnet; assigning a subnet (SN) UE identity (ID) to the UE; and, for output, outputting an indication of the SN UE ID for transmission to the MN.

[0184] Embodiment 2 includes the method according to embodiment 1 or some other embodiment herein, the method further comprising: linking the context of the UE with the context of the MN.

[0185] Embodiment 3 includes a method according to embodiment 2 or some other embodiment herein, wherein the context of the UE includes the SN_UEID and a security context associated with the UE, and the context of the MN includes a layer 1 configuration, a measurement configuration, and a security context associated with the MN.

[0186] Embodiment 4 includes the method according to embodiment 1 or some other embodiment herein, further comprising: linking the SN_UEID with a temporary mobile subscriber identity (TMSI) associated with the UE.

[0187] Embodiment 5 includes a method according to embodiment 1 or some other embodiment of the present invention, wherein the method further includes: receiving a transmission including data and an indication of the SN_UEID based on a cell radio network temporary identifier (C-RNTI) associated with the MN; identifying the context of the UE based on the SN_UEID; and forwarding the data based on the context of the UE.

[0188] Embodiment 6 includes the method according to embodiment 1 or some other embodiment of the present invention, and the method further includes: receiving data directed to the UE, the data being associated with the identity of the UE; mapping the identity to the SN_UEID; accessing the context of the UE based on the SN_UEID; accessing the context of the MN associated with the context of the UE; and outputting data for transmission to the UE via the MN based on the context of the MN.

[0189] Embodiment 7 includes the method according to embodiment 6 or some other embodiment herein, the method further comprising: outputting the data and an indication of the SN_UEID.

[0190] Embodiment 8 includes the method according to embodiment 1 or some other embodiment of the present invention, and the method further includes: receiving a random access channel (RACH) transmission with an indication of the SN_UEID from the UE; identifying the context of the UE and the context of the MN based on the SN_UEID; generating an independent UE context based on the context of the UE and the context of the MN; and outputting a response to the RACH transmission to establish a direct connection with the UE.

[0191] Embodiment 9 includes a method to be implemented by a management node (MN) of a subnet, the method comprising: transmitting a buffer status report (BSR) to a base station, the buffer status report (BSR) indicating a status of an uplink transmission buffer associated with a user equipment (UE) of the subnet; receiving an uplink grant from the base station, the uplink grant scheduling resources to be used for uplink transmission of data from the UE; and outputting the data from the UE using the resources.

[0192] Embodiment 10 includes a method according to embodiment 9 or some other embodiment of the present invention, wherein the uplink transmission buffer is on the MN, and the method further includes: receiving the data from the UE; storing the data in the uplink transmission buffer; and generating the BSR.

[0193] Embodiment 11 includes the method according to embodiment 9 or some other embodiment herein, wherein the uplink transmission buffer is on the UE, and the method further includes: receiving the BSR from the UE.

[0194] Embodiment 12 includes the method according to embodiment 11 or some other embodiment herein, the method further comprising: after outputting the BSR, receiving the data from the UE.

[0195] Embodiment 13 includes a method according to any one of embodiments 9 to 12 or some other embodiment of the present invention, the method further comprising: determining a scheduling constraint of the UE based on a condition of a link between the MN and the UE; and outputting the scheduling constraint for transmission to the base station.

[0196] Embodiment 14 includes a method according to embodiment 13 or some other embodiment herein, wherein the scheduling constraint is a scheduling constraint associated with a MN, and the method further includes: outputting an independent scheduling constraint for the UE for a direct connection between the UE and the base station.

[0197] Embodiment 15 includes the method according to embodiment 13 or some other embodiment herein, the method further comprising: detecting an event; and outputting the scheduling constraint for transmission to the base station based on the event.

[0198] Embodiment 16 includes the method according to embodiment 15 or some other embodiment herein, the method further comprising: detecting the event based on the condition.

[0199] Embodiment 17 includes a method according to embodiment 9 or some other embodiment herein, the method further comprising: outputting an indication of a transport block size limit for transmission to the base station, the transport block size limit being associated with traffic directed to the UE via the subnet.

[0200] Embodiment 18 includes a method according to embodiment 9 or some other embodiment of the present invention, wherein the method further includes: outputting an indication of a time division duplex (TDD) mode associated with the UE or a limitation on the number of UEs of the subnet to be scheduled in parallel for transmission to the base station.

[0201] Embodiment 19 includes a method to be implemented by a base station, the method comprising: receiving traffic for one or more user equipment (UE) for a subnet; aggregating the traffic into a logical channel (LC) or a radio bearer (RB); and outputting the traffic for transmission to a management node (MN) of the subnet via the LC or RB.

[0202] Embodiment 20 includes a method according to embodiment 19 or some other embodiment herein, wherein: aggregating the traffic into the LC or RB includes generating a packet having a subnet tunneling protocol (SN-TP) header and a payload, the subnet tunneling protocol (SN-TP) header having mapping information associated with the LC or RB, the payload having data for a UE among the one or more UEs; and outputting the traffic includes outputting the packet to the MN.

[0203] Embodiment 21 includes a method according to embodiment 19 or some other embodiment herein, wherein the mapping information includes an identity associated with the UE and an indication of the LC or RB.

[0204] Embodiment 22 includes the method of embodiment 19 or some other embodiment herein, further comprising: receiving the traffic in multiple quality of service flows.

[0205] Embodiment 23 includes a method according to embodiment 19 or some other embodiment herein, wherein the method further comprises: aggregating the traffic into the LC or RB at a subnet tunneling protocol (SN-TP) layer of the base station, wherein the SN-TP layer is above or below a radio link control (RLC) layer of the base station.

[0206] Embodiment 24 includes the method according to embodiment 23 or some other embodiment herein, the method further comprising: outputting information for configuring the SN-TP layer to be above or below the RLC layer for transmission to the MN.

[0207] Another embodiment may include an apparatus comprising means for performing one or more elements of the method described in or related to any of Embodiments 1 to 24, or any other method or process described herein.

[0208] Another embodiment may include one or more non-transitory computer-readable media, which include instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of a method described in or related to any of Embodiments 1 to 24 or any other method or process described herein.

[0209] Another embodiment may include an apparatus comprising logic components, modules, or circuits for performing one or more elements of the method described in accordance with or related to any of Embodiments 1 to 24, or any other method or process described herein.

[0210] Another embodiment may include a method, technique or process described or related to any one of embodiments 1 to 24 or a portion or component thereof.

[0211] Another embodiment may include a device comprising: one or more processors and one or more computer-readable media, wherein the one or more computer-readable media include instructions that, when executed by the one or more processors, cause the one or more processors to perform methods, techniques, or processes described in or related to any one of embodiments 1 to 24 or portions thereof.

[0212] Another embodiment may include a signal as described or related to any one of embodiments 1 to 24, or parts or components thereof.

[0213] Another embodiment may include a datagram, information element, packet, frame, segment, PDU or message as described or related to any one of embodiments 1 to 24 or parts or components thereof or otherwise described in the present disclosure.

[0214] Another embodiment may include a signal encoded with data as described or associated with any one of embodiments 1 to 24, or parts or components thereof, or otherwise described in this disclosure.

[0215] Another embodiment may include a signal encoded with a datagram, IE, packet, frame, segment, PDU or message as described or related to any one of embodiments 1 to 24 or parts or components thereof or otherwise described in the present disclosure.

[0216] Another embodiment may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform a method, technique, or process described in or related to any one or part of embodiments 1 to 24.

[0217] Another embodiment may include a computer program comprising instructions, wherein execution of the program by a processing element causes the processing element to perform a method, technique, or process described or related to any one or part of embodiments 1 to 24.

[0218] Another embodiment may include a signal in a wireless network as shown and described herein.

[0219]

[0013] Another embodiment may include a method of communicating in a wireless network as shown and described herein.

[0220]

[0013] Another embodiment may include a system for providing wireless communications as shown and described herein.

[0221]

[0013] Another embodiment may include an apparatus for providing wireless communications as shown and described herein.

[0222] Unless explicitly stated otherwise, any of the above examples may be combined with any other example (or combination of examples). The foregoing description of one or more specific implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. In view of the above teachings, modifications and variations are possible or can be obtained from the practice of various embodiments.

[0223] Although the above embodiments have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to include all such variations and modifications.

Claims

1. A method, comprising: receiving a connection establishment request from a management node (MN) of a subnet, the connection establishment request being used to request admission of a user equipment (UE) to a radio access network (RAN) via the subnet; assigning a Sub-Network (SN) UE Identity (ID) to the UE; and An indication of the SN UE ID is output for transmission to the MN.

2. The method according to claim 1, further comprising: The context of the UE is linked with the context of the MN.

3. The method of claim 2, wherein the context of the UE comprises the SN UEID and a security context associated with the UE, and the context of the MN comprises a layer 1 configuration, a measurement configuration, and a security context associated with the MN.

4. The method according to claim 2, further comprising: receiving a transmission including data and an indication of the SN UE ID based on a cell radio network temporary identifier (C-RNTI) associated with the MN; identifying a context of the UE based on the SN UE ID; as well as The data is forwarded based on the context of the UE.

5. The method according to claim 1, further comprising: The SN UE ID is linked with a Temporary Mobile Subscriber Identity (TMSI) associated with the UE.

6. The method according to claim 1, further comprising: receiving data directed to the UE, the data being associated with an identity of the UE; mapping the identity to the SN UE ID; accessing a context of the UE based on the SN UE ID; accessing a context of the MN associated with a context of the UE; as well as Data having an indication of the SN UE ID is output for transmission to the UE via the MN based on the context of the MN.

7. The method according to claim 1, further comprising: receiving a random access channel (RACH) transmission from the UE with an indication of the SN UE ID; Identifying the context of the UE and the context of the MN based on the SN UE ID; generating an independent UE context based on the UE context and the MN context; as well as A response to the RACH transmission is output to establish a direct connection with the UE.

8. One or more computer-readable media having instructions which, when executed, cause a processing circuit to: outputting a buffer status report (BSR) for transmission to a base station, the buffer status report (BSR) indicating a status of an uplink transmission buffer associated with a user equipment (UE) of the subnet; receiving an uplink grant from the base station, the uplink grant scheduling resources to be used for uplink transmission of data from the UE; as well as The data from the UE is output using the resources.

9. The one or more computer-readable media of claim 8, wherein the uplink transmission buffer is on a management node (MN), and the instructions when executed further cause the processing circuit to: receiving the data from the UE; storing the data in the uplink transmission buffer; and The BSR is generated.

10. The one or more computer-readable media of claim 8, wherein the uplink transmission buffer is on the UE, and the instructions when executed further cause the processing circuit to: receiving the BSR from the UE; and After transmitting the BSR, the data is received from the UE.

11. The one or more computer-readable media of claim 8, wherein the instructions, when executed, further cause the processing circuit to: determining a scheduling constraint for the UE based on a condition of a link between a management node (MN) and the UE; and The scheduling constraints are output for transmission to the base station.

12. The one or more computer-readable media of claim 11, wherein the scheduling constraint is a scheduling constraint associated with a MN, and the instructions when executed further cause the processing circuit to: An independent scheduling constraint for the UE for a direct connection between the UE and the base station is output.

13. The one or more computer-readable media of claim 11, wherein the instructions, when executed, further cause the processing circuit to: detecting an event based on the condition; and The scheduling constraints are output for transmission to the base station based on the event.

14. The one or more computer-readable media of claim 8, wherein the instructions, when executed, further cause the processing circuit to: An indication of a transport block size limit is output for transmission to the base station, the transport block size limit being associated with traffic directed to the UE via the subnet.

15. The one or more computer-readable media of claim 8, wherein the instructions, when executed, further cause the processing circuit to: An indication of a time division duplex (TDD) mode associated with the UE or a limit on the number of UEs of the subnet to be concurrently scheduled is output for transmission to the base station.

16. An apparatus comprising a processing circuit configured to: receiving traffic for one or more user equipment (UE) of the subnet; aggregating the traffic into logical channels (LCs) or radio bearers (RBs); as well as The traffic is output for transmission to a management node (MN) of the subnet via the LC or RB.

17. The device according to claim 16, wherein: To aggregate the traffic into the LC or RB, the processing circuit is to generate a packet having a subnet tunneling protocol (SN-TP) header and a payload, the subnet tunneling protocol (SN-TP) header having mapping information associated with the LC or RB, the payload having data for a UE of the one or more UEs; as well as To output the traffic, the processing circuitry will output the packets for transmission to the MN.

18. The apparatus of claim 17, wherein the mapping information comprises an identity associated with the UE and an indication of the LC or RB.

19. The apparatus of claim 16, wherein the processing circuit is further configured to: The traffic is received in a plurality of quality of service flows.

20. The apparatus of claim 16, wherein the processing circuit is further configured to: Aggregating the traffic into the LC or RB at a subnetwork tunneling protocol (SN-TP) layer of a base station; and Information for configuring the SN-TP layer to be above or below a radio link control (RLC) layer of the base station is output for transmission to the MN.

Images