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, an inactive state, which may also be referred to as an RRC inactive state, is introduced at the radio resource control (RRC) level to reduce resource consumption for frequent transmission of small data packets and improve transmission efficiency.

[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 found in a timely and accurate manner, or SDT setting parameters may not be adjusted or optimized in a timely manner. Therefore, a method for recording SDT events is an urgent problem to be solved currently.

Summary of the Invention

[0005] This application provides an SDT event recording method, apparatus, and storage medium to solve the problem that SDT events cannot be recorded.

[0006] According to a first aspect, an SDT event recording method is provided. The method includes that a terminal device receives a first message from a network device, where the first message includes a first parameter set, and the first parameter set includes one or more parameters for recording transmission characteristic information within an SDT period, and the terminal device records transmission characteristic information corresponding to one or more parameters in the first parameter set based on the first message. Based on the SDT event recording method provided in this embodiment of this application, when performing SDT, the terminal device can record transmission status information based on an instruction of the network device to help find problems occurring during the SDT period and optimize SDT setting parameters.

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

[0008] Referring to the first aspect, in a possible design, SDT includes Configured Grant-Small Data Transmission (CG-SDT) or Random Access Channel-Small Data Transmission (RACH-SDT), the first parameter set includes at least one second parameter, and the second parameter is used to instruct to record events of CG-SDT and / or events of RACH-SDT.

[0009] Referring to the first aspect, in a possible design, the events of CG-SDT are as follows: After transmitting data to the network device on a CG resource, the terminal device does not receive feedback information. When the terminal device sends data to the network device on the CG resource, the signal value of the target cell is smaller than a pre-set threshold value, or the signal value of the target beam is smaller than a pre-set threshold value, The number of times the terminal device sends data to the network device on the CG resource reaches the maximum retransmission number, After sending the layer 3 L3 message and / or data to the network device on the CG resource, the terminal device starts the CG-SDT timer, and before the CG-SDT timer expires, it does not receive an acknowledgment message, a layer 2 L2 message, an L3 message, or scheduled data from the network device, or, The timing advance TA timer of the terminal device expires and the CG resource becomes unavailable including one or more of the above.

[0010] Referring to the first aspect, in a possible design, the RACH-SDT event is as follows: The reason why the terminal device cannot send Msg3 and data to the network device, or, The number of times the terminal device fails to send Msg3 and data to the network device and / or the total number of times the terminal device sends Msg3 and data to the network device including one or more of the above. The total number includes the number of times Msg3 and data transmission fails and the number of times Msg3 and data transmission succeeds.

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

[0012] According to a second aspect, an SDT event recording method is provided. The method includes the terminal device receiving a second message from a network device, where the second message includes a second parameter set, and the second parameter set includes one or more parameters instructing to record service characteristic information during an SDT period, and the terminal device recording service information corresponding to each parameter in the second parameter set based on a first message. Based on the SDT event recording method provided in this embodiment of the present application, when performing SDT, the terminal device can record service characteristic information based on the instruction of the network device to help find problems occurring during the SDT period and optimize SDT setting parameters.

[0013] Referring to the second aspect, in a possible design, the service characteristic information is as follows: The cache of the terminal device, the frequency at which the terminal device sends data to the network device, that the data sent by the terminal device to the network device exceeds a preset threshold, the frequency at which the terminal device transmits data to the network device in segments, the time and / or frequency at which the terminal device receives an MT-SDT message from the network device, the movement trajectory of the terminal device, the signal strength of the cell reselected by the terminal device, an event that the terminal device switches from a first network to a second network in a multi-subscriber identity module Multi-SIM scenario, the reason why the terminal device enters the idle state, the reason why the terminal device ends an SDT session, and an 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 them.

[0014] Referring to the second aspect, in a possible design, the reason why the terminal device enters the idle state includes 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, the reasons for the terminal device to end the SDT session include receiving a first indication message used by the network device to instruct the terminal device to enter an idle state or an inactive state from the network device, or the SDT timer of the terminal device expires.

[0016] Referring to the second aspect, in a possible design, the events that trigger the terminal device to request the network device to resume the Radio Resource Control (RRC) connected state are as follows: at least one of the arrival of a non-SDT service, the terminal device triggering cell selection or cell reselection, and in a Multi-SIM scenario, the terminal device switching from a second network to a first network.

[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 includes the terminal device receiving a third message from the network device, where the third message is used to instruct the terminal device to record SDT events and / or measure drive test minimization (MDT) setting parameters, and the terminal device obtaining a recording result based on the third message by recording measurement results based on the MDT setting parameters and / or SDT events, and the terminal device sending 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, for the terminal device to send the recording result to the network device is that the terminal device sends a fourth message to the network device, where 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, where the second instruction message is used to instruct the terminal device to send the recording result to the network device, and that the terminal device sends 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 carried in a Radio Resource Control (RRC) resume request message or an RRC setup request message.

[0022] Referring to the third aspect, in a possible design, for the terminal device to send the recording result to the network device includes that the terminal device sends the past recording results obtained after the last SDT ends 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 (MAC) layer message.

[0024] Referring to the third aspect, in a possible design, for the terminal device to send the recording result to the network device is that the terminal device receives a third instruction message from the network device, where the third instruction message is used to instruct the terminal device to send the recording result to the network device, and that the terminal device sends the recording result to the network device based on the third instruction message.

[0025] Referring to the third aspect, in a possible design, the third indication 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, before the terminal device records an SDT event and measures MDT configuration parameters based on a third message, the method further includes the SDT timer of the terminal device starting to operate.

[0027] Referring to the third aspect, in a possible design, for the terminal device to obtain a recording result based on a third message by recording measurement results based on MDT configuration parameters and / or SDT events, it includes the terminal device recording measurement results based on MDT configuration parameters and / or SDT events based on a third message, the terminal device stopping recording measurement results based on MDT configuration parameters and / or SDT events when the SDT timer expires, and the terminal device obtaining a recording result based on measurement results based on MDT configuration parameters and / or SDT events recorded during the operation period of the SDT timer.

[0028] Referring to the third aspect, in a possible design, for the terminal device to obtain a recording result based on a third message by recording measurement results based on MDT configuration parameters and / or SDT events, it includes the terminal device recording measurement results based on MDT configuration parameters and / or SDT events based on a third message, the terminal device stopping recording measurement results based on MDT configuration parameters and / or SDT events when the SDT session of the terminal device ends, and the terminal device obtaining a recording result based on the recorded measurement results based on MDT configuration parameters and / or the recorded SDT events.

[0029] Referring to the third aspect, in a possible design, the recording result transmitted by the terminal device to the network device is an available recording result, and the available recording result is 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.

[0030] According to a fourth aspect, a communication device is provided to implement the above method. The communication device may be a terminal device, a device including the terminal device, or a device included in the terminal device, such as a chip, in any design of the first to third aspects. Alternatively, the communication device may be a network device, a device including the network device, or a device included in the network device, such as a chip, in any design of the first to third aspects. The communication device includes corresponding modules, units, or means for implementing the above method. The module, unit, or means may be implemented by hardware, by software, or by executing corresponding software by hardware. The hardware or software includes one or more modules or units corresponding to the above functions.

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

[0032] According to a sixth aspect, a communication device is provided, including 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 a computer program or instructions to execute a method according to any one of the above aspects. The communication device may be a terminal device, a device including the terminal device, or a device included in the terminal device, such as a chip, in any design of the first to third aspects. Alternatively, the communication device may be a network device, a device including the network device, or a device included in the network device, such as a chip, in any design of the first to third aspects.

[0033] Alternatively, the interface circuit may be a code / data read / write interface circuit. The interface circuit receives computer-executable instructions (the computer-executable instructions may be stored in a memory, may be directly read from the memory, or may pass through other components), and sends the computer-executable instructions to the processor, whereby the processor executes the computer-executable instructions to execute a method according to any one of the above aspects.

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

[0035] According to a seventh aspect, a communication device is provided, including a processor. The processor is coupled to a memory and is configured to read instructions from the memory and execute 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 the terminal device, or a device included in the terminal device, such as a chip, in any design of the first to third aspects. Alternatively, the communication device may be a network device, a device including the network device, or a device included in the network device, such as a chip, in any design of the first to third aspects.

[0036] According to an eighth aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores instructions. When the instructions are executed on a communication device, the communication device can execute a method according to any one of the above aspects. The communication device may be a terminal device, a device including the terminal device, or a device included in the terminal device, such as a chip, in any design of the first to third aspects. Alternatively, the communication device may be a network device, a device including the network device, or a device included in the network device, such as a chip, in any design of the first to third aspects.

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

[0038] According to a 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 function in any one of the above aspects. In a possible design, the communication device further includes a memory. The memory is configured to store necessary program instructions and data. In the case of a chip system, the communication device may include a chip, or may include a chip and other discrete devices.

[0039] According to the eleventh aspect, a communication system is provided. The communication system includes a terminal device and a network device. The terminal device may execute a method in any of the designs of the first to third aspects, and the network device may execute a method in any of the designs of the first to third aspects.

Brief Description of the Drawings

[0040]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Embodiments for Carrying Out the Invention

[0041] For ease of understanding, some terms of the present application and related technologies are briefly described below.

[0042] 1. 5th generation (5G) network architecture

[0043] FIG. 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] The network function can be used as a network element executed by dedicated hardware, a software instance executed by dedicated hardware, or a virtual function instantiated on a suitable platform, for example, implemented on a cloud infrastructure.

[0045] It should be noted that FIG. 1 only shows an example of some of the network elements or entities within the 5G network. The 5G network may further include some network elements or entities not shown in FIG. 1, for example, a network data analytics function (NWDAF). This is not particularly limited in the embodiments of the present application.

[0046] As shown in FIG. 1, the terminal device accesses the 5G network via the RAN device. The terminal device communicates with the AMF via the N1 interface (simply called N1), the RAN device communicates with the AMF via the N2 interface (simply called N2), the RAN device communicates with the UPF via the N3 interface (simply called N3), the SMF communicates with the UPF via the N4 interface (simply called N4), and the UPF accesses the DN via the N6 interface (simply called N6). Also, the control plane functions such as AUSF, AMF, SMF, NSSF, NEF, NRF, PCF, UDM, UDR, CHF, or AF shown in FIG. 1 interact through service-based interfaces. For example, the service-based interface shown by the AUSF is Nausf, the service-based interface shown by the AMF is Namf, the service-based interface shown by the SMF is Nsmf, the service-based interface shown by the NSSF is Nnssf, the service-based interface shown by the NEF is Nnef, the service-based interface shown by the NRF is Nnrf, the service-based interface shown by the PCF is Npcf, the service-based interface shown by the UDM is Nudm, the service-based interface shown by the UDR is Nudr, the service-based interface shown by the CHF is Nchf, and the service-based interface shown by the AF is Naf. For the description of related functions and interfaces, please refer to the 5G system architecture diagram in the 23501 standard. Details are not described here again.

[0047] The functions of parts or network elements within the above network architecture in the 5G network are described individually below by using examples.

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

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

[0050] (2) The mobility management network element is a core network element and is mainly involved in functions such as signaling processing parts, for example, access control, mobility management, attach and detach, and gateway selection. When providing services for a terminal session, the mobility management network element provides control plane storage resources for the session to store a session identifier, an SMF network element identifier associated with the session identifier, and so on. 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 other names. This is not limited in this application.

[0051] (3) The user plane network element is used for packet routing and forwarding, quality of service (QoS) processing of user plane data, and so on. In a 5G communication system, the network element or entity corresponding to the user plane network element may be a user plane function (UPF) in the 5G network architecture. In future communication systems, the user plane network may still be a UPF network element or a user plane network element, or may have other names. This is not limited in the embodiments of this application.

[0052] For the descriptions of the functions of network elements such as DN, SMF, AUSF, NSSF, NEF, NRF, PCF, UDM, UDR, AF, and CHF, etc., please refer to the descriptions and records of the prior art. Details are not described again here.

[0053] 2. RRC State

[0054] In the 5G NR system, three RRC states are defined: the non-active state, the connected state, and the idle state. The three states are described as follows.

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

[0056] (2) The non-active state is the RRC_INACTIVE state, also referred to as the non-active state or the third state. The non-active state means that the RRC connection between the terminal device and the access network (e.g., the base station) is interrupted, but the connection between the access network corresponding to the terminal device and the core network is not interrupted. In the conventional solution, when the terminal device is in the non-active state, when data needs to be transmitted, before the data can be transmitted, the RRC connection between the terminal device and the access network needs to be resumed first.

[0057] After the terminal device enters the inactive state, the context of the terminal device is suspended on both the terminal device side and the base station side. The context of the terminal device is stored in the last cell on which the terminal device camped before entering the inactive state, or in the cell that last provided service to the terminal device (also called the anchor cell). When there is a data and / or signaling transmission request, the terminal device may initiate an RRC resume request to resume the RRC connection based on the context of the terminal device to obtain the context of the terminal device. For example, the context of the terminal device includes the security context of the terminal device and the capability information of the terminal device.

[0058] (3) The idle state is RRC_IDLE. The idle state means that there is no RRC connection established between the terminal device and the access network device (e.g., base station), and there is no connection established between the access network device (e.g., base station) corresponding to the terminal device and the core network device (e.g., AMF). When the terminal device is in the idle state, when data needs to be transmitted, before the data can 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) need to be established first.

[0059] Also, the base station to which the cell on which the terminal device is currently camped belongs, or the base station that is currently providing services to the terminal device, may be referred to as the serving base station (Serving-gNB). The base station to which the last cell on which the terminal device camped before entering the inactive state belongs, or the base station that last provided services to the terminal device before the terminal device entered the inactive state, may be referred to as the anchor base station (Anchor-gNB). Note that it should be noted that the terminal device has mobility. After entering the inactive state, the terminal device may move. Therefore, the serving base station and the anchor base station of the terminal device may be different.

[0060] 3. RRC Connection Reestablishment from RRC Inactive State

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

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

[0063] Step 202: If the serving base station of the terminal device is not the anchor base station of the terminal device, the serving base station sends a Retrieve UE CONTEXT REQUEST message to the anchor base station to request the context of 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 Retrieve UE CONTEXT RESPONSE message, 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: The serving base station sends a path switch request message to the AMF to switch the path of the core network device to the serving base station and receives a path switch response message.

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

[0071] After step 208, it should be understood that the serving base station becomes the new anchor base station. Therefore, since the original anchor base station (i.e., the anchor base station in FIG. 2) does not need to hold the context of the terminal device, it can release the context of the terminal device.

[0072] Step 210: After the path switch, the terminal device in the RRC connected state can perform data transmission by the UPF.

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

[0074] The RRC release message may include a suspendconfig for instructing the terminal device to suspend the context of the terminal device.

[0075] If the terminal device that resumes from the inactive state needs to send data again, steps 201 to 211 can be executed again.

[0076] However, from steps 201 to 211, when data transmission is performed relatively frequently, it can be seen that the terminal device needs to frequently switch between the inactive state and the connected state, and as a result, a large amount of signaling resources are occupied. However, the occupation of a large amount of signaling resources for transmitting small data packets is a waste of signaling resources. Therefore, in a possible implementation, the SDT technology is proposed, whereby the terminal device can transmit data in the RRC inactive state.

[0077] 4. SDT

[0078] Currently, there can be two scenarios where the terminal device executes SDT in an inactive state, namely Scenario 1 and Scenario 2. In Scenario 1, after the terminal device finishes SDT, the serving base station transitions the state of the terminal device to the connected state. In Scenario 2, after the terminal device finishes SDT, the serving base station sets the state of the terminal device to the inactive state or the idle state.

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

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

[0081] Step 302: The serving base station sends a message 2 (Msg2), that 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), that is, the RRC resume request message, and the uplink data that needs to be transmitted, to the serving base station. The RRC resume request message can be used to request the execution of SDT, or the RRC resume request message can be used to request the establishment of an SDT session. During the SDT session (which can also be called the SDT period), the UE in the inactive state can transmit data to the serving base station.

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

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

[0085] Step 305: After the data transmission is completed, the serving base station sends an RRC resume message to the terminal device, and the RRC resume message can 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 completion message to the serving base station.

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

[0088] As another example, FIG. 4 is a flowchart for executing SDT in scenario 2. As shown in FIG. 4, the process may include the following steps.

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

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

[0091] Step 403: The terminal device in the inactive state sends Msg3, that is, the RRC resume request message and the uplink data to be transmitted, to the serving base station. The RRC resume request message can be used to request to perform SDT, that is, the RRC resume request message can be used to request to establish an SDT session. During the SDT session (which can also be called the SDT period), the UE in the inactive state can transmit data to the serving base station.

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

[0093] Step 404: The serving base station transfers the received uplink data to the core network (UPF) and transmits the uplink and downlink data that is between the core network and the terminal device and then arrives.

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

[0095] In addition, as shown in FIG. 3 or FIG. 4, the method by which the terminal device acquires the resources used for SDT by using the random access procedure is called random access channel - small data transmission (RACH - SDT). Different from the RACH - SDT procedure shown in FIG. 3 or FIG. 4, the terminal device may further execute SDT by using the configured grant - small data transmission (CG - SDT) procedure. In the CG - SDT procedure, available CG resources are set for the terminal device, and signaling or data can be directly and successfully transmitted on the available CG resources without triggering a random access to request resources. For example, in Scenario 1, the CG - SDT procedure does not need to include step 301 and step 302 in FIG. 3, and the terminal device can directly execute step 303 based on the available CG resources and then execute steps 304 - 306. In Scenario 2, the CG - SDT procedure does not need to include step 401 and step 402 in FIG. 4, and the terminal device can directly execute step 403 based on the CG resources and then execute steps 404 - 405.

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

[0097] Logged - MDT is a technology for collecting relevant measurement quantities of a terminal device in an idle state or a non - active state to help identify the cause of problems, for example, a technology for measuring the signal strength of a cell and recording random access failure events.

[0098] When the 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 includes 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 perform corresponding measurements based on the logged measurement configuration message after entering the idle state or the non-active state, and record the measurement results in order to obtain MDT measurement records (it may also be said as "in order to obtain MDT measurement results"). After obtaining the MDT measurement records, the terminal device may add a message indicating that the terminal device has performed available MDT measurements to the RRC resume request message and send the RRC resume request message to the base station. After receiving the RRC resume request message, the base station can configure the terminal device to resume the RRC connected state, know that the terminal device has MDT measurement records based on the instruction message carried in the RRC resume request message, and send an MDT measurement record report request message to the terminal device that has resumed the connected state to instruct the terminal device to report the MDT measurement records. After receiving the MDT measurement record report request message, the terminal device sends the MDT measurement records to the base station.

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

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

[0101] Step 502: The serving base station receives a trace start message from a 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] Note that the serving base station receiving a trace start message from the core network device as shown in FIG. 5 is merely an exemplary method of triggering the serving base station to distribute MDT measurement setting information. For example, other triggering mechanisms may include various triggering mechanisms such as other mechanisms of triggering by the core network device, mechanisms of triggering by the network management platform, or mechanisms of triggering by the serving base station, and are not limited in this application.

[0103] Also, note that performing step 502 after step 501 as shown in FIG. 5 is merely an exemplary order. When the serving base station receives a trigger message for triggering the serving base station to distribute MDT measurement setting information, the occasion when the serving base station receives the trigger message is not limited in this application. That is, the occasion when the serving base station receives the trigger message is independent of the state of the terminal device. The serving base station may receive the trigger message when the terminal device is in any one of the connected state, inactive state, or idle state. However, note that the serving base station sends the MDT measurement setting information to the terminal device after the terminal device enters the connected state.

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

[0105] Step 504: The serving base station sends an RRC release message to the terminal device so that the terminal device enters the inactive state. The terminal device starts measuring relevant MDT setting parameters based on the log measurement setting message 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 completion message to the serving base station, and the RRC resume completion message carries an indication message indicating that MDT-related measurements are available.

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

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

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

[0112] Based on the problems of the method for recording SDT listed above, an embodiment of the present application provides an SDT event recording method for recording events or conditions that occur during an SDT procedure (which may also be referred to as an SDT period) in order to timely and accurately identify problems that occur during the SDT period and optimize SDT setting parameters.

[0113] The technical solution in the embodiments of the present application is described below with reference to the accompanying drawings in the embodiments of the present application. In the specification of the present application, unless otherwise specified, " / " indicates an "or" relationship between related objects. For example, A / B may indicate A or B. In the present application, "and / or" is merely an associative relationship for describing related objects, indicating that there may be three relationships. For example, A and / or B can indicate the following three cases: only A exists, both A and B exist, and only B exists, and A and B may be singular or plural. Also, in the specification of the present application, unless otherwise specified, "a plurality of..." means two or more. "At least one of the following item(s)" or similar expressions refer to any combination of these items, including a single item or any combination of a plurality of 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 and b and c, and a, b, and c may be singular or plural. Also, in the embodiments of the present application, for the sake of clearly describing the technical solution, terms such as "first" and "second" are used in the embodiments of the present application to distinguish the same item or similar items that basically provide the same function and role. A person skilled in the art can understand that terms such as "first" and "second" do not limit the quantity and execution order, and terms such as "first" and "second" do not indicate a clear difference. Also, in the embodiments of the present application, words such as "example" or "for example" are used to represent giving an example, an instance, or a description. Any embodiment or design solution described as an "example" or "for example" in the embodiments of the present application should not be described as more preferable or having more advantages than other embodiments or design solutions. Exactly, the use of words such as "example" or "for example" is intended to specifically present related concepts for easy understanding.

[0114] In addition, the network architectures and service scenarios described in the embodiments of the present application are intended to more clearly describe the technical solutions in the embodiments of the present application and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Those skilled in the art will recognize that due to the evolution of network architectures and the emergence of new service scenarios, the technical solutions provided in the embodiments of the present application are applicable to similar technical problems.

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

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

[0117] The system architectures described in the embodiments of the present application are intended to more clearly describe the technical solutions in the embodiments of the present application and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Those skilled in the art will recognize that due to the evolution of network architectures and the emergence of new service scenarios, the technical solutions provided in the embodiments of the present application are applicable to similar technical problems.

[0118] The network device according to the embodiment of the present application is a device that connects a terminal device to a wireless network. In the present application, unless otherwise specified, the network device is a wireless access network device. The network device 602 may be a base station, an evolved NodeB (eNodeB), a transmission and reception point (TRP), a next generation NodeB (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, etc., or a module or unit that completes some functions of the base station, for example, a central unit (CU) or a distributed unit (DU). Also, the network device may alternatively be a broadband network gateway (BNG), an aggregation switch, or a non-3GPP access device. The network device may alternatively be a wireless controller, a transmission and reception point (TRP), a device including a TRP, etc. in a cloud radio access network (CRAN). The specific technology and specific device form used by the network device are not limited in the embodiments of the present application.

[0119] The terminal device of the embodiment of the present application may be a device with a wireless transceiver function. The terminal device may be disposed on the ground, including indoors, outdoors, handheld, or in-vehicle, may be disposed on the water surface (e.g., a ship), or may be disposed in the air (e.g., an airplane, a balloon, or a satellite). The terminal device may be a user equipment (UE), an access terminal, a terminal unit, a subscriber unit, a terminal station, a mobile station (MS), a mobile console, a remote station, a remote terminal, a mobile device, a wireless communication device, a terminal agent, a terminal device, etc. within a 5G network or a future evolved public land mobile network (PLMN). The access terminal may be a cellular phone, a cordless phone, a session initiation protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device with a wireless communication function, a computing device or other processing device connected to a wireless modem, an in-vehicle device or a wearable device, a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical, a wireless terminal in smart grid, a wireless terminal in transport safety, a wireless terminal in smart city, a wireless terminal in smart home, etc. The terminal may be movable or fixed. The specific type and structure of the terminal are not limited in the embodiment of the present application.

[0120] Optionally, the terminal device 601 and the network device 602 in this embodiment of the present application may use the configuration structure shown in FIG. 7, or may include the parts shown in FIG. 7. FIG. 7 is a schematic diagram of the structure of a communication device 70 according to an embodiment of the present application. As shown in FIG. 7, the communication device 70 includes one or more processors 701, a communication line 702, and at least one communication interface (in FIG. 7, only an example including a communication interface 703 and one processor 701 is used for description), and optionally, may further include a 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 programs in the solution of the present application.

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

[0123] The communication interface 703 may be a transceiver module and is 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 a transceiver machine. Optionally, the communication interface 703 may alternatively be a transceiver circuit placed in the processor 701 for implementing signal input and signal output of the processor.

[0124] Memory 704 may be a device with a storage function. For example, Memory 704 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, or a random access memory (RAM) or other type of dynamic storage device that can store information and instructions. Alternatively, it may be 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 the expected program code in the form of instructions or data structures and can be accessed by a computer. However, this is not limited to these. The memory may exist independently and be connected to the processor by using communication line 702. Alternatively, the memory may be integrated with the processor.

[0125] Memory 704 is configured to store computer-executable instructions for executing the solution of this application, and Processor 701 controls the execution. 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 this application.

[0126] Alternatively, optionally, in this embodiment of this application, Processor 701 may execute the processing-related functions in the SDT event recording method provided in the following embodiments of this application. Communication interface 703 is involved in communication with other devices or communication networks. This is not particularly limited in this embodiment of this application.

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

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

[0129] In a specific implementation, in the embodiment, the communication device 70 may include a plurality of processors, for example, the processor 701 and the processor 707 in FIG. 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: various computing devices that execute software, such as 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 a specific implementation, in the embodiment, 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 may display information in a plurality of manners. 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 may receive input from a user in a plurality of manners. For example, the input device 706 may be a mouse, a keyboard, a touch screen device, or a sensing device.

[0131] The communication device 70 may sometimes also be 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 terminal devices, the above network devices, or a device having a structure similar to that of FIG. 7. The type of the communication device 70 is not limited in this embodiment of the present application.

[0132] Optionally, FIG. 8 is a schematic diagram of the hardware structure of the UE. As shown in FIG. 8, in some embodiments, the structure of the UE may be shown in FIG. 8. The UE may include a processor 710, an external memory interface 720, an internal memory 771, a universal serial bus (USB) interface 730, a charging 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, etc. 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, etc.

[0133] It can be understood that the structure shown in this embodiment does 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 divided, or different part arrangements may be used. The parts shown 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 integrated into one or more processors.

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

[0136] The power management module 741 is configured to be connected to the battery 742, the charging management module 740, and the processor 710. The power management module 741 receives inputs from the battery 742 and / or the charging management module 740, and supplies power to the processor 710, the internal memory 771, the display 794, the camera 793, the 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] Antenna 1 and antenna 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] Mobile communication module 750 provides a wireless communication solution including 2G / 3G / 4G / 5G, etc. applied to the UE.

[0140] Wireless communication module 760 may provide a wireless communication solution 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, etc. applied to the UE. Wireless communication module 760 may be one or more components in which at least one processing module is incorporated. Wireless communication module 760 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering processing on the electromagnetic wave signals, and sends the processed signals to processor 710. Wireless communication module 760 may further receive the 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 can be used by the UE to send a request to resume the RRC connection to the network node and receive a response message from the network node.

[0142] The UE implements the display function by using a GPU, a display 794, an application processor, etc. The GPU is a microprocessor for image processing and is connected to the display 794 and the application processor.

[0143] The display 794 is configured to display images, videos, etc. A series of graphical user interfaces (GUI) can be displayed on the display 794 of the UE.

[0144] The UE may implement the shooting function by using an ISP, a camera 793, a video codec, a GPU, a display 794, an application processor, etc.

[0145] The camera 793 is configured to capture still images or videos.

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

[0147] The internal memory 771 can 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 execute various functional applications and data processing of the UE.

[0148] The UE can 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 acceleration sensor 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 be connected to a SIM card. The SIM card can be inserted into or removed from the SIM card interface 795 to be detached from or attached to 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 a Nano SIM card, a Micro SIM card, a SIM card, etc. Multiple cards may be inserted into the same SIM card interface 795 simultaneously. The SIM card interface 795 is also compatible with an external memory card. The UE interacts with a network by using a SIM card to implement functions such as phone calls and data communications.

[0150] Also, an operating system, such as the Harmony (registered trademark) operating system, the iOS (registered trademark) operating system, the Android (registered trademark) operating system, or the Windows (registered trademark) operating system, is executed on the above-mentioned parts. An application program can be installed and executed on the operating system. In some other embodiments, multiple operating systems may be executed on the UE.

[0151] The hardware modules included in the UE shown in FIG. 8 are described merely by way of example and are not intended to constitute a limitation on the specific structure of the UE. It should be understood that, in fact, the UE provided in this embodiment of the present application may further include other hardware modules having an interaction relationship with the illustrated hardware modules. This is not particularly limited herein. For example, the UE may further include a flash or a micro-projection device. As another example, when the UE is a PC, the UE may further include parts such as a keyboard and a mouse.

[0152] Referring to FIGS. 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 FIG. 8. The operations, terms, etc. in the embodiments of the present application may be cross-referenced. This is not limited. In the embodiments of the present application, the names of the messages exchanged between devices or the names of the parameters in the messages are merely examples. In a specific implementation, other names may be used. This is not restricted.

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

[0154] Step 901: The serving base station sends a log measurement setting message to the UE, and the log measurement setting message carries a first parameter set, and the first parameter set includes one or more parameters for the UE to record transmission status information when performing SDT (during the SDT period).

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

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

[0157] In this embodiment of the present application, step 901 is executed by the serving base station after the delivery of the MDT measurement setting information is triggered. Also, when the serving base station executes step 901, the UE needs to be in a connected state.

[0158] Note that the mechanism for triggering the serving base station to deliver the MDT measurement setting information is not limited in this embodiment of the present application. Optionally, the core network device may trigger the serving base station to deliver the MDT measurement setting information. For example, the AMF or UPF sends a trace start message to the serving base station. Alternatively, the network management platform may trigger the serving base station to deliver the MDT measurement setting information. Alternatively, the serving base station may trigger the delivery of the MDT measurement setting information, etc.

[0159] Also, note that when the serving base station receives a trigger message for triggering the serving base station to deliver the MDT measurement setting information, the occasion when the serving base station receives the trigger message is not limited in this application. That is, the occasion when the serving base station receives the trigger message is independent of the state of the UE. The serving base station may receive the trigger message when the UE is in any one of the connected state, inactive state, or idle state. However, the occasion when the serving base station sends the MDT measurement setting information to the UE is related to the state of the UE. When the serving base station sends the MDT measurement setting information to the UE, the UE needs to be in a connected state.

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

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

[0162] After receiving the log measurement setting message including the first parameter, the UE may record the measurement value obtained by measuring the beam signal of the serving cell when setting the CG resource used for SDT.

[0163] Optionally, the first parameter set may include at least one second parameter, and the second parameter is used to instruct to record events that occur when the UE performs CG-SDT and / or RACH-SDT. Hereinafter, an event that occurs when the UE performs CG-SDT is briefly referred to as an event of CG-SDT (CG-SDT event), and an event that occurs when the UE performs RACH-SDT is briefly referred to as an event of RACH-SDT (RACH-SDT event). For example, the second parameter may instruct to record a failure event of the UE's CG-SDT. The failure event of CG-SDT may alternatively be understood as the reason for the failure of CG-SDT.

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

[0165] 1. After transmitting 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 transmits data to the serving base station on the CG resource reaches the maximum retransmission number. The maximum retransmission number may be set by the serving base station for the UE by using an RRC message, or the maximum retransmission number may be predefined in the UE.

[0168] 4. After transmitting layer 3 (L3) messages and data to the serving base station on the CG resource, the UE starts the CG-SDT Timer. Before the CG-SDT Timer expires, the UE does not receive an acknowledgment message, a layer 2 (L2) message, an L3 message, or scheduled downlink data fed back by the serving base station.

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

[0170] Specifically, when the second parameter instructs to record a failure event, after transmitting the L3 message and data to the serving base station on the CG resource and starting the CG-SDT Timer, the UE may monitor the physical downlink control channel (PDCCH) to receive signaling or downlink data from the serving base station. If the UE does not receive the corresponding acknowledgment signaling, L2 message, L3 message, or downlink data, the UE records a failure event.

[0171] 5. The timing advance (TA) Timer expires and the CG resource becomes unavailable.

[0172] Specifically, when the second parameter instructs to record a failure event, and if the UE fails to transmit data on the CU resource after the TA timer expires, the UE may consider that the CG resource cannot be continuously used, that is, the CG resource is considered unavailable, and may record the failure event. Optionally, the TA may be set by the serving base station by using the RAR message sent to the UE.

[0173] After the UE receives a log measurement setting message including the second parameter, if an event instructed by the second parameter to record occurs in the CG-SDT procedure, the UE may record the corresponding CG-SDT event.

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

[0175] 1. Reasons why the terminal device cannot send Msg3 and data to the serving base station: For example, the reasons for failure may be that the UE cannot compete for random access with other UEs, the number of times the UE sends Msg3 and data reaches the maximum retransmission number, or the UE still cannot send Msg3 and data after the RACH-SDT timer expires.

[0176] 2. The number of times the UE fails to send Msg3 and data to the serving base station and / or the total number of times the UE sends Msg3 and data to the serving base station. Here, the total number includes the number of times Msg3 and data transmission fails and the number of times Msg3 and data transmission succeeds.

[0177] After the UE receives a log measurement setting message including the second parameter, if an event instructed by the second parameter to record occurs in the RACH-SDT procedure, the UE may record the corresponding RACH-SDT event.

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

[0179] Step 903: The UE in the inactive state decides to perform SDT. When performing SDT, based on the log measurement configuration message, it records the transmission status information indicated by the parameters included in the first parameter set and obtains the recording result.

[0180] In a possible implementation, the UE records the transmission status information when the UE performs SDT in the form of a log and may store the transmission status information.

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

[0182] Optionally, after obtaining the recording result, the UE may send the recording result to the serving base station or the network management platform. The serving base station or the network management platform may determine the transmission status when the UE performs SDT based on the recording result for fast identification when a problem occurs in the UE's SDT procedure. The serving base station or the network management platform may further optimize the SDT configuration parameters or configured resources of the UE based on the recording result reported by the UE. For example, based on the recording result from the UE, the serving base station or the network management platform may adjust the Configured Grant Resource Size (CG Resource Size) or distribute auxiliary indication information. For example, based on the recording result, it may distribute information indicating whether the UE moves the RRC state during the SDT period.

[0183] Based on the SDT event recording method provided in this embodiment of the present application, when performing SDT, the UE records transmission status information based on the instructions of the serving base station, helps to identify problems occurring during the SDT period of the UE, and can optimize the SDT setting parameters.

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

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

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

[0187] The implementation of steps 1001 to 1002 is similar to that of steps 901 to 903, and the description of steps 901 to 903 may be referred to.

[0188] Also, in a possible implementation, an example where the network device providing services to the terminal device is the serving base station and the terminal device is the UE is used. A flowchart of another SDT event recording method provided in the embodiment of the present application may be shown in FIG. 11. Referring to FIG. 11, the SDT event recording method may include the following steps.

[0189] Step 1101: The serving base station sends a log measurement setting message to the UE. The log measurement setting message carries a second parameter set, and the second parameter set includes one or more parameters that instruct the UE to record service characteristic information when the UE performs SDT (during the SDT period).

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

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

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

[0193] 2. The frequency at which the UE transmits data to the serving base station in 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 in the SDT process.

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

[0195] 4. The frequency at which the UE transmits data to the serving base station in segments in the SDT process: Specifically, in the SDT process, the UE may record the frequency at which data is transmitted to the serving base station in segments based on whether the data to be transmitted to the serving base station is transmitted in segments.

[0196] 5. The time and / or frequency at which the UE receives a downlink paging message from the serving base station in the SDT process: The downlink paging message is used to trigger the UE to receive downlink data in the SDT cycle. For example, the downlink paging message may be an MT-SDT paging message.

[0197] 6. The UE's movement trajectory information in the SDT process: Optionally, the UE may record the UE's location information in the SDT process so as to record the UE's movement trajectory information in the SDT cycle.

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

[0199] 8. The event that 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 in the SDT process: For example, the first network may be the network of operator A, and the second network may be the network of operator B. When the parameters in the second parameter set instruct to record the event, and when the UE switches from the network of operator A to the network of operator B in the SDT process, the UE may record the event.

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

[0201] 10. Reasons for the UE to terminate the SDT session or reasons for the UE to terminate SDT: For example, the reason for the UE to terminate the SDT session may be that the serving base station sends a first indication message to the UE to trigger the UE to terminate the SDT session and instruct the terminal device to enter the idle state or the inactive state. For example, the first indication message may be an RRC release message. Alternatively, the reason may be that the UE's SDT timer expires, the UE terminates the SDT session, and enters the idle state.

[0202] 11. Events that trigger the UE to request the resumption of the RRC connected state in 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 Resume Request) sent by the UE after the RRC resume request message (Msg3) sent together with data after the UE triggers 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, the event that triggers the UE to request the resumption of the RRC connected state may include at least one of the following.

[0204] A non-SDT (non-Specific Dynamic Traffic) service arrives at the UE, triggering the UE to perform cell selection or reselection. In a multi-SIM scenario, the UE returns from another network to the first network. A non-SDT service is a service that cannot be transmitted by using the SDT procedure.

[0205] 12. Related information that exists when the UE returns from another network to the first network in a multi-SIM scenario: For example, the related information may be information such as the time and reason for the UE to return from another network to the first network. The information may also be referred to as information such as the time and reason of the switching type.

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

[0207] Step 1103: The UE in the inactive state decides to execute SDT. When executing SDT, based on the log measurement configuration message, it records the service characteristic information corresponding to the parameters included in the second parameter set and obtains the recording result.

[0208] In a possible implementation, the UE records the service characteristic information in the form of a log when the UE executes SDT and may store the service characteristic information.

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

[0210] Optionally, after obtaining the recording result, the UE may send the recording result to the serving base station or the network management platform. Based on the recording result, the serving base station or the network management platform may determine the service status when the UE executes SDT, and implement fast identification in case of problems in the UE's SDT procedure. The serving base station or the network management platform may further optimize the SDT setting parameters or the set resources of the UE based on the recording result reported by the UE. For example, based on the recording result from the UE, the serving base station or the network management platform may adjust the CG grant size or distribute auxiliary indication information such as information indicating whether the UE moves the RRC state during the SDT period.

[0211] Based on the SDT event recording method provided in this embodiment of the present application, when executing SDT, the UE may record the service characteristic information of the UE based on the instruction of the serving base station, help identify problems occurring during the SDT period of the UE, and optimize the SDT setting parameters.

[0212] Note that it should be noted that the embodiment shown in FIG. 11 is an exemplary description of the SDT event recording method provided in the present application. In other possible embodiments, as shown in FIG. 12, the SDT event recording method may include the following steps.

[0213] Step 1201: The serving base station sends a second message to the UE. The second message carries a second parameter set, and the second parameter set includes one or more parameters instructing the UE to record service characteristic information when the UE executes SDT. For example, the second message may be a log measurement setting message.

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

[0215] The implementation of steps 1201 to 1202 is similar to that of steps 1101 to 1103, and the description of steps 1101 to 1103 can be referred to.

[0216] Also, in a possible embodiment, an example where the network device providing services to the terminal device is a serving base station and the terminal device is a UE is used. Flowcharts of other SDT event recording methods provided in the embodiments of the present application can be shown in FIG. 13. Referring to FIG. 13, the SDT event recording method may include the following steps.

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

[0218] Optionally, the log measurement setting message can be carried in an RRC release message and sent to the UE.

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

[0220] Step 1302: The UE triggers the SDT procedure, the SDT timer starts to operate, the UE starts to record related SDT events occurring in the SDT process based on the instructions of the log measurement setting message, and / or performs measurements based on related MDT setting parameters to obtain measurement results based on the MDT setting parameters (hereinafter, simply referred to as measurement results), records the measurement results to obtain a recording result. At this time, 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 within 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 SDT-MDT measurement (Logged SDT-MDT). Correspondingly, the recording results obtained by the UE may be referred to as Logged SDT-MDT recording results.

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

[0223] In this embodiment of the present application, the UE may finish recording SDT events and / or measurement results after the SDT session of the UE ends.

[0224] For example, the end of the SDT session of the UE may be triggered in the following ways: The UE receives an RRC release message from the serving base station. Alternatively, the UE moves from the inactive state to the 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 obtained Logged SDT-MDT recording results reaches a specific threshold, the UE may consider the obtained recording results to be available. Optionally, the threshold that the number of records needs to reach may be set by the serving base station for the UE, or may be predefined by the UE.

[0227] In another possible implementation, when the value of at least one record included in the obtained Logged SDT-MDT recording result reaches a corresponding specific threshold, the UE can consider that the obtained recording result is available. For example, the Logged SDT-MDT recording result obtained 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 more than a corresponding pre-set threshold, for example, the corresponding pre-set threshold may be 100 bits, the UE can consider that the obtained recording result is available.

[0228] Step 1305: If it is determined that the recording result is available, the UE sends the recording result to the serving base station.

[0229] The specific implementation for the UE to send the recording result to the serving base station is described below.

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

[0231] In another possible implementation, the UE may send the recording result (past recording result) obtained after the last SDT is completed in each SDT period to the serving base station. Optionally, the past result may be carried in an RRC message or a MAC layer message. For example, when moving from the inactive state to the connected state, the UE may add the recording result of the last SDT to the RRC resume complete message to be sent to the serving base station. Optionally, the message in which the past recording result needs to be carried may be instructed to the UE by the serving base station by using the indication information or configuration information sent to the UE.

[0232] In yet another possible implementation, the serving base station actively sends a third indication message to the UE to instruct the UE to report the recording result. After receiving the third indication message, the UE sends the recording result to the serving base station based on the third indication message. For example, the serving base station may add information such as identification information, fields, or parameters used to request the report of the recording result to the UE information request message to be sent to the UE. After receiving the UE information request message sent by the serving base station, the UE adds the recording result obtained in the SDT period to the UE information response message to be sent to the serving base station based on the identification information used to request the report of the recording result.

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

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

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

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

[0237] Optionally, before step 1403, step 1402.1 may further be included, in which the UE determines whether the recording result is available based on the number of recorded SDT events and / or the number of measured MDT setting parameters. If it is determined that the recording result is available, the UE executes step 1403. Otherwise, step 1403 is not executed.

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

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

[0240] It can be understood that the method and / or steps implemented by the network device or the terminal device in the above method embodiment may alternatively be implemented by parts (such as chips or circuits) that can be used in the network device or the terminal device.

[0241] Optionally, embodiments of the present application further provide a communication device. The communication device is configured to implement the above method. The communication device may be the network device or terminal device, the device including the network device or terminal device, or a part that can be used in the network device or terminal device in the embodiments of the above method. To implement the above functions, it can be understood that the communication device includes corresponding hardware structures and / or software modules for executing the functions. A person skilled in the art should easily understand that the exemplary units, algorithms, and steps described with reference to the embodiments disclosed herein can be implemented in the present application by hardware or a combination of hardware and computer software. Whether a function is executed by hardware or hardware driven by computer software depends on the specific application and design constraints of the technical solution. A person skilled in the art can use different methods to implement the described functions for each specific application, but it should not be considered that the implementation exceeds the scope of the present application.

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

[0243] FIG. 15 is a schematic diagram of the structure of a 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 the transceiver function. For example, it may be 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 above-described method embodiment.

[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, and the first parameter set includes one or more parameters for recording transmission characteristic information within an SDT period. The processing module 1501 may be configured to record transmission characteristic information corresponding to one or more parameters within the first parameter set based on the first message.

[0246] Optionally, the first parameter set includes at least one first parameter, and the first parameter is used to instruct recording of measurement values of beam signals of a serving cell.

[0247] Optionally, SDT includes configured grant - small data transmission CG - SDT or random access channel - small data transmission RACH - SDT, the first parameter set includes at least one second parameter, and the second parameter is used to instruct recording of events of CG - SDT and / or events of RACH - SDT.

[0248] Optionally, the events of CG - SDT are as follows: After transmitting data to the network device on a CG resource, the terminal device does not receive feedback information. When the terminal device transmits data to the network device on a CG resource, the signal value of the target cell is smaller than a preset threshold, or the signal value of the target beam is smaller than a preset threshold. The number of times the terminal device transmits data to the network device on a CG resource reaches the maximum retransmission number. After transmitting layer 3 (L3) messages and / or data to a network device on a CG resource, the terminal device starts a CG-SDT timer, and before the CG-SDT timer expires, the terminal device does not receive an acknowledgment message, a layer 2 (L2) message, an L3 message, or scheduled data from the network device, or the timing advance (TA) timer of the terminal device expires and the CG resource becomes unavailable includes one or more of the above.

[0249] Optionally, the RACH-SDT event is as follows: the reason why the terminal device cannot send Msg3 and data to the network device, or the number of times the terminal device fails to send Msg3 and data to the network device and / or the total number of times the terminal device sends Msg3 and data to the network device includes one or more of the above. The total number includes the number of times Msg3 and data transmission fails and the number of times Msg3 and data transmission succeeds.

[0250] In other possible implementations, the transceiver module 1502 may be configured to receive a second message from the network device. The second message includes a second parameter set, and the second parameter set includes one or more parameters instructing to record service characteristic information within 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 characteristic information is as follows: The cache of the terminal device, the frequency at which the terminal device transmits data to the network device, that the data transmitted by the terminal device to the network device exceeds a preset threshold, the frequency at which the terminal device transmits data to the network device in segments, the time and / or frequency at which the terminal device receives an MT-SDT message from the network device, the movement trajectory of the terminal device, the signal strength of the cell reselected by the terminal device, an event in which the terminal device switches from a first network to a second network in a multi-subscriber identity module Multi-SIM scenario, the reason why the terminal device enters the idle state, the reason why the terminal device terminates the SDT session, and an event that triggers the terminal device to request the network device to resume the radio resource control RRC connected state includes at least one of the following.

[0252] Optionally, the reason why the terminal device enters the idle state includes that the terminal device triggers a radio link failure or the terminal device triggers a cell reselection.

[0253] Optionally, the reason for the terminal device to terminate the SDT session includes that the terminal device receives a first indication message used by the network device to instruct the terminal device to enter the idle state or the non-active state, or the SDT timer of the terminal device expires.

[0254] Optionally, the event that triggers the terminal device to request the network device to resume the radio resource control RRC connected state includes at least one of the following: 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.

[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 SDT events and / or measure drive test minimization MDT setting parameters. Based on the third message, the processing module 1501 records the measurement results based on the MDT setting parameters and / or the SDT events to obtain the recording results. The transceiver module 1502 may be further configured to send the recording results to the network device.

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

[0258] Optionally, the transceiver module 1502 sends a fourth message to the network device. The fourth message is used to indicate that the terminal device has obtained available recording results or there is an available recording instruction at the terminal device. The transceiver module 1502 receives a second instruction message from the network device. The second instruction message is used to instruct the terminal device to send the recording results to the network device. The transceiver module 1502 is specifically configured to send the recording results to the network device based on the second instruction message.

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

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

[0261] Optionally, the past recording results are carried in an RRC message or a MAC layer message.

[0262] Optionally, the transceiver module 1502 receives a third instruction message from a network device, the third instruction message is used to instruct the terminal device to send the recording result to the network device, and is specifically configured to send the recording result 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, before the processing module 1501 records the measurement result and / or SDT event based on the MDT setting parameter according to the third message, the SDT timer of the terminal device starts to operate.

[0265] Optionally, the processing module 1501 records the measurement result and / or SDT event based on the MDT setting parameter according to the third message, stops recording the measurement result and / or SDT event based on the MDT setting parameter when the SDT timer expires, and is specifically configured to obtain the recording result based on the measurement result and / or SDT event based on the MDT setting parameter recorded during the operation period of the SDT timer.

[0266] Optionally, the processing module 1501 records the measurement result and / or SDT event based on the MDT setting parameter according to the third message, stops recording the measurement result and / or SDT event based on the MDT setting parameter when the SDT session ends, and is specifically configured to obtain the recording result based on the recorded measurement result and / or recorded SDT event based on the MDT setting parameter.

[0267] Optionally, the recording result sent to the network device by the transceiver module 1502 is an available recording result, and the available recording result is determined by the processing module 1501 based on the number of recorded measurement results and / or the number of recorded SDT events based on the MDT setting parameter.

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

[0269] In a possible implementation, 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, 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, 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. Transceiver module 1502 may be further configured to receive a recording result from the terminal device.

[0272] Note that all relevant content of the steps in the embodiment of the above method can be cited in the function description of the corresponding functional module. Details are not described here again. 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 here again.

[0273] Optionally, the network device or terminal device in this embodiment of the present application may also be referred to as a communication device. The network device or terminal device may be a general-purpose device or a dedicated device, which 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 by obtaining each functional module through division. The "module" here may refer to a specific ASIC, circuit, processor, and memory that execute one or more software or firmware programs, integrated logic circuits, and / or other devices capable of providing the above functions. 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 FIG. 7.

[0275] For example, the processor 701 in the communication device 70 shown in FIG. 7 may call the computer-executable instructions stored in the memory 704 so that the communication device 70 can execute the SDT event recording method in the above method embodiment.

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

[0277] 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 here again.

[0278] It should be understood that the sequence numbers of the above processes do not mean the execution order in various embodiments of this application. The execution order of the processes should be determined based on the functions and internal logics of the processes and should not constitute any limitation to the implementation of the embodiments of this application.

[0279] Those skilled in the art can notice that the exemplary units, algorithms, and steps described with reference to the embodiments disclosed in this specification can be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether the function is executed by hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but it should not be considered that the implementation exceeds the scope of this application.

[0280] Those skilled in the art can clearly understand that, for the sake of convenience and concise description, for the detailed operation processes of the above-described system, device, and unit, reference should be made to the corresponding processes in the embodiment of the above method. Details are not described here again.

[0281] In some embodiments provided by the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the device embodiments described above are merely examples. For example, division into units may be used. For example, a plurality of units or components may be coupled or integrated with other systems, or some features may be ignored or not executed. Also, the couplings, direct couplings, or communication connections shown or discussed may be implemented by using some interfaces. The indirect couplings or communication connections between devices or units may be implemented in electronic, mechanical, or other forms.

[0282] The units described as separate parts may or may not be physically separated, and the parts shown as units may or may not be physical units, that is, they may be located in one place or distributed among a plurality of network units. Some or all of the units may be selected according to actual requirements to achieve the purpose of the solution in the embodiment.

[0283] Also, the functional units in the embodiments of the present application may be integrated into one processing unit, each unit may physically exist alone, or two or more units may be integrated into one unit.

[0284] All or part of the above-described embodiments may be implemented by using software, hardware, firmware, or any combination thereof. When a software program is used to implement an embodiment, all or part of the embodiments may be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the 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 devices. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted in a wired manner (e.g., coaxial cable, optical fiber, or Digital Subscriber Line (DSL)) or wirelessly (e.g., infrared, radio wave, or microwave) from a website, computer, server, or data center to another website, computer server, or data center. The computer-readable storage medium may be any available medium accessible by a computer or a data storage device incorporating one or more available media, such as a server or a data center. The available media may be a magnetic medium (e.g., floppy disk, hard disk, or magnetic tape), an optical medium (e.g., DVD), a semiconductor medium (e.g., Solid State Disk (SSD)), etc.

[0285] As used herein, terms such as "component", "module", and "system" are intended to refer to computer-related entities. A computer-related entity may be hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable file, a thread in execution, a program, and / or a computer. In an example, both an application running on a computing device and the computing device may be components. One or more components may be present in a running process and / or thread, and a component may be located on one computer and / or distributed between two or more computers. Also, these components may be executed from various computer-readable media storing various data structures, such as signals having one or more data packets (e.g., data from a component that interacts with other components in a local system or a distributed system and / or uses the signal via a network such as the Internet to interact with other systems).

[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 or may not include other devices, components, modules, etc., and / or may or may not include all of the devices, components, modules, etc. described with reference to the accompanying drawings. Also, combinations of these solutions may be used.

[0287] In addition, in the embodiments of the present application, the term "example" is used to give an example, an illustration, or a description. Any embodiment or design solution described as an "example" in the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of the term "example" is intended to present the concept specifically.

[0288] In the embodiments of the present application, the terms "information", "signal", "message", and "channel" may sometimes be used synonymously. It should be noted that when the differences among "information", "signal", "message", and "channel" are not emphasized, the meanings expressed by "information", "signal", "message", and "channel" are consistent. The terms "of", "corresponding or relevant", and "corresponding" may sometimes be used synonymously. It should be noted that when the differences among "of", "corresponding or relevant", and "corresponding" are not emphasized, the consistency expressed by "of", "corresponding or relevant", and "corresponding" should be noted. The terms "system" and "network" may sometimes be used synonymously. When the differences between "system" and "network" are not emphasized, the meanings expressed by "system" and "network" are consistent. For example, "communication network" refers to "communication system".

[0289] The network architectures and service scenarios described in the embodiments of the present application are intended to describe the technical solutions in the embodiments of the present application more clearly and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. A person skilled in the art will understand that due to the evolution of network architectures and the emergence of new service scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0290] The above description is only a specific implementation of the present application and is not intended to limit the protection scope of the present application. Various modifications or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present application should fall within the protection scope of the present application. Therefore, the protection scope of the present application should follow the protection scope of the claims.

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

Claims

1. A method for recording a small data transmission SDT event, comprising: receiving, by a terminal device, a first message from a network device, wherein the first message includes a first parameter set, and the first parameter set includes one or more parameters for recording transmission characteristic information within an SDT period; and recording, by the terminal device, the transmission characteristic information corresponding to the one or more parameters in the first parameter set based on the first message. A method having the above steps.

2. The first parameter set includes at least one first parameter, and the first parameter is used to instruct recording of a measurement value of a beam signal of a serving cell. The method according to claim 1.

3. SDT includes configured grant-small data transmission CG-SDT or random access channel-small data transmission RACH-SDT. The first parameter set includes at least one second parameter, and the second parameter is used to instruct recording of an event of the CG-SDT and / or an event of the RACH-SDT. The method according to claim 1 or 2.

4. The events of the CG-SDT are as follows: After transmitting data to the network device on a CG resource, the terminal device does not receive feedback information; When the terminal device transmits data to the network device on a CG resource, the signal value of the target cell is smaller than a preset threshold, or the signal value of the target beam is smaller than a preset threshold; The number of times the terminal device transmits data to the network device on a CG resource reaches the maximum retransmission number; After transmitting a layer 3 L3 message and / or data to the network device on a CG resource, the terminal device starts a CG-SDT timer, and before the CG-SDT timer expires, the terminal device does not receive an acknowledgment message, a layer 2 L2 message, an L3 message, or scheduled data from the network device; or The timing advance TA timer of the terminal device expires and the CG resource becomes unavailable. The method according to claim 3 includes one or more of the above. The method according to claim 3.

5. The event of the RACH-SDT includes one or more of the following: The reason why the terminal device cannot send Msg3 and data to the network device, or The number of times the terminal device fails to send Msg3 and data to the network device and / or the total number of times the terminal device sends Msg3 and data to the network device including one or more of them, wherein the total number includes the number of times of failed transmission of Msg3 and data and the number of times of successful transmission of Msg3 and data, The method according to claim 3 or 4.

6. The first message is a measurement record setting message, The method according to any one of claims 1 to 5.

7. A method for recording small data transmission SDT event, comprising: receiving, by a terminal device, a second message from a network device, the second message including a second parameter set, the second parameter set including one or more parameters for instructing to record service characteristic information within an SDT period, the receiving; recording, by the terminal device, service information corresponding to each parameter in the second parameter set based on the first message; A method having the above.

8. The service characteristic information includes one or more of the following: The cache of the terminal device, the frequency at which the terminal device sends data to the network device, the data sent by the terminal device to the network device exceeding a preset threshold, the frequency at which the terminal device transmits data to the network device in segments, the time and / or frequency at which the terminal device receives an MT-SDT message from the network device, the movement trajectory of the terminal device, the signal strength of the cell reselected by the terminal device, an event in which the terminal device switches from a first network to a second network in a multi-subscriber identity module Multi-SIM scenario, the reason why the terminal device enters an idle state, the reason why the terminal device terminates an SDT session, and an event that triggers the terminal device to request the network device to resume a radio resource control RRC connected state including at least one of them, The method according to claim 7.

9. The reason for the terminal device to enter the idle state is including the terminal device triggering a radio link failure or the terminal device triggering cell reselection, The method according to claim 8.

10. The reason for the terminal device to terminate the SDT session is the terminal device receiving a first indication message used to instruct the terminal device to enter an idle state or an inactive state from the network device, or the SDT timer of the terminal device expiring including The method according to claim 8 or 9.

11. The event that triggers the terminal device to request the network device to resume the radio resource control (RRC) connected state is as follows: Arrival of a non-SDT service, the terminal device triggering cell selection or cell reselection, and in the Multi-SIM scenario, the terminal device switching from the second network to the first network including at least one of The method according to any one of claims 8 to 10.

12. The second message is a measurement record setting message, The method according to any one of claims 7 to 11.

13. A small data transmission (SDT) event recording method, comprising: receiving, by a terminal device, a third message from a network device, the third message being used to instruct the terminal device to record an SDT event and / or measure drive test minimization (MDT) setting parameters; obtaining, by the terminal device, a recording result based on the third message, by recording measurement results based on the MDT setting parameters and / or the SDT event; transmitting, by the terminal device, the recording result to the network device The method having.

14. The third message is a measurement record setting message, The method according to claim 13.

15. The above-mentioned transmitting, by the terminal device, the recording result to the network device is 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 a record result that can be used or that there is a record instruction that can be used in 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 record result to the network device, The terminal device transmits the record result to the network device based on the second instruction message having The method according to claim 13 or 14.

16. The fourth message is carried in a Radio Resource Control (RRC) resume request message or an RRC setup request message. The method according to claim 15.

17. Regarding the above-mentioned transmission of the record result from the terminal device to the network device, includes the terminal device transmitting past record results obtained after the last SDT has ended to the network device for each SDT period. The method according to claim 13 or 14.

18. The past record results are carried in an RRC message or a Medium Access Control (MAC) layer message. The method according to claim 17.

19. Regarding the above-mentioned transmission of the record result from the terminal device to the network device, 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 record result to the network device, and the terminal device transmits the record result to the network device based on the third instruction message having The method according to claim 13 or 14.

20. The third instruction message is a terminal information request message, and the record result is carried in a terminal information response message. The method according to claim 19.

21. Regarding the above-mentioned recording of the measurement results based on the MDT setting parameters and / or the SDT event by the terminal device based on the third message before, the method Further comprising that the SDT timer of the terminal device starts to operate The method according to any one of claims 13 to 20

22. The above-mentioned recording of the measurement result and / or the SDT event based on the MDT setting parameter by the terminal device according to the third message to obtain a recording result includes Recording, by the terminal device, the measurement result and / or the SDT event based on the MDT setting parameter according to the third message When the SDT timer expires, stopping, by the terminal device, the recording of the measurement result and / or the SDT event based on the MDT setting parameter Obtaining, by the terminal device, the recording result based on the measurement result and / or the SDT event based on the MDT setting parameter recorded during the operation period of the SDT timer Comprising The method according to claim 21

23. The above-mentioned recording of the measurement result and / or the SDT event based on the MDT setting parameter by the terminal device according to the third message to obtain a recording result includes Recording, by the terminal device, the measurement result and / or the SDT event based on the MDT setting parameter according to the third message When the SDT session of the terminal device ends, stopping, by the terminal device, the recording of the measurement result and / or the SDT event based on the MDT setting parameter Obtaining, by the terminal device, the recording result based on the recorded measurement result and / or the recorded SDT event based on the MDT setting parameter Comprising The method according to any one of claims 13 to 21

24. The recording result transmitted by the terminal device to the network device is an available recording result, and the available recording result is 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 parameter The method according to any one of claims 13 to 23

25. A communication device having a module or unit configured to implement the method according to any one of claims 1 to 6, 7 to 12, or 13 to 24.

26. A communication device having a processor and a memory, wherein the memory is configured to store computer-executable instructions, the processor is configured to execute the instructions stored in the memory, when the communication device operates, the processor executes the instructions so as to enable the communication device to execute the method according to any one of claims 1 to 6, 7 to 12, or 13 to 24, Communication device.

27. A computer-readable storage medium storing instructions, wherein when the instructions are executed by a computer, the computer can execute the method according to any one of claims 1 to 6, 7 to 12, or 13 to 24, Computer-readable storage medium.

Images