Random Access Channel Procedure Using Neural Networks

Integrating DNNs into RACH procedures in wireless communication systems addresses complexity and resource overhead, improving RACH performance by reducing false positives and congestion.

JP7871395B2Active Publication Date: 2026-06-08GOOGLE LLC

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
GOOGLE LLC
Filing Date
2023-02-06
Publication Date
2026-06-08

AI Technical Summary

Technical Problem

Conventional wireless communication systems face excessive complexity, resource consumption, and overhead due to isolated design and implementation of different Random Access Channel (RACH) procedures, leading to false positives, congestion, and interference.

Method used

Implementing individually or jointly trained deep neural networks (DNNs) to handle RACH procedures, reducing the need for proprietary process blocks and optimizing RACH operations by integrating neural networks into transmitter and receiver paths of user equipment (UE) and base stations (BS).

Benefits of technology

This approach reduces RACH throughput issues, minimizes false positives and congestion, and enhances connectivity by optimizing resource utilization and processing efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007871395000001
    Figure 0007871395000001
  • Figure 0007871395000002
    Figure 0007871395000002
  • Figure 0007871395000003
    Figure 0007871395000003
Patent Text Reader

Abstract

The wireless communication system (100) uses DNNs or other neural networks (118, 130, 138, 146) to provide the RACH technique. The TX DNN (118) of the user equipment (UE) (108) generates and transmits a random access (RA) signal (124) wirelessly to the base station (BS) 110. The BS (110) receives the RA signal (124) as an input and, from this input, generates an RA response signal (150) for wireless transmission to the UE (108).
Need to check novelty before this filing date? Find Prior Art

Description

Background Art

[0001] Wireless communication systems often perform random access channel (RACH) procedures used by cellular devices such as mobile phones, wearable electronic devices, and other user equipment (UE) during various events. For example, a UE can execute an RACH procedure during initial network access, handover, or uplink (UL) data transmission. The RACH procedure enables the UE to acquire uplink (UL) synchronization and UL transmission resources. The UE can perform contention-free random access (CFRA) or contention-based random access (CBRA) using the 4-step RACH procedure or the 2-step RACH procedure defined in Release 15 of the 3rd Generation Partnership Project (3GPP (registered trademark)) and Release 16 of 3GPP, respectively.

Summary of the Invention

[0002] According to some embodiments, a computer-implemented method in a user equipment (UE) device of a cellular communication system includes receiving random access (RA) configuration information at the UE, configuring a transmission neural network based on the RA configuration information, and generating a first output by the transmission neural network, where the first output represents a first RA signal for an RA procedure between the UE and a base station (BS) of the cellular communication system. The computer-implemented method further includes controlling a radio frequency (RF) antenna interface of the UE and transmitting a first RF signal representing the first output for reception by the BS.

[0003] According to some embodiments, a computer implementation method in a base station (BS) of a cellular communication system includes: generating a first output by the transmitting neural network of the BS that represents a random access (RA) response signal including an RA response for an RA procedure between the BS and user equipment (UE) of the cellular communication system; and controlling the radio frequency (RF) antenna interface of the BS and transmitting a first RF signal representing the RA response signal for reception by the UE.

[0004] In various embodiments, the method may further include one or more of the following aspects: receiving a second RF signal from a UE at an RF antenna interface before generating a first output, wherein the second RF signal represents an RA signal for an RA procedure, and the first output is generated based on the second RF signal received from the UE. The method may further include providing a representation of the second RF signal as a first input to a receiving neural network of a BS; the receiving neural network generating a second output based on the first input to the receiving neural network; generating RA response information based on the second output; and providing the RA response information as a second input to a transmitting neural network of a first device, wherein the transmitting neural network generates an RA response signal based on the second input. The RA signal is associated with an RA preamble. The RA response includes at least the uplink resource allocation of the UE. The method may further include generating conflict resolution information based on the second output; and providing the conflict resolution information as a third input to a transmitting neural network of a BS, wherein the transmitting neural network generates an RA response signal based on the third input. The method also includes receiving a second RF signal from the UE at an RF antenna in response to transmitting a first RF signal, the second RF signal representing an uplink transmission; the method further includes generating a second output representing a conflict resolution message in response to receiving the second RF signal; providing the second output as input to a transmitting neural network; and the transmitting neural network generating a third output based on the input to the transmitting neural network, the third output representing a conflict resolution signal including a conflict resolution message; and the method further includes controlling the RF antenna interface of the BS and transmitting a third RF signal representing a conflict resolution signal for reception by the UE.Generating a second output representing a conflict resolution message includes providing a representation of a second RF signal as input to the receiving neural network of the BS, and the receiving neural network generating a second output representing a conflict resolution message based on the input to the receiving neural network. Generating a first output representing an RA response includes determining that the RA signal contains a conflict resolution identifier associated with the UE, and generating the first output includes including the conflict resolution identifier in the first output.

[0005] According to some embodiments, a computer implementation method in a user equipment (UE) device of a cellular communication system includes receiving functional information from at least one of a first device or a second device of the cellular communication system, and selecting a first neural network architecture configuration from a set of candidate neural network architecture configurations based on the functional information, wherein the first neural network architecture configuration is trained to implement random access procedures between the first device and the second device, and the computer implementation method further includes transmitting a first indication of the first neural network architecture configuration to the first device for implementation in one or more of the transmitting and receiving neural networks of the first device.

[0006] In some embodiments, the device comprises a radio frequency (RF) antenna interface, at least one processor connected to the RF antenna interface, and a memory for storing executable instructions, the executable instructions being configured to operate at least one processor to perform any of the methods described above and those described herein.

[0007] By referring to the accompanying drawings, this disclosure will be better understood, and many features and advantages will become apparent to those skilled in the art. The use of the same reference numeral in different drawings indicates similar or identical items. [Brief explanation of the drawing]

[0008] [Figure 1] This figure shows an exemplary wireless system that uses a neural network architecture to perform one or more RACH procedures, according to several embodiments. [Figure 2] This figure shows an exemplary hardware configuration of the UE of the wireless system shown in Figure 1, according to several embodiments. [Figure 3] This figure shows an exemplary hardware configuration of the BS of the wireless system in Figure 1, according to several embodiments. [Figure 4] This figure shows an exemplary hardware configuration of the management infrastructure components of the wireless system shown in Figure 1, according to several embodiments. [Figure 5] This figure shows several embodiments of machine learning (ML) modules that use neural networks for use in the RACH neural network architecture. [Figure 6] This figure shows a pair of neural networks being jointly trained for processing and transmitting RA-based signals between a UE and a BS, according to several embodiments. [Figure 7] This flowchart illustrates an exemplary method for the collaborative training of a set of neural networks to facilitate one or more RA procedures in a wireless system, according to several embodiments. [Figure 8] This figure illustrates exemplary methods for performing one or more RACH procedures using a set of selected, individually or jointly trained neural networks, according to several embodiments. [Figure 9] This figure illustrates exemplary methods for performing one or more RACH procedures using a set of selected, individually or jointly trained neural networks, according to several embodiments. [Figure 10]This figure illustrates exemplary methods for performing one or more RACH procedures using a set of selected, individually or jointly trained neural networks, according to several embodiments. [Figure 11] This figure illustrates exemplary methods for performing one or more RACH procedures using a set of selected, individually or jointly trained neural networks, according to several embodiments. [Figure 12] This figure illustrates exemplary methods for performing one or more RACH procedures using a set of selected, individually or jointly trained neural networks, according to several embodiments. [Figure 13] These are ladder signal transmission diagrams showing examples of operation of the methods in Figures 8 and 9 according to several embodiments. [Figure 14] These are ladder signal transmission diagrams showing examples of operation of the methods in Figures 9 and 10 according to several embodiments. [Figure 15] These are ladder signal transmission diagrams showing examples of operation of the methods in Figures 11 and 12 according to several embodiments. [Figure 16] This is a diagram showing the ladder signal transfer for a conventional CFRA. [Figure 17] This is a ladder signal transmission diagram for a conventional 4-step CBRA. [Figure 18] This is a ladder signal transmission diagram for a conventional 2-step CBRA. [Modes for carrying out the invention]

[0009] Wireless communication systems typically implement one or more different RACH procedures, such as CFRA, 4-step CBRA, or 2-step CFRA / CBRA. Designing and implementing these different RACH procedures can be a detailed and challenging task. For example, in conventional wireless communication systems, each different RACH procedure typically relies on a set of processing stages / blocks, such as transmitting and processing RACH signals, transmitting and processing RAR signals, transmitting and processing Physical Uplink Shared Channel (PUSCH) signals, and transmitting and processing CR signals. Furthermore, the design, testing, and implementation of these processing stages are relatively isolated from one another. This custom and independent design approach for each process stage results in excessive complexity, resource consumption, and overhead. However, as described below, wireless communication systems can train and implement one or more deep neural networks (DNNs) that can handle different RACH procedures with fewer technical resources than conventional hardware development. Additionally, DNNs mitigate reduced RACH throughput and connectivity failures with the UE by reducing false positives, congestion, and interference of RACH signals that typically occur in conventional RACH implementations.

[0010] The ladder signaling diagram 1600 in Figure 16 shows an example of a conventional CFRA. UE1602 sends preamble message 1606 to BS1604. For example, UE1602 sends preamble message 1606 on the physical random access channel (PRACH) as the first message (Msg1) of the RACH procedure. In response to successfully receiving Msg1 1606, BS1604 generates a Random Access Response (RAR) message 1608 and sends it to UE1602 as the second message (Msg2) of the RACH procedure. If UE1602 successfully receives Msg2 1608, UE1602 can decode the RAR information on the physical downlink shared channel (PDSCH) associated with Msg2 1608. Based on decoding the RAR information, UE1602 obtains, for example, the resource block (RB) allocation and the modulation and coding scheme (MCS) configuration transmitted by BS1604. If UE1602 does not successfully receive Msg2 1608 during the RAR window, UE1602 retransmits preamble message 1606 up to a threshold number of times. The CFRA procedure terminates when UE1602 successfully receives Msg2 1608.

[0011] The ladder signaling diagram 1700 in Figure 17 shows an example of a conventional 4-step CBRA. A conventional 4-step CBRA typically operates similarly to a conventional CFRA. However, in a conventional 4-step CBRA, UE1602 randomly selects a RACH preamble from a pool of preambles shared with other UEs. Therefore, UE1602 may select the same preamble as another UE, potentially experiencing conflict or competition when sending either Msg1 1706 or UL transmission (called Msg3) 1710 in PUSCH. For example, multiple UEs may attempt RA using the same RA preamble sequence on the same RA channel. Therefore, BS1604 implements a conflict resolution mechanism to manage these CBRA-based access requests. In Figure 17, the processes performed by UE1602 to send Msg1 1706 and the processes performed by BS1604 to send Msg2 1708 are the same (or similar) as the CFRA processes 1606 and 1608 described with respect to Figure 16. Figure 17 further shows that in response to the successful receipt of Msg2 1708, UE1602 sends UL transmission 1710 (Msg3) to BS1604.

[0012] BS1604 receives Msg3 1710 from UE1602. However, in some cases, BS1604 also receives Msg3 from other UEs with the same assignment, in response that these UEs also received Msg2 from BS1604. Therefore, BS1604 sends a Conflict Resolution (CR) message 1712 to UE1602 as the fourth message (Msg4) of the RACH procedure. If UE1602 receives Msg4 1712 associated with UE1602 before the conflict resolution timer expires, UE1602 considers the conflict to have been resolved successfully and enters the Radio Resource Control (RRC) connected state. Otherwise, UE1602 retries the RACH procedure.

[0013] The ladder signaling diagram 1800 in Figure 18 shows an example of a conventional two-step CFRA / CBRA. In this example, UE1602 receives an indication of a dedicated RACH preamble from BS1604, or randomly selects a RACH preamble based on access parameters obtained from BS1604. In another example, the access parameters also indicate a PUSCH assignment from BS1604. In a two-step CFRA / CBRA, UE1602 sends a single message 1802 (MsgA) that collectively represents Msg1 (preamble message) 1606 and Msg3 (UL PUSCH transmission) 1710, based on the RACH preamble and PUSCH assignment. BS1604 receives MsgA 1802 from UE1602 and sends a single message 1804 (MsgB) that represents both Msg2 (RAR message) 1608 and Msg4 (CR message) 1704. UE1602 monitors MsgB1804 within the configured window. In the case of CFRA (dedicated preamble), UE1602 terminates the RACH procedure in response to successfully receiving MsgB1804 from BS1604. In the case of CBRA (randomly selected preamble), UE1602 terminates the RACH procedure in response to successfully receiving MsgB1804 and performing conflict resolution. If UE1602 is unable to successfully complete the RACH procedure after sending a threshold number of MsgA, UE1602 reverts to the conventional 4-step CBRA procedure.

[0014] The following describes exemplary systems and techniques that utilize an end-to-end neural network configuration for the RACH procedure, rather than taking a manual approach to each step of the process. This end-to-end neural network configuration provides rapid development and deployment, in addition to an optimized RACH procedure that is less prone to false detection, congestion, and interference of RACH signals compared to conventional RACH implementations. The conventional processing steps for the RACH procedure described above with respect to Figures 16-18 are replaced or complemented by one or more individually trained neural networks, or one or more jointly trained neural networks, that operate to perform the RACH procedure(s). The individually or jointly trained neural network architecture includes a set of neural networks, each trained to provide more accurate and efficient RACH operation than the conventional sequence of RACH steps, without requiring each to be specifically designed and tested for its sequence of RACH steps. A neural network architecture, trained individually or collectively, can perform one or more RACH processes, such as transmitting and processing RACH (PRACH) signals, transmitting and processing RAR signals, transmitting and processing PUSCH signals, and transmitting and processing CR signals.

[0015] In at least some embodiments, the wireless system can use co - training of multiple candidate neural network architectures of various neural networks used between the UE and the BS based on any of various parameters such as operating characteristics (e.g., frequency, bandwidth, etc.) of the BS, the reference signal received power (RSRP) reported by the UE, Doppler estimates, deployment information, computing resources, sensor resources, power resources, antenna resources, other performance, etc. Thus, in at least some embodiments, the specific neural network configuration used in each of the UE and the BS is selected based on the correlation between the specific configuration of these devices and the parameters used to train the corresponding neural network architecture configuration.

[0016] Figure 1 shows a wireless communication system 100 using a random access (RACH) procedure to facilitate neural networks, according to several embodiments. As shown, the wireless communication system 100 is a cellular network connected to a network infrastructure 106, which includes, for example, a core network 102, one or more wide area networks (WANs) 104, or other packet data networks (PDNs) such as the Internet, or a combination thereof. The wireless communication system 100 further includes one or more UEs 108 (indicated as UEs 108-1 and 108-2) and one or more BSs 110 (indicated as BSs 110-1 and 110-2). Each BS 110 supports the wireless communication UEs 108 through one or more wireless communication links 112, which may be unidirectional or bidirectional. In at least some embodiments, each BS 110 is configured to communicate with the UEs 108 through the wireless communication links 112 via radio frequency (RF) signal transmission using one or more applicable RATs defined by one or more communication protocols or communication standards. Therefore, each BS110 functions as a wireless interface between the UE108 and various networks and services provided by the core network 102 and other networks, such as packet-switched (PS) data services and circuit-switched (CS) services. Traditionally, data communication or signal transmission from BS110 to UE108 is referred to as "downlink" or "DL," and data communication or signal transmission from UE108 to BS110 is referred to as "uplink" or "UL." In at least some embodiments, the BS110 also includes inter-base station interfaces, such as Xn interfaces and / or X2 interfaces, configured to exchange user plane data and control plane data between other BS110s.

[0017] Each BS110 can operate as a Node B (or Base Transceiver Station (BTS)) for the Universal Mobile Telecommunications System (UMTS) radio access technology (RAT), also known as "3G", as an evolved Node B (eNodeB) for the 3GPP Long-Term Evolution (LTE) RAT, as a 5G Node B ("gNB") for the 3GPP 5th Generation (5G) New Radio (NR) RAT, etc., using any of various combinations of RATs. Each BS110 can be an integrated base station or a distributed base station comprising a central unit (CU) and one or more distributed units (DU). Similarly, the UE108 can implement any of various electronic devices operable to communicate with the BS110 via an appropriate RAT, including, for example, a mobile phone, a cellular-enabled tablet computer or laptop computer, a desktop computer, a cellular-enabled video game system, a server, a cellular-enabled home appliance, a cellular-enabled vehicle communication system, a cellular-enabled smartwatch, or other wearable devices.

[0018] The UE108 obtains synchronization and resources for communicating with the BS110 by performing a Random Access Channel (RACH) procedure. As described above, the RACH procedure in a conventional wireless communication system typically depends on a series of processing steps / blocks that introduce excessive complexity, resource consumption, and overhead. Thus, in at least some embodiments, the UE108 and the BS110 each implement a transmitter (TX) and a receiver (RX) processing path that integrates one or more neural networks (NN) that are trained or otherwise configured to facilitate the RACH technique.

[0019] For example, with respect to a RACH path 114 established between one or more UE108s and one or more BS110s, the UE108 uses a TX processing path 116 having a UE PRACH TX DNN 118 or another neural network. The UE PRACH TX DNN 118 has an input configured to receive RACH configuration information 120 and other information such as sensor data 122 in order to generate a RACH signal 124, which will be described in more detail below with reference to Figure 6. The UE PRACH TX DNN 118 further includes an output connected to the RF front end 126 of the UE108.

[0020] In at least some embodiments, the UE108 also uses an RX processing path 128 having a UE RAR RX DNN130 or another neural network. The UE RAR RX DNN130 has an input connected to the RF front end 126 and an output configured to produce, for example, an indication 132 for a successful RACH procedure or an indication 134 for a failed RACH procedure.

[0021] In at least some embodiments, the BS110 uses an RX processing path 136 having a BS PRACH RX DNN 138 or another neural network. The BS PRACH RX DNN 138 has an input connected to the RF front end 140. As described below with reference to Figure 6, the input of the BS PRACH RX DNN 138 is configured to receive, for example, a RACH signal 124 created by the DNN, a conventionally created RACH signal, or a combination thereof transmitted by the UE 108. In at least some embodiments, the BS PRACH RX DNN 138 has an output connected to the RACH management module 142 of the BS110.

[0022] BS110 further uses a TX processing path 144 having a BS RAR TX DNN 146 or another neural network. In at least some embodiments, the BS RAR TX DNN 146 has an input connected to the output of the BS RACH management module 142. In other embodiments, the input of the BS RAR TX DNN 146 is connected to the output of the BS PRACH RX DNN 138. The BS RAR TX DNN 146 further has an output connected to the RF front end 140 that generates an output representing a RAR signal 150, a CR signal 1412 (Figure 14), or a combination thereof.

[0023] In at least some embodiments, a BS110 (or another cellular network component) configures or indicates a configuration for at least one of the following: UE PRACH TX DNN118, UE RAR RX DNN130, BS PRACH RX DNN138, or RAR TX DNN146, based on one or more of the following: the cell size of the BS110, the selection of RACH DNNs for other cells (e.g., PRACH RX DNN and RAR TX DNN), the operating characteristics of the UE108, the operating characteristics of the BS110, the reference signal received power (RSRP) reported by the UE, the UE's velocity estimate, the UE's Doppler estimate, and deployment information. For example, different BS110s can coordinate with each other with respect to the set of RACH DNNs configured for neighboring cells and their UE108s, so that different neighboring cells use different sets of RACH DNNs (e.g., different architectures / weights). Different neighboring cells can use the same time / frequency resources for RACH. However, the RACH DNNs of adjacent cells generate different RACH sequences to reduce the likelihood that the first BS110-1 will detect RACH from UE108 attempting to connect with the second BS110-2. In at least some embodiments, UE108 receives a specific neural network architecture, or at least an indication thereof, from BS110 (or another network component) via one or more control messages, such as RRC messages.

[0024] During operation, one or more of the UE PRACH TX DNN118, UE RAR RX DNN130, BS PRACH RX DNN138, and RAR TX DNN146 are trained, jointly trained, or otherwise configured together to perform one or more RACH operations. The UE PRACH TX DNN118 is configured to receive RACH configuration information 120, PUSCH data 614 (Figure 6), etc., as inputs. In some embodiments, other inputs, such as sensor data 122 (or information generated based on sensor data 122) from the UE 108 sensor, are simultaneously provided as inputs to the UE PRACH TX DNN118. Examples of inputs (or related information) for sensor data 122 include UE velocity estimates, UE Doppler estimates, Global Positioning System (GPS) data, camera data, accelerometer data, internal measurement unit (IMU) data, altimeter data, temperature data, barometer data, and object detection sensors (e.g., radar sensors, lidar sensors, imaging sensors, or structured light-based depth sensors).

[0025] Depending on how UE108 is attempting to access BS110 (e.g., non-standalone (NSA) mode or standalone (SA) mode), the UE may receive RACH configuration information 120 from, for example, a BS110 System Information Block (SIB) message or an RRC message. During handover, the source BS110 may instruct UE108 to implement a specific RACH TX DNN architecture, and the target BS110 may optimize one or both of the RACH RX DNN architecture and RACH RX DNN parameters based on metrics such as the signal-to-noise ratio (SNR) associated with the received UE signal. The source or primary BS110 may send a dedicated RRC message containing the RACH configuration information 120 to the UE during handover or during the addition of a secondary cell (for dual connectivity).

[0026] In at least some embodiments, the RACH configuration information 120 includes one or more different types of information that the DNN(s) of the UE108 use as input to generate and configure one or more RACH signals 124. For example, in at least some embodiments, the RACH configuration information 120 includes information such as instructions to use CFRA or CBRA (2-step or 4-step), the number of RACH occasions available per synchronous signal block (SSB), the number of competition-based preambles available, the preamble format to use, frequency domain resources, time domain resources (slots and symbols), and initial power for PRACH transmission. The RACH configuration information 120 may also include the DNN architecture of the UE108 (including DNN weights and biases) to be applied to the reception of PRACH transmissions (Msg1 / MsgA) and RAR signals (Msg2 / MsgB). For example, a RACH DNN configuration can specify that the waveforms generated by the PRACH TX DNN118 will only be used by the UE108 for a specific resource block, a specific frequency band (e.g., sub-6 gigahertz (GHz) or millimeter wave (mmWave)), a specific period, or a specific other time, frequency, or time-frequency resource. A RACH configuration can also specify different sets of DNNs, such as competition-based DNNs and non-competition DNNs.

[0027] In at least some embodiments, the RACH configuration information 120 indicates which UE PRACH DNN (e.g., UE PRACH TX DNN(s) 118 and UE RAR RX DNN(s) 130) the UE 108 will use. The RACH configuration information 120 can configure the UE 108 to use a new / different PRACH TX DNN 118 after the expiration of the backoff period when the RACH procedure fails. Alternatively, the RACH configuration information 120 can configure the UE 108 to use the same PRACH TX DNN 118 architecture when the RACH procedure fails but has higher transmit power and / or different DNN weights. If the UE 108 implements multiple RACH DNNs, the UE 108 can randomly select one or both of the PRACH TX DNN(s) 118 and RAR RX DNN(s) 130 from the configurations shown in the BS message, such as the RACH DNN configuration message. Furthermore, UE108 can randomly select the weights of a RACH DNN, such as PRACH TX DNN118 or RAR RX DNN130, from a set of weights indicated by BS110 in a message such as a DNN configuration message. In some embodiments, the PRACH TX DNN118 selected by UE108 may have a RAR RX DNN130 corresponding to a RAR signal 150 received by UE108 from BS110. For example, if UE108 selects a particular PRACH TX DNN118 to send a RACH signal 124 to BS110, UE108 selects the corresponding RAR RX DNN130 to receive and process a RAR signal 150 from BS110.

[0028] As described above and in more detail herein, both UE108 and BS110 each use one or more DNNs or other neural networks that are trained or jointly trained and selected based on context-specific parameters to facilitate the entire RACH process. To manage the joint training, selection, and maintenance of these neural networks, in at least one embodiment, the system 100 further includes a management infrastructure component 154 (or "management component 154" for brevity). This management component 154 may include, for example, servers or other components within the network infrastructure 106 of the wireless communication system 100. The management component 154 may also include external components of the wireless communication system 100, such as cloud servers or other computing devices. Furthermore, although shown as separate components in the illustrated examples, in at least some embodiments, the BS110 implements the management component 154. The monitoring functions provided by the management component 154 may include, in whole or in part, monitoring the joint training of neural networks, managing the selection of a specific neural network architecture configuration for UE108 or BS110 based on those specific functions or other component-specific parameters, receiving and processing function updates for the purpose of selecting neural network configurations, and receiving and processing feedback for the purpose of training or selecting neural networks.

[0029] As will be described in more detail below with respect to Figure 4, in some embodiments, the management component 154 maintains a set 412 (Figure 4) of candidate neural network architecture configurations 414 (Figure 4). The management component 154 (or another network component) selects a candidate neural network architecture configuration 414 to be used by a particular component of the corresponding RACH path based on the capabilities of the component implementing the corresponding neural network, the capabilities of other components in the transmit chain, the capabilities of other components in the receive chain, or at least a part of a combination thereof. These capabilities may include, for example, sensor capabilities, processing resource capabilities, battery / power capabilities, RF antenna capabilities, and the capabilities of one or more accessories of the component. Information representing these capabilities of UE108 and BS110 is acquired by the management component 154 and stored in the management component 154 as extended UE capability information 420 (Figure 4) and extended BS capability information 422 (Figure 4), respectively. In at least some embodiments, the management component 154 further considers parameters or other aspects of the corresponding channel or propagation channel of the environment, such as the carrier frequency of the channel, the known presence of objects or other interfaces.

[0030] To support this approach, in some embodiments, the management component 154 can manage the joint training of different combinations of candidate neural network architecture configurations 414 for different feature / context combinations. The management component 154 can then obtain feature information 420 from the UE 108, feature information 422 from the BS 110, or both, and from this feature information, the management component 154 selects a neural network architecture configuration from a set 412 of candidate neural network architecture configurations 414 for each component based on at least some of the corresponding indicated features, RF signaling environment, etc. In at least some embodiments, the management component 154 (or another network component) jointly trains the candidate neural network architecture configurations as a pair of subsets, so that each candidate neural network architecture configuration for a particular set of features of the UE 108 is jointly trained with a single corresponding candidate neural network architecture configuration for a particular set of features of the BS 110. In other embodiments, the management component 154 (or another network component) manages candidate neural network architecture configurations such that each candidate configuration of UE108 has a one-to-many correspondence with multiple candidate configurations of BS110, and vice versa.

[0031] Therefore, in at least some embodiments, the system 100 implements a random access approach that relies not on a proprietary process block specifically designed for compatibility, but on one or more neural networks individually trained and managed on one or more of the UE108 or BS110, or on a set of neural networks managed, jointly trained and selectively used between one or more UE108s and one or more BS110s for RACH technology. This not only increases flexibility but, in some situations, also makes processing at each device faster and more efficient in transmitting and processing RACH-related signals.

[0032] Figure 2 shows exemplary hardware configurations of the UE108 in several embodiments. Note that the illustrated hardware configurations represent the processing and communication components most directly related to the neural network-based process in one or more embodiments, and certain components that are well understood to be frequently implemented in such electronic devices, such as displays, non-sensor peripherals, and external power supplies, have been omitted.

[0033] In the illustrated configuration, the UE108 includes an RF front-end 126 having one or more antennas 202 and an RF antenna interface 204 having one or more modems supporting one or more RATs. The RF front-end 126 actually acts as a physical (PHY) transceiver interface that performs and processes signal transmission between one or more processors 206 of the UE108 and the antennas 202 to facilitate various types of wireless communication. The antennas 202 can be arranged in one or more arrays of multiple antennas configured similarly or differently from one another and can be tuned to one or more frequency bands associated with the corresponding RATs. The one or more processors 206 can include, for example, one or more central processing units (CPUs), graphics processing units (GPUs), tensor processing units (TPUs), or other application-specific integrated circuits (ASICs). For illustrative purposes, the processors 206 can include application processors (APs) utilized by the UE108 to run the operating system and various user-level software applications, as well as one or more processors utilized by the modems or baseband processors of the RF front-end 126. UE108 further includes one or more computer-readable media 208, which include any of the various media used by electronic devices to store data and / or executable instructions, such as random access memory (RAM), read-only memory (ROM), cache, flash memory, solid-state drive (SSD), or other mass storage devices. For ease of explanation and brevity, computer-readable media 208 are referred to herein as “memory 208,” considering that system memory or other memory is frequently used to store data and instructions executed by the processor 206, but it is understood that references to “memory 208” apply equally to other types of storage media unless otherwise specified.

[0034] In at least one embodiment, the UE108 further includes a plurality of sensors, referred herein as a sensor set 210, at least some of which are utilized in a neural network-based manner in one or more embodiments. Generally, the sensors of the sensor set 210 include sensors that sense some aspect of the environment surrounding the UE108 or the user's use of the UE108, and these sensors may sense parameters that have at least some influence on or reflect the speed of the UE108, the position of the UE108, the orientation of the UE108, the movement, or a combination thereof. The sensors of the sensor set 210 may include one or more sensors for object detection, such as radar sensors, lidar sensors, imaging sensors, and structured light-based depth sensors. The sensor set 210 may also include one or more sensors for determining the position or attitude / orientation of the UE108, such as GPS sensors, satellite positioning sensors such as Global Navigation Satellite System (GNSS) sensors, IMU sensors, visual odometry sensors, gyroscopes, tilt sensors or other inclinometers, and ultra-wideband (UWB) based sensors. Other examples of sensor types in the sensor set 210 include environmental sensors such as temperature sensors, barometers, and altimeters, or imaging sensors such as cameras for user image capture, cameras for face detection, cameras for stereoscopic or visual odometry, light sensors for detecting objects near device features, and object detection sensors (e.g., radar sensors, lidar sensors, imaging sensors, or structured light-based depth sensors). The UE108 may further include one or more batteries 212 or other portable power sources, as well as one or more user interface (UI) components 214 such as a touchscreen, user-operable input / output devices (e.g., "buttons" or keyboards), or other touch / contact sensors, a microphone, or other audio sensors for capturing audio content, an image sensor for capturing video content, and a thermal sensor (for detecting proximity to the user, for example).

[0035] One or more memories 208 of the UE108 store one or more sets of executable software instructions and associated data that operate one or more processors 206 and other components of the UE108, and execute various functions belonging to the UE108. The set of executable software instructions includes, for example, an operating system (OS) and various drivers (not shown), as well as various software applications. The set of executable software instructions further includes one or more of the neural network management module 216, the function management module 218, or the RACH management module 220. The neural network management module 216 implements one or more neural networks in the UE108, as described in detail below. The function management module 218 determines various functions of the UE108 related to the neural network configuration or selection and reports such functions to the management component 154. Similarly, it monitors the UE108 for changes in such functions, including changes in RF and processing functions, changes in accessory availability or functionality, changes in sensor availability, etc., and manages the reporting of such functions to the management component 154 and changes in functions. When UE108 does not implement a corresponding RACH DNN, or when the RACH DNN is not configured to perform a specific RACH operation, the RACH management module 220 operates to perform one or more conventional (non-DNN) RACH operations.

[0036] To facilitate the operation of the UE108, one or more memories 208 of the UE108 can further store data associated with these operations. This data may include, for example, RACH configuration information 120, device data 222, and one or more neural network architecture configurations 224. The RACH configuration information 120 represents, for example, instructions from the BS110 using CFRA or CBRA (2-step or 4-step), the number of RACH occasions available per SSB, the number of competition-based preambles available, the preamble format to use, frequency domain resources, time domain resources (slots and symbols), initial power for PRACH transmission, etc. The device data 222 represents, for example, user data, multimedia data, beamforming codebook, and software application configuration information, etc.

[0037] The device data 222 may further include UE108 function information, such as sensor function information relating to one or more sensors in the sensor set 210, including the presence or absence of a particular sensor or sensor type, and for present sensors, one or more representations of corresponding functions, such as the range and resolution of the LiDAR or radar sensor, the image resolution and color depth of the imaging camera. The function information may further include information such as the function or status of the battery 212, the function or status of the UI 214 (e.g., the screen resolution, color gamut, or frame rate of the display).

[0038] One or more neural network architecture configurations 224 represent example UE implementations selected from a set 412 of candidate neural network architecture configurations 414 maintained by the management component 154. Each neural network architecture configuration 224 includes one or more data structures containing data and other information representing the corresponding architecture and / or parameter configuration used by the neural network management module 216 to form the corresponding neural network of the UE 108. The information contained in the neural network architecture configuration 224 includes, for example, a fully connected layer neural network architecture, a convolutional layer neural network architecture, a recurrent neural network layer, several connected hidden neural network layers, an input layer architecture, an output layer architecture, several nodes used by the neural network, coefficients used by the neural network (e.g., weights and biases), kernel parameters, several filters used by the neural network, a stride / pooling configuration used by the neural network, activation functions for each neural network layer, interconnections between neural network layers, and parameters specifying which neural network layers to skip. Therefore, the neural network architecture configuration 224 includes any combination of NN forming components (e.g., architecture and / or parameter configurations) to create an NN forming configuration (e.g., a combination of one or more NN forming components) that defines and / or forms a DNN.

[0039] Figure 3 shows exemplary hardware configurations of BS110 in several embodiments. Note that the illustrated hardware configurations represent the processing and communication components most directly related to the neural network-based process of one or more embodiments, and certain components that are well understood to be frequently implemented in such electronic devices, such as displays, non-sensor peripherals, and external power supplies, have been omitted. Furthermore, note that while the figures shown represent an implementation of BS110 as a single network node (e.g., 5G NR node B, or "gNB"), its functionality, and therefore the hardware components of BS110, can be distributed across multiple network nodes or devices and distributed in a manner that performs the functionality of one or more embodiments.

[0040] In the illustrated configuration, the BS110 includes an RF front-end 140 having one or more antennas 302, and an RF antenna interface (or front-end) 304 having one or more modems supporting one or more RATs, which acts as a PHY transceiver interface that performs and processes signal transmission between one or more processors 306 of the BS110 and the antennas 302 to facilitate various types of wireless communication. The antennas 302 can be arranged in one or more arrays of multiple antennas configured similarly or differently from one another, and can be tuned to one or more frequency bands associated with the corresponding RATs. The one or more processors 306 can include, for example, one or more CPUs, GPUs, TPUs, or other ASICs. The BS110 further includes one or more computer-readable media 308, which include one of various media used by electronic devices to store data and / or executable instructions, such as RAM, ROM, cache, flash memory, SSD, or other mass storage devices. Similar to the memory 208 of UE108, for the sake of ease and brevity of explanation, the computer-readable medium 308 is referred to herein as “memory 308,” taking into consideration that system memory or other memory is frequently used to store data and instructions executed by the processor 306. However, it is understood that references to “memory 308” apply equally to other types of storage media unless otherwise specified.

[0041] The BS also includes one or more network interfaces 326 to the core network 102, other BSs, etc. In at least one embodiment, the BS110 further includes a plurality of sensors, referred herein as a sensor set 310, at least some of which are utilized in a neural network-based manner in one or more embodiments. Generally, the sensors of the sensor set 310 include sensors that sense some aspect of the environment of the BS110 and have the potential to sense parameters that have at least some influence on or reflect the RF propagation path of the BS110 to the corresponding UE 108 or the RF transmit / receive performance of the BS110. The sensors of the sensor set 310 may include one or more sensors for object detection, such as radar sensors, lidar sensors, imaging sensors, and structured light-based depth sensors. If the BS110 is a mobile BS, the sensor set 310 may also include one or more sensors for determining the position or attitude / orientation of the BS110. Other examples of sensors in the sensor set 310 include imaging sensors, light sensors for detecting objects approaching features of the BS110, and so on.

[0042] One or more memories 308 of the BS110 store one or more sets of executable software instructions and associated data for operating one or more processors 306 and other components of the BS110, and perform various functions belonging to the BS110 in one or more embodiments. The set of executable software instructions includes, for example, an OS and various drivers (not shown), as well as various software applications. The set of executable software instructions further includes one or more of the neural network management module 314, the RACH management module 142, or the function management module 318.

[0043] The neural network management module 314 implements one or more neural networks in the BS110, as described in detail below. When the BS110 does not implement a corresponding RACH DNN, or when the RACH DNN is not configured to perform a specific RACH operation, the RACH management module 142 operates to perform one or more conventional (non-DNN) RACH operations. The function management module 318 determines various functions of the BS110 related to the neural network configuration or selection and reports such functions to the management component 154. Similarly, it monitors the BS110 for changes in such functions, including changes in RF and processing functions, and manages the reporting of such functions to the management component 154 and changes in functions.

[0044] To facilitate the operation of BS110, one or more memories 308 of BS110 may further store data associated with these operations. This data may include, for example, RACH configuration information 320, BS data 322, and one or more neural network architecture configurations 324. RACH configuration information 320 represents, for example, an indication of whether CFRA or CBRA (2-step or 4-step) should be performed by BS110 with respect to a given UE108, the number of RACH occasions available per SSB indicated to UE108 by BS110, the number of available competition-based preambles indicated to UE108 by BS110, the preamble assigned to UE108 by BS110, frequency domain resources assigned to UE108 by BS110, time domain resources (slots and symbols) assigned to UE108 by BS110, and initial power for PRACH transmission indicated to UE108 by BS110.

[0045] BS data 322 may represent, for example, a beamforming codebook and software application configuration information. BS data 322 may further include functional information for BS110, such as sensor function information for one or more sensors in sensor set 310, including the presence or absence of a specific sensor or sensor type, and for present sensors, one or more representations of corresponding functions, such as the range and resolution of a LiDAR or radar sensor, and the image resolution and color depth of an imaging camera. One or more neural network architecture configurations 324 represent BS implementation examples selected from a set 412 of candidate neural network architecture configurations 414 maintained by the management component 154. Thus, similar to the neural network architecture configuration 224 in Figure 2, each neural network architecture configuration 324 includes one or more data structures containing data and other information representing the corresponding architecture and / or parameter configuration used by the neural network management module 314 to form the corresponding neural network of BS110.

[0046] Figure 4 shows exemplary hardware configurations of the management component 154 according to several embodiments. Note that the illustrated hardware configurations represent the processing and communication components most directly related to the neural network-based process of one or more embodiments, and certain components that are well understood to be frequently implemented in such electronic devices have been omitted. Furthermore, although the hardware configurations are shown as being located in a single component, the functionality of the management component 154, and therefore the hardware component, can be distributed across multiple infrastructure components or nodes, and can be distributed in a manner that performs the functionality of one or more embodiments.

[0047] As described above, the management component 154 can be implemented in any one or a combination of various components within the network infrastructure 106. For the sake of clarity, the management component 154 will be described with reference to an example implementation as one server or another component of the core network 102, but in other embodiments, the management component 154 may be implemented, for example, as part of BS110.

[0048] As shown in the figure, the management component 154 includes one or more network interfaces 402 (e.g., Ethernet® interfaces) connected to one or more networks of the system 100, one or more processors 404 connected to one or more network interfaces 402, and one or more non-temporary computer-readable storage media 406 (referred to herein for brevity as “memory 406”) connected to one or more processors 404. The one or more memories 406 store one or more sets of executable software instructions and associated data for operating one or more processors 404 and other components of the management component 154, and perform various functions belonging to the management component 154 in one or more embodiments. The sets of executable software instructions include, for example, an OS and various drivers (not shown).

[0049] The software stored in one or more memories 406 may further include one or more of the training modules 408 or the neural network selection modules 410. The training module 408 operates to manage individual and joint training of candidate neural network architecture configurations 414 for a set of candidate neural networks 412 that can be used by transmitting and receiving devices in the RACH path, using one or more sets of training data 416. Training may include training the neural networks while offline (i.e., when not actively involved in processing communications) and / or online (i.e., while actively involved in processing communications). For example, the training module 408 may use one or more sets of training data to individually or jointly train RACH DNNs implemented by at least one of the TX processing modules and RX processing modules of the UE108 and BS110 in order to provide RACH functionality. The offline or online training process can implement different RACH parameters for different RACH scenarios, including initial RRC connection setup, RRC connection re-establishment, handover, downlink data arrival, uplink data arrival, scheduling request failure, addition of new radio (NR) cells for dual connection, and beam recovery.

[0050] In at least some embodiments, the training module 408 also trains the RACH DNN for different RA configurations such as CFRA, 2-step CFRA / CBRA, or 4-step CBRA. The training module 408 can train the CFRA TX and RX DNNs, 2-step CFRA / CBRA TX and RX DNNs, and 4-step CBRA TX and RX DNNs together. In some embodiments, the training module 408 trains the TX DNNs and RX DNNs of BS110 and adjacent cells together to minimize the effects of same-channel interference. The training module 408 can also train the TX DNN of UE108 together with the corresponding RX DNN of UE108, and the RX DNN of BS110 together with the TX DNN of BS110. In other embodiments, the training module 408 trains individual TX DNNs and RX DNNs of UE108, or one or more pairs of TX DNNs and RX DNNs, in conjunction with one or more corresponding individual RX DNNs and TX DNNs, or pairs of RX DNNs and TX DNNs, of BS(or BS)110. In at least some embodiments, the training module 408 trains the RACH DNNs of UE108 based on one or both of the cell size of BS110 and the selection of RACH DNNs of other cells. For example, the training module 408 trains the RACH DNNs to generate different RACH sequences in neighboring cells to reduce the likelihood that a first BS will detect RACH from a UE attempting to connect with a second BS.

[0051] The training module 408 can perform offline training by collecting RACH-related metrics while BS110 is being installed / updated, or by using a simulation environment. Furthermore, the training module 408 can perform online training during the handover procedure or while adding secondary cell groups, so that the training module 408 can estimate RACH performance and update the RACH DNN by gradient descent. Additionally, training can be performed individually or separately so that each RACH DNN is trained individually on its own training dataset, with the results being transmitted to the RACH DNN training at the opposite end of the transmission path, or otherwise without affecting it, or training can be collaborative training so that RACH DNNs in the data stream transmission path are trained together on the same or complementary datasets.

[0052] The neural network selection module 410 operates to retrieve, filter, and otherwise process selection-related information 418 from one or both of the UE108 or BS110 in the RACH path, and uses this selection-related information 418 to select individual neural network architecture configurations 414 or a pair of neural network architecture configurations 414 jointly trained from a candidate set 412 for implementation at the transmitting and receiving devices in the RACH path. As described above, this selection-related information 418 may include one or more of the following, for example, UE function information 420 or BS function information 422, current propagation path information, and channel-specific parameters. After the neural network selection module 410 has made a selection, it then begins to transmit indications of the selected neural network architecture configurations 414 for each network component, for example, by transmitting an index number associated with the selected configuration, by transmitting one or more data structures representing the neural network architecture configuration itself, or a combination thereof.

[0053] Figure 5 shows an exemplary machine learning (ML) module 500 for implementing a neural network in several embodiments. At least one UE108 and BS110 in the RACH path 114 implement one or more RACH DNNs or other neural networks for one or more of the following: transmitting a RACH signal, processing a RACH signal, transmitting a RAR signal, processing a RAR signal, transmitting a PUSCH signal, processing a PUSCH signal, transmitting a CR signal, and processing a CR signal. Thus, the ML module 500 shows an exemplary module for implementing one or more of these neural networks.

[0054] In the illustrated example, the ML module 500 implements at least one deep neural network (DNN) 502 having groups of connected nodes (e.g., neurons and / or perceptrons) organized into three or more layers. The nodes between layers can be configured in various ways, such as a partial connection configuration where a first subset of nodes in the first layer is connected to a second subset of nodes in the second layer, or a full connection configuration where each node in the first layer is connected to each node in the second layer. Neurons process input data and produce continuous output values, such as any real number between 0 and 1. In some cases, the output values ​​indicate how close the input data is to a desired category. Perceptrons perform linear classification, such as binary classification, on the input data. Nodes, whether neurons or perceptrons, can use various algorithms to generate output information based on adaptive learning. Using DNN502, ML Module 500 performs a variety of different types of analysis, including single linear regression, multiple linear regression, logistic regression, stepwise regression, binary classification, multi-class classification, multivariate adaptive regression splines, and locally estimated scatter plot smoothing.

[0055] In some embodiments, the ML module 500 adaptively learns based on supervised learning. In supervised learning, the ML module 500 receives various types of input data as training data. The ML module 500 processes the training data to learn how to map the inputs to desired outputs. For example, when the ML module 500 is equipped with a UE PRACH signal in TX mode, it receives one or more of the following as inputs: RACH configuration information, UE sensor data or related information, UE108 functional information, BS110 functional information, UE1108 operating environment characteristics, BS110 operating environment characteristics, etc., and learns how to map this input training data to one or more configured output RACH signals to be transmitted to, for example, BS110. As another example, when the ML module 500 is implemented in BS PRACH signal RX mode, it receives one or more representations of the received RACH signal (e.g., a separate PRACH signal, a PUSCH signal combined with a PRACH signal, or a separate PUSCH signal) as input and learns how to map this input training data to outputs that represent one or more of the following: an indicator of the RACH signal type, UL TX timing / progress estimate, RAR information, CR information, etc. As yet another example, when the ML module 500 is implemented in BS RAR signal TX mode, it receives one or more of the following as input: an indicator of the RACH signal type, UL TX timing / progress estimate, RAR information, CR information, etc. and learns how to generate one or more configured output RAR (or CR) signals (e.g., a separate RAR signal, a CR signal combined with a RAR signal, or a separate CR signal) to send to the UE108. As yet another example, when the ML module 500 is implemented in UE RAR signal RX mode, it learns how to receive one or more of the following as inputs: RAR (or CR) signal, RAR information, CR information, etc., and generate an output that indicates RACH success or RACH failure.In at least some embodiments, training in either or both TX mode or RX mode may further include training using sensor data as input, functional information as input, RF antenna configuration or other operating parameter information as input, etc.

[0056] During the training procedure, the ML module 500 uses labeled or known data as input to the DNN502. The DNN502 uses nodes to analyze the input and generate corresponding outputs. The ML module 500 compares the corresponding outputs to true data and adapts the algorithms implemented by the nodes to improve the accuracy of the output data. The DNN502 then applies the adapted algorithms to unlabeled input data to generate corresponding output data. The ML module 500 maps inputs to outputs using either or both statistical analysis and adaptive learning. For example, the ML module 500 uses characteristics learned from the training data to correlate unknown inputs to outputs that are statistically likely to be within or within a threshold range. This allows the ML module 500 to receive complex inputs and identify corresponding outputs. In some embodiments, the training process trains the ML module 500 on the characteristics of communications transmitted over a wireless communication system (e.g., time / frequency interleaving, time / frequency deinterleaving, convolutional coding, convolutional decoding, power levels, channel equalization, intersymbol interference, quadrature amplitude modulation / demodulation, frequency division multiplexing / demultiplexing, transmit channel characteristics) as well as the characteristics of the data coding / decoding scheme used in the system. This allows the trained ML module 500 to receive a sample of a signal as input and recover information from the signal, such as binary data embedded in the signal.

[0057] In the illustrated example, the DNN 502 includes an input layer 504, an output layer 506, and one or more hidden layers 508 positioned between the input layer 504 and the output layer 506. Each layer may have any number of nodes, and the number of nodes between layers may be the same or different. That is, the input layer 504 may have the same and / or different number of nodes as the output layer 506, the output layer 506 may have the same and / or different number of nodes as the one or more hidden layers 508, and so on.

[0058] Node 510 corresponds to one of several nodes included in the input layer 504, and each node performs a separate, independent computation. As will be explained further, a node receives input data and processes it using one or more algorithms to produce output data. Typically, the algorithms include weights and / or coefficients that change based on adaptive learning. Thus, the weights and / or coefficients reflect the information learned by the neural network. Each node can, in some cases, decide whether to pass the input data to be processed to one or more subsequent nodes. For example, after processing the input data, node 510 can decide whether to pass the processed input data to one or both of nodes 512 and 514 in the hidden layer 508. Alternatively or additionally, node 510 passes the processed input data to nodes based on the layer-connected architecture. This process can be repeated across multiple layers until the DNN 502 produces an output using a node in the output layer 506 (e.g., node 516).

[0059] Neural networks can also use various architectures that determine which nodes are connected within the neural network, how data is passed and / or held within the neural network, what weights and coefficients the neural network uses to process input data, and how the data is processed. These various factors collectively describe neural network architecture configurations, such as the neural network architecture configurations briefly described above. To explain, recurrent neural networks, such as Long Short-Term Memory (LSTM) neural networks, form cycles between node connections to hold information from the previous part of the input data sequence. The recurrent neural network then uses the held information for the subsequent part of the input data sequence. As another example, feedforward neural networks pass information through connections without forming cycles to hold information. While described in the context of node connections, it should be understood that neural network architecture configurations can include various parameter configurations that affect how DNN502 or other neural networks process input data.

[0060] The neural network architecture configuration of a neural network can be characterized by various architectures and / or parameter configurations. To illustrate this, consider the example of DNN502, which implements a convolutional neural network (CNN). In general, a convolutional neural network corresponds to a type of DNN in which layers process and filter input data using convolutional operations. Therefore, the CNN architecture configuration can be characterized, for example, by pooling parameters(s), kernel parameters(s), weights, and / or layer parameters(s).

[0061] Pooling parameters correspond to parameters that specify pooling layers within a convolutional neural network, reducing the dimensionality of the input data. In essence, a pooling layer can combine the outputs of nodes in a first layer into the inputs of nodes in a second layer. Alternatively or additionally, pooling parameters specify how and where the neural network pools data in the data processing layer. For example, a pooling parameter indicating "maximum pooling" configures the neural network to pool the maximum value from a group of data generated by the nodes of the first layer and use that maximum value as the input to a single node in the second layer. A pooling parameter indicating "average pooling" configures the neural network to generate an average value from a group of data generated by the nodes of the first layer and use that average value as the input to a single node in the second layer.

[0062] The kernel parameters indicate the filter size (e.g., width and height) used to process the input data. Alternatively or additionally, the kernel parameters specify the type of kernel method used to filter and process the input data. For example, a support vector machine corresponds to a kernel method that uses regression analysis to identify and / or classify data. Other types of kernel methods include Gaussian processes, canonical correlation analysis, and spectral clustering methods. Thus, the kernel parameters can indicate the filter size and / or type of kernel method to apply to the neural network. The weight parameters specify the weights and biases used by the algorithm within the node to classify the input data. In some embodiments, the weights and biases are trained parameter configurations, such as parameter configurations generated from training data. The layer parameters specify layer connectivity and / or layer types, such as a fully connected layer type, which indicates that all nodes in a first layer (e.g., output layer 506) are connected to all nodes in a second layer (e.g., hidden layer 508); a partially connected layer type, which indicates which nodes in the first layer are disconnected from the second layer; and an activated layer type, which indicates which filters and / or layers are activated within the neural network. Alternatively or additionally, layer parameters specify the type of node layer, such as normalization layer type, convolutional layer type, and pooling layer type.

[0063] While pooling parameters, kernel parameters, weight parameters, and layer parameters are discussed in this context, it will be understood that other parameter configurations can be used to form a DNN that conforms to the guidelines provided herein. Thus, a neural network architecture configuration can include any appropriate type of configuration parameters to which the DNN can apply, influencing how the DNN processes input data and produces output data.

[0064] In at least some embodiments, the architectural configuration of the ML module 500 is based on the functionality (including sensors) of one or more nodes upstream or downstream of the node implementing the ML module 500, or a combination thereof, of the nodes implementing the ML module 500. For example, UE108 enables or disables one or more sensors or limits battery power. In this example, both the ML module 500 of UE108 and BS110 are trained on different sensor configurations or battery power of UE108 as input, making it easier, for example, for the ML modules 500 at both ends to use RACH techniques better suited to different sensor configurations or lower power consumption of UE108. Thus, in some embodiments, the device implementing the ML module 500 is configured to implement different neural network architecture configurations for different combinations of functional parameters, sensor parameters, RF environment parameters, operating parameters, etc. For example, the device can access one or more neural network architecture configurations for use depending on the current state of the UE battery 212.

[0065] In at least some embodiments, a device implementing the ML module 500 locally stores some or all of the set of candidate neural network architecture configurations that the ML module 500 can use. For example, a component may index candidate neural network architecture configurations by a lookup table (LUT) or other data structure that takes one or more parameters as input, such as one or more UE function parameters, one or more BS function parameters, one or more UE operation parameters, one or more BS operation parameters, one or more channel parameters, and output an identifier associated with the locally stored corresponding candidate neural network architecture configuration suitable for operation considering the input parameters(s). However, in some embodiments, the neural network used in UE108 and the neural network used in BS110 are trained together, so a mechanism is used between UE108 and BS110 to ensure that each device selects a neural network architecture configuration for its ML module 500 that is trained together with, or at least operationally compatible with, the neural network architecture configuration selected by other devices for their complementary ML module 500. This mechanism may include, for example, coordinating signal transmission between UE108 and BS110, either directly or via the management component 154, or the management component 154 may function as a criterion for selecting a compatible, jointly trained pair of architectural configurations from a subset proposed by each device.

[0066] In other embodiments, it may be more efficient, or otherwise advantageous, to operate the management component 154 to select a pair of appropriately jointly trained neural network architecture configurations to be used in the corresponding ML modules 500 of the transmitting and receiving devices. In this approach, the management component 154 obtains information from the transmitting and receiving devices representing some or all of the parameters that can be used in the selection process, and from this information selects a pair of jointly trained neural network architecture configurations 414 from a set 412 of such configurations maintained by the management component 154. In at least some embodiments, the management component 154 (or another network component) performs this selection process using, for example, one or more algorithms, LUTs, etc. The management component 154 then transmits to each device an identifier or another indication (if each device has a locally stored copy) of the neural network architecture configuration selected for its ML module 500, or the management component 154 transmits one or more data structures representing the neural network architecture configuration selected for that device.

[0067] To facilitate the process of selecting appropriate individual neural network architecture configurations or a pair of neural network architecture configurations for the transmitting and receiving devices, in at least one embodiment, the management component 154 trains the ML module 500 on the RACH route 114 using an appropriate combination of a neural network management module and a training module. Training can be performed offline when no active communication exchange is occurring, or online during active communication exchange. For example, the management component 154 can mathematically generate training data, access a file to store the training data, and retrieve real-world communication data. The management component 154 then extracts and stores the various neural network architecture configurations to be learned for subsequent use. In some embodiments, input characteristics are stored along with each neural network architecture configuration, thereby the input characteristics describe various characteristics of one or both of the operational characteristics and functional configurations of the UE 108 or BS 110 corresponding to each neural network architecture configuration. In this embodiment, the neural network manager selects a neural network architecture configuration by matching one or more current operating environments, either UE108 or BS110, to input characteristics, the current operating environment including indication of the functions of one or more nodes along the training RACH path, such as sensor functions, RF functions, and processing functions.

[0068] As described above, network devices that perform wireless communication, such as the UE108 or BS110, can be configured to handle wireless communication exchanges using one or more DNNs in each network device, each DNN replacing and / or adding new functions to one or more functions conventionally implemented by one or more hardcoded blocks or fixed-design blocks in order to facilitate the RACH process. Furthermore, each DNN can further incorporate current sensor data from one or more sensors in the network device's sensor set, and / or function data from some or all of the nodes in the RACH route 114, thereby modifying or otherwise adapting its operation to take into account the current operating environment.

[0069] For this purpose, Figure 6 shows an exemplary operating environment 600 for a DNN implementation in the exemplary RACH path 114 of Figure 1. In the illustrated example, the operating environment 600 uses a neural network-based approach to facilitate RACH operation. In at least one embodiment, the neural network management module 216 of UE108 implements the UE PRACH TX processing module 618, and the neural network management module 314 of BS110 implements the BS PRACH RX processing module 638. The neural network management module 314 of BS110 further implements the BS RAR TX processing module 646, and the neural network management module 216 of UE108 further implements the UE RAR RX processing module 630.

[0070] In at least some embodiments, one or more of these processing modules implement at least one DNN through the implementation of the corresponding ML module, as described above with reference to one or more DNNs 502 of the ML module 500 in Figure 5. For example, the UE PRACH TX processing module 618 implements the UE PRACH TX DNN 118, the BS PRACH RX processing module 638 implements the BS PRACH RX DNN 138, the BS RAR TX processing module 646 implements the BS RAR TX DNN 146, and the UE RAR RX processing module 630 implements the UE RAR RX DNN 130. In at least some embodiments, the UE PRACH TX processing module 618 of UE108 and the BS PRACH TX processing module 638 of BS110 interact to support a neural network-based wireless communication path for the uplink between UE108 and BS110 to generate and communicate data to facilitate RACH operation. Similarly, in at least some embodiments, the BS RAR TX processing module 646 of BS110 and the UE RAR processing module 630 of UE108 interact to support a downlink neural network-based wireless communication path between UE108 and BS1101 for generating and communicating data to facilitate RACH operation. In other embodiments, UE108 and BS110 do not implement all of the DNNs described herein. For example, BS110 may not implement any DNNs, or it may implement only one DNN.

[0071] One or more trained DNNs in the UE PRACH TX processing module 618 of UE108 receive inputs such as RACH configuration information 120, sensor data 122, and payload / data 614 for PUSCH transmission. In at least some embodiments, the DNN(s) of the UE PRACH TX processing module 618 receive RACH configuration information 120 from the BS110 or UE108's RACH management module 220, as described above with respect to Figure 1. In one example, the UE PRACH TX processing module 618 receives one or more of the RACH configuration information 120, payload / data 614, or sensor data 122 as inputs during or in response to RACH-related events, such as initial RRC connection setup, RRC connection re-establishment, handover, downlink data arrival, uplink data arrival, scheduling request failure, addition of a new radio (NR) cell for dual connection, and beam recovery. In at least some of these RACH-related events, BS110 sends RACH configuration information 120 to UE108 using a dedicated RRC message.

[0072] In at least some embodiments, the DNN(s) of the UE PRACH TX processing module 618 receive sensor data 122 (or related information) from the sensor set 210 of the UE 108. Furthermore, it will be understood that the capabilities of the UE 108, including the available sensors, may change from time to time. For example, the UE 108 may disable one or more sensors based on the current battery level, thermal state, or another state of the UE 108. To complement the various sensor capabilities, in at least some embodiments, the management component 154 (or another component) trains one or more DNNs of the UE PRACH TX processing module 618 based on different sensor data 122 inputs to provide a PRACH TX output that takes into account the different sensor capabilities of the UE 108.

[0073] From one or more of the RACH configuration information 120 input, PUSCH data 614, sensor data input 122, or other relevant inputs, one or more DNNs of the UE PRACH TX processing module 618 are trained to generate and configure an output containing one or more RACH signals 124. In one example, one or more DNNs of the UE PRACH TX processing module 618 generate RACH signals 124 based on a dedicated RACH preamble identified in the RACH configuration information 120. If the RACH configuration information 120 does not indicate a dedicated RACH preamble assigned to the UE 108 by BS 110, one or more DNNs of the UE PRACH TX processing module 618 can select a RACH preamble from the available competition-based preambles. In one example, the RACH configuration information 120 indicates the available competition-based preambles. One or more DNNs in the UE PRACH TX processing module 618 can also select a RACH occasion characterized by a RACH time-frequency resource associated with a detected or selected SSB in order to transmit a RACH signal 124.

[0074] In the Msg1 stage of a CFRA or 4-step CBRA configuration, the RACH signal 124 includes a PRACH signal 610, which is generated using a RACH preamble and configured for transmission by UE 108 via PRACH. In at least some embodiments, the PRACH signal 610 is associated with, for example, the ID of the preamble ID (UEID) of UE 108. In one example, the UEID is an RA Radio Network Temporary Identifier (RA-RNTI), which is implicitly specified by the timing of the preamble transmission. In the MsgA stage of a 2-step CFRA / CBRA configuration, the RACH signal 124 includes a PUSCH signal 612 in addition to the PRACH signal 610. For example, one or more DNNs of the UE PRACH TX processing module 618 receive input such as a PUSCH payload / data 614, a PUSCH assignment, etc. From this input, one or more DNNs of the UE PRACH TX processing module 618 generate a RACH signal 124 output, which includes a PUSCH signal 612 in addition to a PRACH signal 610. The PUSCH signal 612 includes, for example, a payload to a higher protocol layer, an RRC connection request, etc. In at least some embodiments, the UE PRACH TX DNN 118 implemented by the UE PRACH TX processing module 618 includes a separate PUSCH TX portion to generate the PUSCH signal 612. In other embodiments, a separate PUSCH TX DNN (not shown) is used by the UE PRACH TX processing module 618.

[0075] The RF antenna interface 204 and one or more antennas 202 of the UE108 convert the output of the RACH signal 124 into a corresponding RF signal 616 that is transmitted wirelessly for reception by the BS110. The RF signal 616 is received and processed by the BS110 via one or more antennas 302 and the RF antenna interface 304. One or more DNNs of the BS110's BS PRACH RX processing module 638 receive the resulting captured RACH signal 124 as input and are trained to generate a corresponding output from these inputs. In at least some embodiments, the DNN(s) of the BS PRACH RX processing module 638 include a separate PUSCH RX for receiving the PUSCH signal 612 from the UE108. In other embodiments, a separate PUSCH RX DNN is used by the DNN(s) of the BS PRACH RX processing module 638. In some embodiments, the BS PRACH RX processing module 638 does not implement a DNN(s) and uses one or more conventional mechanisms to receive / process the RACH signal 124 and generate an output. In at least some embodiments, the generated output includes RACH signal information 617 and UL TX timing estimates 620.

[0076] In at least some embodiments, the BS RACH management module 142 receives outputs from one or more DNNs of the BS PRACH RX processing module 638. The BS RACH management module 142 processes outputs such as RACH signal information 617 and UL TX timing estimates 620 and generates one or more of the corresponding RAR information 622 or CR information 624. In at least some embodiments, the RAR information 622 is generated by the BS RACH management module 142 in response to the BS 110 receiving a separate PRACH signal 610 (Msg1) or in response to the PRACH signal 610 in addition to the PUSCH signal 612 (MsgA). In at least some embodiments, the CR information 624 is generated by the BS RACH management module 142 in response to the reception of a separate PUSCH signal 612 (Msg3) or in response to the reception of the PUSCH signal 612 in addition to the PRACH signal 610 (MsgA). RAR information 622 includes, for example, the RACH preamble identifier (RAPID) associated with the PRACH signal 610, the UEID, the Cell Radio Network Temporary Identifier (C-RNTI) assigned to UE108, a backoff indicator, timing advance, UL resource grant, etc., or is associated with them. If the UEID is RAPID, the RACH management module 142 can derive the UEID from the time slot number in which BS110 receives the PRACH signal 610. CR information 624 includes, for example, a backoff indicator, fallback RAR, success RAR, RRC connection setup information, etc. The BS RACH management module 142 can also assign C-RNTI to UE108, which BS110 uses to address UE108 in subsequent messages. In other embodiments, one or more DNNs of the BS PRACH RX processing module 638 generate either or both of the RAR information 622 or CR information 624 instead of the BS RACH management module 142. In at least some embodiments, one or more DNNs of the BS PRACH RX processing module 638 also assign C-RNTI to UE108.

[0077] The BS RACH management module 142 (or BS PRACH RX processing module 638) provides one or both of the RAR information 622 and CR information 624 as input to the BS RAR TX processing module 646. For example, in the Msg2 stage of a CFRA or 4-step CBRA configuration, the BS RAR TX processing module 646 receives the RAR information 622 as input. From this input, one or more DNNs of the BS RAR TX processing module 646 generate an output RAR signal 150 configured for transmission over the Download Shared Channel (DL-SCH) and carried by the PDSCH. In this configuration, the RAR signal 150 represents a RAR message containing or associated with information such as the RAPID, timing and uplink resource allocation (i.e., timing advance and UL resource grant), backoff indicator, and C-RNTI of the preamble associated with the PRACH signal 610 transmitted by the UE 108. In the Msg4 stage of the 4-step CBRA configuration, the BS RAR TX processing module 646 (or a separate BS CR TX processing module) receives CR information 624 as input. From this input, one or more DNNs of the BS RAR TX module 646 (or a separate BS CR TX processing module) generate a separate CR signal 1412 output for transmission on the PDSCH instead of the RAR signal 150. The CR signal output represents a CR message, including, for example, a CRID corresponding to the UEID of UE108, RRC connection setup information, etc. In the MsgB stage of the 2-step CFRA / CBRA configuration, the BS RAR TX processing module 646 receives both RAR information 622 and CR information 624 as input. From this input, one or more DNNs of the BS RAR TX processing module 646 generate a RAR signal 150 output representing the combination of the RAR information 622 and CR information 624 described above. In at least some embodiments, the DNN(s) of the BS RAR TX processing module 646 for generating the RAR signal 150 includes a separate CR TX portion for generating the CR signal 1412. In other embodiments, the BS RAR TX processing module 646 implements a separate CR TX DNN.In other embodiments, the BS RAR TX processing module 646 does not implement one or more DNNs and generates the RAR signal 150 using one or more conventional mechanisms.

[0078] In at least some embodiments, the output generated by one or more DNNs of the BS RAR TX processing module 646 (or a conventional TX mechanism) includes downlink control information (DCI) associated with the RAR signal 150 (e.g., Msg2 / MsgB), or individual CR signals 1412 (Msg4). The TX neural network (or conventional TX mechanism) scrambles the DCI with the UEID of UE108. The DCI allows UE108 to decode the RAR signal 150 or CR signal 1412 and obtain the RAR information 622 and CR information 624.

[0079] The BS110's RF antenna interface 304 and one or more antennas 302 convert the RAR (or CR) signal 150 output into a corresponding RF signal 626 that is transmitted wirelessly for reception by the UE 108. The RF front-end 304 transmits the DCI associated with the RAR (or CR) signal 150 over the physical downlink control channel (PDCCH) and the RAR and CR information associated with the RAR (or CR) signal 150 over the DL-SCH, which is carried by the PDSCH. The RF signal 626 is received and processed by the UE 108 via one or more antennas 202 and the RF antenna interface 204. One or more DNNs of the UE RAR RX processing module 630 receive the resulting captured RAR signal 150 or CR signal 1412 as input and are trained to generate corresponding outputs from these inputs. In at least some embodiments, the DNN(s) of the UE RAR RX processing module 630 include a separate CR RX portion for receiving the CR signal 1412. In other embodiments, a separate CR RX DNN is used by the UE RAR RX processing module 630. However, in at least some embodiments, the UE RAR RX processing module 630 does not implement a DNN(s) and uses one or more conventional mechanisms to receive / process the RAR signal 150 or CR signal 1412 and generate an output. Also, the RAR signal 150 or CR signal 1412 received by the UE RAR RX processing module 630 via the RF signal 626 can be a signal created by a DNN, a conventionally created signal, or a combination thereof.

[0080] In a CFRA configuration, the RAR signal 150 represents a RAR message (Msg2), and one or more DNNs in the UE RAR RX processing module 630 process the RAR signal 150 to determine whether the RACH procedure was successful or failed. In one example, one or more DNNs determine that the RACH procedure was successful if they can decode the PDCCH associated with the RAR signal 150 using the UEID of UE108 within a given RAR window. Otherwise, one or more DNNs consider the RACH procedure to have failed. In at least some embodiments, one or more DNNs in the UE RAR RX processing module 630 output an indication 132 that the RACH procedure was successful, or an indication 134 that the RACH procedure failed, and provide this indication to another component of UE108, such as the RACH management module 220. This component can use these indicators 132 or 134 to determine whether UE108 should perform additional RACH steps. For example, if the RACH management module 220 receives an indication 134 that the RACH procedure was unsuccessful, the RACH management module 220 configures the UE 108 to retry the RACH procedure. The UE then repeats the above technique. In at least some embodiments, when retrying the RACH procedure, the UE may select a new TX neural network architecture for the UE PRACH TX processing module 618, or it may use the same TX network architecture having higher transmit power and / or different weights for the neural network. In at least some embodiments, if the RACH procedure is successful, one or more DNNs in the UE RAR RX processing module 630 output information such as timing advance and UL resource grant obtained from the RAR signal 150.One or more DNNs in the UE PRACH TX processing module 618 (or a separate PUSCH TX processing module) can receive this information and generate an output representing a PUSCH signal (Msg3), which may include, for example, a payload to the higher protocol layer, an RRC connection request, etc. The RF antenna interface 204 and one or more antennas 202 of the UE108 convert the PUSCH signal output into a corresponding RF signal that is transmitted wirelessly via PUSCH for reception by the BS110. The UE108 then enters the RRC connection state.

[0081] In a 4-step CBRA configuration, one or more DNNs in the UE RAR RX processing module 630 (or a separate UE CR RX processing module) receive the CR signal 1412 instead of the RAR signal 150. One or more DNNs process the CR signal 1412 to determine whether the RACH procedure was successful or failed. In one example, one or more DNNs determine that the RACH procedure was successful if, before the CR timer expires, one or more DNNs can decode the PDCCH associated with the CR signal using the UEID of UE108, or if they determine that the UEID associated with the PDCCH is the same as the UEID associated with the PUSCH signal 612 (Msg3) transmitted by UE108. Otherwise, one or more DNNs consider the RACH procedure to have failed. In at least some embodiments, one or more DNNs in the UE RAR RX processing module 630 output RACH success / failure indicators 132 or 134, similar to the CFRA configuration described above. If the RACH procedure is successful, UE108 enters the RRC connected state. If the RACH procedure fails, UE108 retries the RACH procedure and repeats the above technique.

[0082] In a two-step CFRA / CBRA configuration, the RAR signal 150 represents a combination of the RAR signal 150 (Msg2) and the CR signal 1412 (Msg4). This combined message can be called MsgB. One or more DNNs in the UE RAR RX processing module 630 process the RAR signal 150 to determine whether the RACH procedure was successful or failed. For example, one or more DNNs determine that the RACH procedure has failed if the RAR signal 150 associated with the UEID of the UE108 is not received by the UE108 within a given window. Otherwise, one or more DNNs determine that the RACH procedure was successful. In at least some embodiments, one or more DNNs in the UE RAR RX processing module 630 output a RACH success / failure indicator 132 or 134, similar to the CFRA configuration described above. If the RACH procedure fails, the UE108 retries the RACH procedure and repeats the technique described above.

[0083] If the RACH procedure is successful, one or more DNNs in the UE RAR RX processing module 630 further process the RAR signal 150 to determine whether the RAR signal 150 contains a fallback RAR indicator or a success RAR indicator. The fallback RAR indicator may be associated with the preamble ID of the PRACH signal 610 sent by UE 108, a time advance command, etc., and may contain a UL grant for retransmission of the PUSCH signal 612 portion of the RACH signal 124 (MsgA) by UE 108. The success RAR indicator may indicate the conflict resolution ID of UE 108 (e.g., UEID), the C-RNTI of UE 108, or a time advance command to UE 108. If the RAR signal 150 includes a success RAR indicator associated with the UEID of UE108, this indicates that BS110 detected the preamble associated with the PRACH signal 610 portion of the RACH signal 124 and successfully decoded the PUSCH signal 612 portion of the RACH signal 124. Thus, UE108 enters the RRC connected state. However, if the RAR signal 150 includes a fallback RAR indicator, this indicates that BS110 detected the preamble associated with the PRACH signal 610 portion of the RACH signal 124 transmitted by UE108, but was unable to successfully decode the PUSCH signal 612 portion. Thus, one or more DNNs generate an output that includes, for example, information from the fallback indicator. This information may be included in the RACH success indicator 132 or the RACH failure indicator 134, or it may be separate from them. The UE108's RACH management module 220, DNN, or other component can configure the UE PRACH TX processing module 618 to retransmit the PUSCH payload using the output generated by one or more DNNs of the UE RAR RX processing module 630. In some embodiments, the UE can generate the PUSCH payload using a different TX neural network than the one used to generate the output of MsgA.

[0084] Therefore, one or more DNNs in the UE PRACH TX processing module 618, BS PRACH RX processing module 638, BS RAR TX processing module 646, and UE RAR RX processing module 630 actually provide processing that results in processing of the respective received signals or generating output signals, and such processing is trained on one or more DNNs through individual or joint training, rather than being a cumbersome and inefficient process of hard-coating algorithms or separate discrete processing blocks into the same process.

[0085] DNNs or other neural networks for implementing the RACH path between UE108 and BS110 offer design flexibility, facilitate efficient updates compared to traditional block-by-block design and test approaches, and allow RACH path devices to quickly adapt to generating, transmitting, and processing RACH-related signals based on current operating parameters and functions. However, before DNNs can be deployed and begin operation, they are typically trained or otherwise configured to provide appropriate outputs for a given set of one or more inputs. For this purpose, Figure 7 shows an exemplary method 700 for deploying one or more co-trained DNN architecture configurations as an optional selection of RACH path devices for different operating environments or functions, according to several embodiments. Note that the order of operations described with reference to Figure 7 is illustrative only, and operations may be performed in a different order, one or more operations may be omitted, or one or more additional operations may be included in the illustrated method. Furthermore, while Figure 7 shows an offline training approach using one or more test nodes, it should be noted that a similar approach can be implemented for online training using one or more nodes in active operation. Furthermore, in at least some embodiments, one or more DNNs from UE108 or BS110 are trained individually rather than jointly.

[0086] As described above, the operation of a DNN used by one or both devices in a DNN chain forming a corresponding RACH path may be based on specific functional and current operational parameters of the RACH path, such as the operational parameters and / or capabilities of the devices using the corresponding DNN, one or more upstream or downstream devices, or a combination thereof. These functional and operational parameters may include, for example, the type of sensor used to sense the current status of a device, the functionality of such a sensor, the power capacity of one or more devices, the processing capabilities of one or more devices, and the RF antenna interface configuration of one or more devices (e.g., number of beams, antenna ports, supported frequencies). Since the described DNN uses such information to instruct its operation, it will often be understood that a particular DNN configuration implemented in one of the nodes is based on the specific functional and operational parameters currently used in that device or the device on the other side of the RACH path. In other words, the specific DNN configuration implemented reflects the functional information and operational parameters currently indicated by the RACH path implemented by the UE and BS110.

[0087] Therefore, Method 700 begins in block 702 with the identification of the expected functionality (including expected operating parameters or parameter ranges) of one or more test nodes in a test RACH path, which include one or more test UEs and one or more test BSs (also referred to as “test devices” for brevity). Hereafter, we assume that the functional information of the test devices is known to the training module 408 of the management component 154 (e.g., via a database or another locally stored data structure that stores this information) because the training module 408 of the management component 154 manages the joint training. However, since the management component 154 is unlikely to have prior knowledge of the functionality of any given UE, the test UE provides the management component 154 with indications of its functionality, such as indications of the types of sensors available in the test UE, indications of various parameters of these sensors (e.g., imaging resolution and picture data format for imaging cameras, satellite positioning type and format for satellite-based position sensors), accessories available in the device, and applicable parameters (e.g., number of audio channels). For example, a test UE may provide indication of this capability as part of a UECapabilityInformation radio resource control (RRC) message, which is typically provided by a UE in response to a UECapabilityEnquiry RRC message transmitted by a BS, in accordance with at least the 4G LTE and 5G NR specifications. Alternatively, the test UE may provide indication of the sensor capability as a separate side-channel or control channel communication. Furthermore, in some embodiments, the capabilities of the test device are stored in a local or remote database available to the management component 154, which can query this database based on some form of identifier of the test device, such as an International Mobile Subscriber Identification (IMSI) value associated with the test device.

[0088] In at least some embodiments, the training module 408 attempts to train on all possible RACH configurations. However, in embodiments where the UE108 and BS110 are considered to have a relatively large number of diverse functions and other operating parameters, this attempt is not feasible. Therefore, in block 704, the training module 408 can select a specific RACH configuration from a given set of candidate RACH configurations to co-train the DNN of the test device. Thus, in at least some embodiments, each candidate RACH configuration represents a specific combination of RACH-related parameters, parameter ranges, or combinations thereof for the test device. Such parameters or parameter ranges may include sensor function parameters, processing function parameters, battery power parameters, RF signal transmission parameters such as the number and type of antennas and the number and type of subchannels. Using the candidate RACH configuration selected for training, in block 704, the training module 408 identifies the initial DNN architecture configuration for each test UE and BS, and instructs the test device to implement each of these initial DNN architecture configurations by providing the test device with an identifier associated with the initial DNN architecture configuration if the test device stores a copy of the candidate initial DNN architecture configuration, or by sending data representing the initial DNN architecture configuration itself to the test device.

[0089] When a RACH configuration is selected and the test device is initialized with a DNN architecture configuration based on the selected RACH configuration, in block 706, the training module 408 identifies one or more sets of training data to be used when jointly training the DNNs of the DNN chain based on the selected RACH configuration and the initial DNN architecture configuration. That is, one or more sets of training data are suitable for training the DNNs because they contain or represent data that can be provided as input to the corresponding DNNs in offline or online operation. To elaborate, this training data may include streams such as test PRACH signals, test PUSCH signals, test RAR signals, test CR signals, test parameters or configurations of the test signals, test sensor data that matches the sensors included in the configuration under test, test received representations of the PRACH signals, test received representations of the PUSCH signals, test received representations of the RAR signals, and test received representations of the CR signals.

[0090] Once one or more training sets are acquired, in block 708, the training module 408 begins co-training of the DNNs for the test RACH path. This co-training typically involves initializing the bias weights and coefficients of various DNNs with initial values, which are generally selected pseudo-randomly, then inputting the training data set into the TX processing module of the test UE device (e.g., UE PRACH TX processing module 618), wirelessly transmitting the resulting output as a transmission to the RX processing module of the test BS device (e.g., BS PRACH RX processing module 638), analyzing the resulting output, and then updating the DNN architecture configuration based on the analysis. This co-training further includes inputting the training data set into the TX processing module of the test BS device (e.g., BS RAR TX processing module 646), wirelessly transmitting the resulting output as a transmission to the RX processing module of the test UE device (e.g., UE RAR RX processing module 630), analyzing the resulting output, and then updating the DNN architecture configuration based on the analysis. In another example, collaborative training includes end-to-end collaborative training that involves inputting a set of training data into the TX processing module of a test UE device (e.g., UE PRACH TX processing module 618), wirelessly transmitting the resulting output as a transmission to the RX processing module of a test BS device (e.g., BS PRACH RX processing module 638), providing the output of the RX processing module of a BS test device as input to the TX processing module of a test BS device (e.g., BS RAR TX processing module 646), wirelessly transmitting the resulting output as a transmission to the RX processing module of a test BS device (e.g., UE RAR RX processing module 630), analyzing the resulting output, and then updating the DNN architecture configuration based on the analysis. In at least some embodiments, at least one of one or more DNN architecture configurations of the test devices is trained individually.

[0091] As is frequently used in DNN training, feedback obtained as a result of one or more actual result outputs from the UE PRACH TX processing module 618, BS PRACH RX processing module 638, BS RAR TX processing module 646, or UE RAR RX processing module 630 is used to modify, or otherwise improve, the parameters of one or more DNNs in the RACH path, such as through backpropagation. Thus, in block 710, the management component 154 and / or the DNN chain obtain feedback on the transmitted training set. The implementation of this feedback can take any of several forms or combinations thereof. In at least some embodiments, the feedback includes the training module 408 or another training module determining the error between the actual result output and the expected result output and backpropagating this error across the DNNs of the DNN chain. For example, since processing by the DNN chain effectively provides a form of random access, objective feedback on the training dataset could include some form of measurement of accuracy, such as detection of RACH signals, transmission errors, and reception errors.

[0092] In block 712, the management component 154 or the DNN chain uses the feedback obtained as a result of sending the test dataset through the DNN chain to update various aspects of one or more DNNs in the RACH path, such as by backpropagation of errors that modify the weights, connections, or layers of the corresponding DNNs, or by modifications managed by the management component 154 in response to such feedback, through the presentation or other consumption of the obtained output on the test transmission device. The management component 154 (or another network component) runs the training process of blocks 706-712 on the next set of training data selected in the next iteration of block 706, and this is repeated until a certain number of training iterations have been performed or until a certain minimum error rate is achieved.

[0093] As a result of joint (or individual) training of neural networks along the RACH path between the test UE device and the test BS device, each neural network has a specific neural network architecture configuration, or a DNN architecture configuration if the neural network being implemented is a DNN, which characterizes the architecture and parameters of the corresponding DNN, such as the number of hidden layers, the number of nodes in each layer, the connections between each layer, weights, coefficients, and other bias values ​​implemented at each node. Thus, once the joint or individual training of the DNN along the RACH path for the selected RACH configuration is complete, in block 714, the management component 154 (or another network component) distributes some or all of the trained DNN configurations to the UE 108 and BS 110 in system 100. Each node stores the DNN configuration obtained as a result of the corresponding DNN as the DNN architecture configuration. In at least one embodiment, the management component 154 (or another network component) can generate a DNN architecture configuration by extracting the corresponding DNN architecture and parameters, such as the number of hidden layers, number of nodes, connections, coefficients, weights, and other bias values, at the end of co-training. In other embodiments, the management component 154 stores copies of the paired DNN architecture configurations as a set of 412 candidate neural network architecture configurations 414. The management component 154 (or another network component) then distributes these DNN architecture configurations to the UE108 and BS110 as needed.

[0094] If one or more other candidate RACH configurations remain to be trained, method 700 then returns to block 704 to select the next candidate RACH configuration to be co-trained, and another iteration of the subprocesses of blocks 704-714 is repeated for the next RACH configuration selected by training module 408. Otherwise, if the DNN for the RACH path has been co-trained for all intended RACH configurations, method 700 is complete and system 100 can proceed to the neural network-supported RACH procedure, as described below with reference to Figures 8-15.

[0095] As described above, the management component 154 (or another network component) can run using an offline test node (i.e., while no active communication of control information or user plane data is occurring) or while the actual node of the intended transmission path is online (i.e., while active communication of control information or user plane data is occurring). Furthermore, in some embodiments, the management component 154 does not jointly train all DNNs; in some examples, the management component 154 can train or retrain a subset of DNNs while keeping the other DNNs static. To illustrate, the management component 154 detects that a particular device's DNN is operating inefficiently or incorrectly, for example, due to a change in the functionality of the device implementing the DNN, or in response to a previously unreported loss of processing functionality, and therefore the management component 154 schedules individual retraining of the device's DNN(s) while keeping the other DNNs of other devices in their current configurations.

[0096] Furthermore, while there may be a wide variety of devices supporting numerous RACH configurations, it will be understood that many different nodes can support the same or similar RACH configurations. Therefore, it is not necessary to repeat co-training for all devices incorporated into the RACH path. Following co-training for a representative device, that device can send its trained representation of the DNN architecture configuration for the RACH configuration to the management component 154, which then stores the DNN architecture configuration and can subsequently send it to other devices supporting the same or similar RACH configuration for the DNN implementation of the RACH path.

[0097] Furthermore, DNN architecture configurations often change over time as the corresponding device operates using the DNN. Therefore, as operation progresses, a neural network management module of a given device (e.g., neural network management modules 216, 314) can be configured to transmit a representation of one or more updated architecture configurations of the DNNs used at that node, which is done by providing updated gradients and related information to a management component 154 in response to a trigger. This trigger could be the expiration of a periodic timer, a query from the management component 154, or a determination that the magnitude of the change exceeds a specified threshold. The management component 154 then has an updated DNN architecture configuration that incorporates these received DNN updates into the corresponding DNN architecture configuration and can therefore be distributed to nodes in the transmission path as needed.

[0098] Figures 8 to 14 illustrate exemplary methods 800 for performing different types of RACH procedures using DNN-based RACH paths trained between wireless devices, according to several embodiments. For ease of explanation, method 800 in Figure 8 is described below in the exemplary context of RACH paths 114 in Figures 1 to 6, and for brevity, previously described details are not repeated. Furthermore, the process of method 800 is described with reference to exemplary transaction (ladder) figures 1300 to 1500 in Figures 13 to 15. Specifically, transaction (ladder) figure 1300 in Figure 13 corresponds to the operation described with respect to Figures 8 to 9. Transaction (ladder) figure 1400 in Figure 14 corresponds to the operation described with respect to Figures 9 to 10. Transaction (ladder) figure 1500 in Figure 15 corresponds to the operation described with respect to Figures 11 to 12. Furthermore, while Figures 8 to 12 show Method 800 as a single continuous flow, separate flows are equally applicable for different types of RACH configurations (e.g., CFRA, 4-step CBRA, and 2-step CFRA / CBRA).

[0099] In some embodiments, method 800 begins in block 802, where the UE108 and BS110 establish a wireless connection via a 5G NR standalone registration / attach process in a cellular context, or via an IEEE 802.11 related process in a wireless local area network (WLAN) context. In other embodiments, such as when the UE108 moves into a BS cell during idle mode, method 800 begins in block 804. In the case of other RACH-related events (e.g., handover, addition or modification of a secondary cell), method may begin in block 804, or in a later block such as block 806 or block 808. In block 804, the management component 154 retrieves functional information from one or more of the UE108 and BS110, such as functional information 1302 (Figure 13) provided by the functional management module 218 (Figure 2) of the UE108, and functional information 1304 (Figure 13) provided by the functional management module 318 (Figure 3) of the BS110. In at least some embodiments, the management component 154 has already notified the BS110 of its capabilities when it is part of the same infrastructure network, in which case obtaining the BS110's capability information 1304 may include accessing a local or remote database or other data store for this information. In at least some embodiments, the BS110 can send a capability request to the UE108. The UE108 responds to this request with capability information 1302, which the BS110 then forwards to the management component 154. For example, the BS110 can send a UECapabilityEnquiryRRC message, and the UE108 responds with a UECapabilityInformationRRC message containing RACH-related capability information.

[0100] In block 806, the neural network selection module 410 of the management component 154 selects individual or paired RACH DNN architecture configurations to be implemented individually or jointly in UE108 and BS110 to support RACH path 114 (DNN selection 1306, Figure 13), using, for example, functional information and other information representing the RACH configuration between UE108 and BS110. In at least some embodiments, the neural network selection module 410 uses an algorithmic selection process to compare functional information obtained from UE108 and BS110 and the RACH configuration parameters of RACH path 114 with the attributes of a pair of candidate neural network architecture configurations 414 in set 412 to identify a suitable pair of DNN architecture configurations. In other embodiments, the neural network selection module 410 organizes candidate DNN architecture configurations into one or more LUTs, each entry storing a corresponding pair of DNN architecture configurations, indexed by a corresponding combination of input parameters or parameter ranges. Thus, the neural network selection module 410 selects a suitable pair of DNN architecture configurations to be used by one or both of the UE108 and BS110 by providing the features and RACH configuration parameters identified in block 804 as inputs to one or more LUTs. In at least some embodiments, the management component 154 obtains updated feature information from the UE108 and BS110. The management component 154 can then select different DNN architectures for one or more of the UE108 and BS110 based on the updated feature information. Furthermore, the DNN architecture selected by the management component 154 for the UE108 may correspond to the DNN architecture selected for the BS110. For example, the UE PRACH TX DNN architecture can be compatible with the BS PRACH RX architecture, thereby configuring the BS PRACH RX architecture to process the RACH signal 124 generated by the UE PRACH TX DNN.

[0101] Furthermore, in block 806, the management component 154 instructs one or both of the UE108 and BS110 to implement their respective DNN architecture configurations from the selected individually or jointly trained DNN architecture configurations. In embodiments where each of the UE108 and BS110 stores candidate DNN architecture configurations for potential future use, the management component 154 can send a message containing identifiers for the DNN architecture configurations to be implemented by the UE108 and BS110. Otherwise, the management component 154 can send information representing the DNN architecture configuration, for example, as a layer 1 signal, a layer 2 control element, a layer 3 RRC message, or a combination thereof. For example, referring to Figure 13, the management component 154 sends the UE108 a DNN configuration message 1308 containing data representing the DNN architecture configuration selected for the UE108. In response to receiving this message, the neural network management module 216 of UE108 extracts data from the DNN configuration message 1308 and configures one or more of the UE PRACH TX processing module 618 or UE RAR RX processing module 630 to implement one or more DNNs having the DNN architecture configuration represented by the extracted data. Similarly, the management component 154 sends a DNN configuration message 1310 to BS110 containing data representing the DNN architecture configuration selected for BS110. In response to receiving this message, the neural network management module 314 of BS110 extracts data from the DNN configuration message 1310 and configures one or more of the BS PRACH RX processing module 638 or BS RAR TX processing module 646 to implement one or more DNNs having the DNN architecture configuration represented by the extracted data.

[0102] Once the DNN for RACH route 114 is initially configured, the RACH process can be initiated. In block 808, based on the selected RACH configuration or the RACH configuration information 120 provided by BS110, UE108 determines whether a two-step RACH should be performed by UE108. If UE108 performs a two-step RACH, the process proceeds to block 1166 in Figure 11. Otherwise, UE108 performs a CFRA or a four-step CBRA procedure, and the process proceeds to block 810. In block 810, components of UE108, such as the UE RACH management module 220, determine whether the RACH configuration information 120 provided by BS110 identifies a dedicated RACH preamble (CFRA). If so, the flow proceeds to block 814. Otherwise, UE108 selects a random RACH preamble (four-step CBRA) from the set of available competition-based RACH preambles identified in the RACH configuration information 120. In another example, the UE PRACH TX DNN 118 can detect a dedicated RACH preamble or select a RACH preamble based on RACH configuration information 120. In block 814, the UE PRACH TX DNN 118 receives and processes inputs such as RACH configuration information 120, dedicated / selected preambles, and sensor information to generate a RACH signal 124. For example, in addition to the PRACH signal 1312, the UE PRACH TX DNN 118 generates an output representing either the PRACH signal 1312 (Figure 13) or the PUSCH signal 1406 (Figure 14). In block 816, the RF front-end 126 of the UE 108 modulates an analog signal representing the RACH signal 124 using an appropriate carrier frequency and transmit power for the RF transmission 148 of the RACH signal 124 to BS 110.

[0103] The RF front-end 140 of BS110 receives and provides the RACH signal 124 as input to the BS PRACH RX DNN 138. In block 818, the BS PRACH RX DNN 138 processes the RACH signal 124 to generate RACH signal information 1314 (Figure 13). In at least some embodiments, the BS PRACH RX DNN 138 also generates UL TX timing estimates 1316 (Figure 13). In block 820, the BS PRACH RX DNN 138 (or another component of BS110) determines, for example, the type of RACH signal (e.g., Msg1 or MsgA) to receive from the UE 108, based on the RACH signal information 1314. If the BS PRACH RX DNN 138 determines that MsgA (PUSCH signal 1406 combined with PRACH signal 1312) has been received, the flow continues to block 1174 in Figure 11. Otherwise, in block 822, the RACH management module 142 of BS110 receives RACH signal information 1314 and UL TX timing estimate 1316 as inputs and generates RAR information 1318 (Figure 13). In at least some embodiments, the BS PRACH RX DNN generates the RAR information 1318 instead of the RACH management module 142.

[0104] In block 824, the BS RAR TX DNN 146 receives RAR information 1318 as input and generates an output representing the RAR signal 1320 (Figure 13). In block 826, the RF front-end 140 of BS 110 modulates an analog signal representing the RAR signal 1320 using an appropriate carrier frequency and transmit power for RF transmission of the RAR signal 1320 to UE 108. The RF front-end 126 of UE 108 receives the RAR signal 1320 and provides it as input to the UE RAR RX DNN 130. In block 928 (Figure 9), the UE RAR RX DNN 130 processes the RAR signal 1320. In block 930, the UE RAR RX DNN 130 determines whether to perform conflict resolution based on the processed RAR signal 1320. In block 932, the UE RAR RX DNN 130 determines that no conflict resolution is necessary if UE 108 is performing CFRA and outputs either a RACH success indicator 1322 or a RACH failure indicator 1324. The process then terminates in block 934. Alternatively, if the RACH process fails, the flow can return to block 814, where UE 108 can retransmit the RACH signal 124 using a different UE PRACH TX DNN, different TX power, etc.

[0105] Returning to block 930, the UE RAR RX DNN130 (or another component of UE108) determines that if UE108 is performing a 4-step CBRA, a conflict resolution is required. Therefore, in block 936, the UE RAR RX DNN130 (or another component of UE108) generates UE108's CRID 1402 (Figure 14), such as a random number. In block 938, the UE PRACH TX DNN118 (or the PUSCH TX portion of PRACH TX DNN118) receives the UL TX input 1404 (Figure 14) for PUSCH transmission, containing payload / data 614, PUSCH assignment, UE CR ID, etc. In block 940, the PRACH TX DNN118 (or another DNN) processes the UL TX input 1404 to generate an output representing the PUSCH signal 1406 (Figure 14). In block 942, the RF front-end 126 of UE108 modulates an analog signal representing the PUSCH signal 1406 using an appropriate carrier frequency and transmit power for RF transmission of the PUSCH signal 1406 to BS110.

[0106] The RF front-end 140 of BS110 receives and provides the PUSCH signal 1406 as input to the BS PRACH RX DNN138 (or the PUSCH RX portion of the PRACH RX DNN138). In block 944, the BS PRACH RX DNN138 (or another DNN) processes the PUSCH signal 1406 to generate PUSCH signal information 1408 (Figure 14). In block 946, the RACH management module 142 of BS110 receives the PUSCH signal information 1408 as input and generates CR information 1410 (Figure 14). In block 948, the BS RAR TX DNN146 (or the PUSCH TX portion of the BS RAR TX DNN146) receives the PUSCH signal information 1408 as input and generates an output representing the CR signal 1412. In block 950, the RF front-end 140 of BS110 modulates an analog signal representing the CR signal 1412 using an appropriate carrier frequency and transmit power for RF transmission of the CR signal 1412 to UE108.

[0107] The RF front-end 126 of UE108 receives and provides the RAR signal 1320 as input to the UE RAR RX DNN130 (or the CR portion of the UE RAR RX DNN130). In block 1052 (Figure 10), the UE RAR RX DNN130 (or another DNN) processes the CR signal 1412 and performs a conflict resolution operation 1414 (Figure 14) in block 1154. For example, the UE RAR RX DNN130 (or another DNN) determines whether the CR signal 1412 is associated with the CRID of UE108. If so, in block 1156, the UE RAR RX DNN130 (or another DNN) determines that the RACH procedure was successful and outputs a RACH success indicator 1322. The process then terminates in block 1158. Otherwise, in block 1160, the UE RAR RX DNN 130 (or another DNN) determines that the RACH procedure has failed and outputs a RACH failure indicator 1324. In block 1162, in response to the RACH procedure failure, one of the UE RACH DNNs or the UE RACH management module 220 determines whether the number of RACH retransmission attempts exceeds the retransmission threshold. If the number of retransmission attempts does not exceed the retransmission threshold, the flow returns to block 814, where the UE 108 may retransmit the RACH signal 124 using a different preamble, a UE PRACH TX DNN, different TX power, or a combination thereof. Otherwise, the process terminates in block 1164.

[0108] As described above with respect to block 808 in Figure 8, if the two-step RACH procedure is performed by UE108, the process proceeds to block 1166 in Figure 11. In block 1166, the UE RACH management module 220 (or UE PRACH TX DNN118) determines whether the RACH configuration information 120 provided by BS110 identifies a dedicated RACH preamble (CFRA). If so, the flow proceeds to block 1170. Otherwise, in block 1168, the UE RACH management module 220 (or UE PRACH TX DNN118) selects a random preamble (CBRA) from the set of available conflict-based preambles identified in the RACH configuration information 120. In block 1170, the UE PRACH TX DNN 118 receives and processes inputs such as RACH configuration information 120, PUSCH data 614, dedicated / selected preambles, sensor information, and combinations thereof to generate the RACH signal 124 as described above with respect to Figures 1 and 6. For example, the UE PRACH TX DNN 118 generates a RACH signal 124 output representing a combination of the PRACH signal 1312 and the PUSCH signal 1406. In block 1172, the RF front-end 126 of the UE 108 modulates the analog signal(s) representing the PRACH signal 1312 and the PUSCH signal 1406 using appropriate carrier frequencies and transmit power for RF transmission of the PRACH signal 1312 and the PUSCH signal 1406 to the BS 110.

[0109] The RF front-end 140 of BS110 receives and provides the PRACH signal 1312 and the PUSCH signal 1406 as inputs to the BS PRACH RX DNN 138. In block 1174, the BS PRACH RX DNN 138 processes the PRACH signal 1312 and the PUSCH signal 1406 to generate RACH signal information 1314 and PUSCH signal information 1408. In at least some embodiments, the BS PRACH RX DNN 138 also generates UL TX timing estimates 1316. The BS RACH management module 142 receives the RACH signal information 1314 and the UL TX timing estimates 1316 as inputs to generate RAR information 1318. The BS RACH management module 142 also receives the PUSCH signal information 1408 as input to generate CR information 1410. In at least some embodiments, the BS PRACH RX DNN 138 generates RAR information 1318 and CR information 1410 on behalf of the RACH management module 142. In block 1176, the BS RAR TX DNN 146 receives the RAR information 1318 and CR information 1410 as inputs and generates an output representing the RAR signal 1502 (Figure 15) containing the RAR information 1318 and CR information 1410. In block 1178, the RF front-end 140 of the BS 110 modulates the analog signal representing the RAR signal 1502 using an appropriate carrier frequency and transmit power for RF transmission of the RAR signal 1502 to the UE 108.

[0110] The RF front-end 126 of UE108 receives the RAR signal 1502 and provides it as input to the UE RAR RX DNN 130. In block 1180, the UE RAR RX DNN 130 processes the RAR signal 1502 as input, and this process continues to block 1282 in Figure 12. In block 1282, based on its processing of the RAR signal 1502, the UE RAR RX DNN determines whether UE108 and BS110 should perform conflict resolution. If the UE RAR RX DNN determines that conflict resolution is not necessary, in block 1286, the UE RAR RX DNN proceeds to the output of the RACH success indicator 1322. The process then terminates in block 1288. Otherwise, in block 1284, the UE RAR RX DNN performs conflict resolution and determines whether the conflict resolution was successful. If the conflict resolution is successful, the RAR RX DNN proceeds to the output of the RACH success indicator 1322 in block 1286. The process then terminates in block 1288. Otherwise, in block 1290, the RAR RX DNN proceeds to the output of the RACH failure indicator 1324. In block 1292, in response to the RACH procedure failure, one of the UE RACH DNN or UE RACH management module 220 determines whether the number of RACH retransmission attempts exceeds the retransmission threshold. If the number of retransmission attempts does not exceed the retransmission threshold, the flow returns to block 814 in Figure 8, where the UE 108 retransmits the RACH signal 124 using a different preamble, UE PRACH TX DNN, different TX power, or a combination thereof. Otherwise, the process terminates in block 1294.

[0111] In at least some embodiments, certain aspects of the techniques described above can be implemented by one or more processors of a processing system that executes the software. The software includes one or more sets of executable instructions, which are stored or otherwise tangibly embodied on a non-temporary computer-readable storage medium. The software may include instructions and certain data that, when executed by one or more processors, cause one or more processors to execute one or more aspects of the techniques described above. The non-temporary computer-readable storage medium may include, for example, magnetic or optical disk storage devices, and solid-state storage devices such as flash memory, cache, random access memory (RAM), or a single or multiple non-volatile memory devices, and similar. The executable instructions stored on the non-temporary computer-readable storage medium may be source code, assembly language code, object code, or other instruction format, which are interpreted or otherwise executable by one or more processors.

[0112] Computer-readable storage media may include any storage medium or combination of storage media that are accessible by a computer system while in use to provide instructions and / or data to the computer system. Such storage media may include, but are not limited to, optical media (e.g., compact discs (CDs), digital versatile discs (DVDs), Blu-ray discs), magnetic media (e.g., floppy disks, magnetic tapes, or magnetic hard drives), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or microelectromechanical system (MEMS) based storage media. Computer-readable storage media may be embedded in a computing system (e.g., system RAM or ROM), fixedly mounted to a computing system (e.g., magnetic hard drives), removable mounted to a computing system (e.g., optical disks or Universal Serial Bus (USB) based flash memory), or connected to a computer system via a wired or wireless network (e.g., network-accessible storage (NAS)).

[0113] In addition to the foregoing, it should be noted that not all activities or elements described above are required in the general description, and that certain activities or parts of devices may not be required, or that one or more additional activities may be performed, or that one or more additional elements may be included. Furthermore, the order in which the activities are listed does not necessarily indicate the order in which they are performed. Also, concepts are described with reference to specific embodiments. However, those skilled in the art will understand that various modifications and variations are possible without departing from the scope of this disclosure, as described in the claims below. Accordingly, this specification and the drawings should be considered illustrative rather than restrictive, and all such variations are intended to be included within the scope of this disclosure.

[0114] Benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments. However, benefits, advantages, and solutions to problems, as well as any features(if any) that may produce or make more prominent any benefit, advantage, or solution, should not be construed as material, necessary, or essential features of any or all claims. Furthermore, the subject matter of the disclosed invention can be modified and implemented in different but equivalent ways, as will be obvious to those skilled in the art who have a benefit of teaching this specification; therefore, the specific embodiments disclosed above are merely illustrative. No limitation is intended to any configuration or design details shown herein other than those described in the claims below. Accordingly, it will be apparent that the specific embodiments disclosed above can be modified or altered, and all such variations will be considered within the scope of the subject matter of the disclosed invention. Consequently, the protection sought herein is as described in the claims below.

Claims

1. A computer implementation method for user equipment (UE) (108) of a cellular communication system, The UE includes receiving random access (RA) configuration information (120), and the RA configuration information is One or more transmitting neural network configurations (1308) for the UE to select, Time resources for transmitting one or more radio frequency (RF) signals, Frequency resources for transmitting the one or more RF signals, and The computer implementation method further indicates at least one of the dedicated preamble or available competition-based preambles assigned to the UE by the base station (BS) (110), Based on the RA configuration information, a transmitting neural network (118) implemented by the UE is configured, Receiving at least one of the velocity estimate of the UE or the Doppler estimate of the UE as input to the transmitting neural network, The transmitting neural network includes generating a first output based on the RA configuration information and at least one of the velocity estimate of the UE or the Doppler estimate of the UE, wherein the first output represents a first RA signal (124) for the RA procedure between the UE and the BS of the cellular communication system, and the computer implementation method further includes, Controlling the RF antenna interface (204) of the UE and transmitting a first RF signal (148) representing the first output for reception by the BS, Computer implementation methods, including those mentioned above.

2. Generating the first output is based on receiving an input in the transmitting neural network, and the input is, Sensor data (122) associated with one or more sensors (210) of the UE, or Includes at least one payload data (614) for physical uplink shared channel (PUSCH) transmission, The method according to claim 1, wherein the sensor data includes at least one of the velocity estimate of the UE or the Doppler estimate of the UE.

3. The method according to claim 1, further comprising receiving an input representing one or more RF signals (152) including RA response information (622) transmitted by the BS in response to transmitting the first RF signal.

4. The method according to claim 3, further comprising the RA procedure generating a second output (132, 134) representing an indication of success or failure based on the input.

5. The method according to claim 4, wherein receiving the input representing one or more RF signals includes receiving the input representing one or more RF signals in the receiving neural network (130) of the UE.

6. The method according to claim 5, further comprising receiving an indication from the BS to implement a specific neural network architecture in the transmitting neural network during a handover event.

7. To generate the second output described above, The method according to claim 5, comprising generating the second output in the receiving neural network based on a neural network architecture configuration selected for the receiving neural network from one or more of the aforementioned neural network architecture configurations.

8. The method of claim 4, further comprising selecting a different transmitting neural network for the RA procedure in response to the second output representing the indication that the RA procedure has failed.

9. The method according to claim 1, further comprising selecting a neural network architecture configuration from the one or more neural network architecture configurations of the transmitting neural network based on at least one of the functions of the UE or the BS.

10. The method according to claim 9, further comprising changing the neural network architecture configuration of at least the transmitting neural network in response to a change in at least one of the functions (420, 422) of the UE or the BS.

11. The method according to claim 5, further comprising using the receiving neural network (138) and transmitting neural network (146) of the BS to participate in joint training of the transmitting neural network and the receiving neural network of the UE.

12. The RA procedure generates the second output representing the indication which has either success or failure, The receiving neural network determines whether the input received by the receiving neural network includes a conflict resolution identifier (1402) transmitted to the BS within the first output or another output of the UE, In response to the receiving neural network not including the conflict resolution identifier, the receiving neural network generates a second output representing the indication that the RA procedure has failed, In response to the receiving neural network receiving the input containing the conflict resolution identifier, the receiving neural network generates a second output representing the indication that the RA procedure was successful, The method according to claim 5, including the method described in claim 5.

13. Generating the second output representing the indication that the RA procedure is either successful or unsuccessful is: The receiving neural network of the UE receives an input representing one or more RF signals (626) including RA conflict resolution information (646) associated with the BS, Based on the RA conflict resolution information, a second output is generated that indicates the RA procedure is either successful or unsuccessful. The method according to claim 5, including the method described in claim 5.

14. A computer implementation method for a base station (BS) (110) of a cellular communication system (100), The computer implementation method further includes receiving at least one parameter, the at least one parameter including one or more functional parameters of the user equipment (UE) (108) of the cellular communication system for configuring a receiving neural network, and the computer implementation method further includes: The transmitting neural network (146) of the BS is configured based on at least one of the aforementioned parameters, In response to receiving random access (RA) response information (1318) as input to the transmitting neural network, the transmitting neural network (146) of the BS generates a first output representing an RA response signal (150) including an RA response to an RA procedure between the BS and the UE (108), Controlling the radio frequency (RF) antenna interface (304) of the BS and transmitting a first RF signal (152) representing the RA response signal for reception by the UE, Computer implementation methods, including those mentioned above.

15. The method according to claim 14, further comprising receiving a second RF signal (148) from the UE at the UE's RF antenna interface before generating the first output, wherein the second RF signal represents an RA signal (124) for the RA procedure, and the first output is generated based on the second RF signal received from the UE.

16. The BS receiving neural network (138) is provided with a representation of the second RF signal as a first input, The receiving neural network generates a second output (617) based on the first input to the receiving neural network, Based on the second output, RA response information (622) is generated, The method according to claim 15, further comprising providing the RA response information as a second input to the transmitting neural network of the BS, wherein the transmitting neural network generates the RA response signal based on the second input.

17. Based on the second output, conflict resolution information (624) is generated, The method according to claim 16, further comprising providing the BS's transmitting neural network with the conflict resolution information as a third input, wherein the transmitting neural network generates the RA response signal based on the third input.

18. A computer implementation method, In the cellular communication system (100), receiving functional information (420, 422) from at least one of the first device (108) or the second device (110), The computer implementation method further includes selecting a first neural network architecture configuration (414) from a set of candidate neural network architecture configurations (412) based on the functional information, wherein the first neural network architecture configuration is trained to implement a random access procedure between the first device and the second device, and the computer implementation method further includes Transmitting to the first device a first indication of the first neural network architecture configuration to be implemented in one or more of the transmitting neural network (118) and receiving neural network (130) of the first device, Computer implementation methods, including those mentioned above.

19. Radio frequency (RF) antenna interfaces (204, 304) and At least one processor (206, 306) connected to the RF antenna interface, A device (108, 110) comprising memory (208, 308) for storing executable instructions, wherein the executable instructions are configured to operate the at least one processor to perform the method according to any one of claims 1 to 18.