Wireless communication method, terminal device, and network device

Abstract

Provided are a wireless communication method, a terminal device, and a network device. The wireless communication method comprises: a terminal device receives a first downlink message in a first procedure, the first procedure being used by the terminal device in an RRC idle state to transmit first uplink data; and, on the basis of the first downlink message, the terminal device determines to terminate the first procedure or receive a second downlink message, the second downlink message being used by the terminal device to determine to terminate the first procedure.

Description

Wireless communication methods, terminal devices, and network devices Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a wireless communication method, terminal device, and network device. Background Technology

[0002] To reduce signaling overhead and power consumption between terminal devices and network devices during data transmission, some communication systems (such as new radio (NR) systems) allow terminal devices in the radio resource control (RRC) idle state to transmit data to network devices. For example, a terminal device in the RRC idle state can transmit uplink data via message 3 during the random access procedure. Afterward, the terminal device needs to receive a downlink RRC message from the network device to determine whether to terminate the uplink transmission process, and also needs to receive a medium access control element (MAC CE) with a contention resolution identity (CRID), resulting in significant signaling overhead and / or transmission delay.

[0003] Summary of the Invention

[0004] This application provides a wireless communication method, terminal device, and network device. The various aspects covered by this application are described below.

[0005] In a first aspect, a wireless communication method is provided, comprising: a terminal device receiving a first downlink message in a first process, the first process being used by the terminal device in an RRC idle state to transmit first uplink data; the terminal device determining, based on the first downlink message, to terminate the first process or to receive a second downlink message, the second downlink message being used by the terminal device to determine to terminate the first process.

[0006] In a second aspect, a wireless communication method is provided, comprising: a network device sending a first downlink message to a terminal device, the first downlink message being sent after the terminal device initiates a first process, the first process being used by the terminal device in an RRC idle state to transmit first uplink data; wherein the first downlink message is used to instruct the terminal device to terminate the first process or receive a second downlink message, the second downlink message being used by the terminal device to determine to terminate the first process.

[0007] Thirdly, a terminal device is provided, comprising: a receiving module, configured to receive a first downlink message in a first process, the first process being used by the terminal device in an RRC idle state to transmit first uplink data; and a determining module, configured to determine, based on the first downlink message, to terminate the first process or receive a second downlink message, the second downlink message being used by the terminal device to determine to terminate the first process.

[0008] Fourthly, a network device is provided, comprising: a sending module, configured to send a first downlink message to a terminal device, the first downlink message being sent after the terminal device initiates a first process, the first process being used by the terminal device in an RRC idle state to transmit first uplink data; wherein, the first downlink message is used to instruct the terminal device to terminate the first process or receive a second downlink message, the second downlink message being used by the terminal device to determine to terminate the first process.

[0009] Fifthly, a terminal device is provided, including a processor, a memory, and a communication interface, wherein the memory is used to store one or more computer programs, and the processor is used to invoke the computer programs in the memory to cause the terminal device to perform some or all of the steps in the method of the first aspect.

[0010] In a sixth aspect, a network device is provided, including a processor, a memory, and a communication interface, wherein the memory is used to store one or more computer programs, and the processor is used to invoke the computer programs in the memory to cause the network device to perform some or all of the steps in the method of the second aspect.

[0011] Seventhly, embodiments of this application provide a communication system including the aforementioned terminal device and / or network device. In another possible design, the system may further include other devices that interact with the terminal device or network device as described in the embodiments of this application.

[0012] Eighthly, embodiments of this application provide a computer-readable storage medium storing a computer program that causes a computer to perform some or all of the steps in the methods described above.

[0013] Ninthly, embodiments of this application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of the methods described in the foregoing aspects. In some implementations, the computer program product may be a software installation package.

[0014] In a tenth aspect, embodiments of this application provide a chip including a memory and a processor, the processor being able to call and run a computer program from the memory to implement some or all of the steps described in the methods of the foregoing aspects.

[0015] In this embodiment of the application, the network device can instruct the terminal device to terminate the first process through a first downlink message or a second downlink message, thereby helping to save signaling overhead and / or reduce transmission latency. Attached Figure Description

[0016] Figure 1 is a system architecture example diagram of a wireless communication system applicable to embodiments of this application.

[0017] Figure 2A is a flowchart illustrating the four-step random access process.

[0018] Figure 2B is a flowchart illustrating the two-step random access process.

[0019] Figure 3 is a schematic diagram of the early data transmission process.

[0020] Figure 4 is a schematic diagram of the data transmission process based on pre-configured uplink resources.

[0021] Figure 5 is a flowchart illustrating the wireless communication method provided in an embodiment of this application.

[0022] Figure 6 is a schematic diagram of the structure of the terminal device provided in an embodiment of this application.

[0023] Figure 7 is a schematic diagram of the structure of the network device provided in an embodiment of this application.

[0024] Figure 8 is a schematic structural diagram of the communication device provided in an embodiment of this application. Detailed Implementation

[0025] Communication system architecture

[0026] Figure 1 is a system architecture example diagram of a wireless communication system 100 to which embodiments of this application can be applied. The wireless communication system 100 may include a network device 110 and a terminal device 120. The network device 110 may be a device that communicates with the terminal device 120. The network device 110 may provide communication coverage for a specific geographical area and may communicate with the terminal device 120 located within that coverage area.

[0027] Figure 1 illustrates an exemplary network device and two terminal devices. Optionally, the wireless communication system 100 may include multiple network devices, and each network device may include other numbers of terminal devices within its coverage area. This application embodiment does not limit this.

[0028] Optionally, the wireless communication system 100 may also include other network entities such as a network controller and a mobility management entity, which is not limited in this embodiment.

[0029] It should be understood that the technical solutions of the embodiments of this application can be applied to various communication systems, such as: 5th generation (5G) systems or new radio (NR), long term evolution (LTE) systems, LTE frequency division duplex (FDD) systems, LTE time division duplex (TDD) systems, etc. The technical solutions provided in this application can also be applied to future communication systems, such as 6th generation mobile communication systems, satellite communication systems, and so on.

[0030] The terminal device in this application embodiment can also be referred to as user equipment (UE), access terminal, user unit, user station, mobile station, mobile station (MS), mobile terminal (MT), remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent, or user device. The terminal device in this application embodiment can be a device that provides voice and / or data connectivity to a user, and can be used to connect people, objects, and machines, such as a handheld device with wireless connectivity, vehicle-mounted device, etc. The terminal devices in the embodiments of this application can be mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, self-driving, remote medical surgery, smart grids, transportation safety, smart cities, and smart homes, etc. Optionally, the UE can act as a base station. For example, the UE can act as a scheduling entity, providing sidelink signals between UEs in V2X or D2D, etc. For example, cellular phones and cars communicate with each other using sidelink signals. Cellular phones and smart home devices communicate without relaying communication signals through a base station.

[0031] The network device in this application embodiment can be a device for communicating with a terminal device. This network device can also be called an access network device or a wireless access network device, such as a base station. In this application embodiment, the network device can refer to a radio access network (RAN) node (or device) that connects the terminal device to the wireless network. A base station can broadly encompass, or be replaced by, various names including: NodeB, evolved NodeB (eNB), next-generation NodeB (gNB), relay station, transmitting and receiving point (TRP), transmitting point (TP), master MeNB, auxiliary SeNB, multi-mode radio (MSR) node, home base station, network controller, access node, wireless node, access point (AP), transmission node, transceiver node, baseband unit (BBU), remote radio unit (RRU), active antenna unit (AAU), remote radio head (RRH), central unit (CU), distributed unit (DU), positioning node, etc. A base station can be a macro base station, micro base station, relay node, donor node, or similar, or a combination thereof. A base station can also refer to a communication module, modem, or chip installed within the aforementioned equipment or apparatus. Base stations can also be mobile switching centers, devices that perform base station functions in device-to-device (D2D), vehicle-to-everything (V2X), and machine-to-machine (M2M) communications, network-side devices in 6G networks, and devices that perform base station functions in future communication systems. Base stations can support networks using the same or different access technologies. The embodiments of this application do not limit the specific technologies or device forms used in the network equipment.

[0032] Base stations can be fixed or mobile. For example, a helicopter or drone can be configured to act as a mobile base station, and one or more cells can move depending on the location of the mobile base station. In other examples, a helicopter or drone can be configured as a device to communicate with another base station.

[0033] In some deployments, the network device in this application embodiment may refer to a CU or a DU, or the network device may include both a CU and a DU. The gNB may also include an AAU.

[0034] Network devices and terminal devices can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; and they can also be deployed in the air on airplanes, balloons, and satellites. This application does not limit the scenario in which the network devices and terminal devices are located.

[0035] It should be understood that all or part of the functions of the communication device in this application can also be implemented by software functions running on hardware, or by virtualization functions instantiated on a platform (e.g., a cloud platform).

[0036] Random access (RA) process

[0037] The random access procedure is an essential process for terminal devices when initially connecting to network equipment. Random access can be divided into two types: contention-based random access (CBRA) and contention-free random access (CFRA). The following description uses an LTE network as an example to illustrate the random access procedure in detail.

[0038] In LTE, the random access procedure is primarily triggered by one or more of the following events: the establishment of a radio connection during initial access by the terminal device, such as the terminal device transitioning from the RRC idle state (RRC_IDLE state) to the RRC connected state (RRC_CONNECTED state); the RRC connection reconstruction process, to enable the terminal device to rebuild the radio connection after a radio link failure; cell handover, where the terminal device needs to establish uplink synchronization with the new cell; the arrival of downlink (DL) data in the RRC connected state, while the uplink (UL) is out of sync; the arrival of UL data in the RRC connected state, where the UL is out of sync or lacks PUCCH resources for sending a scheduling request (SR); SR failure; and a synchronization reconfiguration request from the RRC.

[0039] As shown in Figure 2A, the contention-based random access process may include the following steps:

[0040] In step S201: The terminal device sends message 1 (message1, Msg1) to the network device.

[0041] The terminal device can send Msg1 on the physical random access channel (PRACH), and Msg1 includes a random access preamble.

[0042] For example, the terminal device selects one preamble from 64 preset preambles and determines the random access resource to send the preamble. The terminal device then sends Msg1, which includes the preamble, to the base station on the determined random access resource.

[0043] Network devices can estimate uplink timing and the grant size required for terminal devices to transmit Msg3 based on preamble.

[0044] In step S202: The network device sends message 2 (Msg2) to the terminal device. Msg2 can be called a random access response (RAR).

[0045] After the terminal device sends Msg1, it opens a random access response time window (e.g., ra-ResponseWindow). Within this window, it monitors the physical downlink control channel (PDCCH) scrambled with the random access radio access network temporary identifier (RA-RNTI). In LTE, RA-RNTI is calculated as follows: RA-RNTI = 1 + t_id + 10 * f_id. Where t_id is the index of the first subframe of the PRACH transmission (0 ≤ t_id < 10), and f_id is the frequency domain index of the PRACH in that subframe (0 ≤ f_id < 6). PRACH resources are numbered sequentially in the frequency domain from low to high.

[0046] For enhanced machine-type communication (eMTC), the RA-RNTI is calculated as follows: RA-RNTI = 1 + t_id + 10 * f_id + 60 * (SFN_id mod (Wmax / 10)). Where t_id is the index of the first subframe of the PRACH transmission (0 ≤ t_id < 10), f_id is the frequency domain index of the corresponding PRACH in that subframe (0 ≤ f_id < 6), and PRACH resources are numbered sequentially in the frequency domain from low to high. SFN_id is the index of the first system frame number of the PRACH transmission, and Wmax is the maximum PRACH window length supported by eMTC, which is 400 subframes.

[0047] For Narrow Band Internet of Things (NB-IoT) UEs, the RA-RNTI is calculated as follows: RA-RNTI = 1 + floor(SFN_id / 4) + 256 * carrier_id. Where SFN_id is the index of the first system frame number in the PRACH transmission, and carrier_id is the UL carrier index corresponding to the PRACH transmission. The carrier_id corresponding to the anchor carrier is 0.

[0048] For NB-IoT UEs in Time Division Duplexing (TDD) mode, the RA-RNTI is calculated as follows: RA-RNTI = 1 + floor(SFN_id / 4) + 256 * (H-SFN mod 2). Where SFN_id is the index of the first system frame number in the PRACH transmission, and H-SFN is the first H-SFN in the PRACH transmission. As can be seen from the above formula, RA-RNTI is related to the PRACH time-frequency resources used by the UE to transmit Msg1.

[0049] After successfully receiving the RA-RNTI scrambled PDCCH, the terminal device can obtain the physical downlink shared channel (PDSCH) scheduled by the PDCCH, which contains the random access response (RAR). The RAR may contain multiple pieces of information. For example, the RAR subheader may contain a backoff indicator (BI), which can be used to indicate the backoff time for retransmitting Msg1; the RAR random access preamble identification (RAPID) indicates the index of the received preamble in response to the network device; the RAR payload may contain a timing advance group (TAG), which can be used to adjust uplink timing; the RAR may also include an uplink grant (UL grant), used to schedule uplink resources for MSG3; and the RAR may also include a cell-radio network temporary identifier (C-RNTI), which the terminal device can use to decode the PDCCH of Msg4 for initial access.

[0050] If the terminal receives a RA-RNTI scrambled PDCCH and the RAR contains the preamble index it sent, the terminal considers it to have successfully received the random access response.

[0051] In step S203: The terminal device sends message 3 (Msg3) to the network device. Msg3 can also be called scheduled transmission.

[0052] Msg3 is primarily used to inform the network what event triggered the PRACH procedure. For example, if it is an initial access random procedure, the Msg3 will carry the UE ID and establishment cause; if it is an RRC reconstruction, it will carry the connected state UE ID and establishment cause.

[0053] In step S204: The network device sends message 4 (Msg4) to the terminal device. This Msg4 can be called a contention resolution message.

[0054] Msg4 serves two purposes: contention resolution and transmission of RRC configuration messages from network devices to terminal devices. Contention resolution occurs in two ways: First, if the terminal device carries a C-RNTI in Msg3, Msg4 uses a PDCCH scrambled with the C-RNTI for scheduling. Second, if the terminal device does not carry a C-RNTI in Msg3 (e.g., during initial access), Msg4 uses a PDCCH scrambled with the temporary cell-radio network temporary identifier (C-RNTI) for scheduling. In this case, the terminal device receives the PDSCH from Msg4 and matches it with the CCCH SDU within the PDSCH.

[0055] As shown in Figure 2B, the process of non-contention-based random access may include the following steps:

[0056] In step S211: The network device sends random access preamble assignment information (RA preamble assignment) to the terminal device.

[0057] In step S212: The terminal device sends a random access preamble to the network device. This corresponds to step S201 in Figure 2A above, and will not be described in detail here.

[0058] It should be noted that, based on non-contention-based random access, PRACH resources and preamble can be specified by the network device.

[0059] In step S213: The network device sends a random access response to the terminal device. This corresponds to step S202 in Figure 2A above, and will not be described in detail here.

[0060] For non-contention-based random access, the random access process ends after the terminal successfully receives Msg2. For contention-based random access, after successfully receiving Msg2, the terminal still needs to transmit Msg3 and receive Msg4.

[0061] As can be seen from the above random access process, the main purpose of random access is for the terminal device to achieve uplink synchronization with the cell. During the random access process, the network device can know the time when the terminal device sends the preamble based on the PRACH time-frequency resources used to receive the preamble from the terminal device. Therefore, based on the transmission and reception times of the preamble, the network device can determine the initial timing advance (TA) of the terminal and inform the terminal device through the RAR.

[0062] Early data transmission (EDT)

[0063] In traditional LTE systems, if a terminal device in the RRC idle state needs to transmit uplink data, it must first initiate an RRC connection establishment process through a random access procedure. Only after establishing an RRC connection with the network can it transmit data. To reduce signaling interactions between the terminal device and the network caused by data transmission and to save power consumption, the 3rd generation partnership project (3GPP) introduced the EDT mechanism in Release 15 for Narrow-Band Internet of Things (NB-IoT) and enhanced Machine-Type Communication (eMTC). This feature allows a terminal device in the RRC idle state to transmit uplink data through Msg3 during the random access procedure. Upon receiving a successful reception response from the base station, the random access procedure terminates, and the terminal device remains in the RRC idle state without entering the RRC connected state. The base station configures a separate narrowband physical random access channel (NPRACH) resource for EDT. When the amount of uplink data to be transmitted by the terminal device does not exceed the upper limit of the data volume configured by the network, the terminal device can send Msg1 on the separate NPRACH resource of EDT to request Msg3 authorization for EDT from the base station.

[0064] Taking the user plane transmission scheme as an example, the data transmission process of EDT is shown in Figure 3, which includes the following steps:

[0065] In step S301, the terminal device (UE) sends a random access preamble to the base station (eNB).

[0066] In step S302, the eNB sends a Random Access Response to the UE.

[0067] In step S303, the UE sends an RRC contention resume request to the eNB.

[0068] The RRC connection recovery request carries the recovery ID, recovery case, authentication token (shortResumeMAC-I), and uplink data.

[0069] In step S304, the eNB sends a UE context resume request to the Mobility Management Entity (MME).

[0070] In step S305, the bearer between the MME and the Serving Gateway (S-GW) is modified.

[0071] In step S306, the MME sends a context resume response to the UE.

[0072] In step S307, the UE sends uplink data to the S-GW.

[0073] In step S308, the S-GW sends downlink data to the base station.

[0074] In step S309, the eNB and MME perform a suspension process, and the bearer between the MME and S-GW is modified.

[0075] In step S310, the eNB sends an RRC contention release notification to the UE.

[0076] The RRC Connection Release includes the release case, resume ID, next-hop chaining count (NCC), and downlink data.

[0077] During EDT (Electronic Data Transfer) based on control plane transmission, the terminal device needs to receive downlink RRC feedback messages (such as RRC EarlyDataComplete messages) and determine whether to terminate the EDT process based on the received downlink RRC feedback messages. Furthermore, since EDT is based on a random access procedure, the terminal device also needs to receive a MAC CE (Contentment Resolution Identity) with a Contention Resolution Identity (CRID).

[0078] In some embodiments, a MAC CE carrying a CRID and an RRC feedback message (such as an RRCEarlyDataComplete message) can be multiplexed in the same transport block (TB). However, this application embodiment is not limited to this. For example, a MAC CE carrying a CRID and an RRC feedback message (such as an RRCEarlyDataComplete message) can be in different TBs. It should be noted that when a MAC CE carrying a CRID and an RRC feedback message (such as an RRCEarlyDataComplete message) are multiplexed in one TB, since one message is a MAC CE and the other is an RRC message, this application still treats them as two separate messages.

[0079] Preconfigured uplink resources (PUR)

[0080] To further reduce signaling overhead and terminal power consumption on top of EDT, 3GPP introduced the PUR feature in Release 16 for NB-IoT and eMTC. This feature allows the base station to configure PUR resources for the terminal device while releasing it to the RRC idle state. The terminal device can then use these PUR resources for uplink transmission in the RRC idle state without initiating a random access procedure. By skipping the random access procedure, uplink transmission efficiency can be further improved and terminal power consumption can be further reduced.

[0081] Figure 4 shows a schematic diagram of the PUR process. As shown in Figure 4, PUR may include the following steps:

[0082] In step S401, the terminal device determines that a valid PUR resource exists.

[0083] In step S402, the terminal device sends an RRC early data request (such as RRC EarlyDataRequest) to the network device.

[0084] In some embodiments, the RRC early data request may include the identifier of the terminal device, the establishment cause, and dedicated NAS information (such as dedicatedInfoNAS). The identifier of the terminal device carried in the RRC early data request may include a 5G-S-temporary mobile subscriber identity (5G-S-TMSI).

[0085] In steps S403 to S407, the MO-EDT procedure for control plane CIoT EPS / 5GS optimization is performed.

[0086] In step S408, the network device sends downlink feedback to the terminal device to indicate whether the uplink transmission has been successfully received by the network device.

[0087] In other words, after performing uplink data transmission, the terminal device needs to determine whether the uplink transmission has been successfully received by the network by receiving downlink feedback from the network side, and use this as the condition for ending the PUR process. Similar to the EDT process, the downlink feedback can be an RRC message (see step S408a), i.e., RRC connection release RRCConnectionRelease / RRCEearlyDataComplete. In addition, to improve the transmission efficiency of downlink feedback messages, for control plane transmission schemes, PUR also supports using L1 / L2 signaling as downlink feedback messages (see steps S408a / S408b).

[0088] In step S408a, the network device may send a Layer 1 feedback, such as a Layer 1 acknowledgment (ACK), to the terminal device. This Layer 1 ACK may carry a TA adjustment amount.

[0089] In step S408b, the network device may send Layer 2 feedback, such as a MAC CE, to the terminal device. The MAC CE may carry TA adjustment values.

[0090] In step S408c, the network device may send an RRC message, such as an RRC Early Data Complete message, to the terminal device. This RRC message may carry dedicated NAS information (such as dedicatedInfoNAS) and TA adjustment values.

[0091] In step S409, the network side releases the S1 interface / access network (AN).

[0092] To reduce uplink and downlink signaling overhead and improve system uplink capacity, Release 19 IoT NTN plans to further enhance EDT features. For example, EDT features can be enhanced in the following three aspects: First, instead of transmitting Msg1 / RAR, directly transmit Msg3; second, efficiently transmit msg4 / RRCEarlyDataComplete; and third, study and classify radio resource management (RRM) requirements.

[0093] It can be seen that future communication systems may support efficient msg4 / RRCEarlyDataComplete transmission to reduce signaling overhead. Therefore, how to achieve efficient transmission by terminal devices in the RRC idle state to reduce signaling overhead is a problem that needs to be solved.

[0094] To address the aforementioned issues, embodiments of this application propose that a network device can instruct a terminal device to terminate the first process via a first downlink message or a second downlink message, thereby helping to save signaling overhead and / or reduce transmission latency.

[0095] The method embodiments of this application are described below.

[0096] Figure 5 is a schematic flowchart of a wireless communication method provided in an embodiment of this application. The method shown in Figure 5 is described from the perspective of interaction between a terminal device and a network device. The terminal device and the network device can be, for example, the terminal device 120 and the network device 110 shown in Figure 1, respectively. The method shown in Figure 5 may include steps S510 and S520, which will be described below.

[0097] In step S510, the terminal device receives a first downlink message during the first process. For example, during the first process, the network device may send the first downlink message to the terminal device.

[0098] In some embodiments, the first procedure can be used by a terminal device in an RRC idle state to transmit first uplink data. For example, the first procedure can be used by a terminal device in an RRC idle state to transmit first uplink data using a random access procedure. As another example, the first procedure can be used by a terminal device in an RRC idle state to transmit first uplink data using a second procedure. This second procedure can, for example, be a random access procedure that does not include Msg1 and / or Msg2.

[0099] In some embodiments, the first process may include an EDT process. However, the embodiments of this application are not limited to this, as long as the first process is used for a terminal device in an RRC idle state to transmit first uplink data. For example, the first process may also include a PUR process or a process that is the same as or similar to the EDT process in future communication systems.

[0100] This application does not limit the first uplink data, which can be of any type. It is acceptable as long as the first uplink data is transmitted by a terminal device in the RRC idle state. For example, the first uplink data may include user plane data, such as data from an application or service. As another example, the first uplink data may include NAS messages, which may include control information such as authentication requests and registration requests.

[0101] In step S520, the terminal device determines whether to terminate (or end) the first process or receive the second downlink message based on the first downlink message. In other words, the first downlink message can be used to determine (or indicate) whether to terminate the first process or continue receiving the second downlink message.

[0102] As an example, the terminal device can determine whether to terminate (or need to terminate) the first process based on the first downlink message. Taking the first process as an EDT process as an example, the terminal device can determine to terminate the EDT process based on the first downlink message.

[0103] As another example, the terminal device can determine whether to receive (or continue receiving) a second downlink message based on the first downlink message. Taking the first process as an EDT process as an example, the terminal device can determine the second downlink message (such as receiving an RRC Early Data Completion message) based on the first downlink message.

[0104] In some embodiments, the second downlink message can be used by the terminal device to determine to terminate the first process. For example, the second downlink message can be used to instruct the terminal device to terminate the first process.

[0105] In some embodiments, the second downlink message may explicitly instruct the terminal device to terminate the first process. As one possible implementation, the second downlink message may include explicit instruction information used to instruct the terminal device to terminate the first process.

[0106] In some embodiments, the second downlink message may implicitly instruct the terminal device to terminate the first process. As one possible implementation, the second downlink message may be used to indicate that the first uplink data was successfully received. In this case, the terminal device may determine to terminate the first process based on the second downlink message.

[0107] However, the embodiments of this application are not limited to this. For example, the second downlink message can be used to indicate that the first uplink data has been successfully received and to indicate the termination of the first process.

[0108] As an example, a second downlink message can be used to indicate that the first uplink data was successfully received.

[0109] As another example, a second downlink message can be used to indicate the termination of the first process.

[0110] As yet another example, a second downlink message can be used to indicate that the first uplink data has been successfully received and to terminate the first process.

[0111] In some embodiments, the second downlink message is used to indicate that, in the event that the first uplink data has been successfully received, the terminal device can terminate the first process based on the second downlink message. This is because, if the first uplink data has been successfully received, the terminal device will assume that there is no more uplink data to be transmitted in the first process, and therefore, the terminal device can terminate the first process.

[0112] In some embodiments, the second downlink message may also be understood or referred to as a downlink feedback message, a downlink ACK message, etc. Taking the first process as an EDT process as an example, the second downlink message can be used to indicate that the first uplink data carried in Msg3 has been successfully received and / or to indicate the termination of the EDT process.

[0113] This application does not limit the implementation method of the second downlink message indicating that the first uplink data has been successfully received and / or indicating the termination of the first process. As one possible implementation, the second downlink message may explicitly indicate that the first uplink data has been successfully received and / or indicate the termination of the first process. For example, the second downlink message may include one or more indication messages, which can be used to indicate whether the first uplink data has been successfully received and / or whether the first process has been terminated. As another possible implementation, the second downlink message may implicitly indicate that the first uplink data has been successfully received and / or indicate the termination of the first process. For example, the message type of the second downlink message may be used to indicate that the first uplink data has been successfully received and / or the first process has been terminated. That is, as long as the network device sends a second downlink message to the terminal device, it means that the first uplink data has been successfully received and / or that the terminal device needs to terminate the first process.

[0114] This application does not limit the carrying method of the second downlink message in its embodiments. Exemplarily, the second downlink message can be carried as one or more of the following: RRC message, MAC CE, downlink control information (DCI). Alternatively, the second downlink message can be a Layer 1 / Layer 2 message (or signaling), or it can be an RRC message.

[0115] In some embodiments, the second downlink message can be an RRC message. For example, the second downlink message can be an RRC early data completion message (such as an RRC EarlyDataComplete message). For a more detailed explanation of RRC early data completion messages, please refer to the above text.

[0116] In some embodiments, the second downlink message can be a MAC CE, that is, the second downlink message can be a Layer 2 message. For example, the second downlink message can be a MAC CE indicating that the first uplink data has been successfully received. As another example, the second downlink message can be a MAC CE indicating the termination of the first process.

[0117] In some embodiments, the second downlink message can be a DCI, that is, the second downlink message can be a Layer 1 message. For example, the second downlink message can be a DCI indicating that the first uplink data has been successfully received. As another example, the second downlink message can be a DCI indicating the termination of the first process.

[0118] Schemes where the second downlink message is a Layer 1 message and / or a Layer 2 message are beneficial for improving the transmission efficiency of the second downlink message and reducing transmission latency.

[0119] In some embodiments, the second downlink message may carry downlink data. That is, for a terminal device in RRC idle state, while the network device indicates to the terminal device whether the first uplink data has been successfully received, it may also carry downlink data to be sent to the terminal device in the second downlink message. Taking an RRC message as an example, the network device may carry downlink data in the second downlink message.

[0120] Of course, the embodiments of this application are not limited to this, and the second downlink message may not carry downlink data. For example, if the network device determines that there is no downlink data to be sent to the terminal device, the network device may omit downlink data in the second downlink message. In some embodiments, when the second downlink message does not carry downlink data, the second downlink message may be a MAC CE or DCI to improve the transmission efficiency of the second downlink message and reduce transmission latency.

[0121] This application embodiment does not limit the downlink data carried in the second downlink message, which can be of any type. For example, the downlink data carried in the second downlink message may include user plane data, such as data from an application or service. As another example, the downlink data carried in the second downlink message may include downlink control information, etc.

[0122] In this embodiment, the first downlink message can be used by the terminal device to determine whether to terminate the first process or continue receiving the second downlink message. Compared to the traditional EDT scheme, where the terminal device needs to receive the MAC CE carrying the CRID and the second downlink message regardless of the circumstances, this embodiment is beneficial for the network device to determine whether it needs to continue sending the second downlink message and / or for the terminal device to determine whether it needs to continue receiving the second downlink message, thereby saving signaling overhead.

[0123] As mentioned above, the terminal device can determine whether to terminate the first process or receive the second downlink message based on the first downlink message. The following section introduces the first downlink message and how the terminal device determines whether to terminate the first process or receive the second downlink message based on the first downlink message.

[0124] In some embodiments, compared to the traditional EDT process where network devices need to send two messages—a Contention Conflict Resolution Indication (MAC CE message) and an Early Data Completion Indication (RRC message)—the embodiments of this application only require sending a single message, the first downlink message, thereby saving signaling overhead. For example, if the network device can determine whether there will be subsequent downlink data transmission, the network device can send only the first downlink message.

[0125] In some embodiments, compared to the traditional EDT process where network devices need to send two messages—a Contention Conflict Resolution Indication (MAC CE message) and an Early Data Completion Indication (RRC message)—the embodiments of this application require sending two messages: a first downlink message and a second downlink message. However, in the embodiments of this application, the first downlink message and the second downlink message can be Layer 1 / Layer 2 messages, which helps to improve transmission efficiency and reduce transmission latency. For example, when the network device is uncertain whether there will be subsequent downlink data transmission, the network device can send a first downlink message and a second downlink message, and the second downlink message can be a Layer 1 / Layer 2 message.

[0126] In some embodiments, if the network device can determine that there is no downlink data transmission during the first timer operation, the network device only needs to send a first downlink message to the terminal device. The first downlink message may include, for example, a first contention resolution identifier and first indication information, or the first downlink message may include second indication information.

[0127] In some embodiments, if the network device is able to determine that there is downlink data transmission during the first timer operation, the network device may send a MAC CE carrying CRID and an RRC early data completion message carrying downlink data in the manner of the current NR system.

[0128] In some embodiments, if the network device cannot determine whether there is downlink data transmission during the first timer operation, the network device may send a first downlink message and a second downlink message to the terminal device. The first downlink message may include, for example, a first contention resolution identifier, and the second downlink message may be, for example, a layer 1 / layer 2 message.

[0129] In some embodiments, the start time of the first timer can be determined based on the transmission time of the first uplink message. Further details regarding the first uplink message will be provided later and will not be elaborated upon here.

[0130] In some embodiments, the first timer can be used for race condition resolution. For example, during the operation of the first timer, the terminal device can listen for Msg4 messages sent by the network device or messages with the same or similar functionality to Msg4 in a future communication system.

[0131] In some embodiments, the first timer may include a contention resolution timer (CRT) timer.

[0132] It should be noted that the embodiments of this application are not limited to this. For example, if the network device cannot determine whether there is downlink data transmission during the first timer operation, the network device may send a first downlink message and a second downlink message to the terminal device. The first downlink message may include, for example, a first contention resolution identifier and a first indication information, and the second downlink message may be, for example, a layer 1 / layer 2 message.

[0133] To facilitate understanding, the following section provides a detailed explanation of how the terminal device determines whether to terminate the first process or receive the second downlink message based on the first downlink message.

[0134] Implementation method 1: The first downlink message includes a contention resolution identifier.

[0135] In some embodiments, the first downlink message may include one or more of the following: a first contention resolution identifier, and a first indication message.

[0136] The aforementioned first contention resolution identifier can be used for contention conflict resolution. For example, the first contention resolution identifier is used to resolve conflicts arising from multiple terminal devices selecting the same preamble during contention-based random access procedures. In other words, during random access procedures, if multiple terminal devices select the same preamble, the first contention resolution identifier can be used to determine which terminal device successfully accesses the network.

[0137] In some embodiments, the first contention resolution identifier may include a CRID.

[0138] The aforementioned first indication information can be used to instruct the terminal device to terminate the first process or receive the second downlink message. This application does not limit the implementation method of the first indication information instructing the terminal device to terminate the first process or receive the second downlink message. As one possible implementation, the first indication information can be explicit. As another possible implementation, the first indication information can be implicit.

[0139] Taking an explicit indication as an example, the first indication may include a first value and / or a second value. The first value may be used to instruct the terminal device to terminate the first process. The second value may be used to instruct the terminal device to receive the second downlink message.

[0140] This application does not limit the number of bits occupied by the first indication information in its embodiments. As one possible implementation, the first indication information may occupy one bit. In this case, when the value of the first indication information is a first value (e.g., 1 or 0), it instructs the terminal device to terminate the first process; when the value of the first indication information is a second value (e.g., 0 or 1), it instructs the terminal device to receive the second downlink message. As another possible implementation, the first indication information may occupy multiple bits. In this case, when the value of the first indication information is a first value (e.g., "Terminate First Process" or "Terminate," etc.), it instructs the terminal device to terminate the first process; when the value of the first indication information is a second value (e.g., "RRC Early Completion Message" or "Receive ACK," etc.), it instructs the terminal device to receive the second downlink message.

[0141] Taking the first indication information as an implicit indication information as an example, the first indication information can be the aforementioned first contention resolution identifier. For example, when the first downlink message contains the first contention resolution identifier, it means that the terminal device needs to receive the second downlink message; otherwise, the terminal device does not need to receive the second downlink message.

[0142] In some embodiments, the first downlink message may include a first contention resolution identifier.

[0143] In some embodiments, the first downlink message may include a first contention resolution identifier and first indication information.

[0144] In some embodiments, if the first downlink message includes a first contention resolution identifier but does not include first indication information, the terminal device determines that it will receive the second downlink message.

[0145] In some embodiments, if the network device cannot determine whether there is still downlink data to be transmitted before the first timer expires, the first downlink message sent by the network device to the terminal device may include a first contention resolution identifier but not the first indication information. In this case, the terminal device determines to receive the second downlink message.

[0146] In some embodiments, if the first downlink message includes a first contention resolution identifier and first indication information, the terminal device can determine whether to terminate the first process or receive the second downlink message based on the first indication information.

[0147] In some embodiments, if the network device determines that no downlink data needs to be transmitted before the first timer expires, the first downlink message sent by the network device to the terminal device may include a first contention resolution identifier and first indication information. For example, if the network device determines that no downlink data needs to be transmitted within a subsequent period (when this period arrives, the first timer may have expired), the network device may indicate termination of the first process through the first indication information. As another example, if the network device determines that downlink data needs to be transmitted within a subsequent period (when this period arrives, the first timer may have expired), the network device may indicate receipt of a second downlink message through the first indication information. In other words, if the network device determines that no downlink data needs to be transmitted before the first timer expires, but downlink data needs to be transmitted within a short period after the first timer expires, the network device may indicate receipt of a second downlink message through the first indication information.

[0148] In some embodiments, if the network device determines that there is still downlink data to be sent before the first timer expires, the network device can complete the reception of downlink data according to the current EDT procedure.

[0149] For more information about the first timer, please refer to the above text; it will not be repeated here.

[0150] In some embodiments, if the terminal device determines that it has received a second downlink message, the terminal device may continue to receive second downlink messages thereafter. For example, the terminal device may receive a second downlink message that is a Layer 1 or Layer 2 message to reduce transmission latency.

[0151] To facilitate understanding, two specific examples of implementation method 1 are given below.

[0152] Example 1: If the network device can determine whether there is still downlink data to be transmitted before the first timer expires, then if the network device determines that there is no downlink data to be transmitted before the first timer expires, the network device can send only the first downlink message to the terminal device, and the first downlink message includes a first contention resolution identifier and a first indication information.

[0153] Example 2: If the network device cannot determine whether there is still downlink data to be transmitted before the first timer expires, the network device can send a first downlink message and a second downlink message to the terminal device. The first downlink message may include a first contention resolution identifier. The second downlink message may be a Layer 1 / Layer 2 message (such as a Layer 1 ACK message).

[0154] Implementation Method 2: The first downlink message does not include a contention resolution flag.

[0155] In some embodiments, the first downlink message may include second indication information. This second indication information can be used to indicate that the first uplink data was successfully received and / or to terminate the first process. Therefore, in some embodiments, the second indication information may also be understood or referred to as a downlink feedback indication, downlink ACK indication, etc.

[0156] As an example, the second indication information can be used to indicate that the first uplink data was successfully received.

[0157] As another example, the second instruction information can be used to indicate the termination of the first process.

[0158] As yet another example, the second indication information can be used to indicate that the first uplink data has been successfully received and to terminate the first process.

[0159] In some embodiments, the second indication information is used to indicate that, in the event that the first uplink data has been successfully received, the terminal device, upon receiving the first downlink message, can terminate the first process based on the second indication information in the first downlink message. This is because, if the first uplink data has been successfully received, the terminal device will assume that there is no more uplink data to be transmitted in the first process; therefore, the terminal device can terminate the first process.

[0160] This application does not limit the implementation method of the second indication information indicating that the first uplink data has been successfully received and / or indicating the termination of the first process. As one possible implementation, the second indication information can be explicit; for example, the first downlink message may include one bit used to indicate whether the first uplink data has been successfully received and / or whether the first process has been terminated. As another possible implementation, the second indication information can be implicit; for example, the second indication information may include the message type of the first downlink message, that is, the message type of the first downlink message can be used to indicate that the first uplink data has been successfully received and / or the first process has been terminated. In other words, as long as the network device sends the first downlink message to the terminal device, it means that the first uplink data has been successfully received and / or that the terminal device needs to terminate the first process.

[0161] In some embodiments, if the network device determines that no downlink data needs to be transmitted before the first timer expires, the first downlink message sent by the network device to the terminal device may include second indication information. For example, if the network device determines that no downlink data needs to be transmitted before the first timer expires, the network device sends a first downlink message to the terminal device, which is a Layer 1 ACK message. This Layer 1 ACK message can be used to indicate that the first uplink data has been successfully received and / or to terminate the first process.

[0162] In some embodiments, if the network device determines that there is still downlink data to be sent before the first timer expires, the network device can complete the reception of downlink data according to the current EDT procedure.

[0163] It should be noted that the relevant introduction to the first timer can be found above, and will not be repeated here.

[0164] To facilitate understanding, a specific example of implementation method 2 is given below.

[0165] Example 3: If the network device can determine whether there is still downlink data to be transmitted before the first timer expires, and if the network device determines that there is no downlink data to be transmitted before the first timer expires, the network device can send only a first downlink message to the terminal device, and the first downlink message includes second indication information. For example, the network device sends a first downlink message to the terminal device, which is a Layer 1 ACK message, to indicate that the first uplink data was successfully received and / or the first process was terminated.

[0166] The first downlink message is described below.

[0167] In some embodiments, the first downlink message is a message that the terminal device listens for during the execution of a first timer.

[0168] This application does not limit the carrying method of the first downlink message in its embodiments. Exemplarily, the first downlink message may be carried in one or more of the following: RRC message, MAC CE, DCI.

[0169] As an example, the first downlink message can be an RRC message. For instance, the first downlink message is an RRC message that includes a first contention resolution identifier and / or first indication information.

[0170] As another example, the first downlink message can be a MAC CE, meaning the first downlink message can be a Layer 2 message. For example, the first downlink message is a MAC CE, and the first downlink message includes a first contention resolution identifier and / or first indication information.

[0171] As another example, the first downlink message can be a DCI, meaning it can be a Layer 1 message. For instance, the first downlink message could be a DCI, and it could include second indication information. As another possible implementation, the first downlink message could be a Layer 1 ACK message.

[0172] The scheme of having the first downlink message as a Layer 1 / Layer 2 message is beneficial to improving the transmission efficiency of the first downlink message and reducing transmission latency.

[0173] The scheduling of the first downlink message and / or the second downlink message is described below.

[0174] In some embodiments, the first downlink message may be scheduled based on one of the following: TC-RNTI, first RNTI, second RNTI.

[0175] For example, in implementation method 1 above, the first downlink message can be scheduled based on TC-RNTI or the first RNTI.

[0176] For example, in implementation method 2 above, the first downlink message can be scheduled based on the second RNTI.

[0177] In some embodiments, the terminal device may determine the scheduling method of the first downlink message based on one or more of the following: whether a second RNTI exists, and whether the second RNTI is valid.

[0178] In some embodiments, the scheduling of the first downlink message satisfies one or more of the following: if a second RNTI exists, the first downlink message is scheduled based on the second RNTI; if a second RNTI does not exist, the first downlink message is scheduled based on TC-RNTI or the first RNTI; if the second RNTI is valid, the first downlink message is scheduled based on the second RNTI; if the second RNTI is invalid, the first downlink message is scheduled based on TC-RNTI or the first RNTI.

[0179] As one possible implementation, if a second RNTI exists, the first downlink message can be scheduled based on the second RNTI; if a second RNTI does not exist, the first downlink message can be scheduled based on either the TC-RNTI or the first RNTI.

[0180] As another possible implementation, if the second RNTI is valid, the first downlink message can be scheduled based on the second RNTI; if the second RNTI is invalid, the first downlink message can be scheduled based on either the TC-RNTI or the first RNTI.

[0181] As another possible implementation, if a second RNTI exists and is valid, the first downlink message can be scheduled based on the second RNTI; if a second RNTI exists but is invalid, or if no second RNTI exists, the first downlink message can be scheduled based on either the TC-RNTI or the first RNTI.

[0182] For example, in implementation method 1 above, if a second RNTI exists, the first downlink message can be scheduled based on the second RNTI; if a second RNTI does not exist, the first downlink message can be scheduled based on either the TC-RNTI or the first RNTI. As another example, in implementation method 1 above, if the second RNTI is valid, the first downlink message can be scheduled based on the second RNTI; if the second RNTI is invalid, the first downlink message can be scheduled based on either the TC-RNTI or the first RNTI. As yet another example, in implementation method 1 above, if both the second RNTI and the second RNTI are valid, the first downlink message can be scheduled based on the second RNTI; if the second RNTI exists but is invalid, or if the second RNTI does not exist, the first downlink message can be scheduled based on either the TC-RNTI or the first RNTI.

[0183] For example, in implementation method 2 above, if a second RNTI exists, the first downlink message can be scheduled based on the second RNTI; if a second RNTI does not exist, the first downlink message can be scheduled based on either the TC-RNTI or the first RNTI. For example, in implementation method 2 above, if the second RNTI is valid, the first downlink message can be scheduled based on the second RNTI; if the second RNTI is invalid, the first downlink message can be scheduled based on either the TC-RNTI or the first RNTI. For example, in implementation method 2 above, if a second RNTI exists and is valid, the first downlink message can be scheduled based on the second RNTI; if a second RNTI exists but is invalid, or if a second RNTI does not exist, the first downlink message can be scheduled based on either the TC-RNTI or the first RNTI.

[0184] In some embodiments, the terminal device may determine the scheduling method of the second downlink message based on one or more of the following: whether a second RNTI exists, and whether the second RNTI is valid.

[0185] In some embodiments, the scheduling of the second downlink message satisfies one or more of the following: if a second RNTI exists, the second downlink message is scheduled based on the second RNTI; if a second RNTI does not exist, the second downlink message is scheduled based on TC-RNTI or the first RNTI; if the second RNTI is valid, the second downlink message is scheduled based on the second RNTI; if the second RNTI is invalid, the second downlink message is scheduled based on TC-RNTI or the first RNTI.

[0186] As one possible implementation, if a second RNTI exists, the second downlink message can be scheduled based on the second RNTI; if a second RNTI does not exist, the second downlink message can be scheduled based on either the TC-RNTI or the first RNTI.

[0187] As another possible implementation, if the second RNTI is valid, the second downlink message can be scheduled based on the second RNTI; if the second RNTI is invalid, the second downlink message can be scheduled based on either the TC-RNTI or the first RNTI.

[0188] As another possible implementation, if a second RNTI exists and is valid, the second downlink message can be scheduled based on the second RNTI; if a second RNTI exists but is invalid, or if no second RNTI exists, the second downlink message can be scheduled based on the TC-RNTI or the first RNTI.

[0189] For example, in implementation method 1 above, if a second RNTI exists, the second downlink message can be scheduled based on the second RNTI; if a second RNTI does not exist, the second downlink message can be scheduled based on either the TC-RNTI or the first RNTI. As another example, in implementation method 1 above, if the second RNTI is valid, the second downlink message can be scheduled based on the second RNTI; if the second RNTI is invalid, the second downlink message can be scheduled based on either the TC-RNTI or the first RNTI. As yet another example, in implementation method 1 above, if both the second RNTI and the second RNTI are valid, the second downlink message can be scheduled based on the second RNTI; if the second RNTI exists but is invalid, or if the second RNTI does not exist, the second downlink message can be scheduled based on either the TC-RNTI or the first RNTI.

[0190] This application does not limit the implementation method for determining whether the second RNTI is valid. In some embodiments, the implementation methods for determining whether the second RNTI is valid may differ depending on the method of generating the second RNTI.

[0191] As one possible implementation, in the case where the second RNTI is configured based on an RRC message (such as an RRC connection release message, or RRC release message) sent by the first cell, the second RNTI is valid if the terminal device initiates the first procedure in the first cell; and / or, the second RNTI is invalid if the terminal device initiates the first procedure in the second cell. In other words, if the terminal device initiates the first procedure in the cell where it received the RRC message used to configure the second RNTI, the second RNTI is valid; otherwise, the second RNTI is invalid.

[0192] As another possible implementation, in the case where the second RNTI is associated with the PUR (e.g., the second RNTI is PUR-RNTI), the second RNTI is valid if the PUR exists; and / or the second RNTI is invalid if the PUR is released.

[0193] In some embodiments, the second downlink message may be scheduled based on one of the following: TC-RNTI, first RNTI, second RNTI.

[0194] For example, in implementation method 1 above, the second downlink message can be based on the second RNTI. Of course, in implementation method 1 above, the second downlink message can also be scheduled via TC-RNTI or the first RNTI.

[0195] For example, in implementation method 2 above, the second downlink message can be based on the second RNTI. Of course, in implementation method 2 above, the second downlink message can also be scheduled via TC-RNTI or the first RNTI.

[0196] In some embodiments, the first RNTI described above is a common RNTI. For example, the first RNTI can be an RA-RNTI.

[0197] In some embodiments, the first RNTI can be determined based on resource information of the first uplink resource. For example, the first RNTI can be determined based on one or more of the time domain information, frequency domain information, and code domain information of the first uplink resource.

[0198] In some embodiments, the first RNTI can be determined based on one of the resource information described above. As an example, the first RNTI can be determined based on the time-domain information of the first uplink resource. As another example, the first RNTI can be determined based on the frequency-domain information of the first uplink resource. As yet another example, the first RNTI can be determined based on the code-domain information of the first uplink resource.

[0199] In some embodiments, the first RNTI can be determined based on multiple aspects of the resource information described above. As an example, the first RNTI can be determined based on the time-domain and frequency-domain information of the first uplink resource. As another example, the first RNTI can be determined based on the time-domain and code-domain information of the first uplink resource. As yet another example, the first RNTI can be determined based on the frequency-domain and code-domain information of the first uplink resource. As yet another example, the first RNTI can be determined based on the time-domain, frequency-domain, and code-domain information of the first uplink resource.

[0200] As one possible implementation, the determination of the first RNTI based on one or more of the time domain information, frequency domain information, and code domain information of the first uplink resource can be understood as the first RNTI being calculated based on one or more of the time domain information, frequency domain information, and code domain information of the first uplink resource.

[0201] In some embodiments, the first RNTI can be determined based on resource information of the first uplink resource if the random access procedure can send Msg3 directly without sending Msg1 and / or Msg2.

[0202] In some embodiments, the first uplink resource is used to carry the first uplink message, and the first uplink message is used to carry the first uplink data. Further details regarding the first uplink resource and the first uplink message can be found later and will not be elaborated here.

[0203] In some embodiments, the second RNTI is a terminal device-specific RNTI (i.e., UE-specific RNTI).

[0204] In some embodiments, the second RNTI can be the cell RNTI (i.e., C-RNTI).

[0205] In some embodiments, the second RNTI can be an RNTI associated with a pre-configured uplink resource (i.e., a PUR), meaning the second RNTI can be a PUR-RNTI. In other words, the second RNTI can reuse the RNTI associated with the PUR. As an example, in implementation 1 above, the second RNTI can be an RNTI associated with the PUR. As another example, in implementation 2 above, the second RNTI can be an RNTI associated with the PUR.

[0206] In some embodiments, the second RNTI can be the RNTI carried in the RRC message. As an example, in implementation 1 above, the second RNTI can be the RNTI carried in the RRC message. As another example, in implementation 2 above, the second RNTI can be the RNTI carried in the RRC message.

[0207] In some embodiments, the second RNTI is the RNTI carried in the RRC message, and the second RNTI is the RNTI associated with the PUR.

[0208] In some embodiments, the second RNTI is the RNTI carried in the RRC message, but the second RNTI is different from the RNTI associated with the PUR. Alternatively, the second RNTI is the RNTI carried in the RRC message, but the second RNTI is independent of the RNTI associated with the PUR.

[0209] In some embodiments, the RRC message carrying the second RNTI may include an RRC release message. That is, the network device can configure the second RNTI for the terminal device in the RRC release message.

[0210] In some embodiments, the second RNTI can be the RNTI carried in the first downlink message. That is, the network device can configure the second RNTI for the terminal device in the first downlink message, so that when the network device subsequently sends a second downlink message, the second downlink message can be scheduled through the second RNTI. For example, in implementation 1 above, the network device can configure the second RNTI for the terminal device in the first downlink message, and then the network device can schedule the second downlink message through the second RNTI.

[0211] In some embodiments, if the second RNTI is the RNTI carried in the first downlink message, the message format corresponding to the first downlink message may need to be modified; that is, a new message format may be required to carry the second RNTI in the first downlink message. Taking a MAC CE as an example, a new MAC CE format may be required to carry the second RNTI in the first downlink message.

[0212] In some embodiments, the second RNTI can be an RNTI determined based on the TC-RNTI. For example, the TC-RNTI can be converted into the second RNTI after the race condition is resolved.

[0213] In some embodiments, the aforementioned TC-RNTI may be configured by the network device for the terminal device. For example, the network device may configure the TC-RNTI for the terminal device during the random access procedure. For example, the network device may configure the TC-RNTI for the terminal device in Msg2 or RAR during the random access procedure. That is, in some embodiments, the TC-RNTI may be carried in Msg2 or RAR during the random access procedure.

[0214] In some embodiments, after conflict resolution, TC-RNTI can be converted to C-RNTI and used to schedule subsequent downlink messages (such as a second downlink message).

[0215] For further information on TC-RNTI, please refer to the relevant technical documentation; for the sake of brevity, it will not be elaborated upon here.

[0216] Referring again to Figure 5, in some embodiments, the method shown in Figure 5 may further include step S505 before step S510.

[0217] In step S505, the terminal device sends a first uplink message, such as sending a first uplink message to the network device.

[0218] In some embodiments, the first uplink message is used to carry first uplink data. For details regarding the first uplink data, please refer to the above text; it will not be repeated here.

[0219] In some embodiments, the first uplink message includes an RRC message. For example, the first uplink message may include an RRC Early Data Request (RRCE) message.

[0220] In some embodiments, the first uplink message is a message sent during a random access procedure. For example, the first uplink message may be carried within Msg3 or a message in a future communication system that has the same or similar function as Msg3.

[0221] In some embodiments, after sending a first uplink message, the terminal device may receive a first downlink message to determine whether to terminate the first process or receive a second downlink message. As one possible implementation, after sending the first uplink message, the terminal device may receive a first downlink message scheduled via a first RNTI, the first downlink message including a first contention resolution identifier and first indication information, thereby determining to terminate the first process. As another possible implementation, after sending the first uplink message, the terminal device may receive a first downlink message scheduled via a first RNTI, the first downlink message including second indication information (e.g., the first downlink message is a Layer 1 ACK message), thereby determining to terminate the first process. As yet another possible implementation, after sending the first uplink message, the terminal device may first receive a first downlink message scheduled via a first RNTI, the first downlink message including a first contention resolution identifier, and then receive a second downlink message scheduled via a second RNTI (e.g., the second downlink message is a Layer 1 ACK message), thereby determining to terminate the first process.

[0222] In some embodiments, the first uplink message may be carried on a first uplink resource. That is, the terminal device can utilize the first uplink resource to transmit the first uplink message. The first uplink resource is described below.

[0223] In some embodiments, the first uplink resource may be scheduled based on Msg2 or RAR during the random access procedure.

[0224] In some embodiments, the first uplink resource may be selected by the terminal device from a first uplink resource pool. For example, in a random access procedure, if Msg3 is sent directly without sending Msg1 and / or Msg2, the first uplink resource may be selected by the terminal device from a first uplink resource pool.

[0225] As one possible implementation, the terminal device can randomly select an occasion from the first uplink resource pool as the first uplink resource.

[0226] As another possible implementation, the terminal device can select a time from the first uplink resource pool as the first uplink resource based on certain rules or conditions. For example, the terminal device can select a time from the first uplink resource pool as the first uplink resource based on the terminal device's identifier.

[0227] In some embodiments, the first uplink resource pool described above may be determined based on a first condition. The first condition may be related to one or more of the following: the coverage enhancement level corresponding to the terminal device, and a first set of basic parameters used by the terminal device. Alternatively, the first uplink resource pool may be determined based on one or more of the following: the coverage enhancement level corresponding to the terminal device (i.e., the coverage enhancement level at which the terminal device is located), and a first set of basic parameters used by the terminal device.

[0228] As an example, the first uplink resource pool can be determined based on the coverage enhancement level corresponding to the terminal device. In other words, the first uplink resource pool can be determined based on the coverage enhancement level corresponding to the terminal device.

[0229] As another example, the first uplink resource pool can be determined based on a first set of basic parameters used by the terminal device. In other words, the terminal device can determine the first uplink resource pool based on the first set of basic parameters used by the terminal device.

[0230] As another example, the first uplink resource pool can be determined based on the coverage enhancement level corresponding to the terminal device and the first set of basic parameters used by the terminal device. In other words, the terminal device can determine the first uplink resource pool based on the coverage enhancement level corresponding to the terminal device and the first set of basic parameters used by the terminal device.

[0231] As one possible implementation, the terminal device can determine the coverage enhancement level corresponding to the terminal device, for example, determining that the coverage enhancement level corresponding to the terminal device is the first coverage enhancement level. Then, the terminal device can determine that the resources corresponding to the first coverage enhancement level for the transmission of the first uplink message are the first uplink resource pool.

[0232] In some embodiments, if the coverage enhancement level (such as the first coverage enhancement level) corresponding to the terminal device corresponds to multiple carriers, and a first uplink resource pool exists on each of the multiple carriers, then the terminal device can first select a carrier and then determine the first uplink resource pool on the selected carrier as the first uplink resource pool.

[0233] As one possible implementation, the terminal device can determine a first set of basic parameters used by the terminal device, and then the terminal device can determine the resources corresponding to the first set of basic parameters for the transmission of the first uplink message as the first uplink resource pool.

[0234] In some embodiments, the first basic parameter set can be used to define the physical layer characteristics of the terminal device. For example, the first basic parameter set may include a numberology in an NR system or a set of parameters in a future communication system that has the same or similar functions as a numberology.

[0235] This application does not limit the content of the first basic parameter set. For example, the first basic parameter set may include one or more of the following: subcarrier spacing, symbol length, cyclic prefix length, etc.

[0236] This application does not limit the method for determining the first basic parameter set. For example, the first basic parameter set may be determined based on one or more of the following: the capabilities of the terminal device, the signal quality of the terminal device, and the number of attempts by the terminal device to transmit the first uplink message based on the second uplink resources. The second uplink resources correspond to the second basic parameter set.

[0237] As an example, the first set of basic parameters can be determined based on the capabilities of the terminal device (such as its capability level). For instance, if the network device configures both an uplink resource pool with a subcarrier spacing of 3.75 kHz and an uplink resource pool with a subcarrier spacing of 15 kHz for the terminal device, the terminal device will select the uplink resource pool with a subcarrier spacing of 15 kHz as the first uplink resource pool if its capability level is greater than a threshold; otherwise, it will select the uplink resource pool with a subcarrier spacing of 3.75 kHz as the first uplink resource pool.

[0238] As another example, the first set of basic parameters can be determined based on the signal quality of the terminal device. For instance, the network device configures both an uplink resource pool with a subcarrier spacing of 3.75 kHz and an uplink resource pool with a subcarrier spacing of 15 kHz for the terminal device. When the signal quality of the terminal device is greater than a threshold, the terminal device selects the uplink resource pool with a subcarrier spacing of 15 kHz as the first uplink resource pool; otherwise, the terminal device selects the uplink resource pool with a subcarrier spacing of 3.75 kHz as the first uplink resource pool.

[0239] As another example, the first basic parameter set can be determined based on the number of attempts made by the terminal device to transmit the first uplink message using the second uplink resource. For instance, the network device configures an uplink resource pool corresponding to a first basic parameter set (e.g., a subcarrier spacing of 3.75kHz) and an uplink resource pool corresponding to a second basic parameter set (e.g., a subcarrier spacing of 15kHz) for the terminal device. The terminal device initially selects the uplink resource pool corresponding to the second basic parameter set as the first uplink resource pool. When the number of attempts made by the terminal device to transmit the first uplink message using the uplink resource pool corresponding to the second basic parameter set reaches a certain number, the terminal device can select the uplink resource pool corresponding to the first basic parameter set as the first uplink resource pool for the next transmission of the first uplink message. In other words, embodiments of this application can support a fallback mechanism between different basic parameter sets.

[0240] As yet another example, the first set of basic parameters can be determined based on the capabilities of the terminal device and the signal quality of the terminal device.

[0241] As yet another example, the first set of basic parameters can be determined based on the capabilities of the terminal device and the number of attempts made by the terminal device to transmit the first uplink message based on the second uplink resources.

[0242] As yet another example, the first set of basic parameters can be determined based on the signal quality of the terminal device and the number of attempts made by the terminal device to transmit the first uplink message based on the second uplink resource.

[0243] As yet another example, the first set of basic parameters can be determined based on the capabilities of the terminal device, the signal quality of the terminal device, and the number of attempts by the terminal device to transmit the first uplink message based on the second uplink resource.

[0244] This application does not limit the measurement quantity corresponding to the signal quality of the terminal device. For example, the measurement quantity corresponding to the signal quality of the terminal device may include one or more of the following: reference signal received power (RSRP), reference signal received quality (RSRQ), and signal-to-interference plus noise ratio (SINR).

[0245] In some embodiments, the first basic resource set and the second basic resource set contain the same content, only with different values. For example, both the first basic resource set and the second basic resource set include subcarrier spacing, but the values ​​of the subcarrier spacing are different.

[0246] This application does not limit the resources in the first uplink resource pool, as long as they can be used for uplink transmission. For example, in some embodiments, the resources in the first uplink resource pool can be NPRACH resources. In some embodiments, the resources in the first uplink resource pool can be narrowband physical uplink shared channel (NPUSCH) resources.

[0247] The method embodiments of this application have been described in detail above with reference to Figures 1 to 5. The apparatus embodiments of this application will be described in detail below with reference to Figures 6 to 8. It should be understood that the descriptions of the method embodiments correspond to the descriptions of the apparatus embodiments; therefore, any parts not described in detail can be referred to the preceding method embodiments.

[0248] Figure 6 is a schematic diagram of the structure of a terminal device provided in an embodiment of this application. The terminal device 600 shown in Figure 6 may include a receiving module 610 and a determining module 620. The receiving module 610 can be used to receive a first downlink message in a first process, which is used for the terminal device in an RRC idle state to transmit first uplink data. The determining module 620 can be used to determine, based on the first downlink message, to terminate the first process or receive a second downlink message, which is used by the terminal device to determine to terminate the first process.

[0249] In some embodiments, the first downlink message includes one or more of the following: a first contention resolution identifier; and a first indication information for instructing the terminal device to terminate the first process or receive the second downlink message.

[0250] In some embodiments, the first indication information includes one or more of the following: a first value, used to instruct the terminal device to terminate the first process; and a second value, used to instruct the terminal device to receive the second downlink message.

[0251] In some embodiments, the first indication information occupies 1 bit.

[0252] In some embodiments, the first downlink message is scheduled based on TC-RNTI or a first RNTI, where the first RNTI is a common RNTI.

[0253] In some embodiments, the first downlink message includes second indication information, which is used to indicate that the first uplink data was successfully received and / or to terminate the first process.

[0254] In some embodiments, the first downlink message is scheduled based on a second RNTI, where the second RNTI is a terminal device-specific RNTI.

[0255] In some embodiments, the scheduling of the first downlink message satisfies one or more of the following: if the second RNTI exists, the first downlink message is scheduled based on the second RNTI; if the second RNTI does not exist, the first downlink message is scheduled based on TC-RNTI or the first RNTI; if the second RNTI is valid, the first downlink message is scheduled based on the second RNTI; if the second RNTI is invalid, the first downlink message is scheduled based on TC-RNTI or the first RNTI; wherein the first RNTI is a common RNTI.

[0256] In some embodiments, if the terminal device initiates the first process in the first cell, the second RNTI is valid; and / or, if the terminal device initiates the first process in the second cell, the second RNTI is invalid; wherein, the second RNTI is an RNTI configured based on the RRC connection release message sent by the first cell.

[0257] In some embodiments, the second RNTI is valid if a pre-configured uplink resource exists; and / or the second RNTI is invalid if the pre-configured uplink resource is released; wherein the second RNTI is associated with the pre-configured uplink resource.

[0258] In some embodiments, the first downlink message is a MAC CE, DCI, or RRC message; and / or, the second downlink message is a MAC CE, DCI, or RRC message.

[0259] In some embodiments, the first downlink message is scheduled based on TC-RNTI, a first RNTI, or a second RNTI; and / or, the second downlink message is scheduled based on TC-RNTI, a first RNTI, or a second RNTI; wherein the first RNTI is a public RNTI, and the second RNTI is a terminal device-specific RNTI.

[0260] In some embodiments, the TC-RNTI is carried in message two or the random access response message during the random access process.

[0261] In some embodiments, the first RNTI is determined based on one or more of the time domain information, frequency domain information, and code domain information of the first uplink resource, wherein the first uplink resource is used to carry the first uplink message, and the first uplink message is used to carry the first uplink data.

[0262] In some embodiments, the second RNTI is a cell RNTI or an RNTI associated with pre-configured uplink resources; or, the second RNTI is an RNTI carried in an RRC message, an RNTI carried in the first downlink message, or an RNTI determined based on the TC-RNTI.

[0263] In some embodiments, the terminal device further includes: a sending module, configured to send a first uplink message, the first uplink message being used to carry the first uplink data.

[0264] In some embodiments, the first uplink message is carried on a first uplink resource, which is scheduled based on message 2 or random access response message during the random access process.

[0265] In some embodiments, the first uplink message is carried on a first uplink resource, which is selected by the terminal device from a first uplink resource pool.

[0266] In some embodiments, the first uplink resource pool is determined based on one or more of the following: the coverage enhancement level corresponding to the terminal device; and the first set of basic parameters used by the terminal device.

[0267] In some embodiments, the first basic parameter set is determined based on one or more of the following: the capability of the terminal device; the signal quality of the terminal device; the number of attempts by the terminal device to transmit the first uplink message based on a second uplink resource, wherein the second uplink resource corresponds to the second basic parameter set.

[0268] In some embodiments, the resources in the first uplink resource pool are NPRACH resources or NPUSCH resources.

[0269] In some embodiments, the first downlink message is a message listened to by the terminal device during the operation of a first timer, and the start time of the first timer is determined based on the sending time of the first uplink message.

[0270] In some embodiments, the first process includes an early data transmission process.

[0271] In some embodiments, the receiving module 610 may be a transceiver 830, and the determining module 620 may be a processor 810. The terminal device 600 may also include a memory 820, as shown in FIG8.

[0272] Figure 7 is a schematic diagram of the network device provided in an embodiment of this application. The network device 700 shown in Figure 7 may include a sending module 710. The sending module 710 can be used to send a first downlink message to a terminal device. The first downlink message is sent after the terminal device initiates a first process, which is used for the terminal device in an RRC idle state to transmit first uplink data. The first downlink message is used to instruct the terminal device to terminate the first process or receive a second downlink message, which is used for the terminal device to determine to terminate the first process.

[0273] In some embodiments, the first downlink message includes one or more of the following: a first contention resolution identifier; and a first indication information for instructing the terminal device to terminate the first process or receive the second downlink message.

[0274] In some embodiments, the first indication information includes one or more of the following: a first value, used to instruct the terminal device to terminate the first process; and a second value, used to instruct the terminal device to receive the second downlink message.

[0275] In some embodiments, the first indication information occupies 1 bit.

[0276] In some embodiments, the first downlink message is scheduled based on TC-RNTI or a first RNTI, where the first RNTI is a common RNTI.

[0277] In some embodiments, the first downlink message includes second indication information, which is used to indicate that the first uplink data was successfully received and / or to terminate the first process.

[0278] In some embodiments, the first downlink message is scheduled based on a second RNTI, where the second RNTI is a terminal device-specific RNTI.

[0279] In some embodiments, the scheduling of the first downlink message satisfies one or more of the following: if the second RNTI exists, the first downlink message is scheduled based on the second RNTI; if the second RNTI does not exist, the first downlink message is scheduled based on TC-RNTI or the first RNTI; if the second RNTI is valid, the first downlink message is scheduled based on the second RNTI; if the second RNTI is invalid, the first downlink message is scheduled based on TC-RNTI or the first RNTI; wherein the first RNTI is a common RNTI.

[0280] In some embodiments, if the terminal device initiates the first process in the first cell, the second RNTI is valid; and / or, if the terminal device initiates the first process in the second cell, the second RNTI is invalid; wherein, the second RNTI is an RNTI configured based on the RRC connection release message sent by the first cell.

[0281] In some embodiments, the second RNTI is valid if a pre-configured uplink resource exists; and / or the second RNTI is invalid if the pre-configured uplink resource is released; wherein the second RNTI is associated with the pre-configured uplink resource.

[0282] In some embodiments, the first downlink message is a MAC CE, DCI, or RRC message; and / or, the second downlink message is a MAC CE, DCI, or RRC message.

[0283] In some embodiments, the first downlink message is scheduled based on TC-RNTI, a first RNTI, or a second RNTI; and / or, the second downlink message is scheduled based on TC-RNTI, a first RNTI, or a second RNTI; wherein the first RNTI is a public RNTI, and the second RNTI is a terminal device-specific RNTI.

[0284] In some embodiments, the TC-RNTI is carried in message two or the random access response message during the random access process.

[0285] In some embodiments, the first RNTI is determined based on one or more of the time domain information, frequency domain information, and code domain information of the first uplink resource, wherein the first uplink resource is used to carry the first uplink message, and the first uplink message is used to carry the first uplink data.

[0286] In some embodiments, the second RNTI is a cell RNTI or an RNTI associated with pre-configured uplink resources; or, the second RNTI is an RNTI carried in an RRC message, an RNTI carried in the first downlink message, or an RNTI determined based on the TC-RNTI.

[0287] In some embodiments, the network device further includes a receiving module 720, configured to receive a first uplink message sent by the terminal device, the first uplink message being used to carry the first uplink data.

[0288] In some embodiments, the first uplink message is carried on a first uplink resource, which is scheduled based on message 2 or random access response message during the random access process.

[0289] In some embodiments, the first uplink message is carried on a first uplink resource, which is selected by the terminal device from a first uplink resource pool.

[0290] In some embodiments, the first uplink resource pool is determined based on one or more of the following: the coverage enhancement level corresponding to the terminal device; and the first set of basic parameters used by the terminal device.

[0291] In some embodiments, the first basic parameter set is determined based on one or more of the following: the capability of the terminal device; the signal quality of the terminal device; the number of attempts by the terminal device to transmit the first uplink message based on a second uplink resource, wherein the second uplink resource corresponds to the second basic parameter set.

[0292] In some embodiments, the resources in the first uplink resource pool are NPRACH resources or NPUSCH resources.

[0293] In some embodiments, the first downlink message is a message listened to by the terminal device during the operation of a first timer, and the start time of the first timer is determined based on the sending time of the first uplink message.

[0294] In some embodiments, the first process includes an early data transmission process.

[0295] In some embodiments, the transmitting module 710 may be a transceiver 830. The network device 700 may also include a processor 810 and a memory 820, as shown in FIG8.

[0296] Figure 8 is a schematic structural diagram of a communication device according to an embodiment of this application. The dashed lines in Figure 8 indicate that the unit or module is optional. This device 800 can be used to implement the methods described in the above method embodiments. Device 800 can be a chip, a terminal device, or a network device.

[0297] The apparatus 800 may include one or more processors 810. The processor 810 may support the apparatus 800 in implementing the methods described in the preceding method embodiments. The processor 810 may be a general-purpose processor or a special-purpose processor. For example, the processor may be a central processing unit (CPU). Alternatively, the processor may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0298] The apparatus 800 may further include one or more memories 820. The memories 820 store a program that can be executed by the processor 810, causing the processor 810 to perform the methods described in the preceding method embodiments. The memories 820 may be independent of the processor 810 or integrated within the processor 810.

[0299] The device 800 may also include a transceiver 830. The processor 810 can communicate with other devices or chips via the transceiver 830. For example, the processor 810 can send and receive data with other devices or chips via the transceiver 830.

[0300] This application also provides a computer-readable storage medium for storing a program. This computer-readable storage medium can be applied to a terminal device or network device provided in this application embodiment, and the program causes a computer to execute the methods performed by the terminal device or network device in the various embodiments of this application.

[0301] This application also provides a computer program product. The computer program product includes a program. This computer program product can be applied to a terminal device or network device provided in the embodiments of this application, and the program causes a computer to execute the methods performed by the terminal device or network device in the various embodiments of this application.

[0302] This application also provides a computer program. This computer program can be applied to the terminal device or network device provided in this application, and the computer program causes the computer to execute the methods performed by the terminal device or network device in various embodiments of this application.

[0303] It should be understood that the terms "system" and "network" in this application can be used interchangeably. Furthermore, the terminology used in this application is only for explaining specific embodiments of the application and is not intended to limit the application. The terms "first," "second," "third," and "fourth," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. In addition, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0304] In the embodiments of this application, the term "instruction" can be a direct instruction, an indirect instruction, or an indication of a relationship. For example, A instructing B can mean that A directly instructs B, such as B being able to obtain information through A; it can also mean that A indirectly instructs B, such as A instructing C, so B can obtain information through C; or it can mean that there is a relationship between A and B.

[0305] In the embodiments of this application, "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0306] In the embodiments of this application, the term "correspondence" can indicate a direct or indirect correspondence between two things, or an association between two things, or a relationship such as instruction and being instructed, configuration and being configured.

[0307] In the embodiments of this application, the term "comprising" can refer to direct inclusion or indirect inclusion. Optionally, "comprising" in the embodiments of this application can be replaced with "instructing" or "used to determine". For example, "A includes B" can be replaced with "A instructs B" or "A is used to determine B".

[0308] In this application embodiment, "predefined" or "preconfigured" can be implemented by pre-storing corresponding codes, tables, or other means that can be used to indicate relevant information in the device (e.g., including terminal devices and network devices). This application does not limit the specific implementation method. For example, predefined can refer to what is defined in the protocol.

[0309] In this application embodiment, the "protocol" may refer to a standard protocol in the field of communication, such as the LTE protocol, the NR protocol, and related protocols applied to future communication systems. This application does not limit this.

[0310] In the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0311] In the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0312] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0313] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0314] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0315] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can read or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs, DVDs) or semiconductor media (e.g., solid-state disks, SSDs), etc.

[0316] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for wireless communication, characterized in that, include: In the first process, the terminal device receives a first downlink message, and the first process is used for the terminal device in the Radio Resource Control (RRC) idle state to transmit first uplink data; The terminal device determines to terminate the first process or receive a second downlink message based on the first downlink message, wherein the second downlink message is used by the terminal device to determine to terminate the first process.

2. The method according to claim 1, characterized in that, The first downlink message includes one or more of the following: First competition resolution identifier; The first instruction information is used to instruct the terminal device to terminate the first process or receive the second downlink message.

3. The method according to claim 2, characterized in that, The first indication information includes one or more of the following: A first value is used to instruct the terminal device to terminate the first process; The second value is used to instruct the terminal device to receive the second downlink message.

4. The method according to claim 3, characterized in that, The first indication information occupies 1 bit.

5. The method according to any one of claims 2-4, characterized in that, The first downlink message is scheduled based on the Temporary Cell Radio Network Temporary Identifier (TC-RNTI) or the first RNTI, where the first RNTI is a public RNTI.

6. The method according to claim 1, characterized in that, The first downlink message includes second indication information, which is used to indicate that the first uplink data was successfully received and / or to terminate the first process.

7. The method according to claim 6, characterized in that, The first downlink message is scheduled based on the second RNTI, which is a dedicated RNTI for the terminal device.

8. The method according to claim 6 or 7, characterized in that, The scheduling of the first downlink message satisfies one or more of the following: If the second RNTI exists, the first downlink message is scheduled based on the second RNTI; If the second RNTI does not exist, the first downlink message is scheduled based on either the TC-RNTI or the first RNTI; If the second RNTI is valid, the first downlink message is scheduled based on the second RNTI; If the second RNTI is invalid, the first downlink message is scheduled based on either the TC-RNTI or the first RNTI; Wherein, the first RNTI is a public RNTI.

9. The method according to claim 8, characterized in that: If the terminal device initiates the first procedure in the first cell, then the second RNTI is valid; and / or, If the terminal device initiates the first process in the second cell, then the second RNTI is invalid; The second RNTI is an RNTI configured based on the RRC connection release message sent by the first cell.

10. The method according to claim 8, characterized in that: If pre-configured uplink resources exist, the second RNTI is valid; and / or, If the pre-configured uplink resources are released, the second RNTI becomes invalid; The second RNTI is associated with the pre-configured uplink resource.

11. The method according to any one of claims 1-10, characterized in that: The first downlink message is a Media Access Control Unit (MAC CE), a Downlink Control Information (DCI) or RRC message; and / or, The second downlink message is a MAC CE, DCI, or RRC message.

12. The method according to any one of claims 1-4, 6 and 11, characterized in that: The first downlink message is scheduled based on TC-RNTI, the first RNTI, or the second RNTI; and / or, The second downlink message is scheduled based on TC-RNTI, the first RNTI, or the second RNTI; Wherein, the first RNTI is a public RNTI, and the second RNTI is a terminal device-specific RNTI.

13. The method according to claim 12, characterized in that, The TC-RNTI is carried in message two or the random access response message during the random access process.

14. The method according to claim 12 or 13, characterized in that, The first RNTI is determined based on one or more of the time domain information, frequency domain information, and code domain information of the first uplink resource, wherein the first uplink resource is used to carry the first uplink message, and the first uplink message is used to carry the first uplink data.

15. The method according to any one of claims 12-14, characterized in that: The second RNTI is the cell RNTI or an RNTI associated with pre-configured uplink resources; or, The second RNTI is the RNTI carried in the RRC message, the RNTI carried in the first downlink message, or the RNTI determined based on the TC-RNTI.

16. The method according to any one of claims 1-15, characterized in that, Before the terminal device receives the first downlink message in the first process, the method further includes: The terminal device sends a first uplink message, which carries the first uplink data.

17. The method according to claim 16, characterized in that, The first uplink message is carried on the first uplink resource, which is scheduled based on message 2 or random access response message during the random access process.

18. The method according to claim 16, characterized in that, The first uplink message is carried on a first uplink resource, which is selected by the terminal device from a first uplink resource pool.

19. The method according to claim 18, characterized in that, The first uplink resource pool is determined based on one or more of the following: The coverage enhancement level corresponding to the terminal device; The terminal device uses the first set of basic parameters.

20. The method according to claim 19, characterized in that, The first set of basic parameters is determined based on one or more of the following: The capabilities of the terminal device; The signal quality of the terminal device; The number of attempts by the terminal device to transmit the first uplink message based on the second uplink resource, wherein the second uplink resource corresponds to the second basic parameter set.

21. The method according to any one of claims 18-20, characterized in that, The resources in the first uplink resource pool are narrowband physical random access channel (NPRACH) resources or narrowband physical uplink shared channel (NPUSCH) resources.

22. The method according to any one of claims 16-21, characterized in that, The first downlink message is a message that the terminal device listens to during the operation of the first timer, and the start time of the first timer is determined based on the sending time of the first uplink message.

23. The method according to any one of claims 1-22, characterized in that, The first process includes an early data transmission process.

24. A method for wireless communication, characterized in that, include: The network device sends a first downlink message to the terminal device. The first downlink message is sent after the terminal device initiates a first procedure. The first procedure is used for the terminal device, which is in the Radio Resource Control (RRC) idle state, to transmit first uplink data. The first downlink message is used to instruct the terminal device to terminate the first process or receive a second downlink message, wherein the second downlink message is used by the terminal device to determine to terminate the first process.

25. The method according to claim 24, characterized in that, The first downlink message includes one or more of the following: First competition resolution identifier; The first instruction information is used to instruct the terminal device to terminate the first process or receive the second downlink message.

26. The method according to claim 25, characterized in that, The first indication information includes one or more of the following: A first value is used to instruct the terminal device to terminate the first process; The second value is used to instruct the terminal device to receive the second downlink message.

27. The method according to claim 26, characterized in that, The first indication information occupies 1 bit.

28. The method according to any one of claims 25-27, characterized in that, The first downlink message is scheduled based on the Temporary Cell Radio Network Temporary Identifier (TC-RNTI) or the first RNTI, where the first RNTI is a public RNTI.

29. The method according to claim 24, characterized in that, The first downlink message includes second indication information, which is used to indicate that the first uplink data was successfully received and / or to terminate the first process.

30. The method according to claim 29, characterized in that, The first downlink message is scheduled based on the second RNTI, which is a dedicated RNTI for the terminal device.

31. The method according to claim 29 or 30, characterized in that, The scheduling of the first downlink message satisfies one or more of the following: If the second RNTI exists, the first downlink message is scheduled based on the second RNTI; If the second RNTI does not exist, the first downlink message is scheduled based on either the TC-RNTI or the first RNTI; If the second RNTI is valid, the first downlink message is scheduled based on the second RNTI; If the second RNTI is invalid, the first downlink message is scheduled based on either the TC-RNTI or the first RNTI; Wherein, the first RNTI is a public RNTI.

32. The method according to claim 31, characterized in that: If the terminal device initiates the first procedure in the first cell, then the second RNTI is valid; and / or, If the terminal device initiates the first process in the second cell, then the second RNTI is invalid; The second RNTI is an RNTI configured based on the RRC connection release message sent by the first cell.

33. The method according to claim 31, characterized in that: If pre-configured uplink resources exist, the second RNTI is valid; and / or, If the pre-configured uplink resources are released, the second RNTI becomes invalid; The second RNTI is associated with the pre-configured uplink resource.

34. The method according to any one of claims 24-33, characterized in that: The first downlink message is a Media Access Control Unit (MAC CE), a Downlink Control Information (DCI) or RRC message; and / or, The second downlink message is a MAC CE, DCI, or RRC message.

35. The method according to any one of claims 24-27, 29 and 34, characterized in that: The first downlink message is scheduled based on TC-RNTI, the first RNTI, or the second RNTI; and / or, The second downlink message is scheduled based on TC-RNTI, the first RNTI, or the second RNTI; Wherein, the first RNTI is a public RNTI, and the second RNTI is a terminal device-specific RNTI.

36. The method according to claim 35, characterized in that, The TC-RNTI is carried in message two or the random access response message during the random access process.

37. The method according to claim 35 or 36, characterized in that, The first RNTI is determined based on one or more of the time domain information, frequency domain information, and code domain information of the first uplink resource, wherein the first uplink resource is used to carry the first uplink message, and the first uplink message is used to carry the first uplink data.

38. The method according to any one of claims 35-37, characterized in that: The second RNTI is the cell RNTI or an RNTI associated with pre-configured uplink resources; or, The second RNTI is the RNTI carried in the RRC message, the RNTI carried in the first downlink message, or the RNTI determined based on the TC-RNTI.

39. The method according to any one of claims 24-38, characterized in that, Before the network device sends the first downlink message to the terminal device, the method further includes: The network device receives a first uplink message sent by the terminal device, the first uplink message being used to carry the first uplink data.

40. The method according to claim 39, characterized in that, The first uplink message is carried on the first uplink resource, which is scheduled based on message 2 or random access response message during the random access process.

41. The method according to claim 39, characterized in that, The first uplink message is carried on a first uplink resource, which is selected by the terminal device from a first uplink resource pool.

42. The method according to claim 41, characterized in that, The first uplink resource pool is determined based on one or more of the following: The coverage enhancement level corresponding to the terminal device; The terminal device uses the first set of basic parameters.

43. The method according to claim 42, characterized in that, The first set of basic parameters is determined based on one or more of the following: The capabilities of the terminal device; The signal quality of the terminal device; The number of attempts by the terminal device to transmit the first uplink message based on the second uplink resource, wherein the second uplink resource corresponds to the second basic parameter set.

44. The method according to any one of claims 41-43, characterized in that, The resources in the first uplink resource pool are narrowband physical random access channel (NPRACH) resources or narrowband physical uplink shared channel (NPUSCH) resources.

45. The method according to any one of claims 39-44, characterized in that, The first downlink message is a message that the terminal device listens to during the operation of the first timer, and the start time of the first timer is determined based on the sending time of the first uplink message.

46. ​​The method according to any one of claims 24-45, characterized in that, The first process includes an early data transmission process.

47. A terminal device, characterized in that, include: The receiving module is configured to receive a first downlink message in a first process, wherein the first process is used for the terminal device in the Radio Resource Control (RRC) idle state to transmit first uplink data; The determining module is configured to determine, based on the first downlink message, to terminate the first process or to receive a second downlink message, wherein the second downlink message is used by the terminal device to determine to terminate the first process.

48. The terminal device according to claim 47, characterized in that, The first downlink message includes one or more of the following: First competition resolution identifier; The first instruction information is used to instruct the terminal device to terminate the first process or receive the second downlink message.

49. The terminal device according to claim 48, characterized in that, The first indication information includes one or more of the following: A first value is used to instruct the terminal device to terminate the first process; The second value is used to instruct the terminal device to receive the second downlink message.

50. The terminal device according to claim 49, characterized in that, The first indication information occupies 1 bit.

51. The terminal device according to any one of claims 48-50, characterized in that, The first downlink message is scheduled based on the Temporary Cell Radio Network Temporary Identifier (TC-RNTI) or the first RNTI, where the first RNTI is a public RNTI.

52. The terminal device according to claim 47, characterized in that, The first downlink message includes second indication information, which is used to indicate that the first uplink data was successfully received and / or to terminate the first process.

53. The terminal device according to claim 52, characterized in that, The first downlink message is scheduled based on the second RNTI, which is a dedicated RNTI for the terminal device.

54. The terminal device according to claim 52 or 53, characterized in that, The scheduling of the first downlink message satisfies one or more of the following: If the second RNTI exists, the first downlink message is scheduled based on the second RNTI; If the second RNTI does not exist, the first downlink message is scheduled based on either the TC-RNTI or the first RNTI; If the second RNTI is valid, the first downlink message is scheduled based on the second RNTI; If the second RNTI is invalid, the first downlink message is scheduled based on either the TC-RNTI or the first RNTI; Wherein, the first RNTI is a public RNTI.

55. The terminal device according to claim 54, characterized in that: If the terminal device initiates the first procedure in the first cell, then the second RNTI is valid; and / or, If the terminal device initiates the first process in the second cell, then the second RNTI is invalid; The second RNTI is an RNTI configured based on the RRC connection release message sent by the first cell.

56. The terminal device according to claim 54, characterized in that: If pre-configured uplink resources exist, the second RNTI is valid; and / or, If the pre-configured uplink resources are released, the second RNTI becomes invalid; The second RNTI is associated with the pre-configured uplink resource.

57. The terminal device according to any one of claims 47-56, characterized in that: The first downlink message is a Media Access Control Unit (MAC CE), a Downlink Control Information (DCI) or RRC message; and / or, The second downlink message is a MAC CE, DCI, or RRC message.

58. The terminal device according to any one of claims 47-50, 52 and 57, characterized in that: The first downlink message is scheduled based on TC-RNTI, the first RNTI, or the second RNTI; and / or, The second downlink message is scheduled based on TC-RNTI, the first RNTI, or the second RNTI; Wherein, the first RNTI is a public RNTI, and the second RNTI is a terminal device-specific RNTI.

59. The terminal device according to claim 58, characterized in that, The TC-RNTI is carried in message two or the random access response message during the random access process.

60. The terminal device according to claim 58 or 59, characterized in that, The first RNTI is determined based on one or more of the time domain information, frequency domain information, and code domain information of the first uplink resource, wherein the first uplink resource is used to carry the first uplink message, and the first uplink message is used to carry the first uplink data.

61. The terminal device according to any one of claims 58-60, characterized in that: The second RNTI is the cell RNTI or an RNTI associated with pre-configured uplink resources; or, The second RNTI is the RNTI carried in the RRC message, the RNTI carried in the first downlink message, or the RNTI determined based on the TC-RNTI.

62. The terminal device according to any one of claims 47-61, characterized in that, The terminal device also includes: The sending module is used to send a first uplink message, which carries the first uplink data.

63. The terminal device according to claim 62, characterized in that, The first uplink message is carried on the first uplink resource, which is scheduled based on message 2 or random access response message during the random access process.

64. The terminal device according to claim 62, characterized in that, The first uplink message is carried on a first uplink resource, which is selected by the terminal device from a first uplink resource pool.

65. The terminal device according to claim 64, characterized in that, The first uplink resource pool is determined based on one or more of the following: The coverage enhancement level corresponding to the terminal device; The terminal device uses the first set of basic parameters.

66. The terminal device according to claim 65, characterized in that, The first set of basic parameters is determined based on one or more of the following: The capabilities of the terminal device; The signal quality of the terminal device; The number of attempts by the terminal device to transmit the first uplink message based on the second uplink resource, wherein the second uplink resource corresponds to the second basic parameter set.

67. The terminal device according to any one of claims 64-66, characterized in that, The resources in the first uplink resource pool are narrowband physical random access channel (NPRACH) resources or narrowband physical uplink shared channel (NPUSCH) resources.

68. The terminal device according to any one of claims 62-67, characterized in that, The first downlink message is a message that the terminal device listens to during the operation of the first timer, and the start time of the first timer is determined based on the sending time of the first uplink message.

69. The terminal device according to any one of claims 47-68, characterized in that, The first process includes an early data transmission process.

70. A network device, characterized in that, include: The sending module is used to send a first downlink message to the terminal device. The first downlink message is sent after the terminal device initiates a first process. The first process is used for the terminal device in the Radio Resource Control (RRC) idle state to transmit first uplink data. The first downlink message is used to instruct the terminal device to terminate the first process or receive a second downlink message, wherein the second downlink message is used by the terminal device to determine to terminate the first process.

71. The network device according to claim 70, characterized in that, The first downlink message includes one or more of the following: First competition resolution identifier; The first instruction information is used to instruct the terminal device to terminate the first process or receive the second downlink message.

72. The network device according to claim 71, characterized in that, The first indication information includes one or more of the following: A first value is used to instruct the terminal device to terminate the first process; The second value is used to instruct the terminal device to receive the second downlink message.

73. The network device according to claim 72, characterized in that, The first indication information occupies 1 bit.

74. The network device according to any one of claims 71-73, characterized in that, The first downlink message is scheduled based on the Temporary Cell Radio Network Temporary Identifier (TC-RNTI) or the first RNTI, where the first RNTI is a public RNTI.

75. The network device according to claim 70, characterized in that, The first downlink message includes second indication information, which is used to indicate that the first uplink data was successfully received and / or to terminate the first process.

76. The network device according to claim 75, characterized in that, The first downlink message is scheduled based on the second RNTI, which is a dedicated RNTI for the terminal device.

77. The network device according to claim 75 or 76, characterized in that, The scheduling of the first downlink message satisfies one or more of the following: If the second RNTI exists, the first downlink message is scheduled based on the second RNTI; If the second RNTI does not exist, the first downlink message is scheduled based on either the TC-RNTI or the first RNTI; If the second RNTI is valid, the first downlink message is scheduled based on the second RNTI; If the second RNTI is invalid, the first downlink message is scheduled based on either the TC-RNTI or the first RNTI; Wherein, the first RNTI is a public RNTI.

78. The network device according to claim 77, characterized in that: If the terminal device initiates the first procedure in the first cell, then the second RNTI is valid; and / or, If the terminal device initiates the first process in the second cell, then the second RNTI is invalid; The second RNTI is an RNTI configured based on the RRC connection release message sent by the first cell.

79. The network device according to claim 77, characterized in that: If pre-configured uplink resources exist, the second RNTI is valid; and / or, If the pre-configured uplink resources are released, the second RNTI becomes invalid; The second RNTI is associated with the pre-configured uplink resource.

80. The network device according to any one of claims 70-79, characterized in that: The first downlink message is a Media Access Control Unit (MAC CE), a Downlink Control Information (DCI) or RRC message; and / or, The second downlink message is a MAC CE, DCI, or RRC message.

81. The network device according to any one of claims 70-73, 75 and 80, characterized in that: The first downlink message is scheduled based on TC-RNTI, the first RNTI, or the second RNTI; and / or, The second downlink message is scheduled based on TC-RNTI, the first RNTI, or the second RNTI; Wherein, the first RNTI is a public RNTI, and the second RNTI is a terminal device-specific RNTI.

82. The network device according to claim 81, characterized in that, The TC-RNTI is carried in message two or the random access response message during the random access process.

83. The network device according to claim 81 or 82, characterized in that, The first RNTI is determined based on one or more of the time domain information, frequency domain information, and code domain information of the first uplink resource, wherein the first uplink resource is used to carry the first uplink message, and the first uplink message is used to carry the first uplink data.

84. The network device according to any one of claims 81-83, characterized in that: The second RNTI is the cell RNTI or an RNTI associated with pre-configured uplink resources; or, The second RNTI is the RNTI carried in the RRC message, the RNTI carried in the first downlink message, or the RNTI determined based on the TC-RNTI.

85. The network device according to any one of claims 70-84, characterized in that, The network device also includes: The receiving module is used to receive a first uplink message sent by the terminal device, wherein the first uplink message is used to carry the first uplink data.

86. The network device according to claim 85, characterized in that, The first uplink message is carried on the first uplink resource, which is scheduled based on message 2 or random access response message during the random access process.

87. The network device according to claim 85, characterized in that, The first uplink message is carried on a first uplink resource, which is selected by the terminal device from a first uplink resource pool.

88. The network device according to claim 87, characterized in that, The first uplink resource pool is determined based on one or more of the following: The coverage enhancement level corresponding to the terminal device; The terminal device uses the first set of basic parameters.

89. The network device according to claim 88, characterized in that, The first set of basic parameters is determined based on one or more of the following: The capabilities of the terminal device; The signal quality of the terminal device; The number of attempts by the terminal device to transmit the first uplink message based on the second uplink resource, wherein the second uplink resource corresponds to the second basic parameter set.

90. The network device according to any one of claims 87-89, characterized in that, The resources in the first uplink resource pool are narrowband physical random access channel (NPRACH) resources or narrowband physical uplink shared channel (NPUSCH) resources.

91. The network device according to any one of claims 85-90, characterized in that, The first downlink message is a message that the terminal device listens to during the operation of the first timer, and the start time of the first timer is determined based on the sending time of the first uplink message.

92. The network device according to any one of claims 70-91, characterized in that, The first process includes an early data transmission process.

93. A terminal device, characterized in that, The device includes a transceiver, a memory, and a processor. The memory stores a program, and the processor invokes the program in the memory and controls the transceiver to receive or send signals so that the terminal device performs the method as described in any one of claims 1-23.

94. A network device, characterized in that, The device includes a transceiver, a memory, and a processor. The memory stores a program, and the processor invokes the program in the memory and controls the transceiver to receive or transmit signals so that the network device performs the method as described in any one of claims 24-46.

95. An apparatus, characterized in that, Includes a processor for calling a program from memory to cause the device to perform the method as described in any one of claims 1-23 or 24-46.

96. A chip, characterized in that, Includes a processor for calling a program from memory, causing a device on which the chip is mounted to perform the method as described in any one of claims 1-23 or 24-46.

97. A computer-readable storage medium, characterized in that, It contains a program that causes a computer to perform the method as described in any one of claims 1-23 or 24-46.

98. A computer program product, characterized in that, Includes a program that causes a computer to perform the method as described in any one of claims 1-23 or 24-46.

99. A computer program, characterized in that, The computer program causes the computer to perform the method as described in any one of claims 1-23 or 24-46.

Images