SDT event recording method, apparatus, and storage medium

Abstract

This application provides an SDT event recording method, apparatus, and storage medium, which are applicable to the field of communication technologies. The SDT event recording method provided in this application first includes a terminal device receiving a first message from a network device. The first message includes a first parameter set, and the first parameter set includes one or more parameters for recording transmission characteristic information during the SDT period. Next, the terminal device records transmission characteristic information corresponding to one or more parameters in the first parameter set based on the first message. The method provides a processing solution for a method of recording events that occur when SDT is executed to help find problems that occur during the SDT period.

Description

Technical Field

[0001] This application relates to the field of communication technologies, and particularly to an SDT event recording method, apparatus, and storage medium.

Background Art

[0002] In a new radio (NR) system, in order to reduce resource consumption for frequent transmission of small data packets and improve transmission efficiency, an inactive state, which may also be referred to as an RRC inactive state, is introduced at the radio resource control (RRC) level.

[0003] In a conventional solution, in the RRC inactive state, when data needs to be transmitted, the terminal device triggers an RRC resume request to resume the RRC connected state, and then the terminal device transmits data in the RRC connected state.

[0004] With the development of technology, a technology that enables a terminal device to transmit data in the RRC inactive state has been proposed currently. This technology is called small data transmission (SDT). However, a solution regarding a method for recording SDT events, for example, a method for recording the reason for SDT failure, has not been proposed currently. In this case, problems occurring in SDT may not be timely and accurately found, or the SDT setting parameters may not be timely adjusted or optimized. Therefore, the method for recording SDT events is an urgent problem to be solved currently.

Summary of the Invention

[0005] This application provides a method, apparatus, and storage medium for recording SDT events in order to solve the problem of being unable to record SDT events.

[0006] A method for recording SDT events is provided according to a first aspect. The method includes a terminal device receiving a first message from a network device, the first message comprising a first parameter set, the first parameter set comprising one or more parameters for recording transmission characteristics information during an SDT period, and the terminal device recording transmission characteristics information corresponding to one or more parameters in the first parameter set based on the first message. When performing an SDT based on the SDT event recording method provided in this embodiment of the Application, the terminal device can record transmission status information based on instructions from the network device to help identify problems occurring during an SDT period and optimize SDT configuration parameters.

[0007] Referring to the first aspect, in a possible design, the first parameter set includes at least one first parameter, which is used to instruct the recording of measurements of the beam signal of the serving cell.

[0008] Referring to the first aspect, in a possible design, SDT is a configuration grant-small data transmission. (configured grant-small data transmission, CG-SDT ) Or random access channel - small data transmission (random access channel-small data transmission, RACH-SDT ) The first parameter set includes at least one second parameter, which is used to instruct the system to record CG-SDT events and / or RACH-SDT events.

[0009] Referring to the first aspect, in a possible design, the events of CG-SDT are as follows: After sending data to a network device on a CG resource, the terminal device does not receive feedback information. When a terminal device transmits data to a network device on a CG resource, the signal value of the target cell must be smaller than a pre-set threshold, or the signal value of the target beam must be smaller than a pre-set threshold. The number of times a terminal device sends data to a network device on a CG resource reaches the maximum number of retransmissions. Layer 3 to network devices on CG resources (layer 3, L3 ) After sending a message and / or data, the terminal device activates the CG-SDT timer, and before the CG-SDT timer expires, the network device receives an acknowledgment message, Layer 2 (L2). ) Failure to receive messages, L3 messages, or scheduled data, or Terminal device timing advance (timing advance, TA ) The timer expires, and the CG resources become unavailable. Includes one or more of the following.

[0010] Referring to the first aspect, in a possible design, the events of RACH-SDT are as follows: Reasons why the terminal device cannot send Msg3 and data to the network device, or The number of times the terminal device failed to send Msg3 and data to the network device and / or the total number of times the terminal device sent Msg3 and data to the network device. This includes one or more of the following. The total number of attempts includes the number of times Msg3 and data transmission failed and the number of times Msg3 and data transmission was successful.

[0011] Referring to the first aspect, in a possible design, the first message is a measurement record setting message.

[0012] A method for recording SDT events is provided according to a second aspect. The method includes a terminal device receiving a second message from a network device, the second message including a second parameter set, the second parameter set including one or more parameters that instruct the recording of service characteristic information during the SDT period, and the terminal device recording service information corresponding to each parameter in the second parameter set based on the first message. When performing SDT based on the SDT event recording method provided in this embodiment of the Application, the terminal device can record service characteristic information based on instructions from the network device to help identify problems occurring during the SDT period and optimize SDT configuration parameters.

[0013] Referring to the second aspect, in a possible design, the service characteristic information is as follows: Terminal device cache, frequency of terminal devices sending data to network devices, whether data sent by terminal devices to network devices exceeds a pre-configured threshold, frequency of terminal devices transmitting data to network devices within a segment, time and / or frequency of terminal devices receiving MT-SDT messages from network devices, terminal device movement trajectory, signal strength of cells re-selected by terminal devices, multi-subscriber identity module (multi-subscriber identity module, Multi-SIM ) In the scenario, events that cause a terminal device to switch from the first network to the second network, reasons why a terminal device enters an idle state, reasons why a terminal device terminates an SDT session, and wireless resource control. ( RRC ) This includes at least one of the following events: an event that triggers the terminal device to request the network device to resume the connected state.

[0014] Referring to the second aspect, in a possible design, reasons for the terminal device to enter the idle state include that the terminal device triggers a radio link failure or the terminal device triggers a cell reselection.

[0015] Referring to the second aspect, in a possible design, reasons for the terminal device to terminate the SDT session include that the terminal device receives a first indication message used to instruct the terminal device by the network device to enter the idle state or the non-active state, or the SDT timer of the terminal device expires.

[0016] Referring to the second aspect, in a possible design, radio resource control ( RRC ) Events that trigger the terminal device to request the network device to resume the connected state are as follows: arrival of a non-SDT service, the terminal device triggers a cell selection or a cell reselection, and in a Multi-SIM scenario, the terminal device switches from a second network to a first network, including at least one of them.

[0017] Referring to the second aspect, in a possible design, the second message is a measurement record setting message.

[0018] According to the third aspect, an SDT event recording method is provided. The method is that the terminal device receives a third message from the network device, and the third message is used to instruct the terminal device to record an SDT event and / or measure drive test minimization (minimization of drive tests, MDT ) configuration parameters, and the terminal device obtains a recording result based on the third message, records measurement results and / or SDT events based on MDT configuration parameters, and the terminal device transmits the recording result to the network device.

[0019] Referring to the third aspect, in a possible design, the third message is a measurement record setting message.

[0020] Referring to the third aspect, in a possible design, the terminal device transmitting the recording result to the network device is that the terminal device transmits a fourth message to the network device, and the fourth message is used to indicate that the terminal device has obtained an available recording result or there is an available recording instruction at the terminal device; and that the terminal device receives a second instruction message from the network device, and the second instruction message is used to instruct the terminal device to transmit the recording result to the network device; and that the terminal device transmits the recording result to the network device based on the second instruction message.

[0021] Referring to the third aspect, in a possible design, the fourth message is Radio Resource Control ( RRC ) carried in a Resume request message or an RRC setup request message.

[0022] Referring to the third aspect, in a possible design, the terminal device transmitting the recording result to the network device includes the terminal device transmitting the past recording results obtained after the last SDT ended to the network device for each SDT period.

[0023] Referring to the third aspect, in a possible design, the past recording results are carried in an RRC message or a Medium Access Control (media access control, MAC ) layer message.

[0024] Referring to the third aspect, in a possible design, the transmission of recording results by a terminal device to a network device includes the terminal device receiving a third instruction message from the network device, the third instruction message being used to instruct the terminal device to transmit recording results to the network device, and the terminal device transmitting recording results to the network device based on the third instruction message.

[0025] Referring to the third aspect, in a possible design, the third instruction message is a terminal information request message, and the recording result is carried in a terminal information response message.

[0026] Referring to the third aspect, in a possible design, the method further includes the terminal device's SDT timer starting to operate before the terminal device records an SDT event based on the third message and measures the MDT configuration parameters.

[0027] Referring to the third aspect, in a possible design, a terminal device recording measurement results and / or SDT events based on MDT setting parameters in order to obtain recording results based on a third message includes the terminal device recording measurement results and / or SDT events based on MDT setting parameters based on a third message, the terminal device stopping recording measurement results and / or SDT events based on MDT setting parameters when the SDT timer expires, and the terminal device obtaining recording results based on measurement results and / or SDT events based on MDT setting parameters recorded within the operating period of the SDT timer.

[0028] Referring to the third aspect, in a possible design, a terminal device recording measurement results and / or SDT events based on MDT configuration parameters in order to obtain recording results based on a third message includes the terminal device recording measurement results and / or SDT events based on MDT configuration parameters based on a third message, the terminal device ceasing to record measurement results and / or SDT events based on MDT configuration parameters when the terminal device's SDT session ends, and the terminal device obtaining recording results based on the recorded measurement results and / or recorded SDT events based on MDT configuration parameters.

[0029] Referring to the third aspect, in a possible design, the recording results transmitted by the terminal device to the network device are the available recording results, which are determined by the terminal device based on the number of recorded measurement results and / or the number of recorded SDT events, according to the MDT configuration parameters.

[0030] In accordance with the fourth aspect, a communication device is provided to implement the above method. The communication device may be a terminal device, a device including a terminal device, or a device included in a terminal device, e.g., a chip, in any of the designs of the first to third aspects. Alternatively, the communication device may be a network device, a device including a network device, or a device included in a network device, e.g., a chip, in any of the designs of the first to third aspects. The communication device includes corresponding modules, units, or means for implementing the above method. The modules, units, or means may be implemented by hardware, by software, or by hardware running corresponding software. The hardware or software includes one or more modules or units corresponding to the above functions.

[0031] In accordance with the fifth aspect, a communication device is provided, including a processor and memory. The memory is configured to store computer instructions. The processor is configured to execute instructions stored in memory. When the processor executes instructions, the communication device can perform a method according to any one of the above aspects. The communication device may be a terminal device, a device including a terminal device, or a device included in a terminal device, e.g., a chip, in the design of any of the first to third aspects. Alternatively, the communication device may be a network device, a device including a network device, or a device included in a network device, e.g., a chip, in the design of any of the first to third aspects.

[0032] In accordance with the sixth aspect, a communication device is provided, comprising a processor and an interface circuit. The interface circuit is configured to communicate with other modules other than the communication device. The processor is configured to execute computer programs or instructions in a manner that performs any one of the above aspects. The communication device may be a terminal device, a device including a terminal device, or a device included in a terminal device, e.g., a chip, in the design of any of the first to third aspects. Alternatively, the communication device may be a network device, a device including a network device, or a device included in a network device, e.g., a chip, in the design of any of the first to third aspects.

[0033] Alternatively, the interface circuit may be a code / data read / write interface circuit, which receives a computer executable instruction (which is stored in memory and may be read directly from memory or through other components), sends the computer executable instruction to the processor, thereby the processor executes the computer executable instruction in a manner that conforms to any one of the aspects described above.

[0034] In some possible designs, the communication device may be a chip or a chip system.

[0035] In accordance with the seventh aspect, a communication device is provided, including a processor. The processor is coupled to memory and configured to read instructions from memory and to perform a method according to any one of the above aspects based on the instructions. The communication device may be a terminal device, a device including a terminal device, or a device included in a terminal device, e.g., a chip, in the design of any of the first to third aspects. Alternatively, the communication device may be a network device, a device including a network device, or a device included in a network device, e.g., a chip, in the design of any of the first to third aspects.

[0036] In accordance with the eighth aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores instructions. When an instruction is executed by the communication device, the communication device can perform a method according to any one of the above aspects. The communication device may be a terminal device, a device including a terminal device, or a device included in a terminal device, such as a chip, in any of the designs of the first to third aspects. Alternatively, the communication device may be a network device, a device including a network device, or a device included in a network device, such as a chip, in any of the designs of the first to third aspects.

[0037] A computer program product including instructions is provided in accordance with the ninth aspect. When the computer program product is executed on a communication device, the communication device can perform a method according to any one of the aspects described above. The communication device may be a terminal device, a device including a terminal device, or a device included in a terminal device, such as a chip, in the design of any of the first to third aspects. Alternatively, the communication device may be a network device, a device including a network device, or a device included in a network device, such as a chip, in the design of any of the first to third aspects.

[0038] In accordance with the tenth aspect, a communication device (for example, the communication device may be a chip or a chip system) is provided. The communication device includes a processor configured to implement the functions in any one of the above aspects. In possible designs, the communication device further includes memory. The memory is configured to store the necessary program instructions and data. If it is a chip system, the communication device may include a chip, or a chip and other discrete devices.

[0039] A communication system is provided in accordance with the eleventh aspect. The communication system includes terminal devices and network devices. The terminal devices may implement the design methods of any of the first to third aspects, and the network devices may implement the design methods of any of the first to third aspects. [Brief explanation of the drawing]

[0040] [Figure 1] This is an architecture diagram of a communication network according to an embodiment of the present invention. [Figure 2] This is a schematic diagram of an interaction process in which a UE requests the resumption of an RRC connection, according to an embodiment of the present invention. [Figure 3] This is a flowchart of the SDT according to the embodiment of the present invention. [Figure 4] This is a flowchart of another SDT according to the embodiment of the present invention. [Figure 5] This is a flowchart of MDT measurement according to the embodiment of the present invention. [Figure 6] This is a schematic diagram of the structure of a communication system according to an embodiment of the present invention. [Figure 7] This is a schematic diagram of the structure of a communication device according to an embodiment of the present invention. [Figure 8] This is a schematic diagram of the hardware structure of a UE according to an embodiment of the present invention. [Figure 9] This is a flowchart of an SDT event recording method according to an embodiment of the present invention. [Figure 10]This is a flowchart of another SDT event recording method according to an embodiment of the present invention. [Figure 11] This is a flowchart of yet another SDT event recording method according to an embodiment of the present invention. [Figure 12] This is a flowchart of yet another SDT event recording method according to an embodiment of the present invention. [Figure 13] This is a flowchart of yet another SDT event recording method according to an embodiment of the present invention. [Figure 14] This is a flowchart of yet another SDT event recording method according to an embodiment of the present invention. [Figure 15] This is a schematic diagram of the structure of another communication device according to an embodiment of the present invention. [Modes for carrying out the invention]

[0041] For the sake of clarity, some of the terms and related technologies of this application are briefly described below.

[0042] 1. Fifth Generation (5G) Network Architecture

[0043] Figure 1 is a schematic diagram of the service-based architecture of an existing 5G network. The 5G network mainly includes the following network functions and entities: radio access network (RAN) devices, user plane function (UPF), data network (DN), core access and mobility management function (AMF), session management function (SMF), authentication server function (AUSF), network slice selection function (NSSF), network exposure function (NEF), network repository function (NRF), policy control function (PCF), unified data management (UDM), unified data repository (UDR), application function (AF), charging function (CHF), etc.

[0044] Network functionality can be used as network elements running on dedicated hardware, software instances running on dedicated hardware, or virtual functions instantiated on an appropriate platform, such as a cloud infrastructure.

[0045] It should be noted that Figure 1 shows only some examples of network elements or entities within a 5G network. A 5G network may further include several network elements or entities not shown in Figure 1, such as a network data analytics function (NWDAF). This is not particularly limited in the embodiments of the present invention.

[0046] As shown in Figure 1, terminal devices access the 5G network via RAN devices, terminal devices communicate with AMF via the N1 interface (abbreviated as N1), RAN devices communicate with AMF via the N2 interface (abbreviated as N2), RAN devices communicate with UPF via the N3 interface (abbreviated as N3), SMF communicates with UPF via the N4 interface (abbreviated as N4), and UPF accesses DN via the N6 interface (abbreviated as N6). In addition, control plane functions such as AUSF, AMF, SMF, NSSF, NEF, NRF, PCF, UDM, UDR, CHF, or AF shown in Figure 1 interact through service-based interfaces. For example, the service-based interface indicated by AUSF is Nausf, the service-based interface indicated by AMF is Namf, the service-based interface indicated by SMF is Nsmf, the service-based interface indicated by NSSF is Nnssf, the service-based interface indicated by NEF is Nnef, the service-based interface indicated by NRF is Nnrf, the service-based interface indicated by PCF is Npcf, the service-based interface indicated by UDM is Nudm, the service-based interface indicated by UDR is Nudr, the service-based interface indicated by CHF is Nchf, and the service-based interface indicated by AF is Naf. For descriptions of related functions and interfaces, please refer to the 5G system architecture diagram in the 23501 standard. Further details are not provided here.

[0047] The functionality of parts or network elements within the above network architecture in a 5G network is described separately below using examples.

[0048] (1) A RAN device is configured to provide network access functionality to authorized terminal devices within a specific area and may use transmission tunnels of different qualities based on the level of the terminal device, service requirements, etc. A RAN device can manage radio resources and provide access services to terminal devices to complete the transfer of control signals and terminal data between the terminal and the core network. Alternatively, a RAN device may be understood as a base station in a conventional network. For example, a RAN device may be involved in functions such as radio resource management, quality of service (QoS) management, and data compression and encryption on the air interface side.

[0049] A RAN device may be a device within a wireless network. A RAN device may also be called a wireless RAN device or network device. Currently, some examples of RAN devices include Next Generation Node B (gNB) or transmission and reception point (TRP) in 5G systems, evolved Node B (eNB) in long-term evolution (LTE) systems, radio network controller (RNC), Node B (NB), base station controller (BSC), base transceiver station (BTS), home base station (e.g., home evolved Node B or home Node B, HNB), baseband unit (BBU), wireless fidelity (Wi-Fi) access point (AP), and others. In a network structure, network devices may include centralized unit (CU) nodes, distributed unit (DU) nodes, or RAN devices that include both CU and DU nodes. RAN devices may also be wireless backhaul devices, automotive devices, wearable devices, network devices in future 5G networks, network devices in future evolved PLMN networks, etc., and are referred to as Node B in third-generation (3G) systems.

[0050] (2) The mobility management network element is a core network element and is mainly involved in the signaling processing portion, such as access control, mobility management, attach and detach, and gateway selection. When providing services to a terminal session, the mobility management network element provides the session with control plane storage resources to store the session identifier, the SMF network element identifier associated with the session identifier, etc. In a 5G communication system, the mobility management network element may be an access and mobility management function (AMF) network element. In future communication systems, the mobility management network element may still be an AMF network element or may have another name. This is not limited to the present application.

[0051] (3) User plane network elements are used for packet routing and forwarding, quality of service (QoS) processing of user plane data, etc. In a 5G communication system, the network elements or entities corresponding to user plane network elements may be user plane functions (UPFs) within the 5G network architecture. In future communication systems, user plane networks may still be UPF network elements or user plane network elements, or may have other names. This is not limited to embodiments of the present invention.

[0052] For explanations of the functions of network elements such as DN, SMF, AUSF, NSSF, NEF, NRF, PCF, UDM, UDR, AF, and CHF, please refer to the descriptions and references of the prior art. Further details are not provided here.

[0053] 2. RRC status

[0054] Three RRC states are defined in a 5G NR system: Inactive, Connected, and Idle (IDLE). The three states are described as follows:

[0055] (1) The connected state is the RRC_CONNECTED state, also called the connected state or RRC connected state. The connected state means that an RRC connection has been established between the terminal device and the access network. When a terminal device is in the connected state, connections have been established between the terminal device and the access network (e.g., base station) and the core network (e.g., AMF). If data needs to be transmitted, the data can be transmitted directly by using the established connections. The RRC connection is used to process control plane messages between the terminal device and the access network.

[0056] (2) The inactive state is the RRC_INACTIVE state, also called the inactive state or third state. The inactive state means that the RRC connection between the terminal device and the access network (e.g., base station) is interrupted, but the connection between the access network corresponding to the terminal device and the core network is not interrupted. In conventional solutions, if the terminal device is in an inactive state, the RRC connection between the terminal device and the access network must first be re-established before data can be transmitted when data needs to be transmitted.

[0057] After a terminal device enters an inactive state, the terminal device's context is suspended on both the terminal device and base station sides. The terminal device's context is stored in the last cell to which the terminal device camped on before entering the inactive state, or in the cell that last provided service to the terminal device (also known as the anchor cell). If there is a data and / or signaling transmission request, the terminal device may retrieve its context by initiating an RRC resume request to resume the RRC connection based on the terminal device's context. For example, the terminal device's context includes the terminal device's security context and terminal device capability information.

[0058] (3) The idle state is RRC_IDLE. The idle state means that no RRC connection has been established between the terminal device and the access network device (e.g., base station), and no connection has been established between the access network device (e.g., base station) corresponding to the terminal device and the core network device (e.g., AMF). When a terminal device is in the idle state, when data needs to be transmitted, the connection between the UE and the access network device (e.g., base station), and the connection between the access network device (e.g., base station) and the core network device (e.g., AMF) must be established first before the data can be transmitted.

[0059] Furthermore, the base station to which the cell the terminal device is currently camped on belongs, or the base station currently providing service to the terminal device, may be called the Serving Base Station (Serving-gNB). The base station to which the last cell the terminal device was camped on before it entered an inactive state belongs, or the base station that last provided service to the terminal device before it entered an inactive state, may be called the Anchor Base Station (Anchor-gNB). Note that terminal devices are mobile. After entering an inactive state, the terminal device may move. Therefore, the serving base station and anchor base station for a terminal device may be different.

[0060] 3. Switching from RRC inactive state to RRC connected state

[0061] In conventional solutions, when a terminal device needs to transmit data while RRC is inactive, the terminal device may first switch to the RRC connected state and then transmit the data and / or signaling. For example, the terminal device is user equipment (UE). Figure 2 shows the complete procedure for switching from the RRC inactive state to the RRC connected state and transmitting data. As shown in Figure 2, the switching procedure may include the following steps.

[0062] Step 201: A terminal device in an RRC inactive state sends an RRC Resume Request message to the serving base station.

[0063] Step 202: If the serving base station for the terminal device is not the anchor base station for the terminal device, the serving base station sends a Retrieve UE CONTEXT REQUEST message to the anchor base station to request the context for the terminal device.

[0064] Step 203: The anchor base station sends a Retrieve UE CONTEXT RESPONSE message to the serving base station, which contains the context of the terminal device.

[0065] Step 204: After receiving the context read response, the serving base station sends an RRC Resume message to the terminal device to switch the terminal device to the RRC Connected state.

[0066] Step 205: After receiving the RRC resume message, the terminal device switches to the RRC connected state.

[0067] Step 206: After resuming the RRC connected state, the terminal device sends an RRC resume complete message to the serving base station.

[0068] Step 207: After receiving the RRC resume complete message, the serving base station sends Xn-U address indication information to the anchor base station.

[0069] Step 208: In order for the path of the core network device to be switched to the serving base station, the serving base station sends a path switch request message to the AMF and receives a path switch response message to perform the path switch.

[0070] Step 209: After the path switch, the serving base station sends a UE context release message to the anchor base station to instruct it to release the context of the terminal device.

[0071] It should be understood that after step 208, the serving base station becomes the new anchor base station. Therefore, the original anchor base station (i.e., the anchor base station in Figure 2) no longer needs to hold the context of the terminal device and can release the context of the terminal device.

[0072] Step 210: After the path switch, terminal devices in the RRC connected state may perform data transmission via UPF.

[0073] Step 211: After data transmission is complete, the serving base station (which is also the anchor base station) may send an RRC release message to the terminal device so that the terminal device switches to an RRC inactive state.

[0074] The RRC release message may include a suspendconfig to instruct the terminal device to suspend the terminal device's context.

[0075] If a terminal device that has resumed an inactive state needs to send data again, steps 201 through 211 may be executed again.

[0076] However, steps 201 to 211 show that if data transmission is performed relatively frequently, the terminal device needs to switch frequently between inactive and connected states, resulting in the occupation of a large amount of signaling resources. However, occupying a large amount of signaling resources to transmit small data packets is a waste of signaling resources. Therefore, in possible implementations, SDT technology has been proposed, which allows the terminal device to transmit data in an RRC inactive state.

[0077] 4. SDT

[0078] Currently, there are two possible scenarios for SDT to run when the terminal device is inactive: Scenario 1 and Scenario 2. In Scenario 1, after the terminal device completes SDT, the serving base station transitions the terminal device's state to connected. In Scenario 2, after the terminal device completes SDT, the serving base station sets the terminal device's state to inactive or idle.

[0079] For example, Figure 3 is a flowchart for performing SDT in Scenario 1. An example is used where the terminal device is the UE. As shown in Figure 3, the process may include the following steps.

[0080] Step 301: The terminal device is in an inactive state. If a configured grant (CG) resource is not set on the terminal device, or if the CG resource is unavailable, the terminal device triggers a random access (RA) procedure and sends message 1 (Msg1) to the serving base station to request resources to send data.

[0081] Step 302: The serving base station sends message 2 (Msg2), which is a random access response (RAR) message, to the terminal device. The RAR message carries an uplink grant (UL grant).

[0082] Step 303: The terminal device sends message 3 (message3, Msg3), which is an RRC resume request message, and the uplink data that needs to be transmitted, to the serving base station. The RRC resume request message may be used to request that SDT be performed, or the RRC resume request message may be used to request that an SDT session be established. During the SDT session period (also known as the SDT period), an inactive UE may send data to the serving base station.

[0083] Optionally, uplink data may be carried in an RRC resume request message, or the uplink data and the RRC resume request message may be encapsulated in the same message.

[0084] Step 304: The serving base station forwards the received uplink data to the core network (UPF).

[0085] Step 305: After data transmission is complete, the serving base station sends an RRC resume message to the terminal device, which may be used to configure the UE to switch to the RRC connected state.

[0086] Step 306: After receiving the RRC resume message, the terminal device terminates the SDT session (ends SDT) and switches to the RRC connected state. After resuming the RRC connected state, the terminal device sends an RRC resume complete message to the serving base station.

[0087] Optionally, after step 306, the serving base station may further set the terminal device to an inactive or idle state.

[0088] As another example, Figure 4 is a flowchart for performing SDT in Scenario 2. As shown in Figure 4, the process may include the following steps.

[0089] Step 401: If a CG resource is not configured on the terminal device, or if the CG resource is unavailable, the terminal device triggers the RA procedure and sends Msg1 to the serving base station to request resources for sending data.

[0090] Step 402: The serving base station sends Msg2, i.e., a RAR message, to the terminal device. The RAR message carries a UL grant.

[0091] Step 403: An inactive terminal device sends Msg3, i.e., an RRC resume request message, and the uplink data that needs to be transmitted, to the serving base station. The RRC resume request message may be used to request that SDT be performed, i.e., the RRC resume request message may be used to request that an SDT session be established. During the SDT session period (also known as the SDT period), the inactive UE may send data to the serving base station.

[0092] Optionally, uplink data may be carried in an RRC resume request message, or the uplink data and the RRC resume request message may be encapsulated in the same message.

[0093] Step 404: The serving base station forwards the received uplink data to the core network (UPF) and transmits the uplink and downlink data that lies between the core network and the terminal devices and subsequently arrives.

[0094] Step 405: After data transmission is complete, the serving base station sends an RRC release message to the terminal device to configure it to enter an inactive or idle state. Upon receiving the RRC release message, the terminal device terminates SDT (ends the SDT session) and enters an inactive or idle state based on the instructions in the RRC release message.

[0095] As shown in Figure 3 or Figure 4, the method by which a terminal device obtains resources used for SDT by using a random access procedure is called random access channel (Small Data Transmission). -small data transfer This is called RACH-SDT). Unlike the RACH-SDT procedure shown in Figure 3 or Figure 4, the terminal device may also perform SDT by using the Config-Grand Small Data Transmission (CG-SDT) procedure. In the CG-SDT procedure, available CG resources are configured on the terminal device, and signaling or data can be transmitted directly and successfully on the available CG resources without triggering random access to request resources. For example, in Scenario 1, the CG-SDT procedure does not need to include steps 301 and 302 in Figure 3, and the terminal device may directly perform step 303 based on the available CG resources and then perform steps 304-306. In Scenario 2, the CG-SDT procedure does not need to include steps 401 and 402 in Figure 4, and the terminal device may directly perform step 403 based on the CG resources and then perform steps 404-405.

[0096] 5. Minimization of logged drive tests (Logged-MDT)

[0097] Logged-MDT is a technique for collecting relevant measurements from idle or inactive terminal devices to help identify the cause of a problem, such as measuring cell signal levels and recording random access failure events.

[0098] When a terminal device is in a connected state, the serving base station may send a logged measurement configuration message to the terminal device. The logged measurement configuration message may include MDT measurement configuration information and may indicate MDT configuration parameters that need to be measured by the terminal device. After receiving the logged measurement configuration message, the terminal device may, after entering an idle or inactive state, perform the corresponding measurement based on the logged measurement configuration message and log the measurement results in order to obtain an MDT measurement log (or "to obtain MDT measurement results"). After obtaining the MDT measurement log, the terminal device may send an RRC resume request message to the base station, adding a message indicating that the terminal device will perform an available MDT measurement. After receiving the RRC resume request message, the base station may configure the terminal device to resume the RRC connected state, and based on the instruction message carried in the RRC resume request message, know that the terminal device has an MDT measurement log, and may send an MDT measurement log reporting request message to the terminal device that has resumed the connected state, instructing the terminal device to report the MDT measurement log. After receiving an MDT measurement record report request message, the terminal device sends the MDT measurement record to the base station.

[0099] For example, a complete MDT workflow is described below, with reference to Figure 5. As shown in Figure 5, the procedure may include the following steps.

[0100] Step 501: The terminal device enters a connected state.

[0101] Step 502: The serving base station receives a trace start message from the core network device (e.g., AMF or UPF) to trigger the serving base station to send the configured MDT measurement configuration information to the terminal device.

[0102] It should be noted that the receipt of a trace start message from the core network device by the serving base station, as shown in Figure 5, is merely an exemplary method of triggering the serving base station to distribute MDT measurement configuration information. Other triggering mechanisms may be, and are not limited to, other triggering mechanisms by the core network device, triggering mechanisms by the network management platform, or triggering mechanisms by the serving base station.

[0103] Furthermore, it should be noted that performing step 502 after step 501, as shown in Figure 5, is merely an illustrative order. The occasions on which a serving base station receives a trigger message to trigger the serving base station to distribute MDT measurement configuration information are not limited in this application. That is, the occasions on which a serving base station receives a trigger message are independent of the state of the terminal device. A serving base station may receive a trigger message when the terminal device is in any one of the following states: connected, inactive, or idle. However, it should be noted that the serving base station sends the MDT measurement configuration information to the terminal device after the terminal device has entered the connected state.

[0104] Step 503: The serving base station sends a log measurement configuration message to the terminal device, carrying MDT measurement configuration information.

[0105] Step 504: The serving base station sends an RRC release message to the terminal device so that the terminal device enters an inactive state. The terminal device begins measuring the relevant MDT configuration parameters based on the log measurement configuration message in order to obtain measurement records.

[0106] Step 505: The terminal device sends an RRC resume request message to the serving base station to request the resumption of the RRC connected state.

[0107] Step 506: The serving base station responds to the terminal device with an RRC resume message. After receiving the RRC resume message, the terminal device switches to the RRC connected state.

[0108] Step 507: The terminal device sends an RRC resume complete message to the serving base station, which carries an instruction message indicating that MDT-related measurements are available.

[0109] Step 508: The serving base station sends a UE information request message to the terminal device to report the relevant MDT measurement records.

[0110] Step 509: The terminal device sends a UE information request message response message, i.e., a UE information response message, to the serving base station, and the UE information response message carries the relevant MDT measurement record.

[0111] The Logged-MDT measurement procedure was described above. However, relevant parameters of terminal devices in an idle or inactive state are recorded in Logged-MDT. Regarding SDT technology, there is currently no solution to record events or conditions that occur during the SDT process, for example, a solution to record the reasons for SDT failures. In this case, problems that occur during SDT may not be identified accurately in a timely manner, or SDT configuration parameters may not be adjusted or optimized in a timely manner. Therefore, a method for recording SDT events is an urgent issue that needs to be addressed now.

[0112] Based on the challenges of recording SDTs mentioned above, embodiments of the present invention provide an SDT event recording method for recording events or conditions that occurred during an SDT procedure (which may also be called an SDT period) in order to timely and accurately identify problems that occurred during an SDT period and to optimize SDT setting parameters.

[0113] The technical solutions in the embodiments of this application are described below with reference to the accompanying drawings of the embodiments of this application. In the specification of this application, unless otherwise specified, " / " indicates an "or" relationship between related objects. For example, A / B may mean A or B. In this application, "and / or" is simply an association relationship for describing related objects and indicates that three relationships may exist. For example, A and / or B may mean the following three cases: A exists only, both A and B exist, and B exists only, and A and B may be singular or plural. Also in the specification of this application, unless otherwise specified, "plural..." means two or more. "At least one of the following items" or similar expressions refer to any combination of these items, including any single item or any combination of multiple items. For example, at least one of a, b, or c can represent a, b, c, a and b, a and c, b and c, or a, b and c, where a, b, and c may be singular or plural. Furthermore, in order to clearly describe the technical solutions in the embodiments of this application, terms such as “first” and “second” are used in the embodiments of this application to distinguish between the same or similar items that provide essentially the same function and role. Those skilled in the art will understand that terms such as “first” and “second” do not limit the quantity or order of execution, nor do they indicate a clear distinction. Also, in the embodiments of this application, terms such as “example” or “for example” are used to indicate providing an example, illustration, or description. Any embodiment or design solution described as “example” or “for example” in the embodiments of this application should not be described as being more preferable or having more advantages than other embodiments or design solutions. Indeed, the use of terms such as “example” or “for example” is intended to concretely present relevant concepts for ease of understanding.

[0114] Furthermore, the network architectures and service scenarios described in the embodiments of this application are intended to provide a clearer description of the technical solutions in the embodiments of this application and do not constitute a limitation on the technical solutions provided in the embodiments of this application. Those skilled in the art will recognize that, with the evolution of network architectures and the emergence of new service scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical challenges.

[0115] Figure 6 shows a communication system according to an embodiment of the present invention. As shown in Figure 6, the communication system includes a terminal device 601 and a network device 602. The network device 602 is an access network device currently providing services to the terminal device 601. For further details, please refer to the above description of the serving base station.

[0116] Optionally, a 5G communication system may be used as an example. A possible schematic diagram of a network architecture applicable to this embodiment of the present application, corresponding to the communication system shown in Figure 6, may be shown in Figure 1. For example, terminal device 601 may be the terminal device in Figure 1, and network device 602 may be the RAN device shown in Figure 1.

[0117] The system architectures described in the embodiments of this application are intended to provide a clearer description of the technical solutions in the embodiments of this application and do not constitute a limitation on the technical solutions provided in the embodiments of this application. Those skilled in the art will recognize that, with the evolution of network architectures and the emergence of new service scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical challenges.

[0118] The network device in the embodiments of this application is a device that connects terminal devices to a wireless network. In this application, unless otherwise specified, the network device is a wireless access network device. The network device 602 may be a base station, an evolved node B (eNodeB), a transmission and reception point (TRP), a next-generation node B (gNB) in a 5G mobile communication system, a base station in a future mobile communication system, an access node in a wireless fidelity (Wi-Fi) system, or a module or unit that completes some of the functions of a base station, such as a central unit (CU) or a distributed unit (DU). Alternatively, the network device may be a broadband network gateway (BNG), an aggregation switch, or a non-3GPP access device. The network device may alternatively be a radio controller, a transmission and reception point (TRP), or a device including a TRP within a cloud radio access network (CRAN). The specific technologies and device forms used by the network device are not limited to those in the embodiments of this application.

[0119] The terminal devices of the embodiments of the present invention may be devices equipped with wireless transceiver functionality. The terminal devices may be located on the ground, including indoors, outdoors, handheld, or in a vehicle, on the water (e.g., a ship), or in the air (e.g., an airplane, balloon, or satellite). The terminal devices may be user equipment (UE), access terminals, terminal units, subscriber units, terminal stations, mobile stations (MS), mobile consoles, remote stations, remote terminals, mobile devices, wireless communication devices, terminal agents, terminal equipment, etc., within a 5G network or a future advanced public land mobile network (PLMN). Access terminals may include cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices or other processing devices connected to wireless modems, in-vehicle devices or wearable devices, virtual reality (VR) terminal devices, augmented reality (AR) terminal devices, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in telemedicine, wireless terminals in smart grids, wireless terminals in transport safety, wireless terminals in smart cities, wireless terminals in smart homes, and the like. Terminals may be mobile or fixed. The specific types and structures of terminals are not limited in the embodiments of this application.

[0120] Optionally, the terminal device 601 and network device 602 in this embodiment of the present application may use the configuration shown in Figure 7 or include the components shown in Figure 7. Figure 7 is a schematic diagram of the structure of a communication device 70 according to an embodiment of the present application. As shown in Figure 7, the communication device 70 includes one or more processors 701, communication lines 702, and at least one communication interface (in Figure 7, only an example including a communication interface 703 and one processor 701 is used for illustrative purposes), and optionally further includes memory 704.

[0121] The processor 701 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to control the execution of a program in the solution of the present invention.

[0122] Communication line 702 may include channels for communication between different components.

[0123] The communication interface 703 may be a transceiver module and may be configured to communicate with a communication network such as Ethernet, RAN, or other devices or a wireless local area network (WLAN). For example, the transceiver module may be a device such as a transceiver or transceiver machine. Optionally, the communication interface 703 may instead be a transceiver circuit located on the processor 701 to perform signal input and signal output for the processor.

[0124] Memory 704 may be a device with storage capabilities. For example, memory 704 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, or a random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other compact disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be configured to carry or store expected program code in the form of instructions or data structures and that can be accessed by a computer. However, it is not limited to these. Memory may exist independently and be connected to the processor by using a communication line 702. Alternatively, memory may be integrated with the processor.

[0125] Memory 704 is configured to store computer-executable instructions for executing the solution of the present invention, and the processor 701 controls the execution. The processor 701 is configured to execute the computer-executable instructions stored in memory 704 to implement the SDT event recording method provided in the embodiments of the present invention.

[0126] Alternatively, optionally, in this embodiment of the Application, the processor 701 may perform processing-related functions in the SDT event recording method provided in subsequent embodiments of the Application. The communication interface 703 is involved in communication with other devices or communication networks. This is not particularly limited in this embodiment of the Application.

[0127] Optionally, the computer executable instructions in this embodiment of the present application may also be called application program code. This is not particularly limited in this embodiment of the present application.

[0128] In a specific implementation, the processor 701 may include one or more CPUs, for example, CPU0 and CPU1 in Figure 7.

[0129] In a specific implementation, the communication device 70 may include a plurality of processors, for example, processors 701 and 707 in Figure 7. Each of these processors may be a single-core processor or a multi-core processor. The processors here may include, but are not limited to, at least one of the following computing devices that run software: a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a microcontroller unit (MCU), or an artificial intelligence processor. Each computing device may include one or more cores that execute software instructions to perform operations or processing.

[0130] In specific implementations, the communication device 70 may further include an output device 705 and an input device 706. The output device 705 communicates with the processor 701 and can display information in multiple ways. For example, the output device 705 may be a liquid crystal display (LCD), a light-emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device 706 communicates with the processor 701 and can receive input from the user in multiple ways. For example, the input device 706 may be a mouse, a keyboard, a touchscreen device, or a sensing device.

[0131] The communication device 70 is sometimes also called a communication device and may be a general-purpose device or a dedicated device. For example, the communication device 70 may be a desktop computer, a portable computer, a network server, a personal digital assistant (PDA), a mobile phone, a tablet computer, a wireless terminal device, an embedded device, the above-mentioned terminal device, the above-mentioned network device, or a device having a structure similar to that of Figure 7. The type of communication device 70 is not limited in this embodiment of the present application.

[0132] Optionally, Figure 8 is a schematic diagram of the hardware structure of the UE. As shown in Figure 8, in some embodiments, the structure of the UE may be shown in Figure 8. The UE may include a processor 710, an external memory interface 720, internal memory 771, a universal serial bus (USB) interface 730, a charge management module 740, a power management unit 741, a battery 742, an antenna 1, an antenna 2, a mobile communication module 750, a wireless communication module 760, an audio module 770, a speaker 770A, a receiver 770B, a microphone 770C, a headset jack 770D, a sensor module 780, a key 790, a motor 791, an indicator 792, a camera 793, a display 794, a subscriber identification module (SIM) card interface 795, and so on. The sensor module 780 may include a pressure sensor 780A, a gyroscope sensor 780B, an atmospheric pressure sensor 780C, a magnetic sensor 780D, an acceleration sensor 780E, a distance sensor 780F, an optical proximity sensor 780G, a fingerprint sensor 780H, a temperature sensor 780J, a touch sensor 780K, an ambient light sensor 780L, a bone conduction sensor 780M, and the like.

[0133] It should be understood that the structures shown in this embodiment do not constitute a specific limitation on the UE. In some other embodiments, the UE may include more or fewer parts than those shown, some parts may be combined, some parts may be separated, or different sub-arrangements may be used. The illustrated parts may be implemented by hardware, software, or a combination of software and hardware.

[0134] The processor 710 may include one or more processing units. For example, the processor 701 may include an application processor (AP), a modem, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent components or may be combined into one or more processors.

[0135] The charging management module 740 is configured to receive a charging input from the charger. The charger may be a wireless charger or a wired charger.

[0136] The power management module 741 is configured to connect to the battery 742, the charge management module 740, and the processor 710. The power management module 741 receives input from the battery 742 and / or the charge management module 740 and supplies power to the processor 710, internal memory 771, display 794, camera 793, wireless communication module 760, etc.

[0137] The wireless communication function of the UE may be implemented by using antenna 1, antenna 2, mobile communication module 750, wireless communication module 760, modem, baseband processor, etc.

[0138] Antennas 1 and 2 are configured to transmit and receive electromagnetic wave signals. Each antenna of the UE may be configured to cover one or more communication frequency bands. Different antennas may be further multiplexed to improve antenna utilization.

[0139] The 750 mobile communication module provides wireless communication solutions, including 2G / 3G / 4G / 5G, that are applicable to UEs.

[0140] The wireless communication module 760 may provide wireless communication solutions applicable to the UE, including wireless local area networks (WLAN) (e.g., wireless fidelity (Wi-Fi) network), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near-field communication (NFC) technology, infrared (IR) technology, and others. The wireless communication module 760 may be one or more components incorporating at least one processing module. The wireless communication module 760 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering on the electromagnetic wave signal, and sends the processed signal to processor 710. The wireless communication module 760 may further receive a signal to be transmitted from processor 710, perform frequency modulation and amplification on the signal, and convert the signal into an electromagnetic wave signal for radiation through antenna 2.

[0141] In this embodiment of the present application, the wireless communication module 760 may be used by the UE to send a request to a network node to resume the RRC connection and to receive a response message from the network node.

[0142] The UE implements display functionality by using components such as the GPU, Display 794, and application processor. The GPU is a microprocessor for image processing and is connected to the Display 794 and application processor.

[0143] Display 794 is configured to display images, videos, etc. A set of graphical user interfaces (GUIs) may be displayed on the UE's display 794.

[0144] The UE can implement shooting capabilities by using an ISP, camera 793, video codec, GPU, display 794, application processor, etc.

[0145] Camera 793 is configured to capture still images or video.

[0146] The external memory interface 720 may be configured to connect to an external memory card, such as a Micro SD card, in order to expand the storage capacity of the UE.

[0147] The internal memory 771 may be configured to store computer executable program code. The executable program code includes instructions. The processor 710 executes the instructions stored in the internal memory 771 to perform various functional applications and data processing of the UE.

[0148] The UE may implement audio functions, such as music playback and recording, by using an audio module 770, a speaker 770A, a receiver 770B, a microphone 770C, a headset jack 770D, an application processor, etc. The UE may further include a pressure sensor 780A, an atmospheric pressure sensor 780C, a gyroscope sensor 780B, a magnetic sensor 780D, an accelerometer 780E, a distance sensor 780F, an optical proximity sensor 780G, an ambient light sensor 780L, a fingerprint sensor 780H, a temperature sensor 780J, a touch sensor 780K, a bone conduction sensor 780M, a key 790, a motor 791, an indicator 792, etc.

[0149] The SIM card interface 795 is configured to connect to a SIM card. The SIM card can be inserted into or removed from the SIM card interface 795 to connect to and disconnect from the UE. The UE can support one or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 795 can support Nano SIM cards, Micro SIM cards, SIM cards, etc. Multiple cards may be inserted into the same SIM card interface 795 simultaneously. The SIM card interface 795 is also compatible with external memory cards. The UE interacts with the network by using the SIM card to implement functions such as phone calls and data communications.

[0150] Furthermore, an operating system, such as the Harmony® operating system, the iOS® operating system, the Android® operating system, or the Windows® operating system, runs in the above portion. Application programs may be installed and run on the operating system. In some other embodiments, multiple operating systems may run on the UE.

[0151] It should be understood that the hardware modules included in the UE shown in Figure 8 are merely illustrative examples and do not constitute a limitation on the specific structure of the UE. In fact, the UE provided in this embodiment of the present application may further include other hardware modules that interact with the illustrated hardware modules. This is not particularly limited here. For example, the UE may further include a flash or microprojection device. Another example is when the UE is a PC, in which case the UE may further include components such as a keyboard and mouse.

[0152] Referring to Figures 1 to 8, the SDT event recording method provided in the embodiments of the present application is described below. The devices in the following embodiments may include the parts shown in Figure 8. The operations, terminology, etc., in the embodiments of the present application may be cross-referenced, but are not limited thereto. In the embodiments of the present application, the names of messages exchanged between devices or the names of parameters within messages are illustrative only. Other names may be used in specific implementations, but are not limited thereto.

[0153] In possible embodiments, an example is used in which the network device providing services to a terminal device is a serving base station, and the terminal device is an UE. A flowchart of the SDT event logging method provided in embodiments of the present application may be shown in Figure 9. Referring to Figure 9, the SDT event logging method may include the following steps.

[0154] Step 901: The serving base station sends a log measurement configuration message to the UE, which carries a first parameter set, the first parameter set containing one or more parameters for logging transmission status information when the UE performs SDT (during the SDT period).

[0155] For example, in a log measurement configuration message, the first parameter set may be the SmallDataTransmission-r18 log field.

[0156] Optionally, the log measurement configuration message may further carry MDT measurement configuration information that can be used by the UE to perform MDT-related measurements. For specific information that may be included in the MDT measurement configuration information, please refer to existing standards or protocols. Further details are not provided here.

[0157] In this embodiment of the present application, step 901 is performed by the serving base station after the distribution of MDT measurement configuration information is triggered. Also, when the serving base station performs step 901, the UE must be in a connected state.

[0158] It should be noted that the mechanism for triggering a serving base station to distribute MDT measurement configuration information is not limited to this embodiment of the present invention. Optionally, a core network device may trigger a serving base station to distribute MDT measurement configuration information. For example, an AMF or UPF sends a trace start message to the serving base station. Alternatively, a network management platform may trigger a serving base station to distribute MDT measurement configuration information. Alternatively, a serving base station may trigger the distribution of MDT measurement configuration information, and so on.

[0159] Furthermore, it should be noted that the occasions on which a serving base station receives a trigger message to trigger it to distribute MDT measurement configuration information are not limited in this application. That is, the occasions on which a serving base station receives a trigger message are independent of the state of the UE. A serving base station may receive a trigger message when the UE is in one of the following states: connected, inactive, or idle. However, the occasions on which a serving base station sends MDT measurement configuration information to the UE are related to the state of the UE. When a serving base station sends MDT measurement configuration information to the UE, the UE must be in the connected state.

[0160] In this embodiment of the present application, one or more parameters included in the first parameter set that instruct the UE to record transmission status information when performing SDT are described below.

[0161] Optionally, the first parameter set may include at least one first parameter used to instruct the UE to record a measured beam signal of a serving cell when setting up a CG-SDT resource. A CG-SDT resource is a CG resource used by the UE to transmit data or signaling in a CG-SDT procedure. For example, based on the first parameter, the UE may record a measured signal value obtained by measuring the beam of a serving cell when the CG-SDT resource is set up, i.e., a reference signal receiving power (RSRP) beam index synchronization signal block (SSB), i.e., RSRP-index[n]-SSB, where n represents the index value of the beam.

[0162] After receiving a log measurement configuration message containing the first parameter, the UE may record measurements obtained by measuring the beam signal of the serving cell when configuring the CG resources used for SDT.

[0163] Optionally, the first parameter set may include at least one second parameter, which is used to instruct the system to log events that occur when the UE performs CG-SDT and / or RACH-SDT. Hereafter, events that occur when the UE performs CG-SDT will be abbreviated as CG-SDT events (CG-SDT events), and events that occur when the UE performs RACH-SDT will be abbreviated as RACH-SDT events (RACH-SDT events). For example, the second parameter may instruct the system to log a CG-SDT failure event for the UE. A CG-SDT failure event may, alternatively, be understood as a reason for CG-SDT failure.

[0164] Optionally, the second parameter may be used to instruct the system to log one or more of the following CG-SDT failure events.

[0165] 1. After sending uplink data to the serving base station on the CG resource, the UE does not receive feedback information used as a response from the serving base station. For example, the UE does not receive an L1 feedback message (no L1 feedback).

[0166] 2. When the UE transmits uplink data to the serving base station on the CG resource, the signal value of the selected cell (serving cell) is smaller than a pre-set threshold, or the signal value of the selected beam (serving beam) is smaller than a pre-set threshold.

[0167] 3. The number of times the UE sends data to the serving base station on the CG resource reaches the maximum number of retransmissions. The maximum number of retransmissions may be set by the serving base station to the UE using an RRC message, or the maximum number of retransmissions may be predefined in the UE.

[0168] 4. After sending Layer 3 (L3) messages and data to the serving base station on the CG resource, the UE activates the CG-SDT timer and does not receive any acknowledgment messages, Layer 2 (L2) messages, L3 messages, or scheduled downlink data that have been fed back by the serving base station before the CG-SDT timer expires.

[0169] For example, an L3 message sent by the UE to the serving base station may be a media access control layer control element (MAC CE), and an L2 message that needs to be fed back by the serving base station may be an acknowledgment message of the MAC CE.

[0170] Specifically, if the second parameter instructs the system to log a failure event, the UE may monitor the physical downlink control channel (PDCCH) to receive signaling or downlink data from the serving base station after sending an L3 message and data on the CG resource and activating the CG-SDT timer. If the UE does not receive the corresponding acknowledgment signaling, L2 message, L3 message, or downlink data, the UE logs a failure event.

[0171] 5. The Timing Advance (TA) Timer expires, and the CG resources become unavailable.

[0172] Specifically, if the second parameter instructs the system to log a failure event, and the UE fails to transmit data on the CU resource after the TA timer expires, the UE may log a failure event, considering that the CG resource cannot continue to be used, i.e., the CG resource is unavailable. Optionally, the TA may be configured by the serving base station using a RAR message sent to the UE.

[0173] After the UE receives a log measurement configuration message containing the second parameter, if an event occurs in the CG-SDT procedure that the second parameter instructs to be logged, the UE may log the corresponding CG-SDT event.

[0174] Optionally, the second parameter may be used to instruct RACH-SDT to log one or more of the following failure events.

[0175] 1. Reasons why a terminal device may not be able to send Msg3 and data to the serving base station: For example, the reason for failure may be that the UE is unable to compete for random access with other UEs, the number of times the UE has sent Msg3 and data has reached the maximum number of retransmissions, or the UE is still unable to send Msg3 and data after the RACH-SDT Timer has expired.

[0176] 2. The number of times the UE failed to send Msg3 and data to the serving base station and / or the total number of times the UE sent Msg3 and data to the serving base station. Here, the total number includes the number of times the transmission of Msg3 and data failed and the number of times the transmission of Msg3 and data was successful.

[0177] After the UE receives a log measurement configuration message containing the second parameter, if an event occurs in the RACH-SDT procedure that the second parameter instructs to be logged, the UE may log the corresponding RACH-SDT event.

[0178] Step 902: The serving base station sends an RRC release message to the UE so that the UE, which is currently in a connected state, enters an inactive state.

[0179] Step 903: The inactive UE decides to perform SDT, and when performing SDT, it obtains the recording results by recording the transmission status information that the parameters included in the first parameter set instruct to be recorded, based on the log measurement configuration message.

[0180] In a feasible implementation, the UE may log and store transmission status information when the UE performs SDT.

[0181] Optionally, if a log measurement configuration message carries MDT measurement configuration information, the UE may perform further relevant MDT measurements and obtain measurement results after entering an inactive state.

[0182] Optionally, after obtaining the recording results, the UE may send the recording results to the serving base station or network management platform. The serving base station or network management platform may determine the transmission status when the UE is performing SDT based on the recording results in order to implement rapid identification when a problem occurs in the UE's SDT procedure. The serving base station or network management platform may further optimize the UE's SDT configuration parameters or configuration resources based on the recording results reported by the UE. For example, based on the recording results from the UE, the serving base station or network management platform may adjust the Config-Ad-Grand Resource Size (CG Resource Size) or distribute supplementary instruction information, such as information indicating whether the UE should transition to an RRC state during the SDT period based on the recording results.

[0183] Based on the SDT event recording method provided in this embodiment of the present application, when performing SDT, the UE may record transmission status information based on instructions from the serving base station to help identify problems occurring during the UE's SDT period and optimize SDT configuration parameters.

[0184] It should be noted that the embodiment shown in Figure 9 is an illustrative description of the SDT event recording method provided herein. In other possible embodiments, the SDT event recording method may include the following steps, as shown in Figure 10.

[0185] Step 1001: The serving base station sends a first message to the UE, which carries a first parameter set containing one or more parameters instructing the UE to log transmission status information when performing SDT. For example, the first message may be a log measurement configuration message.

[0186] Step 1002: When performing SDT, the UE records transmission status information corresponding to the parameters included in the first parameter set.

[0187] The implementation of steps 1001-1002 is similar to that of steps 901-903, and the instructions for steps 901-903 may be referenced.

[0188] Furthermore, in possible implementations, an example is used in which the network device providing services to the terminal device is a serving base station, and the terminal device is an UE. A flowchart of another SDT event logging method provided in embodiments of the present invention may be shown in Figure 11. Referring to Figure 11, the SDT event logging method may include the following steps.

[0189] Step 1101: The serving base station sends a log measurement configuration message to the UE, which carries a second parameter set, which includes one or more parameters instructing the UE to log service characteristic information when performing SDT (during the SDT period).

[0190] In this embodiment of the present application, one or more parameters included in the second parameter set that instruct the UE to record service characteristic information when performing SDT are described below.

[0191] Optionally, a parameter in the second parameter set may instruct the system to record at least one of the following service characteristic information:

[0192] 1. Amount of data cached by the UE during the SDT process (or size of the cache): Optionally, the UE cache that the parameter instructs to record may be cached data at the packet data convergence protocol (PDCP) layer or the radio link control (RLC) layer, or it may be data generated at a higher layer of the UE during the SDT period, e.g., the RRC layer.

[0193] 2. Frequency at which the UE transmits data to the serving base station during the SDT process: For example, the data frequency may be the time interval between adjacent data packets transmitted by the UE to the serving base station during the SDT process.

[0194] 3. Events where data sent by the UE to the serving base station during the SDT process exceeds a pre-set threshold: For example, if SDT fails because data sent by the UE to the serving base station during the SDT process exceeds a pre-set threshold, the UE may log a failure event.

[0195] 4. Frequency of data transmission by the UE to the serving base station in a segment during the SDT process: Specifically, during the SDT process, the UE may record the frequency of data transmission to the serving base station in a segment, based on whether the data to be sent to the serving base station is transmitted in a segment.

[0196] 5. Time and / or frequency at which the UE receives downlink paging messages from the serving base station during the SDT process: Downlink paging messages are used to trigger the UE to receive downlink data during the SDT cycle. For example, the downlink paging message may be an MT-SDT paging message.

[0197] 6. UE movement trajectory information in the SDT process: Optionally, the UE may record its position information in the SDT process in order to record the UE's movement trajectory information during the SDT period.

[0198] 7. Cell signal intensity measured when the UE triggers cell reselection in the SDT process.

[0199] 8. Events in which the UE switches from the original network (which may be called the first network) to another network (which may be called the second network) in a multi-subscriber identity module (Multi-SIM) scenario during the SDT process: for example, the first network may be operator A's network and the second network may be operator B's network. The UE may log an event if a parameter in the second parameter set instructs it to log the event, and the UE switches from operator A's network to operator B's network during the SDT process.

[0200] 9. Reasons why the UE enters an idle state: For example, a reason why the UE enters an idle state may be that the UE triggers a radio link failure (RLF) event, or that the UE triggers a cell reselection.

[0201] 10. Reasons why the UE terminates the SDT session, or why the UE terminates SDT: For example, a reason why the UE terminates the SDT session may be that the serving base station sends a first instruction message to the UE to trigger the UE to terminate the SDT session, instructing the terminal device to enter an idle or inactive state. For example, the first instruction message may be an RRC release message. Alternatively, the reason may be that the UE's SDT timer (SDT Timer) expires, causing the UE to terminate the SDT session and enter an idle state.

[0202] 11. Events that trigger the UE to request the resumption of the RRC connected state during the UE's SDT process: Optionally, the UE may send an RRC resume request message to the serving base station to request the resumption of the RRC connected state. The RRC resume request message is a second RRC resume request message (second RRC ResumeRequest) sent by the UE after the RRC resume request message (Msg3) sent with data after the UE triggers the SDT. Alternatively, the UE may send a newly defined RRC message to the serving base station to request the resumption of the RRC connected state.

[0203] Optionally, events that trigger the UE to request the resumption of the RRC connected state may include at least one of the following:

[0204] Non-SDT services arrive at the UE, the UE triggers cell selection or cell re-selection, and in a multi-SIM scenario, the UE returns from another network to the first network. Non-SDT services are services that cannot be transmitted using SDT procedures.

[0205] 12. Relevant information that exists when the UE returns to the first network from another network in a multi-SIM scenario: For example, the relevant information may include information such as the time and reason when the UE returns to the first network from another network. This information may also be called information such as the time and reason for the switching type.

[0206] Step 1102: The serving base station sends an RRC release message to the UE so that the UE, which is currently in a connected state, enters an inactive state.

[0207] Step 1103: The UE, which is in an inactive state, decides to perform SDT, and when performing SDT, it records service characteristic information corresponding to the parameters included in the second parameter set based on the log measurement configuration message, and obtains the recording results.

[0208] In a feasible implementation, the UE may log and store service characteristic information as it performs SDT.

[0209] Optionally, if a log measurement configuration message carries MDT measurement configuration information, the UE may perform further relevant MDT measurements and obtain measurement results after entering an inactive state.

[0210] Optionally, after obtaining the recording results, the UE may transmit the recording results to the serving base station or network management platform. The serving base station or network management platform may determine the service status when the UE performs SDT based on the recording results and implement rapid identification if problems occur in the UE's SDT procedure. The serving base station or network management platform may further optimize the UE's SDT configuration parameters or configuration resources based on the recording results reported by the UE. For example, based on the recording results from the UE, the serving base station or network management platform may adjust the CG grant size or deliver auxiliary instruction information such as information indicating whether the UE will transition RRC states during the SDT cycle.

[0211] Based on the SDT event recording method provided in this embodiment of the present application, when performing SDT, the UE may record service characteristic information of the UE based on instructions from the serving base station to help identify problems occurring during the UE's SDT cycle and optimize SDT configuration parameters.

[0212] It should be noted that the embodiment shown in Figure 11 is an illustrative description of the SDT event recording method provided herein. In other possible embodiments, the SDT event recording method may include the following steps, as shown in Figure 12.

[0213] Step 1201: The serving base station sends a second message to the UE, which carries a second parameter set containing one or more parameters instructing the UE to log service characteristic information when performing SDT. For example, the second message may be a log instrument configuration message.

[0214] Step 1202: When performing SDT, the UE records service characteristic information corresponding to the parameters included in the second parameter set.

[0215] The implementation of steps 1201-1202 is similar to that of steps 1101-1103, and the descriptions of steps 1101-1103 may be referenced.

[0216] In addition, in possible embodiments, an example is used in which the network device providing services to a terminal device is a serving base station, and the terminal device is a UE. A flowchart of another SDT event logging method provided in embodiments of the present application may be shown in Figure 13. Referring to Figure 13, the SDT event logging method may include the following steps.

[0217] Step 1301: The UE receives a log measurement configuration message from the serving base station, which is used to instruct the UE to log SDT events and / or measure MDT configuration parameters.

[0218] Optionally, log measurement configuration messages can be carried in RRC release messages and sent to the UE.

[0219] For SDT events that instruct the UE to record a log measurement setting message, refer to the transmission status information in step 901 and / or the service characteristics information in step 1101.

[0220] Step 1302: The UE triggers the SDT procedure, the SDT timer starts, and the UE begins recording relevant SDT events occurring in the SDT process based on the instructions of the log measurement configuration message, and / or performs measurements based on the relevant MDT configuration parameters to obtain measurement results based on the MDT configuration parameters (hereinafter simply referred to as measurement results), and records the measurement results to obtain a recording result, in which case the recording result includes the SDT events and / or measurement results recorded by the UE. One recorded SDT event or one measurement result may be one record in the recording result.

[0221] In this embodiment of the present application, the process by which the UE records SDT events and / or measurement results in the SDT process may be referred to as Logged SDT-MDT measurement. Accordingly, the recorded results obtained by the UE may be referred to as Logged SDT-MDT recorded results.

[0222] Step 1303: The UE terminates recording of SDT events and / or measurement results.

[0223] In this embodiment of the present application, the UE may terminate the recording of SDT events and / or measurement results after the UE's SDT session has ended.

[0224] For example, the termination of an UE's SDT session can be triggered in the following ways: The UE receives an RRC release message from the serving base station. Alternatively, the UE transitions from an inactive state to an RRC connected state. For example, the UE sends an RRC resume request to the serving base station to request the resumption of the RRC connected state. Alternatively, the SDT timer expires.

[0225] Step 1304: The UE determines whether the Logged SDT-MDT recording results are available.

[0226] In a possible implementation, when the number of records included in the acquired Logged SDT-MDT recording results reaches a certain threshold, the UE can consider the acquired recording results to be available. Optionally, the threshold that the number of records must reach may be set for the UE by the serving base station or predefined by the UE.

[0227] In other possible implementations, the UE may consider the acquired logged SDT-MDT log result available if the value of at least one record included in the acquired logged SDT-MDT log result reaches a corresponding specific threshold. For example, the logged SDT-MDT log result acquired by the UE includes the amount of data cached in the SDT process and recorded by the UE. If the amount of recorded data cached in the SDT process is greater than the corresponding pre-set threshold, for example, the corresponding pre-set threshold may be 100 bits, the UE may consider the acquired log result available.

[0228] Step 1305: If the UE determines that the recording results are available, it sends the recording results to the serving base station.

[0229] The specific implementation of how the UE sends the recorded results to the serving base station is described below.

[0230] In possible implementations, the UE may send a fourth message to the serving base station indicating that logging results are available or that available logging instructions exist on the terminal device. For example, the fourth message may be carried in an RRC resume request message or an RRC setup request message. An RRC setup request message is used to request the establishment of an RRC connection. For example, the instruction information indicating that logging results are available may be Logged-SDT-MDT Available information. The serving base station may determine whether the UE needs to report logging results by determining, based on the instruction information sent by the UE, that the terminal device has obtained available logging results, in order to determine whether the UE needs to report logging results. Optionally, if the serving base station determines that the UE needs to report logging results, the serving base station may send a second instruction information to the UE instructing the UE to report logging results. After receiving the second instruction information, the UE may send logging results to the serving base station based on the instructions in the second instruction information.

[0231] In other possible implementations, the UE may transmit to the serving base station the recording results obtained after the last SDT has finished in each SDT cycle (past recording results). Optionally, past results may be carried in RRC messages or MAC layer messages. For example, when transitioning from an inactive state to a connected state, the UE may add the recording results of the last SDT to an RRC resume completion message to be sent to the serving base station. Optionally, the message to which past recording results should be carried may be instructed to the UE by the serving base station using instructional or configuration information sent to the UE.

[0232] In yet another possible implementation, the serving base station proactively sends a third instruction message to the UE instructing the UE to report the recording results. After receiving the third instruction message, the UE sends the recording results to the serving base station based on the third instruction message. For example, the serving base station may add information such as identification information, fields, or parameters used to request the reporting of the recording results to the UE information request message that should be sent to the UE. After receiving the UE information request message sent by the serving base station, the UE adds the recording results acquired during the SDT period to the UE information response message that should be sent to the serving base station, based on the identification information used to request the reporting of the recording results.

[0233] It should be noted that the embodiment shown in Figure 13 is an illustrative description of the SDT event recording method provided herein. In other possible embodiments, the SDT event recording method may include the following steps, as shown in Figure 14.

[0234] Step 1401: The serving base station sends a third message to the UE, which is used to instruct the UE to log SDT events and / or measure MDT configuration parameters. For example, the third message may be a log measurement configuration message.

[0235] Step 1402: When performing SDT, the UE records the SDT event and measurement results based on the third message in order to obtain the recording results.

[0236] Step 1403: The UE sends the recording results to the serving base station.

[0237] Optionally, before step 1403, the UE may further include step 1402.1 in which it determines whether recording results are available based on the number of recorded SDT events and / or the number of measured MDT configuration parameters. If it determines that recording results are available, the UE performs step 1403. Otherwise, step 1403 is not performed.

[0238] The implementation of steps 1401-1403 is similar to that of steps 1301-1305, and the descriptions of steps 1301-1305 may be referenced.

[0239] It should be noted that in the embodiment of the above method, the operation of the network device may be performed by calling the application program code stored in memory 704, which in turn commands the serving base station via the processor 701 in the communication device 70 shown in Figure 7, and the operation of the terminal device may be performed by calling the application program code stored in memory 704, which in turn commands the terminal device via the processor 701 in the communication device 70 shown in Figure 7.

[0240] It may be understood that the methods and / or steps performed by a network device or terminal device in the embodiments of the above method may, alternatively, be performed by a part (e.g., a chip or circuit) that can be used in the network device or terminal device.

[0241] Optionally, embodiments of the present application further provide communication devices. These communication devices are configured to carry out the methods described above. The communication devices may be a network device or terminal device, a device including a network device or terminal device, or a part that can be used in a network device or terminal device, in embodiments of the methods described above. To implement the above functions, it may be understood that the communication devices include corresponding hardware structures and / or software modules for performing the functions. Those skilled in the art will readily understand that the exemplary units, algorithms, and steps described with reference to the embodiments disclosed herein can be implemented in hardware or in combination of hardware and computer software. Whether the functions are performed in hardware or by hardware driven by computer software depends on the specific application and design constraints of the technical solution. Those skilled in the art may implement the described functions using different methods for each specific application, but it should not be conceivable that the implementation would exceed the scope of the present application.

[0242] In embodiments of the present application, the communication device may be divided into functional modules based on the embodiments of the method described above. For example, each functional module may be obtained by division based on its respective corresponding function, or two or more functions may be integrated into a single processing module. The integrated module may be implemented in hardware form or in the form of a software functional module. It should be noted that in embodiments of the present application, the division into modules is merely an example and represents only a logical functional division. In actual implementation, other division patterns may be used.

[0243] Figure 15 is a schematic diagram of the structure of the communication device 150. The communication device 150 includes a processing module 1501 and a transceiver module 1502. The transceiver module 1502 is also called a transceiver unit and can implement transceiver functions, and may be, for example, a transceiver circuit, a transceiver machine, a transceiver, or a communication interface.

[0244] For example, the communication device 150 is a terminal device in the embodiment of the above method.

[0245] In a possible implementation, the transceiver module 1502 may be configured to receive a first message from a network device. The first message includes a first parameter set, which includes one or more parameters for recording transmission characteristic information within the SDT period. The processing module 1501 may be configured to record transmission characteristic information corresponding to one or more parameters in the first parameter set based on the first message.

[0246] Optionally, the first parameter set includes at least one first parameter, which is used to instruct the system to record measurements of the serving cell's beam signal.

[0247] Optionally, the SDT includes a config-grant-small data transmission CG-SDT or a random access channel-small data transmission RACH-SDT, where the first parameter set includes at least one second parameter, the second parameter being used to instruct the CG-SDT to record events and / or RACH-SDT events.

[0248] Optionally, the CG-SDT events are as follows: After sending data to a network device on a CG resource, the terminal device does not receive feedback information. When a terminal device transmits data to a network device on a CG resource, the signal value of the target cell must be smaller than a pre-set threshold, or the signal value of the target beam must be smaller than a pre-set threshold. The number of times a terminal device sends data to a network device on a CG resource reaches the maximum number of retransmissions. If, after sending Layer 3 L3 messages and / or data to a network device on a CG resource, the terminal device activates the CG-SDT timer, and before the CG-SDT timer expires, it fails to receive an acknowledgment message, Layer 2 L2 message, L3 message, or scheduled data from the network device, or, The terminal device's timing advance TA timer expires, rendering CG resources unavailable. Includes one or more of the following.

[0249] Optionally, the aforementioned RACH-SDT event is: Reasons why the terminal device cannot send Msg3 and data to the network device, or The number of times the terminal device failed to send Msg3 and data to the network device and / or the total number of times the terminal device sent Msg3 and data to the network device. This includes one or more of the following. The total number of attempts includes the number of times Msg3 and data transmission failed and the number of times Msg3 and data transmission was successful.

[0250] In other possible implementations, the transceiver module 1502 may be configured to receive a second message from a network device. The second message includes a second parameter set, which includes one or more parameters instructing the recording of service characteristic information for the SDT period. The processing module 1501 may be configured to record service information corresponding to each parameter in the second parameter set based on the first message.

[0251] Optionally, the service characteristics information is as follows: The terminal device's cache, the frequency with which the terminal device sends data to the network device, whether the data sent by the terminal device to the network device exceeds a pre-configured threshold, the frequency with which the terminal device transmits data to the network device within a segment, the time and / or frequency with which the terminal device receives MT-SDT messages from the network device, the terminal device's movement trajectory, the signal strength of the cell re-selected by the terminal device, the event that causes the terminal device to switch from the first network to the second network in a Multi-SIM scenario, the reason why the terminal device enters an idle state, the reason why the terminal device terminates an SDT session, and the event that triggers the terminal device to request the network device to resume the Radio Resource Control (RRC) connected state. It includes at least one of the following.

[0252] Optionally, reasons for a terminal device to enter an idle state include the terminal device triggering a wireless link failure or the terminal device triggering cell reselection.

[0253] Optionally, the reasons for a terminal device to terminate an SDT session include the terminal device receiving a first instruction message from a network device used to instruct the terminal device to enter an idle or inactive state, or the terminal device's SDT timer expiring.

[0254] Optionally, events that trigger a terminal device to request a network device to resume the Radio Resource Control (RRC) connected state include at least one of the following: an arrival of a non-SDT service, the terminal device triggering cell selection or cell reselection, and the terminal device switching from a second network to a first network in a multi-SIM scenario.

[0255] Optionally, the second message is a measurement record setting message.

[0256] In yet another possible implementation, the transceiver module 1502 may be configured to receive a third message from a network device. The third message is used to instruct the terminal device to record an SDT event and / or measure the drive test minimize MDT configuration parameters. Based on the third message, the processing module 1501 records the measurement results and / or SDT event based on the MDT configuration parameters to obtain recording results. The transceiver module 1502 may be further configured to transmit the recording results to the network device.

[0257] Optionally, the third message is a measurement record setting message.

[0258] Optionally, the transceiver module 1502 is configured to send a fourth message to a network device, which is used to indicate that the terminal device has obtained available recording results or that there are available recording instructions on the terminal device; to receive a second instruction message from the network device, which is used to instruct the terminal device to send the recording results to the network device; and to send the recording results to the network device based on the second instruction message.

[0259] Optionally, the fourth message is carried as a radio resource control (RRC) resume request message or an RRC setup request message.

[0260] Optionally, the transceiver module 1502 is specifically configured to transmit past recording results obtained after the last SDT has ended to the network device during each SDT period.

[0261] Optionally, past record results are carried in RRC messages or MAC layer messages.

[0262] Optionally, the transceiver module 1502 is configured to receive a third instruction message from a network device, which is used to instruct a terminal device to send recording results to the network device, and to send recording results to the network device based on the third instruction message.

[0263] Optionally, the third instruction message is a terminal information request message, and the recording result is carried in a terminal information response message.

[0264] Optionally, the terminal device's SDT timer may start operating before the processing module 1501 records the measurement results and / or SDT events based on the MDT setting parameters, based on the third message.

[0265] Optionally, the processing module 1501 is configured to record measurement results and / or SDT events based on the MDT setting parameters based on the third message, stop recording measurement results and / or SDT events based on the MDT setting parameters when the SDT timer expires, and acquire recording results based on the measurement results and / or SDT events based on the MDT setting parameters recorded within the operating period of the SDT timer.

[0266] Optionally, the processing module 1501 is configured to record measurement results and / or SDT events based on the MDT setting parameters based on the third message, and to stop recording measurement results and / or SDT events based on the MDT setting parameters when the SDT session ends, and to acquire recording results based on the recorded measurement results and / or recorded SDT events based on the MDT setting parameters.

[0267] Optionally, the recording results transmitted to the network device by the transceiver module 1502 are available recording results, which are determined by the processing module 1501 based on the number of recorded measurement results and / or the number of recorded SDT events, according to the MDT setting parameters.

[0268] For example, the communication device 150 is a network device in the embodiment of the above method.

[0269] In a possible implementation, the transceiver module 1502 may be configured to transmit a first message to the terminal device. The first message includes a first parameter set, and the first parameter set includes one or more parameters for recording transmission characteristic information within the SDT period.

[0270] In another possible implementation, the transceiver module 1502 may be configured to transmit a second message to the terminal device. The second message includes a second parameter set, and the second parameter set includes one or more parameters for instructing to record service characteristic information within the SDT period.

[0271] In yet another possible implementation, the transceiver module 1502 may be configured to transmit a third message to the terminal device. The third message is used to instruct the terminal device to record SDT events and / or measure drive test minimization (MDT) setting parameters. The transceiver module 1502 may be further configured to receive the recording results from the terminal device.

[0272] Note that all relevant contents of the steps in the embodiment of the above method can be cited in the function descriptions of the corresponding functional modules. Details are not described again here. The communication device 150 provided in this embodiment can execute the SDT event recording method. Therefore, for the technical effects that can be achieved by the communication device 150, refer to the embodiment of the above method. Details are not described again here.

[0273] Optionally, the network device or terminal device in this embodiment of the present application may also be called a communication device. The network device or terminal device may be a general-purpose device or a dedicated device. This is not particularly limited in this embodiment of the present application.

[0274] In this embodiment, the communication device 150 is presented in an integrated form, with each functional module acquired by division. Here, “module” may refer to a specific ASIC, circuit, processor and memory, integrated logic circuit, and / or other device capable of providing the above functions, which executes one or more software or firmware programs. In a simple embodiment, those skilled in the art can conceive that the communication device 150 may take the form of the communication device 70 shown in Figure 7.

[0275] For example, the processor 701 in the communication device 70 shown in Figure 7 may call a computer executable instruction stored in memory 704 to enable the communication device 70 to execute the SDT event recording method in the embodiment of the above method.

[0276] Specifically, the functions / implementation processes of the processing module 1501 and transceiver module 1502 in Figure 15 can be implemented by the processor 701 in the communication device 70 shown in Figure 7 calling computer executable instructions stored in memory 704. Alternatively, the functions / implementation processes of the processing module 1501 in Figure 15 may be implemented by the processor 701 in the communication device 70 shown in Figure 7 calling computer executable instructions stored in memory 704, and the functions / implementation processes of the transceiver module 1502 in Figure 15 may be implemented by using the communication interface 703 in the communication device 70 shown in Figure 7.

[0277] The communication device 150 provided in this embodiment can perform an SDT event recording method. Therefore, for technical effects that can be achieved by the communication device 150, please refer to the embodiments of the method described above. Further details are not described here again.

[0278] It should be understood that the sequence numbers of the processes described above do not represent the execution order of the various embodiments of the present application. The execution order of the processes should be determined based on the function and internal logic of the processes and should not constitute any limitation to the implementation of the embodiments of the present application.

[0279] Those skilled in the art will notice that the exemplary units, algorithms, and steps described with reference to the embodiments disclosed herein can be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are performed by hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may implement the described functions using different methods for each specific application, but it should not be conceivable that the implementation would exceed the scope of this application.

[0280] Those skilled in the art will understand that, for convenience and for the sake of concise description, the detailed operating processes of the systems, apparatus, and units described above should be referred to by the corresponding processes in the embodiments of the methods described above. Further details are not described here.

[0281] It should be understood that in some embodiments provided herein, the disclosed systems, devices, and methods may be implemented in other ways. For example, the embodiments of the devices described above are merely examples. For example, division into units may be used. For example, multiple units or components may be coupled or integrated into other systems, or some features may be ignored or not implemented. Also, the mutual coupling, direct coupling, or communication connection shown or discussed may be implemented by using some interfaces. Indirect coupling or communication connection between devices or units may be implemented electronically, mechanically, or in other forms.

[0282] Units described as separate parts may or may not be physically separated, and parts 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 may be selected according to the actual requirements to achieve the objectives of the solution in the embodiment.

[0283] Furthermore, the functional units in the embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically independently, or two or more units may be integrated into a single unit.

[0284] All or part of the embodiments described above may be implemented using software, hardware, firmware, or any combination thereof. If a software program is used to implement the embodiments, all or part of the embodiments may be implemented in the form of a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded into a computer and executed, all or part of the procedures or functions according to the embodiments of the present application are generated. The computer may be a general-purpose computer, a dedicated computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions may be transmitted from one website, computer, server, or data center to another website, computer server, or data center by wired means (e.g., coaxial cable, optical fiber, or digital subscriber line (DSL)) or wireless means (e.g., infrared, radio waves, or microwaves). Computer-readable storage media may be any usable medium accessible by a computer, or a data storage device incorporating one or more usable media, such as a server or data center. Usable media may be magnetic media (e.g., floppy disks, hard disks, or magnetic tapes), optical media (e.g., DVDs), semiconductor media (e.g., solid state disks (SSDs)), etc.

[0285] The terms “component,” “module,” and “system” as used in this application are intended to refer to computer-related entities. Computer-related entities may be hardware, firmware, combinations of hardware and software, software, or the execution of software. For example, a component may be, but is not limited to, a process executed on a processor, a processor, an object, an executable file, an executed thread, a program, and / or a computer. In the example, both an application executed on a computing device and a computing device can be components. One or more components may reside in an executed process and / or thread, and components may be located on one computer and / or distributed between two or more computers. Furthermore, these components may be executed from various computer-readable media storing various data structures, for example, signals having one or more data packets (e.g., data from components that interact with other components in a local or distributed system and / or interact with other systems by using signals over a network such as the Internet).

[0286] All aspects, embodiments, or features are presented herein by describing systems that may include multiple devices, components, modules, etc. It should be recognized and understood that each system may include other devices, components, modules, etc., and / or may not include all of the devices, components, modules, etc. described with reference to the accompanying drawings. Furthermore, combinations of these solutions may be used.

[0287] In addition, in the embodiments of this application, the term “example” is used to mean providing an example, illustration, or description. No embodiment or design solution described as “example” in this application should be described as being more preferable or having more advantages than other embodiments or design solutions. Indeed, the use of the term “example” is intended to concretely present a concept.

[0288] In the embodiments of this application, “information,” “signal,” “message,” and “channel” are sometimes used synonymously. Note that unless the differences between “information,” “signal,” “message,” and “channel” are emphasized, the meanings expressed by these terms are consistent. “Of,” “corresponding or relevant,” and “corresponding” are sometimes used synonymously. Note that unless the differences between “of,” “corresponding or relevant,” and “corresponding” are emphasized, the meanings expressed by these terms are consistent. “System” and “network” are sometimes used synonymously. Unless the differences between “system” and “network” are emphasized, the meanings expressed by these terms are consistent. For example, “communication network” refers to “communication system.”

[0289] The network architectures and service scenarios described in the embodiments of this application are intended to provide a clearer description of the technical solutions in the embodiments of this application and do not constitute a limitation on the technical solutions provided in the embodiments of this application. Those skilled in the art will see that, with the evolution of network architectures and the emergence of new service scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0290] The above description merely describes a specific implementation of the present application and is not intended to limit the scope of protection of the present application. Various modifications or substitutions that a person skilled in the art can easily conceive within the technical scope disclosed in the present application should fall within the scope of protection of the present application. Accordingly, the scope of protection of the present application should be subject to the scope of protection of the claims.

[0291] This application claims priority to Chinese Patent Application No. 202210612738.8, filed with the China National Intellectual Property Administration on 31 May 2022, with the title of the invention being "SDT EVENT RECORDING METHOD, APPARATUS, AND STORAGE MEDIUM," which is incorporated herein by reference in its entirety.

Claims

1. A method for recording small data transmission (SDT) events, The receiving of a first message by a terminal device from a network device, wherein the first message is a measurement record setting message, and the first message includes a first parameter set, wherein the first parameter set includes one or more parameters for recording transmission characteristic information during the SDT period, The terminal device records the transmission characteristics information corresponding to one or more parameters in the first parameter set based on the first message. It has, The first parameter set includes at least one first parameter, which is used to instruct the recording of a measurement of the beam signal of the serving cell, or The SDT includes a config grant-small data transmission (CG-SDT) or a random access channel-small data transmission (RACH-SDT), wherein the first parameter set includes at least one second parameter, which is used to instruct the recording of CG-SDT events and / or RACH-SDT events, the CG-SDT events including the timing advance (TA) timer of the terminal device expiring and CG resources becoming unavailable. method.

2. The aforementioned CG-SDT event is as follows: If, after sending data to the network device on the CG resource, the terminal device does not receive feedback information, When the terminal device transmits data to the network device on the CG resource, the signal value of the target cell is smaller than a pre-set threshold, or the signal value of the target beam is smaller than a pre-set threshold. The number of times the terminal device transmits data to the network device on the CG resource reaches the maximum number of retransmissions, or, After sending Layer 3 (L3) messages and / or data to the network device on the CG resource, the terminal device activates the CG-SDT timer, and before the CG-SDT timer expires, it fails to receive an acknowledgment message, Layer 2 (L2) message, L3 message, or scheduled data from the network device. Including one or more of the following: The method according to claim 1.

3. The aforementioned RACH-SDT event is as follows: Reasons why the terminal device cannot send Msg3 and data to the network device, or The number of times the terminal device failed to send Msg3 and data to the network device and / or the total number of times the terminal device sent Msg3 and data to the network device. Includes one or more of the following: The aforementioned total number includes the number of times Msg3 and data transmission failed and the number of times Msg3 and data transmission was successful. The method according to claim 1.

4. A method for recording small data transmission (SDT) events, The receiving of a second message by a terminal device from a network device, wherein the second message is a measurement record setting message, and the second message includes a second parameter set, the second parameter set includes one or more parameters that instruct the recording of service characteristic information during the SDT period, The terminal device records service information corresponding to each parameter in the second parameter set based on the second message. It has, The service characteristic information includes the reason why the terminal device terminates the SDT session, and the reason why the terminal device terminates the SDT session includes the terminal device receiving a first instruction message from the network device used to instruct the terminal device to enter an idle or inactive state, or the terminal device's SDT timer expiring. method.

5. The aforementioned service characteristics information is as follows: The cache of the terminal device, the frequency with which the terminal device transmits data to the network device, whether the data transmitted by the terminal device to the network device exceeds a preset threshold, the frequency with which the terminal device transmits data to the network device in a segment, the time and / or frequency with which the terminal device receives MT-SDT messages from the network device, the movement trajectory of the terminal device, the signal strength of the cell reselected by the terminal device, the event that causes the terminal device to switch from the first network to the second network in a multi-subscriber identity module (Multi-SIM) scenario, the reason why the terminal device enters an idle state, and the event that triggers the terminal device to request the network device to resume the Radio Resource Control (RRC) connected state. Including at least one of the following: The method according to claim 4.

6. The reason the terminal device enters the idle state is, The terminal device triggers a wireless link failure or the terminal device triggers cell reselection, The method according to claim 5.

7. The event that triggers the terminal device to request the network device to resume the Radio Resource Control (RRC) connected state is as follows: The arrival of a non-SDT service, the triggering of cell selection or cell re-selection by the terminal device, and the switching of the terminal device from the second network to the first network in the Multi-SIM scenario. Including at least one of the following: The method according to claim 5.

8. A method for recording small data transmission (SDT) events, The receiving of a third message by a terminal device from a network device, the third message being used to instruct the terminal device to record an SDT event and / or measure a drive test minimization (MDT) setting parameter, Based on the third message, the terminal device records the measurement results and / or the SDT events based on the MDT setting parameters in order to obtain recording results. The terminal device transmits the recording results to the network device. It has, The third message includes the first parameter set, The first parameter set includes at least one first parameter, which is used to instruct the recording of a measurement of the beam signal of the serving cell, or The SDT includes a config grant-small data transmission (CG-SDT) or a random access channel-small data transmission (RACH-SDT), wherein the first parameter set includes at least one second parameter, which is used to instruct the recording of CG-SDT events and / or RACH-SDT events, the CG-SDT events including the timing advance (TA) timer of the terminal device expiring and CG resources becoming unavailable. method.

9. The third message is a measurement record setting message. The method according to claim 8.

10. The above-mentioned transmission of the recording results to the network device by the terminal device is, The terminal device transmits a fourth message to the network device, the fourth message being carried as a Radio Resource Control (RRC) resume request message or an RRC setup request message, and the fourth message being used to indicate that the terminal device has obtained available recording results or that there are available recording instructions on the terminal device. The terminal device receives a second instruction message from the network device, and the second instruction message is used to instruct the terminal device to transmit the recording result to the network device. The terminal device transmits the recording result to the network device based on the second instruction message. Having, The method according to claim 8.

11. The above-mentioned transmission of the recording results to the network device by the terminal device is, The terminal device transmits past record results obtained after the last SDT has finished to the network device during each SDT period. The aforementioned past record results are carried in RRC messages or media access control (MAC) layer messages. The method according to claim 8.

12. The above-mentioned transmission of the recording results to the network device by the terminal device is, The terminal device receives a third instruction message from the network device, and the third instruction message is used to instruct the terminal device to transmit the recording result to the network device. The terminal device transmits the recording result to the network device based on the third instruction message. Having, The method according to claim 8.

13. The third instruction message is a terminal information request message, and the recording result is carried in a terminal information response message. The method according to claim 12.

14. Before the terminal device records the measurement results and / or the SDT event based on the MDT setting parameters based on the third message, the method The SDT timer of the terminal device further begins to operate. The method according to claim 8.

15. In order to obtain recording results based on the third message using the aforementioned terminal device, recording the measurement results and / or the SDT events based on the MDT setting parameters is: The terminal device records the measurement results and / or the SDT events based on the MDT setting parameters, based on the third message. When the SDT timer expires, the terminal device stops recording the measurement results and / or SDT events based on the MDT setting parameters. The terminal device acquires the measurement results based on the MDT setting parameters recorded within the operating period of the SDT timer and / or the recorded results based on the SDT events. Having, The method according to claim 14.

16. In order to obtain recording results based on the third message using the aforementioned terminal device, recording the measurement results and / or the SDT events based on the MDT setting parameters is: The terminal device records the measurement results and / or the SDT events based on the MDT setting parameters, based on the third message. When the SDT session of the terminal device ends, the terminal device stops recording the measurement results and / or SDT events based on the MDT setting parameters. The terminal device acquires the recorded measurement results based on the MDT setting parameters and / or the recorded SDT events. Having, The method according to claim 8.

17. The recording results transmitted by the terminal device to the network device are available recording results, and the available recording results are determined by the terminal device based on the number of recorded measurement results and / or the number of recorded SDT events based on the MDT setting parameters. The method according to claim 8.

Images