DATA TRANSMISSION IN A POWER-EFFICIENT STATE

Abstract

This application relates to methods, systems, and devices connected with digital wireless communication, and more specifically, to techniques related to data transmission in a power-efficient state. As an example, a method for wireless communication is disclosed. The method includes transmitting, through a terminal in a first state, a first message to a network node to initiate a data communication resumption procedure with the network node. The method also includes monitoring, after the transmission of the first message, a control channel with a temporary network identifier for a response to the first message.

Description

DATA TRANSMISSION IN A POWER-EFFICIENT STATE FIELD OF INVENTION This patent document is generally aimed at wireless communications. BACKGROUND OF THE INVENTION Mobile communication technologies are moving the world toward an increasingly connected and networked society. The rapid growth of mobile communications and advances in technology have led to greater demand for capacity and connectivity. Other aspects, such as power consumption, device cost, spectral efficiency, and latency, are also important for meeting the needs of various communication scenarios. Several techniques are being explored, including new ways to provide superior quality of service. BRIEF DESCRIPTION OF THE INVENTION This document discloses methods, systems, and devices related to digital wireless communication, and more specifically, techniques related to data transmission in a power-efficient state. In one exemplary aspect, a method for wireless communication is disclosed. The method includes transmitting, through a terminal in a first state, an initial message to a network node to initiate a data communication resumption procedure with that network node. The method also includes monitoring, after the transmission of the initial message, a control channel with a temporary network identifier for a response to the initial message. In another exemplary aspect, a method for wireless communication is disclosed. The method includes receiving, via a network node, an initial message to initiate a data communication resumption procedure from a terminal in a first state. The method also includes transmitting, via the network node, a response to the initial message to the terminal monitoring a control channel with a temporary network identifier for the response to the initial message. In another exemplary aspect, a wireless communications apparatus comprising a processor is disclosed. The processor is configured to implement a method described herein. In another exemplary aspect, the various techniques described here can be incorporated as processor-executable code and stored in a computer-readable program medium. The details of one or more implementations are set out in the accompanying annexes, drawings, and the following description. Other features will be apparent to pzcc Ln / zznz / e / YiAi from the description and drawings, and from the clauses. BRIEF DESCRIPTION OF THE FIGURES FIGURE 1 is an exemplary signaling process for idle data transmission with RRC release after completing a data transmission. FIGURE 2 is an exemplary signaling process that illustrates idle data transmission with RRC involved and an RRC release prior to the start of data transmission. FIGURE 3 is an exemplary signaling process for idle data transmission without RRC involved. FIGURE 4 is an exemplary signaling process of an example for idle data transmission without RRC involved. FIGURE 5 is an exemplary signaling process for anchor relocation with data stored in buffer memory at the target node. FIGURE 6 is an exemplary signaling process for data forwarding used at anchor relocation site 15. FIGURE 7 is a block diagram of an exemplary data transmission method in a power-efficient state. FIGURE 8 shows an example of a wireless communication system where techniques can be applied according to one or more modalities of the present technology. FIGURE 9 is a block diagram representation of a portion of a hardware platform. DETAILED DESCRIPTION OF THE INVENTION The development of the next generation of wireless communication—5G New Radio (NR) communication—is part of an ongoing evolution of mobile broadband to meet the requirements of a growing network demand. NR will provide higher throughput to allow more users to connect simultaneously. Other aspects, such as power consumption, device cost, spectral efficiency, and latency, are also important to meet the needs of various communication scenarios. An RRCINACTIVE state has been introduced to provide a power-efficient state with low CP latency. For various services, such as those with variable data devices, a short control plane (CP) latency may be required because a device may need to report if something out of the ordinary is detected. Additionally, even considering power consumption, a UE can be configured in the RRCINACTIVE state. Furthermore, in many cases, besides transmitting video upon detecting something out of the ordinary, the device may periodically process small data streams. pzcc Ln / zznz / e / YiAi However, for the UE in the RRCINACTIVE state, because state-transition-free data transmission is not supported in the current standard, whenever the UE has data to transmit, it must first enter the RRC CONNECTED state and then initiate data transmission. This requirement to enter the RRC_CONNECTED state to send or receive data can result in considerable signaling consumption and may not meet the requirements identified by SA1 of the 3GPP system for supporting efficient signaling mechanisms (e.g., the requirement that the signaling overhead be less than the data payload). The problem can be particularly severe if the data packet is small and infrequent. The NR can support the RRC_INACTIVE state, and UEs with infrequent data transmission (periodic and / or non-periodic) are generally maintained by the network in the RRC_INACTIVE state. The RRC_INACTIVE state cannot support data transmission. Therefore, the UE may first resume the connection (i.e., move to the RRC_CONNECTED state) for any downlink (DL) and uplink (UL) data (MT). Resuming the connection and subsequently returning to the INACTIVE state can occur for every data transmission, regardless of how small and infrequent the data packets are. This can result in unnecessary power consumption and signaling overhead. An example of small and infrequent data traffic might include smartphone applications. Smartphone applications could include traffic from instant messaging services, heart rate / keep-alive traffic from instant messaging (IM) clients, email and other applications, push notifications from various applications, etc. Another example of small and infrequent data traffic might include non-smartphone applications. Non-smartphone applications could include traffic from wearables (e.g., periodic positioning information), sensors (e.g., Industrial Wireless Sensor Networks transmitting temperature and pressure readings periodically or in an event-triggered manner), smart meters and smart meter networks sending periodic meter readings, etc. A signal-reduction (NR) system can be efficient and flexible for short bursts of low-throughput data, support efficient signaling mechanisms (e.g., signaling is less than the payload), reduce overall signaling overhead, etc. Signaling overhead of UEs in the IDLE state for small data packets can be a general problem and can become critical with more UEs in NR, not only for network performance and efficiency but also for UE battery life. In general, any device that has intermittent small data packets (pzcc Ln / zznz / e / γALA) in the IDLE state can benefit from enabling a small IDLE data stream. The key enablers for small data transmission in NR, specifically the INACTIVE state, 2-step and 4-step RACH, and configured grant type-1, may already have been specified in many cases. Therefore, the present modes may allow data transmission in the INACTIVE state for NR. System overview These modes pertain to enabling data transmission in an idle state. The data transmission procedure described here is primarily applicable to the STANDBY and / or INACTIVE states. In the following description, the idle state is used as an illustrative example. It should be noted that these modes can also be applied to the STANDBY state. Furthermore, these modes can be extended to any power-efficient state where UL synchronization is not maintained on the UE and NW sides.Furthermore, in the following description, 15 the case of single connection (e.g., standalone NR, or standalone LTE) can be used as an illustrative example, the present modes can be further extended to EN-DC, MR-DC, LTE-DC, NR-DC, and / or multiple connectivity cases as well, in which case both MCG and SCG can be configured for the UE, and idle data transmission is applicable to MCG (master cell group) and / or SCG (secondary cell group) based on 20 the network-side configuration. The procedures, as described herein, may incorporate a 2-pass random access channel (RACH) procedure and / or a 4-pass RACH procedure. The payload carried in MsgA in a 2-pass RACH may be carried in Msg3 in a 4-pass RACH, and / or the payload carried in MsgB in a 2-pass RACH may be carried in Msg4 in a 4-pass RACH. In a 2-pass RACH, the contention resolution ID may be included in MsgB, but in a 4-pass RACH, the contention resolution ID may be included in Msg4. Exemplary modality 1 In the first example, multiple alternatives can be disclosed. A first alternative might include a solution with RRC involved, with RRC release after data transmission is complete. A second alternative might include a solution with RRC involved, with RRC release before the end of data transmission. A third alternative might include a solution with no RRC messages involved. As a first alternative, the UE can determine that data transmission 35 should begin in an inactive state. The UE can initiate an RRC resumption request procedure. In some modes, the data PDU and / or MAC SDU may be within the same PDU. MAC. In a CG-based solution, the DE can transmit the RRCResumeRequest message directly through the CG resource, optionally including a data PDU and / or MAC SDU packet. Once the message is transmitted, the UE can monitor the PDCCH using a cell-specific UE identifier known as the C-RNTI. The C-RNTI can be configured (i.e., by the network) or determined by the UE header in time, i.e., during the time the UE was previously in the RRCCONNECTED state or configured by the network when the UE entered the INACTIVE state (e.g., the C-RNTI to be used for a subsequent Resume procedure is included by the network in the RRCRelease message - which is the message that caused the UE to enter the INACTIVE state). In a two-step RACH-based solution, the first step might involve the UE initiating a RACH procedure and transmitting the RRRResumeRequest message via MsgA, optionally including the data PDU and / or MAC SDU. The second step, after MsgA is transmitted, might involve the UE receiving MsgB. Once MsgB is successfully received, the UE can monitor the PDCCH using the C-RNTI included in the MsgB, or with the C-RNTI preconfigured as previously explained. The UE can execute the UL / DL data transmission based on the grant received on the PDCCH with the corresponding C-RNTI. Once the release message If the RRC is received, the UE can stop monitoring the PDCCH directed to the C-RNTI and discard the C-RNTI. Figure 1 is an exemplary signaling process 100 for idle data transmission with RRC release after completing a data transmission. Figure 1 may correspond to the first alternative as noted earlier. As shown in FIGURE 1, in step 106a, a RACH-based solution can include an A message with the RRC Resume Request from UE 102 to gNB 104. The UE can optionally also include data PDUs and / or MAC SDUs in step 106a. The RACH-based solution can also include the contention resolution B message in step 108 from gNB 104 to UE 102. In step 106b, an initial message can include the A message with a RRCRequest from UE 102 to gNB 104. In step 110, gNB 104 can send a data transmission scheduled by a C-RNTI to UE 102. In step 112, UE 102 can send a data transmission scheduled by a C-RNTI to gNB 104. In step 114, gNB 104 can send an RRCRelease message to UE 102. In another mode, a timer can be used by the UE to determine when to discard the C-RNTI and / or enter the normal INACTIVE state. This timer can be configured by the network and signaled to the UE. In one alternative, the timer can be configured in an RRC reconfiguration message (for example, before the UE enters the INACTIVE state). In another alternative, the timer can be configured in an RRC release message (for example, when the UE enters the INACTIVE state). In a third alternative, the timer can be configured in system information where data transmission is taking place. The timer can be used to control the duration of idle data transmission. In one option, the timer can be started once the RRC resume message is generated or transmitted. In another option, the timer can be started once the RRC resume message is delivered by the MAC layer to the lower layer. In a third option, the timer can be started once the MsgB is received in a 2-step RACH-based procedure. In a fourth option, the timer can be started once the Msg4 or RAR MAC corresponding to the UE is received in a 4-step RACH-based procedure. In a fifth option, the timer can be started once the PDCCH addressed to the C-RNTI is received. In a sixth option, the timer can be a timeAlignmentTimer, or a new timer specifically configured for idle data transmission. The timer can be stopped as long as the RRC release is received. If the timer expires, the UE can discard the C-RNTI, stop monitoring the PDCCH with the C-RNTI, and / or suspend the DRB and / or PDCP. A second alternative involves a solution with RRCs engaged, including RRC release before the end of the data transmission. When the UE initiates the RRC resumption request procedure, in a first alternative for a RACH-based solution, the UE can initiate the RACH procedure and transmit the RRCResumeRequest message via MsgA, optionally including the data PDU or MAC SDU. Once MsgA is transmitted, the UE can receive MsgB, and in addition to the successful RAR (e.g., contention resolution ID, C-RNTI, etc.), the RRCConnectionRelease message can be sent to the UE (either within MsgB or in a DL scheduler following MsgB). In some modes, the 4-step RACH procedure will be used, and the UE can initiate the RACH procedure and transmit the preamble first. Once the preamble is transmitted, the UE can monitor the PDCCH directed to the RA-RNTI to receive the RAR MAC. Once the RAR MAC is received, the UE can transmit Msg3 (which may include the RRCResumeRequest message, and optionally a data PDU or MAC SDU) based on the UL grant received in the RAR MAC. Once Msg3 is transmitted, the UE can monitor the PDCCH directed to the C-RNTI (or temporary C-RNTI included in the RAR MAC) to receive Msg4. Once Msg4 is received, if the CCCH message is included in Msg3, then the UE can execute contention resolution based on the contention resolution ID included in Msg4.If the C-RNTI is included in Msg3, then the C-RNTI can be used in the reception of Msg4 (e.g., monitoring the PDCCH directed to the C-RNTI). Although several messages, such as an RRCResumeRequest message, are identified in these modes, these modes are not limited to using only those messages. For example, these modes can use an RRC configuration request message for a terminal in an Idle mode, while it may also be possible to use an RRCResumeRequest message in Idle mode. Alternatively, before the timer expires, the network can send a message to the UE that can either extend the timer or cause the UE to move to an RRC-CONNECTED state. The network message to the UE that causes the UE to extend the timer can be sent using a CE MAC or an RRC message such as RRCConnect. Once this message is received, the UE can either extend the timer and remain longer in a state where it continues monitoring the C-RNTI or move to an RRC-CONNECTED state. The network can determine whether to send this message to cause the UE to either extend the timer or move to the RRC-CONNECTED state based on the UE's observed traffic pattern or based on the arrival of DL (MT) traffic, etc. In a second alternative including a CG-based solution, the UE can transmit the RRRCResumeRequest message through the CG resource directly, optionally with the data packet also included. Once the message is transmitted, the UE can monitor the PDCCH with C-RNTI, which can be configured for the UE before or when the UE is entering the idle state. Once RRCConnectionRelease is successfully received, and based on the received message, the UE should process the idle data transmission, an idle data transmission timer can be started, and the UE can monitor the PDCCH with C-RNTI until the idle data transmission timer expires. The timer can be reset whenever a schedule is received from the PDCCH with C-RNTL. Alternatively, instead of the idle data transmission timer, the timeAlignmentTimer can be used to control idle data transmission, in which case the UE will monitor the PDCCH directed to the C-RNTI if the timeAlignmentTimer is running. The timeAlignmentTimer can be started or reset whenever a Time Advance Command is received. Alternatively, in addition to the idle data transmission timer, the timeAlignmentTimer can also be used to control idle data transmission, in which case the UE can monitor the PDCCH directed to the C-RNTI if both the idle data transmission timer and the timeAlignmentTimer are running. The UE can process the UL / DL transmission based on the grant received on the PDCCH with the corresponding C-RNTI. Once the idle data transmission timer and / or timeAlignmentTimer expires, the UE can stop monitoring the PDCCH with the C-RNTI, discard the C-RNTI, and / or suspend the DRB and / or PDCP. If the UE receives a stop data transmission indicator, which can be a MAC layer command (e.g., CE MAC), a physical layer command (e.g., DCI), or a PDCP layer command (e.g., PDCP control PDU), the UE can stop monitoring the PDCCH with the C-RNTI, discard the C-RNTI, and / or suspend the DRB and / or PDCP. Figure 2 is an exemplary signaling process that illustrates idle data transmission with RRC involved and an RRC release before the start of data transmission. As shown in Figure 2, in a RACH-based solution, UE 202 can send an RRC Resume Request MsgA 206 to gNB 204. gNB 204 can then send an RRC Connection Release MsgB 208 to UE 202. In a CG-based solution, UE 202 can send an RRC 210 Resumption Request through a CG resource to gNB 204. gNB 204 can send a scheduled RRC 212 Connection Release by a C-RNTI to UE 202. In step 214, the UE can start an idle data transmission timer and can start monitoring the C-RNTL. In step 216, the gNB 204 can send a data transmission scheduled by the C-RNTL to the UE 202. In step 218, the UE 202 can send a data transmission scheduled by the C-RNTL to the gNB 204. Although a C-RNTI can be used as an example of a temporary radio network identifier programmed through a network node (e.g., gNB), the temporary radio network identifier can include other identifiers, such as an l-RNTI or another RNTI assigned by the network or selected by a UE from a group of RNTIs configured by the network through dedicated system information signaling, for example. Additionally, although a gNB can be used as an exemplary network node, the present modalities are not limited to that case. For example, a network node can include an eNB. In step 220, the UE can discard the C-RNTI and enter a normal idle state once the timer expires. In step 222, gNB 204 can send a release indication CE MAC to UE 202. Alternatively, the UE can discard the C-RNTI and / or stop monitoring the PDCCH directed to the C-RNTI once timeAlignmentTimer 35 expires. In the normal idle state, the UE may not be required to monitor the PDCCH directed to the C-RNTI. The length of the timer (e.g., idle data transmission timer and / or timeAlignmentTimer) can be configured for the UE. Alternatively, the timer can be configured in an RRC reconfiguration message (e.g., before the UE enters the INACTIVE state). Alternatively, the timer can be configured in an RRC release message (e.g., when the UE enters the INACTIVE state). Finally, the timer can be configured in system information where the data transmission is taking place. A third alternative may involve idle data transmission without RRC involvement. For the UE to determine whether to initiate idle data transmission, the UE, in a first alternative in a RACH-based solution, may initiate the RACH procedure, including in the MsgA the MAC PDU with l-RNTI or C-RNTI and optionally the data PDU and / or CE MAC. Once the MsgA is transmitted, the UE may receive the MsgB. If the l-RNTI is included in the MsgA, the UE may monitor the PDCCH directed to the RA-RNTI (or MsgB RNTI) for receipt of the MsgB, and the l-RNTI in the MsgB may be used for contention resolution. If the C-RNTI is included in the MsgA, the UE may monitor the PDCCH directed to the C-RNTI for receipt of the MsgB. In a second alternative to the CG-based solution, the UE can transmit the UL data packet through the CG resource. Once the CG resource is transmitted, the UE can monitor the PDCCH directed to the C-RNTI, which can be configured for the UE before 20 or when the UE enters the INACTIVE state. Once the MsgB is successfully received (for a RACH-based solution), or the initial UL transmission with CG resource is transmitted (CG-based solution), an idle data transmission timer can be started, and the UE can monitor the PDCCH directed to the C-RNTI until the idle data transmission timer expires. The UE can then process the UL / DL transmission based on the grant received on the PDCCH with the corresponding CRNTI. Alternatively, instead of the idle data transmission timer, the timeAlignmentTimer can be used to control idle data transmission. In this case, the UE can monitor the PDCCH directed to the C-RNTI if the timeAlignmentTimer is running. The timeAlignmentTimer can be started or reset whenever a Timing Advance Command is received. Alternatively, in addition to the idle data transmission timer, the timeAlignmentTimer can also be used to control idle data transmission. In this case, the UE will monitor the PDCCH directed to the C-RNTI if both the idle data transmission timer and the timeAlignmentTimer are running. Once the idle data transmission timer or timeAlignmentTimer pzcc ιπ / ζζιίζ / β / υιλι has expired, the UE can stop monitoring the PDCCH with the C-RNTI, can discard the CRNTI, and / or can suspend the DRB and / or PDCP. If the UE receives the signal to stop data transmission, which may be a MAC layer command (e.g., CE MAC) or a physical layer command (e.g., DCI), or a PDCP level 5 command (e.g., PDCP control PDU), the UE may stop monitoring the PDCCH with the C-RNTI, may discard the C-RNTI, and / or may suspend the DRB and / or PDCP. Figure 3 shows an exemplary signaling process 300 for idle data transmission without RRC involved. In step 306, in a RACH-based solution, UE 302 can send MsgA with the l-RNTI and PDU MAC to gNB 304. In step 308, gNB 304 can send MsgB with the l-RNTI for contention resolution to UE 302. In a CG-based solution, UE 302 can send data via CG resource 310 to gNB 304. In step 312, the UE 302 can indicate the idle data transmission timer and initiate C-RNTI monitoring. In step 314, the gNB 304 can send data transmission 15 scheduled by the C-RNTI to the UE 302. In step 316, the UE 302 can send data transmission scheduled by the C-RNTI to the gNB 304. In step 318, the UE 302 can discard the C-RNTI and enter a normal idle state once the timer expires. In step 320, the gNB 304 can send a CE MAC indicating release to the UE 302. In some modes, the idle data transmission timer will reset to 20 whenever a PDCCH addressed to the C-RNTI is received and / or whenever the UL or DL ​​grant for new transmission is received. Exemplary modality 2 A second exemplary modality relates to data forwarding. Data forwarding can be used if the target gNB (where the inactive data transmission 25 is executed) is different from the source gNB (where the UE enters the INACTIVE state). To perform data forwarding, whenever the first NW node receives the data packet from the UE, the first NW node can forward the received data packet to the second NW node. The first NW node can forward the data packet in a control plane solution, which includes enclosing the data packet within an XnAP message. Alternatively, the first NW node can forward the data packet in a user plane solution, which includes forwarding the data packet to the source node via a GTP tunnel. This GTP tunnel can be either a common GTP tunnel shared by multiple tunnels or a UE-specific tunnel. With the data package, the l-RNTI and / or cell ID and / or PCI can be forwarded along with the data package. For the UP-based solution, the l-RNTI and / or cell ID and / or PCI pzcc ιπ / ζζιίζ / β / υιλι can be included in the header of the user plan package or in the control box of the user plan package. In this alternative, the release request or end marker can be sent from the target node to the source node to signal the end of the idle data transmission. The release request or end marker can be sent in either control plane signaling (e.g., XnAP signaling) or in the user plane packet (e.g., in the user plane packet header or user plane control box). Figure 4 is an exemplary signaling process for idle data transmission without RRC involved. As shown in Figure 4, in step 408, in a RACH-based solution, UE 402 can send MsgA with the l-RNTI and MAC PDU to target gNB 404. In step 410, target gNB 404 can send MsgB with the l-RNTI for contention resolution to UE 402. In step 412, for a CG-based solution, UE 402 can send a data PDU via the CH resource to target gNB 404. In step 414, the source gNB 406 can perform data forwarding to the target gNB 404. The target gNB 404 can perform data forwarding in step 416 to the source gNB 406. In step 418, the UE can start an idle data transmission timer and can start C-RNTI monitoring. In step 420, the target gNB 404 can send a data transmission programmed by the C-RNTI to the UE 402. In step 422, the UE 402 can send a data transmission programmed by the C-RNTI to the target gNB 404. In step 424, the UE 402 can discard the C-RNTI and enter a normal idle state once the timer expires. In step 426, the source gNB 406 can send a release request to the target gNB 404. In step 428, the target gNB 404 can send a release indication to the source gNB 406. In step 430, the target gNB 404 can send a CE MAC with the release indication to the UE 402. Exemplary modality 3 A third exemplary modality relates to anchor relocation. For idle data transmission with RRC involved, anchor relocation can be supported because the control plane is involved. In one alternative, the UE can fall back to a resumption procedure where both the UE-based and NW-based solutions can be considered. In another alternative, an area scope can be configured for the UE, and the UE can only initiate idle data transmission within the configured area (e.g., configuring cells belonging to the same DU within the area scope). If idle data transmission is limited to the cell pzcc ιπ / ζζιίζ / β / ΅ιλι where the UE enters the INACTIVE state, then the area scope may not be necessary. Alternatively, the UE can initiate the resumption procedure with RRCResumeRequest, and it may be up to the NW to determine whether to use idle data transmission or reconfigure the UE to the RRC_CONNECTED state. In this procedure, NW 5 can configure the PDCP recovery / reset procedure to trigger the retransmission of the PDCP PDU, which was transmitted along with the RRCResumeRequest message, if one exists. Alternatively, the target node can place the received data in buffer memory and process it after the context extraction procedure. In this procedure, a new RLC entity can be established, and the data stored in buffer memory will be processed once the new RLC is established. The RLC configuration can be the same as the RLC configuration used on the source node. Figure 5 is an exemplary signaling process 500 for anchor relocation 15 with data stored in buffer memory at the target node. In step 510, in a RACH-based solution, UE 502 can send the MsgA requesting RRC resumption to the target gNB 504. In step 512, the target gNB 504 can send a MsgB with contention resolution to UE 502. In step 514, in a CG-based solution, UE 502 can send the RRC resumption request via the CG resource to the target gNB 504. In step 516, target gNB 504 can place the received data into buffer memory. In step 518, target gNB 504 can send a UE context retrieval request to source gNB 506. In step 520, source gNB 506 can send a UE context retrieval response to target gNB 504. In step 522, target gNB 504 can set the UE context to CU / DU and process the data stored in buffer memory. In step 524, target gNB 504 can send a path switch request to AMF 508. In step 526, AMF 508 can send a path switch request acknowledgment to target gNB 504. In step 528, target gNB 504 can send a context release from UE 528 to source gNB 506. In step 530, target gNB 504 can send a C-RNTI scheduled data transmission to UE 502. In step In step 532, UE 502 can send a data transmission scheduled by the C-RNTI to target gNB 504. In step 534, target gNB 504 can send an RRC release to UE 502. Alternatively, data forwarding can be used instead of anchor relocation 35. In this procedure, the target node can forward both the RRCResumeRequest message and the received data packet to the source node. pzcc Ln / zznz / e / YiAi The source node can indicate whether context relocation is necessary. If context relocation is not necessary, then data forwarding can be performed instead. Alternatively, new RLC entities can always be established in gNB (or in gNB's DU) for idle data transmission, and configuration 5 can be used by default for the established RLC entities, where the default configuration can be specified in protocols or transmitted in system information. Because AM and UM RLCs can be supported, the target node can still require knowledge of the RLC type of a source node configuration, either through the context relocation process or based on the RLC type indication sent from the UE (e.g., in CE MAC UL). A second alternative may include identifying the RLC entity in gNB (or in CU of gNB), for INACTIVE data transmission. A third alternative may include the introduction of the similar AM function in PDCP (e.g., status reporting and polling-based retransmission). The data packet can be forwarded through the Xn interface, or a GTP tunnel which can be established for user plane data forwarding. If the data packet can be forwarded over the Xn interface via the XnAP message, then the target node can forward the data packet directly to the source node, along with the resume request message. If a GTP tunnel is used, then the tunnel can be either UE-specific or cell-specific (i.e., a common tunnel shared by all UEs for idle data transmission). Both the source node and the target node can initiate the release of idle data transmission. The target node can initiate the release by sending an end-of-transmission signal. Figure 6 is an exemplary signaling process 600 for data forwarding 25 used instead of anchor relocation. As shown in Figure 6, in step 608 of a RACH-based solution, UE 602 can send the MsgA with RRC Resumption Request to target gNB 604. In step 610, target gNB 604 can send the MsgB with contention resolution to UE 602. In step 612 of a CG-based solution, UE 602 can send an RRC Resumption Request via the CG resource to target gNB 604. In step 614, target gNB 604 can buffer the received data. In step 616, target gNB 604 can send a request to retrieve UE context to source gNB 606. In step 618, source gNB 606 can send a response to retrieve UE context to target 604. In step 620, target gNB 604 can set a UE context in the DU. In step 622, target gNB 604 can forward data to source gNB 606. In step 624, source gNB 606 can forward data to target gNB 604. In step 626, target gNB 604 can send a data transmission scheduled by the C-RNTI to UE 602. In step 628, UE 602 can send a data transmission scheduled by the C-RNTI to target gNB 604. In step 630, target gNB 604 can send an end-of-transmission indication to source gNB 606. In step 632, source gNB 606 can send a context release from the UE to target gNB 604. In step 634, target gNB 604 can send an RRC release to UE 602. Exemplary modality 4 A fourth exemplary scenario relates to the transmission type selection. In the procedural section, the RACH-based solution and the CG-based solution can be analyzed. Also, considering the legacy RRC resumption procedure, whenever the UE has data available in the buffer memory, the UE may require that the transmission type be determined, including any of the following: a RACH-based solution, a CG-based solution, a legacy RRC resumption procedure, a procedure involving an RRC, and / or a procedure without an RRC. For transmission type selection, any of the following cases may be considered. Initial transmission type selection, which can be performed by the UE whenever the UE determines to initiate data transmission based on the detection of incoming data from the UL. Transmission type switching, which can occur during INACTIVE data transmission, whenever the UE or NW determines that the criteria for inactive data transmission are no longer met, and the UE will switch to CONNECTED mode and perform normal UL transmission. A first procedure may include a selection of the initial transmission type. For the initial transmission type selection, any of the following can be considered: whether idle data transmission is allowed in the cell, whether idle data transmission is applicable to ongoing services, and / or whether both procedures with / without RRC involved are supported, whichever should be used. A second procedure may involve determining whether idle data transmission is permitted in a cell. The UE may determine whether idle data transmission is permitted (and / or what type of idle data transmission is permitted) in the cell based on any indication from system information or dedicated signaling. The following alternative may be considered: One alternative could include an indicator in the system information. One or more indicators could be included in the system information to indicate whether "idle data transmission" is permitted in the cell. The UE can only initiate "idle data transmission" if the indicator is set to true. pzcc ιπ / ζζιίζ / β / υιλι The indicator can be entered into the system information. The indicator can be provided per cell, per PLMN, or per RAN notification area. There can be multiple indicators, and each indicator is associated with a transmission type. A second alternative could include an indicator in dedicated signaling. One (for example, per UE) and / or multiple indicators (for example, per transmission type) could be included in dedicated RRC signaling to indicate whether "idle state data transmission" is permitted for the UE. The indicator can be introduced into the dedicated RRC signaling. There can be multiple indicators, and each indicator is associated with a transmission type. Alternatively, an area scope can be configured with dedicated signaling. An area scope can be configured for the UE via dedicated signaling, and either idle data transmission (e.g., the area scope is configured by UE) or a specific type of idle data transmission (e.g., the area scope is configured by transmission type) can only be permitted within the configured area scope. The area scope can be a cell or a list of cells, an RNA or a list of RNAs. The dedicated RRC message can be the signaling used to push the UE into the efficient idle state, or the dedicated RRC message sent before the UE enters the idle state. The RRC message can be either an RRC reconfiguration or an RRC release. An area range can be introduced in RRC signaling. Area range 20 can be by UE or by transmission type. In a fourth alternative, the indicator per cell in the RAN notification area. The area scope of the RAN notification area can be defined by a list of cells. For each cell in the cell list for the RAN notification area, one (for example, per UE) or multiple indicators (per transmission type) can be entered to indicate whether "idle data transmission" is permitted in that cell. One or more indicators can be entered into the cell information of the cell list, which can then be used to configure the area scope of the RAN notification area. The indicator can be used to indicate whether "idle data transmission" is permitted in that cell. A fifth alternative can be based on resource configuration. Idle data transmission can only be permitted if the configuration and / or resource is configured in the cell. The resource and / or configuration can be provided by either system information or a dedicated RRC message. In addition to resource configuration, a validation rule can also be defined. A specific type of idle data transmission can only be permitted if a valid resource exists for that transmission type. For example, the CG-based solution can only be used if a valid PUSCH configuration exists in the cell and a valid TA is maintained on the UE side. For the aforementioned indicator, the indicator can be either explicit or implicit. For an implicit indicator, it can be inferred from the resource configured for idle transmission (for example, once a resource is configured for a specific transmission type, the UE may consider that transmission type to be supported and / or permitted). A first example might include an indicator transmitted in system information to show whether idle data transmission is permitted in the cell. An indicator can be configured so that the UE indicates whether idle data transmission is permitted for the UE. With both indicators, the UE can only initiate idle data transmission if idle data transmission is permitted in the cell according to the indication in system information and also if idle data transmission is permitted by the UE according to the indication configured in dedicated signaling. A second example might include, if a valid CG resource is configured, that the The UE may select the CG resource; otherwise, if idle data transmission based on RACH is permitted, the UE should initiate the RACH procedure. In this example, the determination of whether the CG is valid or not can be based on any of the following: if a CG resource is configured and / or stored, the valid CG resource can be found in the qualified beam (e.g., the valid CG resource can be found in the SSB with quality above a preconfigured threshold, where the threshold can be configured in either system information or dedicated signaling), the configured and / or stored CG resource is permitted to be used for idle transmission, or a valid TA is maintained on the UE side (e.g., the TAT is running on the UE side). EU), and / or if inactive data transmission is applicable to ongoing services. Even if idle data transmission can be supported / permitted in a cell, ongoing services should be taken into account as well as in the transmission type selection, and the following information can be considered. The buffer size of the data on the UE side. To allow this, a buffer size threshold can be configured for the UE in either the system information or dedicated signaling. The buffer size threshold can be provided per UE, per logical channel, per logical channel group, or the sum of the buffer sizes for the LCH (logical channel) or LCG (logical channel group) for which idle data transmission is permitted. Once the buffer size on the UE side is less than (less than or equal to) the threshold, the UE is permitted to initiate "data transmission in RRCJNACTIVE"; otherwise, the UE should initiate the legacy RRC resumption procedure (e.g., state transition first).If the buffer memory size is defined per logical channel or group of logical channels, and buffer memory is not included for a logical channel or group of logical channels, data stored in buffer memory on that logical channel or group of logical channels will initiate the legacy RRC resume procedure (e.g., data transmission with a state transition; the UE or NW will trigger the state transition procedure directly, and the UE can send the RRC configuration request or RRC resume request message to the NW to initiate the state transition). Alternatively, if the buffer memory size is not configured, then "data transmission on RRCJNACTIVE" is not permitted, and the UE can always initiate the state transition first. Alternatively, the buffer memory size can be configured in both dedicated signaling and system information.If the buffer memory size is set in dedicated signaling, then the UE can use the value set in dedicated signaling; otherwise, the UE will use the value set in system information. The logical channel ID (or DRB ID, QoS flow ID, PDU session ID) for which data is available in buffer memory. To enable this, a flag per logical channel or group of logical channels (for example, the flag can be used to indicate whether data transmission without a state transition is permitted for this logical channel or group of logical channels) or a bitmap for logical channels or groups of logical channels (for example, the bitmap is used to indicate which logical channels or groups of logical channels are permitted for data transmission without a state transition) can be configured for the UE in dedicated signaling. With the flag, once data is stored in buffer memory on the UE side and all (or any) of the logical channel / group of logical channels with data stored in buffer memory are permitted to initiate “data transmission in RRC_INACTIVE,” the UE is permitted to initiate “data transmission in RRC_INACTIVE.” This flag can be modeled as part of the LCP parameters. Based on the combination of logical channel and buffer memory size, a new rule can be deduced regarding the total buffer memory size of the logical channel or groups of logical channels, for which data transmission without state transition is permitted. Based on network configuration. In this option, the network may include an explicit indication in the suspend configuration whether the UE is allowed to use idle data transmission or not. In an initial transmission type selection approach, either a UE-based solution or a NW-based solution can be considered for transmission type selection. In a UE-based solution, the UE can select the transmission type directly and can determine whether the data packet can be included in Msg3 / MsgA. In an NW-based solution, the UE can include the RRC message, which can trigger the state transition, in the RACH procedure payload or in the CG resource, and can depend on NW to determine whether to initiate the state transition or allow the UE to execute data transmission in INACTIVE mode or not. To help in the determination on the NW side, the UE can include some help information in either the RRC message or the CE MAC header or (or sub-header) MAC in the PDU MAC payload in Msg3 / MsgA or PDU MAC in the CG resource.For example, either the BSR or an idle data transmission indication 10 (which will be used to indicate whether or not the criterion for idle data transmission is met) can be sent to NW. For a transmission type switch, if the CG-based solution is initiated or if the CG-based data transmission is configured, the UE may initiate the RACH procedure when (in any of the following cases) the TA held on the UE side is not valid (e.g., TAT expired), the UE cannot receive the DL grant (or UL grant or PDCCH addressed to the C-RNTI) within a period of time or within a number of occasions from the PDCCH, where the timer (for the period of time) and / or counter (for the number of occasions from the PDCCH) may be configured either in system information or dedicated signaling, e.g., RRC reconfiguration message or RRC release message, before or when the UE enters the INACTIVE state, and / or when no qualified beam (e.g., SSB or CSI-RS) with CG resource can be found, and / or the best beam switch or qualified beam switch is changed.and / or the beam used in current transmissions is no longer valid (e.g., it is below a threshold that can be configured in either system information or dedicated signaling before or when the UE enters the INACTIVE state 25). Exemplary modality 5 Exemplary mode 5 can be related to beam mobility. Beam mobility can refer to beam switching during idle data transmission, where the beam refers to SSB or CSI-RS. For beam mobility, whenever a beam change is detected during IDT (idle data transmission), the UE can execute one of the following: initiate a RACH procedure; if a CG resource associated with the new beam is stored and / or configured, the UE can use the CG resource for transmission; and / or generate and / or include beam measurement result information in CE MAC or PHY layer signaling (e.g., UCI). Beam shift detection can be based on any of the following: a beam shift (e.g., SSB), the source beam quality (or current service beam) being above a threshold, the service beam quality (or current service beam) being below a threshold, and / or the target beam quality being above a threshold and the source beam quality (or current service beam) being below a threshold. The beam can be either SSB or CSI-RS. In some modalities, the evaluation will also consider a time to shoot, in which case the event will be considered as shot only if the criterion of the event is satisfied for a period of time, and the period of time will be controlled by a timer (e.g., time to shoot). In some modes, if the CG resource is configured for idle data transmission, and a beam change is detected or the current service beam quality falls below a threshold, the UE can: if any CG resource is available associated with the available beam (e.g., quality above a threshold), the UE uses the CG resource associated with the available beam. If no available CG resource associated with an available beam can be found, the UE can initiate a RACH procedure. In some modes, the UE may include beam measurement information for NW via CE MAC or PHY layer signaling (e.g., UCI). In some modes, the NW may configure one or multiple search spaces and / or CORESETs for idle status, and different search spaces and / or CORESETs may be associated with different beams. In some modes, the UE can be configured with one or multiple search spaces and / or CORESETs for idle status, and different search spaces and / or CORESETs can be associated with different beams. The UE can determine the DL and / or UL beam based on the reserved PDCCH search space and / or CORESET. Alternatively, the UE can determine which search space / CORESET should be used based on the selected service beam. Exemplary modality 6 Exemplary mode 6 can be related to measurement during INACTIVE data transmission. For the measurement space, two alternatives can be considered. A first alternative could include that the measurement space is not used for INACTIVE data transmission, or that the measurement depends on the UE implementation (for example, autonomous use by the UE implementation). A second alternative could involve using the metering space for idle data transmission. This space would be configured for the UE before or when the UE enters the idle state using dedicated signaling. For example, the metering space for idle data transmission could be configured for the UE with an RRC reconfiguration message before the UE enters the idle state; or the metering space for idle data transmission could be configured for the UE with an RRC release message that will be used to configure the UE in the idle state. pzcc ιπ / ζζιίζ / β / υιλι In a third alternative, a measurement space will be used for INACTIVE data transmission, and the measurement space configuration will be transmitted in system information. Optionally, with the measurement space configuration in system information, the UE will determine the measurement space location using both the measurement space configuration in system information and the UE ID, where the UE ID can be either l-RNTI or C-RNTI. For example, the UE determines the measurement space gap offset using: parameter mod A of UE ID or (parameter mod A / B of UE ID) * parameter B or (parameter mod A / B of UE ID) * parameter B, where parameters A and B can be either configurable parameters set in SIB (for example, parameter A can be the measurement space repetition period, parameter B can be the measurement space length), in dedicated signaling, or a constant specified in specifications.Alternatively, a separate parameter C can be used instead of the UE ID, and parameter C can be configured by dedicated signaling before or when the UE enters the inactive state. Example mode 7. Exemplary modality 7 can be related to the re-selection of cells during IDT. During the IDT, the UE can continue the cell re-selection assessment. And the UE can execute the following operations (at least one of the following actions), once the cell re-selection is executed or once the conditions for cell re-selection are met, or once the UE initiates the IDT on the re-selected target cell, or once the UE initiates the resume procedure on the re-selected target cell. A first action might include suspending the DRB. A second action might include stopping the idle data transmission. A third action might include considering the idle data transmission timer expired, or considering the TAT expired. A fourth action might include releasing the configured CG resource, considering the CG resource unavailable, or releasing the C-RNTI. A fifth action might include, to transmit the PDCP entity, maintaining TX_NEXT (i.e., not setting TXNEXT to its initial value). A sixth action might include, to receive the PDCP entity, maintaining RX_NEXT and RX_DELIV (i.e., not setting RX_NEXT and RX_DELIV to their initial values). A seventh action may include resetting and / or releasing the RLC entities for DRB and / or SRB. An eighth action may include executing PDCP recovery or PDCP reset for DRB. A ninth action may include executing PDCP reset for SRB. Alternatively, if IDT is initiated on the reselected target cell, then PDCP recovery or PDCP reset may be triggered; if the legacy resume procedure is initiated on the reselected target cell, then a suspend PDCP operation may be triggered. pzcc ιπ / ζζιίζ / β / υιλι In some modes, the above actions (e.g., action 1 / 5 / 6) may only be required for DRB, for which idle data transmission is permitted. In certain modes, the above actions may be executed when cell reselection is performed. In certain modes, the above actions may be executed when the UE initiates idle data transmission or the RRC re-establishment procedure on the target cell. In some modes, if cell reselection occurred or the criteria for cell reselection are met during idle data transmission, the UE may initiate the RRC re-establishment procedure on the target cell. Exemplary modality 8 Exemplary mode 8 can be related to fault handling. Once a fault is detected during idle data transmission, the following action can be considered. A first alternative could be for the UE to initiate the normal resumption procedure. A second alternative could be for the UE to prioritize the currently active cell in cell reselection. A third alternative could be for the UE to initiate the RRC reset procedure (for example, if a CG transmission fault or an RLC fault is detected). A fourth alternative could be for the UE to initiate the RACH procedure. (For example, if a CG transmission fault or an RLC fault is detected, or if a beam fault is detected, the UE should initiate the RACH procedure). A fifth alternative could be for the UE to enter the STANDBY state (for example, if a RACH fault is detected, or the T319 expired, or is detected out of coverage). For fault detection, any of the following faults can be considered: RLC fault, RACH fault, CG transmission fault, out-of-coverage detection, T319 expiration, and / or beam fault. For RLC fault, RACH fault, out-of-coverage, and beam fault, the fault detection defined for the CONNECTED state can be reused for the inactive state. For fault detection (e.g., RLC fault detection, beam fault detection, etc.), specific fault detection parameters for the idle state (parameters that will be used to configure fault detection, and these parameters used in the idle state may differ from those used in ON mode) can be configured when or before the UE enters the idle state. For example, these fault detection parameters can be configured using system information or an RRC reconfiguration message before the UE enters the idle state, or using an RRC release message, which will be used to configure the UE to the idle state. In some alternatives, fault detection parameters can be configured in both system information and dedicated signaling, and parameters configured in dedicated signaling will have higher priority than parameters configured in system information (for example, parameters configured in dedicated signaling will be used if both are configured). In some alternatives, fault detection parameters can be configured in both system information and dedicated signaling, and parameters configured in dedicated signaling will have lower priority than parameters configured in system information (for example, parameters configured in system information will be used if both are configured). For a CG transmission failure, the failure can be defined as no PDCCH directed to C-RNTI, or UL / DL grant, being received before the timer expires or after N PDCCH occurrences. The timer and / or counter (counter for the number of 10 PDCCH occurrences) can be started at or after the initial transmission through the CG resource. In some alternatives, if a fault is detected on the UE side, and the UE has a valid C-RNTI (or l-RNTI), then the UE can execute the RRC reset procedure. In some alternatives, if a fault is detected on the UE side 15, and the UE does not have a valid C-RNTI (and / or l-RNTI), then the UE can enter the REST state. Exemplary modality 9 Exemplary mode 9 can be related to resource configuration. For RACH resource configuration, the RACH resource for idle data transmission 20 can be configured for the UE with dedicated system information and / or signaling.The following resources can be configured for idle data transmission: idle data transmission-specific PRACH resource, idle data transmission-specific PUSCH MsgA resource set, idle data transmission-specific CORESET / Search Space for receiving Msg2 and / or MsgB, PDCCH resource, PUCCH 25 resource, SRS resource, idle data transmission BWP configuration (e.g., the BWP used for idle data transmission may be different from the initial BWP), DRX configuration used during idle data transmission, RLC and / or MAC configuration used during idle data transmission, other physical layer configuration (different from the physical layer configuration that cannot be covered above) used during idle data transmission, and / or bandwidth (e.g., channel bandwidth, or cell bandwidth) used for idle data transmission.In some modes, a timer (e.g., timer length) can be configured for the UE to indicate the validity period of the specific idle data transmission resource. The timer can be started once the message is received or the UE enters the idle state. The idle data transmission resource configured by dedicated signaling (e.g., CG resource, C-RNTI) can be removed on the UE side once the timer expires. In some modes, if the UE initiates the IDT in a cell different from the cell where the specific idle data transmission resource is configured, then the specific idle data transmission resource configured by dedicated signaling (e.g., CG resource, C-RNTI) can be removed.In some modes, if the UE re-selects a cell that is different from the cell where the specific idle data transmission resource is configured, the specific idle data transmission resource configured by dedicated signaling (e.g., CG resource, C-RNTI) may be removed. In certain modes, if SCG is configured (e.g., in LTE-DC, EN-DC, MR-DC, NR-DC, and / or multiple connectivity instances), the idle data transmission configuration may be provided for MCG (primary cell group) and / or SCG (secondary cell group). If idle data transmission is provided to SCG, then idle data transmission will be applied to SCG. The modes described in this application may be applicable to MCG and / or SCG. For the configuration of resources with dedicated signaling, the configuration can be provided in an RRC reconfiguration message or an RRC release message, before or when the UE enters the idle state. For configuring resources with dedicated signaling, in addition to the resource configurations listed above, the contention-free RACH resource can also be configured for the UE. The contention-free RACH resource can be either the 2-step or 4-step contention-free RACH resource. In certain modes, a timer (e.g., timer length) can be configured for the UE to indicate the validity period of the CFRA resource (e.g., the CFRA resource will be released or considered invalid once the timer expires). The timer can be started once the message is received or when the UE enters the idle state. For the configured grant resource, the following aspect can be considered: One or multiple CG resources can be configured for idle data transmission. In some modes, if there are CG resources configured in the connected state, the NW can indicate in signaling (for example, using ConfiguredGrantConfiglndex) which CG resource can be used in the idle state. An area scope can be configured for the CG resource, and the CG resource can only be used within that area scope. In some modes, the area scope is a cell, a list of cells, an RNA (RAN notification area), a list of RNAs, or a TA or a list of TAs. In some modes, the area scope is limited to the cell where the UE enters the inactive state, in which case no explicit configuration is required. pzcc ιπ / ζζιίζ / β / υιλι Different CG resources can be configured for different beams, where the beam can be SSB and / or CSI-RS. Different CG resources can be configured for different DRBs. In a certain mode, for each DRB, LCH, PDCP, or RLC, a CG resource ID (e.g., ConfiguredGrantConfiglndex) or a list of CG resource IDs can be configured, and only the DRB (LCH / PDCP / RLC) configured with a CG resource ID can execute idle data transmission with a CG resource. A TAT timer can be configured for the idle state. In some modes, the length of the TAT timer used in the idle state may differ from the length of the TAT timer used in the connected state. In certain modes, if the TAT timer for the idle state is absent, the UE may use the length of the TAT timer used in connected mode. In some modes, if the length of the TAT timer for the idle state is configured in both system information and dedicated signaling, the UE may use the value configured in dedicated signaling. In some modes, if the length of the TAT timer for the idle state is configured in both system signaling and dedicated signaling, the UE may use the value configured in system information signaling. A timer can be configured to determine the duration of the CG resource's availability in the idle state. The CG resource can be considered valid before the timer expires. The timer can be configured by either the UE or the CG. Timer 20 can be initiated once the message is received or the UE enters the idle state. The timer's duration can be configured in dedicated signaling (e.g., RRC reconfiguration message or RRC release message before or when the UE enters the idle state). Another resource for transmitting / receiving in the IDLE state. This resource may include C-RNTI, l-RNTI, Searchspace, CORESET, SRS resource, PUCCH resource, and / or BWP configuration for idle data transmission. The aforementioned resource may be the same as the resource used for the connected state or it may be different from the resource used for the connected state (i.e., a resource specific to the idle state). In some modes, the UE may use this resource once idle data transmission is initiated. In some modes, the UE may use this resource once the RRC resume message is received and the UE is configured to execute idle data transmission. The above configurations can be provided in either dedicated signaling (e.g., UE-specific resource configuration) or system information (cell-specific resource configuration). The above configurations can be configured for the UE with RRC message reconfiguration or pzcc release. RRC before or when the UE enters the inactive state. In some modes, the CG resource is configured and transmitted via system information, and the UE can select a resource or a subset of the transmitted resource for idle data transmission based on the configuration received in the system information. In some modes, multiple sets of CG resources can be configured in system information, and the UE will select the configured CG resource based on the QoS requirement, UE ID (C-RNTI or l-RNTI), Segment, access category, or access type. In some modes, the common CG configuration transmitted in system information 10 can coexist with the dedicated CG configuration configured in dedicated signaling. If a dedicated CG configuration is provided, the UE should use the dedicated CG configuration; otherwise, the common CG configuration can be used. Resource configuration sharing for idle data transmission between two network nodes is supported. This sharing can be performed over the X2 or Xn interface (or an additional interface between two RAN access nodes). The resource configuration can be included in either an inter-node message or X2AP / XnAP signaling. For access control, separate access control parameters can be configured for idle data transmission (e.g., different parameters can be configured for initial access and idle data transmission). For the aforementioned RACH and / or CG resource, a different resource configuration can be configured for a different NW and / or CAG and / or NPN segment, and / or a different access category and / or a different access type. For the aforementioned RACH and / or CG resource, a different resource configuration 25 can be set to REST or INACTIVE state. Parameters for transmission type selection can be configured in system information and / or a dedicated RRC message (RRC reconfiguration message or RRC release message). In some modes, if the transmission type parameters are configured with dedicated signaling, the UE can ignore the parameters configured in system information. The following parameters can be considered for transmission type selection: RSRP threshold for idle data transmission. In some modes, the UE can initiate idle data transmission only if the cell RSRP is above (or “equal to or above”) the RSRP threshold. In some modes, the UE is only allowed to select a certain transmission type for idle data transmission if the cell RSRP is above (or “equal to or above”) the RSRP threshold (in this case, the RSRP threshold is configured per transmission type). Path loss threshold for idle data transmission. In some modes, the UE can initiate idle data transmission only if the path loss is less than (or "equal to or less than") the path loss threshold. In one mode, the UE is only allowed to select a certain transmission type for idle data transmission if the cell path loss is less than (or “equal to or less than”) the path loss threshold (in this case, the RSRP threshold is set by transmission type). The buffer memory size threshold for idle data transmission. In a certain mode, the UE is only allowed to initiate idle data transmission if the buffer memory size is less than (or "equal to or less than") the buffer memory size threshold. The buffer memory size can be the overall buffer memory size per UE, the overall buffer memory size for the DRB / LCH of a UE, for which idle data transmission is allowed, and / or the buffer memory size for a DRB or LCH or LCG. Exemplary modality 10 Exemplary mode 10 can be related to security management. For security management during idle data transmission, the following alternatives can be considered. A first alternative could include using the old security configuration 20 during idle data transmission. A second alternative could involve using the old security configuration for the security protection of the first message or the RRC resumption message. The new security configuration could then be used for the next transmission (for example, the new security configuration would be used once the RRC resumption request message is generated or transmitted). A third alternative could be to always allow the use of the new security configuration. The old security configuration could refer to the security configuration used before the UE entered the inactive state. The new security configuration could refer to the security configuration derived from the security configuration set in the RRC release message (which will be used to configure the UE to the inactive state). The security configuration may include the security key and / or security algorithm. In some modes, the UE can perform horizontal key derivation if idle data transmission is configured or if idle data transmission is running or initiated. In some modes, the UE can perform either vertical or horizontal key derivation based on the NW-side configuration. The pzcc ιπ / ζζιίζ / β / ΅ιλι configuration may be provided to the UE in dedicated RRC signaling (e.g., RRC reconfiguration and / or RRC release). In certain modes, the UE can determine the key derivation type based on the selected idle data transmission type. For example, if idle data transmission with no RRC involved is selected, the UE can always perform horizontal key derivation. Exemplary modality 11 Exemplary mode 11 can be related to an impact on the user plane. In some modes, if the RRC release message is received and idle data transmission is configured and / or allowed based on the received RRC release message 10, and / or the CG resource for idle data transmission is configured, the UE can, for the DRB and / or PDCP for which idle data transmission is not supported: To transmit the PDCP entity, set TX_NEXT to the initial value and / or discard all stored PDCP PDUs. To receive the PDCP entity, if t-reordering is running: stop and restart t-reordering, deliver all stored PDCP SDUs to the upper layers in ascending order of associated COUNT values ​​after performing header decompression, and set RX_NEXT and RX_DELIV to the initial value. For DRBs and / or PDCPs that support idle data transmission, the first option is to not perform a PDCP suspend operation, and no special PDCP operation is required. The second option is to suspend the DRB. The third option is to perform a PDCP recovery or PDCP reset. The fourth option is for PDCP. To transmit the PDCP entity, it can maintain TXNEXT (i.e., not set TX_NEXT to its initial value). To receive the PDCP entity, it can maintain RXNEXT and RXDELIV (i.e., not set RXNEXT and RXDELIV to their initial values). In some modes, if the RRC release message is received and idle data transmission is configured and / or allowed based on the received RRC release message, and / or the CG resource for idle data transmission is configured, the UE, for each DRB, may not execute the suspend PDCP operation, and no special operation is required on PDCP, suspend DRB, execute PDCP recover or execute PDCP reset, and / or for PDCP. To transmit the PDCP entity, it can maintain TX NEXT (i.e., it does not set TX_NEXT to its initial value). To receive the PDCP entity, it can maintain RX NEXT and RX_DELIV (i.e., it does not set RX NEXT and RX_DELIV to its initial value). In some modes, if “idle data transmission is configured and / or allowed based on the received RRC release message,” and / or “CG resource for idle data transmission is configured,” and “if the UE determines to initiate the normal RRC resumption procedure,” or “the cell where the UE initiates the RRC resumption procedure does not support or allow idle data transmission,” before or when the UE initiates the RRC resumption procedure, the UE may execute PDCP suspension for each DRB. In some modes, if the UE determines to initiate idle data transmission or if idle data transmission is configured and / or allowed in the cell, before or when the UE initiates the RRC resumption procedure, the UE may execute the PDCP reset procedure for each DRB, may execute the PDCP reset procedure for each DRB, for which idle data transmission is allowed, may execute the PDCP recovery procedure for each DRB, and / or may execute the PDCP recovery procedure for each DRB, for which idle data transmission is allowed. In one mode, if the IDT is allowed, then the UE may not execute the suspend PDCP operation; otherwise, the UE may execute the suspend PDCP operation. In some modes, if the UE determines to initiate idle data transmission or if idle data transmission is configured and / or allowed in the cell, before or when the UE initiates the RRC resumption procedure, the UE may re-establish the RLC entity (or entities) for each RLC or LCH or DRB and / or re-establish the RLC entity (or entities) for each RLC or LCH or DRB, for which idle data transmission is allowed. The re-establishment of RLC can be replaced by the release / addition or establishment of the RLC entity. For the re-establishment of the RLC entity (or release / addition or establishment of the RLC entity), the default configuration should be used, the configuration that was used before the UE entered the inactive state should be reused, or the configuration 25 configured for inactive data transmission should be used, and the configuration can be provided to the UE by the RRC reconfiguration message or the RRC release message, before or when the UE enters the inactive state. In some modes, if the CG resource is configured for idle data transmission, or if TAT is configured for idle, or if idle data transmission is configured / allowed, the UE can keep the TAT (timeAlignmentTimer) timer in an idle state. In some modes, if the TAT expired in an inactive state, the UE may release or clear any configured downlink assignments and / or CG resources. Exemplary method for data transmission in an efficient power state Figure 700 is a block diagram of an exemplary data transmission method in a power-efficient state. The method may include the transmission, through a terminal in a first state, of a first message to a network node to initiate a data communication resumption procedure to the network node (block 702). The first state may include a power-efficient state, such as an idle or rest state, as described herein. The method may also include monitoring, after the transmission of the first message, a control channel with a temporary network identifier for a response to the first message (block 704). The terminal, in the first state, may limit the use of radio resources through the network node. The temporary network identifier may include a cell radio network temporary identifier (C-RNTI) or an idle radio network temporary identifier (l-RNTI) as described here. In some modes, the first message is either a Radio Resource Control (RRC) resume request message and an RRC configuration request message. In some modes, the response to the first message includes a containment solution, where the terminal monitors the control channel including a physical downlink control channel 15 (PDCCH) with the temporary network identifier including a cell radio network temporary identifier (C-RNTI) identified in the response to the first message. In some modalities, the method includes receiving, through the terminal, an initial data transmission programmed by the temporary network identifier monitored from the 20th network node. In some modalities, the method includes transmitting, through the terminal, a second data transmission scheduled by the monitored temporary network identifier to the network node. In some modes, the method includes receiving, through the terminal, an RRC release message 25 from the network node; and in response to receiving the RRC release message, stopping, through the terminal, the monitoring of the control channel with the temporary network identifier configured for the terminal and may discard the temporary network identifier. In some modes, the RRC release message is the response to the first message. In some modes, the first message includes a request to resume RRC transmitted through a configured grant resource (CG), and wherein the RRC release message is scheduled by the temporary network identifier configured for the terminal. In some modes, the method includes initiating, via the terminal, an idle data transmission timer in response to receiving the reply to the first message, where the terminal monitors the control channel with the temporary network identifier pzcc ιπ / ζζιίζ / β / υιλι configured for the terminal in response to initiating the idle data transmission timer. In some modes, the method includes receiving, through the terminal, PDCCH programming information with a C-RNTI; and in response to receiving the PDCCH programming information with the C-RNTI, resetting, through the terminal, the idle data transmission timer. In some modalities, the method includes detecting, through the terminal, an idle data transmission timer expiration; and in response to detecting the idle data transmission timer expiration, executing, through the terminal, any control channel stop monitoring with the temporary network identifier configured for the terminal, discarding the temporary network identifier, and / or suspending a dedicated radio carrier (DRB) and / or a packet data convergence protocol (PDCP). In some modes, an idle data transmission timer length 15 is set by either an RRC reconfiguration message (e.g., received through the terminal before the terminal switches to the idle state), an RRC release message (e.g., which will be used to set the terminal to the idle state), and system information from any message where data transmission is executed. In some modes, the first message includes an idle radio network temporary identifier (l-RNTI), a media access control (MAC) control element (CE), a MAC service data unit (SDU), and a MAC protocol data unit (PDU). In some modes, the response to the first message includes either a CRNTI and the l-RNTI that will be used for contention resolution. In some modes, the first message includes data transmitted through a CG resource. In some modalities, the method includes receiving, through the terminal, a control element (CE) MAC from the network node that includes an indication to release the temporary network identifier; in response to receiving the CE MAC from the network node, stopping, through the terminal, the monitoring of the control channel with the temporary network identifier configured for the terminal; and discarding, through the terminal, the temporary network identifier comprising a C-RNTI. In another embodiment, a method for wireless communication may include the reception, via a network node, of an initial message to initiate a data communication resumption procedure from a terminal in a first state. The method may also include the transmission, via the network node, of a response to the initial message to the terminal pzcc ιπ / ζζιίζ / β / υιλι that monitors a control channel with a temporary network identifier for the response to the initial message. In some modes, in the first state, the use of radio resources through the terminal is limited by the network node, or UL synchronization maintenance is not required unless the IDT is configured, or PDCCH monitoring directed to the C-RNTI is not required unless the IDT is running, or the UE is required to monitor the locator channel. In some modes, the first message is either a Radio Resource Control (RRC) resume request message and an RRC configuration 10 request message. In some modes, the response to the first message includes a containment solution, where the terminal is configured to monitor the control channel including a physical downlink control channel (PDCCH) with the temporary network identifier including a cell radio network temporary identifier (C-RNTI) identified in the 15 response to the first message. In some modalities, the method includes transmitting, through the network node, an initial data transmission programmed by the monitored temporary network identifier to the terminal. In some modalities, the method includes receiving, through the network node, a 20-second data transmission programmed by the temporary network identifier monitored from the terminal. In some modes, the method includes transmitting, through the network node, an RRC release message to the terminal, where the terminal is configured to stop monitoring the control channel with the temporary network identifier configured for terminal 25 and can discard the temporary network identifier in response to receiving the RRC release message from the network node. In some modes, the RRC release message is the response to the first message. In some modes, the first message includes a 30 RRC resumption request transmitted through a configured grant resource (CG), and where the RRC release message is scheduled by the temporary network identifier configured for the terminal. In some modes, the terminal is configured to start an idle data transmission timer in response to receiving the reply to the first message and monitor the control channel with the temporary network identifier configured for the terminal in response to starting the idle data transmission timer. pzcc ιπ / ζζιίζ / β / υιλι In some modes, the first message includes an idle radio network temporary identifier (l-RNTI), a media access control (MAC) control element (CE), a MAC service data unit (SDU), and a MAC protocol data unit (PDU). In some modes, the response to the first message includes either a C5 RNTI and the l-RNTI that will be used for contention resolution. In some modes, the first message includes data transmitted through a CG resource. In some embodiments, the method includes transmitting, through the network node, a MAC control element (CE) to the terminal that includes an indication to release the temporary network identifier, wherein the terminal is configured to stop monitoring the control channel with the temporary network identifier configured for the terminal and can discard the temporary network identifier comprising a C-RNTL Exemplary wireless system Figure 8 shows an example of a wireless communication system where techniques can be applied according to one or more modalities of the present technology. An 800 wireless communication system may include one or more 805a, 805b base stations (BSs), one or more 810a, 810b, 810c, 810D wireless devices or terminals, and an 825 core network. An 805a, 805b base station may provide wireless service to 810a, 810b, 810c, and 810D wireless devices in one or more wireless sectors. In some implementations, an 805a, 805b base station includes directional antennas to produce two or more directional beams to provide wireless coverage in different sectors. The base station may implement programming cell or candidate cell functionalities, as described herein. The 825 core network can communicate with one or more 805a and 805b base stations. The 825 core network provides connectivity with other wireless and wired communication systems. The core network may include one or more service subscription base stations to store information related to subscribed 810a, 810b, 810c, and 810d wireless devices. A first 805a base station may provide wireless service based on a first radio access technology, while a second 805b base station may provide wireless service based on a second radio access technology. The 805a and 805b base stations may be co-located or separately deployed in the field, depending on the deployment scenario. The 810a, 810b, 810c, and 810d wireless devices may support multiple different radio access technologies. In some implementations, a wireless communication system can include multiple networks using different wireless technologies. A dual-mode or multi-mode wireless device includes two or more wireless technologies that could be used to connect to different wireless networks. Figure 9 is a block diagram representation of a portion of a hardware platform. A hardware platform 905, such as a network node, base station, terminal, or wireless device (or UE), may include processor electronics 910, such as a microprocessor, that implements one or more of the techniques presented in this document. The hardware platform 905 may include transceiver electronics 915 for sending and / or receiving wired or wireless signals over one or more communication interfaces, such as an antenna 920 or a wired interface. The hardware platform 905 may implement other communication interfaces with defined protocols for transmitting and receiving data. The hardware platform 905 may include one or more memories (not explicitly shown) configured to store information such as data and / or instructions.In some implementations, the 910 processor electronics may include at least a portion of the 915 transceiver electronics. In some modalities, at least some of the disclosed techniques, modules, or functions are implemented using the 905 hardware platform. Conclusion As a result of the foregoing, it will be appreciated that several techniques are described to allow a wireless device to execute data transmissions while in a power-efficient state, such as the first state described with respect to FIGURE 7, in which the base station or a network device limits the use of radio resources by a wireless device. For example, in the power-efficient state, the network device might not provide the wireless device with opportunities to transmit or receive unicast IP layer data. Specific embodiments of the technology disclosed herein have been described for illustrative purposes, but various modifications may be made without departing from the scope of the invention. Accordingly, the technology disclosed herein is not limited except by the appended claims. The disclosed modalities, as well as other modules and functional operations described in this document, may be implemented in digital electronic circuits, or in computer software, firmware, or hardware, including the structures disclosed in this document and their structural equivalents, or in combinations of one or more of them. The disclosed modalities, as well as others, may be implemented as one or more computer program products, that is, one or more computer program instruction modules encoded in a computer-readable medium for execution by, or to control the operation of, data processing devices.A computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of material that carries a machine-readable propagated signal, or a combination of one or more of these. The term “data processing apparatus” encompasses all apparatuses, devices, and machines for data processing, including, for example, a programmable processor, a computer, or multiple processors or computers. The apparatus may include, in addition to hardware, code that creates an execution environment for the computer program in question, for example, code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of these.A propaganda signal is an artificially generated signal, for example, a machine-generated electrical, optical, or electromagnetic signal, i.e., generated to encode information for transmission to a suitable receiving device. A computer program (also known as a program, software, software application, script, or code) can be written in any programming language, including compiled or interpreted languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit convenient for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (for example, one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (for example, files that store one or more modules, subprograms, or portions of code).A computer program can be deployed to run on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network. The processes and logic flows described in this document can be executed by one or more programmable processors running one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be executed by, and the devices can also be implemented as, special-purpose logic circuits, for example, an FPGA (Field-Programmable Gate Array) or an ASIC (Application-Specific Integrated Circuit). Processors suitable for running a computer program include, for example, general-purpose and special-purpose microprocessors, and any one or more processors of any type of digital computer. Generally, a processor will retrieve instructions and data from read-only memory or random-access memory. The essential elements of a computer are a processor to execute instructions and one or more memory devices to store instructions or data. pzcc ιπ / ζζιίζ / β / υιλι Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, for example, magnetic disks, magneto-optical disks, or optical disks. However, a computer does not need to have such devices. Convenient computer-readable media for storing computer program instructions and data includes all forms of non-volatile memory, memory devices, and media, including, by way of example, semiconductor memory devices, for example, EPROM, EEPROM, and flash memory devices; magnetic disks, for example, internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated into, special-purpose logic circuitry. Although this patent document contains many specific points, these should not be interpreted as limitations on the scope of any invention or what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular inventions. Some features described in this patent document in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, several features described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any convenient sub-combination.Furthermore, although the features could previously be described as acting in some combinations and could even initially be claimed as such, one or more features of a claimed combination may, in some cases, be removed from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination. Similarly, although the operations are shown in the drawings in a particular order, this should not be construed as requiring that these operations be performed in the particular order shown or in a sequential order, or that all the illustrated operations be performed, to achieve the desired results. Furthermore, the separation of various system components in the modalities described in this patent document should not be construed as requiring such separation in all modalities. Only a few implementations and examples are described, and other implementations, improvements, and variations can be made based on what is described and illustrated in this patent document.

Claims

NOVELTY OF THE INVENTION Having described the present invention, the following is considered novel and is therefore claimed as property: 5 CLAIMS 1. A method for wireless communication, characterized in that it comprises: transmitting, through a terminal in a first state, a first message to a network node to initiate a procedure for resuming data communication with the network node; and 10 monitoring, after the transmission of the first message, a control channel with a temporary network identifier for a response to the first message.

2. The method according to claim 1, characterized in that, in the first state, the use of radio resources by the terminal is limited by the network node.

3. The method according to claim 1, characterized in that the first 15 message is either a Radio Resource Control (RRC) resume request message and an RRC configuration request message.

4. The method according to any of claims 1 and 3, characterized in that the response to the first message includes a containment solution, wherein the terminal monitors the control channel including a physical downlink control channel 20 (PDCCH) with the temporary network identifier including a cell radio network temporary identifier (C-RNTI) identified in the response to the first message.

5. The method according to claim 1, characterized in that it further comprises: receiving, through the terminal, a first data transmission programmed by the 25 temporary network identifier monitored from the network node.

6. The method according to any of claims 1 and 5, characterized in that it further comprises: transmitting, through the terminal, a second data transmission programmed by the monitored temporary network identifier to the network node. 30 7. The method according to claim 1, characterized in that it further comprises: receiving, through the terminal, an RRC release message from the network node; and in response to receiving the RRC release message, stopping, through the terminal, the monitoring of the control channel with the temporary network identifier configured for the terminal and discarding the temporary network identifier.

8. The method in accordance with any of claims 1 and 7, characterized in that the RRC release message includes the response to the first message.

9. The method according to any of claims 1, 7 and 8, characterized in that the first message includes a request to resume RRC 5 transmitted through a configured granting resource (CG), and wherein the RRC release message is scheduled by the temporary network identifier configured for the terminal.

10. The method according to any of claims 1, 8 and 9, characterized in that it further comprises: 10 initiating, through the terminal, a first timer in response to receiving the response to the first message, wherein the terminal monitors the control channel with the temporary network identifier configured for the terminal in response to initiating the idle data transmission timer.

11. The method according to claim 10, characterized in that 15 further comprises: receiving, through the terminal, programming information from the PDCCH with a C-RNTI; and in response to receiving the programming information from the PDCCH with the C-RNTI, resetting, through the terminal, the idle data transmission timer. 20 12. The method according to any of claims 1, 10 and 11, characterized in that it further comprises: detecting, through the terminal, an expiration of the idle data transmission timer; and in response to detecting the expiration of the idle data transmission timer, executing, through the terminal, any of stopping the monitoring of the control channel with the temporary network identifier configured for the terminal, discarding the temporary network identifier, and / or suspending a dedicated radio carrier (DRB) and / or a data convergence protocol (PDCP).

13. The method according to any of claims 1 and 10 to 12, characterized in that an idle data transmission timer length is configured by any of an RRC reconfiguration message received through the terminal before the terminal switches to the idle state, an RRC release message used to configure the terminal to the idle state, and system information from any message where data transmission takes place.

14. The method according to claim 1, characterized in that the first message includes a temporary idle radio network identifier (l-RNTI), a medium access control (MAC) control element (CE), a MAC service data unit (SDU), and a MAC protocol data unit (PDU).

15. The method in accordance with any of claims 1 and 14, characterized in that the response to the first message includes either a C-RNTI and the I5 RNTI to be used for contention resolution.

16. The method according to claim 1, characterized in that the first message includes data transmitted through a CG resource.

17. The method according to claim 1, characterized in that it further comprises: 10 receiving, through the terminal, a control element (CE) MAC from the network node that includes an indication to release the temporary network identifier; in response to receiving the CE MAC from the network node, stopping, through the terminal, the monitoring of the control channel with the temporary network identifier configured for the terminal; and 15 discarding, through the terminal, the temporary network identifier comprising a CRNTL 18. A method for wireless communication, characterized in that it comprises: receiving, through a network node, a first message to initiate a data communication resumption procedure from a terminal in a first state; and 20 transmitting, through the network node, a response to the first message to the terminal monitoring a control channel with a temporary network identifier for the response to the first message.

19. The method according to claim 18, characterized in that, in the first state, the use of radio resources by the terminal is limited by the network node. 25 20. The method according to claim 18, characterized in that the first message is either a Radio Resource Control (RRC) resume request message and an RRC configuration request message.

21. The method according to any of claims 18 and 20, characterized in that the response to the first message includes a containment solution, wherein the terminal is configured to monitor the control channel including a physical downlink control channel (PDCCH) with the temporary network identifier including a cell radio network temporary identifier (C-RNTI) identified in the response to the first message.

22. The method according to claim 18, characterized in that it further comprises: transmitting, through the network node, a first data transmission programmed by the monitored temporary network identifier to the terminal.

23. The method according to any of claims 18 and 22, characterized in that it further comprises: receiving, through the network node, a second data transmission programmed by the temporary network identifier monitored from the terminal.

24. The method according to claim 18, characterized in that it further comprises: transmitting, through the network node, an RRC release message to the terminal, wherein the terminal is configured to stop monitoring the control channel with the temporary network identifier configured for the terminal and discard the temporary network identifier in response to receiving the RRC release message from the network node.

25. The method in accordance with any of claims 18 and 24, characterized in that the RRC release message is the response to the first message.

26. The method according to any of claims 18, 24 and 25, characterized in that the first message includes an RRC resumption request transmitted through a configured granting resource (CG), and wherein the RRC release message is scheduled by the temporary network identifier configured for the terminal.

27. The method according to any of claims 18, 25 and 26, 20 characterized in that the terminal is configured to start an idle data transmission timer in response to receiving the reply to the first message and monitor the control channel with the temporary network identifier configured for the terminal in response to starting the idle data transmission timer.

28. The method according to claim 18, characterized in that the first 25 message includes an idle radio network temporary identifier (l-RNTI), a medium access control (MAC) control element (CE), a MAC service data unit (SDU), and a MAC protocol data unit (PDU).

29. The method in accordance with any of claims 18 and 28, characterized in that the response to the first message includes either a C-RNTI and the I30 RNTI to be used for contention resolution.

30. The method according to claim 18, characterized in that the first message includes data transmitted through a CG resource.

31. The method according to claim 18, characterized in that it further comprises: 35 transmitting, through the network node, a MAC control element (CE) to the terminal which includes an indication to release the temporary network identifier, wherein the terminal is configured to stop monitoring the control channel with the temporary network identifier configured for the terminal and to discard the temporary network identifier comprising a CRNTL 32. A wireless communication apparatus, characterized in that it comprises a processor configured to carry out the method in accordance with any of claims 1 to 31.

33. A non-transient computer-readable medium characterized in that it has a code stored therein, the code, when executed by a processor, causing the processor to perform a method mentioned in any one of claims 1 to 31.

Images